Move Fast and Break Compliance
A single developer with an AI assistant can stand up login, a database, payments and a public API in an afternoon. It is one of the most empowering shifts in software's history — and it has quietly detached the act of building from the context that used to travel with it. The code review. The threat model. The security architect who asked the awkward question. This is about the requirements you cannot see, why they get exponentially more expensive the longer you ignore them, and the four questions that turn compliance from a tax into a way of building.
How AI-accelerated building outran the rules that make software trustworthy — and what that quietly costs.
A single developer with an AI assistant can now stand up a working product — login, database, payments, a public API — in an afternoon.
I want to be unambiguous about this before I say anything else: it is one of the most empowering shifts in software’s history. It has pulled a far wider range of people into building real things — people who would once have needed a team, a budget and eighteen months of somebody’s permission. I have spent my career arguing that the barrier between having an idea and shipping it is the most expensive barrier in business. That barrier is falling. I am not here to mourn it.
But something else fell with it, and almost nobody noticed, because it was never on the screen.
Building software used to arrive with context attached. Not because engineers were more virtuous, but because the process dragged the context along behind it — the code review where someone squinted at your schema, the threat-modelling session nobody enjoyed, the security architect who asked the one awkward question that ruined your afternoon and saved your company: where does this data go, and who can see it?
The AI does not ask that question. It was never asked to.
Meet the vibe coder
Let me be careful here, because this is where the argument usually turns snide and stops being useful.
The vibe coder is not careless. They are not unskilled. They are doing something entirely rational: optimising for the thing they can see — a feature that works, a demo that lands, a product that exists by Friday — over the things they cannot. And the things they cannot see are the data-handling obligations, the access controls, the audit trails, the retention rules, the breach-notification duties that any serious product has to satisfy before it is allowed to be trusted with a stranger’s life.
The software does exactly what it was told. That is the whole point of it. That is also the trouble.
Nobody told it to honour constraints it could not see.
The AI is not the risk. The AI is a perfect mirror of the question you asked. The risk is everything you did not think to ask for — and the faster it answers, the less time you spend noticing what is missing.
The requirements that are invisible until they are urgent
The pattern is now so familiar I can practically set my watch by it.
The product works. The demo is flawless. Customers sign up. There is genuine, real, hard-won traction — the thing every founder is told to chase, and this team chased it and caught it.
And then a prospect’s security team sends over a due-diligence questionnaire. Or an EU user exercises their rights and asks, politely, how their personal data is processed. Or an enterprise buyer — the one whose logo would change everything — asks for a SOC 2 report as a formality, the way you might ask someone for their address.
And the team discovers, in the space of about ninety minutes, that there is no audit log. That secrets are sitting in plaintext in a config file. That every engineer has production access, because of course they do, that was the fastest way to fix things. And that there is no way — no actual mechanism, anywhere in the system — to genuinely delete a user.
None of these were bugs. Every test passed. The code did what it said.
They were invisible requirements. And here is the cruel asymmetry of the new speed: the faster and more fluent the assistant, the more confidently you will ship something that is functionally complete and structurally non-compliant. Fluency is not the same as soundness. A thing can be beautifully built and standing on nothing at all — which is, more or less, the picture at the top of this page.
The uncomfortable economics
This is the part that has nothing to do with ethics, and everything to do with arithmetic. I find it is the only version of the argument that reliably changes behaviour, so let me put it plainly.
Compliance cost rises steeply the later it is addressed. Not linearly. Steeply.
A decision made at design time — every table holding personal data carries a user ID and a deletion hook — costs minutes. It is a sentence in a schema review. It is nothing.
The identical decision, made after two years of production data, spread across a dozen services, replicated into an analytics pipeline, warehoused, cached, and quietly copied into three CSVs someone made for a board meeting, is a multi-month re-architecture. It will consume the roadmap. It will be the reason you did not ship the thing that would have won the quarter.
The decision did not change. Only when you made it.
Security and privacy controls are foundations. And adding a foundation to a building that is already standing — occupied, load-bearing, with people living in it — is the single most expensive kind of construction work there is. It is not that it cannot be done. It is that it costs a fortune, takes forever, and everybody has to move out while you do it.
I wrote a while ago that the build got cheap but the bill did not — that AI collapsed the cost of creation and quietly relocated the expense to line items nobody was watching. This is one of those line items. Possibly the largest. It just doesn’t show up until the day someone asks you to prove something.
The build got cheap. The foundations did not. And you cannot pour a foundation under a tower that is already occupied.
This is not a start-up problem
The comforting story goes: this is a scrappy-early-stage thing; the grown-ups have this handled. It is worth killing that story quickly, because it is doing real damage.
Regulators have levied €1.2 billion against Meta. €746 million against Amazon. €530 million against TikTok. These are not careless teenagers in a garage. These are the best-resourced technology companies on the face of the earth, with entire floors of lawyers and privacy engineers, penalised for mishandling ordinary personal data.
And the newer EU AI Act reaches further still — up to €35 million, or 7% of global turnover, whichever hurts more.
Sit with the implication. If organisations with dedicated legal departments and nine-figure compliance budgets get this wrong at that scale, then an early-stage team building on intuition and momentum is not somehow safer. It is merely not yet large enough to have been noticed. The exposure is not smaller. The spotlight is. And the spotlight is precisely the thing that success brings you.
Growth is not the reward that saves you from this. Growth is the event that triggers it.
The gap is closeable — and not by slowing down
Here is the good news, and I mean it sincerely, because I am not interested in an argument whose conclusion is build less.
The gap does not close by slowing anyone down. It closes by making the invisible visible at the one point where it is still cheap: the design.
- Classify your data before you build the schema. Not after. Know which fields are personal, which are sensitive, which are neither — because that single act determines almost every obligation that follows.
- Make least privilege the default. Not the cleanup task. The default. Nobody gets production access because it was convenient at 2am.
- Log consequential actions from the first commit. This one is non-negotiable, and it is the one people most often gamble on and lose — because an audit trail cannot be created retroactively. You either have the history or you do not. There is no migration that invents the past.
- Design the data lifecycle, deletion included. Every piece of data you collect should have a story about how it dies. If it doesn’t, you haven’t designed a system; you’ve designed a liability that accrues interest.
- Treat the AI assistant as a brilliant junior engineer. This is the mental model that fixes most of it. It is fast, tireless, widely-read, and will answer precisely the question you asked — which means it will never volunteer the access control, the input validation or the logging. It is not withholding them. It simply was not asked. So ask.
None of that is a brake. Every item on that list is a decision that takes minutes at design time and months afterwards. This is not the tax that slows you down. This is the thing that stops you being slowed down later, catastrophically, at the worst possible moment — the moment you finally start winning.
The counter-case, honestly
I should steelman the other side, because there is a version of this essay that is smug and wrong, and I would rather not write it.
It is genuinely possible to over-compliance a product to death. A pre-product-market-fit prototype with eleven users does not need a SOC 2 report, a DPO, a formal risk register and a quarterly access review. I have watched teams spend six months building governance scaffolding around a product that the market then declined to want — and that is not prudence. That is an extremely expensive way to avoid finding out you were wrong.
The honest position is not comply with everything immediately. It is narrower and more useful than that: make the decisions that are cheap now and ruinous later, and defer the ones that are merely expensive whenever you want.
Classify the data, put a user ID and a deletion path on every personal record, log the consequential actions, and don’t hand production to everybody — those are the irreversible ones, the foundations. They cost you an afternoon. The certifications, the policies, the auditors and the paperwork can and should wait until there is a business worth certifying. That distinction — between the foundation and the paperwork — is the whole art, and most of the noise in this debate comes from people collapsing the two together.
It comes down to four questions
Strip away the frameworks, the acronyms, the vendor pitches and the two-hundred-page controls matrices, and what is left is embarrassingly simple. Four questions, asked at design time rather than during an audit:
- Who can see this data?
- How long do we keep it?
- How would I prove it?
- How would I delete it?
That’s it. That is the entire foundation, and you can ask all four in the time it takes to make a coffee.
Ask them before the first line of production code, and compliance stops being the thing that ambushes you eighteen months later, after you have built the wrong foundation and staffed a team on top of it.
It stops being a tax on building.
It becomes, simply, the way you build.
The whitepaper
This piece accompanies a longer, more practical paper — “Building Compliance In, Not On.” It goes considerably deeper than an essay reasonably can: the design-time decisions, the controls that genuinely cannot be retrofitted, the regulatory exposure in plain language, and a working sequence for teams who are already moving fast and have no intention of stopping.
It is free. No sign-up, no gate, no catch.
If the argument here lands, the related work is Silo — the governance and evidence layer built on exactly this premise, that a system which cannot prove what it did is a system nobody should be asked to trust — and Trust is the New Infrastructure, which is the same idea pointed at the whole industry rather than at your schema.
Sources
- Meta — €1.2 billion (2023) — fined by Ireland’s Data Protection Commission over transfers of European users’ personal data to the United States; the largest GDPR penalty issued to date.
- Amazon — €746 million (2021) — fined by Luxembourg’s CNPD over its processing of personal data for advertising purposes.
- TikTok — €530 million (2025) — fined by Ireland’s Data Protection Commission over transfers of European user data to China and related transparency failures.
- EU AI Act — penalties up to €35 million or 7% of global annual turnover, whichever is higher, for engaging in prohibited AI practices.
- The economics of late fixes — the principle that defect and design-change cost rises sharply the later it is addressed is long-established in software engineering; security and privacy controls behave the same way, because they are architectural rather than cosmetic.