VSO What is AI governance?
AI governance is the set of responsibilities, policies, decisions and controls through which an organization manages its use of AI. It connects intended uses and risk tolerance with system design, evaluation, deployment, oversight, incident handling and retirement.
For a practical program, separate three activities: deciding what an AI system is allowed to do, enforcing those rules in operation, and retaining evidence that allows the organization to review what happened. Each needs a named owner and a way to test whether it works.
The NIST AI Risk Management Framework is a voluntary resource for incorporating trustworthiness into the design, use and evaluation of AI systems. The workflow below is VSO's practical evidence-design guidance; it is not a NIST assessment, certification or claimed equivalence to that framework.
Separate policy, enforcement and evidence
| Responsibility | Example for an AI agent | Evidence to review |
|---|---|---|
| Policy and accountability | A business owner defines which payments require human approval. | Versioned policy, rationale, approval and exception process. |
| Runtime enforcement | A permission service checks approval before allowing a payment tool to run. | Configuration, access-control tests, denied attempts and failure behavior. |
| Evidence and assurance | The organization records the request, policy result, approval and tool outcome. | Correlated records, verification results, independent reconciliation and review findings. |
A record of a control is not the control itself. Signing an event does not stop an unauthorized action. Enforcing an action policy does not automatically prove that every relevant event was captured. Test these properties separately.
Build the program around one consequential workflow
- Inventory the system and its use. Identify the business owner, users, affected parties, model dependencies, data sources and external tools. Include intended uses and prohibited uses.
- Define the decision boundary. State which actions need approval, which actions are automatic, who may override a decision, and what happens when a dependency or control is unavailable.
- Evaluate before deployment. Use tests relevant to the use case: correctness, robustness, privacy, security, harmful outcomes and failure recovery. Record the test conditions and known gaps.
- Approve a specific configuration. Tie the release decision to model, code, policy and tool versions. A material change should trigger a defined review.
- Monitor and retain evidence. Record consequential decisions and results, track failures and exceptions, and preserve enough context to investigate incidents.
- Review and improve. Assign incident ownership, document corrective actions, re-test controls and define when a system should be restricted or retired.
Do not begin with a universal score. Begin with a decision that matters, the evidence needed to evaluate it, and the person responsible for acting on that evidence.
Make ownership and review explicit
| Role | Owns | Should receive |
|---|---|---|
| Business owner | Use case, risk acceptance and operating limits. | Evaluation findings, incidents and unresolved limitations. |
| Engineering owner | Implementation, instrumentation and operational recovery. | Approved requirements, test failures and change decisions. |
| Security / privacy reviewer | Review of permissions, exposure, retention and access controls. | Data flows, threat scenarios and control evidence. |
| Independent reviewer | Assessment against the declared review criteria. | Versioned evidence, verification inputs and known exclusions. |
A small organization may assign several roles to one person. Record that overlap rather than implying independence. Where a separate reviewer is required, plan access to evidence and an escalation route before the review begins.
Design an evidence set that can answer questions
For a consequential agent workflow, retain a coherent package rather than a collection of unrelated screenshots:
- Decision context: system inventory entry, purpose, owner, approved use and relevant evaluation results.
- Configuration: model, code, policy and tool versions, with the release decision that authorized them.
- Event records: the request, policy outcome, approval or override, tool action and result, connected by stable identifiers.
- Verification material: the schema, key history, integrity proofs, applicable external anchors and verifier version.
- Review record: criteria, scope, exclusions, findings, remediation owner and closure evidence.
Do not log secrets or personal information simply because it may later be useful. Decide which content is necessary, which can be represented by a restricted reference, who may access it, and how long it is retained. Evidence preservation and data minimization need to be designed together.
The companion AI audit trail guide provides an event example, verification sequence and technical evaluation checklist.
How VAP and VCP support the evidence layer
VAP (Verifiable AI Provenance Framework) defines shared requirements for verifiable AI records. VeritasChain Protocol (VCP) applies this approach to algorithmic and AI-driven trading. These specifications can support an organization's evidence design; they are not a complete AI governance program.
As of 24 October 2026, VAP is v1.2.0 Draft 3 and VCP is v1.2.0 General Availability. A published specification's status does not by itself establish external adoption, independent validation or regulatory recognition.
Verification can assess record integrity and attribution under the specified trust assumptions. VAP's completeness invariant concerns post-anchor omission within an anchored batch's declared scope. It does not prove that all real-world actions were observed, that the captured input was true, or that the AI's decision was fair or safe. See the VAP specification, especially §§1.6, 4.1 and 11.1.
For financial implementations, consult the VCP v1.2.0 specification. Review the separate scope and requirements of VeritasChain Certified (VC-Certified) when evaluating technical conformance. Conformance does not constitute compliance with any law or regulation.
Questions for an AI governance review
- Can the owner explain the intended use, affected parties and actions the system may take?
- Is the deployed configuration linked to an approval and a reproducible evaluation?
- Can the team demonstrate that permissions and human-approval rules work under failure conditions?
- Are monitoring gaps, third-party dependencies and unrecorded events disclosed?
- Can a reviewer inspect consequential event records without relying solely on the producer's interface?
- Are incidents, exceptions and changes assigned to an owner with a documented resolution?
- Does the review distinguish a verified record from a justified decision?
Use these questions to identify missing evidence and operating decisions. They are a starting point for a scoped review, not a universal compliance checklist.
Common questions
Is AI governance only a compliance task?
No. It also addresses responsibility, acceptable use, operational risk, system quality and incident response. Legal requirements depend on the organization, jurisdiction and use case, and need a separate assessment.
Does a model evaluation replace production evidence?
No. An evaluation describes behavior under specified test conditions. Production records describe observed operation. Both matter, and neither removes the need to assess gaps and changing conditions.
Can cryptographic logs make an AI system safe?
Logs can provide evidence for investigation and review. They do not themselves prevent harmful actions or guarantee safe decisions. Runtime controls, evaluation and accountable operating processes remain necessary.
Explore the specifications
Read the shared VAP requirements, then use the VCP specification and implementation material for financial systems.
VAP frameworkVCP developer resources