Days to Build, Weeks to Prove: AI-Written Code in a HIPAA Environment
The tool itself is almost boring. It takes an Excel file produced by one system and converts the data into the format a customer’s system can actually use. I built it in days — deliberately lightweight, a stop-gap that keeps a significant and growing customer relationship moving while the fully scoped version is built properly. A few years ago this would have been a quarter-long project. With AI-assisted development it was a sprint.
Then comes the part that turned a small utility into a real education: the data in that file is protected health information. The moment ePHI enters the picture, the code is a fraction of the project.
The code was days. The trust was the project.
AI collapsed the build time, but it did not collapse the burden of proof — nor should it. An app that touches ePHI has to earn its way into the environment where it will run. That meant writing a Security and Compliance Brief and a formal risk assessment, presenting the strategy, collecting feedback from security and IT, resolving open decisions one by one, and getting sign-off on a path. The asymmetry is the lesson: when building gets fast, governance becomes the schedule.
What HIPAA actually means for a small app
Compliance for an app like this is not a certification you download. It is a set of concrete behaviors you design in and then prove. No individual health information ever leaves the machine. The one outbound call the app makes carries plan identifiers, a geography, and a date — nothing about a person. Nothing is retained after conversion. Transport is encrypted with no shortcuts. Logs are written so they can never contain PHI. Credentials do not live in files; they are encrypted by the operating system itself, per user account, entered once by a named operator.
Every one of those sentences is a design decision, a line of code, and a piece of evidence a reviewer can check. That triple duty — behavior, implementation, proof — is the actual shape of HIPAA work.
The paperwork is part of the product
I used to think of compliance documents as friction. Building this app changed my mind. The Brief is how security could evaluate a system they did not write. The risk assessment is how open questions became tracked decisions instead of hallway conversations. And the code-review guide might be the most useful document of the set: the reviewing team should not have to wade into an unfamiliar codebase cold, so the guide maps the architecture in plain language, lists exactly what to verify, and ends with a sign-off box that becomes evidence. If you want your work reviewed well, make it easy to review.
AI wrote the code. Humans own the risk.
Does it matter that an AI wrote most of this app? Less than you would think, and in one way that surprised me, it helps: the app is small and legible, which makes it genuinely reviewable. A few hundred lines of shell, a compact converter, a short list of things it is allowed to do. Under normal governance — independent code review, named accountability, signed attestation — the question of who typed the code dissolves into the question that always mattered: can you prove what it does?
One boundary was deliberate: the finished app uses no AI at runtime. Putting a model inside a pipeline that processes ePHI is a different and much harder security conversation, and it deserves to be treated as one. Knowing where that line sits — AI as the builder, not a component — was itself one of the lessons.
Why bother, for a stop-gap?
Because the customer is real, the deadline is real, and a bridge built to compliance standard buys the enterprise time without buying it risk. This is the first desktop application I will deliver into a HIPAA-protected environment, and the education transfers to everything that follows: the fastest way to ship AI-built software in a regulated industry is to take the compliance path seriously enough that nobody has to take your word for anything.