Waymo announced on 19 August 2026 that it has brought Gemini into its purpose-built Ojai self-driving vehicles as an in-car voice assistant. Riders press a Gemini icon on the cabin screen and talk to it, asking it to adjust the air conditioning, find a nearby coffee shop, or explain the history of a landmark they're passing, while the separate Waymo Driver system handles the actual driving.
The detail worth noticing isn't the novelty of an in-car assistant. It's the boundary Google was explicit about. Gemini operates entirely independently of the Waymo Driver and stays completely inactive until the rider chooses to engage with it. The conversational layer and the safety-critical driving system are deliberately kept apart, with the assistant scoped to cabin comfort and information only.
Draw the boundary before you launch
That separation is the actual template here, and it applies well beyond self-driving cars. Any Australian business embedding an AI assistant into a physical product, a kiosk, a piece of equipment, or a customer-facing environment faces the same design question Waymo answered: what is the assistant allowed to touch, and what stays completely walled off?
Claude's own approach to voice and computer use follows the same logic. Human in the loop by default, scoped permissions, and a clear line between what the assistant can discuss and what it can act on. Those are different capabilities with different risk profiles, and treating them as one thing is how embedded projects get into trouble.
Talking about something is not the same as controlling it
The distinction sounds obvious written down, and it's routinely collapsed in practice. An assistant that can explain how a machine works is a very different product to one that can change its settings. The first fails by being unhelpful. The second fails by doing something.
For a business building a Claude-powered voice or embedded experience, whether that's a showroom kiosk, an in-store assistant, or field equipment with a voice interface, the Waymo example is a useful reference for how to think about the split between a safety-critical system and the conversational layer sitting next to it. Waymo kept them separate even though both sit in the same vehicle, built by different companies with different obligations.
Where this actually matters for Australian SMBs
Most Australian businesses aren't going to embed AI into a moving vehicle. Plenty are building voice-enabled or embedded AI experiences into showrooms, service counters, and field equipment, and the same question applies: does the assistant have a hard boundary around what it can control, or is it one prompt injection away from touching something it shouldn't?
The practical checks are short:
Is the list of actions the assistant can take written down explicitly, or is it whatever the integration happens to expose?
If a member of the public can talk to it, what stops a deliberately crafted request from reaching a system that matters?
Does anything the assistant can do have a physical or financial consequence, and if so, is there a human confirmation step?
What does it capture about the person talking to it, and does that match what your Privacy Act obligations require you to disclose?
That last point catches people out. A kiosk in a Melbourne showroom that records conversations for quality purposes is collecting personal information, and the fact that the interface feels casual doesn't change the obligation.
Public-facing changes the threat model
An internal assistant is used by people who have a reason not to break it. A public-facing one is used by everyone, including people who will try things purely to see what happens. That's not a reason to avoid public deployments, but it is a reason to assume adversarial input from the start rather than treating it as an edge case.
The design that survives contact with the public is one where the interesting failure is simply an unhelpful answer. If the worst realistic outcome of a crafted prompt is that someone gets told something slightly wrong about your opening hours, the boundary is drawn correctly. If it's that a piece of equipment changes state, it isn't.
The engineering is the boundary, not the voice
Voice interfaces are close to a solved problem now, which is exactly why they make an underwhelming centrepiece. Getting the boundary right before launch is the actual engineering work behind a demo like Waymo's.
For an Australian business scoping an embedded or voice-enabled Claude build, expect the permission architecture, the action allowlist, and the adversarial testing to account for most of the effort. A scoped build of this kind typically runs A$8,000 to A$20,000 depending on how many systems the assistant sits beside and how public the deployment is.
The version that costs more is the one that skipped this and has to be pulled back after launch. Retrofitting a boundary onto a live public interface is both slower and more visible than designing it in, and it usually happens at the least convenient moment.
If you're planning an embedded or voice-enabled AI experience, the boundary is the part worth getting right before anything ships. Book a session and we'll map what your assistant should and shouldn't be able to reach.
