Identificar responsabilidades, riscos, anti-padrões e necessidades de rastreabilidade
À medida que os agentes se tornam mais capazes, pode ser tentador imaginar que as responsabilidades passam para o sistema. Não tem. Os sistemas agentivos podem executar o trabalho, mas os humanos continuam responsáveis pelos resultados e pelos controlos que regem a execução.
Nesta unidade, vais aprender
Quem é responsável pelas ações e resultados dos agentes
Quais riscos comuns e anti-padrões aparecem nos sistemas de agentes
Como os controlos do GitHub mitigam estes riscos
Porque é que a rastreabilidade e a observabilidade são necessárias para sistemas fiáveis
A responsabilidade não se altera com a execução
Quando um agente cria um pull request, revê código ou responde a feedback, participa no fluxo de trabalho, mas não assume a propriedade dos resultados. As partes responsáveis continuam a ser as pessoas e equipas que:
Definiu a tarefa
Definir permissões
Escolha e configure os controlos
Aprovada a alteração resultante
Um modelo de revisão por pull request torna isto explícito: o sistema pode propor, mas os humanos decidem o que é aceite.
Riscos comuns e anti-padrões
Os sistemas de agentes em estágio inicial falham frequentemente de formas previsíveis:
Execução sem plano O agente começa a alterar código sem uma abordagem clara e inspecionável.
Agentes com excesso de permissões O agente (ou o seu token de workflow/credenciais de ferramentas) tem acesso mais amplo do que o necessário.
Raciocínio oculto O fluxo de trabalho expõe apenas as saídas (o diferencial) sem artefactos intermédios (plano, pressupostos, pontos de decisão, contexto de execução).
Confiança cega na automação: Passar no CI é importante, mas as verificações só validam o que foram projetadas para detetar. Uma build bem-sucedida não implica automaticamente que a alteração está completa, é apropriada ou de baixo risco.
Mapeamento de implementação: mitigação de riscos → GitHub
| Risco / anti-padrão | Como fica em GitHub | Mitigação usando controlos GitHub |
|---|---|---|
| Execução sem plano | PR tem um diferencial, mas não tem plano ou justificação | Exigir uma secção de plano via modelo de RP; Exige revisão antes da fusão |
| Agentes excessivamente autorizados | Os fluxos de trabalho podem escrever no repositório e aceder a segredos de forma ampla | Privilégio mínimo GITHUB_TOKEN; ambientes com revisores obrigatórios; Restringir quem pode desencadear fluxos de trabalho |
| Raciocínio oculto | Sem suposições/âmbito/rastro de decisões | Exigir o planeamento e a ligação de execuções de fluxo de trabalho e registar decisões nos comentários de pedidos de pull |
| Confiança cega na automação | Mentalidade de "CI aprovado, envia" | Combinar verificações com CODEOWNERS, revisões obrigatórias e aprovações baseadas no risco |
Rastreabilidade e observabilidade
Para supervisionar bem um agente, precisas de mais do que uma diferença final — precisas de um rasto. No GitHub, esse rasto pode incluir:
Pull requests e histórico de commits
Revise comentários e aprovações
Execuções de workflows e artefactos carregados (relatórios de teste, registos)
Envios e alertas de digitalização de código
Alertas secretos de varredura e eventos de proteção contra o empurrão
Eventos de registo de auditoria da organização (disponibilidade e acesso dependem da configuração da organização/empresa)
O objetivo não é apenas a conformidade. É uma compreensão operacional: quando algo falha, é preciso saber o que mudou, quem o aprovou, que provas existiam e o que aconteceu a seguir.
Registo mínimo de auditoria para contribuições de agentes
Um objetivo declarado (link da edição ou descrição do PR)
Um plano inspecionável (seção ou arquivo do plano de relações públicas)
Um conjunto de mudanças limitado (branch e commits)
Evidência automatizada (execução do fluxo de trabalho e artefactos)
Julgamento humano (revisão e aprovação)
Um resultado claro (fusão, reverter ou escalar)
Suponha que a correção da vulnerabilidade do agente passe pelo CI mas depois cause um retrocesso. A questão chave não é apenas se o agente cometeu um erro – é se o sistema tornou o erro compreensível e evitável:
Havia um plano e escopo visíveis?
Foram os revisores certos solicitados (e eles aprovaram)?
As verificações estavam em conformidade com o risco da alteração?
O registo de auditoria é suficiente para reconstruir o que aconteceu?
Os sistemas agentes mudam quem realiza o trabalho, mas não quem detém os resultados. As equipas humanas mantêm-se responsáveis, razão pela qual devem desenhar contra anti-padrões comuns e exigir uma forte rastreabilidade através de artefactos e registos nativos do GitHub.
Depois de perceber como funciona a responsabilidade, o passo final é decidir como o trabalho de agente deve ser avaliado. Na unidade seguinte, irá aplicar o modelo do contribuinte à saída gerada por agentes.