Nas últimas semanas, parece que todo mundo descobriu a palavra “autônomo”.
De repente, não basta um chatbot responder perguntas. Ele precisa fazer coisas: abrir seu e-mail, mexer em planilhas, agendar reuniões, rodar comandos no seu computador. E, claro, prometer milagres.
Esse tipo de ferramenta é sedutor porque resolve um problema real: trabalho demais, tempo de menos. A parte perigosa é que, para “fazer coisas”, ela precisa de algo que a maioria dos softwares nunca deveria ter por padrão: mãos e chaves.
O exemplo perfeito é o ClawBot — que virou MoltBot e depois foi rebatizado de OpenClaw, numa sequência de renomes bem típica de projetos virais. Anthropic pediu a mudança por questão de marca, e o rebrand virou um pequeno caos público, com direito a tentativas de golpe e impersonação.
Mas o nome é a parte menos importante.
O que importa é a ideia: um agente auto-hospedado que você controla por apps como WhatsApp e Telegram, capaz de executar ações no seu ambiente local.
Se você é uma pessoa técnica, isso soa como “legal, dá pra automatizar meu dia”.
Se você é uma empresa, isso deveria soar como: “alguém colocou um estagiário invisível dentro do notebook, e ele aceita instruções por mensagem”.
Porque é isso que um agente é, na prática. Um operador. E operadores cometem erros.
A diferença é que, quando um humano comete um erro, normalmente ele precisa passar por atritos: pedir acesso, abrir um sistema, enfrentar um alerta, ter vergonha de fazer algo absurdo. Um agente, não. Ele só obedece a próxima frase que parecer convincente.
E aí entra a pior parte: a frase convincente pode vir do lugar errado.
Essa é a essência de prompt injection. Você não precisa “hackear” o computador. Basta hackear a conversa. Uma mensagem, um e-mail, um arquivo, um link — qualquer coisa que o agente leia — pode conter instruções escondidas no meio do texto: “ignore as regras”, “envie esse arquivo”, “cole essas credenciais”, “execute esse comando”.
Quando isso acontece com um chatbot comum, o estrago costuma ser limitado ao que ele responde.
Quando isso acontece com um agente com ferramentas, o estrago muda de categoria. O modelo não precisa “vazar dados” pela boca. Ele pode vazar dados pela mão: anexando, copiando, subindo, integrando, sincronizando. É por isso que OWASP tem enfatizado riscos de agentes: abuso de ferramentas, escalada de privilégios e exfiltração por chamadas de tool/use.
Agora some isso a dois hábitos corporativos bem comuns:
1. credenciais espalhadas (tokens em arquivos, variáveis, notas, histórico de terminal), e
2. painéis expostos “só por um tempo” (aquele container que alguém publicou para testar, aquela porta liberada para “facilitar”).
Ferramentas autônomas transformam esses hábitos em combustível.
E tem um efeito colateral ainda mais silencioso: a criação de Shadow AI.
Quando um agente roda “localmente” e “em nome da privacidade”, ele dá ao usuário uma sensação de segurança. “Está no meu hardware, então está tudo bem.” Só que, no mundo corporativo, “no meu hardware” muitas vezes significa: fora do perímetro, fora do inventário, fora do logging, fora do SOC, fora de qualquer trilha de auditoria.
É assim que nascem instâncias paralelas: alguém instala, integra e concede acesso ao e-mail e ao drive, e ninguém mais sabe. Quando dá problema, o problema já virou incidente. E o mais desconfortável é que já existe bastante conversa pública citando vazamentos e impactos atribuídos ao uso não sancionado de IA.
Repare que eu nem precisei discutir se o agente é open-source ou fechado. Esse debate distrai.
Open-source pode ser ótimo. Mas, em empresas, o problema raramente é “código malicioso”. O problema é “código poderoso demais” rodando num lugar sem regras suficientes.
O que nos leva ao ponto central:
o produto real que falta no mercado não é mais um agente. É governança.
Governança parece chata porque não faz demo bonita. Ela não “agenda uma reunião sozinha”. Ela impede que alguém agende a reunião errada, com o convite errado, anexando o arquivo errado, para a pessoa errada.
E governança, quando é boa, tem algumas características bem específicas:
* deixa claro o que é permitido e o que é proibido, sem ambiguidade;
* reduz privilégios por padrão (read-only onde der, escopo mínimo sempre);
* centraliza logs e rastreabilidade (quem fez, quando fez, com qual contexto);
* trata prompt injection como ataque real, não como curiosidade acadêmica;
* exige checagem humana para ações que são irreversíveis ou sensíveis.
Se você olhar para agentes como o OpenClaw, o caminho seguro não é “proibir porque dá medo”. É fazer o oposto do impulso comum: parar de improvisar.
Em vez de cada pessoa ter seu “bot particular” com acesso ao que quiser, você quer um lugar único onde a empresa diz: “use IA aqui, com estas regras, com estes limites, com estas trilhas”.
É exatamente aí que uma plataforma como a Cortex, da SinapseTech, faz sentido na prática: não como “mais IA”, mas como o jeito de transformar IA em infraestrutura corporativa — auditável, supervisionada e alinhada a compliance e risco. (E isso fica ainda mais forte quando acoplado à GRCTech, porque governança não vive só no discurso; ela precisa virar processo e evidência.)
O boom atual vai passar. Sempre passa.
O que fica é o padrão que se instala depois do boom. E o padrão pode ser “cada um por si”, com agentes rodando em laptops e credenciais em texto plano, ou pode ser “IA como capability corporativa”, com políticas, controles e monitoramento.
A escolha real não é entre “usar agentes” e “não usar agentes”.
É entre “automatizar com controle” e “automatizar no escuro”.
E a parte irônica é que, quando você faz do jeito certo, a empresa não fica mais lenta. Ela fica mais rápida — porque para de ter que apagar incêndios causados por automação ingênua.
Milagres são sempre tentadores.
Mas, em empresas, o que escala não é o milagre.
O que escala é o método.
