Appearance
Operationalizing in Modulos
The EU AI Act becomes operational in Modulos through two framework templates that align to the two organising levels of the Regulation: organisation-wide obligations (Article 17 QMS, Article 22 authorised-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; some internal labels still reference pre-renumbering Article numbers (see the Article-numbering note below).
Quick decision
- You are starting a fresh Modulos rollout for the EU AI Act → one organisation 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 organisation project with other framework templates → add OFF-1 to it. The organisation-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:GPAIMand (where systemic-risk)ProductProperty:SRtags, withSupplyTerms:GPAIMNonFOSSfor 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 — org) — 18 mapped requirements across the ORF-1…ORF-224 range. Article 17 QMS, Article 22 authorised-representative mandate, Article 49 registration governance, organisation-level conformity-assessment policy, and the provider-side Article 73 serious-incident reporting requirement (ORF-47) (recorded as evidence — no dedicated incident workflow surface).
- MFF-1 (EU AI Act — app) — 56 mapped requirements across the MRF-1…MRF-131 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-111…MRF-131 (including MRF-128 / MRF-130 / MRF-131 covering Article 54 GPAI authorised-representative duties on the app side).
- EU AI Act settings surface (multi-select) — project-level Role (Provider / Deployer / Importer / Distributor / Authorised 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 fulfilment and do not have reviews.
Recommended project structure
| Project | Template | When to use |
|---|---|---|
| One organisation project | OFF-1 (add to existing org project if you already have one with other framework templates) | Article 17 QMS, Article 22 authorised 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: organisation-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
- Add OFF-1 to your organisation project. Confirm Article 17 QMS scope, Article 22 mandate, Article 49 registration governance, and the organisation's serious-incident-reporting procedure (recorded as evidence on controls linked to ORF-47 — there is no dedicated incident workflow surface).
- Create one AI-application project per AI system. Add MFF-1.
- Set the EU AI Act Role on each application project — Provider / Deployer / Importer / Distributor / Authorised representative. A single project can carry multiple roles where the same legal entity wears more than one hat. (The platform also maintains an internal
Defaultfallback when no role is set — this is not exposed in the settings UI.) - 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).
- Complete the MFF-1 scoping questionnaire. Answers drive which requirements scope in: Annex I vs Annex III, Article 6(3) derogation, GPAI integration, Article 50 deployment characteristics (chatbot, synthetic content, emotion recognition, deepfake), Article 27 FRIA applicability.
- Set readiness on each scoped requirement and assign owner-attested fulfilment as evidence accumulates. The readiness signal answers "are we ready to be assessed?"; the fulfilment evidence is the auditable trail behind the answer.
Where things live in Modulos
| Article / topic | Modulos location |
|---|---|
| Article 5 prohibited-practice screening | OFF-1 (organisational 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 10 data and data governance | MFF-1 — training / validation / test data documentation + Article 10(5) bias-correction rationale |
| Article 11 + Annex IV technical documentation | MFF-1 — Annex IV evidence library; provider authors the technical-file artefact |
| 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 artefact |
| 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 organisation-level QMS, documentation, registration duties |
| Article 17 QMS | OFF-1 — QMS document set linked as evidence |
| Article 22 authorised 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 artefact |
| Article 43 conformity-assessment route selection | MFF-1 — route rationale (Annex VI vs Annex VII vs sectoral) + 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 artefacts |
| 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 authorised 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 organisation-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 artefact + 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 / Authorised representative. A single project can carry multiple roles where the same legal entity wears more than one hat. A
Defaultinternal 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.)
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. Artefacts 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 artefact 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 fulfilment 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 + fulfilment). 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 (app) | MRF-38 |
| Prohibited AI practices — final, C(2025) 5052, 29 July 2025 | Article 5 | Prohibited AI Practices (app) | MRF-119 |
| High-risk classification — DRAFT, May 2026 (consultation closes 23 June 2026) | Article 6(1) / 6(2) | AI System Classification (app) | MRF-38 |
| High-risk classification filter mechanism — DRAFT | Article 6(3) | AI System Classification Exemption (app) | 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)
Some legacy labels inside the Modulos platform reference the EU AI Act by pre-renumbering Article numbers. The final OJ-published text renumbers several Articles. Modulos documentation always uses the final OJ-published numbers:
| Platform legacy label | Final OJ-published Article |
|---|---|
ORF-47 "Art 62 Serious Incident Reporting" | Article 73 |
MRF-46 "Art 61" Post-Market Monitoring System | Article 72 |
MRF-44 / MRF-45 / MRF-58–MRF-61 "Art 52" transparency | Article 50 |
If you see a platform field referencing the pre-renumbering label, treat the docs Article number as the authoritative legal reference.
Full OFF-1 + MFF-1 requirement inventory
OFF-1 (EU AI Act — org), 18 mapped requirements
| Requirement | Description | OJ Article |
|---|---|---|
ORF-1 | Risk Management System (org) | Article 9 |
ORF-5 | Transparency and Provision of Information to Deployers (org) | Article 13 |
ORF-6 | Human Oversight (org) | Article 14 |
ORF-8 | Quality Management System (org) | Article 17 |
ORF-9 | Conformity Assessment (org) | Article 43 |
ORF-11 | Corrective Actions (org) | Article 16 / 20 |
ORF-12 | Duty of Information (org) | Article 20 |
ORF-13 | Cooperation with Competent Authorities (org) | Article 21 |
ORF-14 | Use and Oversight (org) | Article 26 |
ORF-36 | AI Literacy (org) | Article 4 |
ORF-47 | Serious Incident Reporting for Developers (org) | Article 73 (platform legacy: Art 62) |
ORF-49 | Deployment Monitoring and Incident Handling (org) | Article 26 |
ORF-57 | Deployer Cooperation with Competent Authorities (org) | Article 26 |
ORF-62 | Documentation Keeping (org) | Articles 18 / 22 / 23 |
ORF-95 | GPAIM IPR Compliance Policy (org) | Article 53(1)(c) |
ORF-96 | GPAIM Cooperation with Competent Authorities (org) | Article 53 |
ORF-97 | GPAIM-SR Serious Incident Reporting (org) | Article 55(1)(c) |
ORF-224 | GPAIM Documentation Keeping (org) | Article 54 |
MFF-1 (EU AI Act — app), 56 mapped requirements
Articles 8–15 high-risk obligations + Article 26 deployer duties:
| Requirement | Description | OJ Article |
|---|---|---|
MRF-1 | Risk Management System (app) | Article 9 |
MRF-2 | Data and Data Governance (app) | Article 10 |
MRF-3 | Technical Documentation (app) | Article 11 + Annex IV |
MRF-4 | Implementing Record-Keeping Capability (app) | Article 12 |
MRF-5 | Transparency and Provision of Information to Deployers (app) | Article 13 |
MRF-6 | Human Oversight (app) | Article 14 |
MRF-7 | Accuracy (app) | Article 15 |
MRF-9 | Conformity Assessment (app) | Article 43 |
MRF-10 | Keeping Logs by Provider (app) | Article 12 / 19 |
MRF-14 | Use and Oversight (app) | Article 26 |
MRF-15 | Fundamental Rights Impact Assessment (app) | Article 27 |
MRF-37 | EU Representative | Article 22 |
MRF-38 | AI System Classification (app) | Article 6 |
MRF-39 | Accessibility (app) | Article 16(l) |
MRF-40 | System Testing (app) | Article 9 / 15 |
MRF-41 | Disclosure of Contact Information (app) | Article 16(b) |
MRF-42 | Choice for Handling Sectoral Requirements (app) | Article 8 / 43(3) |
MRF-43 | High-Risk AI System Integration Support (app) | Article 25 |
MRF-48 | Relevant and Representative Data in Use (app) | Article 26(4) |
MRF-49 | Deployment Monitoring and Incident Handling (app) | Article 26(5) |
MRF-50 | Keeping Logs by Deployer (app) | Article 26(6) |
MRF-51 | Using Provider-Supplied Information for DPIA (app) | Article 26(9) |
MRF-52 | Transparent Deployment at Workplace (app) | Article 26(7) |
MRF-53 | Public Deployer Registration | Article 49(3) |
MRF-54 | Post-Remote Biometric ID Authorisation and Reporting (app) | Article 26(10) |
MRF-55 | Transparent Automated Decision-Making (app) | Article 26(11) |
MRF-56 | Explanation of Automated Decisions (app) | Article 86 |
MRF-64 | Robustness (app) | Article 15 |
MRF-65 | Cybersecurity (app) | Article 15(5) |
MRF-46 | Post-Market Monitoring System (app) | Article 72 (platform legacy: Art 61) |
Article 50 transparency duties:
| Requirement | Description | OJ Article |
|---|---|---|
MRF-44 | Transparent Interaction with Natural Persons (app) | Article 50(1) |
MRF-45 | Computer-Generated Works Marking (app) | Article 50(2) |
MRF-58 | Transparency of Biometric Categorisation (app) | Article 50(3) |
MRF-59 | Transparency of Emotion Recognition (app) | Article 50(3) |
MRF-60 | Transparency of Deepfakes (app) | Article 50(4) |
MRF-61 | Transparency of Computer-Generated Reporting (app) | Article 50(4) text limb |
Importer / distributor / EU representative duties:
| Requirement | Description | OJ Article |
|---|---|---|
MRF-112 | Duty to Verify Evidence of Conformity (app) | Article 23 |
MRF-113 | Duty to Ensure Appropriate Storage or Transport Conditions (app) | Article 23 / 24 |
MRF-114 | EU Representative Mandate (app) | Article 22 |
MRF-115 | EU Representative Duty to Verify Evidence of Conformity (app) | Article 22(3) |
MRF-116 | EU Representative Registration (app) | Article 22(3) / 49 |
MRF-117 | Modification Assistance (app) | Article 25(2) |
MRF-118 | Integration Assistance (app) | Article 25(4) |
Chapter V GPAI (MRF-111, MRF-119–MRF-131):
| Requirement | Description | OJ Article |
|---|---|---|
MRF-111 | AI System Classification Exemption (app) | Article 6(3) |
MRF-119 | Prohibited AI Practices (app) | Article 5 |
MRF-120 | GPAIM Classification (app) | Article 51 |
MRF-121 | GPAIM Classification Exemption (app) | Article 52 |
MRF-122 | GPAIM Training Data Summary (app) | Article 53(1)(d) |
MRF-123 | GPAIM Legal Compliance Strategy (app) | Article 53(1)(c) |
MRF-124 | GPAIM Documentation and Downstream Integration (app) | Article 53(1)(a)(b) |
MRF-125 | GPAIM-SR Evaluation (app) | Article 55(1)(a) |
MRF-126 | GPAIM-SR Risk Assessment and Mitigation (app) | Article 55(1)(b) |
MRF-127 | GPAIM-SR Security (app) | Article 55(1)(d) |
MRF-128 | GPAIM EU Representative (app) | Article 54 |
MRF-130 | GPAIM EU Representative Mandate (app) | Article 54(3) |
MRF-131 | GPAIM EU Representative Duty to Verify Evidence of Compliance (app) | Article 54(3) |
Recommended rollout order
- OFF-1 setup — QMS scope (Article 17), authorised-representative mandate where applicable (Article 22), registration governance (Article 49), organisation-wide serious-incident reporting procedure (recorded as evidence on the ORF requirement).
- Per-system MFF-1 setup — role tagging, risk classification, scoping questionnaire.
- 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).
- Article 43 conformity-assessment route — rationale + standards / common-specifications application before the system goes to market.
- Article 47 + Article 48 + Article 49 — declaration, CE marking, EU-database registration as the final gate before placement.
- Article 72 PMM plan — established before market placement (it is part of the Annex IV technical documentation).
- 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.
- Article 27 FRIA — completed before first use by in-scope deployers.
- 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) andSupplyTerms: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.
- Quoting Omnibus dates as binding. The 7 May 2026 provisional agreement is not law. Use "if adopted" framing; the published 2024/1689 dates remain the legally binding reference.
- 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
Disclaimer
This page is for general informational purposes and does not constitute legal advice.