EU AI Act compliance checklist: a CTO guide to risk classification and high-risk assessments

EU AI Act compliance checklist: a CTO guide to risk classification and high-risk assessments

On 2 February 2025, the EU AI Act started enforcing bans on prohibited AI practices. By 2 August 2026 and 2 August 2027, a lot of teams will be on the hook for full obligations for general-purpose AI and high-risk systems. The penalty ceiling is blunt: up to €35 million or 7 percent of global annual turnover for some violations, and GDPR can stack on top with up to €20 million or 4 percent (Promise Legal checklist). For a Series A company, one bad launch can block EU revenue and spook the next round.

Here’s the thesis. CTOs need an EU AI Act compliance checklist that starts with correct risk classification, then turns into buildable controls, docs, and operating habits. The fastest path is to treat compliance like a product requirement, not a legal afterthought.

What the EU AI Act compliance tool does, and what “risk classification” really means

The EU AI Act Compliance tool on The Art of CTO classifies an AI system’s risk level under the EU AI Act and generates a checklist tied to that category. It’s an AI risk classification tool for teams that need a defensible answer, fast.

Risk classification isn’t a vibe check. It’s a structured decision about:

• What the system does: predictions, recommendations, content, or decisions.
• Who uses it: provider, deployer, importer, distributor, or product manufacturer.
• Where it lands: prohibited, high-risk, limited risk, or minimal risk.
• What triggers apply: Annex III use cases, safety component rules, and transparency duties.

Pinsent Masons uses a practical definition of an AI system under the Act. It’s a machine-based system that runs with some autonomy and infers outputs that influence environments (Pinsent Masons guide). That definition catches more than “ML models”. It catches rules plus ML, LLM routers, and decision engines.

Here’s the framing that tends to click with engineering teams.

Risk classification is a product scope decision with legal consequences. If the intended purpose falls into Annex III, the system can become high-risk even if the model looks simple.

The four EU AI Act risk categories, in CTO terms

• Unacceptable risk: banned practices. This includes certain social scoring and some real-time biometric surveillance uses.
• High risk: strict obligations. Common triggers include hiring, credit, healthcare, and critical infrastructure.
• Limited risk: transparency duties. Article 50 covers labeling chatbots, marking synthetic content, and deepfake disclosure (ABV checklist).
• Minimal risk: no specific AI Act duties, but other laws still apply.

Most SaaS teams land in limited risk at first, then drift into high-risk through customer use. That drift is the trap.

EU AI Act requirements and deadlines CTOs should plan against

The Act entered into force on 1 August 2024, with phased enforcement. What teams miss is the operational reality. This isn’t just policy. It’s logging, documentation, testing, and training.

A practical timeline to plan against:

• 2 February 2025: prohibited practices enforceable, and AI literacy duties start for providers and deployers (Promise Legal checklist, EU AI Act compliance checker updates).
• 2 August 2026: general-purpose AI model obligations apply in many programs (teams should confirm the exact scope for their role and model type) (Promise Legal checklist).
• 2 August 2027: full high-risk compliance date in several guidance packs and roadmaps, including controls for preexisting systems (ECIIA road to compliance PDF).

The dates matter, but the lead time matters more. High-risk readiness often takes 12 to 18 months in real teams. The slow parts aren’t code. The slow parts are evidence, process, and cross-team ownership.

Want the fastest way to get behind schedule? Treat “high-risk” as a future problem, then discover an Annex III trigger during an enterprise procurement cycle.

High-risk AI system assessment: how to classify correctly and avoid Annex III surprises

Most CTOs I talk to struggle with one thing. They know what they built, but they don’t know how customers use it. The EU AI Act cares about intended purpose and use context, so the customer’s workflow can flip the classification.

A named framework: the RACI-Risk Map for AI Act classification

Use this lightweight model before any EU launch. It fits a 10 to 100 engineer org.

• R1. Role: provider, deployer, importer, distributor, product manufacturer.
• R2. Intended purpose: what decisions or outputs the system supports.
• R3. Annex triggers: Annex III categories, plus biometric and emotion uses.
• R4. Data and impact: personal data, vulnerable groups, and rights impact.
• R5. Transparency surface: chat, synthetic content, deepfakes, disclosures.

The output is a one-page decision record. It becomes the first artifact in your technical file.

The EU AI Act compliance checker site tracks changes that matter for this step. It added explicit AI literacy duties and a fundamental rights impact assessment question for deployers of high-risk systems (EU AI Act compliance checker updates). That’s a clue. Regulators expect teams to show their work.

Scenario: hiring screening SaaS that becomes high-risk on day one

ABV gives a clean example. A hiring screening SaaS that ranks candidates for EU customers is an Annex III employment use, so it’s high-risk. The provider must implement risk management, data governance, human oversight, and logging. It must complete a conformity assessment, issue an EU Declaration of Conformity, affix CE marking, and register the system before go-live (ABV checklist).

For a Series A team, that list sounds like a big-company problem. It isn’t. It’s a product gating problem.

A practical engineering translation:

• System inventory: a table of AI features, models, prompts, and intended purposes.
• Evidence pack: prompts, model versions, router rules, and human review actions.
• Audit-ready logs: input, output, overrides, and guardrail events.

If the team can’t produce that evidence in a week, it’s not ready for high-risk customers.

FRIA: the deployer obligation that can block a deal

Public bodies and private entities providing public services must perform a Fundamental Rights Impact Assessment before deploying high-risk systems. The AI Office will provide a template, and deployers may need to notify the market authority after completion (ABV checklist).

This matters even if you’re “just the vendor”. Enterprise and public-sector buyers will ask you for inputs to their FRIA. If your team can’t answer basic questions about risks, mitigations, and oversight, procurement slows down.

Risk management is not a document. It is a lifecycle loop.

Article 9 requires a risk management system that runs across the AI lifecycle. It must identify and analyze risks to health, safety, and fundamental rights. It must test mitigations and revisit them over time (Article 9 overview).

A useful mental model is “SRE for model harm”. You need a loop with triggers, owners, and logs.

Research groups keep pointing out a gap. There are still few published examples of real algorithmic risk assessments, which makes it hard to compare methods and learn good practice (Ada Lovelace Institute report). That gap is an advantage for teams that build a repeatable internal practice early.

Enterprise implications for Series A and early Series B CTOs

This isn’t just a compliance topic. It changes architecture choices, sales motion, and hiring plans.

1. Sales cycles will demand proof, not promises. EU customers will ask for your risk classification, your operator role, and your evidence. High-risk buyers will ask about conformity assessment and registration. ABV’s hiring example lists CE marking and EU database registration as go-live steps (ABV checklist).

2. Shadow AI features will create hidden high-risk exposure. A “helpful” ranking feature can turn into decision support in hiring or credit. That can pull you into Annex III. The fix is product governance, not a Slack reminder.

3. Transparency duties will hit marketing and product UI. Article 50 style duties include labeling chatbot interactions and marking synthetic content in machine-readable form, plus deepfake disclosure and notices for emotion recognition or biometric categorization in some cases (ABV checklist). This touches front-end, content pipelines, and customer success scripts.

4. Your vendor stack becomes part of your compliance story. Plenty of teams “buy AI” inside a CRM, support desk, or analytics tool. WaTech calls out incidental AI, where a vendor adds AI after procurement, or AI shows up as a side feature in an existing system (WaTech risk guidance PDF). You need inventory and change control for vendor AI too.

CTO recommendations: how to run EU AI Act compliance without slowing delivery

Compliance work fails when it lives only in legal. It also fails when it lives only in engineering. What works is a small operating system that produces evidence as a byproduct of shipping.

Immediate actions (next 30 days)

1. Inventory: list every AI system, feature, and model dependency. Include prompts and routing rules. Tie each item to an intended purpose and an owner.

2. Classify: run each item through an AI risk classification tool and record the decision. Use the same questions every time so the team can compare results.

3. Tag customers: mark which customers are EU-based, public sector, or provide public services. Those tags predict FRIA pressure and procurement depth.

4. Add AI literacy training: ship a 45-minute internal module for product, engineering, and support. Track completion by role. The compliance checker site explicitly added AI literacy obligations for providers and deployers (EU AI Act compliance checker updates).

Policy framework (what to write down, then enforce)

1. Operator RACI: define who is the provider and who is the deployer per feature. Put it in the system inventory. This prevents “we thought the customer owned it” surprises.

2. Change control for AI behavior: require review for changes that alter outputs, target users, or decision impact. Treat prompt changes like code changes.

3. Incident handling for model harm: add an “AI incident” type to your incident process. Link it to your blameless workflow and evidence capture. This pairs well with our guide to incident postmortems using a structured template (/tools/incident-postmortem).

4. Build vs buy gates: require a make-or-buy decision record for any new AI component. Use our Build vs Buy Matrix tool (/tools/build-vs-buy-matrix) to capture vendor obligations, audit rights, and logging access.

Architecture principles (what to build into the system)

1. Evidence by default: log prompts, model versions, feature flags, and human overrides. ABV calls this an evidence pack for technical documentation and post-market monitoring (ABV checklist).

2. Human oversight hooks: design explicit pause points and override paths for high-impact flows. Don’t bolt this on in the UI at the end.

3. Data governance guardrails: track dataset lineage, representativeness checks, and evaluation sets. High-risk obligations expect disciplined data handling and testing across the lifecycle (HCLTech EU AI Act guide PDF).

4. Security for model abuse: add controls for adversarial attacks, data poisoning, and model theft. HCLTech lists these as part of accuracy, robustness, and cybersecurity expectations (HCLTech EU AI Act guide PDF).

A decision matrix you can reuse: “Is this feature drifting into high-risk?”

Use this during roadmap reviews. It’s simple enough for weekly product triage.

This matrix isn’t legal advice. It’s a product risk radar.

How to integrate compliance into a 10 to 100 engineer org

A common failure mode is creating a “compliance squad” that turns into a ticket queue. I’d rather see a thin governance layer plus embedded ownership.

• One DRI: a single accountable owner for AI compliance, often the head of platform or security.
• One weekly review: 30 minutes. Review new AI features, vendor changes, and drift signals.
• One system of record: store inventory, decisions, and evidence links. Many teams already have a place for this. If not, use a lightweight internal portal.

This is a good place to connect tools and habits:

• Use our Command Center to track risks, incidents, and migrations in one place (/command-center).
• Use our Engineering Metrics Dashboard to watch delivery health while adding controls (/tools/engineering-metrics-dashboard).
• Use our ArchiMate Modeler to document AI system boundaries and operator roles for audits (/tools/archimate).

Bigger picture: EU AI Act compliance is becoming a product quality bar

The EU AI Act pushes teams toward repeatable assurance work. Research on high-risk assessments shows why. One arXiv paper proposes mapping legal obligations into concrete verification activities across the AI lifecycle, and it demonstrates the mapping in an automotive intrusion detection case with Scania (arXiv high-risk assessment paper). That’s where this is headed. Regulators and buyers want traceable verification, not slide decks.

For startups, there’s also a window of help. The compliance checker site notes EU AI Act measures aimed at SMEs and startups, including access to regulatory sandboxes and reduced conformity assessment fees in some cases (EU AI Act compliance checker updates). Teams that show up prepared can use those channels to de-risk launches.

The hard question isn’t “Are we compliant?”. The hard question is: if a top EU customer asked for your risk classification and evidence pack in 10 business days, could your team deliver it without stopping feature work?

Use the tool: EU AI Act Compliance

Sources

1. EU AI Act compliance checklist (2025–2027) by ABV
2. AI Compliance Checklist for Startups (2025) by Promise Legal
3. EU AI Act Compliance Checker updates and SME measures
4. Article 9 risk management system overview
5. Pinsent Masons guide to high-risk AI systems
6. ECIIA PDF: The AI Act road to compliance
7. WaTech PDF: Implementing risk assessments for high-risk AI systems
8. HCLTech PDF: EU AI Act compliance guide
9. Ada Lovelace Institute report on AI system risks and assessments
10. arXiv: Assessing High-Risk AI Systems under the EU AI Act