Informe de brecha de remediación antes del lanzamiento en la UE

Por qué un informe de brechas es importante antes del lanzamiento

Cuando se prepara para lanzar un sistema de inteligencia artificial en la UE, debe demostrar que ha cumplido con las obligaciones establecidas en el Acta de IA. Un informe de brechas convierte esos requisitos legales en una lista concreta de tareas completadas y tareas que quedan por realizar. Esta lista es útil para los equipos internos, auditores y reguladores porque muestra exactamente dónde se necesita trabajo. No promete la conformidad; simplemente muestra el estado actual del esfuerzo.

Comenzamos leyendo el texto oficial del Acta y las directrices relacionadas de la Comisión Europea. Cada obligación se copia literalmente en una columna de una hoja de cálculo. Al lado de cada obligación, agregamos una columna para la evidencia (como un documento de política, un resultado de prueba o un comentario de código). Si la columna de evidencia está vacía, marcamos la fila como una brecha. La tabla resultante se convierte en la lista de trabajo que impulsa la remediación.

Dado que el Acta está escrita en lenguaje legal, traducimos cada oración a acciones claras. Por ejemplo, "proporcionar información clara sobre las capacidades del sistema de IA" se convierte en "crear una descripción orientada al usuario que enumere los tipos de entrada, los formatos de salida y las limitaciones conocidas". Este paso de traducción evita la mala interpretación y facilita la asignación de propietarios. Además, se deben considerar las implicaciones de la Ley de Inteligencia Artificial de la UE en los sistemas de IA como ClauseGuard, y las herramientas como. Es importante mencionar que este proceso no reemplaza las políticas de seguridad y privacidad, sino que las complementa.

Cómo mapeamos las obligaciones de la Ley a controles técnicos

El mapeo es la actividad principal que convierte el texto legal en trabajo de ingeniería. Utilizamos una tabla de tres columnas: Obligación, Control, Evidencia. La columna de Obligación contiene el texto exacto de la Ley. La columna de Control enumera la medida técnica o procedimental concreta que hemos implementado para satisfacer ese texto. La columna de Evidencia contiene una referencia a un artefacto (un enlace de documento, un registro de prueba o un archivo de configuración).

A continuación, se muestra un ejemplo de la tabla que mantenemos. Muestra un subconjunto de obligaciones relacionadas con la transparencia y el gobierno de los datos. La tabla se mantiene en una hoja de cálculo compartida para que los productos, legales y de ingeniería puedan actualizarla en tiempo real.

Obligación (texto de la Ley) | Control (lo que hacemos) | Evidencia (artefacto) Los proveedores deben garantizar que las personas físicas estén informadas de que están interactuando con un sistema de inteligencia artificial (Artículo 13(1)). | Agregar un banner persistente en la interfaz de chat que dice "Estás hablando con un asistente de inteligencia artificial". | Captura de pantalla del banner en el entorno de staging (enlace: internal/wiki/ai-banner). Los proveedores deben poner a disposición, de manera clara y accesible, información sobre las capacidades y limitaciones del sistema de inteligencia artificial (Artículo 13(2)). | Publicar una tarjeta de modelo que enumera el uso previsto, los modos de fallo conocidos y las métricas de rendimiento. | Tarjeta de modelo PDF almacenada en el repositorio de cumplimiento (ruta: docs/model-card-v2.pdf). Los proveedores deben implementar medidas de gobierno de datos adecuadas para garantizar que los datos de entrenamiento sean relevantes, representativos y estén libres de errores (Artículo 10(1)). | Ejecutar un script de calidad de datos nocturno que comprueba los valores perdidos, las inconsistencias de etiquetas y las muestras fuera de distribución. | Registro de salida del script para el último…

La tabla hace que sea fácil ver qué obligaciones tienen evidencia y cuáles no. Las filas de evidencia que faltan se convierten en los elementos de la lista de trabajo de remediación. Revisamos la tabla en cada reunión de planificación de sprint y asignamos propietarios para cerrar las brechas.

Construyendo la lista de trabajo: pasos que seguimos

Nuestro proceso para convertir el Acta en una lista de trabajo consiste en cinco pasos repetibles. Cada paso es realizado por un pequeño equipo cross-funcional que incluye a un analista legal, un gerente de producto y un ingeniero.

- Recopilar textos fuente – descargar la versión oficial del Diario de la Acta, las preguntas frecuentes de la Comisión y cualquier norma relevante (por ejemplo, los LLM Top 10 de OWASP o el NIST AI RMF). Almacenarlos en una carpeta de solo lectura. - Extraer obligaciones – copiar cada oración que impone un deber a los proveedores en una lista maestra. Utilizar la redacción literal; no parafrasear en esta etapa. - Traducir a acciones – para cada obligación, escribir una oración imperativa breve que describe qué debe hacerse para satisfacerla. Mantener la traducción bajo 20 palabras cuando sea posible. - Coincidir con controles – examinar las políticas, el código y la documentación existentes para ver si alguno ya cumple con la acción traducida. Si existe una coincidencia, enlazar la evidencia; si no, marcar una brecha. - Priorizar brechas – asignar una prioridad según el nivel de riesgo (alto, medio, bajo) y la estimación de esfuerzo (pequeño, medio, grande). Las brechas de alto riesgo y bajo esfuerzo se abordan primero.

Repetimos el ciclo siempre que la Acta se modifique o cuando lanzamos una nueva versión del modelo. La lista maestra vive en una página de Confluence que solo es editable por el líder de cumplimiento, asegurando una sola fuente de verdad.

Ejemplo: Obligaciones de transparencia (Artículo 13)

El Artículo 13 se centra en asegurarse de que los usuarios sepan que están interactuando con un sistema de inteligencia artificial y entienden lo que puede y no puede hacer. Para satisfacer esto, hemos tomado tres acciones concretas.

Primero, agregamos un aviso visible a cada punto final que enfrenta al usuario. El aviso aparece antes de la primera interacción y permanece hasta que el usuario lo descarta. Contiene la frase exacta requerida por la Ley: "Estás interactuando con un sistema de inteligencia artificial". El texto del aviso se almacena en el archivo de cadenas de la interfaz de usuario (ruta: src/i18n/en.json) y es verificado por nuestra suite de pruebas de interfaz de usuario automatizada.

Segundo, creamos una tarjeta de modelo que resume el uso previsto del modelo, las limitaciones conocidas y los números de rendimiento. La tarjeta sigue el formato sugerido en la guía de transparencia de OWASP LLM Top 10. Está alojada en nuestro sitio de documentación interna y enlazada desde la página de ayuda del producto.

Tercero, configuramos una revisión trimestral donde el equipo de producto verifica que el aviso aún aparezca después de cada lanzamiento de la interfaz de usuario y que la tarjeta del modelo refleje la última versión. Cualquier desviación crea un nuevo elemento de brecha que se agrega a la lista de trabajo.

Ejemplo: Obligaciones de gobernanza de datos (Artículo 10)

El Artículo 10 requiere que los proveedores aseguren que los datos utilizados para el entrenamiento sean adecuados y documenten los pasos tomados para abordar los sesgos. Abordamos estos requisitos a través de una combinación de controles automatizados y documentación manual.

Ejecutamos una tubería de calidad de datos cada noche que escanea el conjunto de entrenamiento en busca de valores perdidos, entradas duplicadas y errores de etiqueta. La tubería está construida utilizando componentes de código abierto y está configurada para que el proceso de construcción falle si se excede algún umbral crítico. Los registros de la tubería se archivan en nuestro depósito de cumplimiento (ruta: gs://clauseguard-compliance/data-quality/).

Para la mitigación de sesgos, mantenemos un registro vivo que lista cada intervención que hemos aplicado, como la re-muestra de grupos subrepresentados o el ajuste de los pesos de pérdida. El registro incluye la fecha, el motivo del cambio y el impacto medido en las métricas de equidad. Este registro satisface el requisito de documentación y es revisado por la junta de ética antes de cada lanzamiento de modelo.

También nos referimos al marco de gestión de riesgos de la inteligencia artificial de NIST (NIST AI RMF) al seleccionar controles para la gobernanza de datos. Las categorías del marco (Gobernar, Mapear, Medir, Administrar) nos ayudan a verificar que nuestra tubería cubra todos los aspectos necesarios.

Qué es esto NO

Este informe de brecha no es un certificado de conformidad. No garantiza que el sistema de inteligencia artificial cumpla con todos los requisitos de la Ley. No promete que los reguladores acepten las pruebas que proporcionamos. No afirma una tasa de éxito del 100 % para encontrar todas las posibles brechas. No asegura que la lista de tareas nunca omita un problema.

Cómo mantenemos el informe actualizado

Mantener un informe de brechas preciso requiere actualizaciones regulares. Hemos instituido un ritmo ligero que se ajusta a nuestro ciclo de sprint existente.

Al comienzo de cada sprint, el líder de cumplimiento ejecuta un script que compara la versión actual del Acta (descargada del portal oficial de la UE) con la lista maestra de obligaciones. Cualquier oración nueva o modificada se agrega como filas frescas. El script también verifica los enlaces de evidencia para ver si alguno se ha movido o se ha vuelto indisponible; los enlaces rotos se marcan para el propietario responsable.

Durante la retrospectiva del sprint, el equipo revisa la lista de brechas y marca los elementos como realizados cuando se sube y verifica la evidencia asociada. Los elementos completados se mueven a una pestaña de archivo para que sigan siendo accesibles para las auditorías, pero no obstaculizan la vista activa.

Cada trimestre, celebramos una reunión de revisión formal con los líderes legales, de producto y de ingeniería. En esa reunión, revisamos las brechas de alta prioridad, confirmamos las estimaciones de esfuerzo y ajustamos los plazos si es necesario. El resultado de la reunión es una nota de actualización breve que se agrega a la página de Confluence.

Referencias

- OWASP LLM Top 10 para Aplicaciones de Modelos de Lenguaje Grande - Marco de Gestión de Riesgos de Inteligencia Artificial de NIST