The Discovery
Enterprise AI deals are closing at a pace that would have seemed absurd two years ago. Anthropic and OpenAI are growing faster than almost any software companies in history, and a significant driver is straightforward: enterprises know they need to be in the game. They've seen someone on their team build something useful in an afternoon. They've watched a competitor announce an AI initiative. They've felt the pressure in the board meeting. So they sign the deal, deploy the licenses, and send the announcement.
What happens next looks a lot like this: imagine you've just discovered there's oil on your property. Not a little oil, significant reserves, real value, the kind of thing that could genuinely change the trajectory of your business. You're excited. Rightfully so. And so you do the obvious thing: you hand everyone who lives and works on that property the tools to go drill for it.
What you get is not a windfall. You get environmental disasters. You get people drilling in the wrong places, hitting pockets of gas they didn't expect, contaminating groundwater they didn't know was there. You get a few lucky strikes alongside a lot of expensive messes. Some people get a little. Most don't get nearly what the reserve was worth. And the property itself ends up worse off than if you'd approached it with some discipline.
That's where most enterprises are right now with AI. The value is real. The tools are accessible. And the vast majority of the people now holding those tools have no framework for how to use them responsibly or effectively. It's not a technology problem. It's a methodology problem. And it's why, by some estimates, upwards of ninety five percent of enterprise AI pilots never make it past the proof of concept stage, not because the technology failed, but because the organization wasn't equipped to extract value from it systematically.
Source: MIT Finds 95% of GenAI Pilots Fail Because Companies Avoid Friction — Forbes, August 26, 2025
The oil is there. The question is whether you're going to mine it or make a mess.
What We're Actually Seeing
Enterprises aren't tiptoeing into AI. They're signing broad platform deals with Anthropic and OpenAI at a speed the software industry hasn't seen in years. And unlike most enterprise software, the barrier to actually touching the product is nearly zero. There's no six-month implementation, no change management program, no phased rollout plan. You sign the deal, your employees download the app, and by Tuesday afternoon someone on your team is burning tokens.
That last part is where it gets uncomfortable. Enterprise AI licenses aren't priced like SaaS seats. They're priced on consumption: API calls, tokens, compute. And when you hand that to an organization of any meaningful size without guardrails, the bills climb fast. There are reports of major organizations burning through their projected annual AI budget in under half a year.
Source: Uber's COO on AI Spending, Tokens, and Claude Code — Fortune, May 26, 2026
CIOs who celebrated signing the deal are now watching dashboards with a kind of low-grade anxiety that's becoming an industry-wide experience.
The vendors know this. Anthropic has stood up a partner ecosystem. OpenAI has talked openly about forward-deployed engineering teams that go sit with clients, help them onboard, and drive adoption. These are smart moves. Enterprises are asking for help, and the vendors have an obvious interest in making sure customers see enough value to renew. But it's worth being clear-eyed about what that help is optimizing for. Adoption. Usage. Renewal. Those are vendor metrics. They're not the same as organizational value.
Just using the tools isn't enough. An organization full of people who have learned to max out their token allowance isn't an AI-mature organization. It's an expensive one. The goal isn't consumption. It's capability. And that distinction is where most enterprises are currently flying blind.
The Vendor Onboarding Problem
There's a version of the forward-deployed engineer story that sounds like help but is actually onboarding. The difference matters more than most enterprises realize when they're signing the deal.
When a vendor sends someone in to drive adoption, the implicit goal is fluency with that vendor's product. And for a while, that feels like progress. People are using the tools, workflows are forming, the platform is becoming embedded in how the organization operates. That's exactly when the risk quietly arrives.
Vendor lock-in with AI is different from vendor lock-in with traditional software, and potentially more dangerous. It's not just that your data is in their system or your workflows depend on their API. It's that your people have built their intuition around a specific product. They know how to prompt Claude. They know how Copilot behaves. They've stopped thinking about the capability and started thinking about the tool. And that's when the leverage shifts entirely to the vendor.
The risks aren't hypothetical. There are already examples of AI providers making deliberate choices to limit model performance in certain domains, framed as safety decisions, but with real competitive implications for the organizations relying on those models. And the broader dynamic is straightforward: if Anthropic decides to reprice tokens, restrict certain use cases, or deprioritize your industry, and your organization's AI capability is synonymous with Claude, you have no move. It's the Microsoft Office problem, except the dependency is on something that's actively making judgment calls about what your people are allowed to do effectively.
The answer isn't to avoid these tools. It's to build capability that's agnostic of them. The question your people should be able to answer isn't how do I use Claude to solve this. It's what kind of problem is this, how does AI typically approach problems like it, and which tool is best positioned to help me right now. That's a transferable skill. It compounds. And it works regardless of which model wins the next benchmark cycle or which vendor decides to change their pricing in Q3.
Partners who are building that capability look different from partners who are driving adoption. They're focused on use cases and outcomes, not platform fluency. They're teaching people how this class of technology works, not just how this product works. And they're building something the organization owns, not something that renews every year at whatever price the vendor decides.
What Responsible Prototyping Actually Looks Like
The promise being sold to enterprises right now is seductive: AI is so powerful that everyone can be a developer. Go forth and build. Your operations manager, your finance analyst, your HR business partner, all of them citizen developers, shipping solutions to problems they understand better than any engineer ever could.
The reality is more nuanced, and getting it wrong is expensive.
Most people are not going to become developers. That's not a limitation of ambition. It's just true. And more importantly, it's not actually what you need. What you need is something more achievable and more valuable: people who are closest to a problem, equipped to validate whether AI can solve it. That's a fundamentally different job description, and it's one almost anyone can do with a little structure.
Here's what that actually looks like. Someone on your team hits a friction point they deal with every day. Instead of submitting a ticket and waiting six months, they open Claude, describe the problem, and start poking at a solution. Maybe it's a script. Maybe it's a logical flow: if I take A and B, can I reliably get C? They're not building an app. They're not worried about hosting or authentication or a UI. They need a basic understanding of how to store an API key safely, and that's about it. They validate it locally. They call a colleague over to look at their screen. It works. That's the moment.
That moment is the handoff. Not to production. To your AI governance group.
The governance group is the connective tissue that most organizations are missing. They receive that validated use case: here's the problem, here's the solution, here's how we know it works. And they evaluate it with something the citizen developer doesn't have: full organizational context. Competing priorities, ongoing initiatives, security posture, compliance requirements, other teams working on adjacent problems. They're the ones who can say yes, this is worth the next level of investment, or no, this duplicates something already in flight, or not yet, but flag it for Q3.
If it gets a yes, it enters a real pipeline. An engineer, or someone more engineer than not, takes the validated concept and builds it properly. Hosted, secured, compliant with your organization's standards. Not a massive project. A focused, scoped build that moves quickly because the hard part — proving the solution works — is already done.
From there, progressive value gates. Does it hold up with ten users? Does it generalize beyond the original use case? Does it justify a wider rollout? Each gate is a real decision point, not a bureaucratic checkpoint. And at each one, the governance group brings that organizational context back to bear.
This is what the citizen developer model actually looks like when it works. They're not builders. They're prospectors. They find the oil, they validate it's there, and they hand it off to the people who know how to extract and distribute it. The pipeline only works if both ends are doing their job, and right now, most organizations have neither the prospectors nor the pipeline.
The Right Question to Ask
The enterprises that are going to win with AI are not the ones with the biggest platform deals or the most seats activated. They're the ones that reframe the goal entirely.
Adoption is not the destination. It's not even a good proxy for value. An organization full of people who have learned to open Claude when they're stuck is not an AI-capable organization. It's an organization that bought an expensive habit.
The reframe is simple but it requires real leadership conviction: stop asking how do we get people using these tools, and start asking how do we build AI fluency as an organizational capability. That means giving people a structure to identify problems worth solving, validate solutions before investing in them, and hand off to the right people at the right time. It means building a governance layer that has the context to make good decisions. It means treating AI like a capability you're developing, not a product you're deploying.
The stakes for getting this wrong are higher than most leaders appreciate. Because if you don't build that capability intentionally, what you get is the oldest story in enterprise software: a large check, a difficult implementation, a lot of activity that looks like progress, and a quiet reckoning twelve months later when someone asks what it actually changed. We've all lived through that with SaaS. We know how it ends. The tools were fine. The organization was never set up to use them well.
AI is not immune to that story. It's just more expensive when you get it wrong, and faster.
The question worth asking any partner, any vendor, anyone coming through your door with a proposal to help: are you here to build our capability, or to drive your adoption? The answer will tell you everything you need to know about whether they're actually solving your problem.
The oil is real. But oil fields don't run themselves. You need people who know what they're doing, and a structure that lets them do it well.