Most healthtech founders treat compliance like a feature they can ship later, once the product works and the users show up. That’s the wrong order, and it’s especially costly once AI enters the stack. Ghazenfer Mansoor, CEO of Technology Rivers, has built more than 50 healthcare applications over the past decade, roughly half of them HIPAA-compliant. That track record is exactly why he’s blunt about what founders get wrong now that AI is in the mix: most don’t know how to make AI HIPAA compliant, and they’re finding out the hard way, after a breach or a failed audit, instead of by design.
In a recent conversation on The CTO Show with Mehmet, he walked through why compliance, clean AI workflows, and a real customer problem all have to exist before a single feature gets built, not after. The conversation covers a lot of ground, from a mobile app he built on a Palm device in 2000 to the architecture decisions that separate a healthtech product that scales from one that quietly collapses under its own technical debt. The through-line in all of it: the startups that survive are the ones that get the foundation right before they get the features right.
“Watch the full episode: How Falling in Love with the Problem Keeps Startups from Failing“
How You Build Then What You Build
Mansoor did not start with a HIPAA playbook. He started with a staffing background, a real gap he could see in the market, and a first startup where he built the entire backend engine himself before talking to a single customer.
It did not work.
“No matter how good the product is, if your customers are not using it, it’s of no use,” he says. So he went back to the whiteboard, talked to actual customers, and rebuilt the product one feature at a time instead of shipping the whole vision at once. That sequencing, problem first, then one validated feature at a time, is the same discipline behind an on-demand medical staffing app Technology Rivers later built HIPAA-compliant from day one: find the customer and confirm the pain point before writing architecture.
The same foundation-first discipline applies once the code exists, not just before it. “Technical debt is like a mess in your house, if you don’t clean it up every day, it becomes a disaster,” Mansoor says. His fix isn’t a quarterly cleanup sprint, it’s cleaning as you go: when a new feature touches a part of the codebase, budget the time to refactor that part while you’re already in there, instead of waiting six months and facing a rebuild.
Why Your AI Strategy Is Failing Before the First Prompt
Before any healthtech founder brings AI into the picture, Mansoor argues there is a process problem that has to get solved first. Most teams pick the tool before they look at the AI and machine learning workflow they’re actually trying to fix, and tools are the wrong place to start.
“AI is going to optimize what you have. If your processes are wrong, you won’t get a good outcome,” he explains. AI does not fix messy data or undefined workflows, it automates them exactly as they are, mess included. His recommendation before any AI rollout: clean the data, map the workflow, define the process, and only then let AI take it over. Skip this step and you end up scrambling later to figure out how to make AI HIPAA compliant after the fact, instead of by design.
Why Compliance Can’t Be Bolted On Later
This is where the episode gets specific to healthtech. Mansoor draws a hard line between regulation and innovation: HIPAA and GDPR are rules, not blockers, and the mistake founders make is treating compliance as a separate track they can layer on once the product is live.
“Compliance cannot be added at a later stage without adding massive complication,” he says. His architecture guidance is concrete: encryption at rest and in transit, audit logging at both the database and application level, and tracking exactly who did what, designed into the system from day one, not retrofitted once a customer or investor asks for it.
Mansoor’s HIPAA compliance checklist for AI-driven products:
- Encryption at rest and in transit, built into the system design, not added post-launch
- Audit logging at both the database level and the application level, not just one or the other
- User-level tracking of exactly who accessed or changed what, and when
- A signed BAA with AI vendors specifically, not just your general vendor stack, before any real patient data reaches them
- No-training and zero-retention terms in those BAAs, confirmed in writing, not assumed
That’s the HIPAA compliance checklist Technology Rivers runs on every healthcare engagement, before a single feature ships.
How to Make AI HIPAA Compliant Without Exposing PHI
The most common misconception Mansoor hears from founders is that any PHI fed into an AI tool automatically gets absorbed into that model’s training data. It does not, if the underlying agreements are in place.
In the US, that agreement is a Business Associate Agreement, and a BAA with AI vendors specifically is what most founders skip. Technology Rivers’ own customers working with OpenAI and Google sign BAAs that specify no data is used for training and, in many cases, a zero-retention policy on top of that. Add data anonymization on top of the contractual protections, and PHI can move through an LLM-powered workflow without training the underlying model on a single patient record.
The Secret to Using AI Without Giving Away Your Private Data
The architecture piece most teams miss when they’re figuring out how to make AI HIPAA compliant is retrieval augmented generation, or RAG. Done right, a HIPAA-compliant RAG setup keeps sensitive data out of the model entirely. Instead of handing sensitive data to a model directly, RAG keeps it in a vector database, retrieves only the relevant chunks for a given query, filters them, and lets the model answer from that limited, controlled context.
There is a second benefit that matters just as much as the privacy protection: RAG cuts down on hallucination. As Mansoor puts it, AI will always give you an answer, even when it does not actually know one, it will guess, and most people never realize they are looking at a guess instead of a fact. Grounding the model in a filtered, retrieved dataset instead of letting it answer from raw training data is what keeps that guessing in check for healthcare, legal, or financial data. That combination, filtered retrieval plus grounded answers, is what a HIPAA-compliant RAG system actually buys you.
The Common Thread
Problem-first product decisions, clean technical debt management, clean processes before AI, and compliance architected from day one are really one answer to the same question: how to make AI HIPAA compliant without slowing the business down. They are the same lesson applied at four different layers of a healthtech company: do the foundational work before you build on top of it, because retrofitting a foundation under a live product is always more expensive than starting with one.
This is not just an engineering argument, it shows up directly in valuation. Mansoor points to a simple benchmark: a typical service business trades at 3-4x EBITDA, but a service business with real technology-enabled differentiation, systems and workflows a competitor cannot simply buy off the shelf, can trade at 15-20x. The startups that treat their architecture, their processes, and their compliance posture as the product, not as overhead, are the ones building something an acquirer or investor will actually pay a premium for, because they figured out how to make AI HIPAA compliant before their competitors did.
Technology Rivers’ healthcare software development services are built around exactly this discipline, compliance and architecture decided before a line of feature code gets written.
