AI Logging: What to Log

Most enterprise logging architectures were designed for deterministic applications: a user logs in, performs an action, and the log records who, what, and when. A generative AI system or an autonomous agent breaks this simple model. The “what” becomes a natural-language prompt—which may be modified during the session by an injection—and the “who” can be a chain of delegation involving a user, an agent, and the tools that the agent, in turn, invokes. Most current logging stacks do not capture any of these specific elements.

Logging: What Is It?

Before examining what AI is changing, we must return to the standard definition in France. The CNIL describes a logging system as the recording, in log files, of three categories of events: users’ business activities (application logs), technical interventions—including those by administrators—and security-related anomalies and events (technical or “system” logs).

Its recommendation of October 14, 2021 (Resolution No. 2021-122) specifies the purpose of these mechanisms: to ensure the traceability of access and actions by users authorized to access information systems and, consequently, of the processing of personal data carried out within those systems. In other words, to know who accessed which data, on which system, and at what time. This record-keeping is not merely an optional best practice: it directly contributes to compliance with the security principle set forth in Articles 5 and 32 of the GDPR.

According to the CNIL, this data is used to detect and investigate incidents, intrusions, or misuse by an authorized individual. A log is not a compliance document to be archived; it is an investigative tool.

The CNIL recommends that log data be subject to automated analysis to enable the rapid detection of unauthorized use. Simply storing the data is not enough, and this requirement was already established in 2021, well before the AI Act.

This definition was developed for deterministic processing, where the authorized user and the logged action are two clearly identifiable entities. It is precisely this pairing that generative AI systems and autonomous agents blur, which is why a log stack compliant with the CNIL framework may remain structurally unaware of what an agent is actually executing.

What the EU AI Act Actually Requires

Article 12 of the EU AI Regulation requires that high-risk AI systems have technical capabilities that enable the automatic logging of relevant events throughout their entire lifecycle. These capabilities must ensure a level of traceability appropriate to the system’s purpose, in particular to identify situations that may pose a risk, to facilitate post-market surveillance, and to enable the deployer to monitor the system’s operation.

Article 19 requires the provider to retain automatically generated logs under its control for a period appropriate to the purpose of the system, of at least six months, unless Union law or national law provides for a different or longer period. Specific sector-based rules may also apply, particularly in the field of financial services.

Article 18 establishes a separate obligation: the supplier must make the technical documentation and several other conformity documents available to the competent national authorities for a period of ten years from the date the system is placed on the market or put into service. It is therefore incorrect to calculate this period from the date the system is withdrawn from the market.

Calendar-related note: The initial schedule did not provide for uniform implementation across all high-risk systems as of August 2, 2026. The Digital Omnibus on AI, definitively adopted by the Council on June 29, 2026, establishes, among other things, a deadline of December 2, 2027, for high-risk AI systems covered by Article 6(2) and Annex III, as well as a deadline of August 2, 2028, for systems covered by Article 6(1) and Annex I.

This postponement does not negate the importance of implementing a structured and proportionate logging system now: it is a measure to prepare for compliance, oversight, and a potential audit, rather than an additional obligation explicitly imposed by Section 12 prior to the applicable deadline.

What an AI log must contain

Most traditional application logging stacks capture an HTTP request, an authenticated user, and a return code. This is insufficient for an AI system. A usable log must include:

• The complete identity of the action chain: the user or system that initiated the request, the agent that processed it, and any tools or subagents invoked in sequence.Traceability of this delegation requires that each link in the chain have its own identity and a dedicated API key
• The prompt and the response; or, for use cases where the full content is too sensitive to be stored in plain text, a hash that allows it to be reconstructed or verified without storing the source data
• The status of the applied policy: Which filtering or control rules were active at the time of the interaction (an aspect that most current architectures overlook, even though it is essential for establishing that a control was indeed in effect at the time of the incident)
• The data or databases consulted—particularly for a RAG system—and the sources that contributed to the generated response, to enable tracing a hallucination or an error back to its source
• The timestamp and period of use, with integrity protected against any subsequent modification (cryptographic signature or chaining of records).

Why the integrity of the log is just as important as its content

A log that can be modified retroactively has no evidentiary value in the event of an investigation or regulatory audit. The most robust architectures follow an “append-only” principle (additions only, with no possibility of retroactive modification) and include protection against tampering, such as cryptographic signatures or certified timestamps. It is this level of rigor that distinguishes a simple application log file from audit evidence that is defensible before a regulatory authority.

Use logs for investigations, not just store them

A large volume of logs that is stored but cannot be analyzed is of no use when it matters most. Two uses must be anticipated from the design phase:

• Near-real-time anomaly detection: identifying agent behavior that deviates from its usual scope (access to unusual systems, abnormal query volume) before an incident escalates.
• Post-incident reconstruction: In the event of a confirmed incident, be able to quickly answer three questions: What data was exposed, through which path, and from which initial identity. This capability depends entirely on the level of detail in the fields captured at the time of the interaction; it cannot be reconstructed afterward if the logs are too sparse.

For agents connected to external tools via connectors, each tool call must be logged as a separate event—not just the initial interaction with the model—otherwise, visibility into what the agent actually executed on behalf of the user will be lost.

FAQ: AI Logging, AI Logs, Agent Traceability, and the AI Act

Organizing Logging for Your AI Systems

Our experts assess your current logging coverage and assist in implementing a log architecture that is compliant and useful for investigations, consistent with your AI governance and your overall AI security strategy .

Would you like to discuss your project or assess your needs? Contact our experts.