Many of the organisations I talk to have already done the hard part once. A team picked an AI use case, worked through the approvals and put something that worked in front of real users. It took months, but it landed.
Then the second use case arrives, and it takes just as long. The same approval conversation, the same debate about model, data and controls, the same questions from security. Little is carried across.
This is the conversation I have most often with organisations scaling AI, and it is rarely about models. You end up with an AI foundation either way: whatever was stitched together to ship the first application becomes policy by default. The only question is whether it was built for the next use case or only for the first.
I have written separately about why a landing zone alone does not close this gap, where as this post is about what does.
Why the second application costs as much as the first
Most organisations already control their cloud environment: approved regions, approved models, who can access what. Those controls were designed for the whole environment, not for any one application. On their own they cannot say what a particular application is for, what it may reach or what it is allowed to do.
Telling one application from another takes controls specific to it, and those exist on AWS today: its own identity, access to only its approved models, a safety configuration it cannot skip, a path to its approved data and nothing else, its costs visible against its name. But nothing creates them consistently for each new application, so the work is left to application teams. Configuring a guardrail is not enforcing it, and a control that depends on being remembered is the first thing to go under delivery pressure.
Build it alongside the first application, not ahead of it
Build the foundation first and invite teams in afterwards, and you get a foundation validated against a document rather than reality. Controls that have never carried real work are assumptions; you find out which were wrong when the first team hits them, after the budget is spent.
The alternative is to build the first application and the capabilities it needs together, and let a real business objective set the scope rather than a reference architecture or a guess at every future workload. Once an application is assessed and approved, its access, data boundaries, guardrails and reporting are provisioned as one step rather than a sequence of tickets. When the second team asks whether it holds up, the answer is a demonstration rather than a diagram.
This is different from building controls for one application and moving on. The controls are built with the first application, but they are built to be reused by the next one and owned as a service after the first one goes live.
It is also how this work gets funded. It rides on the first application and its business case, rather than waiting for a platform budget that rarely comes.
This is how we, at Cevo, recently delivered a customer-facing AI assistant for an aged care provider. The first application went from idea to production in ten weeks, and its guardrails, release testing and spend controls were built with it rather than after it. The provider has kept that testing and governance foundation to reuse for its next customer-facing AI use case, which is the point. The second one starts from what the first one proved.
What the next team inherits, and what it does not
In a regulated organisation, what an application is for is a classification, not a description, and business, security and governance owners decide it, not the delivery team. The same technology put to a different purpose can carry a different classification, evidence burden and approval path. “We extended it slightly” is how an unregulated tool becomes a regulated one without anyone deciding to.
So a second application with a comparable purpose inherits most of the first one’s working controls and settled decisions. One handling more sensitive information is still assessed on its own terms; it inherits the approach and the evidence, not the approval.
Someone must own it
None of this holds if every application team keeps its own copy. The cloud services team that owns the platform should own this capability as an ongoing service: onboarding applications, maintaining the controls and improving them. We, at Cevo, recommend a register of applications and their controls, so that a change reaches only the applications it affects, with their owners’ approval before production. That is what separates a platform capability from a folder of templates.
Three questions worth asking
- How long passes between a team getting approval and writing its first line of code?
- Is your safety configuration something applications must use, or something they should use?
- When the project team moves on, who owns what they built for the team that follows?
None of these are questions about models. All of them decide whether your fifth application is faster than your first.
This is what Cevo’s AI Foundations offering is built around: a first AI application with a real business outcome, delivered on AWS alongside the governed onboarding and reusable patterns the next team will use. Whether your first AI application is live or still on a whiteboard, the foundation underneath it is being decided now. If the second one is starting to feel like the first all over again, that is the problem worth solving next, and I would welcome the conversation.
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.
