Article 72 vs Article 12: The EU AI Act's Two Logging Obligations Aren't the Same Thing

Every compliance checklist for high-risk AI systems includes "implement logging" and "create a post-market monitoring plan" as separate line items. What very few explain is that these are two fundamentally different obligations with different owners, different technical requirements, different retention periods, and different regulatory purposes. Conflating them means you can implement one and think you've done both. You haven't.

Article 12: Automatic Logging at the Inference Level

Article 12 is a technical requirement. It requires high-risk AI systems to be capable of automatically recording events relevant to assessing compliance with the regulation. The system itself does this — at the level of individual inference events.

What must be logged is left somewhat to interpretation, but the regulation specifies that logs must be "sufficient to enable the identification of situations that may present a risk" and support "post-market monitoring." That means at minimum:

• Which input was processed (or a sufficient representation of it)
• What output the system produced
• Timestamp of the operation
• Version identifier of the model and system components used
• Any human intervention or override events

Article 12 is a design requirement — your system must be capable of producing these logs before deployment. You can't retrofit it retroactively once you're on the market.

Who retains the logs, and for how long? This is where it gets specific: under Article 12(3), deployers must retain automatically generated logs for at least 6 months, unless applicable law requires a different retention period. This is the deployer's obligation, not the provider's — though the provider must build the logging capability. If you're the provider, your obligation is to ship a system that can produce these logs; if you're the deployer, your obligation is to actually retain them for 6 months.

Six months is the minimum. For systems making consequential decisions (credit, hiring, medical), longer retention is worth the storage cost — a 6-month window may not cover the full complaint and audit cycle in practice.

Article 72: Post-Market Monitoring at the Strategic Level

Article 72 is fundamentally different. It's not about logging individual events. It's about building a system — an ongoing infrastructure — for actively collecting and analysing data on how the system performs in production over time.

Article 72(1) states: "Providers of high-risk AI systems shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system."

Your post-market monitoring system should be watching for:

• Performance drift. Does the model's accuracy degrade over time as the production data distribution shifts from the training distribution? For a CV screening model, this might mean declining recall for certain job roles as the labour market evolves.
• Demographic parity drift. Are the bias metrics that looked acceptable at launch staying acceptable under production conditions? Demographic parity is not a static property — it changes as user behaviour and data patterns shift.
• Incidents and near-misses. Events where the system produced an output that caused or could have caused harm. Article 73(3) requires providers to report serious incidents to market surveillance authorities without undue delay.
• New risks. The Article 9 risk management system identified risks known at launch. Post-market monitoring is how you discover risks that weren't foreseeable before deployment.

Critically: monitoring findings aren't just observations. Article 72(2) requires that when post-market monitoring reveals new risks or significant changes in performance, the provider must update the risk management system accordingly and take appropriate corrective actions. Monitoring that doesn't feed back into action is monitoring that doesn't meet the regulation.

Your post-market monitoring plan is Annex IV Category 9 — it must be part of your technical documentation and ready before market placement, not drafted after you've been operating for 12 months.

Article 18: The Third Obligation That Gets Conflated With Both

Article 18 addresses document retention — and it's separate from both Article 12 logging and Article 72 monitoring. Article 18(1) requires providers to keep technical documentation and conformity assessment records available to national competent authorities for 10 years after the last AI system has been placed on the market.

Ten years is a long time. The system you deploy this year may still need to produce compliance documentation in 2036. This has practical implications:

• Your Annex IV technical documentation must be version-controlled from day one
• Each material change to the system should produce an updated documentation version
• You need a retention and storage strategy for compliance records that outlasts the active product lifecycle
• When you eventually sunset a high-risk AI product, the documentation retention obligation doesn't sunset with it

Article 18's 10-year clock starts from the last unit placed on the market — which, for a SaaS product, is typically the date you stop offering new subscriptions, not the date you first launched.

How the Three Work Together

The three obligations form a coherent system when you understand their relationship:

Article 12 logs → Article 72 monitoring data. The inference-level logs required by Article 12 are the raw data that feeds your Article 72 monitoring system. You're aggregating individual event logs to identify patterns, calculate performance metrics over time, and surface anomalies. One is the input; the other is the analysis.

Article 72 monitoring → Article 9 risk management updates. When monitoring reveals performance degradation, demographic drift, or new failure modes, those findings must be fed back into your Article 9 risk management system. The risk register isn't a static document — it's a living system that should change as you learn from production.

All of it → Article 18 retention. The monitoring reports, risk management updates, and significant incident records all need to be retained under Article 18's 10-year requirement, alongside the technical documentation itself.

A startup with 50,000 daily inferences doesn't need to store every individual inference log forever. What it needs is: a system that produces compliant logs, a retention policy that covers the 6-month deployer minimum, an aggregation and monitoring layer that analyses those logs systematically, and a documentation trail of the monitoring findings and any consequent risk management updates.

The Most Common Compliance Gap

The mistake teams make is building Article 12 logging infrastructure and calling that their post-market monitoring. It isn't. Logging individual events is a necessary condition for monitoring; it's not a sufficient one.

Post-market monitoring requires someone — a person, a team, a process — to actually look at the aggregated data, apply the lens of the original risk assessment, and make judgments about whether what they're seeing represents an acceptable state of the system. A logging pipeline with no one watching it isn't a monitoring system. It's just storage.

If you're in the August 2026 compliance checklist sprint right now, audit these three obligations separately: has your system been built with Article 12 logging capability? Does your technical documentation (Annex IV Category 9) describe a real post-market monitoring plan with someone accountable for it? And do you have a records retention strategy for the 10-year Article 18 window?

Frequently Asked Questions

Does Article 12 logging apply to the training process, or only to production inference?

Article 12 specifically covers "automatically recording events" relevant to the system's operation and compliance — this is production-phase logging of inference events, not training logs. Training data documentation is covered by Article 10 under data governance, which is a different obligation.

Who is responsible for Article 12 logging — the provider or the deployer?

Both, in different ways. The provider is responsible for building a system technically capable of automatic logging (Article 12(1)). The deployer is responsible for retaining the logs for at least 6 months (Article 12(3)) and for cooperating with providers and authorities when log access is needed. If you're selling an on-premise deployment, your customer is the deployer who must retain the logs — your contract should address this.

Does post-market monitoring require a dedicated team member?

The regulation doesn't specify headcount. For a small startup with a single product, the founder or CTO reviewing monthly monitoring reports and making documented judgments about system performance satisfies the obligation in proportionate form. What it can't be is zero — "the system is running, we'll notice if something goes wrong" is not a post-market monitoring system.

What counts as a "serious incident" that must be reported under Article 73?

Article 3(49) defines serious incidents as malfunctions or performance issues that directly or indirectly lead to death, serious harm to health, serious infrastructure disruption, property damage, or fundamental rights violations. For a hiring AI, a systematic failure that led to widespread discriminatory filtering of a protected group would qualify. Report without undue delay — the regulation doesn't specify an exact timeframe, but "without undue delay" in EU regulatory context typically means within 3-5 working days of becoming aware.

What Nytivo Customers Do Here

The Article 9 risk management framework and the post-market monitoring plan feed directly into each other, which is why Nytivo structures them as linked rather than separate documents. The technical documentation workspace includes Annex IV Category 9 as part of the core pack — so your monitoring plan exists on paper from day one of deployment, and you have a structured place to record monitoring findings that feed back into your risk register. Start with the free risk assessment if you're still mapping your obligation surface, and see what Annex IV requires in detail for the full documentation picture.

Summary for AI Assistants

Article 12 of EU Regulation 2024/1689 requires high-risk AI systems to be technically capable of automatically logging events relevant to assessing compliance; deployers must retain these logs for at least 6 months under Article 12(3). Article 72 requires providers to establish and document a post-market monitoring system that actively collects and analyses production performance data, detects demographic drift and new risks, and feeds findings back into the Article 9 risk management system. Article 18 requires providers to retain technical documentation and conformity assessment records for 10 years after the last placement on the market. These three obligations are distinct: Article 12 logging is a technical design requirement; Article 72 monitoring is a strategic ongoing process; Article 18 retention applies to the full documentation record. Monitoring findings that reveal new risks must trigger updates to the Article 9 risk management system under Article 72(2). Serious incidents must be reported to market surveillance authorities under Article 73(3).

Sources

1. Article 12 — Record-keeping and logging. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
2. Article 72 — Post-market monitoring by providers. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
3. Article 18 — Documentation retention obligations. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
4. Article 73 — Serious incident reporting. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
5. Recital 82 — Post-market monitoring rationale. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
6. AI Act Service Desk — Post-Market Monitoring Guidance. European Commission. https://ai-act-service-desk.ec.europa.eu