Quando a IA para de responder e começa a configurar
Deixar a IA ler os dados é uma decisão. Deixar ela criar um envio de conversão, mexer num público ou apagar um relatório é outra, muito maior — e ela precisa de quatro travas específicas.
A primeira fase da IA sobre dados de negócio é confortável: ela lê, cruza, responde. Se errar, o custo é uma resposta errada que alguém confere.
A segunda fase é onde o valor está e onde o medo mora: a IA cria o envio de conversão, ajusta o filtro, publica o relatório, apaga o que ficou órfão. Agora o erro não é uma frase — é uma configuração que produz efeito no mundo, em campanha que gasta dinheiro.
Essa passagem não deveria ser uma questão de coragem. São quatro travas, e elas são específicas.
1. Ensaio antes de valer
Toda ação que escreve precisa de um modo que faz tudo menos escrever: valida a entrada, monta o resultado, mostra o que ficaria — e não persiste nada.
Não é um detalhe de conveniência. É o que transforma "crie um envio de venda aprovada para o Meta" em algo revisável: você lê o filtro que ela montou, o mapeamento de campos e o código gerado, e só então autoriza.
O ensaio precisa ser garantido no servidor, não prometido no texto. Um modo de ensaio que depende do modelo se comportar não é um modo de ensaio.
2. Confirmar antes de destruir
Ação destrutiva merece tratamento próprio: a chamada sem confirmação explícita não apaga, ela devolve o que seria apagado. A segunda chamada, com a confirmação, executa.
O detalhe que importa é o que a primeira chamada devolve. Não basta dizer "vou apagar o relatório X": ela precisa dizer o que mais depende dele — quais consultas ficariam órfãs, quais são compartilhadas com outros relatórios e portanto não devem ser tocadas.
3. O escopo de escrita não pode ser uma promessa
É comum um conector declarar quais ferramentas são de leitura e quais escrevem. Declarar não é aplicar: se o servidor não recusa a escrita quando o token só tem leitura, a declaração é documentação.
Vimos isso na prática numa auditoria: as ferramentas mais novas verificavam o escopo, e as mais antigas, registradas por um caminho diferente, executavam sem verificar nada. Um token de leitura conseguia criar e apagar conjuntos de dados.
O conserto não foi listar as ferramentas antigas à mão. Foi derivar o escopo da anotação de cada ferramenta — lista escrita à mão envelhece em silêncio, e a próxima ferramenta nasce fora dela.
4. Prova sobre dado real antes de publicar
Esta é a que mais evita estrago, e é a mais específica de marketing. Quando a IA monta um filtro de conversão, o filtro pode estar sintaticamente perfeito e não casar com nada — ou casar com tudo.
A trava é rodar o filtro sobre os últimos eventos reais da conta antes de publicar, e devolver o resultado: destes trinta eventos, tantos passariam, tantos seriam descartados, e aqui estão exemplos de cada. Zero passando é aviso forte.
Sem isso, a primeira notícia de que o filtro estava errado chega dias depois, pelo relatório da plataforma de anúncio — e o que aconteceu no meio-tempo foi campanha aprendendo com sinal errado.
O que fica de fora, de propósito
Nem tudo deveria estar ao alcance. Alterar quem tem acesso, apagar dados de pessoas e mexer em cobrança são decisões de dono, e conveniência não é motivo suficiente para automatizá-las.
A régua que usamos é simples: se o erro não puder ser desfeito por quem autorizou, a ação não entra no cardápio da IA.
No CrazyLeads a criação de envio tem modo de ensaio garantido no servidor, a exclusão exige confirmação e devolve o que depende do item, o escopo de escrita é derivado da anotação de cada ferramenta, e o filtro é testado contra os eventos reais da conta antes de qualquer publicação.