How to Start Bringing AI into Your Business When You Don't Know Where to Begin

Leadership tells you to "look into whether we can do something with AI." The more you research, the more case studies you find, but you can't tell which of your own workflows they apply to. You've talked to a few vendors, and the conversations went nowhere.

Getting out of this means changing the order. Start from AI and you end up hunting for a workflow that fits. Start from the workflow and the technology choice follows.

Making "AI adoption" the goal is how it fails

The internal approval request says "AI adoption." That's a means, not the thing you're trying to achieve.

What the business actually wants is an operational result: less time spent on processing, covering a staff shortage, more consistent decisions. If that isn't settled first, nobody can tell whether a report saying "we got 85% accuracy" is good news or bad news.

Flip the order. List the workflows that take the most time first, then look at which of them AI can handle. When you line them up, you'll often find some that don't need AI at all. Standardizing an input format, aggregating with SQL, writing rule-based branching logic. Using an LLM for work that those would cover raises costs and makes results less stable.

How to tell which workflows fit

Workflows that suit AI have three things in common.

They happen repeatedly. Automating something that comes up a few times a month won't pay back the effort of building and running it. As a rough guide, look at work that happens dozens of times a month or more, or that takes tens of minutes each time.

The decision criteria can be put into words. Can the judgment an experienced employee makes in their head be explained in writing? If you can write down "under these conditions, classify it like this," that explanation becomes the prompt and the evaluation criteria. If you can't write it down, the workflow itself needs sorting out before AI gets involved.

Mistakes aren't fatal, or a human review step can be added. AI works probabilistically, so it will always be wrong some percentage of the time. For work where an error causes immediate damage, always include a human review step. If you can't, take that workflow off the list.

The poor fits are decisions that carry direct legal liability, work that rarely happens, and work that demands a single answer when there's no single correct one.

Where to start

Inventory your workflows and rank them by "frequency x time per occurrence." Go down the list and check each one against the three conditions above.

Don't pick the biggest one. The most time-consuming workflow is usually core to the business, and if it stops, the business stops. Pick the second or third instead, something the business can keep running without if it doesn't work out.

First-pass triage of inquiry emails, pulling information out of internal documents, drafting routine reports, summarizing meeting notes and extracting action items. These tend to meet the conditions, and if they fail, a person can redo the work.

Why it ends at the PoC

You hear it a lot: "We ran a PoC and nothing came of it." The causes usually come down to three.

It started without evaluation criteria. If you judge by watching a demo and thinking "it's smarter than I expected," it falls apart once real data goes through it. Demos are built from examples that are easy to get right.

There's nothing to compare against. "80% accuracy" alone doesn't tell you anything. Without knowing how accurate people are at that work today, you can't tell whether 80% is worth adopting.

Fitting it into the workflow was left for later. Even when something works, if nobody has decided who uses it and when, who checks the output, and how mistakes get fixed, it stalls right there.

The fix: build the evaluation data first

Prepare what you need to make a decision before testing any technology.

1. Collect 50 to 100 real past cases. Not clean samples. Pick at random from work that was actually processed, and include the unusual cases
2. Have people label the correct answers. The staff who do this work write down what the result should be. If different staff give different answers, you've learned the decision criteria are still vague, and finding that out now is cheaper than finding it out later
3. Set the passing bar first. Decide, in business terms, "how many out of 100 need to be correct for the human review effort to be worth it"
4. Measure the current numbers. How long the work takes people today, and their error rate

Only after all that, try the simplest approach. Sometimes a well-written prompt clears the bar on its own. If it doesn't, add a setup that searches internal documents and passes the relevant parts along (RAG). Consider fine-tuning only if that still falls short. Skip this order and you pay for things you didn't need to build.

Accuracy can't be guaranteed

Be skeptical of anyone who says "we guarantee 99% accuracy." An LLM won't necessarily give the same output for the same input, and if the pattern of your input data shifts, so do the results. It never gets to 100%.

A realistic design builds the workflow on the assumption that errors will happen.

• Attach a confidence level to results and route low-confidence ones to a person

• Have people review a sampled percentage instead of every case

• Keep logs of inputs and outputs so you can trace error patterns later

• Decide who fixes mistakes, and how, before going live

Accuracy can also drop after launch. Changes on the business side cause it: the format of the documents changes, a new product category gets added. Without a way to keep measuring, you won't notice it happened.

How to think about cost

Costs fall into four buckets: initial build, API usage fees, ongoing evaluation and improvement, and human review time.

The last two are the ones people miss. It isn't build-and-done. Every month someone has to look at the results and keep adjusting the prompts and what gets searched. Projects that never assigned that person end up, six months later, with nobody looking at all.

API fees are driven almost entirely by input length. Passing whole internal documents makes the per-case cost jump, so designing it to pass only the parts that matter is itself the cost reduction. Depending on how it's built at the start, this can differ several times over.

On top of that you need data cleanup, access permission design, and log retention. If confidential documents are involved, you also need to map out which data gets sent where.

Before asking for quotes, work out one number on the business side and the conversation goes much faster: "how much can we spend per processed case and still come out ahead?" You can back into it from current labor costs. With that number, you can narrow down implementation options by price.

The order to follow

1. Narrow it to one workflow (rank by frequency x time, pick #2 or #3)
2. Build evaluation data (50-100 real cases + correct answers + passing bar)
3. Try the simplest approach (prompt -> RAG -> fine-tuning)
4. Compare against the passing bar and current numbers
5. Fit it into the workflow (design it with the human review step included)
6. Keep logs and review monthly

Skip step 2 and start at step 3, and you'll stall at the PoC. Of all the steps, that's the one that makes the most difference.

Talking to us

Sometimes just deciding which workflow to start with is hard to settle internally. We take on consultations that start with how to build evaluation data and how to set the passing bar. Choosing the technology comes after that.

It's fine if your company hasn't settled on a direction yet.

Get in touch