A OpenAI quer aprovar os gateways de IA que oferecem seus modelos. Veja se o seu entra antes de 20/11

No último ano, o gateway de IA virou a caixa mais útil do diagrama de arquitetura. Ele manda cada requisição para o modelo capaz mais barato, aplica orçamentos, registra cada chamada e deixa o time de plataforma trocar de provedor sem mexer nas aplicações. A partir de 20 de novembro, no caso dos modelos da OpenAI, ele também pode precisar da permissão da OpenAI.

Num texto publicado em 21 de outubro, a OpenAI disse que está atualizando suas Usage Policies, com vigência em 20 de novembro de 2026, e que a atualização avança no seu trabalho de segurança “ao exigir que serviços que oferecem acesso direto aos nossos modelos, como model routers ou gateways de IA, obtenham nossa revisão e aprovação antes de oferecer esse acesso”.

No mesmo dia, OpenAI e Google Cloud anunciaram que os modelos da OpenAI vão chegar ao Model Garden do Google Cloud. Os dois anúncios andam juntos. A OpenAI amplia o número de lugares onde seus modelos podem ser comprados e, ao mesmo tempo, aperta as regras sobre quem pode repassá-los.

O que a OpenAI disse de fato

O texto é curto, e os compromissos principais são estes:

• As políticas valem para quem acessa os modelos diretamente, por parceiros que os hospedam ou por revendedores.
• Parceiros que oferecem acesso precisam manter salvaguardas equivalentes às da OpenAI, investigar possíveis violações e agir sobre elas, e coordenar a aplicação das regras para que uma restrição num lugar valha nos outros.
• Serviços que oferecem acesso direto, “como model routers ou gateways de IA”, precisam de revisão e aprovação da OpenAI antes de oferecê-lo.
• A OpenAI está trabalhando com clientes para introduzir os SafetyIDs, identificadores que o cliente pode enviar para que a OpenAI distinga usuários finais numa investigação sem saber quem eles são.

É uma política contratual de um fornecedor, não regulação. Não tem relação com a ANPD nem com o PL 2338: vale para quem aceita os termos da OpenAI, diretamente ou por um parceiro. E, por enquanto, é uma declaração de intenção: o texto não publica o processo de aprovação, os critérios nem eventuais exceções.

Onde a linha provavelmente passa, e onde não está clara

Três configurações comuns se leem de forma muito diferente diante dessa frase.

Um router ou agregador comercial, que vende acesso a muitos modelos, entre eles os da OpenAI, para qualquer um com cartão de crédito. É a leitura mais direta de “serviços que oferecem acesso direto”. Se os seus times usam um, o status de aprovação dele passa a ser uma dependência da sua arquitetura.

Um software que expõe acesso bruto ao modelo para os próprios clientes, por exemplo uma plataforma que deixa o cliente escolher “GPT” num menu e mandar qualquer prompt. Se isso é “acesso direto” ou um produto construído sobre um modelo é justamente o tipo de dúvida que o texto não resolve.

Um gateway enterprise interno, que roteia as requisições dos seus próprios funcionários e aplicações. A maioria das empresas montou um por custo e controle, e já defendemos que o gateway está virando um ponto de aplicação de políticas, não um proxy. O texto não diz se a OpenAI considera um gateway interno um serviço que “oferece esse acesso”. Não presuma nenhuma das respostas. Pergunte ao seu time de conta e tenha a resposta por escrito antes de 20 de novembro.

Por que isso importa mesmo para quem está claramente fora

A estratégia de roteamento passa a depender dos termos de distribuição de cada provedor. Roteamento entre vários provedores supõe que você pode mandar qualquer requisição para qualquer modelo que licenciou. Se um provedor restringe quais intermediários podem carregar seus modelos, um router que perde a aprovação deixa de servir aquele modelo, e o seu plano de contingência precisa cobrir isso.

Os canais aprovados vão se multiplicar, e não são iguais. Os modelos da OpenAI já chegam diretamente, pela Microsoft, por compromissos com a Oracle, pelo Bedrock Managed Agents da AWS em preview e, em breve, pelo Google Cloud. Cada um é um caminho aprovado, com controles e prazos próprios. Um router sem aprovação é um caminho que pode fechar. O inventário de modelos deve dizer qual caminho cada carga usa, como sugerimos na nossa análise da chegada da OpenAI ao Google Cloud.

Identidade por usuário no gateway deixa de ser opcional. Os SafetyIDs existem porque um provedor que investiga abuso por uma chave de API compartilhada enxerga um cliente, não a pessoa que causou o problema. A alternativa da OpenAI a essa ambiguidade é restringir a chave inteira. Um gateway que repassa um identificador de usuário estável e pseudonimizado permite que a investigação mire um usuário em vez da aplicação toda. É boa prática para a sua própria trilha de auditoria de qualquer forma; a Databricks, por exemplo, deixa as políticas do gateway lerem o contexto da requisição enviado por quem chama.

Antes de 20 de novembro

1. Liste todos os caminhos pelos quais a empresa chega aos modelos da OpenAI: API direta, marketplaces de nuvem, routers e ferramentas SaaS que chamam a OpenAI por baixo. O último grupo costuma ser o mais longo.
2. Pergunte a cada fornecedor de router e plataforma de IA se pediu ou recebeu a aprovação da OpenAI, e o que acontece com o seu tráfego se não tiver recebido até 20 de novembro.
3. Pergunte à OpenAI ou ao seu revendedor se o seu gateway interno está no escopo, e registre a resposta.
4. Inclua uma cláusula de continuidade nos contratos de router: aviso prévio se o fornecedor perder acesso a um provedor, e uma alternativa definida.
5. Repasse um identificador pseudonimizado de usuário final pelo gateway a todo provedor que aceite um, para que uma investigação de abuso pare num usuário e não na sua aplicação.

Nada disso é motivo para abandonar gateways. É motivo para tratar o gateway como o que ele virou: uma parte contratual da sua cadeia de fornecimento de modelos, não só encanamento.