A call transcript is another copy of customer data

Transcripts can help find reasons for repeat contacts, identify gaps in procedures, and prepare short call summaries. But transcription does not make a recording less sensitive. The text can still contain names, phone numbers, addresses, order details, complaints, or payment information—and search or a generative model can make those details more accessible than the original audio system.

For a small business, the key question is not only “which model recognizes speech best?” but also “what data passes through each step, who can see it, and when do the copies disappear?” Without that design, a local model may move processing onto the company’s server while leaving excessive access, long retention, or leakage through logs untouched.

Split the pipeline into separate zones

A useful pattern has several steps:

1. **Recording.** The telephony system stores audio in its source repository under existing permissions and retention rules.
2. **Processing.** A separate transcription service receives only recordings with an approved business purpose. Its service account should not have default access to the entire archive.
3. **Review and sanitization.** The transcript is checked for quality and sensitive fields. Unneeded identifiers are masked or replaced with stable tokens before analytics, indexing, or transfer to an LLM.
4. **Use.** Search and summaries are built from a separate, restricted dataset with its own ACLs. Raw audio and complete transcripts remain available only to roles that actually need them.
5. **Deletion.** When the defined retention period ends, remove audio, transcripts, temporary files, search copies, and vectors that are no longer needed for an established purpose.

The boundaries between zones matter more than the model’s name. A speech-recognition service should not automatically receive access to the CRM, HR files, and every call recording. A summarization component should not be able to download raw audio if cleaned text is sufficient.

Masking reduces risk but does not replace controls

Phone numbers and email addresses can often be detected by their format. Surnames, company names, amounts, order numbers, and descriptions of unusual situations are harder to identify. Rules and dictionaries provide a useful first filter, but misses and false positives are possible; a regular expression does not become a reliable security system by itself.

First decide what the workflow actually needs. Analytics on reasons for contact may not require a name or full order number. Preparing a response for an agent may need order context but not bank details. If token reversal is necessary, keep the mapping table separate and grant access only to a specific service or role.

Before sending text to a model, check not only the transcript but also metadata: file names, operator notes, email subjects, attachment names, and logging fields. Sensitive information sometimes bypasses a filter in a diagnostic event that stores the full request rather than in the main text.

A local deployment is not a data policy

A local model can help keep audio inside company infrastructure if the network, servers, and processing flow are designed that way. But the word “local” does not provide access control, encryption, deletion of copies, or safe backups. Those properties must be designed separately.

For every component, check:

  • who can submit audio and read the result;
  • where temporary WAV files, fragments, and logs are stored;
  • whether storage and backups are encrypted;
  • whether logs could reveal the content of a conversation;
  • how employee and service-account access is revoked;
  • what is sent to external APIs if they remain in the flow.

If you use a cloud API, review the processing and retention terms for the specific service and plan. Do not apply a provider’s general statements to a particular configuration without checking. OWASP treats sensitive-information disclosure as a distinct risk for LLM applications and recommends combining sanitization with access controls and restrictions on data sources. A prohibition in the system prompt is not enough: a model may fail to follow it or receive sensitive content through another path.

Test quality and protection together

Pilot one call type, not the entire archive. Use a test sample the company is entitled to process, and remove or mask identifiers in advance. Check four layers:

  • **Recognition:** errors in names, numbers, negations, product names, and Russian speech over a noisy line.
  • **Sanitization:** which sensitive values are missed and which harmless words are mistakenly hidden.
  • **Access:** can an agent see only their permitted data, a manager see aggregate information, and an unprivileged test user see nothing?
  • **Deletion:** does the test recording disappear from the source repository, working transcript store, index, and backups according to the defined process?

Measure the share of transcripts requiring manual correction, missed sensitive fields, and deletion time for each layer. Do not rely on an automatic summary for important decisions without human review: a recognition error in a number, amount, or negation can change the meaning of a call.

Whisper is one local option to evaluate: its official repository describes multilingual recognition and models of different sizes; the project and weights are listed under the MIT license. This is a technical option, not a guarantee of quality on a particular phone system. Measure quality on Russian recordings from your own workflow, calculate memory and speed requirements, and check the licenses of integrations and derived components separately.

Economics: count more than GPU seconds

For a fair comparison of cloud and local options, calculate the cost of the whole process:

  • audio minutes and repeat processing;
  • servers or API and source storage;
  • queues, monitoring, updates, and backups;
  • manual transcript review;
  • development of sanitization, ACLs, and deletion of derived copies;
  • incident handling and user support.

If most calls still need manual listening, automatic transcription may not deliver the expected savings. Start with one measurable effect, such as time spent finding a relevant call segment or preparing a draft summary. Establish a baseline in the current process and compare it with the pilot; do not count freed minutes as savings until you know what useful work they will support.

A minimal rollout plan

1. Assign a process owner and define the purpose of processing recordings.
2. Map the flow: telephony → audio store → ASR → sanitization → analytics/LLM → CRM or search.
3. For every step, specify the data, access role, retention period, and deletion procedure.
4. Prepare a test sample and controlled examples containing names, numbers, addresses, and sensitive phrases.
5. Compare local recognition quality with the current process and test ACLs at every output.
6. Do not index transcripts or enable automated actions until quality, permissions, and deletion have been verified.

A practical first result is not “AI listens to every call,” but a narrow pipeline where every field has a known source, the reader set is limited, and deletion of copies can be demonstrated. Set the data boundaries first; choose the model after you know what it is allowed to hear.