RFP на AI-видеоаналитику: требования, вопросы и критерии приёмки

Короткий ответ

Чтобы RFP на AI-видеоаналитику давал сравнимые ответы, начните с операционной задачи и измеримого результата, а не со списка функций. Пропишите каждый сценарий — что, где и когда система должна находить, — задайте всем поставщикам одинаковые вопросы о реальной точности, ложных срабатываниях, архитектуре и данных, опубликуйте весовую матрицу оценки и привяжите приёмку к пилоту на ваших камерах с зафиксированными до старта значениями чувствительности и точности по каждому сценарию.

Главные выводы

Начинайте RFP с бизнес-задачи и измеримой метрики — какая доля значимых событий должна дойти до оператора и сколько ложных тревог команда готова разбирать, поскольку у видеоаналитики вероятностный, а не детерминированный результат.
Описывайте сценарии по каждой камере: объект или событие, зону, расписание и маршрут тревоги, чтобы поставщик не мог ответить общими обещаниями.
Требуйте одинаково измеренные значения чувствительности (recall) и точности (precision) и просите данные действующих инсталляций, похожих на вашу, а не лабораторные бенчмарки.
Ложные срабатывания — главный операционный риск: спросите о частоте ложных тревог в плотной живой сцене и о том, как система борется с дублями событий.
Публикуйте весовую матрицу и письменные критерии приёмки пилота до рассылки, чтобы поставщики отвечали именно на то, что решает исход.
Уточните данные и приватность: где хранится видео и метаданные, кто субпроцессоры, сроки ретеншна, есть ли локальный контур и что вендор может делать с вашими данными.
В России опирайтесь на единую терминологию и методику испытаний — ГОСТ Р 59385-2021 и введённый с 1 марта 2026 года ГОСТ Р 72563-2026.

Начните с задачи и метрики, а не со списка функций

Стандартный закупочный шаблон, построенный вокруг перечня функций, плохо подходит для видеоаналитики на базе ИИ. У таких систем вероятностный, а не детерминированный результат: платформа, которая в демонстрации показывает высокую точность, на вашем объекте с иным освещением, углом установки камер и плотностью сцены может работать заметно хуже. Поэтому первое, что фиксируют в RFP, — не функции, а операционная задача и её измеримый результат.

До рассылки документа определите, что значит «работает хорошо»: сколько значимых событий из ста должно дойти до оператора и за какое время, сколько ложных тревог в сутки команда готова разбирать, какие сценарии критичны. Эти числа станут основой критериев приёмки. Заодно оговорите, что менять определения после получения результатов нельзя, — иначе оценка превратится в бессодержательную дискуссию о терминах.

Функциональные и технические требования в ТЗ

Опишите каждый сценарий отдельно: какой объект или событие система должна находить, в какой зоне камеры, в какие часы и с какой реакцией — тревога оператору, запись, экспорт в смежную систему. Формат вроде «человек входит в запретную зону склада с 22:00 до 06:00» не оставляет места для общих обещаний.

Отдельно попросите описать границы работы: в каких условиях (туман, дождь, встречный свет, толпа, ночь) детекция деградирует и насколько. Честный ответ про ограничения ценнее маркетинговой страницы со списком функций.

Категории событий и зоны интереса по каждой камере с учётом расписания и исключений.
Интеграция: поддержка вашего VMS, ONVIF/RTSP, API и форматов метаданных для экспорта событий.
Архитектура: edge, on-premise или облако; какие данные покидают площадку и какая задержка допустима.
Требования к камерам: разрешение и плотность пикселей на объект в приоритетных зонах, ночная съёмка.
Производительность: число каналов, пропускная способность, отказоустойчивость и резервирование.
Хранение и ретеншн: где живут видео и метаданные, сколько хранятся по умолчанию, кто имеет доступ.

Вопросы поставщику: демо против реальности

Задайте всем кандидатам одинаковый набор вопросов и требуйте цифры из действующих инсталляций, а не из лабораторных наборов. Спросите, при каких условиях измерена точность, какой уровень ложных срабатываний в живой плотной сцене, поддерживает ли платформа on-premise или edge без выгрузки видео наружу и как устроено управление данными.

Главный риск эксплуатации — не пропуск единичного события, а лавина ложных тревог, которая приучает персонал игнорировать систему. Поэтому вопросы о точности всегда дополняйте вопросами о ложных срабатываниях, дублях и о том, как система разбирает и подавляет нерелевантные события.

Приведите данные детекции с объектов, похожих на ваш (отрасль, тип камер, освещение).
Какой уровень ложных срабатываний в реальном развёртывании и как обрабатываются дубли.
С какими VMS есть нативная интеграция и что отдаёт API смежным системам.
Где и как долго хранятся видео и метаданные, кто субпроцессоры, есть ли локальный контур.
Референсы клиентов из вашей отрасли, работающих более года, с контактами для проверки.
Модель цены — за камеру, сайт или сценарий — и как она масштабируется при расширении.

Критерии приёмки и методика пилотных испытаний

Наилучшая проверка — пилот на ваших видеопотоках в режиме параллельной работы с текущей системой (shadow mode), а не демо вендора. До старта зафиксируйте письменно длительность, число и разнообразие камер, набор тестовых сюжетов, рецензентов с обеих сторон и какие результаты считаются успехом. В выборку включайте и «лёгкие», и сложные камеры: день и ночь, толпу, плохое освещение, известные источники ложных срабатываний.

Считайте метрики по каждому сценарию, а не одним усреднённым числом. Ключевые показатели — чувствительность (recall, доля верно найденных реальных событий) и точность (precision, доля верных среди всех срабатываний), а также специфичность и доля правильных исходов. Если средний результат красив за счёт простых сценариев, а редкое критичное событие пропускается, приёмка не состоялась, даже если общее число выглядит высоким.

В России методику объективной оценки можно строить на национальных стандартах. ГОСТ Р 59385-2021 задаёт терминологию ситуационной видеоаналитики, а введённый с 1 марта 2026 года ГОСТ Р 72563-2026 описывает методологию определения функциональных характеристик: расчёт чувствительности и точности, требования к испытательным данным, статистически значимому размеру выборки, условиям испытаний и оформлению протоколов. Такая база позволяет сравнивать разных поставщиков по единым правилам.

Весовая матрица: как сравнивать ответы

Опубликуйте в RFP весовую матрицу, чтобы поставщики отвечали именно на то, что решает исход. Типичные веса для задач безопасности: техническое соответствие и точность на вашем материале 25–35 %, совокупная стоимость владения 15–20 %, интеграция и развёртывание 15 %, управление данными и приватность 10–15 %, SLA и поддержка 10 %, референсы 10 %, дорожная карта 5 %. Веса корректируйте под задачу: для строго регулируемых отраслей выше вес приватности и объяснимости.

Отдельный вес дайте тому, чего нет в демо: письменным критериям пилота и фиксации цены полного развёртывания после успешного пилота. Так вы исключите ситуацию, когда после победы в оценке коммерческие условия начинают пересматриваться.

Коммерческие условия, SLA и проверка референсов

Требуйте построчный расчёт: лицензии, интеграция, дообучение моделей, поддержка первого года, продления. Одно общее число скрывает рычаги совокупной стоимости. В SLA пропишите время реакции по критичности, частоту и порядок дообучения при изменении сцены или появлении новых типов событий, а также поведение при дрейфе модели.

Проверка референсов — это «тест боевого развёртывания»: попросите список действующих инсталляций в вашей отрасли, а не маркетинговые кейсы, и свяжитесь с клиентами с опытом более года. Красные флаги для отказа — гарантии ROI до осмотра объекта, нежелание фиксировать письменные критерии пилота, цена без интеграции и данных, неясные формулировки о повторном использовании ваших размеченных материалов.

Практический инструмент

Чек-лист: структура RFP, вопросы вендору и критерии приёмки

Используйте этот перечень, чтобы проверить проект RFP перед рассылкой: он покрывает разделы документа, вопросы, которые нужно задать всем кандидатам одинаково, и элементы, которые следует зафиксировать в контракте до начала пилота.

Зафиксированы бизнес-задача и измеримая метрика успеха: доля событий до оператора, допустимая задержка, число ложных тревог в сутки.
По каждому сценарию описаны объект или событие, зона камеры, расписание, тип тревоги и маршрут её передачи.
Указаны требования к интеграции: VMS, ONVIF/RTSP, API, форматы метаданных и экспорта событий.
Определены варианты архитектуры (edge, on-premise, облако) и что разрешено покидать площадку.
Описаны производительность, число каналов, отказоустойчивость и резервирование.
Заданы требования к хранению и ретеншну, доступам и политике в отношении биометрии.
Всем кандидатам заданы одинаковые вопросы о точности, ложных срабатываниях, субпроцессорах и референсах.
Опубликована весовая матрица оценки с долями по каждому критерию.
Пилот определён письменно: длительность, камеры, тестовые сюжеты, метрики по каждому сценарию.
В контракте зафиксированы критерии приёмки, порядок дообучения, SLA и цена после успешного пилота.
Проверены живые референсы из вашей отрасли с опытом эксплуатации более года.
Отмечены красные флаги отказа: гарантии ROI заранее, отказ от письменных критериев, скрытая стоимость интеграции.

Частые вопросы

Какие метрики закладывать в критерии приёмки видеоаналитики и почему recall и precision нельзя смешивать в одно число?

Базовые метрики — чувствительность (recall), точность (precision), специфичность и доля правильных исходов (accuracy). Чувствительность показывает, какую долю реальных событий система нашла; точность — какая доля срабатываний действительно была нужной. Эти метрики противоречивы: снижая порог, вендор может поднять recall, но завалить оператора ложными тревогами. Задавайте целевые значения отдельно по каждому сценарию и фиксируйте допустимую частоту ложных срабатываний в сутки. Усреднённое число обманывает, потому что маскирует провал на редком критичном сценарии. В России методику расчёта и требования к испытательным данным описывает ГОСТ Р 72563-2026.

Как проверить заявления вендора о точности до покупки?

Запросите данные с действующих инсталляций, похожих на вашу по отрасли, типу камер и освещению, и уточните условия, в которых измерены цифры. Лабораторные бенчмарки не отражают реальную сцену. Самый надёжный способ — пилот на ваших видеопотоках в режиме параллельной работы (shadow mode) с письменно зафиксированными до старта сценариями и метриками по каждому из них. Дополнительно спросите про уровень ложных срабатываний в плотной живой сцене, поскольку именно он определяет операционную нагрузку на команду.

Что включить в пилот, чтобы он был объективным?

До старта письменно определите длительность (обычно две–четыре недели), число и разнообразие камер, включая сложные сцены — ночь, толпу, плохое освещение, известные источники ложных тревог, — набор тестовых сюжетов, рецензентов с обеих сторон и целевые значения метрик по каждому сценарию. Проверяйте и подавленные события: возьмите выборку того, что система отфильтровала, чтобы найти пропуски. Оговорите, что менять определения и критерии после получения результатов нельзя.

Какие требования к данным и приватности закладывать в RFP?

Опишите, где хранятся видео и метаданные — локально или в облаке, — сроки хранения по умолчанию, кто является субпроцессором и имеет доступ, и как система обрабатывает биометрию, если она применяется. Для регулируемых отраслей предусмотрите вариант on-premise или edge без выгрузки видео наружу. Уточните права на данные: может ли вендор использовать ваши размеченные видеоматериалы для обучения моделей для других клиентов. Отметим, что статья носит общий характер, а применимость конкретных норм к вашей ситуации стоит проверить с юристом по вашему региону.

Как объективно сравнивать разных поставщиков между собой?

Опубликуйте весовую матрицу с критериями и их долями до рассылки и оценивайте всех кандидатов по одинаковому набору вопросов. Типичные веса: техническое соответствие и точность на вашем материале 25–35 %, совокупная стоимость владения 15–20 %, интеграция 15 %, управление данными 10–15 %, SLA 10 %, референсы 10 %, дорожная карта 5 %. Сопоставляйте ответы построчно, а не по демо, и уточняйте слабые разделы отдельным дополнением, а не перезапускайте весь цикл.

Какие нормативные ориентиры существуют в России для ситуационной видеоаналитики?

Терминологию ситуационной видеоаналитики устанавливает ГОСТ Р 59385-2021. Введённый с 1 марта 2026 года ГОСТ Р 72563-2026 описывает методологию определения функциональных характеристик: расчёт чувствительности и точности, требования к испытательным данным, статистически значимому размеру выборки и оформлению протоколов. Стандарты полезны как единый язык для ТЗ и испытаний, но не заменяют требований законодательства о персональных данных и отраслевых норм — их применимость проверяйте с профильным специалистом.

Источники и дополнительные материалы

Источники проверены при подготовке страницы. Изменяемые даты, нормы и цены уточняйте у первоисточника.

ГОСТ Р 72563-2026: Ситуационная видеоаналитика. Методология определения значений функциональных характеристикMeganorm.ru (электронный фонд документов)
ГОСТ Р 59385-2021: ИИ. Ситуационная видеоаналитика. Термины и определенияИнформпроект Групп
How to Choose an AI Video Analytics Vendor: The Evaluation Checklist That Actually WorksStaqu
AI Video Analytics for Physical Security: A Buying GuideAmbient.ai
Don't Trust the AI Demo: Prove Video Monitoring ROI in 14 DaysArcadian.ai
AI Vision RFP Template & Vendor Scoring Matrix 2026iFactory