RFP for AI Video Analytics: Requirements, Questions and Acceptance Criteria

Start with the outcome, not a feature checklist

A standard procurement template built around a feature checklist suits deterministic systems, but AI video analytics is probabilistic. The same platform that posts impressive accuracy in a curated demo can behave far worse under your site's lighting, camera angles and scene density. So the first thing to fix in the RFP is not the feature list but the operational problem and its measurable result.

Before release, decide what "working well" means in numbers: how many significant events out of a hundred must reach the operator and within what latency, how many false alarms per day the team can absorb, and which scenarios are critical. These figures become the acceptance baseline. Add a clause that the definitions will not change after results arrive — otherwise the evaluation dissolves into a dispute over terms.

Functional and technical requirements to specify

Describe each scenario independently: which object or event the system must detect, in which camera zone, during which hours, and with which reaction — alert to an operator, recording, or export to an adjacent system. A line like "a person enters the warehouse restricted zone between 10 p.m. and 6 a.m." leaves no room for generic promises.

Also ask vendors to state their limitations: how detection degrades in fog, rain, backlight, crowds or darkness. An honest description of the operating envelope is more valuable than a page of feature names.

• Event categories and interest zones per camera, including schedules and exceptions.
• Integration: support for your VMS, ONVIF/RTSP, an API and metadata formats for exporting events.
• Architecture: edge, on-premise or cloud; which data leaves the site and what latency is acceptable.
• Camera requirements: resolution and pixels-on-target in priority zones, plus low-light performance.
• Capacity: channel count, throughput, failover and redundancy.
• Storage and retention: where video and metadata live, default retention periods and who can access them.

Questions that separate a working platform from a demo

Ask every shortlisted vendor the same questions and demand figures from live installations rather than laboratory datasets. Probe the conditions under which accuracy was measured, the false-positive rate in a real crowded scene, whether the platform supports on-premise or edge deployment without sending footage off-site, and how data governance works.

The operational risk that matters most is rarely a single missed event; it is an avalanche of false alarms that trains staff to ignore the system. So always pair accuracy questions with questions about false-positive rates, duplicate events and how the platform reviews and suppresses irrelevant activity.

• Show detection results from deployments similar to yours in industry, camera type and lighting.
• What is the live false-positive rate and how are duplicate events handled?
• Which VMS platforms have native integration and what does the API expose downstream?
• Where and for how long are video and metadata stored, who are the subprocessors, is there a local loop?
• References from clients in your sector running the platform for over a year, with contacts you can call.
• Pricing model — per camera, site or use case — and how it scales as you expand.

Acceptance criteria and how to test them

The strongest evidence is a shadow-mode pilot on your own video streams running beside your current operation, not a vendor demo. Agree in writing before it starts: duration, the number and variety of cameras, the set of test scenarios, named reviewers on both sides, and what counts as success. Include hard cameras as well as easy ones — night, crowds, poor lighting and known nuisance-alert sources.

Measure metrics per scenario rather than as one blended number. The core measures are recall (the share of real events correctly found) and precision (the share of alarms that were actually warranted), together with specificity and overall accuracy. If an impressive average is driven by easy scenarios while a rare critical event is missed, acceptance fails no matter how good the headline looks.

An evaluation should also review what the system suppressed. Sample the filtered activity across cameras, times and conditions to catch potentially important missed events, and agree on the meaning of terms such as trigger, alert, false positive and duplicate before data collection. In some jurisdictions regional testing methodology and terminology can anchor these metrics; where such standards apply, they help make results reproducible and comparable between vendors.

Weighted scoring matrix

Publish a weighted scoring matrix in the RFP so vendors address what actually decides the award. A typical starting set for security is technical fit and accuracy on your footage at 25–35%, total cost of ownership at 15–20%, integration and deployment at 15%, data governance and privacy at 10–15%, SLA and support at 10%, references at 10%, and roadmap at 5%. Adjust the weights to your situation — regulated sectors usually lift governance and explainability.

Give explicit weight to things absent from a demo: written pilot acceptance criteria and a price lock for full deployment after a passing pilot. That prevents the pattern where a vendor wins on evaluation and then renegotiates commercial terms once the data arrives.

Commercial terms, SLA and reference checks

Require line-item pricing across licenses, integration, model retraining, first-year support and renewals. A single blended number hides the levers of total cost. In the SLA, define response times by severity, the cadence and process for retraining when a scene changes or a new event type appears, and what happens when the model drifts from baseline performance.

Treat references as a deployment-record test: ask for live installations in your sector, not marketing case studies, and contact customers with more than a year of production experience. Walk-away signals include guaranteed ROI before anyone inspects your site, refusal to commit acceptance criteria in writing, pricing that excludes integration and data work, and unclear language about whether the vendor may reuse your labeled footage to train models for other customers.