Ask a founder how many regulators their product is subject to and you'll usually get a number that's too low by an order of magnitude. The answer they give is "GDPR." The real answer is closer to forty distinct regulatory regimes, and the gap between those two numbers is where the work happens.
The stacking problem
Consider a small company shipping a workforce-analytics product into Europe. On paper they have one regulation to worry about. In practice the stack looks like:
- The horizontal EU layer — GDPR, the AI Act, the DSA, NIS2, DORA if they touch financial data.
- National implementations of each — fourteen of those if they sell into fourteen member states.
- Sector-specific overlays — health, education, finance, employment law, each with its own supervisor.
- Sub-national pockets — German works councils, French CNIL guidance, Spanish autonomous-community add-ons.
- Soft law — EDPB guidelines, ENISA recommendations, court interpretations that move the goalposts every few months.
None of these layers are optional. None of them perfectly align. And none of them come with a single source you can subscribe to and call it done.
"GDPR" is shorthand for "the part of the iceberg my last lawyer mentioned."
Why it's not just more regulations
The instinct is to model this as a checklist that grows: 5 rules become 50 become 500. But scaling is the easy part. The harder part is that the rules interact.
A retention obligation under one regime contradicts a deletion obligation under another. A localization mandate in country A is incompatible with a discovery obligation in country B. A risk classification under the AI Act changes the consent basis you can rely on under GDPR, which changes the contractual chain you need with your processors.
You don't compose this by hand. You can't even compose it with a spreadsheet, because the cells aren't independent — they constrain each other. Compliance in this shape is closer to constraint solving than checklist execution.
What changes when you treat jurisdiction as a graph
The mental model that actually works: treat each obligation as a node, each conflict as an edge, and let the system tell you which paths through the graph are still legal for your specific configuration.
That sounds abstract. It manifests very concretely. A product team asks "can we ship this feature in Italy?" and gets an answer in minutes — not because someone memorized the AGCOM guidance, but because the graph already encodes which branches are reachable from your current data flows. When the guidance changes, the graph updates, and the question is re-answerable on Tuesday.
That's the shift. Not faster lawyers. Lawyers who can reason about the whole graph at once, with a system that doesn't forget what it learned last quarter.
The honest cost
None of this is free. Building a graph means digesting primary sources continuously — not press releases, not blog summaries, but the actual gazette, the actual delegated act, the actual court decision the day it lands. That work used to be invisible because it was distributed across a thousand law firms. The companies that win the next decade will be the ones that make it legible.