Ley n.º 2008-12: integrar el cumplimiento CDP desde el encuadre de un proyecto SAP o Salesforce.

Precisemos de entrada lo que este texto no es: un dictamen jurídico. Somos una firma de consultoría y tecnología. Lo que describimos aquí es la manera en que la ley se traduce en un proyecto SAP o Salesforce, y lo que hay que decidir, en qué momento, para no descubrirla demasiado tarde. Las formalidades precisas corresponden a su asesor jurídico y a la propia Comisión de Protección de Datos Personales.

Lo que cubre la ley

La ley n.º 2008-12 de 25 de enero de 2008 regula el tratamiento de datos de carácter personal en Senegal, es decir, toda información que permite identificar a una persona, directa o indirectamente. Designa un responsable del tratamiento, la empresa que decide las finalidades y los medios, y le impone obligaciones: una finalidad determinada y legítima, datos proporcionados a esa finalidad, un plazo de conservación limitado, la seguridad y la confidencialidad, y la información a las personas afectadas. Reconoce a esas personas derechos: ser informadas, acceder a sus datos, hacerlos rectificar, oponerse a ciertos tratamientos.

Instituye una autoridad de control, la CDP, ante la cual los tratamientos son objeto de formalidades previas. Según la naturaleza de los datos y del tratamiento, se trata de una declaración o de una solicitud de autorización; ciertas categorías de datos, llamados sensibles, requieren un régimen más estricto. Por último, la ley regula las transferencias de datos fuera de Senegal, lo que afecta directamente a todo proyecto alojado en el extranjero u operado por un grupo internacional.

Por qué el tema llega demasiado tarde

Tres razones, que encontramos en todas partes. La primera es organizativa: el proyecto lo lidera la dirección financiera, recursos humanos o la dirección comercial, y nadie en el equipo de proyecto se siente responsable del cumplimiento. La segunda es cultural: se piensa que la ley apunta a las grandes plataformas o a los bancos, no a una empresa industrial o a una sociedad de servicios. La tercera es técnica: los editores e integradores hablan de seguridad, de copias de seguridad y de derechos de acceso, y el equipo concluye que el cumplimiento está cubierto. No lo está. La seguridad protege los datos; el cumplimiento justifica que se traten.

El coste del retraso es concreto. Un campo «situación de salud» añadido a una ficha de empleado sin finalidad declarada. Una base de clientes migrada con datos de prospectos recogidos sin información. Un alojamiento elegido fuera del país sin que se haya planteado la cuestión de la transferencia. Cada una de esas decisiones se corrige en el diseño en una reunión. Después de la puesta en producción, se corrige con una migración de datos, una adenda contractual o una nueva formalidad.

La seguridad protege los datos. El cumplimiento justifica que se traten. Un proyecto que confunde ambos descubre el segundo después de la puesta en producción.

Lo que cambia en un ERP

En SAP S/4HANA, SAP SuccessFactors u Odoo, los datos más sensibles son los de recursos humanos y nómina. El proyecto debe decidir qué datos son realmente necesarios: el estado civil y la cuenta bancaria lo son para pagar; la afiliación sindical, la religión o los datos de salud están sujetos a un régimen particular y solo tienen cabida si una finalidad precisa lo justifica. Debe fijar los plazos de conservación, teniendo en cuenta las obligaciones de conservación contable y laboral, y después aplicarlos en el sistema: archivado, bloqueo, supresión. Debe organizar los derechos de acceso por rol, con trazabilidad de las consultas sobre los datos sensibles. Y debe prever cómo un empleado ejerce su derecho de acceso, sin que eso pase por una extracción manual improvisada.

Los proveedores y los clientes personas físicas también están afectados. Un artesano subcontratista o un cliente particular es una persona en el sentido de la ley. El módulo de compras y el módulo de ventas tratan, por tanto, datos personales, con las mismas cuestiones de finalidad, de plazo y de acceso.

Lo que cambia en un CRM

Salesforce Sales Cloud, Service Cloud y Marketing Cloud están diseñados para recoger, enriquecer y explotar datos de contacto. Es su razón de ser, y es lo que exige una vigilancia particular. Tres temas dominan. El primero es la recogida: de dónde vienen los contactos, han sido informados, ¿es utilizable un archivo comprado o importado de una herramienta antigua? El segundo es el scoring y la segmentación: clasificar personas según su valor o su comportamiento es un tratamiento de pleno derecho, que debe declararse y explicarse, y cuyos efectos las personas pueden rebatir. El tercero es la campaña: el envío automatizado de mensajes por SMS, correo electrónico o WhatsApp supone una base legal, una posibilidad de rechazo sencilla y el respeto de ese rechazo en todos los canales.

Un CRM bien diseñado lleva esas reglas en sus datos: la fuente del contacto, la fecha y el modo de su información, sus preferencias de comunicación, canal por canal, y la fecha a partir de la cual debe archivarse. No es un módulo de cumplimiento. Es un modelo de datos pensado desde el encuadre.

Transferencias y alojamiento

La cuestión del alojamiento suele decidirse por razones de coste o de rendimiento, sin que se examine la transferencia de datos. Y un CRM en cloud público, un ERP alojado por un grupo fuera de Senegal, un centro de servicios compartidos en otro país, o un proveedor de soporte que accede a distancia a la base de producción son situaciones que pueden constituir una transferencia. El proyecto debe inventariarlas, discutirlas con su asesor jurídico e integrar las cláusulas necesarias en los contratos con los editores y los proveedores, antes de la firma. Tratamos esta dimensión en nuestra oferta cloud, donde la localización de los datos es un criterio de elección al mismo nivel que la latencia y el coste en divisas.

Lista de control por fase de proyecto

• Encuadre. Designar un responsable del cumplimiento en el equipo de proyecto. Inventariar los tratamientos que soportará el futuro sistema y sus finalidades. Identificar los datos sensibles. Plantear la cuestión del alojamiento y de las transferencias. Consultar al asesor jurídico sobre las formalidades que iniciar ante la CDP y sobre su calendario.
• Diseño. Limitar los campos a los datos necesarios. Definir los plazos de conservación y las reglas de archivado. Diseñar los roles y las habilitaciones. Prever en el modelo de datos la fuente, la información y las preferencias de las personas. Describir cómo se tratarán los derechos de acceso, de rectificación y de oposición.
• Realización. Parametrizar las habilitaciones y la trazabilidad. Cifrar o enmascarar los datos sensibles en los entornos de prueba. Verificar que las interfaces, en particular entre SAP y Salesforce, no dupliquen datos sin necesidad.
• Migración de datos. Cribar antes de migrar. Un dato cuya finalidad u origen no pueda justificarse no debe entrar en el nuevo sistema. Es la ocasión, poco frecuente, de purgar.
• Puesta en producción. Asegurarse de que las formalidades están cumplidas o iniciadas. Informar a las personas afectadas, empleados y clientes, del nuevo tratamiento. Formar a los usuarios en las reglas de acceso y en las solicitudes de las personas.
• Explotación. Revisar regularmente las habilitaciones. Aplicar las purgas previstas. Mantener al día el inventario de tratamientos en cada evolución funcional. Integrar esas revisiones en el contrato de soporte y mantenimiento aplicativo.

El caso de los grupos de la UEMOA

Un grupo presente en varios Estados de la unión comparte una moneda y un derecho mercantil armonizado. No comparte una autoridad de protección de datos. Cada país tiene su ley y su autoridad, con formalidades, plazos y exigencias que difieren. Un CRM regional o un ERP de grupo debe diseñarse, por tanto, para que cada filial siga siendo responsable de sus tratamientos, con datos compartimentados por país cuando la ley local lo exija, y un expediente de cumplimiento por Estado. La tentación de una base única, regida por la regla de un solo país, es fuerte. No se sostiene.

El cumplimiento no es un freno a los proyectos. Es una exigencia de diseño, como el rendimiento o la seguridad, que se paga en el encuadre y rinde en la explotación. Nuestra oferta de seguridad y riesgos IT la integra en nuestros programas SAP y Salesforce, desde el primer taller.