Do we need a notified body?

It depends on the system. Many Annex III high-risk systems can go through internal control: the provider carries out the conformity assessment itself against the requirements. Third-party assessment by a notified body applies in specific cases, notably certain biometric systems and AI embedded in products already subject to third-party assessment under existing EU product legislation. The classification decides the route, not the size of the company.

How fast must a serious incident be reported?

Immediately after the provider establishes a causal link, or the reasonable likelihood of one, between the AI system and the incident — and in any event within deadlines that run from 2 to 15 days depending on severity. The shortest deadlines apply to the most serious events; a widespread infringement or a death carries a tighter clock than other reportable incidents.

What is a fundamental rights impact assessment?

For certain deployers of high-risk systems — notably public bodies and some private operators providing public services, along with deployers of certain credit and insurance-pricing systems — the AI Act requires an assessment before first use. It describes the processes the system will be used in, the period and frequency of use, the categories of people affected, the specific risks of harm to them, the human oversight arrangements, and the measures to take if those risks materialise.

We already run an ISO-style quality system. Is that enough?

It is a strong foundation and it means the hard part — a working management system with documented processes, ownership and review cycles — already exists. It does not by itself satisfy the AI Act, because the regulation asks for specific artefacts: the Annex IV technical documentation, the risk management file, the data governance evidence, logging, the conformity assessment and the EU database registration. Map what you have to those artefacts and close the gaps rather than starting over.

Who keeps the logs — the provider or the deployer?

Both, for different parts. The provider must design the system to record events automatically over its lifetime and must keep the logs it controls. The deployer must retain the logs generated by the system that are under its control, for a period appropriate to the intended purpose. Where the two are different organisations, agree in the contract who retains what and for how long — before an authority asks.

AI Act

What high-risk AI actually requires

High-risk is not a warning label — it is a work programme. The AI Act asks a provider to build the system inside a documented quality and risk management process, prove conformity before the system reaches the market, and keep watching it afterwards. Deployers get a shorter list, but it is the list a regulator will ask them about first.

The requirements in 60 seconds

Who this applies to: Providers of high-risk AI systems carry the full requirement set. Deployers carry a shorter list of use-side duties.
The core idea: A high-risk system must be built inside a documented quality and risk management process, not simply tested until it looks accurate.
Before market: Conformity assessment, CE marking and registration in the EU database happen before the system is placed on the market or put into service.
After market: Post-market monitoring runs continuously, and serious incidents are reported within deadlines from 2 to 15 days depending on severity.

Provider obligations

These apply to every high-risk system, whether it reached that classification through Annex I or Annex III. They are cumulative: none of them substitutes for another, and they follow the provider role rather than the industry.

Risk management system

A continuous, documented process across the whole lifecycle that identifies, estimates and mitigates risks to health, safety and fundamental rights — reviewed and updated, not written once.

Data and data governance

Training, validation and testing data sets governed for relevance, representativeness and known bias, with documented choices about collection, preparation and limitations.

Technical documentation (Annex IV)

Drawn up before the system is placed on the market and kept up to date, detailed enough for an authority to assess conformity against the requirements.

Record-keeping and logging

Automatic recording of events over the lifetime of the system, so that its operation can be traced after the fact and incidents can be reconstructed.

Transparency and instructions for use

Deployers must receive information that lets them use the system correctly: intended purpose, capabilities, limitations, expected accuracy and the human oversight measures built in.

Human oversight

Designed so a competent person can understand the output, monitor operation, intervene and stop the system — oversight has to be possible by design, not promised in a policy.

Accuracy, robustness and cybersecurity

An appropriate level of performance for the intended purpose, resilience to errors and faults, and resistance to attempts to manipulate the system or its data.

Quality management system

A documented organisational system covering design, development, testing, change control, documentation and post-market activity, with named responsibilities.

Conformity assessment and CE marking

The system is assessed against the requirements — internally or by a notified body, depending on the classification — and carries the CE marking before it goes to market.

Registration in the EU database

High-risk systems are registered in the EU database before being placed on the market or put into service.

Post-market monitoring

A plan and an active process for collecting and reviewing performance data once the system is in real use, feeding back into the risk management system.

Serious-incident reporting

Report serious incidents to the market surveillance authority within deadlines running from 2 to 15 days depending on severity, and investigate the cause.

The route through conformity assessment and CE marking depends on the classification: many Annex III systems go through internal control, while certain biometric systems and AI embedded in products already subject to third-party assessment require a notified body.

Deployer obligations

Shorter than the provider list, but these are the duties a deployer is asked about directly.
Duty	What it means in practice
Use according to instructions	Operate the system for the intended purpose and within the conditions the provider documented. Using it for something else can make you the provider.
Assign human oversight	Name the people who oversee the system, and make sure they have the competence, training and authority to act on what they see — including stopping it.
Ensure relevant input data	Where you control the input data, make sure it is relevant and sufficiently representative for the intended purpose.
Monitor operation	Watch how the system behaves in real use and inform the provider and the authority when you have reason to believe it presents a risk or a serious incident has occurred.
Retain logs	Keep the logs the system generates that are under your control, for a period appropriate to the intended purpose.
Inform affected workers	Before putting a high-risk system into use in the workplace, inform workers and their representatives that they will be subject to it.
Fundamental rights impact assessment	Certain deployers must carry out a FRIA before first use, covering the processes involved, the people affected, the specific risks of harm and the oversight and mitigation arrangements.

Implementation without documentation still fails

The evidence problem

You can have a genuinely well-built, well-monitored high-risk system and still fail an assessment, because the regulation is written in artefacts: the Annex IV technical documentation, the risk management file, the data governance record, the logs, the instructions for use, the conformity assessment and the registration entry — the same file that supports CE marking. If a control exists only in someone's head or in a Slack thread, it does not exist for the authority.

The pattern is the same one we describe for NIS2: the work is usually further along than the paperwork. Start from the artefact list, map what already exists to each item, and treat the gaps as documentation tasks with owners and dates — not as a reason to rebuild the system.

Frequently asked questions

Sources

EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act)

AI Act document packages are available now

The AI system inventory, risk classification workbook and documentation templates, in three tiers from 99 EUR. Pay once, download immediately.

See the packages