JD Rico The model is often only one part of the production problem.
What makes an AI system reliable enough to use inside a real business?
Across the cases, the model was often only one part of the production problem.
Reliability depended on a larger system around it.
Usable inputs. Business context. Rules. Validation. Integration. Exception handling. Evidence trails.
Generating a plausible output has become relatively easy. Building a system an organization can rely on is still work.
The model can be the smaller part of the project
Priyank Jain described building forecasting systems across a retail network of roughly 3,000 stores.
The machine-learning work mattered. But most of the effort went elsewhere.
“Most of the year went into data engineering, not modeling.”
The system had to bring together census data, GIS information, traffic sensors, competitor information, spend, and historical sales before the forecasting layer became useful.
That is easy to underestimate when an AI demo starts with clean inputs.
Production systems usually do not.
The data comes from different places. Definitions conflict. Records are incomplete. Important context lives in spreadsheets, dashboards, documents, or someone’s head.
AI does not remove that work.
In some cases it exposes how much of it was there.
Business context is becoming infrastructure
Rohan Kodialam, co-founder and CEO of Sphinx, described a related problem on the enterprise data side.
Organizations could give AI access to data and still get inconsistent answers because the system lacked company-specific definitions, metrics, business logic, edge cases and established ways of making analytical decisions.
Experts then inherited an unexpected new task.
Instead of doing the analysis, they were repeatedly validating AI outputs against business context the system did not reliably have.
Sphinx now focuses its product on that missing layer of company-specific context, making organizational knowledge available to AI without requiring experts to re-explain the business every time.
That points to an important shift in implementation.
A model may know a great deal about the world.
It does not automatically know what your company means by an active customer, qualified lead, profitable store, high-risk account, or successful campaign.
Those definitions are part of the system.
Some things should not be AI at all
Carlos Benavides of Barlo Digital reached the problem from another direction.
In an automated prospect-qualification and outreach workflow, some checks initially appeared plausible but failed during audit.
His response was not to improve every check with another AI call.
“We never pay a model for a check that ordinary code can do.”
That is a useful implementation principle.
AI is useful when a task requires interpretation, classification, synthesis or generation.
For exact validation and known rules, conventional software may be cheaper, faster and more reliable:
- exact validation
- duplicate detection
- required-field checks
- scheduling constraints
- deterministic calculations
- known business rules
Those tasks may be cheaper, faster and more reliable in conventional software.
A production system does not need to use AI for every step.
AI can handle interpretation where it is needed, while deterministic software handles rules that can be stated exactly.
Output is not finished work
Daniel Haiem, CEO of AppMakers USA, described the issue through a bounded extraction task.
AI could parse résumé information into structured fields using a relatively inexpensive model.
The important part came afterward.
Server-side logic still had to verify that the output followed the required structure and that the application could safely use it.
His conclusion:
“Producing output was never the bottleneck. Proving the output is not quietly wrong is.”
That distinction gets more important as AI becomes cheaper.
A system can generate an answer in seconds.
If someone then spends ten minutes checking whether it invented a field, ignored an instruction, confused two entities or returned the wrong format, much of the apparent efficiency disappears.
AppMakers’ broader production work reflects the same concern with designing around model limitations rather than assuming the model will behave correctly every time.
The implementation question becomes:
What catches the failure before it becomes somebody else’s problem?
Verification needs its own design
The same principle applies to research.
Fırat Mıhcı of HumanizeMyAI described an evidence workflow in which AI can retrieve and structure information at a far greater scale than a small team could manually.
But scale creates its own risk.
A system can retrieve the wrong source faster.
It can create a convincing interpretation from weak evidence faster.
It can find support for one side of an argument while missing contradictory evidence faster.
That is why his process separates candidate evidence from accepted evidence and preserves provenance before drawing a conclusion.
HumanizeMyAI’s published evidence protocol now makes that logic explicit: record where material came from, distinguish what a source actually establishes from broader inference, preserve capture dates, and make the path from evidence to conclusion inspectable. (humanizemy.ai)
The principle travels well beyond research.
Greater coverage does not automatically produce greater certainty.
What sits around the AI?
Across the cases, five implementation layers kept appearing:
| Layer | Practical question |
|---|---|
| Inputs | Is the underlying information usable? |
| Context | Does the system understand how this organization actually works? |
| Rules | Which checks should be deterministic rather than probabilistic? |
| Validation | How do we know the output is good enough to use? |
| Exceptions | What happens when the system is uncertain or wrong? |
These are ordinary production questions.
They also account for a large part of the implementation work described in the cases.
And they change the economics of an AI project.
A budget built primarily around model access, prompts and API usage may be missing the expensive part.
The real work may be:
- preparing data
- defining business context
- integrating systems
- encoding rules
- creating evaluation sets
- monitoring failures
- preserving evidence
- building fallback paths
Reliability is what turns a demo into an operating system
This does not mean AI projects require enormous infrastructure to create value.
Daniel Haiem’s example shows the opposite: a relatively inexpensive model can be perfectly adequate when the task is bounded, and the validation is strong.
The question is whether the surrounding system matches the consequence of the work.
A draft that someone will rewrite can tolerate more uncertainty.
A field that automatically changes a customer record cannot.
A research lead can be provisional.
Evidence supporting a consequential recommendation needs a stronger trail.
A recommendation can fail gracefully.
An autonomous action may need retries, deduplication, and a reliable way to confirm that the intended action actually happened.
The model is part of each of those systems.
It is not the whole system.
As access to capable models becomes less differentiated, this surrounding architecture becomes more important.
More of the defensible advantage may sit in the context, evidence, rules, integrations and feedback that make the technology useful inside a particular organization.
Before expanding another AI implementation, it is worth asking one question:
What has to be true around the AI before we would trust the business to act on its output?
If the answer is still mostly “the model needs to get better,” the production problem probably needs another look.
Working through one of those implementations? Email us.
Sources and Contributors
The operator observations and quotations in this article come from our August 2026 research into AI inside real operating workflows.
- Rohan Kodialam — Sphinx
- Daniel Haiem — AppMakers USA
- Carlos Benavides — Barlo Digital
- Fırat Mıhcı — HumanizeMyAI
- HumanizeMyAI — Evidence Protocol
- Priyank Jain — Boost Mobile / EchoStar
