Quick answer
A compliant AI sales agent deployment is nine components, not one policy document: identity and disclosure, consent provenance, suppression, retention and deletion, data residency, human escalation, audit trail, change control and vendor evidence. Each needs a named owner and each must produce one specific artefact. Build the record-keeping before the calling, because the first question anyone asks you is evidentiary.
General information about published regulations and standards, not legal advice. Get counsel in each market you operate in.
Why the architecture matters more than the rule
Most compliance writing about AI calling agents is rule-by-rule: what the EU AI Act requires, what a given US state requires, what ACMA enforces. Those are inputs. They change, they conflict, and across three countries you will never finish reading them.
What does not change is the shape of the answer you must produce. Regulators, auditors and procurement teams all eventually ask the same four questions: what did the agent say it was, where did the permission come from, who could stop it, and show me the record. A deployment that can answer those survives most rule changes. One that cannot will fail an audit even where no AI-specific law exists, because the underlying privacy, records and outsourcing obligations were already there.
Rule-level detail is elsewhere: EU AI Act Article 50, the US state call-disclosure patchwork, Colorado’s rewritten AI Act, Texas TRAIGA, the Do Not Call Register, and the jurisdiction-by-jurisdiction outreach compliance map. This piece is what you build regardless.
The nine components
1. Identity and disclosure
What the agent says it is, when, and in which language — a writing problem covered in how to announce an AI agent on a live call. The architectural part is versioning: asked about a call from fourteen months ago, you resolve its timestamp against a disclosure register. If the disclosure lives only inside the current system prompt, you cannot.
2. Consent capture and provenance
Records not that consent exists but where it came from, in a form that outlives the web form, the vendor, the CRM migration and the person who built it. Third-party data is where most chains break, which is why we treated it separately in purchased lead lists and TCPA consent and rewriting consent language for AI calls.
3. Suppression and list hygiene
The union of every do-not-contact signal — national registers, internal opt-outs, complaints, legal holds, vulnerability flags — and the mechanism that stops the agent dialling them. Split lists are a standard failure mode: an opt-out lodged in one channel never reaches the other. The number that matters is propagation time, from capture to removal from an in-flight queue. Ask your vendor to state it, then test it. If the answer is “nightly batch”, your architecture permits a full day of calls to someone who has already said stop.
4. Recording, retention and deletion
Audio, transcripts, summaries, embeddings and CRM notes governed as one estate rather than five, with a named person who can push a deletion through the whole stack. The OAIC’s APP 11 guidance says at paragraph 11.39 that an organisation must take reasonable steps to destroy or de-identify “all copies it holds of that personal information, including copies that have been archived or are held as back-ups”. Where the data sits on a third party’s hardware such as cloud storage and you have instructed that party to destroy it, reasonable steps “would include taking steps to verify that this has occurred” (paragraph 11.50). Verify, not request. Where irretrievable destruction is genuinely impossible, paragraph 11.52 sets a “beyond use” standard requiring, at a minimum, access controls including logs and audit trails, plus a commitment to take reasonable steps to irretrievably destroy the information if or when that becomes possible.
5. Data residency and sub-processors
Where audio, transcripts and inference physically happen, and who else touches them. The OAIC’s APP 8 guidance states at paragraph 8.2 that “Where an entity discloses personal information to an overseas recipient, it is accountable for an act or practice of the overseas recipient that would breach the APPs (s 16C).” Outsourcing the processing does not outsource the liability. More in AI agent data sovereignty in Australia.
6. Human escalation and the stop condition
When the agent hands over or hangs up: a request for a human, a complaint, a vulnerability signal, a regulated-advice boundary, repeated misunderstanding, a confidence floor. This belongs to the process owner; a vendor default is a starting point, not a control. The NIST AI Risk Management Framework (AI 100-1, January 2023) names it as subcategory MANAGE 2.4: “Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.” Design detail in confidence thresholds and the AI-to-human handoff.
7. Audit trail and observability
For any single call: timestamp, agent version, prompt version, disclosure string served, consent record referenced, suppression result, systems called, escalation events, final disposition — all immutable. NIST’s GOVERN 1.6 asks that “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities” — an inventory that cannot resolve down to individual interactions is a spreadsheet, not a control. Engineering detail in AI agent observability.
8. Change control
A prompt edit is a production change. One sentence can alter what the agent claims or offers to thousands of people before anyone notices, so it belongs in the same change process as your other production systems. NIST’s MANAGE 4.1 lists change management alongside “appeal and override, decommissioning, incident response, recovery”. There is real tension with optimisation here: continuous split-testing of sales scripts is valuable, but in a regulated deployment the variant set has to be pre-approved rather than generated freely.
9. Vendor evidence
What the supplier hands you without being chased: a data processing agreement, a current sub-processor list with change notification, retention and deletion policies per artefact, an incident process with a stated clock, and a written statement on whether your conversations train any model.
Two regulators set useful benchmarks even if neither binds you. APRA’s Prudential Standard CPS 230 Operational Risk Management — the determination currently published on apra.gov.au commenced on 1 July 2026 — requires the formal agreement for a material arrangement to require notification by the service provider of its use of other material service providers it materially relies upon through sub-contracting or other arrangements. Separately, it requires the service provider management policy to cover the risks from fourth parties, and defines the layer: “A fourth party is a party that a service provider relies on in delivering services to an APRA-regulated entity.” In US healthcare, the Department of Health and Human Services states that a written contract between a covered entity and a business associate must “require the business associate to ensure that any subcontractors it may engage on its behalf that will have access to protected health information agree to the same restrictions and conditions that apply to the business associate with respect to such information”; its sample agreement provisions — sample language, which HHS says is not itself required for compliance — render that as a duty to “ensure that any subcontractors that create, receive, maintain, or transmit protected health information on behalf of the business associate agree to the same restrictions, conditions, and requirements that apply to the business associate with respect to such information”. Both reach past your direct supplier. So should your voice-AI vendor security questionnaire and the control-by-control enterprise readiness checklist, which is where the vendor-side detail lives; this component is only about what you must hold on file.
The component map: owner and evidence
| Component | Typical owner | Evidence artefact |
|---|---|---|
| Identity and disclosure | Legal drafts, platform deploys | Versioned disclosure register with effective dates |
| Consent capture and provenance | Marketing ops, spec by legal | Per-contact record: wording, source, timestamp |
| Suppression and list hygiene | One named data owner | Suppression register plus measured propagation time |
| Recording, retention and deletion | Records management | Retention schedule plus a demonstrated deletion |
| Data residency and sub-processors | Security architecture | Sub-processor list: country, function, transfer basis |
| Human escalation and stop condition | Business process owner | Stop-condition list plus logged escalation events |
| Audit trail and observability | Platform engineering | Immutable per-interaction record |
| Change control | Change advisory board | Prompt and config diffs with approvers and rollback |
| Vendor evidence | Procurement | DPA, sub-processor list, retention policy, incident process |
Where Zian sits
Zian AI runs autonomous sales agents on live phone, SMS, email and WhatsApp across 30+ languages, with API and CRM integrations. Two facts bear on this architecture. Private model deployment on customer infrastructure is a supported capability, which materially changes the residency and sub-processor conversation — we describe that model here. And Zian is in waitlist beta: no public pricing, no free trial, no self-serve signup. Zian has run outbound acquisition since 2017. Zian holds no security or AI-management certification, accreditation, attestation or independent audit, and nothing here should be read as claiming one. If your process requires a current certificate before a pilot, we are not the right vendor today — and you should not accept an unevidenced certification claim from any vendor.
Implementation order
Most teams build the calling first because it demos well, then find the first question they are asked is a record-keeping question. This order avoids that.
| # | Build | Why here |
|---|---|---|
| 1 | Suppression register, unified across channels | The only control whose absence causes harm on day one. |
| 2 | Consent record schema | Provenance cannot be retrofitted. Define the fields before the first import. |
| 3 | Audit trail and retention schedule | Both are logging decisions; turning them on later loses every call in between. |
| 4 | Disclosure register with versioning | Ten minutes of schema work now answers a question you get in year two. |
| 5 | Stop conditions and escalation routing | Must exist before the first live call. This is where a person is protected. |
| 6 | Vendor evidence pack | Collect during procurement, while you still have negotiating room. |
| 7 | Change control over prompts and configuration | Needed the moment more than one person can edit the agent. |
| 8 | Residency and sub-processor mapping | Slowest to finish because it depends on the vendor. Start early. |
| 9 | Calling at volume | Everything above is what lets you keep doing this. |
One shortcut is legitimate: if you already run a governance program under an established framework, map these nine onto it rather than building a parallel structure. NIST’s GOVERN 1.1 asks that “Legal and regulatory requirements involving AI are understood, managed, and documented” — the point is that it is findable, not that it lives in a new binder.
How we sourced this
Every regulatory statement above comes from a page we opened on 28 August 2026: the OAIC’s APP 11 and APP 8 guideline chapters, the NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023), the version of APRA’s CPS 230 currently published on apra.gov.au, and the HHS sample business associate agreement provisions. Quotes are verbatim and keep their source’s original spelling.
What we could not verify and so did not assert: any benchmark for how fast a typical AI calling platform propagates an opt-out. No vendor-independent measurement of that exists, so it is a number you must measure yourself. We make no claim that this framework satisfies any specific regulator; it organises controls, it does not certify them.
FAQ
What is a compliance architecture for an AI sales agent?
The set of controls a regulated deployment needs regardless of jurisdiction: identity and disclosure, consent provenance, suppression, retention and deletion, residency and sub-processors, escalation and stop conditions, audit trail, change control, and vendor evidence. Rules set the thresholds; the architecture produces the evidence you met them.
Who owns AI agent compliance — legal, IT or sales?
Split it by component, not by department. Legal owns wording and contract terms, data engineering owns provenance and suppression, platform engineering owns the audit trail, procurement owns vendor evidence, and the process owner owns the stop conditions. Assigning it all to one function is what fails: sales-owned compliance drifts, legal-owned compliance never ships.
How long should we keep AI call recordings and transcripts?
As long as you have a purpose, and no longer. The Office of the Australian Information Commissioner’s APP 11 guidance states at paragraph 11.29 that an entity “must take such steps as are reasonable steps in the circumstances to destroy personal information or ensure it is deidentified if it no longer needs the information for any purpose for which it may be used or disclosed under the APPs (APP 11.2)”, subject to Commonwealth record and legal retention exceptions. Set a schedule per artefact type, and include backups and derived data.
Is a prompt change really a production change?
In a regulated environment, yes. A prompt determines what the agent claims and offers. The NIST AI RMF lists change management within MANAGE 4.1 alongside incident response and decommissioning, which puts prompt edits in the same governance class as code deployments. Practically: diffs, an approver, an effective timestamp, and a rollback path.
What evidence should we demand from an AI voice vendor?
A data processing agreement, a current sub-processor list with country and function, a change-notification commitment, retention and deletion policies per artefact, an incident process with a stated clock, a written statement on model training, and evidence of deletion on termination. APRA-regulated entities must notify APRA of a material operational risk incident “as soon as possible, and not later than 72 hours” after becoming aware of it — a clock you cannot meet if your vendor’s notification timeline is unstated.
Does running the model on our own infrastructure solve compliance?
It resolves one component well and leaves eight open. Private deployment addresses residency and sub-processor exposure, which is why it matters in banking, health and government. It does nothing for consent provenance, suppression propagation, disclosure versioning or change control.
What should a regulated team build first?
Suppression, then the consent record schema, then the audit trail and retention schedule. Those three cannot be retrofitted: an opt-out you did not honour is already harm, provenance you did not capture cannot be reconstructed, and calls you did not log are gone.
Where to go from here
If you are evaluating AI sales agents for a regulated environment and want to work this architecture through against a real deployment, Zian is in waitlist beta and takes partners selectively. Apply For Partnership, and bring your evidence requirements to the first conversation rather than the last.