An alert on a screen involves two different processes: a system flags a condition, and a person decides what to do. When that distinction disappears, “the system flagged it” can become a supposedly conclusive statement about someone's behaviour. What the alert detects, the information behind it and the conditions under which it may be wrong all require separate consideration.
For an organisation purchasing security services, the specification should cover more than camera numbers and software features. It should explain who reviews an alert, who assesses uncertainty and who has authority to decide on any action. An available feature is not evidence that every output is correct.
What research says about human oversight
Parasuraman and Manzey's 2010 review examines how reliance on automated decision support can lead people to follow incorrect advice or omit independent checks. [1] It integrates evidence from different experimental settings rather than testing current video analytics. Adding a human reviewer therefore does not, by itself, guarantee a correct decision.
Our practical recommendation is to define what review means, rather than simply writing “operator approval required”. What can the reviewer see? What contextual information is available? When can they state that they lack enough information to decide? Clicking an approval without the necessary context should not be treated as meaningful oversight.
Record the alert, observation and decision separately
An incident record can distinguish the system's label, the reviewer's observation and the authorised decision. If analytics flag an area crossing, the initial entry should describe that alert. The reviewer then adds what they can actually observe, without turning unclear footage into unsupported conclusions about identity, intention or criminal conduct.
NIST's voluntary AI Risk Management Framework considers AI risks within their use context and responsibilities. [2] It is not a product certification. A useful purchasing question is which decisions may use the software output as supporting information and which decisions remain with an authorised person.
Clarify four sets of responsibilities
The technology supplier should explain the feature, known limitations and technical changes. The operator defines its intended use and decision process. Security personnel carry out their authorised observation, notification and direction duties. Decisions about personal-data purposes, access and retention belong within the controller's authorised processes.
Some roles may sit within one organisation, but their decisions should remain distinguishable. Authority to change a technical setting is not automatically authority to take action concerning a person. An alert may require maintenance attention rather than contact with someone on site.
Questions for an alert decision record
- What did the system report? Are its label, time and relevant location clear, including whether the output is a prediction?
- What did the reviewer observe? Distinguish direct observation, available footage and missing information.
- Was the context checked? If there may be an authorised task or visit, did the responsible person confirm it?
- Who owns the decision? Identify the authorised role for notification, direction or any further action.
- What explains the action? Record its basis in understandable terms linked to the information available.
- Is technical feedback needed? Route recurring unexplained alerts, image problems or configuration questions to the responsible technical team.
- How is the record controlled? Identify permitted access and the applicable retention arrangements.
This proposed record does not establish an algorithm's accuracy. Its purpose is to make a decision explainable without relying solely on a system-generated label.
Revisit privacy when adding a feature
The Turkish Personal Data Protection Authority's workplace-camera notice emphasises defined purposes, proportionality, information duties and authorised access. [3] An organisation should not automatically assume that its previous assessment of a camera installation also covers a newly added analytical process.
For example, a need for a technical alert should not quietly become a new programme for general employee-performance monitoring. Facial recognition or another additional processing function should not be treated as equivalent to an ordinary movement alert. The authorised data-protection process should assess the scope, necessity and applicable conditions.
Questions for procurement and service review
Instead of asking only for successful detection demonstrations, an organisation can examine the decision process through controlled scenarios it authorises. What happens when the image is unclear? How is an unconfirmed alert closed? What does the reviewer learn after a technical update? Testing should also avoid unnecessary collection of personal data.
Separate total alerts from confirmed events when reviewing results. Measuring events that produced no alert requires a reliable independent comparison; a low alert count is not proof of success. Discussing these distinctions with security and technology providers makes the organisation's expectations clearer and avoids assigning decision-making authority to a software output.