Responsible AI
Principles, and the lifecycle that makes them true.
Principles say what should be true. The lifecycle is how it is made true for one AI system, from the day it is proposed to every day it runs.
Operating lifecycle
Eight stages, for every AI system.
In client engagements Captivolt designs and runs this lifecycle with the client. The decisions in it belong to the client’s accountable people, and the evidence it produces is theirs.
- 01
Classify
What is this system, and how much harm could it do?
- What happens
- Every proposed use case enters through intake with a named owner and is classified by a stated rule, so two similar systems land in the same tier whoever classifies them.
- Who decides
- The accountable business owner, applying the rule, not the team that wants to build it.
- Evidence left behind
- A register entry, and the classification with the rule that produced it
- Carried by
- AegisIQUse-case intake · Risk classification · AI system inventory
- 02
Assess
What could go wrong, for whom, and how badly?
- What happens
- The classification is applied to this system in detail: its data, the people it affects, the actions it can take, and the failure that would matter most.
- Who decides
- The business owner, with risk and security; the assessment is recorded rather than presented.
- Evidence left behind
- A risk assessment, with the answers it was based on
- Carried by
- AegisIQRisk assessment · Ownership
- 03
Control
What stops the failures that matter?
- What happens
- Controls are chosen for the assessed risks, mapped once across the frameworks that apply, and built into the system (permissions, filters, limits, human approval steps and logging), so evaluation tests the system with its controls, and they go live with it.
- Who decides
- The business owner accepts the control set; engineering builds it.
- Evidence left behind
- A control mapping, and the controls running in the environment
- 04
Evaluate
Does it behave acceptably, with its controls, on real cases?
- What happens
- Behaviour is measured against criteria agreed before the build, including adversarial and regression suites, and the results are compared to the release conditions.
- Who decides
- The release gate, which can return hold. An override is recorded with its reason.
- Evidence left behind
- A scorecard, adversarial and regression results, and a release gate decision
- Carried by
- VeriCoreDataset management · Test execution · Scorecard · Release gate
- 05
Approve
Who accepts what is left?
- What happens
- A named, accountable person accepts the residual risk against the evaluation evidence, or does not. An approval has a scope and a date.
- Who decides
- The accountable business owner, never the delivery team.
- Evidence left behind
- An approval recorded against its evidence, with any exception and its expiry date
- Carried by
- AegisIQApproval workflow · Evidence record
- 06
Monitor
Is it still behaving the way it was approved to?
- What happens
- The dimensions measured before release are watched in production against the baseline that release produced, and the portfolio shows risk, open exceptions and anything past its expiry.
- Who decides
- The thresholds agreed at approval decide when a change escalates.
- Evidence left behind
- Monitoring results, and the portfolio view
- 07
Investigate
What happened, why, and what has to change?
- What happens
- A breached threshold, a complaint or an incident is triaged by a named owner and traced to its cause, with failures grouped by cause rather than listed, and what was done is recorded against the system.
- Who decides
- The accountable owner decides whether it keeps running, and the pause condition written at release applies.
- Evidence left behind
- An incident record linked to the system, with the cause and the change it led to
- 08
Reassess
Is the original decision still true?
- What happens
- After an incident, on any change to model, prompt, tools or data, and on a schedule regardless, the classification and approval are reviewed and the system is re-evaluated. A decision about last year’s system is not a decision about this one.
- Who decides
- The same accountable owner, against current evidence.
- Evidence left behind
- A review record: the classification confirmed or changed, and a new baseline or a hold
Returns to Classify.
What carries each stage
Governance, evaluation, and the engineering between them.
Each stage above names the capabilities it uses, by the names the product pages use for them.
AegisIQ carries governance
The record side: system register, risk classification, intake and approval workflow, and the evidence model underneath it.
Classify · Assess · Control · Approve · Monitor · Investigate · Reassess
VeriCore carries evaluation
The measurement side: evaluation harness and datasets, regression baselines, scorecards, release gates and drift monitoring.
Evaluate · Monitor · Investigate · Reassess
Engineering carries the controls
Deploy is neither accelerator. Controls have to be built into the running system, which is engineering work, so it is named here and owned there.
Control
One model at two grains
How this relates to each release.
The ASSURE lifecycle is the release view of the same system: it runs from agreeing criteria to re-evaluation, once for each version. This lifecycle is the whole life of the system around it, and each stage names the release stages it contains. Investigate contains none, because it happens between releases.
| Lifecycle stage | Release stages it contains |
|---|---|
| Classify | Define |
| Assess | Define |
| Control | Deploy |
| Evaluate | Evaluate, Test, Gate |
| Approve | Approve |
| Monitor | Monitor |
| Investigate | None: this happens between releases |
| Reassess | Re-evaluate |
Principles
What the lifecycle exists to make true.
The principles that govern how we design and operate AI systems.
- Human oversight
We design AI systems with human oversight and human-in-the-loop approvals at consequential steps.
- Evaluation before release
We evaluate LLM, RAG, and agentic systems before release, and monitor them after deployment.
- Grounding and source traceability
We ground answers in governed sources and design for source traceability.
- Access control
We design access control and data classification into AI systems so models respect entitlements.
- Bias and fairness
We support bias and fairness review where relevant to the use case and its impact.
- Incident escalation
We define escalation paths for unsafe, unexpected, or out-of-policy behaviour.
- Monitoring and continuous improvement
We monitor behaviour, drift, cost, and quality, and route findings back into improvement. We align governance work to recognised frameworks such as ISO 42001 and the NIST AI RMF.
On this website: The AI Readiness Diagnostic is rule-based: the same answers always produce the same recommendation, and no model is involved.
Governing an AI system you already run?
The lifecycle starts wherever the system is today, most often with the register nobody has populated yet.