Uma empresa varejista compartilhou o histórico de compras de clientes com um fornecedor de análise de programas de fidelidade para viabilizar recomendações personalizadas. A plataforma analítica do fornecedor ingeriu o histórico de compras, normalizou-o, calculou atributos derivados (pontuações de frequência de compra, índices de afinidade por categoria, métricas de propensão ao cancelamento) e o uniu à sua taxonomia de produtos de referência. O conjunto de dados resultante tinha dezenas de campos calculados que não existiam nos dados originais. O DPA da varejista especificava a base legal e os requisitos de tratamento do histórico de compras dos clientes. Não dizia nada sobre os atributos calculados que o fornecedor derivou desse histórico, que tinham outras características de sensibilidade, outras implicações de retenção e, possivelmente, outro status regulatório. Quando um cliente apresentou uma DSAR pedindo todos os dados que a varejista mantinha sobre ele, o fornecedor entregou os campos originais do histórico de compras e mais vinte e três atributos calculados. O aviso de privacidade da varejista descrevia o tratamento original do histórico de compras. Não descrevia a derivação de pontuações de propensão ao cancelamento nem de índices de afinidade por categoria. A resposta à DSAR incluiu dados sobre os quais o cliente não havia sido informado. A investigação do ICO que se seguiu constatou transparência inadequada em relação aos dados derivados dos perfis de clientes.
O que é, de fato, o problema do risco de transformação de dados por fornecedores?
Transformação de dados é o processo pelo qual os dados de entrada são modificados, enriquecidos, derivados ou calculados em dados de saída com características diferentes: normalização que padroniza formatos, derivação que calcula novos atributos a partir dos existentes, enriquecimento que une dados externos aos registros de entrada e agregação que produz atributos de síntese a partir de registros individuais. O risco surge quando a saída transformada tem implicações regulatórias, de sensibilidade ou de direitos diferentes das dos dados de entrada, e quando o DPA e o programa de governança tratam da entrada, mas não da saída.
O problema dos atributos derivados é o risco de transformação mais comum em fornecedores de análise de dados. Quando a plataforma de um fornecedor calcula uma pontuação de propensão ao cancelamento a partir do histórico de compras, essa pontuação é um dado pessoal derivado: é um dado pessoal porque é atribuída a uma pessoa e deriva dos dados pessoais originais que o fornecedor estava autorizado a tratar. A base legal do tratamento original do histórico de compras pode ou não se estender à derivação de pontuações preditivas a partir desse histórico; a derivação pode exigir outro fundamento, sobretudo se as pontuações forem usadas em decisões automatizadas. As obrigações relativas aos direitos do titular dos dados sobre os dados derivados podem diferir das que se aplicam aos dados de origem: o titular tem direitos sobre os resultados de perfilamento automatizado que podem ser mais amplos do que seus direitos sobre os registros brutos de compras.
A mudança de classificação regulatória é um risco de transformação específico de fornecedores que aplicam normalização ou categorização aos dados de entrada. Um fornecedor cuja plataforma normaliza históricos médicos em texto livre em códigos diagnósticos padronizados transformou texto não estruturado em dados de saúde estruturados, o que pode deslocar a classificação regulatória de dados pessoais gerais para dados de saúde de categoria especial, com outros requisitos de fundamento para o tratamento, outras obrigações de retenção e outras restrições à transferência internacional. A entrada era um campo de texto não estruturado. A saída é um código de saúde. O fundamento de tratamento que cobria o campo de texto pode não cobrir o código de saúde.
- Criação de atributos derivados sem governança: campos calculados derivados de dados de clientes sem disposições no DPA que tratem dos atributos derivados
- Mudança de classificação regulatória pela transformação: normalização que produz dados com status regulatório diferente do da entrada
- Escopo dos direitos do titular dos dados sobre dados derivados: obrigações de DSAR e de eliminação de atributos derivados não tratadas na governança
- Obrigação de transparência sobre a derivação: avisos de privacidade que descrevem o tratamento da entrada, mas não a derivação da saída
- Retenção de dados derivados sem governança: atributos calculados sujeitos a requisitos de retenção diferentes dos dados de origem, mas regidos pelo mesmo cronograma
Por que isso importa
A transformação de dados por fornecedores é relevante para TPRM porque a transformação cria dados novos, que não existiam antes de o fornecedor tratar a entrada, com características que podem diferir substancialmente das dos dados de entrada quanto ao status regulatório, à sensibilidade e às obrigações relativas a direitos. Um programa de governança que cobre a entrada, mas não a saída, tem uma lacuna sistemática para cada conjunto de dados transformado que o fornecedor cria a partir dos dados de entrada do cliente.
A implicação para as DSAR é imediatamente prática. Quando um cliente apresenta uma DSAR, o fornecedor deve entregar todos os dados pessoais que mantém sobre o titular, o que inclui os atributos derivados além dos dados de origem. Um controlador que não sabia que o fornecedor estava derivando atributos calculados dos registros de seus clientes não tem como incluir esses atributos na resposta à DSAR, o que gera uma resposta incompleta e uma falha de transparência que os reguladores identificarão.
Onde a maioria das equipes erra
A falha mais recorrente é tratar os dados enviados a um fornecedor como equivalentes aos dados que o fornecedor mantém. Fornecedores de análise de dados, por definição, transformam dados: essa é a proposta de valor. O que o fornecedor mantém após o tratamento não é o que foi enviado. É o que foi enviado mais tudo o que o tratamento derivou disso. Uma governança que cobre apenas o que foi enviado deixa sem tratamento tudo o que foi derivado.
- Tratar os dados enviados como equivalentes aos dados mantidos para fins de governança
- Atributos derivados não tratados no DPA
- Escopo das DSAR não estendido aos dados derivados
- Transparência do aviso de privacidade que não abrange a derivação
- Retenção de atributos derivados sem governança própria
Como é uma boa prática
Programas maduros de governança da transformação de dados tratam os dados derivados como uma categoria de dados distinta, especificando a base legal para a derivação, o cronograma de retenção dos atributos derivados, as obrigações relativas aos direitos do titular dos dados aplicáveis aos dados derivados e as obrigações de transparência que exigem a divulgação de derivações significativas nos avisos de privacidade.
- Divulgação das derivações no DPA: tipos de atributos derivados que o fornecedor cria e base legal para a derivação
- Inventário de dados derivados: quais atributos calculados são criados a partir dos dados de entrada do cliente
- Escopo dos direitos do titular dos dados para derivações: obrigações de DSAR e de eliminação que se estendem aos atributos derivados
- Transparência no aviso de privacidade: divulgação de derivações significativas que criem perfilamento ou decisões automatizadas
- Cronograma de retenção de dados derivados: governança de retenção separada para atributos derivados
Ferramentas
Linhagem de dados: Collibra, Alation, dbt
As plataformas de linhagem de dados rastreiam como os dados se transformam entre sistemas, documentando os atributos derivados e a linhagem de seus dados de origem. Para profissionais de TPRM, perguntar se o fornecedor mantém documentação de linhagem para os atributos derivados criados a partir dos dados de clientes é uma pergunta específica de governança das derivações.
Gestão de privacidade: OneTrust, BigID
As plataformas de gestão de privacidade permitem estender os inventários de dados para incluir categorias de dados derivados, possibilitando a governança dos atributos derivados junto com os dados de origem. Para profissionais de TPRM, perguntar se o ROPA do fornecedor inclui as categorias de atributos derivados é uma pergunta específica de documentação regulatória.
Desafios de governança
O desafio de governança da transformação de dados é o problema da governança na fase de projeto. As especificações de transformação são projetadas por engenheiros de dados que otimizam o valor analítico. As implicações de governança dos atributos derivados (classificação regulatória, obrigações relativas a direitos, requisitos de retenção) exigem a participação da equipe de governança na fase de projeto, e não depois que o pipeline de derivação já está em funcionamento há dois anos. Conectar o projeto das transformações à revisão de governança antes do início da derivação é a intervenção organizacional que fecha a lacuna.
- Acrescentar a divulgação das derivações ao DPA com fornecedores de análise de dados: tipos de atributos derivados dos dados de entrada do cliente
- Estender o escopo das DSAR aos atributos derivados
- Atualizar os avisos de privacidade para derivações significativas: transparência sobre perfilamento e decisões automatizadas
- Exigir dos fornecedores de análise de dados um inventário de dados derivados
- Perguntar o que o fornecedor cria a partir dos seus dados, e não apenas o que recebe
Se você faz parte de uma equipe pequena
Faça aos seus fornecedores de análise de dados uma pergunta que revela imediatamente a governança das transformações: além dos campos de dados que enviamos, quais atributos calculados ou derivados a sua plataforma cria a partir dos dados dos nossos clientes, e o nosso DPA trata desses atributos derivados como uma categoria de dados distinta? A resposta indica o que o fornecedor mantém que você não enviou e se a sua governança cobre isso.
- Perguntar quais atributos derivados a plataforma do fornecedor cria a partir dos dados de entrada do cliente
- Perguntar se o DPA trata os atributos derivados como uma categoria de dados distinta
- Perguntar quais dados o fornecedor entregaria em resposta a uma DSAR: dados de origem mais atributos derivados
O que exigir
Pergunte diretamente:
“Quais atributos calculados ou derivados a sua plataforma cria a partir dos dados de clientes que fornecemos, e esses atributos derivados são tratados no nosso DPA como uma categoria de dados distinta, com base legal e cronograma de retenção próprios?”
“Se recebêssemos uma solicitação de acesso de um dos nossos clientes cujos dados vocês mantêm, quais dados vocês entregariam? Especificamente, a resposta incluiria atributos calculados e pontuações derivados dos dados de origem desse cliente?”
O que esperar como evidência
- Inventário de atributos derivados: o que é criado a partir dos dados de entrada do cliente
- Disposições sobre derivação no DPA: base legal e retenção para atributos derivados
- Confirmação do escopo das DSAR, incluindo atributos derivados
- Transparência do aviso de privacidade sobre derivações significativas
Um fornecedor que responde à pergunta sobre derivação com “analisamos os dados que vocês fornecem” confirmou que há análise sem descrever o que ela produz. Pergunte especificamente quais campos calculados existem no sistema dele, atribuídos aos seus clientes, que não estavam nos dados originais que você enviou. Os dados originais são o que você governou. Os dados derivados são o que eles produziram. Ambos exigem governança.
Como comprovar
- Documentação do inventário de atributos derivados
- Disposições sobre derivação no DPA
- Extensão do escopo das DSAR aos atributos derivados
- Transparência do aviso de privacidade sobre derivações significativas
Principal conclusão
Você enviou o histórico de compras. O fornecedor criou a partir dele pontuações de propensão ao cancelamento, índices de afinidade por categoria e outros vinte e três atributos calculados. Esses atributos são dados pessoais. Foram derivados de dados pessoais. São atribuídos aos seus clientes. Existem no sistema do fornecedor neste momento, e o seu DPA não diz nada sobre eles, porque o DPA foi redigido sobre o que você enviou, e não sobre o que o fornecedor produziu a partir disso. Os dados que você enviou e os dados que o fornecedor mantém estão relacionados, mas não são os mesmos. A governança do que você enviou é a governança de parte do que o fornecedor mantém. O restante precisa de governança própria, base legal própria, cronograma de retenção próprio e divulgação de transparência própria. Pergunte o que eles produziram. Depois, governe isso.