The AI strategy playbook for mid-market companies

Who this is for

You run a mid-market company. The AI licenses are bought. The work has not changed. Someone bought seats, a few people got good at the tools on their own, and most kept working as before. One manager we met had paid for a subscription long ago and opened it a handful of times since. There is no L&D department to hand this to, and a strong chance the plan, as of this morning, is you.

This playbook is for whoever was told to make AI useful: an owner, a COO, a chief of staff, an operations leader. The job is the same in every case. Find the work worth changing, give people clear rules, and show results without six months in committee.

• 75% of knowledge workers already use AI on their own, sanctioned or not (Indeed, 2026)
• 42% of companies say their AI strategy is prepared; fewer feel ready on talent and data (Deloitte, 2026)
• 67% of CEOs piloting AI are still stuck in planning or pilots; only 12% see real ROI (Oliver Wyman Forum, 2026)

Pilot purgatory is the default state of the market. One co-owner told us plainly that the company was nowhere on AI and knew it needed to be somewhere.

What follows came from a year spent inside companies like yours, department by department, watching what stalled and what worked. It is organized as advice, in the order we would do it if we started over tomorrow.

Start with an audit, not a purchase

Every company we walked into already had AI running. Not deployed, not approved, just running, often on personal accounts. You are not deciding whether employees will use AI. You are finding out how they use it now.

One finance lead had built company reports on a personal AI plan without realizing its data settings differed from a business plan. The problem was not bad intent. Nobody had told her which account to use or why it mattered.

Do this before you buy anything. Have a short conversation with each person. Say plainly that nobody is in trouble for the answer, then ask:

1. Which AI tools did you use last week?
2. Was the account personal or provided by the company?
3. What did you paste, upload, or connect?
4. What work became faster or better?
5. What still needed manual cleanup?

Do not ask only managers. Managers see outputs. The person doing the work knows how the report was assembled, which spreadsheet had to be fixed, and what went through a personal account. People tell the truth right up until the question feels like an investigation.

What you are looking for

• Company data in personal accounts
• Useful prompts held by one employee
• Repetitive work nobody has tried to improve
• The same paid tool bought by several departments
• Work that AI started but a person had to redo

Name an owner

The most consistent finding across every company we entered: nobody owned this. Licenses bought, usage never checked, one or two people quietly figuring things out alone. AI adoption dies when everyone supports it and nobody owns it. Name one person, and make the work part of their job, with time and authority attached. That person owns:

• The approved-tool list, and the data rules worked out with IT
• A running queue of work worth testing
• The first visible win
• Saving useful work so other employees can run it
• Reporting what shipped and what it saved
• Stopping work that cannot be reviewed safely

Bring IT in from the first day, but do not hand IT the program. IT can tell you what is safe. It cannot tell you which hour of a quoter's day disappears into manual lookups, because IT doesn't do that job. Pick someone close enough to operations to recognize real pain and senior enough to get answers: usually an operations leader, chief of staff, or business-unit head. Do not pick the most enthusiastic AI user just because they are enthusiastic. The owner has to keep leadership, IT, and employees moving after the novelty wears off.

A useful first assignment: in two weeks, return with the current list of AI tools and account types, five repeated tasks worth examining, and one low-risk task to test first. That is enough to begin.

Set four rules before rollout

The most common question we heard was some version of: what are we allowed to do, and what should we not do? Nobody had written it down. The first policy should fit on two pages. People need answers they can use mid-task, not a legal memo they will never open.

1. Approved tools and accounts. Name the tools people may use, and require company-managed accounts for company work. A paid personal account is still a personal account. Before you pick a plan, check its data-training and retention settings, and prefer business tiers with contractual no-training terms, SSO, admin controls, and access removal at offboarding. Terms change, so verify each vendor with the vendor review and record the date.

2. Restricted data. Name what may never be pasted, uploaded, or connected without written approval. Use your own categories: customer records, payroll, pricing and margins, contracts, source code, anything the business already treats as restricted.

3. Human review. Anything sent to a customer, published, entered into a system of record, or used for a financial or employment decision gets a named reviewer who checks it against the source.

4. New tools and connections. Give employees a fast way to ask for a new tool, and give IT a clear review point before any AI system reads from or writes to company software.

The order matters. Teams route around IT because IT is slow, then IT hears about the project at the objection stage and kills it. Bring IT in before the first build and the veto becomes your guardrail: the person who can kill an initiative is the same person whose yes leadership believes. When a connection is needed, start read-only. Read access lets a tool summarize your orders; write access lets it change them. Add write access one workflow at a time, with an owner and a rollback plan, and run each one through the connection sign-off.

Write the policy with the team, not at them. A starter you can copy sits in Appendix A.

Pick the work, not the tools

Do not survey opinions about AI. Ask each person one question: what did you do last week that you would hand to a capable assistant, if one were sitting beside you? The answers will sound ordinary, and none of them will be about AI. Rekeying orders. Hunting old emails for an answer. Rebuilding the same monthly report. That is the list. Ordinary work repeats.

For each task, record who does it, minutes per run, runs per week, the systems or files involved, who reviews the result now, and what happens if the answer is wrong. Annual hours are minutes per run × runs per week × 52 / 60. A ten-minute task repeated fifty times a week costs more than a two-hour task done once a quarter.

Risk is one question: if the AI gets this wrong and nobody catches it, what happens? A wrong internal lookup costs a re-check; a wrong customer invoice costs the customer. Pick a first candidate that repeats every week, costs enough time to notice, produces an output someone else sees, can be checked by a person, needs no write access to a core system, and can be tested in days. Do not begin with the most impressive idea. Begin with work the team will still use after the demo ends. The worksheet turns this into a 30-minute meeting.

Decide: coaching or a build

Once you have the work, one question decides what happens next: can an employee own it, or does it need a system?

A task often starts as coaching: a saved skill that reads approved files and returns an answer for review. When the company wants it to pull from shared systems, run on a schedule, or write back to a system of record, it becomes engineering. The question is not whether AI can do the work. It is who can own it safely after launch.

Ship one low-risk, visible win

Not a rollout. One task, one person, one team. Here is the story we tell most often.

A quoting specialist at a manufacturer had an AI tool and a mandate to use it, and had never opened it. That is the failure mode: "use AI" is not a task. A task has a first step, and this one had none.

The actual day was lookup work. Pull the product specs, find the current price list, compare the inputs against a set of rules, check for recent price changes, record the result. It took 30 to 60 minutes a day, and most of it ran on memory and private notes.

The first version to test was one reusable skill that reads the approved price list and spec files and returns a result card for the specialist to check. It answers one repeated question from approved sources. It writes to no company system and keeps the reviewer in place. Once the team saw one concrete question get one concrete answer, they started proposing the next uses themselves. The friction was never distrust of the technology. It was not knowing what to ask.

What makes a good first win

• A task someone already does every week
• An output visible to someone else: a manager, a customer, a coworker downstream
• The employee can check the answer
• Source files are approved, and no system connection is required
• Testable in days, not a quarter

The anti-pattern is the company-wide rollout as step one. Wide rollouts produce a checkbox and a sanctioned tool nobody opens. A narrow, visible win produces relief instead. One executive, watching a workflow get built live, said it no longer felt like something coming for anyone's job. That relief spreads through a team faster than any memo. Do not announce an AI rollout before this exists.

Train inside the work, not in a course

The gap sits one level below access. A pricing manager told us the hard part was knowing which question to ask and how to ask it. Most AI courses teach features and sample prompts in the abstract, and people return to work unsure which task to change, what data they may use, what a correct answer looks like, or who should review it. A finance lead and a customer service manager cannot use the same lesson. If the work is unchanged on Monday, the training did not work.

Useful training starts with the work, and covers:

• A real task. Work the employee already owns.
• A good example. Show the tool what a correct output looks like. Not "summarize this," but "summarize this the way this one is summarized, using these numbers."
• The data boundary. What the tool may see and what stays out. Most of the fear we met came from not knowing where that line sits.
• A review step. The model can be confidently wrong. Check the answer against an approved source before it leaves the desk.
• A saved version. Keep the instruction where someone else can run and maintain it, so it outlives the person who wrote it.

Employees also need to know where training stops. A task that needs credentials, scheduled runs, shared data, or write access needs engineering.

At one company, an employee with no prior AI experience was running working automations within two weeks, and the team reported six hours saved a week. Nothing changed except that someone sat with them on a task they already owned, then saved what worked.

What stalls the work

People fear what they don't know more than what they do. Most stalls trace back to that, or to nobody being in charge of the month after launch.

The first 90 days

At day 90, do not expect a transformed company. Expect clear rules, several workflows that run without you in the room, an owner who knows what comes next, and a team that has watched it work at least once. That is more than most of the market has.

Appendix

Four tools. Copy, edit the brackets, use them this week.

A. Starter AI usage policy

Replace the bracketed text and review it with IT and counsel. This is an operating template, not legal advice.

Purpose. [Company] permits approved AI tools when they help people do company work safely and accurately. This policy applies to employees, contractors, and temporary staff.

Approved tools and accounts. Use only [approved tools] for company work, on the company-managed account provided to you. Do not use a personal AI account for company information, paid or free.

Restricted information. Do not paste, upload, connect, or disclose [restricted data categories, e.g. financials and margins, pricing, customer lists and contracts, employee data, anything under NDA, credentials] without written approval from [IT or security owner]. When unsure, treat it as restricted and ask [contact].

Review. You remain responsible for the output. Check important claims against the source. A person must review anything sent to a customer, published externally, entered into a system of record, or used for a financial, legal, safety, or employment decision.

System access. Do not connect an AI tool to company software, files, email, or data without approval from [IT owner]. Read access and write access are reviewed separately.

New tools. Request a new tool through [process]. Include the business purpose, the data involved, the account type, and who will own it after approval. Expect an answer within [X business days], with a reason for any rejection.

Problems and mistakes. Report accidental disclosure, incorrect output that reached another person, or unexpected system behavior to [contact] the same day. Reporting a mistake promptly is not treated as misuse.

Ownership. [Program owner] owns adoption and work selection. [IT owner] owns security and tool approval. Department leaders own review inside their work. Reviewed every [quarter]. Last updated: [date].

B. Vendor review

Vendor terms change. For each tool and plan, record the answer, the source, and the date reviewed.

• Does the vendor use business inputs or outputs to train its models by default, and can we opt out?
• How long are prompts, files, and outputs retained?
• Can we export or delete our data, and what happens to it if we cancel?
• What happens to connected files and app data?
• Which subprocessors and regions touch our data?
• Does the plan support SSO, SCIM, and role-based administration?
• Can an administrator remove access at offboarding?
• Can administrators see usage without reading private chats?
• What logs and audit trail can we access?
• How fast are we notified of an incident, and what triggers it?

A vendor who can't answer most of these isn't ready to touch your data.

C. Connection sign-off

Complete before any AI system reads from or writes to company software.

• Business owner named
• Exact source system named
• Read and write permissions listed separately
• Data fields documented
• Restricted data excluded or approved
• Authentication method approved
• Logs and monitoring defined
• Human review point named
• Failure and rollback plan written
• Owner for removing access named
• Review date scheduled

No connection begins until the business owner and IT owner sign the same scope.

D. First-win selection worksheet

Run this in a 30-minute meeting. One row per task.

Hours per year = minutes per run × runs per week × 52 / 60. The rule: among tasks with manageable consequences, a human reviewer, and no unapproved system access, pick the one with the highest hours per year that can be tested in days. Ignore the rest until that one is live and trusted.