AI camera alerts that are wrong: who answers, and how much must a person check?

Suppose the camera in a condominium car park raises an alert about an unfamiliar person loitering. The guard, who hears it while walking the ground floor, phones a resident and demands that he identify himself. He turns out to be a genuine resident who moved in last week; the system had no record of him. Who is at fault: the camera, the vendor, the guard or the juristic person managing the building?

The AI-enabled CCTV guideline from Thailand's National Cyber Security Agency (NCSA) does not say who is liable at law. It offers a way of working that makes the answer findable: decide in advance who must check what before an AI result is used on matters that affect people.

This article reads clauses 3.3.5 to 3.3.7, 3.3.10 and 4.3.5 to 4.3.6 of that guideline alongside the Personal Data Protection Act B.E. 2562 (2019) (PDPA) and the PDPC's AI guideline. For face scanning and biometrics specifically, continue with face-scan cameras at work: how strong a reason do you need.

Neither Thai guideline has an English translation yet. The quotations below are the Thai originals, each followed by an explanation in English. The PDPA quotations use the unofficial English translation held in our law library.

In how many ways can an AI camera be wrong, and what happens to people?

Clause 3.3.5 lists four: a false alert (false positive), missing an event that should have been caught (false negative), misclassification, and misidentification of a person. Each hurts differently. The first gets an innocent person stopped; the second lets a real incident slip by.

An overall accuracy figure cannot tell you whether a system is safe. A system that is 99 per cent accurate (an invented figure) but wrong on the one per cent that matters may be more dangerous than a less accurate one whose every result is checked by a person first. The clause also asks you to look at the real environment, image quality, the groups of people involved and what happens when the system is wrong.

A wrong AI output is still personal data about that person

This is the author's view, which readers should check with their own lawyer. If a system produces an output that identifies a person, such as 'this person matches the watch list', that output is personal data the controller holds. Section 35 of the PDPA is then relevant: the controller shall ensure personal data remains accurate, up to date, complete and not misleading.

If a data subject asks for correction under Section 35 and the controller does not act, Section 36 requires the request and the reasons to be recorded in the Section 39 record. An organisation that uses a camera's identification results should therefore have a channel for disputes and a way to fix wrong results, not just leave the error in the system.

How much must a person check for oversight to count?

Enough that the person can do something about it, rather than merely sign off. Clauses 3.3.6 and 4.3.6 of the guideline agree that having a person check must come with the ability to correct or stop the AI's output.

Clause 3.3.6 lists five things an operator should be able to do. The list works as an immediate checklist for supervisors.

1. Understand what the AI result means and what its limits are.
2. Check supporting data or evidence before acting, when necessary.
3. Avoid believing the AI's result automatically.
4. Intervene, correct or suspend use of the result when something is abnormal.
5. Pass the matter up to someone with authority when the impact exceeds their own role.

Clause 4.3.6, on design, goes further and says that stating merely 'a person checks' is too crude.

The guideline asks six questions, according to risk: who checks, when, what they see, whether they can approve or reject, whether they can stop or limit the AI, and who they escalate to. If a head of security can answer all six without opening a manual, the procedure probably exists in practice.

This matches a familiar picture in software: one large 'Confirm' button, with the reject option hidden in a menu or no box for recording disagreement. If the user has no other choice, that person's review is a ritual.

The PDPC's AI guideline makes the same point from a personal-data angle and defines what a 'meaningful' human review requires. It sets three conditions.

That PDPC document is also a guideline, not a law. It helps show that the questions answered for service teams in when a customer asks for a person to review an AI decision apply equally to camera work. If a camera result affects employment or rights, also read AI in hiring and staff evaluation.

How much power does the AI's result have, and who must check it first?

Clause 3.1.4 ranks the authority of AI output in six levels: Inform, Alert, Recommend, Decision Support, Trigger and Automated Action. Clause 4.3.5 asks designers to state which level a result sits at and to add controls as the level rises.

For Trigger and Automated Action, clause 4.3.5 asks you to define seven things: the systems or actions the AI can trigger, the conditions before acting, the privileges used, the action boundary, human review or approval, how to suspend or stop it, and the evidence to record. The clause closes with one of the shortest and clearest rules in the document.

The table below is the author's own suggestion as a starting template. It is not a requirement of the guideline or of any law, and the incidents in the right-hand column are entirely hypothetical. Adjust it to your premises, your risks and the laws that apply to you.

The last row is the one the guideline worries about most. In clause 3.1.5 it explains that an AI error passed into an automated workflow or another system's API can spread beyond the camera system faster than a person can look. Clause 3.1.6 therefore asks for limited privileges, analysis separated from action, and a defined safe state when the system cannot be trusted.

Who is responsible when the AI decides wrongly?

The guideline answers as a matter of management, not of litigation: the organisation must name who is responsible for using AI in advance, and must not let AI make that person impossible to find.

In practice, responsibility becomes unidentifiable through three common gaps. The vendor says it configured the system as the customer asked. The guard says he followed the alert. The executive says it was handed to IT. When an incident happens, nobody owns the decision.

The author's suggestion for closing those gaps is to write job titles, not names, in a single document for four roles: who approves enabling an AI capability, who checks results before use, who has authority to suspend the system, and who receives disputes from affected people. Then make the vendor contract consistent with it: who can change default settings, and who is told when the model version changes. For processor agreements see the guide to data processor agreements.

Who must compensate an injured person, and how much, is a question for the facts and the relevant statutes case by case. The NCSA guideline does not decide it and neither does this article.

Do we have to tell people that AI is analysing them?

Clause 3.3.10 asks organisations to consider informing people about CCTV and AI at a level suited to the processing and to the requirements that apply. One point it stresses is that a camera sign is not, by itself, notice about AI.

Information the clause treats as suitable includes the purpose of the system, the type of AI processing, the kind of data, how results are used, the retention period and a contact channel for exercising rights. The ordinary camera sign described in CCTV in the workplace under the PDPA should therefore gain another layer when an AI capability is switched on, and a short one is enough: for example, that the system reads plates to open the barrier, how long results are kept (as the organisation decides) and whom to contact.

What should we do when the AI misfires or cannot be trusted?

Clause 3.8.4 asks you to decide in advance how to operate when the AI is unavailable or its results cannot be trusted. The guideline's picture is a stepwise fall-back: normal AI operation, then limited operation, then basic CCTV with human checking, down to a fail-safe state.

In operating terms, this means setting criteria in advance that let someone switch off the AI mode without waiting for approval through several layers, such as repeated false alerts in a row, or the vendor announcing a model update that has not yet been tested. How many repeats is the organisation's call; the guideline gives no number.

Clause 3.5.3 adds a warning: before adjusting a detection threshold to reduce false alerts, look at the cause and consequences first, or the fix may create a new risk, such as loosening the threshold until real incidents are missed.

1. When the system raises an alert
   The operator looks at supporting images and context, and does not decide from the alert text or confidence score alone.Clause 3.3.6
2. Before acting in a way that affects a person
   Someone with authority checks further evidence and decides, with the freedom to reject the AI's result without a long explanation.Clauses 4.3.6 and 6.2.6
3. When a result turns out wrong
   Correct or suspend the result, record the event and reasons, and tell the affected person if the result was already used on them.Clause 6.2.6 and PDPA Section 35
4. When errors repeat or form a pattern
   Suspend AI mode temporarily, fall back to basic cameras with human checking, and find the cause before changing thresholds.Clauses 3.8.4 and 3.5.3
5. At every review cycle
   Look at how often the AI was wrong, how often people overrode it, and whether anyone confirmed without checking; then adjust training and screen design.Clause 3.11.3

Clause 3.11.3 covers training and states its purpose plainly: to reduce the risk of trusting automated results too much.

An organisation with several brands of AI camera across branches can record which one has which capability, who owns it and at what authority level it is approved in the AI registry in AIPDPA. A first risk score is available on the public AI risk check before you buy or enable a new feature.

Who stands behind this guide?

Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel

Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)