EU AI Act Compliance Guide for Engineers: Risk Classification to Minimum Viable Compliance

Which of your AI features count as "high-risk AI"? Your resume screening tool, credit scoring module, or AI customer service system? Most engineers don't know the answer, but it determines everything you need to do before August 2, 2026.

The EU AI Act's high-risk AI obligations take full effect on August 2, 2026, with penalties up to EUR 15 million or 3% of global revenue. Like GDPR, this regulation doesn't care where your company is registered. If your AI output affects anyone in the EU, you're in scope.

This guide gives engineers a practical path: 5-minute risk self-assessment, role identification, minimum viable technical documentation, and a 4-month countdown action plan. You can complete the first three steps without a lawyer.

TL;DR

• If your AI product's output affects EU users, you're subject to the EU AI Act regardless of where your company is based
• High-risk AI (resume screening, credit scoring, medical decisions) compliance deadline is August 2, 2026
• Building products with Claude/GPT APIs makes you both a Deployer (for the model) and a Provider (for your product), with both sets of obligations
• The real compliance driver today is B2B customer procurement requirements, not fine enforcement (zero fines issued to date)
• Start with the official Compliance Checker for a 5-minute self-assessment

Is Your SaaS Within EU AI Act Scope?

The first reaction from many non-EU engineers is "my company isn't in Europe, why should I care?" The answer: the EU AI Act uses output-based jurisdiction, just like GDPR. Regardless of where the provider is established, if your AI system is "placed on the EU market" or "put into service" in the EU, you're regulated.

In plain terms: if your SaaS has European users and your AI output affects natural persons within the EU, you're in scope.

Specific scenarios that trigger obligations:

• Your HR SaaS is used by a European office to screen resumes
• Your FinTech product is used by EU clients for credit assessment
• Your AI chatbot handles queries from European users

"I only have a few EU users, do I still need to comply?" Honestly, the regulation doesn't set a "too small to care" threshold. High-risk AI obligations apply regardless of scale. But don't panic yet. Complete the Annex III self-assessment first. If your system isn't high-risk, most of the heavy obligations don't apply.

Annex III Self-Assessment: 5 Minutes to Determine High-Risk Status

This is the most important first step in the entire compliance process, and the most commonly skipped. Engineers typically grab the compliance checklist and jump straight to writing Annex IV technical documentation, skipping risk classification entirely. The problem: if your system isn't high-risk AI, all that documentation work is wasted.

Annex III lists 8 categories of high-risk AI systems. The most commonly triggered categories for SaaS products:

Category	Annex III Class	Common SaaS Examples
Employment	Category 4	Resume screening, performance evaluation, promotion/termination decisions
Essential Services	Category 5	Credit scoring, loan assessment, insurance pricing
Biometrics	Category 1	Facial recognition, identity verification systems

Notable exception: pure anti-fraud AI is not classified as high-risk. If your FinTech product only uses AI to detect anomalous transactions without credit scoring, it may fall outside the high-risk scope.

Practical step: Open the official EU AI Act Compliance Checker, a free interactive tool designed for SMEs. It takes 5-10 minutes to complete. Your results will tell you:

• Not high-risk → Only basic transparency requirements apply (inform users they're interacting with AI). Significantly reduced burden
• High-risk → Continue with technical documentation and human oversight requirements below

Classify first, then document. This sequence matters.

Provider or Deployer? Responsibility Boundaries When Building with APIs

Once you've confirmed high-risk status, the second critical question is: what role do you play in the AI value chain?

Article 3 defines two core roles:

• Provider: The person or entity that develops an AI system and places it on the market under their own name
• Deployer: The person or entity that uses an AI system in a professional capacity

Sounds straightforward, but here's the reality: if you build a SaaS product using Claude or GPT APIs, you're both roles simultaneously.

For the underlying model (Claude/GPT), you're a Deployer bound by Article 26 (use as instructed, ensure input data quality, monitor operations). For the complete AI product you ship under your own brand, you're a Provider subject to Articles 9-22 (technical documentation, CE marking, risk management, EU database registration).

Role	Key Obligations	Applicable Articles
Provider	Technical documentation, risk management, CE marking, EU database registration, conformity assessment	Articles 9-22
Deployer	Use as instructed, input data quality, operational monitoring, appoint qualified oversight personnel	Article 26

A common misconception: "I use OpenAI's API, so compliance is OpenAI's problem." Not how it works. OpenAI has its own GPAI obligations, but your Provider obligations for your own product are independent and cannot offset each other.

The escalation rule is critical: if you substantially modify a third-party GPAI model or rebrand it with a new intended purpose, you escalate to full Provider status with the complete set of obligations.

Recommended action: Build an AI Inventory listing every AI feature, with role identification and obligation mapping for each.

Annex IV Technical Documentation MVP: Minimum Viable Version for Small Teams

If you're confirmed as a high-risk AI Provider, you'll need to prepare Annex IV technical documentation. The core insight: this is about organizing design decisions you've already recorded, not writing a book from scratch.

Annex IV has 9 sections. Here's the minimum viable version for each:

Section	Content	Documents You Likely Already Have
1. General Description	System purpose, version, intended users	Product README, PRD
2. Development Elements	Architecture, training methods, data sources	Architecture diagrams, design docs
3. Monitoring & Control	Capability limits, demographic accuracy	Test reports, monitoring dashboards
4. Performance Metrics	Accuracy, false positive/negative rates, fairness	Model evaluation reports
5. Risk Management	Identified risks and mitigations	Risk docs, incident logs
6. Change Log	Version history, major updates	Git log, changelog
7. Standards Applied	Which standards or alternatives adopted	Compliance mapping table
8. Conformity Declaration	EU declaration of conformity	Needs to be created
9. Post-Market Monitoring	Ongoing monitoring plan	Monitoring SOP

The regulation explicitly allows SMEs to submit documentation in a "simplified manner," and the Commission plans to release SME-specific simplified forms (not yet published as of April 2026).

Industry estimates suggest 40-80 hours of preparation for systems where design decisions have been continuously documented. The heaviest lift isn't writing new documents, but mapping scattered existing records to the Annex IV framework.

A practical reality to face: CEN-CENELEC harmonized standards are expected to be completed by late 2026, but the compliance deadline is August 2, 2026. This means no complete official technical standards will exist before the deadline.

The current best alternative path: use ISO 42001 (AI management system standard) as your framework, supplemented by the Spanish AESIA guidance (currently the only complete EU AI Act implementation guide). These remain valid regardless of when future standards are finalized.

Article 14 Human Oversight Engineering: More Than a Button

Article 14 requires high-risk AI systems to be designed for effective human oversight. Many engineers' first instinct is to add an "Override" button. That's far from sufficient.

The engineering community consensus: meaningful override is an architecture design problem, not a UI problem. If your audit trail falls back to allow-mode during anomalies, you're creating false compliance records.

Article 14's 5 engineering requirements:

1. HMI tools: Dashboards and alerts for operators to monitor AI decision anomalies in real time
2. Interrupt mechanism: Operators must be able to genuinely halt AI output at the system level, not just "ignore" in the UI
3. Automation bias prevention: System design that keeps personnel aware of over-reliance on AI
4. Interpretability tools: Explainability features that let oversight personnel understand why the AI made a specific decision
5. Capability boundary disclosure: Clear communication of system limitations to oversight personnel

The design principle is fail-closed: when the AI system is uncertain, it should default to refusing a decision, not defaulting to approval. This runs counter to most engineers' instincts, but it's what "meaningful" actually means in the regulation.

Checklist:

• System defaults to refusing decisions during anomalies (fail-closed), not defaulting to approval (fail-open)
• Audit trail logs every human intervention and cannot be automatically bypassed
• Oversight personnel have actual authority and technical capability to execute overrides
• Override mechanism operates at the system architecture level, not just the frontend UI

Countdown to August 2, 2026: 4-Month Action Plan

Based on Orrick's compliance guide, here are 6 steps. Good news: steps 1-3 can be completed by a single person.

Step 1: AI Mapping (This Week)

Inventory all AI systems and GPAI models across your organization, including tools accessed via APIs. List each system's purpose, data sources, and affected persons.

Step 2: Role Identification (This Week)

Determine whether you're a Provider, Deployer, or both for each system. Reference the AI Inventory table above.

Step 3: Annex III Risk Classification (This Week)

Use the official Compliance Checker to complete self-assessment for each AI feature. If none are high-risk, the heavy obligations don't apply.

Step 4: Technical Documentation (April-May)

For high-risk systems, begin mapping existing design documents to the Annex IV 9-section framework. Use ISO 42001 as your governance architecture foundation.

Step 5: Contract Updates & Due Diligence (May-June)

Revise AI service contracts, address third-party API modification rights. Verify upstream GPAI providers' compliance status.

Step 6: AI Governance Framework (June-July)

Establish internal AI policies, AI literacy training, and cross-functional collaboration processes. Note that AI literacy obligations have been in effect since February 2, 2025.

For non-EU companies confirmed as high-risk AI Providers targeting the European market, there's an additional cost: an EU Authorized Representative. Industry estimates put third-party representative services at approximately EUR 2,000-5,000 per year.

Enforcement Reality and the True Compliance Driver

An honest assessment: as of 2026, only 8 of 27 EU member states have formally established AI Act enforcement bodies, and zero fines have been issued. The European Commission's Digital Omnibus proposal could potentially extend high-risk obligations to late 2027.

So why act now?

The real driver isn't fear of fines, it's B2B customer pressure. European enterprises are already requiring AI Act compliance statements when procuring SaaS tools. Companies that achieve compliance first gain a direct competitive advantage in B2B sales.

Commonly overlooked risks:

LLM API + GDPR intersection: If your system sends prompts containing personal data to third-party LLM APIs (like processing EU user resumes via Claude), you simultaneously trigger GDPR Data Processing Agreement obligations. The lowest-cost solution: strip personally identifiable information before sending to the LLM. Most engineers are completely unaware of this layer.

Cross-regulation overlap: In FinTech, you may simultaneously face DORA (Digital Operational Resilience Act) + GDPR + AI Act. DORA's 4-hour incident reporting window can create engineering conflicts with AI Act documentation requirements.

Digital Omnibus isn't a free pass: Even if passed, it only extends deadlines by up to 16 months. The cost of starting AI Mapping and documentation now doesn't go to waste. The ISO 42001 framework remains valid at any point. And non-compliance history could become a retroactive liability.

Conclusion

The EU AI Act's impact on engineers is real, but the compliance path is more manageable than the legal text suggests. The most common mistakes are skipping classification to jump straight to documentation, or assuming "using a third-party API means I don't need to comply."

Your first step today: open the official Compliance Checker and spend 5 minutes completing the Annex III self-assessment. The result will tell you exactly how much you actually need to do, and it might be less than you think.