A maioria dos programas de governança de IA que vi começa criando um fórum. Reúne-se quinzenalmente, produz ata, aprova casos de uso. Seis meses depois, existe um repositório de decisões e nenhum controle rodando.
Por que o comitê sozinho falha
Não é falta de competência das pessoas. É descompasso de velocidade. O comitê decide a cada duas semanas; o agente age em milissegundos, milhares de vezes por dia. Qualquer controle cuja aplicação dependa de um humano no caminho vai ser contornado por volume, não por má-fé.
Some a isso que aprovação de caso de uso governa o que foi declarado. Shadow AI — o servidor MCP que subiu no notebook, a integração que alguém plugou — não passa por comitê nenhum, e é onde está a maior parte do risco.
Governança que só existe em reunião governa slides. Não governa o que está rodando.
A tradução de política para controle
Para cada linha da política, pergunte qual mecanismo a torna verdadeira sem ninguém presente:
- “Agentes devem ter identidade própria” → verificação no pipeline que barra deploy com service account compartilhada.
- “Credenciais não devem ser estáticas” → scanner que falha o build ao encontrar chave em variável de ambiente.
- “Ações irreversíveis exigem humano” → regra no gateway, não frase no prompt.
- “Toda chamada de ferramenta deve ser auditada” → ausência de log vira alerta de saúde, não item de checklist.
- “Servidores de terceiros precisam de aprovação” → allowlist aplicada em runtime, e o que não está nela não conecta.
O que não tem tradução para mecanismo deveria sair da política ou ser assumido explicitamente como risco aceito, com dono e data.
O papel que sobra para o comitê
Sobra o que só humano faz: decidir os limites, arbitrar exceções e assumir risco residual com nome e assinatura. Isso é valioso, e cabe numa reunião mensal curta — desde que a aplicação do dia a dia esteja em código.
