EU AI Act Article 72: Post-Market Monitoring for Course-Evaluation AI

Bottom line up front: Most universities think about AI compliance as a procurement gate — check the system once, sign the contract, move on. Article 72 of the EU AI Act breaks that assumption. For high-risk AI systems, the provider must run a continuous post-market monitoring system for the life of the product, and Article 26 requires the deployer — the university — to feed information back into it. Course-evaluation AI can fall into the high-risk category when its outputs are used to judge staff, which means model drift and degradation become a governance obligation you share, not a one-off validation you pass. A recent deadline shift buys time, but it makes building this discipline now the sensible move, not a reason to wait.

The obligation most compliance checklists miss

The AI Act's high-risk regime is usually discussed in terms of one-time gates: risk management, data governance, documentation, a conformity assessment before the system goes live. Article 72 is different because it is ongoing. It requires providers of high-risk AI systems to "establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks," and that system must "actively and systematically collect, document and analyse relevant data" — data that "may be provided by deployers" — on the system's performance "throughout their lifetime." The monitoring must be based on a documented post-market monitoring plan that forms part of the technical documentation, and the Commission is due to publish a template for that plan (via implementing act) by 2 February 2026.

The reason this matters is technical, not just legal. An AI system that themes and scores student feedback is not static. The language students use shifts, cohorts change, the model or its prompts get updated, and performance drifts. A system validated as accurate in 2026 can quietly degrade by 2028. Article 72 encodes what good machine-learning practice already knows: you cannot validate a model once and assume it stays valid. The regulation makes continuous monitoring a legal duty rather than an engineering nicety.

Why course-evaluation AI can be high-risk in the first place

None of this bites unless the system is high-risk — so the classification route matters. It is tempting to assume course-evaluation AI is caught by the education limb of Annex III, point 3, but that limb targets AI used to evaluate learners and learning outcomes. Course evaluation does not grade students; it appraises teaching. The sharper route is Annex III point 4(b), the employment limb, which covers AI "intended to be used to make decisions affecting terms of work-related relationships... or to monitor and evaluate the performance and behaviour of persons in such relationships." When a university uses AI-analysed course feedback to inform decisions about staff — probation, promotion, workload, contract renewal — it is arguably operating an AI system that evaluates the performance of workers, and the high-risk obligations, including Article 72, attach. This is an application argument rather than a line the text spells out for universities, and reasonable lawyers will weigh it case by case, but it is the classification most likely to catch course-evaluation AI. We set out the deployer-versus-provider distinction and this employment-limb reading in more detail in our piece on Article 26 deployer obligations and on high-risk course-evaluation systems.

The deployer is not a bystander

Article 72 sits on the provider, but the university is written into the loop. Article 26 requires that deployers "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." If a deployer has reason to think that using the system as instructed could present a risk, it must without undue delay inform the provider and the relevant market surveillance authority and suspend use. And where a deployer identifies a serious incident, it must "immediately inform first the provider." In other words, the university cannot outsource vigilance to the vendor. It has to watch how the system behaves on its own students and staff, and it has to escalate.

That connects to Article 73, which requires providers to report serious incidents to market surveillance authorities immediately and, in any event, no later than 15 days after becoming aware — a window that shrinks to two days for widespread infringements and ten days where a death is involved. "Serious incident" is a defined term (Article 3, point 49). For an evaluation system, the realistic failure modes are subtler than a crash: systematic misclassification of feedback about a particular group of staff, or a drift that quietly biases outcomes. Monitoring is how those get caught before they become incidents. This is the same ongoing-vigilance logic behind the Article 14 human-oversight duty.

The deadline moved — which is a reason to start, not stop

Here is the twist. The high-risk obligations for standalone Annex III systems were due to apply from 2 August 2026. But the "Digital Omnibus" reform, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026, postponed the main compliance obligations for standalone Annex III high-risk systems — including systems used in employment and education — to 2 December 2027. Because Article 72, Article 73 and the Article 26 deployer duties only bite once a system is regulated as high-risk under Annex III, they move with that date; that is a reasonable reading of the deferral rather than a line-by-line statement, so treat the timing as high-confidence but not gospel and confirm against the final text. The transparency duties of Article 50, the general-purpose AI rules, and the Article 5 prohibitions were not delayed.

It would be a mistake to read the postponement as a reason to defer the work. Post-market monitoring is not a document you produce the week before a deadline; it is an operational practice — data collection, drift detection, escalation routes, an audit trail — that takes time to build and only proves its worth over months of running. The extra runway to December 2027 is exactly the window in which to stand up that practice properly. Non-compliance with deployer obligations under Article 26 can attract administrative fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99) — but the better reason to act is that a monitored evaluation system is simply a more trustworthy one.

But isn't this the vendor's problem?

The natural objection is that Article 72 is a provider obligation, so a university that buys its evaluation AI can leave the monitoring to the supplier. That is half right and dangerously incomplete. The provider does carry the primary post-market monitoring duty — but Article 26(5) gives the deployer its own monitoring-and-notification obligation, and the provider's system explicitly depends on data "provided by deployers." A university that collects nothing, watches nothing and reports nothing is not compliant simply because it outsourced the model. The practical implication is procurement leverage: institutions should be asking vendors for their post-market monitoring plan, their drift-detection approach, and the exact channel for deployer feedback and incident reporting — and writing those into the contract. The compliance burden is shared, and the university's half is real.

What to do now

Ask for the monitoring plan at procurement. Make a vendor's Article 72 post-market monitoring plan and drift-detection method a contractual requirement, not an afterthought.
Instrument your own deployment. Track how the system performs on your cohorts and staff over time, so you can meet the Article 26(5) monitoring duty and feed the provider.
Define escalation routes. Decide in advance who notices a problem, who informs the provider, and who suspends use — before you need to.
Use the runway. Treat the window to December 2027 as build time for an operational practice, not a licence to delay.

Where Koji fits

A monitoring obligation that runs for the life of the system is a poor match for legacy tools that were never designed to be observed. Koji for Education is built AI-native, which makes the transparency the AI Act now expects tractable: standardized, bias-aware moderation that behaves consistently across cohorts, quality scoring on every interview, and thematic analysis whose outputs a course team can inspect rather than take on trust. That observability is exactly what a deployer needs to meet its Article 26(5) monitoring duty and to hold a provider to its Article 72 plan. Koji is careful about its claims — it mitigates and surfaces bias rather than eliminating it, and it keeps humans in the decision loop where the Act requires. The same AI interview engine powers general user and customer research on the main koji.so platform, under the same governance discipline.

Validating an AI system once is a procurement habit. The AI Act asks for something harder and more honest: watching it for as long as you use it. The institutions that build that habit now — while the deadline gives them room — will be the ones that can prove their evaluation AI is still trustworthy in 2028.

Frequently asked questions

What does Article 72 of the EU AI Act require? It requires providers of high-risk AI systems to establish and document a post-market monitoring system, proportionate to the risk, that actively and systematically collects and analyses performance data — including data from deployers — throughout the system's lifetime, based on a documented post-market monitoring plan.

Why would course-evaluation AI count as high-risk? Not through the education limb of Annex III (which targets AI evaluating learners), but through the employment limb, Annex III point 4(b): when AI-analysed course feedback is used to monitor or evaluate the performance of staff and inform decisions about them, it can be an AI system evaluating workers. It is an application-based reading, decided case by case.

Does the monitoring duty fall on the university or the vendor? Primarily on the provider (the vendor), but Article 26(5) gives the deployer (the university) its own duty to monitor the system in operation and inform the provider, and the provider's monitoring depends on deployer data. The obligation is shared, so a university cannot simply outsource it.

Didn't the AI Act's high-risk deadline get pushed back? Yes. The Digital Omnibus reform, Regulation (EU) 2026/1744 (in force 27 July 2026), postponed the main compliance obligations for standalone Annex III high-risk systems — including employment and education uses — to 2 December 2027. Article 50 transparency, GPAI rules and the Article 5 prohibitions were not delayed.

If the deadline moved, why act now? Because post-market monitoring is an operational practice — data collection, drift detection, escalation, audit trails — that takes months to build and only proves itself in use. The runway to December 2027 is the time to build it properly, not a reason to wait.

How does Koji help with post-market monitoring? By being observable AI-native: standardized bias-aware moderation, quality scoring on every interview, and inspectable thematic analysis give a deployer the visibility needed to meet its Article 26(5) monitoring duty and to hold a provider to its Article 72 plan — while keeping humans in the decision loop and framing its claims as mitigation, not elimination.

Building governance for AI-assisted course evaluation before December 2027? See how Koji for Education works.