El pasado 28 de abril participamos en la séptima edición del Cybersecurity & Data Innovation Summit celebrado en Madrid. La jornada reunió a más de trescientos directores de seguridad, arquitectos y responsables de protección de datos, y dejó una conclusión que ya no admite matices: la presión regulatoria sobre los entornos no productivos ha dejado de ser una conversación interna entre equipos de seguridad para convertirse en un asunto con plazos contractuales y responsabilidad personal.
Nuestro CTO, Ricardo Martínez, expuso un caso de uso técnico bajo el título "Anonimización de datos en entornos multitecnología". La postura que defendimos en el escenario y en el área expositiva se formula en seis palabras: si el dato es real, el riesgo es real.
El problema estructural de los entornos no productivos
Las organizaciones medianas y grandes mantienen una media cercana a las treinta copias completas de bases de datos productivas en sus entornos de desarrollo, QA, staging y entrenamiento de modelos. Cada una de esas copias contiene datos personales reales. Cada una hereda la carga regulatoria del sistema del que procede. Ninguna hereda los controles de seguridad equivalentes.
Durante años, el argumento técnico que justificaba esta práctica fue operativo. Las herramientas de enmascaramiento tradicionales rompían los esquemas relacionales. Los tests dejaban de pasar con los datos transformados. Los equipos de desarrollo recurrían a copias directas de producción para mantener la velocidad de entrega, y la anonimización quedaba como política declarada en documentos, no como comportamiento del sistema.
Lo que el sector reconoce ahora, públicamente y en privado, es que ese trade-off ya no es defendible. Por la presión regulatoria, que ha trasladado la responsabilidad final a los consejos de administración. Y por la presión técnica, que ha demostrado que existen arquitecturas capaces de anonimizar sin romper la utilidad funcional del dato.
NIS2, DORA y AI Act: el triángulo que dominó la jornada
El bloque previo a la sesión técnica de Gigantics fue el debate "Responsabilidad Directiva y el Tsunami Regulatorio". Un panel de juristas y consultores analizó el solapamiento de NIS2, DORA, AI Act y Cyber Resilience Act sobre las entidades esenciales y financieras españolas. Las implicaciones operativas que se trataron en el panel son directas y tienen plazo concreto.
NIS2 exige medidas técnicas y organizativas a lo largo de toda la cadena de datos, incluidos los entornos no productivos. La transposición española sigue pendiente, pero los partners europeos ya están solicitando evidencia de cumplimiento como condición contractual. El Artículo 20 de la Directiva traslada la responsabilidad final a los órganos de dirección, con posibilidad de inhabilitación temporal en casos de negligencia acreditada.
DORA introduce un matiz que muchas entidades financieras todavía están operacionalizando. Las pruebas de resiliencia operativa que la regulación exige se ejecutan, en la práctica, sobre entornos que contienen datos reales de clientes. Cada uno de esos entornos amplía el perímetro regulatorio de la entidad a cada proveedor TIC con acceso a ellos.
El AI Act introduce obligaciones documentales sobre los datasets utilizados para entrenar modelos clasificados como de alto riesgo. Cuando un auditor pida la composición exacta del dataset de entrenamiento de un modelo en producción, la mayoría de organizaciones no estará en condiciones de responder con precisión.
Las tres normativas convergen sobre un mismo punto técnico. Los datos sensibles no deben existir sin control fuera de los entornos productivos. Una formulación que el RGPD ya recogía en el principio de minimización del Artículo 5.1.c, y que ahora se refuerza desde la perspectiva de la cadena de suministro y la resiliencia operativa.
Por qué importa el adjetivo "multitecnología"
Hace una década, el debate sobre anonimización podía darse asumiendo un único motor de base de datos relacional. Esa hipótesis ya no se sostiene. Las organizaciones operan combinaciones de PostgreSQL, MongoDB, Oracle, SQL Server, Snowflake, Elasticsearch y, cada vez con más frecuencia, almacenes vectoriales para casos de uso de IA. Cada motor tiene su modelo de datos, sus identificadores, su forma de representar relaciones.
Las herramientas tradicionales de enmascaramiento se diseñaron antes de esta complejidad. Aplican transformaciones campo a campo, sin conocimiento del esquema completo ni de las relaciones entre sistemas. El resultado es predecible: identificadores que dejan de coincidir entre la base SQL y la NoSQL, foreign keys huérfanas, validaciones de aplicación que rechazan los datos transformados.
La consecuencia operativa también es predecible. Cuando los tests dejan de pasar con datos enmascarados, los equipos de desarrollo recurren a copias directas de producción. Una herramienta de cumplimiento que nadie usa pasa a ser, en términos de riesgo, equivalente a no tener herramienta.
La integridad referencial cross-database no es una característica añadida sobre el motor de anonimización. Es la condición arquitectural que determina si la anonimización se sostiene en el tiempo o se abandona en el segundo trimestre.
Si el dato es real, el riesgo es real
Un dato real fuera de producción no es un dato menos sensible por encontrarse en un entorno marcado como "no crítico". Tiene exactamente el mismo valor para un atacante. Tiene exactamente la misma carga regulatoria bajo RGPD. Y, en muchos casos, está sujeto a controles de seguridad inferiores a los del sistema productivo del que procede.
Las brechas de seguridad de los últimos doce meses muestran un patrón consistente. Los atacantes ya no necesitan llegar a producción. Les basta con encontrar el entorno de desarrollo que contiene una copia operativa de los datos productivos y proteger menos el acceso. El incidente de Vercel del pasado abril, originado por una herramienta de IA de terceros que accedió a variables de entorno con credenciales reales, fue uno de los ejemplos comentados durante el evento.
La conclusión técnica es directa. Si los entornos no productivos contienen datos funcionalmente equivalentes a producción pero sin valor real, el atacante que llegue a ellos no encontrará nada que extraer. La carga regulatoria sobre esos entornos se reduce a la naturaleza técnica del dato que contienen. Y la diligencia debida del consejo de administración pasa a tener una traducción operativa concreta y demostrable.
Lo que confirma el sector
Las conversaciones mantenidas durante la jornada confirmaron tendencias que veníamos detectando con clientes en España y Europa.
Banca y seguros operacionalizan DORA hacia entornos de prueba. Los CISOs consultados durante el evento comparten una preocupación específica. Las pruebas de resiliencia operativa que DORA exige se ejecutan, en la mayoría de los casos, sobre entornos que contienen datos reales de clientes. Reducir ese perímetro mediante anonimización con integridad referencial deja de ser una optimización operativa y se convierte en un requisito de cumplimiento.
Los pipelines de IA están entrando en zona de auditoría. Los responsables de plataforma de varias organizaciones tecnológicas mencionaron, de forma independiente, el mismo problema. La presión por iterar rápido en casos de uso de IA generativa choca con la imposibilidad de demostrar, ante un auditor del AI Act, qué datos personales entraron en el dataset de entrenamiento. La capa de descubrimiento y anonimización aplicada antes del pipeline de entrenamiento está pasando de ser opcional a obligatoria.
Los Data Architects piden coherencia, no más herramientas. El problema más operativo llegó por boca de los arquitectos de datos. La anonimización tradicional rompe sus esquemas. Los datos sintéticos puros pierden distribución estadística y limitan la capacidad de detectar bugs reales. La aproximación que combina anonimización determinista con preservación referencial es, para la mayoría de ellos, la única vía técnicamente sostenible.
La anonimización como propiedad del sistema
La anonimización de datos en entornos no productivos lleva años discutiéndose en informes regulatorios y papers académicos. Lo que defendimos en el Cybersecurity & Data Innovation Summit es que la traducción de esa exigencia teórica a un comportamiento técnico ejecutable y auditable es hoy una decisión arquitectural al alcance de cualquier organización con stack heterogéneo.
La integridad referencial cross-database, la política versionada como código y la ejecución local-first dejan de ser capacidades técnicas para convertirse en condiciones de cumplimiento. Sin las tres, el control regulatorio sobre los entornos no productivos se sostiene sobre documentación; con las tres, se sostiene sobre el comportamiento del sistema.