Singapore AI Verify: Turn the Testing Framework Into Evidence

Singapore AI Verify gives an enterprise a structured way to assess how an AI system implements responsible-AI practices. The current AI Verify Foundation framework covers traditional and generative AI across 11 governance principles. It organizes the assessment around principles and outcomes, with processes and evidence. That structure is useful because it forces a team to name the desired result and the work performed. It also identifies the artifact that supports the answer. It still requires careful scoping around the exact system and version under review.

TL;DR

• The AI Verify Testing Framework covers traditional and generative AI and assesses implementation against 11 internationally recognized governance principles.
• Its four elements pair principles with outcomes and processes with evidence. A credible assessment keeps all four linked to one defined system boundary.
• AI Verify maps to the NIST AI RMF and the NIST Generative AI Profile, along with the Hiroshima Process Code of Conduct and ISO/IEC 42001.
• A framework report records an assessment. Legal compliance and independent certification require their own evidence and owners. Product security and runtime policy enforcement do too.

Singapore AI Verify defines 11 governance principles

The AI Verify Foundation's AI Verify Testing Framework says it helps organizations assess responsible implementation against 11 internationally recognized AI governance principles. The list covers transparency and explainability; reproducibility and safety; security and resilience under changed conditions; fairness and data governance; accountability; human agency and oversight; plus inclusive growth and societal and environmental well-being.

The framework covers traditional and generative AI. That breadth makes the system boundary important. A credit model and retrieval assistant expose different conditions than a support chatbot and autonomous agent. The actors and data differ, as do the outputs and failure paths. Record the exact application and owner; model and version; deployment environment and intended users; affected people and data sources; integrations and decision role before answering a check.

The AI governance framework guide describes the operational layers around that inventory. AI Verify can organize an assessment within those layers, but the enterprise still has to connect each answer to the deployed system.

Four elements connect policy to a testable record

The Foundation describes four key elements. They pair principles with outcomes and processes with evidence. A principle gives the broad governance objective. An outcome states the condition the system should achieve. A process identifies an actionable step used to reach that outcome. Evidence supports the assessment. The AI Verify Foundation presents its broader work through frameworks and testing tools alongside governance practices for its community.

Treat that sequence as a traceability chain. Start with one outcome and assign an owner. Record the process performed and its date; the system version and input or sample; the acceptance rule and reviewer; the result and retained artifact. Link exceptions and remediation to the same record. A policy document alone shows intent. A screenshot alone shows one configuration state. A test result without version details may belong to a retired build.

The framework page exposes a Process Checks tool designed to document implementation and generate a summary report. Use the report as an index into the underlying evidence. The useful package lets a reviewer move from an answer to the named artifact and reproduce the check where appropriate. It also shows who accepted any residual gap.

Crosswalks reduce duplicate work without merging obligations

AI Verify maps its framework to the US NIST AI Risk Management Framework and the NIST Generative AI Profile, along with the Hiroshima Process International Code of Conduct and ISO/IEC 42001. A crosswalk can show that one control or artifact contributes to several review programmes. It should preserve the wording and scope of each destination requirement.

For example, an access-control test may support an AI Verify security process and an internal NIST control mapping. The same test can appear in both evidence indexes. Each assessment still needs its own conclusion and owner. It also needs an applicability decision. Similar labels rarely mean identical obligations.

Singapore financial institutions may also work with sector-specific material. The Singapore MAS FEAT AI checklist covers that separate context. Keep the AI Verify assessment and sector duties in distinct columns. Do the same for contractual requirements and internal policy. Then link shared evidence instead of declaring one framework a substitute for the others.

Evidence should follow the deployed system version

Build the assessment around a versioned evidence pack. At minimum, identify the system owner and intended purpose; model and configuration; data sources and user groups; deployment date and material dependencies. Add the process-check response and evidence location; test date and reviewer; result and exception; remediation owner and next review trigger.

Change triggers matter because AI behavior and architecture can move without a new product name. A model replacement can change quality and safety results. A retrieval source can alter data governance and disclosure risks. A prompt or tool change can affect oversight. New user groups can change fairness and access assumptions. Re-run affected checks and preserve the earlier result rather than overwriting it.

I would reject an assessment where every row points to the same 90-page policy PDF. On a conference-room screen, those links look complete until an engineer asks which request and model, tied to which identity and policy version, produced the evidence. The AI risk register template provides a place to keep those system changes and evidence owners visible.

Runtime evidence covers a defined slice

Some AI Verify processes can use runtime artifacts. Security and accountability may need records of actual model requests and decisions. The same applies to data governance and transparency, as well as oversight. For an authenticated HTTP route, a useful record can include the caller and application; destination model and data classification; policy version and action; timestamp and correlation identifier.

That record supports narrow conclusions about routed use. It can show that a policy evaluated a request before transmission and that an unapproved model route was blocked. It can also show that a reviewer can reconstruct which rule applied. It cannot prove training-data quality or model development practice; environmental impact or fairness across an untested population; human-oversight procedures outside the request path.

Keep runtime records beside evaluation results and governance approvals; data documentation and human-review evidence. The AI audit log format guide covers fields for the request-level record. AI Verify supplies the organizing framework; the system owner still has to produce artifacts with enough scope and provenance to support each answer.

DeepInspect

DeepInspect supports the routed-request part of an AI Verify evidence pack. It sits inline between authenticated users or agents and HTTP-based LLM endpoints. It evaluates identity-aware policy and writes a per-decision record before the request proceeds or the response returns.

Map those records only to processes they directly support. Keep the caller and application; model destination and classification; policy version and decision; timestamp tied to the assessed system version. Evaluations and model documentation remain with their respective owners. The same applies to organizational approvals and human-review procedures, plus checks outside authenticated HTTP AI traffic.

Book a technical deep dive at deepinspect.ai.