AI TRiSM Readiness Assessment

A Diagnostic Companion to the CTO Advisor Field Guide

This assessment is the readiness companion to Operationalizing AI TRiSM: A CTO Advisor Field Guide. The Field Guide maps AI TRiSM concerns to architecture, authority placement, evidence patterns, and the CTO Advisor frameworks. This document serves a narrower purpose: it helps an enterprise determine whether those ideas have been turned into operating reality.

The Field Guide says what the work is.

This assessment asks whether the work has actually been done.

From Governance Language to Operating Reality

Most enterprise AI governance conversations start in the right place and then stall almost immediately. The language is sound. The intent is responsible. The committees are formed. The policies are drafted. Someone points to AI TRiSM and everyone agrees that trust, risk, and security management matter.

Then the implementation team asks the uncomfortable question.

Where does this actually live?

That is the gap this assessment is designed to expose. AI TRiSM gives enterprises a useful institutional language for AI governance, trust, risk, and security. But language is not an operating model. A control that exists in policy but has no system owner, no runtime enforcement point, no evidence chain, and no escalation path is not a control. It is a hope with a slide around it.

This document is not intended to replace Gartner AI TRiSM. It is intended to help enterprise teams operationalize it. The goal is to determine whether an organization has moved from AI governance intent to AI governance placement.

The Core Question

The core question is not whether the enterprise has AI governance.

The core question is whether the enterprise can prove where AI governance takes effect.

That distinction matters. Many organizations can describe their AI principles. Fewer can show where those principles are enforced in the data plane, operational plane, execution path, model lifecycle, application workflow, and human approval chain. Fewer still can explain what happens when those enforcement points disagree.

That is where AI systems fail in production. They do not fail because someone forgot to write down that fairness, reliability, privacy, and security are important. They fail because responsibility is smeared across architecture layers, vendor platforms, internal teams, and business workflows until no one can explain who had authority at the moment the system acted.

The assessment therefore starts with a simple operating assumption: every meaningful AI control must have a place in the system, a responsible owner, a runtime or procedural enforcement mechanism, and an evidence trail.

If one of those is missing, the control may still be useful. But it is not yet operational.

How to Use This Assessment

This assessment is meant to be used in a working session with architecture, security, data governance, platform engineering, application owners, risk, and business stakeholders in the room. It is not a survey to be filled out by a single governance team. If the answers are too clean, the wrong people are probably answering the questions.

For each domain, the team should answer four questions.

First, where does this responsibility live architecturally?

Second, who owns the decision when there is a conflict?

Third, how is the control enforced before or during execution?

Fourth, what evidence exists after the fact?

The answers should be specific enough that an engineer, auditor, or business owner can trace a real AI-enabled workflow from request to outcome. If the answer is “the platform handles it,” the next question is which platform component, under which policy, with which evidence, and under whose authority.

Readiness Levels

This assessment uses four readiness levels. They are intentionally plain.

Level 0: Aspirational

The organization has governance language, principles, or intent, but there is no consistent mapping to architecture, ownership, enforcement, or evidence.

Level 1: Assigned

The organization has identified responsible teams or platforms, but controls are mostly procedural, manual, or inconsistent across business units and AI workloads.

Level 2: Enforced

Controls are implemented in specific systems or workflows. The organization can show where key decisions are made, who owns them, and how policy is enforced before or during execution.

Level 3: Auditable

The organization can reconstruct material AI decisions, explain authority placement, produce evidence across the lifecycle, and adjust controls as systems, models, agents, and business processes change.

The target is not Level 3 everywhere. That would be expensive, slow, and unnecessary. The target is appropriate readiness for the level of authority the AI system holds.

A low-risk summarization workflow does not need the same evidence chain as an agent that can trigger procurement, alter customer entitlements, recommend credit action, or change production infrastructure.

Domain 1: AI Inventory and System Classification

The first failure mode is not model risk. It is not knowing where AI exists.

Enterprise AI no longer arrives only through approved model development projects. It arrives through SaaS features, copilots, agent builders, embedded automation, data platforms, workflow tools, developer assistants, and business unit experiments. An enterprise cannot govern what it cannot see, and it cannot classify risk if it does not know where AI is acting.

A mature organization maintains an inventory of AI systems, models, agents, copilots, data products, and AI-enabled business workflows. The inventory should not stop at model names. It should include business purpose, data access, authority level, human review points, downstream systems, vendor dependencies, and evidence requirements.

This is where the assessment connects directly back to the Field Guide. The inventory is not complete until each workflow has been classified by authority level. A system that summarizes information does not require the same control posture as a system that routes work, initiates action, influences entitlements, or operates autonomously within policy. The names matter because the enterprise needs one shared vocabulary for deciding when AI is merely informing a human, when it is shaping a material decision, and when it has been allowed to act.

The important question is not “Do we have a list?”

The important question is whether the list changes how systems are governed.

A useful inventory drives classification. Classification drives control. Control drives evidence. Without that chain, the inventory becomes another compliance artifact that ages badly the moment a business unit enables a new feature.

Assessment Questions

1. Do we have a current inventory of AI-enabled systems, including vendor-provided AI features and internal agentic workflows?
2. Does the inventory identify where each system acts in the business process?
3. Has each workflow been classified by authority level using the same classification language as the Field Guide?
4. Does classification change required controls, review paths, evidence, and operational ownership?
5. Can we identify systems where practical authority has exceeded the original approval posture?
6. Who is responsible for discovering shadow AI, embedded SaaS AI, and agentic workflows that did not originate through central IT?

Readiness Signal

An organization is moving from aspirational to operational when AI inventory becomes a control plane input, not a spreadsheet.

Domain 2: Data Plane Governance

Most AI risk starts before inference.

The model may be the visible actor, but the data plane often determines the range of possible outcomes. Retrieval sources, embeddings, metadata, lineage, entitlements, masking, retention, and data movement shape what the AI system can know and what it can expose.

This is why AI governance cannot be isolated inside the model platform. A perfectly governed model connected to poorly governed data is not a governed AI system. It is a well-documented risk multiplier.

In the 4+1 AI Infrastructure Model, the data plane is where meaning and risk live. For TRiSM implementation, that means data governance must be connected directly to trust, risk, and security controls. The organization must know what data the system can reach, why it can reach it, how access is constrained, and how those constraints are preserved when data is transformed into embeddings, summaries, prompts, context windows, or downstream outputs.

Assessment Questions

1. Can we identify the authoritative data sources used by each AI system?
2. Are access controls preserved across retrieval, embeddings, prompts, generated outputs, and downstream workflows?
3. Can we trace data lineage from source system to AI output for material decisions?
4. Are sensitive data policies enforced before context reaches the model or agent?
5. Who owns conflicts between business usefulness and data minimization?

Readiness Signal

An organization is operationally ready when AI systems inherit data governance controls instead of bypassing them through convenience layers.

Domain 3: Operational Plane Placement

The operational plane is where AI intent becomes system behavior.

This includes provisioning, orchestration, scheduling, runtime execution, model serving, RAG pipelines, agent coordination, monitoring, and policy enforcement. It is also where many enterprise AI programs discover that “governance” was never actually connected to execution.

Within the 4+1 model, this domain breaks into three subdomains.

The control plane determines how resources, policies, quotas, and placement decisions are managed. The execution plane determines how models, pipelines, tools, and agents actually run. The reasoning plane determines how judgment, constraint arbitration, model selection, escalation, and cross-system coordination happen.

Most enterprise AI architecture discussions under-specify the reasoning plane. That is where authority drift hides.

A system begins as a summarizer. Then it recommends. Then it ranks. Then it routes work. Then it initiates action. At each step, the AI system accumulates decision authority without a corresponding redesign of controls, evidence, or ownership.

Assessment Questions

1. Where are AI policies enforced: before execution, during execution, after execution, or only through review?
2. Who owns runtime behavior when a model, agent, workflow engine, and business application all participate in the same outcome?
3. Are model selection, tool selection, escalation, and fallback decisions explicit parts of the architecture?
4. Can the organization distinguish execution intelligence from governance authority?
5. What prevents an AI workflow from gaining practical authority beyond its approved design?

Readiness Signal

An organization is ready when it can describe not only what the AI system does, but who or what is allowed to decide that it should do it.

Domain 4: Application and Business Workflow Accountability

AI value shows up in the application layer, but so does accountability.

This is where users experience copilots, agents, recommendations, automated workflows, search tools, summarization tools, and decision-support systems. It is also where the enterprise must decide whether AI is providing information, shaping judgment, or exercising authority.

The application owner cannot outsource accountability to the model team. The business process owner cannot outsource accountability to the platform team. The platform team cannot outsource accountability to the vendor. Each may own part of the system, but the business workflow still needs a clear accountability model.

A useful test is simple.

If this system produces a harmful, wrong, biased, insecure, or materially misleading outcome, who explains it to the customer, regulator, board, employee, or business owner?

If the answer is unclear, the authority model is unclear.

Assessment Questions

1. What business process does the AI system alter?
2. Does the system inform, recommend, rank, route, approve, execute, or enforce?
3. Are human review points meaningful, or are they rubber stamps under operational pressure?
4. Who owns the final business outcome when AI materially influences the decision?
5. Are users told when AI is shaping the outcome and what their recourse is?

Readiness Signal

An organization is ready when application accountability matches practical authority, not just formal ownership.

Domain 5: Evidence Chain and Auditability

Trust is not a feeling. It is the ability to reconstruct what happened.

For low-risk AI use cases, that may mean basic logging and user feedback. For high-authority systems, it means a stronger evidence chain: source data, prompt or instruction context, model or tool used, policy checks applied, human approvals, system actions, exceptions, and post-decision monitoring.

The evidence chain should be designed before production deployment. Retrofitting auditability after a system becomes important is painful and often impossible. By then, the organization may discover that prompts were not retained, retrieval context was transient, tool calls were scattered across systems, human approvals happened outside the workflow, and the final business action cannot be tied back to the AI interaction that shaped it.

Evidence does not need to capture everything. It needs to capture what matters for the system’s authority level.

Assessment Questions

1. Can we reconstruct a material AI-influenced decision after the fact?
2. Do logs capture policy checks, data access, model/tool choices, human approvals, and downstream actions?
3. Are evidence requirements based on authority level and business risk?
4. Is auditability designed into the workflow before deployment?
5. Who decides what evidence is sufficient?

Readiness Signal

An organization is ready when evidence is part of the architecture, not a forensic activity after something goes wrong.

Domain 6: Security and Adversarial Resistance

AI security is not a separate concern from enterprise security. It is enterprise security with new attack surfaces.

Prompt injection, data leakage, model abuse, malicious tool use, insecure plugins, poisoned retrieval sources, agent impersonation, and unauthorized action paths all matter because AI systems increasingly sit between users, data, and operational systems.

The security question is not whether the model can be attacked. It can.

The security question is whether the surrounding architecture assumes the model will be attacked and limits the blast radius accordingly.

This requires a security model that treats prompts, retrieved content, tools, agents, APIs, and outputs as part of the attack surface. It also requires separation between instruction, context, authority, and execution. A model should not be able to grant itself permission just because the prompt or retrieved document told it to.

Assessment Questions

1. Are AI-specific threats included in the enterprise threat model?
2. Can untrusted content influence instructions, tool use, or privileged actions?
3. Are tools, APIs, and downstream systems protected by independent authorization checks?
4. Is there separation between model output and system authority?
5. Are AI incidents integrated into security operations and incident response?

Readiness Signal

An organization is ready when AI systems are designed as hostile-input systems, not trusted conversation partners.

Domain 7: Change Management and Continuous Control

AI governance is not a one-time approval event.

Models change. Prompts change. Data changes. Vendors change. Agents gain tools. Business users discover new workflows. SaaS providers quietly introduce AI features. Regulatory expectations move. The risk posture of an AI system can change without a formal project ever being opened.

That is why TRiSM implementation requires continuous control. The organization needs a way to detect when a system’s behavior, data access, authority, or operational dependency has changed enough to require reassessment.

This is especially important for agentic systems. Adding a new tool to an agent may change its authority more than changing the model. Adding write access may change the risk category. Adding retrieval over sensitive records may change the evidence requirement. Adding autonomous retry logic may change operational blast radius.

Assessment Questions

1. What changes trigger reassessment of an AI system?
2. Are prompt, model, data, tool, workflow, and vendor changes governed differently based on authority level?
3. Can business users modify AI behavior without review?
4. Are production AI systems continuously monitored for drift in behavior, risk, and authority?
5. Who can pause, roll back, or restrict an AI system when risk changes?

Readiness Signal

An organization is ready when governance follows the system after deployment.

The Authority Placement Table

The fastest way to make this assessment practical is to classify AI systems by authority. This table intentionally mirrors the Field Guide classification language. The assessment version is shorter, but the underlying model should remain consistent across both documents.

Authority Class	Description	Example	Required Control Posture
Advisory	AI provides information, summaries, analysis, or recommendations, but a human retains meaningful decision authority.	Internal document summarizer, support recommendation, sales next-best-action	Inventory, access controls, disclosure where appropriate, logging, human accountability
Assisted Workflow	AI prepares work, drafts outputs, or organizes next steps inside a human-owned process.	Agent drafts a change request, prepares a customer response, or summarizes case history	Workflow ownership, review requirements, evidence capture, data access controls
Delegated Workflow	AI routes, prioritizes, or initiates work inside a defined process, but cannot complete material action without approved constraints or review.	Agent opens tickets, routes incidents, prioritizes claims, or queues infrastructure changes	Runtime policy checks, tool authorization, escalation paths, workflow audit
Autonomous within Policy	AI can execute bounded actions under pre-approved policy constraints.	Agent remediates a known infrastructure condition or executes a pre-approved service action	Pre-approved action catalog, deterministic checks, rollback, monitoring, independent authorization
Material Decision Influence	AI materially shapes decisions affecting money, access, employment, legal rights, safety, security, or customer outcomes.	Credit, entitlement, hiring, claims, security access, or production change recommendation	Full evidence chain, formal business ownership, independent review, auditable policy enforcement
Autonomous Material Authority	AI can act without meaningful human approval in workflows with material business, legal, safety, security, or customer impact.	Autonomous procurement, production enforcement, customer-impacting eligibility action	Exceptional justification, hard constraints, independent control plane, continuous audit, executive risk acceptance

This table is not a compliance classification by itself. It is a forcing function. It makes the organization say what kind of authority the system actually has.

That is usually where the real conversation begins.

Scoring the Assessment

Each domain should be scored from 0 to 3.

0 means the organization has intent but no consistent placement.

1 means ownership is assigned, but enforcement is inconsistent or mostly procedural.

2 means controls are enforced in systems, workflows, or operating procedures.

3 means the organization can produce evidence, reconstruct decisions, and adapt controls as systems change.

The total score matters less than the pattern.

A high score in policy with a low score in evidence is a warning sign. A high score in model governance with a low score in data plane governance is a warning sign. A high score in security with a low score in authority placement is a warning sign.

The goal is not to win the assessment. The goal is to find the places where governance language has not yet become operating reality.

Buyer Room Use Case

This assessment is also useful for vendors.

Enterprise AI vendors often believe they are selling model performance, developer productivity, infrastructure efficiency, or platform consolidation. Those things matter. But executive buyers are increasingly trying to understand where trust, risk, security, governance, and accountability show up in the actual operating model.

A Buyer Room built around this assessment can expose how CIOs, CTOs, CISOs, data leaders, and platform teams evaluate AI platforms beyond feature lists.

The session can test questions such as:

How do buyers classify AI system authority using the same authority model defined in the Field Guide?

Where do they expect governance controls to live?

What evidence do they need before expanding from pilot to production?

Which risks belong to the vendor, which belong to the customer, and which are shared?

Where does the buyer believe the vendor story is credible, and where does it feel like governance theater?

This maps directly to the Field Guide’s procurement rule: do not ask whether a platform supports AI governance. Ask where the control lives.

That last question is often the most valuable one.

Vendors do not need another generic message test. They need to understand whether their product story maps to how enterprise buyers assign responsibility.

Closing Argument

AI TRiSM is useful because it gives the enterprise a shared language for trust, risk, and security.

But shared language is only the beginning.

The hard work is placement.

Where does the control live? Who owns it? When is it enforced? What evidence proves it worked? What happens when the system changes? Who has authority when the AI system, the human reviewer, the workflow engine, the policy layer, and the business owner all touch the same decision?

That is where enterprise AI governance becomes real.

AI does not fail only because the model is wrong. It fails because the organization cannot explain who had authority when the system acted.

This assessment is designed to make that failure visible before it becomes expensive.