EU AI Act High-Risk AI System Logs: How Providers Should Give Deployers Access

What the Act requires for log generation, control and retention

Article 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over the lifetime of the system. The logging capability must support traceability appropriate to the intended purpose. It must enable recording of events relevant to identifying situations that may result in a risk within the meaning of Article 79(1) or in a substantial modification, and to monitoring the operation of the system as referred to in Article 26(5).

Providers must keep the automatically generated logs when those logs are under their control (Articles 16(e) and 19). The retention period must be appropriate to the intended purpose and at least six months. This is without prejudice to applicable Union or national law, in particular Union law on the protection of personal data. Providers that are financial institutions subject to internal governance requirements under Union financial services law maintain the logs as part of the documentation kept under that law. On a reasoned request from a competent authority, providers must give access to the logs under their control.

Deployers have a parallel duty under Article 26(6). They keep the automatically generated logs to the extent the logs are under their control, for a period appropriate to the intended purpose of at least six months, with the same exception for other Union or national law. The provider's technical documentation must also describe, where relevant, the mechanisms that allow deployers to properly collect, store and interpret the logs. As of November 2026, the Commission states that the rules for high-risk AI systems apply from 2 December 2027.

What the Act leaves to implementation

Both retention duties depend on logs being under a party's control, and the Act does not define control. Nor does it set a log schema, an integrity or tamper-evidence mechanism, or a transfer or API method between provider and deployer. How a provider gives a deployer access is therefore a design and contract decision, not a regulatory category.

That makes the split of control the first decision. For each log set, record which party controls it, because that determines who carries the retention duty and who answers an authority request. Overlapping copies are acceptable, but they should be deliberate and documented, not an accident of how data was exported.

The second decision is scope. Article 12 ties logging to risk situations, substantial modification and monitoring of operation. Map each logged event type to one of those purposes. A regulator can then see why an event is recorded, and a data protection reviewer can see why it is not recorded when it has no purpose.

Three access models and their trade-offs

The models below are analytical options. None is mandated by the Act, and they can be combined, for example by pairing provider-hosted storage with a scheduled export. The right choice depends on where the deployer needs data to reside, what the provider needs for its own Article 19 duty and incident support, and how each party will prove the logs are complete.

• Deployer-hosted storage: The deployer holds the logs in its own environment. This supports its Article 26(6) duty and its residency requirements. The provider's visibility for its Article 19 duty and incident support depends on what it can still reach, so the arrangement must state what the provider may access and when.
• Provider-hosted access: The provider keeps the logs under its control and exposes them to deployers. Retention and integrity controls are centralised. Open questions are data residency, confidentiality of other customers' and provider information, and whether the deployer can retrieve logs when it needs them.
• Contractual or API-based export: Scheduled or on-demand transfer lets each party hold copies. Both parties must agree the schema, completeness checks and integrity verification, and must record which copy is authoritative so retention and authority requests are not duplicated or contradictory.

Governance and operating practice

Assign an owner on each side for log retention, access approval and authority requests. A reasoned request will usually reach the provider, but the relevant logs may be held by the deployer. Define in advance how deployer-held logs are produced, so the response does not depend on informal contacts.

Retention needs the most legal care. The six-month minimum can be displaced by other Union or national law, in particular data protection law, so retention and minimisation settings should be configurable and reviewed rather than fixed at the product default. Providers that are financial institutions should also check whether logs must be held as part of financial services documentation.

Keep the arrangement consistent with the instructions for use. Deployers must take technical and organisational measures to use the system according to those instructions, and a log access process that contradicts them creates a gap in the evidence. Finally, confirm the deployer can actually perform the collection, storage and interpretation the provider documents, and track the application date and any further amendments to the consolidated text.

How runtime policy enforcement produces audit-ready evidence

Event logs record what a system did. Regulators and auditors also ask what the system was allowed to do. Trussed addresses that second question by enforcing policy in the execution path. For individual interactions and tool calls across models, agents, tools and MCP servers, policy is enforced at runtime, not reviewed after the fact. Each decision to allow, redact or block produces continuous, audit-ready evidence, mapped to the EU AI Act among other frameworks.

This supports the obligations above by giving provider and deployer a shared record of policy decisions alongside system events. It does not replace the Article 12 logging capability of the high-risk system itself, and it does not trace agentic workflows end to end.

Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency. For an access arrangement, that means evidence can stay in an environment the deployer or provider controls, and retention can be set to match the period the two parties agree.