vCISO AI governance for a consultancy

Context

A global engineering consultancy had begun deploying AI tools across several business units: document summarisation, proposal drafting, and project-risk triage. The tools were live and in daily use. The board risk committee was asking one question at every meeting: “Which AI do we run, who owns it, and what happens if it fails?” Nobody could answer that from standing artefacts. A project had to be convened each time.

The COO brought us in as a fractional vCISO specifically to resolve that gap. The brief was not to replace the existing risk function. It was to add the four AI-specific layers the existing three-lines structure was missing and give the board a governance model it could recognise and test.

Risk

• No named accountability. AI use cases had been approved informally by product leads. There was no inventory, no tiering, and no record of who was accountable if a tool misbehaved. A material AI failure would have discovered accountability during the incident, not before it.
• Risk appetite expressed as sentiment, not criteria. The board had agreed it had “moderate” appetite for AI risk. That statement was untestable against any proposed use case. There was no autonomy threshold, no data-class limit, and no escalation trigger.
• Shadow deployments invisible to the second line. Because there was no formal onboarding gate, teams had connected AI tools directly to project-management systems and client portals. The second line could not see what was running, so it could not challenge it.

Engagement

We structured the work in three parallel tracks over one quarter, keeping file ownership clean across the tracks so the existing risk team could review without bottleneck.

• Policy and appetite. We drafted the AI policy in the firm’s existing policy format, covering permitted and prohibited AI, the mandatory inherited controls (gateway egress, scoped credentials, logging), and the trust boundary between models and client data. We expressed risk appetite in two testable criteria: no AI deployment at act-autonomously on a client-data path; any tool touching special-category or client-confidential data requires second-line sign-off before go-live.
• Inventory and tiering. We ran a discovery exercise across business units, pairing self-declaration with egress-log review. We found 14 AI use cases; 4 were not in any register. Each use case was tiered on data sensitivity, autonomy level, and client or market impact. Three were re-tiered upward after discovery.
• Approval lifecycle and board cadence. We defined a five-gate approval lifecycle mapped to NIST AI RMF (Govern, Map, Measure, Manage) and aligned to ISO/IEC 42001 for future certifiability. We wired the DPIA trigger into gate two so it ran before design freeze, not after. The governance forum, a quarterly agenda item on the existing technology-risk committee, was given a named chair, a standing membership across the three lines, and a defined remit: ratify tier-3 use cases, review the inventory, and review the incident trend.

The quarterly board pack was templated to answer four questions from standing artefacts: what AI runs, who owns each piece, what autonomy has been permitted, and which named individual is accountable.

Outcome

For the governance framework behind this engagement, read vCISO vs fractional CISO vs BISO.