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

Автор: Николай СапуновОбновлено: август 202638 мин чтения
Содержание статьи +

TL;DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слой камер и приёма – место, где видео входит. Камеры отдают поток – почти всегда по протоколу 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 может вырезать точную форму объекта во времени, когда расследованию нужен точный контур, а не грубая рамка. Опциональный детектор аномалий живёт здесь же, помечая необычные паттерны движения без указания, что искать.

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

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

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

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

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

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

КомпонентСтроить или купитьКонкретный выбор 2026Почему
VMSИнтегрироватьMilestone, Genetec или Eagle Eye NetworksЗапись и ретенция – решённая, регулируемая область; не переписывайте VMS
Edge-детекторВзять open-модельYOLO11 на Jetson через DeepStreamЗрелый, быстрый; Ultralytics не советует v12/v13 в продакшен
Трекер / сегментаторВзять open sourceByteTrack; SAM 2 / SAM 3 для масокСтандарт, бесплатно, проверено всей индустрией
Детектор аномалийВзять или сначала пропуститьМодель уровня BN-WVAD или VLM-промптПолезен, но шумит; добавляйте после поиска, а не до
Эмбеддинги + индексВзять или купитьOpen-эмбеддинги + вектор-БД, или Twelve Labs MarengoДвижок поиска; покупайте модель при умеренном объёме
Vision-language-читательКупить или self-hostСемейство Qwen-VL (self-host) или VLM APIМодели улучшаются ежемесячно; self-host только при больших объёмах
Оркестрация агентаСтроить на фреймворкеLangGraph или сравнимый фреймворкЛогика управления – ваш продукт; фреймворк – это трубы
Приложение, аудит, ревьюСтроитьВаш стекЭто ваш продукт – опыт, дело и защитные механизмы

Две ячейки заслуживают сноски, потому что в 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-vision-language-модель, даже при оптимистичном одном центе за кадр вы потратите 1 300 000 × $0,01 = $13 000 на камеру в сутки – абсурд, и это до умножения на сотни камер. С каскадом модель касается 20 клипов на запрос; при нескольких центах за клип запрос стоит сильно меньше доллара, а единственная постоянная стоимость – дешёвый edge-детектор и умеренная индексация. Разница не в тюнинге; это разница между жизнеспособным продуктом и банкротом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наблюдаемость значит, что вы видите, почему расследование пошло не так, после того как оно закончилось. Видео-ИИ-системы падают так, как обычные веб-приложения не падают, – камера ушла из фокуса, edge-устройство отстало и роняет кадры, модель вернула уверенный неверный ответ. Нужны трассы по расследованию (какие инструменты отработали, сколько заняли, сколько клипов прочитано, что сказала модель), собираемые централизованно, чтобы поддержка могла ответить «почему система пропустила событие, которое точно было?» без угадывания. Стройте это с Майлстоуна 1; ретроспективно встраивать телеметрию в живой пайплайн больно.

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

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

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

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

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

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.