Where AI actually belongs in business software (and where it doesn't)

Nearly every business software vendor added AI in the last two years, and most of it landed in the same place: a chat panel on the side of the screen. It's the easiest thing to build and the least useful thing to use, because it asks the person doing the work to stop, switch context, describe what they want, and paste the result back.

AI that earns its cost doesn't sit beside the workflow. It sits inside it.

The jobs it's genuinely good at

There's a real pattern to what works. Language models are strong wherever the input is messy human output and the wanted result is structure or a draft.

• Reading documents. Invoices, applications, purchase orders, inspection forms. Pulling fields out of a PDF someone emailed used to need either a person or a brittle template. Now it needs neither.
• Classifying and routing. Which department does this belong to, is this ticket urgent, does this email contain a commitment. Sorting is a language problem, and language models sort well.
• Drafting. The follow-up, the summary, the first version of a description. A draft your team edits beats a blank page, and the edit is where judgment stays.
• Search across your own material. The answer is in a spec, a contract, or six years of job notes. Finding it is the work, and this is the job AI does best.

Notice what these share: a person reviews the output, and a wrong answer is visible rather than silent.

The jobs to keep away from it

The rule is simple. If being wrong is silent, don't use a model.

• Anything arithmetic. Pricing, tax, commissions, quantities. Write the rules in code where they're testable and produce the same answer every time. A model that's right 98% of the time is a disaster on an invoice.
• Compliance and eligibility decisions. If you'll have to explain to a regulator or a customer why a decision came out the way it did, that logic has to be inspectable.
• Anything irreversible without review. Sending, paying, deleting, committing. AI can prepare those. A person should trigger them.

The temptation is to reach for a model because it's faster to build than the rules. That trade is fine for a draft and terrible for a calculation.

Governance, without the committee

You don't need a policy binder, but you do need answers to four questions before AI touches business data.

Where does the data go? Use business-tier providers whose terms say your data isn't used for training, and know which provider handles what.

How much are you sending? The minimum the task needs. There's rarely a good reason to hand a model an entire customer record when the job requires two fields.

Can you see what happened? Keep a record of what was processed and what came back. When someone asks why the system did something six months from now, that log is your answer.

Who checks it? For anything that leaves your building or changes a record, a person. Design the review step in from the start rather than bolting it on after the first bad output.

The part nobody mentions: it costs money per use

Traditional software costs the same whether you use it once a day or a thousand times. AI doesn't. Every call carries a token cost, and a feature that looks cheap in testing behaves differently once a whole department uses it daily.

This should shape how you buy it. A vendor folding AI usage into a flat fee is either capping your usage somewhere you can't see, padding the fee to cover the worst case, or planning to renegotiate. We pass model and token costs through at cost, separately from the monthly fee, because usage genuinely varies and you should be able to see the real number.

The short version

Put AI where the work happens, not in a sidebar. Give it the messy language jobs and keep arithmetic in code. Assume a person reviews anything consequential. Know where your data goes and keep a log. And treat the running cost as a real line item, because it is one.