The Claim That Tells You Nothing
Read these four statements. All four are the kind of thing you will find on a communications provider's website in 2026. All four can be literally true.
| The claim | What it is compatible with |
|---|---|
| "AI-powered transcription and summaries" | Anything from a purpose-built local pipeline to a single API call to a service on another continent. |
| "Enterprise-grade AI security" | Usually a restatement of the model provider's security posture, which is not the same as the posture of the company you are paying. |
| "Your data is never used to train models" | Frequently true of the model provider's API. Says nothing about what the intermediary retains, logs, caches or stores on the way through. |
| "Australian hosted" | Accurate about the platform, and silent about the AI feature you enabled with one click, which may be processed somewhere else entirely. |
None of these are lies, and that is the difficulty. They are accurate statements at a level of abstraction that hides the thing you need to know. A vendor answering "is your AI secure?" with the security documentation of the model they call is not being deceptive — they are answering the question they were asked, using the strongest evidence they have. The fix is not to distrust vendors. It is to ask a better question, and the rest of this article is about which one.
The Layers Your Call Audio Passes Through
When a call gets transcribed or answered by an AI agent, the audio does not go to "the AI". It travels through a stack, and every layer in that stack is a separate company with separate policies, a separate jurisdiction and a separate security posture.
| Layer | What it is | Whose policies govern it |
|---|---|---|
| 1. The application | The product you log into. Handles the call, holds the recording, presents the transcript. | The company you contracted with. |
| 2. The middleware | The glue — queues, storage, logging, retries, caches. The least visible layer and frequently where copies of your audio actually sit. | Also the company you contracted with, though they may not have documented it. |
| 3. The model API | The service that turns audio into text, or generates a response. | The model provider, under a contract they hold — not you. |
| 4. The cloud infrastructure | The compute and storage everything above runs on, in a particular country. | A hyperscaler or a data centre operator, several contracts away from you. |
Layer two is where the surprises live
Most procurement attention goes to layer three, because that is where the recognisable brand names are and where the published policies are strongest. But layer two is where a system keeps queues, retry buffers, error logs containing request payloads, caches and temporary storage — and layer two belongs to the company you are paying, is rarely documented, and is frequently the only place your raw audio is persisted at all. The question "does the model provider retain my audio?" can be answered no while the honest answer to "does my audio sit anywhere for more than a moment?" is yes, in a bucket, for thirty days, in a region nobody has thought about.
Five Kinds of Company That Say "We Have AI"
Each of these is a legitimate business. Each fails a customer in a specific way. Knowing which one you are talking to is most of the work.
1. The operator
Runs its own network and platform, and holds direct relationships for each component. Strength: can answer specific questions about specific events, and can change things. Where it fails you: may still call an external model for some AI functions, and must say so plainly rather than letting "we own our infrastructure" imply otherwise.
2. The hyperscaler-hosted platform
Builds and operates its own software on somebody else's compute. Strength: genuine engineering, real control over its own code, good scalability. Where it fails you: region selection is a configuration choice, and an outage of the underlying provider is an outage they can only wait out with you.
3. The reseller
Sells another company's platform under its own name. Strength: often excellent local sales and account management, and there is nothing wrong with buying this knowingly. Where it fails you: cannot change the product, cannot fix a fault, and cannot tell you what happens at layers two to four because they do not operate any of them.
4. The thin application layer
A product built quickly over a public model API. Strength: genuinely fast innovation, and often the nicest interface in the market. Where it fails you: the entire estate is somebody else's, the whole business depends on one API's pricing and terms, and a policy change upstream arrives without notice.
5. The model provider
Builds and runs the models. Strength: the strongest published security and retention commitments in the chain, by a wide margin. Where it fails you: you are almost certainly not their customer. Their commitments run to whoever holds the contract, and that is your supplier, not you.
How to tell them apart
One question does most of it: "if I report a fault at 3am that turns out to be in the AI transcription, who fixes it and what is their name?" The answer separates these five faster than any amount of documentation.
What You Inherit, and What You Do Not
This is the conceptual error at the centre of most AI procurement, and it is worth spelling out because it is easy to make and expensive.
| What people assume | What is actually the case |
|---|---|
| "The model provider does not train on API data, so my data is safe." | That commitment runs to the entity holding the API contract. It says nothing about what your supplier does with your audio before it is sent or after it comes back. |
| "The model provider offers zero data retention, so nothing is retained." | Nothing is retained at that layer, if the option is enabled by the contract holder. Layers one and two are unaffected and belong to your supplier. |
| "Their compliance certifications cover us." | Certifications describe the certified party's controls. They do not transit down a supply chain, and your obligations do not transit up it. |
| "They are a big company, so it is fine." | The size of a company four contracts away is not a control. The relevant question is what the company you can actually telephone controls. |
You inherit the security posture of every layer, and the accountability of exactly one. That asymmetry is the whole reason this matters: the risks are distributed across four companies and the remedy is available from one. Choosing a supplier is therefore mostly a question of how much of the stack that one company can actually reach.
The August 2026 Developments, and Their Actual Scope
The model providers have moved genuinely and recently, and it deserves credit before it gets qualified.
In August 2026, zero data retention arrangements became available for frontier models, meaning prompts and responses are not retained after a request is processed. Alongside that, customer-controlled deployments keep content on customer-managed infrastructure, and work is under way on a mode where content is stored on the provider's infrastructure but encrypted with customer-held keys, so provider personnel cannot read it. Enterprise API data is not used for model training unless a customer explicitly opts in.
This is real progress. Here is its scope.
All of the above is a substantial improvement and businesses should ask for it. What it does not do is tell you anything about the layer you are contracting with. Zero data retention is an option somebody must enable, in a contract you are not party to, at a layer that is one of four. The published analysis of enterprise AI risk makes exactly this point: data flows through multiple layers — application, middleware, model API, cloud infrastructure — and vulnerabilities appear in that chain even where encryption is used, because the weakest architecture in the chain sets the real posture regardless of how strong the model provider's policies are.
So the correct use of these developments in procurement is not "our AI is safe because the model provider announced ZDR". It is: "is zero data retention enabled on the contract that carries my audio, and what does your own middleware do with it either side of that call?" A supplier who can answer both halves is operating the stack. A supplier who can only answer the first half is quoting somebody else's homework.
The Question That Gets Asked Wrong
Nearly every Australian business evaluating a phone system asks about data residency. Nearly all of them ask it in a way that produces a true and useless answer.
| The question usually asked | Why the answer misleads |
|---|---|
| "Is my data hosted in Australia?" | Answers for the platform. The AI feature is frequently a separate path with a separate answer, and the responder is thinking about the platform. |
| "Are you an Australian company?" | Corporate domicile has almost no relationship to where processing occurs. |
| "Do you comply with Australian privacy law?" | Everybody says yes, and the answer is compatible with lawful offshore disclosure under APP 8. |
Ask this instead, and ask it separately
"When a call is transcribed, summarised or answered by an AI agent — where does the audio or text go, which company processes it, is it retained by that company, for how long, and is it used to train models?"
Ask it as a distinct question from general data residency, because they usually have different answers. A provider who has thought about this answers immediately and specifically. A provider who has not will offer to find out — which is a perfectly honest response and is also, itself, the answer to your real question.
The Ten Questions
Fifteen minutes, no technical knowledge required, and they work on us as well as on anybody else.
| # | Question | What a strong answer looks like |
|---|---|---|
| 1 | Where is the audio processed, physically, for each AI feature? | A country per feature. Different answers for transcription and for an AI agent is fine and honest; a single vague answer for all of it is not. |
| 2 | What is retained, at which layer, and for how long? | Separate answers for the platform, your middleware and the model API. Specific periods, configurable, in writing. |
| 3 | Is anything used to train a model, ever? | No by default, stated in the contract rather than in a marketing page or a blog post. |
| 4 | Who are your subprocessors for AI functions? | A list, maintained, with notification of changes. If they will not name them, you cannot assess them. |
| 5 | What happens when the AI is wrong? | A defined failure path — escalate to a human, log the event, notify somebody. Not an assumption of correctness. |
| 6 | Can a human always override, and is there always a path to a person? | Yes, unconditionally. Anything less is disqualifying for anything consequential. |
| 7 | If I report a fault at 3am in the AI layer, who fixes it? | A named team with the ability to change the thing that is broken. "We raise it with our vendor" is an answer, and it tells you which of the five companies you are talking to. |
| 8 | How do I get my data out if I leave? | An export format, a process, a timeframe. Recordings and transcripts included, not just contacts. |
| 9 | What does your automated-decision disclosure look like? | Evidence they know about the 10 December 2026 obligation. If they have not thought about it, they will not help you meet it. |
| 10 | What does this not do, and where does it fail? | A real answer. A supplier who cannot name their product's limits has not examined it, and this question is the single best predictor of the rest. |
The Evidence to Ask For
Answers are cheap. These four artefacts are not, and asking for them changes the conversation immediately.
A data flow description
One page, plain language, showing where audio goes for each AI feature and which company handles it at each step. Any supplier operating their own stack can produce this in a day.
A current subprocessor list
Names, functions, jurisdictions, and a commitment to notify you of changes. Unnamed subprocessors are unassessable subprocessors.
The retention schedule
Per data type — recordings, transcripts, summaries, logs, metadata — with the configurable periods marked. Logs are the category everybody forgets and they frequently contain content.
The incident and escalation path
Who you call, in what hours, in which country, and what they can change. Ask for the after-hours version specifically, because the business-hours version always looks better.
Six Answers That Should Worry You
| If you hear this | What it usually means |
|---|---|
| "We use enterprise-grade AI with bank-level security." | A description of somebody else's product, offered because the speaker does not know the details of their own. |
| "Our AI is proprietary, so we cannot discuss the architecture." | Sometimes genuine commercial protection. Frequently an inability to answer. You can distinguish these by asking a narrower question and seeing whether it gets narrower too. |
| "All data stays in Australia" — with no qualification about AI features. | Either a strong claim they can substantiate in a day, or a claim nobody has tested against the AI path. Ask for it in writing and you will find out which. |
| "We detect deepfakes and synthetic voice reliably." | Overconfidence about a capability that is not currently reliable. It calls the rest of their claims into question. |
| "That has never happened." | An answer about the past presented as a control for the future. Ask what the process is when it does. |
| "We'll come back to you on that." — for every one of the ten | Not disqualifying on one question. Disqualifying on all ten, because it means nobody has ever asked and nobody has ever thought about it. |
The Three in the Morning Test
Strip away the documentation and this is what you are actually buying.
Something is wrong. AI transcripts are silently truncating, or the AI agent is misrouting urgent calls, or a summary contains a customer's details from a different account. You call your provider. Three things then determine what your week looks like, and none of them appears in a feature comparison.
- Can the person who answers see the thing that is broken? Not a status page — the actual system, with your call in it. An operator can. A reseller cannot, and a thin layer can see only its own half.
- Can anybody in that company change it? If the fault is upstream, your provider's role is to file a ticket and wait alongside you. That is not their failing; it is the architecture you bought.
- Is anybody in your timezone empowered to make a decision? Turning a feature off, failing back to a safe mode, or accepting a workaround are decisions, and they need somebody awake and authorised.
This is the whole argument for infrastructure, and it is an accountability argument rather than a technical one. Owning infrastructure does not make software better. What it does is remove the gap between two companies where a fault can sit unresolved while each correctly certifies its own half. The fewer contracts between you and the thing that is broken, the shorter that gap — and at three in the morning, gap length is the only specification that matters.
The Obligation That Stays With You
One asymmetry deserves stating flatly, because a lot of businesses discover it at the worst moment.
Your obligations do not transfer to your supplier
Recordings and transcripts of your calls are personal information, and where they are processed is part of your compliance position, not merely part of your provider's architecture diagram. Cross-border disclosure obligations attach to you. From 10 December 2026, if you use personal information in automated decision-making capable of affecting a person's rights or interests, your privacy policy must disclose the kinds of information used and the kinds of decisions made — and an AI agent that qualifies leads, prioritises a queue or decides who reaches a human quickly is plausibly within scope. Your supplier can help you answer these. They cannot answer them for you, and no contract makes them the regulator's counterparty instead of you.
Which is why question nine on the list is not a formality. A supplier who has never considered automated-decision disclosure will not be able to tell you what to put in your privacy policy, and December is closer than it looks.
In Fairness to the Thin Layer
It would be easy to end with "buy from an operator", and that is not quite the honest conclusion.
The fastest genuine innovation in this market is coming from small teams building over public model APIs. They ship faster than anybody else, they are frequently the nicest products to use, and for a low-stakes internal use case with no sensitive content, the architecture concerns in this article are largely academic.
| A thin layer is a reasonable choice when... | It is the wrong choice when... |
|---|---|
| The use case is internal and low-stakes | Customer conversations are being processed |
| No sensitive or regulated content is involved | You hold health, financial, legal or personal information |
| You can absorb a change of terms or an outage | The function is on the critical path for revenue or safety |
| You are experimenting, deliberately, with an exit in mind | You will be asked to demonstrate what happened, to whom, and where |
The failure is not choosing a thin layer. It is choosing one while believing you chose an operator — and that mistake is made in procurement, not in engineering, because both companies wrote the same sentence on their website.
Where We Stand, and What We Will Put in Writing
It would be poor form to publish ten questions and dodge them, so here is our position.
We are Australian owned, Australian hosted and Australian supported, and we operate our own platform rather than reselling somebody else's. For AI features specifically, we will tell you — per feature, in writing — where the processing happens, which company performs it, what is retained and for how long, and whether anything is used for training. Where a component is not ours, we will say so plainly rather than letting "we own our infrastructure" imply something broader than it should. That distinction is exactly the one this article is about, and we would be poorly placed to fudge it.
The summary
Five very different companies can truthfully say they have AI, and a demonstration cannot distinguish them because the demonstration is of the model. Your call audio traverses four layers owned by different companies, and the middle layer — your supplier's own middleware, with its queues, caches and logs — is where the surprises usually are. The model provider's protections run to whoever holds that contract, which is not you. August 2026's zero-data-retention developments are real and are not an answer about your supplier. Ask the AI processing question separately from general data residency, because they usually have different answers. And ask who fixes it at 3am, because that single question sorts the five categories faster than anything else — and because the obligations stay with you regardless of the answer.
Related reading: Australian infrastructure versus overseas cloud, which covers the general data residency case and the AI exception, the December 2026 automated-decisions obligation, how transcription and summaries actually work, where AI genuinely improves your security, and what AI voice agents cost and return.