AI calls have a different privacy posture than meetings.

The model backend is pluggable per deployment.

CodeB Voice AI doesn’t bake any one model vendor into the product. The bridge can run against any of the following, configured by the operator in App_Data/<tenant>/appsettings.json. There is no default cloud connection: with no backend configured, AI calls don’t run.

Two specifics worth knowing. API keys are per-tenant, configured in the tenant’s appsettings file — we don’t share or proxy keys between deployments. Per-vnum backend override is supported: you can route one DID to a cloud AI Voice Engine and another DID on the same install to an on-premise AI Voice Engine, if some lines need the cloud model and others must stay on-prem.

The egress matrix.

The single most important question for a procurement review is “does this data leave my network?” Here is the complete answer per backend.

What the operator is responsible for.

If your deployment runs AI calls using a cloud model, you are the data controller under GDPR Art. 4(7) and most equivalent jurisdictions. The model vendor is a processor; Aloaha Limited is a processor for the bridge software itself but does not see your call data. Three concrete obligations follow.

Caller disclosure

Tell callers they’re talking to an AI — typically in the AI’s first sentence, or via a brief hold-message before pickup. The EU AI Act (Art. 50, in force 2025-08-02) requires this; California and several US states have similar rules; some sectoral regulators go further.

Backend selection & data-residency match

Pick a backend whose data-processing terms match your regulatory environment. Concrete defaults we recommend:

• EU healthcare, legal or public-sector deployments → on-premise AI Voice Engine, or a vendor with a documented EU data-residency offering and a signed DPA.
• Generic SME EU deployments → cloud backend with a standard DPA; document the choice in your processor register.
• Air-gap / classified environments → on-premise AI Voice Engine only.

Transcript retention policy

The bridge keeps transcripts indefinitely on disk by default. Set a rotation policy that matches your minimisation duty: a scheduled task that deletes files older than N days under App_Data/<tenant>/ai-transcripts/. We deliberately don’t do this for you — the right N depends on your sector.

How this maps to specific laws.

Not legal advice — just the obvious anchors a DPO will look at.

EU GDPR & AI Act

• Art. 4(7) GDPR: you, the deploying organisation, are the controller. Aloaha Limited and the chosen model vendor are processors. Get a DPA signed with each.
• Art. 28 GDPR: your processor register needs an entry for the model vendor if you use a cloud backend. Local-only deployments have no external processor.
• Art. 32 GDPR: technical and organisational measures — the egress matrix above is the document your security team can attach.
• EU AI Act Art. 50: caller-disclosure obligation when an AI system interacts with a natural person.

UK

• UK GDPR mirrors EU GDPR for controller / processor obligations.
• ICO direct-marketing guidance applies to outbound AI campaigns — we recommend reading it before running an outbound vnum to UK consumer numbers.

US

• HIPAA (healthcare): the cloud backend is unlikely to be HIPAA-compliant under the standard DPA. Use the local backend for any deployment that touches PHI.
• State AI-disclosure laws (California, Colorado and others): disclose AI interaction at call start.

Healthcare-sector specifics

• For any deployment that handles patient identifiers or clinical content, default to the local backend.
• If a cloud backend is unavoidable, scope it to non-clinical workflows (appointment confirmation, billing FAQ, opening hours) and never to clinical advice.

If you can’t use a cloud model at all.

Air-gap and high-assurance deployments are supported. Two patterns work today:

• On-Premise-AI-Sprach-Engine scripts — the simplest on-prem option. The persona’s replies are short text-to-speech tied to caller intents, no LLM in the loop. Fine for opening-hours announcements, password resets, scripted intake forms. No external network access required.
• on-premise speech-to-text + an open-weights model on the same Windows host — supported via a local inference server (a local inference server). Sub-second latency is achievable on a modest GPU. Speech quality is below cloud-vendor TTS, but acceptable for many internal-facing applications.

We do not ship the inference server itself — you bring the hardware and model weights. The bridge exposes a configurable WebSocket endpoint URL where your local inference server lives. Get the local-inference setup notes →

Things buyers usually ask.

Are calls between humans handled the same way?

No. Human-to-human calls on CodeB Phone go from softphone ↔ bridge ↔ your SIP trunk. No model API is involved, ever. See the main privacy manifesto and SIP data flow for that path.

Do you train models on my data?

Aloaha Limited does not train anything on your call data — we don’t see it. Whether the model vendor uses your data for training depends on the DPA you sign with them. the cloud AI Voice Engine vendor and enterprise tiers from major cloud vendors contractually exclude training; the consumer tiers may not. Pick accordingly.

Where does the bridge live when an AI call runs?

The bridge is a Windows service on your machine. It maintains two connections: SIP toward your trunk, and a WebSocket toward the configured model API (or your local inference server). It is never proxied through any Aloaha-owned infrastructure.

What about call metadata — numbers dialled, durations, FraudGuard counters?

All of it stays on the machine. The CDR is local. FraudGuard counters reset daily and live in the tenant directory. The webhook dispatcher sends events to URLs you configure, signed with HMAC.

Can a caller request transcript deletion?

Yes — transcripts are flat files under App_Data/<tenant>/ai-transcripts/. A DSAR-fulfilment workflow is one shell-script away. We ship a small admin page (transcripts.html) that lets you locate and delete a specific transcript by call ID.

What gets logged centrally?

Nothing. There is no central log shipper, no telemetry SDK, no Sentry, no Datadog. Bridge logs are written to App_Data/<tenant>/logs/ on the same machine and only viewable via the admin web logs page (operator-only).

Related reading.

• Privacy manifesto — the broader CodeB privacy posture for meetings and SIP calls.
• vnum data flow — the technical packet-level diagram of an AI call.
• AI receptionist overview — the product page.
• Outbound AI use-cases — concrete campaign examples.
• REST API + webhooks — how AI calls integrate with your CRM.
• Contact — for DPAs, local-inference setup notes, or sector-specific questions.