Nivel 4 · En profundidad — Art. 12, DORA y los artículos revisados

§4 — Artículo 12 en profundidad: el registro de actividades es registro git-nativo

Los Niveles 1 a 3 conocieron los artículos 9 a 15 ligeramente o de uno en uno. El primer artículo en profundidad del Nivel 4 es el Art. 12 (registro de actividades) — y es profundo de una forma única en este motor: el grafo de commits es el registro.

El artículo 12 obliga a un sistema de alto riesgo a registrar automáticamente eventos («registros») a lo largo de su vida útil para que su funcionamiento sea trazable. La mayoría de las plataformas lo leen como telemetría en tiempo de ejecución — un flujo de eventos emitidos por un modelo en ejecución. Este motor lo lee ex ante y git-nativo: cada evento de gobernanza es un commit (en texto plano) y el registro es la propia historia git inmutable y de solo adición; lo que va firmado es la evidencia (bundle.json y las conformidades). Concretamente, en el repositorio de crédito:

• El ciclo de vida está en actos firmados, no en una base de datos. La solicitud es el acto .froga/acts/NNNN-request.json; la aprobación es .froga/acts/NNNN-approve.json (sobres DSSE firmados ECDSA-P256, verificados contra signers:). No hay ningún campo de «estado» mutable en ninguna parte — el estado es qué actos firmados existen en la historia. Eso es a prueba de manipulaciones por construcción: reescribir un acto invalida su firma y cambia el hash del commit y el de todos sus descendientes, y la evidencia firmada (bundle.json) fija aparte qué se aprobó.
• La evidencia está anclada. El bundle.json firmado lleva un pipeline_lock_digest — el resumen del pipeline bloqueado (datos + código + parámetros) que produjo los números medidos. El registro no dice simplemente «esto fue aprobado»; fija exactamente qué modelo, sobre qué datos, con qué umbral, obteniendo qué residual fue aprobado.
• Todo el grafo es reproducible. Como cada hito es un commit y los resúmenes están fijados, el requisito de registro de actividades se satisface no con un fichero de registro aparte, sino con la propia evidencia versionada — git log es la pista de auditoría; git diff entre dos hitos es el registro de cambios.

El artículo 12 aquí es un entregable / pista de papel, NO un control de barrera

Esto importa para la honestidad: el Art. 12 no es una barrera medida y bloqueante (como la robustez del Art. 15 o la barrera de equidad de este nivel). Es una obligación de registro de actividades — el motor la satisface produciendo una pista de papel completa, firmada y reproducible, y la muestra en el dossier del Anexo IV. No hay «Art. 12 ROJO». El encuadre honesto es: el Art. 12 es documentación de registro, git-nativa y ex ante, y su calidad se juzga por completitud y resistencia a la manipulación, no por un umbral de aprobado/fallado.

Por qué este es el lugar correcto para conocer el Art. 12 en profundidad — el ancla SCHUFA. Una puntuación de crédito al consumo es una decisión automatizada sobre una persona, que es exactamente el territorio del Art. 22 del RGPD y la sentencia del TJUE en el caso SCHUFA (C-634/21): una salida de puntuación de crédito automatizada que decide efectivamente el acceso de una persona al crédito activa derechos del interesado — incluyendo un derecho a revisión humana significativa de la decisión. Un derecho a revisión humana solo es operativo si existe un registro para revisar: qué modelo, qué datos, qué umbral, qué residual fue aceptado, y por quién. El registro git-nativo del Art. 12 hace esa revisión posible — git diff el modelo, el conjunto de datos, el umbral de decisión y el residual firmado, y el revisor puede ver exactamente qué se decidió y sobre qué base. (SCHUFA es el ancla para por qué el registro de actividades importa en crédito; este nivel no litiga el caso — fundamenta la obligación.)

El límite honesto del Art. 12 git-nativo

El registro de actividades git-nativo cubre código, modelo, conjunto de datos y reproducibilidad de decisiones — qué se entrenó, sobre qué datos, con qué parámetros, obteniendo qué residual, aprobado por quién. No cubre resiliencia de infraestructura: copias de seguridad y objetivos de RTO/RPO, conmutación por error, resultados de pruebas de penetración, clasificación de incidentes. Esos son registros operativos TIC — y, notablemente, pertenecen al mundo de DORA, no al registro de reproducibilidad del Art. 12. Confundir «tenemos un historial git completo del modelo» con «tenemos registros de resiliencia operativa TIC» es exactamente el tipo de reclamación excesiva que guarda el §5 sobre DORA.

---

§5 — DORA = el Registro (un entregable, no un veredicto)

Ahora la superposición financiera da sus frutos — y también la honestidad. El sistema declaró eu/dora@2022 con un bloque dora.entity, así que el plano de control ensambla un Registro de Información DORA a partir del paquete firmado. El ensamblador (cloud/lib/froga/dora-roi.ts) es puro y determinista: deriva el registro a partir del paquete ya verificado, proyectándolo sobre la plantilla xBRL-OIM de las AES (Taxonomía EBA 4.0). Las tablas mínimas:

• B_01.01 — la entidad notificadora. LEI, nombre legal, país, tipo de entidad (credit_institution), fecha de referencia — directamente del bloque dora.entity.
• B_07.01 — la función TIC. Un id de servicio (<lei>-<system_name>), la descripción de la función (nombre del sistema + propósito previsto), la última fecha de evaluación de riesgos (la fecha del commit del paquete), y un resultado de evaluación de riesgos proyectado desde el nivel residual del motor a través de DORA_VOCAB.
• B_05.01 — proveedores TIC directos de terceros. Se rellena a partir del ML-BOM (el inventario de materiales CycloneDX que emite la cadena DVC): el PURL de cada componente se coteja con una lista depurada de proveedores TIC conocidos, sin duplicados por LEI.

El Registro DORA es un entregable firmado + cruce documental, NO un veredicto de conformidad

Lee qué es el registro — y qué no es. Es una proyección fiel y firmada de lo que se midió y declaró en la plantilla de notificación del supervisor — un entregable que el responsable de cumplimiento de la entidad entrega, la contrapartida financiera del cruce documental MDR de la retina. Es documentación, no una declaración de que el sistema es conforme a DORA. La razón estructural es la misma que la del MDR: DORA es derecho sectorial vinculante, no una norma armonizada de gestión del riesgo en IA citada para el artículo 9, así que se sitúa fuera de la cadena de autoridad de veredictos del motor y no confiere ninguna presunción. Titúlalo: «entregable firmado + cruce documental, NO un veredicto de conformidad». Llamar al sistema «DORA gobernado» porque lleva este Registro es la reclamación excesiva que este curso rechaza. El veredicto de conformidad sobre la equidad del modelo es el veredicto de la Ley de IA / ISO 23894 — y aquí cierra en VERDE tras el tratamiento (medido con potencia real, OOF sobre las 1.000 filas).

El catálogo DORA no tiene invocadores de medidas — así que la proyección de cláusulas no es el entregable. Si ejecutaras froga conformance --standard eu/dora@2022, encontrarías que ninguna medida en froga.yaml cita una cláusula dora.* — la única referencia DORA en cualquier parte es eu/dora@2022#art-6 llevada como una etiqueta frameworks consultiva en la medida de equidad, no como invocadora de standard_clauses. Cualquier marcador «cubierto» cruzado que muestre el pliegue DORA proviene de criterios estructurales (el sistema tiene un marco de riesgos, tiene una evaluación residual), nunca de una medida que demuestre una cláusula DORA. La lección: enseña el Registro, no la cobertura de cláusulas. El entregable DORA de valor es el Registro de Información firmado, no un veredicto por cláusula que el catálogo nunca estuvo preparado para producir.

Los marcadores de honestidad — declarados, no maquillados:

• El LEI es ficticio, y está divulgado. La entidad de la demo es NovaCredit con LEI 999999FAKEBANK999 — un identificador deliberadamente inválido y claramente falso, llevado con una divulgación OPSEC en froga.yaml. El ensamblador valida los LEI contra el formato ISO 17442; en producción el LEI debe validarse contra GLEIF. Aquí es un marcador de honestidad: un registro de demo que visiblemente no pretende ser una presentación real.
• B_05.01 es escaso — a propósito. Solo los proveedores con un LEI verificado por GLEIF pueblan la tabla de terceros; los componentes TIC cuyo proveedor no tiene LEI registrado se bloquean en lugar de fabricarse. Así que B_05.01 es intencionalmente escaso (la mayoría de los componentes del ML-BOM son bibliotecas de código abierto, no proveedores TIC registrables). La escasez es el estado honesto, no un defecto.
• El vocabulario pierde información. DORA_VOCAB proyecta el nivel residual del motor sobre la escala de tres valores de DORA — y esa correspondencia pierde información: tanto MEDIUM como LOW se agrupan en «Low» (CRITICAL→Significant, HIGH→Moderate). Una frase honesta: la columna de resultado-de-riesgo del registro es una proyección gruesa de la escala residual más fina del motor, no una transcripción uno a uno.

---

§6 — Artículos 9, 10, 11 revisados (bajo el segundo régimen)

El modelo de crédito ejecuta la misma columna vertebral de los artículos 9 a 15 que los niveles limpios, pero ahora es también un activo TIC, así que vale la pena releer tres de ellos a través de la superposición — brevemente.

• Art. 9 (gestión de riesgos). El mismo programa de risk impulsa el sistema: un apetito, una matriz 5×5, el criterio de residual global, el riesgo de equidad y su tratamiento. DORA no añade nada al veredicto aquí — el residual de equidad cierra en VERDE en la maquinaria de la Ley de IA / ISO, y punto. DORA reutiliza el mismo residual (lo proyecta en la columna de resultado-de-riesgo de B_07.01), pero no lo cambia.
• Art. 10 (gobernanza de datos). El sistema declara un compromiso de gobernanza de datos (datos de entrenamiento equilibrados, minimización), solo de auditoría y declarado. Atención — una colisión de nombres que merece señalar: Ley de IA Art. 10 (gobernanza de datos) ≠ DORA Art. 10 (detección de anomalías TIC). Mismo número, dos leyes diferentes, dos obligaciones diferentes. El Art. 10 de la Ley de IA trata sobre la calidad y gobernanza de los datos de entrenamiento; el Art. 10 de DORA trata sobre la detección de actividad TIC anómala. Cuando un sistema financiero está en el ámbito de ambos, «artículo 10» es ambiguo a menos que nombres la ley — precísalo siempre.
• Art. 11 (documentación técnica, Anexo IV). El paquete firmado es la fuente que el plano de control ensambla en el dossier del Anexo IV — y en el Registro DORA. Un paquete, proyectado tanto sobre la documentación Ley de IA como sobre el entregable financiero: la idea «un paquete → N catálogos» de la superposición hecha concreta.

El mapa de modalidades — dónde se sitúa este nivel

El curso nombra la clase de tratamiento y la clase de control en cada nivel. Aquí:

• Modalidad de tratamiento: un cambio de aprendiz con fairlearn — el tratamiento reemplaza train.py (regresión logística plana → ExponentiatedGradient con restricción DemographicParity). En todos los niveles el tratamiento es un cambio de código versionado (el git diff de train.py), no un flag; lo que varía es su naturaleza: el Nivel 1 añade las features discriminativas, el Nivel 2 hace el mismo cambio de aprendiz con fairlearn (pero resuelve a ámbar por otra vía) y el Nivel 3 reentrena con equilibrado de clases + umbral 0,30. Todos son commits versionados; el tratamiento es el git diff.
• Control de barrera: equidad — demographic_parity_diff — objetivo, bloqueante, medido con un IC cluster/bootstrap OUT-OF-FOLD sobre las 1.000 filas (5-fold StratifiedKFold, no un held-out de 200). Ese IC es lo que hace que V1 sea honestamente ÁMBAR y V2 honestamente VERDE — nunca un verde maquillado.
• Registro de actividades (el artículo en profundidad de este nivel): Art. 12 — registro git-nativo, ex ante — un entregable / pista de papel, no un control de barrera.
• Entregable sectorial: Registro de Información DORA (xBRL-OIM) — un entregable firmado + cruce documental, no un veredicto de conformidad.

---