EU AI Act High-Risk Logging: Moved to 2027 and 2028

If you read that the AI Act's logging rules start on 2 August 2026, that date no longer holds. The Digital Omnibus on AI moved the high-risk obligations, logging included, to 2 December 2027 for stand-alone systems and 2 August 2028 for AI that is, or is a safety component of, a product under the EU product-safety laws listed in Annex I. Those rules also bind you only if your system counts as high-risk. A customer-support bot or a coding assistant is usually outside that scope. A resume screener, a credit-scoring helper or a student-assessment tool built on an LLM may not be. Either way, the logging habits that satisfy the Act are the ones that make an LLM app debuggable and auditable, so it is worth knowing which parts are law and which are good engineering.

This is an engineering explainer, not legal advice. Where we describe what the law says, we link the text.

What changed in 2026

Many guides on this topic were written before the Digital Omnibus on AI, and still tell you the high-risk rules start in August 2026. The Council gave final approval on 29 June 2026. The act was published in the Official Journal as Regulation (EU) 2026/1744 on 24 July 2026 and entered into force on 27 July 2026.

The amended Article 113 now carries both high-risk dates as fixed calendar dates, matching the Council's release. The logging articles themselves were not rewritten: the Commission's AI Act Service Desk, which shows the consolidated text as of 27 July 2026 and labels every Omnibus change, marks no changes to Article 12, Article 19 or Article 26. Under Article 50, disclosure duties such as telling users they are talking to an AI have applied since 2 August 2026. Only the marking of generated content got a grace period: Article 111(4), added by the Omnibus, gives systems placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2).

Note what Article 50 does not do. It asks providers and deployers to disclose and mark AI output; it contains no log-keeping requirement.

Step one: is your LLM app high-risk?

The Act does not classify by technology. It classifies by use. An LLM system is high-risk mainly when it falls under one of the eight areas in Annex III: biometrics, critical infrastructure, education, employment and worker management, access to essential services such as credit scoring or life and health insurance pricing, law enforcement, migration and border control, and justice and democratic processes.

Four details matter for LLM teams:

• Use, not model. The same model behind a general chat feature is not high-risk; behind a tool that ranks job applicants, it can be.
• There is an exception, with paperwork. Under Article 6(3), an Annex III system is not high-risk if it poses no significant risk to health, safety or fundamental rights and meets one of four conditions, such as doing a narrow procedural task or a preparatory task for an assessment in one of the Annex III areas. Systems that profile people are always high-risk. A provider using the exception must document its assessment and still register the system; the Omnibus kept registration and trimmed the information it asks for.
• Building on a third-party model still makes you the provider. If you build an HR or credit product on someone else's model and offer it under your name, you are the provider of that system (Article 3(3)). Article 25 also makes you a provider if you change the intended purpose of someone else's system, including a general-purpose one, so that it becomes high-risk, or put your name on an existing high-risk system.
• It reaches outside the EU. Article 2 covers providers that place systems on the EU market wherever they are based, and providers and deployers outside the EU when the system's output is used in the EU. A US company with EU customers is in scope.

If none of that describes your product, the logging articles do not bind you directly. If it might, read on.

What the logging articles actually say

The text is shorter and less prescriptive than most summaries suggest.

• Article 12. High-risk systems must technically allow automatic recording of events over their lifetime. The logs must help identify situations that could create a risk or amount to a substantial modification, support post-market monitoring, and support the deployer's operational monitoring. Specific minimum fields are listed only for remote biometric identification systems. For everything else, the Act sets no format and no field list.
• Article 19. Providers keep the automatically generated logs that are under their control, for a period that fits the intended purpose and for at least six months, unless other EU or national law, such as data protection law, says otherwise.
• Article 26(6). Deployers do the same for logs under their control, with the same six-month floor. Financial institutions keep these logs as part of the documentation they already maintain under financial services law, as Article 19(2) also says for providers.

The phrase "under their control" has a practical consequence. If your app calls a hosted model, the model vendor's internal logs are not yours. The record that you can produce for a regulator, a customer or your own incident review is the one you capture around the call.

What to log, in practice

The Act does not give you a schema, so what follows is our engineering suggestion. It is not a legal requirement. For the full field list and how to store it, see our complete guide to AI audit logging.

Tool calls deserve special care. A chat transcript shows what an agent said; the tool-call record shows what it did. We go deeper on this in AI audit logging in the agent era.

Retention and privacy pull in opposite directions

Articles 19 and 26(6) set a floor. GDPR Article 5 works as a ceiling: personal data should be limited to what the purpose requires and not kept in identifiable form longer than needed. A log that holds raw prompts is full of personal data.

The workable pattern is to keep two tiers. Keep metadata (IDs, model version, decisions, rule hits, timings) for the full retention period, and keep payloads for a shorter, justified period, redacted before storage so that secrets and personal identifiers never reach the log. Encrypt at rest, restrict who can read payloads, and write the retention period down along with the reasoning.

Making logs hard to quietly change

Neither Article 12 nor Article 19 prescribes tamper evidence, and the logging standards are not final yet. ISO/IEC FDIS 24970, on AI system logging, is in its final approval stage. CEN-CENELEC's prEN 18229-1, the logging part of its AI trustworthiness framework, is listed as under approval. Still, a log that anyone with database access can edit is weak evidence. A cheap improvement is a hash chain, where each record includes the hash of the previous one:

# Illustrative sketch. Assumes a single writer and JSON-serializable events.
import copy
import hashlib
import json
import time

GENESIS = "0" * 64

def _digest(body: dict) -> str:
    raw = json.dumps(body, sort_keys=True, separators=(",", ":")).encode()
    return hashlib.sha256(raw).hexdigest()

def append_event(log: list[dict], event: dict) -> dict:
    prev = log[-1]["hash"] if log else GENESIS
    # The event is nested so its own keys can never collide with the chain fields.
    # A deep copy, so later changes to the caller's dict cannot break the chain.
    body = {"ts": time.time(), "prev": prev, "event": copy.deepcopy(event)}
    record = {**body, "hash": _digest(body)}
    log.append(record)
    return record

def verify(log: list[dict]) -> bool:
    prev = GENESIS
    for record in log:
        body = {k: v for k, v in record.items() if k != "hash"}
        if body["prev"] != prev or _digest(body) != record["hash"]:
            return False
        prev = record["hash"]
    return True

A chain only helps if the latest hash is stored somewhere the writer cannot rewrite, such as a separate account or a periodic signed checkpoint. Treat this as a starting point, not a finished design.

What to do next

1. Write down your system's intended purpose and check it against Annex III. Record the reasoning, including any Article 6(3) conclusion.
2. Note the dates that apply: 2 December 2027 for stand-alone high-risk systems, 2 August 2028 for embedded ones.
3. Decide where events are captured, and make sure it is a layer you control rather than only a vendor's dashboard.
4. Define the fields above, including model version and tool-call records.
5. Redact before storing, and set separate retention periods for metadata and payloads.
6. Add tamper evidence and test restoring and reading a log from six months ago.
7. Ask counsel to confirm your classification before you build around it.

Where this leaves a small team

Capturing events at one point, for example a proxy between your app and the model provider, keeps the record consistent across services and out of application code. That is the approach we took with SignalVault. Its changelog lists CSV and JSON audit exports (v0.3.0), tool-call audit logs with field-level redaction of tool inputs and outputs (v0.10.0) and encryption at rest for every stored event, tool calls included (v0.15.10).

Whatever you build, treat logging as an engineering control first. The regulation then becomes a question of mapping what you already record to what a reviewer asks for.

Sources

• Council of the EU: final green light for the Digital Omnibus on AI, 29 June 2026
• Regulation (EU) 2026/1744 on EUR-Lex
• European Commission AI Act Service Desk, consolidated text as of 27 July 2026: Article 2, Article 3, Article 6, Article 12, Article 19, Article 25, Article 26, Article 49, Article 50, Article 111, Article 113, Annex III, Annex VIII
• Law-firm summaries of the Omnibus: Cooley, Cuatrecasas, Legal 500, Orrick
• GDPR Article 5
• ISO/IEC FDIS 24970: AI system logging
• prEN 18229-1: AI trustworthiness framework, Part 1: Logging (StandICT.eu listing)