A Fundus Camera in Pune, a Compliance File in Warsaw
A diagnostic-AI startup — call it Drishti Health — has spent three years validating a diabetic-retinopathy screening model on fundus photographs collected across eye camps in Maharashtra and Tamil Nadu. The model is good: on a held-out clinical validation set of 1,000 confirmed-positive cases, it correctly flags 960 of them, a sensitivity of 96%. Drishti now signs a contract to deploy the same model in a chain of diabetes clinics in Warsaw, reading scans for Polish patients. The moment that contract is signed, Drishti stops being an Indian medtech company answerable only to India's own AI governance guidelines, and becomes a "provider" of a "high-risk AI system" under Regulation (EU) 2024/1689 — the EU AI Act — regardless of the fact that neither Drishti's servers nor its engineers ever leave Pune. Extraterritorial reach of this kind, and how a system gets sorted into the Act's risk tiers in the first place, is well-trodden ground. What is less often taught — and what actually determines whether Drishti's model is legally allowed to read a single Polish patient's scan — is the machinery that sits between "this system is high-risk" and "this system is generating diagnoses in Warsaw." That machinery, and what keeps running after the paperwork is filed, is this chapter's subject.
Two Different Doors Into "High-Risk"
Article 6 of the Act defines high-risk status through two structurally different routes, and which door a system walks through changes everything downstream. Article 6(1) covers products already regulated by existing EU product-safety law: an AI system counts as high-risk if it is a safety component of, or is itself, a product listed under the Union harmonisation legislation in Annex I — and that sectoral legislation already requires third-party conformity assessment. Annex I explicitly names the Medical Devices Regulation (EU) 2017/745 and the In Vitro Diagnostic Medical Devices Regulation (EU) 2017/746 alongside machinery, toys, lifts, and pressure equipment. Drishti's retinopathy screener is a medical device under the MDR, so it enters through this door. Article 6(2), by contrast, covers systems with no pre-existing sectoral regulator — the eight standalone-use categories listed in Annex III: biometric identification, critical infrastructure, education, employment, access to essential services (credit scoring, insurance, emergency dispatch), law enforcement, migration, and the administration of justice. A résumé-screening tool or a credit-underwriting model has no product-safety law to hook into, so it is classified directly by Annex III.
The reason this fork matters is that Article 43(3) routes conformity assessment differently for each. A system entering through Article 6(1) is assessed by the notified body already designated under its sectoral law — Drishti's screener goes through the same MDR-accredited notified body that would certify any other Class IIa/IIb diagnostic software, which now also checks the AI Act's data-governance, documentation, and human-oversight requirements as an extension of the device audit it was already going to run. A system entering through Article 6(2)/Annex III instead defaults to Annex VI: internal control, meaning the provider self-certifies against harmonised standards, with no external body involved at all — except for remote biometric identification (Annex III point 1), where Article 43(1) makes Annex VII notified-body assessment mandatory only if the provider has not applied the relevant harmonised standards or common specifications — if it has, the provider may still choose Annex VI internal control like any other Annex III system. The Act, in other words, does not build a single new bureaucracy for every high-risk AI system; where one already exists and already bites, it reuses it.
Building the File: Technical Documentation and the Quality Management System
Before any conformity assessment can happen, Article 11 requires the provider to assemble technical documentation matching the structure of Annex IV: a general description of the system and its intended purpose; a detailed account of the design and development process, including the choices made about the training, validation, and testing datasets; the risk management system required by Article 9; the metrics used to measure accuracy, robustness, and cybersecurity under Article 15; and — this is the detail that matters most for the rest of this chapter — the post-market monitoring plan required by Article 72(3), which the Act explicitly requires to be filed as part of this same technical documentation, not as an afterthought once the product ships. Article 17 layers a further requirement on top: a documented quality management system covering the provider's strategy for regulatory compliance, its design-control procedures, its data-management practices, and — again — its post-market monitoring and incident-reporting procedures. The file Drishti assembles before a single Polish patient is scanned already has to describe, in writing, how the company will keep watching the model after deployment.
CE Marking, the EU Database, and the Line Between Pre-Market and Post-Market
Once conformity assessment concludes — successfully, in Drishti's case, because its notified body confirms the technical documentation and testing satisfy both the MDR and the AI Act's added requirements — Article 47 requires the provider to draw up an EU Declaration of Conformity, a signed statement that the system meets every applicable requirement. Article 48 then permits the CE mark to be affixed. For Drishti's system, entered through the Article 6(1) product-safety route, that closes the pre-market gate: as a device already tracked through the MDR's own sectoral registry (EUDAMED), it carries no separate EU AI Act database-registration duty. That duty belongs to the other door. Article 49(1) requires providers of Article 6(2)/Annex III high-risk systems — the standalone-use categories with no pre-existing sectoral regulator, such as a credit-scoring or biometric-identification system — to register in the EU database established under Article 71 before the system is placed on the market or put into service, creating a public record searchable by regulators and the public (Annex III point 2 systems register at national level instead, and Article 49(4)-(5) route law-enforcement, migration, asylum and border-control, and administration-of-justice systems to a restricted, non-public section of the database). Only after that registration can an Annex III provider's system legally go live. This sequence — documentation, assessment, declaration, marking, and, for Article 6(2) systems, registration — is the entire pre-market half of AI Act compliance, and it is the half most treatments of the Act stop at, because it is the half that resembles a familiar checklist: build the file, pass the audit, get the stamp, go live.
The Obligation That Doesn't End at the CE Mark
Article 72 requires every provider of a high-risk AI system to establish and document a post-market monitoring system that actively and systematically collects, documents, and analyses relevant data on the system's performance throughout its lifetime — not a one-time validation number frozen at certification, but a live statistical process running against real patients, real loan applicants, real biometric matches. Article 72(2) requires this monitoring to compare the system's actual, real-world behaviour against the performance it was validated for at conformity assessment, and Article 9(2) requires the risk management system to be updated in light of what that monitoring finds — the compliance loop does not close at deployment, it re-opens. This is precisely the design decision a production ML engineer already recognises from any serving system with a training/serving skew problem: the model that shipped is not the model that keeps running, because the data distribution it sees in the field keeps moving. The Act simply makes tracking that drift a legal duty rather than an engineering best practice, and attaches consequences — reporting deadlines, fines, potential market withdrawal — to ignoring it.
Worked Example: Is a Sensitivity Drop Real, or Noise?
Suppose Drishti's Warsaw post-market monitoring collects its first full month of confirmed cases: 500 patients whose retinopathy status was later confirmed by an ophthalmologist, of whom the AI correctly flagged 460. Observed sensitivity is 460/500 = 92%, against a validated baseline of 96%. Before anyone decides whether this is a "serious incident," the first question is statistical: is a four-point drop distinguishable from ordinary sampling noise at this sample size, or is it real drift?
Treat the validated baseline p₀ = 0.96 as a fixed reference (it was established on a much larger validation set, so its own sampling error is negligible by comparison), and test the null hypothesis that the deployed model's true sensitivity still equals 0.96, against the one-sided alternative that it has fallen. The standard error of a sample proportion under the null is:
SE = sqrt( p0 * (1 - p0) / n )
= sqrt( 0.96 * 0.04 / 500 )
= sqrt( 0.0384 / 500 )
= sqrt( 0.0000768 )
= 0.00876
and the z-statistic compares the observed proportion to the baseline in units of that standard error:
z = (p_hat - p0) / SE
= (0.92 - 0.96) / 0.00876
= -0.04 / 0.00876
= -4.564
A z-score of -4.56 is far beyond the usual |z| > 1.96 threshold for significance at α = 0.05 — this is not a borderline call. The exact one-tailed p-value, computed from the standard normal CDF, confirms it:
import math
def monitor_significance(p0, n, observed_positive):
"""One-sample proportion z-test against a validated baseline rate."""
phat = observed_positive / n
se = math.sqrt(p0 * (1 - p0) / n)
z = (phat - p0) / se
p_value = 0.5 * (1 + math.erf(z / math.sqrt(2))) # lower-tail p
return phat, se, z, p_value
phat, se, z, p_value = monitor_significance(p0=0.96, n=500, observed_positive=460)
print(f"observed sensitivity = {phat:.3f}")
print(f"standard error = {se:.5f}")
print(f"z-score = {z:.3f}")
print(f"one-tailed p-value = {p_value:.2e}")
Run mentally line by line: phat = 460/500 = 0.920; se reproduces the 0.00876 derived above; z reproduces -4.564; p_value uses the standard normal CDF formula Φ(z) = 0.5(1 + erf(z/√2)), which for a negative z gives the lower-tail probability directly. This prints exactly:
observed sensitivity = 0.920
standard error = 0.00876
z-score = -4.564
one-tailed p-value = 2.51e-06
A p-value near 2.5 in a million rules out chance almost completely. Under Article 72, this is now a documented, statistically confirmed instance of real-world drift, and it obligates Drishti to investigate — pulling the 40 missed cases, checking whether they share a cause (a new camera model at the Warsaw clinic producing images outside the training distribution, perhaps, or a shift in patient demographics the Indian training set under-represented).
From Statistical Drift to Legal Duty: Serious Incidents and the Reporting Clock
Statistical significance alone does not trigger anything beyond an internal investigation. Article 3(49) defines a narrower category — "serious incident" — as a malfunction that directly or indirectly leads to: death or serious harm to a person's health; serious and irreversible disruption of the management or operation of critical infrastructure; a breach of Union law intended to protect fundamental rights; or serious harm to property or the environment. Suppose Drishti's investigation of the 40 missed cases finds that one patient's referable retinopathy, missed by the model, progressed untreated to a stage that caused irreversible vision loss. That single case crosses the Article 3(49)(a) threshold — "serious harm to health" — and converts a statistics problem into a reporting obligation under Article 73.
Article 73 does not give providers a single deadline; it tiers the clock by severity. The general rule under Article 73(2) is that the provider must report to the national market surveillance authority without undue delay and in any event no later than 15 days after becoming aware of the causal link between the AI system and the incident. Article 73(4) shortens that to 10 days specifically where the incident involves a person's death. Article 73(3) shortens it further, to 2 days, for a serious incident under Article 3(49)(c) — critical-infrastructure disruption — or for a widespread infringement affecting multiple Member States. For Drishti's irreversible-vision-loss case, no death occurred and no critical infrastructure is involved, so the applicable deadline is the default 15 days from the point the causal link is established or reasonably suspected.
Common Misconception
Students who have just studied risk classification and conformity assessment tend to picture AI Act compliance as a single gate: pass the audit, receive the CE mark, done — the same mental model as clearing a school board exam. This is wrong in a specific, testable way. The CE mark certifies that the technical documentation and testing available at the moment of assessment met the requirements; it says nothing about whether the deployed system keeps meeting them six months later, once it is reading scans from a camera model, patient population, or clinical workflow the validation set never saw. Article 72 makes post-market monitoring a standing legal duty running for the system's entire lifetime, and Article 73 attaches a live reporting clock to what that monitoring finds. A provider who obtains a CE mark and then stops watching the model is not compliant merely because the mark is still on the box — Article 99's enforcement penalties (the same fine structure covered in the classification-and-enforcement treatment of this Act) apply to failures of Article 72 and 73 exactly as they apply to shipping an unclassified system in the first place. The gate does not close behind you; it becomes a checkpoint you have to keep re-passing with live data.
Active Recall
Attempt each question before reading its answer.
- What structurally distinguishes the Article 6(1) route into high-risk classification from the Article 6(2)/Annex III route, and why does that distinction change who performs conformity assessment?
- A credit-scoring system (Annex III, standalone-use route) was validated at 90% decision accuracy on a large historical dataset. A post-market monitoring batch of 400 real loan decisions is reviewed, and 344 are found correct. Using a one-sample proportion z-test against p₀ = 0.90, is this drift statistically significant at the conventional α = 0.05 (two-tailed, |z| > 1.96) threshold?
- Which single document is legally required to contain the post-market monitoring plan, and at what stage of the compliance pipeline must it first be filed?
- True or false, with justification: "Once Drishti Health's screener receives its CE mark, its legal obligations under the AI Act for that system are complete."
- In the worked example, suppose the patient who suffered harm from a missed diagnosis had died rather than lost vision irreversibly. Trace the full effect of this change: does it alter the z-score computed from the 460/500 monitoring batch? Does it change whether Article 3(49) is triggered at all? Does it change the Article 73 reporting deadline? Does it change which conformity-assessment route (Article 6(1) vs 6(2)) Drishti's system was classified under?
- Why does Article 43(3) route medical-device AI systems through the notified body already designated under the Medical Devices Regulation, rather than requiring a fully separate AI-Act-specific certification process?
Answers.
1. Article 6(1) covers AI systems that are safety components of, or are themselves, products already covered by Annex I product-safety legislation (such as the Medical Devices Regulation) and already subject to third-party conformity assessment under that law; Article 6(2) covers the eight standalone-use categories in Annex III, which have no pre-existing sectoral regulator. Because Article 43(3) ties conformity assessment to whichever legal regime governs the product, an Article 6(1) system is assessed by the sectoral notified body (extending its existing audit to cover AI-Act requirements), while an Article 6(2) system defaults to Annex VI self-assessment unless it falls under the biometric-identification category of Annex III point 1, where Annex VII notified-body assessment is mandatory only if the provider has not applied the relevant harmonised standards or common specifications; if it has, the provider may still choose Annex VI internal control.
2. SE = √(0.90 × 0.10 / 400) = √(0.09/400) = √0.000225 = 0.015. Observed proportion = 344/400 = 0.86. z = (0.86 − 0.90)/0.015 = −0.04/0.015 = −2.667. Since |−2.667| > 1.96, the drift is statistically significant at α = 0.05 (one-tailed p ≈ 0.0038, two-tailed p ≈ 0.0077) — this triggers the same Article 72 investigation duty as the retinopathy example, in a completely different Annex III domain.
3. The technical documentation required by Article 11, structured according to Annex IV — Article 72(3) specifies that the post-market monitoring plan forms part of this same documentation. It must therefore be drafted before conformity assessment, not after deployment; a provider cannot pass conformity assessment first and design its monitoring plan later.
4. False. The CE mark (Article 48) certifies conformity at the point of assessment; it does not suspend the Article 72 duty to monitor the system's real-world performance for the rest of its operational lifetime, nor the Article 73 duty to report serious incidents discovered through that monitoring. Non-compliance with either obligation is independently subject to Article 99 enforcement.
5. The z-score is unchanged: it was computed from the aggregate counts of the monitoring batch (460 correct out of 500), which describe overall model sensitivity and do not depend on the clinical outcome of any one missed case, so z stays at −4.564 regardless of what happened to that patient. Whether Article 3(49) is triggered is also unchanged — the harm already qualified as "serious harm to health" under 3(49)(a) before the change, and death still qualifies under the same clause, so a report is required either way. What does change is the deadline: Article 73(4)'s 10-day window for incidents involving death replaces the default 15-day window of Article 73(2). The conformity-assessment route is unaffected by any of this — Article 6(1) classification was fixed at the point the system was first placed on the market as a regulated medical device, and nothing that happens post-deployment reopens that classification decision.
6. Requiring a second, fully independent AI-Act certification for a product that is already subject to a rigorous sectoral safety regime would duplicate work the notified body is already doing — reviewing design documentation, testing protocols, and risk management — without adding regulatory value, and would slow deployment of systems (like diagnostic AI) where delay itself carries a cost to patients. Article 43(3) instead has the existing sectoral notified body absorb the additional AI-Act-specific checks (data governance, human oversight, post-market monitoring plan) into the assessment it was already required to perform, producing one certification that satisfies both regimes.
Think About It
Think about this: How would you explain eu ai act: europe's comprehensive ai regulation to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.
Key Takeaways — Summary and Recap
Let us recap what we covered: the core ideas behind eu ai act: europe's comprehensive ai regulation, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.