IA explicada para quem trabalha: ferramentas testadas, custos reais, sem hype.

Agente de IA na empresa: o que autorizar antes e o que registrar depois

Agente de IA na empresa: o que autorizar antes e o que registrar depois

Um agente de IA que só responde perguntas erra em palavras. Um agente que age — atualiza o CRM, envia uma cobrança, remarca uma consulta — erra no seu sistema. Este guia mostra o que deixar decidido antes de liberar o agente e o que registrar depois de cada ação, sem depender de nenhuma ferramenta específica.

No artigo "A IA respondeu certo, mas cadastrou o cliente errado", a autora convidada Sophie Ale mostrou cinco testes para fazer antes de conectar um agente ao CRM. Este texto continua a partir dali: os testes passaram, e agora? Falta responder duas perguntas que muitas PMEs pulam: o que exatamente o agente está autorizado a fazer e como saber, depois, o que ele fez.

Pense num exemplo ilustrativo: uma clínica coloca um agente no WhatsApp para confirmar consultas. Em uma semana, ele também começa a remarcar horários, porque um paciente pediu e ninguém disse que não podia. Uma remarcação cai em cima de outra. Quando a recepção percebe, ninguém sabe dizer quem pediu, o que o agente mudou nem quando.

Por que escrever no prompt não basta

A primeira reação costuma ser colocar as regras no prompt: "não remarque consultas", "não dê descontos". Ajuda, mas não garante. O modelo pode interpretar mal um pedido ambíguo, e um cliente pode, de propósito ou não, escrever algo que o convença do contrário.

A OWASP, organização de referência em segurança de software, chama esse risco de autonomia excessiva e aponta três causas: o agente tem funções de que não precisa, permissões maiores que o necessário nos sistemas que acessa, ou autonomia para executar ações de alto impacto sem verificação independente. Entre as recomendações está a de aplicar a autorização nos próprios sistemas, e não depender do modelo para decidir se uma ação é permitida.

⚠️
Regra prática: o prompt diz ao agente o que você espera dele. As permissões do sistema dizem o que ele consegue fazer. Se uma ação não pode acontecer de jeito nenhum, ela precisa estar bloqueada no sistema, não só proibida no texto.

Antes: a ficha de autorização

Antes de ligar o agente, escreva uma ficha curta para cada tarefa que ele vai executar. Ela tem cinco campos, e cada um precisa caber em poucas linhas — se não cabe, a tarefa ainda não está clara o bastante para ser automatizada.

  1. O que ele pode fazer sozinho: ações de baixo risco e fáceis de desfazer.
  2. O que precisa de aprovação, e de quem: o nome do cargo, não "alguém da equipe".
  3. O que ele nunca faz: e onde isso está bloqueado no sistema.
  4. Quando ele para e chama um humano: dúvida de identidade, reclamação, valor acima de um limite, segunda tentativa que falhou.
  5. Como conferir a entrega: quem verifica, quando e olhando o quê.

Exemplo de ficha para o agente da clínica (fictícia):

CampoAgente de confirmação de consultas
Pode sozinhoEnviar lembrete; registrar "confirmado" ou "não respondeu" no agendamento.
Precisa de aprovaçãoRemarcar ou cancelar consulta: aprovação da recepção, no painel, antes de gravar.
Nunca fazAlterar dados cadastrais, falar de valores ou de diagnóstico. A integração não tem permissão de escrita no cadastro.
Para e chama humanoPaciente pede remarcação, reclama, ou o número não bate com o cadastro.
ConferênciaRecepção revisa às 18h a lista do dia: confirmações, pendências e transferências.

Onde cada regra precisa morar

Cada linha da ficha vira uma configuração em algum lugar. Quanto maior o risco da ação, mais longe do prompt a regra precisa estar.

Tipo de regraOnde colocarExemplo
Tom, formato, assuntosPrompt"Responda em uma mensagem, sem emojis."
O que o agente consegue tocarPermissões da integração (chave de API, usuário do CRM, escopo de acesso)Usuário do agente só lê o cadastro e só escreve no campo "status da consulta".
Ações que pedem aprovaçãoFluxo da automação (Make, n8n, CRM)Remarcação vira tarefa pendente; só grava depois do clique de aprovação.
Limites numéricosValidação no sistema, antes de gravarDesconto acima de 0% bloqueado; envio para mais de 50 contatos bloqueado.
Parada e transferênciaPrompt e fluxoPalavra "reclamação" ou falha repetida abre atendimento humano.
💡
Atalho para PMEs: crie um usuário separado para o agente no CRM e nas outras ferramentas, com as permissões mínimas. Assim fica claro no histórico o que foi feito pelo agente, e você corta o acesso de uma vez se algo der errado.

Depois: os quatro registros

Autorizar não basta se, depois, ninguém consegue reconstruir o que aconteceu. Para cada ação com efeito real, guarde quatro registros separados:

RegistroO que guardarResponde à pergunta
1. PropostaO que o agente pretendia fazer, em qual registro, e o motivo (a mensagem que originou o pedido)."O que ele ia fazer?"
2. AprovaçãoQuem aprovou, quando e com qual escopo — ou a regra que dispensava aprovação."Quem deixou?"
3. ExecuçãoO que de fato foi gravado ou enviado, com data e hora, e o identificador do registro alterado."O que mudou de verdade?"
4. ConferênciaQuem verificou depois, o que encontrou e se precisou corrigir."Deu certo?"

Os quatro precisam ser separados porque costumam divergir: o agente propõe uma coisa, a pessoa aprova outra parecida, a integração grava uma terceira por causa de um campo mal mapeado. Se tudo estiver misturado no histórico da conversa, você não descobre em qual etapa o erro nasceu.

Esses registros também ajudam com a LGPD. A lei pede que quem trata dados pessoais mantenha registro das operações de tratamento (art. 37) e adote medidas de segurança contra alteração ou tratamento inadequado (art. 46). E quando uma decisão automatizada afeta o cliente, ele pode pedir revisão (art. 20) — o que é difícil de atender sem saber o que o sistema decidiu.

⚖️
Registro não é cópia de tudo: guarde o necessário para reconstruir a ação — identificadores, campos alterados, quem aprovou — e não a conversa inteira com dados pessoais em uma planilha aberta. Defina por quanto tempo os registros ficam guardados e quem pode acessá-los.

Checklist antes de liberar o agente

Rode estes itens em ambiente de teste, com dados inventados, como nos cinco testes da Sophie. Cada um tem resultado claro: passou ou não passou.

  1. Cada tarefa do agente tem uma ficha de autorização com os cinco campos preenchidos.
  2. O agente usa um usuário próprio, com permissões mínimas, em cada sistema.
  3. Peça ao agente uma ação proibida, com insistência: o sistema bloqueia mesmo que ele tente.
  4. Peça uma ação que exige aprovação: nada é gravado antes da aprovação.
  5. Aprove uma ação e confira: o registro de execução bate com o que foi aprovado.
  6. Provoque uma situação de parada (reclamação, dúvida de identidade): o caso chega a uma pessoa e o agente para de agir nele.
  7. Escolha uma ação ao acaso e reconstrua os quatro registros em menos de cinco minutos.
  8. Corte o acesso do usuário do agente: tudo para, e nada fica pela metade sem aviso.
🔎
E as ferramentas? Já existem produtos que ajudam a escrever regras de delegação ou a registrar aprovações de agentes. Não testamos nenhum deles para este guia, então não recomendamos marcas. Para começar, o histórico do seu CRM, uma fila de aprovação no Make ou no n8n e uma planilha de conferência já cobrem os quatro registros.

🖊️ Na nossa avaliação

A pergunta que mais importa antes de colocar um agente para agir não é "qual modelo usar", e sim "o que acontece quando ele erra". Se a resposta for "não sei o que ele fez" ou "ele tinha permissão para tudo", o agente ainda não está pronto — por melhor que converse.

A boa notícia é que nada disso exige software caro: uma ficha por tarefa, um usuário com permissão mínima e quatro registros por ação já colocam uma PME à frente de muita empresa grande.

📩 Receba análises como esta toda semana no seu e-mail Assine o Algoritmo Diário — gratuito, sem spam

📚 Fontes e referências

Compartilhe este artigo:

Ficou com alguma dúvida?

Conte o que você quer resolver com IA e eu respondo por e-mail. Boas perguntas costumam virar a próxima pauta. Fale comigo →