What Article 72 post-market monitoring requires of providers
A provider of a high-risk AI system must keep a documented, proportionate post-market monitoring system running for the whole life of the system, so it can show that the system still performs as it did when assessed. Article 72 requires the provider to actively and systematically collect and analyse performance data, and to use that data to evaluate continuous compliance with the Act's requirements. Where relevant, the provider must also consider how the system interacts with other AI systems. The duty starts at placing on the market and does not end with the conformity assessment, so the provider needs a standing process, named owners and records that exist before the first incident or complaint arrives.
The hard part is that much of the performance data sits with deployers, not the provider. Article 72 expressly includes data from deployers, and Article 26(5) requires deployers to inform providers in line with Article 72. In practice the provider must design the feedback loop before launch: what deployers report, through which channel, how often, and what counts as a signal worth escalating. Contracts and instructions for use should spell out those obligations. The provider should also define which measures it will collect itself, such as drift, error rates on monitored subgroups and override rates, and confirm what its deployers can actually capture from their own environments. Article 9(2)(c) then requires the risk management system to evaluate the risks these data reveal, so monitoring findings must feed back into the risk file rather than sit in a dashboard.
Under the 2026 amendment, the post-market monitoring plan forms part of the Annex IV technical documentation, so the plan is no longer a loose internal procedure. Auditors and market surveillance authorities will read it alongside the design and testing records. Article 72(3) also requires the Commission to issue guidance and a template by 2 September 2027. Until that template exists, providers should draft the plan against the Act's text, version it, and be ready to map it to the template when published. Providers that already run sectoral monitoring under Article 72(4) should confirm with their authority whether the existing system gives equivalent protection before relying on it. The provider owns these decisions and the plan. An implementation partner can help build the monitoring stack and evidence, but the plan itself must reflect the provider's own system and be kept current.
Which systems, data and teams Article 72 applies to
Article 72 applies to providers of high-risk AI systems, and the scoping questions come before any monitoring design. The cards below cover which systems fall in scope, which monitoring route applies, what data feeds the system, and which teams own each signal.
High-risk systems in Section 3 scope
Article 72 sits in the provider obligations for high-risk systems, so the first check is whether the system is high-risk at all. Confirm the classification against Annex III or Annex I and record the decision in the technical file. A system that is later reclassified or substantially modified changes the monitoring scope, so the classification should be reviewed whenever the system's purpose or model changes.
Annex III systems versus Annex I products
Annex III systems are standalone uses such as credit scoring or recruitment, and their monitoring usually sits within a single AI governance and quality system. Annex I systems are AI components of regulated products, such as medical devices or machinery, and must fit the product's existing safety processes. Confirm which group your system belongs to, because it determines both the applicable date and the sectoral reporting channels that the monitoring plan must reference.
Article 72(4) integration route
Providers of Annex I Section A products, and financial institutions providing Annex III point 5 systems, may fold the post-market monitoring elements into monitoring they already run, provided the result gives equivalent protection. Ask your sector regulator or notified body whether existing monitoring meets that test, and document the mapping between the existing process and each Article 72 element so an assessor can follow it.
Logs and performance data owners
Article 72 depends on data the system produces in operation, including the automatically generated logs that Article 19 requires providers to keep. Assign an owner for log retention, access and quality checks, and confirm who can query production traces and metrics. Data collected from deployers must reach that owner through an agreed channel, because the monitoring system cannot evaluate continuous compliance without it.
Incident and deployer feedback channels
Deployers must inform providers about risks and incidents they observe, so the provider needs a documented intake path for that feedback. Define who triages deployer reports, how they feed the risk management system under Article 9, and which reports may become serious incidents under Article 73. Confirm the contact points and response roles in the contract with each deployer before launch.
Generative and LLM components
Where a high-risk system uses a generative or large language model component, standard uptime and accuracy metrics will not show hallucinations, prompt injection or data leakage. These need their own signals, such as adversarial probe results, trace-level tool execution records and content review samples. Confirm with your model supplier which of these signals the supplier provides, and which you must collect yourself.
How an assessor tests the post-market monitoring system
This table sets out the steps an assessor is likely to take to test Article 72 (1) to (3), the evidence each step asks for, and the findings that usually cause problems. Read it as a sequence: confirm the plan exists, trace it to real data, check deployer feedback flows, then sample records over time.
| Test step | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Review the plan | Whether a documented post-market monitoring plan exists, forms part of the Annex IV technical documentation, and covers the whole system lifetime under Article 72(1) and (3) | Current plan version, Annex IV cross-reference, scope statement, owners and review dates | Generic plan copied from a template with no system-specific data sources or thresholds |
| Trace data to risk management | Whether monitoring data feeds back into the Article 9(2)(c) risk management system and changes risk estimates | Risk register entries citing field data, dated risk reviews, linked monitoring findings | Risk file is static and never references post-deployment data |
| Check deployer data flows | Whether deployers' reports reach the provider in a form that supports Article 72 analysis, consistent with Article 26(5) | Deployer reporting instructions, channel records, sample deployer reports and provider responses | Instructions tell deployers to report issues but no intake channel or owner exists |
| Verify collection in operation | Whether performance, error, drift and complaint data is actually collected from the live system | Dashboard or alert configuration exports, log retention settings, sample extracts from the period under review | Metrics defined in the plan are not instrumented in production |
| Sample monitoring records over time | Whether analysis happened on a schedule and whether periodic results were produced across the review period | Dated analysis reports, meeting minutes, trend reviews and ticket history sampled at several points | Monitoring started at launch and records stop after the first few months |
| Test evidence of action taken | Whether findings led to a documented decision, such as a risk update, corrective action or a decision not to act with reasons | Action log linking each finding to a decision, owner, date and closure record | Findings recorded with no documented decision or follow-up |
| Check interaction with other systems | Whether the provider considered interaction with other AI systems where relevant, as Article 72(2) requires | Interaction analysis, integration descriptions and records of joint incidents or anomalies reviewed | Interaction assumed to be out of scope without any written analysis |
| Confirm Article 72(4) routes | Whether a provider relying on an existing sectoral or financial-sector monitoring system can show equivalent protection | Mapping of existing system to Article 72 elements and the equivalence reasoning, reviewed by the assessor | Equivalence claimed with no written comparison against the Article 72 elements |
How a monitoring system collects and analyses performance data
An assessor reviewing Article 72 will look for four connected parts: the data sources the provider draws on, the metrics and thresholds that define acceptable performance, a review cadence with named owners, and a documented route from a finding to corrective action and risk reassessment. The data sources must include more than the provider's own test results. Article 72 expects the provider to actively collect data from deployers as well, so the plan should name each feed: system telemetry, traces of model and tool calls, user feedback, complaints, and deployer reports sent under Article 26(5). Confirm with your deployers how they will send those reports and what fields they must include.
Open-source tooling can produce much of the technical signal. Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series identified by metric name and labels, so an error rate, latency or drift indicator can be queried with PromQL and retained on local storage. Langfuse records traces of each request, including LLM calls, retrieval steps, tool executions, timing, token usage and metadata, which helps reviewers reconstruct how an output was produced. Grafana Alerting builds alert rules from queries across multiple data sources and handles metrics and logs together. These tools capture signals; they do not decide what a deviation means. The threshold decisions and the people who review alerts remain the provider's responsibility and must be written into the plan.
Close the loop in writing. Each threshold breach should open a record that is triaged, assessed against the Article 9(2)(c) risk management system, and either closed with a rationale or passed to corrective action under Articles 20 and 21. Where a finding changes the risk picture, the technical documentation and risk assessment must be updated. Ask your implementation partner, and any penetration tester or red-team provider, to show how their results feed the same register, and confirm with your legal team when a finding could also trigger a serious incident report under Article 73.
Implementing the post-market monitoring plan step by step
This sequence turns Article 72 into a working monitoring system: indicators are defined first, the system is instrumented, deployer feedback is routed, the plan is written into the technical documentation, and findings flow back into risk management. Each step leaves a named output that an assessor or market surveillance authority can inspect.
Define monitored performance and compliance indicators
The provider's compliance and product owners list what the system must keep doing after launch, such as accuracy against the intended purpose, error rates for affected groups, drift in input data, human oversight overrides, and any interaction with other AI systems the provider knows about. Each indicator gets a definition, a data source, an owner, and a threshold that triggers review. The output is an indicator register that links every indicator to a risk identified in the risk management system under Article 9. The step is done when every identified risk has at least one indicator, and every indicator has a named owner.
Instrument the system to produce the data
Engineering teams add the logging, metrics and tracing hooks that generate the data the indicators need, so the system records what it does in production rather than relying on memory or ad hoc tests. Open-source tools such as Prometheus for time-series metrics, Langfuse for traces of model calls and tool use, and Grafana for dashboards and alert rules can capture these signals, though the team should confirm each tool fits its architecture and data protection requirements. The output is a documented instrumentation map showing which component emits which signal. The step is done when a test request produces each expected record in the target store.
Set up data collection and retention
The team decides where monitoring data is stored, who can access it, how long it is kept, and how it is protected, and it aligns retention with the log duties in Article 19 and the documentation duties in Article 18. Personal data in traces and logs is minimized and reviewed against the GDPR where applicable. The output is a retention schedule and access model approved by the provider's compliance function. The step is done when retention settings are configured in the systems, not only written in a policy.
Establish deployer reporting channels
Because Article 72 requires the provider to collect data from deployers, the provider sets up a defined route for deployers to send performance observations, incidents and near misses. This includes instructions in the documentation supplied to deployers, a contact point, a template for reports, and an agreed response time that the provider confirms internally. Deployer obligations under Article 26(5) to inform providers in line with Article 72 are written into the contract or terms of use. The output is a deployer feedback procedure and signed or accepted deployer terms. The step is done when a test report from a deployer reaches the monitoring queue and is logged.
Write the plan into the Annex IV technical documentation
The provider writes the post-market monitoring plan as a section of the Annex IV technical documentation, describing the indicators, data sources, collection methods, analysis cadence, reporting routes and the link to risk management. The plan should be specific enough that an authority can see how the system is monitored in practice. The Commission's template, due by 2 September 2027 under Article 72(3), should be checked against the plan once published. The output is a versioned plan within the technical file. The step is done when the plan matches the instrumentation and the deployer procedure as built.
Run scheduled analysis and review
The monitoring owner runs recurring reviews of the collected data against the indicator thresholds, looking for degradation, new failure patterns, and signs that the system no longer meets its intended purpose. Dashboards and alert rules flag threshold breaches between reviews. Where the system is a language model application, adversarial probes using tools such as garak can be run periodically to check for prompt injection, data leakage and jailbreaks, and the JSONL report and hit log become review inputs. The output is a dated review record with findings, decisions and actions. The step is done when each review is signed off and any breach has an assigned action.
Feed findings into risk management and corrective action
Findings from monitoring are fed back into the Article 9 risk management system, which must evaluate risks identified from post-market monitoring data. Where a finding shows non-conformity or a risk, the provider moves to the corrective action process in Article 20 and assesses whether a serious incident report under Article 73 is needed. The risk register, technical documentation and quality management records are updated to reflect the change. The output is an updated risk register and a link from each finding to its resulting action. The step is done when every finding has a documented outcome, and the plan is revised if the monitoring approach itself proved inadequate.
Evidence that shows post-market monitoring works
Article 72 is tested by the trail it leaves: a written plan, defined metrics, running dashboards, and records showing that someone reviewed the data and acted on it. The cards below list each artifact, what it must show, and how to keep it current between audits so the file reflects the system as it runs today.
Post-market monitoring plan in the technical file
The written plan is the anchor document. It states what performance data is collected, from which sources (including deployer feedback), how often it is analysed, who owns each step, and how findings feed the Article 9 risk management system. Under the 2026 amendment this plan forms part of the Annex IV technical documentation. Check that the plan names the system version it covers and is re-dated whenever the monitoring scope changes. Ask your implementation partner to map each plan section to a live data source so the plan does not describe monitoring that does not exist.
Metric and alert definitions
Keep a versioned register of every metric and alert rule the system uses. Each entry should record the metric name, the threshold or trigger, the data source, the owner, and the risk it tests, such as drift, error rate, or harmful output rate. In Prometheus, rules and recording definitions live in version-controlled files that can be exported for review. Auditors look for a clear link from each alert to a risk in the register, so an alert with no documented purpose is a gap to close.
Monitoring dashboards and exported reports
Dashboards show the system's behaviour over time, but a screenshot alone rarely satisfies an assessor. Schedule exports of dashboard data and key query results at regular intervals and store them with timestamps and the system version they describe. Grafana Alerting can show metrics and logs together from one view, which helps reviewers trace an anomaly to its cause. Confirm that exported reports remain readable after the underlying data source is retired, since authorities may request historical records.
Trace and evaluation records from testing
For generative or language-model components, keep the evidence of output quality over time. Langfuse traces record inputs, outputs, tool calls, and token usage for each request, which lets a team sample real interactions for review. garak writes a JSONL report of every probe attempt and a hit log of successful attacks, which can be rerun after each model or prompt change. Store these outputs with the version they tested. Confirm retention periods with your legal team, since traces can contain personal data subject to GDPR.
Review minutes and sign-off records
Each periodic review should produce minutes that name the attendees, the data reviewed, the findings, and the decisions taken, including decisions to take no action. Minutes show that monitoring is a working control rather than a logging exercise. Record who had authority to accept residual risk and when. Keep the review calendar in the governance file so an assessor can see that reviews happened on schedule, not only that they are planned.
Deployer feedback and risk register updates
Article 26(5) requires deployers to inform providers in line with Article 72, so keep a log of every deployer report, complaint, and incident signal with its date, source, triage outcome, and closure. Feed confirmed patterns into the risk register, updating likelihood, impact, and controls each time. A register that never changes after launch suggests that the monitoring data is not reaching it. Ask deployers in their contracts to report on agreed channels so this log is complete.
Corrective action tickets
When monitoring shows that the system no longer complies or presents a risk, the response must be traceable from detection to closure. Open a ticket for each finding, link it to the alert or report that triggered it, record the root cause, the fix, the verification test, and the approver. Serious incident determinations under Article 73 should reference the same ticket. Tickets closed without verification evidence are a common audit finding, so require a retest result before closure.
Which open-source tools produce monitoring evidence
Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels. For a high-risk AI system, the useful metrics are operational and quality signals the provider has chosen to track, such as request volumes, error rates, latency, drift indicators or score distributions that the post-market monitoring plan names. Prometheus stores this data on its own local storage and is queried with PromQL, which gives you a time-stamped record you can export into the monitoring file.
- Plan-defined metrics: Instrument only the signals your monitoring plan lists, and record the metric definitions in the technical documentation.
- Retention: Local storage is autonomous, so decide how long data is kept and how it is backed up to meet your record-keeping duties.
- Labels: Use labels for system version and deployment context so performance can be compared across releases.
- Queries as evidence: Save the PromQL queries behind each review so the analysis can be repeated.
- Scope limit: Prometheus holds numeric series. It does not capture the content of individual decisions.
Confirm with your platform team how Prometheus will be deployed, backed up and access-controlled before counting its output as evidence.
Langfuse captures traces of every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For a system built on language models, this gives the provider a per-request record that can show how an output was produced and which component was involved. Traces are the natural source for investigating real-world behavior that metrics alone cannot explain.
- Request-level records: Each trace links steps within one request, which supports root-cause analysis after a complaint or incident.
- Inputs and outputs: Traces store the content of prompts and responses, so define in advance what is captured and for how long, because this data can include personal data.
- Token and cost metadata: Usage fields help track changes in model behavior and resource use over time.
- Version tagging: Attach model, prompt and release identifiers so traces can be grouped by system version.
- Licensing: Langfuse is MIT licensed, but confirm which edition, hosting option and features your environment uses.
Check with your data protection lead whether trace content falls under your GDPR obligations before enabling full capture in production.
Grafana Alerting builds alert rules from queries and expressions across multiple data sources, and it can alert on metrics and logs together from a single view. Its role in post-market monitoring is to turn collected data into documented thresholds, notifications and follow-up actions, which supports the duty to evaluate risks found in monitoring data and to act on them. Dashboards built from the same data give reviewers a shared picture of system performance.
- Threshold records: Store alert rules as code or export them so each threshold and its rationale can be shown to an assessor.
- Combined signals: Alert on metric and log queries together to detect patterns that neither source shows alone.
- Notification routing: Record who receives each alert and the response expected, so escalation can be evidenced.
- Review dashboards: Use dashboards as the input to periodic monitoring reviews and keep dated snapshots.
- Licensing: Grafana is licensed under AGPL-3.0-only. Have counsel confirm that your use, including any modifications or network-facing deployment, meets its terms.
Confirm that alert history is retained long enough to show how issues were detected and closed.
garak is an Apache-2.0 licensed tool that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, and a separate hit log listing the attempts that found a vulnerability. These files are structured adversarial testing evidence that can feed the risk evaluation for a model-based system. It probes the model itself, so it complements, rather than replaces, monitoring of live operation.
- Full attempt record: The JSONL report lists every probe and evaluation, which shows the coverage of a test run.
- Hit log: Keep the hit log with its run date, model version and configuration so findings can be tracked to closure.
- Repeatable runs: Schedule runs after model, prompt or configuration changes and retain each report.
- Findings workflow: Link each hit to a risk entry, a mitigation and a retest result.
- Licensing and limits: garak is Apache-2.0. Probe results do not establish that a system is safe, so describe its scope accurately in the plan.
Confirm with your security team which probes apply to your use case and which model endpoints are in scope for testing.
What meeting Article 72 costs in money and effort
This table breaks the cost of a post-market monitoring system into components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none are supplied for this topic, so use the questions in the final column when requesting quotes.
| Cost component | Who is paid | One-time or recurring | What drives it, and what to ask for |
|---|---|---|---|
| Monitoring tooling licences | No licence fee for Apache-2.0, MIT or AGPL-3.0 tools; hosting and storage vendors are paid | Licences none; hosting recurring | Confirm the AGPL-3.0 obligations for Grafana with counsel if modified. Ask the implementer which components need managed hosting. |
| Infrastructure, hosting and storage | Cloud or data center provider, or internal IT | Recurring | Trace volume, metric cardinality and retention period drive storage. Ask for a retention model tied to your log and documentation duties. |
| Engineering to instrument and maintain monitoring | Internal engineers or an implementation partner under a written scope | One-time build, then recurring maintenance | Number of AI systems, data sources and integrations. Ask for instrumentation scope per system and a handover plan. |
| Plan and technical file drafting | Internal compliance staff, legal or consultants | One-time, then periodic review | Scope of the risk management link under Article 9(2)(c) and the Annex IV documentation. Ask who owns each section. |
| Review and analysis of monitoring data | Internal quality, risk and product teams | Recurring | Alert volume, number of incidents and frequency of reviews. Ask for defined review cadence and triage roles. |
| External testing or review | Security testing firms or red team providers | Recurring or per engagement | Scope of adversarial testing, such as garak probes for language models. Ask for testing scope and whether findings feed the risk file. |
| Assessor and notified body time | Independent assessor or notified body, where the route requires one | Per assessment and reassessment | Conformity route under Article 43 and the extent of substantial modifications. Ask the assessor to state scope and fees in writing. |
| Sectoral integration work | Internal teams and sector regulators or auditors where relevant | One-time mapping, then recurring | Whether Article 72(4) equivalence applies to an existing system. Ask for a written equivalence analysis before reuse. |
Where post-market monitoring programs usually fall short
Most Article 72 gaps are not missing tools. They are missing links: between the provider and the deployers who hold the real-world data, between monitoring signals and the technical file, and between findings and documented action. Each card below names one gap and the step that closes it.
No contractual route to deployer data
Article 72 depends on data from deployers, and Article 26 requires deployers to inform providers in line with Article 72. If your contracts do not oblige deployers to share logs, incident notes, complaints and performance observations, that data may never reach you. Check each deployer agreement for a defined data feed, a reporting timeline and a named contact. Add the clause before the first deployment, not after the first problem.
Uptime without accuracy or drift
Dashboards that show availability and latency can look healthy while the system's outputs degrade. Article 72 asks you to evaluate continued compliance, which means tracking the performance metrics your technical documentation claims, such as accuracy, error rates by group and input distribution shifts. Confirm that each claimed metric has a defined measurement, a data source and a threshold that triggers review. Without those, the monitoring cannot show that the system still meets its requirements.
Monitoring plan kept outside the technical file
Article 72(3), as amended in 2026, ties the monitoring system to a post-market monitoring plan that forms part of the Annex IV technical documentation. A plan stored in a team wiki or a slide deck is hard to prove as current. Keep the plan under document control with a version history, owners and review dates, and cross-reference each monitoring activity to the technical file section it supports. Assessors and market surveillance authorities will ask for the version in force at a given date.
No link to Article 9 risk updates
Article 9(2)(c) requires the risk management system to evaluate risks identified from post-market monitoring data. Many programs collect signals but never feed them into the risk register. Define a routine where monitoring findings open or update risk entries, with a recorded residual risk decision and an owner. Check that a sample of monitoring alerts can be traced to a risk record, and that the risk record shows what changed in the system or its controls as a result.
No evidence that findings led to action
Collecting data is only half of the duty. Assessors look for a trail from a finding to a decision and then to a corrective step, such as a retraining, a documentation update, a deployer notice or a serious incident report under Article 73. Record each finding with its date, its assessment, the action chosen and the closure evidence. A monitoring log that shows detection but no outcomes suggests the system does not work as a feedback loop.
Who does what: your team, a partner and the auditor
As the provider of a high-risk AI system, your organization remains legally responsible for the post-market monitoring system under Article 72. No partner or auditor can take that responsibility over. Your team decides what the monitoring plan covers, which performance indicators matter for the intended purpose, what counts as a signal worth acting on, and when a finding triggers corrective action or a report to authorities.
- Plan ownership: approve the post-market monitoring plan that forms part of the Annex IV technical documentation and keep it current as the system changes.
- Risk decisions: feed monitoring data into the risk management system under Article 9(2)(c) and decide on mitigations.
- Deployer channel: set up how deployers report performance problems to you, consistent with the information duty in Article 26(5).
- Corrective action and reporting: decide when a non-conforming or risky system must be corrected, withdrawn or reported.
- Records: keep the monitoring records, decisions and their rationale available for market surveillance authorities.
Before engaging a partner, confirm internally who holds each of these decisions and who can sign off on them.
An implementation partner typically does the technical work that the plan describes: instrumenting the system, collecting and storing data, building dashboards and alerts, and preparing the evidence that shows the system runs as documented. DeployOpen works in this role. It prepares systems and evidence for your assessment but does not issue audit reports, attestations or certificates.
- Instrumentation: configure metric, log and trace collection in your own cloud accounts, data centers or air-gapped networks, using open-source platforms where that fits your environment.
- Dashboards and alert rules: build the views and thresholds your team reviews, and document what each alert means and who acts on it.
- Testing: run security and robustness testing, including adversarial probing of language model components, and record the results.
- Evidence packs: assemble logs, test reports and monitoring records in a form your assessor can trace back to the plan.
- Operations support: where you contract for it, maintain the pipeline, upgrade components and keep the documentation aligned with the system.
Ask any partner to put scope, deliverables and handover of ownership in writing, so that the plan and the evidence stay under your control after the engagement ends.
An independent auditor, assessor or, where the conformity route requires it, a notified body reviews your monitoring system and evidence and reaches its own conclusion. Only these parties issue reports or certificates. Under Article 43, most Annex III high-risk systems follow internal control (Annex VI), so the provider's own assessment carries the formal weight, but the evidence must still withstand inspection by market surveillance authorities. Notified bodies are involved for some biometric systems and Annex I products.
- Independence: the assessor must not design the monitoring system it reviews, or the evidence it tests will not be credible.
- Scope confirmation: agree early which parts of the monitoring system the assessment covers, including any integration with sectoral systems under Article 72(4).
- Evidence testing: sample logs, monitoring records and corrective actions to confirm they match the documented plan.
- Findings: receive and track findings, then confirm closure.
- Certificates where applicable: issue certificates only through a notified body route, and only for the systems that require one.
Ask the assessor which evidence it expects and in what format before the monitoring system is built, so that the build and the test use the same definitions.
Some monitoring work suits an outside partner, and some should stay inside the organization because it carries accountability or business context. The split depends on your staffing, your existing monitoring stack, and the sector you operate in. Cost also varies with how much of the stack you already run.
- Usually outsourced: initial instrumentation, dashboard and alert build, adversarial testing, and evidence packaging for a first cycle.
- Usually kept in-house: the monitoring plan, decisions on risk and corrective action, deployer relationships and final sign-off.
- Shared or case by case: ongoing operation of the pipeline, periodic re-testing, and updates after substantial modification.
- Recurring cost drivers: the number of monitored systems, data volume, how often tests run, and how many deployers report into the system.
- One-time cost drivers: the state of existing logging, the number of data sources to connect, and any integration with sectoral monitoring.
When you request a quote, ask for the scope split in writing, the one-time and recurring items separately, and what your team must supply in each case.
Questions buyers ask about Article 72 post-market monitoring
How much effort does Article 72 post-market monitoring take?
The effort depends mostly on how many high-risk systems you run, how many deployers feed back data, and how much monitoring already exists. Article 72 requires a proportionate system, so a single internal tool with a few deployers needs far less than a fleet across many customers. The one-time work is designing the monitoring plan, defining metrics and thresholds, and wiring data sources. The recurring work is reviewing the data, investigating deviations, feeding findings into the risk management system under Article 9(2)(c), and keeping the plan current. Ask any partner to break its quote into design, build, and run phases so you can see which part recurs.
Can our team run Article 72 monitoring in-house?
Yes, if you have engineers who can instrument the system, an owner who understands the Act, and people who can read performance data and judge whether it signals a compliance problem. Many teams find the technical part manageable and the evidence discipline harder: keeping a documented plan, recording decisions, and showing that findings led to action. Outside help is most useful for setting up the plan as part of the Annex IV technical documentation, for building the instrumentation, or for testing whether the evidence would hold up under review. DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, and the organization keeps ownership of its controls.
What does Article 72 require from engineering teams and deployers?
Engineering teams must make the system observable over its lifetime: capture performance and error data, define what counts as drift or degradation, and retain the data needed to evaluate continuous compliance. Deployers have a parallel duty under Article 26(5) to inform providers in line with Article 72, so the provider needs agreed channels for receiving field reports. Practical items to confirm with each party include:
- Which metrics, logs and incident signals the deployer will send, and how often
- Who triages reports and how fast they are reviewed
- How field findings reach the risk management process and the technical file
When does the Commission post-market monitoring template arrive, and what should we do before it?
Under Article 72(3) as amended in 2026, the Commission must issue guidance with a template by 2 September 2027. Until then, the Article 72 duties still apply, so do not wait for the template to start monitoring. Before it arrives, define your monitoring plan as a document inside your Annex IV technical documentation, map the data sources you already collect, set review cadences, and record how findings loop back into risk management. When the template is published, the gap analysis will be quicker if your plan already uses clear sections for scope, data, thresholds, review and actions.
Are open-source tools enough for Article 72 monitoring?
Open-source tools can cover much of the technical collection and analysis, but they do not replace the plan, the review process, or the evidence trail. Prometheus collects metrics over HTTP and stores them as time series with local storage, and Grafana Alerting builds alert rules across multiple data sources, so together they can cover metric and log signals. Langfuse records traces of LLM calls, retrieval steps, tool executions, token usage and metadata, which helps for generative systems. garak probes language models for issues such as prompt injection, data leakage and jailbreaks, and writes a JSONL report plus a hit log. Confirm each tool's retention, access control and export features against your own requirements, since the Act expects you to show what was collected and what you did with it.
How does Article 72(4) integration with existing monitoring work?
Article 72(4) allows providers of Annex I Section A products, and financial institutions providing Annex III point 5 systems, to integrate the post-market monitoring elements into monitoring systems they already run under sectoral rules, provided those systems achieve equivalent protection. The key test is equivalence: the existing system must still collect and analyse data over the system's lifetime, evaluate continuous compliance, and feed risk management. Ask your assessor or sectoral regulator how they expect equivalence to be shown, and document the mapping between the sectoral process and the Article 72 elements. This route does not remove the need for a documented plan in the technical file.
Which evidence will an assessor or authority ask to see for Article 72?
Expect requests for the post-market monitoring plan within your technical documentation, the data sources and collection methods it describes, records showing the data was actually collected and reviewed, and examples of how findings triggered risk assessments or corrective action. Assessors also look for links to deployer reports under Article 26(5) and for evidence that the plan is proportionate to the system's risk and scale. Keep dated review records, configuration exports for alerting rules, and decision logs. Confirm with your legal or compliance team which records must be retained and for how long, as retention rules sit in other articles of the Act.
How DeployOpen scopes and prepares Article 72 evidence
DeployOpen works on Article 72 as a fixed-scope engagement inside your own infrastructure. We help you set up the monitoring pipeline, the metrics and logs it depends on, and the post-market monitoring plan that sits in your technical documentation, while your organization keeps ownership of the system, the controls and the decisions.
How we scope
- Agree in writing which high-risk AI systems and versions fall inside the post-market monitoring scope.
- Map the performance, drift, error and complaint data each system produces and where it is stored today.
- Identify deployer feedback channels and confirm how deployer reports reach the provider's monitoring process.
- Confirm which sectoral monitoring systems exist, so any integration under Article 72(4) is assessed explicitly, not assumed.
How we build
- Instrument the high-risk system with self-hosted tracing and metrics so inputs, outputs and failures are captured over time.
- Configure alert rules that route degradation, anomalies and complaint spikes to a named owner for review.
- Draft the post-market monitoring plan as a section of the Annex IV technical documentation, aligned to your risk management process.
- Test alerting and data collection with representative scenarios and record the results as evidence.
How we hand over
- Deliver the monitoring plan, data flow diagrams, configuration and alert runbooks in formats your team can maintain.
- Provide a record of monitoring reviews, findings and the risk management actions they triggered.
- Document the handover of operating responsibilities so your staff can run the system after the engagement ends.
- Leave the final conformity judgment and any regulator-facing submissions with your organization and its independent assessor.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer once the monitoring system is live.
- Revisit the monitoring plan when the Commission template due by 2 September 2027 is published, so the scope can be updated.
- Confirm with your legal or compliance team which Article 72 duties apply to your role as provider or deployer.
- Scope any retainer in writing, including which monitoring reviews and system changes it covers.
