Soundings

Our Perspectives and Insights

Back

Build Your AI Sand Castles on One Castle

Two sand castles standing on a solid stone foundation while a wave washes away a third; the foundation holds

Part three of a series. Part one asked whether every AI pilot deserves to go into production. Part two covered how the ones that should actually get there. This one is about making that road shorter for every team that comes next.

In part two of this series, I said every team should build production in from the first prompt. Put the security standard in the build instruction. Design the load test alongside the feature. Write the runbook while you build. This is the right end goal, but an expensive way to get there at scale.

The standards do not move. Every AI system headed to production still has to clear every threshold the enterprise sets. What part two left out is who carries them. If every team builds production in on its own, every team re-earns it, from scratch, every time. That is not discipline. That is the same tax paid fifty times.

Why the Approval Gate Became the Expensive Part

AI collapsed the cost of building software. It did nothing to the cost of getting it to an approved production state: the security review, the model risk sign-off, the change board, the evidence an auditor will ask for. When building something takes an afternoon and approving it takes a quarter, approval is most of what it costs to ship.

Teams already build fast. The prize is not building faster. The prize is arriving at the gate prepared.

You will never delete the approval gate. You can stop arriving at it unprepared.

Sand Castles on Top of One Foundational Castle

Nobody pours concrete when building a sand castle. It is built to be knocked down and built again, and that is how most AI applications should be treated now. The models change, the patterns change, and something built six months ago is often cheaper to rebuild than to maintain. Build disposable. The number that matters is the cost of your next build, not your first.

But disposable only works on top of something that is not. Push all the durability down into one shared layer, built once and cleared once, and let everything above it be thrown away and re-poured. For AI, that one foundational castle holds four things:

  • The rails and security, already in place: identity, logging, data boundaries, the network.
  • The master prompt, already set up: the policies, the tone, and the things the system may never do.
  • The compliance and policies, already included instead of bolted on at review.
  • The build method, already defined: how a team gets from an idea to a submission the gate recognizes.

The prize is not building faster. The prize is arriving at the gate prepared.

We've Built This Before, in the Cloud

At a large enterprise retail company, a team I led built a cloud services catalog for exactly this reason. Instead of every development team assembling its own environment and then fighting its way through security review, a team pulled an entry that already had security, guardrails, logging, disaster recovery and multi-region built in. Getting something enterprise-ready went from roughly three years to roughly two months.

The catalog did not remove approval. Every entry still went through review. What changed was that first submissions showed up much closer to acceptable, so the loop of reject, rework, resubmit mostly went away. The gate stayed. The rework did not.

Pave the Controls, Not the Architectures

Spotify calls its version of this the Golden Path, and Gary Niemen, a product manager there, described why it matters: “With Golden Paths in place, teams don’t have to reinvent the wheel, have fewer decisions to make, and can use their productivity and creativity for higher objectives. They can get back to moving fast.”

He is right, and for AI there is a catch. A golden path is a set of blessed tools, and Niemen’s own team notes that when a tool gets swapped out, the path has to change with it. In AI the tools get swapped every few months. Pave the architectures and within a year you own an authoritative library of wrong answers: a wiki of stale diagrams.

Architectures churn in months. Control questions hold for years.

What does not move is the set of control questions underneath. Who can see this data? What gets logged? What may the system never do? Who approves a change? Architectures churn in months. Control questions hold for years. Pave those, and let the architecture on top stay disposable.

How to Build the One Foundational Castle

  1. Start from the controls you already own. Your security, data, change and logging standards already exist. Translate them for AI instead of writing a new rulebook from scratch.
  2. Set the master prompt once. One policy layer that every AI build inherits, owned by one team and versioned like code, so nobody rewrites the rules in a side project.
  3. Make the compliant path the easy path. If pulling the catalog entry takes longer than going around it, teams will go around it. The shared layer has to be the fastest way to start.
  4. Measure the next build, not the first. Track how many review cycles each build takes and how close a first submission lands to acceptable. Both numbers should fall every quarter. That is the whole return.

The Bottom Line

Part two was right that the standards do not move. It didn’t cover the part of every team carrying them alone. Build one foundational castle, clear it once, and let every team build sand castles on top of it: fast, disposable, and already standing on something the gate recognizes.

You will never delete the approval gate. You can stop arriving at it unprepared.

Direction Beats Chaos™

A Pilot & Rutter principle.