Operationalizing in Modulos

The EU AI Act becomes operational in Modulos through two framework templates that align to the two organizing levels of the Regulation: organization-wide obligations (Article 17 QMS, Article 22 authorized-representative governance, Article 49 registration governance, provider-side Article 73 serious-incident reporting) and per-AI-system obligations (Articles 6–15, Article 26 deployer duties including deployer-side incident handling, Article 27 FRIA, Article 43 conformity assessment, Article 50 transparency, Article 72 PMM, and Chapter V GPAI).

This page is the rollout playbook. For what each Article requires substantively, see the regime-specific spokes: high-risk, prohibited and transparency, roles, conformity assessment, GPAI, post-market monitoring.

Sources and baseline

Article numbers on this page are the OJ-published numbers in Regulation (EU) 2024/1689 (EUR-Lex CELEX 32024R1689 · OJ L, 12.7.2024). Modulos requirement codes (ORF-…, MRF-…) match the framework templates in modulos_platform; several platform requirement names now carry the final OJ-published Article number directly (see the Article-numbering note below).

Quick decision

• You are starting a fresh Modulos rollout for the EU AI Act → one organization project with OFF-1, plus one AI-application project per AI system with MFF-1. Set role and Use Case on each application project.
• You already have an organization project with other framework templates → add OFF-1 to it. The organization-level controls layer naturally with ISO 42001, ISO 27001, NIS2, DORA, GDPR org templates.
• You have a GPAI model → stays on MFF-1; the platform applies Product:GPAIM and (where systemic-risk) ProductProperty:SR tags, with SupplyTerms:GPAIMNonFOSS for non-FOSS GPAI models, driven by the scoping questionnaire. There is no separate GPAI template.
• You operate the same AI system as both provider and deployer → set both roles on the project; the relevant MFF-1 requirements scope in for both.

TL;DR

• OFF-1 (EU AI Act, organization-level) — 19 mapped requirements across the ORF-1…ORF-447 range. Article 17 QMS, Article 22 authorized-representative mandate, Article 49 registration governance, organization-level conformity-assessment policy, the provider-side Article 73 serious-incident reporting requirement (ORF-47) (recorded as evidence — no dedicated incident workflow surface), and the new Article 4a special-category bias-processing legal basis (ORF-447).
• MFF-1 (EU AI Act, application-level) — 57 mapped requirements across the MRF-1…MRF-413 range. Articles 6–15 high-risk obligations, Article 26 deployer duties (including MRF-49 deployer monitoring and incident handling), Article 27 FRIA, Article 43 conformity-assessment route, Article 47 declaration of conformity, Article 48 CE marking, Article 50 transparency, Article 72 post-market monitoring, Chapter V GPAI at MRF-120…MRF-131 (including MRF-128 / MRF-130 / MRF-131 covering Article 54 GPAI authorized-representative duties on the app side), adjacent Article 6(3) and Article 5 gates (MRF-111 and MRF-119), and the new Article 4a special-category bias-processing legal basis (MRF-413).
• EU AI Act settings surface (multi-select) — project-level Role (Provider / Deployer / Importer / Distributor / Authorized representative) and Use Case (High Risk / Limited Risk / Transparency), plus Product, Origin, Model Property, Project Requirements, Critical Issues and Supply Terms. Use Case is a pragmatic deployment-context filter, not a legal high-risk classification.
• Everything else is evidence-attached: FRIA, PMM plan, serious-incident reports, CE marking + declaration, GPAI Codes of Practice, conformity-assessment route selection, Article 25 substantial-modification rationale.
• Evidence attaches to controls (and control components), not directly to requirements. Controls in turn link to one or more requirements. The readiness signal on the requirement aggregates the control-level evidence.
• Reviews are reserved for control status changes; requirements use a readiness signal plus owner-attested fulfillment and do not have reviews.

Recommended project structure

Project	Template	When to use
One organization project	OFF-1 (add to existing org project if you already have one with other framework templates)	Article 17 QMS, Article 22 authorized representative governance, Article 49 registration governance, provider-side Article 73 serious-incident reporting (ORF-47), org-level policies and gating
One AI-application project per AI system	MFF-1	Per-system Articles 6–15, Article 26 deployer duties including deployer-side serious-incident observation (MRF-49), Article 27 FRIA, Article 43 conformity assessment, Article 50 transparency, Article 72 post-market monitoring; Chapter V where the system uses a GPAI model
GPAI model (where you are the model provider)	MFF-1; platform applies Product:GPAIM (and ProductProperty:SR if systemic-risk under Article 51; SupplyTerms:GPAIMNonFOSS for non-FOSS) via the scoping questionnaire	Chapter V Articles 53–55 + Codes of Practice (Article 56)

The split mirrors the Regulation's own design: organization-wide quality / accountability infrastructure on one side; per-AI-system substantive obligations on the other. Article 25 transitions (deployer → accidental provider) trigger a new MFF-1 project if you weren't already tracking the system as a provider.

Set up: a sequence that works

1. Add OFF-1 to your organization project. Confirm Article 17 QMS scope, Article 22 mandate, Article 49 registration governance, and the organization's serious-incident-reporting procedure (recorded as evidence on controls linked to ORF-47 — there is no dedicated incident workflow surface).
2. Create one AI-application project per AI system. Add MFF-1.
3. Set the EU AI Act Role on each application project — Provider / Deployer / Importer / Distributor / Authorized representative. A single project can carry multiple roles where the same legal entity wears more than one hat. (The platform also maintains an internal Default fallback when no role is set — this is not exposed in the settings UI.)
4. Set the EU AI Act Use Case — High Risk / Limited Risk / Transparency. This is a pragmatic deployment-context filter that scopes the active requirements set in MFF-1, not a legal high-risk classification. The legal answer to "is my system high-risk?" comes from the Article 6 + Annex III / Annex I scoping rationale recorded on the MFF-1 classification requirement, not from this dropdown. The four common industry labels (Unacceptable / High / Limited / Minimal) exist in OFF-1 template tagging metadata but are not the active settings UI (see common misreadings).
5. Scope the project — questionnaire or manual. Either complete the MFF-1 scoping questionnaire (guided flow that derives the scope from your answers about Annex I vs Annex III, Article 6(3) derogation, GPAI integration, Article 50 deployment characteristics, Article 27 FRIA applicability), or set the eight EU AI Act settings (Product, Role, Use Case, Origin, Model Property, Project Requirements, Critical Issues, Supply Terms) directly on Project → Settings → EU AI Act and use the Preview Changes step to see exactly which requirements and controls will move in or out of scope before you Apply. Both paths write to the same project configuration and use the same descoping algorithm. See Project Settings → EU AI Act for the field-by-field reference.
6. Set readiness on each scoped requirement and assign owner-attested fulfillment as evidence accumulates. The readiness signal answers "are we ready to be assessed?"; the fulfillment evidence is the auditable trail behind the answer.

Where things live in Modulos

Article / topic	Modulos location
Article 5 prohibited-practice screening	OFF-1 (organizational gating evidence) + MFF-1 (per-system applicability rationale)
Article 6 high-risk classification rationale	MFF-1 — scoping evidence; Article 6(3) derogation rationale where invoked
Article 6(3) derogation + Article 49(2) non-high-risk registration	MFF-1 — derogation rationale, plus Article 49(2) registration confirmation evidence
Article 8 compliance with Section 2 requirements	MFF-1 — readiness signal across MRF-1…MRF-65
Article 9 risk-management system	MFF-1 — MRF-1 (risk-management) + ongoing Article 9(2)(c) post-market feedback
Article 4a special-category data for bias detection / correction	MFF-1 (MRF-413) + OFF-1 (ORF-447) — record-of-processing (RoPA) justification and the six Article 4a safeguards recorded as control-level evidence
Article 10 data and data governance	MFF-1 — training / validation / test data documentation (the Article 10(5) special-category bias-processing basis is relocated to Article 4a by the Digital Omnibus)
Article 11 + Annex IV technical documentation	MFF-1 — Annex IV evidence library; provider authors the technical-file artifact
Article 12 / 19 logs	MFF-1 — logging configuration evidence + Article 26(5) deployer log-retention attestation
Article 13 transparency to deployers / Article 14 human oversight	MFF-1 — design evidence + instructions-for-use artifact
Article 15 accuracy, robustness, cybersecurity	MFF-1 — performance / robustness / cybersecurity evidence including Runtime Inspection signals
Article 16 provider duties	MFF-1 (per-system) layered on the relevant OFF-1 organization-level QMS, documentation, registration duties
Article 17 QMS	OFF-1 — QMS document set linked as evidence
Article 22 authorized representative	OFF-1 — written mandate + 10-year documentation hold
Article 23 / 24 importer / distributor	MFF-1 with the relevant role tagged on the project
Article 25 accidental-provider rationale	MFF-1 — substantial-modification rationale + supporting evidence (model fingerprint, prompt-template version, fine-tuning records)
Article 26 deployer duties	MFF-1 (Deployer role) — instructions-for-use compliance, oversight assignment, log retention, incident notification
Article 27 FRIA	MFF-1 — FRIA document + market-surveillance-authority notification artifact
Article 43 conformity-assessment route selection	MFF-1 — route rationale (Annex VI, Annex VII, or the Annex I Section A product-law integration route under Article 43(3)) + standards / common-specifications application evidence
Article 47 EU declaration of conformity	MFF-1 — versioned declaration evidence (Annex V content)
Article 48 CE marking	MFF-1 — affixing attestation evidence
Article 49 EU-database registration	MFF-1 — registration confirmation; non-public-section carve-outs for Annex III(1)/(6)/(7) noted
Article 50(1)–(4) transparency duties	MFF-1 — design evidence, marking implementation, deployer-side disclosure artifacts
Article 51 GPAI systemic-risk classification	MFF-1 (ProductProperty:SR tag) — FLOPs evidence + Article 52(2) rebuttal rationale where applied
Article 53(1)(a)–(d) GPAI obligations	MFF-1 (Product:GPAIM tag) — Annex XI technical doc, Annex XII downstream-provider doc, copyright policy, training-data summary
Article 53(2) free-and-open-source exemption	MFF-1 — questionnaire indicates FOSS status; non-FOSS GPAI is tagged SupplyTerms:GPAIMNonFOSS. Copyright + training-data summary still required
Article 54 authorized representative for non-EU GPAI	MFF-1 (MRF-128 / MRF-130 / MRF-131 cover the Article 54 app-side duties) + OFF-1 ORF-224 for the organization-side 10-year documentation hold — separate mandate from Article 22
Article 55 systemic-risk GPAI additional obligations	MFF-1 (ProductProperty:SR tag) — evaluations, adversarial-testing records, systemic-risk assessment, AI Office incident reports, cybersecurity
Article 56 Codes of Practice adherence	MFF-1 — Code adherence evidence
Article 72 post-market monitoring plan	MFF-1 (MRF-46) — PMM plan evidence (Annex IV point 9 → Article 72(3) Commission template) + Runtime Inspection signals
Article 73 serious-incident report (provider side)	OFF-1 (ORF-47) — report artifact + market-surveillance-authority submission confirmation. Deployer-side observation lives on MFF-1 MRF-49 (Article 26 deployer monitoring and incident handling)
Article 79(1) system risk	MFF-1 — risk-evaluation evidence + Article 26(5) deployer-notification trail
Article 99 / 101 enforcement readiness	Indirectly — through readiness signals across all in-scope requirements

What is first-class UI vs evidence-attached

EU AI Act settings surface

The EU AI Act settings tab on each project exposes multi-select settings including: Product, Role, Use Case, Origin, Model Property, Project Requirements, Critical Issues, and Supply Terms. Role and Use Case are the two most consequential for scoping the active requirement set.

• Role — multi-select per project from Provider / Deployer / Importer / Distributor / Authorized representative. A single project can carry multiple roles where the same legal entity wears more than one hat. A Default internal fallback exists in service logic when no role is set; it is not in the settings UI. The scoping questionnaire reads the role to scope in the relevant MFF-1 / OFF-1 requirements.
• Use Case — multi-select: High Risk / Limited Risk / Transparency. A deployment-context filter that scopes the active requirements set, not a legal classification. The Article 6 + Annex III / Annex I rationale on the MFF-1 classification requirement is the legal answer. (OFF-1 template tagging metadata uses the four industry labels — Unacceptable / High / Limited / Minimal Risk — for portfolio reporting; this is template metadata, not the active UI.)

These settings can be populated either via the scoping questionnaire (Project → Requirements → EU AI Act Questionnaire) or by editing the dropdowns directly on the settings tab — manual edits go through a Preview Changes → Apply step that lists every requirement and control moving in or out of scope before the change commits. Both paths use the same descoping algorithm; rationale for a chosen Use Case is captured on the MCF-150 control ("Explain and document your reasoning for your chosen EU AI Act Risk Classification") and can be exported as an evidence PDF.

Everything else is evidence-attached. Evidence in Modulos is attached to controls (and control components); controls in turn link to one or more requirements; the readiness signal on the requirement aggregates the linked control-level evidence. Specifically:

• Article 27 FRIA — no dedicated FRIA workflow surface. The FRIA document and update history are evidence on the controls that link to the FRIA MFF-1 requirement.
• Article 72 post-market monitoring plan — no dedicated PMM workflow. The plan is evidence on the controls linked to the PMM requirement; ongoing signals come from Runtime Inspection.
• Article 73 serious-incident report — no dedicated incident workflow. The report and the market-surveillance-authority submission confirmation are evidence on the controls linked to the ORF-47 serious-incident requirement (provider side) / MRF-49 (deployer side).
• Article 47 EU declaration of conformity, Article 48 CE marking attestation, Article 49 registration confirmation — no dedicated CE workflow. Artifacts are evidence on the controls linked to the relevant MFF-1 requirements.
• Article 56 Codes of Practice adherence — no dedicated Codes workflow. Adherence evidence is attached to the controls linked to the relevant GPAI requirements.
• Article 43 conformity-assessment route selection — no dedicated route picker. The rationale, the standards / common-specifications application status, and the notified-body certificate (where Annex VII applies) are evidence on the controls linked to the route requirement.
• Article 25 substantial-modification rationale — no dedicated rationale workflow. The audit record (why deployment-time changes are or are not substantial modification) is evidence on the controls linked to the Article 25 requirement.

Evidence-attached obligations let each provider author the artifact in the form their authorities and notified bodies expect, rather than committing to one prescribed compliance process inside Modulos.

How requirements work in Modulos for the EU AI Act

Modulos has two distinct response mechanisms:

• Reviews are reserved for control status changes. They record an explicit approval / rejection of a control moving between statuses.
• Requirements carry a readiness signal ("are we ready to be assessed against this requirement?") and accumulate owner-attested fulfillment evidence. Requirements do not have reviews; the readiness signal plus the evidence trail is the auditable answer.

For the EU AI Act, the substantive Articles 8–15 / 26 / 27 / 50 / 51–56 / 72 / 73 obligations sit on requirements (readiness + fulfillment). Controls in Modulos sit one layer down — they are the operational execution units that produce evidence which then links up to one or more requirements; control status changes are the surface where reviews apply.

Commission guidance and the Modulos requirements

The Commission has issued interpretive guidance on three areas of the EU AI Act that map directly onto the OFF-1 / MFF-1 framework template:

Commission guidance	Article	Modulos requirement	Code
AI-system definition — final, C(2025) 5053, 29 July 2025	Article 3(1)	AI System Classification	MRF-38
Prohibited AI practices — final, C(2025) 5052, 29 July 2025	Article 5	Art. 5 — Prohibited AI practices	MRF-119
High-risk classification — DRAFT, May 2026 (consultation closed 23 June 2026)	Article 6(1) / 6(2)	AI System Classification	MRF-38
High-risk classification filter mechanism — DRAFT	Article 6(3)	Art. 6 — AI system classification exemption	MRF-111

The guidance documents are Commission interpretive soft law, not binding. The OJ-published Regulation (EU) 2024/1689 text and any CJEU interpretation prevail. The high-risk guidance is currently a draft; its text may change before formal adoption.

Page-by-page treatment of each Commission document is on the commission-guidance hub and its four spokes: definition, prohibited practices, high-risk classification framework, high-risk worked examples.

Article-numbering note (platform vs final OJ text)

Many Modulos requirement names now carry the final OJ-published Article number in Regulation (EU) 2024/1689 directly in the name. Several Articles were renumbered between the earlier drafts and the final text, and the platform reflects the final numbers — for example ORF-47 Art. 73 — Reporting of serious incidents and MRF-46 Art. 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems. Not every requirement name carries its Article number — some keep descriptive names, such as the Article 50 transparency requirements (MRF-44, MRF-45, MRF-58–MRF-61) — so the OJ Article column in the inventory below is authoritative.

Older screenshots or exports produced before the article-anchored rename may still show pre-renumbering numbers (for example Art 61 for post-market monitoring, Art 62 for serious-incident reporting, or Art 52 for transparency). Treat the current OJ-published numbers as authoritative. Similarly, names no longer carry the " (app)" / " (org)" suffix; scope is shown by the project type.

Full OFF-1 + MFF-1 requirement inventory

OFF-1 (EU AI Act, organization-level), 19 mapped requirements

Requirement	Description	OJ Article
ORF-1	Art. 9 — Risk management system	Article 9
ORF-5	Art. 13 — Transparency and provision of information to deployers	Article 13
ORF-6	Art. 14 — Human oversight	Article 14
ORF-8	Art. 17 — Quality management system	Article 17
ORF-9	Art. 43 — Conformity assessment	Article 43
ORF-11	Corrective Actions	Article 16 / 20
ORF-12	Duty of Information	Article 20
ORF-13	Cooperation with Competent Authorities	Article 21
ORF-14	Use and Oversight	Article 26
ORF-36	Art. 4 — AI literacy	Article 4
ORF-447	Art. 4a — Special-category data processing for bias detection and correction	Article 4a
ORF-47	Art. 73 — Reporting of serious incidents	Article 73
ORF-49	Deployment Monitoring and Incident Handling	Article 26
ORF-57	Deployer Cooperation with Competent Authorities	Article 26
ORF-62	Documentation Keeping	Articles 18 / 22 / 23
ORF-95	GPAIM IPR Compliance Policy	Article 53(1)(c)
ORF-96	GPAIM Cooperation with Competent Authorities	Article 53
ORF-97	Art. 55 — GPAIM-SR serious incident reporting	Article 55(1)(c)
ORF-224	Art. 54 — GPAIM documentation keeping	Article 54

MFF-1 (EU AI Act, application-level), 57 mapped requirements

Articles 8–15 high-risk obligations + Article 26 deployer duties (plus the Article 4a bias-detection data basis):

Requirement	Description	OJ Article
MRF-1	Art. 9 — Risk management system	Article 9
MRF-2	Art. 10 — Data and data governance	Article 10
MRF-413	Art. 4a — Special-category data processing for bias detection and correction	Article 4a
MRF-3	Technical Documentation	Article 11 + Annex IV
MRF-4	Art. 12 — Record-keeping	Article 12
MRF-5	Art. 13 — Transparency and provision of information to deployers	Article 13
MRF-6	Art. 14 — Human oversight	Article 14
MRF-7	Accuracy	Article 15
MRF-9	Art. 43 — Conformity assessment	Article 43
MRF-10	Keeping Logs by Provider	Article 12 / 19
MRF-14	Use and Oversight	Article 26
MRF-15	Art. 27 — Fundamental rights impact assessment for high-risk AI systems	Article 27
MRF-37	EU Representative	Article 22
MRF-38	AI System Classification	Article 6
MRF-39	Art. 16 — Accessibility	Article 16(l)
MRF-40	System Testing	Article 9 / 15
MRF-41	Disclosure of Contact Information	Article 16(b)
MRF-42	Art. 8 — Choice for handling sectoral requirements	Article 8 / 43(3) (Annex I Section A integration only)
MRF-43	Art. 25 — High-risk AI system integration support	Article 25
MRF-48	Relevant and Representative Data in Use	Article 26(4)
MRF-49	Deployment Monitoring and Incident Handling	Article 26(5)
MRF-50	Keeping Logs by Deployer	Article 26(6)
MRF-51	Using Provider-Supplied Information for DPIA	Article 26(9)
MRF-52	Transparent Deployment at Workplace	Article 26(7)
MRF-53	Public Deployer Registration	Article 49(3)
MRF-54	Post-Remote Biometric ID Authorization and Reporting	Article 26(10)
MRF-55	Transparent Automated Decision-Making	Article 26(11)
MRF-56	Art. 86 — Right to explanation of individual decision-making	Article 86
MRF-64	Robustness	Article 15
MRF-65	Cybersecurity	Article 15(5)
MRF-46	Art. 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems	Article 72

Article 50 transparency duties:

Requirement	Description	OJ Article
MRF-44	Transparent Interaction with Natural Persons	Article 50(1)
MRF-45	Computer-Generated Works Marking	Article 50(2)
MRF-58	Transparency of Biometric Categorization	Article 50(3)
MRF-59	Transparency of Emotion Recognition	Article 50(3)
MRF-60	Transparency of Deepfakes	Article 50(4)
MRF-61	Transparency of Computer-Generated Reporting	Article 50(4) text limb

Importer / distributor / EU representative duties:

Requirement	Description	OJ Article
MRF-112	Duty to Verify Evidence of Conformity	Article 23
MRF-113	Duty to Ensure Appropriate Storage or Transport Conditions	Article 23 / 24
MRF-114	EU Representative Mandate	Article 22
MRF-115	EU Representative Duty to Verify Evidence of Conformity	Article 22(3)
MRF-116	EU Representative Registration	Article 22(3) / 49
MRF-117	Modification Assistance	Article 25(2)
MRF-118	Integration Assistance	Article 25(4)

Chapter V GPAI (MRF-120–MRF-131), plus adjacent Article 6(3) and Article 5 gates (MRF-111 and MRF-119):

Requirement	Description	OJ Article
MRF-111	Art. 6 — AI system classification exemption	Article 6(3)
MRF-119	Art. 5 — Prohibited AI practices	Article 5
MRF-120	GPAIM Classification	Article 51
MRF-121	Art. 52 — GPAIM classification exemption	Article 52
MRF-122	GPAIM Training Data Summary	Article 53(1)(d)
MRF-123	GPAIM Legal Compliance Strategy	Article 53(1)(c)
MRF-124	GPAIM Documentation and Downstream Integration	Article 53(1)(a)(b)
MRF-125	GPAIM-SR Evaluation	Article 55(1)(a)
MRF-126	GPAIM-SR Risk Assessment and Mitigation	Article 55(1)(b)
MRF-127	GPAIM-SR Security	Article 55(1)(d)
MRF-128	GPAIM EU Representative	Article 54
MRF-130	GPAIM EU Representative Mandate	Article 54(3)
MRF-131	GPAIM EU Representative Duty to Verify Evidence of Compliance	Article 54(3)

Recommended rollout order

1. OFF-1 setup — QMS scope (Article 17), authorized-representative mandate where applicable (Article 22), registration governance (Article 49), organization-wide serious-incident reporting procedure (recorded as evidence on the ORF requirement).
2. Per-system MFF-1 setup — role tagging, risk classification, scoping questionnaire.
3. High-risk readiness — Articles 8–15 evidence cycle. Establish the Article 9 risk-management system first because Articles 10–15 hook into it via Article 8(2).
4. Article 43 conformity-assessment route — rationale + standards / common-specifications application before the system goes to market.
5. Article 47 + Article 48 + Article 49 — declaration, CE marking, EU-database registration as the final gate before placement.
6. Article 72 PMM plan — established before market placement (it is part of the Annex IV technical documentation).
7. Article 73 incident-reporting readiness — the reporting procedure (runbook, deployer-side observation flow, market-surveillance-authority contact path) recorded as evidence and exercised before live operation; the deployer side is critical because deployers are usually the first observers.
8. Article 27 FRIA — completed before first use by in-scope deployers.
9. Chapter V where applicable — GPAI scoping tags applied; Annex XI / XII / training-data summary / copyright policy in place before the model is placed on the market; Article 55 stack added if systemic-risk.

Common pitfalls

• Treating the risk-classification setting as the legal answer to high-risk classification. It is a portfolio filter, not a legal taxonomy. The legal answer is the Article 6 + Annex III / Annex I scoping rationale recorded on MFF-1.
• Assuming GPAI is a separate template. It is folded into MFF-1; the platform applies Product:GPAIM, ProductProperty:SR (for systemic-risk) and SupplyTerms:GPAIMNonFOSS (for non-FOSS) tags via the scoping questionnaire.
• Treating Article 73 EU AI Act and Article 33 GDPR as one duty. They are separate; both can apply to the same incident and must be reported independently.
• Skipping the Article 25 substantial-modification rationale. Deployment-time fine-tuning, prompt changes, or context changes can convert a deployer into a provider under Article 25(1)(b); keep the audit record current.
• Treating adopted Omnibus dates as already binding. The Digital Omnibus on AI was adopted by Parliament on 16 June 2026 and by the Council on 29 June 2026, but is not yet in force. On entry into force (the third day after Official Journal publication), it will move the Annex III high-risk application date from 2 August 2026 to 2 December 2027 and the Annex I high-risk application date from 2 August 2027 to 2 August 2028.
• Building the Annex IV technical file as a Modulos document. Modulos is the evidence library; the Annex IV document itself is the provider's authoring task.

Related pages

EU AI Act overview

Four obligation regimes, classification flow, common misreadings

High-risk AI systems

Article 6 routing; Articles 8–15 substantive obligations

Conformity assessment and CE marking

Article 43 routes; declaration; CE marking; EU database registration

General-purpose AI models

Chapter V — Articles 51–56; Product:GPAIM / ProductProperty:SR / SupplyTerms:GPAIMNonFOSS scoping

Post-market monitoring

Article 72 PMM plan; Article 73 serious-incident reporting

Roles and responsibilities

Article 3 role tagging; Article 25 accidental provider; Article 26 deployer duties

See it in Modulos

Modulos turns the EU AI Act into a running compliance program: scope by role, run readiness + fulfillment on requirements, keep evidence linked to the Article it satisfies.

Request a demo

Disclaimer

This page is for general informational purposes and does not constitute legal advice.