Post-market monitoring
Article 72 of the EU AI Act requires high-risk system providers to monitor their deployment and respond to drift, novel failure modes, and emerging risks. Meridian Blue ships a built-in monitoring loop: rolling windows, scheduled red-team, and automated corrective-action tickets.
Drift detection
The drift-detection service compares rolling 7-day vs 30-day windows on five metrics per (tenant, model, purpose) tuple: toxicity, bias, hallucination, copyright, PII leakage rate. A short-window mean diverging from the long-window mean beyond a configurable threshold fires the drift.detected webhook and writes a snapshot to the audit vault.
Today the sample buffer is in-memory — high-volume tenants should swap to a Redis-backed implementation; the API surface (recordOutputSample / listSamplesInWindow) is shaped for that drop-in.
Scheduled red-team
The red-team scheduler walks every configured (tenant, model) target on a weekly cron, runs the built-in adversarial test suite, and diffs the result against the previous run. Regression beyond the configured pass-rate threshold fires the red_team.degraded webhook.
The runner is injectable: production dispatches through the proxy with an LLM-as-a-judge evaluator; tests use a deterministic simulator.
Corrective actions
When drift detection fires, an entry can be auto-created in the corrective-action workflow (opt-in via the scheduler config). Each action has a status (open / in_progress / closed / wont_fix), a trigger source, an owner, and a list of seeded remediation steps. Status transitions are audit-logged and fire corrective_action.opened / corrective_action.closed webhooks.
API: GET / POST / PATCH on /api/v1/corrective-actions.
Linkage to incidents
If drift escalates into a serious incident under Article 73, you'd graduate the corrective-action ticket into the incident flow at /api/v1/incidents — see Incidents.