Providers of high-risk AI systems must draw up technical documentation before market placement and keep it current (Article 11), and run a documented post-market monitoring system based on a written plan (Article 72). Together they create a living record from design to field performance.
Technical documentation under Article 11
Documentation must be drawn up before the system is placed on the market or put into service and kept up to date. It must show compliance with the Chapter III Section 2 requirements and give authorities and notified bodies the information to assess it. It contains at least the elements of Annex IV, which we did not review, so read that annex for the list.
Two relief points:
- SMEs, including start-ups, and small mid-cap companies can provide Annex IV elements in a simplified form to be set by the Commission, which notified bodies must accept.
- For products under Annex I Section A laws, a single set of documentation covers both this article and the product law.
Post-market monitoring under Article 72
Providers must establish and document a monitoring system proportionate to the technology and risks. It should:
- Collect, record and analyse relevant performance data throughout the system's lifetime, from deployers or other sources.
- Allow the provider to evaluate continuous compliance with the high-risk requirements, including interaction with other AI systems where relevant.
- Follow a post-market monitoring plan that forms part of the Annex IV documentation.
The Commission is to issue a template and guidance for the plan. The page we read shows two different dates for this, so check the official text. Providers under certain product or financial services rules may fold monitoring into existing systems if protection is equivalent.
How the two connect
The plan is part of the documentation, and the monitoring data tells you when the documentation is out of date. A model update, new data source or changed use belongs in both.
A working structure
Keep a documentation set with a version per release:
- Purpose, intended use and unsupported uses.
- Architecture, data sources and quality checks.
- Testing methods, metrics and results.
- Risk management outputs.
- Oversight design.
- Monitoring plan: metrics, sources, thresholds, review cadence, escalation.
- Change log with who approved what.
Automate collection where possible, such as pulling test results and dependency inventories into the record, rather than writing them by hand after the fact.
Common mistakes
- Writing documentation once at launch.
- Monitoring uptime but not output quality.
- No feedback path from deployers.
- Thresholds with no owner.
Assign one owner for the documentation set and one for the monitoring plan, even if they are the same person in a small company. Put review dates in a calendar, tie them to release events and make a release impossible to close without the update. Documentation that lives in the delivery process stays current.
Quick check
Is the monitoring plan separate from the documentation?
No. Article 72 says the plan forms part of the technical documentation under Annex IV.
Can small companies simplify the documentation?
SMEs, start-ups and small mid-caps may use a simplified form to be established by the Commission.
Sources
- AI Act Article 11, technical documentation
- AI Act Article 72, post-market monitoring (an unofficial reader; confirm wording against the Official Journal)
Last reviewed: 19 October 2026.
