Govern AI Systems with Batoi Govern

Who should use this article

This guide is for AI governance leaders, risk and compliance professionals, system owners, builders, analysts, operators, and authorized reviewers. The responsibilities shown in the interface depend on your workspace role. A person with the appropriate authority remains accountable for every consequential approval, exception, restriction, or release decision.

Before you begin

• Confirm the intended workspace and project.
• Identify the accountable business owner and the team responsible for development or operation.
• Gather approved descriptions of purpose, users, affected people, models, providers, data, releases, environments, controls, evaluations, incidents, and limitations.
• Know which frameworks, policies, contractual duties, and regulatory obligations apply to the system.
• Do not enter credentials, secrets, raw tokens, unnecessary personal information, or restricted evidence in ordinary text fields.

Choose the right workspace page

Understand the operating model

AI Governance is not a single questionnaire or score. It is a connected operating record that follows an AI system from intention through operation and retirement.

1. Register and own: identify the system, intended use, accountable owner, provider, users, and affected parties.
2. Classify: describe impact, exposure, constraints, prohibited uses, and the consequences of failure or misuse.
3. Control and evidence: connect policies, controls, evaluations, approvals, and current evidence to the exact scope they support.
4. Measure: apply approved definitions to evidence-backed observations without hiding missing or stale information.
5. Review and decide: record the accountable human decision, its rationale, conditions, exceptions, and review date.
6. Monitor: track incidents, complaints, recourse, drift, supplier changes, and material changes that may invalidate the previous decision.

Register an AI system

1. Open the intended project in Batoi Govern.
2. Open AI Governance, then use AI Systems to create or review the system record.
3. Use a recognizable business name. The platform manages technical references internally.
4. Describe the intended purpose, operating context, users, affected people, owner, provider, and material limitations.
5. Link the exact model, version, release, environment, deployment, and supplier relationship where those records exist.
6. Confirm that the system status communicates whether it is proposed, approved, restricted, active, suspended, retired, or otherwise controlled by the workspace policy.

Connect risks, controls, and evidence

Describe each material risk in terms of cause, uncertain event, and consequence. Record inherent exposure, applicable controls, residual exposure, treatment, owner, and review date. A control should state what must be true, who is accountable, how it is evaluated, what evidence supports it, and how long that evidence remains current.

Evidence must be connected to the exact system, release, environment, period, and assertion it supports. A policy document may prove that a rule was defined, but it does not by itself prove that the control operated effectively.

Run quantitative assurance

Open AI SDLC Assurance when you need an evidence-backed measurement. Define and independently approve the profile and metric definition before recording results.

For each assurance domain $d$, let $E(d)$ be its valid assessed control observations. Each value $x_i$ must be on the approved 0–4 scale. Batoi Govern calculates the domain level as:

• Measured zero and measured values from 0 through 4 can enter the average.
• Not applicable observations are excluded and require an approved rationale.
• Missing, unavailable, stale, failed, or out-of-range observations do not enter the average.
• If a domain has no valid assessed controls, its level is undefined and is displayed as not assessed rather than zero.

Verified evidence coverage is calculated separately. Let $N_{\text{required}}$ be the required evidence items and $N_{\text{verified}}$ be those backed by a current measured observation, verified quality status, and source integrity value:

A high domain level with low coverage is not a strong conclusion. Evidence quality and freshness affect whether required support is verified and whether the decision can proceed; they are not hidden multipliers in the domain average. Always read the result together with scope, evidence dates, decision state, assumptions, and limitations.

Apply non-compensatory decision rules

Critical conditions are evaluated before an aggregate. Strong documentation or performance in one area cannot cancel a failed safety, authorization, integrity, privacy, or recourse gate.

1. An active operational stop condition produces Blocked.
2. A failed critical gate produces Blocked.
3. Stale mandatory evidence produces Stale.
4. Missing or unavailable mandatory evidence, or a supported mandatory observation without verified evidence, produces Not assessed.
5. Another failed gate or a recorded exception produces Conditional.
6. Only a scope that passes those rules may be marked Ready.

Ready means the approved rules were satisfied for the stated scope and period. It is not certification, permanent approval, or a prediction that the system cannot fail.

Record the human decision

The reviewer should be able to understand:

• the exact system, version, release, environment, and period covered;
• the applicable decision criteria and critical gates;
• the evidence reviewed and its freshness;
• coverage, uncertainty, known limitations, and plausible gaming risks;
• the decision, rationale, authority, conditions, exceptions, and expiration or review date; and
• the owner and due date for every follow-up.

The preparer should not approve a consequential definition or result when independence is required.

Monitor the system after approval

Reassessment may be required after a material change to the model, provider, data, prompt, retrieval source, tool authority, evaluation method, release, deployment, environment, intended use, or affected population. Operational incidents, complaints, recourse requests, drift, control failures, and expiring evidence should also trigger review according to policy.

Report and share assurance

Use Reporting to prepare controlled outputs from approved sources:

• Report Templates define approved structure and disclosure expectations.
• Report Runs create source-snapshotted drafts for review and approval.
• Artifact Center retains governed private snapshots and lineage.
• Auditor Rooms provide authorized, time-bound access to selected material.

Publication does not automatically authorize distribution. Confirm classification, redaction, recipients, access period, download policy, and revocation responsibilities before sharing.

Role guidance

Verify the result

• The AI system has a recognizable name, intended purpose, scope, accountable owner, and operating status.
• The exact model, release, environment, deployment, provider, and material changes are connected where applicable.
• Material risks, controls, evaluations, evidence, incidents, and recourse records are current and attributable.
• Formulas, populations, thresholds, stop rules, gaming risks, and limitations are visible to reviewers.
• Missing, zero, unavailable, stale, failed, and not-applicable states remain distinct.
• The final decision and every condition or follow-up have appropriate authority, ownership, and dates.

Troubleshooting

Safety and limitations

For the conceptual basis behind multidimensional quantitative assurance, read Trust Is Not a Score: A Mathematical Framework for Quantitative AI Assurance.

Next step

Open AI Governance in the intended workspace, verify the system record and accountable owner, and record the first missing lifecycle relationship as an assigned follow-up.