Facial Recognition & Biometrics Policy

What we do not do

The following are not capabilities of the Watchful Platform, Quill AI, or any associated service. They are not enabled for any Subscriber and cannot be enabled by configuration:

• Facial recognition or facial identification — no faceprints, face embeddings, face templates, or face-matching against any database (internal, customer-supplied, or public).
• Voice recognition or speaker identification — no voiceprints or speaker embeddings.
• Gait recognition or gait-based identification — no gait signatures, stride embeddings, or movement-pattern biometrics.
• Iris, retina, or eye-vein recognition.
• Fingerprint or palm-print recognition.
• Re-identification of an individual across separate Subscribers' camera networks. This is architecturally prevented, not just policy-prevented.
• Persistent profiles of members of the public — no PII (names, identification numbers, addresses) is stored about people detected on CCTV.
• Sale, disclosure, or sharing of biometric data to any third party — we cannot sell what we do not collect.

What our AI actually does

Watchful's models classify events and objects, not people. The output of our perception stack is a structured event such as “person detected in restricted area at 02:14 AM” — not “this is John Smith”.

Demographic descriptors in confirmed-incident reports

Watchful's models can produce coarse demographic descriptors — estimates of age range, gender presentation, or ethnicity visible in a scene. We use these descriptors in one narrow circumstance, and one only:

• Only for confirmed incidents. Demographic descriptors are generated only after a security event has been confirmed by an operator and the incident meets the threshold for an investigation report (for example, a verified intrusion, assault, theft, or other reportable event).
• Only to compile the investigation report. The descriptors are included in the incident report so that responders, the Subscriber, and law enforcement can describe and locate the individuals involved (e.g., "two adults, one wearing a red jacket"). They are not produced for routine monitoring, analytics, marketing, or model training.
• Not biometric identifiers. These are scene-relative, perceptual descriptors — the same kind of information a human operator would write in a witness statement. They are not faceprints, voiceprints, gait signatures, or any other unique biometric template, and they cannot be used to match an individual against a database.
• Tenant-bounded and incident-bounded. Descriptors live in the incident report for that Subscriber only, follow the retention schedule that applies to incident reports, and are never used to track individuals across Subscribers or build demographic profiles.

Subscribers may opt out of demographic descriptors in incident reports by request. Operators are trained to apply this capability only when it materially helps respond to or document a confirmed incident.

Incident-scoped tracking is not biometric tracking

During a live security incident, the Platform may help an operator follow the same person or vehicle across cameras owned by the same Subscriber so they can coordinate an effective response. This is not facial recognition and not biometric processing. It is:

• scene-relative. The system uses appearance cues within the moment (clothing colour, vehicle silhouette, position) — not a stored template of any specific person or vehicle.
• incident-bounded. The track exists only for the duration of the active incident and is not retained, indexed, or replayable as an identity record.
• tenant-bounded. The track cannot extend beyond the Subscriber's own cameras. Cross-Subscriber tracking is architecturally blocked at the data layer.
• not an identity claim. The system does not assert who the person is — only that the same shape was at camera A and then at camera B during the same incident.

Architectural guarantees

Promises in policy are only as good as the architecture under them. The following technical controls make biometric processing not just forbidden but infeasible:

• No biometric encoders. Our production model stack does not contain facial-recognition, voice-recognition, or gait models. None are deployed, none are loaded on inference servers.
• Per-Subscriber isolation. Subscriber video, audio, and analytics live in logically isolated tenant boundaries. Models cannot cross those boundaries to learn or match against another Subscriber's data.
• No biometric training data. Watchful does not train models on biometric datasets, face datasets, or identified persons. Subscriber footage used for model improvement is consented, scoped, and used only to improve event/object detection.
• Output schema does not allow identity. The event schema produced by our perception layer does not contain a personal-identifier field. There is no “identity” column to populate.
• Audit logs. Model deployments, dataset usage, and schema changes are logged and reviewed under our SOC 2 controls, so any attempt to introduce biometric capability would be visible.

Regulatory alignment

By not collecting biometric identifiers in the first place, Watchful stays clear of the obligations that apply to biometric processors under the world's strictest regimes. The list below is illustrative, not exhaustive:

• Illinois BIPA — we do not collect, capture, or otherwise obtain “biometric identifiers” or “biometric information” as defined by the Act.
• Texas CUBI (Bus. & Com. Code §503.001) — we do not capture biometric identifiers for a commercial purpose.
• Washington RCW 19.375 — we do not enroll biometric identifiers in a database for a commercial purpose.
• NZ Privacy Act 2020 & Biometric Processing Code — we do not undertake biometric processing as defined by the Privacy Commissioner's biometric guidance, and have no obligation to seek authorization for it.
• Australian Privacy Act 1988 (Cth) — we do not collect biometric information or biometric templates, which are sensitive information under APP 3.
• EU/UK GDPR Article 9 — we do not process special categories of personal data (biometric data for the purpose of uniquely identifying a natural person).

If a future law or Subscriber requirement introduces a use case that would change this position, we will publish an update to this policy and notify affected Subscribers in advance.

Verifying our commitment

We are happy to support security and procurement teams who need to verify these claims. Available on request:

• an architectural overview of the perception stack and tenant isolation model;
• a model inventory describing the classes our detectors output;
• a Data Protection Impact Assessment (DPIA) summary covering our AI processing;
• confirmation, on Watchful letterhead, that no facial recognition or biometric identification capability is deployed; and
• access to relevant SOC 2 controls and evidence through our trust portal.

Open a biometric verification request and we will respond within five business days.

Reporting a concern

If you believe Watchful or a Subscriber using the Platform is performing biometric processing in breach of this policy, please report it to our security team immediately. We treat reports of biometric misuse as a Sev-1 incident and will investigate within 24 hours.

Contact Us

Questions, requests, or concerns about this policy? Pick the right channel and we'll route your message to the team responsible.