Article 19 AI Act logs: retention and evidence

Article 19 AI Act logs: what the provider must keep and for how long

If you are the provider of a high-risk AI system and your compliance lead needs proof that logs exist, the core duty is simple: keep the logs your system automatically generates for at least six months, to the extent those logs are under your control, unless Union or national law (in particular data protection law) requires otherwise. Article 19(1) sets that floor, and it is the number an assessor will test first. The logs in scope are the ones produced by the automatic event recording capability that Article 12 requires every high-risk system to have, so the starting point is an inventory of what your system records, where each record lands and who controls it. The risk this article addresses is after-the-fact reconstruction. When a high-risk system produces a harmful or contested output, an authority, a deployer or an affected person needs to know what the system did, with which inputs and under which version. Without retained logs, the provider can only guess. Article 19(2) offers financial institutions a different route: they may keep the logs as part of the documentation they already maintain under Union financial services law, so a bank or insurer should confirm with its sector supervisor which records qualify before building a separate store. This is usually hard because the logs are scattered. Application events, identity and access records, model-serving traces, data pipeline jobs and third-party services each keep their own history, often with their own rotation settings and none designed around a six-month minimum. Retention is commonly an afterthought, so logs age out or are overwritten before anyone decides they are needed. Map every log source to an owner and a retention setting, confirm which sources are under your control, and test a restore before an authority asks for one.

Which systems, logs and organizations Article 19 covers

Article 19 applies to a narrow set of logs, but the boundary decisions determine how much work lands on the provider. Each card below marks one scoping question to settle before retention design starts.

High-risk systems only

Article 19 attaches to high-risk AI systems, whether they fall under the Annex III route or the Annex I product route. A general-purpose chatbot or a low-risk internal tool carries no Article 19 retention duty, although other obligations may still apply. Before scoping logs, confirm the risk classification of each system in writing, because the classification fixes the set of systems in scope.

Logs from Article 12 event recording

The logs in scope are those produced by the automatic event recording capability that Article 12 requires every high-risk system to have. Ordinary application logs, debug output and monitoring metrics are not automatically covered. Map which events your system records for traceability, such as usage periods, reference data checked and the persons verifying results, and treat that mapped set as the retention scope.

Logs under the provider's control

The retention duty applies to logs only to the extent they are under the provider's control. For a self-hosted system running in the client's own infrastructure, the provider may control the log pipeline or may only hand over the software. Record which party holds the storage, the retention settings and the deletion rights for each log stream. Where control sits with the deployer, Article 26(6) becomes the operative duty for that party.

Financial institutions and existing documentation

Article 19(2) lets financial institutions keep the logs as part of the documentation they already maintain under Union financial services law. This can avoid a separate retention store, but it does not remove the need to show that the logs meet Article 12 content and the required record. Confirm with the financial supervisor and legal counsel how the existing retention regime maps to the high-risk logs before relying on it.

Cloud and hosted components with shared control

Logs often pass through a managed database, a hosted log service, a backup vendor or a cloud audit trail. Where another party can read, alter or delete those records, control is shared and the provider must agree who keeps what, for how long and under which access terms. Check whether each hosted component offers configurable retention and export, and document the contractual split in the technical file.

Parallel six-month deployer duty

Article 26(6) places a parallel minimum six-month retention duty on deployers for logs under their control. Provider and deployer duties can cover the same event stream from different angles, so both parties need to agree in writing which copy is kept, where, and for how long. Confirm the handover of log copies in the deployer instructions, since a gap between the two parties is the most common source of missing evidence.

What counts as a log under Article 19 and why retention is tied to purpose

Article 19 does not ask providers to keep every log their platform writes. It points back to Article 12, which requires a high-risk system to be built with an automatic event recording capability, and the logs in scope are the records that capability produces about the system's operation. In practice, that means events such as the period of each use, the reference data checked against, the input data that led to a match where relevant, and the identity of the people who verified results, as the system's own design defines them. Application server access logs, web server noise and general IT logs fall outside the duty unless your Article 12 design captures them as system events. Decide the boundary early, write it into the technical documentation, and confirm it with your conformity assessment body or legal counsel before you build retention around it.

Retention is tied to purpose. Article 19 requires a period appropriate to the intended purpose of the system, and sets six months as the floor, not the ceiling. A system used for short, repeated decisions may need only the minimum, while a system whose outcomes can be challenged years later, or whose post-market monitoring under Article 72 depends on historical records, may justify a longer period. The floor can also be overridden by Union or national law, and data protection law is the usual constraint: personal data in logs must not be kept longer than necessary, so a longer period needs a documented necessity and a shorter period may be mandatory. Ask your legal team to name the controlling rules for each Member State where the system is used, and record the reasoning in the file.

The phrase "to the extent under their control" limits the duty to logs the provider actually holds or can retrieve. When a deployer, a cloud host or a managed database operator stores the logs, the provider's obligation depends on contract terms. Agree in writing who keeps each log stream, where it is stored, how long it is kept, who can export it, how access requests from authorities under Article 21 are routed, and how deletion is evidenced at the end of the period. Without that agreement, a log that is technically generated may be nobody's responsibility, and the provider may be unable to produce it when asked. The same written split should reflect the deployer's parallel six-month duty under Article 26.

How an assessor tests Article 19 and what they ask to see

This table sets out how an assessor typically tests each part of Article 19, what evidence they request and the findings that most often come up. Read each row as a test step: the test approach says what to check, the evidence column says what to have ready, and the findings column shows where systems usually fall short.

Test area	Test approach and evidence requested	Common findings
Logging capability under Article 12	Confirm the high-risk system has automatic event recording and that the events cover the system's operation. Request a log schema, a list of event types, sample log extracts and the design record that links them to the Article 12 capability.	Logging enabled only for errors or administrators. No documented list of recorded event types, so the assessor cannot tell what the logs are meant to show.
Retention period against six months	Check the configured retention for each log store against the at-least-six-month minimum and the intended purpose. Request retention settings, the retention rationale and any Union or national law that changes the period.	Logs rotated or purged at 30 or 90 days. Retention justified only by storage cost, with no link to the intended purpose or the six-month floor.
Logs under the provider's control	Map every log source and state which ones the provider controls and which sit with a cloud host, a deployer or a third party. Request a log inventory, hosting agreements and the data flow diagram.	Logs held by a hosting provider with no contractual access. Gaps in the inventory where a sub-component writes its own logs that nobody tracks.
Integrity and access to logs	Test who can read, change or delete logs and whether changes are recorded. Request access control lists, log integrity settings, backup records and change history for the log store.	No record of who can alter logs. Administrators able to delete logs without an audit entry. Backups that were never tested for restore.
Production on reasoned request under Article 21(2)	Run a tabletop request: ask for a set of logs for a stated period and time the retrieval. Request the request-handling procedure, the named contact, export formats and a sample production record.	No defined owner for authority requests. Logs exist but cannot be exported in a usable form within a reasonable time. Logs needed for the request were already purged.
Financial-sector alternative under Article 19(2)	Where a financial institution relies on this route, check that the logs are kept as part of the documentation under the financial services law it already follows. Request the mapping between the AI logs and the financial documentation.	Institution assumes the financial route applies without confirming the logs sit inside the required documentation. Retention periods under the financial rules are not checked against the AI system's use.

How to implement Article 19 logging step by step

This sequence turns the Article 19 duty into a documented logging capability: which logs exist, how long they are kept and why, how they are protected and retrieved, and who is responsible for them at each point in the value chain.

Inventory the logs each high-risk system produces
Start by listing every high-risk system in scope and the automatically generated logs it writes. Article 12 requires the automatic event recording capability, so the inventory should trace each log stream back to the event types that capability records, including model inference events, user access events, configuration changes and errors. Record the source, format, location and owner of each stream in a log register. The step is complete when every stream is named, has an owner, and the register has been reviewed against the system's technical documentation.
Set and justify the retention period
For each log stream, decide how long it is kept and write a retention decision record. Article 19(1) sets a minimum of six months where the logs are under the provider's control, with the period appropriate to the intended purpose, unless Union or national law (in particular data protection law) requires otherwise. Tie the chosen period to the intended purpose and to any applicable law, and have legal or privacy counsel confirm conflicts with data minimization duties. If your organization is a financial institution, record whether logs are kept as part of documentation under Union financial services law instead. The output is a signed retention decision per stream.
Configure collection and protected storage
Configure each system to write its logs to a defined destination and to keep them there for the approved period. Many platforms write audit output to local files or databases with their own rotation settings, so check each default. Nextcloud's admin_audit app, for example, writes audit information to a configured file path, and OpenBao audit devices write request and response logs in JSON with sensitive values hashed. Confirm each product's capabilities and rotation behavior in its own documentation rather than assuming them. Output: a configuration baseline per system showing the destination, rotation and retention settings.
Apply access and integrity controls to the logs
Restrict read and write access to the log stores to named roles, and log access to the logs themselves. Logs that can be edited or deleted by the people they record are weak evidence. Protect them with integrity mechanisms such as write-once storage, separate administrative accounts, or hashing and signing where the platform supports them. Backups of logs should be verifiable: Bareos keeps a catalog of backed-up files and restores by date, and restic's check command can read pack files back to confirm stored data is unmodified. Output: an access matrix for the log stores and a record of the integrity test performed.
Test retrieval against an authority request
Run a retrieval exercise that mimics a reasoned request from a competent authority under Article 21(2). Pick a system and a past time window, then time-bound the work to extract the relevant logs, confirm they are complete for that window, and produce them in a usable form with a short explanation of their meaning. Check that restored logs from backup match the originals. Record what was missing or slow and fix it. Output: a dated retrieval test record signed by the control owner, with gaps and remediation actions listed.
Document ownership across deployers and hosting partners
Article 26(6) places a parallel six-month retention duty on deployers for the logs they control, so the provider and each deployer need a clear split of responsibility. Write down which party holds which log stream, who retains it, how requests are routed, and what happens when a hosting partner or integrator operates the infrastructure. Put these terms in the contracts or operating agreements and link them from the log register. Confirm the arrangement with counsel, since the Act's value chain rules in Article 25 also affect who is treated as the provider. Output: a responsibility matrix and signed agreements referenced in the register.

What evidence passes an Article 19 review

An assessor reviewing Article 19 will look for a documented logging design, a retention rule with a reason behind it, and proof that the logs exist, are protected and can be produced on request. The cards below cover the artifacts that connect those points, and each one needs a refresh cycle so it still matches the system at audit time.

Logging specification tied to Article 12

Document which automatically generated events the high-risk system records, why each event type matters for traceability and monitoring, and where each log stream is written. Map every event to the Article 12 logging capability it serves so the assessor can follow the chain from requirement to log. Refresh it whenever the system's functions or components change, and review it at least quarterly against the current release notes of each open-source platform in the stack.

Retention policy with justification

State the retention period, the reason for it, and the legal basis that could override it, such as data protection rules. Article 19 sets a minimum of six months where the logs are under the provider's control, so the policy should explain why the chosen period fits the intended purpose. Confirm with counsel how data protection law limits retention of personal data within the logs. Review the policy annually and whenever the purpose of the system changes.

Retention configuration exports

Keep dated exports of the settings that actually control retention and storage, such as audit log destinations, rotation rules, backup schedules and retention jobs. Screenshots help, but a machine-readable export with a timestamp is easier to compare across periods. For example, a Nextcloud admin_audit output path or a Bareos retention pool setting can be exported and stored in the evidence repository. Schedule an export every quarter and keep each one for the full review period.

Sample log extracts with required fields

Provide redacted extracts showing that each event type carries the fields the logging specification promises, such as timestamp, event type, user or service identity and outcome. Extracts should come from production or a production-like environment, not hand-written examples. Confirm that sensitive values are masked or hashed as designed, since the assessor will check both presence and protection. Refresh the extracts each quarter and after any logging change.

Access and integrity records for the log store

Record who can read, change or delete the log store, how those permissions are granted and reviewed, and how tampering is detected. Include access review tickets, privileged access logs and integrity checks such as repository verification output. For backup-based stores, a restic check run that reads pack files back to confirm stored data is unmodified is one example of integrity evidence. Review access quarterly and keep the verification output with its date.

Authority request procedure with test retrieval

Article 21 requires providers to give competent authorities access to logs on reasoned request. Write the step-by-step procedure, name the owner, set internal response steps, and record a test retrieval showing that logs for a chosen period can be pulled, filtered and delivered within the procedure. Keep the test record with the date, the requester role and the outcome. Run a fresh test each quarter, and after any change to log storage or access controls.

What meeting Article 19 costs in money and effort

This table lists the cost components of keeping high-risk system logs under Article 19, showing whether each is one-time or recurring and what drives it. Read it as a checklist for a quote: most of the effort sits in design and retrieval testing, while open-source licenses are only one line among several. Figures are not stated here because none are supplied, so confirm each one against your own environment and scope.

Cost component	One-time or recurring	What drives it	How to keep it down
Logging design and retention decision	One-time	Number of high-risk systems, the event types Article 12 logging captures, and the retention period you justify for each system's intended purpose	Document one retention rule per system class, reuse the same logging pattern across systems, and agree the rule with legal and data protection staff before build
Log storage capacity and backup	Recurring	Event volume per system, retention length beyond the six-month minimum, and how many copies and locations the logs need	Set retention by intended purpose rather than by default, compress and tier older logs, and confirm which copies must stay inside your controlled environment
Access control and integrity tooling	One-time setup, recurring operation	Number of people who can read or alter logs, whether tamper evidence is needed, and whether commercial tools or open-source components are chosen	Use role-based access and separate the logging administrator from the system administrator, and confirm license terms for any commercial component before selecting it
Engineering time to test authority retrieval	Recurring	How many systems and log stores must be searched, how quickly a reasoned request must be answered, and how often retrieval is rehearsed	Script the export of a defined time range per system, run a periodic dry run, and record the results as evidence
External review of the retention justification	Optional, one-time or periodic	Complexity of the sector rules involved, the number of retention periods in use, and whether counsel or an independent assessor reviews the position	Scope the review to the retention rule and the sector rules that apply, and ask for a fixed-scope written proposal
Auditor sampling time	Per audit	Number of systems in scope, the sample of log extracts the assessor selects, and how easily the evidence can be produced	Keep logs in a predictable structure, maintain an index of log locations, and prepare a sample pack before the assessment starts

Which self-hosted open-source tools can produce Article 19 evidence

Article 19 asks providers to keep the logs their high-risk system generates and to hand them to authorities on request. The four tools below each cover a different part of that duty: event records, integrity of stored logs, and retention and restore. None of them proves compliance on its own, so each card names what the organization must still confirm.

Nextcloud admin_audit logging

The admin_audit app records additional event information to audit.log in the data directory, or to a path set with logfile_audit. It supports the event-record part of Article 19 when the high-risk system is built on or alongside Nextcloud. Confirm that each event field needed for the purpose set out in Article 12 is captured, that the log path sits under the provider's control, and that log rotation does not delete records before the retention period ends.

OpenBao audit devices

OpenBao audit devices write a detailed JSON record of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. This gives a tamper-evident style of event record for access to secrets and keys that a high-risk system depends on. Confirm which audit devices are enabled, that more than one destination receives the records, and that the hashed fields still let an assessor link an event to a person or service account.

Bareos backup and archive jobs

The Bareos Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of backed-up files. The catalog lets the organization show which log files were stored, when, and how they can be restored, including versions from before a given date and time. This supports the retention and restore part of Article 19. Confirm that the retention settings in the job and pool configuration meet the period appropriate to the intended purpose and at least six months, and test a restore.

restic integrity checks

The restic check command verifies the structural consistency of snapshots, trees and pack files. With --read-data or --read-data-subset, it reads pack files back to confirm the stored backup data is unmodified. This supports the integrity part of keeping logs that an authority may later examine. Confirm how often checks run, that the read-data option is scheduled and not only run by hand, and that failed checks raise an alert to a named owner.

Who owns the Article 19 logs: your team, a partner and the auditor

Your organization is the provider, so it owns the retention decision under Article 19(1) and the answer to any reasoned request from a competent authority under Article 21(2). No outside party can take on these duties. Your team decides how long logs are kept for the intended purpose, which Union or national law (including data protection law) overrides that period, and whether a financial institution will use the route in Article 19(2).

Retention decision: Set and record the retention period for each high-risk system, starting from the six-month minimum in Article 19(1) and documenting why that period fits the intended purpose.
Log custody agreements: Where a cloud host, data center operator or backup vendor holds the logs, put written terms in place that keep them available for the retention period.
Data protection review: Check with your privacy team whether personal data in logs limits how long they can be kept.
Authority requests: Name an owner who can produce logs quickly and document each request and response.
Deployer coordination: Confirm which logs your deployers hold under their own six-month duty in Article 26(6).

Confirm these decisions with your legal and compliance leads before the first assessment, because they are yours to defend.

Article 19 logs: questions buyers ask before they hire help

How much effort does Article 19 take for a system that already logs?

Effort usually depends on gaps in what is kept and how it is protected, not on creating logs from scratch. Article 19(1) asks providers to keep the logs produced by the automatic event recording that Article 12 requires, for at least six months where they are under their control. Start by mapping which events are logged, where they are stored, who can change or delete them, and whether each entry carries enough context to reconstruct a decision. Typical work includes setting retention rules, restricting deletion, protecting log integrity and documenting how an authority would receive the logs. Cost rises with log volume, the number of components that generate logs and the number of logging sources outside your team's control. Ask any partner for a written scope that lists each log source and the proof of retention it will produce. Article 19 on EUR-Lex gives the exact wording.

Is six months always enough to keep high-risk AI logs?

No. Six months is a minimum. Article 19(1) requires a period appropriate to the intended purpose of the system, and that period may need to be longer. The period can be shorter only where Union or national law, in particular data protection law, provides otherwise. Data protection rules may also require deletion sooner, so the retention period needs a legal review alongside the AI Act duty. Deployers carry a parallel minimum six-month duty under Article 26(6) for logs under their control, so a provider and its customers may set different periods for the same system. Document the chosen period, the reason for it and the legal basis for any shorter period. Confirm the final position with counsel or your data protection officer before the retention policy is approved.

How does the financial-sector option in Article 19(2) change the work?

Article 19(2) lets financial institutions keep the logs as part of the documentation they already maintain under Union financial services law. The work shifts from building a separate AI log store to fitting the logs into an existing record-keeping regime. The duty does not disappear. The logs must still be complete, retrievable, protected and available to competent authorities on reasoned request under Article 21(2). Teams should identify which financial-services record-keeping rules already cover the system, confirm the retention period those rules set and check that the high-risk system's logs reach that archive. Gaps usually sit between the AI event logs and the financial archive, such as missing identifiers or separate retention clocks. Ask a partner to show how the AI logs link to the existing record and who owns that link.

Do logs held by a hosting provider count as under our control?

Logs count as under your control when you can access, retain, protect and produce them without depending on someone else's permission. Article 19(1) limits the retention duty to logs under the provider's control, and Article 21(2) limits authority access to the same logs. A hosting provider that stores logs under a contract you manage may still leave them under your control, provided you hold the keys, set retention and can export the logs. Logs that the provider can delete, restrict or retain on its own terms are harder to treat as under your control. Review the hosting contract, the log retention settings, the access model and the export path. Record the conclusion in writing, because an authority may ask how control was established. Whether a specific arrangement qualifies is a legal question, so confirm it with counsel.

What must our team supply to a partner before scoping Article 19 work?

Bring a system inventory, an architecture diagram and a named owner for the retention policy. These three inputs let a partner scope the work accurately. The inventory should list each high-risk system, its intended purpose and its version history. The architecture should show every component that generates or stores logs, including third-party services, backup targets and administrative tools. The retention policy owner must be able to approve the retention period, the legal basis for any exception and the rules for authority access. Also provide the current logging configuration, log formats, storage locations, existing access controls and any financial-sector record-keeping rules that apply. Missing inputs usually widen the scope, so a written scope and quote should list every assumption made about them.

Can our own team handle Article 19 in-house?

Yes, a team with engineering, security and legal input can handle Article 19 in-house if it has the time and clear ownership. The technical work is mostly configuration, retention, integrity and export. Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. OpenBao audit devices keep a detailed JSON log of every API request and response, with most sensitive values hashed with HMAC-SHA256. Bareos and restic can protect backed-up copies of log data, with restic's check command able to read pack files back to confirm they are unmodified. The harder parts are the legal reading of retention, documenting control and proving to an assessor that the logs are complete. Consider outside help when several systems share logging, when the team lacks time or when evidence must be tested before an authority asks for it. Confirm each tool's capabilities in your own environment first.

When do Article 19 duties start to apply to a high-risk system?

Article 19 sits in Chapter III Section 3, so its duties follow the high-risk dates. As amended in 2026, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Check whether your system falls under Annex III or Annex I, since that determines the date. Plan logging controls before the applicable date, because retention evidence takes time to build and the logs must exist from the moment the system runs. Confirm these dates against the consolidated text of the Act before you set the project plan, and treat any earlier internal deadline as a planning choice.

How DeployOpen prepares Article 19 logging in your environment

DeployOpen works on the logging layer of self-hosted open-source platforms inside your own infrastructure, so the automatically generated logs your high-risk system produces are kept, protected and retrievable for the retention period you set. We prepare the systems and the evidence; your organization keeps ownership of its controls, and only an independent assessor can judge conformity.

How we scope

The written scope lists each platform, host and log source whose events fall under your control and must be retained.
It records the retention period you select, with the six-month minimum in Article 19 as the floor and any longer period set by your own policy or other law.
It names the financial-sector route under Article 19(2) only if your institution will rely on it, and states which logs will be kept as part of existing documentation.

How we build

We configure audit logging on the platforms in scope, such as Nextcloud admin_audit output and OpenBao audit devices, and confirm the destinations are set.
We set up backup jobs and integrity checks for log stores so retained records can be restored and verified over the retention period.
We restrict access to the log stores and document who can read, export or delete them, so access requests can be answered without altering records.

How we hand over

You receive a retention configuration document mapping each log source to its location, format, owner and retention period.
You receive test records showing that a sample of events was written, retained, restored and checked against the configured integrity process.
You receive a runbook for responding to a reasoned request from a competent authority under Article 21(2), including where logs are held and who approves release.

How we support

Ongoing support, upgrades and continuous testing of the logging configuration are available as a retainer.
Retainers can cover re-running restore and integrity tests after platform upgrades or changes to the retention policy.
Whether a particular high-risk system, or any deployer obligation under Article 26(6), applies to you should be confirmed with your legal and compliance advisers.

Article 19 Automatically generated logs