No biometric template is created at any point in the process. Nothing to breach, subpoena, or regulate
Single still image captured per sensor detect. Not video. Not audio. Purged immediately for non-matches
If a sensor is stolen or compromised, there is no biometric data, match history, or PII to retrieve
Privacy by Architecture
Most facial recognition vendors promise privacy through policy. Safience delivers privacy through architecture. The system does not store biometric data because it was not built to store biometric data. There is no configuration to disable, no retention setting to forget, no database to breach. The privacy guarantee is structural.
What Happens at the Sensor
Understanding the privacy architecture requires understanding the data flow. Each step is designed to minimize data creation and maximize data destruction. The following is the complete lifecycle of a single detect event.
-
Sensor Capture
A fixed or portable RTIS sensor captures a single still image as a person enters the sensor’s field of view. One image per person per event. Not continuous video. Not streaming footage. A single frame, under 100KB.
Technical DetailData created: One JPEG image, sub-100KB. Data stored: Temporarily in sensor edge memory during processing.
-
Edge Comparison
The image is compared against UMbRA (law enforcement-sourced identities) and any operator-defined X-lists. This comparison happens at the edge, on the sensor’s processing unit. The image is not transmitted to a central server for comparison.
Technical DetailData created: Comparison result (match or non-match). Data stored: Comparison result held briefly during processing.
-
Non-Match (99%+ of all detects)
If no match is found, the image is purged immediately at the edge. No template is created. No record is kept. No log entry identifies the individual. The system has no memory that the person existed. This is the outcome for the overwhelming majority of all detects.
Technical DetailData created: None. Data stored: None. Image destroyed.
-
Potential Match
If a potential match is identified, the image and match data are transmitted to the Rapid Action Center (RAC) for human verification. A trained analyst reviews the match before any alert is generated.
Technical DetailData created: Match candidate record (image + reference comparison). Data stored: Held at RAC during verification window only.
-
Human Verification (RAC)
A RAC analyst reviews the potential match. If confirmed, an alert is generated and sent to designated venue security personnel. If rejected, the match candidate is discarded. No automated actions occur at any point. A human decides whether to alert.
Technical DetailData created: Verified alert (if confirmed) or discard record. Data stored: Alert record retained per venue's incident documentation policy; non-confirmed candidates discarded.
-
Alert Delivery
Confirmed alerts are delivered to venue security through the designated channel. The alert contains the information needed for the security team to act. Venue security personnel make all operational decisions.
Technical DetailData created: Alert notification. Data stored: Per venue security incident documentation requirements.
Architecture Comparison: What Gets Stored, What Gets Exposed
The privacy risk of any facial recognition system is determined by its architecture, not its policies. Compare what each architectural approach creates, stores, and exposes.
| Architectural Feature | Safience RTIS | Template-Storing FR (Generic) | Scraped-Database FR (e.g., Clearview) |
|---|---|---|---|
| Biometric templates stored | No. Never created. | Yes. Stored in local or cloud gallery. | Yes. 50B+ images with derived templates. |
| Video retained | No. Single still image per detect. | Yes. Continuous recording typical. | Varies. Source images scraped from public posts. |
| Data at rest on device | None. Purged immediately for non-matches. | Templates and match logs stored locally. | N/A (cloud-only service). |
| Breach exposure | Zero biometric data to exfiltrate. | Full template gallery and match history. | Entire scraped database (50B+ images). |
| BIPA applicability | No biometric identifier collected or stored. | Full BIPA compliance required: consent, retention schedule, destruction. | Full BIPA compliance required. Clearview has been sued and fined in multiple jurisdictions. |
| GDPR applicability | No special-category personal data retained. | DPIA required. Explicit consent required. Retention limits apply. | DPIA required. Multiple GDPR fines issued. |
| Mass surveillance capability | Architecturally impossible. No live view, no forensic rewind, no footage. | Possible with continuous recording and template gallery. | 1:N search across 50B+ images by design. |
| Data provenance | UMbRA: booking-verified, law enforcement-sourced. | Operator-enrolled templates. Provenance depends on enrollment process. | Scraped social media. No consent. No verification. No chain of custody. |
| Human verification before alert | Yes. RAC analyst reviews every match. | Varies. Many systems generate automated alerts. | N/A (search tool, not alerting system). |
If your vendor creates a biometric template, you have regulated data. If your vendor stores that template, you have a retention obligation. If your vendor is breached, you have a notification obligation. If your vendor's template appears in litigation, you have a discovery obligation. Safience creates no template. The obligations do not arise.
Request Architecture Documentation
Get the complete technical architecture documentation, data flow diagrams, and privacy impact assessment template. Available under NDA.