Cloud, customer-hosted, or on-device Speech AI?
Choose where processing belongs by following the conversation, the data, and the responsibilities your team can support.
Published
The short answer
Hosting, integration, and data handling are separate decisions. Vendor-hosted services, customer-hosted workloads, and on-device processing divide responsibilities differently. These are general deployment patterns, not a statement that every Sanas capability is available in all three.
Separate where it runs from how you connect
An API describes how systems communicate; it does not establish where processing happens. An SDK supplies software for an integration; it does not, on its own, prove that all processing remains local. A desktop interface may also use remote services.
Ask three questions separately: where does each workload execute, how does it connect to the calling environment, and what data moves between components? A customer-hosted deployment can run in a public-cloud account controlled by the customer, so public cloud and customer hosted are not opposites.
Vendor-hosted: evaluate the service boundary
In a vendor-hosted model, the provider operates the speech-processing service. Your team still owns the integration, configuration, and appropriate use within its application. Managed infrastructure may reduce the work required to operate the underlying processing environment.
Evaluate the complete commercial and technical service: available regions, data handling, authentication, rate and concurrency limits, service commitments, version changes, and exit options. Measure performance over the network path you will actually use.
- What audio, text, or metadata is transmitted to the provider?
- What happens during a network or service outage?
- Who controls retention, access, and the timing of service changes?
Customer-hosted: control comes with operating work
In a customer-hosted model, workloads run in infrastructure under the customer's control. That may be a cloud account or an on-premises environment, depending on the supported product configuration. Responsibility for deployment, capacity, monitoring, and upgrades must be explicitly assigned.
A workload inside your environment is not automatically disconnected from outside services. Map dependencies for authentication, licensing, support, telemetry, model updates, and any other APIs. Establish what can leave the environment instead of inferring it from a hosting label.
- Which hardware and runtime versions are supported?
- Who patches, scales, monitors, and restores the service?
- Which external dependencies remain, and what information do they receive?
On-device: test the actual endpoint fleet
On-device processing places a workload on the endpoint, such as an agent computer. This can keep a particular audio-processing step close to the source. It does not establish that every other function in the application is local or that the application works fully offline.
Evaluate supported devices, operating systems, resource requirements, headset configurations, updates, and administration. A successful test on one powerful machine does not establish performance across a mixed fleet.
Read the Accent Translation app guideMake a deployment brief before choosing
Use the same checklist for every candidate. Record who owns the answer and where it is documented, rather than comparing broad claims such as enterprise ready.
| Decision | What to establish |
|---|---|
| Workload | The exact capability, product version, call direction, and supported deployment. |
| Data | Where audio, transcripts, derived outputs, and operational logs go; who can access them and for how long. |
| Performance | End-to-end delay and quality under representative devices, networks, and concurrent usage. |
| Responsibility | Owners for infrastructure, access, monitoring, upgrades, incident response, and support. |
| Recovery | What users experience when a component fails, and the tested fallback or rollback. |
| Cost | Licensing or usage, compute, network, support, and the internal effort to operate the service. |
Confirm the supported Sanas configuration
Sanas has a desktop Accent Translation experience and a Developer Platform offering a server-side SDK. Start with the capability and workflow you need, then confirm the supported runtime, integration path, infrastructure requirements, and data handling for that specific configuration.
Do not carry a desktop product statement over to an SDK integration or assume that a hosting option available for one capability applies to another. Use maintained documentation and technical review to settle the details before production rollout.
Explore Sanas integration pathsFurther reading
Common questions
No. An SDK is an integration interface. Confirm which components run locally, which call remote services, and what data crosses those boundaries.
Not necessarily. A supported customer-hosted workload may run in the customer's cloud environment or on-premises. Confirm the supported configuration and who operates it.
Not automatically. Audio processing can be local while access verification, administration, updates, or other services still require connectivity.
There is no universal answer. Measure the actual workload, hardware, network path, and concurrent usage. A hosting label alone does not determine the end-to-end experience.
Do not assume that. These are general patterns for evaluating Speech AI. Confirm current availability and requirements for the exact Sanas capability and configuration you intend to use.
Find the right deployment fit.
Bring your workflow and infrastructure requirements to a Sanas conversation.