DefinitionEU AI Act · Articles 12, 19, 26Version 1.023 October 2026
AI audit trail: definition, fields and EU AI Act mapping
An AI audit trail is the append-only record, written by the system at the moment of each action, of who or what acted, with which model and version, under which policy, on which inputs, with which human verification and when, so that any decision can be reconstructed and checked without assembling logs after the fact. This page sets out its 9 fields and maps them to the record-keeping duties of the EU AI Act, read in the consolidated text on 23 October 2026.
On this page
A log is what a system emits. An audit trail is what a regulator can read.
In this page, "we" means Hikari Blue, which engineers and operates the AI operating layer that writes this record. The 9 fields are those of our published Reference Architecture v1.0; the mapping to the EU AI Act is ours, read in the consolidated text of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744.
3 things are often confused. Application logs record what software did, for its engineers. Technical documentation describes how a system was built, for an assessor. An audit trail records each decision as it happens, with its actor, rule and human check, for whoever must reconstruct it later: an auditor, a regulator, a court.
One record per action, 9 fields, chained to the record before.
Each action produces one record. Records are append-only and chained by hash, so a deletion or an edit breaks the chain visibly. The last column names the EU AI Act provision each field answers.
| Field | Content | Why it matters | EU AI Act |
|---|---|---|---|
| Actor identity | The agent or operator identity issued by the enterprise identity provider, never a shared service account. | Every action has one accountable identity. | Art. 12(2)(c) and 26(5): monitoring of operation |
| Model and version | Provider, model name and exact version or snapshot used for this action. | Reproducibility after a provider updates or retires a model. | Art. 12(2)(a): substantial modification |
| Policy applied | Identifier and version of the policy evaluated, with the decision it returned. | Proves the action ran under the rule in force at that moment. | Art. 26(1): use according to the instructions for use |
| Residency corridor | Declared region for compute, storage and inference, and the key custody reference. | Turns sovereignty from a statement into a per-action fact. | Art. 19(1) and 26(6) defer to data protection law |
| Inputs reference | Pointers to the input data and sources consulted, stored by reference or hash, not in cleartext. | Reconstructs what the system saw without copying sensitive data into the trail. | Art. 12(3)(b) and (c): reference database, input data |
| Action | The output produced or the tool call made, with its target system and result. | Links the model output to its consequence in the workflow. | Art. 12(1): automatic recording of events |
| Human verification | Identity of the verifier, decision taken (approve, reject, override) and reason where given. | Evidences human oversight as an event, not as an intention. | Art. 14(4)(d) and 12(3)(d): persons who verified |
| Timestamp | Start and end time from a synchronized clock, in UTC. | Establishes the period of use and the order of events. | Art. 12(3)(a): period of each use |
| Hash chain | Hash of this record combined with the hash of the previous record. | Makes tampering detectable by anyone holding the export. | No article names it; it makes the record usable as evidence |
Fields, content and purposes are those of Reference Architecture v1.0, section 4, published on 25 September 2026 under CC BY 4.0. Article 12(3) sets its 4 minimum items for remote biometric identification systems only; for other high-risk systems, Article 12(2) sets the purposes and leaves the fields to the provider.
4 provisions decide what a high-risk system must leave behind.
Article 12 is a design duty on the provider: the system itself records events over its lifetime. Articles 19 and 26 are retention and use duties, on the provider and on the deployer. Regulation (EU) 2026/1744 changed none of their wording; it moved their application date.
| Provision | Who | What it requires | Applies from |
|---|---|---|---|
| Article 12(1) and (2) | Provider, by design | Automatic recording of events over the lifetime of the system, enabling 3 uses: spotting risk situations or substantial modifications, post-market monitoring under Article 72, and the deployer's monitoring under Article 26(5). | 2 December 2027 (Annex III) · 2 August 2028 (Annex I) |
| Article 12(3) | Provider of remote biometric identification systems | At a minimum: the period of each use, the reference database, the input data that led to a match, and the persons who verified the results. | 2 December 2027 |
| Article 19 | Provider | Keep the logs under its control for a period appropriate to the intended purpose, of at least 6 months. Financial institutions keep them within their financial services documentation. | 2 December 2027 (Annex III) · 2 August 2028 (Annex I) |
| Article 26(5) | Deployer | Monitor operation on the basis of the instructions for use; inform the provider and the market surveillance authority of a risk and suspend use; report a serious incident. | 2 December 2027 (Annex III) · 2 August 2028 (Annex I) |
| Article 26(6) | Deployer | Keep the logs under its control for a period appropriate to the intended purpose, of at least 6 months, unless other Union or national law provides otherwise. | 2 December 2027 (Annex III) · 2 August 2028 (Annex I) |
The articles that read the trail.
3 more provisions do not create the record but depend on it. When one of them is invoked, the answer comes from the trail or it does not come.
Article 73 · Serious incidents
A serious incident is reported not later than 15 days after the provider or deployer becomes aware of it, 2 days for a widespread infringement or a critical infrastructure incident, 10 days in the event of a death. The timeline of the incident is read from the timestamps.
Article 86 · Right to explanation
A person subject to a deployer's decision based on an Annex III high-risk system may obtain clear and meaningful explanations of the role of the AI system and the main elements of the decision. The action and human verification fields hold them.
Article 72 · Post-market monitoring
Providers establish and document a post-market monitoring system. The logs are one of the 3 purposes Article 12 assigns to recording; model and version tie each event to the release that produced it.
Dates. Regulation (EU) 2026/1744, in force since 27 July 2026, replaced Article 113(c): Chapter III, Sections 1 to 3, which hold Articles 12, 14, 19 and 26, apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems. Before that amendment, Annex III systems were due on 2 August 2026.
Standards. On 23 October 2026, no harmonised standard on logging is cited in the Official Journal. ISO/IEC 24970, AI system logging, and prEN 18229-1, the logging part of the CEN-CENELEC trustworthiness framework, are both at the approval stage.
This is not legal advice. Whether a system is high-risk, and which role an organization holds for it, is a question for counsel.
6 months is the floor in the Act, not the design target.
The Act sets minimums and defers to other law, data protection first. Logs and documentation follow different clocks.
| What | Who keeps it | Minimum | Source |
|---|---|---|---|
| Automatically generated logs | Provider | At least 6 months, appropriate to the intended purpose | AI Act, Article 19(1) |
| Automatically generated logs | Deployer | At least 6 months, appropriate to the intended purpose | AI Act, Article 26(6) |
| Logs of financial institutions | Provider or deployer | Within the documentation required by financial services law | AI Act, Articles 19(2) and 26(6) |
| Technical and quality documentation | Provider | 10 years after placing on the market or putting into service | AI Act, Article 18(1) |
| The audit trail we operate | Per contract | 12 months minimum | Our Trust Center |
Personal data in a trail is still personal data. Storing inputs by reference or hash keeps the record complete while the data itself stays where its retention rules apply.
6 properties a buyer can test, and the test that decides.
Written at the moment of action
The system writes the record as it acts. A trail rebuilt from scattered logs in the week before an inspection is documentation, not audit.
One identity per actor
Every agent and operator acts under an identity from the enterprise identity provider. A shared service account makes attribution impossible.
Append-only and chained
No record is edited or deleted; each carries the hash of the one before, so a gap or an alteration shows.
Inputs by reference
The trail points to what the system read without copying sensitive data in cleartext.
One clock
Start and end times come from a synchronized clock, in UTC, so events from several systems line up.
Exportable as is
A scoped extract for one system and one period leaves with its chain hashes, so the recipient verifies integrity without trusting the sender.
The test. Name a past decision and a period, then request the regulator export. Check the 9 fields and recompute the hash chain yourself. Pass: every field is present, the chain verifies, and nobody assembles the file by hand.
The questions asked about AI audit trails.
What is an AI audit trail?
The append-only record, written by the system at the moment of each action, of who or what acted, with which model and version, under which policy, on which inputs, with which human verification and when. It lets anyone reconstruct and check a decision without assembling logs after the fact.
Does the EU AI Act require an audit trail?
For high-risk systems, yes in substance. Article 12 requires the automatic recording of events over the lifetime of the system, and Articles 19 and 26(6) require providers and deployers to keep those logs for at least 6 months. The Act does not use the term audit trail and does not list fields, except for remote biometric identification.
When do the logging duties apply?
From 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for Annex I systems, since Regulation (EU) 2026/1744. The wording of Articles 12, 19 and 26 did not change, so a system built today without the record is a system to rebuild later.
How long must AI logs be kept?
At least 6 months under Articles 19 and 26(6), for a period appropriate to the intended purpose, unless other Union or national law, in particular data protection law, provides otherwise. Financial institutions keep them within their financial services documentation. Our engagement baseline is 12 months minimum.
Who keeps the logs, the provider or the deployer?
Both, each for the logs under its control. The provider builds the recording into the system and keeps its logs under Article 19; the enterprise that runs the system keeps its own under Article 26(6). A company that builds and runs its own system holds both duties.
Does an audit trail store personal data?
It stores identities and decisions, and should point to inputs rather than copy them. Inputs kept by reference or hash leave the data where its own retention rules apply, which Articles 19 and 26(6) preserve.
Reference documents and primary sources.
Every article, date and duration on this page comes from the sources below, read on 23 October 2026.
Reference documents
- AI Operating Layer Reference Architecture v1.0 4 planes, 4 testable controls and the 9-field record.
- Enterprise AI Governance Framework v1.0 15 controls with owners, cadences, evidence and EU AI Act hooks. CC BY 4.0.
- AI governance Why governance is architecture: policy engine, human oversight loop, audit trail.
- Trust Center Retention, sub-processors and the documents we share under NDA.
- The audit trail is the product. Briefing of 28 July 2026: what Articles 12, 19 and 26 require in banking, insurance and health.
Primary sources, consulted on 23 October 2026
- EUR-Lex · Regulation (EU) 2024/1689, the AI Act, consolidated text (opens in a new tab) Version of 27 July 2026. Articles 12, 14, 18, 19, 26, 72, 73 and 86. A documentation tool without legal effect.
- Official Journal · Regulation (EU) 2026/1744, Digital Omnibus on AI (opens in a new tab) Regulation of 8 July 2026, published on 24 July 2026, in force on 27 July 2026. New Article 113(c).
- Official Journal · Regulation (EU) 2024/1689, original text (opens in a new tab) 13 June 2024, published on 12 July 2024. Original application dates.
- Official Journal · Commission Implementing Decision (EU) 2026/2274 (opens in a new tab) 12 October 2026. First harmonised standard cited under the AI Act, on quality management, none on logging.
- ISO · ISO/IEC FDIS 24970, AI system logging (opens in a new tab) Under development, final draft ballot opened on 28 August 2026.
How to cite this document.
This URL is permanent and always serves the current version. Each change of substance increments the version and is listed in the changelog below, so a citation stays traceable to the text it quoted.
Preferred citation
Hikari Blue, "AI audit trail: definition, fields and EU AI Act mapping v1.0", 23 October 2026, https://hikariblue.com/glossary/ai-audit-trail
Section anchors are stable: #status, #fields, #mapping, #retention, #requirements, #faq, #references, #cite.
Changelog
v1.0 · 23 October 2026. First public version.
Editorial correction · 25 October 2026: license extended to this page (CC BY 4.0).
License. Published under CC BY 4.0: free to cite, quote and reuse with attribution to Hikari Blue and a link to this page. The license covers Hikari Blue’s text, tables and diagrams on this page; it does not cover third-party data, quotations or legal texts, which keep their own terms, nor the Hikari Blue name and logo, trademarks of UNITED4 LLC.
Export one past decision. See what is missing.
30 minutes with a named partner. We take one AI decision your organization made last month and check it against the 9 fields: which exist today, which are rebuilt by hand, and which are missing. You leave with the gap list, whether or not we work together.
- One past decision, checked field by field
- What is recorded, rebuilt or missing
- Who should own each gap