Hebrew Call Transcription With AI: What Is Kept, Deleted, and Checked in a Summary

Transcribing a Hebrew call does not produce one file. It produces four separate assets: the recording, the transcript, the summary, and the fields derived from it. Each carries its own access list and its own deletion clock, and a sentence in the summary can only be verified if the timestamp it came from was stored beside it.

A note: this is a design description. Whether you may record, and what must be told to the people on the call, is a legal question for a lawyer and is not covered here.

Why the Hebrew language code breaks integrations

This is the fault that eats the most time in a first Israeli transcription build, because it does not look like a fault. You pass a language code, you get a transcript back, and the transcript is simply bad.

• The IANA language subtag registry defines the tag he for Hebrew, and marks the tag iw as deprecated with effect from 1989, with a preferred value of he. So iw is the historical code and he is the current one.
• Google Cloud Speech-to-Text lists Hebrew (Israel) in its language table under iw-IL - that is, under the historical form.
• Azure AI Speech lists Hebrew (Israel) under he-IL across its tables, covering speech-to-text and synthesis voices.
• OpenAI documents that its languages parameter accepts ISO 639-1 codes, the two-letter kind that he belongs to.

The conclusion is not that one vendor is wrong. It is that the language code is a per-vendor parameter rather than a global constant. It lives in settings beside the engine name, it is exercised by a connectivity test, and it is not hard-coded in two different places.

What exactly is kept, and what is deleted?

Four assets, each with its own decision. The common mistake is treating them as one item called the recording, and then discovering that deleting the file left the full transcript sitting somewhere else.

The third row is why the split matters. The summary is what the business actually needs over time, and it is also the least sensitive item. Keeping the summary while deleting the audio and the transcript is exactly the trade-off most businesses want, and it is impossible if all three live in one field.

How do you check a summary sentence against the recording?

With a time anchor stored beside the sentence, not with trust. Without an anchor, verifying one claim means opening a forty-minute Hebrew recording and hunting, and nobody does that more than once.

OpenAI's documentation supplies the parts, but not uniformly across models, which is why it is worth reading before choosing one:

1. Timestamps. The timestamp_granularities parameter returns word-level or segment-level timestamps, and the documentation states it is supported only on whisper-1.
2. Speaker labelling. A dedicated diarization model returns, in the diarized_json response format, segments carrying speaker, start and end.
3. File size. The transcriptions API accepts files up to 25 MB, and the documentation advises splitting larger recordings without cutting in the middle of a sentence, because such a cut removes context and reduces accuracy.
4. Formats. The supported input formats listed are mp3, mp4, mpeg, mpga, m4a, wav and webm.

From that follows one rule for summaries: every line carries a start, an end, and a speaker where one is available. A line without an anchor is not deleted - it is marked unverified, and that distinction is what turns a summary from text into an asset.

Where Hebrew speech recognition fails, and why it matters to the summary

The errors are not evenly spread. They cluster in exactly the places that produce summary lines:

• Switching between Hebrew and English mid-sentence. In an Israeli business call this is completely normal, and system names and technical terms arrive in English inside Hebrew syntax. A misheard product name becomes a wrong line in the summary.
• Numbers spoken as words. An amount stated in Hebrew arrives as words rather than digits, and every conversion to a number is an interpretation. Amounts in a summary stay as quotation until a person confirms them.
• Personal and business names. These carry no contextual cue, and in Hebrew there is no capital letter to mark them either. They are the first thing worth supplying to the engine as a term list in advance.
• Overlapping speech. Two people talking at once produce a segment with no single speaker. Such a segment is flagged, not summarised.

What do you do when the summary contradicts the transcript?

You flag the line and keep both versions. A summary does not override a transcript and a transcript does not override the recording, and that order of precedence is written down so it is not re-decided during every disagreement.

• An unverified line is one with no time anchor, or whose anchor points at a segment flagged as overlapping speech. It stays in the summary and stays marked, because deleting it hides precisely what needs checking.
• A contradicting line is one whose anchor leads to different text. Here both what the model wrote and what the transcript says are kept, and a person decides between them in a separate field.
• A human correction is stored as a third field rather than overwriting the previous two. The pair of what was written against what was corrected is what reveals that a particular kind of claim keeps going wrong.
• A claim nobody confirmed does not move downstream. A derived field is created only from a verified line, and that is the gate stopping a vaguely heard amount from becoming a line on a quote.

The most common contradiction in Hebrew is not a real contradiction but the gap between quotation and interpretation: the customer said something hedged, and the summary wrote it as a decision. So lines describing a decision or an agreement are automatically flagged for review, even when their anchor is sound.

Related: risk assessment for putting customer data into AI, the customer spreadsheet and Amendment 13, from a call to a quote.

Who may read what, and how that is enforced

A permission held only at conversation level is a permission that does not exist, because every export walks around it. Enforcement happens at three points:

• At the asset. Access to the audio, the transcript and the summary are three separate permissions. Somebody approving a summary does not need the audio.
• At export. Every export is logged with who, when, and which fields. Exporting full transcripts to a spreadsheet is exactly where the restriction disappears.
• At the handoff to downstream systems. When a summary moves into another system, only the summary moves. A transcript is not copied into a customer record, not even as a hidden field.
• At deletion. Deletion is defined as an operation running across all four assets, not as removing a row. A row deleted without its file leaves the file behind.

Sources

• IANA - Language Subtag Registry
• Google Cloud Speech-to-Text - supported languages
• OpenAI - file transcription guide