This page was translated automatically using artificial intelligence (DeepL). The German version is binding. More information about automatic translation
Data protection-compliant transcription and AI-powered summarisation in a single system
A one-hour interview has been recorded. The audio file is uploaded to Mittweida Scripter and, shortly afterwards, the full transcript is available. What used to take several hours of manual work is now largely automated.
But then the next stage of the process often begins.
Depending on the length of the conversation, a transcript can quickly run to many pages. For example, anyone wishing to analyse a lengthy interview, a group discussion or a recorded meeting usually needs more than just the full text. Often, the first step is to identify the key points, pinpoint central themes or gain a quick overview of the conversation.
A summary is therefore often the logical next step after transcription.
And this is precisely where a new problem arose for us.
Data protection does not end with transcription
When developing the Mittweida Scripter, one of our key objectives was to be able to process audio and video files within the university’s infrastructure. Unlike many external services, this means that sensitive interview or conversation data does not need to be transferred to commercial transcription providers. The Mittweida Scripter processes the files on the servers of Mittweida University of Applied Sciences and deletes both the uploaded and generated files once processing is complete. This fundamental concept was already at the heart of the tool’s first version.
However, in discussions with users of the Mittweida Scripter, another need repeatedly became apparent: Whilst conversations could be transcribed using our tool in compliance with data protection regulations, some users still resorted to external AI services for subsequent analysis – and, in particular, for summarising the content – and transferred the generated transcript there.
So the typical workflow might look something like this:
A person is conducting an interview that may contain sensitive content. The recording is transcribed using the Mitweida Scripter within the university’s infrastructure. To speed up the transcription process, the transcript is fed into an external large language model, which is then given the prompt: ‘Summarise this conversation for me.’
Whilst this would mean that the original audio file would remain within our infrastructure, the content generated from it might still leave it in the next stage of the process.
It therefore became clear to us relatively quickly that if we wanted to offer a process that complied with data protection regulations as consistently as possible, it could not end with the finished transcription.
Transcription and summarisation in a single step
This idea has led to the development of a new feature in the Mittweida Scripter.
In addition to the actual transcription, users can now choose directly whether an AI-generated summary should also be created. To this end, a Large Language Model has been integrated into the Mittweida Scripter’s infrastructure, which runs on its own server resources.
The key difference is that the transcript generated for the summary does not need to be downloaded first. Transcription and summarisation can take place within the same workflow.
The website now features an additional option for this: ‘Generate summary?’. If this is activated, further settings can be configured. For example, the desired language for the summary can be selected. There is also a text field available through which further instructions can be given to the AI.
For instance, you can specify that certain topics should be given particular attention, that technical terms should be highlighted, or that key points should be summarised again at the end.
The aim is for the summary not merely to be an abridged version of the transcript, but to be as well-suited as possible to the specific use case.
The technical aspects behind it
At this stage, the further development of the Mittweida Scripter became significantly more technically challenging. Whilst simply feeding a transcript to a language model works relatively smoothly with short texts, However, with long interviews, large volumes of text are quickly generated, in which factors such as context length, the division of the transcript, the length of the generated summary and the wording of the prompts play a key role.
My colleague Erik Herrmann has worked extensively on the integration and optimisation of this feature and describes in the following section how our current solution is technically structured.
Technical background
by Erik Herrmann
The first step was to select a suitable language model. To this end, we tested various models, including, for example, gpt-oss and Llama. Gemma4:e4b delivered the best results; we now run this via an Ollama Docker container.
However, this merely laid the foundations. The real question was how to feed a long transcript into the model in such a way that as little information as possible is lost.
In the first version, we divided the text into fixed sections, known as ‘chunks’. However, a problem soon became apparent: because the text was cut off abruptly at fixed points, some information was lost. For this reason, we increased the context window and adjusted it to be close to the model’s limit. As a result, the model can process significantly more information per call, thereby reducing information loss.
Nevertheless, we cannot do without chunks entirely. For very long recordings – those lasting several hours, for example – the text is still divided into such sections. Compared to the first version, however, each individual chunk is now much larger and contains correspondingly more information. In this case, the chunks are additionally divided into groups and hierarchically reduced to minimise information loss as much as possible. The end result is once again a single text, which is then passed to the model together with a predefined system prompt.
This system prompt, too, has changed significantly over the course of development. Initially, it was very simple in design. This meant that the summaries sometimes contained markup fragments such as ‘#’ or ‘*’. Furthermore, the prompt merely specified a maximum word count. As the text was reduced to a fixed size of 20 per cent, this sometimes resulted in very short summaries. In the second iteration, we therefore adapted the system prompt. As well as the selected language, it now also includes a minimum word count and the instruction to highlight key terms in the text. In the next step, these terms are printed in bold in the document. Furthermore, additional instructions can optionally be provided to the model – for example, to use a specific writing style.
In addition to summarising the transcription, the attribution of speakers is also summarised. For this, we use our own, specially adapted system prompt. It is designed to ensure that statements are directly tagged with the existing timestamps and the speaker from the original document.
Looking back, the greatest challenge lay precisely in the design of these system prompts. This is because even minor changes can alter the result. The consistency of the responses plays a particularly important role here, ensuring that all users receive the same quality.
Nor should the pre-processing of the text be overlooked. A balance must be struck here between the available system resources and the quality of the responses. To this end, we carried out an extensive test run to make sensible use of the available resources without risking system crashes. Furthermore, to ensure that processing proceeds swiftly, several chunks are processed in parallel. Users thus receive their results quickly, as usual. The following figure illustrates the summarisation process once again.
A small change to the interface – a big step forward in the workflow
At first glance, the new feature consists merely of a few additional selection fields on the website. However, it makes a significant difference to the actual workflow.
This is a particularly important step for us when dealing with interview and conversation data containing personal or confidential information. After all, data protection should not be limited to a single processing step; what matters is the entire processing chain.
At the same time, this development illustrates very well how a tool that was initially relatively specialised can gradually evolve into a more comprehensive application. Mittweida Scripter began as a solution to a very specific problem: transcribing audio and video files as simply as possible and within our own infrastructure. Since then, features such as speaker identification, various output and language options, and now automated summarisation have been added. The original article on Mittweida Scripter once described this continuous development, in essence, as being like building with Lego – with every additional brick, new possibilities arise. To me, this comparison still holds true. After all, the new summarisation feature will certainly not be the last building block of Mittweida Scripter.
Conclusion
With the integration of a locally operated large language model, Mittweida Scripter is increasingly evolving from a pure transcription tool into a tool for much more comprehensive processing of audio and video content. However, the most important point for us here is not simply the use of generative AI. Rather, what is crucial is where and how this AI is used. If we wish to provide university staff with tools that enable them to use AI effectively, even with more sensitive data, we must create alternatives to a workflow in which content is transferred to an external service for every single processing step. With the new summarisation feature, we are attempting to take another step towards closing precisely this gap.
