The EU AI Act's High-Risk Rules Went Live on August 2. Article 12 Is the One Most AI Teams Will Fail.

What actually became enforceable on August 2

Three deadlines have shaped the EU AI Act's rollout: prohibited-practice bans in February 2025, obligations for general-purpose AI model providers in August 2025, and a third wave on August 2, 2026 that brings Article 12's record-keeping duty into force. That third date is the one that touches product teams directly, not just labs training foundation models.

On August 2, Articles 9 through 17 became enforceable for providers of high-risk AI systems, Article 26 for the organisations deploying them, and Article 50's transparency rules for AI-interaction disclosure, synthetic-content labelling, and deepfake identification. Systems already on the market needed a completed conformity assessment, finished technical documentation, CE marking, and registration in the EU's high-risk AI database by that date.

Annex III defines what counts as high-risk: biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and the administration of justice. Most compliance content published around this deadline walks through that list and the conformity-assessment steps that follow it. Less of it covers what actually breaks first inside a working production system: Article 12.

It's worth separating this from what didn't happen on August 2. Systems that are safety components of products already covered by sectoral EU legislation, such as medical devices or machinery, get an extra year, until August 2, 2027. GPAI model providers had their own obligations land a year earlier, in August 2025. What went live this August is narrower and more specific: the rules for AI systems built into products that make or shape decisions about people, inside the eight Annex III categories.

Article 12 isn't 'log more.' It's 'reconstruct this decision.'

Article 12(1) requires high-risk AI systems to have logging capability that lets providers identify risks across the system's lifecycle. Article 12(2) is the line worth reading twice: the logs have to enable reconstruction of the system's behaviour in relation to a given output, not just record that an event took place.

That's a different bar than the logging most engineering teams already run. A SOC 2 access log tells you who touched what. A GDPR Article 30 record tells you which categories of data a process handles, in aggregate. Article 12 asks a narrower, harder question: for this one output, on this one date, given this one input, why did the system produce this result? A regulator asking that question, a rejected loan applicant, or a candidate who wants to know why an AI screener filtered them out is asking for the same reconstruction.

Why most LLM-based systems fail this by default

Most production systems built on top of LLMs can't answer that question today, and not because anyone skipped an audit-trail feature. Three specific architectural gaps cause it.

Prompt version drift. Prompts usually live in a dashboard or a config file that gets edited without a version tied to individual decisions. If a hiring-screen prompt changed in March and again in June, and a complaint arrives about a decision from April, most teams can reconstruct roughly what the prompt probably said. Roughly isn't reconstruction.

Retrieval-set capture. Retrieval-augmented systems answer differently depending on what the index returned at query time, and that index keeps changing. Unless the exact set of retrieved documents is captured per decision, no one can explain afterward why the model favoured one candidate's resume language over another's.

Model version pinning. Model providers roll versions behind the same API alias, sometimes without a changelog a customer ever sees. A decision made through a given model alias in March and another made through the same alias in July may have run on materially different weights. Without capturing the exact model version at inference time, per decision, 'reconstruction' is a claim a team can't back up.

Each gap is invisible in the metric that most teams actually watch, which is whether the system is still answering correctly. A prompt edit that improves average accuracy, a reindex that refreshes retrieval quality, a silent model upgrade that a provider ships as a bug fix: all of these look like wins on a dashboard. None of them are recorded as the kind of versioned event Article 12 assumes exists. The logging gap and the product-improvement loop pull in opposite directions, which is exactly why it doesn't get noticed until a specific complaint forces someone to go looking for a record that was never kept.

What a compliant decision record actually contains

None of these are compliance checkboxes. They're schema decisions that have to be made before a system ships, because they can't be retrofitted onto data that was never captured in the first place.

A decision record that would satisfy Article 12(2) needs, at minimum, a stable decision ID, a timestamp, the exact model checkpoint or version string used, a hash of the prompt template in effect at that moment, the IDs of any retrieved context passed to the model, a reference to the input data, the output produced, any human oversight action taken, and the Annex III category the system falls under.

{
  "decision_id": "dr_8f21c9",
  "timestamp": "2026-04-11T09:14:02Z",
  "system_version": "hiring-screen-v3.2",
  "model": {
    "provider": "internal-alias/screener",
    "checkpoint": "2026-03-18-ckpt-a41",
    "resolved_at_inference": true
  },
  "prompt": {
    "template_id": "screen-cv-v7",
    "template_hash": "sha256:9c1a...",
    "resolved_at_inference": true
  },
  "retrieval": {
    "index_snapshot_id": "idx_2026-04-10",
    "retrieved_doc_ids": ["jd_1123", "policy_88"]
  },
  "input_ref": "candidate_9931/application",
  "output": { "decision": "advance", "score": 0.81 },
  "human_oversight": null,
  "annex_iii_category": "employment_worker_management"
}

The classification trap that catches teams first

Classification, not logging, is what catches most teams first. 'We're not doing biometric identification, so we're fine' is the most common miscalculation, and it comes from reading the headline categories in Annex III instead of the sub-categories inside them.

Employment and worker management covers CV screening, task-allocation algorithms, and performance-monitoring systems, not just robotic hiring bots. Access to essential services covers credit scoring and insurance risk pricing, which describes a large share of B2B fintech products with an LLM feature added on top. A company that embeds someone else's AI screening tool into its own hiring workflow doesn't get to skip Article 26 because it didn't build the model. It's the deployer, and deployer obligations include using the system per its instructions, monitoring its operation, and retaining the logs the provider's system generates for at least six months.

The penalty math and how enforcement will actually land

The penalty structure has three tiers, and each figure is whichever number is larger, calculated against global annual turnover rather than EU revenue alone.

Enforcement in year one will be uneven. Not every member state had fully staffed its market surveillance authority by August 2, and the European AI Office is still building its own capacity for GPAI-related oversight. That's an enforcement-capacity problem, not a legal one. GDPR's first eighteen months looked similar: the law was in force well before the first meaningful fines landed, and companies that treated the gap as a grace period spent 2019 explaining themselves anyway.

The complaint path matters more here than a proactive audit does. Article 12 records rarely get requested in bulk. They get requested one decision at a time, triggered by a rejected applicant, a denied claim, or a worker who wants to know why an algorithm flagged their output. A system that can answer 99% of aggregate compliance questions but can't reconstruct one specific April 11 decision hasn't partially failed Article 12. It has failed the only kind of request the article actually anticipates.

What to build this quarter, not before the next audit

None of this gets solved by a review before the next board meeting. Prompt versioning, retrieval-set capture, and model-version pinning are schema and pipeline decisions, and retrofitting them onto six months of unstructured logs after the fact recovers very little of what a real Article 12 request would need.

The systems that will pass a genuine reconstruction request are the ones where decision records were designed as decision records from the first commit, not bolted onto existing observability tooling once the deadline arrived. That usually means three concrete changes: pinning the prompt template version and the model checkpoint to every inference call rather than to a release note, snapshotting the retrieved context for any RAG-based decision instead of only the final answer, and giving every automated decision a stable ID that a human-oversight action can attach to later. None of the three requires new infrastructure so much as a decision, made early, to treat a model call as an auditable event rather than a stateless API request.

Teams shipping anything that touches employment, credit, insurance, or public-service eligibility in the EU have a narrower window than most compliance checklists suggest. The classification question comes first. The logging architecture comes right after it, and it's the one most teams are still missing two weeks into enforcement.