Denmark’s AI Problem Isn’t Models. It’s Procurement Without Exit Ramps.

There is a specific kind of failure that only shows up in mature, well-run societies. The kind where everyone is competent, the paperwork is impeccable, and the program still collapses under its own weight.

Denmark has that failure mode. We are good at committees, fairness, and making sure nobody cuts corners. Then we wonder why technology programs turn into a slow-motion lock-in, followed by a public write-off, followed by “we will continue on the old system for now”.

When the country’s universities scrapped an IT project worth more than 300 million DKK and fell back to a legacy system from the 1990s, the details mattered less than the pattern. This is not a university problem. It is a governance and procurement problem that will repeat in every “AI transformation” we attempt, unless we change how we buy, gate, integrate, and kill.

AI makes the pattern worse because it tempts leaders into buying a “program”: a platform, a vendor stack, a multi-year roadmap, and a promise that value will emerge later. That is exactly backwards. AI value is almost always local first. It compounds only after the handoffs are controlled, the data contracts are explicit, and integration is treated as the product.

The quiet killer: procurement that optimizes for fairness, not fitness

Most procurement processes are built to answer one question: “Did we choose fairly?” They are not designed to answer: “Will this ship, integrate, and survive contact with reality?”

Fairness matters. So does repeatability. But in complex digital work, optimizing for procedural correctness creates three predictable outcomes:

• We buy scope instead of outcomes. The contract describes features, modules, and deliverables, not measurable behavior in a live workflow.
• We outsource uncertainty. We pretend the vendor can price unknowns, then punish them for discovering them, which invites change requests and defensive delivery.
• We remove the stop button. Once a program is approved, stopping it becomes a political event. So it drifts until the money is already gone.

This is why “AI transformation” so often turns into theater. The organization becomes fluent in decks, pilots, and steering groups. Meanwhile, the real constraints sit in integration, security boundaries, data quality, and the boring work of changing how people actually do the job.

If you want a Denmark-specific angle, it is this: our institutions are strong enough to keep funding a failing program for years because no single person is allowed to be fully accountable for killing it. Accountability is distributed. Risk is shared. The downside is also shared, which means it belongs to nobody.

Stage gates are not bureaucracy. They are an honesty mechanism.

Every serious transformation needs stage gates. Not the ceremonial kind where you re-present the same status slides. Real gates that force a binary decision: proceed, pause, or stop.

Here is a set that works for AI and for large IT, without turning into a mega-program.

Gate 0: prove the workflow

Before you buy anything big, define the workflow in plain language. Who does what, with which systems, under which constraints. Then pick one slice that is small enough to ship in weeks, not quarters.

• Exit criteria: one workflow, one owner, one measurable outcome, one security boundary.
• Kill criteria: if the “use case” needs five departments to agree before you can test it, it is not a first use case. It is a program disguised as a pilot.

Gate 1: integration-first prototype

Most AI pilots die when they meet the real stack. So make integration the first proof, not the last.

• Exit criteria: the prototype reads from the real source, writes back to the real system of record, and logs every decision.
• Kill criteria: if you cannot get access to data and APIs without months of exceptions, the organization is not ready for AI. Fix the access model first.

Gate 2: decision ownership and controls

If an AI system produces a recommendation, who is accountable for acting on it. If it takes an action, who is accountable for the result. This must be named, not implied.

• Exit criteria: a named owner for each decision point, an escalation path, and a rollback plan.
• Kill criteria: “the business” owns it is not ownership. It is a way to guarantee blame later.

Gate 3: scale only what survives operations

Scaling is not more users. It is more failure modes. You scale after you prove monitoring, cost controls, and incident handling.

• Exit criteria: uptime expectations, alerting, cost ceilings, and a support model.
• Kill criteria: if costs scale with usage but no one can explain the unit economics, do not expand. Measure first.

This is the difference between shipping capability and funding a hope.

Kill criteria must be contractual, not emotional

The hardest sentence in large organizations is: “We are stopping.” Not because leaders are irrational, but because stopping is treated as failure.

In technology, stopping is often competence.

So you want kill criteria that are designed upfront and tied to objective signals. Then stopping is not a drama. It is the plan.

• Time-based: if Gate 1 integration is not achieved by a fixed date, stop or re-scope.
• Value-based: if the workflow outcome does not improve by a defined margin in a defined pilot group, stop or redesign.
• Risk-based: if security exceptions accumulate beyond a threshold, stop until the architecture is corrected.
• Complexity-based: if the number of dependent systems exceeds what the team can control, split the work or stop.

Procurement can enable this, but only if contracts reward outcomes and learning, not volume of deliverables. Pay for passing gates. Pay for measurable improvements. Pay for documentation that makes the system maintainable. Do not pay for slide decks and “frameworks”.

Integration-first architecture beats platform-first ambition

The most expensive mistake in AI transformation is to start by choosing the platform. You end up with a shiny layer that cannot safely touch the systems that matter.

Integration-first architecture starts elsewhere:

• Define the system of record for each key entity. Customer, asset, invoice, case, identity. No ambiguity.
• Build stable interfaces. APIs, events, or file contracts that are versioned and tested.
• Make observability a requirement. Logs, traces, and metrics are not optional for AI. They are how you audit decisions.
• Keep the “clever” part small. Models change. Workflows and integrations last.

This is also why an “AI program” should not be a single mega-program. It should be a portfolio of small bets with shared plumbing. One integration approach. One identity model. One audit standard. Many thin use cases.

I have watched an ERP cutover eat time and trust because integration was treated as an implementation detail. It is never an implementation detail. It is the product your organization will live with.

If you want a deeper view on how governance choices create cost blowouts, see Budget overruns are rarely a surprise. They are a governance choice.

The procurement reset: four moves you can make this quarter

This is the practical part. You can do it in a public institution, a founder-led company, or a regulated enterprise. The mechanics are the same.

1. Name one accountable owner per workflow. Not a committee. A person. Their job is to decide trade-offs and to say stop when the gate fails.
2. Rewrite the RFP around gates. Vendors bid on passing Gate 0 and Gate 1 first, with clear exit criteria. Gate 2 and 3 are options, not assumptions.
3. Contract for integration and evidence. Require working connectors to systems of record, automated tests for interfaces, and audit logs. Treat these as deliverables with acceptance tests.
4. Make the stop decision cheap. Cap exposure per gate. Keep IP and documentation usable if you terminate. Avoid contracts that punish you for learning.

This is also where AI needs a different leadership reflex. The question is not “which model” or “which vendor”. The question is: which workflow, which handoff, which control, which measurable change.

If you are building agentic tools, this connects directly to the idea that release discipline matters more than feature flags. I wrote about it in Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle. The same principle applies to procurement. Default-on spending without gates is how you end up in a corner you cannot reverse out of.

My opinion: Denmark does not need bigger AI programs. It needs better stop buttons.

The universities’ write-off is a warning flare, not a scandal to gawk at. When a 300+ million DKK system is abandoned and a 1990s platform remains, the cost is not only money. It is momentum. It teaches people that modernization is dangerous, so they protect themselves by demanding more process, which makes the next attempt even slower.

AI will magnify that loop unless we treat procurement as a product discipline: stage gates, kill criteria, accountable ownership, and architecture that starts with integration. Small bets. Real interfaces. Measurable outcomes. Stop early when reality disagrees.

That is how you get transformation without the mega-program hangover.