EU AI Act Art.11 Technical Documentation 2026: What Deployers Must Maintain

Post #3 in the sota.io EU AI Act Deployer Sprint 2026 — August Deadline

Article 11 of the EU AI Act places the primary documentation burden on providers — the companies that develop and place high-risk AI systems on the market. But if you are a SaaS deployer integrating a third-party AI system, your own documentation obligations are substantial. You need to know what to request, what to verify, what to maintain yourself, and what happens if documentation is incomplete when a market surveillance authority comes calling.

This guide covers the full documentation picture for deployers. It is the third post in our five-part series on EU AI Act deployer obligations ahead of the 2 August 2026 deadline.

Why Documentation Matters for Deployers Specifically

The EU AI Act builds its enforcement model on documentation. Market surveillance authorities (Art.74) conduct audits by reviewing technical documentation, logs, and impact assessments. They do not primarily inspect running systems — they inspect records. A deployer who cannot produce the right documentation at audit time faces the same penalties as a deployer who violated a substantive obligation.

There are three distinct documentation layers every deployer of a high-risk AI system must understand:

1. Provider documentation (Art.11 + Annex IV) — what the provider draws up and what you should receive
2. Instructions for use (Art.13) — what the provider must give you, and what you must retain and follow
3. Deployer records (Art.26 + Art.27) — what you must create and maintain yourself

Layer 1: Provider Technical Documentation (Art.11 + Annex IV)

Article 11 requires providers to draw up technical documentation before placing a high-risk AI system on the market or putting it into service. The documentation must be kept up to date and must contain the information specified in Annex IV.

As a deployer, you will not typically draw up this documentation yourself — but you must ensure it exists, is accessible, and is complete. This matters for two reasons:

• If documentation is missing or inadequate, you may not be able to demonstrate your own compliance to supervisory authorities
• If you later modify the system substantially or deploy it in a purpose outside its documented intended use, you may become a provider under Art.3(3) — and inherit the Art.11 obligation yourself

What Annex IV documentation covers:

The Annex IV technical documentation package addresses eight core areas:

Deployer action: When entering a contract for a high-risk AI system, explicitly require contractual access to the Art.11/Annex IV documentation package. Confirm the documentation was current at the time of your deployment, and request updates whenever the provider makes a significant change to the system.

Layer 2: Instructions for Use (Art.13)

Article 13 requires providers to ensure high-risk AI systems are accompanied by instructions for use that enable deployers to implement the system correctly and comply with their own obligations.

The instructions for use are the primary information channel from provider to deployer. They must cover:

• The identity and contact details of the provider
• The AI system's capabilities, limitations, and performance levels
• The intended purpose and use cases for which the system has been validated
• The level of accuracy expected, and circumstances in which accuracy may decrease
• The data the system operates on and any specific input requirements
• Human oversight measures to be put in place (cross-referencing Art.14 requirements)
• Maintenance, security, and updating requirements
• Modifications that would require a new conformity assessment

What deployers must do with these instructions:

• Retain the instructions as part of your compliance documentation — not just follow them, but file them
• Update your own documentation when the provider updates the instructions
• Train your staff on the instructions (AI literacy obligations under Art.4)
• Do not deviate from the specified intended use; deviating converts you from deployer to provider under Art.3(3)

A common failure pattern: SaaS teams download a vendor's documentation at procurement time, file it once, and never update it. When a newer version of the AI system is deployed — with different performance characteristics — the documentation gap creates a compliance breach.

Layer 3: Deployer-Maintained Records

Beyond what you receive from providers, deployers of high-risk AI systems must create and maintain their own records. These fall into four categories.

3a. Operational Logs (Art.12 + Art.26(5))

Article 12 requires high-risk AI systems to technically allow for the automatic recording of events throughout their operation. Article 26(5) requires deployers to keep those logs to the extent that the logs are under their control.

What this means in practice:

• If your deployment infrastructure captures system logs, you are required to retain them
• If the provider controls the logging infrastructure but gives you log exports, request regular exports and archive them
• Logs must be sufficient to enable post-hoc review of the system's operation, including decisions taken and the data used to take them
• Log retention period: maintain logs for the full period during which the system is deployed, plus any additional period specified by applicable national regulation or sector-specific law

Implementation checklist:

• Verify your deployment logs include AI decision inputs and outputs, not just API call metadata
• Configure automated log archival to compliant storage (EU-hosted, GDPR-compliant)
• Document your log retention policy in writing
• Test log retrieval — many teams log everything but cannot actually reconstruct a specific decision from six months ago

3b. Fundamental Rights Impact Assessment (Art.27)

Article 27 requires certain deployers to conduct a Fundamental Rights Impact Assessment (FRIA) before putting a high-risk AI system into service. The obligation applies to:

• Bodies governed by public law
• Private bodies providing public services
• Private bodies deploying AI systems in Annex III categories that could affect fundamental rights (employment, credit, education, law enforcement support)

The FRIA documentation must cover:

1. A description of the deployer's processes and purpose
2. The geographic and temporal scope of the deployment
3. Assessment of the risk to fundamental rights (privacy, non-discrimination, freedom of expression, access to justice)
4. The categories of natural persons affected, including any vulnerable groups
5. Specific risks identified for each affected group
6. Mitigation measures planned or implemented
7. How the FRIA conclusions have been incorporated into the design of the deployment

Documentation requirements:

• The FRIA must be completed before the system is put into service
• It must be submitted to the relevant market surveillance authority on request
• It must be updated whenever the deployment scope or AI system changes materially

Note: If you are also required to conduct a Data Protection Impact Assessment (DPIA) under GDPR Art.35, you can run both assessments in parallel — the Art.13 information from your provider feeds directly into the DPIA. Art.26(7) explicitly links the two.

3c. Incident Records (Art.26(4) + Art.73)

Under Art.26(4), deployers must monitor AI system operation and document any serious incidents or malfunctions. Under Art.73, serious incidents — those resulting in death, serious harm to health, significant property damage, or fundamental rights violations — must be reported to the relevant national competent authority (NCA).

What documentation you need:

• An internal incident response procedure specifically covering AI system incidents
• A log of all anomalous events, including low-severity ones that do not trigger reporting thresholds
• A decision record for each event: was this a reportable incident? If not, why not?
• For reportable incidents: the notification to the NCA (with timestamps and delivery confirmation)

Art.73 reporting timeframes (confirmed): 2 days for AI systems used in critical infrastructure where the incident causes or risks immediate harm; 10 days where the incident involves death; 15 days for other serious incidents. These are maximum timeframes — file as soon as you have sufficient information.

3d. AI Literacy and Training Records (Art.4)

Article 4 requires both providers and deployers to take measures to ensure that staff responsible for operating high-risk AI systems have a sufficient level of AI literacy, tailored to their technical knowledge, experience, and context.

Your documentation obligation here is to be able to demonstrate compliance:

• Records of AI literacy training completed by staff who operate, monitor, or make decisions based on high-risk AI outputs
• Competency assessments or confirmations for staff assigned human oversight roles (Art.26(2))
• For oversight-role staff: documentation of their specific competencies in the domain where the AI operates (not just generic AI training)

Documentation You Do Not Need to Maintain (But Often Think You Do)

A common misconception: deployers often try to replicate the provider's Art.11/Annex IV documentation themselves — recreating training data lineage, model architecture, and validation methodology. You are not required to do this unless you have substantially modified the system.

Your documentation obligations are:

• Receive and retain the provider's Annex IV documentation and Art.13 instructions
• Maintain your own operational logs, FRIA (if applicable), incident records, and training records
• Verify that provider documentation is current — not recreate it

Attempting to maintain the provider's documentation yourself without access to the underlying model and training data creates a false documentation set that can look worse to an auditor than a simple reference to the provider's package.

How Long Must Documentation Be Retained?

The EU AI Act sets retention floors — your sector-specific regulation may require longer periods:

The 10-year floor derives from Art.18, which requires providers to keep technical documentation and conformity declarations for 10 years after the AI system is placed on the market. Deployers should match this floor for documents received from providers to avoid gaps in an audit.

When Documentation Obligations Shift: Deployer Becomes Provider

The documentation landscape changes completely if you cross from deployer into provider territory. This happens when:

1. You substantially modify the high-risk AI system (Art.3(23) defines substantial modification as changes that affect the system's conformity or change its intended purpose)
2. You place the system on the market under your own name or trademark
3. You change the AI system's intended purpose such that it now falls into a new high-risk category under Annex III

When this shift occurs, you must:

• Draw up your own Art.11/Annex IV technical documentation
• Conduct your own conformity assessment (Art.43 — covered in Post #2 of this series)
• Register the system in the EU AI database (Art.49)
• Affix the CE marking

Practical rule: if your engineering team trains a fine-tuned model on top of a third-party foundation model, or builds a custom pipeline that changes how the original model's outputs are used in high-stakes decisions, get a legal review of whether you have crossed the substantial modification threshold.

30-Item Documentation Checklist for Deployers

Receiving and verifying provider documentation:

• 1. Confirmed provider has drawn up Art.11 / Annex IV technical documentation
• 2. Obtained a copy of or contractual access to the Annex IV documentation
• 3. Verified documentation was current at deployment start date
• 4. Received Art.13 instructions for use in written form
• 5. Confirmed instructions for use address all eight required elements
• 6. Stored documentation in a retrievable, access-controlled location
• 7. Established process to receive updated documentation when provider releases new version
• 8. Confirmed provider has issued an EU Declaration of Conformity (Art.47)

Operational logs:

• 9. Verified system technically allows for automatic logging (Art.12)
• 10. Confirmed deployment logs capture AI decision inputs and outputs
• 11. Tested log retrieval for a past date (confirm you can reconstruct specific decisions)
• 12. Documented log retention policy in writing
• 13. Logs stored on EU-hosted, GDPR-compliant infrastructure
• 14. Defined who is responsible for monitoring log completeness

Fundamental rights impact assessment:

• 15. Determined whether your deployment triggers Art.27 FRIA requirement
• 16. If yes: completed FRIA before putting system into service
• 17. FRIA covers all eight required elements (deployer processes, scope, rights assessment, affected persons, risks, mitigations, integration into deployment)
• 18. FRIA updated whenever deployment scope or AI system changes materially
• 19. Combined FRIA with DPIA where GDPR Art.35 also applies

Incident records:

• 20. Documented internal AI incident response procedure
• 21. Internal log exists for all anomalous AI system events
• 22. Decision record for each event: reportable or not, with reasoning
• 23. Confirmed Art.73 reporting timeframes (2/10/15 days depending on severity)
• 24. Know which national competent authority to report to
• 25. Test-drilled at least one incident response scenario

AI literacy and human oversight:

• 26. Documented which staff roles have human oversight responsibility (Art.26(2))
• 27. AI literacy training records exist for all oversight-role staff (Art.4)
• 28. Oversight-role staff have domain-specific competency documentation, not just generic AI training
• 29. Training records updated when oversight staff changes

Provider / deployer boundary:

• 30. Obtained legal review if any fine-tuning, custom pipeline, or rebranding is involved — confirmed whether Art.3(23) substantial modification applies and whether you have become a provider

Connecting to the Rest of the Deployer Sprint

This post covers the documentation foundation. The remaining posts in this series address:

• Post #4 (Art.14): Human oversight implementation — who you assign, what authority they need, how to document override decisions
• Post #5 (Finale): The complete August 2026 readiness checklist — combining all five posts into a single pre-deadline audit

If you are deploying high-risk AI in your SaaS platform and want infrastructure that makes compliance documentation easier — EU-hosted, no CLOUD Act exposure, fully auditable — sota.io is purpose-built for exactly this.

Post #3 of 5 in the EU AI Act Deployer Sprint 2026 series. August 2, 2026 is the enforcement date for deployer obligations under the EU AI Act.