Более 80% ИИ-пилотов не переходят в промышленную эксплуатацию. Проекты зависают, бюджеты иссякают, команды расходятся. Провал редко связан с технологией — ломается все вокруг нее.
В этой статье разберем критерии, по которым принимается решение о масштабировании ИИ-систем в сфере безопасности — видеоаналитики, систем контроля доступа, поведенческого анализа, детекции аномалий.
Разберем, где именно срывается переход от первого пилота до промышленной системы, и как его избежать.
Пилотный проект: структура
Обычно пилот охватывает один объект и небольшое число камер и/или датчиков и, как правило, имеет фиксированные временные рамки, а также реализуется в режиме мониторинга: система может фиксировать события и выдавать оповещения оператору, но при этом она не встроена в общую систему безопасности.
Расширенный пилот, охватывающий два-три разнотипных объекта, позволяет проверить, как модель ведет себя в разных условиях, в том числе проверяется интеграция с инфраструктурой заказчика. Именно здесь выявляются скрытые проблемы с совместимостью оборудования, которые невозможно обнаружить при тестировании одного объекта.
Ограниченное внедрение — следующий шаг, при котором система охватывает уже большую часть целевого периметра по сравнению с расширенным пилотом и переводится из режима мониторинга в режим реагирования на оповещения. Этот этап важен для оценки организационной готовности, а бизнес может оценить первый эффект от автоматизации. Успешное прохождение ограниченного внедрения дает основания для принятия решения о развертывании системы на все предприятие.
Техническая готовность
Техническая готовность — фундамент масштабирования. Без оценки производительности, устойчивости и инфраструктурных ограничений переход к промышленной эксплуатации не приведет к желаемому результату.
Ключевые параметры, которые необходимо проверить до перехода к масштабированию, включают четыре основных блока.
Точность на разнородных данных. Показатели FAR (False Acceptance Rate — коэффициент ложного принятия) и FRR (False Rejection Rate — коэффициент ложного отказа) нужно измерять на выборке, отражающей разнообразие условий.
Нагрузочное тестирование. Система, обрабатывающая 10 камер с задержкой 200 мс, может деградировать при 200 камерах. Тестировать нужно пиковую нагрузку.
Деградация модели. Нужно понять заранее, как быстро падает точность, есть ли процесс дообучения, сколько он стоит.
Инфраструктура. Масштабирование с 10 камер до 500 меняет архитектуру хранения, требования к сети и вычислительным мощностям. Облако не всегда применимо из-за требований к локализации данных.
Техническая готовность — необходимое, но не достаточное условие. Система не работает без людей и процессов.
Организационная готовность
Любое внедрение обречено на провал, если персонал не знает, как работать с новой системой, а зоны ответственности не распределены. Организационная готовность — это способность компании встроить новый инструмент в рабочие процессы.
Чтобы обеспечить такую готовность, требуется проработать три обязательные составляющие.
Регламенты реагирования должны включать информацию, кто получает алерт, в какие сроки ответственный сотрудник должен отреагировать, порядок действий при ложном срабатывании, кто принимает финальное решение.
Ответственность ИБ и ИТ. Матрица RACI (Responsible, Accountable, Consulted, Informed — распределение ролей: исполнитель, ответственный, консультант, информируемый) должна быть готова до запуска. Отсутствие четкого распределения зон ответственности может привести к тому, что инциденты окажутся на стыке зон ответственности ИТ и ИБ. Вследствие этого задачи, направленные на устранение этого инцидента, либо не будут исполняться вообще, либо будут исполняться с нарушением запланированных сроков.
Обучение операторов. Оператор обычной системы видеонаблюдения (CCTV) и оператор ИИ-системы — разные роли. Для сотрудников, ответственных за работу системы, следует провести обучение по функционалу внедряемого решения.
Когда организационный каркас определен, нужно посчитать деньги и оценить риски.
Финансовые и риск-ориентированные критерии
Экономическая эффективность — ключевой аргумент при принятии решения о внедрении решения. Для этого нужна прозрачная финансовая модель и понятный подход к оценке рисков масштабирования системы.
TCO (Total Cost of Ownership — совокупная стоимость владения).
TCO = CapEx (Capital Expenditure — капитальные затраты: лицензии, железо, интеграция) + OpEx (Operational Expenditure — операционные расходы: поддержка, дообучение, персонал).
ROI (Return on Investment — возврат инвестиций) может быть оценен с помощью расчета ущерба за определенный период, который понесла компания из-за предыдущих инцидентов.
Матрица рисков
|
Категория |
Примеры |
Градация |
|
Технические |
Деградация модели, отказ инфраструктуры |
Средний-высокий |
|
Регуляторные |
Несоответствие законодательству |
Высокий |
|
Операционные |
Перегрузка операторов, игнорирование алертов |
Средний |
|
Репутационные |
Публичный инцидент с ложным обвинением |
Высокий |
Риски с градацией «высокий» — стоп-факторы.
Параллельно с финансовым анализом необходимо урегулировать вопросы соответствия законодательству.
Регуляторные критерии
№
С 1 июня 2023 года вступили в силу основные положения Федерального закона №
ФСТЭК и ФСБ. При интеграции с объектами КИИ ИИ-компоненты должны сертифицироваться, если они классифицируются как средства защиты информации (СЗИ) или функционируют в составе значимых объектов КИИ (ЗОКИИ).
Когда все критерии собраны, их нужно свести в рабочий инструмент.
Методология принятия решения
Практическим инструментом для такой оценки может служить чек-лист готовности, охватывающий пять ключевых направлений.
● Техническое: точность на разнородных данных подтверждена; нагрузочное тестирование пройдено; процесс дообучения описан; интеграции протестированы.
● Организационное: регламенты утверждены; RACI согласована; операторы обучены.
● Финансовое: проведены расчеты TCO и ROI; бюджет утвержден.
● Регуляторное: правовая экспертиза пройдена, соответствие отраслевым нормам и обязательным требованиям подтверждено.
● Риск-ориентированное: матрица рисков составлена; риски с градацией «высокий» закрыты.
Поэтапное масштабирование: пилот → расширенный пилот
Стоп-факторы: не закрыты регуляторные риски; точность не достигает установленных пороговых значений; операционные регламенты не утверждены; бюджет масштабирования.
Даже при положительном решении о масштабировании результат во многом определяет выбор подрядчика.
Требования к подрядчику
При выборе подрядной организации (сервисной ИТ-компании/интегратора) для проекта следует проверить четыре признака:
· наличие в портфолио схожих проектов сопоставимого масштаба;
· прозрачность архитектуры;
· SLA (Service Level Agreement — соглашение об уровне услуг);
· опыт работы с регуляторами: ФСТЭК, ФСБ.
Модели взаимодействия различаются по степени зависимости заказчика от разработчика. При полном аутсорсинге компания берет эксплуатацию на себя — это удобно, но создает зависимость от разработчика.
Аутстаффинг предполагает, что разработчики работают внутри команды заказчика и постепенно передают экспертизу.
Выделенная команда подходит для крупных долгосрочных проектов: фиксированный состав, понятные KPI, отдельный бюджет. При передаче компетенций ИТ-компания обучает внутреннюю команду и выходит из проекта.
Вывод
Масштабирование — самостоятельный проект со своим уставом, бюджетом и критериями успеха.
Компания готова к промышленному ИИ, если внутри есть понимание ограничений технологии, процессы адаптированы, распределены зоны ответственности за систему, выделен и распланирован бюджет на разработку, внедрение и поддержку системы.
