Build Compliance First, or Don't Build at All
Last week, I shared the 3 questions every healthcare AI project needs to answer before development starts.
This week, I want to go deeper on Question 2 - the one that silently kills more projects than any other:
"Can it run within existing compliance infrastructure?"
Here's the pattern I keep seeing across the industry:
A team gets excited about an AI use case. They prototype it in a sandbox. It works beautifully. Leadership gets a demo. Everyone's impressed. Budget gets approved.
Then someone walks the project over to the compliance and privacy team.
And the project sits there. For weeks. Then months.
Not because compliance is being difficult. Because the team built something that requires infrastructure the organization doesn't have and nobody checked first.
I've learned this lesson the hard way. So now, before I write a single line of production code, I run what I call the Compliance-First Framework. It takes about a day of work upfront. It has saved me months of rework.
The Compliance-First Framework: 3 Layers
Layer 1: Data Flow Mapping
Before anything else, I draw the complete data journey on a whiteboard. Every step. No assumptions.
You need to answer these questions with specifics, not hand-waving:
Where does patient data enter the system? (EHR extract? API call? Manual upload?)
Where is the data processed? (On-premises server? Cloud instance? Third-party service?)
Where is the output stored? (Back into the EHR? Separate database? Dashboard?)
Who has access at each stage? (Service accounts? Specific roles? Admin-only?)
Does any data leave your organization's security perimeter at any point?
That last question is the one that kills projects. If patient data needs to leave your network even temporarily, even encrypted, even "anonymized" - your compliance review just got significantly more complex.
The goal of Layer 1: A simple diagram that shows data in → processing → data out, with every touchpoint labeled. If you can't draw this clearly, you don't understand your own system well enough to build it.
Layer 2: Security Perimeter Check
Now take that data flow diagram and overlay it against your organization's existing security architecture.
The key question: Can the entire pipeline run within infrastructure your organization already controls and has approved?
If yes- you're in a strong position. Your compliance review becomes a formality rather than a negotiation.
If no -and this is critical — you need to scope the infrastructure work FIRST. Before any AI development begins.
Common gaps I see teams discover too late:
The AI model requires a GPU-enabled cloud instance, but the organization only has approved on-premises compute
The model needs real-time EHR data, but the existing integration layer only supports batch exports
The output needs to write back into the clinical system, but the EHR vendor charges separately for write-access APIs
The solution requires a third-party AI service (like an LLM API), which means patient data leaving the perimeter
Each of these gaps adds 3-6 months to your timeline. Each one requires its own approval process. If you discover three of them after you've already built the model, your "6-month project" is now 18 months and leadership starts questioning the ROI.
The goal of Layer 2: A clear yes/no on whether you can build within existing infrastructure. If no, a specific list of what needs to change and how long each change will take.
Layer 3: Governance and Consent Audit
This is the layer most technical teams forget entirely.
Even if your data flow is clean and your infrastructure is approved, you still need to answer:
Does your organization's current patient consent framework cover this specific use of their data?
If you're using AI for clinical decision support, does your governance structure have a process for validating and approving algorithmic recommendations?
Who is clinically liable if the AI system provides an incorrect recommendation?
Does your privacy office need to conduct a Privacy Impact Assessment (PIA) for this specific use case?
Are there jurisdictional requirements you haven't accounted for? (PHIPA in Ontario is different from PHIA in Nova Scotia, which is different from HIPAA in the US)
These aren't technical questions. They're organizational and legal questions. And they take time to resolve often more time than the technical build itself.
The goal of Layer 3: Written confirmation from your privacy and governance teams that the project can proceed under existing frameworks or a clear list of what needs to be created or amended.
Why This Framework Matters
When I run these three layers before development starts, one of three things happens:
Best case: All three layers clear. I build with confidence, knowing the compliance review at the end will be smooth because I designed for it from Day 1.
Middle case: One or two gaps emerge. I scope them into the project timeline honestly. Leadership sees a realistic plan instead of discovering surprises later.
Worst case: Major infrastructure or governance gaps exist. I flag them early and recommend either resolving the gaps first or choosing a different use case that fits within current capabilities.
All three outcomes are wins. Because in every scenario, the organization avoids spending months building something that dies in compliance review.
The Checklist
Here's a simplified version you can use before your next project:
Data Flow (Layer 1):
☐ Can I draw the complete data journey from input to output?
☐ Is every touchpoint documented (source, processing, storage, access)?
☐ Does any patient data leave our security perimeter?
Infrastructure (Layer 2):
☐ Can the entire pipeline run on approved infrastructure?
☐ Have I identified all infrastructure gaps?
☐ Is each gap scoped with a realistic timeline?
Governance (Layer 3):
☐ Does current consent cover this data use?
☐ Is there a clinical validation process for AI outputs?
☐ Has the privacy office been consulted (PIA required or not)?
☐ Are jurisdictional compliance requirements clear?
If you can check every box, build with confidence. If not, you know exactly what to fix before you start.
One Last Thought
The Compliance-First Framework isn't about slowing down. It's about not having to stop.
The fastest healthcare AI projects I've seen aren't the ones with the best models or the biggest budgets. They're the ones that did this work upfront and never had to pause for a surprise compliance review.
Speed comes from preparation, not from skipping steps.
— Guryash
P.S. What does your organization's compliance process look like for AI projects? Reply and tell me — I'm genuinely curious how different health systems handle this.
Want more? Follow me on LinkedIn where I share daily insights on healthcare AI implementation: linkedin.com/in/guryashsingh
