AI Assurance & Validation

Evidence that an AI system does what you say it does, and keeps doing it.

Why Validation Carries the Weight Here

In classical software, verification does most of the work: there is a specification, and you check the system against it. A trained model has no such specification. What it does is a property of its data, its objective and the conditions it runs in — so the burden shifts to validation. Does this system behave as intended, on the distribution it will actually meet, inside the boundary someone drew for it?

That is also what the regulation now asks for. Under the EU AI Act, performance is not the deliverable. Traceability, human oversight and a record that can explain a decision are.

What the Work Actually Is
Four activities across the life of a model, from before it is deployed to long after it has changed.
+Operational design domain and intended use

The boundary stated explicitly: what the system is for, what it is not for, and what is supposed to happen at the edge of it. Most AI failures are boundary failures.

+Data and model validation

Training and evaluation data examined for provenance, representativeness and leakage. Performance measured on the distribution the system will meet, not the one it was built on.

+Human oversight, tested

Whether the person who is meant to be able to intervene can actually do so — in the time available, with the information the interface puts in front of them.

+Continuous validation after release

Drift detection, retraining gates and the evidence trail that keeps a conformity claim true after the model has changed.

The Rules This Work Is Measured Against

AI assurance sits at the point where a new regulation meets the product rules that were already there.

+ EU AI Act

Regulation (EU) 2024/1689. For high-risk systems: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness.

+ AI inside regulated products

The AI Act and the product regulation applying at the same time — the MDR for medical devices, ISO/PAS 8800 and ISO 21448 for road vehicles.

+ Assurance and lifecycle

IEEE 1012 for verification and validation and ISO/IEC/IEEE 29119 for testing, applied to systems whose behavior is learned rather than specified.

+ Security of the model and its pipeline

The model treated as part of the attack surface: data poisoning, model extraction, and prompt and tool abuse where agents can act.

Where This Applies
Four of the six sectors we serve, where independent verification is either a regulatory requirement or the only way to know.
What the Team Has Worked On

Described by what the systems had to do, rather than by client name.

Models in regulated decisions

Systems whose output affects a person — credit, pricing, triage — where the decision has to be explainable to the person it was made about.

Agentic systems in production

Agents with the ability to act, assessed for what they can reach, what they can change, and what stops them.

MLOps under supervision

Pipelines built and run in environments where a regulator is part of the audience, not an afterthought.

Standards work

Contributions to the international standards this discipline is now being measured against.

The authority decides on evidence
not on effort.
Tell us the platform, the assurance level and who has to accept it. We will tell you where the argument is thin.