AI Strategy: A One-Page Plan for Your Company

Your AI strategy should name the work you will change, the outcome you expect, and the limits you will enforce. For a company of 10 to 200 people, start with six decisions and one funded workflow for the next 90 days.

When the board asks for your strategy, give it a commitment it can evaluate: which business result you are pursuing, who owns it, what you are prepared to spend, and what evidence would make you stop. A presentation about industry trends cannot answer those questions.

What Is an AI Strategy?

An AI strategy is your company's set of choices about where artificial intelligence belongs in the business and how you will judge its contribution. It connects an opportunity to resources, responsibilities, and boundaries. A model is the AI engine producing a draft or suggestion; the workflow includes the people, data, and controls around it.

Think of it as a job specification for a new team member. You define the work, the information they can see, the decisions they can make, who checks their output, and what good performance looks like. Giving someone access to every system before defining their job would be poor management. The same reasoning applies here.

The strategy chooses the work and the tradeoffs. The roadmap schedules the implementation. The employee policy explains what people may do day to day. Keep them connected, but give each a clear purpose.

You also need a view of the business beyond the pilot: whether faster delivery protects your margin, changes what customers will pay for, or enables a different service. The AI-native company guide explores that operating-model change. Your immediate strategy should test a specific part of it.

AI Strategy Examples: Services Firm vs Software Company

The right strategy depends on where work constrains your business. A services firm may need more capacity to produce qualified proposals; a software company may need customers to complete onboarding, the work of getting set up, successfully.

Consider a 30-person services firm and an 80-person software company. Both companies, their workloads, and the allocations below are illustrative planning examples, not client results or performance forecasts. In the software example, import mapping means matching fields in a customer’s file to fields in the application.

These choices become a strategy when you specify the work, evidence, owner, and limits behind each row.

AI Strategy Framework: Six Decisions to Make

Make the decisions in business language before commissioning implementation. Each should fit in a short paragraph, with supporting evidence linked from the one-page record.

1. Choose the Work and the Financial Line It Changes

Choose a bottleneck that affects a cost or revenue line you already manage. “Improve productivity” leaves you unable to distinguish a useful project from a popular tool.

Map a candidate workflow from its trigger to its accepted outcome. Identify the time spent, the waiting, the rework, and the person who decides it is finished. Then compare candidates on business value, frequency, data availability, ability to check quality, and consequences of error. Missing ownership or unavailable data should block a pilot, even if the potential benefit looks large.

Services firm: Start with drafting a proposal from an approved client brief and reusable service descriptions. The financial line is sales effort per qualified proposal; a second hypothesis is that faster turnaround helps the firm compete for work. Those are different claims and need different measurements.

Suppose the firm prepares 20 proposals per month, taking 3 hours each. If AI-assisted drafting, review, and correction together take 1.5 hours, the potential capacity released is:

20 × (3 - 1.5) = 30 hours per month.

That is a scenario to test. It becomes financial value only when the firm uses the capacity to pursue worthwhile opportunities, avoids an expense, or changes delivery economics. It does not automatically reduce payroll or increase wins.

Software company: Start with the work required to interpret inconsistent field names in customer files and prepare a checklist from their setup requirements. Keep fixed, familiar file formats on ordinary import rules. The cost line is onboarding labor; the revenue hypothesis is that fewer setup delays help customers reach a useful first result.

Suppose 40 onboarding jobs per month take 90 minutes each. If total work falls to 60 minutes, including checks and corrections, the scenario releases:

40 × (90 - 60) / 60 = 20 hours per month.

Measure customer completion and subsequent use separately. Faster internal preparation is not evidence of better retention.

Write the decision: “We will improve [workflow] to change [business metric], measured against [current baseline], while protecting [quality condition].” The AI ROI guide explains how to turn observed workflow changes into a defensible value calculation.

2. Decide What AI May Do Without Approval

Start with assistance when a mistake could create a commitment, expose information, or change customer data. Assistance means AI prepares a suggestion and a person decides whether to use it. Automation means the system executes a defined action without approval for each instance.

Use a stricter rule for automation: you can check the result reliably, contain the consequences, and reverse the action. These are screening conditions; passing them does not replace a successful pilot or a named owner. If neither software nor a qualified person can check the output, defer that use.

Services firm: AI may draft the narrative and identify missing information. The account lead approves scope, delivery commitments, and the final proposal. During the pilot, the system cannot send the proposal, sign anything, or alter the commercial terms. Filing an approved document into the correct folder may later be a better automation candidate than negotiating its contents.

Software company: AI may suggest that a customer's “Company” field maps to the application's “Organization” field. An onboarding specialist checks the mapping; ordinary software validates required fields and formats. Keep import execution and changes to production records under the existing approval process. A reversible staging configuration might become eligible for automation after checks and recovery have been demonstrated.

The risk distinction is what an error can do, not whether the interface looks like a chatbot. A draft that cannot act has a different operating boundary from a system connected to write operations.

Write the decision: “AI may [prepare or execute this action]. A named person must approve [these actions]. The system must never [excluded actions].”

3. Choose Build, Buy, or Configure

Buy a standard capability when it meets your requirements. Build the parts that make your workflow distinctive and that you can maintain. Configure an existing application when it already fits the work but needs approved documents, rules, or connections.

“Build” does not have to mean training a model. You can buy access to a model and build the surrounding workflow: how information reaches it, how suggestions are checked, and how users approve actions.

Compare those routes against the same acceptance conditions. Can each preserve permissions, expose the evidence a reviewer needs, export your records, and support a fallback? Include integration, evaluation, staff training, incident handling, and ongoing maintenance in the comparison. A prototype with no operational owner has not won the build-versus-buy decision.

Services firm: Buy and configure a drafting application if it can work within the firm's approved data boundary and review process. Keep the approved source library and proposal checklist portable. If a product cannot meet client-data restrictions, an attractive demo does not rescue it. Reduce the data used, change the route, or defer.

Software company: Buy model access, then build the customer-specific mapping interface, authorization checks, validation, and approval record. Those parts belong close to the product because they encode how this application's onboarding works. Keep the model connection replaceable so a provider change does not require recreating the entire onboarding process.

The choice flips when a standard product cannot satisfy a valuable requirement and your company can fund the ongoing ownership of a custom solution. Wanting your own AI brand is not such a requirement.

Write the decision: “We will [buy/configure/build] because [specific requirement]. [Owner] will maintain it, and [exit route] keeps the workflow recoverable.”

4. Specify the Data and Access Each Use Needs

Give each use only the information and permissions its task requires. “Connect our company data” is too broad to authorize.

Record the source, who may use it, which fields the workflow needs, and who maintains it. Decide what may be sent to a provider, whether it may be retained or used for training, how deletion works, and what stays in logs. Verify these requirements against the selected service's current terms and controls before using company data. An approved subscription does not establish permission to upload every document.

Reading and acting also need separate decisions. The Open Worldwide Application Security Project (OWASP) guidance on excessive agency recommends limiting functions and permissions, requiring approval for high-impact actions, and enforcing authorization in downstream systems. Telling a model “do not access another customer” is not a replacement for an application that prevents that access.

Services firm: Use the current client's approved brief, approved service descriptions, and case studies cleared for reuse. Exclude other clients' confidential proposals and private staff notes. Restrict access to the account's authorized staff. The draft should identify the source for factual claims so the reviewer can check them; unsupported claims return for correction.

Software company: Use the current customer's field names and the minimum sample values needed to understand the mapping. Mask unnecessary personal data. Retrieve information within the current customer account's permissions, including any search index. Keep authentication secrets and other customers' records out of the model context. The pilot proposes mappings but has no permission to update production records.

For both, test a request that should be refused, a missing source, and a stale source. Successful answers alone cannot demonstrate that the boundary works.

Write the decision: “This use may read [sources and fields], for [authorized users], with [retention rule]. It may write only [destination or none]. [Data owner] approves changes.”

5. Assign the Outcome and the Risk to Named People

The CEO owns the company's strategic choice; the workflow owner owns whether the change works in practice. Technical staff own the implementation controls. Reviewers need the expertise, time, and authority to reject output.

The National Institute of Standards and Technology (NIST) AI Risk Management Framework core organizes risk work into govern, map, measure, and manage. It assigns executive responsibility for AI risk decisions, calls for defined oversight, and recommends testing before deployment and during operation. Treat these as continuing responsibilities.

The NIST and OWASP guidance cited here was verified against their primary documentation on 26 October 2026. The six-decision structure and the company examples are this article's practical synthesis, not a certification framework.

Services firm: The sales director owns proposal turnaround and quality. The account lead approves the scope and customer-facing document. The operations lead manages access and the approved sources. The CEO decides whether the remaining risk is acceptable and whether more work should move into the process.

Software company: The head of customer success owns onboarding results. A designated engineer owns authorization, validation, monitoring, and recovery. An onboarding specialist reviews suggestions. Product leadership decides whether the internal pilot has earned a customer-facing release, with the CEO accountable for the company's risk posture.

One person can hold several roles in a small company, but the duties should remain visible. Record who can pause the workflow, who handles an incident, and who can authorize a restart. A named approver without time to inspect the evidence is an unstaffed control.

Use the AI governance framework for the wider control record and the AI acceptable use policy for employees' daily instructions. Explain the new responsibility to the people doing the work, including what to do when the system is wrong.

Write the decision: “[Person] owns the outcome; [person] approves high-impact work; [person] maintains controls; [person] can stop and restart the process.”

6. Set the Budget, Review Rhythm, and Stop Conditions

Fund a bounded learning effort, then release more resources when the evidence supports it. Include staff capacity alongside a cash spending cap. Review, correction, training, and maintenance consume capacity even when software is already available.

Services firm: An illustrative pilot allocation is 40 operations hours across the 90 days for configuration, source cleanup, training, and evaluation. Ordinary proposal review remains separately staffed and measured. The sales director reviews turnaround, total effort, scope corrections, and use of the released capacity each week. The CEO reviews the funding decision monthly.

Software company: An illustrative allocation is 10 engineering days plus 2 onboarding-specialist hours per week across the pilot. Give finance a cash cap before enabling paid services. The engineering allocation covers a narrow internal experiment; a production feature requires a separate estimate. Review total onboarding effort, mapping errors, customer completion, and access-control failures weekly, with a monthly leadership decision.

For both examples, agree the gates before launch:

• Expand when representative work meets the pre-agreed quality and permission requirements, total effort improves after review and correction, and an owner can support the larger scope.
• Revise when the idea helps but a specific fix, such as better source material or a narrower task, has a credible path to the target within the remaining allocation.
• Stop when benefits disappear after checking costs, the required data cannot be used, or the workflow cannot meet its operating boundaries. Pause immediately for unauthorized access or actions.

The services firm should reject a faster process that introduces critical scope errors. The software company should reject a smoother demo that exposes another customer's data. More output does not compensate for either failure.

Write the decision: “We authorize [cash cap] and [staff capacity] until [review date]. We expand if [evidence], revise if [fixable gap], and stop if [condition].”

A 90-Day Sequence From Decision to Evidence

Use the 90 days to earn a decision about continued investment. Completion of the calendar is not permission to expand. These timeboxes are planning recommendations; a missing prerequisite can keep a project at an earlier stage.

1. 1

   Days 1-30: Agree the Plan and Establish the Baseline

   Name the executive sponsor, workflow owner, technical owner, and reviewers. Map the current process and measure complete jobs, including review, correction, and exceptions. Use the AI readiness assessment to find gaps in this workflow's data, permissions, and operating support.

   For the services firm, collect a permitted set of proposal briefs, final documents, effort records, and examples of scope corrections. For the software company, collect approved onboarding cases, mapping decisions, completion records, and failed imports. Include awkward cases, not just tidy demonstrations.

   Agree the six decisions, the quality checklist, the staff allocation, and the cash cap. Tell affected staff which work changes, how their feedback will be used, and where any released capacity will go.

   Exit evidence: a signed decision page, a usable baseline, approved data, and a reviewer who can explain what a passing result looks like. Without these, use the next phase to close the gaps.

2. 2

   Days 31-60: Run a Controlled Pilot

   Evaluate the proposed workflow on historical cases first. Keep a separate set of cases out of configuration so the evaluation does not merely reward examples the system was shaped around. Then run live work within the approved boundary, retaining the original process as a fallback.

   For the services firm, review every draft before it leaves the company. Log unsupported statements, omitted requirements, scope changes, and total effort. For the software company, have specialists review suggested mappings, enforce ordinary import validation, and test that another account's data stays inaccessible.

   Train users with an ordinary case, a misleading suggestion, and a case that must be escalated. Ask them to demonstrate the correction and escalation process. Observe whether review is practical during normal work.

   Exit evidence: accepted and rejected examples, measured review effort, a record of exceptions, and a demonstrated way to pause the workflow. A persuasive demo is insufficient.

3. 3

   Days 61-90: Decide Whether to Expand, Revise, or Stop

   Compare like-for-like work with the baseline, including abandoned attempts and rework. Explain any change in case difficulty or workload. Report uncertainty where the pilot is too small to support a claim.

   For the services firm, check whether proposal capacity was used and whether quality held. Track win outcomes without attributing every change to AI. For the software company, distinguish less specialist effort from improved customer activation; the second requires its own evidence.

   At the day-90 review, release funding for a specific next scope, authorize a bounded revision, or retire the pilot. For any expansion, repeat the permission and quality review for the new users, data, and actions. A customer-facing onboarding feature is a new release decision even if the internal assistant worked.

   Exit evidence: a recorded decision, an accountable owner, updated limits, and the next review date.

Who Should Act Now, Wait, or Keep the Existing Process?

Act now when you have recurring work, a measurable problem, permitted inputs, and someone capable of checking the result. A small internal assistance pilot is a reasonable starting point for either example company under those conditions.

Wait on live use when the data rights are unresolved, access boundaries cannot be enforced, or no one can staff review. There is still useful work to do: measure the baseline, repair the source library, establish permissions, and define a narrower task.

Keep the existing process when a simple rule already solves the problem reliably. A required-field check or a fixed approval rule does not need a model to reinterpret it. Preserve those controls around any AI-generated suggestion.

For a founder, the immediate job is choosing the priority and committing capacity. For an operator, it is documenting the handoffs and exceptions. For a technical lead, it is proving the checks and permissions before adding autonomy.

What's Overhyped About AI Strategy?

A company-wide automation target is a poor starting point. Different actions have different consequences. Requiring an account lead to approve a proposal may remain the correct design even after drafting becomes much faster.

Building your own system does not eliminate dependency. You still own changes in sources, model behavior, integrations, staffing, and customer expectations. Buying an application also leaves you responsible for your use of it. Choose the route whose ongoing work you can support.

Tool usage is not a business result. More prompts, more seats, or more generated documents can coexist with unchanged turnaround and more checking. Report accepted work and the business outcome, including the work required to correct it.

A one-page strategy is a decision record, not the whole operating system. Keep evaluation cases, access records, incident procedures, and implementation detail behind it. Brevity helps leadership make decisions; it does not remove the work of making those decisions sound.

Frequently Asked Questions

What is a crucial consideration when developing an AI strategy?

Connect the proposed use to a measurable business outcome and give it a named owner. Then decide how an error will be caught before it creates a customer commitment, exposes data, or changes a production system. A use with no practical quality check needs a narrower scope or should wait.

One-Page AI Strategy Template

Copy this into a document and replace the blanks. Keep the answers short; link to supporting records rather than expanding the page into a presentation. On Monday, the CEO and workflow owner should fill it in together for the first proposed use, then book the baseline review.

Company: ______ Executive sponsor: ______ Decision date: ______
Planning period: ______ to ______ Workflow owner: ______

The board answer: “We are using AI to improve ______, starting with ______. We have authorized ______ resources under ______ limits. ______ owns the result. We will decide the next investment on ______ using ______ evidence.”

For practical guidance on turning AI decisions into working business processes, join the newsletter.