У CISO появляется новая неприятная обязанность: доказывать не только, что ИИ-система была защищена, но и что компания разумно подошла к её запуску до инцидента. Эксперт по киберправу Дэниел Б. Гарри предложил три рабочих механизма, которые помогают заранее зафиксировать решения, риски и доказательства. Для российских IT-команд ответственность за ИИ всё чаще будет зависеть не от красивой политики по governance, а от журналов, договоров и протоколов, которые можно показать юристу, регулятору или заказчику.
Об этом сообщает Dark Reading со ссылкой на выступление Гарри, CEO компании Law and Forensics, на конференции ISC2 Strategic Congress 2026 в Денвере. Его главный тезис прост: после компрометации AI-сервиса организации часто не могут восстановить, что именно сделал поставщик, какая версия модели работала в момент атаки и кто согласовал условия запуска. Когда договор уже подписан, получить недостающие артефакты обычно можно лишь при следующем продлении контракта — слишком поздно для расследования.
Гарри предлагает смотреть на внедрение ИИ как на комбинацию технического, юридического и управленческого риска. Его подход вырос из работы над JAMS AI Rules — правилами для арбитража AI-споров, принятыми в июне 2024 года. Эти правила не определяют виновного автоматически и не заменяют законы конкретной страны, но помогают выстроить обращение с техническими доказательствами. Для CISO это полезнее абстрактного требования «использовать ответственный ИИ»: нужно заранее понимать, какие данные сохранять и на каких условиях их можно запросить у вендора.
Сначала договориться о доказательствах
Первый практический шаг — подключить службу безопасности к переговорам с AI-вендором до подписания договора. В контракте стоит закрепить право на доступ к логам, сроки их выдачи, порядок подачи запросов на сохранение данных и возможность получить снимок модели или её состояния на момент инцидента. Вопрос «сможет ли поставщик предоставить состояние модели и как быстро?» должен звучать до закупки, а не в разгар форензики.
Не менее важны границы ответственности сторон: разрешённые сценарии использования модели, ограничения на данные, гарантии поставщика, страхование, лимиты ответственности и распределение операционных обязанностей. Отдельно нужны правила доступа, требования к защитным контролям, применимое право, площадка для разрешения споров и порядок экстренных мер. Для команды разработки это означает вполне приземлённую вещь: нельзя считать облачный AI API чёрным ящиком, если результат его работы влияет на клиентов, деньги или критические процессы.
Вторая часть подхода — пятифакторная оценка конкретного внедрения. Гарри предлагает оценивать потенциальный вред, данные и права на них, степень автономности системы, пробелы в доказательствах и зависимость от поставщика. Итоговый балл не обещает магической точности, зато делает видимыми допущения, которые обычно тонут между презентацией продукта и согласованием бюджета. По результату инструмент можно отправить на стандартную проверку, одобрить с условиями, ограничить пилотом или отложить релиз.
Такой скоринг особенно полезен для агентных систем, способных самостоятельно выполнять цепочки действий: создавать заявки, обращаться к внутренним сервисам, менять записи или взаимодействовать с пользователями. У чат-бота для поиска по базе знаний и у агента с доступом к финансовой системе разный радиус поражения — но в дорожных картах их нередко описывают одинаково бодро. Формализованная оценка заставляет владельца продукта назвать ограничения, человека для подтверждения действий и условия остановки сервиса.
Решение совета тоже должно быть техническим артефактом
Третий элемент — подробная фиксация решений совета директоров или другого органа, который принимает риск. Гарри советует сохранять не только итоговое «одобрено», но и рамки решения, срок его действия, описание угроз, приложенные доказательства, условия запуска, требования к ручному подтверждению и список ответственных. В записи должны остаться возражения, ход обсуждения, владелец AI-инструмента, даты контрольных точек и сведения о том, кто проверяет выполнение условий.
Это не бюрократия ради папки с PDF. Если система ошиблась, раскрыла данные или стала точкой входа для атаки, компании придётся объяснять, почему она допустила такой сценарий и какие меры приняла. Наличие протокола не снимает ответственность за ИИ, но позволяет показать последовательность: риск оценили, ограничения установили, ответственных назначили, контроль не бросили после пилота. Неформальное одобрение в мессенджере в такой ситуации выглядит куда менее убедительно.
Отдельный чек-лист нужен для инцидента. Помимо обычных security-логов команда должна сохранять состояние AI-системы, историю взаимодействий, сведения о данных и правах доступа, записи о governance, а также подтверждать целостность материалов и цепочку их передачи. Юристов Гарри рекомендует подключать сразу: часть действий по сбору и хранению доказательств может иметь процессуальные последствия. Полезное упражнение для команды — tabletop-сценарий, в котором вендор должен сохранить артефакты, а компания параллельно уведомляет нужные стороны.
На ближайшие 30 дней эксперт предлагает выбрать одно AI-внедрение для оценки, переписать один отчёт для руководства и провести одну тренировку по инциденту с участием поставщика. Это небольшой объём работы по сравнению с ценой расследования, где ключевые данные уже перезаписаны или недоступны по условиям договора. Следующий этап AI-управления, похоже, будет измеряться не числом принятых принципов, а способностью компании через месяцы воспроизвести: кто, на каких основаниях и с какими ограничениями разрешил системе действовать.
