EU AI Act logging requirements: which logs you must keep, in what form, and for how long.

If you run a high-risk AI system in the EU market, here is the whole answer up front. Your system has to automatically record events (logs) over its lifetime, sufficient to make its behaviour traceable for three purposes the law spells out. The Act does not dictate a file format and, outside biometric systems, does not hand you a fixed field list. You must keep those automatically generated logs for at least six months, whether you are the provider (Article 19) or the deployer (Article 26(6)), and only to the extent the logs are under your control. That six-month log clock is a different clock from the ten-year technical-documentation retention in Article 18, and the two get conflated constantly.

The part that decides which of those obligations is yours is one question most operators skip: are you the provider of the system or its deployer. Answer that first, because it changes the duty. The rest of this piece is the long version, quoting the text, translating it into operator language, and giving you a starter schema you can copy. For the architecture that makes a log survive an auditor's tampering check, I wrote a separate guide on building an audit chain that survives Article 12; this is the reference answer to what you keep and for how long.

One date caveat before we go further, because it is moving. As of this writing (2026-05-30), August 2, 2026 is still the legal date the high-risk obligations apply. But EU institutions reached a provisional political agreement on the "Digital Omnibus" on May 6, 2026, confirmed by Member State representatives on May 13, that would defer stand-alone Annex III high-risk obligations to December 2, 2027 (and Annex I embedded systems to August 2, 2028). That change only takes legal effect once it is formally adopted and published in the Official Journal, which had not happened when I wrote this. So plan for August 2, 2026 until the deferral is law, and treat the new dates as the likely-but-not-yet-binding target. I cite the sources for both in the section below.

Which logs does Article 12 actually require?

Article 12 requires a high-risk AI system to automatically record events over its lifetime, sufficient to make the system's behaviour traceable for three specific purposes. Here is the operative sentence, verbatim.

"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system."
— Regulation (EU) 2024/1689, Article 12(1)

Article 12(2) then says the logging has to enable a level of traceability appropriate to the system's intended purpose, and it names the three things the logs must be good enough to do:

• Identify situations that may result in the system presenting a risk under Article 79(1) or in a substantial modification.
• Facilitate the post-market monitoring under Article 72.
• Support the deployer's monitoring of the system's operation under Article 26(5).

Notice what is and is not there. The Act tells you what your logs must be sufficient for. It does not tell you the columns. That gap is deliberate, and it is the source of most of the confusion I see. People go looking for the official field list and there is not one, so they assume their existing call log is fine. It usually is not, because a call log records what the system did, not enough to reconstruct why it did it. That is the same decision-log gap I find in every audit.

The only concrete field list the Act gives you.

There is exactly one place the Act prescribes specific fields, and it is for remote biometric identification systems under Annex III point 1(a). Article 12(3) requires those systems to record, at a minimum: the period of each use (start and end date and time), the reference database checked against, the input data that led to a match, and the identity of the people who verified the result. That four-item list is the closest thing to an official schema in the whole article, and even if you do not run biometrics, it is a sane place to start. Rephrase it for your own system and you have a defensible v1: when did the decision happen, against what data, on what input, and who (or what) signed off.

What form must the logs be in?

The EU AI Act prescribes no file format and, outside biometric systems, no fixed field list. It requires that the logs be sufficient for traceability appropriate to the system's intended purpose. There is no JSON mandate, no CSV mandate, no "you must use this schema." A regulator is not going to reject your records because they are in Parquet instead of NDJSON.

What they will reject is records that cannot answer the operative question after the fact. So in the absence of a prescribed format, the practical bar is the one auditors actually apply: the logs have to be structured enough to query, timestamped on one canonical clock, integrity-protected so nobody can quietly rewrite them, and complete enough to reconstruct a specific decision months later. Format is your choice. Reconstructability is not. If you want the build pattern for the integrity part, the audit-chain guide walks through signing and chain roots step by step.

Harmonised technical standards that would pin down the implementation detail are still being drafted, so as of this writing there is no single standard number to point a vendor at. Until those land, the obligation is the one in the text: traceability sufficient to the purpose.

How long must AI logs be kept?

Automatically generated logs must be kept for a period appropriate to the system's purpose, at least six months, and that minimum applies to providers under Article 19 and deployers under Article 26(6) alike. This is the number people get wrong most often, because they swap it with the ten-year clock that lives in a different article. There are two clocks, and they measure two different things.

Read the table twice, because the conflation is everywhere, including in AI-generated summaries of this exact question. The logs are six months minimum. The technical documentation, your conformity paperwork and design records, is ten years. Logs are not documentation, and the ten-year clock does not apply to your event logs.

Two qualifiers matter. First, six months is a floor, not a target. The text says "a period appropriate to the intended purpose of the high-risk AI system, of at least six months," and other Union or national law, data-protection law in particular, can require you to keep them longer or to delete them sooner. Second, the obligation only bites "to the extent such logs are under your control." If you are a deployer using a vendor's hosted system, the logs you must keep are the ones you can actually get your hands on. Which brings us to the question that decides everything.

Provider or deployer — who is on the hook?

Whether you keep the logs, and under which article, turns on one question: are you the provider of the high-risk AI system or its deployer. The Act draws a clean line, and SMBs land on the wrong side of it constantly.

You are the provider if you develop a high-risk AI system, or have one developed, and place it on the market or put it into service under your own name or trademark. You are the deployer if you use such a system under your own authority in the course of your business. A clinic running a bought-in diagnostic-support tool is a deployer. A recruiter using an off-the-shelf CV-screening product is a deployer. The vendor who built and sells that product is the provider.

Here is the trap I see most often. The SMB is a deployer. It assumes the vendor keeps everything, so it keeps nothing. Then a complaint lands, the deployer goes to pull six months of logs for a specific decision, and discovers the only copy it controls is whatever the vendor's portal will export, often the last 30 days, because that is the default retention on the observability stack underneath. The phrase "to the extent such logs are under your control" is not a loophole that lets you off. It is a prompt to go make sure the logs you are responsible for are actually within your control before you need them.

One carve-in worth knowing: if you are a financial institution already subject to internal-governance rules under Union financial-services law, the Act lets you fold these logs into the documentation you keep under that law rather than running a parallel regime. Both Article 19 and Article 26(6) say so.

Two worked examples: credit scoring and CV screening.

Two of the most common SMB high-risk cases, credit scoring and CV screening, show how the same rules produce different log contents. Both are Annex III categories, both make the operator a deployer in the typical bought-in setup, and both need a decision log, not just a call log.

A credit-scoring deployer (Annex III, essential private services) should be able to reconstruct, for any applicant: the input features the model saw, the score or decision it returned, the threshold or rule that turned that score into an approve/decline, any human override, and the timestamp on one clock. That is what answers "why was this person declined" when the regulator or the applicant asks.

An HR/CV-screening deployer (Annex III, employment) needs the parallel set: the candidate inputs the model received, the ranking or pass/fail it produced, the criteria behind it, who reviewed it, and when. Same shape, different fields. In both cases the starter schema from the biometric four, when/against-what/on-what-input/who, maps cleanly onto the decision you are actually making.

What to do before the deadline.

If you operate an Annex III system, four steps get you to an Article 12-shaped log before enforcement begins. None of them require a $40K compliance platform. They require decisions, written down.

On timing: the legal deadline is currently August 2, 2026, the date the high-risk obligations were scheduled to apply under Article 113. EU institutions reached a provisional agreement on May 6, 2026, confirmed by Member State representatives on May 13, to defer stand-alone Annex III obligations to December 2, 2027, but that deferral is not law until it is published in the Official Journal (see the Gibson Dunn breakdown of the Omnibus agreement). The practical read: the extra runway is probably coming, but the work below is the same work either way, and starting it now is the cheapest it will ever be.

• Decide your role and confirm you are in scope. Provider or deployer. In an Annex III domain or not. If you are unsure whether August even applies to you, the August 2, 2026 deadline stack breaks down who lands in the high-risk bucket and what the fine tiers are; if the question is whether your agent is high-risk in the first place, walk the classification decision tree before you worry about logs.
• Define the events and fields. Start from the biometric four or from the decision-log concept and write the schema for what your system actually decides. Five fields beats forty placeholders.
• Pin your retention. Six months is the floor. Set it against your sector's law and your data-protection obligations, and write down the number you chose and why.
• Make integrity falsifiable. A log nobody can prove is unedited is not evidence. Sign the records, publish a chain root somewhere external. The audit-chain guide has the pattern.

This is the lane the $997 AI audit sits in. Two hours on a call, I map your provider-versus-deployer exposure, score your existing logs for completeness against Article 12, and hand you a numbered plan. You do not need me to do any of the four steps above, but if you want a second set of eyes before August, that is the offer. The closing line I give every operator stands: regulators do not want philosophy, they want records. You either have them, or you do not.

FAQ

How long do AI logs have to be kept under the EU AI Act?

Automatically generated logs must be kept for at least six months, for both providers (Article 19) and deployers (Article 26(6)), to the extent the logs are under their control. That six months is a floor proportionate to the system's purpose; other Union or national law can require longer. It is a separate clock from the ten-year technical-documentation retention in Article 18.

What form do the logs have to be in?

The EU AI Act does not prescribe a file format or, outside biometric systems, a fixed field list. It requires the logs to be sufficient for traceability appropriate to the system's intended purpose. In practice that means structured, timestamped, integrity-protected records you can reconstruct a decision from.

Am I the provider or the deployer?

You are the provider if you develop a high-risk AI system, or put your name on one, and place it on the market; you are the deployer if you use one under your own authority in your business. Most SMBs running a bought-in tool are deployers, which means Article 26(6) is the log-retention obligation that applies to you.

Do general chatbots and other non-high-risk AI need Article 12 logs?

No. Article 12's logging obligation applies only to high-risk AI systems, mainly the Annex III categories such as biometric ID, credit scoring, and employment screening. A general-purpose chatbot that is not used in a high-risk context is outside this obligation, though transparency rules under Article 50 can still apply.

Does the six-month minimum mean I can delete logs at six months?

Not automatically. Six months is the minimum; the actual period must be appropriate to the system's intended purpose, and other Union or national law, including data-protection law, can require you to keep them longer or shorten them. Treat six months as a floor, not a target.