by AIActRadar (LX AI)

Last updated: 2026-09-16

Technical documentation under the AI Act

Under Regulation (EU) 2024/1689, high-risk providers must keep technical documentation that shows conformity before market placement. Teams often assemble the obvious pieces and miss what auditors open first: dataset summaries, human-oversight design, and post-market monitoring. Treat any generated outline as a draft to verify against the Official Journal, not a finished filing.

What the documentation obligation actually covers

Article 11 and Annex IV set the documentation content for high-risk systems. The package spans intended purpose, design choices, development and testing history, performance claims, and the risk-management measures you actually ran. The Commission summarizes the Act as a risk-based framework with heavier duties for high-risk uses; start from that framing before you invent a custom template (European Commission — AI Act).

The binding text is the regulation itself on EUR-Lex (Regulation (EU) 2024/1689). Secondary blogs and slide decks are useful only after you can point to the article and annex row that supports each claim. I treat documentation as a living file set under version control, not a one-time PDF exported the week before a demo.

Lifecycle, not a freeze-frame

If the model changes, the training set is refreshed, or a safety control is rewired, the documentation must show the delta. Change notes, owners, and dates matter as much as the first write-up. When a deployer asks "which build was in production on Tuesday?", you should answer from the same record that supports conformity — not from a Slack thread.

Step-by-step workflow we use before calling a pack "ready"

1. Confirm the system is high-risk (or will be treated as such) under Article 6 / Annex III before you invent a documentation tree. If it is not high-risk, do not over-claim Annex IV completeness in sales copy.
2. Open Annex IV and create one folder or ticket per theme: general description, design specs, development process, data, risk management, testing, monitoring, and human oversight.
3. Assign a single owner per theme. Shared ownership without a name is how sections stay empty.
4. Draft with product and engineering in the room. Legal reviews claims; engineers supply evidence paths (configs, dashboards, test reports).
5. Link each claim to an artifact: a dataset summary, a logging schema, a runbook, a risk register row. Unlinked prose is a smell.
6. Walk the pack against the live system: does the logging configuration match Article 12 claims? Does the override path in the UI match Article 14 text?
7. Schedule a refresh trigger: model version bump, material dataset change, new deployer class, or serious-incident near miss.

AIActRadar turns these themes into a working checklist. It does not replace notified-body judgment or counsel. Use the product to catch omissions early; use the Official Journal to settle arguments.

Dataset summaries teams skip (Article 10)

Article 10 expects data governance: training, validation, and testing data should be relevant and representative for the intended purpose, with examination for bias and gaps that would hurt performance for people the system will affect. Auditors look for a summary of what data was used and how it was examined — not a marketing model card with three adjectives.

A checklist row that says "data reviewed" with no summary behind it fails the first serious review. Write the summary so a new engineer can answer: source domains, time windows, known skews, exclusion rules, and how labels were produced or audited. If personal data sits in the pipeline, keep your GDPR roles and bases consistent with how you describe processing elsewhere; the EDPB guidance library is the practical cross-check for that language (EDPB guidelines and best practices).

Checklist — data evidence

• Inventory of training / validation / test sets with ownership and last refresh date
• Representativeness notes tied to the intended purpose (who is in scope, who is out)
• Bias and error examination method — even if imperfect — with residual risk stated
• Labeling or annotation process, including quality controls
• Retention and access rules for the datasets themselves

Human-oversight design (Article 14)

Article 14 asks for meaningful human oversight: interfaces and controls that let a person monitor, interpret, and override outputs when needed. "Humans stay in the loop" is not a mechanism. Document the specific override path, who may exercise it, how the system signals that a human should intervene, and what happens when the human is unavailable.

In agent products, this often means a hard stop before a consequential action (hire shortlist publish, credit decision send, case file update), not a decorative approve button that auto-fires after three seconds. Pair the UI description with the runtime policy: which roles, which environments, which audit events fire when override is used.

Checklist — oversight evidence

• Named oversight roles and escalation path
• UI or API controls that actually pause or reverse the AI action
• Signals / thresholds that call for human review
• Training or runbook for the people who oversee
• Evidence that override events are logged

Post-market monitoring and logging (Articles 12 and 72)

Article 12 requires automatic logging sufficient for traceability, with a minimum retention of six months for high-risk systems. Article 72 adds serious-incident reporting duties. Teams document the model and forget the runtime evidence plan. Pair the documentation with the actual logging configuration so the two agree.

If you already run GenAI observability, map spans and events to the questions a post-market review will ask: which input class, which model version, which policy decision, which human action. OpenTelemetry's GenAI conventions are a practical engineering reference for naming those fields consistently across services (OpenTelemetry — GenAI observability). The Act does not mandate OTel; consistent traces just make Article 12 claims easier to defend.

Theme	Article / annex hook	Common miss	Evidence that lands
General description & purpose	Art. 11 / Annex IV	Marketing pitch instead of intended purpose	Purpose statement + out-of-scope uses
Data governance	Art. 10	"Dataset reviewed" with no summary	Dataset inventory + bias exam notes
Risk management	Art. 9	Static risk PDF from last year	Living register with owners and residual risk
Logging	Art. 12	Logs claimed but retention < 6 months	Schema + retention config screenshot/export
Human oversight	Art. 14	Slogan without override path	UI/runbook + role matrix
Post-market / incidents	Art. 72	No serious-incident playbook	Trigger definitions + reporting contacts

Common mistakes we see in documentation packs

• Writing for the brochure, not the annex. Pretty diagrams that never cite Annex IV themes waste review time.
• Copying a US RMF worksheet and renaming it "AI Act pack." NIST's AI Risk Management Framework is useful for process vocabulary (NIST AI RMF), but it is not a substitute for Article 11 / Annex IV content.
• Documenting yesterday's model. Production already moved; the pack did not.
• Leaving deployer instructions empty. Article 13 transparency to deployers is easy to skip when the provider team only talks to itself.
• Calling a checklist "certified." That language overclaims. Checklists reduce omission risk; they do not certify conformity.

Decision criteria: ship the pack vs keep drafting

Treat the pack as release-blocking for a high-risk launch when any of these are true:

• No dataset summary that a third party can follow
• No described human-oversight mechanism tied to a real control
• Logging retention under six months, or logs that cannot reconstruct a decision
• Risk register with no residual-risk owners
• Intended purpose so vague that Annex III mapping is impossible

You can still ship internal prototypes that never touch EU high-risk use. Be honest about the scope in writing. Ambiguous "we comply in spirit" language is worse than a clear "not yet high-risk / not yet on the EU market" status.

What this is NOT

This page is not legal advice, not a notified-body assessment, and not a guarantee that your system conforms to Regulation (EU) 2024/1689. AIActRadar does not claim 100% coverage, does not invent customer win rates, and does not replace counsel or a conformity assessment where one is required. A checklist helps you assemble and verify themes; the binding duty remains the documentation described in Article 11 and Annex IV, owned by qualified people in your organization.

Closing

Start with the Official Journal text, map Annex IV themes to owners, then fill the three gaps auditors open first: data, oversight, and logging. Keep the pack versioned with the system. When the model or the dataset moves, move the documentation in the same release train. For the risk-tier decision that sits upstream of all of this, read our sister primer on EU AI Act risk tiers.

References

• Regulation (EU) 2024/1689 (EUR-Lex)
• European Commission — AI Act
• EU AI Act — Implementation Timeline
• NIST AI Risk Management Framework
• EDPB — GDPR guidelines and best practices
• OpenTelemetry — GenAI observability

FAQ

Which article sets the technical documentation requirement?

Article 11 of Regulation (EU) 2024/1689, with the detailed content listed in Annex IV. It applies to high-risk systems and must be ready before market placement.

How long must high-risk AI logs be kept?

Article 12 requires automatic logging with a minimum retention of six months for high-risk systems. The retention supports traceability and post-market monitoring.

Does a checklist satisfy the documentation obligation?

No. A checklist helps you assemble and verify the required themes, but the binding duty is the documentation described in Article 11 and Annex IV, reviewed against the regulation by qualified owners.

What do teams most often omit?

Dataset summaries under Article 10, a described human-oversight mechanism under Article 14, and a runtime logging plan under Article 12. These are the sections auditors open first.

Try the product: AIActRadar

2026-09-16 · primary sources only · no fabricated traffic metrics