Technical Documentation and the Evidence Trail

Most of the AI Act's obligations are, in operational terms, documentation obligations. Not because the drafters valued paperwork, but because the substantive requirements, accuracy, robustness, data governance, human oversight, are not observable from outside a system. The only way a national authority can assess them is through a record of what you did.

This has an unwelcome implication and a useful one.

The unwelcome one: work done and not recorded counts for nothing. A team that carefully evaluated a model for performance disparities and wrote no record has, from a regulator's position, not done it.

The useful one: the documentation is a genuine artefact of the engineering, not a parallel exercise. Every item Annex IV requires is something a competent team would want anyway. Organisations that experience it as bureaucratic overhead are usually generating it retrospectively, which is both painful and less accurate than generating it as they go.

The design goal for this layer is therefore to make the record a byproduct of the work, which is the same principle the write path of a company brain runs on.

Article 11 requires providers of high-risk systems to draw up technical documentation before the system is placed on the market or put into service, and to keep it up to date. Its contents are specified in Annex IV, in nine parts.

A general description of the system: intended purpose, provider, versions, how it interacts with hardware or other software, and the form in which it is placed on the market.

A detailed description of the elements and the development process: design specifications, system architecture, computational resources, data requirements and the data sets used, human oversight measures, and the validation and testing procedures with the metrics used.

Detailed information about monitoring, functioning and control, including the system's capabilities and limitations, its expected accuracy, and foreseeable unintended outcomes.

The performance metrics and their appropriateness.

A description of the risk management system.

A record of changes made through the lifecycle.

The harmonised standards applied, or a description of the solutions adopted where none were.

The EU declaration of conformity.

And the post-market monitoring plan.

Read as a list, it is intimidating. Read as a description, it is what any team should be able to say about a system it put into production.

The documentation burden is where the 2026 Digital Omnibus did most of its work for smaller organisations, and the relief is real.

The Act already provided a simplified technical documentation form for microenterprises. The Omnibus extended the lighter regime considerably: the simplified quality management system route, previously microenterprise-only, now covers all SMEs including start-ups.

And the new small mid-cap category, organisations with fewer than 750 employees and under 150 million euros in annual turnover, gains simplified technical documentation for high-risk systems along with lighter quality management requirements. That category did not previously exist, and it captures a substantial band of mid-sized European businesses that had been facing the full provider regime.

Two things the simplification does not do, and both are frequently misread.

It does not reduce the substantive requirements. A high-risk system built by a small mid-cap must still meet the accuracy, robustness, data governance and oversight requirements. What is lighter is how much documentary apparatus surrounds the demonstration.

And it does not touch deployer obligations at all, which were never scaled by organisation size.

Article 17 requires providers of high-risk systems to put a quality management system in place, documented through written policies, procedures and instructions.

It covers a wide span: a strategy for regulatory compliance, techniques for design and development, testing and validation procedures, technical specifications and standards applied, systems for data management, the risk management system, post-market monitoring, incident reporting, communication with authorities, record-keeping, and an accountability framework setting out responsibilities of management and staff.

For an organisation with an ISO 9001 quality system or an ISO/IEC 27001 information security management system, much of the scaffolding exists and the work is extension rather than creation. For one with neither, this is the single largest obligation in the Act and the main reason the deadline moved to December 2027.

The practical judgement: a quality management system is a provider obligation. If your organisation is a deployer of purchased systems, you do not need one, and a vendor implying otherwise is selling you something. Establish your role first, which is exactly what the first lesson's inventory does, before committing to this scale of work.

The documents flow along the supply chain, and most confusion comes from expecting the wrong party to hold a given artefact.

The provider produces the technical documentation, maintains the quality management system, carries out the conformity assessment, issues the EU declaration of conformity, applies the CE marking, registers the system in the EU database, and writes the instructions for use.

The instructions for use are the handoff. They travel to the deployer and carry the information the deployer needs to operate the system lawfully.

The deployer produces its own, much smaller, set: records of human oversight arrangements, retained logs, a fundamental rights impact assessment where required, and its own governance records.

Both sides feed post-market monitoring, since the deployer sees the system in real use and the provider is obliged to act on what that reveals.

Article 13 makes high-risk systems subject to a transparency requirement toward the deployer, and the instructions for use are the instrument.

They must be concise, complete, correct and clear, and must include the provider's identity and contact details; the system's characteristics, capabilities and limitations of performance, including its intended purpose, its accuracy, robustness and cybersecurity levels, and the circumstances that may lead to risks to health, safety or fundamental rights; any known or foreseeable circumstance that may lead to such risks; where applicable, the technical capabilities to provide information relevant to explaining output; the system's performance regarding specific persons or groups it is intended to be used on; specifications for input data; the human oversight measures, including the technical measures put in place to facilitate interpretation of output; the expected lifetime and necessary maintenance; and a description of the logging mechanisms.

For a deployer, this document is the most valuable thing in the relationship, because nearly every deployer obligation depends on information only the provider holds.

The practical instruction is therefore simple: ask for the instructions for use during procurement, not after signing. A provider unable to produce them for a high-risk system is either not treating it as high-risk, which is a question worth asking, or is not ready to place it on the market.

High-risk systems must be designed with automatic recording of events over their lifetime, which the Act calls logging capability, so that operation can be traced and post-market monitoring is possible.

On the deployer side, Article 26 requires keeping the logs automatically generated by the high-risk system, to the extent they are under the deployer's control, for a period appropriate to the intended purpose and in any case at least six months, unless other Union or national law provides otherwise, in particular data protection law.

Three practical points follow.

To the extent they are under your control is doing real work. Where a provider hosts the system, the logs may not be yours, which is a contractual question to settle before deployment rather than during an incident.

At least six months is a floor, not a target. For a system making decisions people can challenge later, retention should match the period in which a challenge is realistically possible, which is often longer.

And the data protection carve-out is a genuine tension, not a formality. Logs of decisions about individuals are personal data, so retention has to be reconciled with minimisation and storage limitation. Decide the period deliberately, record the reasoning, and make sure the same reasoning appears in both your AI and data protection records rather than in two documents that disagree.

Article 27 introduces an obligation that falls on deployers rather than providers, and its scope is narrower than commonly assumed.

It applies, before deploying a high-risk system, to deployers that are bodies governed by public law, to private entities providing public services, and to deployers of the high-risk systems in points 5(b) and 5(c) of Annex III, which cover creditworthiness evaluation and credit scoring, and risk assessment and pricing in life and health insurance.

So a private manufacturer deploying a high-risk system in its own operations is generally outside it. A bank deploying a credit-scoring system, an insurer pricing health cover, and any body providing public services are inside it.

The assessment covers the deployer's processes in which the system will be used, the period and frequency of intended use, the categories of persons likely to be affected, the specific risks of harm to those persons, the human oversight measures, and the measures to take if the risks materialise, including internal governance and complaint mechanisms.

It is required for the first use and must be updated if the relevant elements change. Where a data protection impact assessment already exists, the fundamental rights assessment complements it rather than duplicating it, which is the main reason to run the two exercises together rather than sequentially.

The Act establishes an EU database for high-risk AI systems, and registration is a public act rather than a filing with a supervisor.

Providers of Annex III high-risk systems register the system in the database before placing it on the market or putting it into service. Public authority deployers of such systems also register their use.

The part most often missed: a provider that concludes an Annex III system is not high-risk in reliance on the Article 6(3) derogation is still subject to registration. The derogation relieves you of the high-risk requirements. It does not make the system invisible, and the documented assessment must be produced to national authorities on request.

That design is deliberate. It means a claim that a listed system falls outside the regime is made on the record rather than internally, which is a considerably stronger discipline than a private judgement filed in a drawer.

For an organisation planning to rely on the derogation for a recruitment or credit tool, the practical implication is worth absorbing early: the reasoning will be visible, so it should be reasoning you are willing to have read by someone who disagrees.

The difference between organisations that find this manageable and those that find it crushing is almost entirely when the documentation is created.

Generate at the moment, not at the audit. Model evaluation results are written when the evaluation runs. Data set descriptions are written when the data is assembled. Design decisions are recorded when they are made, in the form of a decision record, which is exactly the practice covered in the company brain cursus and for exactly the same reason.

Keep it where the work is. Documentation in the repository next to the code stays closer to true than documentation in a separate compliance system, because the people who change the system are the people who see it.

Version it with the system. Annex IV requires a record of changes through the lifecycle, which is a description of version control, not an additional artefact.

Write the reasoning, not only the conclusion. Every judgement in this cursus, the classification, the derogation, the retention period, the accepted risk, is defensible only through the reasoning behind it.

And assign the documentation to whoever did the work. Documentation written by a compliance function from interviews is slower to produce, less accurate, and stale on arrival.

Done this way, the evidence trail is a description of how the organisation works. Done retrospectively, it is a reconstruction, and reconstructions are where inaccuracies enter.