How to scope a pilot narrowly, triage risk on two axes, name a human checkpoint, and walk into the compliance conversation prepared.
The AI pilots that stall are almost never stalled because the technology does not work. They stall because the proposal that reaches the compliance officer is too broad to evaluate, too vague to approve, and too big to reverse if something goes wrong. A pilot that gets approved on the first pass is usually a small, specific, well-bounded proposal, not an ambitious one.
Pick one workflow, one team, and one tool. Not "AI for clinical documentation" across a department, but "AI drafting assistance for discharge summaries, used by three nurses on one unit, reviewed and signed by the nurse before it goes in the chart." A narrow scope is easier to reason about, easier to monitor, and easier to roll back. It also gives compliance a concrete thing to say yes to, instead of an open-ended commitment they have to defend later.
Set a time box too. A pilot that runs for six weeks with a defined end date and a go or no-go decision is a different request than an open-ended rollout with no stated limit.
Before proposing a pilot, place it on two axes: consequence of error, and data sensitivity. Consequence of error asks what happens if the AI output is wrong and nobody catches it before it affects a patient, a client, or a decision. Data sensitivity asks what kind of information the tool will see, from public or already-disclosed material at the low end to protected health information or privileged material at the high end.
Low consequence and low sensitivity is where you should run your first pilot. Drafting internal talking points, summarizing public research, or generating a first-pass outline that a human rewrites before it goes anywhere. High consequence or high sensitivity work is not off-limits forever, but it needs a stronger case, tighter controls, and usually should not be the first thing you pilot. If a proposal is high on both axes, that is a sign to shrink the scope, not a sign to add more approval meetings.
Every pilot needs a specific, named point where a human reviews the AI output before it has any effect. Not "a clinician will review it" in the abstract, but "Dr. X reviews and signs every note before it is filed, and that step cannot be skipped." Compliance officers approve pilots where the checkpoint is concrete and cannot quietly disappear under deadline pressure. They reject pilots where review is described as a general expectation rather than a required step in the workflow.
Before the pilot starts, write down what would make you call it a success, what would make you call it a failure, and what would make you extend it for more data. This matters for two reasons. It keeps the pilot from drifting into a permanent, unevaluated fixture. And it gives compliance confidence that there is a defined off-ramp if something is not working, rather than a program that just keeps running because nobody set a decision point.
Walk in with the scope, the two-axis risk placement, the named checkpoint, the time box, and the success and failure measures already written down. Also bring the vendor's data handling terms, whether a BAA or equivalent agreement is in place if it is needed, and who on your team is accountable if something goes wrong during the pilot. A compliance officer who receives all of that in one page can usually give you an answer quickly. A compliance officer who receives a general pitch about AI's potential cannot approve anything, because there is nothing specific to approve.
If you want help putting a pilot proposal together before that conversation, that is the kind of work I do with leadership teams. See the contact page to set up a call.
This article is general information, not legal advice. Talk to your compliance officer or counsel about your specific situation.