Agente de IA em conformidade com GDPR: guia 2026

As investigações de GDPR relacionadas com IA aumentaram 340% entre 2024 e 2026, e a Lei de IA da UE começa a aplicar as obrigações de alto risco do Anexo III em 2 de agosto de 2026, com multas a chegarem aos 15 milhões de euros ou 3% do faturamento global. Os dois marcos agora aplicam-se simultaneamente a qualquer pessoa que opere um agente de IA que toque dados pessoais da UE, e não há isenção para "somos pequenos" ou "é só um projeto interno da equipa".

É por isso que muitas empresas europeias estão a reconstruir discretamente as ferramentas de IA que usavam no ano passado. A pilha de fornecedores mudou debaixo dos seus pés: o que em 2024 era uma única conta da OpenAI agora é um responsável pelo tratamento, um subcontratante, uma cadeia de subsubcontratantes, um mapa de fluxo de dados e uma Avaliação de Impacto sobre a Proteção de Dados que tem mesmo de existir antes do agente ir para produção.

Este artigo é a versão prática e agnóstica em relação a fornecedor desse reconstruir. Cobrimos o que o GDPR e a Lei de IA da UE realmente exigem de um agente de IA em 2026, porque é que "região UE" sobre uma cloud norte-americana não chega, as decisões de arquitetura que te mantêm do lado certo da linha, e onde encaixa um agente auto-hospedado como o Hermes.

O que "em conformidade com GDPR" realmente significa para um agente

O GDPR foi escrito para sistemas onde um humano introduz dados e uma máquina os processa de forma previsível. Os agentes de IA são mais confusos. O mesmo agente lê a tua caixa de entrada, chama uma API de modelo, escreve num armazém vetorial, executa uma tarefa agendada e publica no Telegram. Cada passo é uma atividade de tratamento distinta com a sua própria base jurídica.

As exigências não mudaram: simplesmente mordem mais quando o sistema é autónomo.

Artigo 5.º (minimização dos dados): o agente só deve recolher e conservar o necessário. O histórico indefinido de transcrições completas "para analítica ou treino" é a bandeira vermelha mais comum.
Artigo 6.º (base jurídica): cada passo de tratamento precisa de uma. O interesse legítimo não é um passe livre quando o dado é sensível ou o utilizador não foi informado.
Artigo 22.º (decisões automatizadas): se o agente toma decisões que afetam significativamente uma pessoa - aprovar um reembolso, pontuar um CV, escalar um caso de suporte - o utilizador tem direito a revisão humana.
Artigo 25.º (proteção de dados desde a conceção): os controlos de privacidade têm de estar na arquitetura desde o início, não aparafusados depois de uma queixa.
Artigo 30.º (registo das atividades de tratamento): precisas de um inventário documentado dos dados pessoais, onde estão, quem acede e quanto tempo os manténs.
Artigo 17.º (direito ao apagamento): quando um utilizador pede para ser esquecido, tens de o apagar: do registo de conversas, do armazém vetorial, da memória do agente e de qualquer saída de ferramenta que tenha capturado os seus dados.

Os Artigos 22.º e 25.º são os dois mais citados na nova vaga de processos sancionatórios. Também são os dois que apanham desprevenidos os agentes de IA alojados como serviço, porque a plataforma decide a arquitetura e tu herdas o que eles enviaram.

A camada da Lei de IA da UE por cima

O GDPR regula os dados pessoais. A Lei de IA da UE regula o próprio sistema de IA. A partir de agosto de 2026, os fornecedores e implementadores de sistemas de "alto risco" - que incluem muitos casos de uso de RH, crédito, educação e infraestruturas críticas - têm de demonstrar três coisas:

Governança: políticas documentadas, supervisão humana, um processo real de gestão de risco.
Auditabilidade: registos por pedido que mostrem o que o agente executou, quando e sobre que dados.
Residência de dados: prova de que os dados pessoais e regulados ficaram nas jurisdições que a lei exige.

Os dois marcos não se substituem. Empilham-se. Quando a Lei de IA estiver plenamente aplicável em dezembro de 2027, um agente que toque dados pessoais da UE tem de satisfazer ambos, e um único registo em falta pode deixar todo o pipeline fora de conformidade.

Foto escura fotorrealista de um pequeno rack de servidores numa sala mal iluminada com um único LED verde de estado a iluminar os cabos, sugerindo uma infraestrutura auto-hospedada silenciosa

Porque é que "região UE" não chega

O mal-entendido mais caro de 2026 é tratar "região UE" num hyperscaler dos EUA como uma solução de residência. Não é.

A CLOUD Act dos EUA permite às autoridades norte-americanas obrigar empresas com sede nos EUA a entregar dados armazenados em qualquer parte do mundo, incluindo centros de dados europeus. Se o teu fornecedor de modelo, a tua base de dados vetorial ou o teu host do agente é uma entidade legal dos EUA, os teus dados estão sujeitos à jurisdição norte-americana independentemente da localização física do servidor. O Capítulo V do GDPR sobre transferências internacionais não olha para onde está o disco: olha para quem controla o acesso.

Isso tem consequências reais para o desenho do agente de IA. Chamar uma API de modelo com sede nos EUA a partir da UE é uma transferência internacional de dados pessoais no momento da inferência, mesmo que todas as outras camadas sejam europeias. A multa de 15 milhões de euros do Garante italiano à OpenAI em 2024 foi parcialmente sobre exatamente este tipo de transferência não anunciada.

Há três respostas práticas:

Usar um fornecedor de modelo com sede na UE (Mistral, Aleph Alpha, modelos open-weight alojados na OVHcloud). As transferências ficam dentro do EEE e não são precisas Cláusulas Contratuais Tipo.
Auto-hospedar o modelo em infraestrutura da UE (Llama, Mistral, Qwen via Ollama ou vLLM). Nenhuma transferência acontece: a inferência corre em hardware que controlas.
Usar um fornecedor norte-americano com um Acordo de Tratamento de Dados assinado e documentar o mecanismo de transferência. Possível, mas o trabalho de papelada é máximo e a base jurídica é a mais frágil se o utilizador não tiver sido informado.

A escolha depende da sensibilidade do dado e do orçamento. Para agentes virados ao consumidor que lidam com dados de contacto comuns, um fornecedor dos EUA suportado por um DPA pode ser defensável. Para agentes que tocam dados de saúde, financeiros ou de RH, a segunda opção é cada vez mais o padrão seguro.

A arquitetura de agente auto-hospedado que aguenta

Auto-hospedar o runtime ajuda muito, mas por si só não resolve a residência no momento da inferência. Uma arquitetura defensável em 2026 combina várias camadas.

Um runtime auto-hospedado em infraestrutura UE (Hetzner, OVHcloud, Scaleway, o teu próprio hardware). O processo do agente, os registos de conversação, o armazém vetorial e os ficheiros de skills vivem em discos que controlas.
BYOK sobre o fornecedor de modelo para que escolhas onde a inferência acontece. Bring Your Own Key mantém transparente a fatura do modelo, o fluxo de dados e a escolha do fornecedor.
Segredos cifrados em repouso para chaves API, tokens OAuth e credenciais de mensageria. Cifra ao nível do disco não chega: cifra ao nível da aplicação com uma chave que a plataforma anfitriã nunca vê é o padrão.
Allowlists restritas em cada superfície de mensageria (Telegram, Slack, Signal, email). Agentes que respondem a qualquer um com o nome do bot são o vetor de incidente GDPR mais comum para quem auto-hospeda.
Uma política de retenção documentada com tarefas de eliminação realmente a correr. "Apagamos a pedido" não chega se não conseguires mostrar o rasto de auditoria pedido-para-eliminação.
Logs estruturados por pedido que capturem o que o agente fez, mas redijam os dados pessoais dentro dos prompts. As novas stacks de logging estruturado tornam isto prático sem teres de escrever a tua.

Este é o padrão de arquitetura que o Artigo 25.º do GDPR ("proteção de dados desde a conceção") espera que consigas desenhar num quadro. Também é o padrão que sobrevive a uma Avaliação de Impacto sobre a Proteção de Dados sem meses de remediação a seguir.

Onde encaixam o Hermes e o Hermify

O Hermes Agent é uma opção que se alinha com a arquitetura acima logo à saída da caixa. Tem licença MIT, corre em Docker em qualquer VPS da UE, BYOK sobre o fornecedor de modelo para que escolhas onde a inferência acontece, cifra as chaves API em repouso e traz controlos de allowlist por mensageiro (SLACK_ALLOWED_USERS, SIGNAL_ALLOWED_USERS, EMAIL_ALLOWED_USERS). O registo de conversação, o armazém vetorial e a memória persistente do agente vivem todos em HERMES_HOME no host que escolheste, o que significa que a residência de dados é uma decisão de implantação, não uma decisão de fornecedor.

O enquadramento honesto: Hermes auto-hospedado mais BYOK suporta uma arquitetura defensável sob o GDPR, mas não é uma certificação. Continuas a ser o responsável pelo tratamento. Continuas a precisar da AIPD, da política de retenção, da tarefa de eliminação e dos registos do Artigo 30.º. O que muda é que a camada técnica deixa de te combater.

Para empresas europeias que querem a mesma configuração sem operar infraestrutura, o Hermify hospeda o Hermes em VPS de região UE, assina um DPA para a camada de runtime e mantém as tuas chaves de fornecedor cifradas com uma chave que a plataforma não consegue ler. O fornecedor do modelo continua a ser a tua escolha e a tua responsabilidade: essa é a parte BYOK, e é a camada onde a residência é decidida.

Foto cinematográfica escura de uma secretária de madeira com um portátil aberto num visualizador de logs estruturados com suaves destaques verdes e um caderno de papel com marcas escritas à mão ao lado, sugerindo uma auditoria manual cuidadosa de um agente de IA

Uma lista curta de conformidade

Uma lista curta e prática para levar a uma conversa de AIPD:

Mapeia cada lugar onde vivem dados pessoais dentro do agente: registo de conversação, armazém vetorial, ficheiros de skills, saídas de ferramentas, arquivos de mensagens.
Escolhe o fornecedor de modelo com os olhos abertos quanto à jurisdição. UE ou auto-hospedado é o caminho mais fácil.
Assina DPAs com cada subcontratante e subsubcontratante da cadeia.
Implementa eliminação real, não apenas uma flag, e prova-a com um rasto de auditoria.
Fecha as superfícies de mensageria com allowlists explícitas e roda os tokens do bot.
Loga por pedido, redige no momento do log e mantém os logs só o tempo necessário.
Acrescenta um passo humano-no-circuito sempre que o agente tome uma decisão ao abrigo do Artigo 22.º.
Documenta tudo. Os registos do Artigo 30.º são o seguro mais barato contra uma conclusão de "não consegues provar o que o teu agente fez".

O padrão de 2026

Há cinco anos, "IA em conformidade com GDPR" soava a uma preocupação europeia de nicho. Em 2026 é a pergunta de arquitetura que decide se consegues vender a empresas grandes, fazer um piloto do setor público ou aceitar um único cliente da UE sem reconstruir no próximo trimestre. As respostas técnicas - runtime auto-hospedado, BYOK, residência UE na camada que importa, segredos cifrados, allowlists, eliminação real - já não são exóticas. São o padrão. Os fornecedores que não construíram para isto são os que estão a ser reconstruídos à volta.

Se preferes saltar o trabalho de infraestrutura e partir de uma linha de base endurecida, começar com o Hermify demora uns minutos e deixa-te na arquitetura acima. Se preferes operar toda a pilha sozinho, os mesmos padrões aplicam-se: o resto do trabalho é teu, mas o agente não tem de ser a parte que te combate.