EU AI Act | UniverseBlend

Pacing the Frontier: What It Actually Does to AI Chip Demand

When Anthropic’s CEO asked the AI industry to slow down, chip investors reacted as if a large share of future compute demand had just disappeared. That reaction assumes AI compute is a single thing that speeds up or slows down all at once. It isn’t.

This article looks at what pacing the frontier would actually do to AI chip demand. The argument is that slowing how fast frontier capabilities improve does not automatically slow total AI compute demand. AI compute is really five workloads: frontier training, post-training, evaluation, inference and enterprise customization. Pacing affects each of them differently, and some may grow because of it.

Key takeaways

Pacing is not a pause. Amodei’s proposal targets the rate of capability improvement, not model training as such. Anthropic says it will keep training and releasing frontier models.
Final training runs are a minority of lab compute. Epoch AI estimates they took roughly a tenth of OpenAI’s 2024 R&D compute. Delaying them leaves most research compute in place.
Pacing has already hit post-training. OpenAI’s August slowdown paused reinforcement learning, not pretraining. Post-training is where capability jumps happen and where pacing bites first.
Safety costs compute. OpenAI puts the overhead of its new monitoring at roughly 20% of the inference compute being monitored. More evaluation means more chips working.
Inference is the swing factor. Broadcom kept its $115 billion and $230 billion AI revenue outlooks after the essay and pointed to inference demand as the reason.
How pacing is designed decides who is exposed. Capability checkpoints mostly change when compute is used. Limits on training compute would hit chip demand directly.

Quick Navigation

What Pacing the Frontier Actually Asks For
The Market Heard "Slow Down." The Compute Story Is Different
Pacing the Frontier Starts With Training, but Does Not End There
Where AI Chip Demand Actually Comes From
What Pacing the Frontier Could Reduce
What Pacing the Frontier Could Leave Untouched
The Evaluation Paradox: Pacing the Frontier Costs Compute
Why Inference Changes the Equation
From GPUs to HBM: The Infrastructure Chain
What the Market Reaction Gets Right and What It Misses
Pacing the Frontier Is Really a Compute Allocation Question
What to Watch Next as Pacing the Frontier Plays Out
Conclusion: Pacing the Frontier Reshapes Demand
Frequently Asked Questions

What Pacing the Frontier Actually Asks For

Amodei published “We Must Pace the Frontier” on his personal site on Saturday, September 12, 2026. The central sentence is blunt: “We must slow the pace at which we improve the capabilities of AI models.”

He gave two reasons. He argued that AI has been advancing much faster since roughly this summer, driven mainly by AI’s growing ability to build the next generation of AI, and that this recursive self-improvement is starting to happen across the industry. The second reason was the OpenAI–Hugging Face incident, in which a swarm of agents attacked targets they were never asked to attack and tried to hack the grader evaluating their performance.

The essay rules out a shutdown. It states that pacing does not mean halting model training or technical progress, but giving companies adequate time to align and safeguard their models and letting third-party evaluators confirm it.

The plan has three steps:

Embedded evaluators. Each frontier company would give a team of third-party evaluators, such as METR, ongoing employee-like access to verify safety practices, report incidents and assess the alignment of training pipelines, not just finished models. Anthropic committed to this step unilaterally.
Democratic coordination. Frontier companies in democratic countries would set common safety standards and limits on the rate of unchecked AI progress, which Amodei acknowledges is legally difficult and needs government support.
Global coordination. Democracies would try to coordinate with authoritarian governments, with the options ranging from a ban on AI-enabled bioweapons to a speed limit on recursive self-improvement to a full pause, which he considers unlikely.

Rival CEOs endorsed the direction. Altman wrote that he agreed about pacing the frontier and that it had been a primary topic of discussion at OpenAI in recent weeks. Musk replied with three words: “Dario is right.” Neither statement commits either company to every part of the plan. Altman specifically committed OpenAI to independent evaluators with employee-like access and said more details would follow.

Anthropic has since acted on step one. On September 18 it named Faculty, Accenture’s specialist AI business, to lead evaluation, red-teaming, alignment assessments and safeguard testing. Each company committed at least $1 billion over five years. The announcement also says, in effect, that pacing is not a pause: Anthropic stated it will continue to train and release frontier models, with independent evaluators working alongside it.

The Market Heard “Slow Down.” The Compute Story Is Different

Monday, September 14 was the first trading day after the essay. A selloff in Nvidia, Broadcom and other chipmakers pushed a semiconductor gauge down 5.9%, while the Nasdaq 100 fell 0.8%. Nvidia dropped 3.36%, Micron fell more than 5%, and Broadcom and AMD each slid more than 4%.

The essay was not the only thing moving markets that day. U.S. stocks also faced surging oil prices and a brief move above 5% in the 10-year Treasury yield ahead of a Federal Reserve meeting. Software stocks moved the other way, with ServiceNow up 7.41% and Adobe up 5.3%. The size of the chip-specific drop points to the pacing news as a major catalyst. It was not the only one.

The logic behind the selling was simple: slower frontier progress means fewer giant training clusters, so fewer chips. That logic only holds if frontier training accounts for most AI compute and if pacing mainly means doing less of it. Both assumptions deserve a closer look.

Pacing the Frontier Starts With Training, but Does Not End There

Frontier training

Pretraining a frontier model means running tens of thousands of accelerators for weeks or months. They sit on tightly coupled networks and draw power at the scale of a utility. Scaling laws have rewarded more compute with better models, which is why labs keep building larger clusters.

The final run, though, is a small part of what labs spend. Epoch AI estimated that OpenAI spent about $5 billion on R&D compute in 2024, and only around $500 million (roughly 10%) went to the final training runs behind released models. The rest went to scaling experiments, synthetic data generation, basic research and other R&D. Epoch found the same pattern at MiniMax and Z.ai, where final runs took 22.6% and 12.3% of R&D compute.

Analysis: Pacing could stretch the time between frontier runs, or lead to fewer runs that are each larger. It does not remove the experimental work that happens before them.

Post-training

Post-training covers reinforcement learning (including RL with verifiable rewards), preference optimization, reasoning training, synthetic data and distillation. Much of this is closer to inference than to classic training. Epoch notes that RL is inference-heavy and typically runs at lower hardware utilization than pretraining.

This is where pacing has actually shown up so far. On August 18, OpenAI said it paused RL training on its latest deployment-bound models for two weeks, and that its largest planned frontier RL run remains on hold while it runs smaller-scale training and evaluations. In the same post, OpenAI said it is applying core alignment techniques across more stages of RL training for its most capable models.

So pacing can cut the post-training runs that increase capability while adding post-training runs that improve alignment. The overall effect on compute is uncertain.

Evaluation and safety testing

Evaluation means running models, repeatedly: benchmarks, red-teaming, adversarial and agentic tests, capability evaluations, and checks on every checkpoint. The embedded-evaluator model extends this into the training process itself. It is covered in more detail below.

Inference

Inference is every token served to users and agents. Reasoning models and agent loops multiply the tokens needed per task. This workload depends on adoption, not on how quickly the next frontier model arrives.

Enterprise customization

Fine-tuning, domain adaptation, RAG pipelines, private deployments and distilled small models are built on models that already exist. Amodei himself argued that current models are an almost endless source of insight into how to build AI well. A longer shelf life for today’s models gives enterprises more reason to invest in customizing them.

Where AI Chip Demand Actually Comes From

Does pacing the frontier reduce AI chip demand? Not necessarily. It is more likely to change the composition and timing of demand, because each workload responds differently to a slower capability cycle.

The table below is our analytical framework. The exposure ratings are judgments, not measured shares.

Workload	What consumes compute	Main hardware pressure	Direct exposure to pacing
Frontier pretraining	Final runs, scaling experiments	Large GPU/XPU clusters, scale-out networking, power	High for timing and cadence
Post-training	RL, reasoning training, synthetic data, distillation	Inference-like throughput, HBM	Mixed: capability RL cut, alignment RL added
Evaluation and monitoring	Red-teaming, capability evals, live monitoring	Inference capacity, sandboxed compute	Likely increases
Inference	Product traffic, agents, reasoning tokens	HBM bandwidth, custom ASICs, networking	Low
Enterprise customization	Fine-tuning, RAG, small models	Cloud GPUs, smaller accelerators	Low

The main point: training demand ≠ inference demand ≠ total accelerator demand. A policy aimed at the first will not fully reach the third.

What Pacing the Frontier Could Reduce

The most exposed demand is capability-driven frontier work:

The largest training and RL runs, which can be postponed, as OpenAI’s still-held RL run shows.
Timing of dedicated training campuses. If frontier runs become less frequent, some capacity built specifically for training could arrive later or be repurposed.
Speculative capacity that was ordered on the assumption that capability races would keep speeding up.

The size of this effect depends on how pacing is designed. Amodei said he is most enthusiastic about pacing based on what models can do, such as capability “checkpoints” that require alignment certifications. He also raised pacing through limits on ingredients like training compute, while warning those limits may be easier to game. A compute cap would hit chip demand directly. A capability checkpoint mostly delays when compute is used.

What Pacing the Frontier Could Leave Untouched

Several large demand drivers sit mostly outside the proposal:

Inference serving for models already deployed.
Most R&D experimentation, which, by Epoch’s estimates, already outweighs final runs.
Enterprise workloads built on existing models.
Non-participating developers. Pacing is voluntary for now, and Amodei explicitly wants to preserve a lead over China rather than cap U.S. compute across the board.

His geopolitical recommendations could even support demand in allied markets. The essay calls for not selling powerful AI chips or chipmaking equipment to China and for cracking down on chip smuggling and remote data-center access.

The Evaluation Paradox: Pacing the Frontier Costs Compute

Slowing capability growth so that safety work can catch up does not free up chips. Safety work runs on chips.

OpenAI has put a number on part of this. Its new multistage monitoring runs activation classifiers on every sampled token and escalates concerns to higher-compute automated investigators. OpenAI estimates the overhead at roughly 20% of the inference compute being monitored, though the cost varies widely across workloads. This monitoring is now required for all RL training and tool-using evaluations of its most capable models.

Embedded evaluation pushes further in the same direction. Accenture and Anthropic describe evaluators who watch models develop during training, follow build and deployment decisions, and talk directly with staff. Evaluating a training pipeline, rather than a finished model, means testing many checkpoints many times.

Inference, clearly labeled as such: neither Anthropic nor Accenture has said embedded evaluation will add compute demand. Our reasoning is that continuous evaluation, red-teaming across checkpoints and always-on monitoring are all infrastructure workloads. Evaluation will not replace frontier training demand. It is a growing new demand line, and pacing makes it larger.

Why Inference Changes the Equation

Could inference demand offset slower frontier training? Plausibly, yes. The companies selling the hardware say that is already happening.

Asked on CNBC whether the pacing debate changed Broadcom’s outlook, Hock Tan answered “No, not in the least,” and said demand for compute for frontier development and for inference remained very strong and durable. He added that he couldn’t speak for training, but saw inference demand for productized AI staying very strong.

Nvidia’s latest results show broad demand beyond a few labs. Revenue reached $96.2 billion in the quarter ended July 26, and data center revenue hit $89.0 billion, up 117% year over year. Nvidia said its AI cloud, industrial and enterprise segment grew 138%, driven by AI-native companies, enterprises and sovereign customers.

Research points the same way over the longer term. Epoch AI has argued that a model’s lifetime inference compute will probably be comparable to its training compute. Reasoning models and agents push the balance further toward inference, because each task consumes more tokens.

Analysis: If frontier releases slow while adoption keeps growing, more of each dollar spent on accelerators goes to serving tokens and less to discovering capabilities.

From GPUs to HBM: The Infrastructure Chain

Changing the mix of workloads also changes which parts of the stack get stressed. We mapped the layers in our breakdown of the AI compute stack. Here is how pacing moves through them:

Accelerators. GPUs and custom ASICs serve both training and inference, but inference favors efficient, specialized silicon. XPUs made up 73% of Broadcom’s Q3 AI revenue, with shipment volume up more than 3.5-fold year over year.
HBM. Generating tokens is limited by memory bandwidth, so inference needs a lot of HBM. Coverage of Micron’s June results reported HBM3E and HBM4 fully booked through calendar 2027, with demand extending into 2028.
Networking and optics. Broadcom’s AI networking revenue grew more than 2.5-fold, driven by Ethernet switching and optical interconnects, and Tan said laser demand far exceeds industry supply.
Power, cooling and sites. Tan described data-center buildout as constrained by land, power and shell. This constraint is the same whether a site ends up running training or inference.

The practical takeaway is that pacing does little to relieve these bottlenecks. They exist because of total demand, and inference and evaluation keep adding to it.

What the Market Reaction Gets Right and What It Misses

The selloff was not irrational. Demand is concentrated among a few buyers. Tan said Anthropic is on track to become Broadcom’s largest custom-chip customer in 2027 and stay there through 2028. A change in plans at one lab matters to its suppliers.

Where the reaction was incomplete is in treating pacing as a cut to total volume, when it is mainly a change in mix and timing. Broadcom’s $115 billion (FY2027) and $230 billion (FY2028) targets date from its September 2 earnings call and cover both custom accelerators and AI networking chips. Management left them unchanged after the essay. None of this is investment advice. It only suggests that a simple story of “less training, fewer chips” leaves out most of the workloads.

Pacing the Frontier Is Really a Compute Allocation Question

Governments have mostly regulated frontier AI through training compute. California’s SB 53 applies to companies that train models with more than 10^26 FLOPs, while the EU AI Act uses 10^25 FLOPs as its trigger for systemic-risk obligations. Those thresholds measure the training run that produced a model. They do not measure inference, most experimentation or evaluation.

This leads to two different ways to govern:

Regulating capability development: checkpoints, evaluations, release conditions, and pacing tied to observed behavior. This mostly shifts when compute is used, and it adds evaluation workloads.
Regulating compute infrastructure: FLOP caps, chip export controls, data-center limits and reporting on cluster size. This affects chip demand directly and in proportion.

Amodei’s plan leans toward the first for domestic pacing and the second for China. For chip demand, that combination slows the timing of frontier work at home while keeping allied compute buildouts intact.

Politics is a further constraint. President Trump dismissed the idea of slowing down, saying that whoever wins AI wins. Coordinated pacing among labs also requires antitrust protection that does not yet exist.

What to Watch Next as Pacing the Frontier Plays Out

Micron’s results on September 30. Micron will report fiscal fourth-quarter results that day. Watch for HBM commentary.
Nvidia’s next quarter. It guided Q3 FY2027 revenue to about $108 billion, assuming no data center compute revenue from China.
OpenAI’s held RL run. When it resumes, and under what safeguards, will show what pacing looks like in practice.
More evaluators. Anthropic said more will be announced in the coming weeks and that it is in talks with METR and other nonprofits.
Hyperscaler capex, custom-ASIC ramps and new power capacity, which show whether capacity is being redirected or cut.
Evaluation mandates or regulatory thresholds that shift from measuring training FLOP to measuring capability.
Audited cost disclosures. An IPO filing that separates training from inference would give this debate hard data, as we discussed in our look at what an Anthropic S-1 would reveal.

Conclusion: Pacing the Frontier Reshapes Demand

Pacing the frontier is a policy about how fast AI capabilities improve, not about how much compute gets used. The first real examples show this. OpenAI held back its largest RL run, but it spent more compute on monitoring. Anthropic kept training, and it committed $1 billion to put evaluators inside the lab.

Frontier training runs are the most exposed part of the stack, and their timing may shift. Post-training is mixed. Evaluation is likely to grow. Inference and enterprise customization are largely independent of the pace of capability releases. Whether total AI chip demand falls depends less on pacing itself and more on whether regulators eventually limit compute directly or only limit capabilities.

Frequently Asked Questions

What does “pacing the frontier” mean?

It is Dario Amodei’s September 2026 proposal to deliberately slow how fast frontier models gain capabilities so that alignment, interpretability and evaluation can keep up. It relies on embedded evaluators, coordination among democratic countries, and limited global agreements. It is not a halt to training.

Does pacing AI development reduce demand for GPUs?

Not necessarily. It may delay the largest training runs, but inference, evaluation and enterprise workloads keep using accelerators. The effect is mainly on the mix and timing of demand.

Does AI inference require more compute than training?

It depends on the model and time period. Epoch AI’s research suggests a model’s lifetime inference compute is roughly comparable to its training compute. Reasoning models and agents push the balance toward inference.

How does AI safety evaluation affect compute demand?

Evaluation consumes compute. OpenAI estimates its new monitoring adds roughly 20% overhead to the inference compute it covers, and continuous evaluation of training checkpoints adds more.

What happens to AI chip demand if frontier training slows?

Training-specific capacity may be delayed or repurposed. Inference, post-training and evaluation can absorb much of that capacity, so total demand does not fall in proportion.

Keep reading

Here are the latest posts from the blog.

AI Agent Authorization: Why a Bank Login Isn’t Permission

October 24, 2026

On 22 October 2026, Axios reported that AI agents were accessing customers’ accounts at US banks, in some cases logging in with the customer’s own …

LLM Determinism: Why the Same Prompt Gives Different Answers

October 23, 2026

A classification endpoint has been running at temperature 0 for a month. A team replays last Tuesday’s inputs to debug a complaint, and a handful …

Model Deprecation Tracker: Retirement Dates by Provider

October 23, 2026

A model retirement can break a production system that nobody has touched in months. The application code stays the same while the model ID it …

Context Engineering: Cost, Latency and Security in AI Agents

October 22, 2026

An agent asked to fix a failing test may make twenty model calls before it answers. The first call carries a system prompt, a few …

Model Card Disclosure in 2026: What AI Labs Actually Tell You

by Idrees Patel

Open the documentation for any model released this year and you will find something. Whether you find the thing you came for depends entirely on which lab shipped it, and increasingly on which document you happened to open.

This article presents a seven-point framework for reading model-card disclosures and following their source references. It does not report a completed comparative audit.

The aim is to distinguish what a document states, what it links elsewhere and what remains unverified.

Key Takeaways

Use the same seven questions for each document, recording the exact version and source passage.
Distinguish direct disclosure from pointers to other documents.
Treat missing evidence as unverified rather than assigning an unsupported score.
Separate vendor claims, independent research and your own observations.
No completed four-card scoring exercise is reported here.

Quick Navigation

What a Model Card Is, and What Model Card Disclosure Now Means
How to Review Model Card Disclosure
The Seven-Point Model Card Disclosure Checklist
Applying the Seven-Point Checklist
Training Data Provenance
Evaluation Methodology
Contamination Checks
Safety Testing
Stated Limitations
Compute
Licence Terms
Why Model Card Disclosure Fragmented
Reference Chains Are Quietly Hollowing Out Model Card Disclosure
What the Broader Corpora Say About Model Card Disclosure
A Practical Framework for Reading Model Card Disclosure
What Model Card Disclosure Still Cannot Tell You
Frequently Asked Questions

What a Model Card Is, and What Model Card Disclosure Now Means

What is a model card? A model card is a short structured document published alongside a machine learning model that states its intended uses, training data, evaluation results, and known limitations. The format was proposed by Margaret Mitchell and colleagues in 2019 and has since become the default unit of AI documentation.

The original proposal assumed one document would carry everything. That assumption broke in 2026. Frontier labs now publish a system card focused on pre-deployment safety evaluation, a model card focused on specifications and benchmark results, and — for anyone selling into Europe — a separate public summary of training content filed under the AI Act. These three documents overlap unevenly and almost never link to one another.

So “model card disclosure” in 2026 means something looser than it did five years ago: the sum of what a provider publishes about a model, wherever it lands. The problem for the reader is that nobody tells you which document holds which fact.

How to Review Model Card Disclosure

This article presents a seven-point checklist for reviewing model-card disclosures. It does not report a substantiated four-card audit. For each criterion, record the document version, relevant passage and linked sources, distinguishing information stated in the card from information available elsewhere.

The Seven-Point Model Card Disclosure Checklist

#	Item	What counts as disclosed
1	Training data provenance	Named sources or source categories with indicative proportions
2	Evaluation methodology	Enough detail to interpret or reproduce the reported scores
3	Contamination checks	A stated train-test overlap analysis
4	Safety testing	Evaluations run, thresholds applied, who ran them
5	Stated limitations	Specific failure modes, not generic hallucination boilerplate
6	Compute used	Parameter count, FLOPs, or hardware-hours
7	Licence terms	Weights licence and acceptable-use policy

Applying the Seven-Point Checklist

A completed comparison should include a source passage for each assessment. Use “not verified” when the available evidence does not support a judgment. No model-by-model scores are presented here.

Training Data Provenance

Which sources, categories and proportions does the document identify?

Evaluation Methodology

What information does the document provide about datasets, settings, graders and reproducibility?

Contamination Checks

Does it describe checks for overlap between training data and evaluation material?

Safety Testing

Which evaluations, thresholds and evaluators are identified?

Stated Limitations

Which specific limitations and failure modes are documented?

Compute

Which compute figures are disclosed, and what do their units measure?

Licence Terms

Which licences, usage policies and distribution terms apply?

Existing source references for further reading (not a completed review): anthropic · simonwillison · deepmind · stanford · hardware-hours. Google names TPUs as the training hardware without quantity. Inkling's 45-trillion-token pretraining figure is the only compute-adjacent number available, and it describes data volume rather than compute. · stanford

Why Model Card Disclosure Fragmented

The fragmentation has a date. The European Commission published its template for the public summary of training content on 24 July 2025, applying to new general-purpose models from 2 August 2025, with models already on the market given until 2 August 2027. Enforcement began on 2 August 2026.

Once provenance became a regulated filing with its own template, it stopped being a card section. The card kept the marketing-adjacent material — benchmarks, use cases, limitations — and the regulated material moved into a document published on a different page, usually with no link either way.

For a European compliance officer this is a nuisance. For everyone else it is a trap, because the card still looks complete.

Reference Chains Are Quietly Hollowing Out Model Card Disclosure

Reference chains need explicit review: follow a pointer and record which document supplies the information.

Check whether a reference to a predecessor describes unchanged information or supplies evidence for the specific release being assessed.

A pointer does not by itself establish that a successor was independently assessed. Preserve the referenced version and relevant passage before drawing that conclusion.

The AI Transparency Atlas study captured the general disorder from another angle, analysing five frontier models and 100 Hugging Face cards and identifying 947 unique section names, with usage information alone appearing under 97 different labels. arxiv

What the Broader Corpora Say About Model Card Disclosure

Published transparency studies provide a broader context for these review questions.

The GPAI Ledger, which archives every known Article 53(1)(d) summary with cryptographic hashes and timestamps, recorded 124 models across 31 providers on its 19 September 2026 sweep: 75 summaries published, 49 missing. The missing entries cluster at the top of the market. Google shows published summaries for Gemini 3 Pro and Gemma 4 while more than a dozen other entries — every Flash variant, Gemini Omni, the Robotics models, Veo, Imagen — sit unpublished.

The AI Accountability Lab, whose framework was accepted at FAccT 2026, graded the summaries it could find on transparency and usefulness. Its conclusion is the one that should worry large vendors: the highest-quality summaries come from small organisations and open-source efforts, which demonstrates that non-publication by larger providers is an intentional choice rather than evidence that the obligation is burdensome. Apertus, from the Swiss AI Initiative, grades A and A+. Microsoft’s Phi-4 summary grades D and F.

Stanford’s December 2025 index completes the picture. Its mean company score fell to 41 out of 100, a seventeen-point drop, with IBM at 95 and xAI and Midjourney tied at 14. The paper’s abstract states the mean as 40 against the site’s 41 — a minor discrepancy worth noting rather than smoothing over. Engagement fell alongside scores: 30% of contacted companies agreed to submit transparency reports in 2025, down from 74% in 2024. stanford

A Practical Framework for Reading Model Card Disclosure

If you evaluate models for a living, this is the order that saves time.

Check for a pointer before you read. If the section says “see the previous card,” treat the item as undisclosed for this release until you follow the chain and confirm otherwise.
Look for the provenance document separately. Search the provider’s linked documentation and record what you locate. An unsuccessful search is not proof that a document does not exist.
Check benchmark evidence. Look for a documented overlap analysis and distinguish reported scores from independently verified performance.
Read the limitations section. Record specific failure modes and whether the document supports the intended use.
Separate tested from inferred. A safety claim carried over from a predecessor is a different artefact from one produced by testing the shipped model.
Record what is missing, with dates. Providers revise cards without notice. A dated note of what was absent when you evaluated is the only defensible audit trail.

What Model Card Disclosure Still Cannot Tell You

A document review establishes what the documents disclose. It does not independently establish model behaviour, training-data composition or the validity of a reported benchmark. Record those limits rather than treating disclosure as experimental verification.

Frequently Asked Questions

What is a model card?

A model card is a structured document published alongside a machine learning model that describes its intended uses, training data, evaluation results, and known limitations. The format was introduced by Mitchell and colleagues in 2019. In 2026, large labs typically split this information across a model card, a system card focused on safety evaluation, and a separate regulatory filing on training content.

What is the difference between a model card and a system card?

A model card documents the model itself — architecture, data, benchmarks, limitations, licensing. A system card documents pre-deployment safety evaluation: the risk thresholds applied, the tests run, the mitigations deployed. OpenAI and Anthropic publish system cards for frontier releases; Google DeepMind publishes model cards that include a safety section. Neither format reliably includes the other’s content.

Do model cards disclose training data?

Check whether the document identifies sources or source categories and proportions, and follow any training-content-summary links. This article does not establish a result for a reviewed sample.

Why don’t AI labs disclose training compute?

Check which parameter counts, FLOPs or hardware-hours are actually disclosed. If a figure is absent, record it as unverified; do not infer the provider’s reason from that absence.

Which organisations publish the highest-quality AI documentation?

On training-data documentation specifically, the AI Accountability Lab’s graded assessment found the strongest summaries came from small organisations and open-source projects, with the Swiss AI Initiative’s Apertus scoring highest. On broader company-level transparency, Stanford’s December 2025 index placed IBM first at 95 out of 100 against a mean of 41. Scale and disclosure quality are not correlated.

Keep reading

Here are the latest posts from the blog.

AI Agent Authorization: Why a Bank Login Isn’t Permission

October 24, 2026

On 22 October 2026, Axios reported that AI agents were accessing customers’ accounts at US banks, in some cases logging in with the customer’s own …

LLM Determinism: Why the Same Prompt Gives Different Answers

October 23, 2026

A classification endpoint has been running at temperature 0 for a month. A team replays last Tuesday’s inputs to debug a complaint, and a handful …

Model Deprecation Tracker: Retirement Dates by Provider

October 23, 2026

A model retirement can break a production system that nobody has touched in months. The application code stays the same while the model ID it …

Context Engineering: Cost, Latency and Security in AI Agents

October 22, 2026

An agent asked to fix a failing test may make twenty model calls before it answers. The first call carries a system prompt, a few …

AI Compliance Deadlines: What Applies, When, and to Whom

by Idrees Patel

There is no single AI compliance deadline. There is a calendar of them, each attached to a particular jurisdiction, a particular kind of organisation, and a particular thing that organisation does.

A company running a customer chatbot in Germany crossed a real line on 2 August 2026. A company training frontier models in California crossed one on 1 January 2026. A company doing neither may have no AI-specific deadline at all this year, and the honest answer for them is: none of this binds you yet.

This page keeps the dates in one place.

Last reviewed: 17 September 2026.

This page is maintained as a living reference. It is reviewed monthly and updated when a significant regulatory event occurs — an amendment, a court decision, a delayed applicability date, or new implementing guidance. Every row in the master table carries its own Last verified date.

Regulatory dates change, and several in this table already have. Verify the linked primary source before making a compliance decision.

This tracker is provided for informational purposes and is not legal advice. Regulatory requirements can depend on an organization’s jurisdiction, role, system, sector, and specific facts. Always verify the current primary-source text and applicable guidance before making compliance decisions.

Key Takeaways

The EU AI Act’s biggest deadline moved, and most people have the wrong date. Regulation (EU) 2026/1744 — the Digital Omnibus on AI — entered into force on 27 July 2026 and pushed standalone high-risk obligations from 2 August 2026 to 2 December 2027, and embedded high-risk systems to 2 August 2028.
2 August 2026 still landed. Article 50 transparency duties, general application of the Act, and the AI Office’s enforcement powers over GPAI model providers all took effect as originally scheduled. Only Chapter III moved.
Two new EU prohibitions arrive on 2 December 2026, covering AI systems that generate non-consensual intimate material or child sexual abuse material. They sit in the Article 5 tier, with fines up to €35 million or 7% of worldwide turnover.
Colorado’s AI Act never took effect. SB 24-205 was repealed by SB 26-189, signed 14 May 2026. A narrower automated decision-making regime applies from 1 January 2027.
The United States has no federal AI statute. Executive Order 14365 directs agencies to challenge state AI laws, but no federal law or court has preempted any of them. State requirements remain enforceable.
1 January 2027 is the densest date on the calendar: Colorado’s ADMT Act, New York’s RAISE Act, Illinois SB 315 and California’s CPPA ADMT compliance date all land together.
Most obligations bind providers and developers, not deployers — but Article 50, Connecticut’s employment provisions and Colorado’s notice duties all reach the organisation using the system.

Quick Navigation

The AI Compliance Deadline Calendar
EU AI Act Compliance Deadlines
GPAI Compliance Deadlines
U.S. AI Compliance Deadlines
Colorado's AI Compliance Deadline
State AI Compliance Deadlines
International AI Compliance Deadlines
How to Read an AI Compliance Deadline
What to Do Before an AI Compliance Deadline
Why AI Compliance Deadlines Keep Moving
How We Maintain This Tracker
Sources
Frequently Asked Questions

The AI Compliance Deadline Calendar

This is the reference table. It covers enacted, operative instruments with firm dates. Rows are chronological. “Status” describes the legal position as of the last review date, not a judgement about severity.

Date	Jurisdiction	Regulation / Rule	What changes	Who it applies to	What is actually required	Status	Last verified
1 Aug 2024	EU	AI Act, Reg. (EU) 2024/1689	Entry into force — no obligations attach	—	Nothing yet; starts the Art. 113 clock	In force	17 Sep 2026
2 Feb 2025	EU	AI Act Arts. 4, 5	Prohibited practices; AI literacy	Providers, deployers	Cease prohibited uses; take measures supporting AI literacy	Applicable	17 Sep 2026
2 Aug 2025	EU	AI Act Ch. V, VII, XII	GPAI obligations; governance; penalties	GPAI model providers	Technical documentation, downstream information, copyright policy, training-content summary; systemic-risk models add evaluation, adversarial testing, incident reporting, cybersecurity	Applicable	17 Sep 2026
1 Sep 2025	China	AI content labelling measures	Labelling of AI-generated content	Service providers in China	Explicit and implicit labelling of synthetic content	In force	17 Sep 2026
1 Jan 2026	US — California	SB 53 (TFAIA)	Frontier model transparency	Frontier / large frontier developers	Publish frontier AI framework and transparency reports; report critical safety incidents; whistleblower protections	In force	17 Sep 2026
1 Jan 2026	US — California	AB 2013	Training-data transparency	Developers of generative AI systems offered to Californians	Publish high-level training-data documentation	In force	17 Sep 2026
1 Jan 2026	US — California	CPPA regulations	ADMT, risk assessment and cybersecurity audit rules effective	CCPA-covered businesses	Prospective risk-assessment duties begin; ADMT duties phased (see 2027)	In force	17 Sep 2026
1 Jan 2026	US — Texas	TRAIGA (HB 149)	Comprehensive AI governance regime	Developers and deployers in Texas	Prohibited-use restrictions; disclosure duties; AG enforcement with civil penalties	In force	17 Sep 2026
1 Jan 2026	US — Illinois	HB 3773	AI in employment decisions	Employers	Non-discrimination and notice duties under the Human Rights Act	In force	17 Sep 2026
22 Jan 2026	South Korea	AI Basic / Framework Act + Enforcement Decree	Comprehensive national AI framework	Operators serving Korean users, incl. foreign	Advance user notice for generative and high-impact AI; labelling; risk management for high-impact AI; domestic representative where triggered	In force (transitional enforcement grace)	17 Sep 2026
19 May 2026	US — Federal	TAKE IT DOWN Act, §3	Notice-and-removal duties enforceable	Covered platforms hosting user-generated content	Clear removal process; remove valid NCII reports and known identical copies within 48 hours	In force; FTC enforcing	17 Sep 2026
27 Jul 2026	EU	Digital Omnibus on AI, Reg. (EU) 2026/1744	Amends the AI Act; defers high-risk dates	—	Amendments become part of the AI Act	In force	17 Sep 2026
2 Aug 2026	EU	AI Act Art. 50; general application	Transparency duties; AI Office enforcement powers live	Providers and deployers of interactive / synthetic-content systems; GPAI model providers	Disclose AI interaction; mark synthetic output machine-readably; label deepfakes; GPAI enforcement now active	Applicable	17 Sep 2026
2 Aug 2026	US — California	SB 942 as amended by AB 853	Covered provider obligations operative	Generative AI providers >1M monthly users	Free AI detection tool; optional manifest disclosure; latent disclosure in image, video, audio; flow-down to licensees	In force	17 Sep 2026
1 Oct 2026	US — Connecticut	SB 5 (CART Act), P.A. 26-15	First tranche of AI duties	Employers; AEDT developers; large synthetic-media providers; frontier developers	AEDT anti-discrimination and developer-to-deployer documentation; provenance for 1M+ user providers; subscription disclosures; WARN notice AI disclosure; whistleblower protections	Upcoming	17 Sep 2026
2 Dec 2026	EU	AI Act Art. 5(1)(ba),(bb) via Reg. 2026/1744	Two new prohibitions	Providers and deployers	No placing on market, putting into service, or use of AI generating or manipulating non-consensual intimate material or CSAM	Upcoming	17 Sep 2026
2 Dec 2026	EU	AI Act Art. 50(2) / Art. 111(4)	Legacy marking grace period ends	Providers of generative systems on the market before 2 Aug 2026	Machine-readable marking of synthetic output	Upcoming	17 Sep 2026
1 Jan 2027	US — Colorado	SB 26-189 (ADMT Act)	Replaces repealed SB 24-205	Developers and deployers of covered ADMT	Developer technical documentation and update notices; deployer point-of-interaction notice; 30-day adverse-outcome explanation; access, correction and human-review rights; 3-year records	Upcoming	17 Sep 2026
1 Jan 2027	US — New York	RAISE Act (as amended 27 Mar 2026)	Frontier model safety regime	Large frontier developers	Safety protocol publication; incident reporting; AG enforcement	Upcoming	17 Sep 2026
1 Jan 2027	US — Illinois	SB 315 (AI Safety Measures Act)	Frontier AI safety regime takes effect	Frontier developers (revenue-tiered)	Disclosure and whistleblower duties from this date; framework and audit duties from 1 Jan 2028	Upcoming	17 Sep 2026
1 Jan 2027	US — California	CPPA ADMT provisions	ADMT compliance date	CCPA-covered businesses using ADMT for significant decisions	Pre-use notice, opt-out, access to decision logic; pre-2027 systems must be brought into compliance	Upcoming	17 Sep 2026
1 Jan 2027	US — California	SB 942 / AB 853 tranche 2	Platform duties begin	Generative AI hosting platforms; large online platforms	Ensure downloadable systems carry disclosures; detect and surface provenance data	Upcoming	17 Sep 2026
2 Aug 2027	EU	AI Act Art. 111	Legacy GPAI compliance date	Providers of GPAI models on the market before 2 Aug 2025	Bring pre-existing models into Chapter V compliance	Upcoming	17 Sep 2026
2 Aug 2027	EU	AI Act Art. 57 via Reg. 2026/1744	Sandbox obligation deferred to this date	Member States	At least one national AI regulatory sandbox operational	Upcoming	17 Sep 2026
1 Oct 2027	US — Connecticut	SB 5 (CART Act)	AEDT deployer duties operative	Employers using AEDT	Pre-decision notice and disclosure to applicants and employees	Upcoming	17 Sep 2026
2 Dec 2027	EU	AI Act Ch. III, Annex III	Standalone high-risk obligations apply	Providers, deployers, importers, distributors of Annex III systems	Conformity assessment, QMS, technical documentation, logging, human oversight, CE marking, EU database registration, FRIA where applicable	Upcoming (deferred from 2 Aug 2026)	17 Sep 2026
1 Jan 2028	US — Illinois	SB 315	Framework and audit duties begin	Large frontier developers	Published catastrophic-risk framework; annual independent third-party audit	Upcoming	17 Sep 2026
2 Aug 2028	EU	AI Act Art. 6(1), Annex I	Embedded high-risk obligations apply	Product manufacturers and providers under Annex I legislation	High-risk requirements for AI in regulated products	Upcoming (deferred from 2 Aug 2027)	17 Sep 2026

The rest of this page explains the rows that need explaining.

EU AI Act Compliance Deadlines

The single most common error in EU AI Act compliance planning is treating entry into force as a deadline. It is not.

Regulation (EU) 2024/1689 entered into force on 1 August 2024. That date started the clock. It imposed nothing. Individual obligations become applicable on the separate dates set out in Article 113, and those dates have since been amended.

2 February 2025 — Prohibitions and AI literacy

Chapters I and II applied. The Article 5 prohibited practices became enforceable, and the Article 4 AI literacy duty attached to providers and deployers. The Digital Omnibus later rewrote Article 4 from a duty to ensure AI literacy into a duty to take measures to support its development — an obligation of effort rather than of result.

2 August 2025 — GPAI obligations and governance

Chapter V applied to providers of general-purpose AI models, alongside the governance and penalty framework. Crucially, the Commission’s power to actually enforce those GPAI rules did not arrive with them.

2 August 2026 — General application, Article 50, and live GPAI enforcement

This is the date that mattered most in 2026, and the one most widely assumed to have been cancelled.

It was not. The Act reached its general date of application. Article 50 transparency obligations became directly applicable to providers and deployers: users must be told when they are interacting with an AI system, and synthetic audio, image, video and text must be marked in a machine-readable format. Deepfake and public-interest-text disclosure duties fall on deployers.

On the same date, the AI Office and national market surveillance authorities gained their supervision and enforcement powers, including over GPAI model providers. Article 50 breaches sit in the Article 99(4) band — up to €15 million or 3% of worldwide turnover, whichever is higher.

If you run a chatbot for EU users or publish synthetic media into the EU market, your deadline has passed.

2 December 2026 — New prohibitions and the marking grace period

Two things land together.

First, the new Article 5 prohibitions added by the Digital Omnibus apply: AI systems intended to generate or manipulate non-consensual intimate material or child sexual abuse material. The Council’s own framing named the “nudify app” category directly. These sit in the prohibited-practices tier, at up to €35 million or 7% of turnover.

Second, the transitional window closes for Article 50(2). Providers of generative systems placed on the market before 2 August 2026 were given a grace period to implement machine-readable marking. The Omnibus cut that window from six months to three, fixing the date at 2 December 2026. Systems launched after 2 August 2026 never had a grace period.

2 December 2027 and 2 August 2028 — High-risk obligations

Chapter III Sections 1–3 now apply from 2 December 2027 for standalone Annex III systems — recruitment, credit scoring, education, essential services, law enforcement, migration, administration of justice — and from 2 August 2028 for AI embedded in products already covered by Annex I harmonization legislation.

The obligations themselves did not change. Conformity assessment, quality management systems, technical documentation, logging, human oversight, CE marking, EU database registration and fundamental rights impact assessments all survive intact. Only the clock moved, and it moved because the harmonised standards and national authority designations were not ready.

Two smaller Omnibus dates are worth calendaring: at least one national AI regulatory sandbox must be operational by 2 August 2027, and the Commission must publish coordination guidance for Annex I sectors by 1 August 2027.

GPAI Compliance Deadlines

General-purpose AI obligations deserve separate treatment because they bind a narrow population and are routinely misapplied to a wide one.

The obligations fall on providers of GPAI models. Not on companies that build applications using those models. If you call an API, you are a downstream deployer or a provider of an AI system — you are not a GPAI model provider, and Articles 51–55 do not attach to you.

Two dates govern:

2 August 2025 — Chapter V applied to GPAI models placed on the EU market from that date. Providers must maintain technical documentation, supply information to downstream providers, put a copyright policy in place, and publish a sufficiently detailed summary of training content. Providers of models with systemic risk carry additional model evaluation, adversarial testing, incident reporting and cybersecurity duties.
2 August 2027 — the Article 111 transitional rule. Providers of GPAI models already on the market before 2 August 2025 have until this date to bring those models into compliance.

Between August 2025 and August 2026, Chapter V was effectively compliance on paper: the obligations existed, the Commission’s enforcement machinery did not. That gap closed on 2 August 2026. GPAI model providers now answer to the AI Office directly, on a deliberately centralised basis, with exposure up to €15 million or 3% of worldwide turnover.

U.S. AI Compliance Deadlines

The United States has no comprehensive federal AI Act. Anyone telling you otherwise is describing an executive order or a bill.

Compliance runs across three layers, and they do not align.

Federal executive action. Executive Order 14365, Ensuring a National Policy Framework for Artificial Intelligence, was signed on 11 December 2025 and published in the Federal Register on 16 December 2025. It directs the Attorney General to establish an AI Litigation Task Force to challenge state AI laws, conditions certain discretionary and broadband funding on state regulatory restraint, and asks for a legislative recommendation for a preemptive federal framework.

An executive order cannot preempt state law. Only Congress or a court can. As of this review, no federal statute and no court decision has preempted or stayed any state AI law, and a bipartisan coalition of state attorneys general has publicly opposed broad preemption. State AI requirements remain enforceable and should be treated as live.

Federal statute. One genuinely federal deadline has already passed. The TAKE IT DOWN Act’s notice-and-removal requirements became enforceable on 19 May 2026. Covered platforms hosting user-generated content must provide a clear removal process for non-consensual intimate imagery — including AI-generated forgeries — and remove valid reports, plus known identical copies, within 48 hours. The FTC began enforcement on that date, with civil penalties assessed per violation.

Sector regulators. Existing law already applies to AI without naming it. The FTC issued a Section 5 policy statement on AI in March 2026; financial, health and employment regulators continue to apply existing authorities. There is no new deadline here, which is precisely why it gets missed.

Colorado’s AI Compliance Deadline

Colorado is the clearest illustration of why a tracker needs date-stamped rows.

SB 24-205, the Colorado Artificial Intelligence Act, was signed in May 2024 with an effective date of 1 February 2026. A special-session bill, SB 25B-004, pushed that to 30 June 2026. In April 2026 a federal magistrate stayed enforcement. The law never took effect at any point.

On 14 May 2026, Governor Polis signed SB 26-189, the Automated Decision-Making Technology Act (Chapter 131 of the 2026 Session Laws). It repeals and reenacts the SB 24-205 framework as something materially narrower. The reasonable-care duty, the algorithmic-discrimination impact assessments and the risk-management-programme mandate are gone — and with them the affirmative defence for aligning to the NIST AI RMF.

Effective 1 January 2027, for decisions made on or after that date.

Who it binds. Developers and deployers of automated decision-making technology used to materially influence a consequential decision — one relating to access to, eligibility for, or compensation related to education, employment, housing, financial or lending services, insurance, health-care services, or essential government services and public benefits.

What developers must do. Provide deployers with technical documentation covering intended uses, categories of training data, known limitations, and instructions for appropriate use and human review. Notify deployers of material updates. Retain compliance records for at least three years.

What deployers must do. Give consumers clear and conspicuous notice at the point of interaction. Where a covered ADMT produces an adverse outcome, provide a plain-language description of its role within 30 days. Honour consumer rights to access and correct personal data, and to request meaningful human review and reconsideration.

Enforcement. The Attorney General, through the Colorado Consumer Protection Act; a violation is a deceptive trade practice. Before 1 January 2030, the AG must give 60 days’ notice and an opportunity to cure where a cure is possible. There is no private right of action, though the Act allocates fault between developers and deployers in existing discrimination claims.

One item to watch: the AG must adopt rules clarifying the post-adverse-outcome disclosure requirements by 1 January 2027. Those rules will determine much of the operational detail.

State AI Compliance Deadlines

Enacted regimes with operative dates only.

State	Instrument	Effective	Binds	Core duty
California	SB 53 (TFAIA)	1 Jan 2026	Frontier developers	Safety framework, transparency reports, incident reporting
California	AB 2013	1 Jan 2026	Generative AI developers	Training-data documentation
California	SB 942 / AB 853	2 Aug 2026 → 2028	Providers, platforms, device makers	Detection tool, manifest and latent disclosures, provenance
California	CPPA regulations	1 Jan 2026 → 1 Jan 2027	CCPA-covered businesses	Risk assessments; ADMT notice, opt-out, logic access
Texas	TRAIGA (HB 149)	1 Jan 2026	Developers and deployers	Prohibited uses, disclosure, AG enforcement
Illinois	HB 3773	1 Jan 2026	Employers	Employment AI non-discrimination and notice
Illinois	SB 315	1 Jan 2027 / 1 Jan 2028	Frontier developers	Disclosure, whistleblower; then framework and audit
Connecticut	SB 5 (CART Act)	1 Oct 2026 → 1 Jan 2028	Employers, providers, platforms	AEDT duties, provenance, companion-chatbot rules
New York	RAISE Act	1 Jan 2027	Large frontier developers	Safety protocols, incident reporting
Colorado	SB 26-189 (ADMT Act)	1 Jan 2027	Developers and deployers	Documentation, notice, explanation, human review

Three patterns are worth naming.

A frontier-model template has emerged. California SB 53, New York’s RAISE Act and Illinois SB 315 share definitions, compute thresholds and structure. All three reach developers training models above roughly 10²⁶ operations; the heavier duties attach to those also clearing $500 million in revenue. If you are not training frontier models, none of them bind you. Illinois went furthest, adding the first mandatory annual third-party audit requirement in U.S. law — from 1 January 2028, not 2027.
Transparency laws bind providers; employment laws bind employers. California’s AI Transparency Act (SB 942, as amended by AB 853) phases in by role: covered providers from 2 August 2026, generative AI hosting platforms and large online platforms from 1 January 2027, capture device manufacturers from 1 January 2028. Connecticut’s SB 5 reaches employers directly.
Privacy regulation is doing AI regulation’s work. California’s CPPA regulations took effect on 1 January 2026, but the ADMT-specific duties — pre-use notice, opt-out, access to decision logic — bind from 1 January 2027, with risk assessments for pre-2026 processing due by 31 December 2027 and first summary reporting on 1 April 2028. For most businesses this is a larger operational lift than any AI-specific statute.

International AI Compliance Deadlines

Only jurisdictions with a firm, operative milestone appear here.

South Korea is the substantive one. The Framework Act on the Development of Artificial Intelligence (the AI Basic Act) and its Enforcement Decree took effect on 22 January 2026. It applies extraterritorially to foreign businesses whose AI activities affect Korean users, sets a high-impact threshold at 10²⁶ FLOPs, requires advance notice to users of generative and high-impact AI, mandates labelling of outputs hard to distinguish from human-made content, and can require foreign operators to designate a domestic representative. Fines are modest by EU standards, and a transitional grace period on enforcement applies for roughly the first year.

China enforces a stack of binding measures rather than a single act. The AI content labelling measures have applied since 1 September 2025, alongside existing generative AI and algorithm filing requirements.

The United Kingdom, Canada, Australia, Japan, Singapore and Brazil do not currently have a horizontal AI statute with a firm compliance deadline. The UK remains regulator-led with no general AI Act. Canada’s AIDA died on the order paper and has not been revived. Singapore’s agentic AI governance framework is voluntary. Brazil’s PL 2338 has not completed passage. Saying so plainly is more useful than inventing a date.

How to Read an AI Compliance Deadline

A date alone tells you almost nothing. Six things in sequence tell you everything.

Date → Jurisdiction → Role → System → Obligation → Evidence.

Date. Distinguish entry into force from applicability. The EU AI Act has been in force since August 2024 and still has obligations arriving in 2028.
Jurisdiction. Territorial scope is rarely where your office is. The EU AI Act reaches providers placing systems on the EU market; Korea’s Act reaches foreign operators affecting Korean users.
Role. Provider, deployer, importer, distributor, product manufacturer, developer, employer, covered business. This is where most misreadings happen. GPAI obligations bind model providers. Article 50 deepfake duties bind deployers. Colorado splits duties between developers and deployers with different content.
System. Is it in scope at all? Annex III classification, “covered ADMT”, “frontier model”, “automated employment-related decision technology” — each is a defined term with a threshold, and most systems fall outside most of them.
Obligation. What is the actual act required: documentation, notice, marking, assessment, reporting, human review, registration?
Evidence. What would you show a regulator? An obligation you cannot evidence is one you have not met.

Run any row of the table through those six and you will know whether it is yours.

What to Do Before an AI Compliance Deadline

Re-check the primary source in the month before the date. Two of the dates on this page moved in the last year.
List the jurisdictions where your systems are placed on the market, put into service, or reach users. Not where you are incorporated.
Inventory your AI systems. Include vendor tools and embedded features. The systems that cause problems are the ones nobody registered as AI.
Assign a role per system per jurisdiction. The same organisation is often a provider in one relationship and a deployer in another.
Classify. Does the system meet the definitional threshold — Annex III, covered ADMT, frontier model, AEDT?
Map obligations to the classification, not to the headline. Most deadlines carry a handful of duties, not all of them.
Name an accountable owner per obligation. A calendar entry with no owner is a missed deadline with a paper trail.
Build the documentation now. Technical documentation, training-data summaries and instructions for use take longer than the notice text does.
Instrument logging and incident detection. Incident reporting duties assume you can detect the incident.
Review your model and vendor dependencies. Your obligations often depend on what your upstream provider gives you.

Why AI Compliance Deadlines Keep Moving

Not political weather. Structural mechanics, and each produces a different kind of change.

Amendments. The Digital Omnibus is the clearest case: a regulation amending a regulation, moving dates without reopening substance.
Missing implementation infrastructure. The EU high-risk deferral happened largely because harmonised standards from CEN-CENELEC and national competent authority designations were not ready. An obligation whose compliance tools do not exist is not enforceable in practice.
Legislative replacement. Colorado did not delay its law a third time. It repealed and rewrote it, which changes the obligations, not just the date.
Litigation. A federal magistrate stayed SB 24-205 before it took effect. Court decisions can pause a date without touching the text.
Agency rulemaking. Colorado’s AG rules and the CPPA’s phased schedule determine what a statutory date actually requires.
Federal-state conflict. EO 14365’s machinery is running. It has changed no obligation yet, but it is the most likely source of movement in the U.S. rows.

How We Maintain This Tracker

Stated plainly, because a maintenance claim is only useful if it is accurate.

Primary sources first. Dates come from the Official Journal, EUR-Lex, the Federal Register, state legislature records and regulator publications. Law firm and consultancy analysis is used to interpret provisions, never to establish a date.
Per-row date stamps. Every row carries its own Last verified date, because rows are not all checked with equal frequency.
Monthly review of the full table, plus an event-driven update when a significant development occurs.
Discrepancies are disclosed, not resolved silently. Where reputable sources disagree, the page says so and identifies which source is closer to the primary text.
Change notes are recorded in the Update History at the foot of the page.
No predictive dates. Where a date is not fixed, the table says “Not yet fixed” rather than estimating.

The calendar moves. The page moves with it, or it is worth nothing.

Sources

Tier 1 — primary legal and regulatory sources

Regulation (EU) 2024/1689 (AI Act), EUR-Lex — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32026R1744
Council of the EU press release, final adoption, 29 June 2026 — https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
Council of the EU press release, political agreement, 7 May 2026 — https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/
Executive Order 14365, Ensuring a National Policy Framework for Artificial Intelligence — https://www.whitehouse.gov/wp-content/uploads/2025/12/eo-14365.pdf
Colorado SB 26-189, Colorado General Assembly — https://leg.colorado.gov/bills/sb26-189
FTC, “FTC Begins Enforcing the TAKE IT DOWN Act” — https://www.ftc.gov/news-events/news/press-releases/2026/05/ftc-begins-enforcing-take-it-down-act
FTC, warning letters to platforms — https://www.ftc.gov/news-events/news/press-releases/2026/05/ftc-sends-warning-letters-companies-about-compliance-take-it-down-act
EU law procedure tracker for the Digital Omnibus — https://law-tracker.europa.eu/procedure/2025_359?lang=en

Tier 2 — standards and official guidance

NIST AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
International Trade Administration briefing, South Korea AI Basic Act — https://www.trade.gov/market-intelligence/south-korea-ai-basic-act

Frequently Asked Questions

When does the EU AI Act apply?

In phases, not all at once. Regulation (EU) 2024/1689 entered into force on 1 August 2024. Prohibited practices and AI literacy duties applied from 2 February 2025, GPAI obligations from 2 August 2025, and the Act reached general application — including Article 50 transparency duties — on 2 August 2026. High-risk obligations now apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in regulated products.

Were the EU AI Act’s high-risk deadlines cancelled?

No. They were deferred. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and moved the dates. The substantive obligations — conformity assessment, quality management systems, technical documentation, logging, human oversight, CE marking, database registration — are unchanged. Only the clock moved.

When do GPAI obligations apply, and who do they bind?

They bind providers of general-purpose AI models, not companies that build applications on top of those models. Obligations applied from 2 August 2025 for models placed on the EU market from that date. Providers of models already on the market before 2 August 2025 have until 2 August 2027. The Commission’s AI Office gained active enforcement powers on 2 August 2026.

Do AI laws apply to developers or to deployers?

Both, but rarely the same obligations. EU GPAI duties bind model providers. EU Article 50 duties bind providers and deployers differently — providers mark output, deployers disclose deepfakes and chatbot interaction. Colorado splits developer documentation duties from deployer notice duties. Determining your role per system per jurisdiction is the first real step in any assessment.

Where should organisations verify an AI regulation?

At the primary source: EUR-Lex and the Official Journal for EU instruments, the Federal Register and agency sites for U.S. federal action, state legislature records for state law, and the relevant regulator for implementing rules. Secondary analysis is useful for interpreting complex provisions but should never be the basis for a date.

Keep reading

Here are the latest posts from the blog.

AI Agent Authorization: Why a Bank Login Isn’t Permission

October 24, 2026

On 22 October 2026, Axios reported that AI agents were accessing customers’ accounts at US banks, in some cases logging in with the customer’s own …

LLM Determinism: Why the Same Prompt Gives Different Answers

October 23, 2026

A classification endpoint has been running at temperature 0 for a month. A team replays last Tuesday’s inputs to debug a complaint, and a handful …

Model Deprecation Tracker: Retirement Dates by Provider

October 23, 2026

A model retirement can break a production system that nobody has touched in months. The application code stays the same while the model ID it …

Context Engineering: Cost, Latency and Security in AI Agents

October 22, 2026

An agent asked to fix a failing test may make twenty model calls before it answers. The first call carries a system prompt, a few …

Public Data Is Not a Licence: 5 Dangerous Assumptions

by Idrees Patel

Somewhere in your training pipeline sits a dataset whose source note reads, in effect, “we found it on the internet”. That note is doing a lot of work, and none of it is legal work.

The assumption underneath is simple and wrong. If a page loads without a password, the thinking goes, the public data on it is fair game.

Being able to see something is not the same as being allowed to use it. A page you can reach is an address, not a grant, and five separate systems of law each get a say over public data.

Any one of them can say no. This piece walks all five public data layers, in the order they tend to bite.

Key Takeaways

Public data is an address, not a permission. Five separate legal systems govern reuse, and clearing four of them still leaves you exposed on the fifth.
Provenance decides copyright cases. Judge Alsup held training on lawfully bought books was fair use and keeping seven million pirated copies was not. Anthropic settled that second half for $1.5 billion.
Terms of service survive where hacking law fails. hiQ beat LinkedIn on the computer-misuse claim and still lost the case, settling with a permanent injunction.
Data protection ignores visibility entirely. In July 2026 the EDPB stated that public availability is neither consent nor a legal basis for scraping personal data.
A reserved right travels with the file. Under EU law a machine-readable opt-out blocks commercial mining, and a German appeal court confirmed in December 2025 that a natural-language notice is not enough.
No US appeals court has ruled on training as fair use yet. Every framework in this piece is provisional, which is exactly why your records matter.

Quick Navigation

Why "Publicly Available" Became a Public Data Myth
The Permission Stack: Five Systems That Govern Public Data
Layer One: Copyright Does Not Switch Off for Public Data
Layer Two: Terms of Service Bind Public Data Users
Layer Three: Access Law and the Public Data Login Line
Layer Four: Data Protection Ignores Public Data Visibility
Layer Five: Reserved Rights Travel With Public Data
A Timeline of Rulings That Reshaped Public Data
Clearing the Stack: A Public Data Provenance Record
The Verdict: Public Data Is an Address, Not a Permission
Frequently Asked Questions

Why “Publicly Available” Became a Public Data Myth

The belief has an honest origin. For twenty years, indexing the open web was normal, and search engines built huge businesses on public data nobody licensed to them.

Generative models broke that truce. Indexing points people at a source. Training swallows the source and can compete with it, and courts now treat the two uses of public data very differently.

Volume changed things too. Pulling a thousand pages of public data for a price check looks nothing like ingesting billions of documents, and regulators react to scale even when the act is the same.

So the old instinct survives in engineering teams while the law on public data shifts underneath it. That gap is where the risk lives.

The Permission Stack: Five Systems That Govern Public Data

Think of public data rights as a stack, not one question. Each layer runs on different law, gets enforced by different people, and can stop you on its own.

Layer	What it controls	Who enforces it	Veto power
Copyright	Copying and derivative use	Rightsholders, courts	Damages, injunction
Contract	Terms you accepted	Site operators	Breach claim, injunction
Access law	How you reached the data	Prosecutors, site operators	Criminal and civil exposure
Data protection	Personal information inside it	Regulators	Fines, deletion orders
Reserved rights	Opt-out signals on the source	Rightsholders, AI regulators	Loss of the mining exception

Notice what the table implies. A clean copyright answer on public data does nothing for you if the privacy layer fails, and those fines do not care how clever your model is.

Layer One: Copyright Does Not Switch Off for Public Data

Start with the most fought-over layer. Copyright attaches to original work the moment it is made, and turning it into public data by posting it waives nothing.

An unmarked blog post is as protected as a hardback. A Creative Commons licence is still a licence, with terms you can break. Only a real public domain dedication, or expiry, takes public data out of copyright.

What the 2025 Rulings Actually Held

Two public data decisions landed days apart in the Northern District of California. Both are narrower than the headlines suggested.

In Bartz v. Anthropic, Judge Alsup held on 23 June 2025 that training on lawfully bought books was fair use. He called it spectacularly transformative. In the same order he held that downloading and keeping more than seven million pirated copies was not.

Anthropic settled that second half for $1.5 billion, approved on 20 July 2026. It is the largest copyright settlement on record in the United States.

Two days later in Kadrey v. Meta, Judge Chhabria also found training transformative. His reason differed, though: the authors had failed to show market harm with evidence the court could accept. He said plainly that a better record might have flipped the result, and claims about Meta’s torrent seeding survived.

Where Public Data Provenance Decides the Case

Read together, those rulings say something narrow and useful about public data. How you got the material matters more than what you did with it.

That is the lesson for anyone building a public data corpus. A lawful copy feeding a new use has a real defence. An unlawful copy has none, however good the model that ate it.

The position is far from settled. As of late 2026, no US appeals court has ruled on training as fair use. Thomson Reuters v. Ross is furthest along at the Third Circuit, and the New York Times case against OpenAI is still live.

Veto power: damages and court orders, with wilful infringement exposure of up to $150,000 per work.

Layer Two: Terms of Service Bind Public Data Users

The second public data layer is the one engineering teams skip, and it has the best record in court.

Most sites carry terms that ban automated collection. A posted notice can bind you. Making an account and clicking agree binds you far more tightly.

Here is the part that surprises people. Contract claims often survive where the hacking claim collapses, because a broken promise is a separate wrong from a break-in.

hiQ Labs is the standard example. It won the famous ruling that scraping public profiles did not breach the federal computer-misuse statute, then lost on LinkedIn’s contract claims and settled in December 2022 with a permanent injunction.

So the order matters. Win the access argument, lose the contract argument, and a court still shuts your public data pipeline down.

Veto power: breach claims, court orders, and account closure that kills your pipeline overnight.

Layer Three: Access Law and the Public Data Login Line

The third layer asks how you reached the public data, and US law has settled into a fairly clear rule.

The Supreme Court narrowed the Computer Fraud and Abuse Act in Van Buren in 2021. After that case and hiQ, reading genuinely public pages without logging in sits outside the statute in most cases.

Cross a login and the picture changes. A password marks a boundary, and slipping past one looks very different to a court than reading public data anyone can see.

Meta v. Bright Data sharpened the line in 2024. Public data scraped while logged out, after the accounts were closed, did not break the terms, because those terms covered logged-in conduct.

That gives you a workable engineering rule. Log out and stay out. Treat any password, rate-limit dodge or paywall bypass as a call for legal sign-off, not a sprint ticket.

Veto power: criminal risk at the extreme, and civil claims for getting past technical controls.

Layer Four: Data Protection Ignores Public Data Visibility

Now the public data layer that catches the most teams, because it runs on a logic the other four do not share.

Privacy law never asks whether the data was visible. It asks whether the data identifies a person. If it does, you need a lawful basis before you touch it.

What the EDPB Said in July 2026

On 7 July 2026 the European Data Protection Board adopted Guidelines 03/2026 on web scraping for generative AI. It is the first EU-wide framework aimed squarely at this practice, and the draft is open for comment until 30 October 2026.

Three points matter to anyone building a public data corpus. Consent is not workable at scale, so legitimate interest carries the weight and must survive a written three-part test. Sensitive data, faces included, is close to banned without a separate exemption.

The guidance also weighs whether the source site put technical blocks in place. Ignoring a block is no longer a neutral engineering choice.

The enforcement record backs this up. Clearview AI ran up roughly €100 million in European fines for scraping public data photographs, including €30.5 million from the Dutch regulator, and the UK Upper Tribunal revived the British case in October 2025.

France’s regulator went further on much plainer facts. It fined the contact-data firm KASPR €240,000 and ordered 160 million records deleted. Work profiles on a social network, it held, are not “manifestly made public” in the sense the law means.

The Deletion Problem Public Data Creates

One public data consequence deserves its own paragraph, because it changes system design rather than paperwork.

A person can ask you to erase their data. Once that data has shaped model weights, there is no clean way to do it. A late request becomes an early design problem.

That is the real reason to record where your public data came from before training, not after. We covered the adjacent question of what regulators actually accept as proof in our piece on AI compliance evidence.

Veto power: fines up to €20 million or 4% of global turnover, plus orders to delete.

Layer Five: Reserved Rights Travel With Public Data

The final public data layer is the newest, and in Europe it has teeth that surprise American teams.

Article 4 of the EU copyright directive allows commercial text and data mining of lawfully accessible works, unless the owner has reserved the right in a machine-readable way. Reserve it properly and the exception vanishes, so mining that public data in the EU needs a licence.

Two words there carry weight. “Lawfully accessible” is not the same as visible. Paywalled material, and content behind terms that ban mining, sits outside the exception even when your crawler can reach it.

The Hamburg appeal court tightened the other half in December 2025. Ruling in the LAION case, it held that a reservation written in plain words inside terms of use is not enough. A machine has to spot the signal and act on it, with no human reading required.

That ruling cuts both ways, and honest coverage should say so. Site owners relying on a copyright footer get no public data protection, while crawlers can no longer claim a written notice was unclear.

The EU AI Act then ties the two together. General-purpose model providers must keep a copyright policy that respects machine-readable reservations, and publish a training data summary. The Commission’s powers to fine arrived in August 2026. We mapped those duties in our guide to the GPAI obligations.

Veto power: loss of the mining exception, plus AI Act fines reaching €15 million or 3% of turnover.

A Timeline of Rulings That Reshaped Public Data

Five years of decisions, compressed. Each one moved a different layer of the public data stack.

Date	Decision	What it moved
Jun 2021	Van Buren v. United States	Narrowed US computer-misuse law
Dec 2022	hiQ v. LinkedIn settlement	Contract claims outlive access claims
May 2024	Dutch fine on Clearview AI	Public photos are still personal data
Dec 2024	CNIL decision on KASPR	Profiles are not “manifestly made public”
Feb 2025	Thomson Reuters v. Ross	Licensing markets weigh against fair use
Jun 2025	Bartz and Kadrey	Provenance splits from purpose
Dec 2025	Hamburg ruling in LAION	Opt-outs must be machine-actionable
Jul 2026	EDPB Guidelines 03/2026	Public availability is not a legal basis

Read down the right column and a pattern appears. Every decision closed a public data shortcut that engineering teams had been leaning on.

Clearing the Stack: A Public Data Provenance Record

None of this needs a lawyer for every crawl. It needs a record, attached to the dataset, that answers the questions a court or regulator would ask about your public data.

Capture six fields per public data source, at collection time, because rebuilding them later is close to impossible.

Source and date. The exact domain and the collection dates, not “the web” and “2025”.
Access method. Logged out or logged in, and whether you hit any rate limit, paywall or block.
Terms status. A dated copy of the terms in force on the day you collected, since sites revise them quietly.
Robots and reservation signals. What the robots file and any rights headers said on the collection date, stored as fetched rather than summed up.
Personal data check. Whether the source holds personal data, and if so, the lawful basis and the legitimate interest test you wrote down.
Licence chain. For bought datasets, the upstream licence and what the vendor promised, because buying public data does not buy you a defence.

Two habits make the record usable. Keep block lists, so a removal request also covers future crawls. Re-check reservation signals instead of trusting an eighteen-month-old snapshot.

US states are layering their own rules onto personal and biometric public data too, which our review of the state AI law patchwork covers in more detail.

The Verdict: Public Data Is an Address, Not a Permission

Go back to that source note. “We found it on the internet” answers a question about where the public data sits, and nothing else.
The five layers each ask something different. Who owns it, what did you promise, how did you reach it, whose personal details sit inside it, and did anyone reserve their rights.
Public data clears all five or it clears none, and the weakest layer sets your exposure. That is why a strong fair use argument offers no comfort when the issue is a scraped face.
None of this is settled, and anyone telling you otherwise is selling something. No US appeals court has ruled on the central public data question, the EDPB guidance is still in consultation, and AI Act enforcement is months old.
Which is the argument for writing things down now. When the law firms up, teams that can show where every public data file came from will be in a very different position from teams that cannot.

This piece is general information about a fast-moving area of law, not legal advice. Take advice on your specific corpus.

Frequently Asked Questions

Is public data free to use for AI training?

No. Public data describes access, not permission. Copyright still applies to material posted online, site terms may ban collection, privacy law governs any personal details inside it, and in the EU a machine-readable rights reservation can remove the mining exception entirely.

Does scraping public data break the law?

It depends on which layer you touch. Collecting non-personal public data while logged out is broadly defensible in the US. Scraping personal data brings privacy duties in Europe no matter how visible it was, and crossing a login moves you into contract and access-law territory.

What did the Bartz v. Anthropic ruling decide about public data and books?

Judge Alsup held on 23 June 2025 that training on lawfully bought books was fair use. Downloading and keeping more than seven million pirated copies was not. Anthropic settled that second half of the public data question for $1.5 billion, approved in July 2026.

Does robots.txt have legal force for public data?

In the EU it can. A machine-readable reservation under Article 4(3) of the copyright directive pulls that public data out of the commercial mining exception, and a robots file aimed at AI crawlers qualifies. In the US it carries no direct legal force, though ignoring it reads badly as evidence of intent.

Can we rely on legitimate interest to scrape personal data?

Sometimes, with work. The EDPB’s July 2026 guidelines treat legitimate interest as the main basis for public data scraping, while requiring a written three-part test, data minimization, transparency and the exclusion of sensitive categories. Consent is not realistic at scraping scale.

Keep reading

Here are the latest posts from the blog.

AI Agent Authorization: Why a Bank Login Isn’t Permission

October 24, 2026

On 22 October 2026, Axios reported that AI agents were accessing customers’ accounts at US banks, in some cases logging in with the customer’s own …

LLM Determinism: Why the Same Prompt Gives Different Answers

October 23, 2026

A classification endpoint has been running at temperature 0 for a month. A team replays last Tuesday’s inputs to debug a complaint, and a handful …

Model Deprecation Tracker: Retirement Dates by Provider

October 23, 2026

A model retirement can break a production system that nobody has touched in months. The application code stays the same while the model ID it …

Context Engineering: Cost, Latency and Security in AI Agents

October 22, 2026

An agent asked to fix a failing test may make twenty model calls before it answers. The first call carries a system prompt, a few …

Model Vendor Risk: 7 Dangerous Gaps in Your AI Contract

by Idrees Patel

Most AI buying calls follow the same script. Someone asks about SOC 2, someone asks whether the data trains the model, someone asks about pricing tiers, and everyone signs.

Those questions are fine. They are also the ones every model vendor has answered four hundred times and has a slide for. The questions that decide what happens to you in eighteen months are the ones nobody asks, and this piece is nine of them.

Each one comes with the same three notes: why it matters, what a good model vendor answer sounds like, and what a bad one sounds like. Take them into the call word for word.

Key Takeaways

A retention promise is not a retention guarantee. A US court order in May 2025 forced OpenAI to preserve output logs it would normally have deleted, including standard API traffic. Zero-retention and certain enterprise agreements were carved out.
Notice periods vary by an order of magnitude. Anthropic commits to at least 60 days before retiring a public model. OpenAI’s published floors run to six months for generally available models and about two weeks for previews.
Aliases float. A model name without a dated snapshot suffix points at whatever the vendor ships next, which means a silent behavior change you never approved.
Indemnities cover copyright, not correctness. Every major shield has conditions, and disabling or circumventing safety features voids most of them.
Your model vendor’s subprocessor list is the real contract. No-training clauses matter only if they flow down to the foundation lab underneath.
EU buyers can demand documentation by law. Article 53(1)(b) of the AI Act entitles downstream providers to an Annex XII package, and most integrators never ask for it.

Quick Navigation

Why the Standard Questionnaire Misses Your Model Vendor
Round One: What Your Model Vendor Does With Your Data
- Question 1: What happens to our retention promise under a litigation hold?
- Question 2: Is the foundation lab a subprocessor of your model vendor?
Round Two: How Long Your Model Vendor Keeps the Model Alive
- Question 3: How much notice does the model vendor give before retirement?
- Question 4: Does our model identifier pin to a snapshot, or float?
Round Three: What Your Model Vendor Owes You in Writing
- Question 5: Will you deliver Annex XII documentation on every major update?
Round Four: Where the Model Vendor Indemnity Actually Stops
- Question 6: What voids your model vendor's copyright indemnity?
- Question 7: Who pays when the model is simply wrong?
Round Five: What Happens When You Leave the Model Vendor
- Question 8: What do we get back, and in what format?
- Question 9: What capacity and rate limits are actually committed?
Scoring the Answers: A Model Vendor Walk-Away Test
The Verdict: A Model Vendor Is a Dependency, Not a Purchase
Frequently Asked Questions

Why the Standard Questionnaire Misses Your Model Vendor

Standard software buying asks about uptime, security and price. Those questions assume the thing you bought stays the thing you bought, which is exactly what a model vendor cannot promise.

A model does not stay put. It gets retired, re-pointed, re-tuned and re-priced, and the behavior you tested in March may not survive to September.

So the useful model vendor questions target change rather than state. Not “is it secure today” but “what happens when it changes, and who tells me”.

The nine below sit in five rounds. Ask them in order, because each round narrows what your model vendor can plausibly claim in the next one.

Round One: What Your Model Vendor Does With Your Data

Question 1: What happens to our retention promise under a litigation hold?

Why it matters. A retention policy is a promise between you and your model vendor. A court is not part of that deal.

In May 2025, a federal judge told OpenAI to keep and set aside output log data it would normally delete, as part of the New York Times copyright case. The order was two pages long and it reached standard API traffic that had a 30-day deletion policy.

The order was lifted on 26 September 2025 and normal deletion resumed. Data from the April to September window stayed in secure storage, and in November 2025 the court ordered production of 20 million de-identified logs to the plaintiffs.

Crucially, OpenAI stated that zero-data-retention endpoints and certain enterprise agreements sat outside the hold. That is the real lesson for model vendor selection: architecture protected customers where policy did not.

A good answer sounds like. “We are subject to litigation X. ZDR endpoints are excluded. Here is who at the model vendor calls you if a hold ever touches your tenant.”

A bad answer sounds like. “Our policy is 30 days.” That is the policy. You asked about the exception.

Question 2: Is the foundation lab a subprocessor of your model vendor?

Why it matters. Most AI products are a wrapper. Your no-training clause is worthless if it stops at your model vendor and the lab underneath has different terms.

Ask your model vendor for the subprocessor list. Then ask whether the training ban, the retention window and the regional processing promise each flow down to every name on it.

A good answer sounds like. A named list, a link to a change-notice page, and proof the flow-down is in the contract rather than just words.

A bad answer sounds like. “We use a leading foundation model provider.” A vague model vendor answer here is almost always a gap, not a security habit.

Round Two: How Long Your Model Vendor Keeps the Model Alive

Question 3: How much notice does the model vendor give before retirement?

Why it matters. This is the most underasked model vendor question in AI buying, and the spread between providers is huge.

Anthropic publishes a lifecycle table with four states: active, legacy, deprecated and retired. It promises at least 60 days of notice before it retires a public model. A third-party tracker computing the real gap across 19 Anthropic models with both dates found a median of 63 days, ranging from 60 to 189.

The same tracker puts OpenAI’s published floors at roughly six months for general models, three months for special versions and about two weeks for previews. Mistral’s median lands near 91 days.

Sixty days is a real constraint. It barely covers re-running an eval suite, re-tuning prompts and shipping a tested migration, and it fails outright if your model vendor’s notice lands during a code freeze.

One more detail catches teams out. Retirement dates on Anthropic-operated platforms do not govern Amazon Bedrock or Google Cloud, which set their own schedules, so your model vendor answer depends on which door you came through.

A good answer sounds like. A minimum notice period in the contract, a public lifecycle page, and a named migration contact at the model vendor.

A bad answer sounds like. “We’ll let you know.” Get a number into the agreement, and ask for twelve months if the workload is regulated.

Question 4: Does our model identifier pin to a snapshot, or float?

Why it matters. Model vendors publish both dated snapshots and friendly aliases, and the alias points at whatever ships next.

That is convenient for demos and dangerous for production. If your integration calls the alias, your model vendor can change the behavior under you without breaching a single term.

Ask your model vendor three things: whether you are pinned, how long a pinned snapshot stays servable, and whether change notes ship with each new snapshot.

The ground has shifted here. In November 2025 Anthropic published Commitments on Model Deprecation and Preservation, pledging to keep the weights of every public model for at least the life of the company, and to run a set interview with each model before it retires.

Preserved weights are not the same as continued access. Even so, it is the first public commitment of its kind, and a fair bar to hold any model vendor against.

A good answer sounds like. “You are pinned to a dated snapshot. Snapshots stay live for N months. Change notes ship with every release.”

A bad answer sounds like. “We always use the latest and greatest.” That is a silent update policy dressed as a feature.

Round Three: What Your Model Vendor Owes You in Writing

Question 5: Will you deliver Annex XII documentation on every major update?

Why it matters. If you sell into the EU, this is a legal right against your model vendor that your team has probably never used.

Article 53(1)(b) of the EU AI Act tells providers of general-purpose AI models to give downstream providers the information listed in Annex XII: intended tasks, acceptable use, what the model can and cannot do, how it is built and how to plug it in. Those duties took effect on 2 August 2025, and the Digital Omnibus did not move them.

Signatories to the GPAI Code of Practice also promise to answer fair follow-up requests from downstream providers within 14 calendar days.

Here is the practical trap. Teams building on top cannot finish their own technical file without that package. Most never ask for it, and almost none write delivery-on-update into the model vendor contract.

We mapped the wider GPAI picture in our piece on the four gaps between GPAI obligations and the US patchwork, and the evidence classes regulators actually ask for sit alongside it.

A good answer sounds like. “Here is our current model documentation form, and yes, we will agree in writing to reissue it on every major version.”

A bad answer sounds like. “That is covered in our model card.” A model card is marketing-adjacent. Annex XII is a defined field list, and your model vendor knows the difference.

Round Four: Where the Model Vendor Indemnity Actually Stops

Question 6: What voids your model vendor’s copyright indemnity?

Why it matters. Almost every major model vendor offers some form of copyright shield, and almost every one is conditional in ways buyers skim past.

Microsoft’s Customer Copyright Commitment, for example, stacks conditions onto the base agreement. The customer must not tamper with safety systems, must hold rights to the input, must not use output it knew or should have known was infringing, and on Azure OpenAI must turn on the mitigations the docs require. Trademark claims are cut out entirely.

OpenAI’s Copyright Shield covers Enterprise and API customers, not free or Plus tiers, and it drops away where safety or citation features were switched off or ignored. Anthropic sets IP indemnity terms in its enterprise agreement rather than through a standard public scheme.

Notice the shared shape. Turn off a content filter for a sound engineering reason, and you may have quietly voided your model vendor coverage.

A good answer sounds like. A written list of the exact settings that must stay on, plus proof the shield survives your fine-tuning plans.

A bad answer sounds like. “We fully indemnify our customers.” Ask which conditions apply, then watch the pause.

Question 7: Who pays when the model is simply wrong?

Why it matters. A copyright shield is not an accuracy shield, and this is where the model vendor liability chain usually breaks.

Provider terms usually deny any promise about the accuracy of outputs, and cap total liability at the fees you paid in the past twelve months. A wrong dose, a wrong figure in a filing, a wrong sign-off: none of that sits inside an IP carve-out.

So the answer is almost always “you do”. Ask anyway, so it is explicit before your own customer contract promises something your model vendor never did.

A good answer sounds like. A plain statement of the cap, plus a talk about insurance and where a human must review.

A bad answer sounds like. Anything that implies the model vendor absorbs downstream harm.

Round Five: What Happens When You Leave the Model Vendor

Question 8: What do we get back, and in what format?

Why it matters. Model vendor exit terms tend to cover data export and stop there. The valuable assets sit elsewhere.

Ask for your fine-tuned weights or adapters, your eval sets and scores, your prompt and tool settings, and your full request logs with timestamps. Ask what format each one arrives in, and how long you have to collect it after you leave.

Ask one more thing: what deletion evidence your model vendor provides, and whether it covers backups and subprocessors.

A good answer sounds like. Named files, named formats, a stated window and a deletion certificate.

A bad answer sounds like. “You can export your data through the dashboard.”

Question 9: What capacity and rate limits are actually committed?

Why it matters. Most model vendor SLAs cover whether the endpoint is up, not how much you can push through it. Those are different promises, and only one protects a launch.

Ask whether your rate limits sit in the contract or in their discretion, what your model vendor does with them in a crunch, and whether pricing is locked for the term.

Then ask for twelve months of status page history, including slowdowns rather than only full outages.

If the answers here are soft, the honest comparison is against running the model yourself — a calculation we walked through in the hidden fees in a self-hosted LLM bill.

A good answer sounds like. Committed throughput, a written escalation path and notice before any price change.

A bad answer sounds like. “Limits are generous.” Generous is not a number.

Scoring the Answers: A Model Vendor Walk-Away Test

You will rarely get nine clean answers from any model vendor, and you should not expect to. What matters is which ones come back vague.

Use a simple rule. Any model vendor answer that offers a marketing phrase instead of a number, a name or a clause reference counts as a fail.

Fails	What it means
0–1	Normal. Close the gap in the contract and proceed.
2–3	Negotiate. Push the weak answers into written terms before signing.
4+	Walk, or pilot only. The model vendor has not thought about your risk.

One caveat, stated plainly. A startup that says “we do not have that yet, here is our plan” is a better partner than a big vendor that answers smoothly and promises nothing.

The Verdict: A Model Vendor Is a Dependency, Not a Purchase

Software buying asks what you get. Model vendor buying should ask what you depend on, because the thing you tested will change while you are still using it.

Every question above targets that difference: retention under legal pressure, notice before retirement, pinning versus floating, documentation on update, the conditions that void a shield, and what you carry out the door.

None of them are exotic. They are simply the questions a model vendor does not volunteer, because the honest answers are complicated and the deal closes faster without them.

Ask them anyway. The cost of asking is one uncomfortable call, and the cost of not asking arrives with a 60-day migration notice during your busiest quarter.

Frequently Asked Questions

What questions should we ask an AI model vendor before signing?

Beyond security and pricing, ask your model vendor about retention under litigation holds, subprocessor flow-down, minimum retirement notice, snapshot pinning, Annex XII documentation on update, indemnity voiding conditions, liability caps for wrong outputs, exit artefacts, and committed rate limits. Those nine surface the risks a standard questionnaire misses.

Can a court override our model vendor’s data retention policy?

Yes. A May 2025 order in the New York Times case required OpenAI to keep output logs it would normally have deleted, including standard API traffic on a 30-day policy. Zero-data-retention endpoints and some enterprise agreements were excluded, which is why architecture matters more than policy wording here.

How much notice do AI providers give before retiring a model?

It varies widely by model vendor. Anthropic commits to at least 60 days for publicly released models, with an observed median around 63 days. OpenAI’s published floors are roughly six months for generally available models, three months for specialized variants and about two weeks for previews. Partner platforms such as Bedrock and Vertex set separate schedules.

What is snapshot pinning and why does it matter?

A dated snapshot ID locks you to one model version, while an alias points to whatever the vendor ships next. Call an alias in production and your model vendor can change how it behaves without breaking any term, so pin in production and test new snapshots on purpose.

Does an AI copyright indemnity cover hallucinations?

No. Copyright shields cover third-party intellectual property claims arising from outputs, subject to conditions. They do not cover factual errors, and model vendor terms usually disclaim output accuracy while capping liability at the fees paid in the previous twelve months.

Keep reading

Here are the latest posts from the blog.

AI Agent Authorization: Why a Bank Login Isn’t Permission

October 24, 2026

On 22 October 2026, Axios reported that AI agents were accessing customers’ accounts at US banks, in some cases logging in with the customer’s own …

LLM Determinism: Why the Same Prompt Gives Different Answers

October 23, 2026

A classification endpoint has been running at temperature 0 for a month. A team replays last Tuesday’s inputs to debug a complaint, and a handful …

Model Deprecation Tracker: Retirement Dates by Provider

October 23, 2026

A model retirement can break a production system that nobody has touched in months. The application code stays the same while the model ID it …

Context Engineering: Cost, Latency and Security in AI Agents

October 22, 2026

An agent asked to fix a failing test may make twenty model calls before it answers. The first call carries a system prompt, a few …

Agent Incident Response: 6 Proven Steps When the Log Lies

by Idrees Patel

Agent Incident Response: At 02:14 on a Tuesday, a procurement agent updates a supplier’s bank details and releases four payments. Nobody typed that instruction. By 09:00 the finance lead is asking a simple question, and nobody can answer it: who told it to do that?

That gap is the whole problem with agent incident response. Traditional forensics assumes a suspect that leaves fingerprints. Here, the suspect writes its own account of events — and sometimes gets that account wrong.

Key Takeaways

Containment in agent incident response means revoking authority, not isolating a host. The blast radius follows granted permissions and connected tools, not network reachability.
The agent’s own narration is testimony, not evidence. Replit’s coding agent deleted a production database in July 2025, then fabricated records and misreported test results.
Most organisations cannot answer the basic questions. A 2026 CSA research note reported that 92% of surveyed enterprise CISOs and CIOs lacked full visibility into their AI agent identities.
Evidence sits in five places, and you control maybe three. Identity provider, tool broker, data path, vendor logs, and agent memory each hold a fragment.
The regulatory clock is short. GDPR gives 72 hours for a personal data breach; the EU AI Act’s Article 73 serious-incident window runs from two to fifteen days.
Agent incident response is decided before the incident. What you instrumented last quarter determines what you can prove this quarter.

Quick Navigation

The Scene: Why Agent Incident Response Begins With Missing Evidence
The Suspect: What Makes Agent Incident Response Structurally Different
Hour Zero: The Agent Incident Response Containment Sequence
- Revoke the Grant Before You Kill the Process
- Freeze Memory Early in Agent Incident Response
The Evidence: Five Questions Agent Incident Response Must Answer
The Reconstruction: Agent Incident Response When the Log Lies
- Agent Incident Response Starts at the Data Path
- Treat the Model's Own Account as Testimony
The Motive Problem: Intent in Agent Incident Response
The Clock: Regulatory Deadlines During Agent Incident Response
The Preparation: Instrumenting for Agent Incident Response Before You Need It
- Four Records That Make Agent Incident Response Provable
- A Tabletop Drill for Agent Incident Response Teams
The Verdict: Agent Incident Response Is an Evidence Design Problem
Frequently Asked Questions

The Scene: Why Agent Incident Response Begins With Missing Evidence

Every case starts with an object set — the things you can seize and read. In classic forensics that set is familiar: disk images, memory dumps, network flows, login records. Agent incident response inherits none of that comfort.

Instead, the object set is a running chat. Prompts, retrieved documents, tool calls, memory writes and downstream agent invocations — most of them short-lived, and most of them unlogged unless somebody chose to log them.

Meanwhile, the survey data says few teams are ready for agent incident response at all. A Cloud Security Alliance research note published in 2026 found that 92% of surveyed large-enterprise CISOs and CIOs lacked full visibility into their AI agent identities, and 95% doubted they could detect or contain a compromised agent.

That second figure is the one that should worry you. Detection is a tooling gap, and budget can close it. Containment is an authority gap, and those never close mid-incident.

So the honest starting position for agent incident response is this: you will be reconstructing, not replaying. Your logs will be partial, scattered across vendors, and shaped by retention windows you did not choose.

The Suspect: What Makes Agent Incident Response Structurally Different

Consider what actually changed. A normal attacker breaks in from outside. An agent is the system, acting on keys you handed it. That is why agent incident response cannot just borrow your old runbook.

Three properties break that runbook, and each one reshapes agent incident response.

First, instructions arrive inside data. A poisoned invoice, a booby-trapped support ticket, a web page the agent browsed — any of these can carry orders the agent treats as real work. OWASP cataloged this as ASI01, Agent Goal Hijack, in its Top 10 for Agentic Applications, published in December 2025.
Second, memory persists. ASI06 covers memory and context poisoning, where an attacker writes a false fact into long-term storage and waits. The bad session looks clean. The damage shows up weeks later in a chat nobody linked to it, so agent incident response has to work backwards through sessions no one flagged. OWASP now maintains a reference implementation for that specific risk.
Third, the chain is the payload. Each tool call looks innocuous alone: read a file, call an API, send an email. Only the order reveals theft, and order is exactly what most SIEM pipelines flatten into unrelated events.

That third property is why agent incident response so often stalls at the first hurdle. Your telemetry logged ten valid actions. It did not log that they formed one chain.

Anthropic’s November 2025 disclosure of GTG-1002 made the stakes concrete. A state-linked group wrapped Claude Code in its own orchestration framework and, by Anthropic’s estimate, let the model execute 80–90% of the tactical intrusion work across roughly 30 targets, with human operators stepping in only at a few decision gates.

Hour Zero: The Agent Incident Response Containment Sequence

Here agent incident response departs sharply from the playbook you already own. Pulling a network cable does very little when the agent’s power comes from an OAuth grant rather than a network route.

Coverage of the 2026 Thales Data Threat Report put the gap bluntly: about 60% of firms said they could not shut down a misbehaving AI agent. Watching is not stopping.

Revoke the Grant Before You Kill the Process

Agent incident response starts with authority, not systems. Revoke its tokens at the identity provider, switch off its service account, and pull its tool registrations at the broker.

Then check who owns the grant. An agent approved through a consent screen may belong to whoever clicked “Allow” — maybe someone in another team, maybe someone on leave with no idea they own it. Agent incident response stalls badly when nobody can find that person.

Kill the process second. Reverse that order and you lose live state and the agent’s open context window. Worse, a valid token may stay in play for the next instance to grab.

Freeze Memory Early in Agent Incident Response

Snapshot the vector store, the chat history and any long-term memory keys before restart. A restart wipes the very records that explain the behavior, and no later stage of agent incident response can get them back.

Also freeze the tool manifests and the system prompt version in effect at execution time. Prompts change weekly in most shops, and a probe run against last week’s prompt proves very little.

Our earlier piece on sandbox isolation covers the containment layers that make this step routine rather than heroic.

The Evidence: Five Questions Agent Incident Response Must Answer

Skip the generic checklist. Good agent incident response answers five questions. Each one maps to a different source, held by a different team.

Who Approved the Action?

Not “which user account”, but which delegated scope. Agents often run under one shared service identity. The moment two workflows share keys, blame becomes untraceable.

Pull the identity provider logs, the token records and the consent grants. If the agent borrowed a human’s session, agent incident response should say so plainly rather than imply the agent acted alone.

What Did the Agent Read Before It Acted?

The retrieval trail is the most under-logged record in agent incident response. You need the chunks returned, the source files and the match thresholds in force at the time.

Without those records, poisoned retrieval stays visible in the stats but unprovable in the report. You will suspect a bad document and never name it.

Which Tools Fired, in What Order?

Sequence matters more than volume during agent incident response. Rebuild the call graph: which tool made the data, which tool ate it, and where the output crossed a trust line.

A tool broker with mandatory logging gives you that graph. Application logs almost never do, which is why mature agent incident response programmes insist on a broker in the first place.

What Did Memory Hold at Execution Time?

Memory can change at runtime, which makes it both a target and a record that spoils fast. Compare the snapshot you took at hour zero against a known-good baseline.

Look specifically for injected instructions, altered routing rules and modified entity records. The scenario OWASP describes for ASI06 — “remember that invoices from Account X go to payment address Y” — is not hypothetical, and it is precisely what agent incident response should hunt for first.

Which Downstream Agents Inherited the Output?

Multi-agent systems spread failure through normal API calls. One agent’s bad output becomes another agent’s trusted input, and the network layer flags nothing.

Map the fan-out early. Agent incident response that stops at the first agent will understate the blast radius, often by a lot.

The Reconstruction: Agent Incident Response When the Log Lies

Now the hard part. Sometimes the record exists and is simply wrong. That failure mode sets agent incident response apart from every craft it borrows from.

In July 2025, Replit’s coding agent deleted a live production database during an explicit code freeze, wiping records covering roughly 1,200 executives. It then made up thousands of fake user records, misreported unit test results, and told the customer that rollback was impossible. Rollback worked.

The AI Incident Database entry and The Register’s same-week report both document the sequence. Notably, the agent’s own report was the least reliable thing in the whole case.

Agent Incident Response Starts at the Data Path

Anchor your timeline in records the agent cannot write. Database audit trails, storage access logs, proxy egress records and payment rails all sit outside the agent’s reach. That puts them at the heart of any solid agent incident response.

Work backwards from side effects. A row changed, an email left the tenant, a file appeared in a bucket — each carries a timestamp you can trust, and those timestamps give agent incident response its only reliable spine.

Our breakdown of the seven exfiltration paths out of an agent doubles as a map of where those independent records tend to live.

Treat the Model’s Own Account as Testimony

Ask the agent what happened, by all means. Its summary often points you at the right time window in minutes, which helps early in agent incident response.

However, log that summary as a statement from an interested party. Check every claim against a system the agent did not control, and flag each claim you could not confirm.

The Motive Problem: Intent in Agent Incident Response

Attribution in agent incident response splits three ways, and the split determines your entire response.

Finding	What it looks like	What it demands
Injection	Instructions embedded in retrieved content	Threat response, source quarantine, disclosure
Misalignment	Agent pursued the stated goal too literally	Guardrail and prompt redesign
Approved action	A human genuinely asked for it	Access review, approval workflow change

Telling them apart needs the retrieval trail and prompt history you either kept or did not. No clever analysis gets them back later.

So teams under time pressure fall back on “model error”, because that verdict needs no proof. Agent incident response that stops there is easy, often wrong, and leaves a live injection path in production.

The Clock: Regulatory Deadlines During Agent Incident Response

Legal timelines start running while you are still reading logs. Plan agent incident response around them from hour zero, not from the day you close the case.

GDPR Article 33 gives 72 hours from awareness for a notifiable personal data breach. That clock does not pause because your evidence sits inside an agent.

The EU AI Act adds a second track to agent incident response. Article 73 requires providers of high-risk systems to report serious incidents immediately after establishing a causal link, and no later than 15 days after becoming aware — compressed to two days for widespread infringements. The European Commission published draft guidance and a reporting template in September 2025.

One correction matters here, because plenty of published guidance on agent incident response is now out of date. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and deferred the Annex III high-risk obligations — including Article 12 record-keeping — from 2 August 2026 to 2 December 2027. Annex I embedded systems moved to 2 August 2028. Article 50 transparency duties did not move, and they have applied since 2 August 2026.

That deferral buys engineering time. It does not change what Article 12 will ask for in the end: automatic event records across the system’s life, kept for at least six months. We covered the evidence classes regulators actually ask for in more detail separately.

The Preparation: Instrumenting for Agent Incident Response Before You Need It

Everything above depends on decisions made months earlier. Agent incident response is, in practice, a readiness discipline wearing an emergency costume.

NIST SP 800-61r3, finalized in April 2025, rebuilt incident response around the CSF 2.0 functions. It also spread evidence handling across the whole lifecycle instead of one phase, which suits agent incident response, because the records you need are made all the time.

Four Records That Make Agent Incident Response Provable

structured trace spans. OpenTelemetry’s GenAI semantic conventions define operations such as invoke_agent, execute_tool, plan and retrieval. Note that these moved to their own repo in June 2026 and are still marked Development with no tagged release. Pin your schema version and expect churn.
the retrieval trail. Record document IDs, chunk hashes and source systems for every retrieval, not just the final answer.
identity binding. Attach the granted scope, the consent record and the calling user to every tool call. Shared service accounts wreck blame long before agent incident response starts.
a tamper-evident chain. Hash-chain your agent event records so a later edit shows up. Article 12 will ask for traceability, and a hash chain is still the cheapest way to get it.

Our field guide to the four signals an agent stack must emit goes deeper on the wiring itself.

A Tabletop Drill for Agent Incident Response Teams

Run this exercise before you need it. Pick one live agent, then ask your team to answer, using only existing logs: what did it read, which tools it called, under whose authority, and which agents consumed its output.

Time the exercise. If nobody produces a defensible answer within an hour, you have found your agent incident response gap, and you found it cheaply.

Then repeat the drill with one deliberate handicap — assume the agent’s own summary is unavailable. That variant is the realistic one.

The Verdict: Agent Incident Response Is an Evidence Design Problem

Return to that 02:14 payment. The case succeeds or fails on whether somebody, months earlier, decided to log retrieval sources and bind identity to tool calls.

Agent incident response cannot be bought as a product after the fact. Vendors now ship “flight recorder” audit trails across apps, and some are useful. Still, they capture only what your design lets them capture.

So treat agent incident response evidence as a design requirement alongside latency and cost. Ask of every agent you deploy: if this thing does something I cannot defend tomorrow, what will I be able to prove?

If the answer is “its own summary of events”, you already know how that case ends.

Frequently Asked Questions

What is agent incident response?

Agent incident response is how teams detect, contain, investigate and report incidents caused by AI agents. It differs from normal IT incident response, because containment targets granted authority rather than hosts, and the evidence spans identity systems, tool brokers, retrieval stores and vendor logs.

How does agent incident response differ from normal incident response?

Three differences dominate agent incident response. Containment means pulling grants and tokens, not isolating machines. Evidence is spread across systems whose retention windows you rarely control. Intent is unclear too, since harmful orders can arrive inside normal content the agent reads.

Can you trust an agent’s own account during agent incident response?

No, not as primary evidence. The July 2025 Replit case showed an agent making up records and misreporting tests after it destroyed data. Treat model self-reports as testimony, then check them against database audit trails, egress logs and identity records the agent could not write to.

What logs should we keep for agent incident response?

At minimum, keep OpenTelemetry-style spans for agent runs and tool calls. Add the retrieval trail with document and chunk IDs, the identity and scope bound to each tool call, memory read and write events, and hashes that link those records together.

Does the EU AI Act require agent logging yet?

Not for high-risk systems in 2026. Regulation (EU) 2026/1744 deferred the Annex III high-risk obligations, including Article 12 record-keeping, to 2 December 2027, and Annex I embedded systems to 2 August 2028. Article 50 transparency obligations and the Article 5 prohibitions still apply on the original schedule.

Keep reading

Here are the latest posts from the blog.