AI can contribute, but it is not accountable

1832. Lesson identity

Module

4.12 — Teams and roles

Lesson

AI can contribute, but it is not accountable

Academic type

Concept

Schema type

text

Order

Lesson 1 in the module

Estimated time

30–40 minutes, including practice

1833. Learning objective

After this lesson, you can assign a human owner, reviewer, approver, and decision boundary for a set of AI-assisted production decisions.

1834. Why this matters

AI can propose code, content, tests, plans, and alternatives quickly. It cannot accept responsibility for whether a decision is appropriate for the game, the team, or the delivery plan. Without explicit ownership, a team can mistake generated output for an approved production decision. Clear roles make it possible to use AI aggressively while keeping judgment, approval, and consequences with identifiable people.

1835. Prior knowledge

You should have completed 4.11 L3 — Build the Stage 4 delivery plan. You should be able to describe a delivery item, its required evidence, its owner, its reviewer, and the response when required scope is missing.

1836. Core concept

AI participation and human accountability are different things.

An AI system may contribute an option, draft, analysis, implementation, or test result. A human must still own the decision: defining what is acceptable, checking the evidence, approving the result, and deciding what happens when the result is incomplete or wrong.

For each important production decision, separate four responsibilities:

• Owner: The human responsible for moving the decision to a usable state and making sure the required evidence exists.
• Contributor: A person or tool that supplies analysis, implementation, alternatives, or other input. AI may be a contributor.
• Reviewer: The human who examines the decision or evidence against explicit criteria and records concerns.
• Approver: The human with authority to accept or reject the decision within the stated scope. The owner and approver may be the same person only when the team deliberately accepts that arrangement.

These roles describe responsibility for a decision, not merely who touched a file. A person who asks AI for a proposal is not automatically the owner of the resulting decision. Conversely, an owner may delegate implementation while retaining responsibility for the result.

1837. Mental model

Use the decision-rights card for every consequential production decision:

The reusable sequence is:

ASSIGN → CONTRIBUTE → REVIEW → APPROVE → RECORD

AI can participate in CONTRIBUTE and can help prepare material for REVIEW. It does not replace the human roles in ASSIGN, APPROVE, or the accountability represented by RECORD.

1838. Concrete example

Suppose a team must decide whether a new enemy behavior belongs in the next delivery slice.

• The owner is the gameplay lead. They define the decision, gather the test evidence, and keep the item moving.
• An AI assistant is a contributor. It proposes behavior rules, edge cases, and a test checklist.
• A designer is a contributor who checks whether the behavior supports the intended player experience.
• A programmer is a contributor who implements a candidate and reports technical constraints.
• A QA lead is the reviewer. They test the behavior against the agreed criteria and record failures or unresolved risks.
• The production lead is the approver for inclusion in the delivery slice. They can reject the decision if the evidence is incomplete or the scope boundary is exceeded.

The AI-generated checklist may be useful, but it does not approve the behavior. If the checklist misses an edge case, the owner and reviewer must identify that gap. The team does not get to say that the AI was responsible because the AI suggested the test.

Technical accountability example

An AI assistant proposes an implementation, and a human programmer commits the accepted change. The team assigns the programmer as the owner of the technical decision, assigns another human as the reviewer, and restricts the protected branch so that the change cannot be merged without that review. The programmer's commit authorship shows who created or recorded the change; it does not, by itself, prove complete ownership, review, or approval.

Map this situation to the decision-rights card: the decision is whether the change satisfies the stated acceptance criteria; the contributor may include the AI assistant and programmer; the owner is the named human responsible for the change and its evidence; the reviewer owns the technical review; branch permissions enforce part of the approval boundary; and the review record is the evidence. A permission setting supports the process, but it does not replace a human decision or make the AI accountable.

1839. AI-native workflow

Use AI as a bounded contributor rather than as an invisible decision-maker:

1. State the decision, scope, constraints, and acceptance criteria.
2. Ask AI for alternatives, risks, missing cases, or a draft artifact.
3. Compare the output with the decision-rights card and the actual game requirements.
4. Have the named human reviewer inspect the relevant evidence.
5. Have the named approver accept, reject, or request changes.
6. Record the human decision, the evidence used, and any unresolved uncertainty.

A useful prompt asks AI to expose uncertainty instead of granting itself authority:

“For this decision, list possible options, assumptions, failure cases, and evidence we should collect. Do not choose the final option. Keep the recommendation within the stated scope.”

Treat the response as input to judgment. Do not describe an AI-generated recommendation as an approval, review, or team decision.

1840. Common mistake

The most common mistake is assigning a tool a role that requires authority: “AI reviewed the change,” “the assistant approved the plan,” or “the generated test proves the feature is ready.” A generated analysis may support a review, but review requires a human applying criteria. Approval requires a human with decision rights accepting the result. If no person is named, accountability is missing.

Another mistake is naming a single person as owner without defining what they can decide. Ownership without a boundary creates either hidden vetoes or accidental authority. State both the responsibility and the limit.

1841. Guided practice

Create decision-rights cards for three AI-assisted production decisions from the Stage 4 delivery plan. Choose decisions from different categories, such as:

1. accepting an AI-assisted code change,
2. selecting between two generated content options, and
3. changing the scope of a delivery item after review finds a risk.

For each card, write:

• the exact decision,
• one human owner,
• the possible AI contribution,
• the human reviewer and review criterion,
• the human approver,
• the authority boundary,
• the evidence required, and
• the escalation path if the reviewer and owner disagree.

Then test each card with this question: Could a person outside the team identify who must answer if the decision causes a problem? If the answer is no, revise the owner, boundary, or escalation path.

1842. Validation / evidence

Your evidence is three completed decision-rights cards. Each card must:

• name a human owner and a human approver,
• distinguish contribution from review,
• state a review criterion rather than merely naming a reviewer,
• define an authority boundary,
• identify evidence that can be inspected, and
• specify what happens when evidence is missing or roles disagree.

A card is not complete if it says only “the team reviews it” or “AI checks the result.” The decision must be traceable to a person with the authority and obligation to act.

1843. Key takeaways

• AI can contribute analysis, drafts, implementation, and alternatives; it cannot carry human accountability.
• Ownership means moving a decision forward and ensuring that evidence exists.
• Review applies explicit criteria; approval is an authority to accept or reject within a boundary.
• Commit authorship identifies a technical action, but it is not complete ownership without assigned review, approval, and decision rights.
• Every consequential AI-assisted decision needs named human decision rights and an escalation path.
• Record the human decision and evidence instead of treating generated output as approval.

1844. Next lesson

Continue to 4.12 L2 — Make the handoffs visible.

1845. Knowledge check