EU AI Act August 2026 Compliance Finale: The Complete Developer Checklist

Post #1410 — EU AI Act August 2026 Deadline Sprint, #5 of 5

August 2, 2026 is 64 days away. If your SaaS product uses AI — whether you built the model or you're calling Claude, GPT-4, or Gemini via API — the EU AI Act applies to you in some form, and multiple compliance tracks activate on that date.

This finale post consolidates everything from the sprint series into one authoritative checklist. Bookmark it. Print it. Run it against your codebase before the deadline.

How to Use This Checklist

Each section maps to one EU AI Act article. Articles are not isolated — they interact. A high-risk AI system triggers Art.9, Art.11, Art.13, Art.14, and Art.26 simultaneously. A chatbot triggers Art.50(a). Any serious incident after August 2026 triggers Art.73.

Work through each section that applies to your product. Mark items complete with a date. Keep the signed checklist as part of your Art.11 technical documentation.

Section 1: Are You a Provider or a Deployer?

Before anything else, establish your legal role. It determines which obligations apply.

Most SaaS companies are deployers of at least one AI system. Many are also providers.

Checklist:

• Legal role documented (provider / deployer / both) with date
• All AI components in product inventoried (internal models + third-party APIs)
• For each component: risk classification determined (prohibited / high-risk / limited / minimal)
• Legal counsel reviewed classification for high-risk determinations

Section 2: Art.9 — Risk Management System

Applies to: Providers of high-risk AI systems.

Art.9 requires a documented, systematic risk management process covering the entire lifecycle of your AI system — design, development, testing, deployment, and post-market monitoring.

The Four-Step Risk Management Cycle

1. IDENTIFY → catalogue all foreseeable risks
2. ASSESS   → estimate probability × severity
3. MITIGATE → implement technical + operational measures
4. VERIFY   → test and validate mitigations work

Checklist:

Risk Identification

• Foreseeable misuse scenarios documented (not just intended use)
• Vulnerable groups identified (minors, elderly, non-native speakers, disabled persons)
• Interaction effects with other systems documented
• Risks from training data gaps or biases documented

Risk Assessment

• Each identified risk rated: probability (Low/Medium/High) × severity (Low/Serious/Critical)
• Risk matrix created and retained in documentation

Risk Mitigation

• Technical mitigations in place for each High/Critical risk
• Fallback procedures documented for failure scenarios
• Residual risks after mitigation listed and accepted by designated responsible person

Verification

• Test cases cover each residual risk scenario
• Bias and fairness testing completed and results documented
• Robustness testing against adversarial inputs completed
• Risk management system reviewed whenever model or deployment changes

Section 3: Art.11 — Technical Documentation

Applies to: Providers of high-risk AI systems.

Art.11 requires comprehensive technical documentation before placing a high-risk AI system on the market. This documentation must be kept for 10 years after the last version is placed on the market.

Documentation Package

Your Art.11 documentation must cover:

System Description

• General description of the AI system and its intended purpose
• Version history with dates of significant changes
• Interaction with hardware, software, and other AI systems
• Geographic scope of deployment

Development Process

• Design choices and assumptions underlying the system
• System architecture (model type, architecture, key components)
• Training methodology (if applicable)
• Optimisation objectives and trade-offs made

Data

• Training, validation, and test datasets described
• Data provenance, collection methodology, and labeling approach
• Data quality measures and known data limitations
• Steps taken to detect and mitigate dataset biases

Testing and Validation

• Pre-deployment testing methodology documented
• Performance metrics on validation and test sets
• Testing on representative samples from intended deployment population
• Known performance limitations per demographic group or use context

Ongoing Obligations

• Documentation storage location designated and access-controlled
• Update procedure defined: who updates documentation when system changes
• Retention schedule confirms documents kept for 10 years post-last-version

Section 4: Art.13 — Transparency to Deployers

Applies to: Providers of high-risk AI systems whose system is used by deployers.

Art.13 requires providers to give deployers enough information to use the system appropriately, understand its capabilities and limitations, and meet their own legal obligations.

Checklist:

Instructions for Use

• Written instructions prepared in language(s) of intended deployers
• Intended purpose clearly stated (do not leave this implicit)
• Prohibited uses explicitly listed
• Performance levels and known limitations documented

Deployer-Specific Information

• Human oversight requirements explained (when and how to intervene)
• Monitoring instructions provided (what metrics to watch)
• Accuracy, robustness, and cybersecurity measures described
• Expected inputs and outputs documented with examples

Contractual

• Terms of service or API agreement references Art.13 obligations
• Version-tracking: deployers notified when instructions change materially

Section 5: Art.14 — Human Oversight

Applies to: Providers (design obligation) and deployers (operational obligation) of high-risk AI systems.

High-risk AI systems must be designed to allow effective human oversight. Deployers must implement that oversight in practice.

Provider Obligations (Design)

• System designed so humans can understand outputs and detect anomalies
• System can be monitored, overridden, interrupted, or stopped by authorised persons
• Automated outputs do not take effect without human validation (where risk warrants it)
• Appropriate interfaces for human oversight included in system design

Deployer Obligations (Operations)

• Human oversight person(s) designated by name and role
• Oversight person has authority to override, interrupt, or stop the system
• Oversight person understands AI system capabilities and limitations (training documented)
• Decision points requiring human review defined and integrated into workflow
• Override log implemented: every human intervention recorded
• Regular oversight effectiveness reviews scheduled (at least annually)

Section 6: Art.26 — Deployer Obligations

Applies to: All deployers of high-risk AI systems.

Art.26 is the primary article for most SaaS companies: it establishes what you must do when you use someone else's high-risk AI system in your product.

Checklist:

Before Deployment

• Confirmed the AI system is registered in the EU AI Act database (if registration required)
• Read and understood provider's instructions for use (Art.13 documentation)
• Use case verified as within stated intended purpose
• Fundamental Rights Impact Assessment (FRIA) completed if required by your context

During Operation

• System used only in accordance with provider's instructions
• Human oversight implemented as required (see Art.14 above)
• Technical and organisational measures in place to mitigate provider-identified risks
• Automated outputs reviewed before consequential decisions

Record-Keeping

• Operation logs retained for period required by sector law (minimum: as long as system in use)
• Log format captures: timestamp, input type, output type, human oversight action (if any)
• Logs accessible to market surveillance authorities on request

Incident and Issue Reporting

• Procedure defined for reporting serious incidents to provider and authority (feeds Art.73)
• Procedure defined for reporting malfunctions that do not meet serious incident threshold
• Contact details for provider's incident reporting channel documented

Section 7: Art.50 — Transparency Obligations

Applies to: Providers and deployers of chatbots, synthetic media generators, and emotion recognition / biometric categorisation systems.

Art.50 is a limited-risk obligation — it applies to many SaaS products regardless of whether they use high-risk AI.

Art.50(a) — Chatbot Disclosure

If your product uses a conversational AI system that interacts with humans, users must be informed they are talking to an AI before or at the start of the interaction.

Checklist:

• All chatbot entry points display clear AI disclosure
• Disclosure appears before or immediately at conversation start (not buried in settings)
• Disclosure language meets "clear and distinguishable" standard
• Disclosure not suppressible by user for the first interaction
• Implementation tested: screenshot evidence retained in documentation

Art.50(b) — Synthetic Media Labelling

If your product generates AI images, video, audio, or text that represents real events or people, the synthetic nature must be machine-readable labelled and, where technically feasible, human-readable disclosed.

Checklist:

• Content generated by AI is labelled with technical metadata (C2PA, IPTC, or equivalent)
• User-facing interface indicates AI-generated status for visual/audio content
• Deepfake detection / synthetic media policy documented in terms of service
• Exemptions documented if applicable (art, satire, clearly fictional content)

Art.50(c) — Emotion Recognition

If your product uses emotion recognition:

• Users informed before use begins
• Purpose of emotion recognition disclosed
• Opt-out or refusal mechanism available

Section 8: Art.73 — Serious Incident Reporting

Applies to: Providers of high-risk AI systems; deployers must report to providers and authorities.

After August 2, 2026, any serious incident involving your AI system must be reported to the relevant national market surveillance authority within defined timelines.

What Counts as a Serious Incident?

A serious incident is one that results in, or could plausibly have resulted in:

• Death or serious harm to a person's health
• Significant disruption to the management or operation of critical infrastructure
• Infringement of fundamental rights
• Serious property damage or environmental harm

The 2/10/15-Day Timeline

Day 0: Incident occurs or you become aware of it
│
├─ Day 2  → INITIAL NOTIFICATION to market surveillance authority
│            What: type of incident, system involved, affected persons
│            How: authority's official reporting channel
│
├─ Day 10 → INTERMEDIATE REPORT
│            What: preliminary cause analysis, containment measures taken
│            How: follow-up to initial notification
│
└─ Day 15 → FINAL REPORT
             What: root cause, corrective actions, prevention measures
             How: formal closure report with technical documentation attached

Technical Implementation Checklist:

• Incident detection rules defined in monitoring system (Prometheus alerts, etc.)
• Severity classifier routes potential incidents to human reviewer within 15 minutes
• On-call rotation covers incidents 24/7 post-August 2026
• Authority notification template prepared (covers required Day 2 fields)
• Intermediate report template prepared
• Final report template prepared with technical documentation attachment checklist
• Reporting channel URL/contact for each relevant national authority documented
• Internal incident log retains all Art.73-relevant events for 10 years
• Tabletop exercise completed: simulate a serious incident end-to-end

Section 9: Cross-Article Integration Test

The articles above interact. Run this integration test against your actual systems:

Scenario A: Your High-Risk AI System Makes a Consequential Error

1. Error detected → Does your Art.72 post-market monitoring log capture it? ✓/✗
2. Severity assessment → Does your Art.73 classifier correctly identify it as serious or not? ✓/✗
3. If serious → Is Day 2 notification triggered automatically with the right data? ✓/✗
4. Human override → Can your Art.14 oversight person intervene and stop the system? ✓/✗
5. Corrective action → Does your Art.9 risk management system get updated? ✓/✗

Scenario B: A New Deployer Integrates Your High-Risk AI System

1. They request your Art.13 instructions → Do you have current, versioned documentation ready? ✓/✗
2. They ask about Art.14 requirements → Can you tell them exactly what oversight to implement? ✓/✗
3. They have an incident → Do they know your Art.73 reporting channel and what to send? ✓/✗

Scenario C: Your Product Uses a Third-Party AI API (Deployer Role)

1. You call Claude, GPT-4, or Gemini → Have you determined if the use is high-risk? ✓/✗
2. If high-risk → Have you implemented Art.26 obligations? ✓/✗
3. You display AI output to end users → Is Art.50(a) disclosure in place? ✓/✗
4. You generate images or audio → Is Art.50(b) labelling implemented? ✓/✗

Section 10: Documentation Retention Summary

Store documentation in a version-controlled, access-controlled system. Designate a responsible person who is accountable for documentation completeness and accuracy.

Before August 2, 2026: Final Sprint Actions

With 64 days to go, prioritise in this order:

Week 1–2 (now):

• Complete role determination (provider / deployer / both)
• Inventory all AI components
• Classify each for risk level

Week 3–4:

• Run Art.50 chatbot and synthetic media checks — easiest to fix
• Implement Art.14 human oversight designation and override logging

Week 5–6:

• Complete Art.9 risk management documentation for high-risk systems
• Complete Art.11 technical documentation package

Week 7–8:

• Test Art.73 incident detection and notification pipeline end-to-end
• Run integration scenario tests (Section 9 above)

Final week:

• Legal review of documentation package
• Sign off by designated responsible person
• Archive completed checklist as part of Art.11 technical documentation

What Comes After August 2

Compliance is not a one-time event. After the deadline:

• Art.9 requires continuous risk management — update when system changes
• Art.11 requires documentation updates with each material system version
• Art.72 requires post-market monitoring to be actively operated
• Art.73 requires incident reports to be filed when incidents occur — not just documented

The EU AI Act enforcement machinery (national market surveillance authorities, the EU AI Office) will be operational. Enforcement actions — including fines up to €35 million or 7% of global annual turnover for provider violations — are legally possible from this date.

Sprint Series Recap

This post completes the EU AI Act August 2026 Deadline Sprint:

Deploy on EU Infrastructure

EU AI Act compliance requires knowing where your AI systems run and who has jurisdiction over your data. A managed PaaS on EU infrastructure — with no US parent company, no CLOUD Act exposure, and Hetzner Germany as the underlying compute — removes one category of compliance uncertainty entirely.

sota.io is built for exactly this: EU-native, GDPR-ready, deploy any language in minutes.

August 2, 2026 is 64 days away. Use this checklist, not just read it.