Видеонаблюдение: расследование инцидентов мультимодальным агентом

TL;DR

Этот финальный проект превращает весь блок курса по компьютерному зрению и агентным системам в готовый продукт: систему, которая по естественному языковому запросу о записанном видео – например, «покажи всех, кто заходил в зону погрузки после 22:00 вчера» – выдаёт конкретные клипы, таймкоды и письменный ответ. Система построена на реальном стеке 2026 года, а не на абстрактных пожеланиях. Основой архитектуры стал каскад с приоритетом поиска: дешёвый детектор и поисковый индекс отфильтровывают миллионы кадров до небольшой группы клипов-кандидатов, и только они попадают на обработку к дорогой vision-language-модели, которая анализирует их и формирует ответ – всё под управлением агента, планирующего расследование как младший аналитик. Мы предоставляем точный список компонентов с решением «строить или покупать» для каждого, схему развёртывания для команды инфраструктуры, модель затрат с расчётами 2026 года на один клип, план из пяти ключевых этапов и чёткую карту регионов, где европейский закон запрещает распознавание лиц. В то время как урок главы 7 про агента-исследователя объяснял, что это за агент, итоговый проект – это проект, который вы реально выполняете от начала до конца, включая чек-лист запуска.

Почему это важно

Статья для основателя или продакт-менеджера, который решил создать продукт ИИ-анализа видео – для физической безопасности, защиты от потерь в ритейле, промышленной безопасности или умных зданий – и теперь должен понять, сколько реально стоит такая система, сколько времени она занимает, какие компоненты покупаются, а какие разрабатываются с нуля, и где закон проводит жёсткую границу. Она одинаково полезна и инженеру, который прошёл отдельные уроки по computer vision и хочет увидеть, как их можно собрать в одну развёртываемую систему с конкретными технологиями и цифрами. Мы предполагаем, что базовые идеи вам уже знакомы: статья собирает знания воедино, а не объясняет с нуля, и перекрёстные ссылки ведут к каждому ключевому уроку, если нужны детали. К концу вы сможете нарисовать архитектуру продакшена на доске, указать конкретную технологию 2026 года в каждом блоке, обосновать стоимость одного расследования перед финансистами, спланировать сборку так, чтобы первая версия вышла за несколько недель, и отличить законную систему от той, что будет выведена с европейского рынка штрафом.

Что именно вы строите

Зафиксируйте продукт прежде любой технологии. Вы строите систему, которая сидит поверх уже записанного камерами видео и по запросу отвечает на вопросы о нём. Пользователь пишет вопрос обычным языком – «блокировал ли погрузчик пожарный выход № 3 во время вчерашней ночной смены?» – и система возвращает клипы, которые на это отвечают, каждый с таймкодом и абзацем письменного объяснения того, что найдено. Это не робот, который смотрит на стену мониторов и жмёт тревогу; это аналитик-в-софте, который делает просмотр за человека, чтобы тому не пришлось вручную пролистывать часы видео кадр за кадром.

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

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

Хребет: каскад поиска и паттерн агента

Две идеи держат всю конструкцию. Сделайте их правильно – остальное – детали.

Первая – каскад поиска, та самая «коробка раскрытия», доведённая до конкретики. Сырой видеопоток огромен: одна камера 1080p при 15 кадрах в секунду даёт около 1,3 миллиона кадров в день, а сеть из 200 камер – более 250 миллионов кадров в сутки. Ни одна система не может позволить себе прогонять сложную, медленную модель через каждый такой кадр. Поэтому строится воронка. Быстрый и дешёвый детектор просматривает каждый кадр и помечает только те, где что-то происходит – человек, автомобиль, оставленная сумка. Поисковый индекс затем преобразует эти помеченные моменты в формат, пригодный для запросов по описанию. Когда поступает запрос, индекс возвращает короткий список клипов-кандидатов, и только он – несколько десятков клипов, а не сотни миллионов кадров – передаётся дорогой модели, которая тщательно анализирует видео. Каждая ступень дешевле в расчёте на единицу обработки и обрабатывает больше данных, чем ступень выше; каждая передаёт следующей куда меньше работы. Это ключевое архитектурное решение системы, и к его арифметике мы вернёмся ниже.

Вторая идея – ИИ-агент как оркестратор. Вместо жёстко заданной последовательности шагов вы пишете небольшую программу, которая планирует расследование, как младший аналитик: читает вопрос, решает, какие инструменты использовать и в каком порядке, запускает их, анализирует результаты и определяет, достаточно ли полученной информации для ответа или нужно продолжить. Инструменты на её «поясе» – это как раз ступени каскада: детектор, поисковый индекс, трекер, отслеживающий одного человека между камерами, и «читатель» видео. Это цикл агента из уроков главы 7, применённый к набору компонентов компьютерного зрения; урок про цикл агента для видео – концептуальная основа, а урок про агента-исследователя подробно разбирает сам цикл. Здесь мы принимаем цикл как данность и строим вокруг него масштабируемую систему.

Держите обе идеи вместе – и платформа обретает чистую форму. Каскад определяет, какая работа настолько дёшёва, что её можно запускать повсеместно, и какая настолько дорогая, что её выполняют только по короткому списку. Агент решает, какие инструменты вызвать для конкретного вопроса. Всё остальное в статье – это наполнение блоков, выбор «строить или покупать» и расчёт стоимости.

Производственная архитектура, блок за блоком

Реальное развёртывание – это не только детектор и модель. В каждой системе видеонаблюдения, которую мы оценивали, присутствуют семь типов компонентов, и точное их определение – это первый шаг любого проекта.

Слой камер и приёма – это место, куда поступает видео. Камеры передают поток – почти всегда по протоколу RTSP, который является стандартным способом публикации живого видео – в рекордер. Вы не настраиваете это сами; вы получаете потоки с уже установленного на объекте оборудования.

Система управления видео, повсеместно сокращаемая VMS, – это программное обеспечение, которое записывает видеопотоки, хранит их и управляет сроками хранения, то есть определяет, сколько дней видео остаётся до удаления. Это зрелая, скучная, но необходимая инфраструктура с устоявшимися вендорами (Milestone, Genetec и облачный Eagle Eye Networks среди них). С VMS вы интегрируетесь – её не переписываете.

Слой edge-инференса – это быстрый и недорогой детектор, работающий рядом с камерами. «Edge» означает, что он работает на небольшом компьютере на стороне клиента, а не в удалённом дата-центре – и это важно: передача полного видео с каждой камеры в облако слишком дорога и медленна. В 2026 году такой слой обычно представляет собой детектор уровня YOLO11, запущенный на устройстве NVIDIA Jetson через пайплайн DeepStream – специализированный инструмент для одновременной обработки множества видеопотоков. Устройство Jetson Orin AGX способно обрабатывать примерно 8–16 камер; выбор оборудования зависит от количества камер.

Слой трекинга и событий превращает сырые детекции в данные, пригодные для индексации. Детектор сообщает: «в этом кадре есть человек»; трекер объединяет покадровые рамки в непрерывную траекторию: «это один человек, появился в 22:04, ушёл в 22:09». Мультиобъектные трекеры, такие как ByteTrack, выполняют эту сшивку, а видеосегментатор вроде SAM 2 может выделить точную форму объекта во времени – когда расследованию требуется чёткий контур, а не приблизительная рамка. Опциональный детектор аномалий работает на этом же уровне, выявляя необычные паттерны движения без предварительного указания, что именно искать.

Поисковый индекс – память системы и сердце поиска на естественном языке. По мере обнаружения событий система преобразует каждый клип в набор чисел – эмбеддинг, – отражающий его смысл, как отпечаток пальца отражает личность. Эти эмбеддинги хранятся в векторной базе данных – хранилище, предназначенном для ответов на запросы вроде «найди клипы, наиболее похожие на это описание». Когда пользователь вводит фразу «человек в красной куртке у входа», она также преобразуется в эмбеддинг, и база возвращает наиболее близкие совпадения. Это и есть движок видео-РАГ, рассмотренный в уроке 4.6.

Слой рассуждения – это «читатель» видео: vision-language-модель, или VLM – модель, способная обрабатывать кадры видео и текстовый вопрос, отвечая на него словами. Здесь Qwen-VL или аналогичная модель анализирует короткий список кандидатских клипов, определяет, какие из них действительно отвечают на вопрос, и формирует вывод. Это самый мощный, но и самый дорогой компонент – именно поэтому каскад старается передавать ему лишь несколько клипов. Урок 4.4 про открытые vision-language-модели подробно разбирает выбор моделей.

Прикладной слой – всё, с чем взаимодействует человек: строка поиска, экран результатов с клипами и таймкодами, журнал аудита и дело, куда сохраняются выводы. Это обычная веб-территория – база данных, API, объектное хранилище для клипов и отчётов – и она намеренно скучная, потому что сложные задачи решены в другом месте. Здесь человек-ревьюер подтверждает или отклоняет каждый вывод, прежде чем он станет результатом.

Нажмите, чтобы увеличить

Рисунок 1. Производственное развёртывание. Дешёвый edge-детектор работает повсюду; индекс эмбеддингов делает видео доступным для поиска по описанию; агент вызывает дорогую vision-language-модель только на коротком списке; человек подписывает результат прежде, чем он станет финальным.

Build vs Buy: вердикт 2026 года, по компонентам

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

Две ячейки заслуживают сноски, потому что в 2026 году они изменились. Выбор детектора больше не сводится к принципу «новее – лучше»: семейство YOLO продолжало выходить – версии v12 и v13 появились в 2025 году – но разработчик, компания Ultralytics, прямо рекомендует использовать более старый YOLO11 (или упрощённую версию YOLO26) в продакшене, поскольку насыщенные вниманием v12 и v13 вызывают нестабильность обучения, увеличивают потребление памяти и работают медленнее на обычных процессорах при минимальном приросте точности. Итоговый проект, тянущийся к самой высокой версии, предлагает более медленный и хрупкий детектор; правильный выбор для продакшена – стабильный.

В ячейке эмбеддинги-и-поиск теперь появилась реальная опция «купить», которой несколько лет назад не существовало: управляемые сервисы видеоэмбеддингов, такие как Twelve Labs Marengo (версия 3.0 на начало 2026 года), превращают видео в поисковые эмбеддинги через API, позволяя небольшой команде реализовать поиск по естественному языку без развёртывания собственной модели.

Рассуждения о детекторах и трекерах – тема урока 2.2 про линейку YOLO и урока 2.4 про SAM 2 для видео.

Нажмите, чтобы увеличить

Рисунок 2. Что строить, а что брать. Паттерн совпадает с каждой системой курса: интегрируйте зрелую инфраструктуру, берите или покупайте модели, стройте только логику агента и опыт, которые вас отличают.

Одно расследование: от вопроса до клипа

Числа и блоки обретают смысл, когда проследить один вопрос через систему. Возьмём расследование: руководитель смены на складе задаёт вопрос: «Оставалась ли дверь зоны погрузки открытой дольше десяти минут после того, как вчера вечером уехала последняя фура?»

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

Сначала агент запрашивает поисковый индекс на «фура у зоны погрузки» в видео вчерашнего вечера. Поскольку каждое обнаруженное событие уже превратилось в эмбеддинг при появлении, это быстрый поиск по базе, а не скан видео; он возвращает горстку клипов-кандидатов, ранжированных по совпадению. Агент читает таймкоды и находит последний отъезд фуры в 21:47.

Дальше агент сужает временной интервал – до 21:47 – и запрашивает индекс «дверь зоны погрузки, открыта». Быстрый поиск по заранее вычисленным эмбеддингам снова возвращает короткий список. Только теперь агент тратит реальные деньги: он отправляет эти несколько клипов vision-language-модели с точным вопросом: «Открыта ли дверь на этом клипе и свободна ли в остальном зона?». Модель анализирует кадры и по каждому клипу даёт словесный ответ с указанием времени, когда дверь была открыта. Агент собирает эти временные метки в единый интервал – с 21:49 до 22:06 – и проводит арифметику (22:06 − 21:49 = 17 минут, что превышает порог в десять минут). В итоге он формулирует вывод: «Дверь зоны погрузки оставалась открытой примерно 17 минут после отъезда последней фуры в 21:47, с 21:49 до 22:06».

Черновик не уходит пользователю как факт. Он попадает в экран ревью, где человек видит вывод, опорные клипы и таймкоды и подтверждает или правит его прежде, чем тот сохранится в дело. Каждый шаг – каждый вызов инструмента, каждый доставленный клип, каждый ответ модели – пишется в журнал аудита, чтобы спустя недели кто угодно мог восстановить, как именно система пришла к выводу.

Обратите внимание на дисциплину. Два дешёвых поиска по индексу позволили быстро сузить выборку; дорогая модель обрабатывала лишь несколько клипов, а не весь видеоряд; арифметика продемонстрирована явно; человек подтвердил результат. Эта форма – не украшение, а именно то, что обеспечивает скорость, доступность и безопасность системы.

Нажмите, чтобы увеличить

Рисунок 3. Одно расследование, от начала до конца. Дешёвые поиски по индексу сужают выборку; дорогая модель анализирует только короткий список; арифметика показана явно; человек подписывает документ перед тем, как что-либо сохранится.

Каскад, делающий систему доступной

Вся система зависит от одного ключевого решения: никогда не запускайте дорогую модель на объёме видео больше, чем необходимо. Каскад – это способ, которым вы это обеспечиваете, и воронку стоит проиллюстрировать цифрами.

Представьте одну камеру, снимающую в течение суток с частотой 15 кадров в секунду. Это 15 × 60 × 60 × 24 = 1 296 000 кадров – примерно 1,3 миллиона. На первом этапе, edge-детектор, обрабатывает все кадры, потому что это дешево: детектор уровня YOLO обрабатывает один кадр за несколько миллисекунд на Jetson, а большинство кадров не содержат ничего интересного и сразу отбрасываются. Допустим, 5 процентов кадров содержат человека или машину, которые стоит отметить – это около 65 000 кадров, сгруппированных трекером, возможно, в 1500 отдельных событий (проходящий человек – это одно событие на многих кадрах, а не сотни отдельных срабатываний).

Ступень два, индексация, превращает эти 1500 событий в эмбеддинги и сохраняет их. Это относительно недорого и выполняется один раз – при обнаружении события, а не при поиске. Теперь видео за сутки становится доступным для поиска.

Ступень три работает только когда задан вопрос. Индекс возвращает, скажем, топ-20 клипов-кандидатов по запросу. На четвёртой ступени vision-language-модель анализирует эти 20 клипов – а не 1,3 миллиона кадров. Модель никогда не видит 99,998 процента кадров из всех поступающих. В этом и заключается ключевая идея: дорогостоящую «читательскую» модель просят просмотреть всего двадцать клипов, и вопрос решается за секунды и несколько центов вместо часов и сотен долларов.

Проговорим сравнение вслух. Если наивно отправлять каждый кадр в frontier-visual-language-модель, даже при оптимистичной цене в один цент за кадр вы потратите 1 300 000 × $0,01 = $13 000 на одну камеру в сутки – абсурд, и это ещё до умножения на сотни камер. В каскаде модель обрабатывает 20 клипов на запрос; при нескольких центах за клип стоимость запроса оказывается значительно ниже доллара, а единственная постоянная нагрузка – дешёвый edge-детектор и умеренная индексация. Разница не в тюнинге; это разница между жизнеспособным продуктом и банкротством.

Нажмите, чтобы увеличить

Рисунок 4. Воронка каскада. Каждая ступень дешевле в расчёте на единицу и обрабатывает больше единиц, чем предыдущая; дорогой «читатель» видит только короткий список. Именно этот выбор и отличает жизнеспособный продукт от неподъёмного.

Модель затрат с показанной арифметикой

Правильно оценить систему – значит понять, что затраты бывают трёх видов, и только один из них растёт с каждой секундой работы камер. Рассмотрим конкретный пример: площадка из 50 камер за месяц, в течение которого сотрудники подают около 500 запросов на расследование.

Постоянная edge-стоимость – это детектор, работающий на каждой камере круглосуточно. Это аппаратное решение, а не оплата за кадр: Jetson Orin AGX справляется примерно с 8–16 потоками, так что для 50 камер потребуется около четырёх таких устройств. Затраты включают единовременную покупку оборудования и расходы на электроэнергию – порядка нескольких тысяч долларов на аппаратуру, амортизируемую в течение нескольких лет, плюс небольшой счёт за электричество. Главное: эти расходы не растут при увеличении числа запросов; они зависят только от количества камер, которое известно заранее.

Стоимость индексации – это преобразование обнаруженных событий в эмбеддинги по мере их поступления. Она зависит от объёма активности, фиксируемой камерами, а не от общей продолжительности видео: пустой коридор в три часа ночи почти не генерирует событий для индексации. Для оживлённой площадки с 50 камерами это стабильная и умеренная вычислительная нагрузка – независимо от того, используете ли вы собственную модель для генерации эмбеддингов или платный сервис вроде Twelve Labs за минуту проиндексированной активности. Планируйте эту статью расходов как фиксированную месячную статью в нижних сотнях долларов для площадки такого масштаба.

Стоимость рассуждения на запрос – это vision-language-модель, обрабатывающая клипы из короткого списка, и она зависит от количества расследований, а не от числа камер или часов видео. Допустим, каждый запрос отправляет модели около 20 клипов, а каждый клип обходится в несколько центов на обработку; в итоге это составляет примерно $0,50–1,00 на одно расследование. Для 500 запросов в месяц: 500 × $0,75 ≈ $375 на рассуждения в месяц. Самостоятельный запуск VLM на собственном GPU заменяет эту стоимость расходами на сервер – это выгоднее при большом и стабильном объёме запросов, но становится дороже, если учитывать затраты на инженеров, поддерживающих GPU.

Сложите формы: несколько тысяч долларов на единовременную закупку edge-оборудования, пара сотен долларов в месяц на индексацию и несколько сотен – на вычисления. Важна не точная цифра, а форма: система, которая непрерывно запускает умную модель на каждой камере, обходилась бы в кошмарные $13 000 в сутки на одну камеру, как показано в предыдущем разделе, тогда как здесь речь идёт о дешёвом edge-оборудовании плюс несколько сотен долларов на время работы модели в месяц. Поняв форму – вы сможете правильно оценить и масштабировать решение. Полный набор рычагов по снижению затрат – от точки безубыточности при самохостинге до выбора модели и квантизации – раскрывается в уроке 8.4 про оптимизацию затрат на видео-ИИ.

Частая ошибка: обрабатывать каждый кадр с помощью «умной» модели

Сбой, с которым нас чаще всего просят помочь в видео-ИИ-продуктах, – не слабая модель, а хорошая модель, обученная на слишком большом количестве видео. Проблема проявляется в трёх версиях, и все они решаются на этапе архитектуры, а не при дообучении.

Первая – непрерывно прогонять vision-language-модель по каждому кадру с камер, чтобы ничего не упустить. Это выглядит привлекательно простотой, но крайне дорого: стоимость растёт как произведение кадров × камер × секунд – трёх самых больших чисел в системе. Решение – каскад: дешёвый детектор и поисковый индекс сужают объём работы, а умная модель анализирует только короткий список. Если стейкхолдер настаивает, что модель должна обрабатывать всё в реальном времени, это уже другой, гораздо более дорогой продукт – и, как показывает следующий раздел, зачастую незаконный.

Вторая – индексировать на этапе запроса, а не на этапе обнаружения. Команда строит поиск, а потом вычисляет эмбеддинги только когда пользователь ищет, и каждый запрос занимает минуты, потому что заново сканирует видео. Эмбеддинги нужно вычислять один раз, при обнаружении события, и хранить; поиск тогда становится мгновенным запросом к базе. Сделать наоборот – превратить поиск за доли секунды в многоминутный и тихо ограничить, сколько пользователей система потянет.

Третья – доверять ответу модели без участия человека. Vision-language-модели уверены даже в ошибках, а при zero-shot-детекции аномалий у них зафиксирован систематический перекос в сторону вывода «норма», из-за чего они пропускают реальные события, выдавая при этом уверенность. Любой вывод, влекущий последствия – отчёт, эскалацию, обращение к человеку – должен подтверждаться человеком-ревьюером. Это не просто хорошая инженерная практика; в Европе для высокорисковых приложений это уже почти требование закона. Внедряйте этап ревью с самого первого майлстоуна: добавлять его позже означает перерабатывать каждый путь обработки результата.

План сборки: пять этапов, ценность на каждом шаге

Вы не строите всё сразу и не следуете порядку, в котором нарисована схема. Вы строите так, чтобы после первого майлстоуна уже был рабочий продукт, а каждый следующий выпуск происходил независимо – это позволяет проекту оставаться финансируемым, а команду – мотивированной.

Майлстоун 1 – поиск по записанному видео. Поднимите интеграцию с VMS, edge-детектор, трекер, индекс эмбеддингов и простую строку поиска. Запустите возможность ввести запрос «человек у бокового входа после 21:00» и получить ранжированные клипы. Пока без агента и без vision-language-модели – только быстрый поиск. Уже это заменяет часы ручного просмотра и становится фундаментом, к которому крепится всё остальное. Если он шаткий, никакая ловкость агента продукт не спасёт.

Майлстоун 2 – шаг чтения. Добавьте модель, объединяющую визуальное и языковое восприятие, как вторую ступень: она анализирует топовые клипы из поисковой выдачи и составляет краткое однострочное описание каждого. Продукт переходит от «вот клипы, которые могут подойти» к «вот что происходит на этих клипах – словами». Именно в этот момент пользователи начинают чувствовать, что система действительно понимает видео, а не просто его индексирует.

Майлстоун 3 – цикл агента. Оберните поиск и «читателя» в агента, способного планировать многошаговые расследования: сначала найти последнюю фуру, затем проверить дверь, затем измерить длительность – вместо ответов на одношаговые запросы. Здесь продукт превращается из поисковика в исследователя и переиспользует уже построенные компоненты поиска и чтения. Урок про агента-исследователя – чертёж этого майлстоуна.

Майлстоун 4 – слой ревью и аудита. Создайте экран подтверждения с участием человека в цикле, а также реализуйте журнал аудита, фиксирующий каждый вызов инструмента и каждый клип. Этот этап делает систему защищённой – перед службой безопасности клиента, перед аудитором и перед регулятором. Здесь же размещаются функции цепочки хранения для любого клиента, который может использовать вывод в формальных процессах.

Майлстоун 5 – регулируемые расширения. Детекция аномалий, межкамерный трекинг одного человека и любые функции, связанные с личностью, реализуются последними – потому что они дороже, шумнее и несут наибольшую нагрузку с точки зрения соответствия нормативным требованиям. Функции, касающиеся идентификации, нужно проектировать с учётом правовой карты ниже ещё до написания первой строки кода – для некоторых рынков ответ может быть таким: их вообще не стоит создавать.

Лестница из пяти майлстоунов, эталонный стек, вердикты «строить или покупать» и чек-лист запуска и соблюдения закона собраны на одной странице в скачиваемом блюпринте в конце статьи – чтобы команда могла повесить его на стену и следовать по шагам сверху вниз.

Трудная часть: чего закон не позволит системе

Видеосистема, используемая в демо-режиме, – это не продукт, если её незаконно эксплуатировать там, где находятся ваши клиенты. Для систем видеонаблюдения, разрабатываемых или продаваемых в Европейском союзе, закон теперь чётко сформулирован, имеет конкретную дату вступления в силу и является строгим – этот раздел статьи особенно важен для прочтения до начала написания кода. Это инженерный контекст, а не юридическая консультация; уточняйте детали у юристов, работающих на вашем рынке.

Управляющий текст – AI Act Европейского союза, Регламент (ЕС) 2024/1689, – делит применения этой системы на три принципиально разных категории.

Первая коробка – прямой запрет. Согласно статье 5, использование ИИ для удалённой биометрической идентификации людей в реальном времени в общедоступных местах в целях правоприменения запрещено, за исключением отдельных случаев (поисков пропавших или жертв, предотвращение неминуемой террористической угрозы, установление личности подозреваемого в тяжком преступлении – при наличии санкции). Акт также запрещает создание баз данных лиц путём сбора информации с интернета или с камер видеонаблюдения, а также определение эмоций на рабочих местах и в школах. Эти запреты вступают в силу 2 февраля 2025 года. Практическая граница для вашего продукта: функция, которая анализирует живые видеопотоки с камер в общественных местах с целью установить, кто перед камерой, по его лицу, – находится по неправильную сторону закона, если вы не правоохранительный орган и не действуете в рамках узкого санкционированного исключения. Большинство коммерческих продуктов просто не должны этого делать.

Вторая коробка – высокий риск, но разрешено. Анализ записанного видео постфактум для установления личности по биометрическим данным – так называемое постфактумное распознавание лиц – относится к высокорисковым системам согласно Приложению III, но не запрещён. Оно разрешено, однако только при соблюдении всех требований комплаенса: наличие задокументированной системы управления рисками, технической документации, логирования, человеческого надзора, тестирования точности и устойчивости, а также регистрация в базе данных ЕС. Эти обязательства для высокорисковых систем вступают в силу 2 августа 2026 года. Если в вашей дорожной карте предусмотрено установление личности конкретных людей по архивному видео, вы создаёте высокорисковую систему, и требования к комплаенсу необходимо закладывать с самого начала, а не добавлять задним числом.

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

Две обязанности прозрачности завершают общую картину. Статья 50 того же Регламента, вступающая в силу 2 августа 2026 года, обязывает раскрывать сгенерированные или изменённые с помощью ИИ медиа как таковые – это особенно важно, если ваш продукт когда-либо создаёт синтетическую реконструкцию. А проверка с участием человека, предусмотренная на этапе Майлстоуна 4, – это не просто хорошая практика для высокорисковых применений; осмысленный человеческий надзор является одним из прямых требований закона. Полная регуляторная картина, включая правила работы с биометрическими данными и статью 50, – тема урока 8.5 про инжиниринг под EU AI Act.

Нажмите, чтобы увеличить

Рисунок 5. Правовая карта. Поиск по описанию остаётся в самой лёгкой коробке; идентификация живых лиц в общественных местах запрещена; постфактумная идентификация лиц – высокий риск. Намеренно ограничьте продукт рамками самой лёгкой коробки и уточняйте у юристов для каждого рынка.

Эксплуатация: цепочка хранения, наблюдаемость и безопасность

Три ключевых аспекта отделяют прототип от продукта, который служба безопасности купит и которому доверится.

Цепочка хранения – это дисциплина, позволяющая впоследствии доказать подлинность и неизменность клипа, а также показать, как был получен вывод. Журнал аудита из Майлстоуна 4 – его основа: каждый вызов инструмента, каждый полученный клип и каждый ответ модели фиксируются с отметкой времени и остаются неизменяемыми. Для любого клиента, который может использовать результат в страховом случае, HR-процессе или судебном разбирательстве, это не просто внешний блеск, а необходимая функция, без которой результат вообще не может считаться пригодным. Храните оригинальные клипы рядом с производными выводами и никогда не перезаписывайте исходные данные.

Наблюдаемость означает, что вы понимаете, почему расследование прошло неудачно, уже после его завершения. Видео-ИИ-системы «падают» иначе, чем обычные веб-приложения: камера вышла из фокуса, edge-устройство отстало и начало терять кадры, модель выдала уверенный, но ошибочный ответ. Чтобы разобраться в таких ситуациях, нужны трассировки по ходу расследования – какие инструменты сработали, сколько времени заняли, сколько клипов обработано, что именно ответила модель. Эти данные должны собираться централизованно, чтобы служба поддержки могла ответить на вопрос: «Почему система пропустила событие, которое точно имело место?» – без догадок. Заложите это на этапе Майлстоуна 1: добавлять телеметрию в уже работающий пайплайн будет болезненно.

Безопасность и минимизация данных начинаются с того, что видео – один из самых чувствительных типов данных компании. Шифруйте видеофрагменты как при хранении, так и при передаче, строго контролируйте доступ к тем, кто может инициировать расследования и просматривать результаты, и храните видео не дольше, чем это предусмотрено политикой хранения и требованиями законодательства – минимизация объёма хранимых данных одновременно является мерой безопасности и, согласно законам о защите персональных данных, юридической обязанностью. Для клиентов из регулируемых отраслей возможность развертывания всего пайплайна на собственных серверах (self-hosting), чтобы видео никогда не покидало их инфраструктуру, часто становится решающим фактором, и данная архитектура это поддерживает: каждый компонент может работать на оборудовании клиента.

Где здесь Фора Софт

Фора Софт разрабатывает видеософт с 2005 года, и системы компьютерного зрения для видеонаблюдения – одна из наших ключевых вертикалей, наряду с видеоконференциями, стримингом, e-learning и телемедициной. Описанная здесь система – зрелая VMS снизу, edge-детектор по всему, индекс эмбеддингов, делающий видео поисковым по описанию, агент, вызывающий vision-language-модель только на коротком списке, и человек-ревьюер, который подтверждает результаты, – это основа наших работ в области видеонаблюдения и интеллектуальной видеоаналитики. Порядок сборки и решения «строить или покупать» в этой статье для нас не теория – это чек-лист, который мы реально применяем, потому что от него зависит разница между инструментом расследования, работающим за секунды и стоящим копейки, и системой, которая либо пропускает события, либо выносит неподъёмный счёт. Правовая карта – тоже часть этого чек-листа: мы намеренно ограничиваем продукты минимальной функциональной «коробкой», потому что блестящая, но запрещённая функция не дойдёт ни до кого. Наша работа – в сфере видеонаблюдения и интеллектуальной видеоаналитики, где компьютерное зрение в реальном времени по записанному видео является ядром продукта, а не дополнительным украшением.

Ключевые выводы

• Хребет системы – каскад: дешёвый детектор по всему кадру, дорогая модель – только на коротком списке кандидатов.
• Интегрируйте VMS, используйте детектор и трекер, реализуйте логику агента и наращивайте опыт.
• Выбирайте стабильный детектор (например, YOLO11), а не самую новую версию; v12/v13 пока не готовы к продакшену.
• Вычисляйте эмбеддинги на этапе обнаружения – тогда поиск будет мгновенным, а не повторным сканированием.
• Каждый вывод должен подтверждаться человеком; vision-language-модели часто уверены в себе, даже когда ошибаются.
• Ограничьте поиск по описанию, чтобы оставаться в рамках «лёгкой» категории EU AI Act; живая идентификация лиц в общественных местах запрещена.

Что почитать дальше

• Урок 7.4 – Агент-исследователь: кейс видеонаблюдения
• Урок 9.5 – ИИ-видеонаблюдение и интеллектуальная видеоаналитика: инженерный плейбук
• Урок 4.6 – Видео-РАГ: мультимодальный поиск по видеоархиву