La mayoría de los problemas de cumplimiento son problemas de diseño

Si está creando software en la UE, el cumplimiento rara vez aparece al principio. Se vuelve relevante cuando el sistema empieza a importar. Usted tiene usuarios, posiblemente clientes, y la arquitectura ha crecido más allá de algo que pueda razonar completamente en su cabeza. Ese suele ser el momento en que aparecen las primeras preguntas reales. No abstractas, sino muy concretas. ¿Se pueden eliminar realmente los datos de un usuario en todo el sistema? ¿A dónde van esos datos una vez que salen de su aplicación? ¿Qué sucede exactamente cuando un servicio de terceros los procesa? Al principio, estas preguntas parecen preocupaciones legales o administrativas. En la práctica, no lo son. Son preguntas sobre el comportamiento del sistema. Si no puede responderlas, generalmente no es porque la regulación no esté clara. Es porque el sistema en sí mismo lo es.

Dónde las cosas realmente salen mal

El registro (logging) es un buen lugar para empezar porque casi todos los sistemas dependen de él. En las primeras etapas, se agrega el registro para facilitar la depuración. Registra IDs de solicitud, luego IDs de usuario, luego quizás direcciones de correo electrónico porque facilitan el seguimiento de casos de soporte. Más tarde, incluye partes de las cargas útiles de las solicitudes porque ayudan a reproducir casos extremos. Cada paso es útil y ninguno de ellos parece problemático. Ahora considere qué sucede cuando un usuario solicita que se eliminen sus datos: Usted elimina su cuenta de su base de datos principal. Esa parte es sencilla. Pero su dirección de correo electrónico todavía existe en los registros que se escribieron hace meses. Esos registros pueden almacenarse en un sistema de registro central, replicarse en diferentes regiones y conservarse por razones operativas. También pueden haberse reenviado a un servicio externo para su análisis. Incluso si quisiera eliminar esos datos, se encontrará rápidamente con limitaciones prácticas. Los registros a menudo son de solo escritura (append-only). Las copias de seguridad son inmutables. Las herramientas externas mantienen su propio almacenamiento y retención. En ese punto, el problema no es si se requiere la eliminación. El problema es que la eliminación nunca fue parte del diseño del sistema. El sistema se optimizó para la observabilidad y la confiabilidad, no para la eliminación controlada de datos.

Cuando su sistema deja de ser solo su sistema

Un patrón similar aparece con las integraciones de terceros. Tome una configuración común. Utiliza un proveedor de pagos para gestionar transacciones, una herramienta de análisis para comprender el comportamiento del usuario y una plataforma de soporte para gestionar solicitudes de clientes. Cada una de estas herramientas requiere alguna forma de datos del usuario para funcionar. Cuando un usuario se registra, sus datos fluyen a través de múltiples rutas: se almacena en su base de datos, se envía al proveedor de pagos para facturación, se pasa a análisis para seguimiento y posiblemente se incluye en tickets de soporte si se ponen en contacto con usted. Ahora imagine que le hacen una pregunta simple. ¿Qué sucede con los datos de este usuario si cierra su cuenta? Para responder eso adecuadamente, necesita rastrear cada ruta que han tomado los datos. No es suficiente eliminarlo de su propia base de datos. Necesita saber si existe en los sistemas de análisis, si se hace referencia a él en las herramientas de soporte y si lo conservan los proveedores externos. La mayoría de los equipos descubren en este punto que no tienen un mapa claro de estos flujos. No porque ignoraran el problema, sino porque cada integración se agregó de forma independiente, sin una imagen completa de cómo se mueven los datos a través del sistema en su conjunto.

Por qué la regulación expone esto

La regulación no introduce estos problemas. Le obliga a enfrentarlos. Marcos como el GDPR o la Ley de IA requieren que explique qué hace su sistema con los datos. Qué se recopila, cómo se utiliza, dónde se almacena y quién tiene acceso a él. Estos no son requisitos abstractos. Corresponden directamente al comportamiento real del sistema. Si su sistema envía datos de usuario a tres servicios diferentes, su explicación debe tener en cuenta a los tres. Si su sistema no puede eliminar datos de ciertos componentes, esa limitación se vuelve visible. Es por eso que el cumplimiento a menudo se siente difícil. No porque las reglas sean intrínsecamente complejas, sino porque el sistema nunca fue diseñado para proporcionar respuestas claras.

Cómo los sistemas se vuelven difíciles de razonar

El problema subyacente rara vez es una sola mala decisión. Es una acumulación: conserva registros más tiempo del necesario porque podrían ayudar con la depuración futura. Almacena atributos de usuario adicionales porque podrían ser útiles para funciones posteriores. Agrega herramientas porque resuelven problemas inmediatos. Con el tiempo, los datos terminan en múltiples lugares, a menudo con diferentes períodos de retención y controles de acceso. Algunos se utilizan activamente, otros no, y algunos simplemente se olvidan. Por ejemplo, el correo electrónico de un usuario puede existir en su base de datos principal, en registros históricos, en conjuntos de datos de análisis exportados y en conversaciones de soporte archivadas. Cada una de estas ubicaciones es válida por sí sola. Juntas, dificultan responder una pregunta simple como "¿dónde se almacenan los datos de este usuario?" Sin un modelo claro de cómo se distribuyen y gestionan los datos, cualquier requisito que dependa del control se vuelve difícil de implementar.

Qué cambia si lo trata como un problema de diseño

La alternativa no es introducir procesos de cumplimiento pesados. Es tomar ciertas decisiones explícitamente antes. Al diseñar el registro, decide qué tipo de datos pertenecen allí. Por ejemplo, podría optar por registrar identificadores internos en lugar de registrar directamente datos personales, y mantener el mapeo en una ubicación controlada. De esa manera, los registros siguen siendo útiles para la depuración, pero son menos sensibles y más fáciles de gestionar. Al integrar servicios externos, define qué datos se comparten y con qué propósito. En lugar de reenviar objetos de usuario completos a análisis, podría enviar solo datos a nivel de evento que sean suficientes para el análisis pero que no expongan detalles innecesarios. Almacenar datos, define cuánto tiempo deben seguir siendo relevantes. Por ejemplo, los registros operativos detallados solo pueden ser necesarios durante un período limitado, después del cual los datos agregados son suficientes. Hacer esa distinción temprana evita que el sistema acumule datos indefinidamente. Estas decisiones no eliminan la complejidad, pero la mantienen acotada. Más importante aún, aseguran que el sistema se comporte de manera predecible.

Un marco más útil

El cumplimiento a menudo se trata como una lista de verificación o un hito. En la práctica, se comporta más como una propiedad del sistema. Si el comportamiento del sistema no está claro, el cumplimiento siempre requerirá esfuerzo. Cada pregunta desencadenará una investigación. Cada requisito requerirá ajustes en múltiples componentes. Si el comportamiento del sistema se define a través del diseño, el cumplimiento se convierte en una cuestión de describir esos comportamientos. El mismo sistema que es más fácil de operar y depurar también es más fácil de explicar.

La relevancia de esto en el diseño

Para los equipos que desarrollan en la UE, estas preguntas surgirán tarde o temprano. Cuando lo hagan, el costo del cambio dependerá de cómo se diseñó el sistema: si los flujos de datos son implícitos y están ampliamente distribuidos, cambiarlos es difícil. Si son explícitos y controlados, los cambios son más manejables. La mayoría de los problemas de cumplimiento se originan en decisiones ordinarias. Qué se registra, qué se almacena, qué se comparte y cuánto tiempo persiste. Estas decisiones definen el sistema mucho antes de que se evalúen desde una perspectiva de cumplimiento. Comprender eso es el punto de partida.