How to Write a One-Page AI Strategy for Your Company

To write an AI strategy for a company, put one page in front of the people who must decide. It should state the goals you will check, the roles AI will hold, the boundaries it must respect, a named owner for each, and a date when you will review it all. Keep it short enough that people read it and specific enough that someone can say when it is being broken.

Key takeaways

• A one-page AI strategy answers six questions: why, where, who, what is off limits, how you will know it works, and when you will look again.
• Write goals as outcomes in a business process, not as a count of tools, licenses or pilots.
• Give every role, boundary and risk one named human owner, not a team or a committee.
• Put review dates on the page itself, and treat a missed review as a finding.
• Start with one useful role and expand only after the page has survived its first review.

Why does an AI strategy fit on one page?

A long strategy document is easy to approve and hard to use. It collects vision statements, vendor comparisons and technology diagrams, and nobody can tell from it what to do on a Tuesday when an employee wants to paste client data into a chat window, or when a manager asks for a new automation.

A strategy is a set of choices. Choices are what you leave out as much as what you include, and a single page forces that discipline. If a section needs three pages to explain, the decision behind it has probably not been made yet.

Think of the page as a decision tool for three kinds of readers. An employee uses it to learn what is allowed. A manager uses it to judge whether a request fits the plan. An owner or director uses it to approve, pause or redirect spending. Anything more detailed, such as an architecture diagram or a vendor shortlist, belongs in an attachment that the page points to.

What goes on the page?

Use eight blocks. Each gets a few lines, not a few paragraphs. Here is the template:

• Purpose: one sentence on why the company uses AI, tied to a real business problem such as slow handoffs, repeated manual reporting or inconsistent customer replies.
• Goals: two or three outcomes, each with a measure and a description of today's baseline.
• Roles: the jobs AI will hold, written like short job descriptions: what the role does, what it never does, and who it reports to.
• Boundaries: data it may not read, actions that need human approval, and actions it can never take.
• Owners: a named person for the strategy as a whole, for each role, for data, and for risk.
• Tools and data: where the AI runs, what it can read, and which accounts it uses and who holds them.
• Evidence: what you will look at to know it works, how often, and where the record is kept.
• Review dates: when each part is reread, who attends, and what triggers an early review.

If you want a structure behind the eight blocks, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organizes risk work around governing, mapping, measuring and managing. The [OECD AI Principles](https://oecd.ai/en/ai-principles) set out values such as transparency and accountability. You do not need to cite either on the page, but your answers should be consistent with them.

How do you write goals you can check?

The most common weakness in company AI strategies is a goal like "adopt AI across the business." It cannot fail, so it cannot guide anything. A checkable goal names a process, a change and a way to observe it.

Compare two versions:

• Weak: use AI to improve customer service.
• Checkable: shorten the time a support lead spends assembling the weekly summary of open customer issues, compared with how the summary is produced today, and keep the summary's accuracy at the level the lead accepts when reviewing it.

The second version has a baseline, a direction and a quality condition. Before you write it, record how the work is done now, even roughly. Without that, any improvement is an opinion.

Illustrative scenario: a small distribution company has three candidate ideas, one for quoting, one for supplier follow-ups and one for internal policy questions. The operations director scores each on value, effort, risk and data readiness, picks supplier follow-ups, and writes one goal: the purchasing coordinator no longer chases routine delivery confirmations by hand, and exceptions still reach a person the same day. The other two ideas go on a waiting list at the bottom of the page. For a scoring method, see how to prioritize AI use cases, and for turning a goal into a test, see how to define success criteria.

Who owns what, and where are the limits?

Ownership fails when it is shared vaguely. Write a person's name, not "IT" or "the AI team." That person can delegate work, but they remain the one who answers when something goes wrong. If a role has no willing owner, that is a signal to delay the role, not to assign it by default.

For each role, ask who decides what it does, who approves changes, who watches its output and who can switch it off. A RACI for AI agents is a useful attachment when the answers involve several people.

Boundaries are easiest to hold when they sit in three tiers:

• Allowed without asking: low-risk actions the role performs on its own, such as drafting, summarizing or filing.
• Allowed with approval: actions that affect customers, money, contracts or other people's records, where a named person confirms first.
• Never allowed: actions the role cannot take under any instruction, such as deleting records, changing its own permissions or contacting people outside an approved list.

The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege and denying access by default. Applied here: the role gets only the access its job needs, and anything not listed on the page is not permitted. Also write who holds the accounts the role uses. A role that runs under a personal login belongs to that person, not to the company.

When should the page be reviewed?

A strategy without review dates is a one-time announcement. Put a real calendar date next to each block, not a vague promise to look at it periodically. A reasonable pattern is a short check of evidence and incidents at one interval, a fuller reread of goals and roles at a longer interval, and an access check scheduled separately.

Also list the events that trigger an early review, regardless of the calendar:

• A new data source or system is connected to an AI role.
• A role gains a new action, especially one that affects customers or money.
• An incident, near miss or complaint involving AI output.
• A change of model, provider or hosting location.
• A change in a law, contract or customer requirement that touches your data.
• The owner of a role leaves or changes position.

Treat a missed review as a finding, not an embarrassment. Write down who was responsible, why it slipped, and the new date. The access part of the review is its own routine: see how to run a permission review for the steps.

How do you draft it in practice?

A first draft can be done in a few working sessions. This sequence keeps the page honest:

• Step 1: List where work is slow, repetitive or inconsistent today. Ask the people who do it, not only their managers.
• Step 2: Pick one process and write the goal with its baseline. Park the rest on a waiting list.
• Step 3: Describe the single role AI will hold in that process, in a few lines, including what it never does.
• Step 4: Write the three boundary tiers for that role and check them with whoever owns the affected data.
• Step 5: Name the owners and ask each to confirm in writing that they accept the responsibility.
• Step 6: Decide what evidence you will look at and who looks at it, then set the review dates.
• Step 7: Share the page with the people it affects, collect objections, revise, and only then publish it internally.

Read the result aloud to someone outside the project. If they cannot say what AI may do in your company and who to ask when unsure, the page needs another pass.

How does Be Human handle this?

Be Human's first engagement produces the core of this page in practice: one useful role, the memory and tools it needs, the approval boundaries, and an observable success criterion. In managed operations, Be Human monitors the agent, runs recurring evaluations, reviews permissions, maintains integrations and makes controlled improvements, while identity, memory, channels and permissions stay under the company's control. The company keeps the decisions on the page, such as goals, owners and what needs approval. Be Human supplies the operating evidence that makes each review date meaningful.

Frequently asked questions

How long should a company AI strategy be? One page is the right size for the decision document, and anything longer should be an attachment the page points to. If you cannot fit a block on a few lines, the underlying choice is probably unresolved, and the length is hiding that.

Who should write the AI strategy? A business owner or operations leader should hold the pen, with input from the people who do the work and from whoever owns the relevant data and systems. Technical staff or an outside partner can advise, but the goals, owners and boundaries are business decisions and should be signed off by someone with authority to make them.

Do we need a strategy before we run a pilot? You need a small version of it. A pilot with no stated goal, owner or boundary tends to produce impressions instead of evidence. Write the page for one role first, then use the pilot to test whether its goals and limits were realistic, and revise the page afterward.

How often should we update the AI strategy? Update it at each scheduled review date and whenever a trigger occurs, such as a new data source, a new action for a role or an incident. Between reviews, keep changes small and logged so that the page always matches what your AI roles actually do.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.