Топ-менеджер Nvidia по безопасности Марк Уэзерфорд сформулировал неудобную для многих компаний мысль: роль CISO в ИИ не сводится к тому, чтобы поставить штамп «разрешено» или «запрещено». Руководитель информационной безопасности должен помочь бизнесу сопоставить выгоду и риски, но владельцем риска обязано оставаться подразделение, которое решило внедрить ИИ. Об этом сообщает Dark Reading.
Формулировка важна не только для американских корпораций. В русскоязычных компаниях генеративные модели уже попадают в клиентскую поддержку, разработку, маркетинг, аналитику и HR — часто быстрее, чем появляются правила работы с ними. Если каждый новый сценарий отправлять на согласование исключительно в ИБ, CISO превратится в узкое горлышко, а бизнес начнёт искать обходные пути. Если же проверок нет вовсе, в модель могут уйти персональные данные, исходный код, коммерческие условия или документы, которые не предназначались для внешнего сервиса.
Уэзерфорд предлагает иной баланс. Задача CISO — объяснить руководителям и владельцам процессов последствия выбора: какие данные попадут в ИИ-систему, кто получит к ним доступ, можно ли использовать результат без дополнительной проверки и что произойдёт при ошибке. Но решение о запуске конкретного инструмента и ответственность за его деловой эффект не должны автоматически переезжать в службу безопасности. Иначе ИБ фактически будет отвечать за продуктовую стратегию, не располагая ни полномочиями, ни контекстом для такого решения.
Для команд разработки эта логика означает, что вопрос безопасности нельзя оставлять на финальный этап перед релизом. Использование внешней модели в IDE, помощника для ревью кода или сервиса для обработки обращений клиентов — это не просто выбор удобного инструмента. Команде нужно заранее определить, какие данные допускаются в запросах, можно ли отправлять фрагменты репозиториев во внешнюю инфраструктуру, как проверяются ответы модели и кто утверждает исключения. CISO здесь задаёт рамки и контролирует соблюдение, а не обязан вручную разбирать каждый промпт.
У продуктовых команд похожая проблема выглядит иначе. ИИ-функция может ошибиться, выдать убедительный, но неверный ответ, раскрыть сведения из контекста запроса или создать юридически сомнительный результат. Владелец продукта должен решить, где необходим человек в контуре, как пользователю сообщать об ограничениях и какие действия нельзя автоматизировать. Роль CISO в ИИ — сделать такие риски видимыми и измеримыми для бизнеса, а не подменить собой владельца продукта.
На практике компаниям полезно разделить ответственность до запуска пилота. Бизнес-владелец описывает цель и допустимый ущерб, техническая команда выбирает архитектуру и способы контроля, юристы и специалисты по данным проверяют применимые ограничения, а ИБ оценивает угрозы и требования к защите. Такой подход звучит менее эффектно, чем приказ «всем использовать ИИ» или «запретить всё», зато оставляет понятный след решений. При инциденте не придётся выяснять, кто разрешил загрузить чувствительные данные в сервис: это должно быть известно заранее.
Особенно рискованна привычка считать ИИ самостоятельным классом угроз. Модель не отменяет знакомые проблемы: избыточные права доступа, слабую классификацию данных, отсутствие журналирования, неясных подрядчиков и неконтролируемые интеграции. Она лишь ускоряет последствия этих проблем. Если сотрудник может скопировать в чат-бот закрытый документ, значит, вопрос не только в чат-боте, но и в правилах работы с данными, обучении персонала и контроле доступа.
Для IT-директоров вывод тоже довольно приземлённый: скорость внедрения ИИ зависит не от количества купленных лицензий, а от качества управления. Роль CISO в ИИ становится ближе к роли советника по принятию решений — человека, который переводит технические риски на язык последствий для продукта, клиентов и бизнеса. Следующий спор в компаниях будет не о том, разрешать ли ИИ вообще, а о том, кто вправе принять риск ради конкретной выгоды и способен затем ответить за это решение.
