The Operator's Filter: Which AI Use Case Deserves Investment
Every leadership team I work with has the same problem. There are more AI use cases on the table than there is budget, attention, or organizational capacity to execute. The filter that decides which use case gets invested in is the most consequential decision in the AI Operator Framework.
Most teams do not have a filter. They have a list. The list gets prioritized by whoever is in the room when the prioritization meeting happens. The use case that wins is the one with the loudest sponsor, not the one with the highest expected value.
This post is the filter I use. Four questions in order. If a use case fails any of the four, it does not get investment.
Question One: Does the Use Case Have a Named Operational Owner?
Not a project sponsor. Not an executive sponsor. The person who will live with the operational consequences of the AI system every day, indefinitely.
This question kills more use cases than the other three combined. Most AI projects do not have a named operational owner. They have a sponsor. The sponsor is the person who advocated for the project, found the budget, and chose the vendor. The sponsor's job ends at launch.
The operational owner is different. The operational owner answers the customer complaint when the AI gives a bad response. The operational owner re-trains the model when behavior drifts. The operational owner negotiates with the vendor when the contract renews. The operational owner explains to the regulator what the system did and why.
If the use case does not have a named operational owner, do not invest in it. The system you ship will become someone's accidental burden, and the burden will produce resentment that kills the project within eighteen months.
Question Two: Is the Underlying Data Layer Ready?
AI use cases that fail in production fail because the data layer was not ready, not because the model was wrong.
An AI lead-scoring system fails because the CRM data is inconsistent, lead source attribution is broken, and the team has been working around CRM gaps with informal processes for years. An AI customer support agent fails because the knowledge base is out of date, the ticket history is incomplete, and the product documentation contradicts itself. An AI inventory optimizer fails because the SKU master file has duplicates, the supplier lead time data is wrong, and the system of record disagrees with the actual stockroom.
The model is fine. The data is not.
The filter question. If we shipped this use case today, would the data quality support the output quality the business needs? If the answer is no, the use case is not ready for investment. Fix the data first.
Most leadership teams skip this question because data work is not glamorous, takes months, and does not produce demo-able artifacts. The use cases that succeed in production are the ones where the data work happened first.
Question Three: Is the Failure Mode Acceptable?
Every AI system fails. The question is what happens when it does.
An AI scheduling assistant that fails sends the meeting to the wrong time. Recovery: reschedule. Cost: low.
An AI loan-pricing system that fails approves credit that should be declined or declines credit that should be approved. Recovery: depends. Cost: potentially regulatory.
An AI medical triage tool that fails routes a patient incorrectly. Recovery: limited. Cost: clinical and legal.
The filter question. Can the business absorb the worst-case failure mode of this AI system? If yes, the use case is viable. If no, the use case needs either more guardrails before investment or a different scope.
The mistake I see most. Teams calculate the expected value of an AI use case based on average performance and forget that AI systems have fat-tailed failure distributions. The 99th percentile failure matters more than the average. Investment decisions made on average performance fail when the 99th percentile shows up.
Question Four: Will the Use Case Compound?
This is the question that separates AI projects from AI infrastructure.
A use case compounds if shipping it makes the next use case cheaper, faster, or better. A use case that does not compound is a one-time win. One-time wins are fine, but they are not infrastructure.
An AI summarization tool that produces meeting notes is a one-time win. It saves time on meetings. It does not make any other AI use case easier.
An AI knowledge layer that indexes every meeting, document, and customer interaction is infrastructure. The summarization tool is one use case on top. The next AI tool the company ships uses the same knowledge layer. The cost of the second tool is lower than the cost of the first. The cost of the third is lower than the cost of the second.
The filter question. Does this use case build something the next use case can use? If yes, the investment compounds. If no, the investment is a point solution.
Point solutions are not bad. They just need to be evaluated against their own expected value, not against the compounding curve of an infrastructure investment. Teams that confuse the two end up with twenty point solutions and no platform.
How to Apply the Filter
Take every AI use case currently on the list. Run each one through the four questions in order.
If a use case fails question one (no operational owner), do not invest. Either find an owner who will live with it, or shelve it.
If a use case passes question one but fails question two (data layer not ready), do not invest in the use case. Invest in the data layer instead. The use case becomes viable when the data is ready.
If a use case passes one and two but fails question three (unacceptable failure mode), redesign the scope until the failure mode is acceptable. Sometimes this means a different use case entirely. Sometimes it means human-in-the-loop guardrails. Sometimes it means a narrower deployment.
If a use case passes one, two, and three but fails question four (does not compound), invest if the standalone ROI is strong enough. Just acknowledge it as a point solution and do not pretend it is platform work.
If a use case passes all four, invest. This is the use case worth your attention.
What the Filter Reveals
The first time a leadership team runs this filter against their AI use case list, the typical outcome is harsh.
Of ten use cases on the list, maybe two pass all four questions. Three or four fail at question one. Three or four fail at question two. The remaining one or two fail at question three or four.
This is not a failure of the team. It is a feature of how AI use cases get generated. Use cases come from many sources. Vendor pitches. Industry articles. Competitor pressure. Internal champions. The filter is the discipline that separates use cases that should be invested in from use cases that look investable.
Two use cases that pass the filter and ship cleanly are worth more than ten that look good in the planning meeting and fail in production.
The Filter Is Not a One-Time Exercise
The filter runs continuously. Use cases that failed question two last quarter may pass this quarter because the data layer matured. Use cases that passed last quarter may fail this quarter because the operational owner left.
Build the filter into the quarterly planning cycle. Re-run every use case. Re-prioritize. The list is not static. Neither is the filter's output.
This is what discipline looks like in the AI Operator Framework. Not a one-time prioritization. A continuous one. The use cases worth investing in change as the operating environment changes. The filter is the constant.
Structure before tools. Strategy before speed. Systems before scale.
The AI Operator Framework is the methodology for designing, governing, and scaling AI operations inside a business, including the data and citation fidelity layers most companies skip. Explore the full framework at JamilAshkar.com/framework. Start with the free course at JamilAshkar.com/course.
