What Oosto's own documentation says its identity-led platform does not cover, for teams running due diligence on a biometric program. Every constraint carries its documentation, its operational impact, and its workaround.
Every constraint below comes from Oosto's own current documentation or its own dated announcement, checked on August 17, 2026. Where Oosto documents nothing, this page says so rather than guessing, because silence in a document is a question to ask rather than a finding to claim. Product and module names are Oosto's own published wording. Spot AI sells a competing platform, so nothing here rests on an anonymous source or an aggregated user rating, and this page corrects something Spot AI has itself published about Oosto. We wrote that camera reuse applied to its access control product, the one that opens guarded points of entry on cameras already installed. It is broader than that: Oosto describes itself as 100% VMS agnostic across the platform, with named integration for Honeywell, Milestone and Genetec and embedded SDKs on cameras and near-edge devices.
The route from a camera to a match is published in unusual detail, including the privacy controls along it. Three things sitting either side of that route are not on a page at all.
A constraint list is only useful next to an honest account of the product.
Many-to-many face recognition, person of interest alerting, recognition of individuals in crowds within a fraction of a second, cross-camera tracking, and liveness detection that builds a 3D face map to catch a spoofing attempt. Three products separate the jobs cleanly: Oosto Protect for edge-to-cloud alerting, OnWatch for watchlist monitoring, OnAccess for opening a guarded entry point on cameras already installed.
Oosto describes itself as 100% VMS agnostic and names integration with Honeywell, Milestone and Genetec, alongside an edge-optimized design that pushes processing onto cameras through embedded SDKs. Adding it is a layer decision on the estate you have rather than a platform migration, and deployment carries published timelines: as little as one week on premises and less than an hour in the cloud.
Non-watchlisted individuals can be blurred on video playback, image data is converted to vectors including at the edge, and Oosto states the customer builds and maintains their own watchlist and that Oosto never sees that data. Published material on GDPR and on the EU Artificial Intelligence Act sits alongside it, which gives a data protection officer something to read before the first meeting.
Each one is a consequence of how the platform is designed rather than a defect. What matters is whether it collides with your starting point.
Oosto publishes its behavior set by name: fighting, falling, running, walking, crouching and lying down, alongside line crossing and cross-camera tracking. That is a security-shaped list. No safety or operations set appears anywhere on the product pages, so personal protective equipment compliance, forklift proximity, dock dwell, spill detection and procedure adherence are not part of the published scope.
On a 200-camera estate where the security director, the EHS lead and the operations manager are all being asked to justify the same camera budget, Oosto answers one of the three. A distribution center that needs a watchlist alert at the door and a forklift near-miss count on the floor is looking at two platforms reading the same feeds, with two licenses and two integration projects.
Write down the five things you actually need spotted, then mark which are identity questions and which are behavior or process questions. Identity requirements belong with Oosto. If the other list is longer than the identity list, price a platform that ships both sets before splitting the estate between two vendors.
Oosto documents what a match produces: an alert, on the console or through the integrated video management system. No speaker, strobe, horn or talk-down behavior appears on the product or technology pages. The documentation covers how a person is recognized and who is told, not what happens at the door or at the fence, so anything further sits with the access control or public address system already on site.
On a staffed estate this is the design working as intended, because the point of a watchlist alert is that a trained person makes the next decision. On a site nobody watches after 18:00, or a car park at 03:00, the value of a recognition is capped by whoever is free to act on it, and the estate ends up buying a response layer separately.
Ask Oosto in writing what an OnAccess or OnWatch event can trigger in the systems you already run, and get the integration named. Where the requirement is that somebody leaves rather than that the recognition is logged, price the deterrence hardware and the platform that drives it in the same quote rather than in a later phase.
Oosto publishes three deployment shapes, cloud, on premises and SDK, and states that image data is converted to vectors including at the edge. What it does not publish is a storage location, a retention period, a residency statement or an export path for the underlying video. The documentation covers where processing can happen, not where the footage ends up or for how long, and that is an absence of published detail rather than evidence of a weak answer.
On a biometric program that is the first question a regulator or a works council asks, and the answer cannot be read off a web page. A hospital or a bank running a consultation needs a data-flow diagram and a retention schedule per deployment mode before it can write the legal basis, and that is a document request rather than a search.
Request the data-flow diagram and the retention schedule for the exact deployment mode being quoted, on premises or cloud, and ask for the deletion behavior for both the video and the vectors. Put the answers in the evaluation record next to your own retention policy, and ask for the certification pack in the same email.
Oosto is explicit that the customer builds and maintains their own watchlist and that Oosto never sees that data, and it publishes material on GDPR and on the EU Artificial Intelligence Act. Read together, those are statements about where the responsibility sits: the platform supplies the matching and the privacy controls, and the enrollment decisions, the legal basis and the deletion plan belong to the buyer.
The license is not the whole cost. Legal basis, a retention policy, an impact assessment, works council consultation, watchlist governance and a deletion plan for templates and vectors all have named owners and real hours attached. On a European estate that work can run longer than the one-week technical deployment Oosto publishes.
Put the compliance hours on the same sheet as the license and give them an owner before the pilot rather than after it. Start the evidence pack from what Oosto already publishes, the blurring of non-watchlisted individuals on playback and the conversion of images to vectors at the edge, then run the impact assessment against your own enrollment rules.
Oosto announced on 22 January 2025 that it had been acquired by Metropolis, stating that its team and employees would join Metropolis while providing continued support and service to all current and prospective customers and partners. That is the company's own wording. Nothing further about where the three products sit inside the new portfolio, or how the roadmap is now set, appears in public.
This is not a warning, and an acquisition is a normal event in this category. It is simply the point at which a buyer signing a multi-year identity program is entitled to ask which product line owns the roadmap and who answers a support call, and the public record cannot answer either. Renewal is the cheapest moment to ask.
Ask for the product roadmap and the support model in writing, with named contacts, and ask which of the three products carries committed development. Request three reference calls with customers who deployed after January 2025, and align the contract term with the answers rather than with the discount.
The same five constraints in one view, sized to paste into an evaluation document.
Swipe the table sideways to see every column.
Oosto data comes from Oosto's own product, technology and privacy documentation and its own January 2025 acquisition announcement, checked on August 17, 2026. Gaps are marked as not publicly specified.
If the requirement is genuinely to know that a specific person is at a specific door or in a specific crowd, and the organization has the legal basis and the governance to run that program, most of the constraints above stop applying. An airport, a stadium, a casino, a bank branch network or a critical infrastructure site with a named watchlist and a compliance function is buying the thing this platform was built to do, on the video management system it already runs, with the privacy controls published rather than negotiated.
Spot AI is built around a different question, which is why its constraint list looks nothing like the one above. Instead of asking who a person is, it asks what happened and what should fire because of it: 15+ pre-trained Video AI Agents cover vehicle break-in, fire, cash register theft, after-hours intrusion, personal protective equipment, forklift near-miss, falls and crowding in hazard zones, and Iris builds a detection that is not on that list in natural conversation in about eight minutes.
The camera side stays open and the response side is included. Any ONVIF or RTSP IP camera works at full functionality and legacy analog cameras come in through the Intelligent Video Recorder, so a mixed estate does not split into a covered half and an uncovered half. Full-resolution video stays on the IVR in the building and only event metadata crosses the network, which shortens the residency conversation, and an incident is answered on site through talk down, strobes and horns on standard speakers.
The question is not which platform has fewer constraints, but whether your real requirement is who that person is or what just happened in that aisle.
None of that makes Spot AI the right answer here, and on many shortlists these two are not alternatives at all. Spot AI does not match a person against a watchlist, so if named-individual recognition is a genuine requirement then Oosto answers it and Spot AI does not. Oosto's published material on GDPR and the EU Artificial Intelligence Act is more detailed than anything Spot AI publishes about biometric governance, for the plain reason that Spot AI does not run a biometric program. Spot AI also states camera compatibility by protocol rather than by video management system, so an estate whose condition is that an existing VMS stays the system of record is a different conversation. A constraint list earns its keep by lining each platform's shape up against your starting point.
A live pilot on your cameras answers in a week what a spec sheet cannot.
Customer-reported outcomes from named Spot AI customers.
A top five North American EV charging network reports an 80% reduction in incidents with autonomous deterrence and no human monitoring.
Unique Industries covers more than a million square feet with a three-person safety team, catching near misses and falls on the cameras already installed.
Silver Bay Seafoods consolidated 22 locations, including remote Alaska facilities, and reported operational efficiency up 15%.
"With Spot AI, we're focused on three things: safety, productivity, and security."
Five, all documented. The published behavior set is security shaped, with no safety or operations detections. The documented path ends with an alert reaching a person, because no speaker, strobe or talk-down behavior is published. Where full-resolution video is retained, and for how long, is not publicly specified. The governance around a biometric program sits with the customer, which Oosto states plainly. And Oosto's own January 2025 announcement of its acquisition by Metropolis is the last published word on where the products now sit.
Yes, and the correction is worth making plainly: Oosto is not tied to particular cameras or a particular platform. It describes itself as 100% VMS agnostic, names integration with Honeywell, Milestone and Genetec, and publishes an edge-optimized design that pushes processing onto cameras through embedded SDKs and onto near-edge devices. What is not publicly specified is a camera protocol or conformance profile, so an unusual fleet is worth confirming directly before a rollout.
Yes, and the set is published by name: fighting, falling, running, walking, crouching and lying down, plus line crossing and cross-camera tracking. What does not appear anywhere is a safety or operations set, so personal protective equipment compliance, forklift proximity, dock dwell and procedure adherence are outside the published scope. If EHS or operations is funding part of the project, settle that split before the shortlist closes.
Four, and the first two are the ones the public pages do not answer: a data-flow diagram and a retention schedule for the exact deployment mode being quoted, the deletion behavior for both video and vectors, and the current certification pack. Oosto already publishes the controls worth starting from, blurring of non-watchlisted individuals on playback, conversion of images to vectors including at the edge, a customer-held watchlist, and material on GDPR and the EU Artificial Intelligence Act.
It depends on whether identity is the real requirement. If it is, nothing on a shortlist replaces it. If the estate actually needs to know what happened across security, safety and operations, a camera-agnostic platform such as Spot AI fits: 15+ pre-trained Video AI Agents run on any ONVIF or RTSP camera plus legacy analog through the Intelligent Video Recorder, full-resolution video stays in the building, and an incident is answered with talk down, strobes and horns through standard speakers.