How to Implement AI Logging and Auditability for EU AI Act Compliance
Article 12 of the EU AI Act requires high-risk AI systems to automatically generate logs throughout their operation. These logs must capture sufficient information to reconstruct AI decisions after the fact, support post-incident investigations, and enable regulators to verify compliance. Manual or partial logging approaches will not meet this standard at scale.
Article 12 requires that high-risk AI systems have logging capabilities that enable automatic recording of events during their operation, including at minimum the period of operation, the reference database against which input data was checked, input data that led to an output, and the identity of natural persons involved in verification. Article 12.1 specifies that logs must be kept for a period of at least six months unless different requirements apply under other EU law, such as GDPR.
Why Manual Logging Is Insufficient at Scale
In low-volume contexts, it might be technically possible for a human operator to maintain a manual record of AI decisions. In any realistic production deployment, this is not feasible. A customer-facing AI system may process thousands of requests per hour; an HR screening tool may evaluate hundreds of candidates in a week; a fraud detection system may score millions of transactions per day.
Manual logging also introduces integrity risks: records can be altered, selectively maintained, or omitted. Article 12 is designed to produce a reliable, tamper-resistant audit trail. This is a requirement that manual processes cannot meet. Logging must be automated and must operate as a system-level control, not a human process.
What Must Be Logged Under Article 12
The minimum log content required for high-risk AI systems includes:
Step-by-Step: Implementing Compliant AI Logging
Identify Which Systems Require Logging
Article 12 logging requirements apply to high-risk AI systems as defined by Annex III and Article 6. Complete your risk classification exercise first (see risk classification guide) and produce a definitive list of systems in scope. Not every AI system requires Article 12-compliant logging, though logging all AI systems is generally good practice for governance purposes. Focus compliance resources on confirmed high-risk systems.
Select a Logging Architecture
Four primary architectural approaches exist for AI logging. Choose based on your deployment model and operational constraints:
API Gateway Logging
If AI systems are accessed via APIs (whether internal model deployments or third-party AI services), logging at the API gateway layer captures both inputs and outputs without requiring changes to the AI model itself. This is architecturally clean and provides a natural audit boundary. The gateway can log request and response payloads, timestamps, caller identities, and latency. This approach also works for third-party AI services where you cannot modify the model.
Middleware / Proxy Logging
A sidecar or proxy pattern intercepts traffic between the application and the AI model, logging all exchanges. This works well in containerised environments and does not require modifications to either the application or the AI model code.
Model-Level Instrumentation
Instrumentation code embedded within the model serving layer logs decisions directly. This allows the richest data capture (including internal confidence scores, intermediate activations where relevant) but requires access to and modification of the model serving code. Not applicable to third-party SaaS AI tools.
Dedicated AI Observability Platform
Purpose-built observability platforms for AI systems provide structured log collection, storage, and analysis with compliance reporting built in. These platforms typically combine several of the above approaches and offer purpose-built features for AI audit trails.
Capture the Minimum Required Fields
Implement log collection for all fields listed in the section above. For inputs, consider whether full payloads should be stored or whether a hash plus key metadata is sufficient. Storing full inputs raises GDPR questions if inputs contain personal data. Consult your data protection officer on the appropriate approach. In some cases, capturing a deterministic representation of the input (sufficient to identify whether the same input was provided again) may be preferable to storing the full payload.
Secure and Preserve Log Integrity
Logs must be protected against tampering. Store logs in write-once or append-only storage with access controls that prevent modification. Apply integrity controls such as cryptographic hashing or immutable storage solutions. Implement access logging for the log store itself; who has accessed or modified logging configuration should itself be recorded. Retention must be at minimum six months, but may need to be longer if other regulatory requirements (GDPR, sector-specific regulations) require longer retention.
Test Log Completeness
Before relying on your logging implementation for compliance, test it deliberately. Simulate a production incident: can you reconstruct exactly what input was provided, what the AI system produced, at what time, and by which operator? Run through a set of test scenarios and verify that all required fields are present and accurate in the resulting logs. Identify and address any gaps before going live with high-risk AI systems.
Storage and Operational Considerations
Structured formats: Store logs in structured formats (JSON, Parquet, or equivalent) that can be queried programmatically. Unstructured text logs are difficult to analyse at scale and complicate regulatory investigations.
Searchability: Logs must be searchable by key fields: time range, system version, operator, and subject identity (where applicable). Index logs on these fields to enable efficient investigation queries.
Volume planning: High-throughput AI systems can generate very large log volumes. Plan storage capacity accordingly and implement compression and tiered storage strategies to manage cost without compromising retention compliance.
GDPR intersection: Where AI logs contain personal data (names, identifiers, or other data from which individuals can be identified), retention must be compatible with your GDPR retention policies. Logging personal data in AI audit trails requires a documented lawful basis and must be disclosed in your privacy notice.
API-Layer Logging as a Natural Audit Trail
For organisations that access AI capabilities via APIs, whether internal model deployments or external AI services, capturing inputs and outputs at the API layer provides a particularly natural and robust foundation for Article 12 compliance. The API represents the interface between the application and the AI model; logging at this layer captures everything the model receives and returns, independent of implementation details. This approach is especially valuable for third-party AI services where model-level instrumentation is not available.
← Back to Assessment