AI Video Analytics RFP Requirements: A Procurement Checklist for Existing-Camera Deployments
An apparently compliant AI video analytics bid can still leave the decisive questions unanswered. “Works with existing cameras” does not identify which devices and streams were checked. “Real-time alerts” does not say who receives them, what happens when delivery fails, or how the response team acknowledges an event. “AI-powered detection” does not define the observable event, the operating conditions, or the test that earns acceptance.
The remedy is to write every material requirement as a chain: required outcome, vendor response, supporting evidence, acceptance method, responsible owner, and remedy for failure. That structure turns a feature claim into something procurement, security, IT, privacy, facilities, and the selected vendor can interpret the same way. It also keeps an existing-camera project focused on the deployment rather than assuming every camera needs replacement. IntelliSee’s existing-camera feasibility guide separates readiness into image, stream, compute, and alert dependencies.
What should an AI video analytics RFP require?
An AI video analytics RFP should require testable answers across scope, camera inputs, architecture, alert delivery, data handling, acceptance, support, and commercial terms. Each mandatory clause should identify the proof a bidder must submit and the condition that would make its response noncompliant. Weighted scoring should then compare genuine differences among bids that have already passed those minimum gates.
Swipe or scroll horizontally to view all table columns.
| Requirement area | What the RFP should require | Evidence in the proposal | Acceptance method |
|---|---|---|---|
| Detection scope | Name each observable event, covered zone, schedule, exclusions, and intended human action. | Completed use-case schedule with assumptions and dependencies. | Run approved scenarios in representative site conditions. |
| Existing cameras | Identify supported connection methods and disclose device, firmware, stream, credential, and field-of-view dependencies. | Camera compatibility response plus exception list. | Pull and analyze the buyer-approved production streams. |
| Architecture | Describe where inference runs and every required network, compute, power, and outbound connection. | Deployment diagram, bill of materials, and port or endpoint schedule. | Review the final design and observe operation under agreed outage conditions. |
| Alerts | Define recipients, routes, escalation, acknowledgement, suppression, audit logging, and failed-delivery behavior. | Alert workflow mapped to buyer roles and operating hours. | Trigger test events and verify each required route and escalation. |
| Data governance | Disclose every data element collected, processed, transmitted, logged, retained, or used for service improvement. | Data-flow diagram and contract exceptions. | Compare observed traffic and administrative settings with the approved design. |
| Acceptance | Use buyer-approved metrics, test scenes, ground-truth rules, observation periods, and reporting formats. | Draft acceptance plan with sample report. | Execute the signed plan before final acceptance. |
| Support and exit | State monitoring, update, incident, escalation, export, removal, and transition responsibilities. | Support matrix, service terms, and exit plan. | Verify contacts, access, documentation, and handoff artifacts. |
Keep requirements outcome-based where possible
Mandatory specifications define the outcome and boundary the buyer cannot waive. Vendor-specific design choices explain how a bidder will meet them. Do not prescribe an appliance, cloud service, codec, model, or alert channel unless the site has a documented reason for that constraint.
How should the RFP define the operating problem?
Define the operating problem as an observable event in a named camera-covered area, followed by a human response. “Provide perimeter analytics” is too broad to test. A stronger requirement identifies the restricted zone, relevant schedules, authorized exceptions, expected alert recipient, and action the recipient is permitted to take. The RFP should also state that detection supports a response process and does not guarantee prevention or replace required human judgment.
- Event: What must be visibly present or occur before the system creates an event?
- Scene: Which cameras, zones, distances, lighting states, weather conditions, and obstructions are in scope?
- Exceptions: Which authorized activity, maintenance work, schedules, or masked areas should not create an actionable alert?
- Response: Who receives the event, through which route, during which hours, and with what escalation path?
- Boundary: What outcome remains a human, policy, access-control, fire-safety, or emergency-response responsibility?
What must vendors prove about existing-camera compatibility?
Require each bidder to prove compatibility at the level of the actual camera, stream, scene, and network path. A standards label alone does not establish that the chosen detection will work with a particular view or configuration. ONVIF says Profile M supports analytics metadata configuration, querying, filtering, and streaming, but the RFP still needs bidders to distinguish supported interfaces from interfaces used in the proposed design (ONVIF Profile M). For optical planning, use the separate camera requirements briefing.
Swipe or scroll horizontally to view all table columns.
| Buyer asks | Bidder must return | Why it matters |
|---|---|---|
| Which feeds will be used? | Camera identifier, source path, stream profile, codec, resolution, frame rate, and credential owner. | A general compatibility statement cannot reveal a blocked or unavailable stream. |
| Is each scene suitable? | Day and night sample review, target-zone description, obstruction notes, and any lighting or placement dependency. | Device capability does not correct an unusable view. |
| Where does processing occur? | A diagram showing cameras, recorder or VMS, inference location, management services, and alert destinations. | Compute location changes network and outage dependencies. |
| What remains unsupported? | A written exception register covering devices, firmware, streams, detections, and operating conditions. | Procurement can price or reject exceptions before award. |
| What changes are required? | All configuration work, licenses, credentials, network rules, power, rack space, and buyer labor. | A software bid can otherwise omit prerequisites from cost and schedule. |
How should alert routing and human response appear in the RFP?
Put the complete alert-to-action chain in the requirements, not merely the notification feature. The system response should be tested from the visible event through delivery, acknowledgement, escalation, and closure. A useful workflow also distinguishes an AI event from a confirmed incident so operators understand what they are expected to verify before acting.
- Detection: Record what visible condition causes the event and which zone, schedule, or rule applies.
- Context: Specify the image, location, camera identifier, event type, and other information the recipient needs to assess it.
- Delivery: Name primary and backup routes, recipient roles, operating hours, and behavior during a network or service outage.
- Escalation: Define the acknowledgement window selected by the buyer and what happens when delivery or acknowledgement fails.
- Disposition: Capture the operator’s classification, action, reason for dismissal, and information available for review.
What privacy and AI-governance clauses belong in the RFP?
The RFP should require a system-specific data map, documented oversight roles, declared limitations, and ongoing evaluation obligations. NIST describes AI risk management as a lifecycle activity and says AI systems should be tested before deployment and regularly in operation (NIST AI RMF Core). Convert that principle into contract deliverables instead of accepting a general statement that a platform is responsible or compliant.
- List every video, image, event, log, user, device, and telemetry data flow, including destination and purpose.
- State whether any customer data is stored, retained, exported, viewed remotely, or used to train or improve shared models.
- Identify excluded functions, including identity analysis or facial recognition when those functions are outside the solicitation.
- Document administrators, access controls, change logs, model or software update notice, incident contacts, and deletion or return duties.
- Require the vendor to report material changes in system behavior, architecture, subprocessors, or data use before they affect the deployed service.
How should acceptance testing be written and scored?
Score acceptance against buyer-approved scenes, metrics, and response workflows rather than a polished vendor demonstration. NIST calls for testing before deployment and during operation; the RFP should therefore make the acceptance plan a contractual deliverable and preserve a smaller recurring test after go-live. Do not invent universal detection or nuisance-alert thresholds. Establish thresholds from the use case, consequence, site conditions, observed event rate, and the organization’s risk tolerance.
Swipe or scroll horizontally to view all table columns.
| Test element | Define before testing | Record during testing |
|---|---|---|
| Ground truth | Who determines whether the target event occurred and how disagreements are resolved. | Scenario record, reviewer, expected result, and supporting evidence. |
| Representative scenes | Required cameras, operating hours, lighting, weather, movement, occlusion, and authorized exceptions. | Condition present, configuration used, and any deviation from the plan. |
| Detection result | Buyer-selected measures and the unit of analysis, such as event, camera, zone, or operating period. | Detected, missed, duplicate, late, or out-of-scope event using the agreed definitions. |
| Alert workflow | Required recipients, delivery routes, acknowledgement rule, escalation, and outage behavior. | Delivery status, timestamps where needed, acknowledgement, escalation, and disposition. |
| Remediation | Which failures permit tuning, retesting, schedule correction, price adjustment, rejection, or termination. | Issue owner, corrective action, configuration change, retest result, and unresolved exception. |
Keep configuration changes traceable during the test. Otherwise, a bidder can tune a scene after each failure without leaving a stable record of the final configuration. The accepted configuration, exception register, camera list, and workflow map should become controlled handoff artifacts.
What belongs in the pricing and support schedule?
Require one all-in schedule that exposes both vendor charges and buyer-side prerequisites over the selected evaluation period. The goal is not to force every vendor into the same architecture. It is to make architecture-dependent labor, equipment, connectivity, integrations, renewals, and exit work comparable. Financial and claims review can then continue through the separate vendor due-diligence framework.
- Software, required compute, implementation, configuration, integrations, training, travel, and recurring support.
- Buyer-provided network, power, rack, endpoint, credential, camera, VMS, or staffing dependencies.
- Optional detections or modules shown separately from the mandatory base response.
- Update responsibility, planned maintenance, support channels, escalation contacts, and documentation delivery.
- Contract-end export, credential removal, appliance disposition, configuration return, and transition assistance.
Which requirements should be pass-fail?
Use pass-fail treatment for conditions without which the deployment cannot lawfully, technically, or operationally proceed. Apply weighted scoring only after those conditions are met. This prevents a polished interface, broad feature list, or attractive commercial score from compensating for a missing camera path, unacceptable data use, or unworkable alert route.
- Every mandatory use case has a completed response with exceptions identified.
- The bidder can access and analyze the required approved camera streams without an undisclosed replacement dependency.
- The architecture fits the buyer’s network, security, power, and operating constraints.
- Data uses and destinations remain within the buyer’s approved boundary.
- Required alert routes, escalation behavior, and outage handling are testable.
- The bidder accepts the proposed acceptance process, reporting format, remediation path, and handoff obligations.
How do you turn the checklist into solicitation language?
Convert each checklist item into a numbered requirement with the same response fields: comply, partially comply, does not comply, explanation, dependency, exception, evidence reference, implementation owner, and price location. Prohibit an unexplained “yes.” Require bidders to identify conflicts among their technical response, commercial terms, privacy documents, and standard contract language. Evaluators should score only the submitted evidence and documented clarification, not assumptions about what a platform could probably do.
Reusable response instruction
Model clause: “The bidder shall describe how the proposed system satisfies this requirement, identify every dependency and exception, cite supporting proposal evidence, and state how compliance will be demonstrated during acceptance. Silence or an unqualified affirmation without the requested evidence may be treated as nonresponsive.”
This framework does not select a vendor or guarantee that a particular camera and detection combination will pass. It gives the buying team a defensible way to discover incompatibilities, workflow gaps, and commercial assumptions before they become change orders. Review IntelliSee’s detection options against your use-case sheets, then contact IntelliSee to discuss the actual cameras, scenes, and response routes included in your procurement.
Frequently asked questions
Can an AI video analytics RFP require support for existing cameras?
Yes, but “supports existing cameras” should not be the complete requirement. Require the bidder to identify connection methods, tested streams, device or firmware exceptions, credential dependencies, scene limitations, required configuration, and any replacement assumptions. Final acceptance should use buyer-approved production streams and representative operating conditions.
Should detection accuracy be a mandatory percentage in the RFP?
Only when the buyer has defined the event, unit of measurement, ground-truth method, scene classes, test conditions, and consequence of error. A percentage without those definitions is not comparable. Where reliable baseline data is unavailable, use a structured pilot to establish defensible thresholds before final acceptance.
Is ONVIF conformance enough to prove compatibility?
No. ONVIF profiles describe standardized interfaces, but a conformant interface does not prove that a specific detection will perform in a particular view. The RFP must still address stream availability, credentials, codec and configuration, field of view, lighting, target size, network path, and proposed analytics architecture.
What is the difference between a proof of concept and acceptance testing?
A proof of concept helps the buyer evaluate fit before award or full deployment. Acceptance testing determines whether the delivered system satisfies the signed contract. The RFP should state which configurations and findings can carry forward and which requirements must be tested again in the production deployment.
Who should help write the RFP?
Procurement should coordinate input from security, IT, facilities or operations, privacy or legal staff where applicable, and the people expected to receive and act on alerts. Each group owns a different failure boundary. The final document should identify who approves the architecture, data flow, test results, operational handoff, and commercial acceptance.
Sources
Your people. Your spaces.
See it on the cameras you already have.
Bring one priority event and one camera view. We will walk through how IntelliSee turns it into an alert your team can act on.