Data & AI Governance for Health Tech: GDPR, AI Act Article 10, and What Comes Next

Last reviewed: 25 July 2026

Status (updated 25 July 2026), next review 1 October 2026 or immediately on any material development, whichever is sooner. This is one of Venitara's living pillars: the governance obligations it describes are moving targets, and this page is maintained accordingly rather than published once and left static.

If you are building a health AI product, you are not answering to one regulator. You are answering to three, simultaneously, out of the same underlying system: GDPR governs the personal data your product touches, MDR governs the device your product might be, and the EU AI Act governs the model sitting inside it. Most teams build governance for these one at a time, in whatever order a Notified Body meeting or a customer's procurement questionnaire happens to surface first. That approach produces duplicated work, gaps at the seams between regimes, and documentation that reads like three different projects stapled together. This guide sets out a different approach: one governance architecture, built once and evidenced three ways.

In short: Health AI products face three parallel regimes: GDPR governs the personal data (health data is special-category, usually requiring a DPIA), MDR governs the device, and the AI Act governs the model, including Article 10 data-governance duties for high-risk systems. One governance architecture can serve all three — built once, evidenced three ways.

A note on scope before you read further: this page explains how GDPR, MDR, and the AI Act interact from a governance-architecture standpoint. It is regulatory information intended to help you plan, not legal advice. Whether you need a DPIA, what your specific legal basis for processing should be, and how your Data Protection Officer role should be structured are determinations that depend on your product's exact data flows and should involve qualified counsel or a DPO before you rely on them.

On this page: Three regulators, one product · GDPR for device makers · AI Act Article 10 · Where MDR clinical evidence meets data governance · Logging, transparency, oversight in practice · The agentic frontier · A reference governance stack · FAQ

Three regulators, one product: the overlap map

Start with the structural fact that makes this pillar necessary: a single health AI product routinely triggers three separate legislative frameworks, each written by a different institutional process, each with its own vocabulary, its own enforcement body, and its own idea of what "compliant" looks like. None of the three was drafted with the other two open on the table. GDPR dates to 2016 (applicable from 2018); MDR to 2017 (applicable from 2021); the AI Act to 2024. They overlap because health AI happens to sit at the intersection of personal data, medical risk, and algorithmic decision-making. Nobody designed them to fit together.

The practical consequence is that founders often discover the third regime late. Teams that have already internalized "we need a technical file for MDR" are frequently surprised to learn that the AI Act imposes a parallel, only partially overlapping documentation duty, and that GDPR imposes a third parallel duty that predates both. The table below is the fast answer to "wait, which regulator cares about what, again?" Glance at it, then read the chapter that expands the row you need.

Three things are worth pulling out of that table before you move on. First, the "who checks it" column is not three separate audiences in practice. Your Notified Body increasingly asks GDPR-adjacent questions (data provenance, consent basis for training data) as part of MDR technical documentation review, even though a Notified Body has no formal GDPR enforcement role. Second, the artefacts overlap more than the regimes' separate legal texts suggest: your risk management file, your clinical evaluation report, and your data governance documentation all draw on the same underlying dataset and development history, described three different ways for three different readers. Third, timing differs sharply by regime. GDPR obligations are live today and have been since 2018, MDR obligations are live today for any device already on the market or seeking certification, and AI Act obligations phase in on the schedule covered in Chapter 3 — the newest regime is also the one where your compliance posture is most likely to still be under construction.

Companion asset — Three-Regime Evidence Mapping Table. The table above is also available as a standalone, ungated download: a working reference you can print or keep open next to your technical file as you build out each artefact, showing which underlying evidence (dataset documentation, risk analysis, clinical data, logs) satisfies which regime's specific ask. It is open access, no email required, because we think the fastest way to reduce duplicated governance work across founder teams is to make the mapping easy to find rather than gate it behind a form.

The rest of this guide expands each row of that table into an actual build plan: how to satisfy GDPR's special-category data rules (Chapter 2), how to satisfy Article 10 (Chapter 3), where MDR clinical evidence and data governance evidence genuinely meet rather than just sit near each other (Chapter 4), how to build the engineering-facing pieces — logging, transparency, human oversight — that all three regimes ask for in overlapping language (Chapter 5), how to think about the frontier where none of the three regimes has fully caught up yet — agentic AI (Chapter 6), and finally what an actual, named-components governance stack looks like for a real Series A health AI company (Chapter 7).

GDPR for device makers: legal basis, special-category data, and the DPIA question

GDPR is the oldest of the three regimes and the one most founders assume they already understand, because "GDPR compliance" has become a generic phrase covering everything from cookie banners to enterprise data processing agreements. Health AI, however, sits in one of GDPR's more demanding corners, and the generic version of GDPR compliance most startups build for a SaaS product is not sufficient here.

Legal basis. Every processing activity under GDPR needs a lawful basis under Article 6: consent, contract necessity, legal obligation, vital interests, public task, or legitimate interests. For a clinical or near-clinical health AI product, the basis is rarely a simple checkbox. Consent is the basis most founders reach for instinctively, because it feels the most defensible, but GDPR consent has a high bar: it must be freely given, specific, informed, and unambiguous, and it must be as easy to withdraw as to give. A product that would materially degrade or stop functioning if a user withdrew consent sits on shaky ground if consent is its only stated basis, because consent that cannot practically be withdrawn without severe consequence is not "freely given" in the sense the regulation intends. Many device makers rely instead on a combination of contract necessity (processing needed to deliver the service the user signed up for) and, for underlying research or model development activity distinct from direct care delivery, legitimate interests, balanced carefully against the individual's rights. Getting this determination right, and documenting the reasoning, is not a task to improvise internally. It is exactly the kind of question this page flags in its opening scope note as one to take to qualified counsel or a DPO, because the legal basis you choose shapes what rights and obligations attach to every downstream processing decision.

Article 9: special-category data. Health data is special-category data under GDPR Article 9, alongside categories like genetic data, biometric data used for identification, and data revealing racial or ethnic origin. Article 9 processing is prohibited by default, unless one of a specific, closed list of exceptions applies — explicit consent, necessity for healthcare provision under a professional secrecy obligation, substantial public interest, and several narrower grounds. This is a materially higher bar than Article 6 alone: a health AI product needs both a valid Article 6 legal basis and a valid Article 9 exception, layered together, before it may lawfully process the health data at the center of its function. Most clinical-facing products lean on the healthcare-provision exception (Article 9(2)(h)) or explicit consent (Article 9(2)(a)), each of which carries its own conditions — the healthcare-provision route generally requires the processing to be by or under the responsibility of a professional subject to confidentiality obligations, and explicit consent carries the same withdrawability concerns noted above, intensified because the data category is more sensitive.

When a DPIA is mandatory. A Data Protection Impact Assessment is GDPR's structured risk-assessment requirement for processing likely to result in high risk to individuals' rights and freedoms, and Article 35(3) specifically calls out large-scale processing of special-category data as a trigger. In practice, most health AI products that process patient-level health data at any meaningful scale — which is to say, most health AI products with real users — will need a DPIA, and many national supervisory authorities' published DPIA-trigger lists explicitly include health-data processing, profiling, and the use of new or innovative technology (AI models frequently qualify on this ground alone, independent of the health-data trigger). A DPIA is not a form you fill in once; it is a documented process: describe the processing and its purposes, assess necessity and proportionality, identify and assess risks to individuals, and set out the measures taken to address those risks, revisited whenever the processing changes materially — including, notably, when you retrain or materially update the underlying model, which is a trigger event some founder teams don't think to treat as a DPIA-revision moment. One downstream duty to know about: where a DPIA concludes that high residual risk remains despite mitigation, GDPR Article 36 requires prior consultation with the supervisory authority before the processing begins.

The DPIA is worth pausing on specifically because it is where GDPR and AI Act data governance overlap begins visibly. A well-built DPIA already asks many of the questions Article 10's data governance duty asks — is this data representative, could its use produce discriminatory outcomes, what are the risks to individuals — from a different angle and for a different legal reason. Chapter 3 picks this thread back up.

Again: whether your specific product needs a DPIA, and what legal basis and Article 9 exception combination fits your specific processing, are determinations this page cannot make for you. Treat this chapter as the map, not the territory — the actual determination belongs with your DPO or counsel, informed by exactly how your product handles data in practice.

What does AI Act Article 10 actually require for training data?

If GDPR asks whether you were lawfully allowed to process the data, Article 10 of the AI Act asks a different, narrower, upstream question: was the data you used to build the model any good, and did you check. This is the requirement with the least precedent in either GDPR or MDR, which is why it consistently surfaces as the single largest documentation gap for teams that started building their model before formal governance discipline was in place.

Article 10 requires that training, validation, and testing datasets for a high-risk AI system be subject to appropriate data governance and management practices, covering: the relevant design choices; data collection processes and the origin of data, and in the case of personal data, the original purpose of collection; relevant data preparation processing operations (annotation, labelling, cleaning, enrichment, aggregation); the formulation of assumptions, notably with respect to the information the data is supposed to measure or represent; an assessment of the availability, quantity, and suitability of the datasets needed; examination for possible biases likely to affect health, safety, or fundamental rights, or lead to discrimination, especially where outputs influence inputs for future operations; and appropriate measures to detect, prevent, and mitigate biases identified.

Two things separate Article 10 from anything GDPR or MDR already asked for. First, representativeness at the population level: Article 10 wants evidence that your training data reflects the population, geographic context, and behavioral or functional setting the system is intended to be used in. That is a stricter and more specific ask than MDR's general clinical evaluation, which asks whether the device works for its intended population but does not, historically, demand a dataset-composition analysis in this form. For health AI specifically, this is where classic failure modes live: models trained predominantly on data from one demographic group, one imaging equipment vendor, one care setting, or one geography, then deployed more broadly, are exactly the pattern Article 10's bias-examination requirement is designed to catch before deployment, before an adverse-outcome pattern emerges in the field.

Second, provenance as a documented chain, not a one-time note. Article 10 wants to know where the data came from, under what original purpose it was collected, and, for personal data specifically, whether that original collection purpose is compatible with its use in training your model. This is where Article 10 and GDPR's purpose-limitation principle (Article 5(1)(b)) directly intersect: data collected for direct clinical care has a different original purpose than data collected for research, and using the former to train a commercial product without revisiting that compatibility question is a governance gap that shows up under both regimes at once.

Applying the current timeline. Status (updated 25 July 2026): the Digital Omnibus package that postpones the AI Act's high-risk deadlines was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and enters into force on 27 July 2026 (the third day following publication). From entry into force, the deferred dates are the legally binding ones: general Annex III high-risk obligations from 2 December 2027, and Annex I / Article 6(1) obligations for Notified-Body-assessed medical devices from 2 August 2028. The original 2 August 2026 and 2 August 2027 dates are superseded — plan against the deferred dates. Article 10 sits inside the Article 6(1) medical-device bucket for most readers of this page, so 2 August 2028 is the working deadline for formal Article 10 conformity if your AI system is a medical device requiring Notified Body assessment. One converse worth stating plainly: a genuinely Class I self-declared SaMD, with no Notified Body involvement, is not automatically high-risk under Article 6(1) at all — if such a product is high-risk, it is via the separate Annex III use-case route, whose deadline (2 December 2027) differs from the medical-device route's, so a Class I team should map its own deadline against Annex III rather than Article 6(1). Article 4 (AI literacy) is unrelated to this timeline and has applied since 2 February 2025 — it is not a data-governance requirement specifically, but it is worth flagging here because teams working through Article 10 documentation sometimes assume every AI Act obligation shares the same deferred deadline, and Article 4 does not.

The extra runway to 2028 is real, but treat it the way our sibling AI Act content treats it: as a sequencing decision, not a deprioritization signal. Data governance evidence is dramatically cheaper to produce contemporaneously, as you collect, clean, and annotate training data, than to reconstruct retroactively from commit history, old spreadsheets, and institutional memory eighteen months from now. Notified Bodies are already asking AI-governance-adjacent questions inside ongoing MDR technical documentation reviews, ahead of the formal 2028 binding date. That means the practical deadline for having credible answers is sooner than the legal deadline for having a certified conformity assessment.

One track the Digital Omnibus does not touch: Article 50 transparency. Everything above (the 2 December 2027 and 2 August 2028 dates) describes the deferred high-risk track. Article 50's transparency obligations are a separate track entirely, and the Digital Omnibus does not defer them: providers and deployers still need to disclose that a user is interacting with an AI system, and label AI-generated or manipulated content (deepfakes and synthetic audio/video/text) as such, from 2 August 2026, on the original schedule. For a health AI product, this most often surfaces as a chatbot- or triage-assistant-facing disclosure duty. It runs in parallel with the Article 10/Article 6(1) work described above, not deferred alongside it, so it's worth tracking separately in your own deadline planning: don't let the "everything got pushed back" framing of this chapter get over-applied to a track that didn't move.

GPAI providers, briefly. If your product is built on a third-party foundation model instead of one you trained from scratch, note that general-purpose AI model provider obligations are phased, not a single flat date. They have applied since 2 August 2025 for GPAI models placed on the market on or after that date; models already on the market before 2 August 2025 have until 2 August 2027 to bring their documentation into compliance; and the European Commission's own enforcement powers over GPAI obligations only begin applying from 2 August 2026. This does not shift your own Article 10 duties as the device manufacturer: you still carry documentation obligations for how you fine-tuned, prompted, evaluated, or otherwise adapted the model for your specific intended clinical use. But it does mean your foundation model vendor now carries separate, parallel transparency obligations of their own, on a schedule that depends on when their model was placed on the market, which is worth knowing when you evaluate what documentation a vendor should be able to hand you. If you want to verify these phased dates directly, check the European Commission's own GPAI guidelines and the AI Act's transitional provisions (Articles 111 and 113), which set out the placed-on-market cutoff and the compliance and enforcement dates in full.

The table below collects every date from this chapter in one place, so you don't have to re-read two paragraphs of prose each time you need to check one.

One pending-change flag for the MDR/AI-Act interface this guide architects. In December 2025 the European Commission published a proposal to simplify the MDR and IVDR (COM(2025) 1023, procedure 2025/0404(COD)). Among other things it would move much stand-alone software toward Class I self-declaration under a risk-based Rule 11, and it would move AI devices from the AI Act's Annex I "Section A" to "Section B" — so the AI Act would apply only as specified in the MDR/IVDR sectoral provisions, reshaping when and how the AI Act binds via MDR. It is a proposal, not law — adoption is realistically ~2027 at the earliest — so plan against the current rules while factoring the possible change into longer-term strategy.

For evaluating whether a foundation-model vendor's documentation actually meets what you need, Chapter 6's vendor-evaluation checklist covers what to ask for — worth a look now if vendor dependency is your main concern, rather than waiting until you reach that chapter. When Medical Device AI Becomes High-Risk and sibling pillar, the EU AI Act for medical devices, cover the full high-risk obligation set (Articles 9–15) and the complete deadline picture in depth — this chapter deliberately stays inside the data-governance lane rather than re-walking that ground, since that is the AI Act's own comprehensive treatment elsewhere on this site. For how Article 10 sits alongside the rest of the AI Act inside a single MDR-integrated conformity assessment, One Notified Body for MDR and the AI Act walks through the mechanics of the combined Notified Body review.

Where do MDR clinical evidence and data governance actually meet?

MDR's clinical evaluation and the AI Act's data governance duty are often treated as separate workstreams run by separate people. A clinical affairs lead builds the clinical evaluation report; an engineering or data science lead builds the data governance file. That separation is exactly where duplicated work and inconsistent evidence creep in. They meet at a specific, identifiable point: both are, at bottom, asking whether your evidence base actually represents the population and conditions your device will be used in.

MDR's clinical evaluation asks whether your device is safe and performs as intended, for its stated intended purpose and population, based on clinical data generated through clinical investigation, literature, or clinical experience with equivalent devices. The AI Act's Article 10 asks a narrower, upstream question about the specific dataset that trained the model: was it relevant, sufficiently representative, and free of examinable bias for that same intended population. When these two evidence bases are built by disconnected teams working from disconnected requirement lists, you end up with a clinical evaluation report that describes one population and a data governance file that documents a training dataset drawn from a subtly different one. That's a gap a Notified Body reviewer is well positioned to notice, because reconciling exactly this kind of inconsistency is a core part of what technical documentation review is for.

The practical integration point is your intended purpose statement. A precisely written intended purpose (the clinical indication, the patient population, the care setting, the intended user) should drive both your clinical evaluation strategy and your training data representativeness assessment from the same document, so that "does my clinical evidence support this population" and "does my training data represent this population" are answered against an identical reference point instead of two independently drifting descriptions. Teams that write their intended purpose once, early, and treat it as the shared anchor for clinical evaluation, risk management, and data governance consistently produce more coherent technical files, and move faster through Notified Body review, than teams where each function derived its own working definition of the same product.

The second integration point is bias examination feeding clinical risk analysis. Article 10's bias-examination requirement and MDR's risk management process (ISO 14971) ask structurally similar questions from different starting points: Article 10 asks whether the data could produce systematically worse outcomes for a subgroup; ISO 14971 asks what could go wrong and how severe and probable it is. A dataset-representativeness gap identified during Article 10 work is a hazard, in ISO 14971 terms, and should flow into your risk management file as one. It shouldn't sit isolated in a separate data governance annex that the clinical risk team never reads. Building an MDR Technical File and CER covers the MDR-side mechanics of this in depth; the synthesis point for this pillar is that the clinical evaluation and data governance workstreams should share an intended-purpose anchor and a joint risk register from the start, not be reconciled retrospectively before submission.

Where this becomes urgent in practice is post-market. Both regimes ask you to keep watching after launch: MDR's post-market surveillance and clinical follow-up, and the AI Act's post-market monitoring obligation, which extends the same underlying question (is this still safe and performing as claimed) with an AI-specific lens on model drift and performance degradation. A single post-market monitoring process, tracking both clinical outcomes and model performance metrics against the same population baseline, is materially more efficient to run and more convincing to a reviewer than two parallel monitoring processes that happen to look at overlapping data.

Talk to someone about where your specific clinical evidence and data governance work should meet. Every product's intended purpose, population, and data history are different, and the right integration point for your technical file depends on specifics a general guide cannot fully anticipate. Book an expert conversation →

How do you actually build logging, transparency, and human oversight?

The first four chapters were mostly about what to document and why. This one is about what to build. Logging (AI Act Article 12), transparency and instructions for use (Article 13), and human oversight (Article 14) are the three AI Act requirements that are, in practice, primarily engineering decisions rather than paperwork exercises. They're also the three most often bolted on late, right before a submission, in a way that is visibly retrofitted rather than designed in.

Logging, designed in from the start. Article 12 requires automatic recording of events across the AI system's operation, sufficient to enable traceability and support post-market monitoring. In practice this means every inference the model makes in production should be logged with enough context to reconstruct what the system was shown, what it output, and (where relevant) what downstream action or recommendation followed, without logging so much raw clinical data that you create a second, unmanaged special-category-data processing problem under GDPR in the course of solving your AI Act logging problem. The architecture question to settle early is what gets logged versus what gets referenced: storing a pointer to the input record in your primary clinical data store, instead of duplicating the full input into a separate log store, is often the better design both for AI Act traceability and for keeping your GDPR data-minimization posture intact. Retention period for logs is a second design decision worth making deliberately rather than defaulting to "forever." Article 12 asks for logs sufficient to support traceability and post-market monitoring, not indefinite retention, and GDPR's storage-limitation principle pulls in the same direction. For agentic or multi-step systems specifically, log the intermediate steps and tool calls, not just the final output. Chapter 6 returns to why this matters more, not less, as autonomy increases.

Transparency, written for the professional user who actually reads it. Article 13 requires instructions for use that let a professional user understand the system's capabilities, limitations, tested accuracy, and the circumstances that could affect its performance. The failure mode to avoid is transparency content written to satisfy a reviewer's checklist instead of actually informing a clinician's judgment in the moment they are relying on the output. Accuracy figures reported without the test conditions that produced them, limitations buried in boilerplate rather than surfaced at the point of use: these are technically present but not functionally transparent. Building this content alongside your clinical evaluation, instead of as a late-stage documentation task handed to whoever is free, keeps it grounded in the same evidence base the rest of your file uses.

Human oversight, designed at genuine decision points. Article 14 requires that a natural person be able to understand the system's output, monitor its operation, and intervene or override it. The design mistake we see most often is treating "a human sees the output before it's used" as sufficient regardless of where in the workflow that human sits. Meaningful oversight means identifying the actual clinical decision points in your product's workflow, not just the start or the end of a process, and designing the interface and the escalation path around those points specifically, then documenting why those points were chosen. This is materially harder, and materially more important, for multi-step or agentic workflows, where a human "reviewing the final output" of a chain of intermediate autonomous actions is not the same as genuine oversight of each consequential step.

Cybersecurity and robustness as the fourth leg. Article 15 sits alongside these three and is worth a brief mention here because it is frequently under-resourced relative to its actual weight in a Notified Body review: accuracy, robustness, and cybersecurity testing, documented at a level appropriate to the system's intended purpose. For health AI specifically, robustness testing should include adversarial and edge-case input testing relevant to your actual deployment environment (image quality variation, missing or malformed input data, unusual patient presentations), not just standard-conditions accuracy testing. A system that performs well on curated test data but degrades ungracefully on messy real-world input has a robustness gap this Article is specifically designed to catch before it becomes a field incident.

The unifying engineering principle across all four requirements: build the capability into the architecture during development, not into the documentation during submission preparation. A logging system retrofitted six weeks before a Notified Body meeting is visibly different, in both quality and cost, from one designed alongside the product from the start.

How do you govern agentic AI before regulators have caught up?

Every chapter so far has described governance for systems regulators built their frameworks around: a model with a defined input, a defined process, a defined output, validated once and then controlled through a documented change process. Agentic AI — systems that take multi-step autonomous action toward a goal, call external tools, and can shift behavior when an underlying foundation model provider updates something upstream — breaks that mental model in ways neither GDPR, MDR, nor the AI Act was written to answer directly. This is genuinely the frontier of health AI governance, and it deserves an honest treatment rather than a confident-sounding one.

Our dedicated spoke on this topic, Agentic AI Governance in Healthcare, lays out the full picture: no regulator has published agent-specific rules for healthcare AI as of this review. Agentic systems are, in the meantime, assessed under the same tests as any other software. If the agent has a medical purpose, it is a medical device under MDR regardless of its architecture, and if that device requires Notified Body assessment, Article 6(1) makes it automatically high-risk under the AI Act, the same as a static model. Three properties make satisfying the intent of those existing rules genuinely harder for agents than for fixed-function systems: autonomy (multi-step action with less per-step human intervention), tool use (the agent's behavior depends on systems that may not have been validated as part of the same submission), and continuous change (behavior can shift when an underlying foundation model updates, without the deploying organization controlling that change in the traditional sense). The spoke identifies three genuinely open questions with no settled regulatory answer as of this review: change control when a dependency changes underneath you, what meaningful human oversight means across a multi-step autonomous process instead of a single recommendation, and how liability allocates across a multi-vendor, multi-model chain when something goes wrong.

That article is written from the compliance-strategy angle — what existing frameworks require and where they strain. This pillar's job is different: what does the data and AI governance architecture specifically need to do differently for an agentic system, given everything the first five chapters of this page just walked through?

Data governance (Article 10) for an agent is a moving target, not a snapshot. Article 10's representativeness and bias-examination duties were written with a model that is trained, validated, and then relatively fixed in mind. An agent's behavior depends on an orchestration layer you built plus one or more underlying models you may not control, updated on someone else's schedule. That means your data governance file cannot be a one-time artifact: it needs a defined re-evaluation trigger tied to detected or notified changes in any dependency, not just to your own release cycle. Practically, this means treating "the vendor changed the underlying model" as a data-governance re-review event with the same seriousness as "we retrained on new data," even though only one of those is something you initiated.

GDPR data minimization gets harder, not easier, with tool-calling architectures. An agent that can call external tools or query additional systems as part of reasoning toward an output creates data flows that are difficult to fully enumerate in advance. That's in tension with GDPR's purpose-limitation and data-minimization principles, which assume you can describe, ahead of time, what data will be processed for what purpose. The governance-architecture answer is to define and document the agent's permitted data-access bounds explicitly (which systems it can query, what categories of data it can retrieve, under what conditions) as a design artifact before deployment, essentially a data processing boundary specification, instead of discovering the actual data flows retrospectively by inspecting logs after the fact.

Logging has to capture the chain, not just the endpoints. Chapter 5 already flagged this, but it is worth restating specifically here because it is the single most concrete, buildable governance control available for agentic systems today: log intermediate reasoning steps and tool calls, not only final outputs. This serves Article 12 traceability, supports the human-oversight analysis Article 14 requires (you cannot document that oversight was meaningful at each decision point if you cannot reconstruct what those decision points were), and gives you the forensic capability an incident review or liability question will need. Our agentic spoke identifies that need as currently unresolved by any existing liability framework.

Vendor governance becomes a core data governance activity, not an adjacent procurement task. Most teams building agentic health AI products are orchestrating third-party models instead of training their own, which means a meaningful share of your Article 10 evidence base depends on a vendor relationship you do not fully control. The agentic spoke's vendor-evaluation checklist covers model versioning, change notification, evidence for your specific intended use, fallback behavior, and contractual liability clarity. From this pillar's governance-architecture angle, it functions as an extension of your data governance program: vendor documentation should sit inside the same governance file structure as your own internally-produced Article 10 evidence, reviewed on the same cadence, not filed separately as a procurement artifact nobody in data governance ever reads.

None of this converts agentic AI into a solved governance problem. It isn't one, and this pillar is not going to claim otherwise. What it does is extend the same architecture principle running through this whole page (build once, evidence for multiple regimes, design the engineering in from the start instead of retrofitting documentation later) to the case where the underlying system is actively harder to pin down. Read Agentic AI Governance in Healthcare for the complete open-questions treatment, the vendor checklist in its original standalone-checklist form, and how FDA's predetermined change control plan thinking offers a partial, non-binding template for agentic change management.

What does a reference governance stack look like for a Series A health AI company?

Everything above is a set of requirements and design principles. This chapter turns it into something closer to an org chart and an artifact list: what a real Series A health AI company's governance stack looks like once the three regimes have actually been built into one architecture instead of three.

The premise worth stating plainly: at Series A, you rarely have a dedicated headcount for each regulatory function. The stack below assumes one or two people wearing multiple governance hats, with named artifacts and clear ownership, rather than assuming a large in-house regulatory affairs department you likely don't have yet.

Two observations about this stack worth naming directly. First, notice how few rows serve only one regime. Most artifacts are shared infrastructure, evidenced three ways, which is the entire thesis of this pillar made concrete. Second, notice that the ownership column rarely names a role that exists as a full-time hire this early; the practical reality at Series A is a founder or a small regulatory/quality lead wearing several of these hats simultaneously, often with a fractional DPO and external regulatory counsel filling the rest. The stack does not require you to have built a large team before you have built the governance. It requires you to have named, for each artifact, who is accountable for it existing and staying current, even if that person also does three other jobs.

Every artifact in this table gets easier to build correctly, and cheaper to build early, than to reconstruct later. That is true of data governance documentation specifically (Chapter 3), and it is true of this entire stack generally — the teams that build governance architecture alongside product development consistently move faster through Notified Body review than the teams that treat it as a pre-submission scramble.

Frequently Asked Questions

We're pre-revenue and haven't touched real patient data yet. Do we need any of this now? Some of it, yes, even before you have real users. If you are training or fine-tuning on any dataset containing real health data, Article 10 documentation and GDPR's legal-basis and purpose-compatibility questions apply from that point, not from your first paying customer. If you are working entirely with synthetic or fully anonymized data during early development, your GDPR exposure is lower (properly anonymized data falls outside GDPR's scope, though anonymization to that legal standard is a higher bar than most teams initially assume), but Article 10's data governance duty still expects documentation of your dataset's provenance and representativeness once you move toward a real intended use. Start the documentation habit early regardless. It is far cheaper to build as you go than to reconstruct.

Do we need a DPO? GDPR requires a formally designated DPO in specific circumstances — including where your core activities involve large-scale processing of special-category data, which many health AI products meet. Whether your specific product crosses that threshold is exactly the kind of determination this page flags as one for counsel or a fractional DPO to assess against your actual data volumes and processing activities, not a generic yes/no this guide can give you. Many Series A companies engage a fractional or external DPO rather than a full-time hire, which satisfies the requirement while matching team size.

Our model is built entirely on a third-party foundation model API. Do we still have Article 10 obligations? Yes. Building on a third-party model does not transfer your data governance obligations to the model provider. You still carry documentation duties for how you fine-tuned, prompted, evaluated, or otherwise adapted the model for your specific clinical intended use, including representativeness and bias examination relevant to your population. The provider's general-purpose benchmarks, even where their own GPAI transparency obligations apply, were very likely not built around your specific patient population or clinical claim.

How does a DPIA relate to the AI Act's risk management requirement — are they the same document? No, but they should be built from a shared risk-identification process rather than independently. A DPIA is a GDPR-specific assessment of risk to individuals' data protection rights; the AI Act's Article 9 risk management system (extending your ISO 14971 file) is a broader safety-and-fundamental-rights risk process. They ask overlapping questions — could this processing or this system produce harmful or discriminatory outcomes — from different legal starting points. Building them as two connected outputs of one underlying risk analysis, rather than two teams working from two separate requirement lists, is the efficient version of compliance with both.

What actually changes for our governance stack once the AI Act's Article 6(1) deadline hits (2 August 2028, under the Digital Omnibus deferral in force from 27 July 2026)? Formally, that is when Article 6(1) high-risk obligations become binding for Notified-Body-assessed medical devices, meaning your AI Act conformity becomes a checked, certified part of your MDR assessment rather than a voluntarily-built-ahead-of-time posture. Practically, if you have been building the governance stack this page describes contemporaneously, the deadline changes your certification status more than it changes your day-to-day governance work — the artifacts should already exist. Teams that wait to start building until close to the deadline face a materially harder, more expensive reconstruction exercise than teams building throughout the runway the Digital Omnibus deferral provides.

Is there a single person we should hire first to own all of this? Not typically at Series A, and we would be skeptical of any generic advice claiming otherwise. The honest answer depends on your team's existing composition and your product's specific risk profile. Most companies at this stage are better served by a regulatory/quality lead who can own the integration across the three regimes (the connective tissue this whole pillar describes) plus fractional or external specialist support for DPO functions and Notified Body-facing MDR work, instead of one generalist hire expected to be simultaneously expert in GDPR, MDR, and AI Act detail. A working conversation about your specific team and product is a more useful next step than a generic hiring rule.

---

Talk to someone about building this governance architecture for your specific product. This pillar maps the territory; the right sequencing and depth for your team depends on your product's data flows, clinical claims, and current stage — questions better worked through directly than answered generically on a guide page. Book an expert conversation →

Where next: Agentic AI Governance in Healthcare · When Medical Device AI Becomes High-Risk · One Notified Body for MDR and the AI Act · Building an MDR Technical File and CER · Two Routes to High-Risk AI in Healthcare

For the complete EU AI Act treatment (full deadline picture, all high-risk obligations, and the automatic Article 6(1) rule in depth), see the sibling pillar, the EU AI Act founder's handbook. This page deliberately stays inside the data-and-AI-governance lane instead of duplicating that ground.

This page carries a dated status line, prominently near the top and again here, because both the AI Act's timeline and agentic AI governance practice are under active development. Status (updated 25 July 2026): the Digital Omnibus package that postpones the AI Act's high-risk deadlines was published in the Official Journal on 24 July 2026 and enters into force on 27 July 2026 — from entry into force, the deferred dates (Annex III 2 December 2027; Annex I/Article 6(1) medical devices 2 August 2028) are the legally binding ones, and the original 2 August 2026 and 2 August 2027 dates are superseded; plan against the deferred dates. Article 4 AI literacy has applied since 2 February 2025 and is unaffected by the Omnibus; no regulator has yet published agentic-AI-specific rules for healthcare. Next review 1 October 2026, or immediately on any material regulatory development affecting agentic AI governance, whichever comes first.