EU AI Act Art.26 + Art.27 Complete Deployer Compliance Checklist: Verification Package 2026

Post #5 of 5 in the sota.io EU AI Act Art.25–26 Deployer Pack Series

The EU AI Act's August 2, 2026 deadline is 53 days away as of this writing. For SaaS platforms that deploy high-risk AI systems — whether via third-party APIs (OpenAI, Anthropic, Azure AI, Google Vertex) or embedded AI components — full compliance with Art.26 deployer obligations is now a legal requirement. This post is the finale of our five-part series: a deployment-ready verification package that consolidates every Art.26 and Art.27 obligation into a single, structured checklist.

This post references the four preceding posts in the series and should be read alongside them. It does not repeat detailed explanations — it provides the audit trail.

Who This Checklist Applies To

You are a deployer under Art.26 if your organisation:

• Uses a high-risk AI system under your own name or trademark
• Integrates a third-party AI API to automate consequential decisions (employment, credit, insurance, access to essential services, education, law enforcement, biometric ID, critical infrastructure)
• Deploys an AI system that falls within Annex III categories and does not make substantial modifications (in which case you become a provider under Art.16)

At stake: Art.99 penalties for deployers who breach Art.26 obligations reach up to €15 million or 3 % of global annual turnover, whichever is higher.

Section 1: Pre-Deployment Compliance Checklist (Art.26(1))

Before going live with any high-risk AI system or feature, verify all of the following.

1.1 Intended Use Verification

• You have obtained and reviewed the provider's instructions for use
• You have confirmed your deployment scenario matches the provider's declared intended purpose
• You have documented every use case and mapped each to the instructions for use
• Any use case not covered by the instructions for use has been escalated to the provider before deployment
• You maintain a use-case registry (spreadsheet or ticketing system) listing every context in which the AI system is deployed

1.2 Technical and Organisational Measures

• Technical safeguards are in place to prevent use outside the intended purpose (role-based access, workflow guards, API gateway restrictions)
• Organisational policies prohibit repurposing the AI output for non-declared use cases
• Contract with the provider specifies permitted deployment scenarios
• You have not made any input modifications that would change the AI system's output in ways inconsistent with the instructions for use

1.3 Provider Contractual Coverage

• Your contract with the provider includes:
  • Provision of technical documentation on request (Art.26(1))
  • Notification obligations if the provider modifies the system (which may change your compliance status)
  • Clear liability allocation for incidents arising from provider-side failures

Section 2: Human Oversight Implementation Checklist (Art.26(2))

Art.26(2) requires deployers to assign human oversight to persons with the necessary competence, training, and authority.

2.1 Oversight Role Assignment

• At least one named individual is assigned as human oversight responsible per high-risk AI system
• The assignment is documented (job description, contract addendum, or policy document)
• The oversight responsible has the authority to intervene, suspend, or override the AI system's output
• Escalation path is defined: oversight responsible → management → Legal/Compliance

2.2 Competence Verification

• Oversight responsible has completed documented training on:
  • How the AI system works (technical basics from provider documentation)
  • What the system can and cannot do (capability boundaries)
  • How to detect anomalies, errors, or discriminatory outputs
  • How to suspend the system if needed
• Training records are stored with a minimum retention period of 3 years (aligned with Art.12 log retention best practice)

2.3 Operational Oversight Protocols

• Human review is conducted for:
  • High-stakes decisions (employment, credit, insurance, access to essential services)
  • Cases where AI confidence scores fall below a defined threshold
  • Flagged edge cases from the monitoring system
• The ratio of human-reviewed to automated decisions is tracked and reported internally

Section 3: Input Data Quality Checklist (Art.26(4))

If your organisation exercises control over the input data fed to the AI system, Art.26(4) places additional obligations on you.

3.1 Data Relevance and Representativeness

• You have mapped which input data flows into the AI system under your control
• You have verified input data is relevant to the declared use case and does not include prohibited categories (unless permitted by law)
• Input data quality checks are automated: schema validation, null-value detection, outlier flagging
• You have documented the data sources and their provenance

3.2 Bias and Disparity Monitoring on Inputs

• Demographic disparity checks run on input distributions (where applicable)
• Input drift (distribution shift) is detected and triggers a review before the AI system processes the next batch
• You have a documented process for handling data quality failures: reject → log → notify provider

Section 4: Operational Monitoring Checklist (Art.26(5))

Post-deployment monitoring is mandatory. Art.26(5) requires deployers to monitor the AI system's operation on the basis of the instructions for use and to inform the provider or distributor of discovered issues.

4.1 Monitoring Infrastructure

• Automated monitoring is live for all production AI system instances
• Metrics collected include: error rates, output confidence distributions, inference latency, output diversity scores
• Alert thresholds are defined for anomalies (e.g. confidence score drop >15 %, error rate increase >5 %)
• Monitoring dashboard is reviewed at a defined cadence (at minimum: weekly)

4.2 Log Retention (Art.26(5) cross-reference Art.12)

• Logs are stored for a minimum of 6 months (Art.12 reference for deployer-generated logs)
• Log storage is in an EU jurisdiction or subject to documented legal transfer mechanisms (Cloud Act exposure documented)
• Logs include: timestamp, input hash (not raw PII), output category, human override flag, user identifier (pseudonymised)
• Log access is restricted to authorised personnel (GDPR Art.5 integrity principle)

4.3 Provider Notification

• You have a defined process to notify the provider when monitoring detects:
  • System malfunctions not covered in the instructions for use
  • Unexpected outputs that may indicate model drift
  • Performance degradation below the provider's stated thresholds
• Notification records are kept (date, content, provider acknowledgement)

Section 5: Incident Reporting Checklist (Art.26(6) + Art.73)

A serious incident under Art.73 is one that causes or could cause death, serious health impact, disruption of essential services, or infringement of fundamental rights. Deployers have a duty to report.

5.1 Incident Detection

• Incident criteria are documented and shared with engineering and product teams
• Automated detection rules flag potential serious incidents in real time
• On-call rotation includes a compliance-aware engineer with incident escalation authority

5.2 Notification Chain

• For any suspected serious incident:
  • Incident logged immediately in the incident management system
  • Provider notified without undue delay (document the timestamp)
  • Legal and DPO notified within 24 hours
  • Assessment completed: is this reportable to the NCA under Art.73?
• If reportable to NCA:
  • Initial NCA notification sent as soon as possible, no later than 15 days after becoming aware of the incident
  • Intermediate report (where required) submitted within the timeframe specified by the NCA
  • Final report submitted with full root-cause analysis and corrective action

5.3 Incident Records

• All incidents (including near-misses) are recorded with: date detected, description, affected users, impact assessment, actions taken
• Incident records retained for minimum 3 years
• Post-incident review completed and findings incorporated into monitoring thresholds

Section 6: NCA Cooperation and Market Surveillance Checklist (Art.26(7) + Art.74)

Under Art.26(7), deployers must cooperate with national competent authorities (NCAs) on market surveillance requests. Art.74 governs how NCAs conduct market surveillance.

6.1 Documentation Readiness

• The following documents are maintained and can be produced on NCA request within 10 business days:
  • Instructions for use from the provider
  • Use-case registry (Section 1.1 above)
  • Human oversight assignment records (Section 2.1)
  • Training records (Section 2.2)
  • Input data quality documentation (Section 3.2)
  • Monitoring configuration and alert history (Section 4.1)
  • Incident log (Section 5.3)

6.2 Suspension Readiness

• You have a documented and tested procedure to suspend the AI system within 4 hours of a directive to do so
• Suspension does not require provider cooperation (i.e. your team has the technical ability to disable AI integrations independently)
• Downstream communication plan exists: how to notify affected users and stakeholders if the system is suspended

Section 7: Employee Information Checklist (Art.26(8))

Art.26(8) requires deployers to ensure that the natural persons subject to the AI system's decisions are informed that they are subject to the use of a high-risk AI system.

7.1 User-Facing Disclosure

• Users (employees, applicants, customers) are clearly informed before the AI system is used to make or assist in a decision about them
• Disclosure includes: that AI is involved, the general nature of the AI system, contact for human review
• Disclosure is available in the user's language and format (accessible UI, written notice, or contractual clause)

7.2 Internal Employee Notification

• For AI systems used in employment or HR contexts:
  • Works council (Betriebsrat / employee representatives) has been consulted where required by national law
  • Information to employees includes: purpose of the AI system, data used, right to human review
• Documentation of notification is retained

Section 8: Art.27 FRIA Checklist

Art.27 requires certain deployers to conduct a Fundamental Rights Impact Assessment (FRIA) before deploying certain high-risk AI systems. This section provides a quick verification gate; full FRIA methodology is covered in our dedicated five-post FRIA series.

8.1 FRIA Trigger Assessment

A FRIA is mandatory if you are:

• A body governed by public law (as defined in EU procurement directives), OR

• A private entity deploying high-risk AI in:

  • Employment or workers' management
  • Access to self-employment or contractual relations (including credit scoring, insurance)
  • Education or vocational training (Art. 6 + Annex III categories 1, 2, 5, 6)

• You have documented whether Art.27 applies to your organisation and each deployment context

• If Art.27 applies: FRIA has been conducted before deployment

8.2 FRIA Verification Checklist

If FRIA was completed:

• FRIA document covers: scope of system, intended use, affected populations, fundamental rights at risk, risk mitigation measures
• FRIA was conducted before production deployment (not retroactively)
• FRIA was reviewed by a qualified legal or compliance professional
• FRIA is registered with the EU Database if required (Art.71 for systems listed in Annex III)
• FRIA is scheduled for review upon: major system update, change in use case, or annual review cycle (whichever comes first)

Penalties Summary

Penalties apply per breach. A single deployment incident with multiple Art.26 failures may result in cumulative enforcement actions.

Self-Assessment Grid: August 2026 Readiness

Timeline to August 2, 2026

With 53 days remaining, here is a suggested sprint schedule for deployers starting from scratch:

Weeks 1–2 (June 11–22): Complete Sections 1, 2, and 7. These require no technical changes — only documentation, role assignment, and training records. Lowest effort, highest risk if missing.

Weeks 3–4 (June 23 – July 6): Complete Section 4 (monitoring infrastructure) and Section 3 (input data quality checks). Requires engineering involvement but no architectural changes to the AI integration.

Weeks 5–6 (July 7–20): Complete Section 5 (incident reporting procedures) and Section 6 (NCA cooperation documentation readiness). These require legal review and testing of the suspension procedure.

Week 7 (July 21–27): Art.27 FRIA completion (Section 8) if applicable. FRIA requires 2–5 business days for a qualified assessment for most SaaS deployment scenarios.

Buffer week (July 28 – August 1): Final review, gap closure, and internal sign-off.

Infrastructure Note: Where You Host Matters

Art.26's monitoring, logging, and incident-reporting obligations generate significant data flows. Under the US Cloud Act, logs stored in US-jurisdiction infrastructure are accessible to US law enforcement — potentially including AI system audit data. For high-risk AI deployments subject to both EU GDPR and AI Act obligations, hosting on EU-sovereign infrastructure eliminates the intersection risk between your Art.12/26 log retention obligations and Cloud Act exposure.

sota.io provides EU-only hosting and deployment with zero US-jurisdiction data processing. If you are revisiting your infrastructure stack before August 2, this is the moment to switch.

Series Summary

This five-post series has covered the complete Art.26 deployer obligations landscape:

1. Art.26 Overview + Use-Case Restrictions — intended use compliance, documentation requirements, deployer vs. provider boundary
2. Art.26 Fundamental Rights Compliance — non-discrimination monitoring, protected group analysis, human oversight for rights-affecting decisions
3. Art.26 + Art.4 AI Literacy Obligations — staff training requirements, competency documentation, ongoing literacy programmes
4. Art.26 Operational Obligations — monitoring infrastructure, log retention, market surveillance cooperation, NCA notification chains
5. This post — the complete verification package

For FRIA methodology in depth, see our dedicated Art.27 FRIA series.

All citations reference the final adopted text of Regulation (EU) 2024/1689 (EU AI Act) as published in the Official Journal of the European Union. The August 2, 2026 deadline applies to obligations for providers and deployers of high-risk AI systems listed in Annex III. Seek qualified legal counsel for jurisdiction-specific implementation.