When using AI for factory safety management, “AI camera accuracy” is not the only—or even the most useful—basis for comparison. Success depends on whether the plant can define a hazardous situation, observe it, route a decision, trigger a human or engineered response, and retain evidence through recovery. This guide turns those requirements into an RFP, PoC, FAT/SAT, Thailand PDPA workstream, and 90-day rollout plan.
Executive conclusion: procure a reproducible detection-to-response loop
An RFP for factory safety AI should not stop at “detect hazards automatically” or “provide a highly accurate model.” The deliverable should be one operating loop that defines the hazardous scenario, camera coverage, model decision, alert path, site response, recovery, audit evidence, and privacy boundary. The buyer must be able to repeat the same test and reproduce the pass/fail result.
An ordinary AI camera is an observation and escalation layer. It does not automatically become a safety-rated protective function, nor does it replace physical traffic separation, guards, interlocks, light curtains, safety PLCs, training, signs, or PPE. If an automatic machine stop is contemplated, qualified specialists must engineer and validate the entire safety function, its components, failure behaviour, and applicable standards for the required risk reduction. A computer-vision score must not be treated as a safety circuit by itself.
Vendor comparison should therefore use evidence that answers the following questions, not an impressive demo or one accuracy figure.
| Procurement question | Evidence required for acceptance |
|---|---|
| What is considered hazardous? | Approved scenarios, exclusions, priority, and link to each hazard |
| What can the system see? | Effective coverage and blind zones by camera; day, night, obstruction, and contamination tests |
| How is a decision made? | Precision/recall by scenario, false alarms, latency, and model version |
| How is it communicated? | Alert routes, delivery confirmation, backup routes, and acknowledgement logs |
| Who takes which action? | Site procedure, response owner, target time, and escalation |
| How does it recover? | Records of network-loss recovery, camera-obstruction handling, and model rollback |
| Can the outcome be explained? | Audit trail linking event, decision, alert, response, and configuration change |
| How are people protected? | Purpose limitation, notice, retention, access, processor, and transfer controls |
What “factory safety management AI” should—and should not—mean
The search intent behind factory safety management AI can include accident prevention, monitoring efficiency, forklift controls, PPE checks, and early anomaly warning. If a project starts with the vague goal of “making the whole factory safe with AI,” its training data, camera placement, alert recipients, legal basis, and acceptance criteria will all drift. The first PoC should focus on one or two hazardous scenarios.
Practical candidate use cases include:
- detecting a pedestrian entering a forklift route, or a pedestrian and vehicle entering a defined proximity zone;
- detecting entry into a defined restricted area such as a robot cell, loading zone, or work-at-height area;
- assisting checks for site-mandated PPE such as helmets or reflective vests;
- flagging a possible fall or person-down posture, without diagnosing injury from posture alone; and
- supplementary smoke or heat anomaly monitoring only where suitable smoke, heat, or other sensors are also used—not as a video-only substitute for fire detection.
Even within “forklift pedestrian detection,” objectives differ. Retrospective near-miss analysis, a supervisor alert, a driver warning, and a link to equipment control require different reliability and accountability. A system used for later analysis must not share an unexamined acceptance standard with one expected to change action immediately.
Some uses should be explicitly excluded. Safety footage should not quietly become a source for worker speed, breaks, emotion, attention, or individual rankings. Purpose creep undermines labour trust, data protection, and model validity. The ILO warns that intrusive AI surveillance can create psychosocial, privacy, and autonomy risks. The prohibition on converting safety monitoring into productivity scoring should appear in contracts, permissions, interfaces, logs, and change approval.
Groups operating in the EU also need an EU AI Act applicability assessment. Article 5(1)(f) prohibits emotion recognition in the workplace except for medical or safety reasons. This is not Thai law, and labelling a use “safety” does not automatically qualify it for an exception. Confirm the use with local counsel and the DPO before sharing a platform with EU sites.
Put AI in its proper place in the hierarchy of controls
ISO’s occupational safety guidance presents the hierarchy of controls in descending preference: elimination, substitution, engineering controls, administrative controls, and PPE. First ask whether the hazard can be removed, replaced with a less hazardous process, or reduced through engineering controls such as traffic segregation, guards, speed limits, or interlocks. AI cameras normally serve as a complementary layer that makes residual risk visible and supports warning, investigation, and improvement.
At a forklift–pedestrian intersection, the first question is not “Can AI detect a near miss?” Ask whether routes can be separated, made one-way, or redesigned to eliminate the crossing; whether gates and barriers can be installed; and whether speed and visibility can be improved. OSHA’s powered-industrial-truck material similarly emphasises pedestrian separation where possible, clear view, warning, and safe clearance. It is a hazard-control reference, not a statement of Thai law.
AI can reveal gaps and operational changes around fixed controls: doors left open during a certain shift, temporary materials narrowing a walkway, contractors using a different route, or night lighting changing visibility. EHS should compare those events with site observations and feed them into PDCA for physical controls and standard work.
Distinguish ordinary analytics from a safety-rated function
An ordinary video-analytics stack often uses cameras, a general-purpose network, edge computers, an AI model, a message broker, and a dashboard. It may not be designed to fail safely under a single fault, processing outage, delay, or configuration change. Drawing a red box on a screen does not prove fault detection, diagnostic coverage, redundancy, or a bounded response time for a safety function.
If an AI event is to influence machine stopping, begin with the risk assessment and define the required safety function. Specialists must determine the architecture of the safety-related parts, performance-level or safety-integrity requirements, and validation method. Where the AI side interfaces with a safety PLC, engineer what the interface means, what can be lost in communication, how loss is handled, and how uncertain AI scores are treated. This article does not replace machine-specific safety engineering or certification.
ISO 45001 provides a risk-based occupational health and safety management system and PDCA framework. ISO 45001:2018 was confirmed current after review in 2024, but a replacement is expected. Do not claim that an unverified “2026 edition” has already been published; confirm the official current edition and transition terms at contract time.
Architecture from AI camera to response and recovery

The main path is CAMERA → EDGE INFERENCE → EVENT GATEWAY → ALERT ROUTER → HUMAN RESPONSE. EVENT GATEWAY and ALERT ROUTER feed the AUDIT LOG. SAFETY PLC is a separate box and, if connected, uses only a dashed ENGINEERED INTERFACE marked as NOT AN AI SCORE.
CAMERA acquires images, but field of view, exposure, frame rate, time, and health status are also managed data. EDGE INFERENCE estimates objects and relationships and adds model ID, version, confidence, bounding region, and event time. EVENT GATEWAY should not turn every unstable frame into an alarm; it combines inference with zone, duration, direction, re-alert suppression, and equipment-state rules to create an operational event.
ALERT ROUTER sends events according to severity, time, area, and shift—to an andon, mobile device, control room, or supervisor, for example. It should not rely on one chat notification: delivery failure, non-acknowledgement, and an absent owner need escalation paths. The HUMAN RESPONSE runbook defines who reviews the image, contacts the floor, pauses work, arranges assistance or isolation, classifies false alarms, and authorises restart.
AUDIT LOG is not merely a video archive. It joins the source event, camera/model/rule version, recipients, delivery result, acknowledgement, action, and restart approval under a common correlation ID. Design metadata and event-clip retention separately so that audit needs can be met without retaining more personal data than necessary.
Treat failure as part of the operating scenario
Factory systems face network loss, camera obstruction, lens contamination, edge-device overheating, clock drift, full storage, and certificate expiry. If the system cannot distinguish “no event” from “unable to observe,” silence itself becomes a safety concern.
Give each camera a heartbeat and last-good-frame status; detect frozen video, black frames, blur, and a moved field of view. Define how long edge-to-gateway queues retain events offline and what happens at overflow. If real-time warning is unavailable, show a degraded mode to the floor and define when to switch to compensating controls such as additional patrols or area closure. On recovery, old events should be synchronised as historical evidence rather than blasted out as current emergencies.
Camera placement and data readiness come before model selection
Factory AI-camera PoCs often underestimate image conditions. At the same intersection, day/night operation, reflections after rain, loading-bay backlight, floor glare, vibration, dirty lenses, and loads that occlude people can change what is visible. Overlay the hazard map and camera coverage map before installation to verify that the hazard location and the view needed for classification actually coincide.
| Imaging factor | What to confirm | How to test it |
|---|---|---|
| Lighting/backlight | Day, night, light switching, welding light, doorways, shadow | Scenario replay by shift |
| Occlusion | Pallets, racks, columns, vehicle body, overlapping people | Separate partial and full occlusion |
| Dirt/water | Dust, oil, condensation, cleaning interval | Gradual degradation and blocked-camera tests |
| Vibration/view shift | Machine vibration, post-maintenance angle, zoom change | Baseline deviation and recalibration procedure |
| Clothing variance | Uniforms, PPE colours, contractors, visitors | Review results by operational group |
| Vehicle variance | Forklift type, load, speed, and direction | Build real combinations into the test pack |
| Network | Bandwidth, packet loss, offline operation, time sync | Measure latency and evidence gaps |
Do not count only images labelled “person” or “forklift.” Build data at scenario level: approaching, moving apart, travelling along a boundary, stationary, partially hidden by a load, multiple objects crossing, and movement outside the zone. When a frame is inherently ambiguous, EHS and operations should define the decision rule rather than forcing one annotator to guess.
Check whether performance drops for a smaller operational group. Uniform colour, body size, mobility aids, rainwear, or contractor PPE may affect detection and create a safety disparity. This is not a reason to add unnecessary attribute inference or face recognition. Process only the objects and states required for the purpose. Compare edge processing and limited event clips with architectures that continuously send video to an external cloud.
Acceptance metrics: decompose “accuracy” into operating measures
Accuracy can look high when normal conditions dominate the dataset. If hazardous events are rare, a model that always predicts “no hazard” may still produce a superficially attractive number. Create a confusion matrix per scenario and separately measure precision, recall, false alarms per camera-hour, latency, coverage, availability, and evidence completeness.
- Recall: share of actual hazard-scenario tests detected; focuses on misses.
- Precision: share of generated hazard events that are correct; relates to alarm fatigue.
- False alarms per camera-hour: operational burden normalised by active camera time.
- Detection latency: time from scenario onset to event creation; review p95 and p99, not only an average.
- Alert-delivery latency: time from event creation to recipient delivery; separate inference from communication delay.
- Coverage / blind-zone rate: share of the target hazard area that can or cannot be observed and classified effectively.
- Availability: time during which observation, inference, and routing are effective; distinguish planned and unplanned downtime.
- Evidence completeness: share of cases containing event, clip, model/rule version, delivery, and response records.
This article cannot prescribe universal thresholds. They vary with hazard severity, approach speed, compensating controls, camera count, and response procedure. The RFP should not ask a vendor to promise an “industry-standard accuracy.” Set acceptance gates from a site-specific risk assessment and agree on the test population and treatment of confidence intervals.
An example acceptance-gate structure
The following is a project example, not a set of universal pass values.
- EHS records severity, exposure, avoidability, and existing controls for each hazard.
- Divide each scenario by day/night, clear/occluded, single/multiple object, and other relevant conditions.
- Freeze the expected event, recipient, response, and required evidence before execution.
- The vendor runs data independent of the training set and reports the confusion matrix and latency percentiles.
- Emphasise misses for critical scenarios, while also checking whether false alarms make lower-severity scenarios operationally unusable.
- Do not average away a failed critical negative test; correct it and retest.
After a model update, rerun the same golden test pack. Do not release a version that improves the overall metric but regresses at night, on a particular camera, or with contractor clothing. In production, monitor image brightness, blur, object size, and event rate for signs of input or performance drift, then have humans review. Without current ground truth, live operational indicators alone do not prove maintained accuracy.
Define RFP deliverables and responsibilities together
Safety-monitoring AI crosses camera vendors, AI vendors, networks, infrastructure, system integration, EHS, IT/OT, legal/DPO, and floor operations. A simplistic “AI belongs to the vendor; data belongs to the customer” split misses boundary failures. Require deliverables and a RACI in the same work package.
| RFP deliverable | Minimum content | Typical owner / approver |
|---|---|---|
| Hazard and use-case specification | Target hazards, exclusions, priority, existing controls, response | EHS / Operations |
| Coverage design | Camera positions, view, blind zones, lighting, maintenance access | Vendor / EHS |
| Data specification | Collection scope, annotation rules, quality, representation, deletion | Vendor / DPO and EHS |
| Model card and release note | Intended use, limits, tests, version, known failures | AI vendor / EHS |
| Event and interface specification | Schema, time, IDs, retry, security, PLC boundary | IT/OT and integrator |
| Alert and response runbook | Routing, acknowledgement, escalation, recovery | Operations / EHS |
| FAT/SAT test pack | Positive/negative cases, expected results, evidence, retest | Vendor / customer |
| Privacy and security package | Basis assessment, notice, retention, access, contracts | DPO/legal / IT security |
| Operations package | Health monitoring, cleaning, backup, rollback, drift | Vendor / IT/OT |
| Training and change record | Operators, supervisors, maintenance, worker briefing | Operations / HR and EHS |
Where a works council or worker representatives are present, involve them early in use-case design and change control. Beyond formal procedure, they can help define appeals after false alarms, access to footage, and safeguards against adverse individual use in terms workers understand. The ILO’s report on AI, digitalisation, and OSH notes both the preventive potential of smart monitoring and the need for proactive, adaptive management of new risks with worker participation.
Contracts should address model and cloud subprocessors, data location, security-incident notification, vulnerability response, support hours, export format, and data return or deletion at exit. To reduce lock-in, require event logs, configurations, annotation guidelines, test packs, and model-release history in machine-readable form.
For requirements or a delivery model where an off-the-shelf product is insufficient, see our AI development outsourcing guide for Thailand. Product-defect inspection is a different purpose from worker and vehicle safety; our AI visual inspection implementation guide covers test objects, ground truth, and production-process integration separately.
Include negative tests in the PoC, FAT, and SAT
A PoC is not a polished demonstration of bounding boxes. It tests whether the use-case and operating assumptions hold at the site, what becomes visible when they fail, and whether workload is acceptable. FAT reproduces functions, interfaces, and failure handling with fixed versions and data in the supplier’s controlled environment. SAT accepts the end-to-end operation with production cameras, lighting, network, alert devices, staff, and shifts.

The acceptance matrix uses DAY, NIGHT, OCCLUSION, NETWORK LOSS, and CAMERA BLOCKED as rows, with DETECT, ALERT, RESPOND, and EVIDENCE as columns. Close each cell as PASS or FAIL; detailed measurements belong in the linked report rather than invented percentages in the figure. NETWORK LOSS is not simply “detection N/A”: assess loss-of-observation detection, degraded notification, compensating response, and recovery evidence.
At minimum, include these test cases:
- Positive scenario: the target enters or approaches under the defined zone, direction, and duration.
- Boundary: line boundary, threshold edges, brief transit, multiple targets, and partial visibility.
- Negative: travel outside the zone, posters or reflections, parked vehicles, and authorised maintenance should not become hazard events.
- Occlusion: columns, pallets, loads, or other vehicles hide part or all of the target.
- Environmental: day/night, lighting transition, backlight, rain, dust, vibration, and lens contamination.
- Network loss: isolate camera–edge, edge–gateway, and gateway–router segments.
- Camera blocked or moved: detect not only black frames but frozen video, blur, and angle shift.
- Alert delivery: test primary-route failure, backup route, acknowledgement timeout, and escalation.
- Model rollback: restore the approved version after regression in a new release.
- Clock anomaly: preserve ordering and auditability through clock skew, delayed replay, and duplicate events.
- Human response: recipients can verify, intervene, record, and restart by following the runbook.
- Evidence: reconstruct input, decision, alert, action, and change history through one correlation ID.
Do not close FAT/SAT with “confirmed on the vendor screen.” Record test ID, precondition, input, expected result, actual result, log/evidence link, reviewer, date, and software/model/configuration version. After correcting a failure, rerun the affected regression set as well as the failed case.
Measure end-to-end response, not inference alone
Decompose time from hazard onset to human action as T_total = T_capture + T_inference + T_gateway + T_delivery + T_ack + T_action. This is a design formula; allowable values must come from the site risk assessment. A fast demo is irrelevant if the night-shift recipient is absent, the mobile device is silent, or post-acknowledgement action is undefined.
p95 and p99 help reveal tail latency, but percentiles from a small sample are unstable. Record the run count, shifts, and network conditions so that a “p99” label does not masquerade as reliability. For an automatic-stop safety function, statistical averages and percentiles are not enough: applicable standards require separate engineering and validation of worst-case response time and failure behaviour.
Thailand PDPA and cross-border governance
Images of identifiable workers can be personal data. For Thailand PDPA compliance, confirm lawful basis, notice, purpose limitation, minimisation, retention, access control, data-subject handling, processor/cloud contracts, cross-border transfers, and security with Thai counsel or the DPO. This article is not legal advice for a particular case.
The importance of safety does not justify unlimited monitoring. Define the area, events, users, retention, and secondary use—not only a broad purpose such as “accident prevention.” Compare continuous recording with short event clips, edge anonymisation with cloud processing, and object detection without face recognition.
| Governance topic | Question to place in the RFP |
|---|---|
| Purpose | Which hazards and responses are in scope, and which uses are prohibited? |
| Lawful basis | Who assesses and records it, and who reassesses after change? |
| Notice | What is communicated to workers, contractors, and visitors, in which languages? |
| Minimisation | Are resolution, area, audio, face recognition, and continuous upload necessary? |
| Retention | How long are raw video, clips, metadata, and audit logs retained separately? |
| Access | Who can view live video, replay, export, or change settings, and how is it logged? |
| Processor/cloud | Which subprocessors and countries, and what security, incident, and deletion evidence? |
| Secondary use | How are disciplinary use and productivity scoring prevented? |
| Rights and grievance | What inquiry, objection, correction, and non-retaliation processes exist? |
Do not assign one retention number to every data class. Raw video might be short-lived, anonymised statistics longer-lived, and incident evidence placed under a formal hold. Exact periods should reflect legal, insurance, labour, customer, and investigation requirements.
Thailand and the ILO held a national workshop on 25 March 2025 to improve recording and notification of occupational accidents and diseases. AI-camera events must not be confused with official accident counts, but the direction is relevant: use clear definitions, handle missing and corrected records, and improve the quality of prevention evidence.
Compare cost, TCO, and ROI with formulas—not invented market prices
Factory AI-camera cost is not determined by camera count or software licences alone. Existing-camera reuse, lighting, edge compute, network works, OT integration, labelling, privacy measures, round-the-clock support, and model updates can materially change the total. The RFP should compare consistent items over a buyer-selected horizon such as three to five years, rather than use an unsupported “typical price.”
TCO = initial equipment + design/installation + edge/cloud + integration + data/labelling + FAT/SAT + security/privacy + training + annual operations × evaluation years + refresh/retraining + exit cost
Annual benefit = expected avoidable incident loss + investigation time saved + downtime avoided + value of redeployed patrol effort + verifiable insurance/audit effects
ROI = (benefit over evaluation horizon - TCO) / TCO
These formulas define inputs, not universal outcomes. EHS, Finance, and Operations should provide ranges rather than fill injury-avoidance value or reduction rates with vendor assumptions. For low-probability, high-impact incidents, conservative, base, and upside scenarios are usually more informative than one average.
| TCO category | Frequently missed items |
|---|---|
| Hardware | Housing, mounts, lighting, UPS, spares, cleaning access |
| Compute/network | GPU/edge refresh, bandwidth, segmentation, certificates, storage |
| Integration | Alerts, MES/SCADA, identity, tickets, audit, engineered interface |
| Data/MLOps | Site collection, annotation review, golden set, drift, rollback |
| Operations | Health monitoring, lens cleaning, false-alarm triage, on-call cover |
| Privacy/security | Assessment, notice, masking, access review, processor audit |
| Change | Worker briefing, training, shift rollout, SOP revision, reacceptance |
| Exit | Event/configuration export, test pack, data deletion, replacement work |
Simply multiplying a PoC is also unsafe. As camera count grows, diversity, network segments, alert routing, maintenance access, and false-alarm handling can grow non-linearly. Before controlled scale, calculate workload from false alarms per camera-hour and review time per event.
Thailand’s BOI reported 1,300 approved investment-promotion projects worth about THB 1.31 trillion in the first half of 2026, including THB 17.2 billion in projects upgrading machinery, digital technology, automation, and robotics. This is investment-context information; it does not mean every AI-camera project qualifies for an incentive. Confirm eligible activities, timing, and conditions with the BOI or a specialist.
A controlled 90-day rollout

The project-example timeline is 0–30 MAP HAZARD & DATA, 31–60 POC & NEGATIVE TESTS, 61–90 SAT & GOVERNANCE, then CONTROLLED SCALE. Supporting owners are EHS, OPERATIONS, IT/OT, DPO, and VENDOR. It is not a promise to finish an entire factory in 90 days; it is a framework for collecting enough evidence to make a procurement and acceptance decision in one priority area.
Days 0–30: lock the hazard and data boundary
EHS and Operations review incidents, near misses, traffic, and existing controls, then select one or two scenarios. A walkthrough tests camera positions, lighting, occlusion, and maintenance access. IT/OT maps network zones, edge placement, time synchronisation, and alert interfaces. DPO/legal confirms purpose, basis, notice, retention, access, and worker consultation.
Exit deliverables are an approved use-case sheet, hazard/coverage map, data flow, exclusions, RACI, and test outline. Do not allow a vendor to “start filming and train later” before collection scope is approved.
Days 31–60: run the PoC and negative tests
Collect data across representative day/night shifts and create annotation rules and a golden test pack. Connect camera, edge, gateway, and router. Run positive, boundary, negative, occlusion, network-loss, and camera-blocked cases. Measure false alarms per camera-hour, p95/p99 latency, evidence completeness, and operator workload in addition to precision and recall.
Weekly review checks whether threshold tuning merely hides false alarms or an improvement to one scenario reduces recall in another. Record every model, rule, and configuration version with its reason and retain a rollback path.
Days 61–90: close SAT, training, and governance
Run SAT with production-like networks, alert devices, shifts, and recipients. Verify acknowledgement, floor response, escalation, degraded mode, recovery, and rollback against the runbook. Explain purpose, monitored areas, prohibited uses, and inquiry routes to workers; train supervisors and maintenance teams.
Move to controlled scale only after all critical tests close, unresolved risks have owners and dates, privacy/security approvals are complete, and operational capacity and support are ready. For the next area, reuse the structure but add its specific hazards, lighting, traffic, uniforms, and vehicles.
Use NIST AI RMF to govern the operating lifecycle
The NIST AI Risk Management Framework organises AI risk management around Govern, Map, Measure, and Manage. It is not a Thai legal mandate, but it is useful governance scaffolding for factory AI.
- Govern: establish policy, ownership, approvals, competence, vendor duties, worker participation, and records.
- Map: understand hazards, users, affected people, data flows, existing controls, and failure context.
- Measure: test scenario metrics, operational groups, latency, availability, privacy/security, and human factors.
- Manage: prioritise risk and decide whether to deploy, limit, stop, correct, roll back, or retire.
Do not interpret a higher AI-event count as proof that safety worsened. Observability may simply have improved. Conversely, a lower count might reflect effective controls, a dirty camera, or a changed threshold. Compare events with near-miss records, floor observation, equipment changes, and worker feedback.
Model changes, camera moves, layout changes, new uniforms or vehicles, and software updates are reassessment triggers. Run the golden tests before and after change and stop a release with a critical regression. Auditors should be able to see why a change was made, who approved it, and which tests passed—not only that the “latest version” is installed.
FAQ: questions to ask before buying factory AI safety monitoring
What is factory safety management AI?
It observes defined signs of a hazardous scenario in images or sensor data and connects them to alerting, response, and improvement. An ordinary AI camera is an observation and escalation layer, not a safety-rated protective function by itself. Consider elimination, substitution, and engineering controls first.
Can an AI camera replace guards or light curtains?
Do not assume it can. Ordinary analytics should not replace separation, guards, interlocks, safety PLCs, or light curtains. If automatic stopping is involved, specialists must engineer and validate the whole safety function against the required risk reduction and applicable standards.
What should a forklift pedestrian detection test include?
Test direction, speed, crossing, stops, load occlusion, multiple people, day/night conditions, and zone boundaries—not distance alone. Separately accept recall, precision, false alarms per camera-hour, p95/p99 detection and alert latency, coverage, evidence completeness, and actual human response.
What accuracy percentage is acceptable for safety monitoring AI?
There is no universal percentage. Set site-specific thresholds from hazard severity, avoidability, existing controls, response time, and conditions. Evaluate critical-scenario recall, false alarms, latency, availability, and blind zones separately rather than accept one overall accuracy figure.
What happens if the network fails during restricted-area detection?
Detect the loss of observation, announce a degraded mode, and switch to compensating controls such as extra patrols or area restriction. Test offline buffering, resynchronisation, treatment of old events, and evidence gaps in FAT/SAT. The site risk assessment determines how safety is maintained during communication loss.
Is worker video subject to Thailand’s PDPA?
Identifiable video can be personal data. Confirm lawful basis, notice, purpose limitation, retention, access, processor/cloud contracts, cross-border transfers, and security with Thai counsel or the DPO. Prevent undisclosed reuse for productivity scoring or disciplinary ranking.
How do PoC, FAT, and SAT differ?
PoC tests whether the use-case and operating assumptions work under site conditions. FAT reproduces fixed versions and test packs in the vendor environment. SAT accepts the end-to-end operation with production-like cameras, network, alerts, and people. All three should include negative tests and evidence.
How should factory AI-camera cost and ROI be compared?
Include installation, lighting, edge, network, integration, data/labelling, FAT/SAT, privacy/security, training, operations, retraining, and exit cost—not only cameras. Evaluate benefits such as investigation time, downtime, and redeployed patrol work as ranges, and test the assumptions with sensitivity analysis.
Summary: strengthen safety with operating evidence, not an AI score
Factory safety AI procurement should deliver more than an attractive detection demo. Turn hazard, coverage, model decision, alert, human response, recovery, audit, and privacy into one reproducible loop, then test positive and negative cases through PoC, FAT, and SAT. Keep the AI camera in its complementary place within the hierarchy of controls and maintain a clear boundary from any safety-rated function.
TOMAS TECH can support early hazard and route mapping, camera/edge architecture, RFP preparation, PoC, FAT/SAT, IT/OT integration, and operating design that accounts for Thailand’s PDPA. You can contact us even before selecting a product, including for a 90-day validation in one priority area.
Primary sources and references
- NIST AI Risk Management Framework
- NIST AI RMF Playbook
- OSHA: Powered Industrial Trucks — Pedestrian Traffic
- ISO: Occupational safety and health
- ISO 45001:2018
- ILO: Revolutionizing health and safety — the role of AI and digitalization at work
- ILO: AI-driven intrusive surveillance and loss of autonomy at work
- Thailand MDES: Personal Data Protection Act B.E. 2562 (2019)
- Thailand MDES: Personal data protection legal materials
- EU AI Act, Regulation (EU) 2024/1689
- Thailand BOI: Investment promotion results, first half of 2026
- ILO: Thailand takes action to improve OSH statistics