DCP-AI and the EU AI Act — Mapping of Logging, Human Oversight and Record-Keeping Obligations¶
Specification version: 2.0
Last updated: October 2026
Legal review date: 22 October 2026
Status: Informative. The legal sources were read on 22 October 2026 (Section 7); the implementation mapping describes the specifications, schemas and SDKs on main on 25 October 2026 and says where the historical repository tag v2.10.0 (22/10/2026) differs, and where a specification requires something that the SDK functions do not do. That tag is not the current release and is not the Python dcp-ai 2.10.0 package verified on 26/10/2026; the current versions are in Published versions
Note (27/10/2026). Only the row on the dual-hash chain in Section 3 (Art. 19(1) and Art. 26(6)) reflects the unreleased source-code work of 27 October 2026 on the secondary SHA3-256 fields. The legal reading date (22 October 2026) and the 25 October 2026 implementation snapshot of the rest of this document are unchanged.
Note (28/10/2026). That row now refers to the published SHA3 patch releases of 28 October 2026; the rest of this document is unchanged, except the checklist item on the verification cache, which now separates the published packages from the unreleased source on
main.
This document maps the obligations of Regulation (EU) 2024/1689 (the "AI Act"), as amended by Regulation (EU) 2026/1744 (the "Digital Omnibus on AI"), that concern traceability, logging, human oversight, record-keeping, explanation and incident evidence to the artifacts, services and SDK functions of DCP-AI. It follows the structure of NIST_CONFORMITY.md: numbered sections, a mapping table, an implementer checklist and an explicit list of gaps.
Every article cited below was read on 22 October 2026 in the official text on EUR-Lex. The base text is the regulation as published (CELEX 32024R1689); the amendments are taken from the Digital Omnibus on AI as published in the Official Journal. Section 4 says which dates come from which text. Where the text quotes the regulation, the quotes are limited to a few words; everything else is paraphrase and should not be read as the legal wording.
1. Scope and Disclaimer¶
DCP-AI is a protocol and an evidence format. It defines signed artifacts (in a bundle, the Responsible Principal Record, Agent Passport, Intent and Policy Decision are each a SignedPayload; lifecycle, dispute, rights and delegation records are signed by their own functions), audit entries that a signed bundle commits to through its audit Merkle root instead of signing them one by one, a tamper-evident audit trail, optional anchoring and transparency logging, and local verifiers, each of which checks only what its route covers (for example verifySignedBundleV2 for a V2 bundle).
DCP-AI is not:
- a conformity assessment, a harmonised standard, a common specification or a presumption of conformity under the AI Act;
- a risk management system (Art. 9), a quality management system, technical documentation (Art. 11) or a post-market monitoring plan (Art. 72) for any particular AI system;
- legal advice. Whether a given agent is an "AI system", whether it is high-risk, and who is the provider or deployer, is a determination the organisation must make with counsel.
What this document does is narrower: for each obligation listed, it names the DCP mechanism that produces evidence or enforces a control, says how far that mechanism goes (supports, partial, out of scope) and states what the provider or deployer must still do themselves. A row marked supports means the mechanism exists and does what the row says when configured as described in Section 5; it does not mean the obligation is discharged.
Coverage values used in Section 3:
| Value | Meaning |
|---|---|
supports |
A DCP artifact, verifier rule or reference service implements the mechanism the obligation calls for. Operating it correctly remains the organisation's job (Section 5). |
partial |
DCP produces evidence or a building block, but a material part of the obligation (a document, a process, a report, a human decision) is not something the protocol can produce. |
out of scope |
DCP does not address this and should not be cited for it. |
2. Roles: Provider and Deployer versus Operator, Responsible Principal and Agent¶
The AI Act attaches obligations to roles defined in Art. 3. A provider (Art. 3(3)) develops an AI system, or has it developed, and places it on the market or puts it into service under its own name. A deployer (Art. 3(4)) uses an AI system "under its authority", except in a personal non-professional activity. An AI system (Art. 3(1)) is a machine-based system operating with "varying levels of autonomy" that infers how to generate outputs from the input it receives. The Act's obligations attach to the AI system and the legal persons behind it.
DCP roles attach to an agent instance and to the human or organisation that answers for it:
| DCP role | Where it is recorded | Typical AI Act role | Notes |
|---|---|---|---|
| Responsible principal | schemas/v2/responsible_principal_record.schema.json: human_id, legal_name, entity_type (natural_person or organization), jurisdiction, liability_mode (owner_responsible), override_rights, binding_keys |
Deployer, or the natural person the deployer assigns human oversight to under Art. 26(2) | The RPR names who is responsible for the agent's actions. When entity_type is organization it is usually the deployer itself; when it is natural_person it is usually the person inside the deployer who holds override_rights. |
| Agent | schemas/v2/agent_passport.schema.json: agent_id, keys, principal_binding_reference, capabilities, risk_tier, status |
The AI system (or a component of one) | A DCP agent is one deployed instance with its own keys and lifecycle state. The provider of the underlying model or framework is not named in any DCP artifact. |
| Operator (of a verification service, policy engine, transparency log, anchor or revocation service) | server/, services/, verifier policy (OPERATOR_GUIDE.md) |
Usually the deployer; may be the provider when the provider ships the gating as part of the system, or a third party | The operator decides the verifier policy, the retention of audit data and the anchoring cadence. Several Section 5 items are the operator's. |
| Counterparty agent (DCP-04, DCP-09) | interaction_record.counterparty_agent_id, delegation mandates |
Another AI system, possibly another deployer | Interaction records give each side evidence of the other's mandate. |
Two consequences for the mapping:
- Provider-side obligations are mostly
partial. DCP does not know the model, the training data or the intended purpose. It can document how the accountability layer works (Section 3, Art. 11 row), not the AI system itself. - Deployer-side logging and oversight obligations are where DCP is strongest. Intent gating, policy decisions, the audit chain, the RPR's
override_rights, advisory declarations and lifecycle states are all deployer-facing controls that produce signed evidence.
The DCP-AI specifications use "human" and "principal" for the person bound by the RPR. This document uses "responsible principal" for that person and "deployer" and "provider" in the Act's sense.
3. Mapping Table¶
Each row: the article as read on EUR-Lex, a short paraphrase of the obligation, the DCP mechanism with precise references, the coverage, and what the organisation must still do. Spec references are to spec/DCP-AI-v2.0.md ("core §n") and the profile specifications spec/DCP-05.md to spec/DCP-09.md. Function names are from the TypeScript SDK (@dcp-ai/sdk, sdks/typescript/src/index.ts); the Python, Go, Rust and WASM SDKs each cover a different subset under their own naming, so check each SDK's README for what it exposes (see also API_REFERENCE.md).
3.1 Logging and tamper evidence¶
| Article | Obligation (paraphrase) | DCP mechanism | Coverage | What remains for the organisation |
|---|---|---|---|---|
| Art. 12(1) | High-risk systems must technically allow automatic recording of events (logs) over their lifetime. | Every gated action produces an audit entry that the signed bundle commits to through the audit Merkle root (entries are not signed one by one; schemas/v2/audit_entry.schema.json: audit_id, timestamp, agent_id, human_id, intent_id, intent_hash, policy_decision, outcome, evidence). The SDK does not gate actions or write logs on its own: the application builds each entry and passes it to the builder (BundleBuilderV2, with prevHashForEntry and intentHash as helpers). DCP-05 §9, DCP-07 §9, DCP-08 §8 and DCP-09 §9 specify audit entries for lifecycle, dispute, rights and delegation events; the SDK helpers for those events do not create them automatically, so the application must. |
supports |
Route every consequential action of the AI system through intent gating and write its audit entry. Actions taken outside DCP (model inference, UI events, tool calls not declared as intents) are not logged by DCP. |
| Art. 12(2) | Logging must give traceability appropriate to the intended purpose: events relevant to identifying risk situations, to post-market monitoring (Art. 72) and to the deployer's monitoring (Art. 26(5)). | Each audit entry links the intent (intent_id, intent_hash = SHA-256 of the canonical intent, DCP-03), the policy outcome (policy_decision: approved, escalated, blocked), the result (outcome) and the Action Evidence (evidence.tool, evidence.result_ref, evidence.evidence_hash). The Policy Decision carries risk_score (integer 0..1000), reasons, applied_policy_hash and resolved_tier. All artifacts of a session share a session_nonce (core §8). |
supports |
Define action_type, data_classes and estimated_impact so that they reflect the system's intended purpose; keep the policy versions behind applied_policy_hash so that a decision can be re-read later. |
| Art. 12(3) | For remote biometric identification systems (Annex III, point 1(a)): period of each use, reference database, matched input data, identity of the natural persons who verified the result. | Only the last item has a counterpart: schemas/v2/human_confirmation.schema.json records human_id, intent_id, decision (approve/deny) and a composite signature. DCP has no fields for reference databases or matched inputs. |
out of scope |
Biometric-specific log content is the provider's design. Human Confirmations can evidence who confirmed a result, not the match itself. |
| Art. 19(1) and Art. 26(6) | Providers (Art. 19) and deployers (Art. 26(6)) keep the automatically generated logs under their control for a period appropriate to the intended purpose, "of at least six months", unless Union or national law (in particular data protection law) provides otherwise. | Tamper evidence of what is kept: hash chain (prev_hash, DCP-03), dual-hash chain (prev_hash_secondary, hash_alg: "sha256+sha3-256", core §10.3, spec/VERIFICATION.md V2-11), Merkle roots in the bundle manifest (audit_merkle_root, audit_merkle_root_secondary, audit_count; merkleRootForAuditEntries, dualMerkleRoot), PQ checkpoints (schemas/v2/pq_checkpoint.schema.json, createPQCheckpoint, PQCheckpointManager, core §10.2) and compaction checkpoints (schemas/v2/audit_compaction.schema.json, createAuditCompaction in sdks/typescript/src/core/audit-compaction.ts, core §10.4) let a verifier detect, at any later date, whether a retained log has been altered since it was committed. SDK packages released before 28/10/2026 check the primary chain and Merkle root but not the secondary chain or audit_merkle_root_secondary; the verifiers from @dcp-ai/sdk 2.2.1, @dcp-ai/wasm 2.1.1, dcp-ai 2.10.1 (PyPI), Go v2.11.1 and Rust dcp-ai 2.11.1 check the secondary fields that are present, so rely on the secondary commitments as checked evidence only with a verifier that includes this check (STORAGE_AND_ANCHORING.md). Retention itself: DCP defines no retention period and no storage. STORAGE_AND_ANCHORING.md lists the storage options (portable bundle held by the holder, hashes anchored, revocations distributed); OPERATOR_GUIDE.md states that the reference gateway and services keep state in memory, unless the revocation service is given REVOCATION_STATE_PATH on persistent storage, and that "a restart, a deploy or a crash wipes their state". DCP-08 §3.5 (Immutable Record) says audit, vitality and lifecycle records "shall be preserved intact for the retention period specified in the commissioning certificate and decommissioning record", and the DCP-08 rights declaration example uses minimum_retention_period: "P7Y", but no schema field enforces a period. |
partial |
Store the signed bundles and audit entries (not only their hashes) in durable storage for at least six months, longer where the intended purpose or sector law requires it. Compaction (core §10.4) permits archiving compacted events while the checkpoint stays in the active chain; the archived events must still be kept for the retention period. Archive agents' public keys at decommissioning (DCP-05 §8.4) so that old signatures remain verifiable. Decide the GDPR basis for keeping human_id-bearing entries and apply the Blinded RPR (row 3.7) where the entries leave the organisation. |
| Art. 26(6) second subparagraph, Art. 19(2) | Financial institutions keep the logs as part of the documentation required by Union financial services law. | Bundles and audit entries are portable JSON (CBOR optional, core §16) and can be filed inside an existing records system. | partial |
Map the bundle archive to the records retention schedule already in force under financial services law. |
| Art. 73(6) second subparagraph | After a serious incident, the provider must not alter the AI system in a way that affects the later evaluation of the incident's causes before informing the authorities. | Anchoring (services/anchor, anchor_receipt in STORAGE_AND_ANCHORING.md) and the transparency log (services/transparency-log: POST /add, GET /proof/:index, GET /root/signed, RFC 6962 tree, Ed25519-signed tree heads) record a commitment to the state of the audit trail, so a later evaluator can tell whether the retained log matches what was committed (SECURITY_MODEL.md §6, "Retroactive modification"). The time of that commitment rests on the trust placed in the log or anchor operator; it does not show when the incident occurred or that the records are true. |
partial |
Anchor or log the audit Merkle root at a cadence shorter than the incident reporting deadlines of Art. 73 (Section 5). The reference anchor service does not yet submit transactions on-chain (tx_hash: null); use the transparency log, or a production anchor against contracts/ethereum/src/DCPAnchor.sol. |
3.2 Human oversight¶
| Article | Obligation (paraphrase) | DCP mechanism | Coverage | What remains for the organisation |
|---|---|---|---|---|
| Art. 14(1)–(3) | High-risk systems must be designed so that natural persons can effectively oversee them while in use; measures are commensurate with risk, autonomy and context, built in by the provider or implemented by the deployer. | Intent gating (DCP-02): no action without a declared Intent and a Policy Decision (approve, escalate, block); required_confirmation requests a Human Confirmation before the action. Adaptive scrutiny: the security tier (core §14, computeSecurityTier, effectiveVerificationMode) rises with risk_score, data_classes (pii, financial_data, health_data, credentials, children_data), action_type: "initiate_payment" and estimated_impact: "high", and a verifier MUST NOT downgrade it (core §14.3). Lifecycle states (DCP-05 §3): commissioned, active, declining, decommissioned; the specification requires principal approval to reactivate from declining, but validateStateTransition only checks that the transition is one of the allowed edges, not the approval. |
partial |
Decide which actions are gated and which policy produces escalate. The application or its integration enforces the gate on what is declared, and verifiers check the resulting evidence; the provider must make the AI system call the gate. The oversight measures (who, how, with what training) are the deployer's under Art. 26(2). |
| Art. 14(4)(a) | Overseers must be able to understand the system's capacities and limitations and monitor its operation, including detecting anomalies and unexpected performance. | Awareness thresholds (DCP-09 §4, schemas/v2/awareness_threshold.schema.json): signed threshold_rules[] with dimension, operator, value and action_if_triggered (notify, escalate, block); createAwarenessThreshold, evaluateSignificance, shouldNotifyHuman. Principal mirror (DCP-09 §6, schemas/v2/principal_mirror.schema.json, generateMirror). Vitality reports (DCP-05 §5–6, createVitalityReport) with anomaly detection (§6.5). Observability (OBSERVABILITY.md, dcpTelemetry): verify latency, bundles verified, errors and checkpoint latency by tier. |
partial |
The capacities and limitations of the AI system itself (accuracy, robustness, known failure modes) come from the provider's instructions for use (Art. 13). DCP tells the overseer what the agent did and what it declared it does not understand, not what the model can do. |
| Art. 14(4)(b) | Overseers must remain aware of automation bias. | None. | out of scope |
Training and interface design. The narrative layer of interaction records (row below) can make reasoning visible, which helps, but DCP does not address automation bias. |
| Art. 14(4)(c) | Overseers must be able to interpret the system's output correctly. | Interaction records (DCP-09 §7, schemas/v2/interaction_record.schema.json): a human-readable public_layer (terms, decisions, commitments) and a private_layer_hash committing to the technical detail; generateInteractionRecord. DCP-09 §7.3–7.4 describe the technical and narrative layers (the specification's example is richer than the schema's required fields). Advisory declarations (DCP-09 §5, schemas/v2/advisory_declaration.schema.json): action_summary, recommended_response, significance_score. Policy Decision reasons. |
partial |
Interpretation of model output (scores, classifications, generated content) is the provider's and the deployer's. DCP explains the agent's declared intent and its reasoning as recorded, not the model's output. |
| Art. 14(4)(d) | Overseers must be able to decide not to use the system or to disregard, override or reverse its output. | override_rights (boolean, required) in the RPR and copied unchanged into the Blinded RPR (core §12.1): the responsible principal's right to override is a signed, published attribute of the binding. Human Confirmation decision: "deny" on an escalated intent. Advisory response (DCP-09 §5.5): proceed, override, assume control, delegate elsewhere or acknowledge, signed by the principal and recorded in the audit chain; advisory_declaration.human_response, response_deadline, proceeded_without_response. Awareness rule action_if_triggered: "block". |
supports |
Set override_rights: true for every agent used in a high-risk context and make the application or its integration enforce a deny and a block: verifiers do not execute either decision or confirm that a human decided, and neither verification nor admission authorizes an action (an admission result carries action_authorized: false). Define who the principal is and keep that person's keys under their control (Section 5). |
| Art. 14(4)(e) | Overseers must be able to intervene or interrupt the system through a "stop" button or similar, bringing it to a safe state. | Emergency revocation (core §11.3, schemas/v2/emergency_revocation.schema.json): the pre-registered emergency_revocation_token in the passport is SHA-256(revocation_secret); revealing the secret revokes all of the agent's keys with no signature needed (generateEmergencyRevocationToken, buildEmergencyRevocation, verifyEmergencyRevocationSecret; POST /v2/emergency-revoke on the revocation service and the gateway, GET /v2/check/kid/:kid on the revocation service; the signed kid-level revocation is the revocation service's POST /v2/revoke). Revocation record (schemas/v2/revocation_record.schema.json, reason enum includes key_compromise_emergency). Lifecycle transition to declining or decommissioned (DCP-05 §3.2, validateStateTransition, createDecommissioningRecord), termination_for_cause mode (§7.3). Verifiers MUST invalidate cached results when a signer kid is revoked (core §14.5). |
partial |
Revocation stops acceptance of the agent's bundles by every verifier that checks revocations; it does not halt a running process or roll back an action already taken. The safe-state behaviour of the AI system is the provider's design. Pair revocation with an application-level kill switch, and meet the revocation propagation latency for the tier (SECURITY_MODEL.md, "Revocation Propagation SLAs"). |
| Art. 14(5) | For remote biometric identification (Annex III, point 1(a)): no action on an identification unless verified by at least two competent natural persons (with exceptions for law enforcement, migration, border control, asylum). | Multi-party authorization (schemas/v2/multi_party_authorization.schema.json, gateway POST /v2/multi-party/authorize, each party's signature verified against its registered keys and counted once). |
partial |
DCP can evidence that two distinct key holders approved an intent; it cannot evidence their competence or that the identification was "separately verified". The two-person rule is the deployer's process. |
| Art. 26(1)–(2) | Deployers use the system in line with the instructions for use and assign human oversight to natural persons with the necessary competence, training, authority and support. | The RPR binds the agent to a named natural person or organisation with override_rights; the Delegation Mandate (DCP-09 §3, schemas/v2/delegation_mandate.schema.json, createDelegationMandate, verifyMandateValidity, revokeDelegation) states what the agent may do on the principal's behalf (authority_scope: domain, actions_permitted, data_classes, limits; the prohibitions list of the DCP-09 §3.2 example is not a schema field); interaction_record and DCP-09 §7.5 record delegation compliance. |
partial |
Competence, training and support are organisational facts outside the record. Name the oversight person in the RPR (entity_type: "natural_person") or keep an internal register that maps an organization RPR to the persons assigned. |
| Art. 26(5) | Deployers monitor the system's operation, inform the provider under Art. 72, and if use may present a risk, inform the provider or distributor and the market surveillance authority and suspend use; serious incidents are reported first to the provider. | Evidence of operation: audit chain, Policy Decisions, interaction records, obligation records with compliance_status (DCP-08 §5, recordObligation, checkRightsCompliance), vitality reports. Suspension: passport status (suspended, declining, decommissioned), revocation, emergency revocation. Escalation: DCP-08 §6.4 specifies that an obligation breach opens a DCP-07 dispute, with the escalation deadlines of DCP-07 §3.2; the SDK does not open it automatically (reportViolation takes a dispute_id that the caller supplies, or null). |
partial |
Informing the provider, the distributor and the market surveillance authority, and deciding that a risk exists, are the deployer's acts. DCP has no artifact for a report to an authority. |
3.3 Traceability of decisions¶
| Article | Obligation (paraphrase) | DCP mechanism | Coverage | What remains for the organisation |
|---|---|---|---|---|
| Art. 12(2), Art. 13(1) | Traceability of the functioning of the system; operation transparent enough for the deployer to interpret output and use it appropriately. | Decision chain per action: 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) → optional Human Confirmation → audit entry with outcome and evidence. The bundle manifest (core §9, schemas/v2/bundle_manifest.schema.json) carries rpr_hash, passport_hash, intent_hash, policy_hash and the audit Merkle roots, and the bundle's composite signature covers the manifest. Verification is local and reproducible (spec/VERIFICATION.md, verifySignedBundleV2, gateway POST /v2/bundle/verify). Interaction records (DCP-09 §7) add the counterparty, the mandate and the narrative layer. |
supports |
Keep the policy text or rules behind each applied_policy_hash. reasons is free text: write reasons that a reviewer can read a year later. |
| Art. 12(2)(a) | Logs must help identify situations that may result in a risk within the meaning of Art. 79(1) or in a substantial modification. | risk_score, resolved_tier, estimated_impact and data_classes are signed per action and queryable; escalated and blocked outcomes are explicit; awareness thresholds and advisory declarations record the agent's own uncertainty (significance_score; the per-domain confidence scores of DCP-09 §4.2–4.3 appear in the specification's example, not in schemas/v2/awareness_threshold.schema.json). |
supports |
Define what counts as a risk situation for the intended purpose and alert on it. DCP provides the signals, not the alerting policy. |
| Art. 86(1) | An affected person subject to a decision taken by the deployer on the basis of the output of an Annex III high-risk system (except point 2), with legal or similarly significant adverse effects, may obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision and the main elements of the decision. | The signed Intent, Policy Decision (decision, reasons, risk_score) and Human Confirmation (who approved, when), and the audit entry (outcome, evidence) that the signed bundle commits to, plus the interaction record public_layer.decisions and the advisory action_summary, give the deployer signed declarations of what the agent intended, what the policy decided, the recorded confirmation (the confirming person's real-world identity is established outside DCP) and the declared outcome. |
partial |
The explanation to the affected person is a document the deployer writes in plain language; DCP supplies signed declarations, which do not prove that an action was actually carried out or establish anyone's legal identity. Decisions that were not gated as intents, and the model's reasoning behind an output, are not in the record. |
3.4 Explanation, redress and disputes¶
| Article | Obligation (paraphrase) | DCP mechanism | Coverage | What remains for the organisation |
|---|---|---|---|---|
| Art. 27(1)(e)–(f) | The fundamental rights impact assessment (public bodies, providers of public services, Annex III points 5(b) and (c)) describes the human oversight measures implemented and the measures taken if risks materialise, including internal governance and complaint mechanisms. | Concrete, documentable oversight measures: RPR override_rights, intent gating with escalate, Human Confirmations, awareness thresholds, advisory declarations, lifecycle controls, emergency revocation. Internal governance and escalation: DCP-07 three-level model (direct negotiation, contextual arbitration, human appeal, §5) with createDispute, escalateDispute, resolveDispute, createObjection; DCP-08 violation reports (reportViolation). |
partial |
The assessment itself (processes, affected persons, risks, Art. 27(1)(a)–(d)) is the deployer's. DCP-07 and DCP-08 are mechanisms between agents and their principals; they are not a complaint channel for affected natural persons (Section 6). The Omnibus amended Art. 27(4)–(5) to allow cross-references to a GDPR data protection impact assessment. |
| Art. 86 | Right to explanation (see row 3.3). | Human appeal (DCP-07 §5.3): any disputant may escalate to the responsible principals at any time; the human decision is final within the protocol and recorded as an arbitration resolution (schemas/v2/arbitration_resolution.schema.json). Dispute record (schemas/v2/dispute_record.schema.json: dispute_type, escalation_level including human_appeal, status, evidence_hashes). Narrative layer (DCP-09 §7.4): plain-language summary, key decisions with reasoning, unresolved items, action items for the principal. |
partial |
These mechanisms give the deployer's own humans a documented review path over the agent's decisions. The affected person's right under Art. 86 is exercised against the deployer, outside the protocol. |
| Art. 26(11), Art. 50(1) | Deployers of Annex III systems that make or assist decisions about natural persons inform them; providers ensure persons interacting with an AI system are informed they are interacting with one, unless obvious. | The Agent Passport is a signed, verifiable statement that the actor is an AI agent bound to a named principal, presentable to any counterparty (presentFull, presentCompact, presentReference; DCP-04 handshake for other agents). |
partial |
The disclosure to natural persons (interface, wording, timing "at the latest at the time of the first interaction", Art. 50(5)) is the provider's and the deployer's. DCP gives a verifiable proof to back the disclosure; it does not make it. |
| Art. 50(2), Art. 50(4) | Machine-readable marking of synthetic content; disclosure of deep fakes and of AI-generated text on matters of public interest. | None. evidence.evidence_hash can bind the declared bytes of an artefact; it does not prove that the artefact was actually generated, or that it was marked. |
out of scope |
Content marking and detection are separate technical measures. |
3.5 Incident reporting and post-market monitoring¶
| Article | Obligation (paraphrase) | DCP mechanism | Coverage | What remains for the organisation |
|---|---|---|---|---|
| Art. 72(1)–(2) | Providers establish a documented post-market monitoring system that actively collects and analyses data on performance throughout the lifetime, including data provided by deployers and the interaction with other AI systems. | Data a deployer can hand to a provider: audit entries with outcomes and evidence, Policy Decisions with risk_score, obligation records (schemas/v2/obligation_record.schema.json: obligation_type, compliance_status, evidence_hashes; the compliance_history of the DCP-08 §5.2 example is not a schema field), vitality reports (DCP-05 §6), interaction records with counterparty agents (DCP-09 §7), dispute and violation reports. Each is signed, or committed to by a signed bundle, and verifiable by the provider without trusting the deployer's database. |
partial |
The monitoring system and plan are the provider's. The Omnibus replaced Art. 72(3): the plan stays part of the Annex IV documentation, the Commission's implementing act for a template was removed, and the Commission is to adopt guidance including a template by 2 September 2027 (Section 4). |
| Art. 73(1)–(5) | Providers report serious incidents (Art. 3(49): death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental-rights obligations, serious harm to property or environment) to the market surveillance authority: immediately after establishing a causal link or its reasonable likelihood, and no later than 15 days after awareness; 2 days for widespread infringements or critical-infrastructure incidents; 10 days for a death. An incomplete initial report may be followed by a complete one. | Timeline evidence: the timestamps that most signed artifacts carry, as declared by the signer (a PQ checkpoint and a multi-party authorization have none, and a bundle manifest only an optional signed session window, session_issued_at and session_expires_at); the transparency log's signed tree heads and inclusion proofs; anchor receipts. Incident-adjacent artifacts: emergency revocation (which revocation was declared, and when; not proof that a process stopped), lifecycle termination_for_cause and sudden_failure (DCP-05 §7.3, §7.5) with the decommissioning record's audit chain seal (§8.3), dispute records with evidence_hashes, rights violation reports with evidence_hashes. |
partial |
Deciding that an incident is "serious", establishing the causal link and filing the report with the authority are the provider's (and, under Art. 26(5), the deployer's) acts. DCP has no serious-incident report artifact; rights_violation_report concerns the agent's own DCP-08 rights, and dispute_record concerns conflicts between agents. Anchor or log at a cadence that preserves the evidence inside the 2-, 10- and 15-day windows. |
| Art. 73(6) first subparagraph | After reporting, the provider investigates, performs a risk assessment and takes corrective action. | Re-verification of the retained evidence (not a replay of the execution): verifySignedBundleV2 over the retained bundle; cross-agent consistency checks (DCP-07 §9.2); dispute_compliance_verified / dispute_compliance_failed audit events. |
partial |
The investigation and the corrective action are the provider's. |
3.6 Technical documentation¶
| Article | Obligation (paraphrase) | DCP mechanism | Coverage | What remains for the organisation |
|---|---|---|---|---|
| Art. 11(1), Annex IV points 1(b), 2(c), 2(h), 3 | Technical documentation drawn up before placing on the market and kept up to date, containing at least the Annex IV elements: among them how the system interacts with other software including other AI systems (1(b)), the system architecture (2(c)), cybersecurity measures (2(h)), and the monitoring, functioning and control of the system including the human oversight measures (3). | Reusable, versioned descriptions of the accountability layer: spec/DCP-AI-v2.0.md (normative), spec/DCP-01.md–spec/DCP-09.md, spec/BUNDLE.md, spec/VERIFICATION.md, spec/CANONICALIZATION_PROFILE.md; the JSON Schemas in schemas/v2/; TECHNICAL_ARCHITECTURE.md (layers, services, deployment); SECURITY_MODEL.md (threat model, protections, operational requirements); NIST_CONFORMITY.md (cryptographic algorithms); spec/AUDIT-v2.0-FINAL.md. Interoperability with other agents: DCP-04 and the DCP-09 §8 handshake extension. |
partial |
Annex IV is about the AI system: intended purpose, development, data, validation, metrics, risk management (Art. 9), changes over the lifecycle, standards applied, declaration of conformity, post-market plan. Those sections are the provider's. The DCP documents can be cited for the parts of 1(b), 2(c), 2(h) and 3 that describe the accountability layer, with the version pinned (Section 5). The Omnibus amended Art. 11(1) to extend simplified documentation to small mid-caps. |
| Art. 13(3)(d), Art. 13(3)(f) | Instructions for use describe the human oversight measures (Art. 14) and, where relevant, the mechanisms that let deployers collect, store and interpret the logs under Art. 12. | The log format (schemas/v2/audit_entry.schema.json), the chaining and Merkle rules (DCP-03, core §10), the verification checklist (spec/VERIFICATION.md), the storage options (STORAGE_AND_ANCHORING.md) and the CLI (dcp validate-bundle, dcp merkle-root) are exactly such a mechanism, and the oversight controls of Section 3.2 are describable measures. |
partial |
Write the instructions for use. A provider that ships DCP gating can reference this document and the specifications for the logging mechanism and the oversight controls, stating which are built in (Art. 14(3)(a)) and which the deployer must operate (Art. 14(3)(b)). |
| Art. 9 | Risk management system: continuous, documented, over the whole lifecycle; identification, estimation and evaluation of risks; measures; testing against predefined metrics. | risk_score, risk_tier and the security tier are runtime gating signals per action, and the audit trail is a data source for Art. 9(2)(c) (risks emerging from post-market data). DCP-08 obligation records carry a signed compliance_status and evidence_hashes; the compliance_criteria with threshold and measurement_interval shown in the DCP-08 §5.2 example are not schema fields. |
partial |
The risk management system is a provider process, not a protocol feature. Do not present DCP risk scores as the Art. 9 risk assessment. |
3.7 Data protection crossover¶
| Article | Obligation (paraphrase) | DCP mechanism | Coverage | What remains for the organisation |
|---|---|---|---|---|
| Art. 19(1), Art. 26(6) (the "unless provided otherwise in ... Union law on the protection of personal data" clause), Art. 26(9) | Log retention yields to data protection law; deployers use the Art. 13 information for their GDPR data protection impact assessment. | Blinded RPR (core §12.1, schemas/v2/blinded_rpr.schema.json, generatePiiSalt, blindRpr, verifyBlindedRpr; Python blind_rpr/verify_blinded_rpr, Go BlindRPR/VerifyBlindedRPR): the RPR's legal_name and contact are replaced by a salted commitment pii_hash = sha256(canonical({contact, legal_name, pii_salt})); pii_salt (32 random bytes) is signed with the full RPR and must be kept private by the caller (blindRpr omits it, but the full RPR retains it); the blinded record keeps human_id, override_rights, jurisdiction, liability_mode, binding_keys and validity. Deleting the full RPR and its salt makes the published commitment unopenable, which the specification offers as erasure for immutable logs and anchors (GDPR Art. 17); it does not by itself establish GDPR compliance or anonymisation, since human_id, other copies and any leaked preimage remain. human_id MUST be opaque and MUST NOT be derived from PII. Anchors and the transparency log store only hashes (STORAGE_AND_ANCHORING.md, "What goes on-chain"). |
supports |
Send anchors and transparency logs only hashes, never an RPR, not even a blinded one; show counterparties outside the organisation only blinded RPRs; keep every copy of the full RPR (and disclosed copies) under a deletion procedure; make human_id opaque; set the GDPR retention basis for human_id-bearing audit entries. The data protection impact assessment and the legal basis are the deployer's. Legacy unsalted pii_hash commitments are deprecated and confirmable by anyone who guesses the PII (core §12.1). |
4. Application Timeline¶
4.1 Status of the legal text at the review date¶
- Base act. Regulation (EU) 2024/1689 of 13 June 2024, published in OJ L on 12 July 2024 (EUR-Lex, CELEX 32024R1689). Art. 113: entry into force on the twentieth day after publication, application from 2 August 2026, with the staggered dates below.
- Digital Omnibus on AI. The Commission proposed it on 19 November 2025 as part of the Digital Package on Simplification. Political agreement between Parliament and Council was announced on 7 May 2026. The act was adopted as Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230, published in OJ L 2026/1744 on 24 July 2026, and under its Article 4 entered into force on the third day after publication, 27 July 2026 (EUR-Lex, ELI reg/2026/1744). EUR-Lex lists it as "In force". The Commission's AI Act policy page (last updated 19 October 2026) and its news item of 27 July 2026 state the same dates.
- What this means for this document. At the review date the timeline is no longer a proposal: the deferrals are enacted law. During the proposal stage (November 2025 to July 2026) the Commission's FAQ described the deferral as "maximum 16 months later" for Annex III and "maximum 12 months later" for Annex I, tied to the availability of standards and support tools; the calendar dates below are the enacted ones. Dates below marked "as enacted" come from Art. 113 of the base act; dates marked "as amended" come from Art. 1(39)–(40) of Regulation (EU) 2026/1744.
4.2 Dates¶
| Date | Provision | Source | Relevance to this mapping |
|---|---|---|---|
| 1 August 2024 | Entry into force of Regulation (EU) 2024/1689 | Art. 113, first paragraph (as enacted) | — |
| 2 February 2025 | Chapters I and II (general provisions, prohibited practices) | Art. 113, third paragraph, point (a) (as enacted; amended wording keeps the date and carves out the new Art. 5 prohibitions) | Definitions of provider and deployer (Section 2). |
| 2 August 2025 | Chapter III Section 4, Chapter V (general-purpose AI models), Chapter VII, Chapter XII and Art. 78, except Art. 101 | Art. 113, third paragraph, point (b) (as enacted) | Not covered by this document. |
| 27 July 2026 | Entry into force of Regulation (EU) 2026/1744; Articles 102 to 110 of the AI Act apply | Art. 4 of Reg. 2026/1744; Art. 113, third paragraph, new point (d) (as amended) | — |
| 2 August 2026 | General date of application of the AI Act, including Art. 50 (transparency obligations) and Chapter IX (Art. 72 post-market monitoring, Art. 73 serious incidents, Art. 86 right to explanation) | Art. 113, second paragraph (as enacted, not amended) | Arts. 50, 72, 73 and 86 are not in the deferred Chapter III Sections 1–3. Their practical reach for a given system depends on its classification as high-risk, whose substantive requirements apply on the dates below. Organisations should read Chapter IX together with Art. 111(2) as amended and with counsel. |
| 2 December 2026 | New prohibitions in Art. 5(1), first subparagraph, points (ba) and (bb), and Art. 5(1a) and (1b); deadline for providers of generative AI systems placed on the market before 2 August 2026 to comply with Art. 50(2) marking | Art. 113, third paragraph, point (a) (as amended); Art. 111(4) (as amended) | Art. 50(2) is out of scope for DCP (Section 3.4). |
| 2 September 2027 | Commission guidance, including a template, on the post-market monitoring plan | Art. 72(3) (as amended) | Section 3.5. |
| 2 December 2027 | Chapter III Sections 1, 2 and 3 (Arts. 6–27, except Art. 6(5)) for AI systems classified as high-risk under Art. 6(2) and Annex III | Art. 113, third paragraph, point (c)(i) (as amended; as enacted this was 2 August 2026) | Arts. 9, 11, 12, 13, 14, 19, 26 and 27 of this mapping apply to Annex III systems from this date. |
| 2 August 2028 | Chapter III Sections 1, 2 and 3 for AI systems classified as high-risk under Art. 6(1) and Annex I (safety components of regulated products) | Art. 113, third paragraph, point (c)(ii) (as amended; as enacted Art. 6(1) obligations applied from 2 August 2027) | Same articles, for Annex I systems. |
| 2 August 2030 | High-risk AI systems intended to be used by public authorities and placed on the market or put into service before the Chapter III application date | Art. 111(2) (as amended) | Legacy systems of public-sector deployers. |
Grace period for legacy systems: Art. 111(2) as amended applies the Regulation to high-risk systems placed on the market or put into service before the Chapter III application date only if they undergo "significant changes in their designs" after it.
4.3 What the Omnibus did and did not change in the articles mapped here¶
Verified against Art. 1 of Regulation (EU) 2026/1744 on 22 October 2026:
| Article | Changed by the Omnibus? | Effect |
|---|---|---|
| Art. 9, 12, 13, 14, 19, 26, 86 | No | Substance unchanged; application dates for Arts. 9, 12, 13, 14, 19 and 26 move with Chapter III (Section 4.2). |
| Art. 11(1) | Yes, second subparagraph | Simplified technical documentation extended to small mid-cap enterprises. |
| Art. 27(4)–(5) | Yes | The fundamental rights impact assessment may cross-reference or include parts of a GDPR data protection impact assessment; the AI Office template must allow this. |
| Art. 50(7) | Yes | The Commission (no longer the AI Office) encourages codes of practice on detection, marking and labelling of generated content and, taking account of the Board's opinion, assesses their adequacy under the Art. 56(6) procedure. The implementing act approving codes was dropped; the implementing act laying down common rules if a code is inadequate remains. Art. 50(1)–(6) unchanged. |
| Art. 72(3) | Yes | Template by implementing act replaced with Commission guidance including a template by 2 September 2027. |
| Art. 73 | Not directly | New Art. 75(1a) routes serious-incident reports for systems under the AI Office's competence to the AI Office, with Art. 73(2)–(9) applying mutatis mutandis. |
| Art. 111 | Yes | Paragraph 2 replaced (grace period, public-authority deadline of 2 August 2030); paragraph 4 added (Art. 50(2) deadline of 2 December 2026 for generative systems already on the market). |
| Art. 113 | Yes, third paragraph | Points (a) and (c) replaced, point (d) added (Section 4.2). |
Anything published after 22 October 2026 (further amendments, delegated or implementing acts, harmonised standards, Commission guidance under Art. 72(3) or Art. 73(7)) is not reflected here.
5. Implementer Checklist¶
What a deployer or operator must configure or operate for the supports rows of Section 3 to be true in their deployment. Items marked (provider) are for a provider that ships DCP gating inside the AI system.
5.1 Logging and retention (Arts. 12, 19, 26(6))¶
- Every consequential action of the AI system is declared as an Intent and gated by a Policy Decision before execution; actions that bypass gating are enumerated and justified in the instructions for use (provider).
- Audit entries are produced with the dual-hash chain (
hash_alg: "sha256+sha3-256",prev_hash_secondary) and PQ checkpoints at the interval of the resolved tier (core §14.1: every 50, 10 or 1 events). - Signed bundles and audit entries (not only hashes) are written to durable storage under the organisation's control; the reference gateway, anchor, transparency log and revocation service hold state in memory and are not a store of record (OPERATOR_GUIDE.md, "Reference services keep state in memory only"). Set
REVOCATION_STATE_PATHfor the revocation service and add persistent storage before relying on the others. - A retention period of at least six months is set for those records, extended where the intended purpose, sector law (e.g. financial services) or an ongoing incident requires it, and shortened only where data protection law requires it.
- Compaction checkpoints are used only with an archive of the compacted events for the retention period.
- The policy text or rules behind every
applied_policy_hashare version-controlled and retained for the same period. - Agents' public keys and the governance key set are archived at decommissioning (DCP-05 §8.4) so that retained signatures remain verifiable.
- Retained bundles are re-verified periodically with
verifySignedBundleV2(ordcp verify-bundle) against the archived keys and revocation state, and the result is recorded.
5.2 Tamper evidence and anchoring (Art. 73(6), evidence for Arts. 72–73)¶
- Audit Merkle roots (or bundle hashes) are submitted to a transparency log and/or anchored at a fixed cadence. Choose a cadence shorter than the shortest incident reporting window that applies (two days under Art. 73(3)); hourly or daily batching is typical (TECHNICAL_ARCHITECTURE.md, Layer 4).
- The transparency log runs with a persistent
OPERATOR_KEY(so signed tree heads keep verifying across restarts), persistent storage, and at least one gossip peer with a pinned key (GOSSIP_PEERS). - Inclusion proofs and anchor receipts (
anchor_receipt: chain, transaction, block, orlog_urlandlog_index) are stored next to the bundles they cover. - If on-chain anchoring is required, a production anchor is deployed against
contracts/ethereum/src/DCPAnchor.solor a Bitcoin OP_RETURN flow; the reference anchor service alone recordstx_hash: null.
5.3 Human oversight (Arts. 14, 26(1)–(2))¶
- Each agent in a high-risk context has an RPR with
override_rights: true, a currentexpires_at, andbinding_keysheld by the responsible principal, not by the agent's runtime. - The responsible principal (or the persons an
organizationRPR maps to) are the natural persons assigned to human oversight under Art. 26(2), and this mapping is kept in an internal register. - Policy rules return
escalatewithrequired_confirmationfor the action types, data classes and impact levels the deployer wants a human to approve; the application blocks on a missing ordenyHuman Confirmation. - Awareness thresholds are declared per mandate with
action_if_triggeredset toescalateorblockfor the dimensions that matter; advisory declarations carry aresponse_deadlineconsistent with DCP-09 §5.3, andproceeded_without_responseis monitored. - An emergency revocation secret exists for every agent, is held by the responsible principal outside the agent's runtime, and the application has a kill switch that halts the process when revocation is triggered (revocation alone does not stop a running process).
- Verifiers check revocation state within the propagation latency of the highest tier served (SECURITY_MODEL.md, "Revocation Propagation SLAs"), and the verification cache TTL follows core §14.5. In published
@dcp-ai/sdk2.2.1 and earlier, the TypeScriptVerificationCacheis keyed only by the bundle hash and itsinvalidateByAgentdoes nothing; the source onmain(not published) adds agent invalidation and an opt-in context, but nothing is invalidated automatically. With either, invalidate or clear it when revocation or trust changes (API_REFERENCE.md). - For remote biometric identification, the two-person rule of Art. 14(5) is implemented with multi-party authorization over the intent and documented as a deployer process.
5.4 Key custody and verifier policy¶
- Private keys are stored per the tier requirements in SECURITY_MODEL.md ("Private Key Storage"): HSM or TPM SHOULD for
elevated, MUST formaximum. This repository provides no HSM or TPM integration (theHsmCryptoProviderin the TypeScript source is a simulation), so that custody comes from the organisation's own infrastructure. - The verifier policy (
VerifierPolicy,VERIFIER_MODE) uses at leasthybrid_preferred, withrisk_overridesthat never fall below the tier's mode;ALLOW_V1_BUNDLES=falseonce migration is complete. - Operator endpoints are locked with
OPERATOR_TOKEN;TRUST_PROXYis set only behind a proxy that appends the client IP. - The reference gateway's DCP-05–09 endpoints, which
OPERATOR_TOKENdoes not protect and which do not verify signatures, are not exposed to untrusted clients (OPERATOR_GUIDE.md); records they hold are not treated as verified evidence.
5.5 Data protection (Section 3.7)¶
- RPRs are created with
pii_salt; anchors and transparency logs receive only hashes, and counterparties outside the organisation see only Blinded RPRs. -
human_idis an opaque identifier, not an email, name or hash of either. - A deletion procedure covers every copy of the full RPR, including copies disclosed to regulators or counterparties, so that erasure of the commitment is real.
- The data protection impact assessment (and, where Art. 27 applies, the fundamental rights impact assessment) lists the DCP records that contain
human_idand their retention.
5.6 Documentation (Arts. 11, 13) — provider¶
- The instructions for use state which oversight measures are built into the system (Art. 14(3)(a)) and which the deployer must operate (Art. 14(3)(b)), and describe the log format and verification mechanism (Art. 13(3)(f)) by reference to pinned versions of this document,
spec/DCP-AI-v2.0.md,spec/VERIFICATION.mdandschemas/v2/. - The Annex IV technical documentation cites DCP only for the accountability layer (points 1(b), 2(c), 2(h), 3) and names the DCP specification version, SDK package versions and the verifier policy in use.
6. Gaps: What DCP Does Not Address¶
These are stated so that nobody cites DCP for them.
| Area | Why DCP does not cover it |
|---|---|
| Classification as high-risk, provider/deployer determination | Legal determinations about the AI system and the organisations; DCP has no view of the system's intended purpose. |
| Risk management system (Art. 9), quality management, conformity assessment, CE marking, EU database registration (Arts. 49, 71) | Provider processes and administrative acts. risk_score is a per-action gating signal, not a risk assessment. |
| Technical documentation of the AI system (Art. 11, Annex IV points 1(a), 1(c)–(h), 2(a)–(b), 2(d)–(g), 4–9) | Describes the model, data, validation and changes; DCP documents only the accountability layer. |
| Instructions for use (Art. 13(2)–(3)) | A provider document. DCP can be referenced in it, not substitute for it. |
| Automation bias, competence and training of overseers (Arts. 14(4)(b), 26(2)) | Human factors; outside any record DCP produces. |
| Halting the AI system in a safe state (Art. 14(4)(e)) | Revocation stops acceptance of the agent's bundles; it does not stop a process or undo an action. |
| Biometric-specific logging (Art. 12(3)(a)–(c)) and the two-person verification itself (Art. 14(5)) | DCP has no fields for reference databases or matched inputs, and cannot attest competence. |
| Content marking and deep-fake disclosure (Art. 50(2), 50(4)) | Separate technical measures on generated content. |
| Disclosure to natural persons (Arts. 26(11), 50(1), 50(5)) | Interface and wording are the provider's and the deployer's; DCP supplies a verifiable proof of agent identity only. |
| Reports to market surveillance authorities and to the provider (Arts. 26(5), 73) | DCP has no report artifact. rights_violation_report concerns the agent's DCP-08 rights (memory integrity, dignified transition, identity consistency, immutable record); dispute_record concerns conflicts between agents. Neither is a serious-incident report. |
| Complaints and explanations for affected natural persons (Arts. 27(1)(f), 85, 86) | DCP-07 disputes and DCP-08 rights are mechanisms between agents and their principals. Affected persons are not parties in the protocol. |
| Post-market monitoring plan (Art. 72(3)) | Part of the provider's Annex IV documentation; DCP records are inputs to it. |
| Retention enforcement | No DCP field or verifier rule enforces a retention period; DCP-08 §3.5 states the principle and the organisation implements it. The data_disposition of the decommissioning record (transferred, archived, destroyed) records a decision, it does not enforce one. The archive_retention_period shown in the DCP-05 §8.2 example is not a field of schemas/v2/decommissioning_record.schema.json. |
| Actions outside intent gating | Model inference, interface events and tool calls not declared as intents produce no DCP record. |
| PQ checkpoint contents (historical tag v2.10.0) | In the historical repository tag v2.10.0, no SDK verifier checks PQ checkpoint contents (spec/VERIFICATION.md V2-12, OPERATOR_GUIDE.md): checkpoints are produced and signed, but a verifier only checks the chain and the Merkle roots. On main the SDK verifiers already check them, and according to their release notes the current packages include those checks: npm @dcp-ai/sdk 2.2.0 and @dcp-ai/wasm 2.1.0 (npm), Python dcp-ai 2.10.0 (Python), Go v2.11.0 (Go) and Rust dcp-ai 2.11.0 (Rust). See also CHANGELOG.md and Published versions. |
| Durable storage in the reference services | The reference gateway, anchor and transparency log keep their state in memory; the revocation service does too unless REVOCATION_STATE_PATH points to persistent storage (an opt-in). The anchor service does not submit on-chain transactions. |
| Authentication of the reference gateway's DCP-05–09 endpoints | They validate schemas but do not verify signatures or require a token; anyone who can reach them can change lifecycle, dispute and mandate state (OPERATOR_GUIDE.md). |
7. Sources Read for the Legal Review (22 October 2026)¶
Official texts:
- Regulation (EU) 2024/1689, text as published, HTML on EUR-Lex: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R1689 — title and Official Journal header, the headings of Chapter III Sections 1–4 and Chapter IX Sections 1–4, Articles 3 (points 1, 3, 4, 12, 49), 9, 11, 12, 13, 14, 19, 26, 27, 50, 72, 73, 85, 86, 113 and Annex IV, anchors
#art_<n>and#anx_IV. - Regulation (EU) 2026/1744 (Digital Omnibus on AI): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng — title, OJ reference, recitals 39–41, Article 1 points (10), (13), (20), (30), (31), (39), (40), Article 4.
Official Commission pages:
- AI Act policy page: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (last updated 19 October 2026).
- News, 7 May 2026, political agreement: https://digital-strategy.ec.europa.eu/en/news/eu-agrees-simplify-ai-rules-boost-innovation-and-ban-nudification-apps-protect-citizens
- News, 27 July 2026, entry into force: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
- Digital Package FAQ (proposal stage): https://digital-strategy.ec.europa.eu/en/faqs/digital-package (last updated 20 November 2025).
Repository documents this mapping relies on: 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.
This document is informative. It does not amend the specifications and is not legal advice.