This file bundles five R-1 article subpages of the EU AI Act (Regulation (EU) 2024/1689) reference: Article 26 (deployer obligations for high-risk systems), Article 27 (Fundamental Rights Impact Assessment — FRIA), Article 53 (general-purpose AI (GPAI) provider obligations), Annex III (the high-risk-system list), and Annex IV (the technical- documentation pack — index entry; the §1–§9 walkthrough lives in [FORWARD-REF: R-3]). Each subpage shares the same six-section structure: one-sentence summary → verbatim regulatory text → who is bound and when → operative requirements → adjacent obligations → what veric emits. All footnotes are pooled at the end of the file under "Sources".

Article 26 — deployer obligations for high-risk AI systems

Summary

Article 26 of the EU AI Act (Regulation (EU) 2024/1689)¹ transfers operational liability for high-risk AI from the provider who built the system to the deployer who puts it into service — including duties of input-data relevance assessment, log retention, human-oversight assignment, and serious-incident reporting from 2 August 2026.²

Verbatim regulatory text

Deployers of high-risk AI systems shall take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems, pursuant to paragraphs 3 and 6. — Article 26(1), Regulation (EU) 2024/1689¹

Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. — Article 26(2)

To the extent the deployer exercises control over the input data, that deployer shall ensure that input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system. — Article 26(4)

Deployers shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law. — Article 26(6)

Before putting into service or using a high-risk AI system at the workplace, deployers who are employers shall inform workers' representatives and the affected workers that they will be subject to the use of the high-risk AI system. — Article 26(7)

Who this binds + when

External labels: the duties land on the Chief AI Officer's program, the DPO's records, the General Counsel's contractual reps to suppliers, and — for banking and insurance — the Chief Risk Officer's model-risk inventory. SMEs face the lower of the two-amount fine bands under Article 99³.

What the obligation actually requires

Six operative duties survive parsing of the article into a deployer checklist:

1. Use-per-instructions discipline — the provider's Article 13 instructions-for-use are not advisory; deviation invalidates the provider's conformity-assessment coverage and shifts liability to the deployer (Article 26(1) + Article 25(1)(c)).
2. Human-oversight assignment — named natural persons with competence, training, and authority (Article 26(2)). "Authority" matters: the overseer must be able to override, halt, or refuse the system's output — not merely receive notifications.
3. Input-data relevance check — where the deployer controls inputs, the deployer inherits part of the Article 10 representativeness obligation (Article 26(4)). Procurement of an off-the-shelf model with deployer-supplied fine-tuning data is the canonical fact pattern.
4. Log retention ≥ 6 months — Article 26(6) cross-refers to Article 12 logs; the floor is six months, and sectoral law (HIPAA 6y, SOX 7y, AI Act Art 18 10y for the provider) can extend it.⁴
5. Serious-incident reporting — Article 26(5) requires the deployer to inform the provider, the distributor, and the national market-surveillance authority "without undue delay" when use of the system has caused or risks causing harm; the strict ≤15-day / ≤2-day clocks of Article 73 then attach to the provider's downstream notification.⁵
6. Workforce notice + worker-rep consultation — Article 26(7), coordinated with national labour law. Late notification is the most likely first-wave Article 26 enforcement entry point — works councils across the German Mitbestimmung and the French CSE frameworks are already tracking AI deployments at the firms their members are employed by.

The article's most under-appreciated paragraph is Article 26(11) — deployers must explain to affected natural persons the role of the AI system in any decision that produces legal or similarly significant effects, mirroring GDPR Article 22(3) but with a wider materiality threshold and no exception for non-personal-data processing.

Adjacent obligations

• Provider-side counterpart: Article 13 instructions-for-use, Annex IV §3 human-oversight measures.
• FRIA cross-reference: deployers in the populations covered by Article 27 must complete the FRIA before first use, not just at procurement.
• Annex III scoping: a system is "high-risk" only if it falls in Annex III (or Annex I); deployers escape Article 26 entirely if neither annex catches the use.
• Documentation pack: the provider's Annex IV pack is the deployer's evidence input — request it as a procurement precondition. R-3 walks the §1–§9 contents [FORWARD-REF: R-3].
• Logs at Article 12: the same Article 12 logs that the provider retains for 10 years per Article 18⁶ are the artefacts the deployer holds for ≥6 months under Article 26(6).

What veric emits here

veric is compile-time infrastructure; it does not certify human- oversight assignments or replace works-council consultations. It emits the build-time evidence the deployer's Article 26 program needs as inputs:

• Provenance certificate (D1) — passed from provider to deployer at procurement. Combines primitives P1 (schema-level semantic tagging), P2 (tag-flow propagation), and P4 (build-time manifest emission) over license tags (T1), jurisdiction tags (T5), and source-system tags (T10). Lets the deployer demonstrate its Article 26(4) input-data relevance check is grounded in evidence, not assertion.
• PR-time CI diff (D8) — wraps the deployer's input-data pipeline. P5 (cross-build diff) + P3 (forbidden-flow refutation) surface fine-tuning-data drift before it lands in production — the operational analogue of "we use the system per instructions".
• Continuous provenance ledger (D9) — append-only store of D1+D2+D7. Furnishes the Article 26(6) ≥6-month log obligation with a tamper-evident, regulator-receivable artefact rather than a CSV dump.

Article 27 — Fundamental Rights Impact Assessment (FRIA)

Summary

Article 27 obliges a defined set of deployers — public authorities, private bodies providing public services, and banks and insurers running Annex III high-risk AI in credit and life/health underwriting — to conduct and notify a Fundamental Rights Impact Assessment before first use⁷, extending GDPR Article 35 DPIA practice into a parallel rights-based regime that the AI Office and national fundamental-rights bodies will use as a triage signal.

Verbatim regulatory text

Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5(b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce. — Article 27(1), Regulation (EU) 2024/1689⁷

The assessment […] shall consist of: (a) a description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose; (b) a description of the period of time within which, and the frequency with which, each high-risk AI system is intended to be used; (c) the categories of natural persons and groups likely to be affected by its use in the specific context; (d) the specific risks of harm likely to have an impact on the categories of natural persons or groups of persons identified pursuant to point (c) […]; (e) a description of the implementation of human oversight measures […]; (f) the measures to be taken in the case of the materialisation of those risks, including the arrangements for internal governance and complaint mechanisms. — Article 27(1)(a)–(f)

Once the assessment […] has been performed, the deployer shall notify the market surveillance authority of its results, by submitting the filled-out template […]. — Article 27(3)

Who this binds + when

External labels: the FRIA lands on the deployer's DPO desk (where GDPR Article 35 DPIA practice already exists), the Chief AI Officer's pre-deployment gate, and the Chief Risk Officer in banking and insurance. The AI Office will publish the notification-template at a date the regulation does not pin — deployers are expected to file the FRIA result electronically once the template is live.⁸

What the obligation actually requires

The FRIA is a six-element written instrument with a material notification step:

1. Process description (Article 27(1)(a)) — narrative of the business process the system is embedded in; granular enough that a regulator can identify decision points.
2. Use period and frequency (Article 27(1)(b)) — including whether use is one-shot, periodic, or continuous; informs the risk-window analysis.
3. Affected categories of natural persons (Article 27(1)(c)) — not merely "EU residents"; the regulator wants protected-group enumeration sufficient to ground the disparate-impact analysis in Article 27(1)(d).
4. Specific harm risks (Article 27(1)(d)) — including risks to marginalised groups; the EDPB's GDPR Article 35 DPIA reasoning is the working analogue, but Article 27 expressly requires fundamental-rights framing, not data-protection framing alone.⁹
5. Human-oversight implementation (Article 27(1)(e)) — names, training, escalation paths; this paragraph is where Article 26(2) compliance is operationally documented.
6. Materialisation response + complaint mechanism (Article 27(1)(f)) — incident-response runbook plus the Article 85 right-to-lodge-a-complaint workflow at the affected-person level.
7. Notification to market-surveillance authority (Article 27(3)) — once the AI Office publishes the FRIA template, the completed FRIA is filed; non-filing is itself an Article 99(4) non-compliance.

The most-litigated phrase will be Article 27(2)'s allowance to "draw on" the GDPR Article 35 DPIA where the DPIA already covers the same processing — draw on, not substitute. Counsel should expect to deliver two parallel documents (DPIA + FRIA) for the foreseeable future, with shared evidentiary base but distinct legal addressees.

Adjacent obligations

• Annex III scope: Article 27 only fires for Annex III high-risk systems; the §2 critical-infrastructure carve-out excepts them from the FRIA but not from Article 26.
• Annex IV provider pack: the FRIA pulls heavily from the provider's Annex IV documentation for system characteristics — the §1–§9 walkthrough is at [FORWARD-REF: R-3].
• GDPR Article 35 DPIA: parallel, not substitutable. EDPB Opinion 28/2024 sets the data-protection baseline the FRIA presumes.⁹
• Sectoral overlays: in banking, the FRIA is read alongside SR 26-2 / OCC Bulletin 2026-13 for cross-Atlantic deployments¹⁰; in insurance, alongside the NAIC AI Model Bulletin (Dec 2023).

What veric emits here

The FRIA is a written instrument; veric is a compile-time substrate. The intersection is narrower than for Article 26 but load-bearing for paragraphs (a)–(d):

• Annex IV technical-doc pack (D3) — composes primitives P1 (schema-level semantic tagging), P2 (tag-flow propagation), and P4 (build-time manifest emission) over the full T1–T10 vocabulary to populate Article 27(1)(a)'s process description with reproducible system facts. The pack is the provider deliverable the deployer's FRIA author works from.
• Forbidden-flow attestation (D2) — composes P3 (forbidden-flow refutation) and P6 (multi-tag conjunction/disjunction) over protected-class proxies (T6 PII / special-category) and jurisdiction tags (T5). Lets Article 27(1)(d) name the disparate-impact risk surface mechanically rather than hand-curate it. Replaces "we believe no protected-class proxy reaches the scoring model" with a machine-checkable certificate.
• Model-card lineage appendix (D5) — composes P1 + P2 + P4 in the Mitchell-card format; the deployer attaches it to the FRIA as an Annex 27(1)(c)/(d) supporting artefact rather than rebuilding the system characterisation from scratch.

Article 53 — General-Purpose AI (GPAI) provider obligations

Summary

Article 53 binds every general-purpose AI model provider — including open-source providers, who escape the technical-documentation duty in Article 53(2) but not the copyright policy in Article 53(1)(c) or the public training-content summary in Article 53(1)(d) — to ship four artefacts: an Annex XI tech pack to the AI Office, documentation for downstream providers, a documented copyright- compliance policy, and a public training-content summary on the AI Office's 24 July 2025 template.¹¹¹²

Verbatim regulatory text

Providers of general-purpose AI models shall: (a) draw up and keep up-to-date the technical documentation of the model, including its training and testing process and the results of its evaluation, which shall contain, at a minimum, the information set out in Annex XI for the purpose of providing it, upon request, to the AI Office and the national competent authorities; (b) draw up, keep up-to-date and make available information and documentation to providers of AI systems who intend to integrate the general-purpose AI model into their AI systems […]; (c) put in place a policy to comply with Union law on copyright and related rights, and in particular to identify and comply with, including through state-of-the-art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790; (d) draw up and make publicly available a sufficiently detailed summary about the content used for training of the general- purpose AI model, according to a template provided by the AI Office. — Article 53(1), Regulation (EU) 2024/1689¹¹

The obligations set out in paragraph 1, points (a) and (b), shall not apply to providers of AI models that are released under a free and open-source licence […]. This exception shall not apply to general-purpose AI models with systemic risks. — Article 53(2)

Who this binds + when

External labels: the obligation lands on the Chief AI Officer at a GPAI provider, the General Counsel's IP and competition workstreams, and the Head of Trust & Safety responsible for the public summary. Penalties for Article 53 non-compliance reach €15M or 3% of worldwide turnover, whichever is higher (Article 99(4)); supplying incorrect information sits at €7.5M / 1%.³

What the obligation actually requires

Each of the four duties is operationally distinct and produces a different artefact under a different audience:

1. Article 53(1)(a) — Annex XI technical documentation to the AI Office on request. Annex XI mirrors Annex IV's structure but is GPAI-tailored: training process, capabilities, limitations, computational resources, and (for systemic-risk models) Article 55-specific information. Open-source providers are exempt except for systemic-risk GPAI.
2. Article 53(1)(b) — downstream-provider documentation. System-builders integrating a GPAI model need enough information to discharge their own Annex IV obligations. Practically: a documentation pack distinct from (a), API-developer-facing rather than regulator-facing. Open-source exemption applies.
3. Article 53(1)(c) — copyright policy, with explicit Article 4(3) DSM Directive opt-out compliance and "state-of-the-art technologies" for opt-out detection. The GPAI Code of Practice (10 July 2025)¹³ operationalises this through Copyright Measures 1–4. Open-source providers are not exempt.
4. Article 53(1)(d) — public training-content summary on the AI Office's 24 July 2025 template¹². Three sections: (1) general information, (2) data sources by category, (3) data-processing measures including lawfulness and opt-out honoring. Mandatory for new models since 2 August 2025; legacy models from 2 August 2027. Open-source providers are not exempt. R-4 of this content series walks the template field-by-field [FORWARD-REF: R-4].

The open-source carve-out is the most-misread paragraph in Article 53. Article 53(2) exempts paragraphs (a) and (b) only — not (c), not (d) — and the exemption further evaporates the moment a model crosses the Article 51 systemic-risk threshold (≥10²⁵ training FLOPs presumption, rebuttable). Open-weight providers shipping at the frontier are bound to the full set.

Adjacent obligations

• High-risk pipeline: GPAI is distinct from Annex III high-risk — Article 53 binds the model layer, Annex III + Article 26 bind the system layer. A foundation-model provider can be both if it ships a downstream high-risk system on its own model.
• Systemic-risk overlay: Article 55 (model evaluations, adversarial testing, serious-incident reporting to the AI Office, cybersecurity) attaches when the Article 51 FLOPs threshold trips. The GPAI Code of Practice's Safety & Security chapter¹³ is the working spec.
• Copyright overlay: Article 53(1)(c) is enforced against the acquisition of training data, not the act of training — the Bartz v. Anthropic settlement (preliminarily approved 25 September 2025, $1.5B)¹⁴ is the reference fact-pattern.
• Cross-jurisdiction: California AB 2013 (effective 1 Jan 2026)¹⁵ requires a similar but distinct on-website training-data summary for GenAI made available to Californians since 1 Jan 2022 — a GPAI provider with EU and US footprint will publish two summaries with overlapping but non-identical fields.
• Annex IV cross-link: Article 53(1)(a)'s Annex XI pack reuses much of the Annex IV scaffold.

What veric emits here

veric's mechanical product-surface map¹⁶ places three deliverables against Article 53:

• Training-content summary (D6) for Article 53(1)(d) — composes primitives P1 (schema-level semantic tagging) and P4 (build-time manifest emission) into the AI Office template format over license tags (T2), TDM-opt-out signals (T4), jurisdiction tags (T5), and source-system tags (T10). The summary is derived from the build rather than authored alongside it; if the dbt manifest contradicts the summary, veric build exits non-zero.
• Forbidden-flow attestation (D2) for Article 53(1)(c) — composes P3 (forbidden-flow refutation) and P6 over license tags and TDM-opt-out signals. Produces a machine-checkable certificate that no training row carries license=copyright_restricted or tdm_optout_signal=true into a model-input feature.
• Annex IV technical-doc pack (D3) for Article 53(1)(a) — same composition that satisfies Annex IV §2(d) for high-risk systems satisfies Annex XI §1–§3 for GPAI providers; the AI Office's Annex XI template overlaps significantly with Annex IV §2 in data-set fields. R-3 walks the §1–§9 contents [FORWARD-REF: R-3]; the operational walkthrough of the Article 53(1)(d) template itself is at [FORWARD-REF: R-4].

Annex III — the high-risk AI systems list

Summary

Annex III enumerates eight categories of high-risk AI systems — biometrics, critical infrastructure, education and vocational training, employment and worker management, essential private and public services, law enforcement, migration and border control, and administration of justice plus democratic processes — that trigger the full provider regime in Articles 8–22 and the deployer regime in Articles 26–27 from 2 August 2026.²¹⁷

Verbatim regulatory text

High-risk AI systems pursuant to Article 6(2) are the AI systems listed in any of the following areas:

1. Biometrics, in so far as their use is permitted under relevant Union or national law: (a) remote biometric identification systems […]; (b) AI systems intended to be used for biometric categorisation according to sensitive or protected attributes or characteristics […]; (c) AI systems intended to be used for emotion recognition.
2. Critical infrastructure: AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity.
3. Education and vocational training: AI systems intended to be used [for admissions, learning-outcome assessment, level of education prediction, and exam-cheating monitoring].
4. Employment, workers management and access to self-employment: AI systems intended to be used [for recruitment, work allocation, task allocation, and performance evaluation].
5. Access to and enjoyment of essential private services and essential public services and benefits: AI systems intended to be used [for public-benefit eligibility, creditworthiness assessment (excl. fraud detection), life- and health-insurance risk assessment and pricing, dispatch of emergency services].
6. Law enforcement […].
7. Migration, asylum and border control management […].
8. Administration of justice and democratic processes […]. — Annex III, Regulation (EU) 2024/1689¹⁷

(The eight area headers are reproduced verbatim; sub-points are paraphrased for length. Cite the EUR-Lex consolidated text¹ for operative wording.)

Who this binds + when

External labels: Annex III is the procurement-team's first-stop reference. The CAIO's AI use-case inventory must classify every in-scope use against the eight categories; vendors selling into banking, insurance, recruitment, or essential services should expect a §1–§8 questionnaire as a pre-RFP filter from 2026 H2.

What the obligation actually requires

Annex III is a list, not an obligation in itself — it is the trigger for Articles 8–22 (provider obligations) and Articles 26–27 (deployer obligations). Three operative things follow from a system landing in Annex III:

1. Provider conformity-assessment regime — Article 43 routes the provider through internal assessment (Annex VI) or notified-body assessment (Annex VII) depending on the area; biometric and high-risk-as-product systems take the heavier path.
2. Article 6(3) downward exception — a system in an Annex III area is not high-risk if it performs a narrow procedural task, improves prior human-completed activity, detects decision patterns without replacing human assessment, or performs purely preparatory work — unless it profiles natural persons. The provider must document the exception application and register it under Article 49 in the EU database. This is the most-tested loophole; expect AI Office guidance through 2026–2027.
3. EU database registration — Article 49 + Annex VIII require public registration before placing on the market.

The eight categories are not equally enforcement-active. Annex III §4 (employment) and §5 (essential services) inherit existing enforcement infrastructure from EU labour and consumer-protection regulators; §1 (biometrics) inherits from data-protection authorities under EDPB coordination⁹; §6 (law enforcement) and §7 (migration) sit under Member State competent authorities still being designated.

Adjacent obligations

• Article 26 deployer regime: every Annex III system triggers Article 26 duties for the deployer.
• Article 27 FRIA: a sub-set of Annex III (with a §2 carve-out) triggers the Article 27 rights assessment.
• Annex IV documentation: every Annex III provider produces an Annex IV pack — the §1–§9 walkthrough is at [FORWARD-REF: R-3].
• GPAI overlay: a foundation-model provider that ships a downstream Annex III system on its own model is bound by both Article 53 and the high-risk regime.
• Sectoral overlays: HHS §1557 ACA AI nondiscrimination final rule (May 2024)¹⁸ catches US healthcare uses overlapping Annex III §5; ONC HTI-1 DSI rule (Jan 2024)¹⁹ adds a 31-attribute source-attribute disclosure for certified-EHR predictive DSIs.

What veric emits here

Annex III selection happens at procurement and contracting; veric attaches at the build that produces the system. Mapping an Annex III area to compile-time evidence:

• Provenance certificate (D1) — composes primitives P1, P2, and P4 over the full T1–T10 vocabulary. Furnishes Article 26(4) input- data evidence for any Annex III area, with §5 (creditworthiness, insurance) being the highest-value first deployment given the Article 27 FRIA coupling.
• Annex IV pack (D3) — composes P1 + P2 + P4 across all tag types into the AI Act-required §1–§9 bundle. Shipped pre-Article 43 conformity assessment as the technical-documentation deliverable.
• PR-time CI diff (D8) — composes P5 + P3. Lands at the engineering layer for any Annex III pipeline; "this PR causes pii=true to reach analytics.public_dashboard_export" is the failure mode the diff makes visible at PR review time, weeks before a deployer's incident-reporting clock under Article 26(5) would otherwise start.

Annex IV — technical documentation pack (index entry)

Summary

Annex IV defines the nine-section technical documentation pack every provider of an Annex III high-risk system must draw up before placing the system on the market and keep current for 10 years post-market (Article 11 + Article 18)⁴²⁰; this entry indexes the section structure and points into the field-by-field walkthrough [FORWARD-REF: R-3].

Verbatim regulatory text

The technical documentation referred to in Article 11(1) shall contain at least the following information, as applicable to the relevant AI system:

1. A general description of the AI system […];
2. A detailed description of the elements of the AI system and of the process for its development […] including: (d) where relevant, the data requirements in terms of datasheets describing the training methodologies and techniques and the training data sets used, including a general description of these data sets, information about their provenance, scope and main characteristics; how the data was obtained and selected; labelling procedures (e.g. for supervised learning), data cleaning methodologies (e.g. outliers detection);
3. Detailed information about the monitoring, functioning and control of the AI system […];
4. A description of the appropriateness of the performance metrics for the specific AI system;
5. A detailed description of the risk management system in accordance with Article 9;
6. A description of relevant changes made by the provider to the system through its lifecycle;
7. A list of the harmonised standards applied […];
8. A copy of the EU declaration of conformity referred to in Article 47;
9. A detailed description of the system in place to evaluate the AI system performance in the post-market phase […]. — Annex IV, Regulation (EU) 2024/1689²⁰

Who this binds + when

External labels: the pack is the General Counsel's evidence binder, the Chief AI Officer's documentation deliverable, and the notified body's input under Article 43 conformity assessment (where applicable). SMEs may shape the pack to reduced detail under Article 11(1) sub-para. but cannot omit it.

What the obligation actually requires

This entry is intentionally an index — the operative §1–§9 walkthrough lives in R-3 [FORWARD-REF: R-3]. The structural contract:

• §1 — system identification, intended purpose, version, market state.
• §2 — development process, including the §2(d) datasheet obligation that anchors training-data documentation. Most veric evidence emission targets this section.
• §3 — monitoring, functioning, and control: the runtime control surface.
• §4 — performance-metric appropriateness.
• §5 — Article 9 risk-management system description.
• §6 — lifecycle change log.
• §7 — list of harmonised standards applied (CEN-CENELEC JTC 21 output).
• §8 — copy of the Article 47 EU declaration of conformity.
• §9 — post-market evaluation system per Article 72.

Reading the pack as a single evidence object: §2(d) is the most content-heavy section in operational practice, and the section where compile-time-derived facts compose most directly into auditor-receivable artefacts.

Adjacent obligations

• Article 11 (the obligation Annex IV specifies) and Article 18 (10-year retention)⁴: read Annex IV always alongside both.
• Article 26 deployer pack inputs.
• Article 27 FRIA pulls from §1, §2, §5.
• Annex III triggers the pack obligation in the first place.
• Article 53(1)(a) Annex XI is the GPAI variant of the same pack.
• Sectoral overlays: ONC HTI-1 DSI 31-attribute disclosure¹⁹, FDA PCCP²¹, SR 26-2 / OCC Bulletin 2026-13¹⁰ all attach additional documentation requirements that compose with Annex IV rather than replace it.
• Standards anchor: ISO/IEC 42001:2023 Annex A.7 controls map to Annex IV §2(d)²².

What veric emits here

This subpage is the index; the deliverable-by-section mapping is laid out in full in R-3 [FORWARD-REF: R-3]. The headline deliverables:

• Annex IV pack (D3) — composes primitives P1, P2, and P4 over all tag types into the §1–§9 bundle.
• Datasheet / Croissant manifest (D4) — composes P1 + P4 over license, jurisdiction, PII / special-category, and source-system tags (T2, T5, T6, T10) into the Annex IV §2(d) datasheet.
• Continuous provenance ledger (D9) — append-only store of D1, D2, and D7 over time; furnishes the Article 18 ten-year retention with a tamper-evident, regulator-receivable artefact.
• Erasure-completeness certificate (D7) — composes the net-new primitive P7 (erasure-completeness proof) with P3 to discharge the GDPR Article 17 readiness Annex IV §3 monitoring presumes.

What to do next

• Read [FORWARD-REF: R-3] for the Annex IV §1–§9 field-by-field walkthrough with a worked example (the fictional "Cardio-DSS" high-risk clinical decision-support model).
• Read [FORWARD-REF: R-4] for the Article 53(1)(d) AI Office template walkthrough with a worked example (the fictional "Aurelius-70B" GPAI model).
• Install veric: pip install veric — see the OSS repo [FORWARD-REF: O-1] for the GitHub Action wiring.
• Subscribe to AI Act Weekly [FORWARD-REF: S-3] for issue 1 (2026-05-25): curated AI Office, EDPB, OCC, FTC, and state-AG developments + every veric long-form as it ships.
• Read next: [FORWARD-REF: E-1] Why workflow attestation fails the Annex IV evidence test — the founder essay framing the gap that compile-time evidence closes.

Sources

Alphabetised by issuing body. Pooled across all five subpages. Footnote anchors retained for inline-citation continuity.

AI Office (DG-CNECT)

EDPB

European Parliament + Council (Regulation (EU) 2024/1689)

European Commission

Federal Reserve Board / OCC / FDIC

HHS (OCR)

HHS (ONC)

ISO / IEC

State of California

US courts (N.D. Cal.)

US FDA (CDRH)

Internal — veric companion docs