You've read the headlines. Your legal team has skimmed the regulation. Maybe you've even attended a webinar. But when the EU AI Act's enforcement deadlines arrive, your compliance state won't be measured by what you know, it'll be measured by what you've documented, implemented, and validated.
This checklist translates the Act's requirements into actionable compliance tasks. It's designed for teams deploying AI systems that fall under the Act's scope, particularly those classified as high-risk under Annex III.
Prerequisites
Before you start this checklist, confirm:
- You've completed your risk classification. You know whether your AI systems qualify as prohibited, high-risk, limited-risk, or minimal-risk under the Act's tiering framework.
- You've identified your role. Are you the provider, deployer, or both? Your obligations differ significantly.
- You have executive sponsorship. Compliance requires cross-functional coordination and budget. Document who owns AI Act compliance at the C-suite level.
Compliance Checklist
System Classification and Documentation
1. Document your risk classification methodology
Create a written procedure explaining how you determine whether an AI system qualifies as high-risk. Reference Annex III categories explicitly (biometric identification, critical infrastructure, employment, essential services, law enforcement, migration/asylum, justice/democracy).
Good looks like: A flowchart with decision points tied to specific Annex III provisions, plus a log of every classification decision showing who evaluated it and when.
2. Establish a conformity assessment pathway
For each high-risk system, determine whether you'll follow internal conformity assessment (Article 43) or involve a notified body. Document your rationale.
Good looks like: A matrix listing each high-risk system, its applicable harmonized standard, and whether internal assessment is permissible under Annex VI or if third-party involvement is required.
3. Complete Technical Documentation (Annex IV)
Compile the required technical file including: general system description, design specifications, data governance measures, monitoring procedures, risk management documentation, and validation reports.
Good looks like: A version-controlled repository where each Annex IV element is mapped to specific artifacts (architecture diagrams, data lineage docs, test reports) with clear ownership and review dates.
Data Governance and Quality
4. Document your training data governance
Article 10 requires detailed data governance practices. Record your data sourcing decisions, quality checks, relevance assessments, and bias mitigation measures.
Good looks like: Data cards for each training dataset showing provenance, representativeness analysis, known limitations, preprocessing steps, and the specific bias tests you ran before model training.
5. Implement data examination protocols
Establish procedures for ongoing data quality monitoring, not just pre-deployment checks.
Good looks like: Automated data drift detection with defined thresholds, quarterly manual reviews of edge cases, and a documented escalation path when quality degrades below acceptable levels.
Risk Management System
6. Build a continuous risk management process
Article 9 requires risk management throughout the system lifecycle. Create a living document that evolves as you learn from deployment.
Good looks like: A risk register that gets updated after each incident, near-miss, or user complaint, with clear ownership for each identified risk and documented mitigation status.
7. Define your risk acceptance criteria
Document what level of residual risk you'll accept and who has authority to approve deployment despite known risks.
Good looks like: A risk matrix with quantified thresholds and a governance board charter showing who can sign off on residual risks above certain levels.
Human Oversight Mechanisms
8. Design human oversight controls
Article 14 requires human oversight measures. Don't just add a "human in the loop", define what that human can actually do.
Good looks like: Interface mockups showing override controls, documented decision authority, training materials for oversight personnel, and metrics tracking how often humans intervene.
9. Document oversight limitations
Be honest about where human oversight isn't feasible or effective. Explain your reasoning and alternative controls.
Good looks like: A technical analysis showing why real-time intervention isn't possible for certain use cases, plus compensating controls like batch review processes or enhanced Post-Market Monitoring.
Transparency and User Rights
10. Prepare user-facing transparency disclosures
Draft clear explanations of how your AI system works, its limitations, and how users can exercise their rights under the Act.
Good looks like: Plain-language disclosures tested with actual end users. Include concrete examples of system limitations and what users should do if they disagree with an AI decision.
11. Establish an individual rights response process
The Act includes AI-specific rights for individuals. Build procedures to handle requests for explanation, human review, or challenge of automated decisions.
Good looks like: Defined SLAs for rights requests, templated response formats, and a tracking system showing request volume and resolution outcomes.
Post-Market Monitoring
12. Implement logging requirements
Article 12 mandates automatic logging capabilities. Define what you'll log, retention periods, and who can access logs.
Good looks like: Logging architecture documentation showing what events trigger logs, how you protect log integrity, retention schedules tied to your risk classification, and access controls preventing tampering.
13. Create a serious incident reporting procedure
Know what qualifies as a serious incident and who reports it to authorities within what timeframe.
Good looks like: A decision tree helping staff classify incidents, contact details for relevant market surveillance authorities, and a tested escalation protocol with defined response times.
Common Mistakes
Treating this as a one-time project. The Act requires continuous compliance. Your initial documentation is just the starting point.
Copying GDPR processes wholesale. While there's overlap, the AI Act's technical requirements demand different artifacts. A Data Protection Impact Assessment doesn't automatically satisfy Article 9's risk management requirements.
Assuming internal expertise is sufficient. If you're using third-party models or components, you need documentation from your suppliers. Start those conversations now.
Underestimating documentation burden. Technical Documentation (Annex IV) isn't a short form. Budget for technical writers and plan for ongoing maintenance as systems evolve.
Next Steps
Pick three items from this checklist where you're furthest from "good." Assign owners and set 30-day milestones. Compliance isn't built in a sprint, it's built through consistent, documented progress.
And remember: the teams that treat compliance as a design input, not a deployment blocker, will ship faster and sleep better when enforcement begins.
