A Guide to the 43 EU AI Act Obligations and Where to Start

Why the “43 obligations” matter (and why you shouldn’t tackle them in order)

The EU AI Act obligations aren’t a linear checklist. They’re triggered by risk tier (unacceptable, high-risk, limited risk, minimal risk) and by your role in the AI value chain (provider, deployer, importer, distributor, product manufacturer). On top of that, obligations vary by deployment context: HR, credit, healthcare, law enforcement, critical infrastructure, education, public services, and consumer-facing products each create different exposure.

A practical approach is to treat the “43 obligations” as a library of controls and then prioritize what applies to:

1. Your AI system category (GPAI model vs. high-risk system vs. transparency-only system)
2. Your operational role (provider vs. deployer)
3. Your deployment environment (regulated domain, safety-critical use, scale, vulnerability of users)

This guide shows how to sort obligations by tier and context, then where to start in the first 30–90 days.

---

Step 1: Classify your system and your role (the fastest way to cut scope)

Before you build a compliance roadmap, do a rapid classification workshop and capture decisions in a one-page record.

A. Identify what you’re dealing with

• Is it a general-purpose AI (GPAI) model that can be used across many tasks?
• Is it a high-risk AI system (used in sensitive domains or safety components)?
• Is it a limited-risk AI system that triggers transparency duties (e.g., user-facing interaction, emotion recognition, biometric categorization in certain contexts)?
• Is it minimal risk (most internal tools, analytics, and productivity aids that don’t fall into specific categories)?

B. Identify your role(s)

Many organizations have multiple roles at once.

• Provider: develops an AI system or places it on the market under its name
• Deployer: uses an AI system under its authority (including internal use)
• Importer/distributor: brings a system into the EU supply chain
• Product manufacturer: integrates AI into a regulated product (e.g., machinery, medical devices)

Output of Step 1: a scoped list of obligations that plausibly apply, plus an owner for each (legal, product, engineering, security, procurement, HR/compliance).

---

Step 2: Prioritize by risk tier (what to do first)

Tier 0: Unacceptable-risk practices (stop, redesign, or ring-fence)

If your system falls into prohibited practices, prioritization is simple: halt deployment and redesign. Your first obligations are governance decisions:

• Run a prohibited-practices screening
• Document the decision and mitigation or discontinuation
• Ensure product and commercial teams can’t “ship around” the restriction

Where to start: add an AI use-case intake gate so prohibited use cases are caught before procurement or development.

---

Tier 1: High-risk systems (most obligations concentrate here)

High-risk systems require the broadest set of controls—this is where the “43 obligations” mostly come from in practice. Prioritize these controls first because they cascade into everything else.

High-risk starting set (the “core 12” to implement early):

1. Risk management system for the AI lifecycle (hazards, foreseeable misuse, residual risk)
2. Data governance (training/validation/test data quality, relevance, bias handling, lineage)
3. Technical documentation sufficient for assessment and traceability
4. Logging/record-keeping appropriate to risk and system function
5. Human oversight design (clear intervention points, escalation paths, training)
6. Accuracy, robustness, and cybersecurity targets and testing
7. Quality management system (QMS) or QMS-like controls
8. Clear instructions for use and limitations
9. Post-market monitoring plan and feedback loops
10. Incident reporting process and thresholds
11. Conformity assessment readiness (internal or third-party depending on category)
12. Accountability structure (responsible persons, approval gates, change control)

Where to start: build a single High-Risk AI Control Pack (templates + process) and require it for any system that might be classified as high-risk.

---

Tier 2: Limited risk (transparency obligations)

If your AI interacts with people or generates content that could mislead, transparency is the practical focus.

Typical obligations to prioritize:

• Inform users they are interacting with AI where required
• Label or disclose synthetic content when relevant (e.g., deepfakes or generated media)
• Provide basic usage information so users can make informed decisions
• Ensure complaint/feedback channels route to responsible teams

Where to start: implement standard UI/UX disclosure patterns and a content labeling policy that product teams can apply consistently.

---

Tier 3: Minimal risk (voluntary controls and good practice)

Minimal-risk systems may not trigger many legal duties, but you still benefit from baseline controls:

• Inventory and classification
• Security and access controls
• Vendor due diligence
• Basic model performance monitoring

Where to start: establish an AI inventory and a lightweight review for new tools, especially third-party AI features.

---

Step 3: Apply the obligations by deployment context (what changes in practice)

Even within the same tier, context alters what “good” looks like. Use these context cues to decide depth, evidence, and cadence.

HR, education, and worker management

Higher sensitivity due to impact on livelihoods and vulnerability.

• Tighten bias testing and representativeness checks
• Strengthen human oversight (no fully automated adverse decisions without meaningful review where applicable)
• Maintain audit-ready decision records (inputs, outputs, rationale, reviewer identity)
• Provide clear notices to affected persons when required in your process design

Healthcare and safety-critical environments

Focus shifts to safety engineering rigor.

• Define clinical/safety performance requirements
• Validate under realistic conditions and monitor drift
• Formalize incident escalation and rollback plans
• Emphasize cybersecurity and resilience

Credit, insurance, financial services

Scrutiny rises around explainability, governance, and adverse outcomes.

• Strong data lineage and feature governance
• Robust monitoring for disparate impact and performance drift
• Strict change control for model updates

Public sector and essential services

Higher expectations for transparency and accountability.

• Stronger documentation and stakeholder sign-off
• More rigorous post-deployment monitoring
• Clearly defined appeal and remediation routes

Actionable tip: create “context profiles” (HR profile, healthcare profile, finance profile) that automatically add extra evidence requirements on top of your baseline controls.

---

Step 4: Build a compliance operating system (not a pile of documents)

To make 43 obligations manageable, implement them as repeatable operations.

A. Create an AI system inventory and intake workflow

Your inventory should capture:

• System name, owner, vendor/provider
• Purpose and affected users
• Risk tier hypothesis (and final classification once confirmed)
• Where it runs (EU/non-EU), data types processed
• Change history and deployment dates

Intake workflow: no AI system goes live without passing classification and control checks.

B. Define accountability (RACI) and approval gates

At minimum, assign owners for:

• Legal/regulatory interpretation
• Product requirements and UX disclosures
• ML engineering and evaluation
• Security and privacy
• Procurement/vendor management
• Operations (monitoring, incident response)

Add gates at:

• Use-case approval
• Data readiness approval
• Pre-release review
• Material change approval (retraining, new data sources, new target population)

C. Standardize evidence: templates you’ll reuse constantly

Create templates for:

• System description and intended purpose
• Risk assessment and residual risk acceptance
• Data documentation and dataset sheets
• Model evaluation report (metrics, bias tests, robustness checks)
• Human oversight plan
• Monitoring and incident response plan
• User instructions and limitations
• Change log and release notes

Result: teams don’t “interpret the Act” repeatedly; they fill in structured artifacts.

---

Step 5: A 30–60–90 day starting plan

First 30 days: get control of scope

• Stand up an AI inventory and intake questionnaire
• Run a risk-tier triage on existing AI systems
• Identify high-risk candidates and freeze uncontrolled deployments if needed
• Assign accountable owners and create a single compliance workspace for evidence

Days 31–60: implement the baseline control pack

• Deploy the High-Risk AI Control Pack (even if classification is still being confirmed)
• Establish monitoring, logging, and incident pathways
• Draft standard transparency disclosures for limited-risk systems
• Update procurement to require vendor cooperation on documentation and testing evidence

Days 61–90: make it operational and auditable

• Run an internal “mock audit” on one priority system
• Test incident reporting with a tabletop exercise
• Validate change control: can you detect and approve “material changes” before release?
• Roll out training for product, ML, and compliance teams on the new workflow

---

Where most organizations should start (if you can only do five things)

1. Inventory everything: you can’t comply with what you can’t see.
2. Classify by tier + role: determine which obligations apply before writing policies.
3. Implement high-risk core controls (risk management, data governance, documentation, human oversight, monitoring).
4. Operationalize transparency: standard disclosures and synthetic content handling.
5. Add change control and post-market monitoring: compliance is continuous, not a launch task.

---

Common pitfalls (and how to avoid them)

• Treating obligations as a legal-only project: build joint ownership with product and engineering; most controls are technical and operational.
• Over-documenting low-risk tools: right-size evidence to tier; keep minimal-risk lightweight.
• Ignoring the supply chain: vendor AI features still create obligations; bake requirements into procurement and contracts.
• No plan for updates: model refreshes, new data, and feature expansion can change risk classification; implement material-change reviews.

---

Final checklist: your “first page” view of the 43 obligations

To keep momentum, maintain a single master matrix that maps obligations to:

• Risk tier triggers
• Role (provider/deployer/etc.)
• Deployment context overlays
• Required artifacts (templates)
• Control owner
• Evidence location
• Review cadence

When you can answer “What tier are we in, what role are we playing, and where is the evidence?” the 43 obligations become manageable—because they turn into a workflow your teams can actually run.