El delegado de protección de datos (DPD) de un grupo de e-commerce de tamaño medio de Europa Central llevaba meses con un hallazgo abierto. Los datos de clientes y pedidos estaban repartidos entre los servicios de analítica de un hiperescalar estadounidense, y la cuestión de las transferencias de datos a raíz de Schrems II no tenía una respuesta clara. El grupo tiene varios cientos de empleados y unos pocos millones de compradores activos, y su plataforma de datos de e-commerce era un conjunto de servicios gestionados que operaban bajo una jurisdicción ajena.

La sentencia Schrems II del Tribunal de Justicia, de 16 de julio de 2020, invalidó Privacy Shield y dejó en manos del exportador la evaluación de cada transferencia. El Marco de Privacidad de Datos UE-EE. UU. adoptado en 2023 ofrece a las empresas estadounidenses certificadas una vía de adecuación, y el DPD lo tuvo en cuenta. Pero una decisión de adecuación que ya ha sido impugnada ante los tribunales es una base endeble para los historiales de compra de millones de compradores, y el DPD quería cerrar el hallazgo con hechos documentados.

Conviene ser justos con el hiperescalar: sus servicios de analítica son maduros, están bien integrados y permiten empezar rápido. Por eso el entorno había crecido allí. En cuatro años, las exportaciones de pedidos, los feeds de stock y los datos de campañas se habían ido acumulando en varios servicios, cada uno incorporado por una buena razón local.

El coste de ese crecimiento se había convertido en un segundo problema. Los dashboards, los trabajos de reverse-ETL y los notebooks de un equipo de ciencia de datos sacaban datos de la plataforma, y la partida de salida de datos crecía más rápido que la base de compradores.

Qué ejecutaba el cliente

Antes de empezar, mapeamos el entorno junto con el equipo de datos del cliente. Había cinco fuentes de referencia y tres lugares donde se combinaban:

  • datos de pedidos y devoluciones de la plataforma de la tienda;
  • datos de stock y de preparación de pedidos del sistema del almacén;
  • datos de rendimiento de campañas y de email, incluidos identificadores de clientes;
  • un almacén de objetos compartido con exportaciones en bruto;
  • dos servicios de analítica de tipo data warehouse y una herramienta de BI que leía de ambos.

La actualización nocturna de los informes se ejecutaba como una cadena de trabajos que recorría todos estos elementos. Terminaba a media mañana, de modo que el equipo de merchandising abría sus primeros dashboards con las cifras de ayer y tomaba decisiones de precios y promociones con un stock desfasado.

Cómo construimos el data lake en la UE

Definimos el alcance de la construcción con el cliente y la entregamos como una plataforma de datos en nuestro datacenter de Múnich, un centro que el cliente eligió por su acceso al mercado de Alemania, Austria y Suiza y por su cercanía a sus equipos. El cliente trabaja en un tenant aislado por cliente: orquestación, un data lake, notebooks, dashboards y MLOps, con copias de seguridad incluidas. La operamos nosotros para el cliente, así que su equipo de datos trabaja en modelos e informes y no en mantener la plataforma en pie.

El data lake en la UE se convirtió en el único lugar para los datos de pedidos, stock y campañas. Los datos que almacenamos o transmitimos se cifran en tránsito y en reposo, con claves gestionadas por DIVERSITY. Solo el personal autorizado de DIVERSITY ubicado en la UE puede acceder a la infraestructura, y el acceso administrativo queda registrado y exige autenticación multifactor.

«Un hallazgo sobre el riesgo de las transferencias se cierra cuando puedes demostrar dónde se procesa cada flujo, no cuando argumentas que el riesgo es aceptable.»

Documentar cada flujo de datos personales

El hallazgo del DPD tenía que ver tanto con las pruebas como con la arquitectura. Para cada pipeline que tocaba datos personales, registramos el origen, los campos implicados, el lugar donde se procesan y almacenan, y las personas y los sistemas que pueden leerlos. El equipo de datos del cliente y el DPD revisaron ese registro juntos, flujo por flujo, antes de mover cualquier tráfico de producción.

El registro también sacó a la luz dos flujos que nadie había listado: una exportación de campañas que copiaba identificadores de clientes en un bucket temporal y un trabajo de notebook que guardaba en caché datos de pedidos en el espacio de trabajo de un analista. Ambos se eliminaron durante la construcción, con lo que desapareció un riesgo que el hallazgo original ni siquiera había descrito.

Cómo pudo el cliente dejar la analítica del hiperescalar

No hicimos el corte en un fin de semana. Durante seis semanas los entornos antiguo y nuevo funcionaron en paralelo, y cada mañana comparábamos los resultados tabla por tabla: recuentos de filas, totales de ingresos por canal, posiciones de stock por almacén. Las diferencias iban a una lista compartida y cada una se rastreaba hasta una regla de transformación, una suposición sobre la zona horaria o un archivo que llegaba tarde.

La herramienta de BI se fue redirigiendo grupo de dashboards a grupo de dashboards, empezando por los informes de finanzas y terminando por los de merchandising. El equipo de ciencia de datos fue el último en migrar, porque los notebooks arrastran más costumbres locales. Sus herramientas en la nueva plataforma difieren de las que usaban antes, y les llevó unas semanas reconstruir sus hábitos de trabajo; estuvimos a su lado durante ese periodo.

Los servicios de analítica antiguos solo se apagaron después de que el DPD diera el visto bueno al registro y de que el equipo financiero del cliente hubiera conciliado un cierre mensual completo en la nueva plataforma.

Qué cambió

Los resultados, según los comunica el cliente:

  • Actualización de informes: la actualización nocturna que antes terminaba a media mañana ahora se completa antes de que el equipo de merchandising empiece a trabajar, de modo que las decisiones de precios y promociones usan el stock de esa misma mañana.
  • Coste: la factura mensual de analítica bajó aproximadamente una cuarta parte. El ahorro vino sobre todo de eliminar los cargos por salida de datos que generaban todos los dashboards, exportaciones y notebooks.
  • Riesgo de transferencia: el DPD cerró el hallazgo abierto sobre el riesgo de transferencia en el entorno de analítica, partiendo del registro de flujos y de las ubicaciones de procesamiento que documenta.

El cliente también puede sacar sus datos. Las instancias, las bases de datos y el contenido de Object Storage se exportan en formatos documentados, sin cargos por cambio de proveedor ni por salida de datos, lo que mantiene la plataforma como una elección y no como una dependencia de proveedor.

Qué no cubre esto

El alcance fue el entorno de analítica. El cliente sigue usando SaaS de terceros para el envío de emails y la publicidad, y esos servicios tienen sus propios flujos de datos, que el DPD revisa por separado. Reducir los costes de salida de datos de la nube fue un efecto bienvenido del cambio, y el motivo del cliente para actuar fue el hallazgo sobre las transferencias.

Si tu analítica está en un hiperescalar y tu DPD tiene abierto el mismo hallazgo, sirve el mismo método: mapear los flujos, construir la plataforma en un centro que elijas, ejecutar ambos entornos en paralelo y cerrar el hallazgo con pruebas. Los detalles de este proyecto están disponibles bajo NDA.