The riskiest AI plan is doing nothing.

Most conversations about AI risk in an organization end up asking the same thing: what could go wrong if we use it? It's a fair question, and someone should be asking it. The trouble is that it usually gets asked alone, and the opposite question, what goes wrong if we don't, never gets a meeting.

Standing still has costs too.

When a team decides to hold off on AI until things settle down, the decision feels free. Nothing breaks, nobody leaks a file, and the risk register stays tidy. Meanwhile the work goes on exactly as it did last year: proposals still take a week to assemble, intake forms are still retyped into the case system by hand, and the monthly board report still eats two people's Friday.

Those costs are real, but they are spread thin and they arrive slowly. A peer organization that cut its proposal time in half doesn't send you a notice. A clinic down the road that answers referral questions the same day doesn't file anything with your compliance officer. You find out later, usually when you're trying to hire someone who asks which tools your team uses, or when a funder or a client starts expecting a turnaround you can't match.

A risk register lists everything that could go wrong if you act, and nothing that goes wrong while you wait.

So the honest version of the question is a comparison. Moving carries some risk, and so does staying put. A plan that only counts one side will always recommend waiting, because waiting is the side with no line items.

Find the lines you actually can't cross.

Some limits are fixed, and a good plan treats them that way. These are the obligations that come from outside the room: the law that applies to your sector, privacy commitments you have made in writing to patients, students or clients, the terms of your customer and vendor contracts, and any compliance framework you are audited against. A town office handling resident records lives under different rules from a design firm, and a school district has obligations a manufacturer doesn't.

Write these down precisely. "Be careful with sensitive data" doesn't count as a line, because nobody can tell where it starts. "Student records and anything with a Social Security number never go into a tool we haven't approved, per our district agreement" does. Once the real lines are on paper, with the document each one comes from, people can work right up to them with confidence.

Most of your rules are buffers.

Around those fixed lines, organizations tend to build a second ring of rules that nobody required. Someone heard a worrying story and banned all AI tools on work laptops. Someone else decided that any use touching a client needs sign-off from three people. A policy drafted in a hurry says no client names in any tool, even one already covered by a contract with the right data protections.

Each of these felt prudent on the day it was written. Together they keep the organization well inside its actual limits, and that unused space is where most of the useful work would have happened. In our work with teams, the rules people resent most tend to be internal buffers that nobody remembers adding and nobody feels authorized to remove.

Buffers also have a quieter cost. When the official path is blocked for no reason anyone can explain, people use their personal accounts instead, on their own phones, with none of the protections the organization could have provided. A rule meant to reduce risk ends up moving the risk somewhere nobody can see it.

Make the yes faster than the workaround.

Oversight still matters. A short list of approved tools with proper sign-in and data terms, plain written guidance on what can go in, and one person who owns the decisions will protect you far better than a long list of prohibitions, provided the person who owns them answers quickly.

If a staff member asks to try a tool for summarizing meeting notes and the answer takes six weeks, they will find another way within the first one. Set up a simple request: what the tool is for, what data it would touch, which contract or terms cover it. Then commit to an answer within days. A fast, clear no is more useful to people than a slow maybe, and a fast yes keeps the work inside the walls where you can see it.

It also helps to treat the first year as a test. Approve uses that are easy to reverse, watch what happens, and widen the limits you set yourselves as the record builds, while the external ones stay put.

Audit your rules in an afternoon.

Pull together every AI rule your organization has today, written or just understood, and put each one through these questions with whoever owns AI decisions and someone from IT or operations in the room.

1. Where does this rule come from? Name the law, contract, written commitment or audit framework. If the honest answer is "we decided to be cautious," mark it as a buffer.
2. For each fixed line, is it written down specifically enough that a new hire could tell whether a given task crosses it?
3. For each buffer, what work does it block? Name one real task, such as drafting grant reports or sorting the shared inbox, that people would do with AI if the rule weren't there.
4. Where do people go instead? If the answer is personal accounts, the buffer is adding risk rather than removing it.
5. What would it take to replace the buffer with something narrower, such as an approved tool, a data category list or a review step for client-facing output only?
6. How long does a request to use a new tool take to answer today, and who answers it?
7. When will you look at this list again? Put the date on the calendar before everyone leaves the room.

Keep the fixed lines exactly where they are. Retire or narrow every buffer that can't name the problem it solves, and write down what you changed so the next review starts from there.