Um agente pode redigir uma resposta excelente e ainda cometer um erro grave ao agir. Consultar um contrato, preparar uma alteração e confirmar um compromisso são capacidades diferentes. Para utilizar IA em processos empresariais, a empresa precisa definir quais ações podem ocorrer e quem tem autoridade para aprová-las.
Este guia apresenta um desenho de controle para agentes que acessam ferramentas e sistemas. Não autoriza ações em ambientes reais nem propõe automatizar decisões de alto impacto sem governança apropriada. Os cenários são hipotéticos e se concentram em processos operacionais com limites explícitos.
1. Separe quatro capacidades
Uma arquitetura pode distinguir consultar, sugerir, preparar e executar. Consultar reúne informação autorizada. Sugerir apresenta uma alternativa. Preparar cria um rascunho ou simulação. Executar altera o estado de um sistema ou produz uma comunicação externa.
Essas capacidades não devem compartilhar automaticamente a mesma credencial ou permissão. Uma ferramenta de leitura não precisa poder remover registros. Uma ferramenta que gera orçamento não precisa poder aceitá-lo pelo cliente.
Os padrões de adoção de agentes da Microsoft destacam que a passagem de assistência para execução exige responsabilidades e autoridade definidas. O desenho específico deve transformar essa fronteira em controles verificáveis, não apenas em um pedido genérico para o modelo ter cuidado.
2. Classifique ações por efeito e reversibilidade
Liste cada ferramenta e descreva seu efeito real. Enviar uma mensagem, mudar uma data e atualizar um campo podem ter consequências muito diferentes conforme o contexto. O nome técnico da função não é suficiente para avaliar o risco.
Considere quem será afetado, se a ação pode ser revertida, qual informação será transmitida e qual compromisso será criado. A política pode permitir consulta automática, rascunho livre e aprovação obrigatória para mudanças específicas.
| Capacidade | Exemplo hipotético | Controle possível |
|---|---|---|
| Consulta | Buscar situação de uma solicitação | Escopo por usuário e atendimento |
| Preparação | Montar proposta preliminar | Rascunho identificado, sem envio |
| Alteração reversível | Atualizar classificação interna | Política e registro de mudança |
| Comunicação externa | Enviar condição comercial | Conteúdo e destinatário aprovados |
| Compromisso | Confirmar uma reserva ou contratação | Autoridade, estado atual e confirmação adequada |
3. A aprovação precisa de um objeto concreto
Pedir “posso continuar?” não oferece informação suficiente. A pessoa deve revisar ação, destino, dados, efeitos e condições. O pedido deve corresponder ao objeto que será executado, com referência à versão apresentada.
Se a proposta mudar depois da aprovação, a autorização anterior pode não cobrir o novo conteúdo. O backend precisa vincular o aceite à ação e verificar se seus elementos relevantes continuam iguais. Uma conversa em linguagem natural, isoladamente, não garante esse vínculo.
Também defina expiração e escopo. Uma aprovação para uma mensagem não deveria liberar todos os envios futuros ao mesmo cliente. A autoridade pode ser limitada por operação, período, valor, destinatário ou tipo de alteração, conforme a necessidade.
4. Implemente a política fora do prompt
O prompt orienta comportamento, mas as ferramentas precisam rejeitar ações fora da permissão. Verifique identidade, escopo, estado e aprovação no servidor. Não confie em um campo enviado pelo próprio modelo afirmando que tudo foi autorizado.
Use uma lista de capacidades permitidas e entradas validadas. O agente não deve construir livremente qualquer URL ou comando para acessar recursos que a ferramenta não foi projetada para oferecer. A restrição da interface reduz ambiguidades e facilita testes.
Conteúdos recuperados de páginas, mensagens e arquivos não podem ampliar a autoridade do agente. A referência de prevenção de prompt injection da OWASP descreve o risco de misturar dados não confiáveis com instruções; o fluxo deve manter essa distinção e limitar os efeitos possíveis.
5. Reconfira o estado antes de executar
Uma ação aprovada pode deixar de ser válida porque o sistema mudou. A reserva foi ocupada, o cliente alterou o pedido ou uma proposta foi substituída. A execução deve verificar o estado atual e detectar conflitos, em vez de aplicar uma decisão antiga cegamente.
Quando houver conflito, preserve o contexto e peça nova decisão quando necessário. Não ajuste silenciosamente o destinatário, o valor ou a data para “fazer funcionar”. A pessoa aprovou uma condição concreta, não qualquer alternativa que o agente encontre depois.
Registre a operação com identidade estável. Se houver perda de resposta, a recuperação deve consultar o resultado conhecido antes de repetir. Aprovação humana não elimina duplicidade causada por retentativa técnica.
6. Exemplo: proposta preparada por um agente
Uma consultoria recebe uma necessidade de sistema. O agente organiza requisitos e prepara uma proposta preliminar a partir de informações comerciais autorizadas. Ele identifica dúvidas que ainda precisam de confirmação e não afirma que o cliente já aceitou.
Uma pessoa revisa o documento, ajusta o escopo e aprova o envio daquela versão ao destinatário identificado. O sistema associa a autorização ao conteúdo e confere o canal. Se o agente gerar outra versão depois, ela volta ao estado de rascunho.
Após o envio, o registro indica sucesso conhecido ou pendência técnica. A resposta do cliente não é tratada automaticamente como aceite contratual de qualquer condição. O processo comercial e jurídico aplicável continua definindo o que representa um compromisso válido.
7. Planeje espera, recusa e intervenção humana
Um fluxo que aguarda aprovação precisa sobreviver à passagem do tempo e a falhas de processo. Guarde estado e referência da solicitação em um local apropriado. Não dependa apenas da memória de uma sessão do modelo.
A pessoa pode recusar, pedir alteração ou assumir o atendimento. O agente deve respeitar esses estados e não reenviar pedidos repetidos sem critério. Uma recusa não deveria ser reinterpretada como autorização parcial porque a tarefa parece importante.
O guia de execução de workflows do Temporal é uma referência técnica sobre execução durável. Utilizar um motor especializado é uma decisão arquitetural; qualquer solução escolhida precisa preservar espera, retomada e efeitos externos de forma coerente.
8. Audite decisões sem coletar tudo indiscriminadamente
O histórico deve mostrar quem autorizou, qual ação, qual versão e qual resultado. Não é necessário armazenar todos os dados sensíveis ou conversas completas em qualquer log para obter rastreabilidade.
Defina acesso e retenção apropriados ao registro. A equipe de suporte precisa investigar uma falha, mas isso não exige permissão irrestrita sobre todos os clientes. A governança deve acompanhar a expansão das ferramentas do agente.
Também registre o motivo de bloqueios relevantes. Isso ajuda a distinguir uma política correta de uma falha de configuração. Um agente que não executa nada pode estar seguro em um sentido limitado e ainda assim não atender ao processo desejado.
9. Teste autoridade, não somente qualidade da resposta
Inclua cenários de destinatário incorreto, aprovação vencida, conteúdo alterado, recusa e intervenção humana. Verifique que a ferramenta realmente rejeita o que está fora do escopo. O modelo dizer que recusou não comprova que o backend impede a operação.
Comece com simulações e ações de baixo risco em ambientes autorizados. A expansão de autonomia deve depender de evidências, monitoramento e capacidade de resposta. Para estruturar essa análise, consulte o centro de IA aplicada A2CR.
Checklist de implantação
- Separar consulta, sugestão, preparação e execução.
- Classificar ferramentas por efeito e reversibilidade.
- Definir autoridade de pessoas e serviços.
- Apresentar ação concreta antes da aprovação.
- Vincular autorização a conteúdo, destino e versão.
- Aplicar políticas no backend, além do prompt.
- Revalidar estado e tratar conflitos antes de agir.
- Preservar espera, recusa e intervenção humana.
- Reconhecer repetição e resultados incertos.
- Testar bloqueios com cenários autorizados.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre a conferência, o responsável e as observações da implantação.
Perguntas frequentes
Toda ação precisa de aprovação manual?
Não. A política pode autorizar tarefas delimitadas e de risco aceitável. O importante é explicitar o escopo e implementar controles. Exigir aprovação para tudo pode tornar o fluxo inútil, assim como liberar tudo pode criar riscos indevidos.
Uma instrução no prompt é suficiente para impedir envios?
Não como único controle. O serviço de envio deve verificar autorização e limites. O modelo precisa receber apenas as capacidades compatíveis com sua função.
A aprovação elimina erros do agente?
Não. Ela acrescenta uma decisão humana, que também precisa de contexto e interface adequados. A execução ainda pode falhar, repetir ou encontrar um estado diferente, exigindo tratamento técnico.
Para desenhar autonomia com limites claros, prepare um briefing com as ferramentas desejadas e as ações que exigem decisão humana. A A2CR pode estruturar um agente integrado ao processo, sem confundir conversa com autoridade.
Autoria: Agência A2CR. Preparação editorial: 12 de novembro de 2026. Exemplo hipotético; decisões de alto impacto e compromissos exigem avaliação e controles específicos.
