Governança de agentes de código: decisões antes da automação
Defina responsabilidades, limites e evidências para agentes que alteram software. A política precisa orientar o trabalho, não ficar separada dele.
Um agente pode ter capacidade para executar uma ação sem que essa ação faça parte de sua tarefa. Essa diferença é o ponto de partida da governança. O objetivo não é aprovar manualmente cada leitura de ficheiro, mas definir quais efeitos são permitidos, em qual ambiente e sob responsabilidade de quem.
O AI Risk Management Framework do NIST oferece uma referência voluntária de gestão de riscos. A OWASP descreve o risco de autonomia excessiva ligado a funções, permissões e liberdade de ação. Essas referências ajudam a formular perguntas; não certificam automaticamente a configuração de uma equipa.
Escreva o limite em termos de efeito
“Pode usar IA no projeto” é amplo demais para orientar uma integração. Especifique se o agente pode ler código, alterar uma cópia de trabalho, abrir uma proposta de mudança, publicar uma aplicação ou modificar dados. Essas ações têm consequências diferentes e não precisam partilhar a mesma autorização.
Também identifique o ambiente. Uma credencial de teste não deve apontar silenciosamente para produção. Use nomes compreensíveis, permissões compatíveis e uma forma de verificar o destino antes da ação. Uma pessoa responsável precisa conseguir responder qual sistema será afetado sem depender da interpretação do agente.
Transforme a política em ferramentas compatíveis
Se a tarefa é consultar o estado de uma entrega, uma ferramenta de consulta pode ser suficiente. Expor uma função administrativa genérica amplia desnecessariamente o que pode acontecer. Descreva entradas, efeitos e erros de forma que a ferramenta não precise adivinhar o significado de um identificador ou parâmetro.
Como exemplo hipotético, um agente investiga falhas de registo. Ele recebe logs reduzidos e acesso ao ambiente de validação. Alterar permissões de clientes ou apagar registros não pertence à investigação. Se uma correção exigir um desses efeitos, a tarefa deve apresentar a operação concreta e seu motivo antes de executá-la.
Defina quem responde pelo resultado
Cada automação precisa de uma pessoa responsável por avaliar mudanças de configuração, acompanhar falhas e decidir quando suspender o fluxo. Essa responsabilidade não desaparece porque uma ferramenta promete revisar a própria saída. O registro deve indicar quem recebe o problema e qual informação precisa estar disponível para investigá-lo.
Guarde identificador da tarefa, ambiente, ações relevantes, resultados e decisões de aprovação. Evite armazenar segredos nos logs. O objetivo do registro é reconstruir o ocorrido, não reunir indiscriminadamente todo o conteúdo acessível ao agente. Dados de observabilidade também precisam de propósito e acesso definido.
Ensaie a falha antes de ampliar o uso
Teste uma ferramenta indisponível, uma resposta ambígua, um limite atingido e uma mudança rejeitada na revisão. Observe se o agente interrompe a ação corretamente, conserva o trabalho já válido e comunica o que falta. Uma automação que funciona apenas no caminho ideal ainda deixa a operação sem resposta para incidentes previsíveis.
Depois de uma mudança de modelo ou conector, repita os casos relevantes. A diferença entre engenharia de prompts e de agentes explica por que instruções são apenas uma camada. O checklist de adoção empresarial organiza a passagem do ensaio para o uso recorrente. Governança útil aparece nas decisões que as pessoas e as ferramentas conseguem executar no dia a dia.
Sobre o autor
Tiago F SantiagoComentários
Ainda sem comentários
Partilhe uma dúvida ou experiência relacionada com o artigo.
Artigos relacionados
