DCP-AI y el Reglamento de IA de la UE — correspondencia de las obligaciones de registro, supervisión humana y conservación de registros¶

Traducción informativa de la versión en inglés, actualizada el 28/10/2026. Si difieren, prevalece la versión en inglés. Los identificadores, comandos y bloques de código se conservan sin traducir.

Versión de la especificación: 2.0 Última actualización: octubre de 2026 Fecha de la revisión jurídica: 22/10/2026 Estado: Informativo. Las fuentes jurídicas se leyeron el 22/10/2026 (sección 7); la correspondencia de implementación describe las especificaciones, esquemas y SDK de main el 25/10/2026 e indica dónde difiere la etiqueta histórica del repositorio v2.10.0 (22/10/2026), y dónde una especificación exige algo que las funciones de los SDK no hacen. Esa etiqueta no es la publicación actual ni el paquete Python dcp-ai 2.10.0 verificado el 26/10/2026; las versiones actuales están en Versiones publicadas

Nota (27/10/2026). Solo la fila sobre la cadena de doble hash de la sección 3 (art. 19(1) y art. 26(6)) incorpora el trabajo del 27/10/2026 en el código fuente aún no publicado sobre los campos secundarios SHA3-256. La fecha de lectura jurídica (22/10/2026) y la instantánea de implementación del 25/10/2026 del resto de este documento no cambian.

Nota (28/10/2026). Esa fila remite ahora a las versiones de corrección SHA3 publicadas el 28/10/2026; el resto de este documento no cambia, salvo el punto de la lista de comprobación sobre la caché de verificación, que ahora separa los paquetes publicados del código fuente no publicado de main.

Este documento pone en correspondencia las obligaciones del Reglamento (UE) 2024/1689 (el «Reglamento de IA»), modificado por el Reglamento (UE) 2026/1744 (el «Digital Omnibus on AI»), que se refieren a la trazabilidad, el registro, la supervisión humana, la conservación de registros, la explicación y la evidencia de incidentes con los artefactos, servicios y funciones de los SDK de DCP-AI. Sigue la estructura de NIST_CONFORMITY.md: secciones numeradas, una tabla de correspondencias, una lista de comprobación para implementadores y una lista explícita de carencias.

Todos los artículos citados abajo se leyeron el 22/10/2026 en el texto oficial de EUR-Lex. El texto de base es el reglamento tal como se publicó (CELEX 32024R1689); las modificaciones se toman del Digital Omnibus on AI tal como se publicó en el Diario Oficial. La sección 4 indica de qué texto procede cada fecha. Cuando el texto cita el reglamento, las citas se limitan a unas pocas palabras y se conservan en inglés, tal como se leyeron en EUR-Lex; todo lo demás es paráfrasis y no debe leerse como la redacción jurídica.

1. Alcance y advertencia¶

DCP-AI es un protocolo y un formato de evidencia. Define artefactos firmados (en un bundle, el Responsible Principal Record, el Agent Passport, la Intent y la Policy Decision son cada uno un SignedPayload; los registros de ciclo de vida, disputas, derechos y delegación los firman sus propias funciones), entradas de auditoría con las que un bundle firmado se compromete mediante su raíz de Merkle de auditoría en lugar de firmarlas una a una, un rastro de auditoría que permite detectar manipulaciones, anclaje y registro de transparencia opcionales, y verificadores locales, cada uno de los cuales comprueba solo lo que cubre su ruta (por ejemplo, verifySignedBundleV2 para un bundle V2).

DCP-AI no es:

una evaluación de la conformidad, una norma armonizada, una especificación común ni una presunción de conformidad en virtud del Reglamento de IA;
un sistema de gestión de riesgos (art. 9), un sistema de gestión de la calidad, documentación técnica (art. 11) ni un plan de seguimiento posterior a la comercialización (art. 72) de ningún sistema de IA concreto;
asesoramiento jurídico. Si un agente determinado es un «sistema de IA», si es de alto riesgo y quién es el proveedor o el responsable del despliegue son determinaciones que la organización debe hacer con su asesoría jurídica.

Lo que hace este documento es más limitado: para cada obligación enumerada, nombra el mecanismo de DCP que produce evidencia o aplica un control, dice hasta dónde llega ese mecanismo (supports, partial, out of scope) e indica lo que el proveedor o el responsable del despliegue todavía debe hacer por su cuenta. Una fila marcada como supports significa que el mecanismo existe y hace lo que dice la fila cuando se configura como se describe en la sección 5; no significa que la obligación esté cumplida.

Valores de cobertura usados en la sección 3:

Valor	Significado
`supports`	Un artefacto de DCP, una regla del verificador o un servicio de referencia implementa el mecanismo que exige la obligación. Hacerlo funcionar correctamente sigue siendo tarea de la organización (sección 5).
`partial`	DCP produce evidencia o una pieza de construcción, pero una parte sustancial de la obligación (un documento, un proceso, un informe, una decisión humana) no es algo que el protocolo pueda producir.
`out of scope`	DCP no lo aborda y no debe citarse para ello.

2. Roles: proveedor y responsable del despliegue frente a operador, principal responsable y agente¶

El Reglamento de IA vincula las obligaciones a roles definidos en el art. 3. Un proveedor (art. 3(3)) desarrolla un sistema de IA, o lo hace desarrollar, y lo introduce en el mercado o lo pone en servicio con su propio nombre. Un responsable del despliegue (art. 3(4)) usa un sistema de IA «under its authority», salvo en una actividad personal no profesional. Un sistema de IA (art. 3(1)) es un sistema basado en una máquina que funciona con «varying levels of autonomy» y que infiere, a partir de la entrada que recibe, cómo generar resultados. Las obligaciones del Reglamento se vinculan al sistema de IA y a las personas jurídicas que están detrás de él.

Los roles de DCP se vinculan a una instancia de agente y a la persona u organización que responde por ella:

Rol de DCP	Dónde se registra	Rol típico en el Reglamento de IA	Notas
Principal responsable	`schemas/v2/responsible_principal_record.schema.json`: `human_id`, `legal_name`, `entity_type` (`natural_person` u `organization`), `jurisdiction`, `liability_mode` (`owner_responsible`), `override_rights`, `binding_keys`	Responsable del despliegue, o la persona física a la que el responsable del despliegue asigna la supervisión humana según el art. 26(2)	El RPR nombra a quién responde de las acciones del agente. Cuando `entity_type` es `organization`, suele ser el propio responsable del despliegue; cuando es `natural_person`, suele ser la persona dentro del responsable del despliegue que tiene los `override_rights`.
Agente	`schemas/v2/agent_passport.schema.json`: `agent_id`, `keys`, `principal_binding_reference`, `capabilities`, `risk_tier`, `status`	El sistema de IA (o un componente de uno)	Un agente DCP es una instancia desplegada con sus propias claves y su propio estado del ciclo de vida. El proveedor del modelo o del framework subyacente no aparece en ningún artefacto de DCP.
Operador (de un servicio de verificación, un motor de políticas, un registro de transparencia, un servicio de anclaje o de revocación)	`server/`, `services/`, política del verificador (OPERATOR_GUIDE.md)	Normalmente el responsable del despliegue; puede ser el proveedor cuando el proveedor distribuye el control como parte del sistema, o un tercero	El operador decide la política del verificador, la conservación de los datos de auditoría y la cadencia de anclaje. Varios elementos de la sección 5 corresponden al operador.
Agente contraparte (DCP-04, DCP-09)	`interaction_record.counterparty_agent_id`, mandatos de delegación	Otro sistema de IA, posiblemente de otro responsable del despliegue	Los registros de interacción dan a cada parte evidencia del mandato de la otra.

Dos consecuencias para la correspondencia:

Las obligaciones del lado del proveedor son en su mayoría partial. DCP no conoce el modelo, los datos de entrenamiento ni la finalidad prevista. Puede documentar cómo funciona la capa de rendición de cuentas (sección 3, fila del art. 11), no el sistema de IA en sí.
Las obligaciones de registro y supervisión del lado del responsable del despliegue son donde DCP es más fuerte. El control de intenciones, las decisiones de política, la cadena de auditoría, los override_rights del RPR, las declaraciones de asesoramiento y los estados del ciclo de vida son controles orientados al responsable del despliegue que producen evidencia firmada.

Las especificaciones de DCP-AI usan «human» y «principal» para la persona vinculada por el RPR. Este documento usa «principal responsable» para esa persona, y «responsable del despliegue» y «proveedor» en el sentido del Reglamento.

3. Tabla de correspondencias¶

Cada fila: el artículo tal como se leyó en EUR-Lex, una paráfrasis breve de la obligación, el mecanismo de DCP con referencias precisas, la cobertura y lo que la organización todavía debe hacer. Las referencias a la especificación remiten a spec/DCP-AI-v2.0.md («core §n») y a las especificaciones de perfil spec/DCP-05.md a spec/DCP-09.md. Los nombres de funciones son del SDK de TypeScript (@dcp-ai/sdk, sdks/typescript/src/index.ts); los SDK de Python, Go, Rust y WASM cubren cada uno un subconjunto distinto con su propia nomenclatura, así que consulta el README de cada SDK para ver qué expone (véase también API_REFERENCE.md).

3.1 Registro y evidencia de manipulación¶

Artículo	Obligación (paráfrasis)	Mecanismo de DCP	Cobertura	Lo que queda para la organización
Art. 12(1)	Los sistemas de alto riesgo deben permitir técnicamente el registro automático de eventos (logs) a lo largo de su vida.	Cada acción controlada produce una entrada de auditoría con la que el bundle firmado se compromete mediante la raíz de Merkle de la auditoría (las entradas no se firman una a una; `schemas/v2/audit_entry.schema.json`: `audit_id`, `timestamp`, `agent_id`, `human_id`, `intent_id`, `intent_hash`, `policy_decision`, `outcome`, `evidence`). El SDK no controla acciones ni escribe registros por su cuenta: la aplicación construye cada entrada y la pasa al constructor (`BundleBuilderV2`, con `prevHashForEntry` e `intentHash` como ayudas). DCP-05 §9, DCP-07 §9, DCP-08 §8 y DCP-09 §9 especifican entradas de auditoría para los eventos de ciclo de vida, disputas, derechos y delegación; las funciones del SDK para esos eventos no las crean automáticamente, así que debe hacerlo la aplicación.	`supports`	Encaminar toda acción relevante del sistema de IA a través del control de intenciones y escribir su entrada de auditoría. Las acciones que se hacen fuera de DCP (inferencia del modelo, eventos de la interfaz, llamadas a herramientas no declaradas como intenciones) no las registra DCP.
Art. 12(2)	El registro debe dar una trazabilidad adecuada a la finalidad prevista: eventos relevantes para identificar situaciones de riesgo, para el seguimiento posterior a la comercialización (art. 72) y para la supervisión del responsable del despliegue (art. 26(5)).	Cada entrada de auditoría vincula la intención (`intent_id`, `intent_hash` = SHA-256 de la intención canónica, DCP-03), el resultado de la política (`policy_decision`: `approved`, `escalated`, `blocked`), el resultado (`outcome`) y la Action Evidence (`evidence.tool`, `evidence.result_ref`, `evidence.evidence_hash`). La Policy Decision lleva `risk_score` (entero 0..1000), `reasons`, `applied_policy_hash` y `resolved_tier`. Todos los artefactos de una sesión comparten un `session_nonce` (core §8).	`supports`	Definir `action_type`, `data_classes` y `estimated_impact` de modo que reflejen la finalidad prevista del sistema; conservar las versiones de la política que hay detrás de `applied_policy_hash` para que una decisión pueda volver a leerse más tarde.
Art. 12(3)	Para los sistemas de identificación biométrica remota (anexo III, punto 1(a)): periodo de cada uso, base de datos de referencia, datos de entrada coincidentes, identidad de las personas físicas que verificaron el resultado.	Solo el último elemento tiene equivalente: `schemas/v2/human_confirmation.schema.json` registra `human_id`, `intent_id`, `decision` (`approve`/`deny`) y una firma compuesta. DCP no tiene campos para bases de datos de referencia ni para entradas coincidentes.	`out of scope`	El contenido de registro específico de la biometría es diseño del proveedor. Las Human Confirmations pueden evidenciar quién confirmó un resultado, no la coincidencia en sí.
Art. 19(1) y art. 26(6)	Los proveedores (art. 19) y los responsables del despliegue (art. 26(6)) conservan bajo su control los logs generados automáticamente durante un periodo adecuado a la finalidad prevista, «of at least six months», salvo que el Derecho de la Unión o nacional (en particular el de protección de datos) disponga otra cosa.	Evidencia de manipulación de lo que se conserva: la cadena de hash (`prev_hash`, DCP-03), la cadena de doble hash (`prev_hash_secondary`, `hash_alg: "sha256+sha3-256"`, core §10.3, `spec/VERIFICATION.md` V2-11), las raíces de Merkle del manifiesto del bundle (`audit_merkle_root`, `audit_merkle_root_secondary`, `audit_count`; `merkleRootForAuditEntries`, `dualMerkleRoot`), los checkpoints PQ (`schemas/v2/pq_checkpoint.schema.json`, `createPQCheckpoint`, `PQCheckpointManager`, core §10.2) y los checkpoints de compactación (`schemas/v2/audit_compaction.schema.json`, `createAuditCompaction` en `sdks/typescript/src/core/audit-compaction.ts`, core §10.4) permiten a un verificador detectar, en cualquier fecha posterior, si un registro conservado se ha alterado desde que se comprometió. Los paquetes de los SDK publicados antes del 28/10/2026 comprueban la cadena primaria y la raíz de Merkle, pero no la cadena secundaria ni `audit_merkle_root_secondary`; los verificadores desde `@dcp-ai/sdk` 2.2.1, `@dcp-ai/wasm` 2.1.1, `dcp-ai` 2.10.1 (PyPI), Go v2.11.1 y Rust `dcp-ai` 2.11.1 comprueban los campos secundarios presentes, así que confía en los compromisos secundarios como evidencia comprobada solo con un verificador que incluya esta comprobación (STORAGE_AND_ANCHORING.md). La conservación en sí: DCP no define ningún periodo de conservación ni ningún almacenamiento. STORAGE_AND_ANCHORING.md enumera las opciones de almacenamiento (bundle portable en manos del titular, hashes anclados, revocaciones distribuidas); OPERATOR_GUIDE.md indica que la pasarela y los servicios de referencia guardan el estado en memoria, salvo que el servicio de revocación tenga `REVOCATION_STATE_PATH` en un almacenamiento persistente, y que «a restart, a deploy or a crash wipes their state». DCP-08 §3.5 (Immutable Record) dice que los registros de auditoría, vitalidad y ciclo de vida «shall be preserved intact for the retention period specified in the commissioning certificate and decommissioning record», y el ejemplo de declaración de derechos de DCP-08 usa `minimum_retention_period: "P7Y"`, pero ningún campo de esquema impone un periodo.	`partial`	Guardar los bundles firmados y las entradas de auditoría (no solo sus hashes) en un almacenamiento duradero durante al menos seis meses, más tiempo cuando lo exijan la finalidad prevista o la normativa sectorial. La compactación (core §10.4) permite archivar los eventos compactados mientras el checkpoint permanece en la cadena activa; los eventos archivados deben seguir conservándose durante el periodo de conservación. Archivar las claves públicas de los agentes al retirarlos (DCP-05 §8.4) para que las firmas antiguas sigan siendo verificables. Decidir la base del RGPD para conservar las entradas que llevan `human_id` y aplicar el RPR cegado (fila 3.7) cuando las entradas salgan de la organización.
Art. 26(6), párrafo segundo, art. 19(2)	Las entidades financieras conservan los logs como parte de la documentación exigida por el Derecho de la Unión en materia de servicios financieros.	Los bundles y las entradas de auditoría son JSON portable (CBOR opcional, core §16) y pueden archivarse dentro de un sistema de registros existente.	`partial`	Hacer corresponder el archivo de bundles con el calendario de conservación de registros ya vigente según la normativa de servicios financieros.
Art. 73(6), párrafo segundo	Tras un incidente grave, el proveedor no debe modificar el sistema de IA de forma que afecte a la evaluación posterior de sus causas antes de informar a las autoridades.	El anclaje (`services/anchor`, `anchor_receipt` en STORAGE_AND_ANCHORING.md) y el registro de transparencia (`services/transparency-log`: `POST /add`, `GET /proof/:index`, `GET /root/signed`, árbol de la RFC 6962, cabezas de árbol firmadas con Ed25519) registran un compromiso con el estado del rastro de auditoría, de modo que un evaluador posterior puede saber si el registro conservado coincide con lo comprometido (SECURITY_MODEL.md §6, «Retroactive modification»). El momento de ese compromiso depende de la confianza en el operador del registro o del anclaje; no muestra cuándo ocurrió el incidente ni que los registros sean verdaderos.	`partial`	Anclar o registrar la raíz de Merkle de la auditoría con una cadencia inferior a los plazos de notificación de incidentes del art. 73 (sección 5). El servicio de anclaje de referencia todavía no envía transacciones on-chain (`tx_hash: null`); usa el registro de transparencia o un anclaje de producción contra `contracts/ethereum/src/DCPAnchor.sol`.

3.2 Supervisión humana¶

Artículo	Obligación (paráfrasis)	Mecanismo de DCP	Cobertura	Lo que queda para la organización
Art. 14(1)–(3)	Los sistemas de alto riesgo deben diseñarse de modo que personas físicas puedan supervisarlos eficazmente mientras se usan; las medidas son proporcionales al riesgo, la autonomía y el contexto, integradas por el proveedor o aplicadas por el responsable del despliegue.	Control de intenciones (DCP-02): ninguna acción sin una Intent declarada y una Policy Decision (`approve`, `escalate`, `block`); `required_confirmation` solicita una Human Confirmation antes de la acción. Escrutinio adaptativo: el nivel de seguridad (core §14, `computeSecurityTier`, `effectiveVerificationMode`) sube con `risk_score`, `data_classes` (`pii`, `financial_data`, `health_data`, `credentials`, `children_data`), `action_type: "initiate_payment"` y `estimated_impact: "high"`, y un verificador NO DEBE bajarlo (core §14.3). Estados del ciclo de vida (DCP-05 §3): `commissioned`, `active`, `declining`, `decommissioned`; la especificación exige la aprobación del principal para reactivar desde `declining`, pero `validateStateTransition` solo comprueba que la transición sea una de las aristas permitidas, no la aprobación.	`partial`	Decidir qué acciones se controlan y qué política produce `escalate`. La aplicación o su integración imponen el control sobre lo que se declara, y los verificadores comprueban la evidencia resultante; el proveedor debe hacer que el sistema de IA invoque el control. Las medidas de supervisión (quién, cómo, con qué formación) corresponden al responsable del despliegue según el art. 26(2).
Art. 14(4)(a)	Los supervisores deben poder entender las capacidades y limitaciones del sistema y vigilar su funcionamiento, incluida la detección de anomalías y de un rendimiento inesperado.	Umbrales de atención (DCP-09 §4, `schemas/v2/awareness_threshold.schema.json`): `threshold_rules[]` firmadas con `dimension`, `operator`, `value` y `action_if_triggered` (`notify`, `escalate`, `block`); `createAwarenessThreshold`, `evaluateSignificance`, `shouldNotifyHuman`. Espejo del principal (DCP-09 §6, `schemas/v2/principal_mirror.schema.json`, `generateMirror`). Informes de vitalidad (DCP-05 §5–6, `createVitalityReport`) con detección de anomalías (§6.5). Observabilidad (OBSERVABILITY.md, `dcpTelemetry`): latencia de verificación, bundles verificados, errores y latencia de los checkpoints por nivel.	`partial`	Las capacidades y limitaciones del propio sistema de IA (exactitud, solidez, modos de fallo conocidos) proceden de las instrucciones de uso del proveedor (art. 13). DCP dice al supervisor lo que el agente hizo y lo que declaró no entender, no lo que el modelo puede hacer.
Art. 14(4)(b)	Los supervisores deben ser conscientes del sesgo de automatización.	Ninguno.	`out of scope`	Formación y diseño de la interfaz. La capa narrativa de los registros de interacción (fila siguiente) puede hacer visible el razonamiento, lo que ayuda, pero DCP no aborda el sesgo de automatización.
Art. 14(4)(c)	Los supervisores deben poder interpretar correctamente los resultados del sistema.	Registros de interacción (DCP-09 §7, `schemas/v2/interaction_record.schema.json`): una `public_layer` legible por personas (`terms`, `decisions`, `commitments`) y un `private_layer_hash` que se compromete con el detalle técnico; `generateInteractionRecord`. DCP-09 §7.3–7.4 describen las capas técnica y narrativa (el ejemplo de la especificación es más rico que los campos obligatorios del esquema). Declaraciones de asesoramiento (DCP-09 §5, `schemas/v2/advisory_declaration.schema.json`): `action_summary`, `recommended_response`, `significance_score`. `reasons` de la Policy Decision.	`partial`	La interpretación de los resultados del modelo (puntuaciones, clasificaciones, contenido generado) corresponde al proveedor y al responsable del despliegue. DCP explica la intención declarada del agente y su razonamiento tal como quedó registrado, no los resultados del modelo.
Art. 14(4)(d)	Los supervisores deben poder decidir no usar el sistema o descartar, anular o revertir sus resultados.	`override_rights` (booleano, obligatorio) en el RPR, copiado sin cambios en el RPR cegado (core §12.1): el derecho del principal responsable a anular es un atributo firmado y publicado de la vinculación. Human Confirmation con `decision: "deny"` sobre una intención escalada. Respuesta a un asesoramiento (DCP-09 §5.5): continuar, anular, asumir el control, delegar en otro sitio o acusar recibo, firmada por el principal y registrada en la cadena de auditoría; `advisory_declaration.human_response`, `response_deadline`, `proceeded_without_response`. Regla de atención con `action_if_triggered: "block"`.	`supports`	Fijar `override_rights: true` en todo agente usado en un contexto de alto riesgo y hacer que la aplicación o su integración impongan un `deny` y un `block`: los verificadores no ejecutan ninguna de las dos decisiones ni confirman que haya decidido una persona, y ni la verificación ni la admisión autorizan una acción (un resultado de admisión lleva `action_authorized: false`). Definir quién es el principal y mantener las claves de esa persona bajo su control (sección 5).
Art. 14(4)(e)	Los supervisores deben poder intervenir o interrumpir el sistema mediante un botón de «stop» o similar, llevándolo a un estado seguro.	Revocación de emergencia (core §11.3, `schemas/v2/emergency_revocation.schema.json`): el `emergency_revocation_token` registrado de antemano en el pasaporte es `SHA-256(revocation_secret)`; revelar el secreto revoca todas las claves del agente sin necesidad de firma (`generateEmergencyRevocationToken`, `buildEmergencyRevocation`, `verifyEmergencyRevocationSecret`; `POST /v2/emergency-revoke` en el servicio de revocación y en la pasarela, `GET /v2/check/kid/:kid` en el servicio de revocación; la revocación firmada a nivel de kid es el `POST /v2/revoke` del servicio de revocación). Registro de revocación (`schemas/v2/revocation_record.schema.json`; el enum `reason` incluye `key_compromise_emergency`). Transición del ciclo de vida a `declining` o `decommissioned` (DCP-05 §3.2, `validateStateTransition`, `createDecommissioningRecord`), modo `termination_for_cause` (§7.3). Los verificadores DEBEN invalidar los resultados en caché cuando se revoca un kid firmante (core §14.5).	`partial`	La revocación detiene la aceptación de los bundles del agente por todos los verificadores que comprueban revocaciones; no detiene un proceso en ejecución ni revierte una acción ya realizada. El comportamiento en estado seguro del sistema de IA es diseño del proveedor. Combina la revocación con un interruptor de apagado a nivel de aplicación, y cumple la latencia de propagación de la revocación del nivel (SECURITY_MODEL.md, «Revocation Propagation SLAs»).
Art. 14(5)	Para la identificación biométrica remota (anexo III, punto 1(a)): ninguna acción basada en una identificación sin que la verifiquen al menos dos personas físicas competentes (con excepciones para la aplicación de la ley, la migración, el control de fronteras y el asilo).	Autorización multiparte (`schemas/v2/multi_party_authorization.schema.json`, `POST /v2/multi-party/authorize` de la pasarela; la firma de cada parte se verifica con sus claves registradas y se cuenta una sola vez).	`partial`	DCP puede evidenciar que dos titulares de claves distintos aprobaron una intención; no puede evidenciar su competencia ni que la identificación se «verificara por separado». La regla de las dos personas es un proceso del responsable del despliegue.
Art. 26(1)–(2)	Los responsables del despliegue usan el sistema conforme a las instrucciones de uso y asignan la supervisión humana a personas físicas con la competencia, la formación, la autoridad y el apoyo necesarios.	El RPR vincula al agente con una persona física u organización con nombre y con `override_rights`; el Delegation Mandate (DCP-09 §3, `schemas/v2/delegation_mandate.schema.json`, `createDelegationMandate`, `verifyMandateValidity`, `revokeDelegation`) indica lo que el agente puede hacer en nombre del principal (`authority_scope`: `domain`, `actions_permitted`, `data_classes`, `limits`; la lista de prohibiciones del ejemplo de DCP-09 §3.2 no es un campo de esquema); `interaction_record` y DCP-09 §7.5 registran el cumplimiento de la delegación.	`partial`	La competencia, la formación y el apoyo son hechos organizativos ajenos al registro. Nombra a la persona supervisora en el RPR (`entity_type: "natural_person"`) o mantén un registro interno que haga corresponder un RPR de tipo `organization` con las personas asignadas.
Art. 26(5)	Los responsables del despliegue vigilan el funcionamiento del sistema, informan al proveedor según el art. 72 y, si el uso puede presentar un riesgo, informan al proveedor o al distribuidor y a la autoridad de vigilancia del mercado y suspenden el uso; los incidentes graves se notifican primero al proveedor.	Evidencia del funcionamiento: cadena de auditoría, Policy Decisions, registros de interacción, registros de obligaciones con `compliance_status` (DCP-08 §5, `recordObligation`, `checkRightsCompliance`), informes de vitalidad. Suspensión: `status` del pasaporte (`suspended`, `declining`, `decommissioned`), revocación, revocación de emergencia. Escalado: DCP-08 §6.4 especifica que un incumplimiento de obligaciones abre una disputa DCP-07, con los plazos de escalado de DCP-07 §3.2; el SDK no la abre automáticamente (`reportViolation` recibe un `dispute_id` que aporta quien llama, o `null`).	`partial`	Informar al proveedor, al distribuidor y a la autoridad de vigilancia del mercado, y decidir que existe un riesgo, son actos del responsable del despliegue. DCP no tiene ningún artefacto para una notificación a una autoridad.

3.3 Trazabilidad de las decisiones¶

Artículo	Obligación (paráfrasis)	Mecanismo de DCP	Cobertura	Lo que queda para la organización
Art. 12(2), art. 13(1)	Trazabilidad del funcionamiento del sistema; un funcionamiento lo bastante transparente para que el responsable del despliegue interprete los resultados y los use adecuadamente.	Cadena de decisión por acción: Intent (`schemas/v2/intent.schema.json`: `action_type`, `target.channel`, `target.to`/`domain`/`url`, `data_classes`, `estimated_impact`, `requires_consent`, `security_tier`) → Policy Decision (`decision`, `risk_score`, `reasons`, `applied_policy_hash`, `resolved_tier`) → Human Confirmation opcional → entrada de auditoría con `outcome` y `evidence`. El manifiesto del bundle (core §9, `schemas/v2/bundle_manifest.schema.json`) lleva `rpr_hash`, `passport_hash`, `intent_hash`, `policy_hash` y las raíces de Merkle de la auditoría, y la firma compuesta del bundle cubre el manifiesto. La verificación es local y reproducible (`spec/VERIFICATION.md`, `verifySignedBundleV2`, `POST /v2/bundle/verify` de la pasarela). Los registros de interacción (DCP-09 §7) añaden la contraparte, el mandato y la capa narrativa.	`supports`	Conservar el texto o las reglas de la política detrás de cada `applied_policy_hash`. `reasons` es texto libre: escribe razones que un revisor pueda leer un año después.
Art. 12(2)(a)	Los logs deben ayudar a identificar situaciones que puedan dar lugar a un riesgo en el sentido del art. 79(1) o a una modificación sustancial.	`risk_score`, `resolved_tier`, `estimated_impact` y `data_classes` se firman por acción y pueden consultarse; los resultados `escalated` y `blocked` son explícitos; los umbrales de atención y las declaraciones de asesoramiento registran la propia incertidumbre del agente (`significance_score`; las puntuaciones `confidence` por dominio de DCP-09 §4.2–4.3 aparecen en el ejemplo de la especificación, no en `schemas/v2/awareness_threshold.schema.json`).	`supports`	Definir qué cuenta como situación de riesgo para la finalidad prevista y alertar sobre ella. DCP proporciona las señales, no la política de alertas.
Art. 86(1)	Una persona afectada por una decisión que el responsable del despliegue toma sobre la base de los resultados de un sistema de alto riesgo del anexo III (salvo el punto 2), con efectos jurídicos o efectos adversos de importancia similar, puede obtener del responsable del despliegue explicaciones claras y significativas sobre el papel del sistema de IA en la decisión y sobre los principales elementos de la decisión.	La Intent, la Policy Decision (`decision`, `reasons`, `risk_score`) y la Human Confirmation (quién aprobó y cuándo) firmadas, y la entrada de auditoría (`outcome`, `evidence`) con la que se compromete el bundle firmado, más el `public_layer.decisions` del registro de interacción y el `action_summary` del asesoramiento, dan al responsable del despliegue declaraciones firmadas de lo que el agente pretendía, lo que decidió la política, la confirmación registrada (la identidad real de quien confirma se establece fuera de DCP) y el resultado declarado.	`partial`	La explicación a la persona afectada es un documento que el responsable del despliegue redacta en lenguaje claro; DCP aporta declaraciones firmadas, que no prueban que una acción se llevara a cabo realmente ni establecen la identidad jurídica de nadie. Las decisiones que no se controlaron como intenciones, y el razonamiento del modelo detrás de un resultado, no están en el registro.

3.4 Explicación, reparación y disputas¶

Artículo	Obligación (paráfrasis)	Mecanismo de DCP	Cobertura	Lo que queda para la organización
Art. 27(1)(e)–(f)	La evaluación de impacto relativa a los derechos fundamentales (organismos públicos, prestadores de servicios públicos, anexo III, puntos 5(b) y (c)) describe las medidas de supervisión humana aplicadas y las medidas que se adoptarán si los riesgos se materializan, incluidos la gobernanza interna y los mecanismos de reclamación.	Medidas de supervisión concretas y documentables: `override_rights` del RPR, control de intenciones con `escalate`, Human Confirmations, umbrales de atención, declaraciones de asesoramiento, controles del ciclo de vida, revocación de emergencia. Gobernanza interna y escalado: el modelo de tres niveles de DCP-07 (negociación directa, arbitraje contextual, apelación humana, §5) con `createDispute`, `escalateDispute`, `resolveDispute`, `createObjection`; los informes de vulneración de DCP-08 (`reportViolation`).	`partial`	La evaluación en sí (procesos, personas afectadas, riesgos, art. 27(1)(a)–(d)) corresponde al responsable del despliegue. DCP-07 y DCP-08 son mecanismos entre los agentes y sus principales; no son un canal de reclamación para las personas físicas afectadas (sección 6). El Omnibus modificó el art. 27(4)–(5) para permitir referencias cruzadas a una evaluación de impacto relativa a la protección de datos del RGPD.
Art. 86	Derecho a explicación (véase la fila 3.3).	Apelación humana (DCP-07 §5.3): cualquier parte en la disputa puede escalar a los principales responsables en cualquier momento; la decisión humana es definitiva dentro del protocolo y se registra como resolución de arbitraje (`schemas/v2/arbitration_resolution.schema.json`). Registro de disputa (`schemas/v2/dispute_record.schema.json`: `dispute_type`, `escalation_level` incluido `human_appeal`, `status`, `evidence_hashes`). Capa narrativa (DCP-09 §7.4): resumen en lenguaje claro, decisiones clave con su razonamiento, cuestiones pendientes, acciones para el principal.	`partial`	Estos mecanismos dan a las propias personas del responsable del despliegue una vía de revisión documentada sobre las decisiones del agente. El derecho de la persona afectada según el art. 86 se ejerce frente al responsable del despliegue, fuera del protocolo.
Art. 26(11), art. 50(1)	Los responsables del despliegue de sistemas del anexo III que toman decisiones sobre personas físicas, o ayudan a tomarlas, las informan; los proveedores garantizan que las personas que interactúan con un sistema de IA sean informadas de que lo hacen, salvo que sea evidente.	El Agent Passport es una declaración firmada y verificable de que el actor es un agente de IA vinculado a un principal con nombre, presentable a cualquier contraparte (`presentFull`, `presentCompact`, `presentReference`; handshake de DCP-04 para otros agentes).	`partial`	La comunicación a las personas físicas (interfaz, redacción, momento «at the latest at the time of the first interaction», art. 50(5)) corresponde al proveedor y al responsable del despliegue. DCP da una prueba verificable que respalda la comunicación; no la hace.
Art. 50(2), art. 50(4)	Marcado legible por máquina del contenido sintético; comunicación de las ultrasuplantaciones (deep fakes) y del texto generado por IA sobre asuntos de interés público.	Ninguno. `evidence.evidence_hash` puede vincular los bytes declarados de un artefacto; no prueba que el artefacto se generara realmente ni que se marcara.	`out of scope`	El marcado y la detección de contenidos son medidas técnicas distintas.

3.5 Notificación de incidentes y seguimiento posterior a la comercialización¶

Artículo	Obligación (paráfrasis)	Mecanismo de DCP	Cobertura	Lo que queda para la organización
Art. 72(1)–(2)	Los proveedores establecen un sistema documentado de seguimiento posterior a la comercialización que recoge y analiza activamente datos sobre el rendimiento a lo largo de la vida útil, incluidos los datos facilitados por los responsables del despliegue y la interacción con otros sistemas de IA.	Datos que un responsable del despliegue puede entregar a un proveedor: entradas de auditoría con resultados y evidencias, Policy Decisions con `risk_score`, registros de obligaciones (`schemas/v2/obligation_record.schema.json`: `obligation_type`, `compliance_status`, `evidence_hashes`; el `compliance_history` del ejemplo de DCP-08 §5.2 no es un campo de esquema), informes de vitalidad (DCP-05 §6), registros de interacción con agentes contraparte (DCP-09 §7), informes de disputas y de vulneraciones. Cada uno está firmado, o comprometido mediante un bundle firmado, y el proveedor puede verificarlo sin confiar en la base de datos del responsable del despliegue.	`partial`	El sistema y el plan de seguimiento corresponden al proveedor. El Omnibus sustituyó el art. 72(3): el plan sigue formando parte de la documentación del anexo IV, se suprimió el acto de ejecución de la Comisión para una plantilla, y la Comisión debe adoptar orientaciones, plantilla incluida, a más tardar el 02/09/2027 (sección 4).
Art. 73(1)–(5)	Los proveedores notifican los incidentes graves (art. 3(49): muerte o daño grave para la salud, alteración grave e irreversible de infraestructuras críticas, infracción de obligaciones relativas a los derechos fundamentales, daño grave a la propiedad o al medio ambiente) a la autoridad de vigilancia del mercado: inmediatamente después de establecer un nexo causal o su probabilidad razonable, y a más tardar 15 días después de tener conocimiento; 2 días en caso de infracciones generalizadas o incidentes en infraestructuras críticas; 10 días en caso de muerte. Un informe inicial incompleto puede ir seguido de uno completo.	Evidencia de la cronología: las marcas de tiempo que llevan la mayoría de los artefactos firmados, tal como las declara quien firma (un checkpoint PQ y una autorización multiparte no tienen ninguna, y un manifiesto de bundle solo una ventana de sesión firmada opcional, `session_issued_at` y `session_expires_at`); las cabezas de árbol firmadas y las pruebas de inclusión del registro de transparencia; los recibos de anclaje. Artefactos relacionados con incidentes: revocación de emergencia (qué revocación se declaró y cuándo; no prueba que un proceso se detuviera), `termination_for_cause` y `sudden_failure` del ciclo de vida (DCP-05 §7.3, §7.5) con el sellado de la cadena de auditoría del registro de retirada (§8.3), registros de disputa con `evidence_hashes`, informes de vulneración de derechos con `evidence_hashes`.	`partial`	Decidir que un incidente es «grave», establecer el nexo causal y presentar la notificación ante la autoridad son actos del proveedor (y, según el art. 26(5), del responsable del despliegue). DCP no tiene ningún artefacto de notificación de incidentes graves; `rights_violation_report` se refiere a los derechos DCP-08 del propio agente, y `dispute_record`, a conflictos entre agentes. Ancla o registra con una cadencia que conserve la evidencia dentro de las ventanas de 2, 10 y 15 días.
Art. 73(6), párrafo primero	Tras la notificación, el proveedor investiga, realiza una evaluación de riesgos y adopta medidas correctoras.	Nueva verificación de la evidencia conservada (no una repetición de la ejecución): `verifySignedBundleV2` sobre el bundle conservado; comprobaciones de coherencia entre agentes (DCP-07 §9.2); eventos de auditoría `dispute_compliance_verified` / `dispute_compliance_failed`.	`partial`	La investigación y las medidas correctoras corresponden al proveedor.

3.6 Documentación técnica¶

Artículo	Obligación (paráfrasis)	Mecanismo de DCP	Cobertura	Lo que queda para la organización
Art. 11(1), anexo IV, puntos 1(b), 2(c), 2(h), 3	Documentación técnica elaborada antes de la introducción en el mercado y mantenida al día, con al menos los elementos del anexo IV: entre ellos, cómo interactúa el sistema con otro software, incluidos otros sistemas de IA (1(b)), la arquitectura del sistema (2(c)), las medidas de ciberseguridad (2(h)) y la vigilancia, el funcionamiento y el control del sistema, incluidas las medidas de supervisión humana (3).	Descripciones reutilizables y versionadas de la capa de rendición de cuentas: `spec/DCP-AI-v2.0.md` (normativa), `spec/DCP-01.md`–`spec/DCP-09.md`, `spec/BUNDLE.md`, `spec/VERIFICATION.md`, `spec/CANONICALIZATION_PROFILE.md`; los JSON Schemas de `schemas/v2/`; TECHNICAL_ARCHITECTURE.md (capas, servicios, despliegue); SECURITY_MODEL.md (modelo de amenazas, protecciones, requisitos operativos); NIST_CONFORMITY.md (algoritmos criptográficos); `spec/AUDIT-v2.0-FINAL.md`. Interoperabilidad con otros agentes: DCP-04 y la extensión del handshake de DCP-09 §8.	`partial`	El anexo IV trata del sistema de IA: finalidad prevista, desarrollo, datos, validación, métricas, gestión de riesgos (art. 9), cambios a lo largo del ciclo de vida, normas aplicadas, declaración de conformidad, plan de seguimiento posterior a la comercialización. Esas secciones corresponden al proveedor. Los documentos de DCP pueden citarse para las partes de 1(b), 2(c), 2(h) y 3 que describen la capa de rendición de cuentas, con la versión fijada (sección 5). El Omnibus modificó el art. 11(1) para extender la documentación simplificada a las pequeñas empresas de mediana capitalización.
Art. 13(3)(d), art. 13(3)(f)	Las instrucciones de uso describen las medidas de supervisión humana (art. 14) y, cuando proceda, los mecanismos que permiten a los responsables del despliegue recoger, almacenar e interpretar los logs según el art. 12.	El formato del registro (`schemas/v2/audit_entry.schema.json`), las reglas de encadenamiento y de Merkle (DCP-03, core §10), la lista de comprobación de la verificación (`spec/VERIFICATION.md`), las opciones de almacenamiento (STORAGE_AND_ANCHORING.md) y la CLI (`dcp validate-bundle`, `dcp merkle-root`) son exactamente ese mecanismo, y los controles de supervisión de la sección 3.2 son medidas describibles.	`partial`	Redactar las instrucciones de uso. Un proveedor que distribuya el control de DCP puede remitir a este documento y a las especificaciones para el mecanismo de registro y los controles de supervisión, indicando cuáles están integrados (art. 14(3)(a)) y cuáles debe hacer funcionar el responsable del despliegue (art. 14(3)(b)).
Art. 9	Sistema de gestión de riesgos: continuo, documentado, a lo largo de todo el ciclo de vida; identificación, estimación y evaluación de los riesgos; medidas; pruebas con métricas predefinidas.	`risk_score`, `risk_tier` y el nivel de seguridad son señales de control en tiempo de ejecución por acción, y el rastro de auditoría es una fuente de datos para el art. 9(2)(c) (riesgos que surgen de los datos posteriores a la comercialización). Los registros de obligaciones de DCP-08 llevan un `compliance_status` firmado y `evidence_hashes`; los `compliance_criteria` con `threshold` y `measurement_interval` que muestra el ejemplo de DCP-08 §5.2 no son campos de esquema.	`partial`	El sistema de gestión de riesgos es un proceso del proveedor, no una función del protocolo. No presentes las puntuaciones de riesgo de DCP como la evaluación de riesgos del art. 9.

3.7 Intersección con la protección de datos¶

Artículo	Obligación (paráfrasis)	Mecanismo de DCP	Cobertura	Lo que queda para la organización
Art. 19(1), art. 26(6) (la cláusula «unless provided otherwise in ... Union law on the protection of personal data»), art. 26(9)	La conservación de los logs cede ante la normativa de protección de datos; los responsables del despliegue usan la información del art. 13 para su evaluación de impacto relativa a la protección de datos del RGPD.	RPR cegado (core §12.1, `schemas/v2/blinded_rpr.schema.json`, `generatePiiSalt`, `blindRpr`, `verifyBlindedRpr`; Python `blind_rpr`/`verify_blinded_rpr`, Go `BlindRPR`/`VerifyBlindedRPR`): el `legal_name` y el `contact` del RPR se sustituyen por un compromiso con sal `pii_hash = sha256(canonical({contact, legal_name, pii_salt}))`; el `pii_salt` (32 bytes aleatorios) se firma con el RPR completo y quien llama debe mantenerlo privado (`blindRpr` lo omite, pero el RPR completo lo conserva); el registro cegado conserva `human_id`, `override_rights`, `jurisdiction`, `liability_mode`, `binding_keys` y la validez. Borrar el RPR completo y su sal hace que el compromiso publicado no pueda abrirse, lo que la especificación ofrece como supresión para los registros y anclajes inmutables (art. 17 del RGPD); eso no acredita por sí solo el cumplimiento del RGPD ni la anonimización, porque `human_id`, las demás copias y cualquier preimagen filtrada siguen existiendo. `human_id` DEBE ser opaco y NO DEBE derivarse de datos personales. Los anclajes y el registro de transparencia solo guardan hashes (STORAGE_AND_ANCHORING.md, «What goes on-chain»).	`supports`	Enviar a los anclajes y a los registros de transparencia solo hashes, nunca un RPR, ni siquiera cegado; mostrar a las contrapartes ajenas a la organización solo RPR cegados; mantener toda copia del RPR completo (y las copias comunicadas) bajo un procedimiento de supresión; hacer que `human_id` sea opaco; fijar la base de conservación del RGPD para las entradas de auditoría que llevan `human_id`. La evaluación de impacto relativa a la protección de datos y la base jurídica corresponden al responsable del despliegue. Los compromisos `pii_hash` heredados sin sal están obsoletos y cualquiera que adivine los datos personales puede confirmarlos (core §12.1).

4. Calendario de aplicación¶

4.1 Situación del texto jurídico en la fecha de la revisión¶

Acto de base. Reglamento (UE) 2024/1689, de 13/06/2024, publicado en el DO L el 12/07/2024 (EUR-Lex, CELEX 32024R1689). Art. 113: entrada en vigor el vigésimo día siguiente al de su publicación y aplicación a partir del 02/08/2026, con las fechas escalonadas de abajo.
Digital Omnibus on AI. La Comisión lo propuso el 19/11/2025 dentro del paquete digital de simplificación. El acuerdo político entre el Parlamento y el Consejo se anunció el 07/05/2026. El acto se adoptó como Reglamento (UE) 2026/1744, de 08/07/2026, que modifica los Reglamentos (UE) 2024/1689, (UE) 2018/1139 y (UE) 2023/1230; se publicó en el DO L 2026/1744 el 24/07/2026 y, según su artículo 4, entró en vigor el tercer día siguiente al de su publicación, el 27/07/2026 (EUR-Lex, ELI reg/2026/1744). EUR-Lex lo indica como «In force». La página de política sobre el Reglamento de IA de la Comisión (actualizada por última vez el 19/10/2026) y su noticia del 27/07/2026 indican las mismas fechas.
Qué significa para este documento. En la fecha de la revisión, el calendario ya no es una propuesta: los aplazamientos son Derecho promulgado. Durante la fase de propuesta (de noviembre de 2025 a julio de 2026), las preguntas frecuentes de la Comisión describían el aplazamiento como «maximum 16 months later» para el anexo III y «maximum 12 months later» para el anexo I, ligado a la disponibilidad de normas y herramientas de apoyo; las fechas de calendario de abajo son las promulgadas. Las fechas marcadas «según se promulgó» proceden del art. 113 del acto de base; las marcadas «según la modificación» proceden del art. 1(39)–(40) del Reglamento (UE) 2026/1744.

4.2 Fechas¶

Fecha	Disposición	Fuente	Relevancia para esta correspondencia
01/08/2024	Entrada en vigor del Reglamento (UE) 2024/1689	Art. 113, párrafo primero (según se promulgó)	—
02/02/2025	Capítulos I y II (disposiciones generales, prácticas prohibidas)	Art. 113, párrafo tercero, letra (a) (según se promulgó; la redacción modificada mantiene la fecha y excluye las nuevas prohibiciones del art. 5)	Definiciones de proveedor y de responsable del despliegue (sección 2).
02/08/2025	Capítulo III, sección 4; capítulo V (modelos de IA de uso general); capítulo VII; capítulo XII y art. 78, salvo el art. 101	Art. 113, párrafo tercero, letra (b) (según se promulgó)	No lo cubre este documento.
27/07/2026	Entrada en vigor del Reglamento (UE) 2026/1744; se aplican los artículos 102 a 110 del Reglamento de IA	Art. 4 del Rgto. 2026/1744; art. 113, párrafo tercero, nueva letra (d) (según la modificación)	—
02/08/2026	Fecha general de aplicación del Reglamento de IA, incluidos el art. 50 (obligaciones de transparencia) y el capítulo IX (art. 72, seguimiento posterior a la comercialización; art. 73, incidentes graves; art. 86, derecho a explicación)	Art. 113, párrafo segundo (según se promulgó, no modificado)	Los arts. 50, 72, 73 y 86 no están en las secciones 1–3 aplazadas del capítulo III. Su alcance práctico para un sistema determinado depende de su clasificación como de alto riesgo, cuyos requisitos sustantivos se aplican en las fechas de abajo. Las organizaciones deberían leer el capítulo IX junto con el art. 111(2) modificado y con su asesoría jurídica.
02/12/2026	Nuevas prohibiciones del art. 5(1), párrafo primero, letras (ba) y (bb), y art. 5(1a) y (1b); plazo para que los proveedores de sistemas de IA generativa introducidos en el mercado antes del 02/08/2026 cumplan el marcado del art. 50(2)	Art. 113, párrafo tercero, letra (a) (según la modificación); art. 111(4) (según la modificación)	El art. 50(2) queda fuera del alcance de DCP (sección 3.4).
02/09/2027	Orientaciones de la Comisión, plantilla incluida, sobre el plan de seguimiento posterior a la comercialización	Art. 72(3) (según la modificación)	Sección 3.5.
02/12/2027	Capítulo III, secciones 1, 2 y 3 (arts. 6–27, salvo el art. 6(5)) para los sistemas de IA clasificados como de alto riesgo según el art. 6(2) y el anexo III	Art. 113, párrafo tercero, letra (c)(i) (según la modificación; según se promulgó, era el 02/08/2026)	Los arts. 9, 11, 12, 13, 14, 19, 26 y 27 de esta correspondencia se aplican a los sistemas del anexo III desde esta fecha.
02/08/2028	Capítulo III, secciones 1, 2 y 3, para los sistemas de IA clasificados como de alto riesgo según el art. 6(1) y el anexo I (componentes de seguridad de productos regulados)	Art. 113, párrafo tercero, letra (c)(ii) (según la modificación; según se promulgó, las obligaciones del art. 6(1) se aplicaban desde el 02/08/2027)	Los mismos artículos, para los sistemas del anexo I.
02/08/2030	Sistemas de IA de alto riesgo destinados a ser usados por autoridades públicas e introducidos en el mercado o puestos en servicio antes de la fecha de aplicación del capítulo III	Art. 111(2) (según la modificación)	Sistemas heredados de responsables del despliegue del sector público.

Periodo de gracia para los sistemas heredados: el art. 111(2) modificado aplica el Reglamento a los sistemas de alto riesgo introducidos en el mercado o puestos en servicio antes de la fecha de aplicación del capítulo III solo si sufren «significant changes in their designs» después de ella.

4.3 Qué cambió y qué no cambió el Omnibus en los artículos de esta correspondencia¶

Verificado contra el art. 1 del Reglamento (UE) 2026/1744 el 22/10/2026:

Artículo	¿Lo modificó el Omnibus?	Efecto
Arts. 9, 12, 13, 14, 19, 26, 86	No	Contenido sin cambios; las fechas de aplicación de los arts. 9, 12, 13, 14, 19 y 26 se desplazan con el capítulo III (sección 4.2).
Art. 11(1)	Sí, párrafo segundo	Documentación técnica simplificada extendida a las pequeñas empresas de mediana capitalización.
Art. 27(4)–(5)	Sí	La evaluación de impacto relativa a los derechos fundamentales puede remitir a partes de una evaluación de impacto relativa a la protección de datos del RGPD o incluirlas; la plantilla de la Oficina de IA debe permitirlo.
Art. 50(7)	Sí	La Comisión (ya no la Oficina de IA) fomenta códigos de buenas prácticas sobre la detección, el marcado y el etiquetado del contenido generado y, teniendo en cuenta el dictamen del Comité, evalúa su adecuación con arreglo al procedimiento del art. 56(6). Se suprimió el acto de ejecución que aprobaba los códigos; se mantiene el acto de ejecución que establece normas comunes si un código es inadecuado. Art. 50(1)–(6) sin cambios.
Art. 72(3)	Sí	La plantilla mediante acto de ejecución se sustituye por orientaciones de la Comisión, plantilla incluida, a más tardar el 02/09/2027.
Art. 73	No directamente	El nuevo art. 75(1a) encamina a la Oficina de IA las notificaciones de incidentes graves de los sistemas que son de su competencia, aplicándose mutatis mutandis el art. 73(2)–(9).
Art. 111	Sí	Se sustituye el apartado 2 (periodo de gracia, plazo del 02/08/2030 para las autoridades públicas); se añade el apartado 4 (plazo del 02/12/2026 del art. 50(2) para los sistemas generativos que ya están en el mercado).
Art. 113	Sí, párrafo tercero	Se sustituyen las letras (a) y (c) y se añade la letra (d) (sección 4.2).

Nada de lo publicado después del 22/10/2026 (otras modificaciones, actos delegados o de ejecución, normas armonizadas, orientaciones de la Comisión según el art. 72(3) o el art. 73(7)) se refleja aquí.

5. Lista de comprobación para implementadores¶

Lo que un responsable del despliegue o un operador debe configurar o hacer funcionar para que las filas supports de la sección 3 sean ciertas en su despliegue. Los elementos marcados (proveedor) son para un proveedor que distribuye el control de DCP dentro del sistema de IA.

5.1 Registro y conservación (arts. 12, 19, 26(6))¶

Toda acción relevante del sistema de IA se declara como Intent y la controla una Policy Decision antes de ejecutarse; las acciones que se saltan el control se enumeran y justifican en las instrucciones de uso (proveedor).
Las entradas de auditoría se producen con la cadena de doble hash (hash_alg: "sha256+sha3-256", prev_hash_secondary) y con checkpoints PQ al intervalo del nivel resuelto (core §14.1: cada 50, 10 o 1 eventos).
Los bundles firmados y las entradas de auditoría (no solo los hashes) se escriben en un almacenamiento duradero bajo el control de la organización; la pasarela, el anclaje, el registro de transparencia y el servicio de revocación de referencia guardan el estado en memoria y no son un almacén de registro (OPERATOR_GUIDE.md, «Reference services keep state in memory only»). Define REVOCATION_STATE_PATH para el servicio de revocación y añade almacenamiento persistente antes de confiar en los demás.
Se fija para esos registros un periodo de conservación de al menos seis meses, ampliado cuando lo exijan la finalidad prevista, la normativa sectorial (p. ej., servicios financieros) o un incidente en curso, y reducido solo cuando lo exija la normativa de protección de datos.
Los checkpoints de compactación se usan solo con un archivo de los eventos compactados durante el periodo de conservación.
El texto o las reglas de la política detrás de cada applied_policy_hash están bajo control de versiones y se conservan durante el mismo periodo.
Las claves públicas de los agentes y el conjunto de claves de gobernanza se archivan al retirarlos (DCP-05 §8.4) para que las firmas conservadas sigan siendo verificables.
Los bundles conservados se vuelven a verificar periódicamente con verifySignedBundleV2 (o dcp verify-bundle) contra las claves archivadas y el estado de revocación, y el resultado se registra.

5.2 Evidencia de manipulación y anclaje (art. 73(6), evidencia para los arts. 72–73)¶

Las raíces de Merkle de la auditoría (o los hashes de los bundles) se envían a un registro de transparencia y/o se anclan con una cadencia fija. Elige una cadencia inferior a la ventana de notificación de incidentes más corta aplicable (dos días según el art. 73(3)); lo típico es agrupar por horas o por días (TECHNICAL_ARCHITECTURE.md, capa 4).
El registro de transparencia funciona con una OPERATOR_KEY persistente (para que las cabezas de árbol firmadas sigan verificándose tras los reinicios), almacenamiento persistente y al menos un par de gossip con una clave fijada (GOSSIP_PEERS).
Las pruebas de inclusión y los recibos de anclaje (anchor_receipt: cadena, transacción, bloque, o log_url y log_index) se guardan junto a los bundles que cubren.
Si se exige anclaje on-chain, se despliega un anclaje de producción contra contracts/ethereum/src/DCPAnchor.sol o un flujo OP_RETURN de Bitcoin; el servicio de anclaje de referencia por sí solo registra tx_hash: null.

5.3 Supervisión humana (arts. 14, 26(1)–(2))¶

Cada agente en un contexto de alto riesgo tiene un RPR con override_rights: true, un expires_at vigente y unas binding_keys en poder del principal responsable, no del entorno de ejecución del agente.
El principal responsable (o las personas con las que se corresponde un RPR de tipo organization) son las personas físicas asignadas a la supervisión humana según el art. 26(2), y esa correspondencia se mantiene en un registro interno.
Las reglas de la política devuelven escalate con required_confirmation para los tipos de acción, clases de datos y niveles de impacto que el responsable del despliegue quiere que apruebe una persona; la aplicación se bloquea ante una Human Confirmation ausente o con deny.
Se declaran umbrales de atención por mandato con action_if_triggered en escalate o block para las dimensiones que importan; las declaraciones de asesoramiento llevan un response_deadline coherente con DCP-09 §5.3, y se vigila proceeded_without_response.
Existe un secreto de revocación de emergencia para cada agente, en poder del principal responsable fuera del entorno de ejecución del agente, y la aplicación tiene un interruptor de apagado que detiene el proceso cuando se activa la revocación (la revocación por sí sola no detiene un proceso en ejecución).
Los verificadores comprueban el estado de revocación dentro de la latencia de propagación del nivel más alto que atienden (SECURITY_MODEL.md, «Revocation Propagation SLAs»), y el TTL de la caché de verificación sigue core §14.5. En @dcp-ai/sdk 2.2.1 publicado y anteriores, el VerificationCache de TypeScript se indexa solo por el hash del bundle y su invalidateByAgent no hace nada; el código fuente de main (no publicado) añade la invalidación por agente y un contexto opcional, pero nada se invalida automáticamente. En ambos casos, invalídalo o vacíalo cuando cambien la revocación o la confianza (API_REFERENCE.md).
Para la identificación biométrica remota, la regla de las dos personas del art. 14(5) se implementa con autorización multiparte sobre la intención y se documenta como un proceso del responsable del despliegue.

5.4 Custodia de claves y política del verificador¶

Las claves privadas se guardan según los requisitos del nivel de SECURITY_MODEL.md («Private Key Storage»): HSM o TPM DEBERÍA para elevated, DEBE para maximum. Este repositorio no proporciona integración con HSM ni TPM (el HsmCryptoProvider del código TypeScript es una simulación), así que esa custodia procede de la infraestructura propia de la organización.
La política del verificador (VerifierPolicy, VERIFIER_MODE) usa al menos hybrid_preferred, con unos risk_overrides que nunca bajen del modo del nivel; ALLOW_V1_BUNDLES=false una vez completada la migración.
Los endpoints del operador están bloqueados con OPERATOR_TOKEN; TRUST_PROXY se define solo detrás de un proxy que añade la IP del cliente.
Los endpoints de DCP-05–09 de la pasarela de referencia, que OPERATOR_TOKEN no protege y que no verifican firmas, no se exponen a clientes que no sean de confianza (OPERATOR_GUIDE.md); los registros que guardan no se tratan como evidencia verificada.

5.5 Protección de datos (sección 3.7)¶

Los RPR se crean con pii_salt; los anclajes y los registros de transparencia solo reciben hashes, y las contrapartes ajenas a la organización solo ven RPR cegados.
human_id es un identificador opaco, no un correo electrónico, un nombre ni el hash de ninguno de ellos.
Un procedimiento de supresión cubre toda copia del RPR completo, incluidas las copias comunicadas a reguladores o contrapartes, de modo que la supresión del compromiso sea real.
La evaluación de impacto relativa a la protección de datos (y, cuando se aplique el art. 27, la evaluación de impacto relativa a los derechos fundamentales) enumera los registros de DCP que contienen human_id y su conservación.

5.6 Documentación (arts. 11, 13) — proveedor¶

Las instrucciones de uso indican qué medidas de supervisión están integradas en el sistema (art. 14(3)(a)) y cuáles debe hacer funcionar el responsable del despliegue (art. 14(3)(b)), y describen el formato del registro y el mecanismo de verificación (art. 13(3)(f)) por referencia a versiones fijadas de este documento, spec/DCP-AI-v2.0.md, spec/VERIFICATION.md y schemas/v2/.
La documentación técnica del anexo IV cita DCP solo para la capa de rendición de cuentas (puntos 1(b), 2(c), 2(h), 3) y nombra la versión de la especificación de DCP, las versiones de los paquetes de los SDK y la política del verificador en uso.

6. Carencias: lo que DCP no aborda¶

Se indican para que nadie cite DCP para ellas.

Área	Por qué DCP no lo cubre
Clasificación como de alto riesgo, determinación del proveedor y del responsable del despliegue	Determinaciones jurídicas sobre el sistema de IA y las organizaciones; DCP no conoce la finalidad prevista del sistema.
Sistema de gestión de riesgos (art. 9), gestión de la calidad, evaluación de la conformidad, marcado CE, registro en la base de datos de la UE (arts. 49, 71)	Procesos del proveedor y actos administrativos. `risk_score` es una señal de control por acción, no una evaluación de riesgos.
Documentación técnica del sistema de IA (art. 11, anexo IV, puntos 1(a), 1(c)–(h), 2(a)–(b), 2(d)–(g), 4–9)	Describe el modelo, los datos, la validación y los cambios; DCP documenta solo la capa de rendición de cuentas.
Instrucciones de uso (art. 13(2)–(3))	Un documento del proveedor. DCP puede citarse en él, no sustituirlo.
Sesgo de automatización, competencia y formación de los supervisores (arts. 14(4)(b), 26(2))	Factores humanos; fuera de cualquier registro que produzca DCP.
Detener el sistema de IA en un estado seguro (art. 14(4)(e))	La revocación detiene la aceptación de los bundles del agente; no detiene un proceso ni deshace una acción.
Registro específico de la biometría (art. 12(3)(a)–(c)) y la propia verificación por dos personas (art. 14(5))	DCP no tiene campos para bases de datos de referencia ni entradas coincidentes, y no puede atestiguar la competencia.
Marcado de contenido y comunicación de ultrasuplantaciones (art. 50(2), 50(4))	Medidas técnicas distintas sobre el contenido generado.
Comunicación a las personas físicas (arts. 26(11), 50(1), 50(5))	La interfaz y la redacción corresponden al proveedor y al responsable del despliegue; DCP solo aporta una prueba verificable de la identidad del agente.
Notificaciones a las autoridades de vigilancia del mercado y al proveedor (arts. 26(5), 73)	DCP no tiene ningún artefacto de notificación. `rights_violation_report` se refiere a los derechos DCP-08 del agente (integridad de la memoria, transición digna, coherencia de la identidad, registro inmutable); `dispute_record`, a conflictos entre agentes. Ninguno es una notificación de incidente grave.
Reclamaciones y explicaciones para las personas físicas afectadas (arts. 27(1)(f), 85, 86)	Las disputas de DCP-07 y los derechos de DCP-08 son mecanismos entre los agentes y sus principales. Las personas afectadas no son parte en el protocolo.
Plan de seguimiento posterior a la comercialización (art. 72(3))	Forma parte de la documentación del anexo IV del proveedor; los registros de DCP son datos de entrada para él.
Imposición de la conservación	Ningún campo de DCP ni regla del verificador impone un periodo de conservación; DCP-08 §3.5 enuncia el principio y la organización lo implementa. La `data_disposition` del registro de retirada (`transferred`, `archived`, `destroyed`) registra una decisión, no la impone. El `archive_retention_period` que muestra el ejemplo de DCP-05 §8.2 no es un campo de `schemas/v2/decommissioning_record.schema.json`.
Acciones fuera del control de intenciones	La inferencia del modelo, los eventos de la interfaz y las llamadas a herramientas no declaradas como intenciones no producen ningún registro de DCP.
Contenido de los checkpoints PQ (etiqueta histórica v2.10.0)	En la etiqueta histórica del repositorio v2.10.0, ningún verificador de SDK comprueba el contenido de los checkpoints PQ (`spec/VERIFICATION.md` V2-12, OPERATOR_GUIDE.md): los checkpoints se producen y se firman, pero un verificador solo comprueba la cadena y las raíces de Merkle. En `main` los verificadores de los SDK ya los comprueban, y según sus notas de publicación los paquetes actuales incluyen esas comprobaciones: npm `@dcp-ai/sdk` 2.2.0 y `@dcp-ai/wasm` 2.1.0 (npm), Python `dcp-ai` 2.10.0 (Python), Go v2.11.0 (Go) y Rust `dcp-ai` 2.11.0 (Rust). Véanse también CHANGELOG.md y Versiones publicadas.
Almacenamiento duradero en los servicios de referencia	La pasarela, el anclaje y el registro de transparencia de referencia guardan su estado en memoria; el servicio de revocación también, salvo que `REVOCATION_STATE_PATH` apunte a un almacenamiento persistente (opcional). El servicio de anclaje no envía transacciones on-chain.
Autenticación de los endpoints de DCP-05–09 de la pasarela de referencia	Validan esquemas, pero no verifican firmas ni exigen un token; cualquiera que pueda llegar a ellos puede cambiar el estado del ciclo de vida, de las disputas y de los mandatos (OPERATOR_GUIDE.md).

7. Fuentes leídas para la revisión jurídica (22/10/2026)¶

Textos oficiales:

Reglamento (UE) 2024/1689, texto tal como se publicó, HTML en EUR-Lex: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R1689 — título y encabezado del Diario Oficial, los encabezados de las secciones 1–4 del capítulo III y de las secciones 1–4 del capítulo IX, los artículos 3 (puntos 1, 3, 4, 12, 49), 9, 11, 12, 13, 14, 19, 26, 27, 50, 72, 73, 85, 86, 113 y el anexo IV, anclas #art_<n> y #anx_IV.
Reglamento (UE) 2026/1744 (Digital Omnibus on AI): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng — título, referencia del DO, considerandos 39–41, artículo 1, puntos (10), (13), (20), (30), (31), (39), (40), artículo 4.

Páginas oficiales de la Comisión:

Página de política sobre el Reglamento de IA: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (actualizada por última vez el 19/10/2026).
Noticia del 07/05/2026, acuerdo político: https://digital-strategy.ec.europa.eu/en/news/eu-agrees-simplify-ai-rules-boost-innovation-and-ban-nudification-apps-protect-citizens
Noticia del 27/07/2026, entrada en vigor: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
Preguntas frecuentes del paquete digital (fase de propuesta): https://digital-strategy.ec.europa.eu/en/faqs/digital-package (actualizada por última vez el 20/11/2025).

Documentos del repositorio en los que se basa esta correspondencia: spec/DCP-AI-v2.0.md (§8–§12, §14, §18), spec/DCP-01.md–spec/DCP-03.md, spec/DCP-05.md, spec/DCP-07.md, spec/DCP-08.md, spec/DCP-09.md, spec/VERIFICATION.md, schemas/v2/*.schema.json, STORAGE_AND_ANCHORING.md, OPERATOR_GUIDE.md, SECURITY_MODEL.md, TECHNICAL_ARCHITECTURE.md, OBSERVABILITY.md, services/README.md, sdks/typescript/src/index.ts.

Este documento es informativo. No modifica las especificaciones y no es asesoramiento jurídico.