Biometric and Facial Data Statement
Why Mochi creates no face template, runs no recognition, and keeps no photograph.
Not yet reviewed by a lawyer
The position, stated plainly
- No facial recognition is performed, at any point, by anyone.
- No biometric identifier and no face template is created, compared or stored.
- Nothing in the pipeline derives a representation capable of matching one person to another.
- The source photograph is deleted from our systems immediately after your pet is generated. It is held in memory for the length of one request and is never written to disk.
- The image provider has not been selected yet, so no retention or training commitment from one is in force. Not retaining and not training on submitted images is a requirement any provider has to meet before it is used, and this page will name the provider and the commitment once one is chosen. Until then, treat the photograph as leaving our control when it reaches the model.
Why it is built this way and not just promised this way
Illinois BIPA attaches to the collection of a biometric identifier, not only to storing one, so deleting something afterwards is not a defence. A photograph on its own is excluded from that statute. The defensible position is therefore a pipeline that turns a photograph into a drawing without ever computing a face embedding, and that is what is built.
The practical consequence: Mochi cannot tell you whether two photos are of the same person, cannot search for a face, and cannot recognise you in an image. Those are not features that were left out. They are capabilities the design refuses to have.
Voices are different, and are handled separately
Speaker separation in meeting mode does build a voice profile so the same person can be recognised across meetings. Those profiles are stored on your Mac only, are never uploaded, are listed by name in settings, and can be deleted one at a time. Some jurisdictions treat a voiceprint as biometric data, which is exactly why it never leaves the device.
What is processed, and where
| Item | Where it is processed | Retention |
|---|---|---|
| Uploaded photograph | First-party proxy, then a hosted image model | Deleted from our systems immediately after generation. The model provider's own retention is not settled, because no provider has been selected. |
| Generated pet artwork | Your Mac | Until you delete the pet |
| Voice profile | Your Mac | Until you delete it |
| Face template | Never created | Not applicable |
Placeholder, pending legal review
The statements above describe the intended architecture and are written to be verifiable against it. They have not been reviewed by a lawyer, and this page is the one most likely to be read adversarially.
Before launch: select an image provider and get its no-retention and no-training position in writing, then name it here and on the subprocessors page. One thing already known about the intended route: the image endpoint takes no per-request retention flag, and unrecognised request fields are dropped without an error, so sending one proves nothing. Any commitment has to be configured at the account level and confirmed by the vendor, not asserted per call. Also have the pipeline audited to confirm no embedding is derived at any stage, and have counsel check the wording against Illinois BIPA, the Texas CUBI act, and the special category rules under the GDPR and UK GDPR.
Who you are dealing with
Mochi is published by Nuits, a Finnish toiminimi (sole trader).
The registered business address and business ID are withheld for privacy and are available on request. Write tohi@brandnuits.com and you will get them.
All legal and support enquiries go to the same address:hi@brandnuits.com.