O ponto mais importante para quem desenvolve com IA não é apenas quantos níveis de supervisão existem, mas quem define esses níveis e como eles viram controles técnicos. Segundo o Olhardigital.com.br, grandes empresas do setor assinaram um código voluntário de boas práticas proposto pelo governo dos Estados Unidos. O material de referência destaca compromissos com segurança, pesquisa e infraestrutura, mas não detalha quais seriam os quatro níveis de supervisão mencionados no título. Não vou atribuir ao acordo regras que a fonte não especifica.
Na prática, essa distinção importa. Um compromisso voluntário entre empresas não equivale a uma lei, a uma norma técnica nem a um mecanismo de segurança que você possa ativar com uma configuração. Para equipes de engenharia, a pergunta útil é outra: como transformar princípios amplos em decisões verificáveis no produto?
O que o acordo de IA dos Estados Unidos significa para desenvolvedores
O documento foi assinado por representantes de empresas como OpenAI, Anthropic, Google, Microsoft, Meta, Amazon e xAI, durante uma reunião com Donald Trump na Casa Branca. Conforme o conteúdo divulgado, as empresas se comprometem a continuar investindo em modelos e tecnologias de IA, com o objetivo declarado de preservar a liderança dos Estados Unidos no setor.
Há também um compromisso relacionado à infraestrutura. Modelos maiores e mais utilizados exigem capacidade computacional, data centers e energia. Isso afeta custos, disponibilidade dos serviços e, indiretamente, as escolhas que fazemos ao projetar aplicações dependentes de APIs de IA.
Mas um código voluntário não resolve sozinho questões como vazamento de dados, respostas incorretas, uso indevido de ferramentas ou indisponibilidade do provedor. A responsabilidade pelo comportamento de uma aplicação continua dependendo de decisões concretas: quais dados enviar, quais ações permitir e quando exigir aprovação humana.
Quatro níveis de supervisão: uma forma prática de desenhar controles
Como a referência não descreve os quatro níveis do acordo, a classificação abaixo é uma proposta operacional minha para projetos de software. Ela não é uma reprodução oficial do documento. O objetivo é ajudar a equipe a decidir quanto controle humano e técnico cada função de IA precisa.
Nível 1: assistência sem ação externa
A IA sugere, resume ou classifica informações, mas não altera dados nem executa ações em outros sistemas. Exemplos: explicar um trecho de código, resumir documentação ou gerar um rascunho que a pessoa copia manualmente.
Esse nível costuma ter menor impacto operacional, mas não é isento de risco. Uma resposta incorreta ainda pode levar alguém a tomar uma decisão ruim. Por isso, eu trataria a saída como conteúdo não confiável: ela pode ajudar, mas não deve ganhar privilégios automaticamente.
Nível 2: ação com confirmação humana
A IA prepara uma ação — por exemplo, abrir um pull request, enviar uma mensagem ou atualizar um cadastro — mas alguém precisa revisar e confirmar antes da execução. É uma boa escolha para automações úteis cujo erro teria custo perceptível, mas reversível.
A aprovação precisa mostrar o que será alterado. Um botão genérico de “confirmar” não ajuda se a pessoa não consegue inspecionar os destinatários, os campos modificados ou o conteúdo que será enviado.
Nível 3: autonomia limitada e auditável
A aplicação permite que a IA execute ações de baixo risco dentro de limites explícitos. Um assistente pode, por exemplo, categorizar tickets ou atualizar um campo não crítico, desde que registre o motivo, respeite limites e permita reversão.
Aqui, o controle não pode depender apenas de instruções no prompt. O modelo pode interpretar mal uma regra ou receber conteúdo malicioso em documentos e páginas. As permissões devem ser aplicadas pelo código da aplicação, fora do modelo.
Nível 4: bloqueio ou decisão humana especializada
Em ações de alto impacto — como movimentar dinheiro, conceder privilégios administrativos ou tomar decisões que afetem direitos de uma pessoa — o sistema deve bloquear a execução automática ou exigir uma revisão adequada ao contexto. Em certos casos, a escolha segura é não usar IA naquela etapa.
Essa gradação não é uma escala universal. O mesmo recurso pode exigir níveis diferentes conforme o usuário, o volume, a reversibilidade e as consequências do erro. A classificação deve avaliar a ação, não apenas o nome do modelo.
Na Prática: classifique a ação antes de chamar a ferramenta
Uma armadilha comum é deixar o modelo decidir se pode executar uma operação. Em vez disso, a aplicação deve verificar o risco e exigir aprovação antes de chamar ferramentas com efeitos externos. O exemplo abaixo mostra uma barreira simples em TypeScript para uma aplicação Node.js:
type RiskLevel = 1 | 2 | 3 | 4;
type Action = {
name: string;
risk: RiskLevel;
reversible: boolean;
};
type Decision = {
allowed: boolean;
requiresApproval: boolean;
reason: string;
};
function authorizeAction(action: Action): Decision {
if (action.risk === 4) {
return {
allowed: false,
requiresApproval: true,
reason: "Ação de alto impacto: bloqueada para execução automática."
};
}
if (action.risk === 3 && !action.reversible) {
return {
allowed: false,
requiresApproval: true,
reason: "Ação autônoma não reversível exige revisão humana."
};
}
if (action.risk === 2) {
return {
allowed: true,
requiresApproval: true,
reason: "Ação permitida somente após confirmação."
};
}
return {
allowed: true,
requiresApproval: false,
reason: "Ação de baixo impacto."
};
}
const action: Action = {
name: "enviar-email",
risk: 2,
reversible: false
};
const decision = authorizeAction(action);
if (!decision.allowed || decision.requiresApproval) {
console.log("Não executar automaticamente:", decision.reason);
} else {
console.log("Pode executar:", action.name);
}O exemplo é intencionalmente pequeno: uma regra desse tipo não substitui autenticação, autorização por usuário, validação de parâmetros ou trilhas de auditoria. Ela ilustra onde a decisão deve acontecer. O modelo pode sugerir uma ação; o backend decide se aquela ação é permitida.
- Liste as ferramentas disponíveis. Separe operações de leitura das que alteram sistemas ou enviam dados para fora.
- Avalie impacto e reversibilidade. Considere o pior resultado plausível, não apenas o caso ideal.
- Defina o controle fora do prompt. Use permissões, validações e limites no servidor.
- Registre as decisões. Guarde usuário, ação, parâmetros relevantes, resultado e aprovação, respeitando políticas de privacidade e retenção.
- Teste falhas e abuso. Simule entradas maliciosas, indisponibilidade do provedor e respostas estruturadas inválidas.
Erros comuns ao adicionar supervisão a sistemas de IA
- Tratar o código voluntário como obrigação legal. O acordo descrito pela fonte é voluntário. Não presuma que ele substitui leis, contratos, políticas internas ou requisitos aplicáveis ao seu produto.
- Confiar em “regras no prompt” como controle de acesso. Instruções ajudam a orientar o modelo, mas não garantem que uma ferramenta privilegiada será usada corretamente. A autorização deve ser implementada no software.
- Colocar tudo no mesmo nível de risco. Uma consulta de documentação e uma transferência financeira não devem compartilhar o mesmo fluxo de aprovação. Classifique cada capacidade e cada ação.
- Esquecer a reversão. Se uma automação pode editar ou apagar dados, planeje como desfazer a mudança. Sem isso, “autonomia limitada” vira uma aposta.
- Enviar dados sensíveis sem necessidade. O fato de uma API aceitar uma solicitação não significa que seja adequado enviar dados pessoais, segredos ou código privado. Minimize o conteúdo e revise contratos, retenção e configurações do fornecedor.
- Ignorar dependência de infraestrutura. O crescimento da demanda por computação e energia pode afetar preço, latência e disponibilidade. Tenha limites de custo, timeouts, tratamento de erros e uma alternativa para indisponibilidade.
Como os compromissos de infraestrutura afetam uma aplicação
A expansão de data centers e capacidade computacional pode sustentar modelos mais potentes e ampliar a oferta de serviços, mas não garante que toda API ficará mais barata ou disponível o tempo todo. Para quem mantém um produto, faz sentido evitar dependência rígida de um único fornecedor quando a função é crítica.
Uma camada de abstração pode facilitar a troca de provedor, desde que não esconda diferenças importantes. Modelos variam em latência, limites de contexto, formatos de saída, políticas de retenção e qualidade em tarefas específicas. Eu compararia fornecedores com avaliações próprias, usando dados representativos e métricas de custo, precisão e tempo de resposta.
Também é importante definir o comportamento quando a IA falha. Uma funcionalidade secundária pode exibir uma mensagem e tentar novamente; uma etapa de pagamento não deve repetir uma operação sem idempotência. O controle de infraestrutura começa com decisões de engenharia: timeout explícito, circuit breaker quando necessário e fila para tarefas que possam ser processadas depois.
O que eu cobraria de qualquer compromisso de segurança em IA
Um código de boas práticas pode estabelecer direção e pressionar o setor a investir em segurança. Para avaliar o resultado, porém, eu procuraria detalhes mensuráveis: quais riscos serão testados, como incidentes serão comunicados, quais informações serão auditáveis e como os compromissos serão verificados ao longo do tempo.
Para equipes de produto, a lição imediata é não esperar que acordos entre grandes empresas definam a arquitetura segura da nossa aplicação. O trabalho continua sendo mapear riscos, limitar permissões, informar usuários e criar mecanismos de revisão proporcionais ao impacto de cada ação.
FAQ sobre supervisão de IA em aplicações
O acordo citado criou oficialmente quatro níveis de supervisão?
O conteúdo de referência informa que o acordo é um código voluntário ligado a segurança, inovação e desenvolvimento, mas não apresenta a descrição dos quatro níveis. Por isso, os níveis explicados neste artigo são uma proposta prática, não uma classificação oficial atribuída ao documento.
Um acordo voluntário muda as obrigações de quem usa APIs de IA?
Não por si só. O acordo mencionado envolve compromissos das empresas signatárias. Quem integra uma API ainda precisa avaliar suas próprias obrigações legais e contratuais, além de proteger os dados e os usuários da aplicação.
Posso deixar um agente de IA executar ações sem aprovação?
Depende do impacto e da reversibilidade. Para tarefas restritas, de baixo risco e com registro, pode ser razoável permitir automação. Para operações sensíveis ou difíceis de desfazer, exija aprovação humana ou bloqueie a execução automática.
Como evitar que uma resposta errada vire uma ação real?
Não conecte diretamente texto gerado a operações privilegiadas. Valide parâmetros no backend, aplique autorização por usuário, limite as ferramentas disponíveis e peça confirmação quando a ação exigir supervisão.
O crescimento da infraestrutura de IA reduz o custo das APIs?
Não necessariamente. Mais capacidade pode ampliar a oferta, mas preços e disponibilidade dependem de vários fatores. Projete para variação de custo e latência, acompanhe o consumo e evite assumir que um serviço externo estará sempre disponível.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.