Agentes de IA com segurança: limites, dados e supervisão

Os agentes de IA são a primeira categoria de software que executa ações em nome da empresa sem que alguém carregue num botão. Não sugerem: fazem. Enviam o email, alteram o registo no CRM, emitem a nota de crédito.

Essa diferença muda o que significa segurança. Um erro de um assistente é uma frase errada no ecrã. Um erro de um agente é uma fatura enviada ao cliente errado, com o carimbo da empresa.

O Eurostat indica que 20,0% das empresas da UE com 10 ou mais pessoas usaram tecnologias de IA em 2025. Em Portugal, o INE aponta 11,5%, mais 2,9 pontos percentuais do que no ano anterior. A adoção está a crescer mais depressa do que as regras internas que a deviam enquadrar.

Este artigo trata das três decisões que determinam se um agente de IA é seguro numa PME: que limites lhe dá, que dados lhe deixa tocar e como o supervisiona.

Com agentes de IA, o risco muda de sítio: já não é o que a IA diz, é o que a IA faz

O relatório trimestral de exploits do OWASP GenAI Security Project, que cobre 1 de janeiro a 11 de abril de 2026, documenta oito incidentes com sistemas de IA. Vale a pena olhar para a distribuição.

Três dos oito envolveram agência excessiva — o agente tinha permissões a mais para o que precisava de fazer. Um envolveu injeção indireta de prompt. Apenas um dos oito tinha um CVE formal atribuído (o CVE-2025-59528, execução remota de código no Flowise, com 12 000 a 15 000 instâncias expostas na internet).

Esse último número é o mais revelador. A maioria dos incidentes com agentes de IA não nasce de uma falha de código catalogada. Nasce de má configuração, de erros de desenho e de fluxos de dados mal pensados. Não são problemas que um patch resolve — são problemas que uma decisão de arquitetura resolve, ou não.

No Top 10 do OWASP para aplicações com modelos de linguagem, a agência excessiva subiu de sexto lugar em 2025 para terceiro em 2026. É a categoria que mais subiu, e é exatamente a que se aplica a quem está a montar agentes.

Limites: a regra dos dois em três

Há uma heurística de desenho que vale mais do que qualquer lista de boas práticas, e que se resume a três propriedades perigosas.

Um agente torna-se explorável quando acumula as três em simultâneo:

1. Acesso a dados privados — o CRM, o email, a base de clientes, os ficheiros internos.
2. Exposição a conteúdo não confiável — emails recebidos, PDFs de fornecedores, páginas web, tickets de clientes.
3. Capacidade de comunicar para fora — enviar email, chamar uma API externa, publicar algo.

Com as três, um atacante que consiga colocar texto no canal de entrada pode instruir o agente a ler dados privados e a enviá-los para fora. Com duas em três, o mesmo ataque não fecha o circuito.

A Meta formalizou isto como a "regra dos dois": um agente autónomo pode ter no máximo duas destas propriedades. Se o caso de uso exigir mesmo as três, então deixa de ser autónomo e passa a exigir aprovação humana antes de agir.

Na prática, isto traduz-se numa pergunta que qualquer decisor pode fazer à equipa técnica: este agente lê algo que veio de fora, tem acesso aos nossos dados e consegue enviar mensagens? Se a resposta for sim às três, o desenho está errado ou falta-lhe um passo de aprovação.

O problema que os fornecedores não vão corrigir

Convém perceber porque é que a injeção de prompt não se resolve com uma atualização.

Um modelo de linguagem recebe as instruções do sistema, o pedido do utilizador e qualquer texto vindo de fora como uma única sequência de tokens. Não existe uma forma fiável de marcar uns tokens como comandos e outros como dados. É a mesma classe de problema que o SQL injection era antes das consultas parametrizadas — com a diferença de que aqui ainda não existe o equivalente à consulta parametrizada.

A injeção de prompt mantém-se em primeiro lugar no Top 10 do OWASP e está ligada a seis das dez categorias da lista dedicada a aplicações com agentes. E as instruções já não vêm só em texto: podem estar escondidas dentro de uma imagem, de um áudio ou de um documento que o agente processa.

Isto não é motivo para não usar agentes de IA. É motivo para não os desenhar a assumir que o modelo vai obedecer sempre a quem manda. Assume-se o contrário e limita-se o estrago.

Dados: nos agentes de IA, onde corre o workflow não é onde corre o modelo

Esta é a confusão mais cara que vemos em projetos de PME.

Instalar a plataforma de automação em servidor próprio, num alojamento europeu, é uma decisão sólida — e é uma das razões pelas quais o n8n é uma escolha frequente para automação de workflows em empresas com dados sensíveis. Mas resolve a orquestração, não a inferência.

Se o fluxo corre no seu servidor em Lisboa e depois chama a API de um modelo alojado nos Estados Unidos, o prompt — incluindo o nome do cliente, o valor da fatura e o histórico da conversa — viaja para os Estados Unidos. A fronteira que interessa para o RGPD é onde acontece a inferência, não onde está o motor de workflows.

Três decisões concretas decorrem daí:

• Minimizar o que entra no prompt. Um agente que classifica reclamações não precisa do NIF nem do IBAN do cliente. Filtrar campos antes de chamar o modelo é o controlo mais barato e mais eficaz que existe.
• Saber onde está o fornecedor de inferência e ter o contrato de subcontratação a cobrir isso. Uma opção europeia ou um modelo alojado internamente muda a resposta, com custo e desempenho diferentes.
• Registar o que foi enviado. Sem registo do prompt e da resposta, não há forma de auditar um incidente nem de responder a um pedido de acesso.

Há ainda o problema da IA que ninguém autorizou. Segundo os dados citados pelo OWASP, apenas 37% das organizações têm uma política para detetar IA em uso não aprovado. Na maioria das empresas, alguém já está a colar dados de clientes numa ferramenta que a direção desconhece.

Supervisão: aprovação humana onde a ação é irreversível

Supervisionar tudo é o mesmo que não supervisionar nada — a equipa aprova em piloto automático ao fim de três dias. A supervisão só funciona quando é seletiva.

O critério é a reversibilidade. Ler um email, classificar um ticket e preencher um rascunho são ações reversíveis: se o agente errar, corrige-se sem custo. Enviar uma comunicação a um cliente, apagar um registo, emitir uma nota de crédito ou fazer um pagamento não são.

A documentação do n8n sobre aprovação humana em chamadas de ferramentas implementa exatamente esta distinção: a revisão humana ativa-se por ferramenta, não para o agente inteiro. Quando o agente decide usar uma ferramenta marcada para revisão, o fluxo suspende-se e envia um pedido de aprovação por Slack, Telegram, Gmail ou pelo chat da própria plataforma, mostrando que ação vai ser executada e com que parâmetros. Se for recusada, a ação é cancelada e o agente é informado da recusa — o que importa, porque o agente não fica a assumir que a tarefa ficou feita.

O padrão que funciona: o agente trata de todo o percurso, e só a última ação irreversível passa por uma pessoa. É a mesma lógica que já se aplica a automação de aprovações para encurtar ciclos de decisão, só que agora quem pede a aprovação é o software.

Um exemplo com números, com o cálculo à vista

Não temos um estudo público que meça isto, por isso o que se segue é uma estimativa, com os pressupostos declarados.

Uma PME recebe 40 emails por dia no endereço de apoio ao cliente. Triagem, resposta-tipo e, em cerca de 3 casos por dia, uma nota de crédito a emitir. A triagem manual leva cerca de 4 minutos por email: 160 minutos por dia, perto de 2,7 horas.

Com um agente mal desenhado — acesso ao CRM, leitura dos emails recebidos e permissão para emitir notas de crédito e responder ao cliente — temos as três propriedades da regra dos dois em simultâneo. Um email construído por um atacante pode pedir ao agente que emita uma nota de crédito ou que reenvie dados de outro cliente.

Com o mesmo agente desenhado com limites: classifica e prepara a resposta em todos os 40 emails; a emissão de notas de crédito é uma ferramenta com revisão humana obrigatória. Passam pela pessoa apenas os 3 casos por dia, a 2 minutos cada: 6 minutos.

A conta são 160 minutos contra 6. E a diferença não vem de o agente ser mais rápido — vem de a supervisão estar concentrada nos 7,5% de casos onde o erro custa dinheiro. O mesmo raciocínio de concentrar o esforço humano onde ele decide alguma coisa já discutimos a propósito das tarefas de back-office em que o controlo humano continua essencial.

O que a lei já exige, em agosto de 2026

O Regulamento da IA da União Europeia não se aplica só a quem constrói modelos. Aplica-se também a quem os usa, e há duas obrigações que já estão em vigor e que apanham qualquer PME.

O artigo 4.º, sobre literacia em IA, aplica-se desde 2 de fevereiro de 2025 a fornecedores e a utilizadores profissionais, com menção expressa às PME. Obriga a assegurar que quem opera o sistema tem conhecimento suficiente para o fazer de forma informada. Na prática: se a equipa usa um agente sem perceber o que ele pode e não pode fazer, a empresa está em falta.

O artigo 50.º, sobre transparência, aplica-se desde 2 de agosto de 2026. Se o cliente está a interagir com um sistema de IA, tem de ser informado disso, de forma clara e o mais tardar no primeiro contacto. Um agente que responde a emails de clientes sem o dizer não cumpre.

Uma nota de calendário, porque há confusão a este respeito: o pacote legislativo conhecido como Digital Omnibus, em vigor desde 27 de julho de 2026, adiou as obrigações dos sistemas de alto risco do anexo III de 2 de agosto de 2026 para 2 de dezembro de 2027. O que foi adiado foi isso. A transparência do artigo 50.º e a literacia do artigo 4.º não foram adiadas.

A decisão que tem de tomar

Não é se vai usar agentes de IA. É que autoridade lhes dá.

Escolha um processo — apenas um — e responda a três perguntas antes de escrever uma linha de configuração: que dados é que este agente precisa mesmo de ver, quais das ações que ele pode executar são irreversíveis, e o que acontece se o texto que ele lê tiver sido escrito por alguém com má intenção.

Se não conseguir responder às três, o problema não é de segurança informática. É de desenho do processo, e é aí que se resolve.

Qual é o processo em que confiaria num agente para fazer tudo, exceto o último clique?