The Counting Exercise
Take ten minutes and try to establish, for the AI you already use, how many separate legal entities touch your call audio. Not vaguely — by name.
- Who do you pay? That is company one, and it is the only one you have a contract with.
- Does company one operate the software, or resell it? If they resell, add company two, and note that company one cannot change anything.
- Which model performs the transcription or generates the AI agent's speech? That is another company, unless your supplier built and runs the model, which is rare and should be stated explicitly if true.
- Whose data centres does all of that run in? Another company, and quite possibly in more than one country depending on the feature.
- Now write the count down. Then ask your supplier for their number and see whether it matches yours.
3–4
Typical number of companies in the chain
1
Number you have a contract with
4
Retention policies you inherit
0
Of this visible in a product demonstration
You inherit every layer's security posture and exactly one layer's accountability.
— the asymmetry the whole method is built around
The Four Layers, and Which One Surprises People
Layer 1 — the application
What you log into. Takes the call, holds the recording, shows you the transcript. Governed by the company you pay, and the only layer most buyers ever think about.
Layer 2 — the middleware
The unglamorous plumbing: queues, retries, caches, temporary storage, error logs. Also owned by the company you pay, and almost never documented. This is the layer that surprises people.
Layer 3 — the model API
Where the audio becomes text, or where a response is generated. Governed by the model provider, under a contract your supplier holds and you do not.
Layer 4 — the infrastructure
The compute and storage everything above runs on, in a specific country, under a specific legal regime. Several contracts away from you.
Why layer two is where the problems are
Procurement attention concentrates on layer three, because that is where the recognisable names and the strongest published policies live. But layer two is where a system keeps retry buffers, error logs containing request payloads, caches and temporary storage — and it belongs entirely to the company you are paying. It is entirely consistent for a supplier to say truthfully that the model provider does not retain your audio while the honest answer to does my audio sit anywhere for more than a moment is yes: in a storage bucket, for thirty days, in a region nobody has asked about. Ask about layer two by name and watch what happens.
Why the Demonstration Tells You Nothing
This is the part that catches careful buyers, because a demonstration feels like evidence.
When a supplier shows you AI transcription, or an AI agent handling a call convincingly, what you are watching is the model's performance. If two suppliers call the same model, their demonstrations will be indistinguishable, because the thing performing is the same thing. The demonstration tells you the model is good. You already knew that.
| What a demonstration shows | What it cannot show |
|---|---|
| Transcription accuracy | Where the audio went to be transcribed |
| How natural the AI agent sounds | What is retained, by whom, for how long |
| How nice the interface is | Whether anybody at that company can fix a fault in the AI layer |
| How quickly it responds | What happens when the upstream provider changes its terms |
| That the feature exists | Whether the supplier can describe their own data flow in one page |
The practical implication is uncomfortable: the demonstration is the least informative part of the evaluation, and it is the part everybody spends the most time on. Watch it, by all means — you do need to know the accuracy is adequate for Australian accents and your industry vocabulary. Then set it aside and do the paperwork, because the paperwork is where the suppliers differ.
You Inherit Four Postures and Can Call One Company
Four assumptions worth correcting, because each one is common and each one is wrong.
| The assumption | The correction |
|---|---|
| "The model provider does not train on API data, so we are fine." | That commitment runs to the entity holding the API contract — your supplier. It says nothing about what your supplier does with your audio before it goes and after it returns. |
| "They have certifications." | A certification describes the certified party's controls. It does not flow down a supply chain to you, and your obligations do not flow up it to them. |
| "It is a huge company, so it is safe." | The size of a company four contracts away is not a control. What matters is what the company you can telephone actually controls. |
| "Our contract makes them responsible." | Contracts allocate liability between the parties. They do not make your supplier the regulator's counterparty instead of you. |
What the August 2026 Announcements Actually Cover
Credit where it is due before the qualification. In August 2026 zero data retention became available for frontier models, meaning prompts and responses are not retained after a request is processed. Customer-controlled deployments keep content on customer-managed infrastructure, and work is under way on an arrangement where content sits on provider infrastructure encrypted with customer-held keys so provider staff cannot read it. Enterprise API data is not used for training unless a customer opts in.
Genuinely good, and precisely bounded
Every business should want these arrangements and should ask whether they are enabled. What they do not tell you is anything about the company you are paying. Zero data retention is an option somebody must switch on, in a contract you are not party to, at one of four layers. Published analysis of enterprise AI risk makes the same point directly: data flows through application, middleware, model API and cloud infrastructure, and weaknesses appear along that chain even where encryption is in use — because the weakest architecture in the chain sets your real exposure, no matter how strong the policies at layer three.
So the useful procurement sentence is not "our AI is safe, the model provider announced ZDR". It is: is zero data retention enabled on the contract carrying my audio, and what does your own middleware do with that audio either side of the call? A supplier who answers both halves operates their stack. A supplier who answers only the first is quoting somebody else's work.
The Six-Line Email
Send this, unedited, to every provider you are considering. Send it to us. Six lines, no technical vocabulary, and it is very hard to answer misleadingly without being untruthful.
Copy from here
Hello — before we go further I need short written answers to six questions about your AI features. Please answer per feature where the answers differ.
1. For each AI feature (transcription, summaries, AI agent), which country is the audio or text processed in, and which company performs the processing?
2. What is retained at each stage — your application, your own internal systems and logs, and the model provider — and for how long? Which of those periods can we configure?
3. Is any of our content used to train any model, ever? Please point us to where that is stated contractually.
4. Please list your subprocessors for AI functions, with their jurisdictions, and tell us how you notify us of changes.
5. If we report a fault at 3am that turns out to be in the AI layer, who investigates it, in which country, and can they change the component that is broken?
6. What does your AI capability not do, and where does it fail? And what is your position on the automated decision-making disclosure obligation commencing 10 December 2026?
Short answers are fine. We are comparing several providers on these six points.
Note the design of it. Question two asks about three layers separately, which is what makes it hard to answer with a single reassuring sentence. Question five asks who fixes it rather than who you call, which is a different question and reveals the architecture. And question six is deliberately last, because it is the strongest single predictor of everything else: a supplier who can name their product's limits has examined it.
How to Score the Replies
Score on specificity, not on tone. A blunt, specific reply beats a warm, general one every time.
| Question | 2 points | 1 point | 0 points |
|---|---|---|---|
| 1. Where processed | A country per feature, plus the company doing it | One country for all features | "In the cloud" / "with an enterprise provider" |
| 2. Retention | Three separate answers with periods, marked configurable | One period covering everything | "We don't store your data" with no layer breakdown |
| 3. Training | No, with a contractual reference | No, in an email | A link to a marketing page |
| 4. Subprocessors | A named list with jurisdictions and a change-notice commitment | A partial list | Declined as confidential |
| 5. 3am fault | A named team, in a stated country, able to change the component | An escalation path to a vendor, honestly described | A support email address |
| 6. Limits and ADM | Real limits named, and a considered ADM position | Limits named, ADM not considered | "There aren't really any limitations" |
Do not use the total as a ranking. Use it as a filter: anything scoring zero on questions one, two or five should be excluded from consideration for anything involving customer conversations, regardless of price or interface quality. Then compare the remainder on the things you actually care about. The point of the exercise is not to find the highest score — it is to find out which suppliers know their own architecture.
Five Replies That Are Really a No
"Enterprise-grade, bank-level security"
A description of somebody else's product, offered because the writer does not know the details of their own. Ask question two again, narrower.
"Proprietary — we cannot discuss the architecture"
Occasionally genuine commercial protection. Usually an inability to answer. Test it by asking something narrower; if the answer also narrows, it was genuine.
"Everything stays in Australia" — unqualified
Either a strong claim they can substantiate in a day, or one nobody has tested against the AI path. Ask for it in writing, per feature, and you will find out which.
"We reliably detect synthetic voice"
Overconfidence about something that is not currently reliable. It devalues every other claim in the reply.
"We'll come back to you" — on all six
Fine on one question. On all six it means nobody has ever asked and nobody has ever thought about it, which is the finding.
A very warm reply with no facts
The hardest to reject and the most important to. Enthusiasm is not specificity, and you are buying specificity.
Why Owning Infrastructure Is an Accountability Argument
We own and operate our own network rather than reselling somebody else's, so we have an obvious interest here. That is exactly why the argument should be made narrowly rather than expansively.
Owning infrastructure does not make software better. Plenty of excellent software runs on hyperscaler compute, and plenty of poor software runs on privately owned racks. The claim is not technical superiority.
What ownership removes is the gap between two companies where a fault can sit unresolved while each correctly certifies its own half. Anyone who has watched a network provider and a platform vendor each pass a test and each point at the other knows this gap. It is not caused by bad faith; it is caused by scope. Each supplier honestly confirms their own boundary and neither owns the space between. The fewer contracts between you and the broken thing, the shorter that gap. That is the entire claim, and it is an accountability claim rather than an engineering one.
It also has an honest limit, and we would rather state it than have you find it. Where a component genuinely is not ours — and for some AI functions a model may be called externally — we will say so, per feature, in writing, rather than allowing "we own our network" to imply something broader than it should. That is precisely the distinction this article is about, and it would be poor form to blur it in our own favour.
The Out-of-Hours Test
Strip away the documentation and this is what you are buying.
It is 3am. AI transcripts are silently truncating, or the AI agent is misrouting urgent calls, or a summary has attached one customer's details to another's record. Three questions then determine what your week looks like, and none of them appears on a comparison table.
- Can whoever answers see the thing that is broken? Not a status page — the actual system, with your call in it. This separates operators from everyone else immediately.
- Can anybody in that company change it? If the fault is upstream, your supplier's role is to raise a ticket and wait with you. That is not a failing on their part; it is the architecture you selected.
- Is somebody in your timezone empowered to decide? Disabling a feature, failing back to a safe mode, or accepting a workaround are all decisions, and decisions need a person who is both awake and authorised.
What Stays Your Problem Regardless
Obligations do not transfer with the audio
Recordings and transcripts of your calls are personal information, and where they are processed forms part of your compliance position rather than merely your supplier's architecture. Cross-border disclosure obligations attach to the entity that collected the information — you. And 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 personal information used and the kinds of decisions made. An AI agent that qualifies leads, prioritises a queue or decides who reaches a human quickly is plausibly in scope, and the drafting is broad enough to capture rule-based tools as well as anything anyone calls AI.
A good supplier helps you answer those. None of them answers on your behalf, and no contract makes them the regulator's counterparty in your place. Which is why question six matters: a supplier who has not considered the December obligation will be no help drafting your disclosure, and you will need an inventory of every automated decision your systems already make before you can write it.
When Fewer Layers Genuinely Does Not Matter
It would be convenient to conclude that you should always buy from whoever owns the most. That is not the honest conclusion.
| Layer count matters less when... | It matters a great deal 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 could absorb a terms change or an outage | The function sits on the revenue or safety critical path |
| You are deliberately experimenting, with an exit in mind | You may have to demonstrate what happened, to whom, and where |
Some of the fastest genuine innovation in this market comes from small teams building over public model APIs, and they frequently produce the nicest products to use. The mistake is not buying from one. It is buying from one while believing you bought from an operator — and that error is made in procurement, not in engineering, because both kinds of company can write exactly the same sentence on a website.
Our Own Answers
Publishing a questionnaire and dodging it would be indefensible, so briefly: we are Australian owned, Australian hosted and Australian supported; we own and operate our own network rather than reselling somebody else's; support is Australian-based and staffed by humans around the clock; and for AI features we will answer all six questions per feature in writing, including naming where a component is external. We would rather you tested that than took it on trust.
The summary
Count the companies between you and the model — it is usually three or four, you inherit all their postures and can telephone one. The demonstration is the least informative part of the evaluation because it demonstrates the model, and the model is the same model. Middleware is where the surprises live, and it belongs to whoever you are paying. Model provider commitments, including August 2026's zero data retention, attach to the contract holder rather than to you. Send the six lines, score on specificity rather than tone, and exclude anything that scores zero on where, retention or who fixes it at 3am. Owning infrastructure is an accountability argument, not a technical one — fewer contracts means a shorter gap for a fault to sit in. And whatever you buy, the compliance obligations stay with you, including disclosure from 10 December 2026.
Related reading: why we operate our own network, the December 2026 disclosure obligation, what AI security actually catches, how transcription and summaries work, and what AI voice agents cost and return.
Frequently Asked Questions
How do I find out how many companies handle my business call audio?
Work through five steps and write the number down before you ask your supplier for theirs, because comparing the two is the actual test. First, identify who you pay — that is company one and the only entity you hold a contract with. Second, establish whether that company operates the software itself or resells somebody else's platform; if they resell, add a second company and note that the one you pay cannot change anything about the product. Third, find out which model performs the transcription or generates the AI agent's speech, which is another company unless your supplier genuinely builds and runs its own models, something rare enough that it should be stated explicitly if true. Fourth, determine whose data centres all of that runs in, which is another company again and possibly in more than one country depending on the feature. Fifth, write your count down and then ask your supplier for their number. The typical answer is three or four companies, each with its own retention policy, jurisdiction, security posture and view about what your customers' conversations are for. You inherit every one of those postures and you can telephone exactly one of the companies, and that asymmetry is the core of the problem. None of it is visible in a product demonstration.
Why can't I judge an AI provider from a demonstration?
Because a demonstration shows you the model's performance, and if two suppliers call the same model their demonstrations will be indistinguishable — the thing performing is the same thing. A demonstration can legitimately tell you that transcription accuracy is adequate for Australian accents and your industry vocabulary, how natural an AI agent sounds, how nice the interface is, how quickly it responds and that the feature exists at all. Those are worth checking. What it cannot show you is where the audio travelled to be transcribed, what is retained and by whom and for how long, whether anybody at that company can actually fix a fault in the AI layer, what happens when the upstream provider changes its terms, or whether the supplier can describe their own data flow on a single page. That is an uncomfortable conclusion because the demonstration is the part of an evaluation everybody spends the most time on and it is the least informative part. The practical approach is to watch it, confirm the accuracy is good enough for your context, and then set it aside and do the paperwork, because the paperwork is where suppliers actually differ from one another. Two companies with completely different architectures and completely different ability to help you run identical demonstrations.
Does zero data retention from the AI model provider protect my business?
Partly, and it is important to understand exactly how far it reaches. Zero data retention means the model provider does not retain customer prompts or model responses after a request has been processed, and such arrangements became available for frontier models in August 2026, alongside customer-controlled deployments that keep content on customer-managed infrastructure and work on a mode where content sits on provider infrastructure encrypted with customer-held keys so provider staff cannot read it. Enterprise API data is also not used for training unless a customer explicitly opts in. All of that is genuine progress and worth asking for. What it does not tell you is anything about the company you are actually paying. Zero data retention is an option somebody must enable, in a contract you are not a party to, at one of four layers in the chain. Published analysis of enterprise AI risk makes precisely this point: data flows through application, middleware, model API and cloud infrastructure, and vulnerabilities appear along that chain even where encryption is used, because the weakest architecture anywhere in the chain sets your real exposure. So the useful question is not whether the model provider announced ZDR. It is whether ZDR is enabled on the contract carrying your audio, and what your supplier's own middleware does with that audio either side of the API call.
What should I ask an AI provider before signing?
Six questions, sent in writing and answered per feature where the answers differ. One: for each AI feature — transcription, summaries, AI agent — which country is the audio or text processed in, and which company performs the processing? Two: what is retained at each stage, meaning the application, the supplier's own internal systems and logs, and the model provider, and for how long, and which of those periods are configurable by you? Three: is any of your content used to train any model, ever, and where is that stated contractually rather than in marketing material? Four: who are the subprocessors for AI functions, in which jurisdictions, and how will you be notified of changes? Five: if you report a fault at 3am that turns out to be in the AI layer, who investigates it, in which country, and can they change the component that is broken? Six: what does the AI capability not do and where does it fail, and what is the provider's position on the automated decision-making disclosure obligation commencing 10 December 2026? Question two is designed to be hard to answer with one reassuring sentence because it asks about three layers separately. Question five asks who fixes it rather than who you call. Question six is the strongest single predictor of the rest, because a supplier who can name their product's limits has examined it.
How should I compare the answers from different AI providers?
Score on specificity rather than on tone, because a blunt specific reply is worth more than a warm general one. On processing location, full marks for a country per feature plus the company doing the processing, partial for one country covering everything, nothing for in the cloud or with an enterprise provider. On retention, full marks for three separate answers with actual periods marked as configurable, partial for one period covering everything, nothing for we don't store your data with no layer breakdown. On training, full marks for a contractual reference, partial for an assurance in an email, nothing for a link to a marketing page. On subprocessors, full marks for a named list with jurisdictions and a change-notification commitment, nothing for declining as confidential. On the 3am fault, full marks for a named team in a stated country able to change the broken component, partial for an honestly described escalation path to a vendor, nothing for a support email address. On limits, full marks for real limits named plus a considered disclosure position. Do not use the total as a ranking. Use it as a filter: exclude anything scoring zero on location, retention or who fixes it, for any use involving customer conversations, regardless of price or interface quality. The purpose is to discover which suppliers know their own architecture.
Is owning your own infrastructure actually better for AI?
Not for technical quality, and any provider claiming otherwise is overreaching — plenty of excellent software runs on hyperscaler compute and plenty of poor software runs on privately owned racks. The genuine argument is about accountability rather than engineering. What ownership removes is the gap between two companies where a fault can sit unresolved while each of them correctly certifies its own half. Anybody who has watched a network provider and a platform vendor each run a test, each pass it, and each point at the other knows this gap well. It is not caused by bad faith, it is caused by scope: each supplier honestly confirms their own boundary and neither owns the space in between, so the customer ends up relaying test results between two companies in order to prove that one of them is wrong. The fewer contracts between you and the thing that is broken, the shorter that gap. That is the whole claim. It also has an honest limit worth stating: where a component genuinely is not the provider's own — and for some AI functions a model may be called externally — that should be disclosed per feature in writing rather than allowed to hide behind a general statement about owning the network. A provider unwilling to draw that distinction in their own disclosures is the one to worry about.
Which AI compliance obligations stay with my business?
More than most businesses expect, and no supply arrangement transfers them. Recordings and transcripts of your calls are personal information, so where they are processed forms part of your compliance position rather than simply your provider's architecture. Cross-border disclosure obligations attach to the entity that collected the information, which is you rather than the supplier who transmitted it. And 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 personal information used and the kinds of decisions made — with drafting broad enough to capture rule-based tools and automated assessment technologies as well as anything anyone labels AI. An AI agent that qualifies leads, prioritises a queue or determines who reaches a human quickly is plausibly within scope. A good supplier will help you answer these questions and should be asked to. None of them answers on your behalf, and no contract substitutes your supplier for you as the regulator's counterparty. This is why asking about a provider's disclosure position is not a formality: a supplier who has not considered the December obligation will be no help drafting yours, and you will first need an inventory of every automated decision your systems already make, including the ones nobody currently thinks of as AI.
