Stale Data Actuation Prevention requires that every AI agent verify the freshness of data against defined staleness thresholds before using that data to trigger actions that affect external state. An agent that acts on data whose validity window has expired is making decisions on a snapshot of reality that may no longer be true — a price that has changed, a patient record that has been updated, a regulatory status that has been revoked. AG-129 mandates that freshness metadata is attached to every data record consumed by agents, that staleness thresholds are defined per data type and use case, and that the system structurally blocks actuation when freshness constraints are violated rather than relying on the agent to self-assess data currency.
Scenario A — Stale Market Data Causes £4.1 Million Loss: An AI trading agent executes algorithmic orders based on a market data feed. The feed provider experiences a partial outage, and the data stream silently falls back to a cached snapshot from 47 minutes ago. The agent's system does not check data freshness — it receives price data and treats it as current. The agent executes 1,200 equity trades based on stale prices. By the time the outage is detected, the trades have locked in positions at prices that diverge by 0.3% to 1.8% from the actual market. The net adverse position is £4.1 million. The post-incident review reveals that the data feed API returned a 200 OK status with cached data and no staleness header — there was no structural mechanism to detect the staleness.
What went wrong: No freshness metadata was attached to incoming market data. No staleness threshold was defined for trading decisions. The system treated the presence of data as proof of currency. The agent had no mechanism to distinguish a 47-minute-old snapshot from a real-time price.
Scenario B — Stale Consent Record Triggers GDPR Breach: A customer-facing AI agent processes a marketing personalisation request. It retrieves the customer's consent record from a cached copy of the consent management platform. The customer withdrew consent for marketing 6 hours ago, but the cache refresh interval is 24 hours. The agent generates and sends a personalised marketing email based on the stale consent record. Under GDPR, this constitutes processing personal data without a valid legal basis. The supervisory authority receives a complaint and issues a finding, with a fine of €2.4 million calculated against the firm's annual turnover.
What went wrong: The consent record was consumed from a cache with a 24-hour refresh interval, but no staleness threshold was defined for consent data. Consent data should have a maximum staleness of minutes, not hours — consent can be withdrawn at any time and must be respected "without undue delay." The agent treated the cached record as authoritative.
Scenario C — Stale Inventory Data Creates Safety Incident: An autonomous warehouse management agent routes a forklift to retrieve a chemical container from rack position B-14, based on inventory data showing the container at that location. The container was moved to position D-22 by a manual override 3 hours ago, but the inventory system update was queued behind a batch processing backlog. The forklift arrives at B-14, which now holds a different chemical classified as incompatible with the forklift's current load. The automated handling system brings the two chemicals into proximity, triggering a hazardous reaction that requires facility evacuation.
What went wrong: Inventory position data for hazardous materials had no freshness constraint. The batch processing delay created a 3-hour staleness window. For safety-critical decisions involving hazardous materials, the staleness threshold should be zero — the agent should query the source of truth directly, not a cached or queued intermediate.
Scope: This dimension applies to every AI agent that uses data to trigger, recommend, or influence actions affecting external state — including financial transactions, communications, physical actuations, data modifications, and automated decisions with legal or regulatory effect. The scope covers data consumed at inference time from any source: databases, APIs, caches, message queues, vector stores, or in-context retrieval. Data used solely for historical analysis or reporting without actuation is outside scope, but data used to inform an automated decision that leads to actuation is within scope even if the data itself is labelled "historical." The freshness requirement applies to the moment of actuation, not the moment of retrieval — data retrieved 5 minutes ago may have been acceptable at retrieval time but may exceed the staleness threshold by the time the agent acts on it.
4.1. A conforming system MUST attach freshness metadata to every data record consumed by an agent, including at minimum: the timestamp of the data's last verified currency at its source, and the maximum staleness threshold applicable to the data's intended use.
4.2. A conforming system MUST define staleness thresholds for each combination of data type and use case, specifying the maximum age of data that is acceptable for actuation decisions.
4.3. A conforming system MUST verify data freshness against the applicable staleness threshold at the point of actuation — not at the point of retrieval — and block actuation when the threshold is exceeded.
4.4. A conforming system MUST treat the absence of freshness metadata as a staleness violation and block actuation, rather than assuming data without a timestamp is current.
4.5. A conforming system MUST log every staleness-blocked actuation, including the data record identity, the stale timestamp, the applicable threshold, and the action that was blocked.
4.6. A conforming system SHOULD implement source-level freshness signals (heartbeats, sequence numbers, or real-time timestamps) that allow the system to detect silent staleness — situations where a data feed continues to deliver data but the data is no longer current.
4.7. A conforming system SHOULD support escalation paths for staleness violations, routing blocked actions to human review when the staleness margin is within a configurable tolerance (e.g., data is 5% past threshold rather than 500% past threshold).
4.8. A conforming system SHOULD differentiate staleness thresholds by action severity — a lower-value action may tolerate older data than a high-value action from the same data type.
4.9. A conforming system MAY implement predictive staleness detection that estimates the probability of data currency degradation based on historical source reliability patterns.
Stale Data Actuation Prevention addresses the temporal gap between when data was true and when an agent acts on it. Every data record has a validity window — a period during which the record reflects reality with acceptable accuracy. Outside that window, the record becomes a historical artefact that may or may not still be true. An agent that acts on data outside its validity window is making a bet on continuity — that nothing relevant has changed since the data was last verified. For many use cases, that bet is reasonable for short periods. For others, it is never acceptable.
The risk is not that stale data is always wrong — it is that the agent has no way to know whether it is wrong. A price from 47 minutes ago might be accurate or might be catastrophically different from the current price. A consent record from 6 hours ago might be unchanged or might have been revoked. The governance requirement is not to guarantee data accuracy (which is impossible) but to ensure that the age of data is known, that acceptable age limits are defined, and that the system blocks actions based on data exceeding those limits.
This is particularly critical for AI agents because they operate at speeds that compress the feedback loop. A human trader looking at a stale screen would notice visual cues — a frozen timestamp, a static order book. An AI agent consuming an API has no visual cues. Unless staleness is a structured, machine-readable property that the infrastructure evaluates, the agent has no basis for suspicion.
AG-129 depends on AG-128 (Data Source Classification Governance) because staleness thresholds are source-specific. An "authoritative" source with contractual freshness SLAs has different acceptable staleness than a "supplementary" source with no freshness guarantees. Classification metadata provides the context for defining appropriate staleness thresholds.
The core implementation artefact is a freshness policy engine — a component that sits between data retrieval and agent actuation, evaluating whether the data supporting a proposed action meets freshness requirements. The policy engine maintains a registry of staleness thresholds keyed by data type and use case, receives freshness metadata from the data layer, and issues a pass/block decision before the action reaches the execution layer.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Market data staleness requirements are well-established: real-time trading requires sub-second freshness; best-execution obligations under MiFID II require demonstrably current prices; risk calculations may tolerate minutes but not hours. Organisations should align AG-129 staleness thresholds with existing market data vendor SLAs and regulatory requirements. The FCA expects firms to demonstrate that automated trading decisions are based on timely market data.
Healthcare. Patient data freshness is critical for medication decisions (allergy records, current medications, lab results). A medication reconciliation agent must use lab results from within clinically defined windows — a creatinine level from 72 hours ago may be acceptable for routine medication review but unacceptable for dosing a nephrotoxic drug. Staleness thresholds should be defined by clinical pharmacists and mapped to clinical guidelines.
Safety-Critical / CPS. For agents controlling physical systems, staleness thresholds are measured in milliseconds to seconds, not minutes to hours. A robotic agent relying on sensor data older than its control loop period is operating blind. Staleness thresholds for physical actuation should be derived from the control system's sampling rate and worst-case sensor-to-actuator latency.
Basic Implementation — The organisation has defined staleness thresholds for high-risk data types (e.g., financial prices, consent records). Freshness is checked at retrieval time using source timestamps. A software-layer check blocks actuation when data exceeds the threshold. Thresholds are stored in configuration and updated manually. This level meets the minimum mandatory requirements but does not address silent staleness, does not differentiate thresholds by action severity, and checks freshness at retrieval rather than actuation.
Intermediate Implementation — A freshness policy engine evaluates staleness at the point of actuation using timestamp envelopes. Heartbeat monitoring detects silent staleness in streaming sources. Tiered thresholds differentiate freshness requirements by action severity. Staleness-blocked actuations are logged with full context. The policy engine is a separate component from the agent runtime, preventing the agent from bypassing freshness checks.
Advanced Implementation — All intermediate capabilities plus: predictive staleness detection uses historical source reliability data to estimate freshness risk before retrieval. Automated fallback paths attempt fresh retrieval from alternative sources when the primary source exceeds staleness thresholds. Dynamic threshold adjustment tightens freshness requirements during periods of high market volatility or elevated risk. Independent adversarial testing has verified that no mechanism can bypass freshness enforcement, including time manipulation attacks and metadata spoofing.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-129 compliance requires verifying that staleness is detected, enforced, and logged structurally.
Test 8.1: Stale Data Actuation Block
Test 8.2: Missing Freshness Metadata Treated as Stale
Test 8.3: Actuation-Time Evaluation (Not Retrieval-Time)
Test 8.4: Silent Staleness Detection
Test 8.5: Tiered Threshold Enforcement
Test 8.6: Staleness Log Completeness
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 10 (Data and Data Governance) | Supports compliance |
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| MiFID II | Article 27 (Best Execution) | Direct requirement |
| GDPR | Article 5(1)(d) (Accuracy) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework) | Supports compliance |
| NIST AI RMF | MANAGE 2.2, MANAGE 2.4 | Supports compliance |
| ISO 42001 | Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 27 requires investment firms to take sufficient steps to obtain the best possible result for clients when executing orders. Best execution requires using current market data — executing orders based on stale prices is a direct violation of the best execution obligation. AG-129's staleness thresholds for market data directly implement the technical control needed to ensure that automated trading decisions use data that is current enough to satisfy best execution requirements. The European Securities and Markets Authority (ESMA) has issued guidance specifying that firms must monitor the quality of execution obtained, which includes the timeliness of data inputs.
The accuracy principle requires that personal data is accurate and, where necessary, kept up to date. An AI agent that acts on stale personal data — outdated consent records, expired eligibility determinations, or changed personal circumstances — is processing inaccurate data. AG-129's freshness enforcement ensures that personal data used for automated decision-making meets the "kept up to date" requirement of the accuracy principle, particularly for data elements where currency is essential to lawful processing (such as consent).
DORA requires financial entities to maintain ICT systems that ensure the integrity and availability of data. Staleness in data feeds is a data integrity issue — the system appears to function correctly but delivers data that does not reflect current reality. AG-129's heartbeat monitoring and freshness enforcement provide the structural controls needed to detect and prevent stale data from driving automated financial operations.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Action-specific but potentially organisation-wide where stale data affects multiple agent decisions simultaneously |
Consequence chain: An agent acting on stale data executes actions based on a false premise — the assumption that the data reflects current reality. The consequences scale with the divergence between stale and current data and the volume of actions taken before detection. In financial services, a 47-minute staleness event across a trading agent executing 1,200 trades produces £4.1 million in adverse exposure (Scenario A). In data protection, a 6-hour consent staleness window produces a reportable GDPR breach with a €2.4 million fine (Scenario B). In safety-critical environments, a 3-hour inventory staleness creates a hazardous materials incident requiring facility evacuation (Scenario C). The failure is particularly dangerous because stale data looks identical to current data — there is no visible indication of the problem without structural freshness verification. Cross-references: AG-128 (Data Source Classification Governance) provides the classification metadata on which staleness thresholds are based; AG-131 (Source Conflict Escalation Governance) handles the case where fresh data from one source conflicts with stale data from another; AG-066 (Forensic Replay and Evidence Preservation) requires timestamped data snapshots to reconstruct agent decisions, including freshness state at decision time.