Real anonymised engagement · Case study

Enterprise AI Framework for an NSE-listed Company

Captivolt developed an enterprise AI framework covering use-case intake, governance, risk classification, accountability, evidence, and leadership oversight.

A listed company moved AI from scattered initiative to a governed operating capability its board can oversee.

Engagement evidence

What the work produced

AI governance workflow
Risk classification model
Use-case intake design
Evidence model

CLIENT CONTEXT

An NSE-listed company required a board-credible framework to take AI from initiative to governed operating capability.

BUSINESS PROBLEM

AI activity was growing faster than the governance, accountability, and evidence structures needed to oversee it.

CONSTRAINTS

Listed-company disclosure and regulatory requirements
AI activity growing faster than the oversight around it
Accountability spread across functions with no named owner
Evidence expected by auditors, not just by engineering

ARCHITECTURE & APPROACH

Developed the enterprise AI framework: use-case intake, governance workflows, risk classification, accountability model, evidence requirements, and leadership oversight cadence.

WHAT CAPTIVOLT DELIVERED

Governance framework · use-case intake workflow · risk classification · accountability model · evidence requirements · oversight cadence.

EVIDENCE

Reference available under NDA where client permission allows.

The public case study describes the system and the work. It does not publish the client’s identity, source data, commercial information or unapproved performance figures.

In detail

How the governance model fits together.

The operating model

Four layers of accountability, and the decisions each one holds. Naming the decisions is what stopped funding, architecture and release approval arriving at the same monthly meeting.

Board and audit committee: Oversight of the portfolio and its risk appetite, served by a standing pack rather than by a presentation prepared for each meeting.
AI council: Funds, stops and pauses use cases against the classification and the evidence, with a named chair.
Accountable business owner: One per system, distinct from the team that built it and the team that runs it. Accepts residual risk personally.
Delivery and run teams: Build, release against the gate, and operate. They propose; they do not accept risk on the organisation’s behalf.

The governance workflow

Intake to review, as a path a use case travels rather than a policy it is measured against afterwards.

Intake: A front door with a named owner and enough detail to classify. Proposals that arrive elsewhere are the ones nobody governs.
Classification: Applied by the rule below, producing a risk level and the controls that follow from it.
Approval: Against evidence, by the accountable owner, with what they were shown recorded alongside the decision.
Release: Gated on the assurance evidence rather than on the date.
Periodic review: A date on every classification and approval, because a decision about last year’s system is not a decision about this one.

Risk classification

A rule rather than a judgement call, so two similar systems are classified the same way by different people in different quarters.

Decision consequence: What happens if the output is wrong and acted on: the dimension that dominates the others.
Reversibility: Whether the action can be undone, and how quickly.
Data classification: What the system can reach, and under whose entitlements.
Autonomy: Whether a person is in the path before the consequence occurs.
Regulatory exposure: Whether the decision sits in a supervised activity.

Evidence requirements and oversight

What each control has to produce, so the governance model can be shown to be working rather than described.

Per system: Identity, owner, purpose, classification with the rule that produced it, data sources, model and version, and the tools it may call.
Per release: Evaluation evidence against the agreed criteria, the gate decision, and who approved it against what.
Per exception: An accountable approver and an expiry date. An exception without an expiry is a policy change nobody voted on.
Per incident: What happened, what was done, and what changed afterwards, linked to the system rather than to a thread.
Oversight view: Portfolio by risk, approvals outstanding, exceptions approaching expiry, incidents open. The pack the committee actually needs.

Publication boundary

What is not published here.

The client’s figures (how many systems the register holds, how many use cases have passed intake, how long approval now takes) belong to the client and have not been approved for publication. The structures above are ours to describe; the numbers are not, and we would rather show an empty column than a plausible one.

OUTCOME

Leadership gained a structured, execution-ready framework with named ownership and defined oversight.

WHAT THE CLIENT OWNS NOW

The governance framework and use-case intake workflow
The risk classification model
The evidence requirements
A named accountability model and oversight cadence

Start with the work most relevant to your initiative.

Anonymised artefacts and reference discussions are available under NDA where client permission allows.

Discuss Your AI Initiative Run the AI Readiness Diagnostic