"Quero todos os dados que têm sobre mim": como responder a um pedido de acesso sem perder uma semana

O email chega numa terça-feira à tarde, de um cliente antigo com quem houve uma discussão por causa de uma fatura: "Ao abrigo do artigo 15.º do RGPD, solicito cópia de todos os dados pessoais que a vossa empresa tem sobre mim." Lês duas vezes e a primeira pergunta que te ocorre não é jurídica. É prática: onde é que estão esses dados todos?

Estão na ficha de cliente do ERP. Nas faturas e nas notas de crédito dos últimos seis anos. Na conta-corrente e nos recebimentos. Nas guias de transporte com a morada de entrega. Nos pedidos de assistência técnica, com observações escritas por três técnicos diferentes. E também na ferramenta de newsletters, no email comercial e, provavelmente, numa folha de Excel que alguém fez em 2021 e nunca mais apagou.

Hoje, numa PME, isto costuma resolver-se assim: alguém exporta listagens do ERP, outra pessoa procura no email, cola-se tudo num documento e reza-se para não faltar nada. Dá um a dois dias de trabalho repartidos por pessoas que tinham outras coisas para fazer. E no fim ninguém consegue garantir que a resposta está completa.

Quanto tempo tens, e o que tens de entregar?

O prazo é um mês a contar da receção do pedido (art. 12.º, n.º 3, do RGPD). É o "30 dias" de que toda a gente fala, e convém contá-lo como mês de calendário. Pode ser prorrogado por mais dois meses se o pedido for complexo ou se houver muitos pedidos. Mas tens de avisar o titular dentro do primeiro mês e explicar porquê. A primeira cópia é gratuita.

E não basta mandar uma listagem. O artigo 15.º obriga-te a entregar uma cópia dos dados e, além disso, a informar:

• para que finalidades os tratas;
• que categorias de dados tens;
• a quem os comunicaste (contabilista, transportadora, software de faturação, etc.);
• durante quanto tempo os guardas, ou com que critério;
• que direitos a pessoa tem: retificação, apagamento, limitação, oposição e reclamação à CNPD;
• de onde vieram os dados, quando não foi a própria pessoa a fornecê-los;
• se há decisões automatizadas sobre ela.

A maior parte disto é texto fixo, que escreves uma vez e reutilizas. A parte difícil, a que come os dias, é a primeira: a cópia completa e correta dos dados, tirada de sistemas que nunca foram pensados para responder a esta pergunta.

Porque não usar simplesmente o ChatGPT público?

Porque, para lhe pedir ajuda, terias de colar lá dentro precisamente aquilo que estás a tentar proteger: o nome, o NIF, a morada e o histórico de compras de um cliente que já está desconfiado de ti. Esses dados saem da empresa e, consoante o plano e a configuração, podem sair da UE. E não fica registo interno de quem os enviou.

Há um segundo problema, mais traiçoeiro. Um modelo de linguagem genérico, quando não tem a informação, preenche o vazio. Num resumo de reunião isso incomoda. Numa resposta ao abrigo do RGPD, um dado inventado ou uma omissão que não se vê é exatamente o tipo de erro que transforma um cliente chateado numa queixa à CNPD.

O que faz um assistente privado ligado ao ERP neste caso?

Faz uma coisa simples e chata, e por isso útil: percorre, só em modo de leitura, todos os sítios do ERP onde aquele titular aparece e devolve o que encontrou, linha a linha, com a origem de cada dado.

Na prática, a arquitetura tem quatro peças:

1. Um conector só de leitura ao ERP que já tens (PHC, Primavera ou outro). Não escreve, não altera, não apaga. Não é preciso migrar nada.
2. Um mapa das tabelas onde há dados pessoais: ficha de cliente, moradas alternativas, contactos, documentos de venda, recebimentos, assistências, anexos. Este mapa faz-se uma vez, no arranque, e é metade do valor.
3. Uma camada que transforma o pedido numa consulta a esse mapa, filtrada pelo identificador do titular (NIF, número de cliente, email).
4. Um registo de auditoria: quem pediu, sobre que titular, quando, que tabelas foram lidas e o que foi devolvido.

O modelo de linguagem serve para perceber o pedido em português e para redigir o resumo. Os números e os registos vêm diretamente da base de dados, nunca da "memória" do modelo. A arquitetura é agnóstica ao modelo: pode usar um modelo nacional ou um modelo alojado na UE, conforme o caso. Os dados não saem da UE.

Como fica isto numa tarde real?

Um exemplo, com dados fictícios e números meramente ilustrativos, numa distribuidora com cerca de 4.000 clientes:

Pergunta: Pedido de acesso do cliente NIF 2xx xxx xx0. Lista todos os dados pessoais que temos no ERP, por origem.

Resposta (exemplo): Encontrei o titular em 6 tabelas. Ficha de cliente: nome, NIF, 2 moradas, 1 telefone, 1 email. Documentos de venda: 41 faturas e 3 notas de crédito (2019–2026). Recebimentos: 38 registos. Guias de transporte: 27, com morada de entrega. Assistências técnicas: 4 pedidos com observações em texto livre. Anexos: 2 PDF. Fonte de cada linha indicada no relatório.

Pergunta: Há observações em texto livre que mencionem outras pessoas?

Resposta (exemplo): Sim. Em 2 dos 4 pedidos de assistência aparece o nome de um técnico e, num deles, o de um vizinho do cliente. Marquei-os para revisão antes do envio.

Pergunta: A quem foram comunicados estes dados?

Resposta (exemplo): No ERP há registo de envio para a transportadora (27 guias). Não encontrei outros destinatários no ERP. O gabinete de contabilidade e a plataforma de newsletters não estão ligados a este assistente e têm de ser confirmados à parte.

Esta última resposta é a mais importante das três. O assistente diz o que não sabe, em vez de dar a lista por fechada.

Um apontamento: o mesmo assistente pode responder no WhatsApp a perguntas do dia a dia, como vendas, stock ou cobranças. O dossiê de um pedido de acesso não deve passar por lá. Faz-se na consola, com um perfil próprio, e o ficheiro final segue pelo canal seguro que já usas.

Não é arriscado dar a uma IA acesso aos dados pessoais dos clientes?

É a objeção certa, e responde-se com controlos, não com promessas:

• Só leitura. O assistente não tem permissões para escrever no ERP. Não "corrige" nem apaga nada por iniciativa própria.
• Acesso por perfil (RBAC). A consulta "pedido de acesso", que junta tudo sobre uma pessoa, só está disponível para o perfil do responsável pela proteção de dados ou de quem fizer esse papel. O comercial que pergunta pelas vendas do mês não a consegue usar.
• Auditoria. Cada pedido fica registado. Isto protege-te duas vezes: sabes se alguém andou a consultar dados que não devia, e tens prova de que respondeste dentro do prazo, com o que encontraste e quando. O RGPD chama-lhe responsabilidade (art. 5.º, n.º 2). Na prática, é teres o papel guardado.
• Dados na UE. Alojamento e processamento na UE, sem treino de modelos com os teus dados.

Há um argumento menos óbvio: sem assistente, o risco não desaparece. Fica num Excel exportado à pressa, guardado no ambiente de trabalho de alguém e enviado por email interno. A alternativa a um sistema auditado costuma ser um processo que ninguém audita.

O que é que o assistente não faz?

Convém dizê-lo sem rodeios:

• Não decide o que se entrega. O artigo 15.º, n.º 4, diz que a cópia não pode prejudicar os direitos de terceiros. Tirar o nome do vizinho ou de um colega das observações é uma decisão humana. O assistente assinala, tu decides.
• Não verifica a identidade de quem pede. Antes de enviares seja o que for, tens de confirmar que quem escreveu é mesmo o titular (art. 12.º, n.º 6). Mandar o histórico de um cliente a um impostor é, em si, uma violação de dados.
• Só vê o que está ligado. Se os dados também vivem no email, na ferramenta de marketing ou numa pasta partilhada, ou ligas essas fontes ou as tratas à parte. O assistente deve dizer-te sempre que fontes consultou.
• Precisa de dados minimamente arrumados. Se o mesmo cliente existe três vezes com NIF mal escrito, o primeiro trabalho é esse. Muitas vezes, o próprio pedido de acesso é a primeira vez que alguém dá por isso.

Vale a pena montar isto para um pedido que chega uma vez por ano?

Se fosse só para o pedido de acesso, provavelmente não. Mas o trabalho que dá mais valor, que é mapear onde estão os dados pessoais no ERP e ligá-los em modo de leitura com perfis e auditoria, é o mesmo que serve para perguntar ao ERP "quanto faturámos ao cliente X este trimestre e o que está por receber?". O pedido de acesso funciona como teste: se o assistente consegue juntar tudo sobre uma pessoa, com fonte e sem inventar, é porque conhece bem os teus dados.

E há o custo do erro. Um pedido mal respondido ou fora de prazo é das queixas mais fáceis de fazer à CNPD, porque o titular só tem de mostrar o email que enviou e a data.

Por onde começar?

Pequeno e medido:

1. Escolhe o ERP e uma área, por exemplo clientes e vendas.
2. Faz o mapa das tabelas com dados pessoais. Costuma levar dias, não meses.
3. Define os perfis: quem pode fazer a consulta completa de um titular e quem só vê agregados.
4. Simula um pedido de acesso com um cliente interno de teste e compara com o que farias à mão: tempo gasto, registos encontrados e registos que te escapavam.
5. Junta 10 a 20 perguntas frequentes da operação e mede as horas poupadas num mês.

Somos uma equipa pequena em Leiria. Quem faz o mapa das tuas tabelas é a mesma pessoa que escreve o conector, e falas diretamente com ela, sem gestores de conta pelo meio.

Queres perguntar ao teu ERP em português, sem os dados saírem da UE? Fala connosco: hello@leiritech.com · +351 914 572 595, ou vê o nosso trabalho em leiritech.pt.

Este artigo é informativo e não substitui aconselhamento jurídico sobre o teu caso concreto.