After the first ambitious AI proposal was rejected, we redesigned a much narrower administrative pilot. The new version processed only three structured fields from the intake form and produced a single internal checklist for the front desk. No free-text notes, no patient-facing language, no clinical content. This article documents exactly what we allowed, what we blocked, and the reasoning behind each boundary. The goal is to make the trade-offs visible so other small practices can adapt the approach to their own capacity.
The redesign process itself took several weeks of focused conversation. We started by listing every element of the original proposal and then systematically removed anything that could not be clearly bounded, reviewed, and logged. What remained was almost deliberately ordinary. That ordinariness turned out to be the feature that made the pilot sustainable inside a five-to-fifteen-person practice.
What We Allowed Into the Pilot
The final scope was deliberately small. After a new patient submitted the digital intake packet, staff manually copied three non-clinical fields into a separate secure form: preferred contact method, insurance verification status, and referral source.
Those three fields fed a limited prompt that returned a standardized internal checklist. The checklist reminded the front desk to confirm contact preferences, flag incomplete insurance information, and note the referral source for tracking. Nothing else was generated. The output language was fixed and administrative. It never attempted to summarize clinical content or suggest next clinical steps.
Human review occurred at two fixed points. The operations lead checked the checklist for completeness before any further action. A second staff member verified that the final patient message, written entirely by a human, matched the checklist items. Both review steps were logged with date and initials. The dual review was intentional. A single review step tends to become a rubber stamp when the clinic is busy. Two named steps created a small amount of friction that kept attention on the process.
We allowed the pilot to run for six weeks with a maximum of fifteen cases per week. That volume limit kept the experiment observable and prevented it from becoming invisible background work. At the end of each week the operations lead reviewed the exception log and the volume count. If either number had risen unexpectedly we would have paused. The limit also made training straightforward. New staff could shadow a handful of cases and understand the entire flow in one afternoon.
What We Explicitly Blocked
The blocked list was longer and more important than the allowed list. We refused any free-text clinical or psychosocial content, automatic generation of patient-facing messages, storage of AI outputs inside the primary EHR chart, shared login credentials for the AI tool, and expansion of the three fields without a new decision record.
Each prohibition had a concrete operational reason. Free-text content carried too much residual risk of sensitive detail that could appear in intake narratives. Automated patient messages would have required clinical review capacity we did not want to commit on a standing basis. Storing AI drafts in the chart would have created a permanent record of machine-generated language that clinicians might later need to explain to patients or regulators. Shared logins would have destroyed individual accountability and made access reviews after staff departures nearly impossible. And any expansion of scope required returning to the original judgment process rather than quiet feature creep.
These boundaries felt restrictive during the design meetings. They proved protective once the pilot was live. When a staff member suggested just adding the presenting concern field, the written block list supplied an immediate answer. The conversation returned to the decision record instead of sliding into informal expansion. That moment alone justified the time spent writing the prohibitions in advance.
Why the Narrow Scope Was Defensible
A narrow pilot is easier to train, easier to audit, and easier to stop. Staff could learn the exact steps in a single short session. Exceptions were few enough that the log remained readable and useful for later training. If conditions had changed, such as new staff, new vendor terms, or new regulatory guidance, we could have paused the workflow without disrupting core operations or leaving orphaned data trails.
The modest time savings were real but secondary. The primary value was the proof that a controlled administrative use of AI could exist inside a small practice without eroding accountability. That proof required the discipline of saying no to almost everything the original proposal had wanted. In a five-to-fifteen-person clinic, the ability to stop cleanly is often more valuable than the ability to scale quickly.
Lessons That Transferred to Later Work
Three lessons from this pilot now shape every subsequent AI discussion in the practice.
First, the blocked list is often more valuable than the allowed list. Writing down what will not happen prevents the slow erosion of boundaries that occurs when only the positive scope is documented. Teams tend to remember what they approved and forget what they rejected. A written prohibition list corrects that bias.
Second, volume limits and time limits keep a pilot experimental. Without them, a successful small workflow can quietly become permanent infrastructure before the practice has decided it wants that outcome. The six-week and fifteen-case caps forced a formal review meeting at the end. That meeting became the moment we decided the process was stable enough to continue under the same constraints.
Third, every expansion must restart the judgment process. New fields, new outputs, or new users are not minor adjustments. They are new decisions that require their own record, their own data map, and their own stop conditions. Treating expansion as a simple configuration change is how narrow pilots become broad and unreviewable.
The tool does not sign the note. You do. Keeping that reality visible required us to block far more than we allowed. The resulting pilot was smaller than the original vision. It was also the first version we could fully stand behind when questions later arose from clinicians or from outside the practice.
That's a judgment call, not a tool question. A narrow administrative pilot that survives its own constraints is more useful than an ambitious one that cannot be defended when something goes wrong. The discipline of the blocked list turned out to be the most transferable part of the entire experiment.
Slow is not the same as behind. The time spent defining and defending these boundaries produced a cleaner operating process than any faster path we considered. Other small practices facing similar pressure to adopt AI quickly may find that the same sequence, reject the broad version, write the narrow version, and document the refusals, creates more durable results than trying to move at vendor speed.