Where to start with AI so you don’t burn the budget

Over the past year the request has arrived in the same shape: “we need AI.” Not “our managers are drowning in email,” not “closing the monthly report takes a week of manual work,” but “we need AI.” That is a conversation about a tool rather than a job to be done, and it almost always ends with a burned budget and the conclusion that “this isn’t for us.”

Where the money actually goes

Not on models. It goes on three things you only see from inside the project.

• Starting from the tool. The platform gets picked first, then someone looks for work to give it. That is buying a machine and then inventing a part to mill on it.
• A pilot with no metric. “Let’s try it and see” is not a pilot, it is spending. If nobody wrote down what is measured and what the number was before, the result can be neither defended nor disproved.
• Data that is not ready, discovered in month three. Reference tables disagree, half the knowledge lives in two people’s heads, documents live in email. A model does not rescue you from disorder; it amplifies it.

The rule for the first project

Your first AI project is chosen not by how interesting it is, but by three properties at once: the process repeats daily, it is measured in hours or money, and a mistake in it is not fatal.

Daily repetition gives you statistics in weeks instead of years. Measurability gives you an argument in front of the owner. A non-critical error earns the right to experiment: if a human checks the output before it reaches a customer, the cost of a miss is a minute of attention, not your reputation.

A good first project is boring. It saves one department two hours a day and never appears in an innovation deck.

What a healthy pilot looks like

1. Four to six weeks. Not a quarter — over a quarter the context shifts and you can no longer tell what worked.
2. One metric. Hours per task, share of requests handled without a human, time to first response, data entry error rate — pick one.
3. A manual baseline. Spend the week before the start measuring how things stand today. Without that number the whole project is a matter of faith.
4. A kill threshold agreed in advance. “If after six weeks we save less than N hours, we close it.” A project that cannot be closed will live forever and cost forever.

What pays off first

The list is shorter than you would expect. Triage and routing of inbound requests. Search across internal documents and policies — the case where an employee burns twenty minutes on “what are we supposed to do here.” Drafts of routine documents and replies. Data quality control: duplicates, anomalies, required fields left empty.

They share one property: a human stays in the loop and owns the final call. The most expensive failures start where AI was put in charge of a decision on a process nobody had properly described.

What not to do

• Don’t start with an “AI strategy.” A forty-page document will be stale before the budget is approved. Strategy is written after the second or third working project, out of experience rather than slides.
• Don’t buy a platform before the pilot. A pilot runs on what you already have. A platform is chosen for load you have measured, not load you hope for.
• Don’t hide the experiment from the people whose work it touches. An implementation a department learns about after the fact gets sabotaged quietly and professionally.
• Don’t count savings in abstract hours. Count in the units the company actually lives by: shifts, orders, shipments, days to close the month.

What to do on Monday

Take one department and write down ten routines it repeats every day. Next to each, put hours per week and the cost of an error. Pick the one with the most hours and the cheapest errors. That is your first project. At this stage you need neither a vendor nor a budget — you need an hour of the department head’s time and an honest list.