Post-Market Monitoring: Practical Guide for SaaS Teams

Post-market monitoring means checking how an AI system behaves after release and using the findings to keep it safe and compliant. For SaaS teams, the practical starting point is a named owner, a documented monitoring plan, reliable feedback from real use, and a route from each significant finding to a decision. A dashboard becomes useful evidence only when someone reviews it and acts on what it shows.

This guide focuses on high-risk AI systems under the EU AI Act. The operational suggestions can also help with other AI features, but that does not make every SaaS product subject to Article 72. The checklists, review intervals, and examples below are implementation recommendations, not a prescribed regulatory template.

Establish scope and the current timetable

Article 72 requires providers of high-risk AI systems to establish and document proportionate post-market monitoring. It covers systematic collection and analysis of relevant performance data across the system's lifetime, including relevant interactions with other AI systems. The purpose is to evaluate continuing compliance with the high-risk requirements. AI Act, Article 72.

Start with the system's intended purpose, risk classification, and your company's role. Providing an application under your own name, operating a purchased system, and supplying a general-purpose model are different situations. Have the legal owner confirm the applicable role and provisions, including transitional treatment for existing systems, before presenting a monitoring programme as a legal obligation.

As of 13 September 2026, the Commission identifies 2 December 2027 as the application date for Annex III high-risk rules and 2 August 2028 for high-risk AI embedded in Annex I products. These updated milestones follow the AI Omnibus entering into force on 27 July 2026. They are not a blanket postponement of every AI obligation. Commission implementation update.

The amendment to Article 72(3) requires a monitoring plan and sets 2 September 2027 as the deadline for Commission guidance, including a template. Do not describe the original February 2026 implementing-act deadline as the current position. Regulation (EU) 2026/1744, Article 1(30).

Keep a dated applicability note alongside the plan. Record the system version, rationale, relevant dates, reviewer, and next reassessment trigger. Reopen it when intended use, market, or product responsibilities change. A clear scope statement prevents a monitoring team from inheriting an unsupported promise that every feature is already fully compliant.

Connect provider monitoring with customer feedback

A provider may see service telemetry while customers see the consequences of individual outputs. Design a feedback route that connects both views. Ask customer-facing teams to collect enough context to distinguish a product defect, unsuitable input, configuration issue, and use outside the documented purpose.

Deployers have a separate operational monitoring duty under Article 26(5), including relevant communication to providers and escalation of specified risks and serious incidents. A provider's monitoring plan does not replace that responsibility. AI Act, Article 26.

Agree who receives complaints, how customers identify the affected release, and who can request follow-up information. Include a route for urgent concerns outside normal account reviews. If the customer hosts the system and you cannot inspect production data, document that visibility limit and agree alternative evidence, such as aggregate findings, controlled reproductions, or customer-led evaluations.

For wider organisational context, use the guides to AI governance expectations for SaaS vendors and assigning compliance ownership.

Build a plan people can operate

Start with a short plan for one clearly bounded system. Link to existing engineering, support, security, and risk records instead of copying the same evidence into several documents. The following fields are a practical starting point:

• System boundary: intended purpose, affected users, supported configurations, releases, and connected AI components.
• Accountability: plan owner, technical reviewer, legal escalation contact, and deputy for absences.
• Signals: evaluation results, complaints, overrides, service failures, vendor notices, and known visibility gaps.
• Methods: sampling approach, comparison baseline, review frequency, and limitations of each measurement.
• Decisions: thresholds for investigation, restrictions, rollback, customer communication, and executive escalation.
• Evidence: where findings, approvals, corrective actions, and follow-up results are stored.
• Change triggers: new models, prompts, data sources, integrations, customer populations, and intended uses.

Give each signal a named recipient. A shared inbox without an accountable reviewer can accumulate reports while everyone assumes someone else is handling them. In a small company, one person may hold several roles, but the plan should still distinguish who investigates, who accepts residual risk, and who authorises continued operation.

Test the plan with a recent support complaint. Can the reviewer identify the release, find the relevant baseline, contact the right engineer, and document a decision without searching through private messages? If not, fix the handoff before adding more metrics.

Choose signals that can change a decision

Begin with the failure modes in the system's risk assessment. For each one, ask what observable evidence would suggest that a control is weakening. Availability and response time may matter, but they do not establish that outputs remain appropriate for the intended purpose.

Useful candidates include incorrect outputs in reviewed samples, failure to escalate uncertain cases, unexpected changes in overrides, complaints about recurring exclusion, and failures after an upstream update. Where meaningful and lawful, compare results across relevant operating contexts. Treat a missing or very small sample as a limitation, not proof of equivalent performance.

Record how each metric is calculated and what population it covers. A weekly error percentage can fall because the product improved, because difficult cases disappeared from the sample, or because the collection process broke. Pair numerical changes with information about traffic, configuration, and measurement coverage.

Choose alert thresholds through documented reasoning. An illustrative rule might open an investigation when a release produces repeated failures in a critical evaluation scenario. That is an internal decision rule, not a statutory numerical threshold. Assign someone to review false alarms and missed detections so the monitoring itself can improve.

Avoid collecting entire customer conversations by default. Work with privacy and security owners to choose the minimum information needed, access restrictions, and a retention schedule suitable for each evidence type. Keep a case identifier and restricted supporting material where possible, rather than duplicating sensitive content across tickets and dashboards.

Set review rhythms and change triggers

Separate immediate alerts, routine analysis, and periodic management review. For example, a team could triage urgent signals as they arrive, review trends weekly, and reassess the plan monthly during an early rollout. These are suggested starting intervals; choose a cadence justified by the system's risks and rate of change.

A release should identify which assumptions might have changed. New retrieval sources, model routing, permissions, languages, and customer populations can alter behaviour even when the user interface stays the same. Capture a baseline before the change, define the observation period, and decide what evidence would justify pausing rollout.

Include vendor updates in this process. Ask who receives release notices, how versions are identified, and what happens when an upstream service changes without a pinned version. Where observability is limited, record compensating checks and the remaining uncertainty rather than implying complete coverage.

For related operating practices, see how AI changes compliance monitoring and reporting. Keep the review outcome short: what changed, what evidence was examined, what decision followed, and who owns the next action.

Route findings into corrective action

Every significant finding needs a case record. Capture the discovery time, affected release and configuration, available evidence, potential impact, initial containment, decision owner, and follow-up deadline. Classify uncertainty explicitly: a plausible concern may need rapid action before the root cause is known.

A practical sequence is to triage the signal, protect affected users, preserve necessary evidence, investigate, select corrective action, and verify the result. Possible actions include changing instructions, restricting a configuration, rolling back a release, improving human review, or suspending a feature. Choose the response based on the actual failure and applicable duties.

Do not automatically close a case when engineering deploys a patch. Re-run the failed scenario, check representative use, and record whether the change introduced new problems. Update the risk assessment, instructions, monitoring checks, and release documentation when the finding changes their assumptions.

For issues accepted temporarily, specify the scope, approver, expiry date, compensating controls, and reopening trigger. An indefinite exception makes it difficult to distinguish a considered decision from a forgotten task. The next reviewer should be able to understand why operation continued and what would cause that decision to change.

Keep serious-incident reporting on a separate path

Potential serious incidents need immediate legal and incident-response triage. They should not wait for the next trend review. Article 73 contains reporting duties and differentiated deadlines: the general outside limit is 15 days, with shorter limits for specified cases, and immediate reporting requirements tied to the circumstances. It is not permission to wait 15 days. AI Act, Article 73.

Have the responsible reviewer determine whether the incident meets the legal definition, which reporting provisions apply, who must be notified, and when the clock started. The workflow should also assess parallel obligations under other applicable regimes and customer contracts. Keep those decisions distinct so one report is not mistakenly treated as satisfying every duty.

Rehearse an urgent scenario before launch. Confirm that the team can find the right contacts, preserve evidence, restrict use, and prepare an initial account while facts remain incomplete. Record who can make time-sensitive decisions if the usual owner is unavailable.

Example: a hiring application after a model update

Consider a hypothetical SaaS provider whose candidate-ranking application has been assessed as high-risk. After an upstream model update, customer complaints suggest that candidates with unconventional career histories are being ranked inconsistently. Aggregate service availability remains normal.

The monitoring owner opens a case, identifies affected versions and customers, and asks engineering to reproduce the issue using controlled examples. The team checks whether the evaluation set covered these career patterns and whether ranking behaviour changed relative to the approved baseline. Legal and product reviewers assess potential impact and any incident-reporting implications.

Depending on the findings, the provider could pause the rollout, restore the previous version, restrict affected functionality, or introduce additional human review. Customer communications explain the affected scope and interim measures without claiming a root cause that has not been established.

The case closes only after verification supports the chosen correction and the responsible reviewer records the result. The team expands its evaluation coverage and monitoring triggers where justified. This example illustrates a workflow; it does not establish that every ranking inconsistency is a legally reportable serious incident.

Common mistakes to avoid

Treating uptime as the whole programme. Operational health tells you whether a service runs. Add checks tied to output quality, oversight, and the risks of its actual purpose.

Waiting only for complaints. Quiet customers may lack a reporting route or may not recognise a failure. Combine feedback with planned evaluations and targeted follow-up.

Monitoring an obsolete version. Link findings to model, application, configuration, and data-source changes. A report about last quarter's system may say little about today's release.

Keeping evidence without decisions. A collection of charts cannot explain why the team continued, restricted, or stopped operation. Preserve the reasoning and follow-up verification.

Promising complete visibility. Identify missing customer data, inaccessible vendor internals, and sampling limits. Explain how those gaps affect confidence and decisions.

Questions teams ask

What is the practical purpose of post-market monitoring?

To detect when real use challenges assumptions made before release and turn that evidence into reviewed action. The operational output is a defensible decision and verified follow-up, supported by traceable findings.

Does every SaaS company need an Article 72 plan?

Do not assume so. Confirm high-risk classification, provider status, scope, and application timing. Other systems may still benefit from proportionate monitoring, while deployers must assess their own responsibilities separately.

What should we document first?

Start with one system's boundary, accountable owner, main failure modes, available signals, and urgent escalation route. Run a real finding through the process before expanding it across the product portfolio.

What evidence should a review produce?

Keep the plan version, reviewed evidence, coverage limitations, decision, action owner, and verification result. A reviewer should be able to follow the path from signal to closure without reconstructing the team's memory.

Sources

The legal discussion uses the consolidated AI Act, the AI Omnibus amendment, and the Commission references linked at the relevant claims. Legal status checked on 13 September 2026. The operating examples and suggested review rhythms are editorial recommendations.

Image: Team Meeting by woodleywonderworks, CC BY 2.0, via Wikimedia Commons; resized to 1280 × 482 pixels.