Governança
não é um endereço
de API

Duas estreias, uma pergunta antiga

Uma equipe conecta modelos e ferramentas MCP por caminhos diferentes. Cada produto promete uma entrada governada: autenticação, permissão, rastros e gestão de custo em vez de integrações isoladas. Em 15 de setembro, a Snowflake abriu o Cortex AI Gateway em preview para modelos disponíveis no Cortex. No dia seguinte, a Databricks levou a API de administração do Unity Gateway à disponibilidade geral, incluindo recursos de provedores e MCP. As duas mudanças são reais, mas não são a mesma entrega. Uma estreia um caminho de inferência; a outra estabiliza as operações de gestão de recursos já existentes.

A pergunta de engenharia não é qual painel parece mais completo. É se a política vê todas as requisições que pretende governar. Uma aplicação pode ser configurada para a URL-base do gateway, com token PAT da Snowflake e permissões adequadas; no SDK Anthropic, ainda é preciso adaptar a autenticação para o cabeçalho Bearer. Outra pode continuar chamando uma API direta. O mesmo modelo pode responder nos dois caminhos enquanto apenas um produz o rastro, a atribuição de custo e a decisão esperados pela equipe de plataforma.

O que a porta da Snowflake controla

O Cortex AI Gateway é um objeto único criado automaticamente em cada conta elegível. Ele expõe um endpoint compatível com formatos de API usados por clientes OpenAI e Anthropic. A especificação permite listar os modelos servidos e configurar registros de atividade. Na rota do gateway, o consumo é associado ao usuário Snowflake. Quando o registro está habilitado, a plataforma grava informações como modelo, duração, tokens e erros. Capturar o conteúdo de prompts e respostas exige uma configuração adicional.

Há uma distinção importante entre acesso ao gateway e acesso ao modelo. A documentação informa que o privilégio USAGE do gateway é concedido a PUBLIC por padrão, mas afirma também que isso não amplia as permissões sobre os modelos subjacentes. Portanto, a configuração inicial não prova que qualquer pessoa possa chamar qualquer modelo. Quem quiser restringir a entrada precisa revisar o privilégio do gateway e as permissões de inferência.

O produto está em preview aberto apenas nas regiões comerciais AWS que a Snowflake enumera, com exclusões explícitas. Preço de inferência por token segue a tabela do modelo; o gateway não é, por si, uma economia. Sua contribuição operacional é tornar acesso, telemetria e atribuição observáveis numa rota comum.

O caminho direto continua existindo

A documentação da Snowflake descreve uma segunda entrada, Cortex Inference, no caminho direto da conta. Ambas aceitam requisições de inferência, mas somente o tráfego que passa pelo Cortex AI Gateway recebe os controles, rastros e atribuição de custo do gateway. Essa frase não declara a API direta insegura: os privilégios do modelo e outros controles continuam relevantes. Ela delimita a cobertura do produto anunciado.

O risco de arquitetura é mais sutil que um invasor contornando uma barreira. Uma equipe pode acreditar que centralizou a governança enquanto um cliente legado, um SDK com URL antiga ou uma integração de teste ainda usa o caminho direto. O painel do gateway estará correto para o tráfego que conhece e silencioso sobre o restante. Se o orçamento ou a auditoria foram definidos apenas ali, o silêncio pode ser confundido com ausência de uso.

Também há limites dentro da própria rota governada. O registro de metadados depende da configuração de logging; conteúdo de prompt e resposta não entra automaticamente nos rastros. Isso pode proteger dados sensíveis, mas impede investigar algumas falhas somente pelo painel. Identificadores de conversa e de trace dependem de campos enviados pelo cliente. Governança útil precisa decidir quais dados registrar, quem pode vê-los e quanto tempo serão retidos.

A comparação com Databricks exige cuidado

No Unity Gateway, a novidade de 16 de setembro foi a disponibilidade geral da API e das ferramentas para criar, ler, alterar, listar e apagar serviços de modelos, provedores e MCP. Terraform, CLI e SDKs tornam esses recursos administráveis como código. É uma mudança de operação relevante para equipes que precisam repetir configurações, revisar diferenças e recuperar um ambiente depois de uma falha.

Isso não torna todas as capacidades do Unity Gateway equivalentes às do preview da Snowflake, nem significa que cada política de serviço já esteja em GA. A própria Databricks mantém algumas funções em beta e avisa que releases podem chegar às contas em etapas. Comparar apenas o rótulo “gateway” apaga diferenças de escopo: plano de gestão, caminho de inferência, autorização e observabilidade são contratos distintos.

O teste antes de chamar isso de política

Um ensaio seguro começa numa conta de teste, sem dados reais. Inventarie clientes, credenciais e URLs-base. Faça a mesma chamada permitida pelo gateway e pelo caminho direto, depois repita com um usuário sem o privilégio necessário. Confira onde cada tentativa aparece, o que é negado e quais custos são atribuídos. Teste separadamente a quota por usuário, que pode bloquear chamadas após a avaliação em minutos, e o orçamento compartilhado, cuja notificação e ação personalizada são avaliadas periodicamente, sem corte imediato garantido. Simule também uma falha de rede e veja se o cliente muda de endpoint ou tenta novamente fora da rota observada.

O Korvo não executou esse experimento. O critério para confiar na arquitetura é observável: cada aplicação em escopo usa a rota escolhida, cada rota alternativa tem uma decisão explícita, e as negativas e os custos podem ser reconciliados sem depender de uma suposição sobre o SDK. Governança não é o endereço escrito na configuração. É a cobertura verificável entre intenção, caminho e consequência.