AI Act Post-Market Monitoring Plan
What Article 72 of the EU AI Act requires of a post-market monitoring system and plan, why the mandatory Commission template was repealed before it ever appeared, and what telemetry, logging and retention an engineering team has to build to make the plan real.
18 min read
72 views
Technically reviewed by Victor Sineglazov, D.Sc.
- The mandatory template was repealed before it ever appeared Regulation (EU) 2026/1744 replaced Article 72(3), turning a binding implementing act due 2 February 2026 into non-binding guidance, including a template, due 2 September 2027.
- The duty did not go anywhere when the template did Article 72(1) and (2) are unchanged, so the documented system, the plan inside the Annex IV technical documentation and the continuous compliance evaluation are owed whether or not a form exists.
- The plan is only as real as the telemetry behind it Article 72(2) asks for data actively and systematically collected, documented and analyzed across the system's lifetime, which is a pipeline requirement written in compliance vocabulary, and Article 12(1) separately requires the system to allow automatic recording of events over its lifetime.
- Drift monitoring is how you satisfy the duty, not what the law says Searched in full, the consolidated AI Act text in force 27 July 2026 contains zero occurrences of the word drift. Drift detection, calibration and stability monitoring are practice, and a plan that presents them as statutory requirements is inventing law.
- Provider and deployer duties are separate, and the financial services carve-outs are narrow Article 26(5) deems only the deployer's monitoring obligation fulfilled, leaving suspension, notification and serious incident duties intact, while Article 17(4) excepts post-market monitoring from the provider-side quality management system deeming rule.
Every high-risk AI system placed on the EU market owes a post-market monitoring plan. A lender running a credit scoring model, an insurer pricing life cover, a FinTech vendor selling either to banks, all of them have to write one and file it inside their technical documentation. The obvious move is to wait for the official form. There was supposed to be one, mandated, with a legal deadline. It no longer exists, and the thing that replaced it does not arrive until September 2027.
In short: Article 72 requires a documented post-market monitoring system based on a plan, and that plan sits inside the Annex IV technical documentation. The binding Commission implementing act that was to lay down the template was repealed by Regulation (EU) 2026/1744 and downgraded to non-binding guidance due 2 September 2027. The duty itself did not move. So the plan has to be designed in-house, now, against obligations that bite from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I ones.
What Article 72 obliges a provider to do
The duty is short and it is not conditional on any template existing. Under Article 72(1), "Providers shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system." That is Regulation (EU) 2024/1689, and Regulation (EU) 2026/1744 left paragraphs 1, 2 and 4 of Article 72 untouched.
Proportionate cuts both ways. A low-volume internal model does not need the apparatus of a system making millions of automated decisions a month. A model deciding consumer credit at scale does, and proportionality is why a supervisor will not accept a one-page plan for it.
The duty is a measurement duty, not a filing duty
Article 72(2) is where the paperwork framing breaks down. The system has to "actively and systematically collect, document and analyse relevant data which may be provided by deployers or which may be collected through other sources on the performance of high-risk AI systems throughout their lifetime, and which allow the provider to evaluate the continuous compliance of AI systems with the requirements set out in Chapter III, Section 2". The same paragraph adds that "Where relevant, post-market monitoring shall include an analysis of the interaction with other AI systems." Both from Regulation (EU) 2024/1689, Article 72.
Read the verbs. Collect, document, analyze, actively and systematically, throughout the lifetime. None of that is satisfied by an annual review meeting. It is a data pipeline obligation written in compliance vocabulary, and what it produces is a continuing judgment about whether the system still meets the requirements it was assessed against.
The interaction clause is the part FinTech teams read past. A scoring model consumes features from an upstream fraud model, a KYC screening service or a document extraction system, and when one of those changes behavior the scoring model's inputs shift without anyone touching the scoring model. Where that is the architecture, the interaction analysis is what the paragraph asks for.
The template that was repealed before it appeared
The pre-amendment Article 72(3) contained a hard promise to providers. It required the Commission to adopt "an implementing act laying down detailed provisions establishing a template for the post-market monitoring plan and the list of elements to be included in the plan by 2 February 2026", under the examination procedure. That wording is in the base Official Journal text of Regulation (EU) 2024/1689 and it is quoted here only as the pre-amendment reading. It is no longer the law.
Two things were promised there and both mattered. A template, so every provider filed the same shape of document. And a list of elements, so the question of what belongs in the plan had a legal answer rather than a consultancy answer. Neither survived.
What replaced it, and when it arrives
Regulation (EU) 2026/1744, the Digital Omnibus on AI of 8 July 2026, in force 27 July 2026, replaced Article 72(3) in full. The retained part keeps the plan where it always was, since "The post-market monitoring plan shall be part of the technical documentation referred to in Annex IV." The substituted part reads "The Commission, taking utmost account of the opinion of the Board, shall adopt guidance, including a template, on the post-market monitoring plan by 2 September 2027." Both from Regulation (EU) 2026/1744.
Three changes are folded into that one sentence. Binding became non-binding, an implementing act became guidance. The deadline moved by nineteen months. And the list of elements is simply gone, not deferred, because the replacement text promises guidance and a template and says nothing about a list.
The practical effect is more work, not less. A mandated template is a ceiling as well as a floor: fill it in correctly and adequacy is largely settled. With none, the provider designs the artifact, defends the design and later reconciles it against guidance that lands after the obligations have started applying to Annex III systems.
What a post-market monitoring plan has to contain
Nothing in the Regulation enumerates the contents. The enumeration was the job of the repealed implementing act, and the guidance that replaced it is not due until September 2027. Any list of plan sections available today, including this one, is engineering judgment derived from the duty in Article 72(1) and (2). It is not a statutory requirement and it should never be presented to a supervisor as one.
What the duty does constrain is the shape of the argument. The plan has to say where performance data comes from, what is done to it, what that supports about continuous compliance with Chapter III Section 2, and who acts when the answer turns negative. Metrics without a named data source are not auditable, and metrics without a threshold and an owner produce no action.
The headings that follow from the duty, labeled as judgment
Working backwards from Article 72(2), a plan for a credit or underwriting model normally has to answer five questions. Which data the provider will collect and from which deployers and other sources. How that data is analyzed and on what cadence. Which Chapter III Section 2 requirement each measurement speaks to, since that is the compliance judgment the paragraph asks the provider to be able to make. Where the interaction with other AI systems is analyzed, where relevant. And what happens on a negative finding, including the route into corrective action and, where the threshold is met, into serious incident reporting.
The third is the one most drafts skip and the one that makes the plan defensible. Accuracy metrics mean little alone. Tying a measurement to the requirement it evidences, whether accuracy, robustness, human oversight or data governance, is what turns telemetry into the continuous compliance evaluation the paragraph names.
What an engineering team actually builds
The plan is only as real as the pipeline behind it, and the pipeline starts with a logging capability the Regulation requires independently. Article 12(1) provides that "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system", from Regulation (EU) 2024/1689. That is a design obligation on the system, not an operational habit, and it is the substrate every monitoring claim rests on.
In a scoring stack, the events worth recording are narrower and more specific than application logs. Each decision needs the model version and the feature set version that produced it, the input feature values or a privacy-safe representation of them, the score and the decision boundary applied, any override a human made and the outcome once it is known, which for credit arrives months later. Without the outcome join, nothing downstream can measure whether the model is still right, only whether it is still running.
The second engineering problem is that the outcome arrives late and unevenly. Default data for a twelve-month loan book matures on a twelve-month lag, and it matures only for applicants who were approved, which is the population the model already liked. Any monitoring design that ignores that selection effect will report stable performance for as long as the model keeps rejecting the same people.
Deployer feedback is an input channel, not a mailbox
Article 72(2) names deployers as a data source, and for a vendor selling a scoring model to banks that is a product requirement rather than a support process. It means a defined submission format, a route by which a deployer's observation reaches the provider's analysis rather than its account manager, and a record of what was done with it. A shared inbox satisfies nobody's reading of actively and systematically.
Performance and drift signals, and where the Regulation stops
Here the honest answer diverges from most published guidance. The AI Act does not require drift monitoring. Searched in full, the consolidated text of the Regulation as in force 27 July 2026 contains zero occurrences of the word drift. It contains no reference to population stability, calibration monitoring or any other named statistical technique either.
What it requires is the continuous compliance evaluation in Article 72(2). Drift detection is one way to perform that evaluation, and for a model whose inputs are consumer behavior in a moving economy it is a good one. It is practice, not law, and a plan that presents it as a legal requirement is inventing the Regulation.
Why the distinction is worth holding
Because the technique is not prescribed, the provider chooses it and defends the choice, which means an unusual model can justify a measurement that fits it. The choice then has to be written down with its rationale, since nothing else stands behind it.
For lending and underwriting models the working set is usually input distribution monitoring on the features that carry the most weight, calibration checks against realised outcomes as they mature, stability tracking of the score distribution and subgroup performance monitoring where fundamental rights exposure is real. Each of those should be tied in the plan to a Chapter III Section 2 requirement, and none of them should be described as something the Regulation demands by name.
Retention, and how long the evidence has to live
Monitoring evidence is worthless if it is rotated away before anybody asks for it, and the AI Act sets a floor on both sides of the relationship. On the provider side, Article 19(1) says a provider "shall keep the logs referred to in Article 12(1), automatically generated by their high-risk AI systems, to the extent such logs are under their control", for a period appropriate to the intended purpose and at least six months. On the deployer side, Article 26(6) requires the deployer to "keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months". Both from Regulation (EU) 2024/1689.
Six months is a floor with no ceiling, and for a credit model it is close to useless as a target. Outcome data for the decisions logged in month one is not available until well past month six, so retention set to the statutory minimum guarantees the logs are gone before the evidence they support becomes measurable. The phrase appropriate to the intended purpose is doing the real work, and for lending that means retention keyed to the outcome horizon of the product.
Financial institutions file the logs, they do not skip them
Both retention provisions have a financial services limb, and neither is an exemption. A deployer that is a financial institution "shall maintain the logs as part of the documentation kept pursuant to the relevant Union financial service law", and Article 19(2) of Regulation (EU) 2024/1689 puts the provider-side logs in the same place. That is a filing instruction. The logs still have to exist, still have to cover what Article 12 requires and still have to be producible. What changes is which shelf they sit on, which for a bank is usually a benefit, because that shelf already has retention controls, access logging and an audit trail attached to it.
The provider and deployer split
Post-market monitoring reads like one duty and is two. A bank that buys a scoring model from a vendor is a deployer. A bank that builds the same model in-house and puts it into service is a provider, and carries both sets.
The deployer duty is in Article 26(5). "Deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72." Where the deployer has reason to consider that use in accordance with the instructions may present a risk within the meaning of Article 79(1), "they shall, without undue delay, inform the provider or distributor and the relevant market surveillance authority, and shall suspend the use of that system." On identifying a serious incident the deployer must "immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities of that incident", and where the provider cannot be reached, Article 73 applies mutatis mutandis. All from Regulation (EU) 2024/1689, Article 26.
The suspension duty is the sharp one. It is not a recommendation to consider suspending, and it sits next to an obligation to notify a supervisor, so a deployer's monitoring design has to produce that determination quickly and with enough evidence to survive being second-guessed. The Article 79(1) threshold it turns on is not defined in the AI Act's own words. That threshold is imported from the definition of a product presenting a risk in Article 3, point 19 of Regulation (EU) 2019/1020, adding, in Article 79(1) of Regulation (EU) 2024/1689, that it applies "in so far as they present risks to the health or safety, or to fundamental rights, of persons".
The deeming rule is narrower than it looks
On the provider side, Article 17(4) deems the quality management system obligation fulfilled by financial services internal governance, but carves post-market monitoring straight back out. The deeming applies "with the exception of paragraph 1, points (g), (h) and (i) of this Article, shall be deemed to be fulfilled by complying with the rules on internal governance arrangements or processes pursuant to the relevant Union financial services law". Point (h) is the post-market monitoring system. That passage is in Regulation (EU) 2024/1689. The deployer-side half of the same deeming pair, Article 26(5) plus these same excepted points, is developed in full in our note on the AI Act and DORA overlap for financial entities.
So a bank that is a provider inherits most of its quality management system from governance it already runs and has to build post-market monitoring anyway. The deeming rule is a reason to reuse governance plumbing, not a reason to think the duty is already discharged.
Where monitoring hands off to incident reporting
Monitoring produces the signal. Article 73 sets the clocks, a separate machine with a baseline reporting deadline of 15 days from awareness and shorter deadlines for severe incidents. The handoff is what belongs in the monitoring plan, not the clocks.
The plan has to specify the trigger, the escalation path and the evidence bundle. A monitoring alert has to reach a named role who can decide within hours whether the threshold is met, and the log excerpts, model version and affected decision population have to be assemblable in the same window. Teams that discover during a live incident that the bundle takes four days to assemble have already lost the reporting deadline.
Who receives the report is no longer one answer
Regulation (EU) 2026/1744 replaced Article 75 and gave the AI Office competence over certain systems, subject to carve-outs. One of them covers "AI systems provided by law enforcement authorities, border management authorities and financial institutions, insofar as those AI systems fall under Article 74(6)", from Regulation (EU) 2026/1744. That final clause is a condition, not a category.
Article 74(6) makes the national financial supervisor the market surveillance authority for financial institutions, but only "in so far as the placing on the market, putting into service, or the use of the AI system is in direct connection with the provision of those financial services", from Regulation (EU) 2024/1689. A credit scoring model plainly is in that direct connection. An HR screening model the same bank runs is not, and it falls outside the carve-out with it. A monitoring plan that names a single recipient authority for every AI system the firm operates is naming the wrong one for some of them.
Integration with existing financial services systems
Article 72(4) offers a reuse route, and it survived the amendment intact. For systems covered by the Union harmonisation legislation in Section A of Annex I, providers have a choice of "integrating, as appropriate, the necessary elements described in paragraphs 1, 2 and 3 using the template referred in paragraph 3 into systems and plans already existing under that legislation, provided that it achieves an equivalent level of protection". The second subparagraph extends that route to "high-risk AI systems referred to in point 5 of Annex III placed on the market or put into service by financial institutions that are subject to requirements under Union financial services law regarding their internal governance, arrangements or processes". Both from Regulation (EU) 2024/1689.
Annex III point 5 is where creditworthiness evaluation and life and health insurance pricing sit, so this is the paragraph that matters for a bank or an insurer. It lets the monitoring elements live inside model risk management the firm already operates, rather than in a parallel AI compliance structure nobody reads.
The route now points at a document that does not exist
Notice what the first subparagraph points at. It offers integration using the template referred to in paragraph 3, and paragraph 3 is exactly the provision the Digital Omnibus rewrote. The template that clause anticipates is now the non-binding one due 2 September 2027. The integration route is still available and still worth taking, but it cannot be executed against a form, only against the duty in paragraphs 1 and 2.
Financial entities separately run ICT risk management and incident reporting obligations under Regulation (EU) 2022/2554, and the operational plumbing there, detection, classification, escalation and reporting, resembles what Article 72 needs. The AI Act does not refer to that regime, and neither regime satisfies the other. The reason to look at both together is engineering reuse of pipelines and on-call rotas, never a claim that one discharges the other. An AI governance framework is where the two are reconciled at the organization level.
Timeline after Regulation (EU) 2026/1744
The Digital Omnibus on AI is the only amendment the AI Act has received, and it moved the high-risk clock. The amended Article 113 provides that "Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5), shall apply from" two dates: "2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and" "2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I;". From Regulation (EU) 2026/1744.
Article 72 sits in Chapter III Section 3, so the monitoring duty follows those dates. For a credit scoring or insurance pricing model, which reaches high-risk status through Article 6(2) and Annex III, the operative date is 2 December 2027. Article 6(5) is expressly carved out of the deferral and keeps its 2 February 2026 date. Material citing 2 August 2026 was written before the amendment, or was not updated after it. The AI Act compliance timeline carries the rest of the dates.
Two of those dates sit badly together. Monitoring applies from 2 December 2027 and the guidance that shapes the plan is due 2 September 2027, which leaves about three months between a non-binding template appearing and the duty biting. That is not enough time to design and instrument a monitoring system from scratch, which is the practical argument for starting now and treating the guidance as a reconciliation exercise.
What routine retraining does to the clock
Monitoring and conformity assessment meet at retraining. A substantial modification restarts the assessment, but changes "pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation referred to in point 2(f) of Annex IV, shall not constitute a substantial modification", from Regulation (EU) 2024/1689, Article 43(4).
That draws a line the monitoring plan should respect. A quarterly refit inside a documented envelope is a monitoring event, absorbed by the plan and recorded through it. A change outside the envelope is an assessment event. Writing the envelope into Annex IV point 2(f) before launch is what keeps routine model maintenance on the monitoring side of that line, and it has to be done in advance, since a retraining policy authored later does not qualify retroactively.
How Pharos Production builds post-market monitoring
We build FinTech and insurance systems where the model is part of a regulated product, so we treat the monitoring plan as an engineering deliverable, not a document written after the build. That means decision-level event logging designed against Article 12 from the first sprint, outcome joins engineered for the product's real maturation horizon, a deployer feedback channel with a defined submission format, and every metric mapped to the requirement it evidences.
Because there is no template yet, the test we apply is whether an outsider can read the plan alongside the telemetry and see that the measurements described were actually taken. Our AI governance and FinTech development teams build the pipeline and the plan together, and we write the technical documentation around both, so that when the Commission guidance lands in September 2027 the work is a reconciliation rather than a rebuild.
Sources: Regulation (EU) 2024/1689 (AI Act), base Official Journal text, Articles 12, 17, 19, 26, 43, 72, 74 and 79, via Regulation (EU) 2024/1689; Regulation (EU) 2026/1744 (Digital Omnibus on AI) of 8 July 2026, in force 27 July 2026, amending Articles 72(3), 75 and 113, via Regulation (EU) 2026/1744. Read on 25 August 2026. Provisions the Digital Omnibus replaced are quoted from the amending instrument; provisions it left alone are quoted from the base text. The pre-amendment Article 72(3) wording is quoted once and identified as historic. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 5
No matches
Try a different keyword, change the topic or clear filters
-
No. Article 72(3) originally required the Commission to adopt an implementing act laying down a template and the list of elements by 2 February 2026, and Regulation (EU) 2026/1744 replaced that paragraph before any such act appeared. What is owed now is non-binding guidance, including a template, by 2 September 2027.
Providers have to design the plan themselves in the meantime, and the guidance arrives roughly three months before the obligations start applying to Annex III high-risk systems.
-
A documented post-market monitoring system proportionate to the nature of the AI technologies and the risks of the system, which actively and systematically collects, documents and analyzes relevant performance data across the system's lifetime, whether supplied by deployers or gathered from other sources, so the provider can evaluate continuous compliance with the Chapter III Section 2 requirements. Where relevant it must also include an analysis of the interaction with other AI systems.
-
In the technical documentation referred to in Annex IV. That sentence survived the Digital Omnibus unchanged.
The plan is not a standalone compliance memo, it is part of the file that has to exist before the system is placed on the market, which means it is read alongside the rest of the Annex IV documentation rather than on its own.
-
Partly. Article 72(4) lets providers integrate the required elements into systems and plans already established under Annex I Section A legislation, and its second subparagraph extends that route to Annex III point 5 systems placed on the market or put into service by financial institutions subject to Union financial services law on internal governance, arrangements or processes.
On the deployer side, Article 26(5) deems the monitoring obligation fulfilled by complying with those internal governance rules, but the duties to suspend use, to inform the market surveillance authority and to escalate a serious incident are not covered by that deeming. On the provider side, Article 17(4) excepts points (g), (h) and (i) from its quality management system deeming rule, and point (h) is post-market monitoring.
-
Both sides carry a six-month floor. Providers keep the Article 12(1) logs their high-risk systems generate, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months, and deployers carry the same floor under Article 26(6).
Financial institutions on either side maintain the logs as part of the documentation kept under the relevant financial services law, which places the logs rather than excusing them. For a credit model the outcome horizon usually makes six months far too short to be a sensible target.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
