Documentar as falhas do assistente virtual sem expor clientes exige um registo que guarde o problema e a correção, nunca a identidade de quem falou: sem nomes, sem números de telemóvel, sem moradas e sem transcrições literais das conversas. O RGPD obriga a que os dados pessoais sejam adequados, pertinentes e limitados ao necessário para a finalidade do tratamento, e um registo interno de melhorias é precisamente a finalidade que funciona com o mínimo de informação. Este guia define os campos essenciais, o procedimento de registo em cinco passos e a fronteira entre anonimizar e pseudonimizar, com um exemplo prático para equipas pequenas.
O mínimo que o registo precisa
Um registo de falhas cumpre três funções: perceber o padrão dos erros, corrigir a causa e verificar que a correção funcionou. Nenhuma delas precisa de identificar o cliente. Quanto mais pessoas acedem à folha — técnicos, fornecedor do assistente, novos colegas — maior o risco de cada campo pessoal que lá entrar, porque o registo circula mais do que a conversa original. A regra prática é a minimização dos dados: se um campo não muda a decisão sobre a correção, não entra no registo.
A tabela seguinte resume os campos que chegam para quase todos os casos de assistentes de atendimento por mensagens:
| Campo do registo | O que escrever | O que nunca escrever |
|---|---|---|
| Data e hora | Momento em que a falha ocorreu | Nome ou contacto do cliente |
| Canal | WhatsApp, site ou telefone | Número de telemóvel ou e-mail |
| Tipo de falha | Resposta errada, resposta incompleta, loop, falha de transferência | Excerto literal da conversa |
| Causa provável | Regra desatualizada, informação em falta no assistente | Dados de acesso a contas |
| Correção e data | O que mudou e quando entrou em vigor | Morada, NIF ou número de utente |
Registar a falha em cinco passos
O procedimento cabe numa folha de cálculo partilhada e não exige ferramentas novas:
- Marcar a data e a hora da ocorrência, sem qualquer referência ao cliente.
- Classificar a falha por tipo: resposta errada, resposta incompleta, loop de conversa, falha de transferência para uma pessoa ou espera acima do tempo definido.
- Descrever a intenção do pedido em palavras genéricas — por exemplo, “pedido de alteração de marcação”, em vez da frase exata escrita pelo cliente.
- Anotar a causa provável e a correção aplicada, com a data em que passou a valer.
- Rever passadas duas semanas se a falha voltou a ocorrer; se voltou, o registo ganha uma nova linha, nunca uma edição silenciosa da anterior.
O quinto passo é o que transforma a folha num ciclo de melhoria em vez de uma lista de queixas: a estrutura da NIST para gestão de risco de inteligência artificial é de utilização voluntária e abrange o desenho, o desenvolvimento, a utilização e a avaliação de produtos e sistemas de IA, tratando a monitorização e a correção como parte normal do ciclo de risco. O quadro da NIST está publicado para consulta livre e serve de referência mesmo a equipas de dois ou três colaboradores.
Anonimizar não é pseudonimizar
Substituir o nome do cliente por um código interno não transforma o registo em dado anónimo. De acordo com o RGPD, os dados pseudonimizados que possam ser atribuídos a uma pessoa através de informação adicional continuam a ser dados pessoais, com todas as obrigações de proteção daí decorrentes. Se a folha de registo guardar um código e noutra folha existir a tabela que liga esse código ao cliente, a “anonimização” é apenas aparência.
Um registo verdadeiramente anónimo não permite reconstituir ninguém: descreve o problema, o canal e a correção, e nada mais. O mesmo cuidado vale para as ferramentas do assistente — por exemplo, ao detetar o idioma do cliente sem confundir nomes e moradas, os campos capturados devem ficar no sistema de atendimento, não no registo de melhorias.
A distinção tem reconhecimento institucional: as orientações do EDPB sobre pseudonimização (Guidelines 01/2025) estiveram em consulta pública entre 17 de janeiro e 14 de março de 2025, e o tema continua na agenda europeia de proteção de dados. O painel de orientações do EDPB reúne estes documentos para consulta direta.
Quem acede ao registo e porquê
O acesso ao registo deve ser mais restrito do que o acesso às conversas. Uma regra útil: quem pode corrigir o assistente lê a folha inteira; quem só reporta falhas escreve numa fila de entrada que outra pessoa trata e limpa. Defina também um prazo de conservação e cumpra-o — um registo de melhorias não precisa de viver anos, porque o que interessa é o padrão recente e a correção em vigor.
Guarde separadas as duas coisas que se confundem: o registo de falhas, anónimo, e as conversas originais, que são dados pessoais e ficam na ferramenta de atendimento com acesso restrito e prazo próprio. Para avaliar o resultado das correções junto dos clientes, use instrumentos de satisfação desenhados para isso, como avaliar a satisfação após a conversa com o assistente virtual, em vez de reabrir conversas antigas para confirmar se a correção resultou.
Exemplo fictício de folha de registo
Exemplo fictício, para ilustrar o formato — não é um caso real. Uma barbearia com assistente de marcações regista numa semana: “falha de transferência para a pessoa quando o cliente pede corte específico” num dia ao fim da tarde; “resposta com horários desatualizados de terça-feira” no dia seguinte; “confusão entre agendamento e cancelamento” três dias depois. Em nenhum dos casos a folha guarda o nome, o número ou a mensagem do cliente: a correção recai sobre as regras do assistente e sobre os horários sincronizados com a agenda. Ao fim de duas semanas, a folha mostra se as correções seguraram — e é essa a única métrica que o registo precisa de produzir.