«El DPO ya participa en los comités de transformación digital»

La figura del Delegado de Protección de Datos (DPO) ha sufrido una metamorfosis radical en los últimos años en España. De ser percibida como una obligación burocrática impuesta por el RGPD en 2018 a convertirse, en las organizaciones más maduras, en un actor estratégico que participa en los comités de transformación digital y en las decisiones de arquitectura tecnológica. Beatriz Rodríguez, socia de RocaJunyent y referente nacional en privacidad, seguridad y transformación digital, es una de las voces más autorizadas para explicar ese tránsito y, también, para poner el foco donde el mercado español todavía tiene deberes pendientes.

En un ecosistema tecnológico donde las empresas acumulan decenas de proveedores cloud, SaaS y terceros especializados, la complejidad del cumplimiento normativo se ha disparado. Beatriz Rodríguez advierte de que muchas compañías españolas siguen construyendo sus estrategias de protección sobre cimientos débiles, sin haber realizado siquiera un ejercicio básico de identificación de activos críticos o clasificación de datos. Normativas como DORA están obligando a corregir esa carencia, pero la presión regulatoria no debería ser el único motor del cambio.

El auge de la Inteligencia Artificial ha añadido una nueva capa de complejidad al panorama. Para Beatriz Rodríguez, uno de los errores más comunes y costosos que cometen las organizaciones es diseñar funcionalidades de IA que sobre el papel parecen inofensivas, pero que en la práctica constituyen usos prohibidos o prácticas sancionadas por la legislación vigente. El coste de corregirlos una vez el producto está en el mercado puede ser, en sus propias palabras, «exponencialmente mayor» al de haberlos prevenido desde el diseño.

Desde su posición en el Grupo de IA de APEP y su participación en think tanks sobre regulación tecnológica, Beatriz Rodríguez tiene una perspectiva privilegiada sobre cómo deben prepararse las organizaciones ante un entorno normativo en permanente evolución. Su recomendación es pragmática y alejada del maximalismo: no se trata de «cumplir con el estándar más exigente posible», sino de realizar un análisis de riesgos informado, distinguir entre obligaciones inminentes y contingencias futuras, e integrar el compliance tecnológico como un proceso continuo dentro del ciclo de vida de los proyectos.

[MCPRO] Como delegada de Protección de Datos en RocaJunyent y experta en transformación digital, ¿cómo ha evolucionado el papel del DPO de ser meramente «cumplidor normativo» a convertirse en un actor estratégico clave en las decisiones de arquitectura tecnológica de un despacho como el vuestro? ¿Qué cambios en la organización y de mentalidad en la C-Suite han sido necesarios para que entiendan que la privacidad y la seguridad no son frenos, sino aceleradores de innovación?

[Beatriz Rodríguez] En los últimos años, el mercado ha experimentado una transformación significativa del papel del DPO. Cuando se implementó el RGPD en 2018, la función se percibía fundamentalmente como una figura obligatoria pero prescindible, centrada en revisar cláusulas informativas y gestionar ejercicios de derechos. Hoy, en las organizaciones que han avanzado en su cultura de cumplimiento, el DPO tiende a participar en los comités de transformación digital, en la adquisición o desarrollo de nuevos productos o servicios y en los procesos internos, aunque el grado de integración varía enormemente según el sector y la madurez de cada organización.

El cambio de mentalidad en la dirección ha requerido varios elementos: demostrar con casos concretos que los proyectos que integran “privacy by design” desde el inicio reducen fricciones posteriores, aunque no siempre suponen un ahorro neto, ya que la inversión inicial en análisis y diseño puede ser considerable; cuantificar el riesgo reputacional y económico de los incidentes de seguridad en términos que el Comité de Dirección pueda valorar, y posicionar la privacidad como elemento diferenciador ante determinados clientes, sobre todo en sectores regulados como el financiero o el sanitario, si bien en otros sectores este argumento tiene menor tracción comercial.

La clave ha sido pasar de un discurso de «no se puede» a uno de «cómo podemos hacerlo de forma razonable». Ahora bien, seamos realistas, no en todas las organizaciones el DPO ha logrado ese posicionamiento estratégico, y en muchas empresas del mercado español sigue siendo una función percibida como coste regulatorio más que como aportación de valor.

Este año pasado hemos realizado precisamente un estudio de análisis de madurez y ética digital en consejos de administración y alta dirección, y una de las conclusiones ha sido que, si bien el camino está trazado, la madurez del tejido empresarial es muy desigual, y que no siempre existe coherencia entre la adopción formal de políticas internas y su aplicación efectiva dentro de la organización.

[MCPRO] Supongo que RocaJunyent asesora a empresas en adopción de blockchain, IA y tecnologías disruptivas. Desde tu perspectiva de especialista en privacidad y seguridad, ¿cuáles son los tres mayores riesgos de gobernanza de datos que ves que los CTOs/CIOs subestiman al implementar estas tecnologías? ¿Cómo debería estructurarse una estrategia de compliance antes de comenzar la inversión tecnológica, no después?

[Beatriz Rodríguez] Los riesgos son muy distintos según el sector y el tipo de información que maneja cada entidad, pero hay tres problemas que veo de forma recurrente y que se subestiman sistemáticamente.

Primero, la deficiente identificación de activos críticos y clasificación de datos. Muchas organizaciones no tienen claro qué elementos de su infraestructura son realmente esenciales para la continuidad del negocio ni qué datos resultan verdaderamente imprescindibles. Puede parecer básico, pero es sorprendentemente frecuente: empresas que desconocen qué sistemas sostienen su operativa y qué información, de verse comprometida o perdida, les generaría un perjuicio real.

Normativas como DORA han obligado a madurar en este aspecto, precisamente porque imponen la obligación de identificar y mapear funciones críticas y sus dependencias tecnológicas. Sin embargo, hasta que ha llegado esa presión regulatoria, muchas empresas, sobre todo aquellas de menor tamaño que están innovando y creciendo rápidamente, simplemente no lo habían contemplado. Y sin ese ejercicio previo de identificación y clasificación, cualquier estrategia de protección o de cumplimiento se construye sobre cimientos muy débiles.

Segundo, no incorporar los requisitos regulatorios en el diseño de los productos y los modelos de datos desde el inicio. Esto tiene múltiples manifestaciones. Por ejemplo, implementar soluciones basadas en blockchain sin haber contemplado cómo van a poder los usuarios ejercitar sus derechos de protección de datos (supresión, rectificación) cuando la propia arquitectura de la tecnología lo dificulta enormemente.

O, en el ámbito de la Inteligencia Artificial, diseñar funcionalidades que a nivel de negocio parecen completamente inofensivas e incluso muy ventajosas, pero que en realidad constituyen usos prohibidos o prácticas expresamente sancionadas por la legislación vigente. Cuando estos problemas se detectan una vez que el producto ya está desarrollado o en el mercado, el coste de corregirlos es exponencialmente mayor que el de haberlos prevenido, y en algunos casos la corrección ni siquiera resulta viable sin rediseñar desde cero.

Tercero, la fragmentación de responsabilidades cuando intervienen múltiples proveedores tecnológicos. Dicho de forma llana: cuando una empresa utiliza cinco, diez o veinte proveedores distintos para construir su ecosistema tecnológico (que es lo habitual hoy en día), la cadena de quién responde de qué se vuelve enormemente confusa. Los contratos no siempre reflejan con claridad las responsabilidades de cada parte, y cuando ocurre un incidente, determinar quién ha fallado y quién debe responder se convierte en un ejercicio muy complejo.

Y si a esto le añadimos que muchos de esos proveedores son extranjeros, el problema se multiplica: el enforcement transfronterizo es extraordinariamente difícil y costoso. Perseguir contractualmente a un proveedor con sede fuera de la Unión Europea, hacer valer cláusulas de responsabilidad o simplemente obtener la colaboración necesaria tras un incidente de seguridad puede suponer procesos largos, jurisdicciones poco favorables y costes legales que muchas empresas, especialmente las medianas y pequeñas, sencillamente no pueden asumir.

La estrategia de compliance debería idealmente estructurarse en fases previas a la inversión: evaluación de impacto regulatorio del caso de uso, due diligence de proveedores tecnológicos y diseño de la arquitectura de gobernanza de datos. Dicho esto, hay que ser realistas con los costes; esta fase previa requiere recursos significativos (tanto internos como de asesoramiento externo) y no todas las organizaciones pueden o quieren asumirlos. El retorno de esta inversión es difícil de cuantificar, aunque la experiencia del mercado muestra que los proyectos que omiten esta fase suelen enfrentar problemas de cumplimiento más adelante.

[MCPRO] Leo en tu experiencia el asesoramiento en «estrategias de prevención, reacción y reparación». Para un CIO que hoy gestiona infraestructuras cada vez más distribuidas y complejas, ¿cuál debería ser el marco mínimo de preparación (governance, herramientas, cultura) para que una organización no sea reactiva ante un incidente, sino que pueda anticipar y contener? ¿Qué ves que falla más en las empresas españolas a nivel de madurez de ciberseguridad?

[Beatriz Rodríguez] El marco mínimo de preparación tiene tres patas que ya son conocidas: gobernanza (un comité de seguridad con representación de negocio, tecnología y legal, papeles claros y un plan de respuesta a incidentes testado periódicamente que sea realmente efectivo, no mero papel); herramientas de detección y respuesta adecuadas al tamaño y riesgo de la organización, y cultura (formación continua, simulaciones y un entorno donde reportar incidentes no penalice a quien lo hace). Pero esto es la teoría.

En la gran mayoría de empresas falta estrategia. En un entorno donde predominan las pymes, como el español, normalmente existe una externalización de los servicios de IT que incluye seguridad básica, pero que no alcanza al nivel de conocimiento de la dirección ni se traduce en la planificación de una verdadera estrategia de seguridad. Hay organizaciones que invierten en herramientas sofisticadas de threat intelligence pero que mantienen usuarios con privilegios excesivos y redes planas donde un atacante puede moverse lateralmente sin ninguna restricción, por mera comodidad operativa.

Otra gran asignatura pendiente es la gestión de terceros. Se audita internamente, se invierte en controles propios, pero luego se confía excesivamente en proveedores críticos que tienen acceso a sistemas y datos sensibles sin que exista una supervisión real sobre sus prácticas de seguridad.

A ello se suma una elevada dependencia de grandes proveedores con contratos de adhesión que dejan escaso margen para el control efectivo. Cuando ocurre un incidente a través de un proveedor, la empresa se encuentra con que no tiene visibilidad sobre lo sucedido, carece de palancas contractuales efectivas para exigir respuestas rápidas y, en muchos casos, ni siquiera tiene claro el perímetro de acceso de ese proveedor.

Mi mensaje es siempre el mismo: antes de buscar soluciones sofisticadas, hay que consolidar los fundamentos. No siempre hay que perseguir el último estándar del mercado ni la herramienta más avanzada. A veces lo que necesitas es revisar quién tiene acceso a qué, segmentar tu red adecuadamente y asegurarte de que tus proveedores críticos cumplen unos mínimos reales, no solo sobre el papel.

[MCPRO] Tu despacho asesora en «contratación de servicios tecnológicos» desde la óptica de compliance. Para un CIO que depende cada vez más de vendors cloud, SaaS y proveedores especializados, ¿cuáles son las cláusulas críticas de protección de datos y seguridad que debería exigir en contrato que hoy se negocian mal o se ignoran?

[Beatriz Rodríguez] Las cláusulas que veo frecuentemente mal negociadas o directamente aceptadas sin revisión son las siguientes, aunque conviene matizar que el poder de negociación del cliente varía enormemente según el proveedor y el volumen de contratación.

Empecemos con los acuerdos de nivel de servicio efectivos para el servicio de que se trate. Si tienes una aplicación turística, por ejemplo, no te sirve un SLA de lunes a viernes en horario laboral. Son cuestiones que normalmente no revisa la dirección y que a veces quedan ocultas en los contratos de forma que el equipo técnico tampoco las ha identificado en la oferta. Es fundamental tener claro quién hará qué y con qué coste antes de la firma.

A nivel de portabilidad y reversibilidad, disponer de cláusulas de salida que garanticen la recuperación de datos en formatos estándar, con plazos y costes predefinidos, es otro punto que suele fallar. Hay muchos proveedores que blindan sus contratos de forma que los clientes encuentran después dificultades significativas para migrar a otro proveedor, o se enfrentan a costes de salida muy elevados.

Algo fundamental también es el régimen de responsabilidad. Hay que revisar cuidadosamente los caps de responsabilidad y las exclusiones. Muchos contratos estándar limitan la responsabilidad a importes insuficientes ante un incidente grave. Cuando estamos ante proveedores con los que una negociación puede simplemente no ser viable, hay que seguir otras estrategias que deben poder ser activadas en paralelo, como seguros o diversificación de proveedores.

Conseguir derechos de auditoría y control efectivos es también complejo y suele desatenderse. Lo ideal es especificar alcance, frecuencia, preaviso, acceso a informes y posibilidad de auditorías por tercero independiente, pero hay que calibrar expectativas y centrarse en lo negociable. En la práctica, la mayoría de proveedores cloud de primer nivel solo aceptan facilitar certificaciones e informes de auditoría independiente, rechazando auditorías presenciales salvo para clientes de gran volumen.

Está también la parte relativa a cumplimiento en protección de datos. Es importante revisar los compromisos contractuales sobre ubicación de datos, subencargados y mecanismos de transferencia. Muchos contratos SaaS de proveedores estadounidenses incluyen cláusulas genéricas que pueden resultar insuficientes. Ahora bien, la realidad del mercado es que los grandes hyperscalers y proveedores SaaS dominantes rara vez negocian estas cláusulas con clientes medianos; en estos casos, la labor del asesor es documentar el análisis de riesgos y las medidas complementarias adoptadas.

En la notificación de incidentes, también es fundamental obligar al proveedor a comunicar en un plazo que permita cumplir a la empresa con sus propias obligaciones de notificación (recomiendo 24-48 horas máximo).

Por último, algo que no se tiene suficientemente en cuenta es evitar asumir compromisos de cumplimiento de leyes y normativas extranjeras cuyas implicaciones se desconocen (como el sometimiento a jurisdicción en otros territorios) y, al mismo tiempo, establecer cláusulas que contemplen el compromiso del proveedor de adaptarse a cambios regulatorios relevantes, como el Reglamento de Inteligencia Artificial.

[MCPRO] Estás en el Grupo de IA de APEP y participas en think tanks sobre regulación. Para un CTO/CIO que hoy invierte fuerte en IA pero ve cambios regulatorios a menudo, ¿cómo debería estructurarse internamente la función de compliance tecnológico para que la organización sea resiliente ante cambios normativos y no quede atrapada entre una inversión y un cambio de reglas?

[Beatriz Rodríguez] Es necesario que la empresa tenga cierta capacidad, interna o externalizada, para monitorizar el pipeline regulatorio (propuestas, borradores, consultas públicas) y traducirlo en impactos concretos para la organización. En materia de IA, por ejemplo, esto significa seguir no solo el desarrollo del AI Act, sino también las normas armonizadas, las guías de la Agencia Española de Supervisión de IA y la jurisprudencia emergente. No todas las organizaciones necesitan un equipo dedicado; para muchas, un servicio de alertas regulatorias combinado con revisiones periódicas con asesores externos puede ser suficiente y más eficiente en costes.

El principio de «cumplir con el estándar más exigente previsible» puede resultar atractivo a priori, pero en la práctica puede llevar a sobredimensionar inversiones en cumplimiento que nunca llegan a materializarse como obligatorias. Aquí es precisamente donde suele producirse el desencuentro entre el equipo legal interno y las áreas tecnológicas o de negocio, y donde mayor riesgo existe de que la función de compliance sea percibida como un freno.

Mi recomendación es pragmática: identificar las líneas rojas para la compañía y distinguir entre los requisitos que probablemente serán exigibles a medio plazo (y cuyo coste de implementación es razonable si se abordan desde el diseño) y aquellos cuya implementación anticipada supone un coste desproporcionado.

La clave está en un análisis de riesgos informado, no en la máxima de que «más cumplimiento siempre es mejor». El mercado español, además, tiene sus propios ritmos de enforcement que conviene tener en cuenta. El análisis debe ser proporcional al riesgo real del caso de uso y a la probabilidad efectiva de cambio regulatorio.

Para mí, uno de los mecanismos más efectivos es incorporar procesos de evaluación de impacto regulatorio integrados en el ciclo de vida de los proyectos tecnológicos, con hitos de revisión periódica. Del mismo modo que existen metodologías ágiles en el desarrollo de software, integrar puntos de control de cumplimiento normativo en la metodología de trabajo suele abaratar costes y facilitar la configuración de soluciones diseñadas desde el cumplimiento (compliance by design). Pero para ello se necesita una función de compliance tecnológico, interna o externa, que revise periódicamente el inventario de sistemas y soluciones tecnológicas frente al mapa regulatorio actualizado.