Applied AI is an AI system that is in production, owned by a person, and accountable for an outcome a business can measure. If any one of those three is missing, it is research — useful, but not yet applied.
The three tests
Most "AI" projects we see fail one of three tests. Pass all three and you have applied AI; fail one and the system is something else — usually a useful prototype, occasionally a press release.
- In production. Real users hit it with real data. It is not a notebook. It is not behind a demo flag. Someone besides the team that built it can break it.
- Owned by a person. A named human is on the hook when the answer is wrong. They have the access, the authority, and the obligation to fix it.
- Accountable for an outcome. The system exists to move a number — cycle time, win rate, accuracy of a downstream decision. The number is instrumented. The team knows when the system is helping and when it is not.
What this rules out
This is not a gatekeeping exercise. Plenty of valuable work doesn't pass these tests — internal explorations, capability spikes, prompt libraries, evaluation harnesses. We do that work too. We just don't call it applied.
What it rules out is the specific category of work that is most likely to waste a company's first year of AI investment: the impressive demo that never gets a production owner, that never moves a number, that gets quietly shelved when the executive sponsor moves on.
The human-in-the-loop corollary
If a system is accountable for an outcome, and the outcome matters, you almost always want a human in the loop. Not at every step — that strangles throughput — but at the points where being wrong is expensive. The design question isn't should there be a human?, it's at which exact decision?
The fastest way to ruin an AI workflow is to put the human review checkpoint in the wrong place — either too early to add value, or too late to catch the error.
The practical takeaway
If you're scoping AI work for your team, write the three tests on the whiteboard before you write the architecture diagram. For every candidate workflow, name the person who owns it in production, name the number it moves, and name the day it goes live. If those three are hard to write — you're not yet ready to build, and that's useful information.
The good news: making them easy to write is the work. That's the work we do.