Lei n.º 2008-12: integrar a conformidade CDP desde o enquadramento de um projeto SAP ou Salesforce.

Precisemos desde já o que este texto não é: um parecer jurídico. Somos uma empresa de consultoria e tecnologia. O que descrevemos aqui é a forma como a lei se traduz num projeto SAP ou Salesforce, e o que é preciso decidir, em que momento, para não a descobrir tarde demais. As formalidades precisas cabem ao seu consultor jurídico e à própria Comissão de Proteção de Dados Pessoais.

O que a lei cobre

A lei n.º 2008-12, de 25 de janeiro de 2008, enquadra o tratamento de dados pessoais no Senegal, isto é, toda a informação que permite identificar uma pessoa, direta ou indiretamente. Designa um responsável pelo tratamento, a empresa que decide as finalidades e os meios, e impõe-lhe obrigações: uma finalidade determinada e legítima, dados proporcionais a essa finalidade, um prazo de conservação limitado, a segurança e a confidencialidade, e a informação das pessoas envolvidas. Reconhece a essas pessoas direitos: ser informadas, aceder aos seus dados, mandá-los retificar, opor-se a certos tratamentos.

Institui uma autoridade de controlo, a CDP, junto da qual os tratamentos são objeto de formalidades prévias. Consoante a natureza dos dados e do tratamento, trata-se de uma declaração ou de um pedido de autorização, exigindo certas categorias de dados, ditas sensíveis, um regime mais estrito. Por fim, a lei enquadra as transferências de dados para fora do Senegal, o que diz diretamente respeito a qualquer projeto alojado no estrangeiro ou operado por um grupo internacional.

Porque é que o tema chega tarde demais

Três razões, que encontramos em todo o lado. A primeira é organizacional: o projeto é conduzido pela direção financeira, pelos recursos humanos ou pela direção comercial, e ninguém na equipa de projeto se sente responsável pela conformidade. A segunda é cultural: pensa-se que a lei visa as grandes plataformas ou os bancos, não uma empresa industrial ou uma sociedade de serviços. A terceira é técnica: os editores e integradores falam de segurança, de cópias de segurança e de direitos de acesso, e a equipa conclui que a conformidade está coberta. Não está. A segurança protege os dados; a conformidade justifica que sejam tratados.

O custo do atraso é concreto. Um campo «situação de saúde» acrescentado a uma ficha de colaborador sem finalidade declarada. Uma base de clientes migrada com dados de prospetos recolhidos sem informação. Um alojamento escolhido fora do país sem que a questão da transferência tenha sido colocada. Cada uma destas decisões corrige-se na conceção numa reunião. Depois da entrada em produção, corrige-se com uma migração de dados, uma adenda contratual ou uma nova formalidade.

A segurança protege os dados. A conformidade justifica que sejam tratados. Um projeto que confunde as duas descobre a segunda depois da entrada em produção.

O que isso muda num ERP

No SAP S/4HANA, SAP SuccessFactors ou Odoo, os dados mais sensíveis são os dos recursos humanos e do processamento de salários. O projeto tem de decidir que dados são realmente necessários: o estado civil e a conta bancária são-no para pagar; a filiação sindical, a religião ou os dados de saúde estão sujeitos a um regime particular e só têm lugar se uma finalidade precisa o justificar. Tem de fixar os prazos de conservação, tendo em conta as obrigações de conservação contabilística e social, e depois implementá-los no sistema: arquivo, bloqueio, eliminação. Tem de organizar os direitos de acesso por perfil, com rastreabilidade das consultas aos dados sensíveis. E tem de prever como um colaborador exerce o seu direito de acesso, sem que isso passe por uma extração manual improvisada.

Os fornecedores e os clientes pessoas singulares também estão abrangidos. Um artesão subcontratado ou um cliente particular é uma pessoa no sentido da lei. O módulo de compras e o módulo de vendas tratam portanto dados pessoais, com as mesmas questões de finalidade, de prazo e de acesso.

O que isso muda num CRM

O Salesforce Sales Cloud, Service Cloud e Marketing Cloud são concebidos para recolher, enriquecer e explorar dados de contacto. É a sua razão de ser, e é o que exige uma vigilância particular. Três temas dominam. O primeiro é a recolha: de onde vêm os contactos, foram informados, um ficheiro comprado ou importado de uma antiga ferramenta é utilizável? O segundo é o scoring e a segmentação: classificar pessoas segundo o seu valor ou o seu comportamento é um tratamento de pleno direito, que tem de ser declarado e explicado, e cujos efeitos as pessoas podem contestar. O terceiro é a campanha: o envio automatizado de mensagens por SMS, e-mail ou WhatsApp pressupõe uma base legal, uma possibilidade de recusa simples e o respeito dessa recusa em todos os canais.

Um CRM bem concebido transporta estas regras nos seus dados: a origem do contacto, a data e o modo da sua informação, as suas escolhas de comunicação, canal a canal, e a data para além da qual tem de ser arquivado. Não é um módulo de conformidade. É um modelo de dados pensado desde o enquadramento.

Transferências e alojamento

A questão do alojamento é muitas vezes decidida por razões de custo ou de desempenho, sem que a transferência de dados seja examinada. Ora, um CRM em cloud pública, um ERP alojado por um grupo fora do Senegal, um centro de serviços partilhados noutro país, ou um prestador de suporte que acede à distância à base de produção são situações que podem constituir uma transferência. O projeto tem de as inventariar, discuti-las com o seu consultor jurídico, e integrar as cláusulas necessárias nos contratos com os editores e os prestadores, antes da assinatura. Tratamos esta dimensão na nossa oferta cloud, em que a localização dos dados é um critério de escolha ao mesmo título que a latência e o custo em divisas.

Checklist por fase de projeto

• Enquadramento. Nomear um responsável pela conformidade na equipa de projeto. Inventariar os tratamentos que o futuro sistema vai suportar e as suas finalidades. Identificar os dados sensíveis. Colocar a questão do alojamento e das transferências. Consultar o consultor jurídico sobre as formalidades a iniciar junto da CDP e sobre o seu calendário.
• Conceção. Limitar os campos aos dados necessários. Definir os prazos de conservação e as regras de arquivo. Conceber os perfis e as habilitações. Prever no modelo de dados a origem, a informação e as escolhas das pessoas. Descrever como os direitos de acesso, de retificação e de oposição serão tratados.
• Realização. Parametrizar as habilitações e a rastreabilidade. Cifrar ou mascarar os dados sensíveis nos ambientes de teste. Verificar que as interfaces, nomeadamente entre SAP e Salesforce, não duplicam dados sem necessidade.
• Migração dos dados. Triar antes de migrar. Um dado cuja finalidade ou origem não possa ser justificada não deve entrar no novo sistema. É a ocasião, rara, de purgar.
• Entrada em produção. Assegurar que as formalidades estão cumpridas ou iniciadas. Informar as pessoas envolvidas, colaboradores e clientes, do novo tratamento. Formar os utilizadores nas regras de acesso e nos pedidos das pessoas.
• Exploração. Rever regularmente as habilitações. Aplicar as purgas previstas. Manter atualizado o inventário dos tratamentos a cada evolução funcional. Integrar estas revisões no contrato de suporte e manutenção aplicacional.

O caso dos grupos da UEMOA

Um grupo presente em vários Estados da união partilha uma moeda e um direito dos negócios harmonizado. Não partilha uma autoridade de proteção de dados. Cada país tem a sua lei e a sua autoridade, com formalidades, prazos e exigências que diferem. Um CRM regional ou um ERP de grupo tem portanto de ser concebido para que cada filial continue responsável pelos seus tratamentos, com dados compartimentados por país quando a lei local o exige, e um dossiê de conformidade por Estado. A tentação de uma base única, regida pela regra de um só país, é forte. Não se sustenta.

A conformidade não é um travão aos projetos. É uma exigência de conceção, como o desempenho ou a segurança, que se paga no enquadramento e rende na exploração. A nossa oferta segurança e riscos de TI integra-a nos nossos programas SAP e Salesforce, desde o primeiro workshop.