Roles and responsibilities

The EU AI Act assigns obligations based on your legal role in the AI value chain. These roles answer "who is accountable for what" under the Act.

Modulos also has internal roles (Owner, Editor, Reviewer, Auditor) that answer "who can do what in the platform." These are different concepts and should not be conflated.

Legal roles and obligations

Role	Definition	Key obligations (high‑risk)	Article
Provider	Develops or places an AI system on the market under own name/trademark	Ensure compliance with requirements (Art. 8–15); maintain technical documentation; implement QMS; undergo conformity assessment; affix CE marking; register in EU database; keep logs; take corrective actions; cooperate with authorities	Art. 16
Deployer	Uses an AI system under own authority (not personal use)	Use system per instructions; assign human oversight to competent persons; ensure input data quality; monitor operation; keep logs ≥6 months; report serious incidents; conduct FRIA (if public sector)	Art. 26
Importer	Places a third‑country provider's system on EU market	Verify conformity assessment completed; verify CE marking + declaration of conformity; ensure authorized representative appointed; indicate own contact details on product; keep documentation 10 years	Art. 23
Distributor	Makes system available on market (not provider/importer)	Verify CE marking + declaration before making available; ensure storage/transport doesn't affect compliance; withdraw/recall non‑conforming systems; cooperate with authorities	Art. 24
Authorized representative	Appointed by third‑country provider to act in EU	Verify and keep compliance documentation; keep technical documentation + logs 10 years; cooperate with authorities; handle registration; terminate mandate if provider non‑compliant	Art. 22

Role transformation (Art. 25)

Any distributor, importer, deployer, or other third party shall be considered a provider if they: (a) put their name or trademark on a high‑risk AI system already on the market; (b) make a substantial modification; or (c) modify the intended purpose so the system becomes high‑risk.

Provider vs deployer: the key distinction

Most teams need to understand the provider/deployer split:

Aspect	Provider	Deployer
Core accountability	System meets requirements before market placement	System used correctly after deployment
Conformity assessment	Must complete before placing on market	Not required (relies on provider's assessment)
Technical documentation	Must create and maintain	Must have access to instructions for use
Human oversight	Must design oversight capabilities into system	Must implement oversight in operations
Incident reporting	Must report serious incidents to authorities	Must report serious incidents to provider and authorities
Record retention	10 years	6 months minimum for logs

How to think about accountability

A useful framing:

• Legal role defines which obligations you must meet under the AI Act
• Internal org model defines which teams own the work (Product, Engineering, Risk, Compliance, Legal)
• Platform workflow defines how you execute and audit the work

Many organizations act as both provider and deployer — building AI systems for internal use. In this case, you must meet obligations for both roles.

Mapping to Modulos workflows

In Modulos, teams implement legal responsibilities through project workflows:

Legal obligation	Modulos location
Track requirements and fulfillment	Project → Requirements
Execute and review controls	Project → Controls
Manage evidence artifacts	Project → Evidence
Store scope and classification	Project → Settings
Assign accountability	Project → Settings → User Access
Generate audit packages	Project → Exports

EU AI Act controls by role

When you add the EU AI Act framework to a project, Modulos creates controls mapped to your legal role. Here's how they align:

Provider controls

Obligation	Example controls in Modulos
Risk management (Art. 9)	Risk identification and analysis; Risk mitigation measures; Residual risk documentation
Data governance (Art. 10)	Training data documentation; Bias examination; Data quality assessment
Technical documentation (Art. 11)	System description; Design specifications; Development methodology
Human oversight (Art. 14)	Oversight capability design; Operator interface specification; Intervention mechanisms
Accuracy and robustness (Art. 15)	Performance testing; Robustness validation; Cybersecurity measures
Conformity assessment	Internal control checklist; Declaration of conformity preparation
Post‑market monitoring (Art. 72)	Monitoring plan; Incident identification criteria; Corrective action procedures

Deployer controls

Obligation	Example controls in Modulos
Instructions compliance (Art. 26)	Deployment within intended purpose; Configuration per provider specs
Human oversight (Art. 26)	Oversight personnel assignment; Competency verification; Escalation procedures
Input data (Art. 26)	Input data quality checks; Data relevance verification
Monitoring (Art. 26)	Operational monitoring; Anomaly detection; Performance tracking
Record‑keeping (Art. 26)	Log retention (≥6 months); Access controls
Incident reporting (Art. 26)	Serious incident identification; Reporting to provider; Authority notification
FRIA (Art. 27)	Fundamental rights impact assessment (public sector deployers)

Finding your controls

In Modulos, go to Project → Controls and filter by the EU AI Act framework. Controls are tagged by article reference so you can see which obligation each control addresses.

Scoping with the EU AI Act Questionnaire

The EU AI Act Questionnaire in Project → Requirements helps you determine which requirements and controls apply based on your role, risk classification, and use case. Complete it early to scope your compliance work correctly.

123

The questionnaire tailors requirements and controls to your specific situation — provider vs deployer, high-risk vs minimal, and use case context.

1. 1
   Role selection

   Choose whether you act as provider, deployer, or both.
2. 2
   Classification questions

   Answer questions about your system to determine risk classification.
3. 3
   Scoped requirements

   Based on your answers, only relevant requirements and controls are activated.

Accidental provider status

It's easy to become a provider without intending to. If you fine‑tune a model, modify prompts significantly, change the deployment context, or rebrand a vendor's system — you may have made a substantial modification under Art. 25. This triggers full provider obligations including conformity assessment. When in doubt, document why your changes do not constitute substantial modification.

Separation of duties

Modulos project roles support separation of duties:

• Owners and Editors execute controls and attach evidence
• Reviewers approve controls without edit access
• Auditors view and export without modification rights

This maps to typical compliance workflows where those who implement controls should not be the same people who approve them.

For platform role assignment, see Project Settings and Organization user management.

Related pages

EU AI Act overview

Scope, classification, timeline, and how Modulos operationalizes compliance

High‑risk AI systems

What high‑risk means and what it usually requires

Conformity assessment

The two assessment routes and what each requires

Disclaimer

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