When a licence plate reader gets it wrong, who has to prove what it saw?

What happened in Toledo

On an ordinary day, Brandon Upchurch was driving in Toledo, Ohio, when police pulled him over at gunpoint ^[1]. Officers said an automated licence plate reader had flagged his vehicle as stolen. Upchurch's car had not been reported stolen, and he says the plate shown on the officer's screen was not his ^[1].

The system in question, made by Flock Safety, uses cameras and recognition software to read plates and check them against police databases ^[1]. It is one of many such systems used across the United States.

Like a smoke alarm that goes off when someone burns toast, an automated plate reader gives a signal, not a certainty. The question is what happens next, and who has to prove what the system actually saw.

The evidence gap

When an AI system gets something wrong, the natural question is: what exactly did it detect, and how did it arrive at that conclusion? In this case, Upchurch says the plate on the officer's screen did not match his vehicle ^[1]. If that is true, it matters whether the reader misread the plate, the database had the wrong information, or something else went wrong along the way.

The problem is that the driver and the police may not have the same record. The driver has what he can remember and perhaps a photo from the scene. The police have what the system showed them at the time. Flock Safety and the department have access to the logs. In a dispute, the question is who keeps the checkable record of what the system detected, and whether anyone outside the organisation that runs it can verify that the record has not been edited.

What the law expects

In the EU, the AI Act does not yet apply to such systems in US jurisdictions, but it sets out a framework that is worth looking at. Under Article 12, high-risk AI systems must technically allow for the automatic recording of events over their lifetime ^[2]. The idea is that if a system makes a decision that affects someone, there should be a log of what it did.

Article 12 says what to log. It does not say how to protect the logs once they exist. That is the gap.

For police use, some jurisdictions already have rules about body camera footage and dispatch records, but automated recognition systems are newer, and the rules have not always caught up ^[3].

Who should keep the receipt?

When a shop till prints a receipt, the customer gets a copy and the shop keeps one. Both sides have a record of the transaction. When an AI system flags a vehicle and that leads to a stop, it would be reasonable to ask: who gets the receipt, and can it be checked?

At the moment, the answer often is that the organisation running the system keeps the log, and the person affected has to trust that it has not been changed. That works until it does not.

What a digital witness does here

The thing to seal in a case like this is the detection event itself: the plate as read by the system, the database match, the timestamp and the location. Sealing means taking a fingerprint of that record when it is created and storing the fingerprint on WitniumChain, where any later change would show ^[4].

The sealed record stays with the police or the contractor. The fingerprint goes on a chain where even we cannot quietly rewrite it. When the record is questioned, anyone the police share it with can calculate the fingerprint again and check whether it matches the sealed one. Change a single character in the record and the fingerprints will not match.

What it shows is that the record of what the system detected at that moment has not been edited since. It does not show that the detection was correct, that the database was accurate, or that the stop was justified. Those are separate questions. What it does is let both sides agree on what the system actually said, without having to take anyone's word for it.

How it would work

1. The plate reader writes the detection record (plate, match result, time, location) to its log.
2. A fingerprint of that record is sealed immediately.
3. If the detection is disputed, the record is shared and anyone can check that the fingerprint still matches.

What it does not do is make the system more accurate, replace oversight or decide whether the stop was lawful.

What this means for you

If you run automated recognition systems, or you are building AI that makes decisions people might later question, here are a few things to ask now:

• When your system flags something, who keeps the record of exactly what it detected, and can that record be checked by someone outside your organisation?
• If a decision leads to action (a stop, a rejection, an alert), could you show six months later what the system actually said?
• When something goes wrong, do you have your own evidence, or only the logs you can edit?

For police and public bodies using such systems, the same questions apply. The person affected may turn up with their own account, a photo or a lawyer. It helps to have a record you can prove has not changed.

What to watch

The EU AI Act's high-risk requirements for law enforcement AI come into force on 2 August 2026 ^[5]. Among other things, that means systems used by police for biometric identification, risk assessment and evidence analysis will need to meet the logging and oversight requirements in Articles 9 to 15. Protecting those logs so they hold up under scrutiny is not required by the Act, but it is a good idea.

In the United States, there is no federal AI Act yet, but some states are starting to require that automated systems used in criminal justice be auditable and that their decisions be explainable ^[3]. Logs are part of that, and the question of who can check them is likely to come up more often.