AI 扩展计划 / Playbooks

ABPA 模板 09：Operating Model RACI

R = responsible, A = accountable, C = consulted, I = informed.

90 行abpa/templates/09-operating-model-raci.md

AI Operating Model And RACI

Use this to define how the AI product will be governed after the prototype. A good AI solution has owners for data, evals, model changes, incidents, and adoption.

Operating Model Scope

Field	Answer
AI product / capability
Business process
Operating phase	discovery / pilot / production / scale
Sponsor
Product owner
Architecture owner

Core Workstreams

Workstream	Purpose	Key artifact
Product and workflow	user value, backlog, workflow fit	PRD / roadmap
Data and knowledge	source data, labels, knowledge quality	Data Readiness Pack
Model and prompt	model selection, prompt changes, tool behavior	ADR / prompt registry
Eval and quality	test sets, graders, release gates	Eval report
Risk and compliance	controls, audit, policy alignment	AI Control Pack
Platform and integration	APIs, auth, observability, cost	Architecture runbook
Change and adoption	training, usage, communications	Adoption Dashboard

RACI Matrix

R = responsible, A = accountable, C = consulted, I = informed.

Activity	Sponsor	Product	BA	Architect	Data owner	Risk / compliance	Engineering	Operations	Frontline users
Approve business case	A	R	C	C	C	C	I	I	I
Define workflow and requirements	I	A	R	C	C	C	C	C	C
Approve data access	I	C	C	C	A/R	C	C	I	I
Maintain labels / ground truth	I	C	R	I	A/R	C	C	C	C
Approve architecture ADRs	I	C	C	A/R	C	C	R	C	I
Approve release gate	I	A	R	R	C	C	R	C	I
Review AI risk controls	I	C	C	C	C	A/R	C	C	I
Respond to production incident	I	A	C	R	C	C	R	R	I
Own adoption and training	I	A	R	I	I	C	C	R	C

Governance Cadence

Meeting	Cadence	Decisions made	Inputs	Outputs
Product triage	weekly	backlog priority	user feedback, metrics	updated roadmap
Eval review	weekly / biweekly	release readiness	eval report, failure cases	go / fix / stop
Risk review	monthly	control changes	incident log, audit sample	risk register update
Architecture review	monthly / per release	ADR changes	cost, latency, quality	accepted ADR
Steering review	monthly / quarterly	funding and scope	business case, adoption	executive decision

Change Control

Change type	Examples	Required approval	Required evidence	Rollback plan
Prompt change	instructions, output format	Product + Eval owner	regression eval	previous prompt version
Model change	provider, model version	Architecture + Product	quality, cost, latency report	fallback model
Knowledge change	policy corpus, SOP version	Data owner + Risk	source version diff	previous index
Tool permission change	new system action	Architecture + Risk	threat review, test log	disable tool
Workflow change	approval step, queue routing	Product + Operations	user test, metric impact	old workflow

Incident Model

Severity	Definition	Required action
Sev 1	customer harm, regulatory breach, material financial risk	stop / disable / notify
Sev 2	repeated wrong recommendations or data exposure risk	hotfix and review
Sev 3	quality degradation or workflow disruption	backlog fix
Sev 4	minor usability issue	normal triage

Capability Maturity

Capability	Level 1: ad hoc	Level 2: repeatable	Level 3: managed
Requirements-to-eval	notes only	mapped tests	release gates
Data governance	manual pulls	named owners	monitored freshness
Risk controls	checklist	control owners	audited controls
Observability	logs only	dashboards	alerting and response
Adoption	training once	feedback loop	adoption experiments

Open Operating Questions

Question	Why it matters	Owner	Due date