Article 12 of the EU AI Act: Logging as a Build Spec

Article 12 of the EU AI Act is one paragraph of obligation and two paragraphs of scope. Most explainers of the AI Act quote it, gloss it in legal register, and stop. That is not much use to the person who has to ship the thing. Read as a build specification, Article 12 is short, demanding, and conspicuously silent at the exact point where implementations tend to fail.

This is what it compels, what it leaves open, who keeps the records, what a failure costs, and why the deadline that moved in July 2026 did not change any of it.

What Article 12 actually says

Article 12 sits in Chapter III, Section 2, among the requirements for high-risk AI systems. Paragraph 1 is the whole obligation:

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.

Three words in that sentence carry the weight, and the European Commission's own text does not soften any of them.

Technically. The capability lives in the system. A compliance process that exports records on request, a reviewer who writes notes, a quarterly spreadsheet: none of these satisfy paragraph 1, because none of them are a technical property of the system.

Automatic. No human decides what gets recorded. A system that logs when an operator remembers to, or logs only what a rule-writer anticipated, has a judgment step where the statute requires a mechanism.

Over the lifetime. From first deployment through decommissioning, across upgrades, migrations and re-platformings. A pipeline that was reconfigured mid-year has a coverage gap, and the gap is the thing an auditor will find.

The three jobs your logs have to do

Paragraph 2 sets the standard as traceability appropriate to the intended purpose of the system, then names three specific uses the logging capability must serve: identifying situations that may cause the system to present a risk under Article 79(1) or to have been substantially modified, feeding the post-market monitoring of Article 72, and supporting the operational monitoring deployers carry out under Article 26(5).

Translated out of statutory language, all three are the same test applied at different moments. Can an outside party reconstruct a specific decision from the record alone, without asking you what happened?

That test rules out two common designs. Logging only errors fails it, because a risk you did not anticipate does not announce itself as an error. Sampling fails it too, since the one inference that later gets challenged is exactly the one that was not in the sample.

The minimum fields, and what they tell you

Paragraph 3 is the only place in Article 12 where the regulation names data fields, and it names them for one category: remote biometric identification systems under Annex III point 1(a). Those systems must at minimum record the start and end date and time of each use, the reference database the input was checked against, the input data that produced a match, and the identification of the natural persons who verified the result under Article 14(5).

Read that list as a template rather than a carve-out. It captures when, against what, on what evidence, and on whose authority. Every one of those questions arrives at incident time for any high-risk system. Biometrics is simply where the legislator wrote the answer down.

Who keeps the records, and for how long

Article 12 creates the capability. Two other articles create the custody, and both hang on the word control.

Providers keep the logs their systems generate to the extent those logs are under their control, for a period appropriate to the intended purpose and in any case at least six months under Article 19. Deployers keep the logs under their control on the same six-month floor under Article 26(6). Six months is a floor, not a target: an incident under investigation extends it, and sector law can too.

Control is the operative word for anyone selling software. A provider running a hosted service holds most of the record. A provider shipping a self-hosted system holds almost none of it, and inherits a different obligation instead: Article 13(3)(f) requires the instructions for use to tell the deployer how to interpret the logs. A log format nobody outside your engineering team can read is not a compliant deliverable.

The deadline moved. The requirement did not

Anything written about Article 12 before August 2026 is now carrying a wrong date.

The Digital Omnibus on AI, Regulation (EU) 2026/1744, was signed on 8 July 2026, published in the Official Journal on 24 July 2026, and entered into force on 27 July 2026. It moves the application of the high-risk chapter from 2 August 2026 to 2 December 2027 for standalone Annex III systems, and from 2 August 2027 to 2 August 2028 for AI embedded in products regulated under Annex I. Recital 40 of the amending regulation gives the reason without decoration: the standards and the national competent authorities were not going to be ready, and enforcing on the original date would have raised implementation costs without a corresponding benefit.

Two things did not move. The text of Article 12 was not amended, and the transparency duties of Article 50 and the newly added prohibitions arrive on their own timetable regardless of the high-risk deferral. If you want the broader picture of what is already enforceable and what is still ahead, the sequencing matters more than the headline.

The deferral bought build time, not relief. Logging is a design decision, not a feature you bolt on in the final quarter, and the systems in scope in December 2027 are largely the systems being architected now.

What Article 12 does not say

Here is the part the legal summaries skip.

Article 12 specifies no format, no schema, no storage technology, and no retention mechanism. More importantly, it says nothing at all about integrity. The regulation's vocabulary is record-keeping, automatic recording of events, and traceability. It never says audit trail and it never says tamper-evident.

That silence is not an oversight to be argued away, and nobody should tell you the Act requires cryptographic guarantees it does not require. But the silence has a consequence, and the consequence shows up at exactly one moment: when the record is challenged.

A conventional pipeline can capture every event Article 12 asks for and still be mutable. Anyone with write access to the store can alter or truncate it, and nothing inside the log demonstrates that it is complete. Such a record can be vouched for. It cannot be verified. When a market surveillance authority, a notified body or a counterparty asks whether the log is the whole log, the answer is your word.

There is a related trap. Platform and infrastructure logs rarely satisfy Article 12 on their own, because the events the article cares about are application-level: which model version produced the output, which policy fired, whether a human reviewed and overrode it. Those facts are not in your load balancer.

What a record-keeping failure costs

Article 12 has no penalty of its own. It reaches the fine schedule through the operator obligations that carry it.

Under Article 99(4), failing the provider obligations of Article 16 or the deployer obligations of Article 26 carries administrative fines of up to EUR 15,000,000 or 3 percent of total worldwide annual turnover, whichever is higher. For SMEs and start-ups the ceiling inverts to whichever of the two is lower, which is the one piece of proportionality in the schedule.

The tier worth a second look is Article 99(5): up to EUR 7,500,000 or 1 percent for supplying incorrect, incomplete or misleading information to a notified body or a national competent authority. A weak record does not only fail the record-keeping test. It is also how an honest company answers a regulator's question incorrectly and creates a second, separate ground for a fine.

A requirement with an unmet technical gap is an IP question

Every regulation that compels a capability without specifying the hard part does the same thing to a market. It defines a technical problem precisely, attaches a date to it, and applies it across the entire Union at once. That is an unusually clean brief for an inventor, and it is why regulatory text belongs in the filing strategy rather than only in the compliance folder.

EX-IX took that view of Article 12 directly. The first family listed on IX Markets, Edge Assist, is a method for a tamper-proof black box recorder for AI systems, aimed at the automatic logging and traceability requirement the article creates. Application P00202606645 is filed in Indonesia and pending examination, with dual US and EU prosecution scoped. Pending means pending: it has not been examined, grant is not assured, and nothing here should be read as a claim that it has issued.

The claim we do make is about method. Before any family reaches a buyer, it goes through a digital twin validation gate: physics-grade reconstruction of the claims, detectability analysis and validity probability, benchmarked at 0.76 percent mean absolute percentage error against real-world outcomes. That is what separates a filing aimed at a real regulatory gap from a filing aimed at a press release, and it is the same evidence that determines whether a filed but not yet granted application is worth anything to anyone else. If you are looking at a filing of your own against a compliance deadline, the question of how a patent is valued is the one to answer before the deadline arrives, not after.

FAQ

Does Article 12 apply to general-purpose AI models like a large language model?

Not directly. Article 12 sits in the high-risk chapter, while general-purpose AI models are governed by a separate regime whose obligations have applied since 2 August 2025. A general-purpose model comes into Article 12's scope when it is built into a system that is itself classified as high-risk, and then it is the system's provider who owes the logging capability.

Can we log a sample of inferences instead of all of them?

No. The obligation is automatic recording over the lifetime of the system, and sampling breaks traceability for the single decision that later gets questioned. Sampling is a cost strategy. Article 12 is a coverage requirement, and they do not reconcile.

Does Article 12 override GDPR data minimisation?

No. Article 19 carves out Union data protection law explicitly, which means the logs are themselves personal data. Minimisation, purpose limitation, residency and transfer analysis apply to the record as much as to the system that produced it, so pseudonymisation belongs in the logging pipeline rather than in a later clean-up pass.

Who is responsible if the provider and the deployer are different companies?

Both, over different material. The provider owes the technical capability under Article 12 and retention of the logs under its control under Article 19; the deployer owes retention of the logs under its control under Article 26(6) and the operational monitoring of Article 26(5). Neither obligation absorbs the other, and a contract cannot move a statutory duty, only allocate the work.