---
title: "Ten operational AI risks to check before you scale"
slug: checklist-riesgos-ia-operacion
lang: en
situation: gobernar
format: checklist
minutes: 15
updated: 2026-10-19
---

# 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

1. Go through it with the process owner and with someone who uses the tool every day.
2. Tick only what you can show with a document or a figure. If it is "we think so", leave it unticked.
3. For every empty box, write an owner and a date next to it.
4. The most common mistake: reviewing only data and forgetting continuity and cost, which surface when you scale.
5. 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.

## If this becomes a big decision

If the expansion touches client data, contracts or approval authority and carries your name, the free tools at vicsol.org/decision-clarity/ help you structure it. They do not replace a formal review.

---

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.