Once the sovereignty question was settled, keeping employee voice recordings entirely in-house, a second problem showed up on the same automated meeting summary project. In a properly equipped meeting room, every microphone gets mixed into a single audio stream. The transcription produces text just fine, but without knowing who said which sentence. And a meeting summary is only useful if every statement is attributed to the right person.

The obvious temptation is to solve this with more AI: a voice recognition model, trained on a sample of each employee’s voice, then able to recognize who is speaking. Technically, that works. But it shifts the problem instead of solving it.

Three approaches compared

Create a voice fingerprint per employee. On paper, the most accurate solution. But it turns a simple meeting into biometric data collection under GDPR: a sensitive data category that requires its own legal basis, its own registration, its own security measures. The original project aimed to automate a meeting summary, not open a biometric compliance workstream.

Ask every participant to state their name at the start of the meeting. The simplest solution to implement, with no additional processing at all. The problem is human: it works in the first meeting, because everyone remembers to do it. It stops working by the tenth, once the habit fades.

Use the information the video conferencing tool already knows. Most enterprise meeting tools already know, internally, who activated their microphone and when, if only to visually highlight the active speaker on screen. That information already exists, with no biometric model to build, train, or store.

What was chosen

The third option was chosen. The gain is not only technical, it is also legal: no new sensitive data category appears in the processing. Diarization, identifying who spoke when, happens by correlating with metadata the tool already produces, not through a new AI layer analyzing the voice itself.

The general lesson

Before asking which AI model would best solve an identification problem, the better question is often: what information already exists in the system, without needing to create a new sensitive category? Adding a model is sometimes the most visible solution, rarely the leanest one. In a context where personal data protection is an explicit decision criterion, restraint in processing matters as much as accuracy.

GDPRArtificial intelligenceMeetings.NET

Take it further

For mid-caps and software vendors whose IT lives in .NET and SQL Server: AI developed inside your application (document extraction, agents, classification) with your business rules, your architecture, your code. Not another tool next to the IT system: a new capability inside it. I work in your repo, alongside your developers, to your team's standards.

Let's talk about your IT system →