Mapping LiteLLM Proxy Logs to EU AI Act Article 12 Logging: Gaps and Fixes

What Article 12 requires, and what is commonly inferred

Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to technically allow automatic recording of events over the lifetime of the system. Article 12(2) asks for logging capabilities that provide a level of traceability appropriate to the intended purpose of the system. That qualifier matters: the required depth of the log depends on what the system is for, and the text does not prescribe one schema for every deployment.

The same paragraph ties logging to three purposes. Events must be recordable so that situations that may result in a risk under Article 79(1), or in a substantial modification, can be identified. They must also facilitate post-market monitoring under Article 72 and support the monitoring of operation under Article 26(5). For systems under Annex III point 1(a), the minimum content includes identification of the natural persons involved in verifying results, as referred to in Article 14(5).

Article 19 then requires providers to keep the automatically generated logs, to the extent they are under the provider's control, and to give a competent authority access on a reasoned request. Who controls the logs therefore decides who carries the retention and access duties.

Three things teams often attribute to Article 12 are engineering inferences rather than text: tamper resistance, log signing, and recording an allow, redact or block decision for every interaction. They are sensible ways to make logs credible as evidence and to serve the three purposes above. Treat them as design choices, and label them that way in your own control documentation.

Mapping proxy log categories to Article 12 purposes

The table maps categories of LiteLLM proxy output, not individual field names, because field names and callback payloads depend on version and configuration. Whether the proxy sits inside the high-risk system or is supporting infrastructure is a scoping question for legal review. The gap analysis below applies either way.

• Event-level traceability: Proxy logs typically record request and response metadata and errors per call. Gap: depth is set for debugging, so confirm each record can be tied to the system's intended purpose and to a specific event, not only to aggregate usage.
• Risk and substantial-modification detection (12(2)(a)): Spend, error and callback output can surface anomalies. Gap: nothing records which policy was evaluated or what was decided, so risk-relevant events are hard to separate from routine traffic.
• Post-market monitoring (12(2)(b)): Usage and response metadata give raw material. Gap: retention is whatever the database or callback destination happens to hold, with no defined period or lifetime coverage.
• Deployer monitoring (12(2)(c)): Logs can be exported to the deployer's tooling. Gap: the deployer needs a way to collect, store and interpret them, and ownership of that path must be explicit.
• Identification of natural persons (Annex III 1(a)): Proxy logs attribute traffic to keys, users or teams. Gap: a key or user ID is not a record of the person who verified a result under Article 14(5).

The gaps, in order of how often they matter

Integrity comes first. Proxy logs usually live in an operational database or in the destination a callback writes to, where administrators can alter or delete rows. Article 12 does not state a tamper-resistance requirement, but logs offered to a competent authority are only useful if you can show they were not changed. This is an engineering requirement you impose on yourself.

Retention is second. Article 19 sets provider retention duties for logs under their control, and recitals refer to recording over the lifetime of the system. Operational logs are normally pruned for cost and performance reasons. Set retention deliberately, against the period in the official text that applies to your role, and make sure pruning jobs cannot silently undercut it.

Completeness and attribution follow. A proxy sees model traffic, but human verification of results often happens elsewhere, in a review tool or a downstream application. If that step is not recorded with the identity of the person, the Annex III point 1(a) item is not met, however good the proxy log is. Map where verification occurs and carry a person identifier into the record.

The last gap is policy decisions. Callback output can include the result of a check, but a record of which policy applied to each interaction and tool call, and the decision taken, is generally not something a debugging log produces. It is not named in the Article 12 text either. It is nonetheless the evidence that makes traceability and monitoring answerable in practice.

Fixes, from configuration to architecture

Start with what configuration can change, then decide what needs a separate system.

Configuration and pipeline fixes: enable the callbacks that emit the fields you need, standardise correlation identifiers across proxy, application and review tools, and decide explicitly what is stored or redacted in prompts and responses. Redaction is a trade-off, because content that is removed from the log cannot support later investigation, while retained content widens data protection exposure.

External storage fixes: forward logs to a write-once or versioned store with restricted delete rights, separate from the proxy's own database. Add hash chaining or signing at the point of export if you need to demonstrate integrity. Forward to a SIEM for alerting and correlation, and keep the immutable copy as the record. Apply a retention policy at the storage layer, not in the proxy.

Process fixes: assign ownership of each log set between provider and deployer, document how deployers collect, store and interpret logs, and define how you respond to a reasoned request for access under Article 19(2).

These changes make the logs durable and attributable. They do not make the proxy a source of policy decisions, because the proxy log only records what the proxy was configured to emit.

• Emit and correlate: Enable required callbacks and carry one correlation ID across proxy, application and human review.
• Export immutably: Write to separate write-once storage with restricted deletion and optional hash chaining or signing.
• Retain deliberately: Set retention at the storage layer against the period that applies to your role.
• Record the verifier: Capture the natural person who verifies a result where Annex III point 1(a) applies.
• Assign ownership: Document who controls each log set and who answers an authority request.

Gaps configuration alone cannot close

Two gaps survive even a well-tuned proxy with immutable export. The first is the natural person who verifies a result. That fact lives in a human workflow, so it has to be captured where the review happens and joined to the interaction record. The second is the policy decision. If policy is checked after the fact, from logs, the record shows what happened but not what was permitted at the moment of the call. Evidence that a policy applied and an outcome was chosen has to be produced by the component that applies the policy, at the time it applies it.

Timing is a planning variable as well. The general date of application under the Regulation is 2 August 2026, but as of November 2026 a later act, published in the Official Journal on 24 July 2026, states that this date should not be maintained for the high-risk obligations in Chapter III Sections 1 to 3, which include Article 12. Plan remediation against the adopted application dates for your systems, and treat the logging design as lead-time work, since storage, retention and identity capture touch several teams.

Enforcing policy in the execution path

Trussed addresses the policy-decision gap, not the proxy's role as a router. It enforces policy in the execution path across models, agents, tools and MCP servers, and applies allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. Because the decision is enforced at runtime, not reviewed after the fact, the audit-ready evidence records which policy applied and what was decided, and is mapped to the EU AI Act among other frameworks.

The deployment is self-managed in the customer cloud, with configurable retention and data residency, which bears on the storage and retention decisions above. In production, Trussed has run continuously for more than 18 months in a regulated enterprise and generates more than 30 GB of audit evidence per day. It records decisions at the level of individual interactions and tool calls. It does not replace your immutable store, your SIEM or the recording of human verifiers in your own review workflow.