Compliance cannot be retrofitted

With the CRA, the obligation to provide evidence extends to the entire software industry: anyone who delivers a product must be able to demonstrate how it was developed and how it behaves. This has been standard practice in the pharmaceutical industry for decades. There, it is not the function of an application that determines its approval, but the documented proof of its behavior.

Validation is not a document, but an argument

Regulated environments do not know a "running" state, only a "validated" one. Anyone operating software in pharmaceutical manufacturing, quality control, or clinical development must demonstrate to regulatory authorities that a system operates reliably for its defined intended use. The foundations for this - EU GMP Annex 11, 21 CFR Part 11 - are older than most of the development tools in common use today.

The core of this guideline is familiar: "Computerized System Validation" implies a seamless chain from requirements through specification and testing to proof that the test actually ran. Requirements traceability, automated test suites, reproducible builds, and rigorous change control - that already accounts for the bulk of the work.

The difference between software and pharmaceutical documentation lies in their validity: documentation does not have to withstand the next sprint, but an inspection five years from now. The so-called "Good Automated Manufacturing Practice" (GAMP 5) has explicitly moved away from a checklist-based approach and places "critical thinking" at the center: the effort follows the risk, not the habit. This is an invitation to treat validation as an engineering task and not as a form.

Low-code shifts validation; it does not replace it

Hardly any other technology has spread as quickly in pharmaceutical companies as low-code. On the Microsoft Power Platform, applications for training records, deviation reports, or sample logistics are being built - processes that previously lived in Excel files and email threads. At first glance, this is a win: a documented workflow is superior to an undocumented spreadsheet in every respect.

The difficult question arises afterwards: what about an application that a business unit built in a single afternoon and that has been processing batch data for the past three months? The answer does not lie in the individual app, but in the platform as a whole: separate development, test, and production environments; managed environments; DLP policies for connectors; solution-based ALM with Azure DevOps or GitHub; plus a risk-based classification of which applications are actually GxP-relevant. The focus shifts from the app to governance.

Complying with regulations puts the central promise of low-code into perspective and is, at the same time, the prerequisite for enabling business units to actually develop applications on their own - within a framework that handles the documentation requirements rather than burdening each individual with them.

AI and the end of reproducibility

The real breaking point is artificial intelligence. Regulatory expectations rely on determinism: the same input, the same result, reproducible at any time. Generative models do not meet this criterion, and no configuration can fundamentally change that.

Four approaches are currently feasible: a narrowly defined intended use. Humans as the decision-making authority. Validation of the process rather than the model. And continuous monitoring rather than one-time qualification, including versioning of the model, prompt, context sources, and data basis.

It is remarkable how well the principle of data integrity - which originated in the pharmaceutical industry - holds up. ALCOA+ requires that data be attributable, legible, contemporaneous, original, and accurate - essentially a provenance model that anticipates today's debate on SBOMs and supply-chain traceability by decades. With AI-powered systems, attributability becomes the most challenging category: the audit trail must be able to distinguish whether an entry was made by a human or by a model. Those who try to introduce this distinction retroactively will no longer manage it cleanly.

Regulation as a design pattern

Regulated software development is no longer a special case, but a forerunner. The questions that have preoccupied pharmaceutical IT for years - traceability, assignment of responsibility, and robust evidence for systems that no one fully understands - are now reaching the entire industry. The most important lesson is unspectacular: traceability cannot be retrofitted. It is built into the architecture, or not at all.

This article touches on our work at the intersection of GxP compliance, data integrity, validation, and Power Platform.