EU AI Act AI Supply Chain Due Diligence: Art.13 & Art.26 Deployer Obligations (2026 Checklist)
Post #1453 in the sota.io EU AI Act Compliance Series — EU-AI-ACT-AI-SUPPLY-CHAIN-2026 #2/5
Most SaaS developers approaching the August 2, 2026 EU AI Act deadline focus on their own obligations. But there is a second, often-missed layer: obligations that flow from your AI provider to you, and then from you downward to your end users. Articles 13 and 26 together create a transparency cascade across the entire AI supply chain.
This post maps exactly what your third-party AI API provider must deliver under Art.13, what you as a deployer must do with that information under Art.26, and gives you a concrete 28-item checklist to close the loop before your compliance deadline.
The Two-Layer Transparency Structure
The EU AI Act does not treat AI compliance as a one-party responsibility. It explicitly distributes obligations across the value chain:
Art.13 (Provider obligation → Deployer): Providers of high-risk AI systems must ensure that their systems come with instructions for use that enable deployers to implement the system appropriately.
Art.26 (Deployer obligation → End users & authorities): Deployers must implement the information received from providers, monitor the system, and ensure that human oversight is exercised.
The chain is linear: your AI vendor (provider) must give you documentation → you must act on it → your end users receive the downstream transparency.
If your AI vendor cannot provide what Art.13 requires, you cannot fulfill your Art.26 obligations. That gap is your compliance risk.
What Art.13 Requires Your AI Provider to Deliver
Under EU AI Act Art.13 ("Transparency and provision of information to deployers"), providers of high-risk AI systems must supply deployers with:
1. Instructions for Use
The instructions for use must include all of the following that are applicable:
- Identity and contact details of the provider — who built the model, where to reach them for compliance queries
- The intended purpose of the AI system — the specific use cases the system is authorized for
- Level of accuracy and robustness — the performance metrics the system achieved during testing, including potential failure modes
- Any known or foreseeable circumstances under which the AI system may fail — edge cases, distribution shift risks, adversarial inputs
- The human oversight measures required — what a human must review before the AI output is acted upon
- Technical measures required — infrastructure prerequisites, latency requirements, monitoring specifications
- Measures for logging and monitoring — how the deployer should capture system behavior for audit purposes
2. Conformity Assessment Documentation
For high-risk AI systems, providers must provide evidence that the system has undergone conformity assessment (Art.43). This includes:
- EU Declaration of Conformity (Art.47) — the formal self-declaration or notified body certificate
- CE marking documentation where applicable
- Technical documentation summary showing that the system meets Annex IV requirements
3. Post-Market Monitoring Data Access
Providers must share relevant post-market monitoring data with deployers under Art.72, particularly when that data indicates changes in system performance that affect the deployer's risk profile.
What Art.26 Requires You to Do With That Information
Art.26 ("Obligations of deployers of high-risk AI systems") creates a parallel set of obligations on you as the deployer. You cannot simply receive the Art.13 documentation and file it. You must act on it.
Core Art.26 Obligations
1. Follow the instructions for use. If the provider specifies that the AI system requires human review before a hiring decision is made, you must implement that review. Deploying in a way that contradicts the instructions for use creates direct liability.
2. Assign human oversight. Art.26 requires that deployers assign human oversight to natural persons who are competent, trained, and have the authority to intervene. You must document who in your organization holds this function.
3. Monitor for risks during operation. You must monitor the AI system during operation and report serious incidents or malfunctions to the provider and, where required, to national authorities under Art.73.
4. Perform a fundamental rights impact assessment where required. For specific high-risk categories (public authority deployers, certain private-sector uses), Art.26 requires a FRIA before deployment.
5. Register in the EU database. Deployers of certain high-risk AI systems must register their use case in the EU AI Act public database (Art.49).
The Art.13/Art.26 Gap Problem
Here is the practical problem for SaaS developers integrating third-party AI APIs:
Most commercial AI API providers (OpenAI, Anthropic, AWS Bedrock, Google Vertex AI) serve global markets and have not, as of mid-2026, produced Art.13-compliant instructions for use for their high-risk AI use cases.
This creates a compliance gap:
| Your situation | Risk |
|---|---|
| Your use case is high-risk AI (CV screening, credit scoring, medical triage) | You need Art.13 docs — if provider cannot supply them, you may not be able to deploy legally |
| Your use case is GPAI-based (summarization, content generation, search augmentation) | Art.13 applies differently — GPAI providers have their own Art.50 transparency obligations, not Art.13 |
| Your use case is not high-risk AI | Art.13 does not apply — you have lighter Art.50 transparency obligations instead |
Classification matters before due diligence. Post #1452 in this series covered the decision tree for determining whether your use case is high-risk. If you have not yet classified your integration, do that first.
When Your AI Vendor Cannot Provide Art.13 Documentation
This is a real-world scenario. If your AI API provider cannot or will not provide Art.13-compliant documentation, you have three paths:
Path 1: Downscope to non-high-risk use cases. If your deployment scenario can be redesigned to avoid the Annex III high-risk categories, Art.13 does not apply. This is the most common practical resolution.
Path 2: Treat yourself as the provider. Under the EU AI Act, when you significantly modify a high-risk AI system — including fine-tuning, retraining, or changing its intended purpose — you may be reclassified as a provider (Art.25 concept). As provider, you must then produce Art.13 documentation yourself.
Path 3: Obtain contractual commitments. Negotiate with your AI API vendor for contractual compliance representations including: intended purpose documentation, known failure modes disclosure, incident notification SLAs, and conformity assessment evidence. This creates a paper trail even when formal Art.13 documentation is not yet available.
28-Item Due Diligence Checklist (Art.13 + Art.26)
From Your AI Provider (Art.13 — request these before deployment)
| # | Item | Status |
|---|---|---|
| 1 | Written statement of the AI system's intended purpose | ☐ |
| 2 | List of high-risk use cases covered and excluded | ☐ |
| 3 | Performance metrics (accuracy, precision, recall) on validation dataset | ☐ |
| 4 | Known failure modes and edge cases documentation | ☐ |
| 5 | Instructions for human oversight implementation | ☐ |
| 6 | Required technical measures (latency, monitoring, logging) | ☐ |
| 7 | Data quality requirements for inputs to the system | ☐ |
| 8 | Post-market monitoring data sharing commitment | ☐ |
| 9 | Incident notification SLA (what they will tell you, within what timeframe) | ☐ |
| 10 | EU Declaration of Conformity or equivalent certification evidence | ☐ |
| 11 | Provider contact for compliance queries | ☐ |
| 12 | Changelog policy (how they notify you when the model changes) | ☐ |
| 13 | Jurisdiction of provider (EU/non-EU, CLOUD Act exposure) | ☐ |
| 14 | Data processing agreement covering model inference logs | ☐ |
Your Implementation Obligations (Art.26 — verify these before go-live)
| # | Item | Status |
|---|---|---|
| 15 | Human oversight function assigned (named person or role) | ☐ |
| 16 | Instructions for use implemented in your deployment configuration | ☐ |
| 17 | Monitoring procedures documented for your use case | ☐ |
| 18 | Incident reporting process defined (who files the Art.73 report) | ☐ |
| 19 | Training provided to human oversight personnel | ☐ |
| 20 | Deployment scope limited to provider-authorized use cases | ☐ |
| 21 | FRIA completed if your use case is in a public authority or biometric context | ☐ |
| 22 | EU database registration completed where required (Art.49) | ☐ |
| 23 | Record-keeping system in place for AI-assisted decisions | ☐ |
| 24 | End-user disclosure implemented (Art.50 transparency requirements) | ☐ |
| 25 | Data minimization review for model inputs containing personal data | ☐ |
| 26 | GDPR impact assessment completed if AI processes personal data | ☐ |
| 27 | Version control for the AI system used (track which model version per decision) | ☐ |
| 28 | Off-boarding procedure documented (what happens when you stop using this AI API) | ☐ |
Practical Timelines for August 2, 2026
The August 2, 2026 deadline applies primarily to providers and deployers of high-risk AI systems (Annex III categories). If your use case falls into high-risk:
- Now → June 30, 2026: Request Art.13 documentation from your AI vendor. If they cannot provide it within 2 weeks, escalate to legal review.
- July 1-15, 2026: Complete items 15-28 of the checklist above. Document everything in writing.
- July 16-31, 2026: Final review with legal/compliance. Ensure EU database registrations are filed.
- August 2, 2026: Deadline. All high-risk AI deployers must be compliant.
For GPAI-based integrations (not Annex III high-risk), the primary obligations are Art.50 transparency requirements (disclosing to users that they are interacting with AI). These apply from August 2, 2026 as well, but the documentation burden is significantly lower.
Key Insight: The Supply Chain Is Only as Strong as Its Weakest Link
The EU AI Act's supply chain logic is deliberate: regulators cannot audit every deployer of every AI system. By obligating providers to produce Art.13 documentation and obligating deployers to implement it, the regulation creates a chain of accountability that functions even in complex, multi-vendor architectures.
For SaaS developers building on top of AI APIs, this means your compliance posture is partially determined by your vendor's compliance posture. Selecting an AI API provider who has invested in EU AI Act compliance documentation is not just a legal checkbox — it is a supply chain risk decision.
Next in this series (#3/5): AI Supply Chain Contracts — the mandatory clauses that protect you when your AI vendor's model changes, fails, or gets found non-compliant.
Further Reading
- EU AI Act AI Supply Chain: When SaaS Developers Become Deployers — Post #1 in this series: the provider/deployer classification decision tree
- EU AI Act Deployer Sprint: Art.26 Obligations in Practice — deep dive into Art.26 implementation
- EU AI Act Incident Reporting Operations: Art.73 Playbook — what happens when your AI system fails
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.