A Board Asked Me for an AI Strategy. Here Is the One Page I Gave Them.

A board asked me for an AI strategy last quarter. I gave them one page. Three decisions and a short list of what we would not touch. We shipped something real three weeks later.

They expected a deck. Sixty pages, pillars, a maturity model, four horizons on a roadmap. That version would have taken three months to write and given the team nothing to do on Monday.

Strategy is not the problem. The sixty-page version of it is.

What a real AI strategy fits on

One page. It is three decisions, and until a board makes them, everything downstream is people guessing and asking permission.

1. Where is our data allowed to go? Name the models and vendors you trust. Claude, ChatGPT, whatever you land on. Say plainly what data can touch them and what never can. This is the decision that keeps you out of the newspaper, and it is the one boards most want to skip because it feels technical. It is not technical. It is a risk call, which is exactly the board's job.

2. Build or buy, and where is the line? Most of the AI you want already exists behind an API. You are not training a model. You are wiring one into your own product and process. Decide where the vendor's job ends and your code begins, so your team stops relitigating it on every project.

3. Who owns it, and what is the budget? One name. One number. If nobody owns it, AI becomes everybody's side project, which means it is nobody's, and it dies quietly around week six.

Three answers. One meeting. That is a strategy a company can actually act on.

The other half is the list of what you will not do

This is the part every framework leaves out, and it does more work than all the pillars combined.

Write down what is off the table. No customer records in public models. No fully automatic decisions on anything that touches money or people. No pilot that cannot ship in ninety days. No standing up a data science team to solve a problem an API already solved.

A short list of nos is not caution. It is permission. When the fences are clear, your people stop coming to you for approval on every small thing and start moving. Speed comes from knowing the boundaries, not from a vision statement about them.

Why one page beats sixty

The deck fails because a document is not a decision. By the time it clears legal and survives three rounds of edits, the tools have moved and the team has lost the thread. I have watched sharp companies spend a quarter aligning on language while a competitor shipped a working feature with worse slides and better nerve.

The one-pager works because it ends arguments instead of starting them. It tells your best engineer what they are allowed to touch and what they are not, which is the only thing they were ever waiting for.

When I replaced that board's planning cycle with three decisions, engineering already knew what to build. They had been waiting on permission and boundaries, not inspiration. We took one internal workflow that ate hours every week, wired a model in behind a small app, shipped it to a handful of users, watched it, and fixed what broke. No maturity model. The point was not the feature. The point was proving the company could move, because once a team ships once, the second thing is easier.

What to do this week

1. Book one meeting. Put three questions on the agenda: where data can go, build versus buy, who owns it and the budget. Leave with answers, not action items.
2. Write the list of nos on one page. Send it to the team the same day. Watch how fast they move once the fences are up.
3. Pick one workflow that wastes hours every week. Ask your best engineer whether a model plus an API can dent it in thirty days. If yes, fund it now.
4. Skip the deck. You do not need it, and writing it will cost you the quarter.

A sixty-page strategy tells you where you might go someday. A one-page strategy tells your team what to do Monday. Give them the page.