The cloud strategy I helped build didn’t survive contact with AI. Here’s what we did next

I knew the plan was in trouble when a finance partner asked me a question I couldn’t answer cleanly.

“How much of this cloud spend is experimentation, and how much is now becoming the new normal?”

That should not have been a hard question. We had a mature cloud strategy. We had standards. We had architecture reviews. We had cost controls, service patterns, reserved capacity, security gates and a decent story for the board. Nothing about it felt reckless. It felt grown-up. Ordered. Sensible.

Then AI walked in and started moving the furniture.

Silently. More like a slow shove. One use case here. One pilot there. A team testing copilots. Another team asking for more compute. Security was asking where the prompts were going. Legal is asking what data crossed which border. Finance stared at the bill like it had started speaking Latin.

Good strategies rarely die from stupidity. They die from drift. The world changes, but the logic stays parked in last year’s weather.

Our cloud strategy had been built for a world of applications, platforms, storage growth and ordinary bursts of demand. AI brought a different appetite. It wanted more power, faster decisions, looser experimentation, tighter controls and more adult supervision. It was like inviting a clever guest to dinner and discovering he’d also brought three wolves and an invoice.

The strategy was sound for the game we were playing

I want to be fair to the original plan because I helped build it, and because sneering at old decisions is one of the cheapest forms of hindsight.

The strategy solved real problems. We needed consistency across environments. We needed stronger resilience. We needed better cost discipline than the old “just move it and sort it out later” school of cloud migration. We wanted teams to build faster without having to reinvent their own religion each quarter. We wanted clearer guardrails and fewer exceptions that were hard to understand.

So, we created patterns. Standard hosting routes. Cost reviews. Architecture checkpoints. Shared controls. Approved services. Escalation paths. It worked. The business moved. The core platforms are held. We had enough orders to be useful and enough flexibility to avoid becoming the department of ceremonial no.

Underneath that plan sat a few quiet assumptions. Workloads would stay mostly familiar. Demand would rise, but in ways we could model. Costs would wobble, not convulse. Governance would keep pace with technology. Most exceptions would stay exceptional.

That set of assumptions was not foolish. It was built for a different climate.

AI broke the assumptions first

The mistake would be to say AI, “changed everything.” It didn’t. AI broke specific assumptions, and once those snapped, the strategy started falling apart.

1. The first break was compute. Traditional enterprise workloads usually behave like people with routines. They rise, fall and repeat. AI workloads behave more like teenagers with borrowed car keys. One experiment looks harmless. Then a model run chews through expensive resources. Then inference demand shows up in places nobody had forecast.
2. The second break was data. Many firms say they have data ready for AI because they have data lakes, reports or analytics platforms. That is like saying you’re ready for surgery because you own a sharp knife. AI use depends on permission, lineage, quality, context, retention and movement. Data that seemed fine for dashboards became awkward, risky, or unusable once models were introduced.
3. The third break was economics. Cloud costs had always needed watching, but AI added a new twist. You could spend real money before proving real value. Pilots looked small until they spread. A use case that seemed cheap in testing became costly when people used it. Finance hates mystery, and AI has a talent for turning cost models into abstract art.
4. The fourth break was governance. Our existing controls had been built around systems, services, vendors and access. AI introduced different questions. Which prompts are being stored? Which data is being exposed? Who approved this model? What evidence supports this use case? What happens when teams adopt tools outside the approved stack because the approved stack moves too slowly?

That was the point at which I stopped seeing AI as just another demand line on the platform roadmap. It had become a pressure test for our judgment.

The trouble showed up in symptoms before it showed up in strategy decks

Big strategy failures rarely arrive wearing a name badge. They come disguised as irritations.

First came cost surprises. Just a steady rise in bills nobody could explain with much confidence. Then came the awkward meetings. Finance wanted forecasts. Engineering wanted a room to test. Security wanted tighter control. Data teams wanted access. Everyone had a valid concern. Nobody was wrong. That almost made it worse.

Then came architecture drift.

Teams were trying to get work done. If the approved path took too long, they found another path. A hosted tool here. A side environment there. A vendor service that solved today’s problem and quietly created next quarter’s headache. You could feel the strategy starting to fragment at the edges.

Control gaps followed. Some teams knew exactly where their prompts went and what data they used. Others had a hazier picture. Logging varied. Review depth varied. Local workarounds multiplied. Policies still looked confident on paper, but paper is generous. Reality is less polite.

The hardest symptom to spot was decision fatigue. Meetings got longer. Ownership got fuzzier. People started using the same words to mean different things. “Low risk” to one group meant “good enough for a pilot.” To another, it meant “fit for regulated production.” Progress slowed. Shadow behavior grew in the dark space between demand and delay.

I remember one discussion about a simple internal assistant. The business wanted speed. The data team said the source material was manageable. Security asked a plain question about retention and auditability. Silence. Not hostile silence. The worst kind. The kind that tells you the room has just discovered it was working from several different maps.

That is when I knew we needed a reset instead of a patch.

We changed the frame before we changed the plumbing

Once you admit the plan no longer fits the conditions, pride becomes expensive.

Our first useful move was mental. We stopped asking, “How do we fit AI into the current cloud model?” That question trapped us. It assumed the existing model was the fixed point, and AI was the exception. In practice, AI was changing the operating conditions.

So, we asked a better question. What kinds of AI work are we dealing with, what do they need and what should run where, why and under which controls?

That shift saved us from one-size-fits-all thinking.

We split the workload space into clear groups. Experiments were not the same as production services. Internal assistants were not the same as high sensitivity use cases. Data-heavy model work was not the same as quick feature add-ons. Once we made those distinctions, better decisions followed. Some workloads could move fast with light review. Others needed tighter handling, clearer evidence and harder boundaries.

We also made trade-offs explicit.

Before that, teams argued in code. One side talked speed. Another talked about risk. Another cost. They were often debating values without naming them. So, we dragged the trade-offs into daylight. When do we pay more for control? When do we accept a delay for clearer evidence? When do we permit local freedom, and when do we insist on a common route?

As we couldn’t remove tension, we made it usable.

The other big shift was governance. We moved it closer to design. As working logic. Architecture, security, legal, finance and data leaders needed to shape decisions early, before file opinions after a team had already fallen in love with a tool.

What we did next

The reset became real when it changed weekly behavior.

We reclassified workloads using a few plain tests. How sensitive is the data? How heavy is the computing need? How much latency matters. How exposed is the use case to regulation, customer trust or public embarrassment? Each category had a preferred route. A clear one, before a perfect route.

We rebuilt cost visibility. Experimentation spend could no longer be hidden within general platform usage. We separated trial money from operating money. We pushed teams to tie spend to an intended outcome, beyond technical curiosity. Curiosity matters. So do receipts.

We tightened data pathways. We became stricter about what data could go where, under which terms and with what record. Less wandering. Fewer assumptions. Better memory.

We updated review thresholds. Not every use case needed a committee. Some did. The trick was to define that line before the pressure arrived. Teams need to know when they can move, when they must pause and who can break a tie.

We also created a regular decision forum across platform, security, data, finance and business leads. A place to resolve trade-offs fast and make decisions. That one change cut a lot of theatre. People no longer had to guess who owned the hard calls.

What this taught me about cloud, AI and leadership

I came out of this with less faith in neat architecture slides and more respect for decision design.

What AI did to our cloud strategy also affected leadership. It exposed paradoxes you can often keep apart in calmer times. In my CIO article, “4 leadership paradoxes that define AI adoption,” I framed four tensions leaders now face: Speed and security, innovation and stability, talent and compliance, and ethics and efficiency. The piece argues that AI leadership is about learning to lead inside contradictions instead of resolving those once and for all. That is the part that stayed with me.

That is exactly what happened here.

We wanted teams to move quickly, but not so quickly that cloud spend became guesswork and controls became folklore. We wanted experimentation, but not at the price of production stability. We wanted strong technical people to explore, test and build, but not in ways that left legal, risk and security trying to reconstruct decisions after the fact. We wanted useful AI services, but not the kind that looked cheap and clever right up until they created a trust problem. No side debates. They became the work itself. The paradoxes were no longer theory. They were operating conditions.

That is why I no longer see cloud strategy as a platform conversation with some governance attached. It is a leadership discipline. You are not just choosing hosting patterns or cost controls. You are deciding how your organisation will behave under tension. Can you move with speed and still protect trust? Can you create room for experimentation without letting the estate drift into sprawl? Can you give talented teams the freedom they need without turning compliance into an afterthought? Can you chase efficiency without losing the ethical grip that keeps the whole thing defensible? That is the real burden of AI adoption. It pulls leadership into trade-offs that used to sit in separate meetings.

Boards should care more than they sometimes do. They shape spending, resilience, accountability and the company’s ability to adopt AI without behaving like a teenager left alone with a corporate card. That was the deeper lesson for me. The cloud strategy I helped build did not fail because the architecture was weak. It failed because AI changed the tensions leaders had to manage, and the old model was not built to carry that weight.

The cloud strategy I helped build did not survive contact with AI. I’m oddly grateful for that. It forced us to admit that a good strategy is not a monument. It is a living argument with reality.

The plan that survives is rarely the prettiest one, it is the one honest enough to change before the bill, the breach or the board meeting does it for you.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?