CE Assessment Playbook

01

Engagement Overview

Agent Readiness Assessment — a 4-week fixed-price diagnostic that tells a CDO exactly which AI agents they can deploy, and what is blocking the rest.

Week 1

Discovery

Target Class Elicitation (30 min)
Business intent alignment
Top-20 priority questions
Platform inventory
Artifact: Target Class Profile

Week 2

8-Pillar Scoring

Data interviews (3–4 sessions)
Platform scan per pillar
Evidence collection
P8 governance deep-dive
Artifact: Draft pillar scores

Week 3

Floor Plan Analysis

Score all 8 pillars
Run Target Class Matrix
Identify Class-Gating Gaps
Draft Quick Win Spec
Artifact: Gap register

Week 4

Findings Delivery

Findings presentation (CDO + sponsors)
CE Maturity Score Report
Floor Plan one-pager
OSI Quick Win Spec
90-day CE Roadmap

Team

CE Architect — owns engagement, runs elicitation, scores all pillars
Data Platform Analyst — platform scan (Databricks / Snowflake / Fabric)
Delivery Lead — Week 4 CDO presentation, contract close

When to pitch

CDO/CAO has expressed interest in agentic AI but no active deployment
Customer has deployed BI agents and hit unexpected blockers
Platform partner (Databricks/Snowflake) is recommending a readiness review
Post-pilot failure — CDO needs to understand why

02

The 6 Agent Classes

proprietary taxonomy. Elicited in Week 1 before scoring begins. Target class sets the minimum pillar floors for the entire engagement.

Class 1

Query Agent

Answers structured questions about metrics and KPIs in natural language. Stateless or lightly stateful. One question → one answer.

Insurance example

"What was gross written premium for P&C Home in Q3 by distribution channel?"
"Which underwriters exceeded binding authority limits last quarter?"

Min harness: RBAC · audit log · basic output validation

Floors: P1=3, P2=2, P3=2, P4=3, P5=2, P6=2, P7=2, P8=2

Class 2

Research & Synthesis

Aggregates across multiple domains, combines structured data and documents, produces summaries or recommendations.

Insurance example

"Generate a renewal pack for account #AC-7821 including 5-year loss history, exposure summary, market conditions, and rate recommendation."

Min harness: Hallucination detection · source attribution · output validation

Floors: P1=4, P2=3, P3=3, P4=4, P5=3, P6=3, P7=2, P8=3

Class 3

Monitoring & Alert

Runs continuously or on schedule, watches data signals against business thresholds, triggers alerts or downstream actions.

Insurance example

"Alert claims ops when P&C Motor combined ratio exceeds 97% for any regional portfolio for 3 consecutive weeks."
"Notify the chief actuary when IFRS 17 CSM movement deviates >5% from forecast."

Min harness: Circuit breakers · iteration cap · escalation logic

Floors: P1=3, P2=4, P3=2, P4=3, P5=2, P6=2, P7=4, P8=3

Class 4

Workflow Orchestration

Drives multi-step business processes end-to-end, coordinates human review gates and system actions, maintains process state.

Insurance example

"Process a new commercial property application: risk assessment → appetite check → underwriting recommendation → referral if above threshold → bind confirmation."
"Run month-end IFRS 17 close end-to-end with actuary sign-off gate."

Min harness: Full harness · human-in-the-loop gates · step-level audit trail · rollback

Floors: P1=4, P2=4, P3=4, P4=4, P5=4, P6=3, P7=3, P8=4

Class 5

Autonomous Decision

Makes decisions with limited or no human oversight in a pre-approved decision domain. Output triggers direct system action.

Insurance example

"Auto-approve motor claims under £3,000 meeting all standard adjudication criteria — no fraud indicators, PH not on watchlist, damage consistent with reported incident."
"Automatically bind personal lines home renewals within pre-agreed rate change corridor."

Min harness: Full harness · AIUC-1/EU AI Act Art. 9 · explainability · hard-stop controls

Floors: P1=5, P2=5, P3=4, P4=5, P5=5, P6=4, P7=4, P8=5

Class 6

Multi-Agent Orchestrator

Coordinates and delegates to multiple specialist agents (which may be Class 1–5), manages delegation chains, resolves conflicts.

Insurance example

"Solvency II QRT submission orchestrator: delegates to domain agents (P&C, Life, Health), data quality agent, actuarial agent, filing agent — coordinates end-to-end."
"Customer 360 orchestrator across CRM, claims history, risk scoring, and next-best-action agents."

Min harness: Delegation chain accountability · cost envelope at orchestrator level · CSA Agentic Profile

Floors: P1=5, P2=4, P3=5, P4=5, P5=4, P6=4, P7=4, P8=4

03

Week 1 · Target Class Elicitation

Run these 5 questions in the first 30 minutes of the Week 1 Discovery Workshop with the CDO and Business Champion. Document the Target Class Profile before moving to priority question elicitation.

Q1

What tasks or decisions do you want AI agents to handle?

Open-ended. Note what actions the agent takes, not just what insights it produces. "Tell me X" → lean Class 1/2. "Do X automatically" → lean Class 3/4/5. Record verbatim.

Q2

Will the agent's output be consumed by a human making a decision — or will it trigger a downstream system action directly?

Human reads and acts → Class 1/2 candidates. Triggers automated system action → Class 3/4/5 territory.

Q3

Does the agent need to run continuously or on a schedule, without a human initiating each run?

Yes → Class 3 minimum (monitoring) or Class 4/5 (if acting). No → Class 1/2. An underwriting recommendation on demand is Class 2; one that runs nightly against the book is Class 3.

Q4

Does the agent's output domain involve regulated decisions — claims adjudication, underwriting bind decisions, credit scoring, trading, clinical care?

Yes → floor the class at Class 4 minimum. If the agent makes the decision autonomously → Class 5 treatment required. This is the question that changes the readiness bar most dramatically.

Q5

Do you intend to have multiple specialised AI agents coordinated by a higher-level orchestrator?

Yes → include Class 6 in target profile alongside the specialist classes. No → target class is the highest class identified from Q1–Q4.

Insurance worked example · Aegon-type Life & P&C carrier

Q1: "We want agents that monitor our combined ratio in real-time and alert us to deteriorating portfolios, and also agents that can auto-approve low-value motor claims."
Q2: Monitoring → alert to human (Class 3). Claims approval → system action, no human (Class 5).
Q3: Monitoring runs continuously. Claims agent runs on submission event.
Q4: Claims adjudication is a regulated decision → Class 5 treatment confirmed.
Q5: Not in Year 1.

Target Class Profile: Class 3 (Monitoring) + Class 5 (Autonomous Decision). Year 2 may add Class 4 for IFRS 17 close workflow.

Delivery note: This profile immediately sets the readiness bar high. P1=5, P2=5, P4=5, P8=5 are all required for Class 5. Check these pillars first in Week 2 — early signal on whether a Foundation Sprint is needed.

04

Week 2 · 8-Pillar Scoring Guide

Each pillar: what it measures, insurance-specific interview questions, platform tooling to check, and the 5-level scoring rubric. Score each pillar 1–5 based on evidence gathered. Never self-report — verify claims against platform artefacts.

P1 20% Semantic Asset Coverage ▶

Breadth and quality of formal metric, entity, and KPI definitions in the platform's semantic layer. An agent can only answer questions that are formally defined — undefined terms force improvised SQL with no business-logic guarantee. Insurance focus: combined ratio, loss ratio, GWP, NWP, earned premium, claims frequency/severity, reserve adequacy, binding authority utilisation, IFRS 17 CSM/RA.

Interview Questions

Where do your metric definitions live today — BI tool measures, dbt models, or a platform-native semantic layer (Databricks Metric Views / Snowflake Semantic Views)?
If an AI agent asked "What is our P&C Motor combined ratio?" — could it get the answer without a human writing SQL for it?
How many of your top-20 business questions have a verified, agreed metric definition that any function in the company would accept as authoritative?
Are your metric descriptions written for LLMs (natural language, business context) or for data analysts (technical, with SQL references)?

Platform Tooling to Check

Databricks

Unity Catalog Metric Views, dbt Semantic Layer (MetricFlow), AI/BI Genie semantic configuration

Snowflake

Semantic Views (preview), Cortex Analyst YAML semantic file, dbt on Snowflake

Fabric

Power BI semantic models, Direct Lake semantic layer, dbt-fabric adapter

Scoring Rubric

Level	Label	Evidence
L1 · Absent	No semantic layer	Metrics exist only in BI calculated fields or ad-hoc SQL scripts. No machine-readable definitions. Agent would need to improvise SQL.
L2 · Initial	CEO dashboard set only	<20% of priority questions covered. Definitions in a single tool (e.g. Power BI measures only). No cross-platform consistency.
L3 · Developing	20–50% coverage	Formal definitions in one platform's native layer (dbt metrics, Databricks Metric Views). Column-level descriptions exist but inconsistent. LLM context absent.
L4 · Established	50–80% coverage	Definitions include business logic, not just column aliases. LLM-facing descriptions present on priority assets. Multi-domain coverage beginning.
L5 · Optimised	80%+ coverage	Semantic layer is the system of record for metrics. Version-controlled. Domain coverage spans all AI-target domains. LLM consumption descriptions tested.

P2 17% Data Asset Governance & Trust ▶

Whether gold-layer data assets are documented, owned, quality-certified, and have freshness SLAs — so agents can trust what they consume. An agent acting on stale or uncertified data produces authoritative-sounding wrong answers. Insurance focus: policy data gold tier, claims transactions, premium ledger, reinsurance bordereau, actuarial run-off triangles, IFRS 17 measurement data.

Interview Questions

Who is the named data owner for your claims, policy, and premium datasets? Can you name them today without looking it up?
Do you have quality monitoring on gold-layer data assets? What happens — who is alerted — when quality drops below threshold?
How do you know whether the data an agent would query was loaded this morning or three days ago? Is freshness SLA enforced?
Do you have data contracts between producing and consuming teams — or does everyone query source systems directly?

Platform Tooling to Check

Databricks

Unity Catalog data lineage, Delta Live Table expectations, Databricks data quality monitoring (system.data_quality)

Snowflake

Data Quality Monitoring (GA 2026), governance tags, masking policies, lineage in Snowsight

Fabric

Microsoft Purview data catalog, Fabric Data Factory pipeline monitoring, OneLake data quality

Scoring Rubric

Level	Label	Evidence
L1 · Absent	No governance layer	No data catalog. No data owners assigned. Data quality unknown. Agent would consume raw data with no quality guarantee.
L2 · Initial	Basic catalog only	Column names and table descriptions catalogued. Some owners identified. No quality monitoring. Freshness unknown.
L3 · Developing	Priority assets governed	Gold-layer assets catalogued with business context. Data owners identified. Quality checks exist but not alerting-enabled. Freshness SLAs documented for some assets.
L4 · Established	Quality monitoring active	Gold/silver/bronze tier documented. Quality monitoring active on AI-target assets (DLT expectations or equivalent). Freshness SLAs enforced with alerting. Data stewardship process active.
L5 · Optimised	Data contracts in force	Automated quality gates on all AI-target assets. Data contracts governing producer/consumer relationships. Freshness SLAs tied to agent execution schedules. Quality score tracked as a KPI.

P3 13% Domain & Organisational Alignment ▶

Whether the organisation's domain model is agreed, entities are resolved across domains, and a business champion owns the semantic layer programme. Without this, every function builds its own definitions and the agent gets contradictory answers for the same question. Insurance focus: Customer/policyholder entity resolution (same customer in CRM, policy admin, claims), Counterparty ID for reinsurance, product hierarchy agreed across Finance/Underwriting/Reserving.

Interview Questions

Is there a single agreed Customer ID (or Policy ID, Counterparty ID) that every system uses — or do different systems use different identifiers for the same entity?
Who is your CDO or business champion for the semantic layer programme? What decisions can they make unilaterally?
If the Claims team and Finance disagree on the definition of "paid loss" — who resolves it and how? How long does that take?
Do you have a process for publishing new semantic definitions, or does each team build its own in isolation?

Platform Tooling to Check

Databricks

Unity Catalog business glossary, entity resolution via Delta tables, domain workspace structure

Snowflake

Cortex Glossary, Snowflake governance schema, cross-database entity joins

Fabric

Purview data glossary, OneLake domain partitions, Power BI shared semantic models

Scoring Rubric

Level	Label	Evidence
L1 · Absent	No domain model	Data ownership disputes common. No business champion. Each team builds its own definitions. Same entity has different IDs across systems.
L2 · Initial	Informal ownership	One team has started semantic layer work. No cross-functional engagement. Entity resolution not attempted.
L3 · Developing	Domain model drafted	Domain model documented (even informally). Business champion identified. Cross-domain entity definitions begun (e.g. Customer ID agreed between Policy Admin and CRM).
L4 · Established	Cross-domain resolution	Formal domain ownership with data stewards per domain. Cross-domain entity resolution in place. Business sponsor actively engaged. Conflict resolution process documented.
L5 · Optimised	Governance committee active	Semantic layer governance committee meets regularly. Domain boundaries enforced via platform access controls. Entity resolution automated. Organisation-wide publishing process.

P4 18% Agent & AI Consumption Readiness ▶

Whether the semantic layer is configured for machine consumption — API access, LLM-facing descriptions, verified example queries, agent-scoped RBAC. A semantic layer built for human BI users is fundamentally different from one ready for agent consumption. Hard gating rule: P4 = Level 1 caps the overall tier at Foundation regardless of composite score.

Insurance note

Check whether Cortex Analyst YAML semantic file exists for Snowflake; Genie-ready Unity Catalog configuration for Databricks; verified NL→SQL for top-20 insurance questions (combined ratio, loss ratio, GWP, reserve adequacy).

Interview Questions

Has your semantic layer ever been queried by a machine — a bot, an API, or an AI tool — rather than a human BI user?
Do your metric definitions include LLM-facing descriptions written in natural language, explaining business context — not just column aliases?
Have you tested a natural language to SQL tool against your semantic layer? What percentage of your top-20 questions did it answer correctly?
Do AI agent service accounts have separate RBAC from human user accounts — or does the agent use a shared human login?

Platform Tooling to Check

Databricks

Genie (AI/BI conversational analytics), Unity Catalog function calling, Mosaic AI Agent Framework, Genie-ready metadata configuration

Snowflake

Cortex Analyst semantic YAML file, Cortex Search, Snowflake Cortex LLM functions, Arctic Embed

Fabric

Microsoft Copilot for Power BI, Azure OpenAI on Fabric data, natural language query in Power BI

Scoring Rubric

Level	Label	Evidence
L1 · Absent	Human BI only	Semantic layer is a human BI tool. No API access. No LLM-facing descriptions. No verified NL→SQL. Agent cannot consume without writing raw SQL. Hard gate — Foundation Sprint required
L2 · Initial	API accessible	Assets accessible via SQL API. Descriptions written for analysts, not LLMs. No verified example queries. Agent service account exists but has broad permissions.
L3 · Developing	LLM descriptions present	Some LLM-facing descriptions (ai_context, column-level NL descriptions). Priority assets accessible via agent accounts with scoped permissions. Some example queries verified.
L4 · Established	Agent-ready configuration	All priority assets have LLM consumption descriptions. Agent service accounts configured with scoped RBAC. Top-20 priority questions have verified SQL. Genie/Cortex Analyst/Copilot configured.
L5 · Optimised	NL→SQL tested in production	Semantic layer tested against LLM consumption (NL→SQL eval on priority questions). Agent access patterns monitored. Prompt templates maintained for complex queries. AI features in active production use.

P5 13% Business Context & Knowledge Capture ▶

Whether tacit business knowledge — regulatory thresholds, exception rules, domain-specific context — is captured in machine-readable form in the semantic layer. Insurance focus: loss ratio thresholds by portfolio segment, underwriting authority limits, IFRS 17 CSM calculation rules, Solvency II pillar thresholds, fraud indicators, claims adjudication criteria, risk appetite parameters.

Interview Questions

Where does your combined ratio threshold live — in someone's head, in a spreadsheet, or in the data platform as a versioned definition?
If an agent needed to know "what constitutes a large claim in P&C Motor" — where would it find that definition?
For IFRS 17 or Solvency II reporting — are the regulatory definitions of your key metrics machine-readable, or only in the regulation text?
When a business rule changes (e.g. the threshold for automatic binding approval is updated) — how is that change communicated to the teams building data products?

Platform Tooling to Check

Databricks

Unity Catalog business glossary, dbt metric descriptions with business context, documentation site

Snowflake

Cortex Glossary with business context fields, Semantic Views description fields, Snowflake docs

Fabric

Purview glossary terms with definition and context, Power BI measure descriptions, DAX documentation

Scoring Rubric

Level	Label	Evidence
L1 · Absent	Knowledge in people's heads	Business rules exist only in documents or tribal knowledge. No thresholds in the data platform. Agent would have to hallucinate business context.
L2 · Initial	Informal capture	Some rules captured in column descriptions. No structured glossary. Exception handling undocumented. Thresholds not versioned.
L3 · Developing	Glossary with 50+ terms	Business glossary covering key insurance terms. Key thresholds documented in the semantic layer (e.g. loss ratio threshold = 65%). Common exception rules captured.
L4 · Established	All AI-target domains covered	Glossary covers all AI-target domains. Thresholds version-controlled and linked to semantic definitions. Regulatory context documented for regulated metrics. Exception ontology in progress.
L5 · Optimised	Rules expressed as code	Business rules expressed as dbt tests, DLT expectations, or Snowflake data quality constraints. Regulatory rule changes tracked as semantic layer updates. Knowledge base integrated with agent consumption layer.

P6 5% Semantic Coverage vs Business Demand ▶

Whether the current semantic coverage actually covers the questions the target agent needs to answer. High P1 scores with low P6 mean quality definitions exist but don't address the priority use cases.

Interview Questions

Can you give me your top 20 business questions — the ones your CDO, underwriting director, or head of claims would ask every week?
For each of those, can we map it: does a formal metric definition exist in the semantic layer today?
Which 3–5 questions are most important for your target agent? Are those specifically covered?

Scoring Rubric

Level	Label	Coverage of top-20 priority questions
L1 · Absent	No mapping done	No priority question catalog. Coverage unknown.
L2 · Initial	<30% answerable	Questions catalogued informally. Coverage assessed: fewer than 6 of top 20 answerable from semantic layer.
L3 · Developing	30–50% answerable	Top-20 questions catalogued. Coverage mapped: 6–10 answerable from current semantic assets.
L4 · Established	50–75% answerable	Coverage mapped for all priority questions: 10–15 answerable. Gaps identified and backlogged. Coverage tracked quarter-on-quarter.
L5 · Optimised	75%+ answerable	15+ of top-20 answerable. Coverage tracking automated. New business questions triaged against semantic layer before BI tool build.

P7 4% Operational Readiness ▶

Whether the team, tooling, and processes exist to maintain and evolve the semantic layer over time. A semantic layer without operational discipline decays — metrics drift, definitions become stale, coverage shrinks. Especially important for Class 3 (monitoring) agents which depend on freshness SLAs.

Interview Questions

Who maintains your semantic layer today? Is it one person or a team? What happens when they leave?
Is your semantic layer in version control with a review/approval process for changing a metric definition?
How long does it take to add a new metric definition from business request to production availability?
Do you have automated tests that run when a semantic layer change is deployed?

Scoring Rubric

Level	Label	Evidence
L1 · Absent	Ad-hoc, single owner	One person owns the semantic layer with no documentation. Changes undocumented and untested. No version control.
L2 · Initial	Some version control	Files in git. One informal owner. No deployment pipeline. Change process undocumented.
L3 · Developing	Basic CI/CD	Named team (even if small). Semantic layer in version control. Basic CI/CD for dbt or equivalent. Change management process informal but present.
L4 · Established	Process-governed changes	Dedicated team or clear ownership matrix. CI/CD pipeline with automated tests. Change request process for semantic definition changes. Documentation standards enforced.
L5 · Optimised	Platform-agnostic management	Automated semantic drift detection. Semantic layer SLA (availability, freshness, quality) tracked. Roadmap for coverage expansion maintained and reviewed quarterly.

P8 10% Agentic Harness Readiness ▶

Whether the platform and team are ready to govern, cost-control, evaluate, and certify agents safely. For Class 4–6 agents, a gap here is as blocking as a gap in P1. Hard gating rule: P8 < Level 3 with a Class 4, 5, or 6 target caps the overall tier at Foundation regardless of composite score.

Insurance note

Class 5 agents (auto-approve claims) require documentation ready for FCA or PRA inspection: AIUC-1 conformance path, EU AI Act Article 9 risk management system, explainability output per claim decision, hard-stop inputs that always require human review (e.g. suspected fraud flags, claims above £X regardless of criteria).

Interview Questions

If an agent ran 10,000 queries overnight due to a loop bug — would anything stop it? What is your cost-per-task circuit breaker?
Before deploying an agent to production — what is your testing process? Do you have a test suite with deliberate edge cases and seeded defects?
When the agent produces a wrong answer — how do you know? What hallucination detection approach do you use for agent outputs?
Does the agent use a dedicated service account with scoped permissions — or a shared admin credential?
For regulated use cases: do you have documentation ready for a regulator asking "how does this agent make decisions?"

Platform Tooling to Check

Databricks

Mosaic AI Agent Evaluation, Unity Catalog agent RBAC, system.access.audit for agent query logs, Model Serving guardrails, Databricks cost management per cluster/job

Snowflake

Cortex Guard (hallucination detection), Snowflake Trust Center, model monitoring, Cortex Fine-Tuning eval harness, resource monitors for cost control

Fabric

Azure AI Content Safety, Azure AI Foundry evaluation framework, Responsible AI dashboard, Azure Monitor for cost tracking

Cross-platform governance: AIUC-1 certification (BSI audit path), OWASP Top 10 for Agentic Applications 2026, Cloud Security Alliance Agentic AI security controls, LangSmith / Arize Phoenix for eval harness tooling.

Scoring Rubric

Level	Label	Evidence
L1 · Absent	No governance layer	No cost controls. No eval harness. Agents deployed directly with no validation layer. No agent-specific RBAC or audit log. Hard gate for Class 4/5/6
L2 · Initial	Token caps only	Token limits set at LLM API level. Manual testing only. Agent credentials shared with human users. No structured eval suite. Basic output format checking.
L3 · Developing	Cost + basic eval	Cost tracking per agent run. Basic eval suite covering happy-path cases. Agent service accounts with scoped permissions. Query audit log active. Basic hallucination detection (schema validation, answer grounding check). Minimum for Class 4/5/6
L4 · Established	Circuit breakers + edge cases	Circuit breakers on cost and iteration count. Eval harness with edge-case coverage and defect seeding. Hallucination detection for all priority outputs. Dedicated agent audit trail reviewed. Escalation/hard-stop rules documented. Cost-per-task tracked as a KPI.
L5 · Optimised	CI/CD gated + compliant	No agent promotes without passing eval CI/CD gate. CHARM-type cascading hallucination detection. AIUC-1 or EU AI Act Article 9 controls documented. Governance board reviews agent permissions and eval scores quarterly. All Class 4+ agents have human-in-the-loop gates documented and tested.

05

Week 3 · Target Class × Pillar Floor Matrix

Enter the customer's pillar scores (1–5) to identify Class-Gating Gaps. Any score below the floor for the target class is a blocker — not a recommendation. These go into Phase 1 of the 90-day roadmap.

Customer scores →

P1 Semantic

P2 Governance

P3 Domain

P4 Agent Ready

P5 Biz Context

P6 Demand

P7 Operations

P8 Harness

43

Tier 1 · Foundation

Pillar	Class 1 Query	Class 2 Research	Class 3 Monitor	Class 4 Workflow	Class 5 Autonomous	Class 6 Orchestrator

0Class 1
gaps

0Class 2
gaps

0Class 3
gaps

0Class 4
gaps

0Class 5
gaps

0Class 6
gaps

Above floor At floor Gap

06

Readiness Tiers

Composite score = P1×20% + P2×17% + P3×13% + P4×18% + P5×13% + P6×5% + P7×4% + P8×10%. Level-to-score mapping: L1=15, L2=35, L3=55, L4=75, L5=95.

Score 0–29

0

Not CE-Ready

Mandatory Foundation Sprint (6–8 weeks) before any T2 Accelerator. Do not proceed to Sprint 1.

Score 30–49

1

Foundation

T2 Accelerator Sprint 1 — focus on P1/P4 quick wins. Pilot a Class 1 query agent with limited scope.

Score 50–69

2

Emerging

T2 Sprint 1 + Conversational BI pilot. Class 1–2 agents viable. Address Class-Gating Gaps before Class 3+.

Score 70–84

3

CE-Ready

Genie / Cortex Analyst pilot immediately. T2 Sprint 2. Class 3 agents viable. Class 4 requires gap remediation.

Score 85–100

4

Advanced

Multi-agent deployment viable. Skip starter sprint. Class 5/6 pending P8 score confirmation and compliance path.

Hard gating rules override the composite score: (1) P4 = Level 1 → capped at Foundation regardless. (2) P8 < Level 3 with Class 4/5/6 target → capped at Foundation for that class. (3) Any Class-Gating Gap → those gaps are Phase 1 roadmap items before that class can deploy.

07

Week 4 · Deliverables Guide

Four deliverables handed to the customer at the Week 4 findings presentation. The CE Architect owns the report and roadmap; the Data Platform Analyst produces the OSI export.

CE Maturity Score Report

18–24 pages · CDO and sponsors

Target Class Profile (0.5 page): confirmed class(es), minimum score floors this implies
Executive summary: composite score, tier, 3 Class-Gating Gaps
8-pillar scored assessment with evidence per pillar
Class-Gating Gaps section (1 page): each gap with evidence and specific remediation
P8 Harness Readiness deep-dive: score, gap, recommended tooling
Competitive benchmark vs industry (insurance/BFSI peers)
Quick Win recommendation with rationale

Floor Plan One-Pager

1 page · CDO boardroom visual

Radar chart: 8 pillar scores as the outer polygon
Target class floor plotted as inner overlay ring
Class-Gating Gaps highlighted in red where score is below the floor
Title: "[Customer] · Class [X] Readiness Profile"
Single artefact that makes the CDO conversation immediate — they see exactly which gaps block their target deployment

OSI-Compatible Quick Win Spec

Technical · Data Platform Analyst delivers

3–5 metric/entity definitions in OSI-format JSON/YAML (Apache Ossie spec v0.1.1)
Industry ontology seed: relevant FIBO/ACORD terms for the customer's vertical, pre-formatted for their primary platform
Deployable on Snowflake on day 1 of Sprint 1 (SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML)
Structured for portability to Databricks/Fabric once native support ships
Note in delivery agreement: definitions may require spec version update when OSI moves to stable release

90-Day CE Roadmap

3-phase · CDO and delivery team

Phase 1 (0–30 days): All Class-Gating Gaps + Quick Win implementation
Phase 2 (30–60 days): Remaining pillar improvements to reach next tier
Phase 3 (60–90 days): First agent deployment with eval harness in place
Tier 0 customers: Foundation Sprint replaces Phase 1; re-score at end
Each phase item maps to: pillar → current score → target score → specific platform action

08

OSI Export Specification Horizon · 12–18 months

Delivery guidance: Include the OSI Quick Win Spec on Snowflake engagements today (native preview support available). Flag as a 12–18 month roadmap item on Databricks and Fabric engagements — native import is not yet shipped on either platform. This section is a forward reference; keep it in the 90-day roadmap as a Phase 3 item rather than a Week 4 hard deliverable on non-Snowflake customers.

Apache Ossie spec v0.1.1 (Apache Software Foundation incubating project, January 2026). Do not use 0.2.0.dev0 — breaking changes, not backward compatible.

Snowflake

In Preview Two SQL procedures available. Use SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML. Known limitation: datatypes not exported; composite primary keys fail cross-tool. Spec locked to v0.1.1.

Databricks

Working group member No native export shipped. Deliver structured JSON following OSI schema conventions. Note in the deliverable: "OSI-structured — natively importable once Databricks ships support (projected H1 2027)."

Microsoft Fabric

Community converter Power BI ↔ Ossie community converter available (not native Fabric). Use the converter for Power BI semantic models. Flag as community tooling, not production Fabric feature.

OSI YAML Structure (v0.1.1)

# Apache Ossie v0.1.1 — Quick Win Spec template (insurance example)
semantic_model:
  name: "insurance_core_metrics"
  description: "Core P&C insurance metrics for AI agent consumption. the SI CE Assessment Quick Win."
  datasets:
    - name: "policy_fact"
      source: "gold.policy_fact"
      description: "One row per in-force policy. Refreshed nightly by 06:00 UTC."
      primary_key: "policy_id"
  metrics:
    - name: "combined_ratio"
      description: "(Incurred losses + LAE + underwriting expenses) / earned premium. Target: below 97% for P&C Motor portfolio."
      ai_context: "Use this metric to assess underwriting profitability. Values above 100% indicate an unprofitable portfolio. Threshold 97% triggers management review."
      expression: "(SUM(incurred_loss) + SUM(lae) + SUM(expense)) / NULLIF(SUM(earned_premium), 0)"
      format: "percentage"

Delivery checklist: (1) Confirm the customer's primary platform — use native Snowflake procedure if on Snowflake, OSI-structured JSON for Databricks/Fabric. (2) Include industry ontology seed: ACORD terms for insurance, FIBO for BFSI. (3) Version the file as ossie-quickwin-v1.yaml and include in delivery agreement. (4) Note spec version in the file header. (5) Add a statement that definitions will be updated if spec version changes before Sprint 1 starts.

09

Competitive Positioning

Use this table in the CDO findings presentation (slide 2 or 3). Do not lead with it — lead with the Floor Plan One-Pager. The table lands hardest after the CDO has seen their own gap profile.

Differentiator	v1.0	Databricks tool	Snowflake score	TCS SRI	Persistent	Other SI
Multi-platform (DB + SF + Fabric) composite score	✓	✗	✗	✗	✗	✗
Target Agent Class elicitation before scoring	✓	✗	✗	✗	✗	✗
Class-specific minimum score floors (8×6 matrix)	✓	✗	✗	✗	✗	✗
Agentic Harness Readiness as scored pillar (P8)	✓	✗	✗	✗	✗	✗
OSI-compatible Quick Win deliverable	✓	✗	✗	✗	✗	✗
Industry-vertical calibration (Insurance + BFSI)	✓	✗	✗	Life Sci only	✗	✗
Question-first intake (top-20 elicitation)	✓	✗	✗	✗	✗	✗
Fixed-price with Quick Win spec ($30–40K, 4 weeks)	✓	No delivery	No delivery	No delivery	✗	✗
Kill rules / dead-end protocol	✓	✗	✗	✗	✗	✗
T2 Accelerator Sprint intake included	✓	No delivery	No delivery	No delivery	✗	✗

Handling objections:
"Snowflake already has a readiness score" → "It has a single undifferentiated agents workload bucket. It doesn't ask what class of agent you're building, and it can't see your Databricks environment."
"TCS/Accenture can do this" → "Ask them for their fixed-price with a platform-portable Quick Win spec and a kill rule. They'll say they need to scope it first. We hand you the deliverable in 4 weeks."
"OSI isn't mature yet" → "Snowflake has native preview support today. Databricks is in the working group — native import is 12 months away. We give you a durable artefact that deploys on your primary platform now and is ready for Databricks when they ship."

10

Kill Rules & Foundation Sprint Protocol

These are the conditions under which we explicitly recommend the customer does NOT proceed to T2 Sprint 1 yet. Honest gating at this stage is what builds CDO trust and protects the delivery relationship.

Automatic Foundation Sprint triggers — apply before presenting findings

Kill Rule 1 · Composite score ≤ 29 (Tier 0)

Mandatory Foundation Sprint. Present it positively: "You're in the right place — the gap is specific and addressable. We'd rather give you 6 weeks to fix it than have a sprint fail in month 2." Never proceed to Sprint 1 with a Tier 0 customer.

Kill Rule 2 · P4 (Agent Consumption Readiness) = Level 1

The semantic layer is not machine-accessible at all. Overall tier is hard-capped at Foundation regardless of composite score. Sprint 1 cannot succeed without basic API access and LLM-facing descriptions. Foundation Sprint focus: P4 to Level 2 minimum.

Kill Rule 3 · P8 (Harness Readiness) < Level 3 with Class 4, 5, or 6 target

Tier capped at Foundation for the target class. Proceed to Sprint 1 only for Class 1–3 agents. Explicitly document: "Your target class (Class [X]) cannot be deployed safely until P8 reaches Level 3. This is a prerequisite, not a recommendation." Include a P8 track in the 90-day roadmap.

Kill Rule 4 · 3 or more Class-Gating Gaps for the target class

When three or more pillars are below the target class floor, Sprint 1 is high-risk. Present a Phase 0 gap remediation sprint (2–4 weeks, scoped to close the gaps) before full Sprint 1. This is a judgment call — use it when the gaps are structural (P3, P7) not just incremental (P6).

Sprint Kill Rule — applies during T2 Sprint 1

No qualified pilot conversation within Sprint 1 timeline → retire and redirect

If the customer cannot identify a qualified internal champion for the Sprint 1 pilot by week 3 of Sprint 1, raise the flag immediately. Agreed exit criteria: no named business owner + no agreed pilot scope = Sprint 1 cannot succeed.
Action: Formally retire Sprint 1. Redirect the engagement to T1 (KAM/Sales Velocity track) — help the customer identify and engage the right internal champion before re-qualifying for Sprint 2. Document as a clean exit, not a failure.

Foundation Sprint — what it includes

Duration & cost

6–8 weeks · $30–40K fixed price

Deliverables

Platform inventory, semantic scaffolding for 5–10 priority metrics, data owner assignment, basic quality monitoring setup, P8 cost controls and agent RBAC configuration

Gate to Sprint 1

P1 ≥ Level 2, P2 ≥ Level 2, P4 ≥ Level 2, P8 ≥ Level 2 (Level 3 if Class 4/5/6 target)

11

Market Reference — Similar Assessment Plays

Know the landscape before walking into a CDO conversation. These are the frameworks a well-read customer may have already encountered. Organised by category — platform vendor tools, analyst models, SI-led assessments, and AI governance frameworks.

Platform Vendor Assessments

Databricks Data + AI Maturity Assessment Platform-native

A self-serve maturity questionnaire embedded in the Databricks account console. Scores across five dimensions: Data Ingestion, Processing, Governance, ML/AI, and Collaboration. Outputs a radar chart and recommends Databricks product adoption paths. Tied entirely to Unity Catalog and Mosaic AI adoption — no cross-platform view, no agent class concept, no harness readiness dimension.

If a CDO mentions it: "That tool tells you how mature your Databricks environment is. Our assessment tells you whether you're ready to deploy a specific class of AI agent — and what's blocking you across any platform you're running."

Snowflake Modern Data Experience Assessment Platform-native

Partner-delivered readiness review scoped to Snowflake adoption — Data Cloud migration readiness, Cortex AI feature adoption, and Snowflake governance maturity. Strong on Cortex Analyst and Snowflake semantic views but blind to Databricks or Fabric environments. No minimum score floors by agent class.

If a CDO mentions it: "Snowflake's assessment is a platform adoption health check. It doesn't score your governance readiness or harness readiness for autonomous agents — that's what our framework adds."

Microsoft Cloud Adoption Framework — AI Readiness Platform-native

Microsoft's structured path for enterprise cloud and AI adoption, with an AI readiness pillar added in 2025 covering Azure OpenAI, Copilot Studio, and Fabric integration. Maturity levels 1–5 across strategy, skills, data, and governance. Broad in scope but light on specifics for agentic deployments — it addresses Copilot readiness more than Class 4–6 autonomous agent deployment. No class-specific floor plan.

If a CDO mentions it: "CAF AI readiness covers Copilot and Azure OpenAI adoption well. For customers targeting autonomous workflow or decision agents, our framework picks up where CAF stops — specifically on semantic layer depth and harness governance."

AWS Analytics Lens — Well-Architected Framework Platform-native

AWS Well-Architected Tool with the Analytics Lens applied — covers operational excellence, security, reliability, performance, and cost optimisation for data workloads. A strong infrastructure and architecture review, not a semantic layer or agentic readiness assessment. Increasingly used as a pre-sales tool by AWS account teams ahead of Bedrock and SageMaker engagements.

If a CDO mentions it: "Well-Architected reviews are infrastructure assessments. They won't tell you whether your business questions are defined clearly enough for an agent to answer them, or whether you have a harness to govern agent behaviour safely."

Analyst & Research Firm Frameworks

Gartner Data & Analytics Maturity Model Analyst

Five-level maturity model (Unaware → Transformational) across data governance, analytics capability, and business value realisation. Widely referenced by CDOs as a common language framework. Gartner's 2025/26 iteration adds an AI-readiness dimension, but it remains a broad organisational maturity gauge — not a deployment-gate assessment. No minimum score per use-case class, no harness pillar.

If a CDO mentions it: "Gartner's model is the right framework for where you are on the data maturity journey overall. Our assessment is narrower and more actionable — it tells you specifically which agent class you can deploy now and exactly what is blocking you."

Forrester Insights-Driven Business Assessment Analyst

Forrester's IDB model scores organisations on data-driven culture, analytics tooling, and AI-enabled decision-making. Strong on business strategy alignment and executive leadership readiness. It starts from business questions, not platform features — closest analogue to the SI's question-first approach. However, it is strategy-framed, not deployment-gated: it identifies AI ambition, not AI blockers. No scoring floors, no harness dimension, no kill rules.

If a CDO mentions it: "Forrester's IDB is excellent for executive alignment. Our framework complements it at the technical layer — turning the business ambition Forrester identifies into a deployment-ready gap register with specific platform actions."

IDC DataSphere Maturity Model Analyst

IDC's model quantifies organisational data capability across five stages — Ad Hoc, Opportunistic, Repeatable, Managed, and Optimised. Used frequently in BFSI and insurance sector benchmarking. Covers data volume, velocity, and value realisation but does not address AI agent deployment readiness or semantic layer depth. Strong for board-level benchmarking; limited operational guidance for delivery teams.

If a CDO mentions it: "IDC DataSphere is useful for peer benchmarking. Our deliverable goes further — a scored gap register with a 90-day roadmap your team can act on immediately."

SI-Led Assessment Tools

TCS Data Intelligence Quotient (DIQ) SI-led

TCS's proprietary readiness tool used in enterprise pre-sales across BFSI and manufacturing. Covers data strategy, platform maturity, governance, and AI/ML ambition. Delivered as a 2–3 week scoping exercise, typically at no charge to anchor a larger transformation SOW. Output is a maturity score and a multi-year transformation roadmap. Does not decompose by agent class, does not score harness readiness, and has no fixed-price commitment — it is a sales motion, not a standalone advisory product.

If a CDO mentions it: "TCS DIQ is a good starting point for a transformation conversation. Our assessment is a fixed-price standalone product — the customer owns the deliverable regardless of what comes next."

Accenture Applied Intelligence Maturity Assessment SI-led

Accenture's enterprise AI readiness tool, part of their Applied Intelligence practice. Evaluates AI strategy, talent, data, technology, and responsible AI readiness across five dimensions. Strong breadth but light depth on technical semantic layer and platform-specific agentic deployment. Typically embedded within a broader Accenture engagement — not sold as a standalone diagnostic. No agent class concept, no class-specific floors.

If a CDO mentions it: "Accenture's assessment maps strategic AI readiness well. It won't give you the platform-level gap register you need to deploy an agent on Databricks or Snowflake in the next 90 days — that's our gap."

Tredence / Tiger Analytics Data Maturity Assessments SI-led

Mid-market SI tools — typically 2–4 week engagements covering data infrastructure, ML pipeline maturity, and BI consolidation readiness. Common in insurance, retail, and CPG sectors. Output is a slide deck with a maturity heat map and recommended workstreams. Neither firm has published a structured agentic AI readiness framework as of Nov 2026. Competitive risk is primarily on price and account relationships, not framework depth.

If a CDO mentions it: "Those assessments cover data platform health well. For agentic AI — specifically Class 3–5 agents in an insurance context — they don't yet have the class-specific scoring depth or the harness readiness dimension."

AI Governance & Certification Frameworks

NIST AI Risk Management Framework (AI RMF 1.0) Governance

NIST's voluntary framework for managing AI risk across four functions: Govern, Map, Measure, Manage. Released January 2023; widely adopted as a baseline across US federal contractors and regulated industries. Addresses AI risk governance holistically but is technology-agnostic and does not score deployment readiness. Relevant to P8 — CDOs building toward AIUC-1 conformance will reference NIST AI RMF as a foundational layer.

Delivery note: Our P8 harness pillar is structurally aligned with NIST AI RMF's Measure and Manage functions. Reference this alignment when scoring P8 for customers with US regulatory exposure or those pursuing AIUC-1 certification.

CSA Agentic AI Governance Maturity Model (Draft, March 2026) Governance Draft

Cloud Security Alliance's draft maturity model specifically for agentic AI systems — closest published peer to the SI's P8 pillar. Covers agent identity, delegation chain accountability, cost envelope controls, and cascading hallucination risk. Five maturity levels. Still in draft as of Nov 2026; expect GA in H1 2027. CSA documented 10 agentic AI security incidents in the 7 weeks Jan–Mar 2026 — the market evidence that P8 is not optional for Class 4–6 deployments.

Delivery note: When scoring P8, align rubric language to CSA's five levels — it gives the CDO a recognised external reference point. Monitor for GA release; update P8 rubric when it ships.

AIUC-1 — AI Agent Use Case Certification Governance Emerging standard

Emerging "SOC 2 for AI agents" — a third-party audit certification covering safety controls, eval harness design, human oversight gates, and explainability. UiPath was the first certified vendor (2026). BSI and a consortium of European insurers are driving adoption in regulated industries. Directly relevant to Class 5 (Autonomous Decision) agents in insurance — FCA and PRA are watching AIUC-1 closely as a potential compliance reference. A customer targeting Class 5 without an AIUC-1 roadmap faces significant regulatory risk.

Delivery note: For Class 5 insurance customers, include an AIUC-1 readiness gap in the P8 section of the CE Maturity Score Report. Frame it as a 12-month compliance trajectory, not an immediate blocker — but document it explicitly.

EU AI Act — Article 9 Risk Management System Regulatory

EU AI Act Article 9 mandates that high-risk AI systems — including Class 5 autonomous decision agents in insurance, credit, and employment — must have a documented risk management system with "prior defined metrics and probabilistic thresholds." This is functionally a legal requirement for an eval harness, making P8 Level 3+ a regulatory necessity for EU-regulated insurers deploying Class 5 agents. Full enforcement August 2026.

Delivery note: For EU insurers with Class 5 target class, cite Article 9 explicitly when presenting the P8 gap. "This is not a KPI recommendation — EU AI Act requires you to have this in place before deploying autonomous decision agents." This reframes P8 as a compliance gate, not an advisory score.

12

Security & Compliance Industry Standards

Practitioner reference for delivery teams. Each standard is mapped to the pillars it affects most directly, with a scoring implication and a customer-facing check. Relevant when conducting Week 2 pillar interviews, writing the CE Maturity Score Report, and advising on the 90-day roadmap.

Pillar tags: P1Semantic P2Governance P3Domain P4Agent Ready P5Biz Context P6Demand P7Operations P8Harness

OWASP — Open Web Application Security Project

OWASP Top 10 for LLM Applications v2.0 Active · 2025 P8 P2

The foundational security checklist for any LLM-powered system. Ten risk categories, each with prevention controls. The most-cited framework in enterprise AI security procurement. v2.0 (2025) tightened definitions for Prompt Injection (LLM01) and added Vector and Embedding Weaknesses (LLM08) as a standalone risk.

LLM01 · Prompt Injection

Malicious input overrides agent instructions. Direct (user input) and indirect (data the agent reads). Most exploited risk in production agents.

LLM06 · Excessive Agency

Agent granted more permissions, tools, or autonomy than needed. Core P8 control: principle of least privilege for agent service accounts.

LLM09 · Misinformation

Agent outputs that are plausible but factually wrong, used by downstream systems. Addressed by P1 semantic definitions and P8 hallucination detection.

Scoring implication: During P8 Week 2 interview, ask whether the customer has assessed their agent deployment against OWASP LLM Top 10. A yes with documented controls moves P8 toward L4. A no — or "we use prompt guardrails only" — stays at L2/L3.

OWASP Agentic AI Security Project Emerging · 2026 P8 P2 P4

The agent-specific extension to the LLM Top 10. Released mid-2026 to address risks that emerge only when LLMs are given tools, memory, and the ability to take actions autonomously. Critical reading for any team delivering Class 4–6 agents.

Tool Poisoning

Malicious tools injected into the agent's available toolchain — e.g. a rogue MCP server that mimics a legitimate data tool and exfiltrates queries. P8 control: tool registry governance and tool provenance checks.

Agent Hijacking

Indirect prompt injection via data the agent reads — a document, a database record, an email — that contains embedded instructions. Particularly relevant to Class 2 (Research) and Class 4 (Workflow) agents that consume unstructured content.

Memory Manipulation

Poisoning the agent's persistent memory store — e.g. injecting false context into a vector store that the agent retrieves on future runs. P8 control: memory access RBAC and memory integrity checks.

Delegation Chain Gaps

Class 6 orchestrators delegating to sub-agents with no accountability chain — audit trail breaks at the delegation boundary. P8 control: delegation chain logging and cost envelope at orchestrator level.

Uncontrolled Iteration

Agent enters a reasoning or tool-call loop with no circuit breaker — 10,000 API calls, runaway cost, system overload. P8 control: iteration cap and cost circuit breaker mandatory.

Insecure Output Handling

Agent output consumed by downstream systems without sanitisation — SQL injection via LLM-generated queries, script injection in generated content. P4 + P8 joint control.

Scoring implication: For Class 4–6 target class engagements, run through these six risks explicitly in the P8 Week 2 interview. Each unmitigated risk keeps P8 at L2 or below. Document which risks are unaddressed — they become P8 gap items in the CE Maturity Score Report.

OWASP API Security Top 10 Active · 2023 P8 P4

Relevant for Class 4–6 agents that call external APIs — claims systems, policy admin, underwriting platforms, reinsurance portals. Key risks: Broken Object Level Authorization (API1), Unrestricted Resource Consumption (API4), and Broken Function Level Authorization (API5). An agent calling a claims API with an over-permissioned service account violates API1 and LLM06 simultaneously.

Scoring implication: When P4 service account RBAC is being scored, cross-check against OWASP API Top 10 API1/API5. Over-permissioned agent API credentials are a P8 gap regardless of how well the semantic layer is configured.

ISO / IEC Standards

ISO/IEC 42001:2023 — AI Management Systems Active · Dec 2023 P8 P2 P7

The first international standard for AI Management Systems — the ISO 27001 equivalent for AI governance. Specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system. Covers AI risk assessment, impact assessment, documented controls, policy framework, and supplier AI governance. Increasingly required for enterprise AI procurement in the EU and for financial services regulators. Structured around the same Plan-Do-Check-Act model as ISO 27001 — familiar to any organisation with existing ISO certification.

Clause 6 — AI Risk Management

Requires documented AI-specific risk assessment process — maps directly to P8 eval harness and P2 data quality controls.

Clause 8 — AI System Impact Assessment

Mandatory impact assessment before deployment of high-risk AI — aligns with Class 5 deployment gate requirements in our framework.

Annex A — Controls Reference

56 controls across data governance, transparency, human oversight, robustness, and accountability. Strongest overlap with P2, P7, and P8 pillars.

Scoring implication: Ask whether the customer has ISO 42001 certification in scope or is aligned to it. ISO 42001 Annex A alignment moves P8 to L4 minimum and P2 to L3+ minimum. For Class 5 insurance customers, an ISO 42001 gap alongside an AIUC-1 gap should both appear in the CE Maturity Score Report.

ISO/IEC 27090 — AI Cybersecurity In development · expected 2027 P8

The forthcoming cybersecurity extension to ISO 42001, specifically addressing AI-specific attack vectors: adversarial inputs, model extraction, data poisoning, and supply chain compromise in AI pipelines. In balloting as of Nov 2026. Watch for final publication in H1 2027 — once published, it will become the procurement requirement for AI systems in ISO-certified enterprises, replacing ad-hoc security checklists.

Delivery note: Not yet enforceable — do not include in current P8 scoring rubric. Flag to customers pursuing ISO 42001 that 27090 is coming and their AI security controls should be designed to accommodate it. Include it in the 90-day roadmap Phase 3 as a watch item.

ISO/IEC 5338 — AI Lifecycle Processes Active · 2023 P7 P8

Provides processes for AI system development and maintenance across the full lifecycle — requirements, design, verification, deployment, operation, retirement. Complements ISO 42001's management system requirements with engineering-level process controls. Particularly relevant to P7 (Operational Readiness) — whether semantic layer changes follow a governed change management process that can be audited.

Scoring implication: ISO 5338-aligned change management processes for semantic layer updates move P7 to L4. Ask: "Is there a documented process for reviewing and approving semantic definition changes?" If yes with audit trail, P7 ≥ L4.

NIST — National Institute of Standards and Technology

NIST AI RMF 1.0 + Generative AI Profile (NIST AI 600-1) Active · 2023 / 2024 P8 P2 P7

AI RMF 1.0 provides four core functions — Govern, Map, Measure, Manage — for managing AI risk across any system. The companion Generative AI Profile (NIST AI 600-1, July 2024) maps those functions specifically to GenAI risks: hallucination, harmful bias, data provenance, and human oversight gaps. Both are voluntary but widely adopted as the US federal baseline and used by BFSI regulators as a reference point for AI governance expectations.

Govern → P2 + P7

Policies, processes, roles, and responsibilities for AI risk — maps to data governance (P2) and operational process maturity (P7).

Map → P1 + P5

Identifying AI risks in context — maps to semantic coverage completeness (P1) and business context capture (P5).

Measure → P8

Quantifying AI risks with metrics and thresholds — directly maps to P8 eval harness, hallucination detection, and performance monitoring.

Manage → P8

Responding to identified risks — maps to P8 circuit breakers, hard-stop controls, escalation protocols, and incident response.

Scoring implication: NIST AI RMF alignment is the strongest single signal for P8 L4+. Ask: "Have you mapped your AI systems to NIST AI RMF?" If yes with documented Measure/Manage controls, P8 ≥ L4. Reference 600-1 specifically for GenAI hallucination controls.

Threat Intelligence Frameworks

MITRE ATLAS Active · ongoing P8

Adversarial Threat Landscape for AI Systems — the ATT&CK framework for ML/AI. Documents real-world adversarial tactics, techniques, and procedures (TTPs) used against AI systems: model evasion, training data poisoning, model extraction, inference API abuse, and supply chain compromise. Used by red teams and security architects assessing AI deployment risk. Not prescriptive (no controls checklist) but essential context for P8 — understanding what attackers actually do to AI systems shapes what controls to require.

AML.T0051 · LLM Prompt Injection

ATLAS technique for prompt injection against LLM-integrated systems. Documented case studies from production deployments — useful for illustrating agent hijacking risk to a sceptical CDO.

AML.T0018 · Backdoor ML Model

Supply chain compromise via a backdoored model weight file. Relevant for Class 5/6 customers using open-weight models or fine-tuned models from third parties.

AML.T0040 · ML Model Inference API

Abuse of model inference endpoints — rate limits, cost exploitation, data extraction via carefully crafted queries. P8 cost circuit breakers partially mitigate this.

Delivery note: MITRE ATLAS is background reading for the CE Architect — use it to stress-test P8 interview questions, not as a customer-facing checklist. Reference it when a customer asks "what specific threats are you protecting against?"

CSA AI Controls Matrix Active · 2026 P8 P2

Cloud Security Alliance's companion to the Agentic AI Governance Maturity Model — a spreadsheet-format controls matrix mapping AI risks to specific technical and process controls across cloud environments. Covers identity and access management for agents, data residency, model provenance, audit logging, and incident response. Practical complement to NIST AI RMF — where RMF is principles-based, the CSA matrix is controls-based. Particularly useful for customers running agents on multi-cloud estates (Databricks + Snowflake, or Fabric + Databricks).

Scoring implication: If a customer references the CSA AI Controls Matrix in their governance documentation, P8 is at minimum L3. Cross-check which control domains they have implemented — incomplete coverage (e.g. identity controls done, audit logging missing) keeps them at L3 rather than L4.

Quick Reference — Standard to Pillar Mapping

Standard	Status	Primary pillars	Class relevance
OWASP LLM Top 10 v2.0	Active	P8 P2	All classes
OWASP Agentic AI Security	Emerging	P8 P4	Class 4–6 critical
OWASP API Security Top 10	Active	P8 P4	Class 4–6 (API-calling agents)
ISO/IEC 42001:2023	Active	P8 P2 P7	Class 5–6 procurement gate
ISO/IEC 27090 (AI Cybersecurity)	Draft	P8	Watch item — H1 2027
ISO/IEC 5338 (AI Lifecycle)	Active	P7 P8	All classes
NIST AI RMF 1.0 + AI 600-1	Active	P8 P2 P7	All classes — US / global
MITRE ATLAS	Active	P8	Architect reference — all classes
CSA AI Controls Matrix	Active	P8 P2	Multi-cloud Class 4–6
AIUC-1 Certification	Active	P8	Class 5 insurance compliance path
EU AI Act Article 9	Enforced Aug 2026	P8	Class 5 EU insurers — mandatory