Minutes, Not Recordings: How AI Transcription Must Be Built for the Courtroom

A Special Case of Speech Recognition

Speech recognition has long been part of everyday life: dictation software, subtitles, transcripts of video conferences. Anyone who wants to use the same technology in criminal trial proceedings quickly realizes that the standard tools were built for different situations. A dictation program expects a single voice close to the microphone. A video conference delivers each participant via their own channel. In a courtroom, by contrast, a laptop sits on the defense table, and in front of it speak the presiding judge, any associate judges, lay judges, the prosecution, witnesses, and expert witnesses – from varying distances, amid room acoustics, with interruptions and many proper names.

Added to this are requirements that no office application knows. The audio must not leave the device. Whether it may even be stored is a legal question with significant consequences: if it is processed only transiently in working memory, the result is legally a written note; if it is stored, it becomes an audio recording, which requires the court's permission. And the defense attorney has no free hand during examination to operate software. This article describes how transcription software must be structured to meet these conditions.

Principle 1: Everything Stays on the Device

Modern laptops carry specialized AI processing units that allow real-time speech recognition without the cloud. In the courtroom, this is not a question of convenience but a prerequisite. If recognition runs locally, there is no data processor, no transfer to third countries, and no question of attorney–client confidentiality vis-à-vis a service provider.

Local here means consistently local. The recognition models belong in the software package and are not loaded at runtime. The audio path has no access to the network. Where the software requires a connection at all – for example, to import master data from a case file from the law firm's software – that connection remains restricted to the firm's internal network, is read-only, and touches neither audio nor transcript. These properties should not merely be promised but enforced by the operating system's permission management.

Principle 2: The Audio Is Raw Material, Not the Result

The result of a written note is text. The audio is merely the material from which that text is produced. From this follows the most important architectural decision: the path from microphone to text must be built in such a way that nothing required for the written note itself is missing without storing audio.

The process is fundamentally always the same. The microphone signal is converted into a format suitable for recognition, held in short segments in a buffer, and passed to the recognition model. What comes back is not just text, but a timestamp for each word and a value indicating how confident the model is. These additional data points are the true value of the machine, because speaker attribution, search, and error flagging are all built on them.

With purely transient processing, the buffer is continuously overwritten. The crucial point is that this is a property of the architecture, not a setting that first writes a file and later deletes it. Anyone who stores audio instead must treat it in accordance with its sensitivity:

• a unique key per session, which in turn can only be read with a master key bound to the device's security chip, ensuring the data cannot be decrypted on any other machine,
• encryption in small blocks, so that a crash does not render the entire recording unusable,
• a fixed deletion deadline enforced by a system service even when the application is not running,
• deletion through destruction of the key (crypto-shredding), so that even remnants on the storage medium become unreadable,
• exclusion from data backups, so that no copy outlasts the deletion deadline.

Two stages of recognition

Live transcription requires a fast, energy-efficient model. It displays provisional text immediately and replaces it once it has committed to a result. Such models perform well with everyday language but are noticeably weaker with proper names, place names, numbers, and dates. Yet these are precisely the details that are often decisive in witness testimony.

If audio has been saved, a second stage can be added after the session: a considerably larger recognition model that re-transcribes the hearing day overnight. To ensure this second stage does not degrade quality, it requires safeguards. Manually corrected passages must not be overwritten, removed passages must remain blank, and the live version should be restorable. Large models also tend to fabricate sentences during silent phases that were never spoken. Such typical hallucinations must be detected and filtered out.

Without audio storage, the second stage is unavailable. That is the price of the legally secure variant, and the software must compensate for it elsewhere – primarily through the dictionary and the annotation column described below.

Who is speaking? Speaker separation without pressing a key

A transcript without speaker attribution is of little value in the courtroom. However, the defence attorney cannot press a key at every speaker change while simultaneously preparing questions or consulting with the client. The assignment must therefore happen automatically.

Speaker separation (diarisation) operates in three steps: it divides the audio into segments each containing a single voice, computes a voice print for each segment – a numeric vector capturing the characteristics of the voice – and groups similar prints into speakers. The more audio is available, the more stable this assignment becomes. It therefore makes sense to re-compute the separation regularly over the entire session so far rather than examining only the most recent segment.

This creates a practical problem: every new run renumbers the speakers. If the defence attorney has already labelled "Speaker 2" as the presiding judge, that assignment must not be lost in the next run. The software must therefore map old and new speakers to one another based on their overlapping speaking times. A role is thus assigned only once per speaker and applies throughout the entire day. It is also helpful to suggest who the witness is in a hearing – identifiable as the person with the largest share of speaking time. Such a suggestion must remain marked as a suggestion until the defence attorney confirms it.

Voice prints are not audio, but they are personal data and potentially biometric data. They must therefore be protected and deleted with the same care as the audio itself.

Making Uncertainty Visible

The accuracy of transcription software is approximately 95 percent. A fluently readable text conceals this error rate. The software must therefore show where it is uncertain. Words for which the model reports a low confidence score are highlighted in color, both in the application and in the export. Every document produced by the software should also be explicitly labeled as an automated transcript that does not constitute an official record.

The Second Column: Verbatim Text and Notes Side by Side

The most important element of the interface is a two-column layout: on the left, the recognized verbatim text; on the right, the defense counsel's annotations. There, they record what the machine cannot accomplish: a correction, the note "uncertain," an observation about a witness's demeanor, or a reference to a document in the case file. Machine text and human perception appear side by side, but remain separate.

One detail determines usability: an annotation must be assigned to the paragraph that was being spoken when the defense counsel began writing, not the one currently running when the note is saved. Typing a note takes a few seconds, and during that time the witness continues to speak. The column is supplemented by markers for important passages, contradictions, and potential motions, as well as by structural headings that map the progression of an examination: caution, personal details, substantive testimony, questions from individual parties to the proceedings, confrontations with prior statements, and dismissal.

Without audio recording, this column is the central instrument for correction. It replaces subsequent listening back with perception captured in the moment.

Learning from Corrections

Proper names are the weak point of every speech recognition system. Many systems offer the option of providing a list of expected names in advance. In practice, this feature shows no measurable effect with some live models, and with some large models such a prompt text can even cause sentences to be lost.

More reliable is a dictionary that learns from the user's corrections. When the defense counsel corrects a paragraph, the software compares the old text with the new text word by word and suggests the changes found as replacement pairs. Pairs that appear to be proper names are pre-selected. Confirmed pairs apply immediately to the entire session and to all future recognition. If a witness is corrected once on the first day of proceedings, their name will be spelled correctly from the outset on the second day.

What Does Not Belong in the Transcript

Not everything that reaches the microphone belongs in a transcript. The software must handle two cases.

The first involves portions of proceedings that may not be recorded – for example, following the exclusion of the public or during a consultation at the table. This requires a clearly visible switch that actually turns off the microphone, not merely the display. The transcript retains only a note indicating the period during which nothing was recorded.

The second category consists of conversations that were accidentally captured, such as a quiet exchange with the client. These must be removable after the fact. If audio has been saved, deleting the text is not enough: the audio at that point must also be irreversibly overwritten, with a small safety margin before and after, otherwise the second recognition stage could restore the content overnight. Nothing from such a passage appears in the export.

Tools for Everyday Use in Court

A transcript only delivers its true value when it works during the hearing, not merely afterwards.

• Search during live transcription. If a witness contradicts in the afternoon what they said in the morning, the passage must be locatable within seconds without stopping the transcript. The results appear with timestamps and speaker identification and can be copied as a quotation for a confrontation.
• Motion under § 273 para. 3 StPO. When the exact wording of a statement is at issue, the defense counsel can move for it to be recorded in full and read aloud. The software transfers the highlighted wording directly into a pre-drafted motion.
• Export. A word-processing file with header information about the proceedings and a table containing the wording and annotations for each examination, with uncertain words flagged and a list of the markers that have been set.
• Operational reliability. The screen must not lock during transcription. If no audio is incoming or the level has been barely measurable for an extended period, the software must issue a warning. It should also select the microphone itself: on many computers, video-conferencing or recording applications have installed virtual audio devices that register themselves as the default input. Software that relies on this default may then transcribe silence for hours without any indication.

The Core Architectural Question: Store Audio or Not?

Ultimately, every design decision comes down to a trade-off. Stored audio enables the second recognition stage, the ability to replay individual passages during correction, and a later recalculation of speaker separation. Without audio, the live transcript, the flagging of uncertain words, the annotation column, the adaptive dictionary, search, and export all remain fully intact.

From a legal standpoint, ephemeral processing is, according to the relevant literature, to be treated like a written transcript and is permissible. The storage of audio, by contrast, requires authorization from the presiding judge and carries criminal-law risks in non-public portions of proceedings. Anyone designing such software should draw the logical conclusion: ephemeral processing is the default; audio storage is a deliberately activated exception for proceedings in which the court has granted its permission.

Technology in the Service of the Defense

Good transcription software for the courtroom is less a question of the best recognition model than a question of architecture. It runs locally, treats audio as transient raw material, assigns speakers without manual input, displays its uncertainty openly, allows the defense attorney to record what they heard alongside the recognized wording, and learns from every correction. Built this way, it replaces uncertain memory with the verbatim record and gives the defense attorney their attention back – focused on the witness.