The Agent Audit Trail: what the EU AI Act requires you to log from 2 August 2026

From 2 August 2026 the EU AI Act requires a traceable record of what a high-risk AI system did. For an enterprise deploying agents across its own estate, that means being able to show which agent touched which record, when, and under whose authority. This briefing, for CIOs, CTOs and enterprise architects, sets out what the Act actually asks for, why the model vendor cannot produce it for you, and why point-to-point integration is the wrong place to go looking. The short version: the evidence lives in the integration layer.

The obligation, and the date

Three articles carry the duty, and the penalties are not nominal:

• Article 12 requires a high-risk AI system to “technically allow for the automatic recording of events (logs) over the lifetime of the system”, at a level of traceability appropriate to its intended purpose.
• Article 19 requires the provider to keep those automatically generated logs for at least six months.
• Article 26(6) places the same retention duty on the deployer, for logs under its control – and Article 26(5) requires the deployer to monitor operation, suspend use where a risk appears, and report serious incidents.
• Article 99(4)(e) sets fines for breaching those deployer duties at up to €15m or 3% of total worldwide annual turnover, whichever is higher.

Scope note: these duties attach to high-risk AI systems. The European Commission’s Digital Omnibus on AI, tabled in November 2025, proposed deferring parts of the high-risk regime – confirm the current position with counsel before relying on the date.

The duty lands on the deployer, not the model vendor

Model providers log prompts and completions. That is their record, on their infrastructure, under their retention terms. It is not what a regulator, a data protection officer or an internal auditor is asking for — and Article 26(6) covers logs “under their control”, which means yours.

The question an auditor asks is which records the agent read, what it changed, and under whose authority. A prompt-and-completion log shows what the agent was told and what it said; it does not show what it did to your data. That evidence exists in exactly one place: where the agent meets the enterprise.

Point-to-point integration was never built to be audited

Most connected enterprise systems are joined point-to-point — one system calling another over a bespoke API link written for that pair alone. A link like that exists to move data. Logging was never part of its brief. Where it records anything at all, it is an application log written for a developer debugging one interface: useful for diagnosis, but not an evidentiary record of which identity changed which record, and not retained for six months.

So a point-to-point estate cannot simply be queried for the trail the Act asks for. The trail has to be built — a logging standard agreed, then retrofitted link by link, by the team that owns each one, into code that is already the most expensive part of the estate to change. The work scales with the number of links, not the number of agents, and links grow quadratically with the estate. The published evidence on changing existing code is not encouraging:

• 14.8%–24.4% of fixes to post-release bugs in large production codebases were themselves incorrect and made an impact on end users, and 27% of those incorrect fixes were made by developers who had never touched the source files involved (Yin et al., ACM ESEC/FSE, 2011).
• Accumulated technical debt of ~$1.52 trillion in the US alone, which CISQ describes as “the biggest obstacle to making any changes to existing code bases” (CISQ, 2022).
• 10–20% of the technology budget intended for new products is already diverted to resolving technical-debt issues (McKinsey).
• 98% of enterprises had to rebuild integrations to core applications within the last 12 months, and 60% of the IT project backlog requires integration support (Digibee, 2022 and 2023).

Retrofit means paying twice for every link — once for the connection, again for evidence it was never designed to produce.

What an iPaaS changes

An integration platform as a service replaces bespoke pairwise links with a hub. Each system connects once, through a managed connector, and everything crossing the hub is governed, monitored and logged in one place. Connectors are reused rather than rebuilt, a system replacement is absorbed at a single point, and — the part that matters here — the record of every agent action becomes a property of the platform rather than a project. It exists because the traffic passes through one place, which is also why the marginal cost of making the next agent auditable is close to zero. Independent analysis by Nucleus Research puts iPaaS returns at $3.76 for every $1 invested, with up to 29% lower integration total cost of ownership and 66% faster development (December 2023).

W3 Partnership’s iPaaS is Smarter Integration — UK-hosted, ISO 27001 certified and delivered as a managed service, with the connectors, monitoring and audit trail built and run for you.

The AI Act is not the only clock

Even where an agent falls outside the high-risk classification, other regimes want the same evidence — and unlike the high-risk regime, they already apply. GDPR Article 30 records of processing, Article 5(2) accountability and Article 32 security of processing. The Data Act (Regulation (EU) 2023/2854), applicable since September 2025. DORA (Regulation (EU) 2022/2554) for financial entities. NIS2 (Directive (EU) 2022/2555) for essential and important entities. Each of them wants to know what happened, in an estate where nothing was designed to say.

What the full briefing covers

Section 1, the obligation — Articles 12, 19 and 26 in detail, what an auditor will ask to see, why the duty follows the deployment rather than the model, and the adjacent regimes. Section 2, why the wiring matters — how enterprises actually connect systems today, and the cost of retrofitting an audit function onto links that never had one. Section 3, the iPaaS answer — what an iPaaS is, what changes when the wiring runs through a hub, and an obligation-by-obligation map from each article to the capability that satisfies it. Section 4, Smarter Integration — and an explicit account of what an integration layer does not solve. Every figure cited inline, with full sources in the speaker notes.

Frequently asked questions

What does the EU AI Act require you to log?

Article 12 requires high-risk AI systems to automatically record events over the system’s lifetime, at a level of traceability appropriate to the system’s intended purpose. Article 19 requires providers to keep those logs for at least six months, and Article 26(6) places the same retention duty on deployers for logs under their control. In practice an auditor will want to see which agent identity performed which action, against which system of record, at what time, and what data was read or changed. These obligations apply from 2 August 2026.

Is the model provider or the deployer responsible for keeping AI agent logs?

Both, for different records. The provider’s duty sits in Article 19. The deployer’s duty sits in Article 26(6) and covers logs under their control, which means logs of what the agent did inside the deployer’s own estate. A model provider’s prompt-and-completion log does not discharge the deployer’s obligation, and the duty cannot be contracted away to the model vendor.

Can point-to-point integration produce an EU AI Act audit trail?

Not without significant additional work. Point-to-point links are built to move data between two endpoints; logging is not part of their design, and where they log at all it is diagnostic output for developers rather than an evidentiary record with identity, payload and a defined retention period. Producing an audit trail from a point-to-point estate means agreeing a logging standard and retrofitting it link by link, in code that is typically brittle and expensive to change, and the resulting logs still cannot be correlated into a single decision trail unless every team implements the standard identically.

What is an iPaaS, and how does it help with EU AI Act compliance?

An iPaaS, or integration platform as a service, is a managed hub that every system connects to once, instead of each system wiring directly to every other. Because all traffic between agents and systems of record passes through one governed layer, the audit trail the AI Act asks for is produced as a by-product: identity, target system, operation, payload, result and correlation ID, with retention set once as platform policy rather than negotiated per connection. It does not, on its own, satisfy the Act’s risk-management, technical documentation or conformity-assessment requirements, which remain governance work.

General information, not legal advice. W3 Partnership is not a law firm; confirm the current status of the EU AI Act high-risk timetable and your own classification with counsel.