Face-scan cameras at work: how strong a reason do you need?

A retailer installs cameras to stop stock going missing. Later the vendor suggests switching on face recognition as well, so the shop can spot regulars, flag people with a record and see what time each employee arrives. Many organisations say yes at this point without asking when the old camera was ever allowed to do this new thing.

The AI-enabled CCTV guideline from Thailand's National Cyber Security Agency (NCSA) answers that in clause 3.3.1. A camera installed for one purpose should not be assumed to permit every kind of AI use of the footage.

This article reads clauses 3.3.1 to 3.3.4 of that guideline together with Section 26 of the Personal Data Protection Act B.E. 2562 (2019) (PDPA). It ends with a table of which jobs can plausibly justify a face scan and which have lighter alternatives. Signage, footage retention and police requests are covered in CCTV in the workplace under the PDPA and are not repeated here.

The NCSA guideline exists only in Thai so far. The quotations below are the Thai original, and each is explained in English right after it. The PDPA quotations are in the unofficial English translation held in our law library.

Can we switch on face recognition on a camera we installed for security?

Not on the strength of the security purpose alone. Clause 3.3.1 treats installing a camera and enabling an AI capability as two decisions, each needing its own purpose and necessity.

That is the situation many buyers are in. The camera was bought because of theft, yet the software has a recognition mode a click away. Clause 3.3.1 says that click needs a justification of its own, separate from the one used to put the camera up.

The guideline does not ban facial recognition. It sets five questions an organisation should be able to answer before enabling it.

1. What is the AI used for?
2. What data does it need?
3. What data or results does it create?
4. Who uses the results?
5. What do they do with them?

Try the five questions on staff time-keeping. The AI confirms who arrived and when. It needs employee face images and a face template. The result is a clock-in time. HR or payroll uses it to calculate pay or to decide on lateness, which affects the employee directly. The answers should be written down, not left in a manager's head.

What kind of data is a face template under the PDPA?

It is sensitive data under Section 26. The Act's English translation says 'biometric data'. The Thai text of the Act and the Thai text of the NCSA guideline use two slightly different words for it, but both describe data from a person's physical or behavioural traits that can identify them, so in practice they can be read as the same thing.

Note the wording: data arising from technology used to identify a person. An ordinary photo of a face is general personal data. The template a program extracts from it in order to match people is what falls under Section 26. That is why the same camera can sit on either side of the line depending on whether recognition is on.

Section 26 lists five exceptions to the explicit-consent rule, such as preventing danger to the life of someone who cannot consent, or establishing or defending legal claims. One observation by the author: the list has no counterpart to the legitimate-interests ground that Section 24 (5) offers for ordinary personal data. Anyone planning to rely on that ground for a face scan should read both sections side by side and take advice from their own lawyer.

Can we simply ask staff for consent?

You can ask, but an employee's consent to an employer can be challenged as not freely given. Section 19 tells the controller to take that into account as far as possible.

A safer workplace approach, offered here as the author's suggestion and not as statutory wording, is to give staff who decline a different way to clock in, with no penalty or disadvantage. If the organisation offers no alternative at all, staff cannot realistically refuse, and the word 'consent' on the form carries much less weight.

What should we check before switching a face scan on?

Three clauses run in sequence: how much to collect (3.3.2), which safeguards a biometric system needs (3.3.3), and how far the system tracks or links people (3.3.4). All of them are things to weigh. None sets a fixed number or deadline.

Clause 3.3.2: do not collect more just because the system can

The clause counts what the system produces, not only the source video. It lists seven kinds: video, metadata, detection or classification results, tracking data, biometric data or templates, derived or inferred data, and alert or AI decision history. Anyone who has built a record of processing will recognise this as the list of data types to enter.

Clause 3.3.3: safeguards for biometric data

Clause 3.3.3 then lists seven measures to consider according to risk. They work well as an internal questionnaire before purchase approval.

• Limit purpose and scope, for example face match only at the server-room door, not on every camera in the building.
• Limit who and what can access the data, including people and systems that can call up templates.
• Protect the template: ask the vendor how it is encrypted and where it is stored.
• Set a retention period, as a number the organisation decides and writes down.
• Control onward transfer and linking to other databases, for example no matching against the customer database.
• Delete when no longer needed, including a step that deletes the template when an employee leaves.
• Log and review significant access or use.

The guideline points to ISO/IEC 24745 as a reference for protecting biometric data and ISO/IEC 19795-1 for performance testing. Clause 3.2.7 adds ISO/IEC 30107 on presentation attacks. These are technical standards the organisation 'may consider', not obligations, and clause 3.2.7 itself warns that using them does not replace the lawfulness question.

In plain terms, a vendor with a certificate cannot answer for the organisation whether it has a reason to scan employees' faces. That question belongs to the controller.

Clause 3.3.4: tracking and linking

Clause 3.3.4 warns that AI lets camera data follow a person across time, places or systems, and combine with other sources to create new information about them. A shop that matches customers' faces to purchase history, or a factory that ties face and clock-in time to payroll, is in this picture.

The second quotation, from clause 6.2.2 on identifying and tracking people, makes the same point as clause 3.3.2: 'can' is not 'has a reason to'. If tracking or linking changes the level of impact significantly, clause 3.3.4 says to go back and reassess under clause 3.1.

Which uses can justify biometrics, and what is the lighter alternative?

The table below is the author's own suggestion for thinking through the structure of clause 3.3.1. It is not wording from the guideline or from any law, and it is not a ready-made answer. An organisation's specific reasons can change the outcome.

The PDPC's AI guideline from the same year gives an example of CCTV with face recognition in a shopping centre or public place, used to identify customers, analyse emotion or monitor safety. It puts the example among high-risk uses, says Section 26 must be followed strictly, and notes that in some cases the risk may be unacceptable. It too is a guideline, not law.

If the system scans the wrong person, who bears the consequences?

The person misread bears them first: marked absent, refused entry to a room, or called in for questions. Clause 3.3.5 therefore asks the organisation to assess the types of error and their consequences, not just the overall accuracy figure. Clause 6.2.4, on biometric performance, lists four kinds: accepting the wrong person, rejecting the right person, identifying the wrong person, and failing to detect or match in some conditions.

Whoever acts on scan results should know in advance that a screen saying '95 per cent match' (an invented figure for illustration) does not prove the person is the face's owner. Clause 6.4 recommends fallback measures for systems controlling high-value access and suggests more than one factor, such as a face together with a password, because systems can be fooled by photos or deepfakes.

How much a human must check before using an AI result, and how to design that step, is the subject of the companion piece AI camera alerts that are wrong: who is responsible and how much must a person check.

Does deleting the footage delete the face data too?

Not necessarily. Clause 3.3.9 says outright that deleting the original video does not automatically delete what the AI generated from it.

A face-scan system usually holds at least three separate layers. The first is the camera footage. The second is the face template the software extracted for matching. The third is the match log: times, match or no match, and the images used to compare. Each may sit somewhere different: on a device at the branch, on a central server, or in the vendor's cloud.

The guideline asks organisations to set retention separately for each data type and to know where each one is. Data that must be kept for legal purposes, audits or investigations should be separated and protected as appropriate. The guideline gives no number of days; the organisation has to decide from its own purpose.

1. Before buying
   Answer the five clause 3.3.1 questions in writing, and ask the vendor where face templates are stored, who can reach them and how they are deleted.Clauses 3.3.1 and 3.3.3
2. Before installing
   Decide whether to seek consent or rely on a Section 26 exception, and prepare an alternative for those who decline.PDPA Sections 26 and 19
3. Before going live
   Run a DPIA and a security risk assessment, and add the activity to your record of processing.Clause 3.3.8
4. In use
   Spot-check match accuracy, review access logs for templates, and reassess whenever a new AI capability is added.Clauses 3.3.3 and 6.2.7
5. When staff leave or the system is retired
   Delete templates, match logs and inferred data on the schedule you set, and keep proof of deletion.Clause 3.3.9

Do we need a DPIA, and is it too much for a small business?

Clause 3.3.8 does not say a DPIA is needed in every case. It separates several assessments that should not be treated as the same thing: an AI system impact assessment, a data protection impact assessment (DPIA), a security risk assessment, and a fundamental rights impact assessment (FRIA), the last being a foreign regulatory reference point.

The same clause lets organisations link the assessments to avoid duplication, as long as purpose, scope, results and measures remain clear. For a small business that means you do not need three documents; one document that answers all three questions will do. The practical steps for finishing a DPIA are in RoPA and DPIA that actually get finished.

For biometric data an organisation already holds without realising it, such as scanned ID cards or fingerprints from an old time clock, see sensitive data you hold without knowing.

Clause 3.1.7 adds a guard against a common misreading: the level of safeguards should not be set from a single factor.

This cuts both ways. It would be wrong to conclude that any use of facial recognition means the strictest measures in every case, and equally wrong to conclude that cameras in a small shop need no thought at all. The guideline asks you to weigh purpose, data, AI capability and the consequences of error together. An organisation that already has written answers to the five questions above can do this itself.

In AIPDPA a face-scan activity can be entered in the RoPA and its DPIA opened in the same place. The demo account shows how the fields are filled before you decide to sign up.

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)