The feature we refused to build

The goal

Politikkradar publishes what happens in municipal council meetings: who spoke, what they said, how votes fell. The source material is long meeting videos. Turning video into a usable public record means solving who-said-what: aligning a transcript with the person actually speaking at each moment.

The tempting shortcut

Council members are public figures with published photos. Matching faces in the video against those photos would identify speakers with high confidence and little engineering effort, and most of the surrounding pipeline existed already. It is the kind of feature that ships in a weekend and feels obviously fine, because everything involved is already public.

Why we refused

GDPR Article 9 treats biometric data processed for the purpose of uniquely identifying a person as a special category, prohibited unless a narrow exception applies. Face recognition against a reference gallery is exactly that processing, and none of the exceptions comfortably fit a private company enriching public video for a commercial product. That the people involved are elected officials does not remove the protection: a public role does not make biometric processing proportionate. There is also a plainer objection. A monitoring product that normalizes running face recognition over public officials is building exactly the kind of infrastructure a healthy public sphere should be wary of.

What shipped instead

The compliant pipeline separates two questions that face recognition collapses into one: is a visible person speaking right now, and who is that person. Active-speaker detection answers the first from face and lip movement, without ever comparing a face to a reference photo. The second is answered by signals the meeting itself provides. The broadcast shows a name banner when someone takes the floor, and the pipeline reads it as on-screen text, not as a face. The chair announces speakers out loud, so the handoffs are right there in the transcript. Every name proposed by any of these signals is validated against the council's published member roster before it is accepted. Within a single meeting, anonymous voice and face clustering then carries a confirmed name through the rest of that person's turns. The clusters are per-meeting labels: no biometric template is stored, and no identity database exists to match against.

Every attribution carries its evidence and a confidence status. Only the strongest statuses are allowed onto published pages; anything weaker is held for human review. Quality is measured against hand-checked meetings and a hand-transcribed gold set, not assumed.

The same line, applied to voice

Faces are not the only biometric shortcut in this problem. A stored voice profile per council member, remembered across meetings, would raise attribution quality more than any other single feature; recognizing a voice you already know is exactly how a person in the room does it. It is also the same Article 9 processing with a different sensor, so the same line applies: the pipeline stores no voice embeddings, and a voice cluster from one meeting is never matched against another. The difference is that here a lawful path exists, namely explicit consent from the council members themselves. The enrollment code is written and sits behind a flag that is off by default, and even with consent in hand, a cross-meeting voice match will only ever surface as a suggestion to a human reviewer, never as a published attribution. Consent can make the processing lawful; it does not make automatic publication wise.

The cost, honestly

The compliant design was slower to build, has more moving parts, and required its own evaluation work. That is the real shape of privacy by design: sometimes the answer is a different architecture, not a consent banner. The alternative was a feature we would have had to defend to users, to a regulator, and to ourselves.

This note describes one lab's reasoning. It is not legal advice.