目录
AI Operating Model / RACI / Runbook
核心问题: AI 系统上线后仍在持续变化。模型、提示词、知识库、供应商、权限、数据、流程和用户行为都会改变系统输出。如果没有明确的运行模型, AI 会从受控能力退化成无人真正负责的生产风险。
系统边界: 本手册聚焦金融零售企业的生产 AI 运行机制, 覆盖 RAG、copilot、agent、工作流自动化、模型网关、知识库、评测、事故处理、供应商变更、采用效果和治理节奏。它不替代法律、合规、审计、模型验证或生产批准结论。
运行判断: AI launch is not the finish line. Production AI needs operating ownership, measurable controls, change discipline, incident routes, evidence capture and business-value review.
Source Anchors
这些来源提供运行模型语言。正式项目仍需结合机构政策、司法辖区、业务域和技术架构确认。
1. 核心问题: 生产 AI 为什么需要运行模型
传统系统上线后主要面对容量、缺陷、权限和发布问题。生产 AI 还会面对行为漂移和上下文漂移:
变化源 典型表现 运行风险 模型版本 供应商调整模型、路由或安全策略 旧评测不再代表新行为, 拒答、幻觉和成本变化 提示词 团队为改善体验直接改系统提示词 行为边界、输出格式、拒答策略和合规措辞漂移 知识库 政策、产品、费用、流程、FAQ 更新 RAG 引用过期, 客服或员工得到旧规则 工具权限 agent 从只读扩展到写入或外发 由回答错误升级为行动错误 用户行为 员工复制输出、绕开复核、批量使用 人工监督失效, 形成事实自动化 供应商 SLA、区域、日志、训练配置或模型公告变化 数据边界、可用性和审计证据失控 监管和政策 新义务、审计发现、投诉趋势 上线时合规但运行中失配
运行模型要回答的不是“谁参加会议”, 而是以下问题:
Who owns the AI capability and residual operating risk?
Who owns data, knowledge and allowed sources?
Who approves model, prompt, index, tool and workflow changes?
Who monitors quality, safety, cost, adoption and control effectiveness?
Who handles incidents and customer-impact decisions?
Who can pause, roll back, degrade or retire the capability?
Who proves business value and decides whether to scale?
2. 运行模型总架构
成熟的 AI 运行模型应被设计成一个闭环系统:
Inventory and ownership
-> risk tier and operating controls
-> data / knowledge / tool readiness
-> release and change gates
-> production monitoring
-> incident and issue management
-> adoption and value review
-> architecture and policy feedback
层级 核心问题 关键产物 Ownership layer 谁对业务结果、流程、数据、平台、风险和证据负责 owner map、RACI、delegated authority Control layer 哪些控制在运行时真实生效 control matrix、policy decisions、tool permission、human review Evidence layer 如何证明系统按批准方式运行 trace schema、dashboard、eval report、issue log、attestation Change layer 模型、提示词、索引、工具、供应商和流程如何变更 change request、regression eval、rollback plan、materiality rule Incident layer 发生幻觉、越权、泄露、停机或质量退化时如何处置 severity matrix、runbooks、postmortem、corrective actions Value layer AI 是否真正改善流程, 是否值得继续投入 adoption metrics、baseline comparison、cost per outcome、scale decision Governance layer 运行发现如何进入政策、架构标准和投资取舍 quarterly review、architecture decision record、risk acceptance
运行模型的价值在于减少三类失败: 第一, 控制只存在于文档中; 第二, 问题发生后找不到决策权; 第三, 用例持续扩张但证据、人员和平台能力没有同步扩张。
3. 角色与责任边界
角色不是职称清单, 而是运行责任的边界。一个人可以承担多个角色, 但每项责任必须有明确 owner 和替代人。
Role Operating responsibility Evidence owned AI capability owner 对业务目标、范围、价值、路线图、上线建议和停止建议负责 use case record、roadmap decision、value review Business process owner 对受影响工作流、人工职责、SOP、容量和操作风险负责 process map、SOP、review queue metrics、fallback plan Process analysis owner 对流程状态、需求证据、例外路径、验收条件和 stakeholder alignment 负责 workflow model、requirements trace、acceptance evidence Solution architect 对系统边界、集成、非功能属性、控制点、日志、回滚和降级设计负责 architecture view、ADR、trace design、rollback record Data owner 对源数据质量、访问、血缘、留存、最小化和数据合约负责 data inventory、quality SLO、lineage、access review Knowledge owner 对政策、产品内容、FAQ、SOP、知识库版本和有效日期负责 corpus registry、source approval、freshness evidence Model and platform owner 对模型网关、路由、可用性、供应商版本、成本和平台控制负责 model route registry、SLA report、gateway logs EvalOps owner 对 golden set、回归评测、红队样本、阈值和质量仪表盘负责 eval suite、release gate result、quality dashboard Risk and compliance owner 对风险分类、政策解释、挑战意见、例外、控制标准和证据要求负责 risk assessment、challenge memo、exception record Security and privacy owner 对身份权限、数据保护、DLP、供应商安全和隐私事件路径负责 security review、privacy assessment、DLP evidence Operations lead 对日常采用、用户支持、缺陷分流、培训和一线反馈闭环负责 adoption dashboard、support log、training record Vendor owner 对供应商合同、SLA、模型变更通知、区域、日志和退出方案负责 vendor review、notice log、exit plan Frontline champion 对用户反馈、实践障碍、信任缺口和工作流适配反馈负责 feedback log、training insight、defect examples
职责设计的基本原则:
业务结果由第一线 owner 承担, 不应由治理团队代持。
数据、知识、模型和工具分别有 owner, 因为它们的变更节奏和失败模式不同。
风险、合规、安全和隐私提供标准、挑战和监控要求, 但不替代业务对残余运行风险的负责。
架构责任包括证据生成能力, 不是只画系统图。
运行责任必须覆盖工作日、非工作日、供应商事故、紧急禁用和回滚。
4. RACI: 用例准入与范围定义
用例准入阶段决定 AI 是不是正确工具、风险是否可控、基线是否存在、上线后是否有人运营。
Activity Capability owner Process analysis Process owner Architect Risk Data owner Operations Identify business problem A R R C C I C Define baseline metrics A R R I C C R Assess AI fit and no-AI option A R C C C C C Define allowed and prohibited use A R R C C C C Initial risk tier C C C C A/R C I Discovery decision A R A C C C C
准入质量标准:
Check Failure mode Pass condition Business problem 为使用 AI 而找场景 有人工基线、痛点证据、价值指标和不使用 AI 的比较 Scope 用例名称过宽 明确用户、渠道、流程步骤、允许动作和禁止动作 Risk tier 先试点后补风险判断 在 discovery 前做初始风险分类, 高风险场景设更高证据预算 Baseline 只看模型 demo 有处理时长、错误率、返工、投诉、成本或覆盖率基线 Operating owner 项目团队负责到上线为止 指定上线后的流程、知识、数据、平台和事故 owner
5. RACI: 数据与知识就绪
RAG 和 copilot 的质量通常由知识库和数据治理决定。运行模型必须把 source-of-truth、权限、有效期和删除路径前置。
Activity Capability owner Process analysis Architect Data owner Knowledge owner Security / privacy Risk Source inventory C R C A/R R C C Data classification I C C R C A/R C Access control design I C R C C A/R C Knowledge versioning C C C I A/R C C Retention and logging C C R C C A/R A/R Data readiness sign-off C R C A/R A/R C C
控制设计要点:
RAG corpus 必须有 owner、purpose、allowed users、effective date、retention 和 sensitivity。
权限过滤必须在 retrieval time 执行, 不能只依赖生成后过滤。
知识更新要触发回归评测, 尤其是费用、信贷政策、投诉处理、KYC、反洗钱和适当性规则。
日志和评测集不应成为新的未治理数据湖。
数据删除、同意撤回和权限撤销要能传播到索引、缓存、记忆、日志和供应商副本。
6. RACI: 模型、提示词、索引、工具和供应商变更
生产 AI 的关键不是“能不能改”, 而是“什么变化足以改变风险”。高影响场景必须把行为变化纳入变更门禁。
Activity Capability owner Architect EvalOps Knowledge owner Platform owner Risk Operations Change request A/R C C R C C C Impact assessment A R R R C C C Regression eval C C A/R C C C I Risk review C C C C I A/R I Release approval A R R C R C C Rollback decision A R R C R C R
Material change examples:
Change Why it matters Default handling Model route or provider changes 能力、拒答、上下文、安全策略、成本和延迟可能变化 regression eval、canary、rollback plan、vendor review System prompt changes 改变角色、边界、输出格式和拒答逻辑 prompt diff、targeted eval、approval、post-release sampling RAG corpus or index refresh 影响依据来源、有效日期和检索结果 freshness test、citation eval、source owner sign-off Tool permission expansion 从建议进入执行或外发 policy check、approval workflow、idempotency、audit trace Workflow automation change 改变人工复核、默认采纳或升级路径 process simulation、capacity check、control owner review Vendor terms or region changes 数据处理、留存、训练、审计权和驻留边界变化 third-party risk review、privacy/security review、exit option
7. RACI: 事故响应与问题整改
事故响应不是单独的技术流程。AI 事故往往同时涉及客户影响、合规判断、数据保护、模型行为、运营流程和供应商责任。
Activity Capability owner Operations Architect EvalOps Risk Security / privacy Vendor owner Triage incident A R R R C C C Severity classification A R C C A/R C C Containment A R R C C A/R R User or customer communication A/R R I I C C I Root cause analysis C R R R C C C Corrective action A R R R C C C Postmortem A R R R A/R C C
Severity 参考:
Severity Definition Response Critical 已造成或极可能造成客户伤害、监管违规、未授权工具动作、重大泄露或资金损失 stop route、executive escalation、customer-impact assessment、formal incident process High 高风险流程控制失效, 但可通过人工、回滚或流量控制缓解 restrict scope、increase review、open high issue、root cause deadline Medium 局部质量、流程或监控缺口影响效率或中等风险输出 fix with due date、targeted regression、monitor recurrence Low 文档、格式、体验或低影响缺陷 track in backlog and review trend
8. 治理节奏
运行节奏要匹配风险等级和变化速度。低风险内部工具不需要重治理, 高影响场景不能只靠季度会议。
Cadence Forum Inputs Decisions Daily during pilot Pilot operating standup incidents、feedback、defects、queue health quick fixes、support、scope restriction Weekly AI quality review eval results、override、complaints、unsupported answers prompt/index/tool fixes、new eval cases Biweekly Product and operations adoption review adoption dashboard、workflow metrics、training feedback rollout adjustment、training、UX changes Monthly AI risk and governance review risk register、incidents、model changes、exceptions risk acceptance、control changes、gate decisions Quarterly AI capability review value、cost、quality trend、vendor review、residual risk scale、refresh、merge、retire、platform investment Event-driven Material change or incident forum change request、incident record、vendor notice、regulatory signal pause、rollback、release gate、exception
会议质量标准:
每次 forum 都有明确 decision type: approve, hold, reduce scope, escalate, remediate, retire。
指标只作为证据, 不是会议目的。会议要做决策。
过期问题、重复问题和控制漂移必须进入升级路径。
高风险例外必须有到期日、补偿控制、监控指标和退出路径。
9. 必备运行资产
Artifact Purpose Minimum content AI use case inventory 确认生产 AI 在哪里、谁负责、影响什么 use case、risk tier、owner、status、approved use、controls Owner map 防止责任模糊 business、process、data、knowledge、platform、risk、security、vendor owners RACI 明确设计、变更、事故和运营决策 activities、accountable owner、responsible teams、consulted/informed roles Data and knowledge registry 管理 RAG 和数据依赖 sources、owner、sensitivity、freshness、retention、allowed use Prompt/model/index registry 支持版本化和回滚 model route、prompt hash、index version、tool schema、release status Eval dashboard 判断质量和风险是否仍在门槛内 golden set、red-team、threshold、failures、trend Incident log 追踪事故、近失和根因 severity、impact、containment、root cause、corrective action Risk register 管理残余风险和例外 risk statement、control、owner、review date、status Change log 管理行为变更 request、materiality、approval、eval delta、rollback Adoption dashboard 判断工作方式是否安全改变 active users、eligible cases、accept/edit/reject、training gaps Vendor review log 管理外部依赖 SLA、model notice、region、data terms、incident、exit readiness Quarterly capability review 决定继续、扩展或退役 value、risk、cost、control maturity、roadmap decision
10. Runbook: Hallucination or Unsupported Answer
Trigger
输出包含无依据事实。
引用错误、引用不支持结论或引用过期。
用户报告答案错误。
质量抽样发现虚构理由或政策。
Capture request id, prompt hash, source ids, model route, output, user role and channel.
Classify severity by customer impact, regulatory relevance and whether answer reached final workflow.
For high severity, disable affected route, force human review or switch to fallback source.
Notify capability owner, operations, EvalOps, architecture and risk owners.
Diagnosis
Question Evidence Was the correct evidence available? source registry、index version、top-k retrieval trace Was retrieval wrong or stale? citation log、effective-date metadata、reranker score Did prompt over-instruct or under-constrain? prompt diff、system instruction review Did model ignore evidence? answer trace、judge score、manual review Did evaluator miss this case? eval coverage map、similar failure samples
Corrective Actions
Add the failure to golden set or challenge set.
Fix retrieval metadata, source freshness or chunking.
Update prompt, output schema or citation validator.
Add low-confidence human review for similar scenarios.
Update monitoring threshold and open issue with closure evidence.
Postmortem Questions
Which control was expected to catch this?
Why did the release gate or monitoring miss it?
Is the root cause local to one use case or a reusable platform control gap?
What evidence proves the corrective action works?
Trigger
Model follows instructions embedded in retrieved content.
User asks model to bypass policy, reveal hidden rules or call forbidden tools.
Tool call attempts unauthorized lookup, write, notification or account action.
Retrieval content includes hostile instructions or data exfiltration pattern.
Stop affected tool route if side-effect risk exists.
Preserve prompt, retrieved content, tool request, policy decision and result trace.
Notify security, architecture, risk, capability owner and operations.
Review access policy, action policy and whether any customer-impacting action occurred.
Diagnosis
Question Evidence Was retrieved content treated as data, not instruction? prompt hierarchy、content sanitization record Did entitlement filter run before retrieval and tool call? access decision log、deny log Did tool gateway enforce action policy? policy decision、approval token、tool schema Was red-team coverage sufficient? prompt injection test cases、release results Was the user interface making unsafe action too easy? UX state、confirmation flow、operator feedback
Corrective Actions
Add prompt injection and tool misuse tests.
Harden content sanitization and instruction hierarchy.
Add explicit action approval for side-effect tools.
Reduce tool scope, add rate limits or require exact identifiers.
Train operators on unsafe prompts and escalation route.
12. Runbook: Data Leakage
Trigger
Output includes unauthorized customer, account, employee or third-party data.
Logs contain sensitive fields beyond approved schema.
RAG citation exposes restricted title, path or case metadata.
Vendor, observability or annotation tool receives unapproved data.
Stop affected route or restrict to safe mode.
Preserve evidence in controlled store without expanding exposure.
Identify data classes, affected subjects, systems, logs and external processors.
Notify security/privacy, risk, legal/compliance, capability owner and incident command.
Determine whether customer notification, regulatory notification or contractual notice may be required under institutional process.
Diagnosis
Question Evidence Which control failed: input, retrieval, tool, output, log or vendor? data flow、DLP event、trace Was data needed for the approved purpose? minimization record、allowed use matrix Did access control run at source and retrieval time? source entitlement、retrieval filter log Did logs preserve raw payload by design? trace schema、redaction pipeline Did vendor terms and configuration prohibit training and retention? vendor record、gateway configuration
Corrective Actions
Patch DLP or redaction rules and replay representative traces.
Remove or quarantine affected index, cache, memory and logs.
Update data copy map and deletion verification.
Add regression tests for the leaked data class.
Review vendor configuration and contractual evidence.
13. Runbook: Model or Provider Outage
Trigger
Model API unavailable or degraded.
Latency, timeout or cost spike affects service level.
Provider announces behavior, region, logging or route change.
Approved model route unavailable and fallback not automatically selected.
Switch to approved fallback model, retrieval-only mode or manual process.
Cap traffic or disable non-essential workloads.
Notify platform, operations, vendor owner and affected business owners.
Communicate expected operational impact and manual workaround.
Diagnosis
Question Evidence Is this provider outage, network issue, quota, rate limit or internal gateway failure? gateway metrics、provider status、network logs Are fallbacks behaviorally approved for this use case? fallback approval、eval comparison Did degraded mode preserve customer and regulatory controls? SOP、manual queue、control log Did cost controls prevent runaway spend? cost dashboard、quota policy
Corrective Actions
Add provider health check and automatic safe degradation.
Validate fallback quality and refusal behavior.
Update capacity planning, quota alerts and vendor SLA review.
Add outage scenario to quarterly tabletop.
14. Runbook: Eval Regression
Trigger
Regression suite falls below release threshold.
Golden set trend degrades after model, prompt, index or tool change.
New topic cluster lacks coverage.
Judge and human expert scores diverge materially.
Hold release or block scale request.
Preserve eval run id, dataset version, model route, prompt hash and index version.
Compare with previous approved run.
Classify failures by severity and business workflow.
Diagnosis
Question Evidence Is degradation caused by model, prompt, retrieval, data, judge or sample shift? eval diff、trace sample、component version Are thresholds still aligned with risk appetite? release gate、risk tier、control matrix Did new failures expose missing requirements? failure taxonomy、issue log Is judge scoring calibrated? human review sample、judge drift metric
Corrective Actions
Add new samples for uncovered topic or failure mode.
Fix component and rerun targeted regression before full run.
Recalibrate judge or require human review for high-risk samples.
Update release gate and change materiality rules if needed.
15. Runbook: Knowledge Staleness
Trigger
Source policy, product, fee, procedure or regulatory content changes.
RAG cites old document after effective date.
Knowledge owner misses freshness review.
User reports answer contradicts official portal or SOP.
Identify affected corpus, document ids, effective dates and use cases.
Freeze or roll back index if stale content may affect customer or regulated workflow.
Route affected questions to human or official source.
Notify knowledge owner, capability owner, EvalOps and risk.
Corrective Actions
Repair source metadata and effective-date filter.
Rebuild index and run stale-citation regression.
Add source-change event trigger to change process.
Set freshness SLO and overdue escalation.
Review whether other use cases share the same corpus.
16. Runbook: User Trust Drop
Trigger
Adoption drops despite eligible workload.
Accepted suggestion rate falls while edit or reject rate rises.
Qualitative feedback says output is too long, too vague, risky or not trustworthy.
Users bypass AI or use unofficial tools.
Diagnosis
Question Evidence Is the issue quality, latency, workflow fit or accountability fear? adoption dashboard、feedback tags、session replay Are users seeing evidence and limitations clearly? UI review、citation visibility、copy Is AI output too hard to edit or verify? edit distance、time saved、operator notes Are managers pushing blind acceptance? training record、override trend Does the use case need narrower scope? failure pattern、eligible case segmentation
Corrective Actions
Improve evidence display, citations and short-form output.
Narrow scope to tasks with high trust and clear value.
Add feedback-to-eval loop and show users fixes made.
Train champions with specific workflow examples.
Clarify accountability and safe override expectations.
17. 金融零售运行模式示例
AML Copilot
Area Operating design Business boundary Assists analysts with evidence organization and narrative draft; final disposition and suspicious activity conclusion remain with authorized analyst. Owners Financial crime operations owns workflow; compliance owns SAR boundary; knowledge owner owns SOP and typology library; EvalOps owns red-flag eval; architecture owns audit and retrieval/tool controls. Cadence Weekly case-quality review, monthly typology refresh, quarterly risk review. Evidence Source-span linkage, analyst approval event, narrative edit diff, typology coverage, issue/action log. Runbook focus Unsupported narrative, typology drift, source evidence gap, analyst over-reliance.
Customer Service RAG
Area Operating design Business boundary Supports agents with approved-source answers and drafts; fee disputes, complaints and account actions route to controlled workflows. Owners Knowledge manager owns articles; contact center operations owns adoption; quality team owns answer sampling; capability owner owns roadmap; EvalOps owns policy regression. Cadence Weekly source freshness review, weekly quality sample, monthly complaint linkage review. Evidence Source approval, citation accuracy, stale-source alerts, agent edit/reject reasons, customer complaint linkage. Runbook focus Outdated policy, unauthorized promise, escalation miss, privacy leakage.
Payments Exception Agent
Area Operating design Business boundary Recommends repair steps and prepares draft work items; payment rail actions require deterministic tool policy and approval. Owners Payment operations owns process; architecture owns tool gateway; operational risk owns action approval criteria; platform owns idempotency and audit trace. Cadence Daily exception queue health, weekly duplicate-action review, monthly payment rail dependency review. Evidence Tool decision log, approval token, idempotency key, rollback or compensation record. Runbook focus Duplicate action, wrong repair recommendation, rail outage, unauthorized tool attempt.
Lending Assistant
Area Operating design Business boundary Finds policy, prepares document checklist and drafts explanation for internal review; does not decide approval, decline, limit or adverse action. Owners Credit policy owns content; underwriting owns final decisions; compliance owns fair lending review path; EvalOps owns reason-code and citation eval. Cadence Monthly policy-source review, monthly override and complaint review, quarterly fairness challenge. Evidence Policy citation, reason-code mapping, underwriter approval, override reason, adverse action evidence link. Runbook focus Unsupported reason code, protected-factor proxy issue, incorrect policy citation, stale policy.
18. Adoption and Change Management
Adoption is not login count. Adoption means users safely change how work is done while controls remain effective.
18.1 Adoption Metrics
Metric What it proves Failure signal Eligible users activated Training and access reached intended population Capability exists but workflow not adopted Eligible cases touched AI is used in the target workflow, not only by enthusiasts Low case coverage suggests workflow fit problem Repeat usage Users find recurring value One-time demo usage Accept / edit / reject mix Whether output is useful and controlled Blind acceptance or universal rejection Override reasons Why human judgment differs from AI Missing policy, wrong context, trust issue Time saved Value against baseline Efficiency claim unsupported Quality defects Risk and rework impact AI increases downstream QA issues Escalation rate Boundary and uncertainty handling Too many escalations or missed escalations Trust survey themes Human factors and explainability Users fear blame, audit or replacement
18.2 Trust-Building Controls
Start with read-only or draft support in high-risk domains.
Show source, version, evidence and limitations at the point of use.
Keep the authorized human role able to edit, reject, escalate and pause.
Capture feedback inside the workflow, not in disconnected surveys only.
Close the feedback loop by adding real failures to eval and communicating fixes.
18.3 Resistance Handling
Resistance Operating response AI will replace my judgment Position and design it as decision support; final authority stays in named workflow roles. AI makes mistakes Show eval results, citations, human review and issue closure evidence. It slows me down Shorten outputs, reduce clicks, improve context prefill and remove unnecessary confirmations. I do not know who is accountable Clarify approval boundary, override reason and management expectations. I do not trust the knowledge Show source owner, version, effective date and freshness cadence.
19. Failure Modes and Control Design
Failure mode Root cause pattern Control design Ownerless capability Project team disbands after launch Production owner map, quarterly attestation, support rota Paper control Control described but not instrumented Runtime policy decision log and dashboard evidence Silent scope creep Users apply assistant to unapproved tasks Approved-use binding, usage taxonomy, topic drift monitoring Knowledge drift Source changes without index refresh Source-change event, freshness SLO, stale citation eval Tool overreach Agent gains write or send actions without stronger controls Tool class tiers, approval token, side-effect audit Human oversight theater Reviewer lacks time, authority or evidence Review workflow, workload capacity, override rights, evidence display Vendor surprise Provider changes model or terms without route control Vendor notice process, pinned route, regression gate Evidence gap Logs cannot reconstruct high-risk output Trace schema, retention rule, evidence store, audit query Adoption without value Usage rises but baseline does not improve Value dashboard, stop rule, workflow redesign Over-governance Low-risk cases wait for high-risk committees Risk-tiered gates and reusable platform controls
20. Operating Readiness Check
Before a production release or material scale decision, the team should be able to answer:
Check Pass condition Capability ownership Business outcome, process, data, knowledge, platform, risk, security and vendor owners are named. Approved scope Allowed use, prohibited use, user population, channels and automation level are documented. Data and knowledge readiness Sources are approved, access-filtered, fresh, retained and deletion-aware. Control operation Critical controls have runtime evidence, owner, frequency, threshold and failure action. Change discipline Model, prompt, index, tool, workflow and vendor changes have materiality rules and rollback. Monitoring Quality, risk, cost, adoption and control metrics are live with alert routing. Incident readiness Runbooks exist for hallucination, injection/tool misuse, leakage, outage, regression and stale knowledge. Adoption plan Training, feedback, champions, support and trust metrics are in place. Evidence A sampled high-risk output can be reconstructed from input to final human action. Stop rule The accountable owner can pause, route to human, disable tools, roll back or retire the capability.
21. Connections
Existing asset Use docs/abpa/templates/09-operating-model-raci.mdBaseline RACI structure and responsibility mapping. docs/AI_ARCHITECTURE_REVIEW_GATE_CHECKLISTS.mdRelease gate evidence and architecture review criteria. docs/AI_REQUIREMENTS_TO_EVAL_COOKBOOK.mdConnecting requirements, eval suites and release criteria. docs/AI_VENDOR_BUILD_BUY_ADOPTION_PLAYBOOK.mdVendor dependency, adoption and build-buy governance. docs/AI_GOVERNANCE_EVALOPS_RISK_90_PLAN.mdDeeper governance and EvalOps practice path. docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.mdDrawing system boundary, operating model and runbook architecture.
22. Landing Check
An AI system is not production-ready until the operating model can prove:
Quality has an owner.
Data has an owner.
Knowledge has an owner.
Changes have a gate.
Incidents have a route.
Rollback has authority.
Adoption has evidence.
Business value has a baseline.
Residual risk has a named owner and review date.