What it means
- Before any AI system goes live (or a vendor model is switched on), test that it does what it should, at the accuracy you need, without unacceptable side effects.
- Set acceptance criteria up front: accuracy, error rates, latency, fairness thresholds, safety checks, hallucination rate for GenAI.
- Test on data the model has not seen, including edge cases, Indian languages and formats, and realistic misuse.
- Release only after documented sign-off against the criteria.
Why it matters
- RBI FREE-AI expects all models, built or bought, to be validated before and during use.
- MeitY's 2024 advisory says under-tested or unreliable models must be labelled as such before being offered to users.
- The 2026 IT Rules expect platforms to use technical tools to check synthetic content declarations; those tools need testing too.
Checklist
- Write acceptance criteria for each system based on its tier and use.
- Build a holdout test set that reflects real users, including edge cases and regional variety.
- Run functional, performance, fairness (SC-AI-017 Fairness and discrimination testing of outputs) and security or misuse (SC-AI-018 Robustness and adversarial testing (red teaming)) tests as the tier requires.
- For GenAI: test with a fixed prompt set covering accuracy, refusal of harmful requests, data leakage and tone.
- For vendor models: run your own tests on your use case, do not rely only on vendor benchmarks.
- Keep test and production environments separate; mask personal data in test sets.
- Record results and get go-live sign-off from the owner (and validator for high risk).
- If testing is incomplete, label the feature as beta or unreliable to users.
Evidence examples
- Test plan and acceptance criteria for the KYC document-reading model.
- Test results report with metrics against thresholds and pass or fail.
- GenAI evaluation run output (prompt set, scores, failures reviewed).
- Go-live approval record in the change ticket.
- Screenshot of beta or "may be inaccurate" label for a feature released with known limits.
Common pitfalls
- Testing on the same data used for training.
- Accepting vendor benchmark numbers without testing on your own data.
- No written thresholds, so "good enough" is decided after seeing results.
- Skipping retesting for a "small" prompt or configuration change.
Satisfies
- VoluntaryISO/IEC 42001
- BindingEU AI Act
- SupervisoryPRA SS1/23
- VoluntaryNIST AI RMF and GenAI Profile
- SupervisoryOSFI E-23
- SupervisoryMeitY AI and Deepfake Advisories
- VoluntaryRBI FREE-AI
Also relevant to
- ICMR AI in Healthcare Guidelinesno numbered obligations; mapped in its practical notes (validity and clinical validation)
- NITI Aayog Responsible AI for Allno numbered obligations; mapped in its practical notes (safety and reliability)
- Tamil Nadu Safe and Ethical AI Policyno numbered obligations; mapped in its practical notes (pre-deployment scoring)
Standards crosswalk
Clause references only. Check the standard itself for the exact wording.
ISO/IEC 42001
- 8.1 Operational planning and control
- A.6.2.2 AI system requirements and specification
- A.6.2.4 AI system verification and validation
- A.6.2.5 AI system deployment
ISO/IEC 27001
- A.8.25 Secure development life cycle
- A.8.29 Security testing in development and acceptance
- A.8.31 Separation of development, test and production environments
- A.8.33 Test information
SOC 2
- CC8.1
Key takeaways
- Set pass criteria first, test on unseen and realistic data, sign off before release.
- Partial reuse from ISO 27001: your SDLC, security testing and environment separation (A.8.25, A.8.29, A.8.31, A.8.33) carry over; accuracy, fairness and GenAI evaluation are new.
- Test vendor models on your own use case.