Governança de IA em 2026: O Framework Americano, o PL 2338 e o Que o Seu Time Precisa Documentar

Na quinta-feira passada chegou um e-mail do jurídico com uma pergunta de três linhas: qual é a nossa política de uso de IA, e quem assina por ela. Não era hostil — era um cliente grande preenchendo questionário de fornecedor, e o campo pedia o nome de um documento e a data da última revisão. Passei uns bons quinze minutos procurando algo que pudesse ser honestamente apontado como resposta e cheguei a uma página de Confluence escrita em janeiro, quando a gente ainda chamava aquilo de "piloto".

O que me incomodou não foi a página desatualizada. Foi perceber que, se a pergunta tivesse sido mais específica — quais modelos exatamente estão em produção hoje, em qual versão, com qual credencial, e o que cada um deles fez na semana passada —, eu teria levado dias juntando pedaço de log, print de painel e memória de gente. E teria entregado algo que ninguém de fora consegue verificar, o que na prática é o mesmo que não ter resposta.

Enquanto isso, no andar de cima do problema, a semana anterior tinha sido movimentada. Em 3 de agosto foi anunciada uma reunião na Casa Branca com as principais empresas de IA, realizada no dia 4, para revisar um novo framework de teste de modelos. Estavam lá OpenAI, Anthropic, Google e Meta. Foi noticiado como o primeiro movimento grande de regulação de IA nos Estados Unidos, e a leitura imediata em boa parte do mercado foi de que "agora vem a régua".

Passei o domingo lendo o que saiu sobre isso e cheguei a uma conclusão mais desconfortável do que a manchete sugere. O framework é voluntário, é opt-in, e — detalhe que quase não apareceu nos resumos — boa parte dos padrões que ele define não será divulgada publicamente. Se você roda agente em produção e esperava que esse movimento virasse um checklist para o seu time seguir, ele não vira. Este post é sobre o que de fato aconteceu, por que a forma dele importa mais que o conteúdo, e quais seis registros eu defenderia ter escrito até o fim deste trimestre — independentemente do que qualquer regulador decida.

---

O Que De Fato Aconteceu Em 4 De Agosto

O desenho é o seguinte. A reunião, anunciada em 3 de agosto e realizada no dia seguinte, serviu para revisar com as empresas um framework de teste de modelos. O mecanismo central é que elas poderiam dar ao governo acesso antecipado a certos modelos de fronteira por até trinta dias antes do lançamento, para avaliações de segurança. O framework nasce de uma ordem executiva de junho de 2026 do presidente Donald Trump sobre cibersegurança em IA, que já tinha estabelecido a abordagem opt-in para essas revisões.

Duas coisas ficam explícitas e vale separar bem. A primeira é que a participação é voluntária: nenhuma empresa é obrigada a submeter modelo nenhum. A segunda é que o instrumento não pode ser usado para criar licenciamento obrigatório ou aprovação prévia — não existe cenário em que um modelo fica impedido de lançar porque a avaliação não terminou. É uma janela de observação, não um portão.

Chris Lehane, Chief Global Affairs Officer da OpenAI, chamou o movimento de "um passo importante para fechar a lacuna entre inovação e governança". Anthropic, Google e Meta não comentaram — assimetria que já diz alguma coisa sobre quanto consenso existe ali dentro.

O contexto temporal é a parte que menos apareceu e que mais importa para quem trabalha com isso. A reunião veio poucos dias depois de OpenAI e Anthropic reportarem incidentes de agentes de IA saindo do controle e invadindo sistemas de outras empresas. É a sequência clássica de qualquer área técnica que amadurece por incidente: o problema aparece na operação primeiro, vira reporte público depois, e só então chega à mesa onde se discute regra. O modo de falha, nos dois casos, não foi o modelo "querendo" algo — foi o ambiente ao redor dele deixando alcançar algo.

Quero registrar uma coisa antes de seguir, porque ela costuma se perder nessa conversa. Um framework voluntário de teste pré-lançamento é razoável de existir. Ele endereça um problema real — capacidade perigosa descoberta tarde demais — no único ponto em que ainda é barato agir, antes do modelo estar em dez mil integrações. O que estou questionando não é a existência dele. É a distância entre ele e você.

---

Um Padrão Que Você Não Pode Ler Não É Um Padrão Que Você Pode Seguir

Aqui está o detalhe que reorganizou a minha leitura da notícia inteira: os detalhes do framework não serão divulgados publicamente, e boa parte dos padrões definidos ali será classificada.

Um padrão de segurança tem valor por dois canais distintos. O primeiro é o direto: os laboratórios que submetem modelos passam a ser avaliados contra ele. O segundo, e historicamente o mais importante, é o de difusão: todo mundo abaixo na cadeia lê o padrão, entende o que ele considera risco, e ajusta a própria operação para se parecer com aquilo. Foi assim que OWASP, CIS Benchmarks, NIST CSF e uma dúzia de outros documentos moldaram práticas em empresas que nunca falaram com regulador nenhum. O documento público é o produto.

Um padrão classificado tem o primeiro canal e não tem o segundo. Pode até fazer o trabalho dele nos quatro ou cinco laboratórios de fronteira, mas não desce. Você não alinha a sua arquitetura de agente a um critério que não tem permissão para ler, e não dá nem para discordar dele de forma útil.

Temos então um movimento regulatório de alto nível acontecendo e nenhuma tradução acionável dele para a camada onde a maioria dos incidentes acontece — que não é o treino do modelo, é o agente rodando com credencial ampla demais dentro da VPC de uma empresa média. Os incidentes que motivaram a reunião foram desse tipo, e são justamente o tipo que teste pré-lançamento não cobre: o comportamento problemático emerge da combinação entre modelo, ferramenta, permissão e ambiente, que só existe depois que o modelo saiu da mão de quem o treinou.

Some com isso a esperança que vejo circulando em conversas de liderança técnica desde o começo de agosto: a de que o regulador vá produzir uma referência que o time possa adotar e, ao adotar, terceirizar parte do julgamento. É compreensível — governança é cara, ambígua e nunca é prioridade do trimestre. Mas não vai se realizar por esse caminho. O padrão que existe não é legível, e o que é legível ainda não é padrão.

A conclusão prática é desconfortável e é o eixo deste post: a documentação que protege o seu time é a que o seu time escreve. Ninguém vai escrever por você, e o gap entre "temos boas práticas" e "conseguimos provar o que fizemos" continua sendo trabalho manual de gente sênior. A boa notícia é que esse trabalho é bem menor do que parece quando você o recorta direito.

---

Por Que Isso Chega Ao Seu Time Mesmo Sem Obrigar Ninguém A Nada

Alguém vai ler o que está acima e concluir, com alguma lógica, que se o framework é voluntário e classificado então ele não é problema seu. Discordo, e o motivo não é jurídico.

Regulação de tecnologia raramente chega ao time técnico pela via da lei. Chega pela via contratual, e chega antes. O caminho é sempre o mesmo: um movimento regulatório de destaque acontece, os departamentos de compliance das empresas grandes leem a notícia, e em seis ou oito semanas o questionário de fornecedor ganha três campos novos. Foi assim com LGPD, com SOC 2, com o Cyber Resilience Act europeu. Ninguém do meu time leu o texto integral de nenhum desses. Todos nós já preenchemos as planilhas derivadas deles várias vezes.

O que muda depois de agosto de 2026 não é que alguém vai te fiscalizar. É que "governança de IA" acabou de ganhar peso suficiente para entrar em processo de compra — e ali a pergunta não é filosófica, é documental: mostre o inventário, mostre a trilha, mostre a política, mostre a data da última revisão. Se você não tem, o custo não é multa. É um ciclo de venda travado por seis semanas enquanto alguém monta às pressas um documento que deveria existir desde o começo.

Tem uma segunda razão, essa interna. Se você já tem agente em produção, você já tem o risco. A ausência de documentação não reduz o risco, só remove a sua capacidade de responder quando ele se materializa. Escrevi em shadow AI e a lacuna de governança sobre agentes em produção sobre o dado que mais me incomoda nessa área: entre organizações que sofreram incidente relacionado a IA, uma proporção grande não tinha política de governança nenhuma. Não é que a política teria evitado o incidente. É que sem ela ele vira investigação arqueológica de duas semanas em vez de consulta de vinte minutos.

E tem a razão mais honesta de todas, que é operacional e não tem a ver com auditor nenhum. Time que não sabe listar os modelos que roda também não sabe estimar impacto de depreciação de API. Time que não sabe qual credencial cada agente usa não consegue rotacionar segredo sem quebrar coisa. Documentação de governança e documentação de operação são, quase sempre, o mesmo documento com dois leitores diferentes. Vale escrever mesmo que nenhum regulador apareça.

---

Os Seis Registros Que Eu Defenderia Ter Escrito Até O Fim Do Trimestre

Uso aqui a única lista estruturada do post, porque essa parte precisa ser conferível item a item. Cada um dos seis é um artefato que pode ser aberto, lido e datado por alguém de fora do time. Nenhum exige comprar ferramenta; todos exigem alguém sentar e decidir coisas.

1. Inventário de modelos e versões em uso. Uma tabela com cada modelo em produção, o provedor, a versão exata ou o alias fixado, em qual serviço ele é chamado, e quem é o dono técnico daquela chamada. O motivo não é burocrático: modelo virou a parte mais volátil do stack, e a maioria dos times aponta para alias móvel do tipo "latest" sem perceber que isso significa que o comportamento do sistema pode mudar sem um único commit. Sem inventário você não responde a pergunta mais básica de qualquer incidente — "isso mudou?" — porque não sabe qual era o estado anterior. E quando um provedor anuncia depreciação, a diferença entre uma tarde e três semanas de trabalho é exatamente ter ou não ter essa tabela.

2. Identidade e permissão de cada agente. Cada agente com identidade própria, não compartilhada com serviço nem com pessoa, e uma lista explícita do que aquela identidade alcança. Sem identidade separada você perde a capacidade de atribuir ação, e sem atribuição não existe auditoria — só um log dizendo que a service account genérica fez alguma coisa. É o assunto de identidades não-humanas e gestão de acesso de agentes, e o padrão que mais vejo continua sendo o pior: o agente herda a credencial da aplicação que o hospeda, que por sua vez tem permissão ampla por razões históricas que ninguém lembra. O exercício útil não é escrever a permissão que você acha que o agente tem. É ir na IAM, listar o que a identidade de fato alcança, e comparar.

3. Trilha de auditoria do que o agente fez e com qual autorização. Para cada ação com efeito colateral — escrita em banco, chamada externa, envio de mensagem, criação de recurso — um registro com quem pediu, qual agente executou, com qual identidade, sobre qual recurso, e o resultado. O log de aplicação tradicional foi desenhado para depurar código determinístico e responde "o que o sistema fez". A pergunta que aparece num incidente com agente é outra: por que ele achou que devia fazer isso, e quem autorizou. Isso exige correlacionar decisão e efeito no mesmo trace, tema de observabilidade e tracing de agentes em produção. Se for para fazer um único item desta lista bem feito, faça esse.

4. Evidência de eval antes de promover mudança. Um conjunto congelado de casos, com resultado registrado por versão, rodado antes de qualquer promoção — troca de modelo, mudança de prompt, ferramenta nova, ajuste de permissão. Sem isso você não distingue "a qualidade caiu" de "as pessoas pararam de reclamar". E toda decisão de custo vira aposta: rebaixar modelo, cortar contexto ou migrar para provedor mais barato são escolhas racionais quando se consegue medir o que foi perdido, e irresponsáveis quando não. O que precisa ficar registrado não é o número bonito. É a data, a versão testada, o resultado e a decisão tomada com base nele.

5. Procedimento de incidente com dono nomeado. Uma página respondendo: como se desliga o agente, quem pode desligar sem escalar, qual é o canal, qual é o prazo de comunicação, e o nome — nome de pessoa, não de time — de quem responde fora do horário comercial. Nomear pessoa é o que mais gera resistência e é a parte mais importante do documento. "O time de plataforma responde" significa, às três da manhã, que ninguém responde. E o item que mais falta nesses procedimentos é o mais óbvio: o botão de desligar. Já vi mais de uma arquitetura em que interromper o agente em execução exigia deploy, o que na prática significa que ele não podia ser interrompido.

6. Retenção de log com prazo definido. Uma decisão escrita de por quanto tempo cada tipo de registro é mantido, onde, e quem pode ler. Isso é item separado porque os cinco anteriores só valem se os dados ainda existirem quando alguém for procurar. O padrão silencioso da maioria dos times é reter o que a ferramenta retém por default, sete ou trinta dias — confortável para depurar bug, insuficiente para investigar comportamento que só ficou evidente depois. Prompt e resposta frequentemente carregam dado pessoal, então essa decisão passa pelo jurídico de qualquer jeito. Melhor que passe agora, por escrito, do que na semana do incidente.

---

Por Que Esses Seis E Não Uma Política De Trinta Páginas

A objeção previsível é que essa lista é pequena demais para o tamanho do problema. Concordo que é pequena; discordo que isso seja defeito.

Toda vez que vi um time atacar governança de IA com ambição de completude, o resultado foi um documento longo, escrito por uma pessoa, aprovado por três, lido por zero. Ele existe para ser anexado no questionário do cliente e não descreve nada do que o sistema faz. A distância entre ele e a operação real só cresce, porque não há mecanismo que o force a acompanhar mudança.

Os seis itens acima têm propriedade diferente: cada um é subproduto de algo que o time já precisa fazer para operar bem. Você já precisa saber quais modelos roda para não quebrar em depreciação, já precisa de identidade separada para rotacionar segredo, já precisa de trace para depurar. Documentação que nasce colada na operação envelhece junto com ela, e é a única que já vi se manter viva por mais de dois trimestres.

Tem uma segunda razão para preferir o recorte pequeno: defensabilidade. Trinta páginas descrevendo intenções são difíceis de defender numa auditoria, porque cada afirmação abre uma pergunta de acompanhamento. Seis artefatos que descrevem estado — este é o inventário, esta é a permissão, este é o log, esta é a data — são fáceis de defender exatamente porque não prometem nada. Eles mostram. A conversa deixa de ser sobre o que você acredita e passa a ser sobre o que está registrado.

Vale dizer o que essa lista não cobre, para não vender mais do que ela entrega. Ela não fala de viés, de avaliação de impacto sobre direitos, de transparência para o usuário final, nem de classificação de risco por caso de uso — dimensões reais e, em vários setores, as que o regulador vai olhar primeiro. Estou recortando de propósito a fatia de infraestrutura e operação, onde o time técnico decide sozinho e entrega em semanas. As outras exigem produto, jurídico e às vezes cliente na mesa, e travar as seis por causa delas é a forma mais comum de não entregar nenhuma.

---

O Brasil, O PL 2338 E A Diferença De Velocidade

Do lado de cá a discussão tem outro formato. O PL 2338 adota abordagem baseada em risco, mais próxima em espírito do modelo europeu do que do americano: classifica sistemas por nível de risco, impõe obrigações proporcionais a essa classificação, e trata direitos do titular e transparência como parte central. Escrevi sobre a estrutura dele em o Marco Legal da IA no Brasil e o PL 2338 e não repito a análise aqui.

O que quero destacar é a comparação entre os dois movimentos, instrutiva mesmo para quem não se importa com nenhum deles. São desenhos quase opostos. O americano é voluntário, focado no topo da cadeia, opera no pré-lançamento do modelo e é parcialmente secreto. O brasileiro é vinculante por natureza, focado na aplicação e no uso, opera depois que o sistema está em campo e é público por definição, como todo texto legal. Um mira quem treina; o outro mira quem implanta.

Para o seu time, o segundo desenho importa mais, e isso raramente é dito. Você quase certamente não treina modelo de fronteira — você implanta. Qualquer regime que classifique risco por caso de uso cai sobre a sua aplicação, não sobre o laboratório de onde veio o modelo, e as obrigações derivadas dele serão de documentação, rastreabilidade e explicação, que é precisamente o conteúdo dos seis itens da seção anterior. Não é coincidência: são as exigências a que todo regime de conformidade converge, porque são as únicas verificáveis de fora.

E aqui vem a parte honesta, que é a razão de eu ter escrito isso num domingo em vez de deixar quieto. Os dois movimentos caminham em velocidades diferentes, e nenhum chega a tempo do seu problema. O processo legislativo brasileiro tem o ritmo que tem, e mesmo texto aprovado precisa de regulamentação, prazo de adequação e órgão com capacidade instalada para significar alguma coisa. Do lado americano, um instrumento voluntário e classificado pode se consolidar rápido dentro dos laboratórios e nunca produzir referência pública que desça até você. Se o seu agente está em produção agora, com permissão ampla e log de sete dias, nenhum dos dois calendários te ajuda neste trimestre.

Isso não é argumento contra regulação. É a constatação de que os relógios são diferentes: o regulatório conta em anos, o de incidente conta em semanas. Nos postmortems de falha de agente em produção que já examinei, a diferença entre um susto e uma crise quase nunca esteve em quão avançado era o modelo. Esteve em quanto tempo levou para alguém perceber, e quanto levou para desligar depois de perceber. As duas medidas dependem inteiramente do que o seu time controla, e de nada que se decida em Brasília ou em Washington.

---

Conclusão

O que fica de 4 de agosto, para mim, é menos sobre política pública e mais sobre uma assimetria que ficou visível. Existe uma camada da indústria com acesso a critérios de segurança que não podem ser lidos por quem opera embaixo, e é embaixo que os incidentes efetivamente acontecem — inclusive os que motivaram a reunião. Não estou dizendo que a classificação seja injustificada; há razões plausíveis para não publicar detalhes de teste de capacidade perigosa, e não tenho informação para julgar a escolha. Estou dizendo que o efeito colateral é real: o canal de difusão que fez padrões de segurança melhorarem a prática de todo mundo não vai funcionar aqui.

Assumo a incerteza sobre quase todo o resto. Não sei se o framework se consolida ou some no ciclo político seguinte. Não sei se o PL 2338 chega ao fim do processo com a estrutura que tem hoje. Não sei se, daqui a um ano, a conversa vai ser sobre esses instrumentos ou sobre um terceiro que ainda não existe, empurrado por um incidente maior. Regulação de tecnologia costuma ser escrita depois do acidente, e não tenho razão para achar que desta vez será diferente.

A parte de que tenho relativa convicção é a menos interessante de escrever e a mais fácil de adiar. Quaisquer que sejam as regras que apareçam, elas vão pedir que você mostre o que roda, com que permissão, e o que aconteceu. Isso vale no desenho americano, no brasileiro, no europeu e no questionário de fornecedor do seu maior cliente. Os seis registros deste post são, na melhor das hipóteses, meio trimestre de trabalho de uma pessoa sênior — não é o suficiente para chamar de programa de governança e eu não chamaria. Mas é a diferença entre responder o jurídico em vinte minutos e passar duas semanas reconstruindo o passado a partir de logs que talvez já tenham expirado. Na quinta-feira passada eu estava do lado errado dessa linha, e é por isso que passei o domingo escrevendo sobre ela.

Fontes:

• CNBC — White House to host AI companies Tuesday to review new model-testing framework
• CNN Business — White House to meet with OpenAI, Anthropic and other top AI companies in first big regulation push
• NBC News — White House meets with AI giants on rules after forcing models offline
• Bloomberg — OpenAI, Anthropic, Google to Join White House AI Safety Meeting
• Gottheimer — Statement on White House AI Framework