By · Last updated 2026-06-02

Voltar ao BlogSegurança de IA

Construindo uma IA de Suporte ao Cliente em...

A IA de suporte ao cliente recebe mensagens de clientes com nomes, e-mails E IDs de pedidos.

June 2, 20267 min de leitura
customer support AIGDPR AI complianceorder ID detectionIntercom GDPRZendesk privacyAI vendor data

RGPD e IA de Suporte: Identificadores Personalizados Importam

A sua equipe de suporte usa IA para redigir respostas e revisar tickets. A produtividade aumenta. Então o seu DPO analisa a configuração.

Uma mensagem típica de cliente contém um nome, um endereço de e-mail e um número de pedido. O nome e o e-mail são dados pessoais. O número de pedido também é. Ele vincula Sarah Johnson à sua base de dados de pedidos. Um fornecedor de IA pode cruzar essa informação. Se dados de treinamento vazarem, o identificador pode reidentificá-la.

Enviar qualquer um desses dados a um fornecedor externo de IA sem base legal é uma violação do RGPD.

Por que Números de Pedido São Dados Pessoais

O artigo 4.º do RGPD define dados pessoais de forma ampla. O termo abrange toda informação relativa a uma pessoa identificada ou identificável. A identificabilidade inclui a identificação indireta por referência a um identificador.

Um número de pedido como ORD-4521893 é um identificador indireto. Sozinho, não identifica Sarah Johnson. Combinado com a sua base de dados de pedidos, sim.

O artigo 4.º(5) do RGPD trata da pseudonimização. Números de pedido são pseudónimos. Precisam de uma fonte adicional para revelar a pessoa por trás deles. Ao enviar um número de pedido a um fornecedor externo de IA, está a partilhar dados pessoais. Uma base legal e um contrato de tratamento de dados são necessários.

O fornecedor pode não ter a sua base de dados. Isso não encerra a sua obrigação. Partilhou dados pessoais. O RGPD aplica-se igualmente.

A Lacuna nas Ferramentas de Anonimização Standard

As equipas de suporte frequentemente usam deteção de PII para cumprir o RGPD. As ferramentas standard removem tipos de entidades comuns.

A deteção standard identifica nomes de clientes, endereços de e-mail, números de telefone e números de cartão de crédito. Estes são processados corretamente.

A deteção standard não identifica números de pedido no formato ORD-XXXXXXX. Também não deteta números de conta, referências de tickets, identificadores de utilizador internos nem identificadores de subscrição. Aqui está a lacuna.

O resultado é assim: «Hi, I'm [PERSON_1] and my order ORD-4521893 hasn't arrived yet. Please email me at [EMAIL_1]

O número de pedido ainda está lá. Qualquer pessoa com acesso ao CRM pode encontrar Sarah Johnson de imediato. A anonimização está incompleta. Este é o problema de conformidade.

Extensão Chrome: Deteção no Navegador

Os agentes de suporte que usam Claude, ChatGPT ou Gemini trabalham no seu navegador. A extensão Chrome impede que identificadores personalizados saiam do navegador.

Veja como funciona. O agente cola uma mensagem de cliente na ferramenta de IA. A extensão deteta que o destino é uma plataforma de IA. Remove os PII standard. Depois aplica padrões personalizados. Estes correspondem ao formato dos seus números de pedido, ao formato dos seus números de conta e a qualquer outro identificador usado pela sua equipa. O agente vê apenas a mensagem limpa. Os dados em bruto nunca chegam à IA.

A equipa de conformidade define os padrões personalizados uma vez. Partilha uma predefinição com todos os agentes. Os agentes não precisam de gerir isso. Colam a mensagem. A extensão trata do resto.

Servidor MCP: Deteção na Camada de API

Algumas plataformas chamam a IA através de APIs. O Intercom usa IA para redigir respostas. O Zendesk usa IA para sugerir respostas. O servidor MCP adiciona anonimização na camada de API para estas configurações.

Veja o fluxo. Uma mensagem de cliente chega à plataforma de suporte. Passa pelo endpoint MCP antes de chegar à IA. O endpoint remove entidades standard e personalizadas. A mensagem limpa vai para a IA. A IA devolve uma resposta. Nenhum dado pessoal foi exposto. O agente lê e edita a resposta na plataforma de suporte.

Os agentes não notam qualquer mudança no seu trabalho. O processo é o mesmo. As entidades personalizadas são definidas uma vez na configuração MCP. Todas as chamadas de API usam a deteção completa de entidades a partir desse momento.

Lista de Verificação para o DPO

1. Mapear todos os fluxos de dados para a IA.

Listar onde os agentes usam IA. Incluir ferramentas de navegador, ferramentas baseadas em API e carregamentos de ficheiros.

2. Listar todos os tipos de identificadores nas mensagens de clientes.

PII standard — nomes, e-mails, telefones — está coberto pela deteção predefinida. Identificadores personalizados — números de pedido, referências de tickets, números de conta — precisam de padrões personalizados.

3. Adicionar padrões de entidades personalizadas.

Definir cada formato. Testá-lo em mensagens de exemplo. Guardá-lo na predefinição da equipa.

4. Implementar na camada correta.

IA no navegador: extensão Chrome com predefinição partilhada. IA integrada por API: servidor MCP ou pré-processamento na camada de API.

5. Atualizar o seu registo de atividades de tratamento.

Registar que a IA de suporte usa anonimização automatizada. Listar os tipos de identificadores personalizados cobertos. Esta é a sua documentação de medida de proteção técnica.

6. Testar a configuração.

Enviar mensagens de teste com todos os tipos de identificadores. Verificar que nada chega à IA. Consulte o guia de conformidade legal para modelos de documentos.

Equipa de Suporte SaaS: Um Exemplo Prático

Uma equipa de suporte SaaS usa Claude através de uma plataforma de IA interna. As mensagens de clientes incluem nomes, e-mails, números de pedido e identificadores de subscrição. Alguns nomes de feature flags também contêm identificadores internos.

Antes da revisão do RGPD: Todo o conteúdo ia para a IA. Números de pedido e de subscrição estavam incluídos.

Após a ativação da deteção de entidades personalizadas:

ORD-XXXXXXX e SUB-XXXXXXXX foram adicionados como entidades personalizadas. A extensão Chrome foi implementada com uma predefinição de equipa partilhada. O DPO realizou testes e confirmou que todos os identificadores eram removidos antes do processamento pela IA.

Mudança no fluxo de trabalho dos agentes: Nenhuma. Os agentes trabalham da mesma forma. A anonimização corre em segundo plano. O DPO tem uma medida de proteção documentada.

Conclusão

Uma IA de suporte conforme com o RGPD faz mais do que remover nomes e e-mails. Números de pedido, números de conta e referências de tickets são dados pessoais. As ferramentas standard não os detetam. A configuração de entidades personalizadas fecha a lacuna.

Os passos são simples. Definir os seus formatos de identificadores. Testá-los em mensagens de exemplo. Implementá-los na equipa. Um DPO pode fazer isto numa tarde. Depois disso, todos os dados de clientes são removidos antes de chegarem a sistemas de IA externos. O benefício de conformidade mantém-se permanentemente.

Fontes

Pronto para proteger seus dados?

Comece a anonimizar PII com mais de 285 tipos de entidades em 48 idiomas.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.