Perguntar ao sistema quais pedidos estão atrasados é uma coisa. Pedir que ele altere prazos, conceda desconto e envie uma cobrança é outra. A interface pode ser a mesma conversa, mas os riscos e as autorizações mudam a cada capacidade.
Integrar IA ao ERP exige separar consulta, preparação e execução. O agente deve receber somente as capacidades necessárias, e cada efeito precisa respeitar as regras do sistema e o contexto autorizado do usuário.
Comece pelo processo, não pelo comando aberto
“Quero uma IA que faça tudo no ERP” não define uma entrega verificável. Escolha uma jornada, como localizar pedidos em risco, preparar uma proposta ou resumir pendências. Depois identifique quais dados e ações essa tarefa realmente exige.
Em um exemplo hipotético de distribuidora, o atendimento consulta disponibilidade e prepara um orçamento. O agente não precisa de acesso para alterar custo de produtos ou exportar toda a base de clientes. A capacidade deve acompanhar a função, não o privilégio máximo disponível na credencial.
Uma matriz simples de autonomia
| Nível | Capacidade | Controle principal |
|---|---|---|
| Consultar | Ler status de pedido autorizado | Conferir vínculo e limitar campos |
| Preparar | Criar rascunho de proposta | Validar dados e indicar pendências |
| Solicitar aprovação | Apresentar efeito, valor e destinatário | Registrar decisão do responsável |
| Executar | Aplicar uma ação permitida | Autorização no servidor e rastreabilidade |
Essa matriz é um ponto de partida editorial. Não significa que toda operação de leitura seja inofensiva. Consultar dados financeiros ou pessoais também pode exigir restrição forte. O risco depende da informação e do uso, não apenas de haver uma gravação.
Regras comerciais precisam continuar no sistema
O modelo pode interpretar a solicitação, mas valores, alçadas e permissões devem ser verificados por lógica confiável. Uma chamada com estrutura válida não prova que o desconto foi autorizado nem que o usuário representa o cliente consultado.
Evite colocar condições importantes apenas no prompt. Se o servidor aceita qualquer valor enviado, uma interpretação incorreta pode produzir uma operação indevida. O endpoint precisa aplicar o limite e devolver uma explicação utilizável quando a ação não puder ser executada.
Ferramentas específicas ajudam a tornar o contrato compreensível. Uma função para preparar orçamento de um cliente é mais controlável do que uma função que executa comandos arbitrários no banco. Isso também facilita auditoria e teste.
Confirmação precisa mostrar o efeito concreto
Antes de uma ação relevante, apresente o que será feito: registro, destinatário, valor, condição e consequência. “Posso continuar?” é insuficiente quando o usuário não sabe se está aprovando um rascunho ou o envio definitivo.
A confirmação deve estar ligada à operação preparada. Se o cliente, o valor ou o destinatário mudar depois, a autorização anterior pode deixar de ser aplicável. O desenho precisa impedir que uma aprovação genérica seja reutilizada em um efeito diferente.
Falha de integração não pode virar confirmação falsa
Quando o ERP demora ou recusa uma solicitação, o agente deve informar o estado real. Receber um comando não significa concluir a operação. Uma resposta como “pedido atualizado” precisa depender da confirmação correspondente.
Também trate repetição. Uma tentativa pode ter sido concluída mesmo que a resposta não tenha chegado. Reexecutar sem identidade estável pode duplicar pedidos ou cobranças. A aplicação precisa reconhecer a mesma operação e conferir o resultado antes de repetir o efeito.
Um piloto com evidência de controle
Escolha uma tarefa de leitura e outra de rascunho. Use dados fictícios para testar usuário sem permissão, cliente inexistente, origem indisponível e informação incompleta. Depois avalie se o agente continua ajudando sem ultrapassar o limite.
O aceite deve considerar resultado correto, recusas adequadas, tempo, correções humanas e rastreabilidade. Uma demonstração em que tudo dá certo não mostra como o sistema se comporta em condições reais.
Checklist antes de ampliar a autonomia
- Jornada e resultado esperado definidos.
- Ferramentas limitadas ao processo necessário.
- Identidade e empresa verificadas fora do texto livre.
- Regras de negócio aplicadas no servidor.
- Rascunho separado de envio ou alteração definitiva.
- Confirmações ligadas a efeitos específicos.
- Repetição, falha e cancelamento testados.
- Histórico suficiente para investigação sem excesso de dados.
Perguntas frequentes
Posso conectar a IA diretamente ao banco do ERP?
Uma conexão ampla pode ampliar riscos e dificultar controle. Em geral, serviços específicos com autorização e validação oferecem fronteiras mais compreensíveis para a tarefa.
Toda ação precisa de aprovação humana?
Não necessariamente. A política deve considerar impacto, reversibilidade e autorização existente. O importante é definir limites explícitos, não liberar autonomia por acidente.
MCP resolve a autorização?
Não sozinho. O protocolo pode organizar capacidades, mas o sistema que executa a operação continua responsável por conferir acesso e regras comerciais.
Referência e próximo passo
O AI Risk Management Framework do NIST oferece uma base geral para administrar riscos. A matriz e os casos deste artigo são uma aplicação prática da A2CR, sem alegação de certificação.
Conheça a integração de sistemas e o artigo sobre MCP empresarial para planejar uma implantação com limites claros.
