January 2026
What regulation does to architecture
Years of healthcare engineering taught me that compliance, taken seriously, is a design input that produces better systems.
I spent several years leading engineering in healthcare: an enterprise telehealth platform serving over a million patient interactions, then a health-equity fintech moving benefit dollars to the people they were meant for. Engineers from unregulated industries tend to offer condolences when they hear this. The assumption is that regulation is friction, a tax paid in velocity. I went in assuming roughly that. I came out believing the opposite: regulation, taken seriously, is a design input.
The first thing regulated data does is force you to know where it goes. In most companies, the true data-flow map exists in no document; data wanders into logs, analytics pipelines, third-party tools, and engineers’ laptops, and nobody can say with confidence where a given record has been. With patient data, “nobody can say” is not an available answer. You are obligated to know every system a record touches, every vendor it transits, every place it rests, and you discover that drawing the real map is brutally clarifying. That map pays off in every migration, incident, and design review that follows, none of which have anything to do with compliance.
The second thing regulation does is make audit a load-bearing requirement. Healthcare systems must be able to answer who saw what, who changed what, and when, years later, to someone with subpoena power. You cannot bolt that on; an audit trail assembled after the fact from miscellaneous logs does not hold up, and regulators know it. So the record of action has to be designed in: append-only, attributed, complete by construction. Here is the part I did not expect: systems built this way are simply better systems. Debugging improves, because history is queryable instead of reconstructed. Support improves. Disputes between services resolve on evidence.
The third effect is on permissions. Unregulated products grow access control late and reluctantly, as a feature for the enterprise tier, and the lateness shows: roles that map to nothing, admin flags doing the work of a model. In healthcare the question “who may see this, under what authority” is the product. Clinical staff, billing staff, the patient, a guardian, a covering physician: each sees a different slice, and the slices are defined by law and consequence. Modeling authority as a first-class domain concept, from the beginning, was some of the most rigorous design work my teams did. When we later shipped the enterprise capabilities that large health systems demanded, single sign-on and granular permissioning and delegated administration, those deals closed because the model underneath was already there.
The constraint list and the enterprise buyer’s due-diligence checklist are nearly the same document. Where can data live, who can access it, how is access revoked, what happens on breach, can you prove all of the above: every health-system procurement asked these, and the platform’s answers were strong precisely because regulators had been asking first, for years, with sharper teeth.
I notice all of this now because I build platforms that let AI agents act on enterprise operational data, and the security reviews those platforms face are the healthcare questions again, almost verbatim. What can this system touch? On whose authority? Where does the data go, and can you prove it? What is the record of what happened? The enterprises adopting agents are imposing, contractually, what healthcare imposed legally, and they are right to, because the underlying risk is the same shape: a powerful system operating on data whose misuse harms real people.
Engineers trained under regulation arrive at the agent era already knowing how to design data flows that can be enumerated, audit trails that are load-bearing, and authority models that are first-class, because they were never allowed to do otherwise. Engineers trained in moving fast arrive having to learn it, mid-flight, from their customers’ security teams.
I still would not claim regulation is pleasant. Plenty of it is genuinely procedural, and the paperwork-to-safety ratio varies. But the core demands, know your data flows, keep honest records, model authority explicitly, are what rigorous system design looks like. Regulation made me do it before I was wise enough to choose it. The agent era is making everyone choose it.