AI Act Logging: Article 12 & 26 Duties for High-Risk AI

Key takeaways

• Article 12 is a provider design duty (the system must emit logs automatically); Article 26(6) is the deployer duty to keep the logs under its control for a period appropriate to the purpose and at least six months (Article 26 breakdown).
• Zero-retention at the LLM layer removes almost nothing from your obligation, because the loggable events (input reference, model version, confidence, human review decision) live in your orchestration layer, not in the model vendor's storage.
• The clock moved: Regulation (EU) 2026/1744 entered into force on 27 July 2026 and moved obligations for stand-alone high-risk AI systems listed in Annex III from 2 August 2026 to 2 December 2027.
• Log metadata and hashes, not raw document content, and you satisfy traceability without turning your audit trail into a second copy of the personal data you were told to minimise.

Does zero-retention at the LLM provider exempt me from Article 12 logging?

No. Zero data retention is a commitment by the model vendor not to persist your prompts and completions; it says nothing about what your pipeline has to record. ZDR is narrow by design: it normally means covered prompts and outputs are not written to durable provider storage after processing, and it does not automatically cover metadata, tools, customer logs, files, caches, safety signals, or legal exceptions.

The split of duties is what matters here. Article 12 is the provider-side record-keeping design duty: a high-risk AI system must be technically capable of automatic event logging. Article 26(6) is the deployer-side retention duty: the deployer keeps the logs under its control for at least six months, unless another applicable law requires a longer or different period. If you built the extraction pipeline and put it into service under your own name, you are the provider of that system, whatever foundation model sits inside it. The LLM is a component. Nobody in Brussels will accept "OpenAI doesn't keep it" as an answer about events your own orchestrator generated and discarded by choice.

Zero retention is a promise about the model vendor's disks, not a waiver of your own audit trail.

What exactly does Article 12 require a document pipeline to log?

Article 12 does not hand you a field list for document extraction. It gives you three purposes, and you derive the schema from them. Article 12(2) spells out three purposes: identifying risk situations under Article 79, supporting post-market monitoring under Article 72, and tracking operational performance under Article 26(5).

The only hard-coded minimum field list applies to remote biometric identification under Annex III point 1(a): the period of each use with start and end timestamps, the reference database checked, the input data that produced a match, and the identification of the natural persons involved in verifying the results. Read that list as a template rather than a limit. For a document pipeline it translates cleanly: one event per document processed, with ingestion timestamp and completion timestamp, the document identifier and content hash, the model and prompt version used, the extracted field set with per-field confidence, any validation rule that fired, and the identity of the reviewer who accepted or corrected the output.

Logs must allow full traceability of the system's operation from deployment through decommissioning, covering every algorithmically driven decision. That phrase "every decision" is the design constraint: sampling your logs is not an option, and aggregating at batch level loses the per-document granularity an auditor or a contested applicant will ask about.

Which logs stay with me when the model vendor keeps nothing?

Everything that is generated by your code rather than the vendor's. The model API returns a response; the decision about what that response means and what happened next is yours, and that decision is the loggable event.

The abuse-monitoring row is the one engineers get wrong. Abuse monitoring retention means data held so the provider can investigate misuse, and it survives most ZDR arrangements: OpenAI generates abuse monitoring logs for all API feature usage and retains them for up to 30 days. With ZDR enabled, customer content is excluded from those abuse-monitoring logs, and the API's store parameter is always treated as false for covered endpoints, even if a request tries to set it true. So under ZDR there is nothing retrievable there, and even without ZDR a 30-day window cannot carry a six-month-plus legal retention anyway. Treat vendor telemetry as monitoring, never as evidence.

If you are buying rather than building the extraction layer, log access is a procurement clause, not an afterthought. Logs in a vendor's cloud may not be under your control at all, so export rights and access on demand belong in the contract. Our IDP vendor evaluation checklist covers the questions worth asking before signature, and the build vs buy analysis sets out where the logging burden lands in each model.

How long do I keep them, and does GDPR cut the period short?

Six months is the floor, and for most document pipelines it is the wrong answer. The text requires a period appropriate to the intended purpose, of at least six months, so where the purpose implies a longer accountability horizon six months is not compliant: a credit scoring system whose decisions can be challenged years later, or an employment tool feeding decisions subject to labour law limitation periods, points to a longer period.

Work backwards from the contestability window of the downstream decision. A KYC refusal, a claims rejection, a loan decline: each has a statutory or contractual challenge period, and your log retention should exceed it. An expired log is an evidential gap you created, and GDPR storage limitation pulls the other way, so you need a documented retention rationale per system, not a platform default.

The tension resolves in favour of data protection law, which is precisely why metadata-first logging is the right architecture. Store content hashes, field-level confidences, model versions and reviewer IDs; keep the source document under its own sectoral retention rule and reference it by ID. The log then survives the document deletion without reproducing its personal data. Our GDPR checklist for document AI projects walks through the minimisation and retention mapping; Sygnet documents its own processing, retention and residency options on the same basis.

Is my extraction pipeline actually high-risk, or did I over-classify it?

Most document extraction is not high-risk on its own. The classification attaches to the use, not to the parsing. Products with AI functions that only assist users or optimize performance will not automatically face high-risk obligations if their failure or malfunction does not pose health or safety risks, which is intended to prevent overclassification of AI-enabled products as high-risk.

An OCR or VLM layer that turns a PDF into structured JSON, with a human reading the result and making the call, is a long way from Annex III. The same layer feeding an automated creditworthiness score is squarely inside it. Annex III covers stand-alone high-risk systems such as recruitment and assessment of employees, credit scoring, and biometrics. So the question to answer first is not "what does my parser do" but "what decision does its output drive, and how much human judgement sits between them".

Do the mapping now regardless of the deferral. An organisation should still complete its classification mapping now, even though the obligations attaching to a high-risk classification do not bite until December 2027. Classification also determines whether you need the field-level accuracy evidence described in our extraction accuracy evaluation checklist, since Article 15 robustness claims need measured numbers, not vendor marketing.

The parser is rarely high-risk; the decision it feeds usually decides the answer.

FAQ

If my LLM provider is zero-retention, can I log nothing at all?

No. ZDR only means the vendor does not persist your prompts and completions. The Article 12 events, timestamps, model version, per-field confidence, validation outcomes and human review actions, are produced by your orchestration code and are under your control, which is exactly the test in Article 26(6). A pipeline that calls a ZDR endpoint and writes no event record of its own has no audit trail whatsoever.

Do I have to store the document content itself in the logs?

Not usually, and in most cases you should not. Store a stable document ID plus a content hash, and keep the document under its own sectoral retention rule. That keeps traceability intact while respecting GDPR storage limitation. Treating the AI Act as authority to keep logs indefinitely is one of the common mistakes companies make.

When do these logging duties actually start applying?

Regulation (EU) 2026/1744 moved the timeline: high-risk systems listed in Annex III are only covered from 2 December 2027, with AI embedded in regulated products under Annex I deferred to 2 August 2028. Logging schemas are hard to backfill, so build the event model before the deadline rather than after.

Does using a managed extraction API make the vendor the provider?

Generally no. If you put the system into service under your own name for your own high-risk use, you are the provider of that system, and the extraction API is a component. The vendor's obligations cover its own product; yours cover the pipeline you assembled, including the logs.