01
AI audits for GxP
Model lifecycle, training data, evaluation evidence, human oversight, drift, and AI embedded inside validated GxP systems.
Auditing
See beyond the checklist.
A useful audit explains what matters, why it matters, and how the evidence supports the conclusion — not simply whether a document was produced when asked for.
Perspective
The difference between an audit that changes something and an audit that files something is usually visible in the first hour. It comes from choosing the right samples, following the awkward thread instead of the prepared one, and being able to hold a technical conversation and a regulatory one in the same room. That last part is what most audits of AI and modern technology are missing.
Specialist services
Two questions define any audit.
What is being audited, and who is being audited or why. The subject pages carry the technical depth; the type pages carry the access, the dynamics, and what the report has to support afterwards. Start from whichever you already know.
What is audited
02
Technology & cloud audits
Infrastructure and cloud, GxP computerized systems, data flows and interfaces, and the technology services behind them.
Who is audited, and why
03
Internal audit & self-inspection
Independent examination of your own processes, systems, and quality system, with the objectivity an internal reporting line cannot always provide.
04
Supplier & vendor audits
Qualification, routine, and surveillance audits of software, cloud, AI, laboratory, CRO, and specialist service providers.
05
For-cause & due diligence
Event-triggered and transaction-driven audits: incidents, data-integrity signals, allegations, and pre-acquisition quality due diligence.
Both axes
Subject and type, and what each combination looks like.
These are not separate services to buy. They are the same engagement described from two directions, and most audits are specified by naming one cell of this grid.
| Internal | Supplier | For cause | |
|---|---|---|---|
| AI | Your AI register, risk tiering, and whether the oversight you designed is actually being performed. | The vendor’s model lifecycle, evaluation evidence, and whether they tell you when the model changes. | A model behaved unexpectedly — scope, cause, and impact on decisions already made on its output. |
| Technology | Your systems, environments, change control, and access as operated rather than as documented. | The provider’s development lifecycle, hosting, and where shared responsibility silently gaps. | After an outage, a data loss, or an integrity signal — what failed, and what it touched. |
Shared method
The discipline is the same whoever is across the table.
Subject changes what you look at. Type changes the access, the tone, and the constraints. Neither changes what makes an audit defensible — and that is where most audits are won or lost.
- Criteria fixed and stated in the plan, before the first record is requested
- Sampling that is deliberate and justified, not whatever was offered first
- Evidence examined at source, with demonstrations rather than descriptions
- Interviews that reach the people doing the work, not only those presenting it
- Findings graded on risk and evidence, so priority survives challenge from both sides
- Conclusions stated plainly, including where the evidence did not support one
- Corrective actions tested against cause, and closure verified rather than accepted
Choosing the audit
The trigger determines the type.
Choosing wrongly is the most common reason an audit produces little. A qualification audit run after an incident answers the wrong question; a for-cause audit run on a routine schedule finds nothing because nobody was looking for anything.
Before commitment
A new supplier, platform, or material scope change needs qualification before the activity begins. Establishes whether capability and control exist at all.
On a risk-based cycle
Routine and surveillance audits confirm a previously acceptable state has held, and that change since then has been controlled.
A specific question
A directed audit narrows scope to one process, system, study, or control, usually because an oversight question has become urgent.
An event
A data-integrity signal, serious incident, allegation, or pattern of deviations calls for a for-cause audit and an honest view of cause.
A transaction
An acquisition, a partnership, or a major contract needs quality and technical due diligence before the risk transfers.
Your own house
Self-inspection obligations, ISO internal audit requirements, or a need to test inspection readiness honestly rather than optimistically.
Delivery
On-site, remote, or hybrid — chosen deliberately.
Delivery mode is an audit design decision, not a logistics one. It changes what can be observed, what has to be requested, and how much preparation time the auditee has.
Direct observation of facilities, environments, and working behaviour. Best where culture, physical control, or unrehearsed access matters.
Efficient for document-heavy and system-based scope, with live screen-shared walkthroughs of configuration, logs, and audit trails.
Remote document review and preparation ahead of a shorter, sharper on-site visit spent only on what needs to be seen in person.
Approach
Context first. Evidence throughout.
A consistent sequence across the practice, scaled to the engagement in front of us.
- 01
Define the risk
Connect scope to the service, regulated process, data, and responsibilities actually involved — then resist scope drift.
- 02
Follow the evidence
Use interviews, records, live demonstrations, and traceable samples to understand how the process runs on an ordinary day.
- 03
Test the interfaces
Examine hand-offs, shared controls, subcontractors, and every place where accountability can quietly become nobody’s.
- 04
Report for action
Deliver conclusions that leaders and process owners can act on, with findings graded so priority is obvious.
Deliverables
What you receive.
A complete, defensible audit record — the documentation a sponsor, a client, or an inspector expects to see behind an oversight decision.
- An audit plan with scope, risk rationale, agenda, and evidence requests
- A written report with graded findings, context, and the basis for each conclusion
- A clear overall conclusion on suitability, with conditions where relevant
- Review and challenge of the auditee’s responses and corrective action plan
- Formal closure documentation once actions are verified as effective
Reference frameworks
The expectations behind the audit.
Audit criteria are drawn from the regulations and standards that apply to the activity being audited, and are stated in the audit plan before the audit begins. The frameworks below are among those most often relevant.
- ICH E6(R3)
- Sponsor oversight, risk-proportionate quality management, and computerized system expectations in clinical research.
- EMA guideline on computerised systems and electronic data in clinical trials
- Detailed European expectations for computerised systems, validation, audit trails, data integrity, cloud services, and service providers in trials.
- ISO 19011
- Auditing discipline: competence, independence, evidence, sampling, and reporting that holds up to challenge.
- EU GMP Chapter 7 & Annex 11
- Outsourced activities and computerized systems, where a manufacturing or product-quality context applies.
- 21 CFR Part 11
- Electronic records and signatures, audit trails, and the controls expected around regulated electronic evidence.
- ISO 9001 & ISO/IEC 27001
- Where the auditee relies on certification, used with a clear view of scope, applicability, and residual gaps.
These are examples, not a complete list. The frameworks and criteria that apply to a particular engagement are identified and agreed as part of defining its scope.
Start a conversation
Start with the decision in front of you.
A short discussion is usually enough to establish which of these services fits, and how much of it you actually need.