AI Sprawl in Danish SMEs Is Not an AI Problem. It’s a Money-and-Risk Ownership Problem.

Give smart people a powerful tool and they will use it. That part is predictable.

What is also predictable, but less discussed, is what happens next: the tool becomes ten tools. Then twenty. Licenses slip onto expense reports. Sensitive text gets pasted into prompts. Teams build little workflows that never get reviewed. Nobody is malicious. Nobody is “doing shadow IT” on purpose. They are just trying to get their work done.

That is why I do not find it surprising that every second Danish SME has lost control of its own AI use, nor that one in three companies with an AI strategy still cannot control usage. The headline frames it as a leadership failure. I agree. But not in the moral sense. It is a design failure.

Most companies are trying to solve AI sprawl with policies and training. Those are necessary, but they are not sufficient. The bottleneck is the operating model: who owns the spend, who owns the risk, and what “good” looks like in measurable output.

The pattern behind AI sprawl: the path of least resistance wins

AI sprawl is not a mystery. It is the natural outcome of three incentives colliding.

• Employees are rewarded for speed, not tool hygiene. If a new assistant saves 30 minutes today, it gets adopted today.
• Budgets are fragmented. Each team has a small amount of discretion, so nobody sees the total until it becomes embarrassing.
• Risk is abstract until it is not. Data leakage and compliance issues feel theoretical right up to the first incident or audit.

Put those together and you get exactly what the Danish SME article describes: employees pick their own tools, while management cannot see, control, or standardize the usage even when “strategy” exists on paper.

There is a simple rule of thumb here: if you cannot answer “who owns the bill” and “who can turn it off” within five seconds, you have not governed anything. You have just documented intentions.

Stop calling it “AI strategy” when it is really procurement plus security plus productivity

Most AI rollouts fail quietly because they are treated as a tech choice or an innovation initiative. In practice, day-to-day AI usage is closer to three functions working together:

• Procurement: what tools are allowed, under what contract terms, with what renewal and exit conditions.
• Security and data governance: what can be shared, where it can be processed, and what must be logged.
• Productivity management: what outcomes you expect and how you measure whether the tools are earning their place.

If you run those three as separate conversations, you get sprawl. If you run them as one system, you get compounding learning and lower risk.

This is also why I like the framing of “loss of control” better than “lack of AI adoption.” Adoption is not the scarce resource anymore. Coherent use is.

I have written before that sovereign compute is an operating model, not a vendor swap. AI in SMEs is the same genre of problem. Tools are the visible surface. Ownership and process are the real machinery.

The simplest fix that works: appoint an AI spend owner

The biggest mistake I see is treating AI cost as “too small to manage.” That was true when it was one pilot. It stops being true when it becomes the default way people write, summarize, code, design, and analyze.

So here is my blunt recommendation: name an AI spend owner. One person accountable for the total bill and the total value. Not as a gatekeeper for every prompt, but as the person who makes trade-offs visible.

This owner does three things consistently:

1. Defines the allowed tool set (and the path for adding a new one).
2. Defines data classes and which classes are permitted in which tools.
3. Runs a monthly review where spend is compared to measurable output, plus security posture.

That is it. No theatre. No “center of excellence” unless you are big enough to justify one. Just accountability attached to money and risk.

One lived example. I once watched a cloud tool ecosystem multiply inside a product organization because each team optimized locally. It took a quarter to realize we had three overlapping contracts, inconsistent access control, and zero shared logging. The technical part was solvable in weeks. The cleanup took months because nobody could credibly say, “this is the single approved path, and here is the bill if we do not consolidate.” The day we assigned one owner for the spend and one owner for the data boundary, the conversations changed. Not magically. But measurably.

Define “allowed tools” and “data classes” like you mean it

Most AI policies fail because they are either too vague (“be careful with sensitive data”) or too strict (“never use AI”). You need something enforceable.

1) Allowed tools (a short list, not an encyclopedia)

Create a tiered list:

• Tier A (default): approved for general use, integrated with SSO, logged, with clear contractual terms.
• Tier B (restricted): allowed for specific roles or projects, with extra controls.
• Tier C (blocked): not permitted due to data handling, lack of enterprise controls, or unclear terms.

Do not aim for perfect. Aim for legible. People follow rules they can remember.

2) Data classes (five is usually enough)

Define a small number of buckets. For example:

• Public: marketing copy, published docs.
• Internal: non-sensitive operational information.
• Confidential: customer details, pricing, contracts, internal financials.
• Regulated: anything with special legal obligations.
• Secrets: credentials, private keys, security details.

Then make a clear matrix: which data class is allowed in which tier of tool. If “confidential” is allowed only in Tier A, that becomes simple to communicate and enforce.

If you want the mental model, think of it as your AI version of “what can go in email.” Everyone already understands that some things do not belong in the wrong channel.

Measure output, not enthusiasm: the productivity contract

AI adoption is easy to celebrate because it looks like activity. What you need is a productivity contract that turns usage into outcomes.

Pick a few workflows that matter and measure them before and after. Not everything. Just the places where time and quality are visible.

• Sales: time to produce a first draft of a proposal, conversion rate of outbound sequences, time from lead to qualified opportunity.
• Customer support: time to first response, resolution time, deflection rate, escalation rate.
• Engineering: cycle time for small changes, defect leakage, time spent in code review.
• Finance and ops: time to close, reconciliation effort, exception handling rates.

The goal is not to prove AI “works.” The goal is to learn where it pays, where it creates new risks, and where it is just entertainment with a subscription fee.

This is also where many firms get trapped in demos. A demo shows possibility. A workflow shows accountability. If you want a deeper pattern for turning AI into shipped capability, a playbook beats a demo.

Run it monthly: a lightweight governance cadence

Governance does not need to be heavy. It needs to be frequent enough that drift is caught early.

Here is a monthly cadence that works for smaller companies without suffocating initiative:

• Spend review: total AI spend by tool and by team, new subscriptions, renewals due in the next 60 days.
• Tool exceptions: who is using non-approved tools and why, decide whether to approve, replace, or block.
• Data boundary incidents: any reported policy violations, near misses, or unclear cases that need a better rule.
• Output metrics: 2 to 5 workflow metrics, trend lines, what changed, what will be tested next month.
• Kill list: tools or pilots to shut down, with an explicit date.

This is the part most companies avoid. Killing things feels like admitting failure. In reality, it is how you keep learning cheap.

One more link for the same theme from another angle: procurement without exit ramps is how AI costs become permanent even when the value never shows up.

My opinion: free-play is fine for two weeks, then you need a system

I am not anti-experimentation. Let people explore. It is how you discover the surprising use cases.

But exploration has a half-life. After the first burst, unmanaged usage turns into three real costs:

• Financial: duplicated subscriptions, unclear renewals, and a bill nobody can explain.
• Security and compliance: data goes places it should not, and you cannot prove what happened.
• Organizational: people learn different tools, build incompatible ways of working, and you lose reuse.

So yes, call it a leadership failure if you want. I would call it something more actionable: an ownership failure.

Name an AI spend owner. Define allowed tools. Define data classes. Review monthly. Measure output. Shut down what does not earn its place.

That is how you keep AI useful, safe, and affordable. Not by asking employees to self-govern a procurement and security problem with good intentions.