We get asked to add AI to products roughly once a week. The honest answer is that language models are transformative for a narrow band of problems and an expensive distraction everywhere else, and the difference is usually obvious within an hour of looking at the actual workflow.
The test we apply is simple. Is the input unstructured, is the output reviewable, and is a human currently doing it slowly? If all three are true, a model will probably pay for itself. If any one is false, be suspicious.
Where they genuinely pay off
Turning documents into records. Contracts, invoices, inspection reports, scanned correspondence — anything where a person currently reads a PDF and types fields into a system. This is the strongest case by a distance. The input is genuinely unstructured, the output is a structured record you can validate, and the work is expensive because it is done by someone whose time is worth more.
Search over your own material. Retrieval over internal documentation, past projects, policies and support history. The value is not that the model is clever; it is that it reads the whole corpus every time and never forgets a document written before it joined.
Triage and routing. Classifying inbound messages, tickets or applications so they land with the right person with a summary attached. Low risk, because a misroute is cheap and immediately visible.
First drafts of routine writing. Summaries, handover notes, release notes. Someone still edits, but starting from something beats starting from nothing.
Where a database query still wins
- Anything with a correct answer you already store. If the fact is in a table, query the table. A model that is right 97% of the time is worse than SQL that is right always.
- Arithmetic and totals. Compute them. Do not ask a language model to add up a column and hope.
- Decisions you must be able to defend. If you have to explain a refusal to a regulator or a customer, you need rules you can point at.
- High-volume, low-value operations. The per-call cost is small until you multiply it by a million. Run that number before you build.
The part nobody budgets for
The model is the easy bit. The work that actually takes time is everything around it: getting clean input, chunking and indexing sensibly, building an evaluation set so you can tell whether a prompt change helped or quietly broke something, and designing the review step where a human catches what the system got wrong.
That evaluation harness is the single highest-value thing you can build, and it is the most commonly skipped. Without it you are changing prompts on vibes and discovering regressions in production.
If you cannot measure whether a change improved the system, you do not have an AI feature. You have a demo that happened to work the day you showed it.
Keep the human in the loop on purpose
For anything touching money, compliance or a customer relationship, we design the human review step first and the automation second. Not because the models are bad, but because the cost of a confident error in those domains is asymmetric — one bad output costs more than a hundred correct ones saved.
Done that way, the usual outcome is unexciting and valuable: a workflow that used to take a person a day now takes them an hour of checking. No one writes a press release about it. It just quietly pays for itself every month.
We build these systems as part of our AI and blockchain engineering work, and most engagements start with a short feasibility review rather than a build. If you have a workflow in mind, tell us about it and we will give you an honest read on whether it is worth doing.