A founder reached out to me a while back. Quiet panic in his voice.
Real product. Real users. A hospital deal on the table that would have been the biggest of his company’s life. The hospital sent over their security and architecture questions. He started answering them. And around question fifteen, he realized he could not answer most of them.
Not because the answers were bad. Because he did not know what they were.
He knew his product worked. He did not know how it worked, in the specific terms a hospital needs. Where exactly PHI lived. Every system that touched it. What his retrieval layer did when two sources disagreed. Whether his prompt logs were holding patient data. Whether he could trace any single answer back to its evidence.
He built fast, the way you have to when you are small and just trying to survive. The architecture grew on its own. Nobody ever sat down and mapped the whole thing, because there was never time, and until this deal, never a reason.
Now there was a reason. And the clock was running.
What we actually did
I want to be specific, because the value here was not magic. It was just mapping.
Week one was discovery. Not the pitch deck version of his system. The real one. We sat with him and his lead engineer and walked every path patient data took through the product. Where it came in. Where it went. What stored it. What touched it. What external service saw it. What got logged, and where.
This part is always uncomfortable. It was uncomfortable here too. About halfway through, his engineer went quiet, then said the thing I hear on almost every one of these. “I didn’t realize we were doing that.” There was a logging path nobody had thought about in a year, quietly holding model inputs. Inputs with PHI in them. It never caused a problem. It was also exactly the kind of thing a hospital security team finds, and the moment they find it, they stop trusting everything else you told them.
By the end of week one he had the thing he never had. A full map of his system as it actually was. Every component, every data flow, every place PHI lived or moved or could leak.
Week two was the gap analysis and the plan. We took his real architecture and lined it up against what the hospital was going to require. We sorted the findings by severity. The logging path was a five alarm fire. A few things were slow burns. A couple were technically fine but would create friction in the review if he could not explain them. Then we wrote the fix plan. Specific, in order, sized to what his small team could actually pull off, with a clear “do this first” at the top.
What he walked away with
Three things, all written down.
A system map he could hand to anyone. It became the source of truth his team never had. He told me months later they still use it to onboard new engineers.
A gap analysis, ranked by severity, with evidence for each item. Written so his engineers could act on it, and so a hospital reviewer could read it and see that he understood his own risks.
A fix plan he could start the day after we handed it over. No vague advice. The actual work, in order.
We did not implement most of it for him. His team did. That is usually how these go. The value was not us writing his code. It was him finally seeing his own system clearly, and knowing exactly what to fix before the people who could kill his deal went looking.
How it ended
He went back into the review with the map, the documented controls, and clear answers to the questions that stopped him cold a few weeks earlier.
Different conversation this time. He was not defending himself or making things up on the spot. He explained, in the hospital’s own language, exactly how his system handled patient data, where his risks were, and how he managed them. He pasted parts of the map straight into his questionnaire response.
The deal closed. His technology had not changed. The story around it had. And the one genuinely dangerous gap got fixed before a stranger found it instead of him.
Why I am telling you this
Because the pattern is almost universal and almost nobody sees it coming.
You build fast. The product works. Then a real buyer asks you to explain it at a level you have never had to before, and you find out that “it works” and “I can account for exactly how it works” are two very different sentences. The space between them is where deals stall, where security reviews go sideways, and where months disappear. It’s the same shift I described in the model was never the hard part — the technology was never really the question.
This is the same discipline I use on the systems I run myself. It is not theory. It is just the work of being able to account for every part of a system that touches patient data before someone with the power to walk away asks you to.
The whole thing takes about two weeks. You walk away with a map of how data and PHI actually move through your AI, a findings report ranked by severity with evidence for each issue, and a specific list of fixes in the order that matters. Written so your engineers can act on it and a customer can read it.
And if you already shipped, that is actually the best time to do this. There is real signal to work with, and there is still time to fix what you find.
Better to find it yourself than have a hospital find it for you. Happy to talk through whether now is the right time for your team.
