Why Operating Across Regulatory Regimes Is a Product Design Problem

The first time you try to ship a feature across three different regulatory regimes in the same week, you learn something fast: the compliance problem you thought you had is actually an architecture problem you've been ignoring.

At PRCNX, I run technology across 15+ clinic locations spanning Italy, the UAE and Turkey. Three jurisdictions. Three data residency requirements. Three definitions of what constitutes a medical record, what requires a licensed practitioner's sign-off and what an AI system is legally permitted to do at the point of care. The EU AI Act and MDR on one side. MOHAP guidelines in the UAE on another. Turkish health data regulations on a third. Different consent frameworks, different audit requirements, different rules about what can be processed by a third-party system and what has to stay on-premises.

If you're reading this from a single-jurisdiction product, this probably sounds like a compliance headache. That's the wrong frame. Compliance is the symptom. The underlying problem is that you're trying to ship one product that behaves differently in every market it operates in, and the teams responsible for making it behave differently are the last ones in the room when the product decisions get made.

That's not a legal problem. It's a structural one.

The compliance layer is a product debt trap

The standard approach to multi-jurisdiction compliance looks like this. The core product gets built. Legal and compliance review it. A list of changes comes back: add a consent screen here, restrict this data field there, add an audit log for this action, remove that feature entirely in market X. The product team implements the changes. The product ships. Compliance signs off.

This works exactly once. The second time you try to ship a feature, you do the same dance again. And the third time. Every new feature pays the same tax: build it, then retrofit it for each regulatory context. The compliance review becomes a predictable delay at the end of every release cycle. The product team learns to account for it in the sprint plan. The delay becomes normal.

What doesn't get named is the compounding cost. Every feature built without regulatory constraints in the design phase generates two artifacts: the feature itself and the compliance patch that has to follow it. The patch is usually more expensive than building the constraint in from the start, because the patch has to work around decisions already made in the architecture. Data models get contorted. API responses get filtered in post-processing because the upstream data structure wasn't designed with field-level jurisdiction rules in mind. Consent flows get bolted onto user journeys that weren't designed to carry them. The product accrues what I'd call regulatory debt, the accumulated cost of decisions made without their compliance implications fully considered.

At some point, the debt becomes structural. You can't easily add a new jurisdiction because the product wasn't designed to be jurisdiction-aware. You can't efficiently modify the consent framework for one market without risking a regression in another. The system becomes brittle at exactly the point where you need it to be flexible.

I've seen this happen in healthcare products built by teams that are technically sophisticated and organizationally serious. It's not a failure of diligence. It's a failure of sequence. The product architecture got locked before the regulatory constraints were in the room.

What velocity actually looks like when you get it right

There's a counterintuitive thing that happens when you build regulatory constraints into the architecture from the start rather than retrofitting them at the end.

You ship faster.

Not because compliance gets easier. It doesn't. But because you stop paying the retrofit tax on every feature, and because the product team can reason about jurisdiction-specific behavior without needing a legal review to confirm what the system is allowed to do.

At PRCNX, the data model that underlies the clinical systems was designed from the beginning with a concept we call a jurisdiction profile. Every data entity (patient record, treatment log, consent record, practitioner sign-off) carries a set of jurisdiction attributes that control what can be processed, where it can be stored, who can access it and what audit trail is required. A new feature doesn't get designed in isolation and then reviewed for compliance. It gets designed against the jurisdiction profile from day one. The question isn't "will legal approve this?" It's "what does the jurisdiction profile say this entity is allowed to do, and does our feature design respect that?"

The result is that compliance review at the end of the cycle is rarely a surprise. The constraints were in the design. The review confirms the implementation. It doesn't rewrite it.

This approach didn't make compliance invisible. We still have legal counsel, we still do regulatory review, we still have incidents where a jurisdiction's rules change and we have to update the profile and trace the implications through the system. But the surface area of those changes is contained. A change to the UAE's data residency requirements updates the jurisdiction profile and propagates through the system predictably, rather than triggering a hand-audit of every data flow to figure out what's affected.

The speed gain is real. We cut release cycles from four weeks to two weeks at PRCNX in part because the compliance surface was predictable. Predictable compliance means shorter review cycles. Shorter review cycles mean faster shipping.

The team structure problem

Here's where most multi-jurisdiction product strategies fail even when the architecture is right.

The jurisdiction profile is only as good as the input that built it. If the people who understand the regulatory environment aren't in the product conversations until after the architecture decisions are made, the profile reflects what legal knows, not what the product needs to support. That gap is where the retrofitting comes from.

The standard model puts compliance in a separate function that reviews product decisions after they're made. The product team owns the roadmap. Legal owns the regulatory review. Compliance owns the audit trail. The three functions interact at defined handoff points: requirements go to legal, legal sends back constraints, compliance does a pre-launch check. It's a sequential model built for a single-jurisdiction product operating in a stable regulatory environment.

Multi-jurisdiction products in regulated industries aren't that. The regulatory environment changes. A new guidance from MOHAP changes what an AI system can document about a clinical interaction in the UAE. The EU AI Act's implementation guidance clarifies what a high-risk AI application is required to log. These aren't edge cases that show up once a year. In healthcare, in 2026, they're showing up quarterly. A sequential review model can't absorb that rate of change without becoming a bottleneck.

The structural fix isn't adding more compliance headcount. It's changing when compliance knowledge enters the product process.

At Reviv Italy, the medical director and the legal lead are in the product planning meeting. Not to approve or reject. To constrain. When a new feature is on the table, the first conversation includes the regulatory context. What are the boundaries of what a non-licensed system is permitted to document? What consent requirements attach to this data if a patient is in a cross-border care situation? Those constraints go into the design brief, not the review checklist. The product manager doesn't need to guess at the compliance implications because the person who knows them is in the room.

This sounds expensive. It costs, at most, three hours per week of a legal lead's time. The cost of not doing it is a retrofit on every feature that touches a regulatory boundary, which in healthcare is most features.

The three structural changes that make multi-jurisdiction viable

These aren't theoretical. They're what actually changed how we operate.

First, build a jurisdiction profile and own it as a product artifact. Not a legal document. Not a compliance spreadsheet. A product artifact, maintained by the product team, reviewed by legal and updated on a defined cadence when regulations change. The profile defines what each data entity is allowed to do in each jurisdiction. Every feature brief references it. Every architecture decision is tested against it. When it changes, the change propagates through the product spec, not through a post-launch audit.

Second, change when compliance enters the product process. The handoff model, build then review, works for stable single-jurisdiction products. For anything else, it's a retrofit machine. Move the compliance input to the design phase. Not to slow down decisions, but to make more decisions final. A design decision made with regulatory constraints in the room is less likely to be reopened at the review stage. Fewer reopened decisions mean faster cycles.

Third, define jurisdiction-specific behavior as a product feature, not an exception. The teams that treat regulatory differences as exceptions to the core product spend their time managing exceptions. The teams that treat jurisdiction-specific behavior as a first-class feature of the product build it once and maintain it. The consent flow for the Italian market isn't a patch on top of the global consent flow. It's a jurisdiction variant that the consent flow is designed to support. The distinction sounds semantic. In the codebase, it's the difference between a maintainable system and one where every jurisdiction update requires a surgery.

The hidden benefit nobody talks about

There's a product quality benefit to multi-jurisdiction design that almost never gets mentioned in the compliance literature.

When you design a system to behave differently in different contexts based on explicit rules, you are, by definition, making the system's behavior legible. The jurisdiction profile is a written specification of what the system does and why. Every behavioral difference is documented. Every constraint is named.

That legibility has a value that goes beyond compliance. When something goes wrong, and in a system operating across 15 clinic locations in three countries, something will go wrong, the jurisdiction profile is the first place you look. The incident investigation starts with a specific question: did the system behave according to the jurisdiction profile, or did it deviate? If it deviated, where? If it didn't deviate, is the profile wrong? That structure compresses the investigation. Compressed investigations mean faster fixes. Faster fixes mean fewer compounding incidents.

At Reviv Italy, we've had two incidents in the past year where the agentic support system behaved in a way that required review. In both cases, the investigation went from incident detection to root cause in under four hours. Not because we're unusually good at incident response, but because the system's intended behavior was written down in enough detail that "what should have happened" was not a debate.

Most products don't have that document. Most incident investigations therefore start with a reconstruction effort: what was the system supposed to do? That reconstruction is expensive and often incomplete. The jurisdiction profile is a forcing function for documentation that pays back in incident response velocity.

What this means if you're not yet operating across jurisdictions

If you're building in a single market today and expect to expand, the worst thing you can do is defer the jurisdiction design question. The architecture decisions you make now determine how expensive expansion is later. A product built with a single-jurisdiction assumption in the data model, the consent flow and the audit trail requires a significant rearchitecture to become jurisdiction-aware. That rearchitecture happens at exactly the moment you're trying to move fast in a new market.

The minimum viable jurisdiction design for a single-market product is not complicated. Audit what data you collect and where it goes. Identify which fields would be subject to different rules in the markets you're likely to expand into. Design the data model with those fields as explicit attributes, not hard-coded assumptions. Document the consent and audit requirements for your current market in a format that's extensible: a profile, not a policy.

You don't have to solve for every jurisdiction you might ever enter. You have to make the decision to not make that expansion impossible by the architecture choices you're making today.

The teams that build one product that works everywhere are not the teams with the best lawyers. They're the teams that decided compliance was an architecture problem before it became a retrofit problem.

Multi-jurisdiction isn't hard because regulation is complicated. It's hard because most teams bring the people who understand regulation into the conversation after the people who build the product have already made the consequential decisions. Move that sequence, and the problem changes shape.

If you're building across markets and want to think through what jurisdiction-aware product design looks like in practice, get in touch.

---

This is the eighth in a weekly series on what I see in the market and hear from operators across the companies I've worked with. Next week: why the gap between what a healthcare AI product promises in a demo and what it actually deploys in a clinic is wider than the industry admits, and who's responsible for closing it.