Unity AI Gateway: como governar múltiplos modelos de IA sem perder controle
Em setembro de 2026, o GPT-6 Astra da OpenAI chegou ao Unity AI Gateway do Databricks no mesmo dia do seu lançamento público — ao lado de Claude, Gemini e DeepSeek V4.1 Flash, todos sob a mesma camada de controle. Não é um detalhe de release note. É a confirmação de que a pergunta que mais importa em projetos de IA corporativa deixou de ser “qual modelo usar” e passou a ser “como governar o acesso a todos os modelos que sua empresa vai usar, hoje e daqui a seis meses”.
Esse artigo explica o que é o Unity AI Gateway, por que ele resolve um problema real de arquitetura — não só de compliance — e como ele se conecta ao restante da governança de dados no Unity Catalog.
Por que a maioria das empresas perde o controle da governança de IA
O padrão mais comum em empresas que começam a usar múltiplos modelos de LLM é a descentralização silenciosa: um time integra a API da OpenAI direto no código, outro usa Claude via chave própria, um terceiro testa um modelo open-source auto-hospedado. Cada integração vira uma chave de API isolada, sem inventário central, sem log unificado e sem orçamento visível até a fatura do mês seguinte.
O resultado técnico é previsível: não existe visibilidade de quanto cada time gasta, não existe trilha de auditoria de quais dados foram enviados para qual modelo, e não existe um jeito único de aplicar uma política de acesso (por exemplo, “dados de clientes nunca saem para modelo externo sem mascaramento”). Quando a área de compliance ou segurança pergunta “quais modelos de IA processam dados sensíveis da empresa hoje”, a resposta correta costuma ser “não sabemos com certeza” — e isso é o problema real por trás do Marco Legal da IA (PL 2338) e de qualquer auditoria de fornecedor de IA.
O Unity AI Gateway como ponto único de acesso a modelos
O Unity AI Gateway funciona como um proxy governado entre as aplicações da empresa e os provedores de modelo — internos (Mosaic AI) ou externos (OpenAI, Anthropic, Google, DeepSeek). Em vez de cada aplicação guardar sua própria chave de API, toda chamada passa por um endpoint único dentro do Unity Catalog, que decide, com base em política, se aquela chamada pode acontecer, para qual modelo ela deve ser roteada e com qual limite de custo.
Auditoria e controle de orçamento por chamada
Cada chamada ao Gateway gera um registro de auditoria: quem chamou, qual modelo, qual payload (ou seu hash, dependendo da política de dados sensíveis), quanto custou e quanto tempo levou. Orçamentos podem ser definidos por usuário, por time ou por aplicação — e o Gateway bloqueia ou alerta antes que o limite seja estourado, em vez de a empresa descobrir o excesso na fatura do provedor.
Governança de acesso conectada ao Unity Catalog
O Gateway não é uma camada isolada — ele herda o modelo de permissionamento do Unity Catalog. Com as ABAC DENY policies (em beta desde o ciclo de release de setembro/2026), é possível negar acesso a um modelo ou a um conjunto de dados com base em atributos (por exemplo, classificação de sensibilidade de uma tabela), em vez de depender só de listas de permissão estáticas por usuário. Isso conecta a decisão de “quem pode chamar qual modelo” à mesma linhagem e classificação de dados que já governa o resto do Lakehouse.
Roteamento e resiliência à troca de modelo
Como o Gateway abstrai o provedor por trás de um endpoint único, trocar de modelo — por custo, performance ou descontinuação de um fornecedor — vira uma mudança de configuração no Gateway, não uma reescrita de código em cada aplicação que consome IA. Com sete a doze lançamentos de modelo por mês no mercado atual, essa resiliência deixou de ser luxo arquitetural e virou requisito operacional.
Como isso funciona na prática
Um padrão comum em projetos de modernização de governança de IA: a empresa já tem dois ou três modelos em uso espalhados por times diferentes, sem inventário central. O primeiro passo é um levantamento de todas as integrações de IA existentes — chaves de API, endpoints, times responsáveis. Em seguida, essas integrações são migradas para passar pelo Unity AI Gateway, com políticas de acesso mapeadas a partir da classificação de dados já existente (ou construída nesse momento, se ainda não existir) no Unity Catalog. O resultado, ao final desse tipo de projeto, costuma ser o mesmo: a empresa passa a ter, pela primeira vez, uma resposta objetiva para “quanto gastamos com IA por time” e “quais dados sensíveis passam por modelo externo” — perguntas que antes exigiam pedir a cada time individualmente.
Governança de IA não é sobre escolher o modelo certo
A escolha do modelo de IA vai continuar mudando — a cada duas semanas, se o ritmo de 2026 se mantiver. A camada de governança é o que garante que essa mudança não vire um projeto de reescrita cada vez que um modelo novo for adotado ou descontinuado.
Se sua empresa já usa mais de um modelo de IA e ainda não tem visibilidade centralizada de custo, acesso e auditoria, esse é exatamente o tipo de diagnóstico que a Arbit conduz com clientes que já operam em Databricks.
