Roles, Boundaries, and the AI-Native RACI

Key Takeaways

• AI-native failures often happen between functions because workflows cross old artifact boundaries.
• A useful RACI must include autonomy level, data boundary, customer impact, evidence requirement, and rollback owner.
• Boundary drift is a management event even when the permission model has not changed.
• Responsibility should track consequence, not the team that bought or built the tool.

An AI-native RACI follows consequence, not artifact ownership: the accountable owner is whoever owns what the system may do.

The incident review was awkward because everyone had done their job. Product approved the AI assistant's scope. Engineering implemented the workflow. Legal had reviewed the template three months earlier. Support trained the team. RevOps connected the CRM fields. The assistant still sent the wrong escalation path to a strategic customer because nobody owned the boundary between recommendation and commitment.

AI-native failures often happen between roles, not inside them.

This chapter shows how to draw boundaries around AI-native work. The tool may span product, engineering, legal, support, security, data, and revenue operations. That cross-functional reach is exactly why responsibility must be explicit. A RACI matrix is not bureaucracy when autonomy is involved; it is the minimum map of who decides, who builds, who reviews, who is informed, and who is accountable after action.

Research spine

This chapter uses: Team Topologies, Key Concepts; NIST AI Risk Management Framework; OWASP Top 10 for Large Language Model Applications; Google SRE Book.

Why old boundaries fail

Traditional boundaries often follow artifact ownership. Engineering owns code. Product owns requirements. Legal owns contract terms. Support owns customer response. AI workflows blur these artifacts. A model-generated response may be both product behavior, operational action, legal representation, and customer experience. If each function reviews only its old artifact, the system-level risk can pass through the seams.

Boundary design must follow action and consequence. Who owns the action the system can take? Who owns the evidence that the action is safe? Who owns the customer's interpretation of the action? Who owns rollback when the action is wrong? These questions matter more than which team owns the tool license.

The AI-native RACI

A useful RACI for AI workflows must include five extra fields beyond the classic responsible, accountable, consulted, and informed pattern: autonomy level, data boundary, customer impact, evidence requirement, and rollback owner. Without these fields, the matrix can say who is involved without saying what kind of machine behavior they are involved in.

Autonomy level names whether the system suggests, drafts, decides, or acts. Data boundary names what information the workflow can access. Customer impact names whether the output is internal, reviewed external, or automatic external. Evidence requirement names the eval or review needed before scaling. Rollback owner names who can stop the workflow quickly.

Boundary drift

Boundaries drift as teams become comfortable. A workflow that started as a draft assistant becomes a semi-automatic responder. A recommendation becomes a default choice. A default choice becomes an action. This drift is often invisible because no one formally changed the product; people simply clicked accept faster.

The RACI must therefore be revisited when usage behavior changes, not only when architecture changes. If human review becomes rubber-stamp review, autonomy has increased even if the system's permission model has not. That is a management event.

Operating table

RACI extension	Question	Example
Autonomy level	Does the system suggest, draft, decide, or act?	Draft only until eval passes 90-day review.
Data boundary	Which data can the system read or combine?	CRM notes yes; contract terms no.
Customer impact	Who sees or feels the output?	Internal recommendation vs customer-facing email.
Evidence requirement	What proof is needed before scaling?	Sampled QA, resolution lift, complaint rate.
Rollback owner	Who can stop it?	Support operations lead with kill-switch access.

Artifact example: an AI-native RACI with autonomy fields

ai_workflow_raci:
 workflow: "support escalation recommendation"
 autonomy_level: "recommendation_only"
 data_boundary:
 allowed: ["ticket_text", "account_tier", "recent_incidents"]
 forbidden: ["contract_negotiation_notes", "legal_disputes"]
 accountable: "Director of Support"
 responsible:
 - "Support Ops"
 - "AI Platform"
 consulted:
 - "Legal"
 - "Security"
 - "Customer Success"
 informed:
 - "Sales leadership"
 evidence_required_before_autonomy_increase:
 - "500 reviewed recommendations"
 - "no severity-1 misroutes"
 - "segment-level error review"
 rollback_owner: "Support Ops on-call"

Checklist

• Create a RACI for every AI workflow that can affect customers.
• Add autonomy level and rollback owner to the classic RACI.
• Review boundaries when user behavior changes, not only when code changes.
• Treat data access as part of role design.
• Name the accountable business owner, not just the technical builder.

Takeaway

AI-native responsibility follows consequence, not artifact ownership.

Internal map

For the larger argument, keep this chapter connected to the AI-Native thesis, Building an AI-Native Team, The Judgment Economy, and Human in the Loop Is Not a Plan.