The EU AI Act, a comprehensive 144-page document, introduces essential logging requirements for developers of AI agents. These stipulations are spread across four pivotal articles, each interrelated, guiding developers on how to align with the new regulations. This article breaks down the critical components of the Act, including classifications, obligations, and potential gaps.

Classification of AI Agents

While the term “AI agents” is not explicitly mentioned in the EU AI Act, the classification hinges on the system's functionality. If an AI agent is involved in high-stakes processes like scoring credit applications, filtering job resumes, determining healthcare benefits, setting insurance prices, or managing emergency call triage, it is categorized as high-risk under Annex III of the Act. However, Article 6(3) provides a potential exemption; if the system does not materially influence decision outcomes, it may not fall under the high-risk category. Nevertheless, arguing this exemption for an agent that autonomously interacts with tools and processes results is challenging.

Moreover, general-purpose AI models carry distinct responsibilities outlined in Chapter V. While the model itself may not be deemed high-risk, the system utilizing it becomes high-risk once deployed in a high-risk context. Here, the model provider retains its obligations from Chapter V, while the integrator assumes high-risk provider responsibilities as per Article 25.

Key Articles on Logging

Article 12 is central to the logging requirements, stating that high-risk AI systems must be capable of automatically recording events throughout their operational lifespan. This mandates that logs are generated by the system itself, eliminating the possibility of relying on manual documentation. The term 'lifetime' indicates the need for continuous logging from deployment to decommissioning, not merely during the current version's lifecycle.

Further, Article 12(2) categorizes the logs into three essential areas: instances where the system may pose risks or undergo significant modifications, data necessary for post-market monitoring, and information required for operational oversight by deployers. While the regulation does not prescribe specific formats or fields, it emphasizes these three purposes.

In addition, Article 13 mandates that developers provide thorough documentation on how deployers can collect and interpret these logs. This aspect should be seen as a technical integration manual for the logging infrastructure rather than a compliance guideline.

Articles 19 and 26 stipulate a minimum retention period of six months for logs. Financial services firms may integrate AI logs into their existing regulatory documentation, while other sectors must retain logs for at least six months, with potential extensions based on specific industry regulations.

Challenges of Standard Logging

AI agents typically engage with multiple tools, delegate tasks to sub-agents, receive responses from language models, and derive final outputs. Standard application logging can manage this complexity with ease. However, the real challenge arises later when a regulator requires proof that logs have not been altered. Since application logs are stored on controlled infrastructure, there is a risk of modifications going unnoticed.

Although Article 12 does not explicitly call for 'tamper-proof' logs, if logs can be discreetly changed without detection, their evidentiary value diminishes significantly. This poses a considerable issue for high-risk systems.

To address this vulnerability, I have explored the implementation of cryptographic signing for agent logs. This strategy involves signing each action taken by the agent with a key that the agent itself does not possess, creating a chain of signatures that connects each action. The receipts for these actions are stored in a secure manner, ensuring that any alteration breaks the chain visibly.

The key principle is that the signing key exists outside the agent's trust boundary, every action receives a receipt, and these receipts collectively form a verifiable chain. Regardless of whether one employs NIST FIPS 204 post-quantum signatures or another method, adherence to these principles will likely meet the requirements set forth in Article 12.

No Established Standards

As of now, there is no finalized technical standard for the logging requirements outlined in Article 12. Two drafts worth monitoring include prEN 18229-1, which addresses AI logging and human oversight, and ISO/IEC DIS 24970, focusing on AI system logging. Neither of these drafts has reached completion.

Developers are preparing for regulations that outline expected outcomes without specifying implementation methods. Teams that proactively establish robust logging practices will be better positioned when the standards are finalized. In contrast, those who delay may find themselves under pressure to retrofit solutions.

Upcoming Deadlines and Possible Penalties

The obligations outlined in Annex III are set to take effect on August 2, 2026. The Commission has proposed a delay through the Digital Omnibus package, potentially pushing the deadline to December 2027. However, as of now, the enforceable date remains August 2026.

Failure to comply may result in penalties reaching up to 15 million euros or 3% of global annual turnover, whichever figure is higher. While this penalty structure applies to all entities, Article 99 emphasizes that penalties should be proportionate and dissuasive, allowing national authorities to consider the size and economic viability of the company. Consequently, startups and SMEs may face lesser fines than the maximum stipulated, despite the unchanged penalty framework.

Essential Questions for Developers

• Can your system automatically generate logs at every decision point?
• Are those logs secure against tampering?
• Can you retain them for six months in a format accessible to regulators?

If the answers to these questions are negative, the deadline of August is approaching rapidly.

Source: Help Net Security News