Ley 25 de Quebec: el proyecto que hubo que rehacer
Resumen:
- La Ley 25 convive con PIPEDA y en varios puntos es más estricta.
- El consentimiento para datos sensibles se pide aparte, por propósito, y se registra.
- La portabilidad cubre lo que aportó el titular, no necesariamente lo inferido.
- La responsabilidad recae en una persona con nombre, que necesita poder consultar el sistema.
Una empresa de servicios profesionales con producto digital operaba en Ontario y decidió abrir en Quebec. Su aplicación cumplía la normativa federal, tenía política de privacidad, consentimiento en el registro y borrado de cuenta.
La revisión previa a la expansión encontró cuatro problemas. Dos se resolvieron con configuración. Los otros dos exigieron cambios en el modelo de datos.
Uno: el consentimiento agrupado
La aplicación pedía aceptar términos y política de privacidad en una sola casilla al registrarse. Dentro de esa aceptación iban varios tratamientos distintos: prestar el servicio, enviar comunicaciones comerciales y analizar el uso para mejorar el producto.
Ese agrupamiento no sirve cuando hay datos sensibles ni cuando los propósitos son separables. El consentimiento tiene que ser específico por finalidad, y el usuario debe poder aceptar uno y rechazar otro.
El cambio técnico no fue añadir casillas. Fue pasar de un campo booleano «aceptó» a una tabla de consentimientos con propósito, fecha, versión del texto aceptado y estado. Sin esa estructura no se puede demostrar qué aceptó una persona concreta hace dos años.
Dos: la portabilidad y qué se exporta
Existía un botón de descarga que entregaba un archivo con la información de la cuenta. Insuficiente por dos motivos.
El formato era un documento pensado para leerse, no para reutilizarse. La exigencia habla de un formato estructurado y de uso común, es decir, algo que otro sistema pueda importar.
Y no distinguía entre lo aportado por el usuario y lo generado por la empresa. Esa distinción importa: lo primero es claramente portable, lo segundo tiene matices.
| Categoría | Ejemplo | Tratamiento |
|---|---|---|
| Aportado por el titular | Nombre, documentos que subió, contenido que escribió. | Portable sin discusión. |
| Observado | Registro de accesos, uso de funciones. | Accesible por el derecho de acceso; su portabilidad es más matizada. |
| Inferido | Segmentación, puntuaciones internas. | No necesariamente portable; el titular sí puede conocer su existencia. |
Etiquetar cada campo con su categoría es trabajo de modelo de datos. Hacerlo después, con la base ya en producción, significa revisar tabla por tabla.
Tres: la evaluación de impacto
La empresa alojaba datos fuera de la provincia, algo habitual y que activa la obligación de evaluar el riesgo antes del tratamiento.
No es un requisito de software: es un documento que analiza qué datos salen, a dónde, con qué protecciones y qué riesgo supone para las personas. Pero condiciona al software, porque para escribirlo hay que poder responder dónde vive cada dato y quién accede.
Un sistema que no sabe responder eso obliga a redactar la evaluación con suposiciones, que es exactamente lo que una revisión detecta.
Cuatro: el francés no es una traducción
La aplicación tenía interfaz en inglés y una traducción parcial al francés hecha con un servicio automático.
La exigencia lingüística en Quebec no se satisface con una traducción aproximada. Y hay un detalle que sorprende a los equipos técnicos: no basta con traducir la interfaz. Las comunicaciones al cliente, los documentos contractuales y la atención también entran.
La traducción automática al francés canadiense falla además de una forma específica: produce texto correcto en francés europeo que suena ajeno localmente. Es un problema de terminología y de registro que solo detecta una revisión humana local.
Preguntas frecuentes
¿La Ley 25 sustituye a PIPEDA?
No, convive con ella. PIPEDA es el marco federal y la Ley 25 aplica en Quebec con exigencias propias que en varios puntos son más estrictas. Una empresa que opera en todo el país acaba diseñando para el estándar más alto, porque mantener dos comportamientos distintos multiplica el riesgo.
¿Qué es la evaluación de impacto y cuándo hace falta?
Un análisis documentado del riesgo para la privacidad, exigible antes de ciertos tratamientos, como la comunicación de datos fuera de la provincia o el uso de tecnología que permita identificar o perfilar a una persona. Es un documento, no una casilla en el sistema.
¿Qué significa consentimiento explícito para datos sensibles?
Que no puede deducirse del uso del servicio ni ir incluido en una aceptación general de términos. Debe pedirse por separado, para un propósito concreto, y el sistema debe registrar cuándo y para qué se otorgó.
¿La portabilidad obliga a exportar todo?
Obliga a entregar, a petición del titular, los datos que él aportó, en un formato tecnológico estructurado y de uso común. No incluye necesariamente lo que la empresa infirió o generó a partir de ellos, y esa distinción conviene modelarla desde el principio.
¿Hace falta nombrar a un responsable de protección de datos?
La ley atribuye esa responsabilidad por defecto a la persona con mayor autoridad en la organización, que puede delegarla por escrito. En la práctica significa que alguien con nombre responde de las decisiones sobre datos, y esa persona necesita poder consultarlas en el sistema.
Lo que habríamos hecho distinto desde el inicio
Tres decisiones de diseño que cuestan poco al principio y mucho después.
Consentimiento como registro, no como campo. Una tabla con propósito, fecha, versión del texto y estado, desde el primer día. Convertir un booleano en un historial cuando ya hay usuarios es una migración con datos que no existen.
Cada campo con su categoría de privacidad. Aportado, observado o inferido. Etiquetarlo al crear la tabla es gratis; deducirlo después es un inventario manual.
El idioma por usuario y no por región. Alguien en Toronto puede preferir francés y alguien en Montreal, inglés. Atarlo a la ubicación produce exactamente el tipo de suposición que la normativa lingüística pretende evitar.
Los plazos que corren
Un aspecto operativo que condiciona el diseño: varias obligaciones tienen plazo de respuesta.
Una solicitud de acceso o de supresión no admite «lo revisamos cuando podamos». Si el sistema no puede reunir la información de una persona con rapidez, la organización se queda sin margen antes de empezar.
Eso convierte una capacidad que parece administrativa —poder responder qué datos tenemos de alguien— en un requisito técnico con fecha límite implícita.
Qué pedimos ahora antes de expandir a una provincia nueva
- Inventario de datos personales con dónde vive cada uno y para qué se recogió.
- Mapa de terceros que acceden a esos datos, incluidos proveedores de infraestructura.
- Historial de consentimientos ya estructurado, no un campo booleano.
- Plan lingüístico que incluya interfaz, comunicaciones y atención, no solo la interfaz.
Los cuatro se pueden preparar antes de tomar la decisión comercial. Hacerlos después, con usuarios reales, es lo que convierte una expansión en un proyecto de remediación.