AI is changing how life sciences companies work. It supports documentation, answers questions about standard operating procedures (SOPs), and increasingly acts as an agent inside business processes. In regulated environments, this raises a question that many organisations are only starting to answer: how do you qualify an AI application that keeps changing?
Author: Florian Kattner
Traditional computer system qualification assumes that a validated system remains in a known state. Changes are rare, controlled, and easy to trace.
AI applications behave differently. Models are updated, prompts are refined, knowledge sources grow, connected services change, and permissions shift. Each of these changes can affect how the application behaves, often without any visible change to the user interface.
For life sciences companies, this means that a one-time assessment is not enough. The key question is: how can an assessment remain reliable when the environment around the application evolves?
Cloud providers and SAP can show that their services are available and operate within their responsibilities. That is important, but it does not answer the GxP question.
It does not show whether the complete AI application behaves as intended in a specific regulated process. To close that gap, organisations need to connect:
the intended use of the application,
the model and its version,
prompts, instructions, and approved knowledge sources,
the technical services involved,
and the operational evidence that shows how the system performs over time.
Once these elements are assessed together, the accountable roles can make a traceable qualification or release decision. This is the assurance gap we see today. Established qualification practice covers services and technical components well. AI adds new questions:
Does the agent actually do what it was intended to do?
How reliable and reproducible is the behaviour of the model?
How are prompts, model versions, and parameters controlled?
How can a change to a model, prompt, or agent be assessed in a traceable way?
One conceivable way to address this is to treat AI-supported GxP processes as something that must be assessed systematically throughout their lifecycle. This is a line of reasoning, not a finished method. The focus is not only on the model. It is on the interaction between intended use, model, instructions, approved knowledge, technical services, and human responsibility.
We call the object under assessment the AI Composite. It includes the intended use, the model, prompts, knowledge sources, retrieval configuration, tools and APIs, permissions, guardrails, and test cases. The AI Composite is the unit of assurance. When something changes, we can see which part of the composite is affected, assess the impact, and define the right level of re-verification.
Assurance is not a single event. It is an operating model that continues after release: changes are assessed by risk, test results are documented, and operational signals such as deviations, complaints, or drift are reviewed.
Our approach looks at AI applications on three connected levels:
Service level: The technical qualification of the SAP Business Technology Platform and AI services that the application uses. This builds on established qualification practice.
Model level: The assessment of the AI model or large language model: its characteristics, versions, and relevant risks.
Use case and agent level: The concrete agent, its prompts, and its behaviour within a specific business process. Here, the question is whether the application performs as intended in its actual context.
These three levels are brought together in one integrated view. This makes it possible to assess changes consistently and to derive targeted tests from the intended use.
We see three reasons to think about AI assurance in this way. First, the assurance question cannot be answered at the level of the model alone, because the behaviour of an application emerges from the interplay of all its components. Second, existing qualification logic is a sound starting point, but it needs to be extended to cover change and behaviour, not only the state of a system at one point in time. Third, the discussion about which evidence, which tests, and which decision criteria are meaningful in GxP work is still open, and a shared understanding has to come before any common practice can emerge.
For this reason, we want to discuss the approach openly with people who carry responsibility for quality, regulatory, and IT decisions before anyone commits to a particular answer.
AI assurance is not a problem that one company can solve in isolation. Our role, as we see it, is to contribute to the discussion: to test our reasoning against the experience of people who work in GxP every day, and to share what we learn along the way.
That is why we are opening the discussion now. Whether you are in regulatory affairs, quality assurance, computer system validation, IT, or responsible for a specific AI use case, the questions you face today are exactly the ones we want to understand.
You do not need a finished AI use case to start. If you are unsure how to qualify an AI application, how to handle changes, or what evidence your organisation will need, we would welcome a conversation.
The exchange is informal. It can be the start of a shared discussion on how AI assurance should be approached in practice.
Start a conversation with us about AI assurance in your GxP processes.