Computer vision earns its place in AI not because machines now “see,” but because a specific four-stage pipeline — detection, alignment, embedding, matching — turns pixels into decisions that production systems can act on. The framing that matters is not “AI looking at images.” It is which stage of that pipeline owns which failure mode, and which governance constraint binds which stage. Buyers who evaluate vendors on demo accuracy without that decomposition routinely buy black boxes that fail under the lighting, pose, or gallery-drift conditions of their actual deployment. This article walks the pipeline as we encounter it in practice across our computer vision engagements, names the failure classes per stage, and connects the pieces back to the broader facial recognition pipeline discussion where the architectural detail lives. What does computer vision actually do inside an AI system? The colloquial answer — “it lets computers see” — is the one that causes the most expensive misunderstandings. A more useful framing: computer vision is the stack of operations that converts a 2D pixel array into a structured assertion (this region contains a face; this face matches identity I with similarity 0.83; this lane marking deviates from the expected geometry). Everything downstream — a self-driving control loop, a hospital triage queue, an access-control gate — consumes that structured assertion, not the raw image. The reason this matters is that each conversion step is a distinct engineering surface. A convolutional neural network (CNN) or vision transformer is doing feature extraction, not “understanding.” Downstream of that, a separate matching or classification head turns features into labels. When a system fails in production, the failure almost always lives in a specific stage — and naming the stage is half the diagnosis. This is an observed pattern across the deployments we audit: teams that treat the model as one opaque box spend weeks chasing symptoms; teams that instrument per-stage spend hours. The four-stage pipeline, named Facial recognition is the cleanest illustration because every stage is visible. The same decomposition applies, with variations, to object detection, OCR, and medical image triage. Stage What it does Typical failure mode Evidence class Detection Locates candidate regions (faces, objects) in the frame. MTCNN, RetinaFace, YOLO-family. Missed detections under occlusion, extreme pose, or low light. observed-pattern Alignment Normalises geometry (pose, scale, landmark positions) before embedding. Landmark drift on profile faces; degrades embedding quality silently. observed-pattern Embedding Maps the aligned region to a fixed-dimension vector (ArcFace, FaceNet-derived, transformer encoders). Distribution shift between training demographics and deployment population. observed-pattern Matching Compares the embedding against a gallery; thresholds decide identity / no-match. Gallery staleness, threshold drift, no operating-point discipline. observed-pattern The disallowed framing — and the one that drives most procurement mistakes — is to ask a vendor “what is your accuracy?” That single number collapses four independent failure surfaces into one marketing figure. The right questions are stage-specific: which detector, what alignment scheme, which embedding model and on what training distribution, what false-match rate at the operational threshold, what is the gallery-refresh policy. Why MTCNN is usually preferred over Haar cascades — and where that flips Haar cascade detectors were the workhorse of face detection through the early 2010s because they ran on modest CPUs in real time. MTCNN and its successors (RetinaFace, BlazeFace) replaced them on accuracy: they hold up under in-plane rotation, partial occlusion, and varied scale far better than Haar, and they output landmark points the alignment stage needs anyway. The trade-off flips on the smallest edge devices — a microcontroller-class target with no neural accelerator, or a thermal-bound always-on sensor — where a tuned Haar cascade still wins on latency and power. This is not a relic preserved out of nostalgia; it is the right choice when the inference budget is sub-milliwatt. We pay close attention to this boundary in our edge work, because the wrong default here shows up as battery life or cost-per-node, not as accuracy. Where facial recognition sits inside the broader computer vision pipeline Facial recognition is not a separate discipline. It is a specialised composition of image recognition (does this image contain a face), pattern recognition (which face), and the deep-learning infrastructure (CNNs, transformers, embedding spaces) that both rely on. Image recognition can exist without identity matching; identity matching cannot exist without it. The same is true for object detection in autonomous vehicles, defect detection on manufacturing lines, and medical image triage. Each is a particular configuration of detection, optional alignment, feature extraction, and decision-stage logic. Recognising this shared structure is what lets a team port engineering instincts across domains rather than re-learning the same lessons inside each vertical. Realistic accuracy and bias limits in 2026 deployments Three things are true at once. First, top-of-leaderboard face-recognition models report sub-1% error on benchmarks like LFW and IJB-C. Second, those numbers are benchmark figures, not operational ones — they measure performance on a curated dataset, not on a specific deployment’s lighting, camera, demographic mix, and gallery composition. Third, demographic performance gaps persist: NIST’s ongoing Face Recognition Vendor Test reports residual disparities across race, age, and gender bands, especially at low false-match-rate operating points. For buyers, the operationally relevant question is not “what is the headline accuracy” but “what is the false-match rate at the false-non-match rate you can tolerate, measured on a population that resembles your deployment.” That number is almost always worse than the leaderboard number, and the gap is the part that matters for risk planning. Treating benchmark accuracy as a procurement floor instead of a ceiling is one of the more durable mistakes in the field. Which CV algorithms are still relevant — and which are obsolete A short, opinionated map: Still relevant for production: deep embedding networks (ArcFace-family, CLIP-derived encoders), vision transformers for high-resolution tasks, CNN backbones (ResNet, EfficientNet) for cost-sensitive deployments, MTCNN / RetinaFace / BlazeFace for detection. Niche but not obsolete: Haar cascades on microcontroller targets; classical descriptors (SIFT, ORB) for SLAM, AR registration, and image stitching where deep models are overkill or non-deterministic. Largely obsolete for new builds: eigenfaces and other PCA-based face recognition methods. They are pedagogically useful and historically important, but no production system would choose them today over a learned embedding. The point of naming this is not to chase novelty. It is to push back on the equally common pattern of teams either over-engineering (transformer where a CNN suffices) or under-engineering (eigenfaces in 2026 because someone read an old textbook). Deployment context: cloud, on-device, edge The pipeline does not change shape across deployment targets, but the engineering envelope does. Cloud inference gives you the largest models and the simplest gallery management, at the cost of network round-trip and the privacy posture that comes with sending faces off-device. On-device inference (phone, kiosk) keeps the face local and uses quantised models — typically with a measurable accuracy delta versus the cloud version. Edge inference on dedicated hardware (NVIDIA Jetson, Hailo, edge TPUs) sits between the two, with the gallery-refresh policy becoming the dominant operational concern. Each setting changes which stage of the pipeline is most likely to fail, which is why “we’ll just port the model” is rarely the right plan. FAQ How does the facial recognition pipeline decompose — detection, alignment, embedding, matching? Detection locates candidate face regions in the frame. Alignment normalises pose, scale, and landmarks so the embedding step sees a canonical input. Embedding maps the aligned face to a fixed-dimension vector. Matching compares that vector against a gallery and applies an operating threshold to decide identity or no-match. Each stage is independently tunable and independently failable. Why is MTCNN typically preferred over Haar cascades in modern face detection, and where does that trade-off flip? MTCNN holds up better under rotation, occlusion, and varied scale, and it produces the landmark points alignment needs anyway. Haar cascades remain the right choice on microcontroller-class targets without a neural accelerator, where the latency and power budget rules out a deep detector. Where does facial recognition sit in the broader CV pipeline (image recognition, pattern recognition, deep learning)? It is a specialised composition of all three: image recognition to find that a face is present, pattern recognition (via learned embeddings) to identify which face, and deep-learning infrastructure to provide the encoders. It is not a separate discipline. What are the realistic accuracy and bias limits of production facial recognition in 2026 deployments? Benchmark error rates under 1% on curated datasets do not transfer to operational deployments unchanged. Demographic performance gaps persist, especially at low false-match-rate operating points, as documented in the NIST Face Recognition Vendor Test. The operational figure on your population, lighting, and camera is what should drive risk planning, not the leaderboard number. Which CV algorithms (eigenfaces, deep embeddings, transformers) are still relevant for face recognition, and which are obsolete? Deep embedding networks and vision transformers dominate new production builds. CNN backbones remain strong on cost-sensitive deployments. Eigenfaces and other PCA-based methods are obsolete for new face-recognition systems. Classical descriptors retain niches in SLAM and AR registration but not in identity matching. How does facial recognition deployment differ across cloud, on-device, and edge inference settings? Cloud allows the largest models and simplest gallery management, with network and privacy trade-offs. On-device inference uses quantised models with a measurable accuracy delta. Edge inference on dedicated hardware sits between the two, with gallery-refresh policy becoming the dominant operational concern. For the architectural walkthrough — detection model choice, embedding-space geometry, gallery management, and the governance envelope around them — see Facial Recognition in Computer Vision: How the Pipeline Actually Works. For the broader programme context across our deployments, the Computer Vision R&D page describes how we scope this kind of engagement. Image credits: Freepik
