Article 12 requires high-risk systems to automatically log production behaviour. Wild Edge is the edge-native telemetry SDK that captures these required inference logs on-device, without compromising data privacy or requiring cloud round-trips.
The Digital Omnibus on AI pushed the high-risk obligations to December 2027 and August 2028. Everything else below is already in force.
| Obligation | Applies from | Status |
|---|---|---|
| Prohibited practices, AI literacy | 2 Feb 2025 | In force |
| GPAI models, governance, penalties | 2 Aug 2025 | In force |
| Transparency duties (Art. 50) | 2 Aug 2026 | In force |
| Annex III standalone high-risk | 2 Dec 2027 | Deferred from 2 Aug 2026 |
| Annex I embedded high-risk | 2 Aug 2028 | Deferred from 2 Aug 2027 |
The same instrument narrowed the definition of "safety component" and largely excluded AI in Machinery Regulation products from high-risk classification. Medical devices, IVDs, and toys remain in scope.
On the day the obligations apply, your technical file must describe a post-market monitoring system that is already in place, and you must hold at least six months of logs. A purchase order on the deadline satisfies neither.
Art. 19 and 26(6) set a six-month minimum retention. To hold six months on 2 Dec 2027, the system is running by June 2027.
Notified body queues for regulated products currently run six to twelve months. That work starts before the logs are complete, not after.
Annex IV point 9 asks you to describe the monitoring system and its plan. You cannot describe what you have not run.
Realistic instrumentation date for a 2 Dec 2027 obligation is Q1 2027. That puts the decision roughly two quarters out.
Your date depends on how the system is classified. Work out yours in six questions.
Start a Proof of ConceptSix provisions concern what the system does once it is in use. These are the ones Wild Edge is built against.
| Provision | Requirement | What Wild Edge contributes |
|---|---|---|
| Art. 12 Record-keeping |
Automatic logging of events over the system lifetime, at a level of traceability appropriate to its purpose. | Per-inference records with timestamp, model version, device, accelerator, latency, and confidence, emitted by the SDK. |
| Art. 19 Provider retention |
Providers keep automatically generated logs for at least six months. | Configurable retention in an open table format, in storage you control. See the retention note below. |
| Art. 26(5), 26(6) Deployer duties |
Deployers monitor operation against the instructions for use, and retain logs under their control for six months. | Drift, latency, and error-rate monitoring per model and per device, with alerting when behaviour moves. |
| Art. 72 Post-market monitoring |
Providers actively collect and analyse performance data throughout the system's lifetime. | Continuous collection plus a query path over the full history in SQL or natural language. |
| Art. 14(4) Human oversight |
Overseers must monitor operation, stay alert to automation bias, and be able to disregard or override the output. | Accept, reject, undo, and edit events tied to the originating inference, with response latency and edit distance. Evidence that oversight happened, and a measurable automation-bias signal. |
| Annex IV, point 9 Technical documentation |
"A detailed description of the system in place to evaluate the AI system performance in the post-market phase in accordance with Article 72, including the post-market monitoring plan." | Wild Edge is that system. You still write the description and the plan; this is what they describe. |
The SDK instruments models where they run, including calls that never reach a server.
User actions stay linked to the inference, revealing whether operators reviewed, overrode, or reflexively accepted it.
Breaches of provider and deployer obligations sit in the Art. 99 middle tier: administrative fines up to €15 million or 3% of total worldwide annual turnover, whichever is higher. The headline 7% tier applies only to the prohibited practices in Art. 5.
Most of a technical file describes what a system is designed to do. One part records what it actually did, and it is the only part you cannot write after the fact.
Risk management system
Your QMS or GRC platform
Data and data governance
Your data and QA function
Technical documentation
Your regulatory affairs team
Production evidence and record-keeping
Wild Edge
Human oversight design
Product and system design
Wild Edge evidences 14(4)(a), (b), (d)
Quality management system
Your ISO 13485 or ISO 42001 QMS
Wild Edge evidences 17(1)(f), (h), (k)
Fundamental rights impact assessment
Legal or your DPO
Conformity assessment and declaration
Internal control, or a notified body
EU database registration
You, before placing on the market
If a vendor tells you a monitoring tool makes you compliant with the AI Act, read Annex IV.
Records are only useful if they are complete, attributable, and still there when someone asks.
Art. 19 and Art. 26(6) set a six-month floor. Enterprise supports custom retention windows that meet or exceed it, along with bring-your-own object storage so the records remain yours.
Records land as Apache Iceberg tables with immutable snapshots and point-in-time reads, so you can reconstruct what a given model version was doing on a given date. Stop using Wild Edge and the evidence is still there, still queryable.
VPC, on-premise, and air-gapped deployment. Ingestion, storage, and query traffic stay inside your perimeter, which is what makes the record-keeping obligation compatible with sovereignty and classification requirements.
The SDK emits structured telemetry by default. Raw inputs and outputs stay on the device unless you explicitly enable capture for a defined scope, so record-keeping does not become a new personal-data liability.
Overseers are required to stay alert to the tendency to over-rely on model output. That is usually asserted in a document and never checked. Wild Edge records what the human actually did with each inference: whether they accepted, rejected, edited, or reported it, how long they took, how much they changed, and whether they accepted and then reverted. A fleet accepting at a median of 180 milliseconds is not being overseen, and no document will tell you that.
Record-keeping obligations outlast procurement cycles. These decide whether the evidence is still there, and still yours, on the day someone asks for it.
Where do the records physically live, and who controls that storage?
Art. 12 records describe inferences made about people. If they sit in a vendor's cloud, your record-keeping obligation has quietly created a data transfer question on top of itself.
If you stop paying, or the vendor is acquired, what happens to the evidence?
Retention obligations outlive contracts. Art. 19 sets a six-month floor, and medical device technical documentation runs ten years past the last unit shipped. Ask whether the records stay readable without the vendor.
Can it record inference that never reaches a server?
If the model runs on the device, there is no server-side call to instrument. A platform built around a serving endpoint cannot produce a record of an event it never saw.
Does the human-oversight evidence come from real users, or from internal reviewers?
Art. 14(4) concerns the person operating the system choosing to disregard or override the output. A sampling workflow or annotation queue is a proxy for that. A record of what the operator actually did is not.
Can you reconstruct what a specific model version was doing on a specific date?
"We keep the logs" and "here is the state of the record set as of 14 March" are different claims. An Art. 74 request asks for the second one.
Instrumentation takes minutes. Accumulating the history it produces takes six months. Only one of those is under your control on the deadline.
This page summarises Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 and is provided for information only. It is not legal advice. Whether a given system is high-risk, and which obligations attach to it, depends on facts specific to that system.