EU AI Act Readiness

Use this when you ship, or plan to ship, an AI system into the EU and need to know which obligations actually apply and how far you are from meeting them. Covers risk-tier classification, your role (provider or deployer), general-purpose AI model duties where relevant, the full obligation set for high-risk systems, transparency duties, and a prioritized gap-to-remediation roadmap. This produces a readiness assessment to drive internal work and conversations with counsel. It is not legal advice.

Related skills: Stand up the broader program with /ai-governance-framework. Track the gaps it surfaces as risks in /ai-risk-register. Wire the obligations into product process with /ai-product-governance.

The hard part most teams miss

The Act is not a single checklist. It is a decision tree, and you have to get the top of the tree right before any branch below it means anything.

1. Classification is the whole game, and teams misclassify. Every obligation hangs off the risk tier (prohibited, high-risk, limited/transparency, minimal) and your role. Call a high-risk system "limited" and you will skip a conformity assessment you were legally required to run. Call a minimal system "high-risk" and you will burn months building governance the Act never asked for. Get the tier wrong and everything downstream is wrong, so spend your effort here.
2. Provider and deployer obligations differ, and many orgs are unknowingly both. A provider develops or places a system on the market under its own name; a deployer uses one under its authority. The duties are not the same. The trap: take a third-party model, fine-tune it, rebrand it, or change its intended purpose, and you may have become a provider with provider obligations you never planned for. Pin down the role per system before you scope the work.
3. The deliverable regulators inspect is documentation. Technical documentation, the risk management system, logging and traceability records, human-oversight design, post-market monitoring: these are evidenced by artifacts, not intentions. If it is not written down, it does not exist in an audit. Readiness is measured by what you can produce on request, not by what the team believes it does.

Process

Step 1: Gather inputs

Ask the user:

1. What is the AI system, and what is its intended purpose? ({{system_name}} plus one or two sentences on what it does and the decisions it informs or makes. Intended purpose drives classification.)
2. Where and to whom is it offered? (Is it placed on the market or put into service in the EU, or do its outputs reach people in the EU? This is what brings it in scope.)
3. What is your role for this system? ({{provider_or_deployer}} -- do you develop or rebrand it, or do you use someone else's? Note if both.)
4. Does it build on a general-purpose AI model? (Foundation/GPAI model used, whether you train or substantially modify it, and roughly its scale.)
5. What domain does it touch? (Hiring, credit, education, biometrics, critical infrastructure, law enforcement, essential services -- these are where high-risk tends to live.)
6. Does the system interact with people or generate content? (Chat, decisions about a person, or synthetic text/image/audio/video -- this triggers transparency duties regardless of tier.)
7. What governance exists today? (Any risk process, documentation, logging, human-oversight design, or testing already in place.)

Step 2: Confirm scope and role

Settle two questions before classifying:

• Is the system in scope at all? It is generally in scope when it is placed on the EU market, put into service in the EU, or its outputs are used in the EU. If clearly out of scope, say so and stop.
• What is the role, per system? Provider versus deployer, decided by the facts of who develops, rebrands, or materially changes it. Flag explicitly where the org is both. If you have substantially modified a third-party system or changed its intended purpose, treat provider obligations as in play.

Step 3: Classify the risk tier

Walk the tiers top down and stop at the first that fits:

• Prohibited. Practices the Act bans outright (for example certain manipulative, social-scoring, or untargeted-scraping uses). If it lands here, the system cannot ship as designed; that is the finding.
• High-risk. Systems in regulated-product safety components or in the Act's listed high-risk use areas (such as employment, credit, education, essential services, biometrics). This tier carries the heavy obligation set in Step 4.
• Limited / transparency. Systems that interact with people or generate synthetic content. The duty is disclosure (Step 5), not the full high-risk regime.
• Minimal. Everything else. No mandatory obligations beyond voluntary good practice.

State the tier, the single reason it lands there, and the one factor that would move it up or down. Misclassification is the dominant failure mode, so make the reasoning legible.

Step 4: Map high-risk obligations (if applicable)

If high-risk, assess against each obligation and mark present, partial, or absent:

• Risk management system: a continuous, documented process to identify and mitigate risks across the lifecycle.
• Data governance: training, validation, and test data managed for relevance, representativeness, and known bias.
• Technical documentation: the system documented in enough detail to demonstrate conformity.
• Logging and traceability: automatic record-keeping of events over the system's lifetime.
• Human oversight: designed-in measures letting a person understand, intervene, and override.
• Accuracy, robustness, cybersecurity: performance levels and resilience appropriate to the purpose, stated and tested.
• Conformity assessment and registration: the route to demonstrate conformity before placing on the market, plus any registration duty.

For each, record the evidence artifact that would prove it. No artifact means absent, whatever the team intends.

Step 5: Map transparency duties

Independent of tier, apply where relevant:

• Disclose AI interaction: a person interacting with the system is informed they are dealing with AI, unless obvious.
• Label synthetic content: AI-generated or manipulated text, image, audio, or video is marked as such, in a machine-readable way where required.
• Deployer-side notice: deployers of certain systems (for example emotion recognition or deepfakes) carry their own disclosure duties.

Step 6: Map GPAI obligations (if applicable)

If the system trains or substantially modifies a general-purpose AI model:

• Baseline GPAI duties: technical documentation, information for downstream providers, a copyright/training-data policy, and a training-content summary.
• Systemic-risk tier: models above the Act's capability threshold carry added duties (model evaluation, systemic-risk assessment, incident reporting, cybersecurity).
• If you only consume a GPAI model as a deployer without modifying it, note that most GPAI-provider duties sit upstream, and capture what you must obtain from that provider.

Step 7: Output the readiness assessment

# EU AI Act Readiness: {{system_name}}

**Intended purpose:** (one or two sentences)
**In scope:** (yes/no + why)
**Role:** (provider / deployer / both -- per system)
**Risk tier:** (prohibited / high-risk / limited / minimal)
**Tier rationale:** (the single reason, plus what would move it)

## Obligation assessment
| Obligation | Applies? | Status (present/partial/absent) | Evidence artifact | Gap |
|---|---|---|---|---|
| Risk management system | | | | |
| Data governance | | | | |
| Technical documentation | | | | |
| Logging / traceability | | | | |
| Human oversight | | | | |
| Accuracy / robustness / security | | | | |
| Conformity assessment / registration | | | | |
| Transparency: AI disclosure | | | | |
| Transparency: synthetic-content labeling | | | | |
| GPAI duties (if applicable) | | | | |

## Remediation roadmap (prioritized)
| Priority | Gap | Action | Owner | Effort (S/M/L) | Sequence |
|---|---|---|---|---|---|
| P0 | (blocker: prohibited use or missing legally required artifact) | | | | Now |
| P1 | (high-risk obligation absent) | | | | Next |
| P2 | (partial obligation to harden) | | | | Later |

## Phasing note
The Act applies in phases, with prohibited-practice rules, GPAI duties, and high-risk obligations coming into force on a staggered timeline. Sequence remediation against the applicable phase for each obligation. 

## Open questions for counsel
- (classification edge cases, role ambiguity, anything needing legal sign-off)

Step 8: Review

Ask the user:

• Is the tier defensible, and would a regulator reading the same facts agree?
• Are you a provider for any system you assumed you only deployed?
• For every "present" obligation, can you produce the artifact today?
• What is the one P0 that blocks shipping, and who owns it?
• Which gaps belong in counsel's lap, not the team's?

Anti-patterns

Anti-pattern	Why it fails	Do instead
Classifying once, never again	A changed intended purpose or new use case silently moves the tier	Re-classify on any material change to purpose, data, or audience
Assuming "deployer" by default	Fine-tuning or rebranding quietly makes you a provider	Decide the role per system from the facts, flag where you are both
Treating transparency as tier-bound	AI-disclosure and labeling duties apply even to minimal systems	Assess transparency separately, on its own trigger
Intentions instead of artifacts	Audits inspect documents, not good faith	Name the evidence artifact for every obligation; no artifact means absent
One deadline in your head	The Act phases in; a single date misroutes the plan	Sequence each obligation to its own applicable phase
Skipping counsel on edge cases	A readiness assessment is not a legal determination	Route classification edge cases and role ambiguity to a lawyer

Output location

Present the readiness assessment as formatted text in the conversation for the user to copy into their compliance doc.