LTRLS Learning Through Real-Life Scenarios
Who owns the AI decision?
Work through 10 fictional manufacturing decisions about AI ownership, vendor evidence, human review and change control. Leave with practical conditions for a better pilot or rollout.
No account needed. Work alone or discuss with a team.
What you will practise
Make the trade-off visible.
Make the owner, evidence, review authority and stopping conditions explicit. These fictional cases let you practise the questions that turn an AI proposal into a decision you can explain.
- Name decision owners and approval conditions.
- Distinguish a successful demo from operational evidence.
- Define human review, change control and stopping conditions.
Built for the people making the call
Fictional educational scenarios adapted from manufacturing workshop material. The recommendations support discussion and do not certify organisational readiness, safety or legal compliance.
- 01
Read the situation
Identify the purpose, people and consequences.
- 02
Make your choice
Confirm a response before opening the reasoning.
- 03
Question the control
Discuss what would need to change in a real workflow.
- 04
Leave with a card
Record an owner, evidence, approval conditions and a stop point.
LTRLS / Practise before the real decision
A situation. A choice. A better question.
You are reviewing AI proposals at a fictional manufacturer. Decide what evidence, ownership and controls you need before approving, changing or retiring each workflow.
Progress and notes stay in this page’s memory. Refreshing, leaving or closing the page loses them. Use anonymous examples and roles.
Running this with a team?
- Use the cases individually or with a small team. The source workshop timing is a guide, not a required countdown.
- For group discussion, assign a sponsor, data owner, security lead, AI owner, risk reviewer and affected-person advocate. Roles may be combined.
- Let participants explain their choice before revealing the recommendation. Ask what would have to change before they could approve the workflow.
- Finish with a control card for one proposed use case. Do not interpret a quiz result as certification or validated readiness.
Prefer to read?
The complete case notes.
The same situations and reasoning, without the interactive flow.
Open all 10 cases
Case 01
The assistant nobody owns
A chatbot answering from manuals, work orders and technician notes has been live for four months. Operations assumes IT owns it. IT assumes the vendor owns it. The vendor says the plant owns the decisions. It is about to be rolled out to a second plant.
What has to happen before it expands?
- Expand it: users already trust it, and trust is the hardest part.
- Name a business owner, a data owner, an AI product owner and a human decision owner; document purpose, users, data and escalation.
- Ask the vendor to accept responsibility for the outputs in the contract.
- Move it to a private cloud before expanding.
Recommended response for this scenario
Name a business owner, a data owner, an AI product owner and a human decision owner; document purpose, users, data and escalation.
Technology and contracts do not replace clear decision ownership. Define responsibility for business outcomes, data, the product and human decisions, including who can stop expansion. One person may hold more than one role where appropriate; the requirement here is clear accountability, not a universal four-person staffing rule.
Practical control: Maintain a use-case record with clear business, data, product and human-decision responsibilities, escalation authority and a review date.
Discuss: Who owns the outcome and has authority to pause the proposed expansion?
Case 02
The demo in perfect light
A vendor demonstrates visual inspection on clean samples, perfect lighting and a known defect catalogue. Accuracy is 98%. The plant head wants to approve production deployment on Monday.
What is the right next step?
- Test in representative production conditions: every shift, real lighting, product variants, rare defects and the actual operator workflow.
- Ask the vendor for a larger model before deciding.
- Adopt the vendor’s global benchmark as the acceptance test.
- Approve production deployment on the strength of the 98% demo result.
Recommended response for this scenario
Test in representative production conditions: every shift, real lighting, product variants, rare defects and the actual operator workflow.
The demonstration does not establish performance across actual production conditions. Test representative shifts, lighting, variants and important defect classes, then assess errors and operator workflow. The quoted 98% belongs to this fictional situation. It is not a validated benchmark or evidence about the human inspection process.
Practical control: Agree the acceptance threshold and the evaluation set before the pilot begins, and write down what the system is not expected to handle.
Discuss: What evidence is missing, and what acceptance conditions would you agree before the pilot?
Case 03
One committee for everything
After an incident, the company creates a single rule: every AI use case, from a meeting-summary tool to an agent that changes process parameters, goes through the same committee, which meets monthly.
Is this a sound governance design?
- No: let each department approve its own use cases.
- No: approve generative AI centrally and ban predictive models.
- Yes: one consistent process is fair and easy to explain.
- No: classify by consequence and apply proportionate controls, with a fast path for low-risk uses and stronger review for high-risk ones.
Recommended response for this scenario
No: classify by consequence and apply proportionate controls, with a fast path for low-risk uses and stronger review for high-risk ones.
Review should match the consequences of a failure. A meeting-summary tool and an agent changing a process setting need different evidence and approval depth. A heavy universal queue may encourage workarounds. Define proportionate tiers, ownership, review targets and exceptions while preserving basic controls for every use case.
Practical control: Define review tiers based on consequence, with evidence requirements, owners, exceptions and appropriate turnaround targets.
Discuss: How would the approval route differ for a summary tool and an agent controlling equipment?
Case 04
The AI says stop the line
A quality model flags a batch as defective and recommends stopping production. The operator sees a red alert. No image, no threshold, no comparison, no source evidence: just the alert and a decision to make in ninety seconds.
What should the plant require before that alert can stop production?
- Remove the operator from the loop entirely to avoid inconsistent human judgement.
- Require the operator to follow the model: hesitation is what lets defects through.
- Provide the evidence, define who has review authority, measure false positives and negatives, and set the escalation path first.
- Treat model alerts as advisory only and let operators use their own judgement.
Recommended response for this scenario
Provide the evidence, define who has review authority, measure false positives and negatives, and set the escalation path first.
A human cannot meaningfully review an alert without evidence, time and authority. Show the relevant image or source, define thresholds and escalation, and determine the safe operational response. The right process also depends on the plant’s existing safety requirements; this exercise does not override them.
Practical control: Before any model output can halt production: show the evidence, name the override authority, publish the error rates, and define the safe state.
Discuss: What does the operator need to see, decide and escalate when the alert arrives?
Case 05
Only a shortlist
A hiring model filters out candidates whose CVs show employment gaps. HR notes that it is only a shortlist: a human still makes every final decision: and that it saves the team about nine hours a week.
Is “only a shortlist” an adequate governance position?
- Yes: no final decision is automated, and the time saving is real.
- No: a filter that decides who is seen is consequential. Test for disparate impact, document the criteria, provide human review and monitor outcomes.
- No: remove the word “reject” from the interface and continue.
- No: ask the vendor to certify an acceptable bias level.
Recommended response for this scenario
No: a filter that decides who is seen is consequential. Test for disparate impact, document the criteria, provide human review and monitor outcomes.
A shortlist affects who receives an opportunity. Examine whether each criterion is relevant to the work and whether the filter excludes groups unfairly. Employment gaps can arise for many reasons. Define accountable review and a challenge route instead of accepting a vendor’s assurance as the whole assessment.
Practical control: Test the filter against outcomes by group, document why each criterion is job-relevant, and monitor who is being excluded: not only how much time is saved.
Discuss: How would you discover which candidates are being excluded and why?
Case 06
Only informational
A chatbot answers worker questions about leave, pay and safety procedures. It tells a worker something incorrect about medical leave entitlement. The worker acts on it. The company’s position is that the tool is only informational and workers should verify anything important.
What should the organisation do?
- Define the scope, cite sources, add escalation to a human, monitor for wrong answers and run a correction process.
- Remove the disclaimers, which reduce trust and discourage use.
- Let the chatbot update HR records directly so answers and records cannot diverge.
- Keep it live: the disclaimer is clear and workers should verify.
Recommended response for this scenario
Define the scope, cite sources, add escalation to a human, monitor for wrong answers and run a correction process.
People may rely on answers about pay, leave or safety even when a tool is called informational. Give it a clear scope, reliable sources, an accessible human route and a correction process. Assess the impact of the wrong answer. Expanding its record-changing permissions would introduce additional risk.
Practical control: Define the assistant’s scope, provide traceable sources and an accessible human route, and record, assess and correct material errors.
Discuss: How would a worker reach a person and receive a corrected answer?
Case 07
The sovereign proposal
A vendor describes its solution as sovereign because the GPUs are in India. Asked whether support engineers, the underlying model provider or backup systems outside India can access data, it cannot answer.
What should procurement do?
- Reject all cloud solutions and build in-house.
- Approve if the vendor is an Indian-registered company.
- Approve: the primary compute is in India, which is what sovereignty means.
- Require a complete processing and access map: model provider, support, backups, logs, subprocessors, identity and exit.
Recommended response for this scenario
Require a complete processing and access map: model provider, support, backups, logs, subprocessors, identity and exit.
Primary compute location is only part of the processing and control arrangement. Map model providers, support access, backups, logs, subprocessors, identity and exit. Evaluate the claims against your requirements and evidence. This is procurement guidance, not a universal definition of sovereignty or a jurisdiction-wide certification.
Practical control: Obtain a complete processing and access map as part of procurement. Resolve material unknowns before approving the relevant data use.
Discuss: What must the vendor show before its sovereignty claim supports your decision?
Case 08
The silent model update
The vendor changes the underlying model without notice. The maintenance assistant’s answers change in style and, in a few cases, in substance. The vendor points out that the new model scores higher on its benchmark.
What should the customer require?
- Re-run the vendor’s generic benchmark to confirm the improvement.
- Accept it: the vendor controls the model and the benchmark improved.
- Require version notification, regression testing against your own cases, approval thresholds, rollback and post-deployment monitoring.
- Contractually prohibit all model updates for the term.
Recommended response for this scenario
Require version notification, regression testing against your own cases, approval thresholds, rollback and post-deployment monitoring.
An update can change behaviour, latency, cost, retrieval and tool use. Agree notification, representative regression testing, approval criteria, rollback and monitoring. A generic benchmark cannot replace evaluation of your workflow. Avoid treating either unrestricted updates or permanent freezing as a sufficient lifecycle policy.
Practical control: Agree update notification and rollback arrangements, and maintain a representative evaluation set for your workflow.
Discuss: Which workflow cases would you retest, and what would trigger rollback?
Case 09
Ninety-six per cent
The AI dashboard reports a single number: accuracy 96%. There is no breakdown by product, shift, lighting, machine age or defect type. The steering committee has been using it as the acceptance measure for two quarters.
What should the governance team ask for?
- Adopt 96% as the formal production acceptance threshold.
- Add slice-based evaluation, false-positive and false-negative analysis, drift indicators, calibration and operational impact metrics.
- Replace the model with a larger one to raise the number.
- Drop the metric: the operators know the plant better than the dashboard.
Recommended response for this scenario
Add slice-based evaluation, false-positive and false-negative analysis, drift indicators, calibration and operational impact metrics.
Overall accuracy can conceal poor performance in a consequential subset. Review results by shift, variant and defect class, including error types, sample sizes and operational impact. Define acceptance conditions by consequence. A small or unrepresentative slice also needs better evidence before drawing a conclusion.
Practical control: Evaluate consequential conditions separately, with adequate samples, suitable error metrics and documented acceptance criteria.
Discuss: Which slice matters most for consequences, and is its evaluation sample adequate?
Case 10
The system nobody will switch off
An AI system has falling adoption, rising false alarms, expensive inference costs and no clear business owner. Two years and a significant budget have gone into it. The vendor proposes another model upgrade to fix the false alarms.
What is the right governance decision?
- Review value, risk, adoption, cost, controls and ownership; retire or redesign if it cannot justify continued operation.
- Increase automation so that adoption is no longer optional.
- Keep it running quietly and stop reporting adoption to the committee.
- Continue: the investment is substantial and the upgrade may resolve it.
Recommended response for this scenario
Review value, risk, adoption, cost, controls and ownership; retire or redesign if it cannot justify continued operation.
Past spending alone does not justify keeping a system live. Review present value, adoption, costs, controls and ownership. A redesign or retirement may be appropriate. If retiring, plan the vendor exit, data handling and transition to a supported workflow. Do not assume an upgrade fixes every organisational problem.
Practical control: Put a review date on every AI system at approval. Retirement should be a scheduled decision, not something that happens when the champion leaves.
Discuss: What evidence would justify continuing, redesigning or retiring the system?
Sources and limits
Keep the context with the decision.
Fictional educational scenarios adapted from manufacturing workshop material. The recommendations support discussion and do not certify organisational readiness, safety or legal compliance.
Editorial source review: 2026-09-17. Not legal approval or a verified readiness assessment.
- NIST AI Risk Management FrameworkNIST · Accessed 2026-09-17
- ISO/IEC 42001:2023 overviewISO · Accessed 2026-09-17
- Fictional educational scenarios adapted from manufacturing workshop material. The recommendations support discussion and do not certify organisational readiness, safety or legal compliance.
- The scenarios and quoted performance figures are fictional, not verified client outcomes.
- Recommended responses simplify the stated facts. More than one design may be defensible when conditions change.
- Workshop completion and learner choices are not validated measures of instructional effectiveness.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (September 17, 2026). Who owns the AI decision?. dotSuper. https://dotsuper.net/feeds/applied-systems/ai-governance-decision-lab
Move from practice to your operating context
Discuss your next AI workflow
Bring a proposed workflow and the questions this exercise raised. Explore the evidence, ownership and controls needed for your next step.
Talk with dotSuper