- Home
- Mokuji
- Trust center
- AI and biometrics
Governing a system that recognizes people.
Intended and prohibited use, accuracy and its limits, human oversight, how your media is never used for training, the EU AI Act position, and what your DPIA needs from us.
Last updated
Mokuji recognizes faces and voices. That puts it in the category of system most likely to be stopped by an AI governance review, and the category where most vendors have nothing to hand over. This page is what we would want to receive if we were the ones assessing it.
None of it is legal advice. Your obligations depend on your jurisdiction, your purpose and your footage. We can only tell you accurately what the system does, which is the part your counsel will ask us for anyway.
What it is for, and what it is not for.
Retrospective search of footage you already hold.
- ▸Finding material in an archive you own and have the right to process
- ▸Attributing dialogue to a speaker for editorial or compliance work
- ▸Locating every appearance of a person who has been deliberately enrolled
- ▸Producing selects, pull-lists and timecoded references for a human to act on
Anything that acts on a person automatically.
- ↗Real-time identification of people in a live feed
- ↗Identifying strangers against a database you did not build by enrollment
- ↗Inferring emotion, intent or character, or sorting people by estimated age or sex
- ↗Automated decisions about a person with legal or similarly significant effect
Mokuji suggests; people decide. It never acts on a result by itself.
Where the recognition comes from.
Your data and the models
- Training on your media
- Never. In the standard install your footage stays on your hardware and never reaches us. If you turn on cloud processing for a catalog, frames and audio go, encrypted, to a GPU worker you approved and are deleted when each job ends: never to us, never for training.
- Reference databases
- None supplied. Face and voice recognition only match people somebody in your organization enrolled; there is no population to match a stranger against. Descriptions, transcripts and on-screen text can still contain a name that was said, shown or widely known.
- Enrollment
- Explicit and attributable. A person is named because a named user enrolled them, and that act is in the audit log. Once someone is enrolled, the system can add further voice samples to their profile as it finds them.
- Estimated attributes
- The system estimates apparent age and sex for each detected face. The estimates help a reviewer tell unnamed faces apart and are not offered as a search filter. A person's profile can also carry a gender your team enters, so scene descriptions can name them rather than say “a man” or “a woman”. Descriptions of people who are not enrolled can say “a man” or “a woman”, and descriptions are searchable as text.
- Human oversight
- Required by design rather than recommended. Output is ranked results, each with a match score and a breakdown of why it matched; the interface is built to make correcting them easy, and corrections persist.
- Model updates
- Arrive with releases you choose to apply. Nothing changes until you apply a release.
- Explainability
- Each search result can show why it matched (the description, the transcript line, the enrolled face) so a reviewer can see the basis rather than being asked to trust a score.
Good enough to be useful. Not good enough to be unsupervised.
Any vendor quoting you a single accuracy figure is quoting it against their own benchmark, on footage that is not yours. The number that matters is the one measured on your material.
What we will do
Measure it on a slice of your own archive during evaluation and show you the result, including where it does badly.
Where it degrades
Poor lighting, heavy motion blur, small faces in wide shots, overlapping speech, heavy accents and low-bitrate source. These are real limits, not edge cases.
Demographic performance
Face recognition accuracy is known to vary across demographic groups. We have not independently audited ours, and we will not claim otherwise. If that is a gate, raise it. It is a fair one.
Where this is likely to land.
Written to help your counsel start, not to replace them.
The regimes that come up
- EU AI Act
- Post-remote biometric identification is treated as high-risk under Annex III. Deploying it brings obligations around risk management, logging, human oversight and transparency, most of which fall on you as the deployer. We will supply the technical documentation that supports them; the architecture diagrams and hardening guide are still in preparation, as the trust center says. The age and sex estimates described above are also worth putting to counsel under the Act's provisions on biometric categorization. Confirm the classification for your specific use with counsel; it turns on purpose, not on the software.
- GDPR Article 9
- Face embeddings and voiceprints used to identify someone are special-category biometric data. You need a lawful basis and an Article 9 condition. Self-hosting does not provide either. It only keeps the data under your control while you satisfy them.
- GDPR Article 35
- Large-scale processing of special-category data triggers a mandatory DPIA. Yours, not ours. See below.
- BIPA and similar state law
- Illinois requires written notice, a written release before collection, and a published retention and destruction schedule. The system gives you the deletion mechanics; the notice, the consent and the published schedule are yours to produce.
- Sector rules
- Defense, law enforcement and education each add their own. Tell us which you are under and we will tell you what we can evidence and what we cannot.
We write the half that is ours.
A data protection impact assessment is almost certainly mandatory for you here, and it is yours to produce, but a good half of it is a description of what the system does, which is a question only we can answer properly.
The support pack covers the processing description, data categories and sources, the retention and deletion mechanics, the Article 32 measures, our support-access model, and the residual risks we think are real. It is written to drop into your template rather than to sit beside it, and it ends with a list of what remains yours, because that part depends on your purpose rather than on the software.
What the pack contains
- Processing description and purpose
- Data categories, sources and derivation
- Recipients: none outside your organization in the standard install, and the cloud GPU provider you choose if you turn on cloud processing
- Retention and deletion mechanics
- Technical and organizational measures (Article 32)
- Residual risks, stated plainly
- A list of what remains yours to complete, including necessity and proportionality
Bring your AI governance reviewer.
This is the gate most likely to stall a biometric system, and the one where we would rather be early. Send the framework you assess against and we will answer it directly.