Чому AI-система безпеки пропускає реальні інциденти
Ложні тривоги та пропуск інцидентів — зазвичай не два різні дефекти, а наслідок одного: детектор навчений на усередненій сцені. Його калібрують на типовому об'єкті — рівне світло, чисті ракурси, денна зйомка.
На живому периметрі камера дивиться в контражур, взимку матриця йде в шум, а рух у кадрі дає заметіль. Щоб зняти потік хибних тривог, поріг чутливості підвищують — і разом із шумом відсікаються реальні події.
Зони аналітики розмічають під зручність монтажу, а не під сценарій охорони: маски закривають ділянки, які заважають калібруванню — смугу перед воротами, сходовий марш, стик двох камер.
Людина проходить через таку зону, траєкторія розсипається на фрагменти, і правило «об'єкт у забороненій області довше заданого часу» не набирає умов. Це не помилка моделі, а помилка розмітки — і вона відтворюється на кожному схожому інциденті.
Остання ланка — рішення щодо тривоги, і його ухвалює людина в нічну зміну. За сотень спрацювань за зміну, з яких більшість порожні, оператор перестає розбирати кожну картку: перевіряє вибірково, реагує із затримкою, а справжній інцидент знаходить за архівом наступного дня.
Ланцюг рветься в трьох місцях: навчання на чужій статистиці, розмітка під монтаж замість сценарію охорони, відсутність автоматичних правил на етапі ухвалення рішення. Розбираємо, як кожне з цих місць закривається.
Що змінюється після впровадження: швидкість реакції та частка помилок
Ефект від AI-системи безпеки вважають не за кількістю камер, а за чотирма метриками, які знімаються з єдиного журналу подій і змінних звітів. До впровадження їх зазвичай ніхто не веде: оператор працює за відчуттями, а розбір інциденту починається з питання, хто був на зміні.
- Час до підтвердження тривоги. Подія надходить на пост із доданим фрагментом і розміткою, тому охорона їде на підтверджену ситуацію, а не на сигнал про рух. Шлях від спрацювання до рішення скорочується з хвилин до десятків секунд.
- Частка хибних тривог. Система розрізняє людину, транспорт і перешкоду на кшталт відблиску або гілки, що гойдається — спрацювання йде на об'єкт, а не на зміну картинки. Наряди перестають виїжджати на тіні, зміна не витрачає час на перевірку порожніх кадрів.
- Навантаження на чергову зміну. Оператор бачить не стіну плиток, а чергу пріоритетних подій: рутинні проходи позначаються автоматично. Парк камер на об'єкті зростає, а кількість одночасних потоків на одну людину — ні.
- Розбір інциденту за єдиним журналом. Спрацювання, дії оператора й команди наряду лягають в одну стрічку з мітками часу та посиланнями на записи. Історія піднімається за хвилини, без ручного зведення архівів із різних реєстраторів.
Окремо йде клас відмов, за якого тривога є, а реакції немає: система тримає лічильник непідтверджених подій і ескалує їх за регламентом.
Камери будь-яких виробників із профілем ONVIF стають у спільний контур без заміни парку, тому метрики вважаються за об'єктом загалом, а не за однією лінійкою обладнання.
Порівнювати результат коректно на однаковому вікні спостереження до і після — зазвичай це два-чотири тижні змін.
Порівняння режимів роботи: пост охорони, гібрид, автономний контур
Режим роботи контуру визначає не модель розпізнавання, а те, де ухвалюється рішення і що відбувається при втраті зв'язку.
Локальний контур обробляє потік на об'єкті, гібридна схема виносить ресурсомісткі задачі в центр, а пост охорони залишається точкою ухвалення рішення щодо тривоги. Вибір між ними — компроміс між повнотою аналітики та стійкістю майданчика.
На практиці частіше працює гібрид: локальні модулі тримають виявлення й тривожну логіку, центр — розпізнавання за базою та зведену аналітику.
При обриві каналу об'єкт переходить в автономну охорону: події пишуться в буфер, тривоги відпрацьовуються за локальними правилами, а після відновлення зв'язку архів доганяється без втрати записів.
| Режим роботи контуру | Коли підходить | Чесні обмеження |
|---|---|---|
| Автономна охорона об'єкта (локальний контур) | Віддалені майданчики, нестабільний канал, вимога зберігати дані на території об'єкта | Живе за локальною базою: розпізнавання за рідкісними сценаріями та незнайомими особами слабше, оновлення моделей потребує виїзду або захищеного каналу |
| Гібридна схема | Розподілені та міські об'єкти зі стійким каналом, де потрібна страховка на випадок обриву | Частина аналітики недоступна офлайн, тому заздалегідь задається пріоритет: що йде в центр, а що вирішується на місці |
| Пост охорони в контурі | Об'єкти з регламентом реакції людиною та високою ціною хибного спрацювання | Швидкість залежить від зміни, а точність — від того, наскільки зручно оператору розбирати тривогу |
Режим не обирається «на око»: ми заміряємо доступність каналу, частку часу офлайн-роботи та кількість тривог за зміну, а потім розкладаємо ролі між локальним контуром і центром.
Етапи впровадження: від обстеження об'єкта до передачі регламентів
Роботи йдуть шістьма етапами, і в кожного є точка приймання: поки замовник не підтвердив результат кроку, наступний не починається. Це захищає від класичної ситуації, коли обладнання змонтовано, а сценарії тривог на реальному потоці ніхто не перевіряв.
- Обстеження об'єкта. Інженери проходять периметр і внутрішні приміщення, фіксують сліпі зони, освітленість у темну пору, стан уже встановлених камер, доступну смугу мережі та точки живлення. На виході — звіт із картою покриття та переліком техніки, яку можна використати повторно без заміни.
- Схема зон спостереження. Об'єкт розбивається за критичністю: периметр, вхідні групи, касова зона, склад, службові проходи. Для кожної зони визначається ракурс і задача — огляд, розпізнавання або ідентифікація. Приймання — узгоджена схема з точною кількістю камер та їхніми позиціями.
- Монтаж та інтеграція. Траси, вузли, накопичувачі під відеоархів із заданою глибиною зберігання, резервування живлення, розмежування доступу операторів. Перевіряється, що запис іде без втрат, а відмова одного вузла не виводить систему цілком.
- Налаштування сценаріїв тривог. Налаштовуються правила: перетин лінії, вхід у заборонену зону поза графіком, залишений предмет, скупчення людей. Добираються пороги чутливості та фільтри, що відсікають тіні, опади, тварин і світло фар. Приймання — прогін на записах реальної доби.
- Калібрування на даних об'єкта. Моделі дообучаються на розмічених кадрах із цього об'єкта — знімається частина хибних спрацювань, які не прибираються налаштуваннями. Приймання — метрики на окремій вибірці, що не брала участі в навчанні.
- Передача документації. Оператор отримує матрицю реакцій на кожен тип події, інструкції з розбору тривог, схему розміщення та журнал змін конфігурації. Навчання зміни йде за цими документами, приймання — оператор самостійно відпрацьовує навчальний сценарій.
Після передачі документації система йде на супровід: нові зони та правки сценаріїв вносяться через той самий журнал, тому конфігурацію можна відтворити й відкотити до попередньої версії.
Що залишається на об'єкті: конфігурації, схеми зон, регламенти
Система фізичної безпеки живе не лише в камерах і моделях — її поведінку визначають конфігурації, схеми та правила. Якщо ці артефакти залишаються в підрядника, об'єкт втрачає керованість: зміна зони або зміна інтегратора перетворюється на відновлення логіки з пам'яті.
Тому комплект документації ми збираємо під час проєкту й передаємо замовнику — у репозиторії та на носії, без закритих форматів.
- Конфігурація рішення — файли з параметрами детекторів, порогами спрацювання та прив'язкою до камер, із яких стенд розгортається з нуля.
- Схеми зон і доступів — плани поверхів із розміткою контрольованих зон, напрямків проходу та рівнів доступу за ролями.
- Матриця прав — хто які події бачить, хто підтверджує тривогу, у кого є право змінювати налаштування й пороги.
- Регламенти для зміни — порядок дій оператора при спрацюванні, час реакції, правила ескалації та передачі зміни.
- Інструкції з розгортання та відновлення — покрокове підняття сервісів, перевірка зв'язків із камерами й контролем доступу, відкат до попередньої конфігурації.
- Схема зберігання подій — де лежать записи й метадані, скільки зберігаються, як вивантажуються на запит служби безпеки.
- Паспорт об'єкта — перелік обладнання, адресація, точки інтеграції та контакти супроводу з розмежуванням зон відповідальності.
Комплект зібрано так, щоб його міг прийняти інший підрядник: описано інтерфейси, формати обміну та зовнішні залежності, а не лише кінцевий результат.
Нова команда розгортає конфігурацію на своєму стенді, звіряє схеми й продовжує роботу — без перепроєктування системи та повторних виїздів на об'єкт.
Кейс: як скоротили потік хибних тривог на розподіленому об'єкті
Що було до впровадження
Клієнт — мережа розподілених об'єктів: кілька десятків майданчиків із власним парком камер на кожному.
Детекція спрацьовувала на рух у зоні, тому в єдиний центр моніторингу надходило 1000-1200 тривог на добу, і до 85% із них були хибними — гілки, прожектори, тіні, тварини, підрядники в неробочі години.
Розбір однієї тривоги займав в оператора 3-4 хвилини, а середня реакція на реальний інцидент сягала 20 хвилин: значущі події тонули в потоці.
Що змінили
Парк камер і реєстратори залишили як є — інтеграція йшла з уже працюючою платформою відеоспостереження Milestone.
На кожному майданчику з'явився модуль детекції, який відсіює події до відправлення в центр: за класом об'єкта, потраплянням у зону та часом доби, із перевіркою за кількома кадрами підряд.
Другий рубіж — серверний: спрацювання з кількох камер однієї ділянки склеюються в одне, короткі та дубльовані гасяться. Оператор отримує не «рух у зоні», а картку з вердиктом і готовим відрізком запису.
Що вийшло за метриками
Потік тривог упав із 1000-1200 до 40-60 на добу, частка підтверджених зросла з 15% до 75%. Реакція на значущу подію скоротилася з 20 хвилин до 40 секунд — оператор бачить її першою, а не після розбору сміття.
Зміна справляється одним оператором замість трьох при тій самій кількості майданчиків, пропусків реальних подій у зоні покриття не зафіксовано. Нові об'єкти підключаємо типовим профілем детекції: майданчик вводиться в контур за години.
Чим AI-відеоаналітика відрізняється від класичного відеоспостереження?
Класичне відеоспостереження реагує на зміну картинки: детектор порівнює пікселі в зоні інтересу й при перевищенні порогу чутливості пише подію «у кадрі щось сталося». Людина це, тінь від хмари чи сніг — система не розрізняє. Оператор отримує потік таких спрацювань і вручну переглядає архів, щоб знайти значуще.
AI-відеоаналітика працює на іншому рівні. Кадр проходить через детектор об'єктів, між кадрами будується траєкторія, і подія описується сценарієм: людина перетнула лінію в забороненому напрямку, підійшла до периметру, залишила предмет, перебуває в зоні довше заданого часу.
Рішення ухвалюється за метаданими — класом об'єкта, координатами, напрямком руху, часом, — а не за яскравістю пікселів.
Відмінності підходів проявляються в точності детекції на складних сценах. Уночі, у дощ або при щільному потоці поріг чутливості, виставлений удень, дає шквал хибних спрацювань, а класифікатор об'єктів відсікає шум.
Порівнювати системи коректно за часткою хибних спрацювань і пропусків на сотню подій та за часом, за який інцидент знаходиться в архіві, — не за кількістю камер.
Різниця принципова там, де потрібна реакція в реальному часі — відкриття шлагбаума, зупинка лінії, оповіщення охорони, — і де потрібен пошук за ознаками замість перегляду доби запису. Якщо задача зводиться до фіксації та зберігання, класична схема залишається розумним вибором.
Аналітику ставлять поверх уже працюючої платформи на кшталт Milestone: парк камер не змінюється, додається лише шар обробки.
Часті питання: хибні тривоги, дані та робота чергової зміни
Ці питання звучать майже на кожній другій зустрічі щодо AI-системи безпеки, тому відповідаємо прямо, без «залежить від сценарію». Нижче — чотири технічні сумніви, які найчастіше гальмують старт.
По зоні постійно ходять люди — чи не буде потоку хибних тривог?
Тривога піднімається не за одиничним кадром, а коли сцена в часі збігається з правилом: вхід у заборонену зону, залишений предмет, рух у неробочі години. Пороги й розклади налаштовуються для кожної камери окремо, тому прохідна в годину пік не перетворюється на чергу спрацювань. Частку відсікання хибних тривог вважаємо на пілотній ділянці до масштабування.
Скільки зберігаються записи і як знайти потрібний епізод?
Зберігання задається правилами: безперервний архів — один строк, тривоги з пов'язаними фрагментами — довше, службові метадані — окремо. Подія пишеться щільніше фонового потоку, тому обсяг зростає передбачувано, а епізод знаходиться за часом, камерою та типом події.
Хто всередині компанії отримає доступ до відео та аналітики?
Доступ будується на ролях: оператор бачить лише свою зону, керівник служби безпеки — усі камери без права вивантаження, адміністратор керує правилами.
Перегляди й вивантаження фіксуються в журналі, а обробка може йти в локальному контурі, якщо кадри не можна виносити за межі об'єкта.
Наскільки складно навчити чергову зміну?
Інтерфейс чергового зведено до трьох дій: підтвердити тривогу, відхилити як хибну, передати наряд.
Навчання займає дві-три зміни по 30-40 хвилин, далі зміна розбирає реальні спрацювання разом із нашими інженерами — зворотний зв'язок дообучає модель під конкретний об'єкт, і рішення ухвалюються без підказок.
Обговоримо задачу: що потрібно знати про ваш об'єкт
Щоб повернутися з оцінкою та планом робіт, а не із загальними обіцянками, потрібні ввідні щодо об'єкта — вони визначають і склад моделей, і вимоги до заліза. Нижче те, що достатньо описати в обговоренні задачі: чим точніші формулювання, тим менше ітерацій у проєкті.
- Перелік зон і точок огляду: периметр, входи, паркування, складські та касові вузли, де камери вже стоять і які задачі вони закривають зараз.
- Якість наявного потоку: стабільність запису, нічна зйомка, ракурси, перекриття. Від цього залежить, чи потягне детектор поточна оптика або потрібна заміна.
- Що вважаємо подією: прохід у заборонену зону, залишений предмет, скупчення людей, спроба проходу вдвох, зняття маски. Список подій — це і є обсяг роботи.
- Реакція на подію: хто отримує повідомлення, за який час, чи потрібна зв'язка з пропускною системою, оповіщенням і постом охорони.
- Обмеження щодо даних: де зберігається архів, скільки він живе, чи допускається винесення кадрів на навчання, чи є вимоги до обробки біометрії.
- Інфраструктура: де розгортаємо — на своєму обладнанні в контурі замовника або у виділеному сегменті мережі, які канали зв'язку між майданчиками.
- Навантаження: кількість камер на один вузол обробки, очікувана кількість подій на добу, припустима затримка між кадром і повідомленням.
За цими ввідними ми збираємо схему розміщення, склад моделей і план робіт з етапами та критеріями приймання. Зобов'язань з вашого боку на цьому кроці немає — лише розмова по суті.
