On 2 August 2026, the EU AI Act’s main enforcement phase begins. For organisations developing or deploying AI systems in the European market, documentation is a legal requirement.
Here’s what it might mean to your workload.
Does it apply to you?
The Act applies to both providers and deployers
Providers are organisations that build AI systems and place them on the EU market under their own name. If your organisation makes software with AI features used by European customers, you’re a provider.
Deployers are organisations that use AI systems in the course of their work. If you use an AI-powered tool (a recruitment system, a customer service chatbot, a document review tool) in your internal processes, you may be a deployer.
Both roles carry documentation obligations.
A risk-based approach
The legislation dictates a sliding scale of obligations depending on the potential risk an AI application poses to human safety and fundamental rights.
Unacceptable risk (Banned)
Systems that threaten human safety or rights are strictly prohibited.
High risk
Systems used in critical infrastructure, healthcare, education, law enforcement, or HR (such as automated CV-scanning) require rigorous risk assessments, high-quality data governance, documentation, and continuous human oversight.
Limited/Transparency risk
AI systems interacting directly with humans (e.g., chatbots) or generating synthetic media (deepfakes) must clearly disclose that the content or interaction is AI-generated.
Minimal risk
The vast majority of AI systems (such as spam filters or AI-enabled video games) fall here and remain largely unregulated, with no mandatory compliance requirements.
Deadlines
The Digital Omnibus on AI is a European Union legislative package that amends and simplifies the EU AI Act. The Omnibus delays several high-risk compliance timelines to give businesses and developers more time to adapt.
Deadlines for stand-alone Annex III systems (such as HR or education AI tools) have been deferred to December 2, 2027, while embedded product software under Annex I moves to August 2, 2028.
This documentation must be drawn up before the system is placed on the market or put into service, and kept up to date throughout its lifetime. It must be retained for ten years after the system is placed on the market.
What documents are required?
For high-risk systems, the Act specifies nine categories of technical documentation under Annex IV. As a technical writer, these will look familiar, but the framing is new:
- A general description of the system
- What it does, its intended purpose, what hardware it runs on, how it interacts with other systems
- A detailed account of the development process
- Design specifications, data governance, training data origin, labelling procedures, and testing methods
- Monitoring, control, and human oversight mechanisms
- Who can override the system, and how
- Performance metrics and how they were validated
- A risk management log, covering known risks, mitigations, and residual risks.
- This must be maintained continuously.
- A record of changes throughout the system’s lifecycle, including any modifications that may affect compliance
- An EU Declaration of Conformity
- A aftermarket monitoring plan
The three most common gaps
According to Ferndesk, there are three common areas where documentation teams most often find they’re starting from scratch.
Data provenance
The Act requires detailed documentation of training data origin, selection criteria, labelling procedures, and cleaning methods.
Living documentation
Several sections explicitly require ongoing maintenance. Treating documentation as a one-time deliverable is a compliance risk. A static PDF from six months ago is unlikely to be compliant.
Evidence, not assertion
Regulators look for verifiable information: actual test results that influenced design decisions, genuine risk assessments, real audit logs. Assertions without evidence will not pass conformity assessment.
It preserves design decisions that might otherwise exist only in individual team members’ heads, provides a baseline against which to evaluate whether system modifications are substantial enough to require a new conformity assessment, and enables faster root-cause analysis when issues arise in production.
What this means for technical writers
The documentation has to exist. Someone has to write it well. For technical writers who want to make the case for their value in organisations developing AI products, the EU AI Act is a strong argument.
Leave a Reply