Each language version is independently generated for its own context, not a direct translation.
Imagina que construir un software es como construir un rascacielos.
Hace años, los arquitectos y constructores solo se preocupaban por que el edificio no se cayera y fuera bonito. Pero hoy, hay miles de nuevas leyes (regulaciones) sobre cómo debe ser ese edificio: "debe tener ventanas anti-alarma", "los ascensores deben ser accesibles para sillas de ruedas", "no puede haber fugas de datos personales".
El problema es que los constructores (ingenieros de software) hablan un idioma técnico, y los abogados hablan un idioma legal lleno de palabras complejas. A menudo, los constructores intentan cumplir estas leyes "al vuelo" o de forma desordenada, lo que lleva a errores costosos o a edificios ilegales.
Este paper es el trabajo de tesis doctoral de Oleksandr Kosenkov, quien quiere solucionar este caos. Aquí te explico su idea usando una analogía sencilla:
1. El Problema: Dos idiomas que no se entienden
Actualmente, cuando una empresa quiere cumplir la ley (por ejemplo, la ley de protección de datos), suele hacerlo de dos formas equivocadas:
- Opción A: Contratan a un abogado al final del proyecto para que revise si todo está bien (como si un inspector viniera cuando el edificio ya está terminado).
- Opción B: Intentan seguir la ley, pero lo hacen de forma desordenada, sin un plan claro, creando "parches" que no encajan con el diseño original.
El autor dice: "¡No! Necesitamos integrar la ley desde el primer día, desde el plano inicial. Esto se llama 'Cumplimiento por Diseño'".
2. La Solución: El "Mapa de Tesoros" (AM4RRE)
Para unir a los abogados y a los ingenieros, el autor ha creado un modelo llamado AM4RRE. Imagina que este modelo es un mapa de tesoros o un manual de instrucciones universal que todos pueden entender, sin importar si son abogados o ingenieros.
En lugar de decirles qué actividades hacer (como "reunirse el lunes"), el modelo les dice qué información (artefactos) deben crear y cómo conectarla.
El mapa tiene 5 partes clave:
- Quién es quién (Roles): Define quién hace qué (el abogado, el experto en el tema, el ingeniero de requisitos, el arquitecto de software).
- Qué queremos lograr (Objetivos): ¿Qué busca el abogado? ¿Qué busca el ingeniero?
- El contexto (Por qué): ¿Qué leyes aplican? ¿Qué desafíos tenemos?
- El cuándo (Hitos): ¿En qué momento del proyecto se debe hacer cada cosa?
- El contenido (Qué escribimos): Aquí está la magia. Define exactamente qué debe escribir cada persona.
- El abogado escribe la "Especificación Legal" (ej: "El usuario debe poder borrar sus datos").
- El ingeniero escribe la "Especificación de Software" (ej: "Crear un botón de 'Borrar Cuenta' en la base de datos").
- El truco: El modelo asegura que lo que el abogado pide se conecte perfectamente con lo que el ingeniero construye.
3. La "Traducción" (Ajuste del Modelo)
El modelo no es rígido. Funciona como un adaptador de enchufes universal.
- Adaptación por Ley (T1): Si la ley cambia (por ejemplo, de una ley de privacidad a una de accesibilidad), el modelo se ajusta para traducir los conceptos de esa ley específica.
- Adaptación por Proyecto (T2): Conecta los conceptos legales con los técnicos. Por ejemplo, si la ley habla de "Sujeto de Datos", el modelo le dice al ingeniero: "Eso es lo mismo que tu 'Usuario Registrado' en el sistema". Así evitan duplicar trabajo o malentendidos.
- Adaptación por Metas (T3): Si la empresa quiere priorizar ciertas cosas, el modelo ayuda a enfocarse en lo importante.
4. ¿Qué sigue? (El Futuro)
El autor ya ha creado este "mapa" y ha probado partes de él con expertos. Ahora, el siguiente paso es probarlo en la vida real.
Quiere ver si, usando este modelo (y herramientas sencillas como listas de verificación o plantillas), los equipos de trabajo pueden construir software que cumpla la ley de forma natural, sin dolor de cabeza y sin tener que rehacer todo al final.
En resumen
Este paper propone dejar de tratar las leyes como un obstáculo que aparece al final del camino. En su lugar, propone un sistema de traducción y planificación (el modelo AM4RRE) que permite a abogados e ingenieros trabajar juntos desde el principio, asegurando que el software sea legal, seguro y útil desde su primer boceto.
Es como pasar de intentar arreglar un coche mientras se conduce, a tener un manual de instrucciones claro que te dice cómo construir el coche para que nunca se averíe.