Quando a IA passa a executar: o rótulo da ferramenta não diz o risco

A gente precisa parar de tratar "agentes de IA" como se fossem um único tipo de produto que se compra, nomeia e coloca num diagrama. Na maioria das empresas os agentes já estão rodando, e o rótulo da ferramenta quase não diz nada sobre o risco.

Este texto é para o CISO, o CIO e o CTO que ouvem a palavra "agente" em toda reunião de fornecedor e querem uma definição que resista ao problema real: uma IA que deixou de apenas responder e passou a agir.

O rótulo não diz o risco

Um desenvolvedor dentro de um editor de código já pode estar usando um agente. Um analista num app de chat que aprendeu a executar tarefas de vários passos também. Um agente pode ser um processo que acorda toda manhã, faz o trabalho e encerra. Pode ser uma carga rodando quieta no seu cluster Kubernetes.

Nenhum desses rótulos, editor, linha de comando, janela de chat, contêiner, diz quanta liberdade a IA tem nem o que ela alcança. Um editor é uma interface. Uma linha de comando é uma interface. Kubernetes é um lugar para publicar software. A pergunta que importa de verdade é mais simples e mais incômoda:

O sistema está escolhendo os próprios passos e executando-os rumo a um objetivo, ou está apenas respondendo?

Mesma janela, mesmo nome de produto. Uma ajuda a pessoa a pensar. A outra executa trabalho nos seus sistemas. Essa distância, não a interface, é onde a governança começa.

Vale ser preciso em mais um ponto. O modelo de IA não é o agente inteiro. Em volta dele há software, muitas vezes chamado de runtime ou harness, que conecta o modelo às ferramentas, gerencia a sessão e aplica as permissões que existirem. Trocar o modelo não é a mesma coisa que mudar o que esse runtime tem permissão de fazer. E o modo visível de um produto não é um jeito confiável de identificar toda execução: os fornecedores já estão juntando as experiências de chat e de "trabalho" numa superfície só.

Uma corrida curta pode deixar consequências duradouras

A maior fonte de confusão é tratar "autônomo" e "de longa duração" como a mesma coisa. São eixos diferentes. Autonomia é o quanto o sistema faz sem uma pessoa no meio. Duração da sessão é quanto tempo uma corrida específica leva. Um desenvolvedor pode passar uma tarefa a um agente e deixá-lo trabalhar sozinho por dez minutos: é uma corrida curta com autonomia real.

E corrida curta não é corrida segura. Nesses minutos o agente pode mudar arquivos, publicar código, chamar uma API externa ou abrir uma conexão. Quando a corrida termina, esses efeitos não se desfazem sozinhos.

Há uma armadilha mais sutil com agentes que delegam. Um agente pode passar partes da tarefa a subtrabalhadores que fazem o trabalho no próprio contexto e devolvem um resumo curto. O "pronto" final do agente é um resumo, não o relato completo de tudo que foi executado por baixo. Para uma equipe de segurança, "o agente disse que terminou" e "conseguimos mostrar o que ele de fato fez" não são a mesma frase.

Observar não é a mesma coisa que controlar

Essa é a distinção que quase toda conversa sobre governança de IA embaralha, e a que mais importa para um líder de segurança.

Observabilidade ajuda a detectar, investigar e atribuir o que aconteceu. Enforcement pode impedir ou restringir uma ação antes de ela acontecer. Registrar uma chamada de ferramenta depois que ela rodou ajuda a investigar. Não a desfaz. Um evento coletado depois do fato não é um controle.

Os dois são necessários e não são intercambiáveis. Um jeito útil de olhar o seu parque é separar cada superfície de IA pelo que dá para fazer com ela de verdade. Algumas você só consegue observar: um app de desktop que emite telemetria deixa você ver a atividade, mas não há um ponto em que você possa entrar e barrar uma ação. Outras ficam no caminho do trabalho, onde uma camada de controle pode avaliar a próxima ação do agente e negá-la antes de a ferramenta rodar, não depois.

Um control plane para agentes é a camada que torna essa diferença explícita: observa onde só dá para observar, bloqueia onde dá para bloquear e mantém o registro dos dois. O que ele nunca deve fazer é vender coleta pós-fato como prevenção.

Governe o trabalho, não a ferramenta

Se o rótulo da ferramenta é a unidade errada de governança, qual é a certa? O próprio trabalho. Para qualquer corrida de agente que importe, uma equipe de segurança deveria conseguir responder a uma lista curta de perguntas:

São requisitos práticos de evidência, não um pedido para ler a mente do modelo. E a evidência precisa viver em algum lugar durável e central, alimentando o seu SIEM junto do resto da sua telemetria de segurança, e não num histórico local na máquina de um desenvolvedor nem no resumo que o agente faz de si mesmo. Um registro que só sobrevive dentro da ferramenta que o produziu não é uma trilha de auditoria.

Nada disso exige que o agente tenha "ficado rebelde" em algum sentido dramático. A maior parte do risco é mais banal: uma injeção de prompt vinda de conteúdo não confiável tentando redirecionar o agente, ou um agente perfeitamente comportado operando dentro de permissões amplas demais. As perguntas certas de risco são sobre dados alcançáveis, permissões concedidas, exposição a conteúdo não confiável e onde fica o limite de enforcement, não sobre quanto tempo a sessão durou.

O ponto

O objetivo não é rotular toda interação de IA como "agente". É reconhecer o momento em que a IA passa de ajudar alguém a pensar para executar trabalho, e aplicar o controle certo nesse momento: observar onde só dá para observar, bloquear onde dá para bloquear e manter a evidência viva além da corrida.

Na KonaSense, é assim que a gente acredita que a governança de agentes deve funcionar: ela deve seguir o trabalho, não a marca na janela. A corrida do agente pode ser temporária. As consequências não são.