What AI Model Testing Proves

You can run every test on the list and still ship a system nobody has properly checked. That happens when AI model testing is treated as one activity with one pass mark, rather than a set of separate questions that each prove something narrow. The AIGP exam pushes on exactly that seam. It asks which test answers the question in front of you, and the tempting wrong answer is usually a real test pointed somewhere else.

The Body of Knowledge, the blueprint the IAPP publishes to set out what the exam covers, puts training and testing in Domain III, next to data governance and documentation. The placement is deliberate.

AI model testing is not one activity

An AI model testing regime runs from unit tests up through integration, validation, performance, security, bias and interpretability. Each has a different subject. Unit and integration testing ask whether the software works. Model testing asks whether the model works, which is separate and harder.

Validation and performance ask different questions

Validation asks whether the model does what you specified on data it has not seen. Performance asks whether it holds that standard under the load, latency and data volumes of the actual deployment. A model can validate cleanly on a curated hold-out set and degrade in production, because the live input distribution never resembled the test set. If a question hands you a system that passed its checks and failed on release, look for a performance problem dressed as a validation answer.

Security testing is not bias testing

Security testing asks whether someone can make the model behave badly on purpose. Bias testing asks whether it already behaves badly on its own, across groups you have a legal reason to care about. They use different methods, different data and different people. A red-team exercise that finds no prompt injection tells you nothing about disparate outcomes, and a fairness audit that clears the model tells you nothing about data poisoning.

What AI model testing proves, and what it does not

Every test proves a bounded claim, and the boundary is where the marks are. Validation proves the model met a threshold on a specific dataset at a specific moment. It does not prove the threshold was the right one. Bias testing proves the model showed no measured disparity on the attributes you measured. It does not prove there is no disparity on an attribute you never collected, the position anyone testing for indirect discrimination ends up in.

Interpretability testing is the one candidates misread most often. It tells you something about how the model reaches an output. It does not hand you an explanation the affected person can use. That gap is the subject of explainability against interpretability, and it returns in the exam because the two words are used loosely everywhere else.

Test against thresholds you set first

Article 9 of the Artificial Intelligence Act requires high-risk systems to be tested to identify the most appropriate and targeted risk management measures, and requires testing against prior defined metrics and probabilistic thresholds appropriate to the intended purpose. The word doing the work is "prior". A threshold chosen after you have seen the result is not a threshold; it is a rationalisation.

Article 15 requires an appropriate level of accuracy, robustness and cybersecurity, with the accuracy metrics declared in the instructions for use. Article 10 requires training data to be examined for biases likely to affect health and safety, harm fundamental rights or lead to discrimination, then requires measures to detect, prevent and mitigate what that examination finds. Read the three together and the shape of AI model testing under the regulation is plain: set the measure, run the test, declare the number, act on what it shows.

The NIST AI Risk Management Framework arranges the same model testing work under its Measure function, and ISO/IEC 42001 places it inside a management system with defined records. Different vocabulary, same demand.

Reading a model testing question

Candidates lose marks by choosing the most thorough-sounding option rather than the one the scenario asks for. A stem about a model producing confident nonsense on inputs outside its training range is a robustness question, not a bias question, however much the bias option flatters your instincts. A stem about a vendor refusing to share its test set is a data governance question. Read the failure described, then name the test that would have caught it.

When a test finds something you cannot fix

AI model testing has a second half that study notes tend to drop: managing the issues and risks the testing surfaces. Finding a problem creates a decision, and it is rarely technical. You can retrain, restrict the intended purpose, add human review at the point of harm, or decline to release. Doing nothing and logging it is also a decision, and it reads worst in an audit.

What you find here reopens design risk decisions you thought were closed, and it sets the evidence you will need at release readiness. A test result nobody acted on is worse than no test, because now you have a record showing you knew.

The exam rewards the candidate who can say what a given test proves in one sentence, without reaching for the word comprehensive.

A free reference card goes with this one: six tests, what each proves, and where that proof stops. It is attached to this week's post in the AIGP study group. More study material is at 22academy.com/study.