por VendorVet (LX AI)

Documentación técnica bajo el Reglamento de IA

Según el Reglamento (UE) 2024/1689, los proveedores de alto riesgo deben mantener una documentación técnica que demuestre la conformidad antes de la colocación en el mercado. Los equipos suelen ensamblar las piezas obvias y pasar por alto lo que los auditores abren primero: resúmenes de conjuntos de datos, diseño de supervisión humana y monitoreo después de la comercialización. Trate cualquier esquema generado como un borrador para verificar contra la Revista Oficial, no como una presentación final.

Qué cubre realmente la obligación de documentación

El artículo 11 y el anexo IV establecen el contenido de la documentación para sistemas de alto riesgo. El paquete abarca el propósito previsto, las elecciones de diseño, la historia de desarrollo y pruebas, las afirmaciones de rendimiento y las medidas de gestión de riesgos que realmente se ejecutaron. La Comisión resume el Acta como un marco basado en el riesgo con deberes más pesados para usos de alto riesgo; comience con ese marco antes de inventar una plantilla personalizada (Comisión Europea — Ley de IA).

El texto vinculante es el reglamento en sí en EUR-Lex (Reglamento (UE) 2024/1689). Los blogs y decks de diapositivas secundarios son útiles solo después de que pueda señalar el artículo y la fila del anexo que respalda cada afirmación. Trato la documentación como un conjunto de archivos vivos bajo control de versiones, no como un PDF de un solo tiempo exportado la semana anterior a una demostración.

Ciclo de vida, no una instantánea

Si el modelo cambia, el conjunto de entrenamiento se actualiza o un control de seguridad se reconfigura, la documentación debe mostrar el delta. Las notas de cambio, los propietarios y las fechas son tan importantes como la primera redacción. Cuando un desplegador pregunta "¿Qué versión estaba en producción el martes?", debe responder desde el mismo registro que respalda la conformidad — no desde un hilo de Slack.

Flujo de trabajo paso a paso que utilizamos antes de llamar a un paquete "listo"

- Confirme que el sistema es de alto riesgo (o será tratado como tal) según el artículo 6 / anexo III antes de inventar un árbol de documentación. Si no es de alto riesgo, no afirme la completitud del anexo IV en la copia de ventas. - Abra el anexo IV y cree una carpeta o ticket por tema: descripción general, especificaciones de diseño, proceso de desarrollo, datos, gestión de riesgos, pruebas, monitoreo y supervisión humana. - Asigne un solo propietario por tema. La propiedad compartida sin un nombre es cómo se mantienen las secciones vacías. - Redacte con el producto y la ingeniería en la sala. Los revisores legales examinan las afirmaciones; los ingenieros suministran rutas de evidencia (configuraciones, paneles de control, informes de pruebas). - Enlace cada afirmación a un artefacto: un resumen del conjunto de datos, un esquema de registro, un libro de ejecución, una fila del registro de riesgos. La prosa no enlazada es un olor. - Camine el paquete contra el sistema en vivo: ¿La configuración de registro coincide con las afirmaciones del artículo 12? ¿La ruta de anulación en la interfaz de usuario coincide con el texto del artículo 14? - Programe un desencadenador de actualización: incremento de la versión del modelo, cambio de conjunto de datos, nueva clase de desplegador o casi accidente grave.

VendorVet convierte estos temas en una lista de verificación funcional. No reemplaza el juicio de un cuerpo notificado o asesoramiento. Utilice el producto para detectar omisiones temprano; utilice el Diario Oficial para resolver argumentos.

Resúmenes de conjuntos de datos que los equipos de revisión omiten (Artículo 10)

El Artículo 10 espera una gobernanza de datos: los datos de entrenamiento, validación y prueba deben ser relevantes y representativos para el propósito previsto, con un examen de sesgos y lagunas que podrían perjudicar el rendimiento para las personas a las que el sistema afectará. Los auditores buscan un resumen de qué datos se utilizaron y cómo se examinaron — no una tarjeta de modelo de marketing con tres adjetivos.

Una fila de lista de verificación que dice "datos revisados" sin un resumen detrás de ella no supera la primera revisión seria. Escriba el resumen para que un nuevo ingeniero pueda responder: dominios de origen, ventanas de tiempo, sesgos conocidos, reglas de exclusión y cómo se produjeron o auditaron las etiquetas. Si los datos personales se encuentran en la canalización, mantenga sus roles y bases de GDPR consistentes con la forma en que describe el procesamiento en otros lugares; la biblioteca de orientación del EDPB es la verificación práctica para ese lenguaje (directrices y mejores prácticas del EDPB).

Lista de verificación — evidencia de datos

- Inventario de conjuntos de entrenamiento / validación / prueba con propiedad y fecha de última actualización - Notas de representatividad vinculadas al propósito previsto (quién está en el alcance, quién está fuera) - Método de examen de sesgos y errores — incluso si es imperfecto — con riesgo residual declarado - Proceso de etiquetado o anotación, incluyendo controles de calidad - Reglas de retención y acceso para los conjuntos de datos en sí mismos.

Diseño de supervisión humana (Artículo 14)

El Artículo 14 solicita una supervisión humana significativa: interfaces y controles que permitan a una persona monitorear, interpretar y anular los resultados cuando sea necesario. "Los humanos permanecen en el bucle" no es un mecanismo. Documente la ruta de anulación específica, quién puede ejercerla, cómo el sistema indica que un humano debe intervenir y qué sucede cuando el humano no está disponible.

En productos de agentes, esto suele significar una parada dura antes de una acción con consecuencias (publicación de la lista de preselección, envío de la decisión de crédito, actualización del archivo de casos), y no un botón de aprobación decorativo que se activa automáticamente después de tres segundos. Asocie la descripción de la interfaz de usuario con la política de tiempo de ejecución: qué roles, qué entornos, qué eventos de auditoría se activan cuando se utiliza la anulación.

Lista de verificación — Evidencia de supervisión

Monitoreo y registro de posventa (Artículos 12 y 72)

El Artículo 12 requiere un registro automático suficiente para la trazabilidad, con un mínimo de retención de seis meses para sistemas de alto riesgo. El Artículo 72 agrega deberes de informe de incidentes graves. Los equipos documentan el modelo y olvidan el plan de evidencia de tiempo de ejecución. Asocie la documentación con la configuración de registro real para que los dos estén de acuerdo.

Si ya ejecuta la observabilidad de GenAI, asocie los spans y eventos con las preguntas que se harán en una revisión de posventa: ¿qué clase de entrada, qué versión del modelo, qué decisión de política, qué acción humana? Las convenciones de GenAI de OpenTelemetry son una referencia de ingeniería práctica para nombrar esos campos de manera consistente en todos los servicios (OpenTelemetry — Observabilidad de GenAI). El Acto no obliga a OTel; las trazas consistentes simplemente hacen que las reclamaciones del Artículo 12 sean más fáciles de defender.

Errores comunes que vemos en paquetes de documentación

- Escribir para el folleto, no para el anexo. Los diagramas bonitos que nunca citan los temas del Anexo IV desperdician el tiempo de revisión. - Copiar una hoja de trabajo de RMF de EE. UU. y renombrarla "paquete de la Ley de IA." El Marco de Gestión de Riesgos de IA de NIST es útil para el vocabulario de procesos (NIST AI RMF), pero no es un sustituto del contenido del Artículo 11 / Anexo IV. - Documentar el modelo de ayer. La producción ya se movió; el paquete no. - Dejar las instrucciones de implementación vacías. La transparencia del Artículo 13 para los implementadores es fácil de omitir cuando el equipo del proveedor solo habla consigo mismo. - Llamar a una lista de verificación "certificada." Ese lenguaje sobredeclara. Las listas de verificación reducen el riesgo de omisión; no certifican la conformidad.

Criterios de decisión: enviar el paquete vs seguir redactando

Trate el paquete como bloqueador de lanzamiento para un lanzamiento de alto riesgo cuando cualquiera de los siguientes sea cierto:

- No hay resumen de conjunto de datos que un tercero pueda seguir - No hay mecanismo de supervisión humana descrito vinculado a un control real - Retención de registros inferiores a seis meses, o registros que no pueden reconstruir una decisión - Registro de riesgos sin propietarios de riesgos residuales - Propósito previsto tan vago que es imposible el mapeo de Anexo III

Todavía puede enviar prototipos internos que nunca tocan el uso de alto riesgo de la UE. Sea honesto sobre el alcance por escrito. El lenguaje ambiguo "cumplimos en espíritu" es peor que un estado claro "no es alto riesgo / no está en el mercado de la UE".

Qué no es esto

Esta página no es asesoramiento legal, no es una evaluación de un organismo notificado y no es una garantía de que su sistema se ajuste al Reglamento (UE) 2024/1689. VendorVet no afirma una cobertura del 100%, no inventa tasas de victoria del cliente y no reemplaza al asesoramiento o una evaluación de conformidad donde se requiera. Una lista de verificación le ayuda a ensamblar y verificar temas; el deber vinculante sigue siendo la documentación descrita en el Artículo 11 y el Anexo IV, propiedad de personas calificadas en su organización.

Cierre

Comience con el texto de la Revista Oficial, asigne los temas del Anexo IV a los propietarios, luego complete las tres brechas que los auditores abren primero: datos, supervisión y registro. Mantenga el paquete versionado con el sistema. Cuando el modelo o el conjunto de datos se mueva, mueva la documentación en el mismo tren de lanzamiento. Para la decisión de nivel de riesgo que se encuentra aguas arriba de todo esto, lea nuestra guía hermana sobre los niveles de riesgo de la Ley de IA de la UE.