Your AI Operating Model

Governance Layer

The Governance Layer is active from Phase 0 onwards. It is not a phase deliverable — it is a standing structure that runs in parallel with all execution phases. Without it, every layer below drifts.

Executive Sponsor

Single named owner of the AI mandate at board or executive level (CEO / CIO / CDO). Must be appointed before Phase 0 begins — not a committee role.

Responsibilities:
- Holds budget authority and strategic investment decisions
- Resolves cross-functional conflicts that the Steering Committee cannot
- Signs off on phase gate go/no-go decisions
- Named in all AI programme documentation

By tier: Small = Owner/CEO. Medium = CIO or COO. Enterprise = CIO / CDO.

AI Steering Committee

Formal governance body with cross-functional representation. Operates on its own calendar — not triggered only by phase gates.

Members: Legal, DPO, CISO, Business Process Owners, IT Lead, CAIO (chair).

Cadence: Monthly (Enterprise), Quarterly (Medium). Not required for Small — BIITS acts as governance support.

Responsibilities:
- Intake and prioritisation of new AI use case requests
- Phase gate go/no-go decisions (full compliance review before proceeding)
- Monthly review of KPI dashboard and incident log
- Annual governance audit scheduling and oversight

CAIO / Client-Side AI Lead

The CAIO / AI Lead is responsible for:
- Chairing the Steering Committee
- Maintaining the AI Inventory and Risk Register
- Translating governance constraints into strategic and tactical boundaries
- Day-to-day coordination between Legal, CISO, and delivery teams
- Escalation path for all governance questions

By tier: Small = not required (BIITS provides governance support). Medium = named IT Manager or senior business lead. Enterprise = dedicated CAIO or Head of AI.

Policy & Acceptable Use

Minimum policy contents:
- Data classification rules (what data can be used in which AI systems)
- Approved AI use cases (explicit list — everything not on it requires steering committee approval)
- Prohibited AI use cases (explicit list — no exceptions without executive sponsor sign-off)
- Vendor AI tool approval process (which third-party tools are permitted; how new ones are evaluated)
- Human override requirements (which decisions must have human sign-off regardless of AI confidence)
- Employee obligations (usage rules, disclosure requirements, confidentiality)

Owner: CAIO with Legal and DPO sign-off.
Review cadence: At each phase gate + annually. Updated within 30 days of any regulatory change.

AI Inventory

A living catalogue of every AI system in use — internal builds, vendor tools, embedded AI (Copilot, ChatGPT, etc.). Cannot audit what you haven't catalogued.

Minimum fields per entry:

Established: Phase 0 (initial catalogue). Updated: at every phase gate and when new tools are introduced.
Owner: CAIO. Reviewed by: Steering Committee quarterly.

GRC Framework — Baseline

The GRC Framework operates at two levels:

Level 1 — Baseline (active from Phase 0):
- Risk appetite statement (documented, executive-signed)
- EU AI Act risk classification applied to all use cases at scoring time
- GDPR data flows mapped for every AI system touching personal data
- Sector-specific rules applied (CMMC, HIPAA, SOX where relevant)
- Vendor AI tool compliance declaration (DPA, data residency, audit rights)

Level 2 — Advanced controls (activated at Phase 3, Agentic AI):
- Bias monitoring (detect and document bias in model outputs; cadence defined per use case)
- Model explainability (SHAP, LIME, or counterfactual explanations for regulated decisions)
- Drift detection (statistical monitoring; alert thresholds set at deployment)
- Audit trails (every agent action logged: timestamp, actor, input, output, decision rationale)
- Access controls (role-based permissions; no agent has broader data access than required)
- Incident response plan (severity tiers, escalation paths, post-incident review)

Important: Phase 3 activates Level 2 controls on top of the Level 1 baseline already in place — not instead of it. Both levels run in parallel from Phase 3 onwards.

Compliance Alignment

Standing alignment with applicable regulatory frameworks. Reviewed at each phase gate.

Audit & Review Cadence

A governance-level review calendar that runs independently of delivery phases. Phase gates are tactical milestones; this is the governance heartbeat.

Strategy Layer

The Strategy Layer sets direction and connects AI investment to business outcomes. It is established at Phase 0 and revisited at every phase gate. Without a clear strategy layer, tactical execution becomes a list of disconnected experiments.

Business Objective Mapping

Every AI initiative must connect to a measurable P&L outcome before it enters the use case queue. This is the primary filter — not technology interest, not executive enthusiasm.

Mapping format per use case:
- AI initiative → business process it changes → KPI it moves → estimated financial impact
- Acceptable outcome categories: cost reduction, revenue growth, churn reduction, cycle time improvement, risk reduction, customer experience improvement
- Initiatives with no mappable outcome are not scored — they are returned to the business owner for reframing

Done at: Phase 0. Revisited at: each phase gate.

AI Wave Placement

Clients are placed on the AI evolution track at Phase 0. This determines the roadmap entry point and which phases are in scope.

Wave placement is not static. Re-assess at each phase gate — clients can accelerate or pause wave progression based on data readiness and governance maturity. The most common failure is skipping to Agentic AI without completing the GenAI foundation.

Competitive & Regulatory Context

Strategy built without external visibility is strategy built in a vacuum. Two scans run in parallel at Phase 0 and refresh annually.

Regulatory scan: Maps applicable frameworks per use case — EU AI Act risk tier, GDPR exposure, sector rules (CMMC, HIPAA, SOX). Output: a constraint map that filters the use case shortlist before scoring begins. No use case enters the portfolio without a compliance ruling.

Competitive scan (added v1.3): Which competitors are deploying AI, in which functions, and at what scale? Sources: public announcements, earnings calls, job postings, vendor case studies. Output: 1-page competitive AI positioning summary per client. This surfaces urgency that internal stakeholders often underestimate — and identifies differentiation opportunities that competitors have not yet claimed.

Refreshed: Annually as a standing deliverable. Triggered immediately on a significant competitor move or regulatory change.

Use Case Portfolio

The Use Case Portfolio is the prioritised shortlist of AI initiatives approved for execution. It is not a wishlist — it is a scored, ranked, gate-controlled queue.

Scoring model (1–5 each dimension):

T-shirt sizing by effort: S (1–4 weeks pilot), M (4–8 weeks), L (8–16 weeks), XL (programme-level, multi-phase).

Output: Ranked shortlist of 3–5 use cases per phase, each with Build/Buy/Partner decision, data requirements, and pilot KPI targets.

Owner: CAIO + your BIITS consultant. Approved by: Steering Committee. Reviewed at: every phase gate.

Build / Buy / Partner

Required per capability before it enters the use case execution queue. Ad hoc vendor selection without this framework is the most common source of lock-in risk.

Sign-off required: CAIO + Executive Sponsor. Revisited: at every phase gate. Documented in: AI Inventory with rationale.

Multi-Year Roadmap

The roadmap is a 5-phase gate sequence — not a Gantt chart. Each phase has explicit go/no-go criteria that must be met before the next phase begins. Timing varies by company size tier.

Gate criteria — Phase 0 → Phase 1: Executive Sponsor named; minimum 3 use cases scored; GRC Level 1 baseline documented; data readiness assessment complete for top use case.

Gate criteria — Phase 2 → Phase 3: Phase 2 pilot ROI confirmed; adoption KPI above baseline; AI Inventory current; Steering Committee approved Phase 3 scope; data readiness score ≥16/24 for agentic use case.

How You Invest — Phase by Phase

AI investment is scoped from your Phase 0 diagnostic — not from a fixed price list. Every budget is allocated per phase with ROI targets agreed per use case before a single pilot begins. Three starting points, depending on where you are today.

The right starting point is determined at Phase 0. BIITS will not recommend a scope before the diagnostic is complete.

Strategic KPIs

Strategic KPIs are agreed at executive level at the end of Phase 0 — before any delivery begins. They belong to the Steering Committee scorecard, not the delivery team's sprint board.

Required format per KPI:

KPI categories: Efficiency (cost reduction, cycle time), Quality (error rate, accuracy), Revenue (new revenue, churn reduction), Risk (incidents avoided, compliance findings), Adoption (active users, workflow penetration).

Rule: If a KPI cannot be measured today (no baseline data source exists), it cannot be a strategic KPI. Fix the data source first — then set the target.

Tactical Layer

The Tactical Layer is where strategy becomes execution. It runs phase by phase — each activity has a named owner, a start dependency, and a gate-linked completion criterion. This is also where 70% of AI programme failures originate: data not ready, change management skipped, integration ungoverned.

Phase Execution Plans

Each phase has a documented execution plan before work begins. A plan without named owners and dependency maps is a timeline — not a plan.

Required elements per phase plan:
- Named owner per activity (one person, not a team or role title)
- Milestone dates tied to gate criteria — not calendar quarters
- Dependency map: what must be true before each activity can start
- Risk register: top 3 risks per phase with mitigation action, owner, and early-warning signal

Gate completion evidence: Phase plans are closed with a gate completion report — not marked complete by delivery team self-assessment. Steering Committee reviews the evidence and approves the gate.

Pilot Design & Delivery

A pilot is a functional AI system running in an actual workflow — not a sandbox, not a demo, not a proof of concept with synthetic data. The only question a pilot answers is: does this produce confirmed business value at acceptable risk in real conditions?

Pilot design requirements:
- Target duration: 4–8 weeks in production workflow
- KPIs defined before launch with baselines: accuracy, cycle time, cost saving, adoption rate
- Human review checkpoints configured for any customer-facing or regulated output
- Kill criteria agreed upfront — specific condition + time window. If the condition is met, the pilot stops. No extensions without Steering Committee approval.

What makes pilots fail: KPIs defined after launch (no baseline); data quality assumed rather than validated; kill criteria absent (pilots run indefinitely); change management treated as a communications email.

Data Readiness Programme

Data readiness runs as a parallel workstream from Phase 0. It is not a blocker that halts everything else — it is a scored, actively-managed programme that determines which use cases can proceed to production and when.

6-dimension scorecard (0–4 each, total 24 points):

Gate rule: Score <16/24 = do not proceed to production for this use case. Remediate failing dimensions first. Score ≥16/24 = approved to proceed, with a remediation plan for remaining gaps.

Skills Gap Assessment

The Skills Gap Assessment identifies which roles are unprepared for AI-augmented work and determines whether gaps are closed by training, hiring, or partnering. Run at Phase 0 and re-run at each phase gate.

6 skill dimensions assessed per role: AI literacy, prompt engineering, data stewardship, model monitoring, AI-assisted workflow operation, change facilitation.

Scope by tier: Small = owner + 2–3 key staff. Medium = all AI-adjacent roles. Enterprise = full role families by function.

Output per role: Gap heat map (red/amber/green per dimension) + prioritised reskilling plan with named individuals and deadlines + Buy/Train/Partner decision per gap.

Common failure: Assessment covers IT roles only. The highest-impact AI adoption failures happen in operations, finance, and customer-facing roles — not in the IT team. The Skills Gap Assessment must follow the use case portfolio, not the org chart.

Vendor & Tool Selection

Triggered at Phase 1/2 — after use cases are locked and data requirements are confirmed. No vendor is selected before the Build/Buy/Partner decision is made at the Strategy Layer.

7-criterion evaluation framework:

Minimum contract requirements before signature: DPA signed with EU data residency confirmed; audit rights included; exit terms and data deletion procedures defined; SLA with financial remedy for breach.

Change Management

Change management is a parallel workstream from Phase 0 — not a communications plan added at the end of delivery. The primary failure mode for technically successful AI pilots is adoption failure driven by absent change management.

Required workstream elements:
- Role impact map: which roles change, which are augmented, which are eliminated — updated at each phase
- Reskilling plan: output of Skills Gap Assessment, with named individuals and completion dates
- Adoption KPI: defined before pilot launch. No adoption KPI = change management has already failed
- Leadership engagement plan: Executive Sponsor and middle management alignment (AI adoption fails most often at the middle management layer, not the front line)

Adoption KPI format: % of target users actively using the AI-assisted workflow at least X times per week, measured at weeks 4, 8, and 12 post-launch.

Kill / Scale Framework

Every pilot exits through one of three gates: Scale, Iterate, or Kill. These decisions are made on evidence — not on sunk cost, executive enthusiasm, or vendor pressure.

Important: Kill decisions are not failures — they are the framework working. A portfolio with no kills is a portfolio where kill criteria were never enforced.

AI CoE / Intake Process

The AI Centre of Excellence manages the use case intake pipeline and ensures new requests are evaluated against the portfolio before entering delivery. Its structure scales with the client.

Intake form minimum fields: Use case description; business process affected; KPI targeted; data requirements; requestor and business owner named; estimated value and urgency.

Integration Layer Governance

AI output that cannot reach the systems it needs to affect is operationally worthless. Integration without governance creates the opposite risk: AI output that incorrectly updates financial or operational records.

Write-back control tiers (ascending sensitivity):
1. Advisory — output is informational only; no system write; no approval needed
2. Workflow trigger — AI initiates a workflow (creates a task, sends a notification); rule-based conditions required
3. Record update — AI writes to a system of record (CRM, ERP, HRIS); HITL review or threshold rule required
4. Financial transaction — AI initiates or approves a payment or contract; always dual sign-off, no exceptions

Pre-production integration checklist:
- API contracts defined and version-controlled before build starts
- End-to-end integration test completed in staging environment
- Failure mode test: what happens when the AI system is unavailable?
- Rollback test: can the integration be cleanly reversed without data corruption?
- Fallback process documented: named manual process for every AI-assisted workflow

Operational Layer

The Operational Layer never switches off. Once a system is in production, these processes run continuously — independent of project phases, delivery teams, or BIITS engagement status. If any of these processes are absent post-deployment, the programme has a standing compliance and operational risk exposure.

MLOps & Observability

Model performance in production degrades silently if not actively monitored. MLOps is the discipline of treating deployed AI systems with the same operational rigour as production software infrastructure.

Standing monitoring requirements:
- Model performance: tracked continuously against the pilot baseline; deviations above threshold alert the CoE owner automatically
- Drift detection: input distribution (data pattern changes) and output distribution (model behaviour changes); alert thresholds set at deployment and reviewed quarterly
- Pipeline health: uptime, latency, processing volume anomalies; real-time alerting
- CI/CD discipline: all model updates go through staging validation before production — no ad hoc pushes to production models

Monitoring configuration is a Phase 3 handover item — it cannot be added retroactively without service disruption and creates a compliance gap in audit trails if absent at deployment.

Audit Trails

Audit trails are the primary compliance defence in a regulatory enquiry. They must be configured at deployment — they cannot be added retroactively once a system is in production.

What must be logged per event: Model output; human override of a model output; access event (who accessed what system and when); configuration change to an AI system.

Gap discovered post-deployment: P2 incident. CAIO notified within 4 hours. Remediation plan with completion date required within 5 business days.

Incident Response

Incident response for AI systems requires defined severity tiers, response SLAs, and root cause discipline. A plan document that no one practises is not incident response.

Post-incident requirement (P1/P2): Root cause analysis completed within 5 business days. Written corrective action with named owner and completion date. Filed in AI Inventory and incident register. Steering Committee notified at next scheduled review.

Bias & Explainability

Bias monitoring and explainability are not Phase 3 configuration items that run once at deployment — they are standing operational processes that continue for the life of every deployed system.

Bias monitoring cadence: Weekly for high-risk or customer-facing use cases. Monthly for standard use cases.

Checks per cycle: Output distribution across demographic groups; decision rate consistency across segments; error rate disparity by group. Threshold breach triggers P2 incident automatically. Findings are logged whether the check passes or fails — a log with only passes is a log that isn't running.

Explainability for regulated decisions: Any decision affecting credit, employment, insurance, or healthcare must be explainable to the subject on request. Approved methods: SHAP, LIME, counterfactual explanations, decision tree surrogates. Named person responsible for retrieval; maximum 48-hour response SLA.

Annual explainability audit: Verify that the explanation method still accurately reflects model behaviour — models can drift away from their explanations over time as data patterns shift.

Access Controls

AI systems introduce new access risk vectors: agents with broad tool access, LLMs that can be prompted to reveal data, and shadow AI tools that bypass approved channels entirely.

Standing access control requirements:
- Quarterly access review: who has access to which AI systems and underlying data, and is that access still required
- Offboarding: AI system access revoked within 24 hours of employee departure — separate from standard IT offboarding checklist
- Monthly privilege creep scan (automated where tooling supports)
- Least privilege for agents: AI agents are granted the minimum data access required to complete their task; no persistent elevated access between tasks
- Access outside approved matrix → immediate revocation + P2 incident logged

Shadow AI mitigation: Clear policy + enforcement mechanism + approved alternatives that are genuinely better than the shadow alternatives. Prohibition without a better approved option accelerates shadow AI adoption, not compliance.

Human-in-the-Loop (HITL)

Human-in-the-loop is a governance requirement in high-stakes domains — not a fallback for AI systems that are underperforming.

Mandatory HITL domains — no exceptions without Executive Sponsor sign-off:
- Financial decisions (payments, contracts, credit decisions)
- HR decisions (hiring, performance assessment, termination)
- Legal decisions (claims, liability determinations, regulatory filings)
- Security decisions (access grants, incident response actions)

HITL operational requirements:
- Named reviewer per use case — not a team, a named individual
- Maximum review SLA defined before deployment (e.g., 4-hour SLA for contract approval workflow)
- Fallback reviewer named: the process does not stall if the primary reviewer is unavailable
- Every human override logged in audit trail with timestamp and override rationale

HITL design test: If the human reviewer approves everything the AI produces without genuinely reading it, HITL is theatre — not governance. Fix the review design, reduce the review volume, or acknowledge the risk explicitly and document the decision.

KPI Tracking & Optimisation Loop

The KPI loop connects operational performance to strategic targets. Without it, the Steering Committee receives anecdotal updates. With it, the Executive Sponsor has a data-driven scorecard that drives decisions.

Optimisation loop: Monitor → Analyse (root cause) → Remediate (tactical or operational fix) → Govern (update policy or AI Inventory if needed) → Refresh (update baselines post-remediation).

Escalation rule: Any metric below threshold for 3 consecutive reporting periods escalates to the next audience tier automatically. No silent degradation is permissible.

Vendor Governance

Vendor governance is active from the first vendor tool deployed — not from Phase 4. Vendors delivering AI capabilities carry compliance, performance, and concentration risk that must be actively managed, not periodically checked.

Quarterly review per vendor:
- SLA compliance: uptime, latency, error rates vs. contracted terms
- Capability roadmap: are planned features still on track? Any EOL notices?
- Cost vs. value: actual token/API consumption vs. budget; pricing model changes in pipeline
- Data handling compliance: DPA still current, data residency confirmed
- Security posture: any disclosed incidents or certification status changes

Annual review (full re-assessment): Full vendor risk re-assessment + renewal/exit decision + competitive market check — are better alternatives available at equivalent or lower risk?

Vendor register fields in AI Inventory: Contract expiry date, DPA status and expiry, last review date, exit complexity rating (Low / Medium / High). Concentration risk flag required if >60% of AI workload runs on a single vendor.

Model Lifecycle Management

Deployed models are not static — they age, drift, and eventually need to be retired or replaced. Without active lifecycle management, deprecated models stay in production long after their performance has degraded or their data sources have changed.

Version record required per deployed model:

Retirement triggers — any one of the following:
- Performance below defined threshold for 4 consecutive weeks
- Validated replacement available with confirmed improvement over incumbent
- Data source changed materially (distribution shift confirmed by monitoring)
- Vendor end-of-life notice received
- Business process the model supported has been discontinued

Transition process: Parallel run — replacement model runs alongside the retiring model for a minimum of 2 weeks before cutover. Rollback: previous model version retained in staging for 30 days post-cutover; 4-hour rollback execution SLA. Cutover and retirement logged in AI Inventory with rationale and owner sign-off.

AI Architecture & Technology v1.4 — In development

Data & Platform Foundation v1.4 — In development

Economics & ROI v1.4 — In development

Security & Data Protection v1.4 — In development

Organisation & Talent v1.4 — In development

User & Employee Experience v1.4 — In development