Как считать долг управляемости ИИ в деньгах, а не в тревоге

Как перевести дефицит контроля над ИИ-сценариями в приоритеты и решения без стресса и абстрактных угроз

CISO обычно говорят о риске, связанном с ИИ, я же предпочитаю обсуждать цену конкретного разрыва между тем, как ИИ-сценарий работает сейчас, и тем, как он должен контролироваться при своих данных и полномочиях. Чаще всего мы стараемся измерять скорость его внедрения и почти никогда не оцениваем долг управляемости, который эта скорость оставляет за собой.

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

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

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

Единицу учета я беру конкретную – не модель или корпоративный ИИ-сервис, а сценарий. У агента, читающего данные CRM и готовящего черновик ответа клиенту, должны быть владелец процесса, класс данных, список полномочий, внешние зависимости, цена ошибки, целевой SLA и перечень контролей, причем не только тех, что есть, а и тех, которых пока нет.

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

Вот несколько вещей, которые я обычно проверяю:

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

Наличие политики или лога само по себе ничего не доказывает. Настоящие аргументы появляются, когда можно воспроизвести действия, объяснить полномочия, остановить процесс и подтвердить, что след не менялся.

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

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

Станислав Ежов, директор по развитию ИИ, ПАО Группа Астра