AI that is real, and AI that is marketing

Two things are true at once

The first is that language models are a real capability shift. Reading unstructured text and turning it into something structured used to require either a person or a brittle set of rules. It no longer does, and that changes the economics of a large amount of clerical work.

The second is that most of what is currently marketed as AI is a feature label applied to existing software, or a pilot that will not survive contact with real data. Both are true, and holding both is the only way to make a good decision.

What the technology is genuinely reliable at

Reliability here means: performs consistently on messy real inputs, and fails in ways you can detect.

• Extraction. Pulling defined fields out of documents that arrive in inconsistent formats. Invoices, forms, applications, correspondence.
• Classification and routing. Deciding what an incoming message is about and where it should go.
• Summarization of supplied text. Condensing something you provide. Note the constraint: text you supply, not facts it recalls.
• First drafts. Getting from blank page to editable material, where a person is reviewing before anything goes out.
• Translation between formats. Notes into a structured record, transcript into action items.

The pattern is consistent: transforming information that is already in front of it. That is where current systems are strong.

Where it fails, and how the failure looks

The dangerous failure mode is not being wrong. It is being wrong in fluent, confident, well-formatted prose that reads exactly like being right.

Specifically, do not rely on these systems as a source of fact from memory, as a final authority on anything with legal or financial finality, or as a substitute for arithmetic on your actual records. And do not deploy anything into a workflow where a wrong answer proceeds unreviewed.

How to read a vendor claim

Four questions filter most of it.

1. What task does this do, in the words my staff would use? If the answer arrives as capability language rather than a task description, there is no defined use yet.
2. What happens when it is wrong? A serious answer describes confidence handling, escalation, and logging. An unserious one describes accuracy in the abstract.
3. What does it connect to? A tool that cannot reach the systems where work happens creates copy-paste labor rather than removing it.
4. What does my data do? Where is it processed, what is retained, who can see it, and does that satisfy the obligations we already carry.

Vagueness on the second and fourth questions is the most reliable signal you are being sold a demo.

The measurement most pilots skip

Before building anything, measure the manual process. How many of these come in weekly, how long does each take, how often is one wrong, and what does the error cost to correct.

Without that baseline there is no way to evaluate the result. The project will be assessed on impression, and impression favors whichever option was more recently demonstrated. With the baseline, the conversation afterward is arithmetic.

Scope small on purpose

The instinct is to look for a transformative application. The better move is the opposite: pick one bounded task, automate it end to end including the exception path, and run it in parallel with the manual process until it has earned trust on your own data.

Small scope is not timidity. It means a failed attempt costs weeks instead of a year and a platform commitment, and a successful one produces something specific you can point at when deciding what to do next.

The part that is actually hard

It is not the model. Access to capable models is cheap and getting cheaper. The difficulty is everything around it: getting clean data out of the system that holds it, writing results back reliably, handling the cases nobody described, deciding what happens when confidence is low, logging enough to audit a decision months later, and defining who owns the process once it is live.

That work is ordinary systems integration, and it is where AI projects succeed or quietly stall. A vendor whose pitch is entirely about model capability and silent on integration has not encountered the hard part yet.

A reasonable position to hold

Take it seriously, and take it in small pieces. Find the task your team dreads. Measure it. Automate the narrow version. Keep a person on the exceptions. Expand only what has proven itself.

That is less exciting than the marketing and it is the approach that ends with something running in production rather than a pilot nobody mentions anymore.