O seu agente de IA sabe demasiado sobre os seus clientes
Num alerta publicado em 9 de maio de 2025, a CNPD deu conta de um anúncio específico da Meta sobre o uso de determinados dados para treinar IA e apontou para os mecanismos de oposição disponibilizados pela empresa; esse alerta não criou uma regra geral para todos os agentes ou fluxos de WhatsApp. Para quem constrói agentes em Portugal, minimização e pseudonimização são medidas de arquitetura que podem reduzir a exposição antes de o contexto chegar ao modelo, mas não são garantias nem substituem a avaliação das obrigações do RGPD.
Por Reynier RiveroEngenheiro de software
Imagine este cenário hipotético: só precisava de saber se a fatura estava paga.
Mas recebeu o nome completo.
O NIF.
O telefone.
A morada.
O histórico de atendimento.
As últimas compras.
As notas que alguém do comercial escreveu no CRM.
E os últimos vinte eventos daquele cliente no sistema.
O agente respondeu corretamente.
Em menos de cinco segundos.
Toda a gente ficou satisfeita.
É aí que está o problema.
A arquitetura é perfeitamente possível: o agente recebeu muito mais contexto do que a pergunta exigia.
O anúncio da Meta e a resposta da CNPD
Num alerta publicado em 09-05-2025, a CNPD deu conta do anúncio da Meta de que, a partir de 27 de maio, usaria dados de publicações públicas de utilizadores com mais de 18 anos e dados gerados através do uso dos seus serviços de IA — incluindo informação inserida no seu agente conversacional no WhatsApp — para treinar e melhorar o Meta AI e modelos de linguagem como o Llama. A CNPD indicou os formulários de oposição disponibilizados pela Meta e afirmou que estava a avaliar, com outras autoridades europeias, a compatibilidade dessas atividades com o RGPD. Esse alerta dizia respeito a esse anúncio específico; não é, por si só, uma regra geral para todos os agentes ou fluxos de WhatsApp.
O alerta não responde por nós à pergunta de arquitetura. Se a automação usar WhatsApp, é preciso avaliar separadamente as regras e os termos da plataforma e as obrigações relativas aos dados pessoais. Cumprir uma camada não prova nem substitui a outra. O Regulamento (UE) 2016/679 (RGPD), adotado em 27-04-2016 e publicado em 04-05-2016, enquadra essa decisão através dos princípios da minimização e da proteção de dados desde a conceção.
O que isso muda para um agente
A tentação óbvia é dar acesso “só por precaução” e resolver a fronteira mais tarde.
É a tentação errada.
É a mesma linha que separa um agente de IA com acesso controlado a processos de negócio de um chatbot com bom nome.
Um agente ligado ao CRM para confirmar um pagamento não precisa da morada.
Um agente que reagenda uma consulta não precisa do histórico médico completo.
Mesmo quando ninguém está a olhar para esse desenho, o dado continua exposto se o agente o receber.
O perigo nem sempre está na base de dados
Imagine que a sua aplicação faz tudo "certo": tem a base de dados cifrada, autenticação, RLS, permissões e cópias de segurança.
Perfeito.
E depois o agente pega nos dados do cliente e envia tudo para o modelo.
Guarda a conversa inteira na ferramenta de observabilidade.
Cria embeddings.
Regista o prompt para depuração.
Mantém memória da conversa.
E uma integração externa recebe uma cópia para executar outra ação.
O NIF que estava protegido numa base de dados agora pode estar exposto em seis sítios diferentes.
Parabéns.
Criou um pequeno programa de intercâmbio de dados pessoais, e desta vez ninguém vai alertar ninguém.
A pergunta deve ser feita antes de os dados chegarem ao modelo:
Este dado precisa mesmo de chegar à IA?
Como medida de minimização na arquitetura, o dado desnecessário pode ser removido, mascarado ou substituído por um identificador temporário. O agente resolve o problema com CLIENTE_8472. Uma camada controlada da aplicação sabe quem é essa pessoa. O modelo não precisa de saber.
Remover, mascarar, tokenizar ou pseudonimizar são medidas de arquitetura que podem reduzir a exposição; não garantem, por si só, anonimização, segurança ou conformidade. Se ainda existir informação adicional que permita voltar a atribuir o identificador a uma pessoa, continuam em causa dados pessoais; o texto oficial do RGPD deve ser considerado ao avaliar finalidades, acessos, retenção e fornecedores.
Na prática
- detetar dados pessoais antes de enviar contexto ao modelo;
- mascarar ou tokenizar o que não é necessário;
- separar os dados reais da memória do agente;
- limitar cada ferramenta às operações necessárias;
- exigir aprovação humana para ações com efeito real;
- saber exatamente que fornecedores receberam cada tipo de dado;
- testar prompt injection antes de produção.
Nada disto aparece numa demonstração.
Mas as demonstrações duram vinte minutos, e os sistemas ficam anos em produção. O mesmo critério vale quando se decide como automatizar processos e integrar sistemas: o processo mais barato de automatizar raramente é o que implica menor exposição de dados.
Quando o agente atravessa CRM, ERP, stock ou faturação, vale a pena mapear a integração entre esses sistemas antes de escolher as ferramentas e os dados que cada uma pode receber.
A pergunta
Sabe exatamente que dados pessoais o seu agente consegue aceder hoje?
Se a resposta demorou, o próximo passo é desenhar a fronteira entre a IA e os seus dados.
Faça-o agora, enquanto ainda é uma escolha e não uma correção.
Na Prontavel é aí que gostamos de começar: construir automações em que a privacidade faz parte da arquitetura desde o primeiro dia, e não da lista de coisas para resolver depois.
Este artigo é informativo e não constitui aconselhamento jurídico. As obrigações aplicáveis dependem do contexto; para avaliar um caso concreto, procure aconselhamento profissional.
Calcule você mesmo a faixa
Isto estima quanto custaria construir e manter o seu projeto. Cinco perguntas, e cada uma mostra o que soma. É a mesma planilha que usamos no Discovery, então dá para conferir a conta em vez de confiar num número.
O serviço de que fala este artigo: Agentes de IA e chatbots que conhecem o seu negócio