Computer vision for business: use cases, data requirements and implementation cost

A bottling plant runs three lines at 20,000 bottles an hour. A crooked or missing label means a rejected pallet at the retailer’s distribution centre and a penalty clause in the supply contract. The vendor’s demo is convincing: a model flags misaligned labels on a screen with 98% confidence. The pilot starts on line two. Six weeks later the plant manager has two numbers. The system rejects one good bottle in fifteen, and the night shift has switched it to “advisory mode” because the rejects were stopping the line.

The model was fine. The demo images had been shot under studio lights with bottles standing still. On the line, bottles move past the camera faster than the exposure time allows, condensation on cold bottles reflects the overhead LEDs, and the new label supplier uses a glossier paper. Nobody had written down how many millimetres of skew count as a defect, so two quality inspectors labelled the same images differently.

This article is for COOs and product owners considering computer vision (also sold as AI vision) for quality control, inventory, document processing or site safety. Its thesis runs against much of what the market says: in business computer vision, the scene decides the outcome, not the model. The camera, the lighting, the definition of what counts as an error and data that captures the real variability of the process determine results more than the choice of algorithm. Budget and pilot should therefore be built from the station and the data outward, and the model chosen last.

Why does the computer vision demo work while the factory deployment does not?

Because the demo and the deployment solve different problems. The demo answers whether a model can recognise a defect in a good image. The deployment must answer whether the system can take a good image of every part, in every condition, across three shifts, and make a decision the process can act on.

The gap is well known from research. The public datasets used to benchmark models are shot in controlled conditions. MVTec AD, one of the most widely used datasets in industrial anomaly detection research, contains over 5,000 high-resolution images across fifteen object and texture categories, and each category’s training set contains only defect-free images. Results on such datasets tell you how good an algorithm is. They do not tell you how good a system will be on your conveyor.

On the shop floor almost everything that was constant in the lab changes. Daylight through skylights, dust on the lens, vibration in the frame, part position, a new raw material batch with a slightly different shade, a new packaging supplier. Each change shifts the distribution of data the model sees. A model trained on a week of images has never seen winter, a new product variant or a dirty lens cover.

The practical conclusion for a buyer: before asking which model a vendor will use, ask what the station will look like, where training and test images will come from, who will define a defect, and how the system will behave when conditions change. Those four answers say more about the project’s chances than the name of the network architecture.

Where do companies actually use computer vision?

The use cases that pay off outside the technology sector fall into four areas. Each has different economics, different data requirements and a different legal risk, so it is worth separating them before the budget conversation starts.

Quality control. Surface defect detection, assembly completeness checks, dimensional measurement, label and print inspection, colour verification. The return is fewer customer complaints, less inspection labour, 100% inspection instead of sampling, and an image of every part for disputes with customers.

Inventory and logistics. Counting items on shelves and pallets, out-of-stock detection in retail, reading labels and container numbers, damage checks at goods receipt, pick-and-pack verification. The return is shorter stock counts, fewer shipping errors and evidence of the condition of goods at receipt.

Documents. Optical character recognition (OCR) and intelligent document processing (IDP): proofs of delivery, consignment notes, handwritten forms, inspection reports, legacy archives. This area sits closest to process automation, and it is where overpaying is easiest, as discussed below.

Safety and security. Detecting entry into danger zones around machines, checking hard hats and high-visibility vests, smoke and fire detection, access control, licence plate recognition at the gate. Images here almost always contain people, so technical decisions are also legal decisions.

What the four share is that computer vision replaces or supports the human eye in a repetitive task that can be described. Where the task cannot be described well enough for two people to judge the same image the same way, the model will not be consistent either. Computer vision rarely lives alone: in many plants it is one more sensor in a wider Internet of Things architecture, sharing networks, gateways and data pipelines with other devices.

When does camera-based quality inspection make sense, and when does it not?

It makes sense when the defect is visible in an image, can be described, and the cost of letting it through or of manual inspection is clearly higher than the cost of the station. It does not make sense when the defect is invisible in visible light, when its definition changes with the customer and the inspector’s mood, or when volume is so low that an inspector at a bench costs less than maintaining the system.

So the first question is not “can AI detect this” but “can a person detect this in a photo”. If an experienced inspector looking at an image instead of holding the part cannot tell whether there is a defect, the model will not tell either. Some defects show only under a specific light angle, some only in infrared, some only to the touch. The last rules out a camera, and the first two change the station design.

The second question is how rare defects are. In a well-run process, defective parts are a fraction of a percent. Collecting hundreds of images of each defect type can take months. That is why anomaly detection often works better in quality control: the model learns what a good part looks like and flags anything that deviates. MVTec AD is built exactly that way, with training on defect-free images. Defect images are then needed mainly for testing, not for training.

The third question is the cost of the two types of error. A system that rejects a good part creates scrap or re-inspection work. A system that passes a defective one creates a complaint and, in some industries, a safety risk. These costs differ, so the model’s decision threshold must be set deliberately, and the pilot’s success criterion written as two numbers: the share of defects caught and the share of good parts rejected. A single “accuracy” number hides which error the system makes, and in the bottling example above it was the false rejects that killed the pilot.

The fourth question is what happens with the decision. If the system only draws a red box on a monitor while the part moves on, the value is small. You need a reject mechanism, a signal to the line’s PLC, a record in the quality system with the batch number, or a manual re-check station. That is integration with automation and business systems, not with the model, and it often decides the timeline.

How does computer vision change inventory and warehousing?

In warehouses and retail, computer vision replaces counting and comparing. A camera on a forklift or drone counts pallets in locations, a camera over the packing table checks that the right products are in the box, and an image at the dock documents the condition of a shipment at receipt. Each of these has a cheaper alternative that it must be compared with honestly.

That alternative is usually a barcode, a 2D code or RFID. If goods carry a label and the process allows scanning it, a scanner is cheaper, faster and more predictable than a model that recognises products by appearance. Computer vision wins where there is no label, or it is hidden or unreadable, where you need to assess condition rather than identity (a crushed carton, a leaning pallet, missing stretch wrap), or where scanning every item takes too long.

The most common mistake in warehouse projects is trying to recognise thousands of similar products by appearance. Products in the same range sometimes differ only in the volume printed on the label, and new variants appear every month. Every new product means new images and retraining, or adding to a reference database. Before ordering such a system, count how many new SKUs you add per year and who will be responsible for adding them.

The second mistake is expecting the system to replace the stock count entirely. It is more effective to use it to flag discrepancies: the system compares the image with the WMS record and sends a person only where the numbers disagree. A model error then means one extra location check, not a wrong stock level.

Are OCR and IDP still worth it as e-invoicing spreads?

The question matters more every year. Where invoices arrive as structured data rather than images, a document recognition project for those invoices solves a problem that no longer exists. Poland is a clear example: its national e-invoicing system, KSeF, has been mandatory since 1 February 2026 for companies whose 2024 sales exceeded PLN 200 million including VAT, and since 1 April 2026 for everyone else. A company with Polish operations that builds OCR for domestic invoices in 2026 should be building an integration with KSeF instead. Before scoping invoice OCR in any country, check what structured e-invoicing your suppliers already use or will be required to use.

That does not make document recognition obsolete. Plenty of documents still travel as paper or scans: signed proofs of delivery, CMR consignment notes, handover reports, handwritten forms, documents from partners in countries without e-invoicing mandates, pre-digital archives, identity documents in onboarding. Here intelligent document processing, combining OCR with classification and field extraction, still saves labour.

Document recognition depends on the same factors as quality inspection under different names. Scan resolution and quality correspond to the camera and lighting. The number of document layouts corresponds to product variability. Handwriting and stamps over text correspond to difficult defects. A document photographed with a phone at an angle, under yellow light, with the shadow of a hand across it, will be read worse than the same document from a flatbed scanner, whatever the model.

We have covered how to cost document automation and calculate its payback in the article on business process automation cost, so we will not repeat it here. From this article’s perspective one point matters: before ordering document recognition, check whether you can get the data from the source in structured form. An integration with a partner’s system or a public register is almost always cheaper and more reliable than reading an image.

What data does a computer vision project need, and how many images are enough?

There is no honest single answer to “how many images”, and a vendor who gives one without seeing the process is guessing. What matters is not the count but whether the dataset covers the variability the system will meet in production. A hundred images from one shift are worth less than a hundred spread across three shifts, four raw material batches and two product variants.

Data planning should therefore start with a list of variability sources. For quality control these are typically product variants and colours, raw material batches and suppliers, shifts and time of day, machine state (after changeover, before maintenance), part position and orientation, and the condition of covers and lenses. For warehousing: packaging types, lighting in different zones, rack fill levels and seasonal changes in range. For each source, the dataset should include examples from both ends of the range.

The second element is the labelling guideline. Two people labelling the same images must reach the same result. If they do not, the model will learn their disagreement. A simple test: give two inspectors the same set of a hundred images and count how often they differ. If the answer is often, refine the defect definition first (dimensions, position, visibility from a given distance) and collect data afterwards. That is work for the quality team, not for developers.

The third element is how data is split. The test set should come from different days, shifts and batches than the training set. If images from the same hour land in both, the model is evaluated on data very similar to what it learned from, and pilot results will be inflated. This is the most common reason for disappointment after go-live.

The fourth element is data after deployment. Processes change, so the model must be checked periodically on new images and retrained. You need a mechanism that collects uncertain cases, cases overruled by operators and a random sample, and routes them to labelling. Without it, model quality degrades unnoticed. We explain why keeping data good is the largest line in AI cost in the real cost of AI is keeping the data good, and the deployment and monitoring discipline itself is described under MLOps in our glossary.

How much does labelling cost? It depends on the task and should be calculated rather than assumed. An illustrative estimate: if a “good or bad part” decision takes an inspector five seconds on average, labelling 5,000 images is about seven hours of work. If every defect must be marked with a bounding box, time per image grows several times, and pixel-accurate outlines take longer still. Add a second person reviewing a share of labels. These hours usually sit with the company, because only its people know what a defect is.

Why do the camera and lighting matter more than the choice of model?

Because a model cannot recover information that is not in the image. If a scratch is narrower than a pixel, if glare covers a print, if motion blurs an edge, no algorithm will fix it. A good image, on the other hand, often lets you reach the goal with a simpler, cheaper and faster model.

Start with resolution, because it can be calculated before you buy anything. Example: the field of view is 300 mm wide and the smallest defect you must catch is 0.5 mm. If you assume a defect should span at least four pixels across, you need 300 / 0.5 × 4 = 2,400 pixels across the image. That immediately tells you which class of camera is in play, or that you must narrow the field of view and use two cameras. Put this calculation into the specification, because it lets you compare proposals.

The second parameter is motion. A part on a conveyor moves during the exposure. A short exposure needs more light; a long one blurs the image. Solutions include strobe lighting synchronised with the camera, a sensor that triggers the shot when the part is in view, or stopping the part at the station. These are decisions for an automation engineer, not a machine learning specialist.

The third parameter is light. Shiny, metallic and film-wrapped surfaces reflect light in ways that look like defects in an image or hide them. The right lighting (diffuse domes, backlights, low-angle light that brings out scratches) can turn a hard task into an easy one. Add shielding from ambient light: an enclosure costs less than a model that has to cope with sunlight through a skylight.

The fourth parameter is stability. A camera bolted to a vibrating frame points somewhere else after a month. An unprotected lens collects dust. Lights lose brightness over time. The station design should include cleaning, alignment checks (for example a reference target in the field of view that the system checks at the start of each shift) and component replacement.

All of this means an industrial computer vision project team needs someone who knows machine vision and automation, not only machine learning. A good test of a vendor is to ask who will design the camera station and who is accountable if image quality turns out to be poor. If the answer is “that is on the client side”, the project risk is on your side.

Off-the-shelf, fine-tuned or trained from scratch?

Three levels, three different budgets. The market is moving towards off-the-shelf and fine-tuned models, which for many use cases is good news.

Off-the-shelf cloud services. General object detection, text, faces, labels, content moderation. You pay per image and train nothing. Google Cloud Vision pricing gives 1,000 free units a month and then USD 1.50 per 1,000 units for features such as label detection and text detection, up to 5 million units. Amazon Rekognition image analysis costs USD 0.001 per image for the first million images a month, so a million images is about USD 1,000. This is a good choice when the question is generic (“is there a pallet in the image”, “read the text”) and images can be sent to the cloud.

Models fine-tuned on your data. You take a pre-trained model and adapt it with hundreds or thousands of your own images. This is the typical path for quality control and recognising specific products. In Amazon Rekognition Custom Labels, training costs USD 1 per hour and a running model costs USD 4 for every hour it is running, regardless of how many images it processes. AWS’s own pricing example: a model running eight hours a day costs USD 32 a day. The same model running around the clock is roughly USD 2,900 a month, which for a continuously running line is worth comparing with an edge device.

Open models you run yourself. Full control, no per-image fee, but full responsibility for infrastructure and updates. This is where a trap appears that many teams discover late: licensing. The popular YOLO models from Ultralytics are available under AGPL-3.0, which requires releasing the source code of the entire project using the model, or under a paid Enterprise licence. According to Ultralytics, a commercial licence is needed for, among others, commercial products, SaaS platforms and embedded deployments on edge devices and cameras. The same applies to data: MVTec AD is released under CC BY-NC-SA 4.0, which prohibits commercial use. Ask the vendor directly which licence covers the model, the weights and the training data, and write the answer into the contract.

Training from scratch rarely makes sense today: for unusual imagery (X-ray, thermal, hyperspectral), very high volumes, or when hardware constraints demand a very small model. For most companies it is not the starting point.

How to choose? Start with the cheapest level that has a chance of working and test it on real images from your process. An off-the-shelf service tested on a thousand images from your loading dock in one day tells you more than a month of architecture discussions. If it is not enough, move to fine-tuning. We break down the cost of each stage, from pilot to production, in the article on AI implementation cost from PoC to production.

Edge or cloud: where should the model run?

This decision affects cost, response time, security and compliance at once, so make it at the start, not after the pilot.

The cloud wins when volume is low or irregular, when the decision does not have to be made in a fraction of a second, when connectivity is good and when images may leave the site. Document reading, analysis of field inspection photos and periodic shelf checks in stores are typical cloud cases. You pay for usage, maintain no hardware, and model updates are simple.

An edge device, a computer next to the camera or in a cabinet by the line, wins in four situations. When the decision must be made before the part reaches the reject gate. When the camera runs continuously and streaming video to the cloud would cost too much in bandwidth and model hours. When site connectivity is unreliable and the line cannot stop because the internet is down. And when images contain people or production secrets that should not leave the premises. Hardware for this is now small and power-efficient: NVIDIA’s Jetson Orin Nano Super developer kit, for example, delivers 67 INT8 TOPS according to the manufacturer, within a 7–25 W power range.

The edge has costs that proposals rarely mention. Devices must be updated, monitored and replaced remotely. A model updated in the cloud must be rolled out safely to dozens of stations and rolled back if the new version performs worse. With many stations, that becomes a workstream of its own. Deployment strategies for edge hardware are covered in more depth in our guide to edge AI implementations.

A hybrid set-up is usually best. Inference runs at the edge, next to the camera. Only uncertain cases, a random sample and statistics go to the cloud, where labelling, retraining and quality monitoring happen. This limits bandwidth, shortens response time, reduces the personal data leaving the site and keeps the model improving.

What does the EU AI Act prohibit, and what does it treat as high-risk in biometrics?

Most business computer vision is not subject to special requirements under the AI Act, Regulation (EU) 2024/1689. A model that finds scratches on castings or counts pallets is not a high-risk system. The picture changes the moment a system recognises or assesses people. Here is the position as of 12 November 2026.

Prohibitions have applied since 2 February 2025. Article 5(1) prohibits, among other things, creating or expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage (point e), using AI systems to infer emotions of people in the workplace and in education institutions, except for medical or safety reasons (point f), biometric categorisation that assigns sensitive traits such as race or political opinions (point g), and real-time remote biometric identification in publicly accessible spaces for law enforcement, with narrow exceptions (point h). For employers, point f matters most: a system that uses camera images to judge employees’ fatigue, frustration or engagement is prohibited. Fines for breaching Article 5 reach EUR 35 million or 7% of total worldwide annual turnover, whichever is higher.

The Digital Omnibus added a prohibition and moved deadlines. The Commission proposed the AI part of the Digital Omnibus on 19 November 2025, political agreement was reached on 7 May 2026, and Regulation (EU) 2026/1744 entered into force on 27 July 2026. It added to Article 5 a prohibition on AI systems that generate or manipulate realistic intimate images of identifiable people without their consent and child sexual abuse material. That prohibition applies from 2 December 2026, less than three weeks from now. It has little practical relevance for companies using computer vision in quality control or logistics, but a great deal for anyone building image generation and editing tools.

Biometrics as high-risk. Annex III point 1 covers remote biometric identification systems, biometric categorisation by sensitive or protected attributes, and emotion recognition, insofar as their use is permitted by law. The key exclusion: the category does not include biometric verification systems whose sole purpose is to confirm that a person is who they claim to be. A face reader at a door that compares a person with their own enrolled template is verification. A camera in a warehouse that recognises who walks past is identification. The first is not high-risk under the AI Act; the second is.

When high-risk requirements start to apply. Originally this was to be 2 August 2026. After the Digital Omnibus, Chapter III Sections 1–3 apply to Annex III systems, including biometric ones, from 2 December 2027, and to AI embedded in products covered by the Union harmonisation legislation in Annex I (machinery, for example) from 2 August 2028. The second date matters for machine builders who embed computer vision as a safety component.

What does this mean for a COO? The postponement does not change the design. A system that recognises employees by face today will, from December 2027, have to meet requirements on risk management, data quality, documentation and human oversight, among others. How to design oversight that is more than clicking “approve” is covered in our article on human in the loop. And regardless of the AI Act, such systems are already constrained by the GDPR.

What do the GDPR and workplace monitoring rules say about cameras and faces?

For business computer vision in Europe, the GDPR is a bigger constraint than the AI Act, because it applies without postponement and covers every camera that has people in view.

Start with a distinction that is often missed. A camera image showing a person is personal data. It is not automatically biometric data. Article 4(14) GDPR defines biometric data as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a person, which allow or confirm their unique identification, such as facial images or fingerprint data. Recital 51 adds that processing photographs should not systematically be considered processing of special categories of data. A photograph becomes biometric data only when processed through specific technical means that allow identification.

The difference is practical. A system checking whether a person in a machine zone wears a hard hat processes personal data but does not need to know who that person is. A system recognising employees by face processes biometric data to identify them, which is special category data under Article 9 GDPR, prohibited in principle with narrow exceptions. In an employment relationship, consent is a weak basis because it is hard to regard as freely given. Facial recognition for time tracking or access control therefore needs careful legal analysis and a data protection impact assessment before the first line of code is written.

National employment law adds another layer. Poland’s Labour Code, Article 22², is a useful example of how specific these rules get. It allows video monitoring only where necessary for employee safety, protection of property, production control or protection of confidential information; excludes sanitary rooms, changing rooms, canteens and smoking rooms (with a narrow exception) and premises made available to trade unions; limits processing to the purposes for which recordings were collected and retention to three months unless the recordings are evidence in proceedings; and requires the purpose and scope to be set out in workplace rules, employees to be informed at least two weeks before launch and monitored areas to be marked at least one day before. Other EU countries have their own rules, often involving works councils, so check them for every site where cameras will run.

For a computer vision project this translates into concrete design decisions. A quality inspection camera should look at the product, not at the workstation: a narrow field of view, framing on the conveyor, masking of areas where people appear. If recordings are used to train a model, that use must fit the purpose for which they were collected and any retention limit, or the images must be anonymised (faces and bodies blurred) before entering the training set. Processing on an edge device that sends on only the result, or a crop containing the product, reduces risk by design. The European Data Protection Board’s Guidelines 3/2019 on processing of personal data through video devices, adopted in final form on 30 January 2020, give general guidance on recordings. For the security side of storing and transferring images, see the glossary entry on data security.

How do you estimate the cost and design the pilot?

This part has three steps: choosing the first area, breaking down the estimate and talking to vendors. The order matters, because a correct estimate for the wrong first project is useless.

What does the decision map for the four use cases look like?

Before you start counting, decide which area goes first. The table below summarises what drives effectiveness and risk in each area. It is worth going through with quality, logistics, legal and IT before writing a request for proposal.

Area	What drives effectiveness	Typical starting data	Where the model usually runs	Is off-the-shelf enough?	Legal risk
Quality control	Resolution, lighting, fixed part position, an unambiguous defect definition	Images of good parts from different shifts and batches, a defect set for testing	Edge, at the line	Rarely; usually fine-tuning or anomaly detection	Low if people are out of frame
Inventory and warehousing	Packaging variability, number of product variants, zone lighting	Images of locations and packaging, product catalogue	Edge or cloud	Often for counting and condition, rarely for product identity	Low to medium; staff in frame
Documents (OCR/IDP)	Scan quality, number of layouts, handwriting, stamps	A sample of each document type, a field list	Usually cloud	Often, with fine-tuning to layouts	Medium; personal data in content
Safety and security	Camera angle and coverage, night lighting, occlusion	Footage from different times and conditions	Edge	Often for detecting people and protective equipment	High for identifying people; prohibited for inferring employees’ emotions

The table suggests a simple rule of order. Low legal risk and a highly repeatable scene, such as quality control at a fixed station, make the best first project. Use cases that identify people need legal analysis before anyone collects data and should not be the first project of a company still learning computer vision.

What goes into the estimate?

A computer vision estimate has a different structure from a typical automation estimate, because a large share of the money goes into the physical station and into data work rather than software. Break it into six lines.

Station. Camera, lens, lighting, enclosure, mounting, trigger sensor, edge device. Cost scales linearly with the number of stations, so even a one-station pilot must be scaled to the target footprint.

Data. Collecting images across all variability sources, writing the labelling guideline, labelling and review. Partly on the company side, because only its experts know what a defect is.

Model. Choice of approach, fine-tuning, testing on data from other days, setting thresholds according to the cost of each type of error.

Integration. Signal to the line PLC, reject mechanism, records in the quality system, WMS or ERP, an operator interface for flagging mistakes.

Compliance. A data protection impact assessment where people are in frame, updated monitoring notices and works council consultation where required, licence review for models and data and, where people are identified, an AI Act requirements analysis.

Run. Quality monitoring, collecting and labelling new cases, retraining, device updates, station cleaning and calibration, cloud fees.

How does this become a number? An illustrative estimate of team effort for a one-station quality inspection pilot: two people (a machine learning engineer and an integration and machine vision engineer) for 6–8 weeks is about 480–640 hours. Multiply by your vendor’s blended rate; on ARDURA’s senior rate scale of PLN 180–260 per hour net, that is roughly PLN 86,000–166,000 for team effort alone. Add hardware, your experts’ labelling time and any cloud fees. This illustrates the method; it is not a quote. Actual cost depends on the number of product variants, defect difficulty, the state of your automation and how much station work is needed.

More important than the number is how the pilot is designed so that its result can be trusted. First, write the success criterion before you start as two numbers: the minimum share of defects caught and the maximum share of good parts rejected. Second, test on data from other days, shifts and batches than training. Third, run the pilot in shadow mode: the system judges, the inspector still decides, and you compare both judgements over several weeks. Fourth, before the pilot, test the cheapest level, an off-the-shelf service on real images, because it may be enough. Fifth, cost the roll-out to all stations and three years of running before the board approves the next stage.

Which questions should you ask a vendor before signing?

A few answers show whether a vendor understands that the problem lies in the scene and the data, not only in the model.

Who will design the camera station and lighting, and who is accountable if images turn out to be too poor? How will the dataset be collected, which variability sources will it cover, and how will it be split into training and test sets? How will the vendor measure agreement between labellers, and what will it do if agreement is low? Which two numbers will be the pilot’s success criterion, and on what data will they be measured?

Which licence covers the model, the weights and the training data, and does it permit commercial use in your scenario, including on edge devices? Where will images be processed, will they leave the site, and do they contain people? Who owns the collected and labelled data and the trained model after the contract ends? If the contract is silent, you may lose the most valuable part of the project, the labelled dataset, when you change vendors.

How will the system be monitored after go-live, how will uncertain cases be collected, and how often will the model be retrained? What does a year of running cost and what exactly does it cover? How is a new model version rolled back if it performs worse than the previous one?

A vendor who answers these questions concretely understands deployment. A vendor who keeps returning to the demo and the model’s confidence scores is selling the demo.

What are the key takeaways before you deploy computer vision?

Computer vision pays off in four business areas: quality control, inventory, documents and safety. In each, the result depends more on the scene and the data than on the choice of model, and the most expensive mistakes are made before the first line of code.

Remember six things. First, before asking about the model, check that a person can see the problem in an image, and write the error definition so that two people judge it the same way. Second, collect data across the full variability of the process and test on data from different days than training. Third, calculate resolution and design lighting before buying a camera, because a good image lets you use a simpler model. Fourth, start with the cheapest level, an off-the-shelf service, and check model and data licences before building a product on them. Fifth, decide on edge or cloud at the start, because it drives cost, response time and GDPR exposure. Sixth, keep cameras away from faces unless identifying people is the goal: inferring employees’ emotions has been prohibited since February 2025, high-risk biometric requirements arrive in December 2027, and the GDPR and national monitoring rules apply today.

If you want to check whether your use case is ready for a pilot and design it so the result can be trusted, see how we work in custom software development, or book a call. We start with a discovery phase of one to two weeks that ends with a defined scope and solution architecture.