Module 4 — Logs, Monitoring, Suspension and Incidents

Module 4 of the AI Act Deployer certification: Art. 12 logging, the six-month floor in Art. 26(6), monitoring against the instructions, when to suspend under Art. 26(5), and how serious incident reporting under Art. 73 reaches you.

This module is about the machinery that makes everything else provable: what the system records, what you watch, when you stop, and who has to be told.

Art. 12 — what the system records, and why it is not your application log

Art. 12 obliges providers to design high-risk systems so that events are automatically recorded over the lifetime of the system, at a level appropriate to the intended purpose. For the remote biometric identification systems in Annex III point 1, Art. 12 specifies a minimum: the period of each use, the reference database against which input data was checked, the input data for which the search led to a match, and the identification of the natural persons involved in verifying the results.

Two things follow for a deployer.

These are not your application logs. Your access logs, your API gateway logs and your audit trail are yours and may be excellent, but they are not the Art. 12 record. The Art. 12 record is generated by the system itself and describes its operation.

If the system does not generate them, that is a provider defect. You cannot retrofit Art. 12 logging into a system that does not have it, and a vendor whose system produces nothing you can retain has sold you something you cannot deploy compliantly. Ask to see a sample log export during evaluation, not after.

Art. 26(6) — six months is a floor

Deployers shall keep the logs automatically generated by the high-risk AI system, to the extent those logs are under their control, for a period appropriate to the intended purpose of the system, of at least six months, unless provided otherwise in applicable Union or national law.

Every clause is doing work:

• automatically generated — the Art. 12 record, per above.
• under their control — the contractual question. Settle it at procurement.
• appropriate to the intended purpose — six months may be plainly inadequate for a system whose harms surface over years. The Regulation sets a minimum and expects you to think.
• at least six months — a floor.
• unless provided otherwise — and sectoral law very often provides otherwise, almost always upward. A financial entity does not get to keep decision records for six months because the AI Act says six months.

The failure mode here is a retention policy written by whoever read the AI Act, overriding a longer sectoral requirement written by whoever read the sectoral law. Reconcile them explicitly and record the reconciliation.

Art. 26(4) — monitoring against the instructions

Monitoring is owed on the basis of the instructions for use. That phrase decides what you monitor.

If the provider's instructions state operating conditions — an input distribution, a population, a language, a volume envelope, an accuracy figure under stated conditions — those are the reference points. Monitoring against your own comfortable internal metrics while the system runs outside its declared envelope satisfies nothing.

A workable monitoring plan names, per system: the indicators, drawn from the instructions; the thresholds and who set them; the frequency; the person who reads the output; and the escalation path when a threshold is crossed. Without the last two it is a dashboard, not a control.

Watch specifically for input drift — the population the system now sees diverging from the one it was built for. This is where Art. 26(3), on input data you control, and Art. 26(4) meet, and it is the most common way a compliant deployment becomes a non-compliant one without anybody changing anything.

Art. 26(5) — the decision to stop

Where the deployer has reason to consider that use in accordance with the instructions may present a risk within the meaning of Art. 79(1), it shall without undue delay inform the provider or distributor and the relevant market surveillance authority, and suspend the use of the system.

Three observations.

The threshold is "reason to consider ... may present a risk". It is not certainty, not proof, not a completed investigation. If you are waiting for confirmation before acting, you have set the bar higher than the Regulation does.

Suspension is not optional and not sequenced last. The text lists informing and suspending together; operationally, suspend first.

The trigger is risk from use in accordance with the instructions. If the risk arose because you were using the system outside its declared purpose, this is not the paragraph you are in — you are in Art. 26(1), and quite possibly Art. 25.

The artefact is a suspension procedure a duty manager can execute without convening a committee: who can pull the switch, what happens to work in flight, what the fallback process is, and which templates are pre-written. Test it. A procedure that has never been executed is a document.

Art. 73 — serious incidents, and how they reach you

The reporting obligation in Art. 73 sits on the provider, which must report serious incidents to the market surveillance authority of the Member State where the incident occurred, immediately upon becoming aware and in any case within 15 days. Shorter deadlines apply for the gravest categories — where there is a risk to life and safety, or a widespread infringement — and the Regulation expects notification without undue delay in those cases even where the investigation is incomplete.

The deployer's position is straightforward and easy to get wrong: you are usually the only party that can see the incident, and the provider cannot report what it has not been told. Your Art. 26(5) notification is what starts the provider's Art. 73 clock. A deployer who investigates internally for three weeks before telling the vendor has not breached Art. 73 — it does not bind them — but has made it impossible for the provider to comply, which is a contractual and a reputational problem, and evidence of a poor programme in any supervisory conversation.

Build the two paths as one procedure: detect, suspend, notify the provider, notify the market surveillance authority, record. The AI Act notification also sits alongside, and does not replace, a GDPR personal data breach notification where one is triggered — different regimes, different clocks, different recipients.

Art. 26(12) — cooperation, in practice

Cooperation with competent authorities means being able to produce, within a reasonable period: the classification determination, the instructions for use, the oversight assignment, the monitoring output, the logs, and the incident record. If those live in six systems owned by four teams, cooperation is a project. If they live in one file per system, it is a morning.

Check yourself

1. Our SIEM captures everything the AI system does. Does that satisfy Art. 26(6)? — Not by itself. The retained record must be the logs the system generates automatically under Art. 12; your own telemetry is not a substitute.
2. Sectoral rules require seven years' retention. Can we keep six months? — No. Art. 26(6) sets a floor and expressly defers to other Union or national law providing otherwise.
3. We suspect a problem but have not confirmed it. — The Art. 26(5) threshold is "reason to consider ... may present a risk". Suspend and notify; confirm afterwards.
4. Do we report the serious incident to the authority under Art. 73? — The Art. 73 duty is the provider's. Yours is to suspend and inform the provider and the market surveillance authority under Art. 26(5) — which is what makes the provider's report possible.

Previous: Module 3 — Human oversight that survives a review Next: Module 5 — The Article 25 trap →