trust & responsible use
Built for lawful, consented biometric use.
Face recognition is powerful and sensitive. SightRadar is designed for teams who process biometric data with consent and a lawful basis — and our product, data handling, and Terms are built around that, not bolted on.
Consent is your responsibility — and we make it the default
You are the controller of the faces you index; we are the processor. Our Terms require that you have a lawful basis and the consent needed to process the biometric data you send. We build for that workflow, not around it.
We never train on your data
Your images and faceprints are used only to serve your own API calls. They are never used to train, fine-tune, or improve any model — yours or anyone else's.
Tenant isolation
Every collection is scoped to your account. Searches only ever match within your own collections; one customer can never see, search, or reach another customer's faces.
Deletion on request
Delete a collection and its faceprints are removed. We support data-subject deletion and export requests so you can honour GDPR Article 15/17 and BIPA obligations to the people in your data.
Plain, purpose-written legal terms
Our Terms and Privacy Policy are written specifically for a biometric processor — controller/processor split, biometric-consent obligations, prohibited uses — not generic SaaS boilerplate.
Prohibited uses, enforced
Mass or covert surveillance, tracking people without consent, and any unlawful use are prohibited by our Terms. This isn't a marketing line — it's a condition of using the API.
Who owns which obligation
You are the controller, we are the processor. That split decides who has to do what, so here it is spelled out rather than implied. The binding version is in the Data Processing Addendum.
| Topic | You (controller) | SightRadar (processor) |
|---|---|---|
| Lawful basis & consent | Obtain and record the lawful basis and, where required, explicit biometric consent from every person whose face you index. | Require it contractually, and build the product so consented workflows are the natural path (per-event collections, one-call deletion). |
| Role under GDPR | Data controller. You decide why faces are processed and for how long. | Data processor. We process only to serve your API calls, on your instructions. |
| Data-subject requests (access / erasure) | Receive the request, verify the person, and decide what to action. | Provide the API to execute it — delete every face indexed from a photo, or an entire collection — and support export so you can answer within your deadline. |
| Retention | Set it, tell the people involved, and enforce it by deleting when it expires. | Store embeddings until you delete them. We do not impose a retention period. By default, collection and photo-face deletes keep the data recoverable for a 7-day grace window; after that window, or after an immediate/compliance erasure, no copy is kept. |
| BIPA-style written release | Collect the written release and publish your retention/destruction schedule where the statute requires it. | Never use the biometric data for our own purposes, never sell it, and never train models on it. |
| Breach notification | Notify your regulator and data subjects on your own timeline. | Notify you without undue delay so your clock can start. Terms in the DPA. |
How deletion actually works
“Deletion on request” is a promise until you can see the shapes it takes. Each of these is an API call you make yourself — you do not open a ticket and wait for us. Note the distinction that matters for a data-subject request: routine deletes are recoverable on purpose, permanent erasure is a deliberate separate mode, and erasure runs asynchronously — so confirm it finished before you close the ticket.
Delete one photo's faces (recoverable by default)
Remove every face indexed from a specific photo — the usual shape of “take this picture down”, where the image is coming out of your storage anyway. This is the finest-grained delete available: the unit is the photo, not an individual faceprint within it. Like a collection delete it is recoverable by default, with a restore path during the grace window.
Delete the whole collection (recoverable by default)
One call ends an event, a term or a shift. By default this is a SOFT delete: the collection is hidden immediately and kept for a 7-day grace window, so an accidental deletion is recoverable. Storage still bills during the grace window because the vectors still exist.
Permanent erasure, for a verified request
When you are answering a GDPR Article 17 or BIPA destruction request, use the immediate mode to skip the grace window and START an irreversible purge, or compliance mode to start the audited, non-restorable workflow. Both are asynchronous: the call returns 202 with a workflow id and the vectors are removed after it. To record a completed erasure, poll GET /v1/collections/{id}/deletion until it reports phase “completed” with verified_zero true — that, not the 202, is the evidence the vectors are gone. Do not use the recoverable default mode for a verified request.
What we never held in the first place
Detect and Compare process images in memory and do not persist them, so there is nothing to delete from those operations. Index stores the embedding, not your original photo — you keep the images in your own storage.
The endpoints are in the API reference, and the retention commitments are in the Privacy Policy.
What we don't do
Being clear about the lines we won't cross is part of being trustworthy.
- We don't sell or share your data, and we don't build a cross-customer face database.
- We don't support covert surveillance, or identifying people without their consent.
- We don't train models on your images or faceprints.
- We don't publish made-up accuracy benchmarks or fake customer metrics — when we show numbers, they're measured and reproducible.
Read the details
This page summarizes our posture. The binding specifics live in our legal documents.