IA no plantão: autonomia, confiança e quem responde quando o agente erra

Agentes de IA já executam ações em produção. A pergunta mais importante não é "ele consegue?", mas "o que acontece quando ele errar?".

Fala pessoal, tudo bem?

Hoje o post não tem passo a passo. É uma conversa sobre algo que está chegando rápido nos times de infraestrutura: agentes de IA que não só sugerem, mas executam.

Eles leem o alerta, consultam métricas, escrevem o patch, rodam o kubectl e fecham o incidente. Às vezes antes de alguém acordar. Parece o sonho de todo plantonista, e em parte é mesmo.

A ideia central do post: autonomia de um agente não é questão de capacidade. É questão de risco: quanto ele pode fazer sozinho, até onde vai o estrago se errar e quem responde depois.

Por que é diferente do autoscaler

Automação em produção não é novidade. Autoscaler, failover, pipeline de deploy. A diferença é que essas automações são determinísticas: mesma entrada, mesma ação.

Um agente de IA interpreta. Pode acertar um diagnóstico difícil e, no incidente seguinte, concluir com toda a convicção que o problema é o DNS quando era um certificado expirado. Essa flexibilidade é justamente o que o torna útil e imprevisível.

Autonomia é um dial, não um interruptor

Em vez de "deixa a IA mexer" contra "IA longe de produção", pense em níveis:

O erro mais comum é pular do nível 1 para o 4 porque a demonstração foi impressionante. Demonstração é o caminho feliz. Produção é o resto.

A pergunta certa: qual é o raio de impacto?

Um restart de pod errado custa segundos. Um terraform destroy no workspace errado custa um final de semana. Um DELETE sem WHERE custa uma carreira.

💡 Regra prática: dê autonomia ao agente só para ações que você desfaz com um único comando. Tudo que for irreversível passa por aprovação humana, sem exceção.

Exemplo: limitando o agente com RBAC

A mesma lógica de permissão mínima que usamos com pessoas vale para o agente. Ele ganha uma ServiceAccount própria, que só consegue reiniciar e escalar deployments em um namespace, e nada mais:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: agente-ia-nivel3
  namespace: app-pagamentos
rules:
  # pode ler o estado para diagnosticar
  - apiGroups: ["", "apps"]
    resources: ["pods", "pods/log", "deployments", "events"]
    verbs: ["get", "list", "watch"]
  # pode reiniciar (rollout restart) e escalar
  - apiGroups: ["apps"]
    resources: ["deployments", "deployments/scale"]
    verbs: ["patch"]
  # NÃO tem create/delete, secrets, nem acesso a outros namespaces
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: agente-ia-nivel3
  namespace: app-pagamentos
subjects:
  - kind: ServiceAccount
    name: agente-ia
    namespace: app-pagamentos
roleRef:
  kind: Role
  name: agente-ia-nivel3
  apiGroup: rbac.authorization.k8s.io

Para conferir o que ele pode ou não fazer:

$ kubectl auth can-i patch deployments -n app-pagamentos \
    --as=system:serviceaccount:app-pagamentos:agente-ia
yes

$ kubectl auth can-i delete pods -n app-pagamentos \
    --as=system:serviceaccount:app-pagamentos:agente-ia
no

Guardrails que valem para gente e para máquina

• Permissão mínima: identidade própria, nada de reaproveitar o kubeconfig de admin.
• Caminho oficial: se o time muda via PR e pipeline, o agente também.
• Ambientes separados: agente de homologação não tem credencial de produção.
• Auditoria: cada ação registra o quê, por quê e quem aprovou.
• Limite de velocidade: um humano errado apaga um recurso; um agente em loop apaga duzentos.
• Botão de parar: uma forma simples, conhecida por todos, de desligar o agente.

⚠️ Atenção: o agente lê logs, tickets e commits. Qualquer um desses textos pode conter instruções escritas por alguém mal-intencionado. Trate tudo o que ele lê como dado, nunca como ordem.

E quando der errado, quem responde?

Culpar "a IA" não ajuda ninguém. Ela não vai à reunião de postmortem. O agente é uma ferramenta; a responsabilidade é de quem definiu o que ela podia fazer. As perguntas do postmortem continuam as mesmas:

• Por que ele tinha permissão para isso?
• Por que essa ação não passou por aprovação?
• Por que ninguém percebeu que o raio de impacto era tão grande?

Nenhuma delas é sobre o modelo. Todas são sobre o sistema em volta dele.

Considerações Finais

Agentes de IA vão fazer parte da operação, assim como a pipeline e o autoscaler. Bem usados, tiram muito trabalho repetitivo e muita madrugada mal dormida do caminho.

Comece pelo nível mais baixo, meça e aumente a autonomia conforme o histórico justificar. No fim do dia, alguém precisa explicar por que aquela ação aconteceu em produção.

E esse alguém ainda é você.

Abs e até a próxima!!!

:wq!