Skip to main content

AI Act Audit Trail Requirements

What Articles 12, 19 and 26(6) require of logging, what the Act leaves open, and engineering practices that protect logs as evidence.

Providers of high-risk AI systems must build them to record events automatically (logs) over their lifetime (Article 12). Providers and deployers (those using the system) keep logs under their control at least six months, unless other law provides otherwise (Articles 19 and 26(6)).

This applies from 2 December 2027 (Annex III) and 2 August 2028 (Annex I). Article 2 lists exclusions. Older systems are covered only after significant design changes (Article 111(2)). Fines reach up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: list the events to record.

The Act requires logging capability, retention and access, not a log format

  • Article 12(1): the system must be able to record events automatically

    A high-risk AI system must technically allow automatic recording of events (logs) over its lifetime.

  • Article 12(2): logs must serve three purposes

    Logging must enable recording of events relevant for identifying risk situations (Article 79(1)) or substantial modifications, for post-market monitoring (Article 72) and for monitoring operation by deployers (Article 26(5)). The Act lists no event types.

  • Article 12(3): remote biometric identification has a minimum

    Remote biometric identification systems (Annex III point 1(a)) must log at least the period of each use, the reference database checked, the input data that led to a match and the people who verified the result.

  • Article 19(1): providers keep logs for at least six months

    Providers keep the automatically generated logs to the extent they are under their control. The period fits the intended purpose and is at least six months, unless Union or national law, in particular on personal data, provides otherwise. Providers that are financial institutions keep the logs as part of their financial-services documentation (Article 19(2)).

  • Article 26(6): deployers keep logs for at least six months

    A deployer is a natural or legal person, public authority, agency or other body using the system under its authority (Article 3(4)). Deployers keep the logs the system generates, to the extent they are under their control, for a period that fits the intended purpose and is at least six months, unless Union or national law provides otherwise. Deployers that are financial institutions keep the logs as part of the documentation they keep under Union financial services law on internal governance.

  • Article 21(2): authorities can ask for access to logs

    On a reasoned request of a competent authority, providers give access to the automatically generated logs, to the extent they are under their control.

  • Not in the Act: log format, immutability, hash chains, storage region

    Articles 12, 19 and 26(6) name no log format, no write-once storage, no hash chain and no storage region. The words “immutable”, “tamper” and “hash” do not occur in the consolidated Regulation of 27 July 2026. Such measures protect logs as evidence; they are your design choice.

Engineering practices that protect logs as evidence (our recommendations)

The Act speaks of logs, not audit trails. Here an audit trail means logs kept as evidence. These practices serve the goals of Articles 12 and 19; the Act does not require them.

  • Structured events

    Write each event as JSON with the same fields every time, so that you can query it. The example below is one possible schema.

Example event (illustrative schema, not prescribed by the Act)

{
  "event_type": "AI_DECISION",
  "timestamp": "2026-10-22T14:22:33.456Z",
  "trace_id": "abc-123-def-456",
  "system_id": "credit-scoring-v2",
  "actor_id": "user-789",
  "metadata": {
    "model_version": "v2.3.1",
    "input_hash": "sha256:a1b2c3...",
    "decision": "refer_to_human"
  }
}

  • Append-only, separate storage

    Store logs where nobody can change them afterwards, for example in write-once object storage apart from the application database. Logs kept in the application database can be changed or deleted by its administrators.

  • Integrity checks

    Chain entries by hash or lock the stored objects, and verify them on a schedule. Then you can show that stored logs are unchanged.

  • Trace IDs

    Pass one trace ID through every service and put it in every entry. Then you can follow a single request through the whole AI pipeline.

  • Pseudonymous identifiers

    Log opaque IDs and event metadata, not names or email addresses, where the purpose allows. Which personal data a log may hold is a GDPR question for your data protection officer or counsel.

  • Non-blocking writes

    Send events to a queue and retry on failure, so that a failing log write does not take the application down.

  • Query and export

    Make logs filterable by time, event type and system. Then you can answer a reasoned authority request under Article 21(2) and run your own monitoring.

What Scanara checks, and what it does not

Scanara’s code rules flag AI operations without recognisable logging patterns. The checks are rule-based static analysis that detects standard ML framework patterns; confidence varies by programming language tier. Scanara also keeps a write-once log of actions in the platform, and you can re-run scans on demand.

Scanara does not observe your running system, check the content or completeness of its logs, or show that Article 12 is met. A passing scan is not proof of compliance, and the decision stays with you.

Audit trail checklist: what the Act requires, then good practice

  • Required (Article 12(1)): the system technically allows automatic recording of events over its lifetime.
  • Required (Article 12(2)): logging covers events relevant for risk situations and substantial modifications, post-market monitoring and deployer monitoring.
  • Required (Article 12(3)): remote biometric identification systems log the minimum content.
  • Required (Articles 19(1) and 26(6)): logs under your control are kept for at least six months, unless other law provides otherwise.
  • Required (Article 21(2)): you can give an authority access to the logs on a reasoned request.
  • Good practice: events use a fixed JSON schema with timestamp, event type, system ID and trace ID.
  • Good practice: log storage is append-only and separate from the application database.
  • Good practice: log writes do not block the application.
  • Good practice: logs hold pseudonymous identifiers, not raw personal data, where the purpose allows.
  • Good practice: the integrity of stored logs is verified on a schedule.

Exclusions, older systems and fine caps

The Regulation does not apply to AI systems used exclusively for military, defence or national security purposes (Article 2(3)). It does not apply to AI systems specifically developed and put into service for the sole purpose of scientific research and development (Article 2(6)), or to research, testing or development before placing on the market or putting into service, except testing in real-world conditions (Article 2(8)). Free and open-source systems are excluded unless they are placed on the market or put into service as high-risk systems or fall under Article 5 or 50 (Article 2(12)). Natural persons who use a system in a purely personal non-professional activity are not bound as deployers (Article 2(10)). For high-risk systems related to products under Annex I Section B legislation, such as motor vehicles, aviation, rail, marine equipment, agricultural vehicles and machinery, only Article 6(1), Article 60a and Articles 102 to 112 apply. Articles 57 to 59 apply only in so far as that legislation integrates the requirements (Article 2(2)).

High-risk systems placed on the market or put into service before the application date are covered only after significant design changes. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)).

For SMEs, each fine is up to the percentage or amount, whichever is lower (Article 99(6)). For small mid-cap enterprises (SMCs, defined in Article 3(14b)), the same cap applies to fines under Article 99(4) and (5) (Article 99(6a)). The EUR 15 million tier also covers the obligations of providers and operators under Article 25(2) and (4) (Article 99(4), point (da)).

Read next: pipeline checks, rule-based scanning and Article 12

Scanara prepares evidence from your repositories

Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.