Not every AI idea that reaches a small behavioral-health practice deserves a pilot. Some proposals are simply too vague to approve, even on a limited basis. Approving a vague use case transfers the hard work of definition into the live environment, where the cost of discovery is higher and the risk of scope expansion is greater. Recognizing the warning signs early is one of the most practical forms of governance a practice can exercise.
This article lists five recurring signals that a proposed AI use case is not yet ready for approval. Each signal is drawn from conversations inside a five-to-fifteen-person clinic. The list is not exhaustive. It is a working filter that has prevented several under-specified experiments from consuming staff time. The filter does not replace professional judgment or legal review. It simply forces the conversation to become specific enough that those later steps have something concrete to evaluate.
Sign 1: The Use Case Is Described Only in Benefits
When a proposal begins with “this will save time” or “this will reduce burnout” and never names the exact workflow, the conversation is still at the aspiration stage. Benefits are not a use case. A use case specifies the inputs, the outputs, the people who will act on those outputs, and the boundaries that will keep the process contained.
We now require a one-sentence description that answers three questions: What data enters the process? What comes out? Who reviews the output before it is used? If that sentence cannot be written, the proposal is not ready.
Sign 2: No One Can Name the Data That Will Leave the Practice
Vague proposals often assume that “the system will handle the data appropriately.” That assumption is not a data map. Before any approval, someone must list the specific fields or free-text elements that will be processed by an external tool and confirm which of those elements are permitted to leave the internal environment.
If the team cannot produce that list in a short meeting, the use case remains too undefined. The absence of a data map is itself evidence that the practice is not ready to proceed.
Sign 3: Human Review Is Mentioned but Not Designed
Many proposals include the phrase “staff will review the output.” That phrase is not a design. Functional review requires a named role, a specific moment in the workflow, a clear input, and a recorded decision. When those elements are missing, the review step will almost certainly collapse into a checkbox under ordinary clinic pressure.
We treat the absence of a designed review step as a hard stop. Designing the review is not a later implementation detail. It is part of the decision to approve the use case at all.
Sign 4: Ownership of the Stop Decision Is Unclear
Every pilot needs a clear answer to the question: Who has authority to pause or end this workflow, and under what conditions will that authority be exercised? When the answer is “we’ll decide if problems arise,” the practice has already accepted an open-ended commitment. Vague ownership of the stop decision is a reliable predictor of later difficulty.
Writing the stop conditions into the decision record before the pilot begins converts an abstract governance principle into an operational fact. Without that written ownership, the use case remains too vague to approve.
Sign 5: The Proposal Relies on Vendor Claims Instead of Practice Reasoning
When the primary justification for a use case is “the vendor says it is HIPAA compliant” or “other practices are already using it,” the practice has outsourced its judgment. Vendor claims and peer adoption can be useful inputs. They cannot substitute for the practice’s own analysis of data, ownership, and review.
We now treat heavy reliance on external claims as a signal that the internal reasoning is still incomplete. The decision record must be able to stand on the practice’s own mapping and boundaries even if the vendor language later changes.
Using the Five Signs as a Working Filter
These five signs are not a scoring system. They are conversation starters. When two or more appear in a proposal, we pause the discussion and return to the mapping and decision-record work. The pause is not a rejection. It is a requirement that the use case become specific enough to defend. In practice the pause often lasts one or two focused meetings. That time is almost always shorter than the time later required to untangle a pilot that launched without clear boundaries.
The filter also protects staff attention. When every new idea receives a full pilot by default, the practice’s limited capacity for careful work is quickly consumed. Requiring specificity first creates a natural queue. Only the proposals that can answer the basic questions move forward. The others wait until their sponsors are ready to do the definitional work.
That’s a judgment call, not a tool question. Approving a vague AI use case feels like progress in the moment. It usually creates more work later. Taking the time to insist on clarity before approval has consistently reduced the number of pilots we later had to redesign under pressure.
Slow is not the same as behind. The practices that learn to recognize these signs early spend less time cleaning up experiments that should never have left the planning stage. The ones that treat every suggestion as an immediate pilot opportunity often discover the cost of vagueness only after the tool is already embedded in daily routines.