What I keep seeing as organisations start building and scaling AI on AWS
A lot of my conversations with customers about AI on AWS start with a request for a landing zone. They want somewhere to host their AI applications, and they expect the landing zone to take care of the security and governance they need.
A secure and governed generic platform foundation is absolutely a step in the right direction, but it is not everything teams need to start and scale AI on AWS.
In this post, I will cover what is still missing once the landing zone is built, and why the usual ways of filling that gap do not make the next AI application any easier.
The same pattern across many industry sectors
A healthcare client asked us to build a landing zone for regulated workloads. The request came from a business unit that had an AI application ready to build and nowhere to build it. The landing zone request was really a request to build what the future AI application needs to securely run in the cloud.
A large state government agency already had a mature enterprise landing zone. It was built the way AWS recommends, and it runs with no major issues. The teams wanted to start using AI. Their first question was not how to build the application. It was what governance controls we could put around it. Until that question had an answer, nothing started. A mature landing zone did not make the AI conversation any shorter.
An emergency services organisation runs both AWS and Azure and has operational technology it cannot disturb. They asked what approaches we had seen across government for enabling AI safely. Their first question was about permission, not about capability.
A financial services group is planning a new landing zone for 2026 and beyond. They asked for it with the AI foundations built in from the start. Their AWS account team saw that as the mechanism that would let AI adoption scale, and they are right.
Why it keeps happening
AWS is releasing AI capability faster than most governance processes can absorb it. The teams closest to the business want to build with it now. What stops them is legitimate: regulation, security requirements, and the question of what an AI system is allowed to see and do. So the organisation starts with the step everyone knows, a well-governed landing zone. That is what doing it safely has traditionally meant.
The landing zone gets built and usually built well. Then it is declared done, the budget is spent, and the AI application is exactly where it was. A generic landing zone answers generic risk. I It controls which regions and services can be used, and who can log in. It does not say what this application may reach, which data it may see, what it may spend, or how anyone can prove any of that later. The team is unblocked on paper and still blocked in practice.
The landing zone is not the problem. The problem is treating the landing zone as the end goal.
Organisations usually take two approaches and neither scales
Some organisations build their governance controls first, based on prescriptive guidance or a reference architecture. Then they start building the AI application to find out that the generic textbook does not serve their use case. The controls were recommended for every use case under the sun yet do not perfectly fit theirs.
Other organisations build the governance controls while building their first AI application, and for that application only. That works very well for the first one, until the second AI application arrives and it takes as much time as the first.
Both approaches eventually get one AI application into production. Neither approach makes the second one faster than the first.
Whatever makes the second AI application faster than the first is harder to fund than a landing zone. It does not look like a traditional generic platform project, and it does not look like an application either. It looks like governance, and governance rarely gets a budget line until something has gone wrong.
The organisations that get a second AI application out faster do three things differently. They build the controls with the first application, they build them to be reused, and they keep someone owning them after the first application goes live.
Three questions worth asking
- Is your landing zone built, and is your first AI application running on it?
- Where did your AI governance controls come from: a reference architecture, or the first application you built?
- Would your second AI application take less time than your first?
If the answer to the last one is no, the landing zone was not the missing piece.
I have written separately about what that foundation looks like when it is built.
I spend a good part of my time in these conversations, across sectors that have very little in common except this pattern. If it sounds familiar, I am always happy to chat about it.
Mostafa Mabrouk leads the Cloud Evolution practice at Cevo, helping enterprises build secure, scalable AWS platforms and migrate and modernise their workloads. He is passionate about enhancing developer experience through enabling self-services and creating repeatable solutions to complex cloud challenges.
