Ten operational AI risks to check before you scale
For managers with an AI pilot that worked who are about to extend it to more people, more volume or more clients.
When to use it
The pilot went well and you are asked to roll it out to the whole area next month.
A tool started as one team's test and others now use it without anyone deciding so.
You are going to present the expansion to a committee and want to arrive with the risks reviewed.
The sheet
Tool or use case: [ ] · Reviewed by: [name] · Date: [ ]
Data and confidentiality
☐ 1. We know which data goes into the tool and whether it leaves the company. What good looks like: a written list of allowed and forbidden data types that the team knows.
☐ 2. It is clear whether the vendor uses our data for training or stores it. What good looks like: the answer is in the contract or the settings, not in an assumption.
Quality and errors
☐ 3. A named person reviews what goes out to the client. What good looks like: no text, calculation or decision leaves the company without a recorded review.
☐ 4. We measure the error rate and know what to do when it rises. What good looks like: a weekly number and a threshold that stops usage.
Vendor dependency and variable cost
☐ 5. We know what it costs at twice the volume. What good looks like: a cost estimate at scale, with the vendor's pricing model in writing.
☐ 6. We could switch tools without rebuilding the process. What good looks like: data and instructions can be exported and are documented.
People and authority
☐ 7. It is written down who may use it and what they may approve with it. What good looks like: approval authority did not change without someone deciding it.
☐ 8. The people affected know what changes in their work. What good looks like: it was explained to them before scaling, not after.
Continuity
☐ 9. We know what happens if the tool fails for a full day. What good looks like: a manual fallback procedure tested at least once.
Compliance (check with your legal team; this is not legal advice)
☐ 10. Legal or compliance reviewed the use at the new scale. What good looks like: a recorded, dated review, not a "nobody said no".
How to fill it in 15 minutes
Go through it with the process owner and with someone who uses the tool every day.
Tick only what you can show with a document or a figure. If it is "we think so", leave it unticked.
For every empty box, write an owner and a date next to it.
The most common mistake: reviewing only data and forgetting continuity and cost, which surface when you scale.
Decide: if boxes 1, 3 or 10 are empty, the expansion waits.
The line that is almost always missing
Box 9. During the pilot there was always someone who could do the work by hand. At scale, that person is gone or no longer knows how. A tested manual fallback separates an incident from a lost week.
Vic Sol · Decision Desk · vicsol.org/resources/ · Free to use with attribution. This sheet structures a conversation; it is not legal, financial or audit advice.
Open the .docx in Word (or the .xlsx in Excel) or print it before the meeting.
Fill the fields with the team; leave the blanks visible, they are the discussion.
Close with one owner, one date and one next action. Nothing else.
Prompt
Generate this sheet for your case
Paste this prompt into ChatGPT, Claude or Gemini together with your proposal, process or policy. It reproduces the sheet with your data and flags what is missing.
Act as an operational risk manager with 15 years of experience who reviews tool expansions before they reach a committee and accepts only documents or figures as evidence.
Context I am giving you:
- Company / area: [ ]
- AI tool and what it is used for today: [ ]
- Pilot result (who, how long, what was measured): [ ]
- Scale it is meant to reach (people, volume, clients): [ ]
- Which data goes into the tool: [ ]
- What I know about the vendor's contract and pricing model: [ ]
What I need: produce the one-page checklist with exactly these ten items, grouped as follows:
1. Data and confidentiality: (1) which data goes in and whether it leaves the company; (2) whether the vendor uses or stores the data.
2. Quality and errors: (3) who reviews what goes out to the client; (4) error rate and the threshold that stops usage.
3. Vendor dependency and variable cost: (5) cost at twice the volume; (6) ability to switch tools.
4. People and authority: (7) who may use it and what they may approve; (8) whether the people affected know what changes.
5. Continuity: (9) what happens if the tool fails for a full day.
6. Compliance: (10) legal or compliance review at the new scale. Label this group "check with your legal team; this is not legal advice".
For each item: a `- [ ]` box, status based on what I gave you (met / not met / no evidence), "what good looks like" and the next action with an owner.
Output format: the grouped list and, at the end, one line saying whether the expansion can go ahead or should wait. Maximum 450 words. No introduction.
Rules:
- Do not invent figures or contract clauses. If data is missing, write [DATA PENDING] and tell me how to get it.
- If there is no evidence for an item, mark it "no evidence", never "met".
- Do not give a legal opinion; say what to ask the legal team.
- If critical information is missing, ask me at most 3 questions before answering.
- Answer in plain, direct business English, with no sales adjectives.
What to check in the answer:
Did it mark "no evidence" where you gave no document or figure, or did it treat items as met by assumption?
Does the continuity item propose a concrete manual fallback?
Did the compliance group stay as a question for your legal team, with no legal opinion?
Vic Sol