Agentes de IA com aprovação humana e auditoria: que parceiro escolher

Para escolher um parceiro para criar agentes de IA com aprovação humana e auditoria, peçam-lhe que prove, numa demonstração com os vossos dados, três coisas: que a aprovação é imposta no sistema que executa a ação, e não no prompt; que cada aprovação fica presa à ação exata e expira; e que um auditor consegue reconstruir qualquer execução meses depois. Na Unlocking Tech chamamos-lhes as três provas. Quem as passa tem a arquitetura certa; quem fala de "human-in-the-loop" sem as mostrar tem um diapositivo.

Verificado a 2/11/2026 no AI Act Service Desk da Comissão Europeia (texto consolidado de 27/07/2026, já com o Omnibus Digital) e na OWASP AI Agent Security Cheat Sheet. É informação geral, escrita por engenheiros que constroem agentes de IA, não aconselhamento jurídico — para um caso concreto, confirmem com um advogado.

TL;DR:

• As três provas: aprovação imposta no sistema que executa, aprovação presa à ação exata e com prazo, execuções reconstruíveis a partir do registo. Peçam para as ver a funcionar.
• Pedir confirmação no prompt não é aprovação. A OWASP chama-lhe complete mediation: a autorização vive nos sistemas a jusante, não na decisão do modelo.
• A lei obriga menos do que se diz: a supervisão humana do art. 14.º do AI Act aplica-se a sistemas de alto risco, a partir de 2 de dezembro de 2027 no caso do Anexo III. Ainda assim, o projeto de orientações da ANACOM sobre literacia em IA já recomenda, para agentes que executam ações, limites de ação, aprovações humanas obrigatórias, registo do que o agente fez e um kill switch.
• A Unlocking Tech, empresa portuguesa de engenharia de IA sediada em Lisboa, lança cada agente com uma pessoa no circuito — aprovação nos passos de risco, um teto de custo por execução e cada ação registada — e só sobe a autonomia quando a taxa de acerto medida o justifica.

O que são, na prática, agentes de IA com aprovação humana?

Um agente de IA com aprovação humana prepara a ação — lê o contexto, decide o passo seguinte, monta o pedido ao CRM ou ao ERP — e só a executa depois de uma pessoa com autoridade a aprovar, num controlo técnico que o agente não consegue contornar. A auditoria é a outra metade: cada execução deixa um registo que permite saber, meses depois, o que o agente leu, o que propôs, quem aprovou e o que foi escrito.

Há dois modelos: no human-in-the-loop nada corre sem aprovação; no human-on-the-loop a ação corre e a pessoa supervisiona e pode parar ou reverter. Um agente bem desenhado usa os dois, ação a ação, em três padrões:

Porque é que "pedir confirmação no prompt" não é aprovação

Escrever no prompt "pergunta antes de apagar" é uma instrução ao modelo, não um controlo: o modelo pode ignorá-la, ser manipulado por texto escondido num email ou numa fatura, ou simplesmente errar. No LLM06:2025 Excessive Agency, a OWASP separa duas medidas: exigir aprovação humana para ações de alto impacto e complete mediation — implementar a autorização nos sistemas a jusante em vez de deixar o modelo decidir se uma ação é permitida. A AI Agent Security Cheat Sheet acrescenta que a autorização se impõe no componente de execução, fora do contexto do agente, e que uma flag user_confirmed não chega.

Traduzido: o pedido ao ERP só sai se existir uma aprovação válida e registada para aquele pedido. Sem ela — ou com o serviço que a valida em baixo —, a ação não corre. A OWASP chama-lhe fail closed.

Que ações devem exigir aprovação humana — e quais não?

Exigem aprovação as ações irreversíveis, as que mexem em dinheiro ou em documentos com valor legal e as comunicações redigidas pelo agente que saem em nome da empresa; mensagens de modelo fixo (lembretes, pedidos de avaliação) e ações reversíveis e internas podem correr sozinhas, desde que fiquem registadas. Três perguntas decidem: dá para desfazer? Quanto custa se correr mal? Quem paga o erro: a vossa empresa ou um cliente?

A regra que aplicamos: no lançamento, o agente não executa sozinho nenhuma ação irreversível nem com impacto financeiro acima de um limiar definido por vocês. Por setor:

O erro oposto também existe: mandar tudo para aprovação. Quem aprova duzentos pedidos por dia deixa de os ler. O art. 14.º, n.º 4, alínea b), do AI Act pede que quem supervisiona fique consciente da tendência para confiar automaticamente, ou em excesso, no resultado do sistema — o automation bias. Na nossa experiência, uma fila só protege se tiver poucas entradas e cada uma mostrar o que muda; quando cresce, revejam os limiares ou a qualidade do agente. Se ainda estão a escolher o primeiro processo, os 7 agentes de IA que mais compensam numa empresa são um bom ponto de partida.

Como funciona uma fila de aprovação bem desenhada?

Uma fila de aprovação bem desenhada mostra a ação exata que o agente quer executar — sistema, registo, campos antes e depois, motivo —, aceita aprovar, rejeitar ou editar, deixa a proposta expirar, e só então o sistema de execução envia o pedido, com uma credencial própria do agente e uma entrada no registo. Em oito passos:

1. Pedido: chega um email, uma mensagem de WhatsApp, uma fatura.
2. Proposta: o agente monta a ação concreta — os campos e os valores, não "atualizar o cliente".
3. Validações: os campos estão no âmbito do agente? Os dados batem com o sistema de referência? A ação já foi feita?
4. Fila: a pessoa certa recebe a proposta onde já trabalha (Outlook, Teams, Slack, uma tarefa no CRM), com o diff.
5. Decisão: aprovar, rejeitar com motivo, editar ou deixar expirar.
6. Execução: o sistema confirma que a aprovação vale para aquele pedido e envia-o com o utilizador do agente.
7. Registo: o que se propôs, quem aprovou, o que foi enviado, o que o sistema respondeu.
8. Rollback: os valores anteriores são repostos a partir do registo — e o rollback também fica registado.

Exemplo trabalhado: uma escrita no HubSpot validada contra o Primavera

Um cliente escreve a pedir mais prazo de pagamento. O agente propõe atualizar o negócio N-1042 (Cliente Exemplo, Lda.) no HubSpot. Os dados são fictícios; o caminho é o que usamos na integração de IA com CRM e ERP:

Antes de chegar ao gestor de conta, a proposta passa quatro validações: campos dentro do âmbito do utilizador da IA; fase existente e mudança permitida no pipeline; cliente confirmado no Primavera, porque o NIF coincide; e uma chave de idempotência, um identificador único da ação que impede que uma nova tentativa automática ou um clique duplo a executem duas vezes. Em dry-run, nada é escrito: o gestor revê o payload exato. Aprovada, a escrita sai pela API do HubSpot com o utilizador do agente e fica registada como «3 campos · motivo: email do cliente · aprovado pelo gestor de conta». Se estiver errada, o rollback repõe os três campos a partir do registo.

A aprovação fica presa ao pedido, não ao negócio. Se alguém alterar o negócio entre a proposta e o clique, a proposta deixa de corresponder ao estado atual e tem de ser refeita. É o que a OWASP descreve: o registo da aprovação inclui o ator, a ferramenta, o recurso alvo, os parâmetros normalizados, a data e hora (timestamp) e a expiração. Como cada ERP português se liga está em integrar IA no ERP: Primavera, PHC, Sage e Dynamics; a escolha entre plataformas e agentes à medida, em agentes de IA para CRM e ERP.

O que deve ficar no registo de auditoria de um agente de IA?

O registo de auditoria deve permitir reconstruir uma execução inteira sem perguntar a ninguém: o que a disparou, o que o agente leu, que modelo e que versão das instruções usou, o que propôs, que validações passaram, quem aprovou e quando, o que foi enviado e o que o sistema respondeu. Se faltar um destes elementos, o registo diz que algo aconteceu, mas não porquê.

Para ações de risco, a OWASP pede metadados com a classificação da ação, o resultado da autorização, o identificador da aprovação, o resultado da execução e a versão da política; a tabela junta o que falta para reverter e explicar. Uma entrada, com os dados mascarados:

{
  "execution_id": "exe_2026-11-02_0412",
  "trigger": { "type": "email", "message_id": "msg_7f3c…" },
  "sources": ["hubspot:deal/N-1042", "primavera:cliente/C-0388"],
  "model": "<fornecedor>/<modelo>@<versão>",
  "prompt_version": "v14",
  "policy_version": "politica-aprovacao v3",
  "proposed_action": {
    "tool": "hubspot.update_deal",
    "target": "deal/N-1042",
    "params": { "stage": "Em negociação", "next_step": "Rever o prazo de pagamento", "note": "Resumo do email do cliente" }
  },
  "checks": { "field_scope": "ok", "stage_valid": "ok", "nif_match": "ok", "idempotency_key": "a91e…" },
  "risk_class": "approval_required",
  "approval": {
    "id": "apr_5521",
    "approver": "gestor-conta-03",
    "decision": "approved",
    "decided_at": "2026-11-02T10:14:09Z",
    "expires_at": "2026-11-02T18:00:00Z",
    "payload_hash": "sha256:4be0…"
  },
  "result": { "status": 200, "fields_written": 3 },
  "rollback_ref": "rb_exe_2026-11-02_0412"
}

Três regras: só se acrescenta, nunca se edita — guardem o registo fora do agente, num armazenamento onde ele só escreve entradas novas; é exportável por vocês, em JSON ou CSV, sem pedir ao fornecedor; e tem prazo, porque contém dados pessoais e a Comissão Europeia resume a regra do RGPD assim: conservar pelo período mais curto possível, com prazos para apagar ou rever (página em inglês). Separem os metadados (quem, quando, que ação) do conteúdo (o email, a fatura) e deem-lhes prazos diferentes.

O que exigem o AI Act, a OWASP e o NIST, traduzido em controlos?

O AI Act só obriga à supervisão humana os sistemas de alto risco: o art. 14.º aplica-se aos do Anexo III a partir de 2 de dezembro de 2027 e aos do Anexo I a partir de 2 de agosto de 2028. As datas são as do art. 113.º, na redação do Omnibus Digital (Regulamento (UE) 2026/1744). Ainda assim, as cinco capacidades que o art. 14.º, n.º 4, pede são uma boa especificação de supervisão para qualquer agente. A OWASP cobre a segurança das ferramentas; o NIST, a gestão de risco. Cada requisito, o controlo e o teste para a demo:

Quatro notas para não exagerar:

• O art. 14.º obriga quem fornece o sistema; o art. 26.º, quem o usa. Quem manda desenvolver um sistema e o põe em serviço com o seu nome passa a ser prestador — o que isso implica está no guia do AI Act para PME.
• A transparência já se aplica: o art. 50.º obriga a que um agente que fala com pessoas lhes diga que é uma IA (salvo quando isso é óbvio), desde 2 de agosto de 2026, como confirma o FAQ da Comissão sobre o AI Act.
• O NIST AI RMF é voluntário: publicado a 26 de janeiro de 2023, com um perfil para IA generativa de 26 de julho de 2024, e em revisão (verificado a 2/11/2026).
• O documento da ANACOM é um projeto de orientações sobre literacia em IA, não vinculativo, mas já fala de agentes: para os que executam ações, recomenda limites de ação, aprovações humanas obrigatórias, registo do que o agente fez e um kill switch.

Como comparar parceiros para agentes de IA com aprovação humana e auditoria?

Comparem os parceiros numa grelha ponderada em que aprovação, auditoria e segurança valem 65% e são eliminatórias, e em que cada nota exige uma evidência mostrada, não uma resposta numa reunião. As perguntas gerais estão no guia para escolher uma empresa de desenvolvimento de software com IA, e a comparação de propostas comerciais no guia para comparar fornecedores de agentes de IA. Aqui fica a parte do controlo:

Como pontuar: nota de 1 a 5 por critério, a dividir por 5 e a multiplicar pelo peso; a soma vai até 100. Como referência: acima de 80, base sólida; entre 65 e 80, o piloto decide; abaixo de 65, o risco fica do vosso lado. Eliminatórias, seja qual for a soma: nota 1 ou 2 em aprovação, auditoria ou segurança; recusa de um piloto com os vossos dados; registos que só o fornecedor lê; um agente que escreve com a conta de uma pessoa.

Oito perguntas para a primeira reunião

1. Mostrem uma aprovação recusada: o que acontece ao pedido e o que fica no registo?
2. E se os dados mudarem depois de eu aprovar e antes da execução?
3. Quanto tempo vale uma aprovação, e o que acontece quando expira?
4. Com que credencial escreve o agente no ERP e no CRM, e que campos pode tocar?
5. Se o serviço de aprovação estiver em baixo, o agente executa ou fica parado?
6. Como impedem que uma instrução escondida numa fatura mude o que o agente faz?
7. Consigo reconstruir e exportar uma execução de há três meses sem vos pedir ajuda?
8. De quem são o código, a configuração — prompts, políticas, regras de aprovação — e os registos no fim do contrato?

Que piloto pedir antes de assinar?

Peçam um piloto de duas a quatro semanas num processo real de risco controlado — por exemplo, faturas de fornecedor que o agente lê e propõe lançar no PHC ou no Primavera, sempre em rascunho — com testes de abuso e critérios de aprovação escritos antes de começar. Uma demo prova que o modelo funciona; o piloto prova que os controlos funcionam quando algo corre mal — a diferença entre demo e produção que detalhamos em porque é que o vosso agente de IA não é fiável para escalar. Os testes, adaptados da matriz de casos de abuso da OWASP:

Fixem também as métricas: taxa de propostas aprovadas sem edição, tempo até à aprovação e exceções por semana. São elas que decidem, mais tarde, onde a aprovação pode passar a exceção.

O que pôr no contrato com o parceiro?

O contrato deve dizer que código, configuração e registos são vossos e exportáveis a qualquer momento, quanto tempo se guardam, em quanto tempo o fornecedor avisa de um incidente, quem aprova, opera e mantém cada agente, e como se sai. Cláusula a cláusula:

• Propriedade do código, da configuração (prompts, políticas, limiares de aprovação) e dos registos.
• Exportação dos registos em formato aberto, sem custo adicional.
• Retenção e apagamento por tipo de dado, alinhados com o RGPD e, num sistema de alto risco, com os seis meses do art. 26.º, n.º 6.
• Notificação de incidentes — ação indevida, fuga de dados, falha dos controlos —, com prazo e conteúdo do aviso.
• Papéis e credenciais: quem aprova, opera, mantém e pode parar o agente; contas do agente criadas e revogáveis por vocês.
• Acordo de tratamento de dados, com onde os dados são processados e por que fornecedor de modelo.
• Saída: o que é entregue no fim — código, documentação, runbook, registos — e em que prazo.
• Alto risco: o art. 25.º, n.º 4 exige um acordo escrito entre o prestador e quem fornece ferramentas, serviços ou componentes integrados, sobre a informação, o acesso técnico e a assistência necessários para cumprir.

Porque é que a aprovação humana e a auditoria não devem ser um extra?

Desenhadas desde o primeiro dia, a aprovação humana e a auditoria fazem parte da construção do agente e não são um extra; acrescentá-las a um agente que já escreve diretamente nos sistemas obriga a refazer o caminho de execução e, na nossa experiência, sai mais caro. Na Unlocking Tech, o registo de tudo o que o agente faz está incluído no setup de cada agente e a aprovação nos passos de risco faz parte do lançamento; o setup é único, desde €1.500 para um processo ou €2.500 para um agente multi-passo, e a alternativa é uma mensalidade fixa por agente. Tokens do modelo e canais pagos, como o WhatsApp, são à parte — os modelos estão em pacotes e preços.

O custo que pesa de facto é o tempo das pessoas a aprovar: na nossa experiência, num agente com volume, a revisão humana pesa mais todos os meses do que os tokens — os números estão no guia quanto custa um agente de IA.

Como a Unlocking Tech constrói agentes com aprovação humana e auditoria

A Unlocking Tech é uma empresa portuguesa de engenharia de IA, sediada em Lisboa e fundada em 2022, que constrói agentes de IA à medida para PME com aprovação humana nos passos de risco e registo de cada ação. Os agentes ligam-se ao WhatsApp, ao email, ao CRM e ao ERP que a empresa já usa: PHC, Primavera, Sage, Dynamics, HubSpot e Outlook. Construímos em n8n quando um workflow low-code chega e em código (Python ou C# com Semantic Kernel, ou Azure AI) quando não chega, com o modelo escolhido por tarefa. É o desenho que entregamos nos serviços de automação com IA, e o processo está publicado na página de agentes de IA para empresas: testes contra tarefas reais do passado antes de lançar; lançamento com uma pessoa no circuito, com aprovação nos passos de risco, teto de custo por execução e cada ação registada; e autonomia a subir passo a passo, só onde a taxa de acerto medida o justifica. O código e a documentação ficam com o cliente, e um primeiro agente bem delimitado chega a produção em cerca de duas semanas.

Um exemplo real: os dois agentes do Grupo Filtrarte, um grupo português de soluções para o lar. O agente de leads lê o Google Sheets a cada 15 minutos, elimina as leads duplicadas das campanhas Meta e Google Ads, cria o contacto no HubSpot e avisa quem atribui o distribuidor; o segundo pede avaliações por Outlook e WhatsApp quando uma sessão de apoio é concluída no HubSpot. Aqui a autonomia é aceitável: nenhum passo mexe em dinheiro nem em documentos com valor legal, o que sai para o cliente é um pedido de avaliação e a decisão comercial — a que distribuidor vai cada lead — continua com quem o atribui. Cada ação e submissão fica registada no Google Sheets, que serve de sistema de registo e permite auditoria.

Quando não somos a escolha certa

• O processo vive todo numa só plataforma. Se tudo acontece no Salesforce, o Agentforce é o caminho mais curto; no Microsoft 365, o Copilot Studio. Os eixos de decisão estão em construir ou comprar agentes de IA.
• O volume é baixo. Com poucas execuções por semana, um workflow em n8n com um passo de aprovação, montado pela vossa equipa, pode chegar — o guia de agentes de IA com n8n é um bom começo.
• O sistema decide sobre pessoas numa área de alto risco, como recrutamento ou crédito a particulares. Aí o trabalho principal é de conformidade e começa num advogado; muitas vezes, a melhor resposta é redesenhar o sistema para ficar fora do alto risco.

Perguntas frequentes

O AI Act obriga todos os agentes de IA a ter aprovação humana?

Não. A supervisão humana do art. 14.º aplica-se a sistemas de alto risco: os do Anexo III (recrutamento, avaliação de trabalhadores, crédito a particulares, entre outros) a partir de 2 de dezembro de 2027, e os do Anexo I, em produtos regulados, a partir de 2 de agosto de 2028, segundo o art. 113.º do AI Act, na redação do Omnibus Digital. A maioria dos agentes de uma PME — atendimento, faturas, leads — não é de alto risco. Já se aplica, desde 2 de agosto de 2026, a obrigação de um agente que fala com pessoas lhes dizer que é uma IA, salvo quando isso é óbvio (art. 50.º). No resto, aprovar os passos de risco é boa engenharia, não obrigação legal.

Qual é a diferença entre human-in-the-loop e human-on-the-loop?

No human-in-the-loop, a pessoa aprova antes de a ação acontecer e nada corre sem ela. No human-on-the-loop, a ação corre sozinha e a pessoa supervisiona: vê os registos, recebe as exceções, pode parar o agente e reverter. O primeiro serve para ações irreversíveis ou de impacto; o segundo, para ações reversíveis e de volume, com taxa de acerto medida.

A aprovação humana não anula o ganho de tempo?

Não, se for desenhada para as exceções. Aprovar uma proposta já preparada, com os campos e o diff à vista, leva muito menos tempo do que fazer a ação à mão. O ganho perde-se quando tudo vai para a fila e o aprovador deixa de ler. Meçam a taxa de propostas aprovadas sem edição: quando estiver alta e estável numa ação reversível, essa ação pode correr sozinha, com supervisão por amostragem.

Dá para fazer aprovações humanas em n8n?

Sim. O n8n tem human-in-the-loop para as ferramentas de um AI Agent: o workflow fica em pausa antes de a ferramenta correr, o revisor vê que ferramenta o agente quer usar e com que parâmetros, e uma recusa cancela a ação. A aprovação pode chegar por Slack, Microsoft Teams, Outlook, Gmail, WhatsApp Business, Telegram, Discord, Google Chat ou pelo chat do n8n. Para dar prazo a uma aprovação por formulário ou webhook, o nó Wait tem a opção Limit Wait Time — quando o prazo acaba, o workflow retoma sozinho, por isso o ramo seguinte tem de tratar a falta de resposta como recusa (fail closed) e nunca seguir para a escrita (documentação do n8n verificada a 2/11/2026). O resto é desenho: credencial do agente no ERP com permissões mínimas, validações antes da escrita e um registo de auditoria guardado fora do workflow. A Unlocking Tech constrói em n8n quando um workflow low-code chega e passa para código quando o processo pede mais controlo.

Quanto tempo devemos guardar os registos de um agente de IA?

Num sistema de alto risco, pelo menos seis meses: o art. 26.º, n.º 6, do AI Act obriga quem o usa a guardar, na medida em que estejam sob o seu controlo, os registos gerados automaticamente durante esse período, salvo se outra lei exigir outra coisa — por isso, se os registos ficam no fornecedor, o acesso tem de estar no contrato. Fora do alto risco, o AI Act não fixa prazo e aplica-se o RGPD: o período mais curto possível, com prazos definidos para apagar ou rever e escritos no contrato.

Quem é responsável se o agente errar depois de uma aprovação?

Em regra, perante os vossos clientes responde a vossa empresa, tal como responderia pelo erro de um colaborador. Internamente, o registo mostra o que o aprovador viu: se a proposta mostrava o erro e foi aprovada, o problema está no processo de aprovação; se o sistema executou algo diferente do aprovado, é um defeito do sistema, e o contrato deve dizer o que o fornecedor faz nesse caso. Num sistema de alto risco, o AI Act reparte obrigações entre prestador e responsável pela implantação — para um caso concreto, confirmem com um advogado.