AI audit logging under the EU AI Act

AI Act Article 12 does not ask for a separate compliance system. Instead, it requires that the records you already generate be complete, unalterable, and retrievable during an audit. Consequently, an LLM proxy is where those records get produced.

The Act came into force on 1 August 2024 as Regulation (EU) 2024/1689. Its record-keeping obligations under AI Act Article 12, its accuracy and cybersecurity obligations under Article 15, and its retention obligations under Article 17 apply to providers and deployers of high-risk AI systems from 2 August 2026. In practice, if you are shipping AI into a regulated European workflow such as hiring, credit, education, essential services, or law enforcement, you will be answering these questions from an auditor by then. Meanwhile, if you are shipping AI into any European workflow and want a defensible position, you will want the same records regardless of whether your use case is technically classified as high-risk.

This page maps each of those articles to the log lines an LLM proxy needs to emit at request time. It also lists what auditors actually ask for, in the order they ask for it.

What AI Act Article 12 actually requires

AI Act Article 12 titled "Record-keeping" is short and specific. Paragraph 1 states that "High-risk AI systems shall technically allow for the automatic recording of events ('logs') over the lifetime of the system." In addition, paragraph 2 defines the purpose: those logs must enable the identification of situations that may result in the AI system presenting a risk under Article 79, must facilitate the post-market monitoring referred to in Article 72, and must enable the monitoring of operation under Article 26.

That is a lot to unpack. Broken down:

• The recording must be automatic, not manual and not sample-based. Every relevant event has to be captured.
• The recording must run over the lifetime of the system, which means from first inference to decommissioning.
• The records must be useful for three specific purposes: risk identification, post-market monitoring by the provider, and operational oversight by the deployer.

In addition, AI Act Article 12 paragraph 3 goes further for a specific subclass of high-risk systems (biometric identification), requiring logs of the period of each use, the reference database checked, the input data that led to a match, and the identity of the natural persons involved in verifying the result. However, most enterprise LLM use is not biometric, so paragraph 3 does not usually apply, although paragraph 1 always does.

Every engineer should remember one line: AI Act Article 12 does not describe a report format. Instead, it describes an evidence stream. Your obligation is to generate the events. As a result, the regulator does not care whether they end up in CloudWatch, a Postgres table, or a WORM bucket, as long as they exist, remain unaltered, and can be produced on request.

Article 17 and how long you keep the records

Article 17 titled "Quality management system" contains, among other things, the record-retention obligation. Paragraph 1(m) requires providers to keep documentation "for a period ending 10 years after the AI system has been placed on the market or put into service." The same duration applies to logs. So the shortest defensible answer to "how long do we keep the logs?" is ten years from the moment your AI system stopped being available on the market.

A deployer, by contrast, has a shorter default under Article 26 paragraph 6: "for a period appropriate to the intended purpose of the AI system, of at least six months, unless provided otherwise by applicable Union or national law, in particular Union law on the protection of personal data." Six months is a floor, not a ceiling, and if any part of the record is personal data your GDPR retention analysis applies on top.

The practical consequence is that an LLM proxy has to preserve records durably from the moment they are written. Records that get truncated after 30 days on cost grounds are non-compliant.

Article 15 and the accuracy record

Article 15 titled "Accuracy, robustness and cybersecurity" is often read as a documentation obligation. It is also a logging obligation. Paragraph 3 requires that high-risk AI systems be "resilient against errors, faults or inconsistencies" and that the levels of accuracy and their metrics be declared. To be able to declare those levels honestly and to detect drift, you need production telemetry: prompt classes, response classes, refusal counts, error counts, and error taxonomies. That is a second stream of logs that lives alongside the Article 12 stream.

Ciralgo emits Article 15 records as aggregate counters, not per-request logs, because the accuracy metric is a rate, not an event. A daily rollup of "how many completions succeeded, refused, timed out, or returned malformed output" is enough for the vast majority of deployments.

The three record types Ciralgo emits at request time

Every LLM call routed through Ciralgo produces up to three records, each mapping to a specific article in the Act.

UsageRecord captures the fact that an inference happened, and everything Article 12 requires to identify who did what and when. One record per completed request. Emitted at response time, never before, so failed and aborted requests carry an explicit terminated status.

GovernanceEvent captures policy decisions. Every time the proxy applied a jurisdiction rule, blocked a provider, redacted a prompt, or forwarded a request under an explicit override, a GovernanceEvent is written. This is the log that answers auditors' hardest question: "how do you know the model you selected was allowed?"

ProviderRoutingDecision captures the reasoning behind provider choice. This is separate from GovernanceEvent because provider selection can be policy-driven (rule fired), preference-driven (workload owner chose), or fallback-driven (primary provider unavailable). Auditors care about the difference.

Together, the three records let you reconstruct any completed request in three sentences: what was called, why that provider, and which policies applied.

What is in a UsageRecord

The schema is stable and versioned. Every field maps directly to a requirement in the Act.

• record_version — schema version, monotonically increasing.
• record_id — ULID, unique per record.
• request_id — ULID, unique per request, correlates the three record types.
• system_id — the AI system this call belongs to, as registered by the deployer.
• deployer_id — the tenant that owns the system.
• team_id, project_id, workflow_id — attribution triple. Article 12 paragraph 2 requires that logs support Article 26 oversight. Article 26 is the deployer article. Without these three fields, a deployer cannot demonstrate oversight.
• user_id — the natural person (or service account) that made the call, hashed. Optional per deployer policy.
• timestamp_utc — ISO 8601 with millisecond precision.
• provider, provider_region, model — the actual endpoint that answered.
• input_class, output_class — the automatic classification the proxy assigned. Not the raw prompt.
• prompt_hash, response_hash — one-way hashes of the material, so identical prompts can be correlated across records without storing the prompt itself.
• latency_ms, input_tokens, output_tokens, cost_eur — operational fields required for Article 15 accuracy tracking and Article 26 cost oversight.
• terminated — one of success, refused_by_provider, blocked_by_policy, client_disconnected, provider_error, timeout.
• retention_class — retention policy identifier that this record inherits. The record does not carry its own expiry; the retention class does.

Fields that are conspicuously absent: the raw prompt and the raw response. Ciralgo does not store either by default. Both are hashable, both are reconstructable via the provider's own logs if needed, and both are personal data if they mention people. The proxy stores enough to answer any Article 12 question without storing enough to create a new GDPR exposure.

The GovernanceEvent taxonomy

A GovernanceEvent has a discrete event type. The taxonomy is small on purpose. If your event does not fit, the audit narrative gets fuzzy.

• POLICY_APPLIED — a rule matched and modified the request. Includes the rule name and version.
• PROVIDER_BLOCKED — a provider was refused for this request. Includes the reason (jurisdiction, allowlist, capacity, other).
• PROVIDER_ALLOWED_BY_OVERRIDE — a normally-blocked provider was permitted under an explicit override. Includes the override name, the person or role that authorised it, and the expiry.
• REDACTION_APPLIED — the prompt or response was redacted before or after transmission. Includes the detector name and the counts by category.
• RETENTION_CLASS_ASSIGNED — the record was routed into a specific retention class. Includes the class and the effective expiry.
• CONSENT_RECORDED — the request carried explicit consent evidence (typical in health, education, HR).

Auditors ask for the count and distribution of these events across a period. A distribution that looks reasonable in October and swings sharply in November is a signal that something operational changed. The distribution is the audit trail. Individual events are backup.

What auditors actually ask for during an AI Act Article 12 review

Based on Notified Body practice on the older Medical Device Regulation, and on early feedback from Notified Bodies now scoping AI Act conformity assessments, the sequence tends to be the same.

First, the counts

How many inferences did this AI system run last quarter? How many terminated, and in what proportions? What percentage triggered a policy event? In practice, auditors expect this on demand in a form they can filter.

Second, a sampled reconstruction

Pick five requests at random from the previous quarter. Walk me through what happened: which model was called, why that model was allowed, what policies applied, what came back. Every field mentioned above is a question that needs an unambiguous answer. As a result, this is where records that were "close enough" fall apart.

Third, a change history

Show me the version of the policy in force on the day of one of those five requests. Show me who changed it, when, and to what. Meanwhile, GovernanceEvent references policies by name and version so that this question is answerable.

Fourth, an incident response walkthrough

If your provider had produced a plausibly harmful output on a specific request, how would you have detected it, who would have received notification, and how quickly would the request have been reversed. This is not a log question. Instead, it is a runbook question, and Article 79 makes it a compliance question.

Ciralgo's records are designed to answer questions one, two, and three from a single query interface. However, question four requires you to have a runbook. The proxy can support the runbook. It cannot write it for you.

Retention, access control, and immutability

Records are written once. The retention class assigned at write time drives expiry. Records cannot be edited after emission. If the underlying policy changes, the change produces a new GovernanceEvent, which references the old policy version by hash. There is never a scenario in which an old record retroactively changes meaning.

Access to the records is scoped to the deployer, and within the deployer to a small set of roles: auditor (read-only), compliance officer (read-only, may export), and platform administrator (may query for operational purposes, cannot modify content). Ciralgo never has default read access to a deployer's records. Ciralgo staff access requires an explicit customer-signed break-glass, which itself produces a GovernanceEvent on the customer's own log.

Records can be exported by the deployer at any time to any storage the deployer prefers. Article 12 does not require Ciralgo to be the retention system. The obligation to retain lives with the provider and deployer. Ciralgo produces the records; the customer keeps them.

Where this fits in the wider AI Act stack

Logging is one of seven obligations imposed on providers of high-risk AI systems by Chapter III Section 2 of the Act. The others are risk management (Article 9), data and data governance (Article 10), technical documentation (Article 11), transparency and information to deployers (Article 13), human oversight (Article 14), accuracy, robustness, and cybersecurity (Article 15), and the quality management system (Article 17). Ciralgo touches all seven, but only Articles 10, 12, 13, and 15 in a directly logs-producing way. The other three require documentation you produce yourself, informed by the records Ciralgo generates.

For deployers, the corresponding article is Article 26. Paragraph 6 makes the deployer responsible for retention of the automatically generated logs, "to the extent such logs are under their control". If your deployer contract with Ciralgo assigns retention to Ciralgo, the "under their control" test still applies because the deployer chose the retention configuration. Article 26 is not something you can outsource by clicking a checkbox.

Frequently asked questions about AI Act Article 12

Is Ciralgo alone sufficient to make our AI system compliant with the AI Act?

No. Compliance is a shared responsibility. Specifically, Ciralgo produces the operational evidence for Articles 10, 12, 13, and 15. Meanwhile, your organisation still owns the risk management system, the technical documentation, the human oversight process, and the quality management system. As a result, the proxy generates records; your compliance function turns records into a defensible conformity assessment.

Do we need to keep the raw prompt and raw response?

AI Act Article 12 does not require it. Article 17 does not require it. Furthermore, GDPR frequently prohibits it. Consequently, the pragmatic default is to keep hashes and classes and not the raw material. However, where you have a specific business or contractual reason to keep raw content, you configure that per system and accept the corresponding data protection obligations.

What about general-purpose AI models used through Ciralgo?

Chapter V of the Act addresses providers of general-purpose AI models. Specifically, those obligations sit with the model provider (OpenAI, Anthropic, Mistral, and so on), not with you. Your obligation is to consume the model responsibly, which under Article 26 and Article 27 for high-risk deployment means running the same logging and oversight you would run for a bespoke system. In practice, Ciralgo does not distinguish between GPAI and non-GPAI at the record level.

How does this interact with a GDPR right-to-be-forgotten request?

A hashed record with no personal data attached does not usually trigger erasure. However, where a user_id field is present and your DPO deems the request personal data, Ciralgo supports selective erasure on a per-record basis using the deployer's own signed key. In addition, the GovernanceEvent taxonomy includes the erasure action so the audit trail remains intact.

What is the default retention?

Ten years for records associated with an active AI system, in line with Article 17 paragraph 1(m). Deployers can also opt for shorter retention on individual retention classes where the six-month Article 26 floor applies and no other Union law extends it. By default, the Ciralgo setting assumes provider-side obligations because those are longer and safer.

Can we export the records into our own SIEM?

Yes, via a signed streaming export or a batch export. In addition, records are available through a REST API. Auditors accept whichever format your organisation already uses for evidence retention. Ultimately, the important property is that the records were generated correctly at request time; where they live afterwards is a customer decision.

How is this different from what OpenAI or Anthropic logs on their side?

Provider-side logs answer the question "what did the model do." AI Act Article 12, by contrast, asks "what did the deployer do." Those are different questions. Specifically, a provider log has no way to record the deployer's team, project, workflow, redaction decisions, or policy applications. Meanwhile, a proxy log records the deployer context, which is the missing half of any AI Act audit.

Related reading

• What is an EU-hosted LLM proxy?
• Connecting to the Ciralgo proxy
• Provider routing governance
• Ciralgo security whitepaper

Last refreshed: 9 July 2026. This page is reviewed quarterly against the Official Journal text of Regulation (EU) 2024/1689.