One reference architecture instead of three competing AI pilots
A governance-first architecture review that consolidated three overlapping AI intake pilots into one compliant build, after a risk review flagged the patient-data exposure each was carrying alone.
The shape of the work
- Industry
- Healthcare & Dental Practices
- Duration
- 8 weeks
- Cooperation model
- Fixed price
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The question we were asked
Three clinics inside the same network had each started their own AI pilot for patient intake, with no shared data plan or oversight. We ran a risk review, designed a single reference architecture with the right guardrails, and sequenced a roadmap that let all three clinics build on it.
A clinic network where three sites had each started an AI intake pilot within the same year, each with a different vendor and each against live patient data. None had been formally reviewed. The engagement began when the network's compliance lead asked a question none of the three could answer: how long does this system keep what a patient told it, and who has seen it?
AI Architecture & Governance
The decision, first
- 01
Three pilots each carrying the same unaddressed risk is one problem, not three projects.
Three teams had independently reached the same omission, which means it was a property of the approach, not of any one team, and one architecture fixes it once.
- 02
Governance designed in costs a fraction of governance retrofitted after a review.
Retrofitting retention and audit onto a running pilot means migrating data whose provenance is already unclear, which is the expensive half.
- 03
Consolidating to one architecture was the only way any of the three could pass a real audit.
One path means one thing to review. Three overlapping pilots would each have needed their own approval, and the network couldn't have carried that.
What the numbers couldn't answer
Three separate teams were each piloting an AI intake assistant against live patient data, without a shared review of data handling, cost, or oversight. Leadership had no way to know which pilot to standardize on, or whether any met the network's compliance bar.
All three pilots had the same gap, which is what made it one problem instead of three. Retention was undefined: nobody could say what was kept or for how long. Access was enforced in each application's own interface, never in its data layer. And no pilot logged who had authorized an output that reached a patient record, so no review could reconstruct a decision after the fact.
We audited all three pilots against a single risk and governance framework, found none of them fully addressed data retention or oversight, and designed one reference architecture with the guardrails built in from the start. The roadmap sequenced a rebuild of the strongest pilot onto the new architecture, with the other two retired.
How we worked it through
Audited all three pilots against a shared data and governance framework
One framework across all three was what turned a shared omission into a single finding, instead of three separate conversations with three teams.
Scored each pilot's approach on risk exposure and technical fit
Each pilot was scored on risk exposure and technical fit separately, so the strongest clinically wasn't automatically the one that could be built on.
Designed one reference architecture with guardrails built in
Retention classes are enforced by storage and access resolves server-side per request, so neither is left to an application to remember.
Sequenced a roadmap to rebuild the strongest pilot and retire the rest
The roadmap sequences a rebuild of the strongest pilot with the other two retired, and their useful pieces folded in, not discarded.
Phase by phase
Phase 1: Audit
Three pilots, one framework
Assessed all three intake pilots against one shared data and governance framework, so none was judged by its own assumptions.
- Governance framework
- Per-pilot audit
Phase 2: Score
Risk against fit
Scored each pilot on risk exposure and technical fit, and found none of the three fully addressed retention or human oversight.
- Risk scoring
- Gap analysis
Phase 3: Architect
Guardrails first
Designed one reference architecture with access control, retention, and audit logging specified up front.
- Reference architecture
- Control specification
Phase 4: Sequence
Rebuild one, retire two
Sequenced a rebuild of the strongest pilot onto the new architecture and a wind-down of the other two.
- Adoption roadmap
- Decommission plan
The decommission plan: the strongest pilot rebuilt, two pilots wound down with their data deleted and useful pieces folded in, and all nine clinics sequenced onto the single build in two waves.
What it changed
3 to 1
Overlapping pilots consolidated
100%
Governance gaps closed
9
Clinics onboarded to the plan
Three to one is the consolidation itself. Governance gaps closed is measured against the framework's own checklist applied to the reference architecture, not to the deployed system, which hadn't yet been rebuilt at the end of the engagement. Nine clinics onboarded to the plan means committed to the sequence: the three pilot clinics run on the build, and the other six are scheduled.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Guardrails in the design
Retention, access, and oversight specified in the architecture, once, for every pilot.
Retention windows, access rules and human oversight are specified in the architecture, so no application has to remember them. Records carry a retention class that the storage layer enforces, access is role-based and evaluated server-side per request, and any model output touching a clinical decision passes through a named reviewer before it reaches a patient record. None of it is optional per pilot.
- Retention classes enforced by storage, not by application code
- Role-based access evaluated server-side on every request
- Named human reviewer before any clinical-facing output
Guardrail configuration, specified before any build: five retention classes the storage layer enforces, access by role resolved server-side on every request, and human oversight locked on for every clinic.
One compliant path
The pilot review: three competing intake pilots scored 31, 84 and 48 of 100 against one network framework, compared row by row on retention, access, redaction, sign-off and audit, with the strongest marked for rebuild.
Three overlapping pilots consolidated into a single build reviewed against one framework.
Three pilots had been built independently by three teams and overlapped in what they did while disagreeing on how they handled data. The strongest was selected on clinical value and rebuilt onto the reference architecture; the other two were retired with their useful pieces folded in. One path means one thing to review, which is what made approval realistic instead of perpetual.
- Three overlapping pilots consolidated into one build
- Selection made on clinical value, then rebuilt on the reference
- One path to review, so approval is achievable
An auditable trail
Every model call logged with its inputs and its authorizer, so a review can reconstruct any decision.
Every model call is logged with its inputs, the retrieved sources, the output, the version of the prompt and model that produced it, and the person who authorized the action. Logs are append-only and retained to the same schedule as the clinical record, so a review months later can reconstruct exactly what the system saw and why it said what it said.
- Inputs, sources, output, versions and authorizer logged per call
- Append-only, retained on the clinical record's schedule
- Any past decision reconstructable in full
One intake conversation reconstructed from the append-only log: the inputs as the model saw them after redaction, the retrieved sources, the accepted output, the prompt and model versions, and the clinician who authorized it.
How the engagement ran
A cross-functional team of 4 worked on a fixed price basis over 8 weeks, covering Reference architecture, Risk & governance review, Adoption roadmap. We ran two-week increments, each one shippable, reviewed with them before it merged. Decisions were recorded as they were made, so the reasoning survived the people who made it.
Eight weeks, fixed price, with the compliance lead in the room for the framework and the clinical leads for the pilot assessment. The consolidation recommendation was the difficult part and was made on clinical value first and technical fit second. Retiring two teams' work is a decision that has to be defensible to the people who built it, as well as to the network.
Three pilots, one framework
Three pilots carrying the same gaps is one problem, not three projects.
Each tab is one check from the network’s governance framework: how each intake pilot stood on it, what the reference architecture does in its place, and why that check pointed to one build. Switch tabs, or use the arrow keys once one is focused.
The framework requires
Every record carries a retention class, and something other than the application enforces it.
- KGKingsmere Green · Front-desk assistant0/20Not metNo retention defined anywhere
- TRThistlewood Road · Pre-visit intake12/20Partly metWindow set for summaries; transcripts kept indefinitely
- ACAldercombe · Symptom questionnaire4/20Partly metExports land in a shared drive with no expiry
- Reference architecture20/20MetRetention classes enforced by the storage layer, never by application code.
Pilots meeting this check in full
0of 3
The same gap in all three pilots.
Why this pointed to one build
Not one pilot could say how long a patient's conversation was kept. The same omission three times is one finding, and it's fixed once: a retention class on every record that the storage layer enforces, so no application has to remember it.
Kingsmere GreenRetired
31 / 100
Clinical value low · folds in appointment-type mapping
Thistlewood RoadRebuilt
84 / 100
Clinical value high · onto the reference
AldercombeRetired
48 / 100
Clinical value medium · folds in translated question sets
Reference architecture
100 / 100
The framework’s checklist, applied to the design
Why three became one: the strongest pilot was chosen on clinical value first and technical fit second, then rebuilt on the reference; the other two were retired with their useful pieces folded in. One path means one thing to review. Totals are the recorded scores; the split into five checks of 20 points is illustrative.
From what a patient says to what reaches their record
Retention, access and oversight are specified in the architecture, so no application has to remember them. None of it is optional per pilot, because there's only one path for it to sit on.
- 01 · SourcePatient intake conversationOne intake build for every clinic on the plan, instead of three pilots each handling patient data its own way.
- 02 · AccessRole check, server-sideAccess is role-based and evaluated server-side on every request, below any application's interface.
- 03 · EngineRetrieval-augmented model callEach call logs its inputs, retrieved sources, output, and the prompt and model versions that produced it.
- 04 · StateClassed storage and append-only logRecords carry a retention class the storage layer enforces; logs are append-only on the clinical record's schedule.
- 05 · DeliveryNamed reviewer, then the recordOutput touching a clinical decision passes a named human reviewer before it reaches a patient record, and the authorizer is logged.
The question that started the engagement
Patient-data retention, access & accountability
How long it keeps what a patient said
Every record carries a retention class, and the storage layer enforces it. Retention is no longer something an application has to remember.
Who can see it
Access is role-based and evaluated server-side on every request. Hiding a screen in one app's interface, which is how all three pilots did it, no longer stands in for control.
Who decided, and on what
Every model call is logged append-only with its inputs, sources, output, versions and the person who authorized it, retained with the clinical record, so a later review can reconstruct it.
Governance gaps closed is measured against the framework’s own checklist applied to the reference architecture, not to a deployed system, which hadn't yet been rebuilt when the engagement ended.
Running more than one AI pilot against patient data? Scope your build in 3 minutes.
Scope your buildNearby engagements
Web PlatformsThe ransomware attack that became a four-hour non-event
A ransomware attack encrypted the primary patient records server. Drilled offsite backups and a written runbook turned what could have been a scramble into a full restore inside the recovery time objective.
Healthcare & Dental Practices · Ongoing retainer
E-commerceA cart that won't check out until the prescription is real
An online pharmacy where a prescription is a first-class record with its own lifecycle, and prescription-only items simply can't leave the cart without one.
Healthcare & Dental Practices · 20 weeks
Web PlatformsThe right blood type isn't enough: it has to be someone who can get there
A donor register that matches each request on blood-group compatibility and on whether the donor can actually reach the hospital. One platform serves a web admin and a mobile client from the same records.
Healthcare & Dental Practices · 16 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
