When Technical Documentation Applies and What to Do Next

Technical documentation applies as a specific EU AI Act obligation when a company is the provider of a high-risk AI system. Article 11 requires the provider to prepare the documentation before placing that system on the market or putting it into service, keep it up to date, and make it clear enough for authorities and notified bodies to assess compliance. Annex IV defines the minimum content.

That does not mean every SaaS company using an AI API needs a full Annex IV file. The answer depends on three connected questions: what the AI system is, which role the company performs, and whether the system is high-risk. A team should document those decisions before it starts filling a template. If the legal duty does apply, the practical response is to build a controlled evidence index connected to the released system—not a one-off report assembled for an audit.

Even where Article 11 does not apply directly, a proportionate technical record can still support product governance, vendor review, customer assurance, incident response, and later reassessment. The important distinction is to label voluntary governance records accurately rather than presenting them as proof of a legal obligation that has not been established.

Start with the system boundary, role, and classification

A useful scope decision begins with the system, not the model. Describe the intended purpose, users, affected people, inputs, outputs, integrations, user interface, deployment context, and the way the output influences a decision or workflow. A third-party model may be only one component of a larger SaaS system. Conversely, several product features may form one system if they operate together for a shared intended purpose.

Next, determine the company's role. A business that develops a high-risk AI system and markets it under its own name is generally acting as a provider. A customer using another provider's system may be a deployer. Importers, distributors, product manufacturers, and authorised representatives have separate roles. Rebranding a system, making a substantial modification, or changing its intended purpose can shift provider responsibilities, so procurement labels alone are not conclusive.

Finally, assess high-risk classification. Article 6 provides two principal routes: systems connected to regulated products listed in Annex I, and use cases listed in Annex III. An employment-screening feature, for example, may raise Annex III questions that a writing assistant for internal marketing does not. Classification must be tied to the actual intended purpose and deployment, including any exclusions or conditions on which the conclusion relies.

For a broader overview, see what SaaS providers need to know about the EU AI Act. Teams buying AI tools should also use a structured review of what compliance teams should ask before adoption.

When Article 11 applies

Under the AI Act, Article 11 and Annex IV apply to the technical documentation of high-risk AI systems. The provider bears the core obligation. The file must demonstrate how the system meets the applicable requirements in Chapter III, Section 2, and give competent authorities and notified bodies the information needed for assessment.

Timing follows the current phased application schedule. Following Regulation (EU) 2026/1744, the high-risk rules for Annex III systems apply from 2 December 2027, while the corresponding rules for high-risk systems embedded in Annex I regulated products apply from 2 August 2028. The European Commission's implementation overview reflects those dates.

The dates are not a reason to postpone evidence design. A team may already need similar records because of product-sector law, data-protection duties, security controls, contracts, customer questionnaires, insurance, or internal release criteria. Starting early also avoids reconstructing model versions, datasets, tests, and risk decisions after the people or tools that produced them have changed.

Do not confuse this obligation with the separate documentation duties for providers of general-purpose AI models. A SaaS business integrating a third-party general-purpose model may need information from its supplier, but the classification and documentation of the complete downstream system remain separate questions.

When a full Annex IV file may not be required

A full Article 11 file may not be the applicable legal deliverable where the system is not high-risk, the company is only a deployer, or the activity falls outside the AI Act's scope. That conclusion should still be recorded. A short decision note should identify the system and version, the facts considered, the role analysis, classification route, reviewer, date, and triggers for reassessment.

Reassessment triggers include a new intended purpose, expansion into a sensitive use case, a material model or data change, rebranding, a different customer workflow, a new geography, or a change in how outputs influence people. A low-risk conclusion for an internal summarisation tool should not silently carry over when the same technology is configured to rank applicants or determine access to an essential service.

Voluntary documentation should be proportionate. A low-risk feature may need a concise system card, vendor record, test summary, data-flow diagram, risk decision, and monitoring owner rather than a full conformity file. The goal is enough traceability to support the real risk and the claims the company makes.

What the documentation must cover

Annex IV is a minimum coverage map. In operational terms, it asks the provider to connect nine areas:

1. System identity and intended purpose: provider, versions, intended users, forms of delivery, interfaces, dependencies, and operating conditions.
2. Development and design: methods, third-party contributions, model or component choices, design assumptions, and material development decisions.
3. Architecture and data: component relationships, computational resources, and relevant training, validation, testing, or retrieval data and their provenance.
4. Capabilities and limitations: performance metrics, expected accuracy, robustness, cybersecurity, foreseeable unintended outcomes, and conditions in which performance may degrade.
5. Testing and validation: datasets, methods, thresholds, results, failures, corrective actions, dates, versions, and accountable reviewers.
6. Risk and human oversight: identified risks, controls, residual-risk decisions, oversight design, user information, override paths, and escalation rules.
7. Lifecycle controls: logging, versioning, change management, maintenance, incidents, and post-market monitoring.
8. Standards and conformity: applicable standards or technical specifications, the conformity route, declaration of conformity, and notified-body material where required.
9. Traceability: a clear link from each claim to the controlled artifact that supports it.

The file can be an index that points to controlled records. It does not have to duplicate every architecture diagram, test run, risk entry, and ticket into a single document. Stable references, permissions, version history, and preservation matter more than page count.

What to do next: a practical workflow

1. Approve a scope record

Give the system a stable identifier. Record its intended purpose, system boundary, versions, company role, classification, deployment contexts, and responsible reviewer. State assumptions and exclusions plainly. If the conclusion is not yet final, record the open question, interim control, owner, and decision deadline.

2. Create an Annex IV coverage index

Use one row for each applicable requirement. Include the source artifact, evidence owner, system version, status, reviewer, last review date, and update trigger. A “not applicable” entry needs a rationale. This index is the navigation layer that lets an independent reviewer follow the evidence.

3. Collect evidence from its real owners

Product should own intended purpose and user workflow; engineering should own architecture, dependencies, versions, and release facts; data or ML teams should own datasets, evaluations, and performance limits; security should own resilience and cybersecurity evidence; legal and compliance should own regulatory mapping and coordinate challenge. One documentation owner can manage the file, but should not invent technical conclusions on behalf of other teams.

4. Close the highest-risk gaps first

Prioritise gaps that undermine system classification, intended-purpose clarity, safety or fundamental-rights protection, performance claims, human oversight, or release approval. Avoid measuring completeness by the number of documents. A concise, verified limitation is stronger than a long unsupported assurance.

5. Tie updates to product change

Add a documentation-impact check to release management. Changes to intended purpose, models, prompts, retrieval sources, datasets, thresholds, users, integrations, oversight, security controls, or monitoring may require targeted updates and retesting. Preserve which sections changed and which were reviewed but remained valid.

6. Test retrieval before a deadline

Sample one performance claim, one risk control, one human-oversight path, and one material release. Ask a reviewer outside the authoring team to locate the supporting evidence and confirm that versions agree. This reveals broken permissions, stale diagrams, missing approvals, and unexplained claims before a regulator, notified body, or customer finds them.

The companion technical documentation checklist provides a detailed review structure. Teams can also examine the controls buyers increasingly ask about so customer responses remain consistent with the technical file.

Common mistakes

Starting with a generic template. A template can organise information, but it cannot establish the system boundary, role, classification, or evidence. Begin with facts and map them to the requirement.

Documenting only the foundation model. The relevant system includes configuration, data flows, integrations, user interaction, controls, and the context in which outputs are used.

Assuming vendor documentation transfers responsibility. Supplier records are inputs. They do not prove how a SaaS team configured, evaluated, monitored, or constrained its own product.

Treating a non-high-risk conclusion as permanent. Intended purpose, customers, integrations, and product behaviour change. Define event-based review triggers.

Keeping an audit-only file. Documentation that does not participate in release and change management becomes stale. The released version and the documented version must remain aligned.

Example: an AI-assisted recruitment feature

Suppose a SaaS provider offers a feature that ranks job applications for customer recruiters. The team should first define whether the ranking feature is an AI system, its intended purpose, the legal entity marketing it, and the Annex III classification analysis. If the company is the provider of a high-risk system, the technical file should exist before the applicable market-placement or service-entry milestone.

The file would identify the production model and software versions, input data, customer workflow, evaluation groups, metrics, thresholds, limitations, human-review controls, logging, security measures, risk decisions, and monitoring. If a later release changes the model or ranking threshold, the release workflow should reopen connected performance, discrimination-risk, oversight, instruction, and monitoring records. That trace demonstrates that the documentation describes the system actually in use.

FAQ

What is the practical purpose of technical documentation?

It gives internal and external reviewers a traceable account of what an AI system is, how it was developed and evaluated, which risks and controls apply, and why the provider considers it compliant. Operationally, it also keeps product, engineering, legal, security, and customer statements aligned.

When does technical documentation apply to SaaS teams?

Article 11 applies to providers of high-risk AI systems. A SaaS company may instead be a deployer, or its system may not be high-risk. Confirm the system boundary, role, and classification before deciding that a full Annex IV file is legally required.

What should a team document first?

Start with intended purpose, system boundary, role, classification, production version, architecture, material risks, evaluations, controls, instructions, and named owners. Then build the Annex IV coverage index and close the gaps that could block a defensible release.

Can existing engineering records be reused?

Yes. Reuse controlled and current records rather than copying them into a parallel compliance archive. The coverage index should show which artifact supports each requirement and which system version it covers.

Who owns the documentation?

Assign one accountable coordinator, but keep evidence ownership with the teams that produce and can verify the facts. Product, engineering, data or ML, security, legal, and compliance each have distinct responsibilities.

Sources

• Regulation (EU) 2024/1689, especially Articles 6 and 11 and Annexes I, III, and IV.
• Regulation (EU) 2026/1744, including the amended technical-documentation provisions and high-risk application dates.
• European Commission, “AI Act,” for the current implementation timeline.