Your AI Didn't Make the Decision. It Made the Shortlist.

How much decision-making authority should AI have?

Give AI permission to do work in proportion to the consequences of error, the reversibility of the outcome and the quality of available checks. Generating alternatives is usually easier to delegate than declaring what customers need. Recommending a direction requires inspectable evidence. Consequential changes need a named decision owner who can challenge the premise, not merely approve the output.

This is not a rule that AI must never act. A system can complete well-bounded, low-impact actions under predefined conditions. The mistake is treating the same permission as appropriate for every step of a product workflow.

An assistant that drafts five onboarding headlines and an agent that changes a learner's access to a paid course may use similar technology. They should not inherit similar authority.

The decision can be made before the decision meeting

Most teams know how to put a person in front of a final approval button. Fewer ask what happened to the available choices before the button appeared.

Consider the sequence:

1. Frame. What is the problem called? Is it a usability issue, a reliability issue or an account-access issue?
2. Interpret. Which evidence is grouped together? Which minority experiences disappear inside a broad theme?
3. Recommend. Which options make the shortlist? What alternatives were never compared?
4. Commit. What gets built, changed, promised or funded?

Only the last step looks like a formal decision. The first three can determine its shape.

A human who sees a polished recommendation without the raw evidence may be able to choose yes or no while being unable to ask whether the team is solving the right problem. That's approval, but it isn't much judgment.

The most useful safeguard is therefore upstream: preserve the ability to dispute the model's framing, not just its final recommendation.

GOODSCOOL JOURNAL / FIG. 02

Read full figure transcript

FIG. 02 ILLUSTRATIVE PRODUCT WORKFLOW · SYNTHETIC TICKETS One neat AI label. Two different product problems. An AI summary groups both messages under “Navigation.” The underlying examples suggest separate causes requiring separate investigations. ✦ ≡ ◈ ◷ Support triage / proposed themes RECONSTRUCTION AI SUMMARY · CANDIDATE THEME Primary issue: Confusing navigation Suggested fix: redesign the course dashboard and onboarding tour. ⚑ Framing needs review against source messages EXAMPLE MESSAGE A “I can’t find my lesson.” Discovery Navigation or information architecture EXAMPLE MESSAGE B “I can see the lesson, but can’t open it.” Access Enrollment or entitlement activation Design lesson Both reports mention lessons. Only one necessarily calls for a navigation redesign. Reinspect how the problem was labeled before choosing the solution. Original GoodScool illustration. Neither message is quoted from an actual support record. No incident frequency or customer outcome is being asserted.

↗ Revisit Fig. 01: four decision permissions

What the research actually tells us

An April 2026 study from Microsoft Research surveyed 860 Microsoft developers and identified 22 AI systems respondents wanted built. The authors describe a preference for “bounded delegation”: substantial AI help with supporting work, alongside limits on authority, transparency about sources and uncertainty, and narrowly scoped access.

In a separate July 2026 Microsoft Research preprint, researchers surveyed 448 professional developers at Microsoft. Greater task accountability was associated with lower willingness to let AI act on a developer's behalf. The study also found variation by task and by person.

GOODSCOOL JOURNAL / FIG. 03

Read full figure transcript

EVIDENCE NOTE 01 TWO DISTINCT MICROSOFT RESEARCH STUDIES Developer preference is not blanket AI permission. APRIL 2026 · SURVEY 860 Microsoft developers Respondents described AI systems they wanted built; the authors discuss bounded delegation and transparency. Scope: developer needs and self-reported preferences. View research ↗ JULY 2026 · PREPRINT 448 Microsoft developers Respondents described where and why they place limits on AI autonomy in professional work. Scope: developer preferences, not a causal safety experiment. View research ↗ The sample sizes are not directly comparable performance scores; the studies had different questions and methods. Interpretation belongs to GoodScool, not the authors' measured outcomes.

Source links: View research ↗; View research ↗

These are studies of developers' preferences in software work. They do not prove that one autonomy setting is safe for every UX researcher, startup or product team. Their value here is more specific: capable professionals may welcome substantial automation while still wanting precise control over where authority changes hands.

NIST's voluntary AI Risk Management Framework approaches the issue from a governance perspective. Its Govern and Map guidance calls for clear responsibilities, documented knowledge limits and appropriate oversight processes, while its risk-management approach emphasizes context and ongoing evaluation. It does not prescribe GoodScool's four-stage model.

The shared lesson is not “always keep a human in the loop.” It is define what the system may decide, what it may only suggest and what information a reviewer needs to exercise genuine control.

Four permissions, not one AI on/off switch

Use the following model to decide what authority a particular workflow earns.

These are permissions, not job titles. One AI tool might be authorized to perform several of them in one workflow and only one in another. Higher consequence, lower reversibility, sensitive data or weak evidence calls for tighter limits.

The practical question is not “Can the model do this?” It's “Under what conditions would we be comfortable defending this outcome if it went wrong?”

What meaningful human oversight looks like

Imagine an assistant says: “The primary issue is lesson discovery. Prioritize navigation work.”

A reviewer should be able to do more than edit the slide or approve the ticket. They need the right and the material to ask:

• Show the sources. Which support messages support this theme? Are they representative of the material reviewed, or just memorable examples?
• Show the rival explanation. Could the same complaints indicate access failures, broken links, slow loading or unclear entitlements?
• Show what's absent. Which user groups, channels, dates or edge cases are outside the evidence?
• Show the consequences. What will this recommendation change, what could be harmed, and how will we detect a bad call?

GOODSCOOL JOURNAL / FIG. 04

Read full figure transcript

FIG. 03 ORIGINAL REVIEW INTERFACE · ILLUSTRATIVE Human oversight needs something to inspect. A credible review interface should let a product owner challenge the problem definition—not just click “Approve.” Decision review / course access REVIEW REQUIRED AI RECOMMENDATION Prioritize a navigation redesign. Proposed explanation: learners are unable to locate their lessons. 01 Source trail Open the messages behind the summary. 02 Alternative cause Check access activation or entitlement issues. 03 Unknowns Identify missing channels, dates and segments. 04 Consequence Assess impact, reversibility and error detection. Reviewer conclusion Keep both navigation and access causes open until checked. Conceptual GoodScool UI example, not a screenshot of a deployed system. The four review checks follow the article's editorial recommendations.

If the reviewer cannot inspect and reject the model's assumptions, the oversight process is largely ceremonial.

That does not mean a person has to read every line of every low-risk summary. It means the depth of review must match the stakes, and the workflow must retain an auditable path from claim to evidence. For a consequential decision, representative excerpts alone may not be enough; the reviewer may need access to the underlying dataset, appropriate sampling checks or independent validation.

Put an authority boundary on the actual workflow

Return to the hypothetical learning-product team. Here is a more defensible hand-off:

Research preparation: AI groups the approved support records, but its output is labeled candidate themes. Each theme has linked source records. The team checks whether access failures and navigation difficulties are being wrongly merged.

Option development: AI suggests changes to navigation, account activation and troubleshooting. It states which evidence supports each path and what would falsify it. The product team can add an option the system never proposed.

Decision: A named product owner chooses what to investigate or test next, records the trade-offs and checks the proposal with the relevant team. If the change affects paid access, billing or other significant entitlements, the workflow follows the organization's specific approval and risk controls.

Follow-through: The team observes whether the intervention addresses the original issue. The ability to reverse a release, handle incidents or pause an automated action is part of the authorization—not an afterthought.

Notice what AI still does: a great deal of useful work. The boundary protects the connection between evidence, judgment and accountability rather than forcing people to perform every clerical step.

Write the boundary down before the next prompt

For an AI-supported task, a short authority brief is more practical than a vague promise that someone will review the result.

GOODSCOOL JOURNAL / FIG. 05

Read full figure transcript

FIELD TOOL 01 COMPLETED EXAMPLE · ILLUSTRATIVE POLICY What a bounded task actually sounds like. AI SUPPORT-TRIAGE BRIEF SCOPED EXAMPLE 01 / Task Group already-approved support tickets into candidate themes. Do not infer causes as confirmed facts. 02 / Allowed moves Summarize, classify and suggest. No automatic publication or learner-access changes. 03 / Evidence Link each proposed theme to underlying records, alternatives and known coverage gaps. 04 / Accountable owner Product/support lead can revise or reject the framing and authorize next steps. 05 / Stop / rollback Pause on missing source access or contradictory evidence; withdraw incorrect classifications and re-review before action. This is an example of an editorial decision aid, not organization-specific compliance advice or a deployed workflow. Use the article's copyable exercise to adapt the fields.

This is a proposed GoodScool operating tool, not a compliance certification. Adapt the thresholds to your organization, applicable law, affected users and the actual system's capabilities.

A useful test: If you cannot write the Allowed moves row without using “whatever the AI thinks is best,” you have not set a boundary yet.

The hand-off that matters

A product team's responsibility is not to keep every step manual. It is to remain capable of explaining why a specific customer problem deserved attention, why one option beat another and who accepted the risk of acting on it.

AI can expand the search, organize the evidence and challenge assumptions. Sometimes it can execute routine steps safely within narrow controls. But increased capability should not quietly become permission to define the problem, suppress alternatives and make a commitment on the organization's behalf.

Before asking who approves the AI's answer, ask who approved the question it answered.