Where AI Actually Fits in Your Business Process

On one of my own projects I built a pipeline that drafts articles straight from a product database and publishes them without anyone touching the file. One of the queued articles had a good angle: a particular category of product in the catalog was making a comeback after years of decline. The idea file had a note attached to it that said, in effect, check the numbers first.

So I checked. The premise was false. The apparent rise was an unrelated category being filed under the same label by the people submitting the data. The real category had been flat for years. If that one note had not been read by a person, the pipeline would have drafted, formatted, illustrated, and published a confident headline that the underlying data did not support.

Here is the part worth sitting with. The pipeline had automated checks, and they all passed. They verified the article's structure, its markup, its links, its metadata. Not one of them looked at whether the claim was true. That gap is the entire subject of this post.

TL;DR: AI is genuinely good at drafting, summarizing, classifying, and extracting - the work that is tedious rather than difficult. It fails in exactly one way that matters: it produces a confident, well-formatted answer that is wrong, and the output looks identical to a correct one. So the automation is only half the job. The other half is a check that tests the claim against the underlying data, not a check that tests the formatting. Build the check first, keep a human wherever being confidently wrong is expensive, and start with one process rather than a program.

What Does "Putting AI in a Process" Actually Mean?

It usually does not mean buying a product. It means taking one step of an existing workflow - a step where someone reads something, decides what it is, and writes something else - and having a model do the reading and writing part. The customer email gets sorted into a category. The meeting notes become a summary. The vendor invoice becomes rows in a spreadsheet. The support ticket gets a first-draft reply.

The work still runs through your systems, on your schedule, in your format. What changes is that a step that used to require a person's attention now requires a person's review. That distinction is the whole game, and most projects that go badly went badly because someone assumed the review step was optional.

What AI Is Genuinely Good At

The honest list is narrower than the marketing and wider than the skeptics allow.

Drafting. First versions of anything - a reply, a summary, a job description, a policy outline. A first draft that is eighty percent right and takes ten minutes to fix beats a blank page every time.

Summarizing. Long threads, call transcripts, incident reports, a quarter's worth of survey comments. Anything where a person would otherwise skim and hope.

Classifying. Routing inbound messages by topic, tagging tickets by urgency, sorting documents into folders that already exist. This is boring, high-volume work where humans get tired and inconsistent and machines do not.

Extracting. Pulling structured fields out of unstructured documents. Invoices, purchase orders, resumes, scanned forms. Getting the date, the amount, and the vendor out of a PDF is a real cost center in a lot of small companies.

Translating between formats. Notes to a report. A spreadsheet to a narrative. A narrative to a checklist. Technical output into language a customer can read.

The pattern across all five is that the task is tedious rather than difficult, and that a person can tell quickly whether the result is right. That second condition matters more than the first.

The One Failure Mode That Matters

Normal software fails loudly. When a script breaks, it stops, throws an error, and someone gets paged. The failure is obvious, which is why we build so little ceremony around detecting it.

This does not work that way. When it is wrong, it is wrong in complete sentences, in the right format, with the right headings, at the right length, in a confident tone. There is no visual difference between a correct output and a fabricated one. You cannot tell by looking, and neither can any check that only looks.

That is why the near-miss above is not a story about a bad model. The model would have done exactly what it was asked to do: take a premise, write a well-structured article supporting it. The premise was the problem, and nothing in the automated path was ever going to catch a bad premise.

So the Check Is the Product

If you take one thing from this: a verification step that tests the format will pass a false answer every single time. The check has to test the claim against the data it came from.

Two examples from the same project, both of which looked like discoveries and were not.

The first was a statistical method for finding the point where a trend changes direction. It worked. It found changes. Then I ran it against a hundred random samples to see how often it found a change where none existed, and it came back with a "significant" result in eighty-two of them. Finding one, therefore, proved nothing at all. The method was not broken. It was simply answering a different question than the one I thought I was asking, and the output gave no hint of that.

The second was an apparent engineering shift in a product line - the average size of one specification jumped sharply in a single year, which reads like a deliberate design change worth writing about. It was not. Two models had been discontinued that year, and removing them from the average moved it. Nothing was engineered. The lineup changed and the arithmetic followed.

Both of those would have made a confident, plausible, well-written article. Both were artifacts of how the question was asked. The only thing that caught them was going back to the source data and asking whether the claim survived contact with it.

Where the Human Stays

The practical line I draw is this: automate the drafting, keep the human on the claim.

Let the machine assemble the report, write the summary, propose the classification, extract the fields. Then, before anything leaves your organization or becomes the basis of a decision, a person confirms the part that would be expensive to get wrong. Not the whole output - the claim inside it.

That means an approval point anywhere the cost of being confidently wrong is high. Anything a customer sees with your name on it. Anything that becomes a number in a financial or compliance record. Anything that triggers a payment, a shipment, or a legal obligation. Anything that gets published.

Where the cost of being wrong is low - internal drafts, first-pass sorting, personal notes - skip the approval and let it run. The review step should be sized to the damage, not applied uniformly out of nervousness or skipped uniformly out of enthusiasm.

The failure I keep seeing is a process that was automated end to end because a demo looked impressive, with the approval point removed as the last "optimization." That is the point at which a system stops saving time and starts manufacturing confident mistakes at scale.

How to Start

Pick one process. Specifically, the one everybody complains about - the weekly report nobody wants to assemble, the inbox that gets sorted by hand, the data that gets retyped from one system into another. There is always one, and everyone in the building already knows which one it is.

Then build the check before you build the automation. Decide what "correct" means for this task and how you would prove it, in a way that does not depend on the output looking tidy. If you cannot describe that check, the process is not ready to be automated - and finding that out on a whiteboard is a lot cheaper than finding it out in production.

Do the one process end to end, with the check in place, and see whether it pays for itself. If it does not, that is a cheap thing to learn. If it does, you now have a working example and a real number, which is a far better basis for the next decision than a vendor's slide deck.

This is the same instinct behind everything else I build. Self-hosting this site is not interesting because it is clever; it is interesting because a release that fails its health check rolls itself back automatically. The value was never the automation. It was the thing that catches the automation when it is wrong.

If you have a process that should be running itself, or one that already does and nobody is entirely sure it is right, let's talk about it - or read more about how I approach automation work.