EU AI Act: Turning evidence obligations into a release artefact

Editorial update, 19 September 2026: This article was first published on 25 January 2026. We withdrew it after the Digital Omnibus on AI changed the application dates for high-risk AI systems. This revision replaces the old timeline, corrects an outdated monitoring-template claim, and distinguishes our Assurance Pack approach from the Act’s legal requirements. Check the European Commission’s current timeline and the consolidated regulation before making a compliance decision.

The original article, as published on 25 January 2026, is preserved as a historical record with a superseded-content notice.

Information, not legal advice: The obligations that apply depend on the system, its intended use, the organisation’s role, and the relevant dates and transitional provisions. Seek qualified legal advice for a specific system.

The release question

When a team updates an AI system, what evidence explains the change and the decision to deploy it? A model version, evaluation report, risk note, and monitoring dashboard might all exist, yet remain difficult to connect. The question becomes harder when a customer, reviewer, or regulator asks what was known about a particular release.

For AI systems within its scope, the EU AI Act makes parts of that evidence discipline legally important. In particular, the Act sets requirements for technical documentation, record-keeping capability, and post-market monitoring for applicable high-risk AI systems. An Assurance Pack organises the relevant evidence around a specific release. It does not replace the legal documentation, conformity assessment, or other duties that may apply.

The current timetable

The Act entered into force on 1 August 2024, but its provisions apply in stages. The Commission’s implementation timeline incorporates the Digital Omnibus on AI amendments:

Date	Main milestone
2 February 2025	General provisions, AI literacy, and initial prohibited practices began to apply.
2 August 2025	General-purpose AI model rules and governance provisions began to apply.
2 August 2026	Most remaining rules began to apply, including the transparency rules in Article 50; enforcement began for provisions already applicable.
2 December 2026	Additional prohibitions and a transition under Article 50(2) apply.
2 August 2027	Member States should have at least one operational AI regulatory sandbox.
2 December 2027	Rules for high-risk AI systems listed in Annex III apply.
2 August 2028	Rules for high-risk AI embedded in regulated products covered by Annex I apply.

These are headline milestones, not a substitute for reading the applicable provisions. For example, some obligations were already in effect by August 2026, while the main Annex III high-risk date moved to December 2027. The Commission’s enforcement overview explains the distinction. We removed our earlier timeline image because it showed the superseded dates.

First establish the system and your role

Before building a compliance file, determine what the system does, who provides or deploys it, and which provisions apply. Article 3 defines the relevant actors. Article 6 and Annexes I and III govern high-risk classification. The Annex I route concerns certain regulated products and includes conditions such as third-party conformity assessment. Annex III lists use cases such as employment, education, and access to certain essential services, with a limited exception for systems that do not pose a significant risk, subject to conditions and documentation.

Using a third-party model or API does not, by itself, settle whether your organisation is a provider or a deployer of the resulting AI system. Intended purpose, how the system is placed on the market or put into service, and changes made to it matter. Other provisions, including prohibitions, transparency rules, and rules for general-purpose AI models, may apply independently of high-risk classification. Record the classification reasoning and revisit it when the use case or system changes.

Three connected evidence streams

For an applicable high-risk system, three parts of the Act are especially relevant to an engineering team:

1. Technical documentation. Article 11 and Annex IV describe documentation that allows authorities to assess the system’s compliance. It covers matters such as intended purpose, design, development, testing, risk management, and the system’s evolution. The exact content depends on the system and other applicable rules.
2. Record-keeping capability. Article 12 requires high-risk systems to technically allow automatic recording of events over their lifetime, with capabilities appropriate to the intended purpose. Separate duties concerning retention and access depend on the actor and the provision. A logging design should identify which events support traceability without assuming that every input or output must be retained.
3. Post-market monitoring. Article 72 requires providers of high-risk systems to establish a monitoring system and draw up a plan as part of the technical documentation. The aim is to collect, document, and analyse relevant performance data throughout the system’s lifetime. Article 73 separately addresses reporting of qualifying serious incidents, with its own conditions and deadlines.

These are distinct legal concepts. Connecting them is an engineering choice that can make the evidence easier to maintain and review. A monitoring alert is more useful when it identifies the deployed version and points to the evaluation and risk decision that preceded it. A technical document is more useful when its claims can be traced to current tests and operational observations.

The amended Article 72 provides for Commission guidance, including a template, by 2 September 2027. Earlier versions of this article referred to a mandatory harmonised template expected in February 2026. That description is no longer current. Teams can still design and maintain a monitoring plan against the applicable legal text while following later Commission guidance.

A practical release record

We use “Assurance Pack” to describe a versioned index of evidence and decisions. The Act does not require an artefact with this name. A useful pack answers five questions:

1. What was released? Record the system’s intended use, owner, version, configuration, deployment context, and the change from the prior release.
2. What was evaluated? Link to test datasets, evaluation methods, results, limitations, and the criteria used to make the release decision.
3. What risks were considered? Record identified harms, controls, residual risks, and the people who reviewed them.
4. What will be observed? Link to the monitoring plan, operational signals, thresholds, escalation route, and a way to identify the deployed version in monitoring data.
5. Who approved the decision? Preserve the decision, its date, rationale, and any conditions or follow-up work.

The pack can point to existing controlled records rather than copying sensitive data into another repository. Access, retention, privacy, and security controls still need to be designed for the actual system. For a change, create a new release record and retain the connection to the previous decision. This makes a version comparison possible without treating the evidence as a static PDF.

How to start

Choose one AI system and one release. Write down its intended purpose and the organisation’s likely role, then get the classification reviewed. Map the applicable legal provisions to the records you already produce. Identify missing evidence and assign owners. Make the release decision cite a fixed system version and evaluation run. Finally, connect monitoring signals and incident handling back to that version.

Ormedian’s approach connects release evidence and assurance. The useful test is whether a team can answer a concrete release question with traceable evidence, and keep that answer current after deployment.

For the legal requirements and dates, use the consolidated EU AI Act and the Commission’s implementation timeline. For updates to our research and early access, join the Ormedian list.