Anonimização e NER por IA: o guia que separa anonimização, pseudonimização e RGPD (2026)
Quick Answer: o que é anonimização por IA e NER?
A anonimização e a pseudonimização por IA apoiam-se na técnica do NER (Named Entity Recognition, «reconhecimento de entidades nomeadas»: a capacidade de uma IA detetar automaticamente nomes, moradas, números, datas, organizações num texto). A IA identifica estes dados pessoais e substitui-os por marcadores ou pseudónimos.
Distinção RGPD crítica:
- Anonimização: transformação irreversível. O dado sai do âmbito do RGPD (Considerando 26). Muito difícil de alcançar tecnicamente — é preciso garantir que a pessoa não poderá ser reidentificada nunca, mesmo cruzando com outras fontes, mesmo se alguém recuperar a chave.
- Pseudonimização (artigo 4.º n.º 5 do RGPD): substituição reversível sob acesso restrito. O dado mantém-se pessoal nos termos do RGPD, mas o risco é reduzido.
A maioria dos projetos ditos «anonimização IA» produzem na realidade pseudonimização. É a primeira coisa a esclarecer: tudo o resto — base de licitude, AIPD, prazo de conservação, transferências para fora da UE — daí decorre.
Ferramentas 2026:
- Grandes modelos de linguagem (Mistral Large, GPT-4o, Claude): precisão 95-98 % em português padrão, simples de implementar via prompt, mas custo de inferência e dependência do fornecedor.
- Modelos NER dedicados (spaCy pt_core_news_lg, BERTimbau, GLiNER, Microsoft Presidio): mais rápidos, mais económicos em volume, mas taxonomia rígida.
- Para soberania: Mistral instalado on-premise ou Llama 3 auto-alojado + spaCy interno, zero saída de dados para os Estados Unidos — pertinente para SNS, registo de saúde eletrónico (RSE), escritórios de advogados e bancos supervisionados.
Casos de uso que se sustentam: preparação de corpus para fine-tuning interno, partilha com parceiros académicos sob contrato art. 28.º, resposta a pedido RGPD art. 15.º sem expor dados de terceiros, análise de gestão de corpus internos respeitando o Código do Trabalho, conformidade setorial (SNS, segredo médico, banca), preparação de documentos antes de chamar um LLM SaaS.
Porquê este tema, porquê agora
Muitas organizações portuguesas têm em mente: «enviar os nossos documentos a um LLM, mas sem os dados pessoais lá dentro». A ideia é sã. A promessa é raramente cumprida.
Três coisas mudaram em 2026. Uma, os LLMs modernos sabem fazer NER em português a sério — não era verdade em 2022. Duas, os modelos dedicados open-source (spaCy, GLiNER, BERTimbau) estão ao alcance de uma implantação soberana — não é preciso enviar uma única palavra à OpenAI para anonimizar uma única palavra. Três, a doutrina regulatória endureceu sobre o que verdadeiramente conta como «anonimização»: a CNPD e o EDPB recordam regularmente que pseudonimizar não é anonimizar (Parecer EDPB 28/2024).
A armadilha: acreditar que um detetor de nomes basta para «sair do RGPD». Não basta. Este artigo separa o que funciona, o que não funciona e onde traçar a fronteira entre IA, organização, EPD e máquina humana de validação.
Anonimização vs pseudonimização: a distinção que muda tudo
É a base. Tudo o resto — base de licitude, AIPD, contratos com subcontratantes, prazo de conservação — depende desta distinção.
Anonimização nos termos do RGPD
Para que um dado esteja verdadeiramente anonimizado, três condições devem ser cumpridas em simultâneo, conforme as Linhas Diretrizes do GT29 (acolhidas pelo EDPB) e as orientações da CNPD:
- Sem reidentificação direta — nomes, identificadores, NIF, números de utente do SNS, IBAN são eliminados ou transformados.
- Sem reidentificação indireta — nenhuma combinação de atributos permite isolar uma pessoa. Isso inclui os contextos singulares («o único diretor comercial que abandonou a ACME S.A. em março de 2025»).
- Sem reidentificação por cruzamento — mesmo combinando com a Conservatória do Registo Comercial, o cadastro eleitoral, uma exportação de LinkedIn ou um dataset aberto, a pessoa permanece indistinguível.
Se as três condições estiverem cumpridas, o dado sai do âmbito de aplicação do RGPD. É a promessa máxima.
Alcançar as três condições é tecnicamente muito difícil, particularmente em textos livres (e-mails, atas, contratos). Existem técnicas formais — k-anonimato, l-diversidade, t-proximidade — mas aplicam-se sobretudo a bases tabulares, não a texto livre.
Pseudonimização nos termos do RGPD
O artigo 4.º n.º 5 do RGPD define-a como «o tratamento de dados pessoais de forma que deixem de poder ser atribuídos a um titular dos dados específico sem recorrer a informações suplementares, desde que essas informações suplementares sejam mantidas separadamente e sujeitas a medidas técnicas e organizativas».
Em claro: substitui-se Maria Silva por Pessoa_001, e mantém-se uma tabela Pessoa_001 → Maria Silva noutro local, sob acesso muito restrito. A pseudonimização reduz fortemente o risco, mas o dado mantém-se pessoal nos termos do RGPD. Todas as obrigações se aplicam: registo de atividades, base de licitude, prazo de conservação, direitos dos titulares, AIPD se aplicável, contratos com subcontratantes.
Tabela rápida de decisão
| Critério | Anonimização | Pseudonimização |
|---|---|---|
| Ligação à pessoa | Destruída irremediavelmente | Conservada via chave separada |
| Sujeita ao RGPD? | Não | Sim |
| Viabilidade em texto livre | Muito difícil | Viável com NER + política |
| Caso de uso típico | Publicação de dataset aberto | Tratamento interno, partilha enquadrada |
| Risco residual | Quase nulo (se bem feita) | Baixo mas não nulo |
| Esforço de implementação | Elevado | Moderado |
Veredicto prático: a maioria dos projetos ditos «anonimização IA» são na realidade pseudonimização. Não é uma fraqueza, é um quadro claro. A armadilha consiste em prometer anonimização e entregar pseudonimização: a conformidade desmorona-se e o EPD descobre o problema seis meses depois — tipicamente durante uma fiscalização da CNPD.
O NER: o que faz, o que não faz
A mecânica
O NER (Named Entity Recognition) identifica num texto as entidades nomeadas pertencentes a categorias predefinidas. Uma taxonomia clássica adaptada ao contexto português:
| Categoria | Exemplo | Sensibilidade RGPD |
|---|---|---|
| PER — pessoa | Maria Silva, Sr. Costa | Identificador direto |
| ORG — organização | ACME S.A., Hospital de Santa Maria | Indireto (combinado com PER) |
| LOC — local | Lisboa, Avenida da Liberdade 24 | Indireto, por vezes direto (morada precisa) |
| DATE | 15 de março de 2026 | Indireto (datas de eventos pessoais) |
| EMAIL / PHONE / IBAN / NIF / SNS | maria@acme.pt, 21 234 56 78 | Identificadores diretos |
| MISC — diversos | Número de processo, referência interna | Variável |
Para a pseudonimização em empresas portuguesas, esta taxonomia é enriquecida com categorias de negócio: número de utente do SNS, identificador de cliente, número de processo, montantes sensíveis, identificadores de contrato, código postal (combinado com idade e género é altamente identificativo — o resultado de Sweeney sobre códigos ZIP americanos transpõe-se aos códigos postais portugueses). É este trabalho de tipificação de negócio que faz a diferença entre um NER genérico e uma pseudonimização utilizável.
Esquema simplificado da pipeline
[Texto fonte]
│
▼
[NER] → lista de entidades detetadas (tipo, valor, posição)
│
▼
[Política de substituição] → o que eliminar, o que pseudonimizar, o que manter
│
▼
[Geração de pseudónimos] → tabela «original → pseudónimo»
│ │
│ ▼
│ [Cofre seguro]
▼ (chave de reidentificação,
[Texto pseudonimizado] acesso muito restrito)O cofre é a peça crítica. Se qualquer pessoa puder aceder à tabela de correspondência, a pseudonimização desmorona-se. É um ponto de arquitetura, não um detalhe de implementação — a CNPD examinará exatamente este controlo durante uma fiscalização.
O que o NER não vê
O NER, mesmo excelente, falha em três famílias de dados identificativos:
1. Dados indiretamente identificativos por contexto. «O diretor comercial que abandonou a ACME S.A. em março de 2025 para um concorrente» — nenhum nome próprio na frase, mas só uma pessoa no mundo corresponde. O NER deteta «diretor comercial», «ACME S.A.», «março de 2025». Não compreende que a combinação é singular.
2. Combinações raras. «Mulher, 47 anos, engenheira agrónoma, residente em Bragança, mãe de gémeos» — nenhum elemento é identificativo isoladamente, o conjunto é-o fortemente. Nenhum NER deteta «combinação rara».
3. Referências implícitas internas. «Como combinámos ontem ao telefone, aqui vai o rascunho de carta para o cliente de quem falávamos» — o NER não vê nenhuma entidade identificável, e no entanto um humano que conhece o contexto sabe exatamente de quem se trata.
É por isso que a revisão humana sobre amostra continua obrigatória: 5 a 10 % do corpus no arranque, redutível a 1-2 % uma vez estabilizados os padrões. E é também por isso que combinamos sistematicamente o NER com uma política de reescrita contextual sobre os casos de alto risco: não substituímos apenas os nomes, neutralizamos também os contextos singulares.
As três abordagens técnicas (em linguagem clara)
Abordagem 1 — LLM genérico com instrução
Dá-se ao LLM uma instrução do tipo: «identifica neste texto todas as entidades nomeadas e devolve-as em forma estruturada, com o seu tipo e posição». Os modelos modernos (Mistral Large, GPT-4o, Claude) fazem-no muito bem em português padrão.
| Vantagens | Limites |
|---|---|
| Precisão elevada (95-98 % em português padrão) | Custo de inferência não trivial em volume |
| Gere o contexto (útil para casos ambíguos) | Latência (alguns segundos por documento) |
| Flexível: taxonomia adaptada via prompt | Dependência do fornecedor LLM |
| Sem curva de aprendizagem técnica | Possível saída para fornecedor estrangeiro se SaaS |
Quando é a escolha certa: protótipos, volumes baixos a médios (até algumas dezenas de milhares de documentos por mês), taxonomia evolutiva, equipa sem experiência em NLP.
Abordagem 2 — Modelo NER dedicado (open-source)
Modelo pré-treinado especializado: spaCy pt_core_news_lg, BERTimbau, GLiNER, Microsoft Presidio. Funciona em local, muito rápido, baixo custo.
| Vantagens | Limites |
|---|---|
| Muito rápido (milissegundos por documento) | Taxonomia rígida por defeito |
| Económico em volume | Desempenho variável conforme o domínio |
| Implantável on-premise, zero saída de dados | Setup mais técnico (Python, empacotamento de modelos) |
| Maduro (spaCy em produção desde 2015) | Compreensão fraca do contexto |
Quando é a escolha certa: volumes elevados (SNS, banca), latência crítica, exigência de soberania máxima, orçamento de inferência controlado.
Abordagem 3 — Híbrido
Modelo dedicado para deteção rápida sobre o grosso do fluxo + LLM genérico para casos complexos ou ambíguos + revisão humana sobre casos críticos.
| Vantagens | Limites |
|---|---|
| Ótimo custo / precisão em grandes volumes | Arquitetura mais complexa |
| Robusto sobre casos atípicos | Exige um orquestrador (LangChain, código à medida) |
| Compatível com soberania | Requer acompanhamento de métricas (taxa de fallback ao LLM) |
Quando é a escolha certa: produção estabilizada, grandes volumes, exigência de qualidade alta, equipa capaz de operar uma pipeline.
Árvore de decisão rápida
Volume mensal?
│
├── < 10.000 documentos
│ └── Latência crítica (tempo real)?
│ ├── Sim → NER dedicado (spaCy)
│ └── Não → LLM genérico
│
├── 10.000 – 1 milhão
│ └── Sensibilidade máxima (SNS, escritório)?
│ ├── Sim → Híbrido sobre stack soberana
│ └── Não → LLM genérico soberano (Mistral)
│
└── > 1 milhão
└── Híbrido obrigatório (economia de inferência + qualidade)Casos de uso que se sustentam
Sem catálogo exaustivo. Seis casos robustos, com o que é preciso saber antes de começar.
Caso 1 — Preparar um corpus para fine-tuning interno
Contexto: uma organização portuguesa quer adaptar um LLM open-source (Llama, Mistral) ao seu negócio. Dispõe de um corpus de atas internas, trocas de e-mail, documentação. Sem pseudonimização, estes dados arriscam-se a acabar nos pesos do modelo final e reaparecer através de um ataque dito membership inference («estava este documento no corpus de treino?»).
Volume tipo: 10.000 a 500.000 documentos.
O que pode falhar: pseudonimização incompleta sobre referências internas (números de processo, códigos de projeto) — estas referências não são vistas pelo NER mas permitem cruzamento interno.
Métrica de sucesso: taxa de reidentificação < 1 % sobre amostra manual pós-pseudonimização.
Caso 2 — Partilhar com um parceiro académico ou consultor
Contexto: um escritório de advogados português quer partilhar um corpus de contratos com um laboratório universitário para análise estatística. Um ator de saúde quer partilhar atas clínicas com um consultor de dados para uma auditoria de qualidade.
Volume tipo: alguns milhares de documentos.
O que pode falhar: subestimação dos dados indiretamente identificativos. Um contrato anonimizado nos nomes das partes pode manter-se identificável pelo número de processo, pelo tribunal competente, pela data de registo.
Salvaguarda: contrato de subcontratação (art. 28.º RGPD) com o parceiro, prazo de conservação limitado, destruição comprovável, auditoria possível. A pseudonimização por si só não substitui o contrato — e para dados do SNS, o acordo deve respeitar também a Lei 12/2005 sobre informação genética e de saúde.
Caso 3 — Responder a um pedido RGPD art. 15.º
Contexto: uma pessoa solicita acesso aos seus dados pessoais. Tem o direito de os receber — mas não de obter de passagem os dados de outras pessoas presentes nos mesmos documentos (e-mails, atas). NER + ocultação de terceiros torna a resposta conforme. A CNPD aplicou em vários processos coimas pela má gestão de pedidos de acesso (deliberações 2023-2025 com coimas de 5.000 a 100.000 €).
Volume tipo: variável, por vezes alguns documentos, por vezes várias centenas.
O que pode falhar: sobre-pseudonimização que torna o documento ininteligível e impede o requerente de compreender os seus próprios dados.
Salvaguarda: política clara sobre o que se oculta e o que se mantém, validação pelo EPD ou serviço jurídico antes do envio.
Caso 4 — Analisar um corpus interno sem cair em vigilância individual ilegal
Contexto: uma direção quer compreender os temas recorrentes nas trocas internas (e-mails, apoio ao cliente) sem ultrapassar a linha da vigilância individual ilegal nos termos do Código do Trabalho e da Lei 58/2019 art. 28.º (regras especiais para o tratamento de dados pessoais no contexto laboral). A pseudonimização de remetentes e destinatários permite uma análise agregada.
Volume tipo: 10.000 a 1 milhão de mensagens por mês.
O que pode falhar: a pseudonimização não basta se a análise revelar indiretamente o comportamento individual (volume de envio atípico, padrões horários únicos). É preciso também agregar antes da análise.
Salvaguarda: informação prévia aos representantes dos trabalhadores (Comissão de Trabalhadores), AIPD documentada, finalidade limitada, acesso restrito aos resultados.
Caso 5 — Conformidade setorial (SNS, segredo profissional médico, banca)
Contexto: um ator de saúde quer usar um LLM externo para analisar relatórios clínicos. Se o identificador do utente não for necessário à análise, a pseudonimização a montante permite enviar o conteúdo a um LLM menos restringido (Mistral Le Chat Enterprise) em vez de impor uma infraestrutura completa conforme à Lei 12/2005 e ao Regulamento do RSE (Registo de Saúde Eletrónico). O segredo médico (art. 87.º do Código Deontológico da Ordem dos Médicos) e a Lei 58/2019 continuam a aplicar-se — a pseudonimização não isenta a organização de documentar finalidade, necessidade e minimização. Veja o nosso guia IA conforme ao RGPD.
Salvaguarda: contrato de subcontratação com o fornecedor LLM, AIPD obrigatória, rastreabilidade de cada envio, conservação da versão original em ambiente conforme com as orientações da CNPD para o sector da saúde.
Caso 6 — Preparação contabilística e fluxos financeiros
Contexto: faturas sensíveis (faturas de fornecedores incluindo dados salariais, faturas de cuidados em seguros de saúde), notas de despesas detalhadas. Pseudonimização de dados de utentes ou trabalhadores antes do tratamento por um LLM SaaS para extração estruturada. Veja o nosso guia automação de faturas por IA.
Volume tipo: 10.000 a 500.000 documentos por mês conforme o tamanho da organização.
Arquitetura de referência: o que construímos concretamente
Uma pipeline de anonimização IA em produção decompõe-se em sete etapas. Cada uma tem as suas armadilhas.
Etapa 1 — Ingestão. O documento chega em formato bruto: PDF, Word, e-mail, exportação de base de dados, imagem digitalizada. Para documentos não textuais, OCR prévio (Tesseract, AWS Textract na região de Lisboa, Doctly). Nesta etapa conserva-se o original cifrado para auditoria.
Etapa 2 — Deteção NER. LLM ou modelo dedicado identifica as entidades. Saída: lista estruturada {tipo, valor, offset_início, offset_fim}. Para documentos longos segmenta-se em blocos de alguns milhares de caracteres com sobreposição (chunking); caso contrário os modelos perdem entidades nas fronteiras.
Etapa 3 — Política de substituição. Decisão de negócio, não técnica:
- Categorias a eliminar (remoção limpa, p. ex. números de cartão em e-mails)
- Categorias a pseudonimizar (substituição por identificador pseudónimo estável, p. ex. nomes de pessoas)
- Categorias a manter (úteis para o uso a jusante, p. ex. datas se servirem para análise temporal)
Etapa 4 — Geração de pseudónimos. Maria Silva → Pessoa_001. O pseudónimo deve ser estável (a mesma pessoa recebe o mesmo pseudónimo em todos os documentos) e não correlacionado ao valor original (sem hash do valor — um hash é atacável por dicionário se o domínio for pequeno). A tabela de correspondência guarda-se em cofre separado.
Etapa 5 — Aplicação ao texto. Substituição efetiva. Atenção às fronteiras de palavra, maiúsculas/minúsculas, acentos, variantes ortográficas. Uma Maria Silva pode aparecer mais à frente como Sra. Silva, D. Maria, M. Silva — o NER deve ligar estas formas (resolução de correferência).
Etapa 6 — Validação. Revisão humana sobre amostra (5 a 10 % no arranque, redutível a 1-2 % após estabilização). Medimos:
- Taxa de entidades omitidas (recall)
- Taxa de deteções falsas (precisão)
- Presença de dados indiretamente identificativos residuais
Etapa 7 — Auditoria e logs. Conservação separada:
- Documento original cifrado (em caso de litígio, pedido RGPD art. 15.º, auditoria)
- Documento pseudonimizado (para uso a jusante)
- Tabela de correspondência (cofre, acesso muito restrito)
- Logs de acesso (quem viu o quê, quando)
Esquema de produção simplificado
[Fonte] [Tratamento] [Destinos]
│ │ │
▼ ▼ ▼
PDF / e-mail ──► OCR ──► NER ──► Política ──► Pseudo. ──► LLM SaaS / fine-tune / partilha
│ │
└─► Auditoria ──┘
│
▼
Cofre da chave (acesso estrito)
Original cifrado (RSE se SNS)A armadilha da reidentificação
É o teste último. Uma pseudonimização que não resista a ataques por cruzamento não é pseudonimização utilizável — e a CNPD dirá isso durante uma fiscalização.
Três ataques clássicos
Ataque 1 — Cruzamento com fonte aberta. O atacante dispõe da Conservatória do Registo Comercial, do cadastro eleitoral, de uma exportação de LinkedIn. Cruza os atributos restantes no documento pseudonimizado (idade, cidade, profissão, empregador) com estas fontes. Se uma combinação for única, a reidentificação tem êxito. O famoso estudo Sweeney (1997) mostrou que 87 % dos indivíduos americanos são univocamente identificáveis por código ZIP + data de nascimento + género — os códigos postais portugueses dão resultados semelhantes.
Ataque 2 — Inferência por contexto. O atacante conhece o domínio. Sabe que apenas um diretor comercial abandonou a ACME S.A. em março de 2025. Deduz a identidade.
Ataque 3 — Membership inference (sobre LLM afinado). Um atacante interroga um modelo afinado sobre um corpus pseudonimizado para adivinhar se tal ou tal indivíduo estava no corpus. Se o modelo se sobreajustou, revela informação. O trabalho de Carlini et al. (2023) sobre ataques de extração contra GPT-2 colocou o tema nos conselhos de administração.
Três defesas
Defesa 1 — k-anonimato (para bases tabulares). Cada combinação de atributos aparece pelo menos k vezes no dataset. Se k = 5, cada perfil é indistinguível de pelo menos outros 4. Sobre texto livre, transposição parcial via generalização: «47 anos» → «40-50 anos», «engenheira agrónoma em Bragança» → «quadro no norte de Portugal».
Defesa 2 — l-diversidade e t-proximidade. Extensões do k-anonimato que também restringem a diversidade dos valores sensíveis em cada grupo. Útil quando os dados sensíveis (saúde, opinião) estão no centro do dataset.
Defesa 3 — Testes de reidentificação. Mais pragmática: tenta-se ativamente reidentificar sobre uma amostra. Se se consegue demasiado facilmente, a pseudonimização é insuficiente. Esta prática é esperada pela CNPD para projetos sensíveis nas suas orientações.
Nenhuma das três protege totalmente. Regra prática: testar explicitamente a robustez antes da entrada em produção e documentar os testes.
Conformidade RGPD: o que é verdadeiramente esperado
A anonimização/pseudonimização por IA é em si mesma um tratamento automatizado de dados pessoais. Logo sujeita ao RGPD. Eis o que se inscreve e o que se deve poder produzir em caso de fiscalização.
No registo das atividades de tratamento (art. 30.º RGPD)
Uma ficha dedicada: «pseudonimização automatizada por NER para [finalidade precisa]». Inscreve-se:
- Finalidade (p. ex. preparar corpus para fine-tuning, partilhar com parceiro X, analisar e-mails internos)
- Categorias de dados tratados (texto livre, tipos de entidades detetadas)
- Pessoas afetadas (clientes, trabalhadores, utentes conforme o caso)
- Prazo de conservação (do original, da versão pseudonimizada, da tabela de correspondência — cada um justificado)
- Subcontratantes (fornecedor LLM, alojamento)
- Medidas técnicas e organizativas
Base de licitude
Conforme o contexto:
- Interesse legítimo (art. 6.º n.º 1 alínea f) RGPD): caso mais frequente para tratamentos internos, com a condição de documentar o teste de ponderação (interesse prosseguido vs direitos das pessoas).
- Execução de um contrato: se o tratamento decorre diretamente da execução de um contrato com a pessoa.
- Obrigação legal: rara, mas possível (resposta a pedido RGPD art. 15.º, por exemplo).
- Consentimento: excecionalmente, e a evitar se outra base for mobilizável — o consentimento pode ser retirado.
AIPD (avaliação de impacto sobre a proteção de dados)
Recomendada na maioria dos casos, obrigatória em vários cenários listados pela CNPD:
- Volumes elevados
- Dados sensíveis (saúde, opiniões políticas, biométricos, judiciais)
- Tratamento em larga escala
- Vigilância sistemática de trabalhadores
- Cruzamento de fontes
A AIPD documenta o risco residual após pseudonimização, justifica as escolhas técnicas e formaliza o controlo de acesso à chave. É mantida à disposição da CNPD em caso de fiscalização. Veja o nosso guia AIPD para projetos IA.
Contrato de subcontratação com o fornecedor LLM
Se utiliza um LLM SaaS, o contrato de subcontratação (art. 28.º RGPD) deve prever:
- Localização do tratamento (idealmente UE — Mistral, Scaleway, Claranet Portugal)
- Proibição de utilizar os dados para treinar o modelo
- Prazo de conservação de prompts e completações
- Sub-subcontratantes (alojamento, cópias de segurança)
- Modalidades de notificação de incidente
Com um fornecedor soberano europeu, o contrato é claramente mais simples. Com um fornecedor americano, torna-se um dossier técnico à parte (cláusulas contratuais-tipo, transfer impact assessment pós-Schrems II, por vezes inutilizável conforme a natureza dos dados — particularmente para dados do SNS ou bancários supervisionados pelo Banco de Portugal).
Localização do tratamento
Para dados sensíveis (SNS, segredo médico, dados bancários sob supervisão do Banco de Portugal, dados salariais), a localização é um tema em si mesmo. Três níveis:
- Cloud soberana (Scaleway, OVHcloud, Claranet Portugal, Altice Cloud, NOS, Imatech) — os dados permanecem na UE, sob direito europeu, sem risco de apreensão ao abrigo do Cloud Act americano.
- On-premise — a IA funciona nos servidores da organização, zero saída de dados. Veja o nosso guia LLM local na empresa.
- Cloud estrangeira com enquadramento contratual — possível mas com carga documental considerável e risco residual não nulo. O EU-US Data Privacy Framework ajuda em alguns fluxos mas não cobre todos os casos.
Para a maioria dos casos sensíveis em Portugal, mantém-se ou um fornecedor soberano (Mistral La Plateforme), ou on-premise. É a abordagem que a DPLIANCE adota para os seus clientes, no quadro de soluções IA à medida.
O que recusamos prometer
Três antipadrões que vemos regularmente em projetos e que evitamos na DPLIANCE.
«Vamos anonimizar, logo saímos do RGPD.» Não, salvo caso muito excecional. A pseudonimização permanece sob RGPD. Se a promessa de saída do RGPD for necessária ao projeto, é preciso redesenhar o projeto — não torcer o sentido das palavras. As orientações da CNPD são explícitas sobre isto.
«O NER deteta tudo, não precisamos de revisão humana.» Nenhum NER deteta os contextos singulares, as combinações raras, as referências implícitas. A revisão humana sobre amostra é não negociável no arranque e mantém-se recomendada em regime estável.
«Mantemos a chave de reidentificação, mas trancamo-la bem.» Se a chave permanece acessível a várias pessoas, a pseudonimização torna-se teórica. A prática RGPD espera um acesso muito restrito, registado, com um processo de recuperação excecional e rastreado.
FAQ
Qual é a diferença concreta entre anonimização e pseudonimização à luz do RGPD?
A anonimização é irreversível: torna-se impossível reidentificar a pessoa, mesmo cruzando com outras fontes, mesmo com uma chave. O dado sai do âmbito do RGPD e da Lei 58/2019 (Considerando 26). A pseudonimização, definida no artigo 4.º n.º 5 do RGPD, é reversível: um identificador pseudónimo substitui os identificadores diretos, mas existe uma chave de reidentificação noutro local sob acesso restrito. O dado mantém-se pessoal nos termos do RGPD. Consequência prática: a maioria dos projetos ditos «anonimização IA» produzem na realidade pseudonimização. As obrigações do RGPD continuam a aplicar-se (registo de atividades, base de licitude, AIPD se necessária), mesmo se o risco baixou.
Basta o NER (reconhecimento de entidades nomeadas) para anonimizar um texto?
Não, quase nunca. O NER deteta as entidades nomeadas explícitas: nomes, apelidos, números de telefone, moradas, IBAN, NIF, número de utente do SNS, datas. Falha sistematicamente nos dados indiretamente identificativos: descrições precisas («o diretor comercial que abandonou a ACME S.A. em março de 2025»), combinações singulares (idade + cidade + profissão), referências internas (número de processo correlacionado com um cliente), formulações contextuais. Uma anonimização rigorosa exige NER + análise contextual + revisão humana sobre os casos críticos + testes de robustez face à reidentificação — exatamente o que a CNPD espera nas suas orientações sobre técnicas de anonimização.
Que precisão se espera de um NER IA em 2026 sobre português?
Em português europeu padrão, um LLM moderno (Mistral Large, GPT-4o, Claude, BERTimbau) deteta entre 95 e 98 % das entidades nomeadas explícitas com um prompt bem construído. Os modelos dedicados (spaCy pt_core_news_lg, BERTimbau da NeuralMind, GLiNER multilingue) atingem entre 92 e 99 % de F1 conforme o domínio. O desempenho cai fortemente em: nomes estrangeiros ou raros, línguas mistas (português europeu vs brasileiro, mirandês), abreviaturas setoriais, referências implícitas dentro do texto. Nenhum modelo atinge 100 % — é por isso que a revisão humana sobre amostra continua indispensável no arranque.
LLM genérico ou modelo NER dedicado?
Para a maioria dos casos em 2026, um LLM genérico bem promptado (Mistral, GPT-4o, Claude) basta com precisão superior a 95 %. O modelo NER dedicado (spaCy pt_core_news_lg, BERTimbau, modelo afinado) torna-se pertinente quando o volume é muito elevado (milhões de documentos por mês), quando a latência é crítica (triagem em tempo real no SNS ou em bancos supervisionados pelo Banco de Portugal), ou quando o contexto é ultra-especializado (terminologia clínica, jurídica). Regra simples: começar com LLM genérico para o protótipo, passar para dedicado se o custo de inferência ou o desempenho o justificarem.
Um dado pseudonimizado por NER mantém-se sujeito ao RGPD?
Sim. O RGPD considera um dado como pessoal enquanto a reidentificação for possível — diretamente, indiretamente, por cruzamento com outras fontes ou através da chave de pseudonimização. A pseudonimização reduz o risco mas não retira o dado do âmbito do RGPD. Para alcançar uma verdadeira anonimização nos termos do RGPD, é preciso destruir a chave, eliminar os dados indiretamente identificativos e resistir a ataques por cruzamento. É tecnicamente muito difícil — a CNPD recorda-o explicitamente nas suas deliberações.
Que casos de uso se sustentam realmente em empresas portuguesas?
Seis casos robustos: (1) preparar um corpus para fine-tuning de um modelo interno sem risco de fuga; (2) partilhar um dataset com um consultor ou parceiro académico através de contrato de subcontratação (art. 28.º RGPD); (3) responder a um pedido de acesso (art. 15.º RGPD) sem expor dados de terceiros; (4) analisar corpus internos (e-mails, atas) para fins de gestão sem ultrapassar a linha da vigilância individual ilegal nos termos do Código do Trabalho e da Lei 58/2019 art. 28.º; (5) conformidade setorial (SNS, segredo profissional médico nos termos do Código Deontológico da Ordem dos Médicos, banca conforme Banco de Portugal); (6) preparação de documentos antes de chamar um LLM SaaS para reduzir a exposição.
Que ferramentas permitem anonimização IA soberana em 2026?
LLMs genéricos soberanos: Mistral Large via La Plateforme (França), Mistral on-premise via vLLM, alojamento em fornecedores portugueses (Claranet Portugal, Altice Cloud, NOS, Imatech). Modelos dedicados open-source: spaCy pt_core_news_lg (excelente relação desempenho/custo para português), BERTimbau da NeuralMind (BERT português pré-treinado), GLiNER multilingue. O Microsoft Presidio é uma excelente framework open-source mas a inferência por defeito passa pela OpenAI — a redirecionar para fornecedor soberano ou local. Para máxima soberania: Mistral on-prem ou Llama 3 auto-alojado + spaCy interno, zero saída de dados.
É preciso uma AIPD para um projeto de anonimização IA?
Recomendada na maioria dos casos, obrigatória em vários: volumes elevados, dados sensíveis (saúde, opiniões, biometria nos termos do art. 9.º RGPD), tratamento em larga escala, vigilância sistemática de trabalhadores, cruzamento de fontes. A lógica: a anonimização IA é em si mesma um tratamento automatizado de dados pessoais, logo sujeita ao RGPD. A AIPD documenta o risco residual após pseudonimização, justifica as escolhas técnicas e formaliza o controlo de acesso à chave de reidentificação. A CNPD publica a lista indicativa de tratamentos sujeitos a AIPD em cnpd.pt.
Fontes: Regulamento (UE) 2016/679 (RGPD), em particular art. 4.º n.º 5 e Considerando 26; Lei 58/2019 (execução do RGPD na ordem jurídica portuguesa); Lei 12/2005 sobre informação genética e de saúde; Linhas Diretrizes do GT29 sobre técnicas de anonimização (acolhidas pelo EDPB); Parecer EDPB 28/2024 sobre aspetos de proteção de dados em modelos IA; CNPD, deliberações e orientações sobre anonimização, sobre o RSE, sobre a videovigilância e o tratamento de dados no contexto laboral; Código Deontológico da Ordem dos Médicos (segredo profissional); documentação oficial spaCy, Microsoft Presidio, GLiNER, BERTimbau (NeuralMind); documentação Mistral AI La Plateforme.
Para enquadrar um projeto de anonimização por IA na sua organização — escolha de ferramenta, metodologia, pipeline, conformidade — veja o nosso guia IA conforme ao RGPD, o nosso guia AIPD para projetos IA, o nosso guia LLM local na empresa, ou contacte-nos através das nossas soluções IA à medida.