AI in Industrial and Automotive Video — The Engineering Playbook

Published 2026-06-03 · 29 min read · By Nikolay Sapunov, CEO at Fora Soft

Why this matters

If you run product, operations, or engineering for a manufacturer, a fleet operator, an equipment maker, or an automotive supplier, you will be told that "adding AI vision" is a matter of pointing a camera at the problem and calling a cloud API. For a dashboard that counts forklifts, that is roughly true. For anything that stops a machine, brakes a car, deactivates an airbag, or warns a distracted driver, it is dangerously wrong — those features live on the far side of two lines that change the entire build, the budget, and the legal exposure. In 2026 the calendar made this urgent: driver-distraction monitoring is now mandatory on new cars in Europe, Euro NCAP scores in-cabin monitoring, the industrial robot-safety standard had its first overhaul since 2011, and the EU AI Act's high-risk regime is closing in on AI safety components in both vehicles and machinery. This article is the plain-language map a decision-maker needs to scope the work, brief engineers, pick a partner, and avoid the two mistakes that quietly sink these projects: assuming you can stream everything to the cloud and decide there, and shipping a safety-critical model as if it were a dashboard.

What "AI in an industrial or automotive product" actually means

When someone says "we want AI vision in our product," they are usually pointing at one of a handful of jobs that share a camera and a chip but little else. Sorting them on day one is the first real engineering act, because each job carries its own latency need, its own accuracy bar, and — the part that surprises people — its own legal status.

On the industrial side, the families are clear. Automated visual inspection is a camera and a model checking each part for defects — a scratch, a missing screw, a bad weld, a misprint — at line speed, replacing or backing up a human inspector. Worker-safety analytics watches a workspace for unsafe conditions: a person without a hard hat, someone inside a machine's danger zone, a bad lifting posture, a near-miss between a pedestrian and a forklift. Logistics and warehouse vision reads barcodes and labels, counts and tracks goods, and guides automated vehicles. Predictive and process monitoring watches equipment and material flow for early signs of trouble. And robot and machine guidance gives an arm or an autonomous mobile robot the eyes it needs to pick, place, and avoid people.

On the automotive side, the families mirror them. A driver monitoring system, or DMS, is a small camera aimed at the driver's face that estimates drowsiness and distraction — eyes off the road, eyes closing — and warns before a lapse becomes a crash. An occupant or in-cabin monitoring system, OMS, widens the view to the whole cabin: who is sitting where, whether seatbelts are worn correctly, and whether a child has been left behind. ADAS perception — the vision behind advanced driver-assistance systems — is the outward-facing job: detecting lanes, vehicles, pedestrians, and signs to feed automatic braking and lane-keeping. Fleet video telematics, the AI dashcam, combines an outward and an inward camera to detect risky driving and document incidents. And full autonomous perception is the same outward job taken to its limit.

Figure 1. The video-AI feature families in industrial and automotive products. They look like different worlds, but they share a camera, an edge chip, and — above a certain line — a safety obligation.

The reason to lay them out side by side is that they are built from the same parts. Underneath almost all of them sits the same substrate: a camera, an embedded computer with an AI accelerator, a detection or segmentation model trained for the scene, and a decision rule that turns the model's output into an action or an alert. A defect detector and a driver-distraction warning are, at the silicon level, the same shape of problem. That shared shape is good news for budgeting — the skills transfer — but it hides the distinction that actually matters, which is not industrial-versus-automotive at all. It is which side of two lines a given feature sits on.

The two lines that decide your whole build

Before any hardware is chosen, two lines run through every decision in a physical-world video-AI product. Most over-budget or recalled projects crossed one of them without realising it.

The first is the edge line. A model in a factory or a vehicle does not have the luxury of thinking in the cloud. The scene is physical and it is moving — a part travels down a line, a car travels down a road — so the time you have to notice something and act is short and fixed by physics, not by your architecture. Cross this line — assume you can stream the video to a data centre, run the model there, and send the answer back — and you build a system that is too slow to be useful, stops working the moment connectivity drops, and quietly leaks private video off the device. The honest design accepts that the perception and the time-critical decision run on the device, at the edge, and that the cloud's job is the slower work: training the models, learning across the fleet, storing the handful of events worth keeping, and showing humans the dashboards.

The second is the safety line. A vision model does not know anything; it produces a score — its best guess that a weld is cracked or a driver's eyes are closed. Most of the time that guess only feeds a chart or a report, and a wrong guess costs you a little accuracy. But some features wire that guess to a physical consequence: the line halts, the robot stops, the car brakes, the airbag disables, the driver gets a legally required warning. The instant a wrong answer can injure a person rather than mislead a manager, the feature crosses from analytics into a safety function — a regulated category with certification duties, mandated performance, and documentation that engineering cannot bolt on at the end. The feature looks the same in a demo. Its obligations are not remotely the same.

Figure 2. The edge line and the safety line. The first decides where your AI runs; the second decides whether it is analytics or a regulated safety function — and which standards attach.

Hold both lines in mind, because every recommendation below is one of them in disguise: the action happens where the action is (respect the edge line), and if being wrong can hurt someone, you are building a safety function, so engineer and certify it as one (respect the safety line).

Where the AI runs: the edge, the cloud, and the moment of action

The most consequential architecture decision in these products is where each piece of computation happens, because location fixes latency, reliability, privacy, and cost all at once. Three places matter, and real systems use all three.

The edge — the device itself — is where perception and the time-critical decision live. This is the camera plus an embedded computer with an AI accelerator: a dashcam's 4-to-8-TOPS chip, an automotive vision processor such as Mobileye's EyeQ family, or an industrial edge box built on something like an NVIDIA Jetson module. (TOPS, "tera-operations per second," is just a measure of how many simple calculations the chip can do — billions per second — and it is the rough currency of edge AI horsepower.) Running here means the answer arrives in milliseconds, the system keeps working when the network does not, and raw video — a worker's face, a driver's cabin — never has to leave the device. The cost is that the model must be small and efficient enough to fit, which is its own engineering discipline. (We cover that discipline in distillation and quantization for edge video AI, and the general edge-versus-cloud trade-off in our guide to latency, deployment, and real-time vs batch.)

The cloud is where the slow, heavy, fleet-wide work lives. Training and retraining the models, learning from millions of clips collected across every device, generating analytics and compliance reports, and storing the small fraction of footage worth keeping — none of this is millisecond-critical, and all of it benefits from scale and proximity to data. The modern fleet-dashcam design makes the split explicit: the device decides, in real time, that an event happened, and only the flagged clip is uploaded. Motive's 2026 dashcam generation detects distraction on the device and streams only the flagged events to the cloud, precisely to keep bandwidth — and cost — under control.

The third place is the moment of action, where a human or an actuator closes the loop. Some outputs trigger a machine directly: the robot stops, the press won't cycle, the car brakes. Others put a person in the loop: a safety manager reviews a flagged near-miss, a fleet coach reviews a hard-braking clip, a quality engineer confirms a rejected part. Designing this moment — auto-act when the answer is unambiguous and the stakes are high, route to a human when it is ambiguous — is as important as the model, and it is where the safety line gets enforced in practice.

Figure 3. Where the AI runs. Perception and the urgent decision on the edge; training, fleet learning, and reporting in the cloud; the action with an actuator or a human in the loop.

The 2026 default, then, is a hybrid with a firm rule: anything on the safety side of the line runs at the edge and degrades safely on its own, and the cloud is never in the critical path of a decision that has to be made before a car travels twenty metres.

A worked example: the edge latency budget

The edge line is not a philosophy; it is arithmetic, and the arithmetic is simple enough to do on a napkin — which is exactly why every team should do it before promising "we'll just run it in the cloud."

Take a driver-distraction warning. The whole point is to alert the driver in the fraction of a second before a glance becomes a hazard. Suppose the car is moving at 100 kilometres per hour. First convert that to metres per second:

100 km/h ÷ 3.6 = 27.78 metres per second

Now compare two designs. In the cloud design, the camera frame travels to a data centre, the model runs, and the answer comes back — call it a 700-millisecond round-trip on a good mobile network. In that time the car has travelled:

27.78 m/s × 0.70 s = 19.4 metres

Nineteen metres — about the length of a truck and trailer — covered before the warning could even arrive, and that assumes the network is up at all. Now the edge design, where the model runs on the dashcam's own chip in 50 milliseconds:

27.78 m/s × 0.05 s = 1.4 metres

A metre and a half. The difference between the two designs is roughly eighteen metres of road crossed blind, every single time. That gap is why every serious driver-monitoring and ADAS feature runs on the device, and why "stream it to the cloud" is not an option for anything the safety line touches. The same logic governs a factory: a defect on a line moving ten parts a second cannot wait for a data-centre round-trip before the reject gate has already passed.

The edge line also shows up as a bandwidth-and-cost wall, and the same back-of-envelope math settles it. A single 1080p camera streaming continuously runs about 2 megabits per second. Over a ten-hour shift that is:

2 Mbit/s × 36,000 s = 72,000 megabits = 9,000 megabytes ≈ 9 GB per day, per camera

Multiply by a thousand-vehicle fleet and you are moving nine terabytes a day just to watch — most of it footage of nothing happening. The edge alternative is to keep the video on the device and upload only flagged events: twenty short clips of twelve seconds at 2 Mbit/s is about 60 megabytes a day, roughly a hundred and fifty times less. This is why "the device decides, the cloud stores the exceptions" is the standard fleet design, not a clever optimisation.

The safety line in depth: when video AI becomes a safety function

This is the section to read twice, because it is where a feature quietly acquires obligations that the original plan never accounted for. The test is blunt: if the model is wrong, can a person be hurt? If the worst case is a bad statistic, you are below the line, building analytics. If the worst case is an injury, you are above it, building a safety function — and the rules change.

Below the line sit most of the appealing demos. A dashboard that counts how many people entered a zone. A weekly report that flags weld defects for a human to re-check. A coaching clip that a fleet manager reviews after the shift. These are valuable, they are where most projects should start, and a wrong answer is a nuisance, not a hazard. You still want them accurate, but you do not need a safety case.

Above the line sit the features that make the product matter and the lawyers nervous. A vision system that triggers an automatic emergency stop on a press. A driver-distraction warning that European law now requires on every new car. An occupant monitor that deactivates an airbag when it detects a rear-facing child seat. ADAS perception that feeds automatic braking. Here, a wrong answer — a missed defect that ships, a missed distraction that the law assumed you'd catch, a false airbag deactivation — can injure someone, and the feature inherits a safety obligation whether or not anyone planned for it.

The hardest idea above the safety line is one the standards bodies gave a name to, and it catches almost every newcomer. In ordinary engineering, you make things safe by making sure components do not fail. But a perception model can be working exactly as built — no crash, no bug, no broken sensor — and still be confidently, dangerously wrong, because it met a situation its training never covered: an unusual object, a strange light, a reflection, a defect it had never seen. The automotive world calls the safety of getting these "known unknowns" right the Safety Of The Intended Functionality, or SOTIF, standardised as ISO 21448. It exists precisely because the older functional-safety standard, ISO 26262 — which is about catching component failures, graded on a scale called ASIL from A to D — does not address a system that fails while every part works. AI vision lives squarely in this gap, which is why a third standard, ISO/PAS 8800, was published to cover AI specifically, to be used alongside the other two.

Figure 4. The safety line and the standards that attach above it. SOTIF is the one that surprises teams: a model can be wrong while every component works perfectly.

Pitfall — shipping a safety-critical model as if it were a dashboard. The most expensive mistake in this field is to build a feature that can cause physical harm with the same casual pipeline you'd use for an analytics demo: one model, one threshold, no safety case, no SOTIF analysis, no defined safe state for when the model is unsure. It passes the demo because demos are easy cases. Then it meets the real world's hard cases — the defect it never saw, the driver in unusual sunglasses, the child under a blanket — and either fails silently or fires false alarms that get switched off. The fix is not a bigger model. It is to recognise the feature is above the safety line before you build it, design a safe fallback for uncertainty, validate against the known-unknowns, and document the safety case from day one. Retrofitting a safety case onto a finished analytics pipeline is the most common way these projects blow their timeline.

The practical consequence is a sequencing rule. Decide which side of the safety line each feature sits on at scoping time, not at launch. Start the product with the below-the-line analytics that deliver value cheaply, and treat every above-the-line feature as a separate, heavier workstream with its own standards, its own validation budget, and its own timeline. A plan that mixes the two and assumes the same speed for both has already mis-scoped itself.

The automotive half: watching the driver, the cabin, and the road

Automotive video AI in 2026 is being pulled forward by regulation faster than by any other force, so it pays to understand what the law now expects.

The driver-facing job, the driver monitoring system, uses a camera — usually infrared, so it works in the dark and through most sunglasses — to track the driver's eyes, head, and face and estimate two states: drowsiness and distraction. This stopped being optional in Europe. Under the EU General Safety Regulation, Regulation (EU) 2019/2144, Driver Drowsiness and Attention Warning has been required on all new cars sold in the EU since July 2024, and the stricter Advanced Driver Distraction Warning — which watches where the driver is actually looking and warns when their eyes stay off the road — becomes mandatory for all new cars from July 2026. One supplier estimates the rules will put driver-monitoring cameras in roughly eighteen million European cars. This is the textbook above-the-safety-line feature: the law assumes the warning fires when it should, so the performance is not yours to set casually.

The cabin-facing job, the occupant monitoring system, is being pulled by the testing body rather than the statute. Euro NCAP, whose star ratings sell cars, made in-cabin monitoring part of its 2026 assessment. From 2026, cars lose points if they cannot tell that a seatbelt is worn incorrectly, and child presence detection — sensing a child left behind in a locked car — moves from a nice-to-have to a scored requirement. The protocol is specific in a way that reveals how hard the problem is: a system must detect a child through direct signs of life such as movement or breathing, begin detecting within fifteen seconds of the car being locked, and, if it sees a rear-facing child seat, deactivate the airbag automatically rather than relying on a manual switch. The driver-monitoring tests are just as exacting — the system must still work through clear sunglasses and short facial hair and across the day-to-night light transition, and must warn a degraded driver within ten seconds.

The outward-facing jobs — ADAS perception and, at its limit, autonomous driving — are the most mature and the most demanding. This is the world of Mobileye, whose EyeQ vision processors crossed their two-hundred-millionth unit shipped in 2024, with a new higher-performance generation rolling into cars from 2026. These systems increasingly fuse the camera with radar and sometimes lidar, but the camera and its perception model remain the core, and they sit at the top of the safety stack: ISO 26262 for failures, ISO 21448 for the intended-function gaps, ISO/PAS 8800 for the AI, and United Nations vehicle regulations for specific automated functions.

The fleet dashcam is where automotive video AI is most visibly a business, not just a compliance item. The video-telematics market was worth about 1.69 billion dollars in 2024 and is growing near 18% a year. Samsara alone reported dashcam-related revenue above 800 million dollars in 2025. These devices run the whole edge playbook: a 4-to-8-TOPS chip detects, in real time, more than a dozen risk behaviours per trip — phone use, drowsiness, tailgating, no seatbelt, a pedestrian too close — and uploads only the flagged moments. Most fleet-safety features are below the safety line, because they coach a human after the fact rather than steer the truck, which is why this is also the easiest place for a non-automotive company to enter the field. The biometric dimension — a camera analysing a driver's face — does carry data-protection duties; we cover those in face detection and recognition under the EU AI Act.

The industrial half: inspecting parts, protecting workers, guiding machines

Industrial video AI is pulled by economics more than by mandate, and the economics are strong. The industrial machine-vision market sits around 17 billion dollars in 2026 and is forecast to roughly double by the mid-2030s, growing in the high single digits each year.

The flagship use is automated visual inspection: a camera and a model checking every part for defects at line speed. The case for it is a number that keeps improving. Deep-learning inspection models now reach up to 96% accuracy on hard, subtle defects — micro-cracks in electronics, for instance — where the older rule-based machine-vision systems managed around 71%, a roughly 40% relative jump in catch rate, and well-tuned systems exceed 99.5% precision on the defects they are built for. Most inspection is below the safety line — a flagged part is pulled and a human confirms it — which makes it a comparatively safe place to start. It crosses above the line only when the vision verdict directly controls a safety-relevant action with no human check, such as releasing a part that a person will rely on without further inspection.

The second use, worker-safety analytics, turns the cameras a plant already has into a safety system. Platforms such as Intenseye and Protex AI connect to existing CCTV and watch for missing protective equipment, people in danger zones, bad ergonomics, and near-misses, then alert and log them. The vendors report large effects — Protex AI cites an average 64% reduction in risk within three months of deployment, a vendor figure worth verifying against your own baseline rather than taking at face value. Crucially, almost all of this is below the safety line: the system flags a condition and a human acts, so it is analytics, not a machine-stopping safety function. That keeps it accessible, and it is one of the highest-return entry points into industrial video AI.

The third use, robot and machine guidance, is where the safety line bites hardest, and 2025 reset the rules. The core robot-safety standard, ISO 10218, had its first major overhaul since 2011, folding the old collaborative-robot guidance (ISO/TS 15066) into the main text and shifting the focus from "is this a collaborative robot?" to "is this a collaborative application?" — because safety depends on how the robot is used, not what it is labelled. When a vision system is the thing that detects a person and slows or stops a robot to avoid hitting them, that vision system is a safety function in the fullest sense, governed by machinery functional-safety standards such as IEC 61508 and ISO 13849, and soon by the EU AI Act. The detection and tracking primitives underneath — the same object detectors and trackers used everywhere in this field — are covered in our pieces on the YOLO production lineage and multi-object tracking, and the surveillance-grade version of "the model flags, a human verifies" is the subject of our AI security camera and intelligent video analytics playbook.

The regulation and standards map

Because the safety line is enforced through a thicket of standards and laws, it helps to see them in one place. The table below maps the main ones; the rule of thumb is that failure-oriented standards, intended-function standards, and AI-specific standards stack on top of each other, and the EU AI Act sits above all of them for features it classes as high-risk.

The EU AI Act is the newest and the most cross-cutting. Its logic is simple: if an AI system is a safety component of a product already regulated for safety — and its Annex I list includes vehicles, machinery, and personal protective equipment — then that AI is automatically high-risk, with duties for risk management, data quality, human oversight, transparency, and documentation. A vision model that stops a robot, or that steers a lane-keeping system, is exactly this. The obligations for these product-embedded systems are scheduled to apply from August 2027, though a proposed simplification package would push some of them to 2028, so treat the exact date as unsettled and design to the requirements rather than to the deadline. The full machine is covered in our regulatory-engineering article on the EU AI Act.

Figure 5. The 2024–2028 calendar. The dates are close enough that a product scoped today should be built to the 2027 requirements now.

Three ways to build it

Once you know which features sit above the safety line and which run at the edge, there are three ways to actually build the vision system, and they trade speed of delivery against control — the same trade-off as in every other vertical.

The first route is to buy a platform. In automotive, this is buying a DMS or ADAS module from a tier-one supplier or a vision-chip vendor, or buying fleet dashcams from Samsara, Lytx, Motive, or NetraDyne. In industrial, it is buying an inspection system from a machine-vision vendor or an EHS platform such as Intenseye or Protex AI. You get a working, often pre-certified system in weeks, and the vendor carries much of the safety and accuracy burden. The trade-off is that you accept their feature set, their hardware, and their per-device or per-seat pricing, and you have limited room to adapt the model to a defect or a behaviour unique to you.

The second route is to assemble your own on standard parts: an edge computer such as a Jetson module, cameras suited to the scene, open detection and segmentation models fine-tuned on your data, and your own decision logic and dashboards on top. This takes months and means you own the accuracy, the thresholds, and the data. It is the right choice when your inspection target or your environment is specific enough that no off-the-shelf product fits, or when per-device platform fees stop making sense at your scale. Above the safety line, choosing this route means you also own the safety case — a serious commitment, not a detail.

The third route is to build and train custom models for a problem the market handles poorly — a rare defect class, an unusual material, a site-specific hazard. This is the heaviest path, justified only when the vision capability is itself the differentiator. For most teams it is premature; the question of when a general vision-language model can replace a custom detector entirely is the subject of our VLM-versus-custom-CV article.

For most teams scoping a first version, the honest path is to buy a platform for the standard, above-the-line features where a vendor's certification is worth more than your control, and to assemble your own for the below-the-line analytics that are specific to your operation and cheap to get wrong.

What these systems actually cost

Budgets vary with scope, but a few realities are routinely underestimated, and naming them prevents the worst surprises.

The first is that the edge hardware is a per-unit cost that scales with deployment, not a one-time build cost. Every camera, every edge computer, every vehicle or workstation you equip carries hardware, installation, and maintenance. A pilot on five cameras tells you little about the bill for five thousand. The second is that above the safety line, validation and certification can cost as much as the model. The safety case, the SOTIF analysis, the test campaigns against known-unknowns, and the documentation the EU AI Act will require are real engineering work with real timelines, and they do not shrink as you scale — they are the price of being allowed to ship. The third is data: a defect detector or a driver monitor is only as good as the labelled examples it learned from, and gathering, labelling, and curating that data — especially rare defects and rare hazards — is often the longest single line in the plan. A budget that books the model but not the data, the hardware fleet, and the safety case has mis-scoped the build.

Where Fora Soft fits in

Fora Soft has built video software since 2005, and the computer-vision work behind industrial and automotive video AI is the same craft we apply across video surveillance, where the discipline has always been that the model flags and a human verifies. The real-time, on-device constraints of a dashcam or an inspection camera are the same edge and latency constraints we engineer for in WebRTC conferencing and live streaming. Handling sensitive footage — a worker's face, a driver's cabin — with explicit consent and careful retention is the same standard we hold in telemedicine. That cross-domain experience is what keeps a build from treating a safety-critical feature like an analytics dashboard, and from assuming the cloud can sit in the critical path of a decision that physics says must happen on the device.

What to read next

• AI security camera + intelligent video analytics — engineering playbook
• Latency, deployment topology, and real-time vs batch
• Regulatory engineering — EU AI Act, Article 50, and biometrics

Talk to us / See our work / Download

• Talk to a video engineer — scope your inspection, driver-monitoring, or worker-safety build with a team that has shipped computer vision and real-time video since 2005. → /services/computer-vision-development
• See our case studies — explore Fora Soft's work across computer vision, surveillance, conferencing, and streaming. → /cases
• Download the Industrial & Automotive Video-AI Engineering Decision Sheet — the two lines, the feature catalog, where the AI runs, the safety-line test, the standards map, the 2024–2028 timeline, and the edge latency math on one page. → Download the decision sheet

References

1. Regulation (EU) 2019/2144 — General Safety Regulation (GSR). European Union / EUR-Lex. https://eur-lex.europa.eu/eli/reg/2019/2144/oj — Tier 1 (statute). Mandates advanced vehicle safety systems including Driver Drowsiness and Attention Warning (DDAW) and Advanced Driver Distraction Warning (ADDW). DDAW required on all new vehicles sold from 7 July 2024; ADDW phases to all new vehicles by 7 July 2026. The controlling EU source for the automotive safety line.
2. Euro NCAP — 2026 assessment protocol: occupant status monitoring & child presence detection. Euro NCAP / Smart Eye, Anyverse, AVL summaries. https://www.euroncap.com/en/for-engineers/protocols/ — Tier 1 (test protocol) / Tier 4 (summaries). From 2026, in-cabin monitoring is scored: seatbelt-misuse detection, occupant stature classification (CDC growth charts), and child presence detection (direct life-sign sensing, detection within ~15 s of locking, automatic airbag deactivation for rear-facing seats); driver-impairment notification within 10 s, robust to clear sunglasses (>70% transmittance) and day/night transitions.
3. ISO 26262:2018 — Road vehicles: Functional safety. ISO. https://www.iso.org/standard/68383.html — Tier 1 (standard). Functional safety for automotive E/E systems; the ASIL A–D risk-classification scheme. Addresses hazards from systematic and random component failures — the baseline the SOTIF standard extends.
4. ISO 21448:2022 — Road vehicles: Safety of the intended functionality (SOTIF). ISO. https://www.iso.org/standard/77490.html — Tier 1 (standard). Addresses hazards that arise when no component fails but the intended function (e.g., a perception algorithm) is insufficient — the "known unknowns." The standard that governs AI perception limitations; cited over popular blog framings that treat ISO 26262 as sufficient for AI.
5. ISO/PAS 8800:2024 — Road vehicles: Safety and artificial intelligence. ISO / SGS summary. https://www.iso.org/standard/83303.html — Tier 1 (publicly available specification). Functional safety for AI in road vehicles; used alongside ISO 26262 and ISO 21448 to address the AI/ML element specifically. Published 2024; first dedicated AI-safety PAS for vehicles.
6. ISO 10218-1:2025 & ISO 10218-2:2025 — Robotics: Safety requirements for industrial robots. ISO / The Robot Report, A3, IDEC summaries. https://www.iso.org/standard/73933.html — Tier 1 (standard) / Tier 4 (summaries). First major revision since 2011; incorporates the former ISO/TS 15066 collaborative-robot content; reframes safety around the "collaborative application" rather than the robot type; adds robot classifications, functional-safety requirements, and cybersecurity. The controlling source for vision-based robot safety functions.
7. Regulation (EU) 2024/1689 — Artificial Intelligence Act (high-risk; Annex I product safety legislation). European Union / EUR-Lex; EC AI Act Service Desk. https://eur-lex.europa.eu/eli/reg/2024/1689/oj — Tier 1 (statute). AI used as a safety component of a product covered by Annex I harmonisation legislation (vehicles, machinery, PPE) is classified high-risk, triggering risk-management, data-governance, human-oversight, transparency, and documentation duties. Product-embedded high-risk obligations scheduled from 2 August 2027; a proposed simplification ("Digital Omnibus") may move some to 2028 — date flagged as unsettled in-text.
8. Regulation (EU) 2023/1230 — Machinery Regulation. European Union / EUR-Lex; Nemko summary. https://eur-lex.europa.eu/eli/reg/2023/1230/oj — Tier 1 (statute). Replaces Machinery Directive 2006/42/EC; applies from 20 January 2027; addresses AI-enabled and self-evolving safety functions in machinery — the product-safety law beneath the EU AI Act for industrial robots and machines.
9. Industrial machine vision market size & deep-learning inspection accuracy (2026). Fortune Business Insights; MarketsandMarkets; Verified Market Research; industry summaries. https://www.fortunebusinessinsights.com/industrial-machine-vision-market-116429 — Tier 6 (analyst). Market ~USD 17.5B in 2026, ~8.4% CAGR to the mid-2030s; deep-learning inspection up to ~96% accuracy on micro-defects vs ~71% for rule-based vision (~40% relative gain); >99.5% precision on targeted defects. Used for sizing only; labelled with year.
10. Video telematics & AI dashcam market — Samsara, Lytx, Motive, NetraDyne (2024–2026). GMInsights; Intel Market Research; FleetOwner. https://www.gminsights.com/industry-analysis/video-telematics-market — Tier 6 (analyst) / Tier 4 (vendor). Market ~USD 1.69B in 2024, ~17.9% CAGR; Samsara dashcam revenue >USD 800M in 2025; edge chips 4–8 TOPS detecting 16+ risk behaviours in real time; Motive AI Dashcam Gen 3 (Jan 2026) does on-device distraction detection and uploads only flagged events. Evidence for the edge "device decides, cloud stores exceptions" pattern.
11. Mobileye EyeQ — perception SoC milestones (2024–2026). Mobileye Global Inc., SEC Form 8-K / 10-Q filings FY2025. https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001910139 — Tier 4 (first-party filings). 200-millionth EyeQ shipped in 2024; EyeQ6 High-based products launching from 2026; SuperVision/Chauffeur/Drive stacks. Evidence for camera-centric ADAS/AV perception at the top of the safety stack.
12. EHS computer-vision platforms — Intenseye, Protex AI (PPE / near-miss detection, 2025). Intenseye; Protex AI; Verdantix Smart Innovators. https://www.protex.ai/product/ppe-detection — Tier 4 (vendor). Integrate with existing CCTV to detect missing PPE, danger-zone entry, ergonomics, and near-misses (SIF prevention); Protex AI cites an average 64% risk reduction within three months (vendor claim, flagged for independent verification). The below-the-safety-line worker-safety entry point.

Standards-citation note: this is a vertical/regulatory playbook with no codec, container, color space, or quality-metric content, so the codec-spec obligation in the house rules is not applicable. The article still anchors on eight official/standards primaries — EU GSR 2019/2144, Euro NCAP 2026 protocol, ISO 26262, ISO 21448, ISO/PAS 8800, ISO 10218:2025, EU AI Act 2024/1689, and EU Machinery Regulation 2023/1230 — far exceeding the three-official-source minimum. Per the source hierarchy, where popular articles frame ISO 26262 as sufficient for AI perception, the article follows ISO 21448 / ISO 8800 and flags the gap.