Handing a supplier your phone line and your client records is a real decision. This page says what happens to that data, who decides where it sits, and which words are deliberately not used on this site.
Your jurisdiction and your sector decide the architecture. That is a scoping input, not a checkbox at the end.
Deployment runs on your infrastructure, in the region you specify. You decide where recordings, transcripts and client records physically live, and that decision is made during scoping rather than discovered later in a subprocessor list. We do not hold your client data after handover, because we are not in the path.
The system collects what the task needs and no more. Processing records exist from the first day of the build, not from the first audit. Data processing terms are issued at contract, and the subprocessors involved are named rather than described in a category.
When a client asks to be removed, the record leaves the calendar, the transcripts and the backups. Retention windows for recordings are set by you and enforced by the system rather than by someone remembering.
Whether a caller is told they are speaking to a system is a configuration decision made before launch. In several markets it is a legal requirement rather than a courtesy, and the rules differ by jurisdiction and by sector. We build to the rule that applies to you.
You will not find a certification badge on this site. Ready and aligned are words that look like certification without being it, which is why they are not used here. Where your sector requires a specific standard, the architecture is designed for it and the gap between designed for and certified against is stated plainly in the proposal.
Language coverage and jurisdiction are confirmed during scoping against your actual client base. Related: how impact is measured and the full FAQ.
The architecture is easier to agree when the person who has to sign it off is in the room from the start.