Here in the Netherlands you do not decide how many cows you want and then go build a barn. It runs the other way around, and it is a little bit brutal process about it. Your land has a so called phosphate allowance. The manure rules, the nitrogen rules, the whole beloved circus of mestwetgeving, decide how many animals your hectares are legally allowed to carry. That number is the first line on any plan. It’s there way before the concrete, before the barn, before you have picked anything as fun as a colour. Why are there no pink barns? The regulation is not paperwork you file afterwards. It is the shape of the box you are permitted to build inside.
I have watched a neighbour redesign an entire building around a nitrogen calculation. Nobody out here enjoys it, and there is a lot of muttering at the coffee machine at voetbal kantine. But not one of them treats it as an afterthought, because a permit refused after you have poured the foundation is not a fine. It is maybe a demolished barn and a very bad year.
We in Enterprise IT do the exact opposite, and I think that is so strange. We should actually be a bit embarrassed about it.
The second-sprint question
You know the moment I mean. The system is designed, the happy path works, the demo went well, thank the demo gods, again. And then somewhere in the second sprint somebody raises a hand and asks “is this actually GDPR okay?”. The room goes quiet. It becomes a squad transversal item and Legal gets a ticket. A document appears, the regulation arrives late, owned by the wrong people, bolted onto a thing that was never shaped to receive it.
I wrote about a version of this before, in Beyond the Policy PDF, where the governance lived in a document nobody could actually act on. This is the same thing, except one floor up. The EU AI Act wanting you to explain a decision is not a compliance task, it is an architecture requirement, and you cannot bolt explainability onto a model that was never built to hand you a reason. DORA wanting you to prove operational resilience is an architecture requirement, and you cannot retrofit a clean failover story onto a system quietly held together by one load-bearing workaround. Treat these as design inputs, constraints like latency, cost and availability, and you build a calmer, cheaper thing. So far, so tidy.
Except that is the easy half, and it is not the half that gets anybody’s blood up.
And then they move the fence
Well farmers get very easily very angry, but sometimes they have a point
Or the goal posts. And that is part what actually makes a farmer furious, and it is not just that the rules are strict, or that they are caught… It is that the line moves after you have already built to it. Like a court ruling moving the nitrogen line under all of the plans at once, retroactively, and the barn that was completely legal on Monday was a problem on Tuesday. The Dutch’s rules about the barn changed, and suddenly a compliant building was an expensive liability.
That is what makes everybody blood boil, and not just at the feed store. It’s part that “the rules are hard”. The rules being hard is somewhat fine, you can design against hard. It is “I complied and it did not protect me”
Enterprise IT has exactly this, and we even have a name for the wreckage it leaves. We call it tech debt, except this is debt you never chose to take on. You built your data flows to be compliant, Privacy Shield was blessed, everything was fine, and then Schrems II invalidated the whole arrangement overnight and your perfectly legal architecture was suddenly illegal without you touching a single line of code. The AI Act’s risk tiers will shift. Guidance will “clarify” in ways that quietly reclassify things you already shipped. You will do nothing wrong and wake up in violation.
I called the slow version of this Contextual Decay a while back, the context around a component rotting faster than the component itself. Regulation is just context with lawyers attached. And a system whose compliance was perfectly frozen into the shape of last year’s rule is walking straight into the Amber Trap, beautifully preserved for a world that has already moved on.
Design for the line that moves
So the real design input was never the 2026 clause. You cannot design for the specific future rule, because you do not know it yet, and anyone who claims they do is selling something. What you can design for is the near certainty that the line moves at all. That means keeping the ability to change the thing after the fact, which is the exact muscle I went on about in the build-versus-buy piece, the capability you must not casually buy away, because the day the rule moves is probalby the day you need to rebuild in a hurry. It means keeping data flows re-routable, decisions explainable, and the seams where the regulation bites loose enough to actually adjust.
A system that cannot absorb a rule change is a fragility you can see the day you pour the concrete, you were just admiring the finish instead of looking at the joints.
Leave a Reply