Post-Market Risk Feedback for High-Risk AI: From Harm Signal to Controlled Change

Bottom line: post-market monitoring fails in practice not because teams lack dashboards, but because no one has defined the path from a harm signal to a validated, reversible change. A latency chart does not tell you whether a model regression, a retrieval-index refresh, a prompt edit, a policy change, or a fatigued reviewer caused the outcome. Build the loop as an engineering system with a signal taxonomy, a triage owner, correlation to a specific release artefact, and a release criterion that must be satisfied before the fix ships.

The EU AI Act frames this obligation in Article 72: providers must establish a documented post-market monitoring system that “actively and systematically” collects and analyses performance data across the system's lifetime, based on a monitoring plan that forms part of the Annex IV technical documentation. Deployers carry a matching operational duty under Article 26(5) to monitor operation and inform the provider. Article 73 then imposes hard reporting clocks once a serious incident is established. None of those provisions tell you how to build the machinery. That is the engineering problem this article addresses.

What changed in the timeline, and why it does not buy you a break

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and published in the Official Journal on 24 July 2026. It amends the AI Act's Article 113 so that Chapter III Sections 1–3 — the core high-risk obligations — apply from 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for AI embedded in Annex I regulated products. The same regulation replaced Article 72(3): instead of a binding implementing act with a mandatory template by 2 February 2026, the Commission must now adopt guidance, including a template, on the post-market monitoring plan by 2 September 2027.

Two consequences follow. First, the substantive obligation to run and document a monitoring system did not move — only the application date and the format guidance did. Second, and more importantly for engineering planning: the deferral pushes the deadline past the point where most organisations will already be operating the systems in question. You do not get to design the feedback loop retroactively over two years of production traffic that was never instrumented. Signal capture is the part with lead time.

Legal question for counsel: whether your specific system is a high-risk AI system under Annex I or Annex III, whether you act as provider or deployer, which application date binds you, and whether sectoral post-market frameworks (medical devices, machinery, financial services) already satisfy parts of the obligation. Those are classification and role questions that depend on your product, contracts and sector. Have them answered by qualified counsel.

Engineering recommendation: build the closed feedback loop now regardless of classification. Every control described below is defensible operations engineering that reduces incident cost, and each one takes months to instrument properly.

Why operational dashboards are not a risk-feedback system

A typical enterprise AI observability stack captures latency percentiles, token cost, error rates, and perhaps a thumbs-up/thumbs-down signal. Each of those is a system-health metric. A risk signal is different in three ways:

• It is about outcome, not throughput. “The extraction succeeded in 240 ms” and “the extracted counterparty was wrong and a payment was released” live in different observability planes. Health metrics rarely carry the business outcome.
• It arrives out-of-band. Harm signals surface through complaint desks, works councils, supervisor escalations, downstream correction tickets, auditors and customer support — not through your inference gateway. If your loop only ingests telemetry, you are structurally blind to the highest-severity class of signal.
• It needs attribution, not correlation. A rise in override rate is not actionable until you know whether the model version, the retrieval index, the system prompt, an upstream data schema change, a policy update, or reviewer staffing changed in the same window. Without a release identifier stamped on every decision, attribution degrades into argument.

A risk-signal taxonomy that actually routes

Classify signals by source and by what they can prove, then attach a fixed triage owner and clock to each class. The point of the taxonomy is routing, not paperwork.

Class F is the only class with a statutory clock attached, and the clock is unforgiving. Under Article 73, providers report a serious incident to the market surveillance authority of the Member State where it occurred immediately after establishing a causal link or the reasonable likelihood of one, and in any event within 15 days of becoming aware. That collapses to two days for a widespread infringement or an Article 3(49)(b) incident, and 10 days where a person has died. Article 73(5) explicitly permits an incomplete initial report followed by a complete one — design your process to use that, because waiting for a full root cause before notifying is how organisations miss the window.

One further constraint from Article 73(6) has direct engineering consequences: after reporting, the provider must investigate and must not alter the AI system in a way that could affect a subsequent evaluation of the causes before informing the authorities. In practice this means your rollback tooling must be able to contain without destroying evidence — disable a feature flag, route traffic to a fallback path, and preserve the exact artefact set, rather than hot-patching the prompt and losing the reproducible state.

The closed loop: from signal to controlled change

Step 1: capture, including the channels you do not own

In-band capture is the easy half: log the decision, the inputs (or their hashes where data protection requires), the retrieved context identifiers, the release identifier, the confidence or abstention signal, and the human action taken. The discipline is stamping every record with an immutable release identifier so attribution is a join, not an investigation.

Out-of-band capture is where most programmes fail. Complaint desks, works-council escalations and support tickets are the channels that carry Class A and Class F signals, and they typically live in systems with no link to your AI platform. The minimum viable integration is a single required field — “was an AI-supported decision involved, and if so, which case identifier?” — on the intake form of every channel that can receive a complaint about an automated outcome. Without that field, the signal exists but cannot be joined to a release.

Deployers should note the retention floor in Article 26(6): logs automatically generated by a high-risk AI system that are under the deployer's control must be kept for a period appropriate to the intended purpose and at least six months, unless other Union or national law — in particular data-protection law — provides otherwise. Six months is a floor, not a target. If your re-assessment cycle is annual, a six-month log horizon means half your evidence has expired before you need it.

Step 2: triage on severity and reversibility, not on volume

The common failure is triaging by ticket count, which systematically deprioritises rare high-severity events. Triage on two axes instead: severity of the potential harm, and reversibility of the decision that was made.

Two operating rules make this table work. First, the triage owner has standing authority to contain — to disable a feature flag or force human review — without a change advisory board meeting. Containment is not a change; it is a return to a previously approved, more conservative state. Second, containment and investigation run in parallel. Serialising them is what turns a two-hour incident into a two-week one.

Step 3: attribution against the release bundle

Attribution only works if there is a single artefact that pins the entire decision-making configuration at a point in time. This is the same construct discussed in the LLM release bundle: an immutable manifest covering model version and weights, quantisation variant, system prompt and template revision, retrieval index snapshot and embedding model, tool and function schemas, policy/guardrail version, and the evaluator suite hash. Add one further dimension that pure MLOps manifests usually omit: the human-oversight configuration — which reviewer roles were entitled, what the escalation threshold was, and what the staffing level looked like in that window.

With that in place, attribution becomes a mechanical diff. When a Class B override drift appears on 12 August, you query which of the eight dimensions changed between 5 and 12 August. In most real incidents exactly one changed, and it is frequently not the model: index refreshes, upstream schema changes and reviewer roster changes are heavily over-represented in root-cause data compared to how much attention model versions receive.

Data-side attribution needs its own lineage. If a Class C segment regression traces to training or retrieval content, you need to reach the source records, their transformations and their cohort coverage — the structure covered in data governance for high-risk AI. Without lineage, the only available fix is retraining on everything, which is slow, expensive and unverifiable.

Step 4: choose the fix path deliberately

Once attributed, the correction path determines the validation burden and the rollback plan. Choosing the cheapest path by default is how organisations accumulate prompt patches that nobody can reason about six months later.

The last two rows are the ones engineering teams skip. Article 26(2) requires deployers to assign human oversight to natural persons with the necessary competence, training, authority and support. “The reviewer approved 400 cases in a shift and stopped reading” is a genuine, fixable defect in the oversight configuration — not a training problem. The mechanics of tying capability to entitlement are covered in role-based AI literacy as an access-control system.

Step 5: validate against a pre-registered release criterion

The single most valuable artefact in this loop is the incident-to-release-criterion table. Every incident that results in a change must add a permanent, automated check to the release gate. This converts one-off firefighting into a ratchet: the system cannot regress into the same failure twice without the pipeline noticing.

Two design notes. Aggregate scores hide exactly the regressions that matter here — the criterion must be evaluated per segment (language, document type, cohort, rare-case class), which is the argument developed in designing release gates for enterprise model changes. And the frozen sets must be genuinely frozen and access-controlled; a suite that leaks into training data stops measuring anything.

Step 6: re-release with a safety-case delta

Article 9 defines the risk management system as a “continuous iterative process” across the entire lifecycle, requiring regular systematic review and updating, and Article 9(2)(c) explicitly requires evaluating risks that emerge from post-market monitoring data. Practically, that means every material change should produce a short, structured delta rather than a full document rewrite:

1. Which risk in the register did this change address, and what evidence shows it is now mitigated?
2. Which new risk did the change introduce (a new tool, a broader scope, a looser threshold, a removed review step)?
3. Which release criterion was added, and where does it run in the pipeline?
4. What is the rollback trigger and the named owner who may pull it?
5. Does the technical documentation and the post-market monitoring plan need updating, and who signed off?

Keep it to one page and generate it from the release bundle where possible. A delta that requires a workshop will not be written, and an unwritten delta means the next auditor sees a version history with no reasoning attached.

Failure modes seen in production

• The unjoined complaint. A complaint arrives about an automated outcome, is resolved compassionately by support, and is never linked to a case or release identifier. The pattern is invisible until a regulator asks for it. Fix: a mandatory AI-involvement field on every intake channel.
• Silent index refresh. The retrieval index is rebuilt on a nightly job that is not part of the release process. Quality moves, the model version has not changed, and attribution stalls for days. Fix: index snapshots carry release identifiers and are gated like model changes.
• The hot-patched prompt. An engineer edits the system prompt to stop an incident. The behaviour changes, the evidence for causal analysis is destroyed, and — for a reportable incident — this collides with Article 73(6). Fix: containment through flags and routing only; content changes go through validation.
• Alert fatigue as a risk control. Every anomaly raises a ticket, the queue exceeds triage capacity, and the team starts closing tickets in bulk. Severity signals drown in volume signals. Fix: separate the risk-signal pipeline from the health-alert pipeline, with different owners and different queues.
• Reversibility assumed, never drilled. Rollback exists on paper. Nobody has executed it against the current index format, the current adapter stack or the current policy version. Fix: a quarterly rollback drill with a measured recovery time, treated as a release criterion in itself.
• Evidence expiring before the review. Logs are kept for the six-month statutory floor, the re-assessment cycle is annual, and the trace for a January incident is gone by the time the July review runs. Fix: set retention from the re-assessment cadence and the limitation periods that apply to your sector, then reconcile with data-protection minimisation.

What this does not solve

A closed risk-feedback loop is an operational control, not a correctness guarantee. It will not detect harm that never produces a signal in any channel you monitor — quiet harms, unreported discrimination, and effects on people who never interact with your complaint process remain structurally invisible, which is precisely why fundamental-rights assessment is a separate discipline rather than an output of monitoring.

It does not determine your legal classification, your role as provider or deployer, or whether a given event meets the Article 3(49) definition of a serious incident. That last judgement is time-critical and legally consequential; the engineering system's job is to surface candidates fast and preserve evidence, not to make the call. The assessment plumbing that connects risk findings to controls and tests is covered in the shared FRIA–DPIA evidence platform.

It also does not fix a system that is unfit for its intended purpose. If the underlying capability is not adequate for the task, a fast feedback loop will simply document the failures more precisely. Withdrawal and scope reduction have to remain live options in the fix-path table, or the loop becomes a machine for justifying a system that should not be running.

Implementation sequence

1. Instrument the release identifier end to end. Nothing downstream works without it. Two to four weeks in most stacks.
2. Add the AI-involvement field to every out-of-band intake channel: complaints, support, works-council escalation, audit findings.
3. Write the six-class signal taxonomy with named owners and first-touch clocks. Publish it where the owners actually work.
4. Build the severity x reversibility triage matrix and grant standing containment authority. Test it with a tabletop exercise.
5. Freeze the first stratified evaluation suite and wire it into the promotion gate as a blocking check.
6. Start the incident-to-release-criterion table with the last three real incidents you can reconstruct. It is the artefact auditors and engineers both use.
7. Run one rollback drill and record the measured recovery time. If it exceeds your containment clock, that is your next piece of work.

Sources

• Regulation (EU) 2024/1689 (AI Act) — consolidated text — Articles 9, 20, 26, 72 and 73.
• Regulation (EU) 2026/1744 (Digital Omnibus on AI) — amends Article 72(3) and the Article 113 application dates.
• European Commission AI Act Service Desk — Article 72 — official article text and related recitals.
• European Commission — regulatory framework for AI — risk-based structure and obligation overview.

Where to start

If you are running or preparing a high-risk AI system, the highest-leverage first step is not a governance workshop — it is stamping a release identifier on every decision and adding one AI-involvement field to your complaint intake. Those two changes make every later control possible.

If you want the loop reviewed against your actual architecture, I run a focused post-market feedback assessment: signal taxonomy and channel coverage, release-bundle and attribution readiness, triage authority, rollback drill, and the incident-to-release-criterion table. The output is an implementation plan with named owners and measurable gates, not a slide deck.