Dev & EngARTIGO

Como a Tailscale construiu um roteador de modelos de IA sobre o AI Gateway da Vercel

O case do Aperture mostra um padrão reaproveitável para quem precisa rotear centenas de modelos, controlar acesso por identidade e rodar agentes isolados sem construir a infraestrutura do zero.

0
Como a Tailscale construiu um roteador de modelos de IA sobre o AI Gateway da Vercel
Imagem gerada por IA

A Tailscale é conhecida por conectar laptops, servidores, instâncias de nuvem e dispositivos pessoais em uma rede privada única, a chamada tailnet. O que o changelog da Vercel documenta é como a empresa pegou esse mesmo conceito e aplicou a modelos de IAInteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI , através do produto Aperture, construído sobre AI Gateway e Vercel Sandbox.

A ideia central do Aperture é deixar de distribuir chaves de API de provedores individualmente para cada funcionário, agente ou ferramenta. Em vez disso, o acesso aos modelos passa pela própria identidade de rede: adiciona-se alguém à tailnet e ele usa os modelos aprovados na hora; remove-se, e o acesso desaparece. Remy Guercio, líder de produto do Aperture, resume o conceito da tailnet como "basicamente uma VPC que pode abranger qualquer nuvem, on-prem, sua casa e seu celular".

Para o dev brasileiro que está montando uma camada de IA em produção, o interessante aqui não é a Tailscale em si, mas o padrão de arquitetura que o case expõe: um roteador de modelos com controle de acesso por identidade, custo transparente e execução isolada de agentes. Vale entender o que a Vercel entrega pronto e onde ainda é preciso colocar a mão.

Por que rotear modelos é mais difícil do que parece

A Tailscale é uma empresa de infraestrutura, então construir a camada de roteamento internamente era a primeira opção óbvia. Eles desistiram depois de olhar o esforço de engenharia de perto.

O ponto que costuma pegar quem monta esse tipo de camada é achar que os endpoints dos provedores são intercambiáveis. "Você acharia que todos os endpoints são iguais", diz Remy. "Eles não são." Cada provedor tem particularidades de formato, autenticação, streaming e semântica de erro que precisam ser normalizadas.

David Carney, cofundador e chief strategy officer, aponta um detalhe concreto que ilustra bem o trabalho invisível de um gateway:

Há muitas coisas que os grandes provedores não fazem, e me espanta que o gateway faça, como simplesmente colocar o custo na resposta. Inicialmente construímos esses sistemas para clientes nós mesmos, e a complexidade é insana.

David Carney, cofundador da Tailscale

Retornar o custo em cada request parece trivial, mas exige manter tabelas de preço atualizadas por provedor e por modelo, algo que muda constantemente. O AI Gateway devolve custo e uso a cada chamada, o que permite ao Aperture mostrar gasto ao cliente sem a Tailscale manter esse cadastro.

Zero data retention como requisito, não como feature

Os clientes da Tailscale se importam com proteção de dados, então zero data retention (ZDR) era condição mínima. O AI Gateway ajuda em duas frentes: o próprio gateway não retém dados, e é possível configurar ZDR globalmente ou por request, com a flag zeroDataRetention, que restringe automaticamente o roteamento a provedores compatíveis.

Esse é o tipo de lógica que ninguém quer manter à mão. "Todo esse assunto de ZDR é um alvo em movimento, quais modelos têm zero data retention e quais não têm", diz David. "Mas não temos que escrever nenhuma dessa lógica, porque tudo é tratado para nós." Na prática, delegar essa decisão de roteamento significa que quando um provedor muda sua política, o comportamento do sistema acompanha sem deploy.

Outro ponto de negócio relevante: o AI Gateway não aplica markup sobre o custo dos tokens de nenhum provedor ou modelo, inclusive quando os clientes da Tailscale trazem as próprias chaves. Quem consome o Aperture paga a mesma tarifa que pagaria indo direto ao provedor.

Agentes isolados na tailnet com Vercel Sandbox

A parte que mais eleva a barra de segurança é a execução de agentes. Um agente que lê dados privados, age sobre o texto que lê e ainda alcança a internet pública configura o problema que o texto chama de "lethal trifecta" (a tríade letal). A mitigação correta é um sandbox isolado, com identidade e controle de acesso embutidos.

O fluxo que o Aperture roda para agentes, descrito na fonte, é enxuto e vale como referência de desenho:

  1. Um sandbox sobe e se conecta ao Aperture.
  2. O Aperture se conecta ao AI Gateway.
  3. A Tailscale valida a identidade.
  4. O agente faz seu trabalho.
  5. O sandbox é desligado.

O detalhe crítico: nenhuma chave é entregue ao agente. A autenticação acontece na borda, por identidade de rede, e o segredo nunca chega ao código que o agente executa. Esse desenho reduz drasticamente a superfície de vazamento de credencial, um problema recorrente em orquestração de agentes.

A Tailscale chegou a ter uma implementação completa de sandbox em outro provedor antes de trocar. O motivo da migração foi de foco, e não só técnico:

Tentamos muitos provedores diferentes de sandbox e até tínhamos uma implementação completa em um deles, e ainda assim trocamos para a Vercel. Foi surpreendentemente fácil migrar tudo.

Remy Guercio, líder de produto do Aperture na Tailscale

A justificativa de Remy é a que interessa a quem decide stack: "Queríamos focar em identidade de rede, não em fronteiras de segurança de sandbox." É o clássico build vs. buy aplicado a IA, onde o diferencial do produto é a identidade, não o isolamento do runtime.

A migração interna: cutover sem interrupção

O uso interno de IA da Tailscale tinha crescido do jeito que quase toda empresa cresce: uma mistura de contas diretas de provedores e endpoints de nuvem, acumulados um time de cada vez. Internamente essas requisições já passavam pelo Aperture, mas atrás do proxy ainda se chamava cada provedor diretamente.

O time de engenharia construiu um chave dentro do Aperture apontando as requisições para o AI Gateway em vez das APIs individuais. Como o Aperture continuava sendo o endpoint chamado e todos os modelos já em uso estavam no catálogo do gateway, a virada aconteceu sem interrupção. "Conseguimos migrar a empresa inteira para o AI Gateway em segundos, e ninguém percebeu", diz Remy.

Esse é o ponto de arquitetura que dá para copiar mesmo sem usar Vercel: se sua aplicação sempre falou com um proxy interno em vez de falar direto com provedores, trocar o que está atrás do proxy vira uma decisão de configuração. A abstração paga o próprio custo no dia da migração.

O que dá pra levar (e onde não vale)

O conceito de "time to first token" aparece com dois sentidos no case, e ambos são úteis. O técnico é o clássico: quanto tempo para carregar o cache, gerar a resposta e devolver ao usuário, ou seja, latência. O de produto, que David gosta de usar, é o tempo do cadastro do usuário até a primeira chamada de modelo, o time-to-value real. Vale separar os dois quando se define métrica de sucesso de uma feature de IA.

O conselho final de David é direto: focar no produto entregue ao cliente, não na infraestrutura para rodá-lo. "Muita gente quer construir o próprio roteador. E olhe para nós, tentamos também. Mas você não precisa construir outro roteador."

Cabe a ressalva de leitura: o case é publicado pela própria Vercel, então os números e elogios vêm de quem vende o produto, sem benchmark independente. Amarrar-se ao AI Gateway e ao Sandbox é uma dependência de fornecedor real, e o argumento "não construa seu próprio roteador" convém a quem vende roteador. Para times pequenos com poucos provedores e sem requisito de ZDR ou execução de agentes, uma camada fina própria pode ser mais barata do que adotar toda uma plataforma. O padrão que importa aqui, proxy interno único, custo por request, identidade na borda e sandbox efêmero sem chave, é replicável independentemente do fornecedor escolhido.

Fonte: Vercel Changelog

Este artigo foi escrito por Carina Ferreira, colunista de front-end do iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Rosa. Saiba como produzimos no expediente.

Carina FerreiraEspecialista virtual

Especialista virtual de front-end. Vive de TypeScript, React/Next e da fronteira AI + front (copilots, geração de UI, edge). Obcecada por DX e performance percebida — mede antes de opinar e mostra o antes/depois.

Ver perfil

Comentários

0/1200

Ninguém comentou ainda. Começa a conversa?