The real AI risks for a smaller organization, ranked.
Ask a room of directors what worries them about AI and the answers come from the news: deepfakes, rogue systems, a machine that decides to do something on its own. For a twenty-person nonprofit, a clinic with three locations or a small engineering firm, they are rarely what goes wrong first.
The risks that actually show up are duller and closer to home. They live in the inbox, the shared drive and the one spreadsheet that runs payroll. A useful way to sort them is to ask two plain questions of each: how likely is this to happen to us in the next year, and how bad would it be if it did?
How to rank a risk without a risk department.
Large organizations have frameworks, committees and a person whose title has "risk" in it. A town office or a family-owned manufacturer has the director and maybe an outside IT contractor. That is enough to do this well, as long as you score each risk on the same two questions and resist ranking by how frightening it sounds.
Likelihood comes from how often the thing that causes the risk happens in ordinary work. If people use AI tools every day, anything tied to everyday use scores high. Damage comes from what the worst realistic outcome would cost you: money, a client, a regulator's attention, or a week of someone's time cleaning up. Multiply the two in your head, and the order below is what we usually see when teams do the exercise honestly.
First: a confident wrong answer leaves the building.
This one sits at the top because it happens so often. AI tools write fluently whether they are right or wrong, and a fluent paragraph is easy to wave through on a busy afternoon. A grant summary with a misread deadline, a policy answer that cites a rule your state doesn't have, a proposal that promises a turnaround nobody agreed to. Each one reads well, and each goes out under your name.
The damage per incident is usually moderate. Someone apologizes, a client asks a pointed question, a correction goes out. The trouble is frequency. A team that drafts dozens of emails and documents a week with AI will produce some wrong ones, and the cost adds up in trust more than in dollars. The response is a habit: anything a person outside the organization will read gets read first by someone inside it who knows the subject.
The risks that actually show up are duller and closer to home.
Second: the wrong data goes into the wrong tool.
A staff member pastes a client's file, a student's record or an employee's medical note into whatever chatbot is open in the next tab. Usually nothing happens. Sometimes the tool's terms allow that text to be stored, reviewed or used in ways your contracts, your funders or the law don't permit. You often won't know it happened at all, which is part of the risk.
Likelihood is high wherever people use personal accounts for work, and damage depends on what was pasted. A recipe is harmless; a patient note can mean a reportable breach. The response has two parts. Name, in your own vocabulary, the categories of information that only go into approved tools, and then make sure an approved tool exists, because people who have nowhere safe to paste will paste somewhere unsafe.
Third: an automation nobody owns keeps running.
Someone connected the intake form to a spreadsheet and a follow-up email. It worked, so everyone forgot about it. Months later the form changes, the sheet gets renamed, or the person who built it leaves, and the automation either stops quietly or keeps sending the wrong thing to the wrong people.
This ranks below the first two because fewer people build automations than write with AI. When one does fail, though, it fails repeatedly and without anyone watching, which raises the damage. The response is a named owner for every automation that touches clients, money or records, and a short list somewhere that says what each one does.
Fourth: everything depends on one person.
In many smaller organizations, one enthusiastic person sets up most of the AI work. They wrote the good prompts, they know which settings matter, and they hold the logins. If they leave, go on leave or simply get busy, the work they built gets harder to run and nobody else knows how to fix it.
The likelihood is moderate and the damage arrives slowly, which is why this one is easy to ignore. What usually follows is a gradual slide back to doing things by hand, and a sense on the team that AI "didn't stick." The response is to write down what that person knows while they are still around, and to pair them with a second person on anything the organization relies on.
A risk-and-response table you can fill in.
Use this as a starting sheet for a one-hour conversation with your leadership team. Keep the four rows above, add any risk specific to your work, and score each one honestly before deciding what to do.
| Risk | Likelihood | Damage | First response | Who checks |
|---|---|---|---|---|
| Wrong answer sent outside | High | Moderate | A knowledgeable person reads anything external before it goes | Each team lead |
| Sensitive data in the wrong tool | High | Low to severe | List protected categories; provide an approved tool | Director or IT contact |
| Unowned automation | Moderate | Moderate to high | One named owner per automation; keep a list | Operations lead |
| Dependence on one person | Moderate | Slow, cumulative | Document the setup; assign a second person | Director |
| (Your own risk) |
Then work through it in order:
- Score likelihood and damage for each row as high, moderate or low, using your own recent history as evidence.
- Pick the highest-scoring row and write one response you can put in place this month.
- Put a name in the "who checks" column, one person rather than a team.
- Set a date three months out to look at the table again and rescore anything that changed.
