The Productivity Trap

Denis Bouton, Chief Architect at OBEL™, recently spoke with the CEO of a mid-market professional services firm. By every measure, this organisation was doing AI well: tools deployed across operations, legal, HR, and client delivery. Productivity was meaningfully up. Revenue per head was climbing. The CEO was, rightfully, pleased.

Bouton asked him one question: what does your AI security architecture look like? The CEO paused. Then he said something Bouton has heard from dozens of senior leaders in the past eighteen months:

“Honestly? The productivity gains are so significant that the security and IP side just hasn't come up yet. We'll get to it.”

- CEO, professional services firm

That organisation sits at one end of a wide spectrum. At that end: businesses running AI hard, capturing real productivity gains, moving fast, and operating without a security architecture for any of it. The returns are too compelling to slow down and ask the question.

At the other end are organisations still working through the fundamentals. What AI actually means for their operations. Whether the productivity case is real for their context. How to run a pilot that sticks. For these organisations, security architecture has not come up either, but for a different reason: the AI program itself is not yet defined.

Both groups, and every organisation between them, share one thing: when security is not architected into an AI program from the start, the cost of addressing it later is not proportional to the gap. It compounds. Neither group is reckless. They are pragmatic operators making rational decisions about where to direct energy under constraint. The problem is that this reasoning, which feels correct at every stage of the AI journey, is exactly how organisations walk into the most preventable category of data breach in 2026.

But here is the question neither group is asking: does that CEO actually know what is leaving his company right now? Not in principle. Today. As his team uses AI tools to draft contracts, summarise client files, and work through questions that touch on proprietary strategy, does anything in his stack show him what data reached which model, when, and whether it was classified or scrubbed before it left? Does he have a real-time view of his AI program's exposure? Does anything warn him, or stop a request entirely, when content crosses a threshold it should never cross?

For most organisations, the answer is no. The tools that deliver the productivity gains do not come with the observability to show you what those gains are costing. That CEO is not making an informed trade-off when he says 'we'll get to it.' He is making an uninformed one. And the gap between those two things is exactly where breaches originate.

The productivity gains are real. The security gap is also real.

McKinsey's November 2025 State of AI report found that 88% of organisations are now using AI in at least one business function, up from 65% in early 2024 and 33% two years prior ^[1]. Separate McKinsey Global Institute research found productivity improvements of 20-40% in knowledge-work functions that adopted AI tools systematically ^[2]. These are not marginal gains. They compound. For a 100-person firm, the efficiency equivalent can represent millions of dollars in annual value.

Despite that adoption rate, McKinsey's 2024 governance survey found only 21% of organisations had established policies governing employees' use of GenAI ^[1]. Most were operating on the implicit assumption that existing cybersecurity frameworks, designed for traditional software, would transfer cleanly to AI systems. They don't.

What is actually at risk

The threat model for AI systems is different from traditional application security. Understanding it requires thinking about how AI actually works in a business context, not how it works in a controlled lab.

1. Sensitive data reaching external models with no record of it

When an employee pastes a client contract into an AI tool to get a summary, that content leaves your infrastructure and enters a third-party model's context. Depending on the provider's data terms, it may be retained in logs, used for training, or accessible to support staff. Even where the terms are favourable, you have no audit record of what was sent, when, or by whom. You cannot recover it. You cannot produce evidence of it for a regulator. You may not know it happened at all.

In 2023, Samsung experienced exactly this. Three separate incidents in a single month saw engineers paste semiconductor source code and confidential meeting notes into ChatGPT. The data left Samsung's control permanently. The company subsequently banned external AI tools and spent months rebuilding internal alternatives, suspending the productivity gains they had been chasing in the first place.

2. AI tools manipulated through content they are asked to process

When an attacker embeds malicious instructions in a document, email, or webpage, an AI agent that processes that content can be redirected to take unintended actions: leaking data, executing commands, or impersonating users. As AI agents gain access to internal systems, calendars, and databases, the consequence of a single manipulated input scales accordingly. OWASP listed this class of attack as the number one vulnerability in LLM applications in both its 2024 and 2025 editions ^[9].

Gartner predicts that by 2027, 17% of total cyberattacks will involve generative AI as a vector ^[5]. This is not a future problem. The attack surface exists today, in every AI deployment that processes external content without inspection.

3. AI use your organisation cannot see, govern, or account for

Employees using unsanctioned tools is not new. But the exposure profile of a shadow AI tool is categorically different from a shadow SaaS subscription. A rogue cloud storage account might expose a file. A rogue AI tool exposes every document, question, and thought an employee feeds into it, with no visibility, no governance, and no way to recover what has already been sent.

CrowdStrike's 2026 Global Threat Report found that AI-enabled adversary operations grew 89% year-on-year, with adversaries actively exploiting poorly governed AI deployments at over 90 organisations during 2025 ^[6]. The common factor was not sophisticated attackers defeating strong defences. It was ungoverned AI making exfiltration trivially easy.

4. Proprietary knowledge extracted through a conversation interface

When AI is connected to internal knowledge bases (documentation, research, client files, strategic plans), access control becomes a first-order problem. Without a governed gateway, any user with a login can query the entire internal corpus in natural language and walk away with the output. Unlike a file download, this generates no obvious signal in conventional data loss prevention tools. The output looks like an AI summary. The input was your most sensitive material.

5. No record to produce when legal, insurers, or regulators ask

When an incident occurs, the first question from your legal team, insurer, and regulator will be: what was sent, to where, and when? If your AI program is ungoverned, you cannot answer. You cannot reconstruct the sequence of events. You cannot demonstrate compliance with data protection obligations. And you cannot invoke cyber insurance where the policy required controls you cannot evidence.

The security debt multiplier

There is a well-established principle in software engineering: defects cost exponentially more to fix in production than in design. NIST research quantifies this at between 6x and 100x depending on severity and stage ^[7]. The same principle applies directly to AI governance.

When security architecture is retrofitted after an AI program is already embedded in operations, you face a different problem than if you had designed it in from the start. Employees have established workflows. Data has already moved. Contracts have already been signed with providers that didn't require your data handling standards. The technical debt compounds. Worse, asking people to change how they work after they've been productive for twelve months is significantly harder than establishing the right habits from day one.

IBM's 2025 Cost of a Data Breach report found that organisations with extensively deployed AI security programs spent $2.22 million less per breach than those without ^[3]. That gap doesn't include the compliance remediation, legal review, staff retraining, and contract renegotiation costs that flow from an ungoverned period. The organisations paying that premium built their AI programs first and their governance frameworks second. The cost of that ordering is now measurable.

What security-by-design looks like for an AI program

The good news is that AI security architecture is not as complex as traditional infosec when done from the start. The core requirements are tractable. They are not optional.

• A governed AI gateway that acts as the single ingress point for all AI requests, with no direct connections from employees to external model providers.
• Real-time PII scrubbing on every prompt before it leaves your infrastructure, automatic and not reliant on user discipline.
• Data classification at the gateway. Every message assessed for sensitivity before inference starts, with hard blocks for content that should never reach an external model.
• A tamper-evident audit trail. Every prompt, classification decision, and model response logged with cryptographic integrity, producible to a regulator or insurer within hours.
• Usage governance: spend caps, per-user quotas, and visibility into what your AI program is actually costing, in real time.
• Zero shadow AI. When there is a governed gateway that is genuinely good to use, employees do not need to go around it. That is the design objective.

None of these requirements are unique to OBEL. They are the baseline that any enterprise AI security architecture needs to meet, regardless of which platform or approach you use. The question is whether you build this capability before you need it or after you discover you needed it.

The CEO I mentioned will get there eventually

The productivity he's capturing is real. The gains his team is seeing will continue. And at some point, through a breach, a near-miss, a compliance audit, or a client contract that starts asking questions about AI data handling, the security and IP conversation will arrive on his desk. The only variable is whether it arrives as a planned programme of work or as an incident.

The data suggests most organisations will discover this the hard way. You don't have to.