August 2026: The EU AI Act is now Applicable, Making High-Risk Validation Mandatory

The conversation about AI in life sciences has been dominated for the past several years by innovative product launches. AI that summarizes clinical documents. AI that drafts first-pass regulatory text. AI that answers natural-language questions about study data. AI that flags data discrepancies before a human notices them. The demonstrations are often technically impressive, but something important is missing from most of them.

They do not show what happens after the prompt and reply, when the output must hold up in a regulated process.

The European Union AI Act is what turned that gap into a deadline. The Act entered into force on 1 August 2024. On 2 August 2026, most of its remaining provisions became applicable, including the Article 50 transparency obligations and the governance and enforcement powers of the AI Office and national authorities. For any organization whose AI outputs reach EU patients, EU sites, or EU citizens, the compliance clock is not approaching. It is running.

That registration matters even for a mostly American audience, since the life sciences ecosystem is not organized by geography. A US sponsor running a trial with EU sites has EU data subjects. A US manufacturer placing a device or IVD on the European market is subject to the Act as a provider. A US platform vendor whose model output is used in the EU falls within scope. Clinical research, regulatory submissions, safety reporting and pharmacovigilance are international by design, and EU citizens are very often stakeholders in them. The Act follows the activity, not the address.

One clarification worth stating plainly, because the term gets used loosely in this conversation. The Act classifies AI systems into four risk tiers:

• Unacceptable risk — prohibited outright. Nine practices, including social scoring, manipulative AI, and real-time remote biometric identification in public spaces.
• High-risk — the strict-obligations tier: risk management, data governance, logging, technical documentation, human oversight, robustness and accuracy.
• Limited risk — transparency obligations only. Disclosure when users interact with an AI system, and marking of AI-generated content.
• Minimal or no risk — no specific rules. Most AI systems in use today.

"High-risk" is a defined legal category, not a synonym for "important" or "sensitive." An AI system reaches it by one of two routes:

• Article 6(1) with Annex I — the system is a safety component of a product covered by EU harmonization legislation, or is such a product itself, and requires third-party conformity assessment. MDR and IVDR devices and in-vitro diagnostics fall here.
• Article 6(2) with Annex III — the system is stand-alone but operates in a listed sensitive area: employment and worker management, education, credit scoring, migration and border control, law enforcement, and the administration of justice.

Those two routes carry different obligations and, critically, different dates.

Two timelines, one regulatory shift: transparency obligations are live, while high-risk AI requirements move to later deadlines.

Infiligence has followed the Act's progression from its entry into force, through the phased application dates and the amendments that followed. That has produced one conclusion that shapes how the firm scopes work: the transparency obligations and the high-risk obligations are not the same problem, and only one of them can be met with documentation.

The transparency tier is, in the main, a disclosure and marking exercise — a real obligation with real penalties attached, but a bounded one. High-risk classification is a different kind of requirement. It attaches to the system's function inside a regulated process, and it triggers a specific set of controls: risk management, data governance, logging, technical documentation, human oversight, robustness and accuracy. None of those are tasks completed at the end of a build. They are properties of the system, and they must be designed, instrumented and evidenced while the system is being built.

That is the work Infiligence already does in regulated environments: validated cloud infrastructure, governance-driven delivery, and validated pipelines built against GAMP, 21 CFR Part 11 and SaMD expectations, with HIPAA, GDPR and SOC 2-aligned security as standing requirements rather than project add-ons. The Act's high-risk obligations do not describe an unfamiliar discipline to a team already working this way. They describe a familiar discipline applied to a new class of system — the AI system itself.

To see what that means in practice, follow a Head of Quality preparing to move an AI tool into a regulated workflow. They are required to show an inspector which data trained it, how it was tested against the cases that matter to her endpoints, what happens when the data or the model changes, and who stays accountable for its outputs. The chain must be reproducible if someone questions it at an audit six months from now. And it must fit the validation process her organization already runs, not add a parallel one around it.

A generic AI assistant cannot deliver that. Neither can a test suite bolted onto the end of a project. The gap, in most cases, lies in the scope of validation; and the EU AI Act has now given that gap a date and a legal consequence. The question is now is whether you can document what AI does and keep documenting it for the whole life of the system.

What AI Validation Must Actually Do?

Validation means that it must hold up under a high-risk regime rests on four requirements that go beyond raw technical capability.

1. Answer for a Defined Intended Use

A summarization assistant is not validated "in general." It is validated for the documents it will handle, the users who will rely on it, and the decisions it may inform. The same model used to draft an internal memo needs different evidence than one whose output can reach a clinical decision. The Act's risk-management and transparency requirements (Articles 9 and 13) make that boundary a documented fact, not an engineering preference. Clear boundaries also make testing meaningful: you cannot prove a system is fit for purpose if you have never closed what the purpose is.

2. Rest on Governed Data

AI is only as defendable as the information around it. Under Article 10, the training, validation, and testing data behind a high-risk system must be relevant, representative, and free of errors and bias. In practice that means knowing where each dataset came from, how it was labelled, who had access to it, and how sensitive information moves through the application, the model, and its APIs. Data governance is not the part of validation you do after the interesting work. It is the part an inspector reads first.

3. Trace It End to End

A regulator does not ask whether your AI was mostly right. They ask what was tested, what was observed, what was decided, and who signed off. Articles 11 and 12 make that evidence non-negotiable: technical documentation of intended purpose and design, and automatic logging that lets anyone reconstruct an output later. If a six-month-old validation decision cannot be reproduced from records, for a high-risk system it is now a compliance finding, not a paperwork gap.

4. Keep Proving It After Deployment

Models, data, prompts, integrations, and user behaviour all drift. Article 15 requires accuracy, robustness, and cybersecurity to hold across the lifecycle; Article 72 obliges post-market monitoring. Validation that ends at the go-live date is, in effect, no validation at all — for the regulators now watching, the only credible claim is one that keeps being earned. The corollary is change control: a model update that looks minor from the technology side can shift outputs, and the evidence that justified the original deployment must be reassessed before the new version counts.

The Regulatory Environment Is Moving Everywhere

Europe is not the only place asking these questions. On August 18, 2026, the FDA's Center for Devices and Radiological Health published a discussion paper on regulating generative AI-enabled medical devices, covering risk assessment, premarket evaluation, and postmarket monitoring. It is a discussion paper seeking stakeholder input rather than final guidance; but it is the same conversation the EU has already begun to make binding, with transparency obligations live and high-risk obligations landing in 2027 and 2028. Both regimes are circling the same question: how do you evaluate AI according to intended use, risk, and ongoing performance, and how do you keep proving it after the system is in the market?

That convergence is the useful signal. The exact text will differ, and the final FDA guidance is still some distance away. But the shape of the requirement is no longer in doubt. Risk-proportionate scrutiny, documented evidence of performance against intended use, and continuous postmarket monitoring are the direction of travel on both sides of the Atlantic. Teams waiting for certainty before they build the capability are waiting for something that will not arrive in a more convenient form than it is in now.

So, what should a team do now?

The instinct, understandably, is to wait for the dates to settle. The better answer is to work on the part that is already legible: the evidence chain. Whatever the final deadlines turn out to be, no regulator on either side is going to accept a validation record assembled retrospectively from screenshots and memory. That record must be a by-product of how the system is built.

That is what we call Validation by Design: validation treated as an engineering capability designed into the delivery lifecycle from the outset, rather than a gate applied at the end of it.

Practically, that means three things change. Requirements and risk classification are established before development begins, so the scope of validation is derived rather than negotiated. Evidence — test results, traceability, telemetry, change history — is generated automatically as work moves through CI/CD, so it accumulates continuously instead of being reconstructed under audit pressure. And validation is treated as a living state, not a one-time event, because a system whose model, data, or prompts can change is never permanently validated. Risk-proportionate effort is the organising principle throughout: a summarization agent and a safety component do not need the same depth of evidence, and pretending otherwise is how validation programs become both slow and unconvincing.

None of this is a reason to slow AI down. It is a reason to stop treating validation as a gate at the end of a project and start treating it as an engineering capability inside the delivery lifecycle — designed in, automated, and evidenced continuously. That is what turns a demonstration into a product that can legally ship, and what turns a barrier into a ticket to entry.

For organizations working this way, Infiligence builds validation into the AI delivery lifecycle rather than layering it on afterward — automated web, API, performance, security, and accessibility testing wired into CI/CD with telemetry and evidence collection, so the record a high-risk system now requires is produced continuously instead of reconstructed later.

Citations

1. Regulation (EU) 2024/1689, the AI Act in full
2. Consolidated AI Act text as amended, dated 27 July 2026
3. Regulation (EU) 2026/1744, the Digital Omnibus on AI
4. What the Omnibus moved and what it left alone
5. Annex III and Annex I deadlines in plain summary
6. Article 113(c), the provision that sets the deferred application dates
7. Article 5, prohibited practices
8. Article 5 deep dive, the eight prohibitions
9. Prohibited practices compliance guide
10. Harvard HUIT summary of prohibited use cases
11. Annex III, the Article 6(2) route
12. Annex I, the Article 6(1) route
13. High-risk classification reference
14. Classification guide, the eight Annex III areas
15. Article 9, risk management system
16. Article 10, data and data governance
17. Article 11, technical documentation
18. Annex IV, the minimum contents of that documentation
19. Article 12, automatic logging and traceability
20. Article 13, transparency and instructions for use
21. Article 15, accuracy, robustness and cybersecurity across the lifecycle
22. Article 72, post-market monitoring
23. Academic treatment of the Article 9 lifecycle obligation
24. FDA discussion paper page, 18 August 2026
25. FDA press announcement
26. The discussion paper itself, PDF
27. MedTech Dive on the three concepts in the paper
28. Axios on the competency-based approach
29. Maynard Nexsen legal read
30. Congenius summary
31. The paper's 26 stakeholder questions, analysed