Your Robot Cannot Get a Signature From the Sidewalk
Autonomous delivery puts cameras on public streets at eye level, all day, past people who never ordered anything. Illinois biometric law asks for written consent before collection — so the only workable answer is an architecture that never needs it.
Why Robotics Is a Worse Fit Than Any Fixed Camera
Biometric claims against fixed installations — retail loss prevention, time clocks, security analytics — share a helpful property: the camera is somewhere, and the people in front of it have a relationship with that place. Employees can be given a written release. Customers walk through a door you control and past a notice you posted.
A delivery robot has none of that. It moves through public space on a route nobody consented to, at a height chosen for navigation that happens to be perfect for faces, encountering hundreds of uninvolved people per shift. There is no doorway, no notice position, no employment relationship, and no moment at which a passer-by could sign anything even if they wanted to.
Under a statute with a private right of action and damages assessed per violation, the arithmetic of that exposure is unlike anything a fixed installation faces. The population in front of the camera is not your customer base; it is everyone outdoors. That is the structural fact every design decision below is trying to defuse.
Feature by Feature: Where the Line Actually Falls
- Obstacle detection and path planning. Lowest risk. Bounding boxes, depth estimation and trajectory prediction on a person-shaped object do not derive facial geometry. Keep it that way and document that it is so — a diagram of the perception stack is the artifact that answers this question.
- Recipient verification at handoff. Highest risk, and the one product managers ask for. "Confirm the right person collected the package" via face match against an enrolment photo is exactly the conduct the statute contemplates. If you do it, do it with a real section 15(b) release from the recipient at signup, a published retention and destruction schedule, and a non-biometric alternative that does not degrade the service.
- Doorstep and proof-of-delivery imagery. Ambiguous, and it depends entirely on what happens downstream. A stored photograph is a photograph. A photo that a later pipeline clusters by face to group deliveries, detect theft, or build a recipient profile has become something else, and the team that wrote that downstream job is usually not the team that answered the compliance questionnaire.
- Theft and vandalism response. The feature most likely to be added under pressure after an incident. Identifying the person who tipped a robot over is precisely a face-matching use case against a population that gave no consent. If you need evidence, retain footage for law enforcement rather than running identification yourself.
- Fleet telemetry used for model training. Sidewalk video is valuable training data, and face datasets assembled without consent have produced some of the largest biometric settlements on record. Whether faces are blurred before the data leaves the vehicle is a decision worth making at board level.
- Teleoperation feeds. A remote operator watching a live camera is not collecting a biometric identifier, but the session recording is imagery of uninvolved people held by you, and it flows into the same retention and state-surveillance questions as everything else.
The Controls That Do the Work
Compliance here is engineering, not paperwork. Four decisions carry nearly all of the risk reduction, and each one is verifiable by someone reading the code rather than the policy.
- Blur or discard at the sensor boundary. Face redaction applied on the vehicle, before any frame is stored or transmitted, with the unredacted buffer never written to disk. Everything downstream inherits the protection automatically.
- A hard architectural separation between navigation and identity. Navigation models should be physically incapable of emitting an embedding usable for matching. Separate services, separate storage, no shared feature store.
- Enrolment-scoped matching only. If face verification exists, it compares against the single enrolled recipient for that delivery — never a gallery, never a search. A one-to-one comparison against a consenting customer is a categorically different risk from one-to-many identification.
- A retention schedule that is actually implemented. The statute requires a written policy with destruction deadlines, made publicly available. Write it, publish it, and then confirm the deletion job runs — an unexecuted policy is worse than none, because it documents the standard you failed to meet.
Add one governance control to those four: a review gate on any change that touches the perception pipeline. The recurring failure mode in this industry is not a deliberate decision to identify bystanders. It is a well-intentioned feature — dedupe these delivery photos, flag repeat package thieves — shipped by a team that did not know it had just crossed a statutory line.
Beyond Illinois
Illinois is the state with the private right of action, which is why it drives design. It is not the only constraint: Texas and Washington have biometric statutes enforced by their attorneys general, Colorado added biometric consent duties, and a growing set of comprehensive privacy laws treat biometric data as sensitive and require opt-in consent for its processing. Our state-by-state biometric map covers the rest. For a fleet that crosses municipal lines by design, the only sane posture is to build to the strictest rule and deploy one configuration everywhere.
Frequently Asked Questions
Our robots operate under a municipal sidewalk permit. Does that authorisation help?
It addresses a different question. A permit governs whether your device may occupy the right of way — speed, weight, yielding to pedestrians, insurance, hours of operation. It is not a licence to process biometric data and it does not supply consent from anyone. Municipal permitting conditions are worth reading closely for a separate reason: several sidewalk robot ordinances impose their own data collection and retention limits, and those conditions can be stricter than state privacy law.
We license the perception stack from a vendor and do not know what it computes. Where does that leave us?
In a poor position that is fixable with one question and one clause. Ask the vendor, in writing, whether any model in the pipeline produces a facial embedding or template, and whether any such value is persisted or transmitted. Then put the answer in the contract with a change-notification obligation, because a silent model update is how this becomes a surprise. Possession of biometric identifiers creates duties for the party possessing them; not knowing what your own vehicles compute is not a defence, and it is the kind of fact that reads badly in a deposition.
What about the robot's interior camera for the cargo compartment?
Generally the lowest-risk sensor on the vehicle, because it points at packages. It matters if the compartment camera captures the customer's face while they reach in, and if that image joins the delivery record. Point it at the goods, crop the aperture out of frame, and the question disappears. This is a good example of a risk that a five-minute conversation at design time removes permanently and that no policy document can remove later.
Can we rely on blurring faces after upload rather than on the vehicle?
It is better than nothing and materially weaker than redaction at the sensor. Post-upload blurring means unredacted imagery existed in your infrastructure, was transmitted over a network, and sat in whatever storage the ingest pipeline uses — including backups, logs, and any queue that buffered it. Each of those is a location a plaintiff will ask about and a breach could expose. If the blurring happens before the frame is written, none of those locations ever held the original.
Is there a realistic non-biometric way to verify the right person got the package?
Several, and they are what most operators actually ship. A one-time code sent to the customer and entered on the robot's keypad, a QR code in the app scanned at the hatch, a Bluetooth proximity handshake with the customer's phone, or simply unlocking the compartment from the app. Each verifies possession of an authenticated account, which is what you actually care about — face matching verifies a body, which is both more legally fraught and a weaker signal about authorisation than the phone the order was placed on.
One Diagram Answers Most of This
Draw the perception pipeline from sensor to storage and mark every point where a face could become a template. In most fleets the honest answer is that no such point exists — and the document proving it is worth more than any policy you could write, because it converts a contested legal question into a factual one you win.
Where a point does exist, it will be a recipient verification feature or a downstream analytics job. Those are the two places to spend your attention, your consent flow, and your retention engineering. Everything else on the robot is a camera doing arithmetic about obstacles.