Google DeepMind published a short explainer this week on what full-stack AI means inside a company like Google: infrastructure, security, research, models and tooling, and product. Five layers that all have to work together for an AI product to hold up in production. It is a fair framework and a useful one to borrow. It also describes what Google does internally, which is a very different problem from what an Australian business buying AI needs to evaluate.
The translation is worth doing carefully, because the layers stay the same but the question attached to each one changes completely when you are the buyer rather than the builder.
The same five layers, reframed as buyer questions
Infrastructure: who is running it, where does the data physically sit, and what is the answer when a client asks whether their information left Australia?
Security: who is responsible when something surfaces, what is the notification path, and does it match what your own contracts already commit you to?
Research: is anyone in your business tracking which new capability is safe to switch on yet, or does that happen when someone reads a headline?
Models and tooling: do Claude Code, Claude Cowork and your MCP connectors actually fit how the team works, or were they bolted onto an existing process that nobody re-examined?
Product: does the result solve a problem worth the spend, measured against something you agreed before the build started?
Where Australian businesses actually come unstuck
The gap is almost never the model layer. Claude, Gemini and the frontier open-weight models are all good enough for the overwhelming majority of mid-market work, and picking between them is rarely what decides whether a deployment succeeds. The gap sits in everything around the model.
The pattern we see repeatedly with Sydney and Melbourne businesses looks like this. Nobody owns the infrastructure decision, so it gets made by whoever set up the first pilot and never revisited. Nobody tracks which new capability is safe to enable, so features arrive by accident when a vendor ships an update. And tooling gets added ad hoc, one connector at a time, in response to individual requests rather than scoped against an actual workflow. Each of those is survivable on its own. Together they produce a deployment that works in the demo and quietly fails to change how anyone works.
That is a full-stack problem even when the model itself is excellent. It is also why the businesses that get the most out of AI are rarely the ones that spent the longest choosing a model.
What a structured audit actually looks at
Running the five layers as a checklist before committing to a build usually takes a few days, not a few weeks, and it is dramatically cheaper than discovering the gaps six months into an engagement. A typical audit at this scope runs $3,500 to $6,000 and the output is a decision document, not a slide deck: what gets built, what gets bought, what gets deferred, and who owns each layer by name.
Infrastructure and residency, written down with the actual region and the actual retention terms, not the marketing summary.
A named owner per layer. Unowned layers are where deployments rot, and the fix costs nothing except the awkwardness of assigning it.
A capability review cadence, even a quarterly half-hour, so new features are a decision rather than a surprise.
Tooling mapped against one real workflow end to end, with the manual steps that survive marked explicitly.
Two honest caveats about the framework
First, Google's five layers describe a vertically integrated stack, and almost no Australian mid-market business has one or needs one. Borrowing the framework does not mean building every layer yourself. For most businesses the right answer at the infrastructure and research layers is buy, and the audit's job is to make that an explicit choice with a named vendor rather than a default.
Second, a framework published by a model vendor will naturally emphasise the layers that vendor sells. That does not make it wrong, and this one holds up better than most, but the buyer's version needs a layer Google's does not include: change management. Who is going to use this, what are they doing today instead, and what happens to the people whose work it changes. A deployment can be flawless across all five technical layers and still fail because nobody answered that.
This is the actual work of standing up AI properly rather than picking a model and hoping. Automata AI runs the five-layer audit as a fixed-scope engagement before any build work starts, and the output is a document you can act on with or without us. If your AI work has stalled somewhere between pilot and production, book a session and we will find out which layer it is stuck in.
