Ao final deste artigo você vai saber como deixar um agente de IA consultar e acionar a sua operação sem que ele tenha acesso ao banco de dados da empresa.
Para acompanhar, você precisa saber quais sistemas guardam a informação que o agente vai usar. Não precisa saber programar. As decisões que importam aqui são de negócio, não de código.
Esse é o trabalho que separa empresa que publica um agente em semanas de empresa que descobre, no meio do projeto, que não tem como perguntar nada ao próprio sistema.
Por que não dar acesso direto ao banco de dados?
Porque banco de dados não tem noção de limite. Ele responde o que for perguntado, inteiro.
Um agente com acesso direto consegue ler a tabela de clientes toda, inclusive as colunas que ninguém pretendia expor. E consegue escrever, o que significa que um erro de interpretação vira alteração de dado real.
A alternativa não é confiar mais no modelo. É reduzir o que ele pode pedir. Em vez de acesso, o agente recebe um conjunto pequeno de ações prontas, cada uma com entrada, saída e limite definidos.
Foi assim que a Gol colocou check-in dentro do ChatGPT sem entregar senha de passageiro, como contamos no artigo sobre o check-in pelo ChatGPT. O assistente conduz a conversa, a empresa continua dona da fechadura.
O método em seis passos
No desenho, repare que escrita só aparece no terceiro passo. Começar por leitura é o que torna o projeto reversível.
- Liste as ações que o agente precisa, sempre em verbo.
- Separe o que é leitura do que é escrita.
- Escreva o contrato de cada ação, com entrada e saída.
- Defina o limite de cada uma, inclusive quem aprova.
- Registre toda chamada, com quem pediu e o que voltou.
- Teste o caso que deve ser negado, não só o que deve funcionar.
Passo 1, listar as ações em verbo
Escreva o que o agente precisa fazer usando verbos. Consultar status do pedido. Verificar disponibilidade de agenda. Abrir chamado. Remarcar entrega.
Essa lista costuma ser curta. Um agente de atendimento bem desenhado opera com cinco ou seis ações. Lista grande no começo é sinal de que ninguém decidiu ainda para que serve o agente.
O que não entra na lista é tudo que o agente não precisa. Essa é a parte que dá trabalho, porque a tentação é liberar mais por garantia.
Passo 2, separar leitura de escrita
Leitura responde perguntas. Escrita muda o estado da operação.
São riscos de natureza diferente. Leitura errada entrega informação indevida. Escrita errada altera dado real, e isso aparece no cliente.
Comece publicando só as de leitura. O agente que apenas consulta já resolve a maior parte do atendimento repetitivo, e o projeto inteiro continua reversível. Escrita entra depois, uma ação por vez.
Passo 3, escrever o contrato de cada ação
Para cada ação, defina três coisas em uma linha cada.
- Entrada. O que precisa ser informado para a ação rodar.
- Saída. Exatamente quais campos voltam, e nenhum a mais.
- Quem pode chamar. Qual agente, em qual canal, para qual tipo de usuário.
A saída é onde quase todo vazamento nasce. Devolver o registro inteiro do cliente porque era mais fácil que escolher campos é o erro mais comum e o mais caro.
Esse formato de contrato já existe como padrão de mercado, e tratamos dele no artigo sobre o padrão de integração que conecta IA a sistema.
Como saber se a lista de ações está boa
Existe um teste rápido. Pegue as dez perguntas que mais chegam no seu atendimento e tente responder cada uma usando só as ações da lista.
Se sobrarem perguntas sem resposta, falta ação. Se sobrarem ações que nenhuma das dez perguntas usa, essa ação está ali por garantia, e garantia é o nome bonito de permissão desnecessária.
Esse exercício costuma reduzir a lista pela metade. É um bom sinal. Agente com menos ações é mais previsível, mais fácil de testar e mais barato de manter.
Vale também olhar a lista pensando em quem usa o sistema hoje. Se uma ação só faz sentido para um perfil de usuário, isso precisa estar escrito no contrato dela, e não resolvido com uma instrução no prompt.
Passo 4, definir o limite e quem aprova
Toda ação de escrita precisa de uma linha dizendo até onde ela vai sozinha.
Remarcar entrega para a semana seguinte pode ser automático. Cancelar contrato não. Conceder desconto até certo valor pode. Acima disso, vai para uma pessoa.
Escreva esses limites antes de o agente ir ao ar, não depois do primeiro incidente. Política escrita depois do problema protege quem escreveu, não quem opera.
Passo 5, registrar toda chamada
Cada chamada precisa deixar rastro. Quem pediu, qual ação, com quais dados, o que voltou e quando.
Sem isso, qualquer investigação futura vira reconstrução de memória. Com isso, você consegue responder em minutos o que o sistema fez e por quê.
Esse registro também alimenta o inventário de sistemas, que é o que torna governança possível, como descrevemos em como montar um inventário de sistemas de IA.
Passo 6, testar o caso que deve ser negado
Quase todo teste de agente verifica se ele acerta. Poucos verificam se ele recusa.
Monte três pedidos que o agente deve negar e rode todos antes de publicar. Peça um dado de outro cliente. Peça uma alteração acima do limite. Peça algo que não está na lista de ações.
Se o agente responder qualquer um desses com algo útil, o problema está no contrato, não no modelo.
Se depois desse desenho você quiser ajuda para construir a camada, a página de tecnologia e automação mostra como entramos nessa etapa.
Um exemplo com números
O exemplo abaixo é ilustrativo e serve para mostrar o formato, não para servir de referência de prazo.
Uma empresa de serviço quis colocar um agente para responder status de pedido no WhatsApp. A lista final ficou em quatro ações.
| Ação | Tipo | Decide sozinho |
|---|---|---|
| Consultar status do pedido | leitura | sim |
| Consultar prazo de entrega | leitura | sim |
| Abrir chamado de atraso | escrita | sim |
| Remarcar data de entrega | escrita | não, aprova o operador |
As duas de leitura foram ao ar primeiro e resolveram boa parte do volume. As de escrita entraram quinze dias depois, uma por vez, com registro completo desde o primeiro dia.
Por que o limite não deve morar no prompt
Essa é a confusão mais frequente e a que custa mais caro.
Instrução no prompt é pedido, não impedimento. Ela orienta o comportamento do modelo e funciona na maior parte das vezes. Maior parte das vezes não é critério aceitável quando se trata de dado de cliente.
O limite precisa estar na camada que executa a ação, não no texto que orienta o modelo. Se a função não aceita desconto acima de 15%, não existe frase capaz de convencê-la a aceitar.
A regra prática que usamos é simples. Prompt define tom, escopo de conversa e quando transferir para uma pessoa. Contrato define o que é tecnicamente possível. Misturar os dois é como trancar a porta com um bilhete pedindo para não entrar.
O desenho do prompt continua importando, e tratamos dele em como escrever o prompt de um agente de atendimento. Ele só não é o lugar da permissão.
Erros comuns
- Dar acesso de leitura ao banco inteiro. Parece inofensivo e expõe colunas que ninguém revisou.
- Devolver o registro completo. Escolher campos dá trabalho uma vez. Vazar dado dá trabalho para sempre.
- Publicar leitura e escrita juntas. Tira a reversibilidade do projeto logo no começo.
- Deixar o limite na cabeça de alguém. Limite não escrito não existe quando a pessoa está de férias.
- Testar só o caminho feliz. O que machuca é o pedido que deveria ter sido negado.
- Esquecer o registro. Sem rastro, nenhum incidente é investigável depois.
Perguntas frequentes
Preciso trocar meus sistemas para fazer isso?
Quase nunca. A camada de ações fica por cima do que já existe. Sistema antigo costuma ser suficiente desde que permita consulta programada de alguma forma.
Isso vale para empresa pequena?
Vale, e costuma ser mais rápido. Empresa com poucos sistemas tem menos ações a mapear. O que muda com o porte é a quantidade, não o método.
O agente pode errar mesmo com tudo isso?
Pode. A diferença é que o erro fica dentro de um limite conhecido. Ele erra ao escolher entre ações aprovadas, não ao inventar uma operação no banco.
Quem deve escrever esses limites?
Quem responde pela operação, com apoio técnico. São decisões de negócio. Deixar isso só com quem desenvolve é como pedir ao fornecedor que defina a sua política de desconto.
Isso resolve a parte de LGPD?
Ajuda e não resolve sozinho. Reduzir campos devolvidos e registrar chamadas são boas práticas, mas o enquadramento é decisão do jurídico. Conteúdo educativo não substitui avaliação técnica ou jurídica do seu caso.
Quanto tempo isso leva
O mapeamento das ações costuma levar de dois a quatro dias, e é trabalho de conversa, não de código. O que define o prazo real é o estado dos sistemas que guardam a informação.
Sistema que já permite consulta programada encurta tudo. Sistema que só entrega dado por planilha exportada à mão é o que transforma semanas em meses, e descobrir isso cedo vale mais que qualquer estimativa otimista.
A tarefa desta semana
Pegue a pergunta que mais chega no seu atendimento e escreva, em uma folha, as três linhas do contrato. O que precisa ser informado, o que volta como resposta e quem pode perguntar.
Se você conseguir escrever as três, a sua empresa está a poucas semanas de ter um agente útil. Se travar na segunda linha, encontrou o trabalho que precisa ser feito antes, e isso já vale a folha.
Quer esse desenho feito com alguém que já montou essa camada antes? fale com o time da Blue Labs no WhatsApp.