Служба безопасности, привыкшая работать с классическими ИТ-рисками, нередко пытается уместить риски ИИ в существующую матрицу угроз — и упускает то, что делает их принципиально другими. Классическая уязвимость в ПО обычно детерминирована: при одинаковом входе система выдаёт одинаковый результат, и её можно закрыть патчем один раз. Модель ИИ по своей природе вероятностна: на одинаковый запрос она может дать разный ответ, а её поведение меняется вместе с обновлением версии, на которое компания часто не имеет прямого влияния.
Вторая особенность — скорость и масштаб распространения ошибки. Ошибка сотрудника в одном документе остаётся локальной, если её вовремя не растиражировали. Ошибка, встроенная в автоматизированный процесс с использованием ИИ, — например, в шаблон автоматического ответа клиентам — может повториться тысячи раз за считаные часы, прежде чем кто-то её заметит, поскольку сам механизм проверки результата человеком часто исключён именно ради скорости, которую и должна была дать автоматизация.
Именно поэтому риски ИИ имеет смысл рассматривать отдельной категорией — не потому, что они опаснее любых других корпоративных рисков, а потому, что для них нужны специфические меры контроля, которые классическая ИТ-безопасность или классический комплаенс не покрывают по умолчанию без явной адаптации существующих процедур под особенности этой технологии.
Самая обсуждаемая, но не единственная категория. Сюда входит передача чувствительных данных компании или клиентов в публичные сервисы без гарантий об их неиспользовании для обучения модели, а также риск того, что модель, обученная или дообученная на внутренних данных компании, впоследствии воспроизведёт фрагменты этих данных в ответах другим пользователям того же сервиса.
Отдельный, менее очевидный риск в этой категории — накопление чувствительных данных в истории переписки с чат-ботом внутри самой компании: сотрудники годами обсуждают с корпоративным ассистентом рабочие вопросы, и эта история со временем становится не менее ценной и уязвимой целью для атаки, чем традиционные корпоративные базы данных, но часто не защищается с той же строгостью просто потому, что воспринимается как «просто чат», а не как хранилище данных.
Практические меры защиты: явная классификация данных с запретом на передачу определённых категорий в неавторизованные сервисы, использование корпоративных версий инструментов с договорным обязательством не использовать данные компании для обучения модели, и включение истории переписки с ИИ-ассистентами в общий периметр защиты данных компании, а не в отдельную, менее контролируемую зону. Подробнее — в статье «Безопасность данных при использовании ИИ».
Ещё один источник риска в этой категории — интеграции между ИИ-инструментом и другими корпоративными системами через API. Каждая такая интеграция расширяет объём данных, к которым потенциально имеет доступ внешний сервис, и часто настраивается техническим специалистом без параллельного пересмотра политики классификации данных — в результате доступ оказывается шире, чем изначально предполагалось при согласовании использования инструмента с юридическим отделом или службой безопасности.
Компания, встроившая ИИ-инструмент в критичный рабочий процесс, тем самым создаёт новую точку отказа. Если сервис становится недоступен, меняет условия использования или заметно теряет в качестве после незаметного для клиента обновления модели, а бизнес-процесс не предусматривает быстрого отката к предыдущему способу работы, — компания сталкивается с операционным сбоем, источник которого находится вне её прямого контроля.
Похожий, но более скрытый риск — зависимость от одного поставщика без резервного варианта. Если весь клиентский сервис, аналитика или внутренние коммуникации компании завязаны на единственный ИИ-сервис, а альтернативный план на случай его недоступности не проработан заранее, ущерб от простоя оказывается значительно выше, чем от аналогичного сбоя привычного корпоративного ПО, для которого резервные процедуры обычно уже отлажены годами.
Практические меры защиты: для каждого критичного процесса, использующего ИИ, — явно прописанный откат на ручной или альтернативный автоматизированный вариант работы, регулярное тестирование этого отката (а не предположение, что он сработает, если понадобится), и, где это оправдано масштабом задачи, использование более чем одного поставщика или модели для действительно критичных сценариев.
Стоит отдельно учитывать и коммерческий операционный риск: изменение ценовой политики поставщика ИИ-инструмента способно резко увеличить стоимость процесса, уже встроенного в бизнес-модель компании по прежним расчётам окупаемости. Договор с чёткими условиями пересмотра цены и заложенный в финансовую модель запас на случай подорожания снижают вероятность того, что рост стоимости внешнего сервиса вынудит компанию срочно и не подготовленно менять процесс, критичный для клиентов.
Модель может уверенно и убедительно сформулировать неверный факт, устаревшие данные или логически некорректный вывод — так называемые галлюцинации. Риск не в том, что модель иногда ошибается (это неизбежное свойство технологии), а в том, что сотрудники, привыкшие к общей высокой полезности инструмента, постепенно перестают перепроверять результат в задачах, где цена ошибки высока.
Этот риск особенно опасен в задачах, где результат ИИ становится входом для дальнейшего автоматического процесса без промежуточной проверки человеком: например, автоматическая классификация обращений клиентов, влияющая на дальнейшую маршрутизацию, или автоматическая генерация отчётности, которая затем используется для принятия решений без ручной сверки с первоисточником.
Практические меры защиты: явное определение категорий задач, где результат ИИ обязательно проверяется человеком перед использованием, регулярный выборочный аудит результатов даже в задачах с формально низким риском (чтобы не пропустить постепенное ухудшение качества), и обучение сотрудников конкретным признакам, по которым можно заподозрить недостоверный ответ модели, а не полагаться на общую интуицию.
Полезная практика — фиксировать реальные случаи обнаруженных ошибок модели в общей базе внутри компании, доступной всем отделам, а не только тому, кто столкнулся с конкретной ошибкой. Без такой базы одна и та же характерная ошибка модели в похожих задачах обнаруживается заново разными отделами месяцами позже, вместо того чтобы новый отдел, начинающий работу с тем же инструментом, сразу знал, на что обратить особое внимание.
Ошибка ИИ, ставшая публичной, наносит бизнесу ущерб непропорционально её техническому масштабу — не потому, что сама ошибка обязательно серьёзнее человеческой, а потому, что общественное внимание к сбоям ИИ сейчас выше, чем к аналогичным сбоям привычных систем, и скриншот неудачного ответа чат-бота компании распространяется в соцсетях значительно быстрее, чем большинство других видов корпоративных инцидентов.
Отдельный репутационный риск — публикация ИИ-контента, который выдаётся за созданный человеком, без раскрытия, особенно в чувствительных жанрах (аналитика, экспертное мнение, персонализированное общение с клиентом). Обнаружение такой практики клиентами или журналистами наносит доверию к бренду ущерб, заметно превышающий экономию, которую компания получила от автоматизации создания контента.
Практические меры защиты: заранее подготовленный протокол реагирования на публичный инцидент с участием ИИ-инструмента (кто отвечает первым, что говорится клиенту, как быстро откатывается проблемный процесс), прозрачная политика раскрытия использования ИИ в клиентской коммуникации там, где это существенно для восприятия контента, и мониторинг публичных упоминаний бренда в связке с темой ИИ, а не реагирование только на прямые жалобы.
Важно понимать разницу между самой ошибкой ИИ и реакцией компании на неё — именно вторая часть чаще определяет итоговый репутационный ущерб. Компания, которая быстро признаёт проблему, объясняет, что произошло, и показывает конкретные изменения процесса, обычно теряет в доверии заметно меньше, чем компания, пытающаяся замолчать инцидент или переложить ответственность на «особенности технологии» без конкретных мер по исправлению ситуации.
Ответственность за решение, принятое или подготовленное с помощью ИИ, юридически лежит на компании, а не на разработчике модели — независимо от того, насколько убедительно выглядела рекомендация инструмента. Это касается и нарушения авторских прав при использовании сгенерированного контента, и требований к маркировке ИИ-контента, и обязательств по защите персональных данных при использовании ИИ для их обработки.
Особая категория — риски, связанные с использованием ИИ в решениях, затрагивающих людей напрямую: отбор кандидатов при найме, оценка кредитоспособности, ценообразование для конкретного клиента. Здесь ошибка модели или скрытая предвзятость в данных, на которых она обучена, может привести не только к репутационному, но и к прямому юридическому риску дискриминации, доказать отсутствие которой значительно сложнее, если решение принимал непрозрачный алгоритм, а не человек, способный объяснить свою логику.
Подробный разбор регуляторных требований и юридической ответственности — в статье «Юридические риски и регулирование ИИ в России». Практические меры защиты здесь пересекаются с этой темой напрямую: юридическая проверка договоров с поставщиками ИИ, обязательная проверка человеком решений, затрагивающих права людей, и документирование логики использования ИИ в таких процессах на случай последующей проверки регулятором или судебного разбирательства.
Отдельного внимания заслуживают договорные риски с самим поставщиком ИИ-инструмента: условия ограничения ответственности поставщика за ущерб от ошибки модели часто сформулированы значительно в его пользу, и стандартный договор, подписанный без проверки юристом именно этого пункта, может оставить компанию без реальной возможности компенсировать ущерб от системной ошибки инструмента, даже если она напрямую привела к прямым финансовым потерям бизнеса.
Кадровые риски ИИ редко обсуждаются наравне с техническими, но способны не менее серьёзно повлиять на бизнес. Первый — открытое или тихое сопротивление сотрудников, воспринимающих ИИ как угрозу собственной занятости, что приводит либо к саботажу внедрения, либо к формальному, поверхностному использованию инструмента без реальной интеграции в рабочий процесс.
Второй, более отложенный по времени риск — постепенная эрозия профессиональной квалификации сотрудников, годами полагающихся на ИИ в задачах, требующих самостоятельного суждения. Junior-специалист, с самого начала карьеры делегирующий ИИ анализ и выводы вместо того, чтобы научиться делать их самостоятельно, рискует так и не развить экспертизу, необходимую впоследствии для проверки и корректировки результатов того же ИИ на более высоком уровне ответственности.
Практические меры защиты: явная коммуникация с сотрудниками о роли ИИ как инструмента, а не замены (подкреплённая реальными кадровыми решениями компании, а не только словами), сохранение практики самостоятельного выполнения ключевых задач младшими специалистами хотя бы периодически, и включение кадровых рисков в общую программу управления рисками ИИ, а не оставление этой темы исключительно HR-отделу без связи с остальной картиной. Подробнее о построении программы обучения — в статье «AI-грамотность персонала».
Третий кадровый риск, часто недооцениваемый, — уход ключевых сотрудников из-за неудачно проведённого внедрения ИИ. Специалист, увидевший в компании небрежное отношение к его квалификации при поспешной автоматизации его задач без предварительного обсуждения, нередко предпочитает сменить работодателя, а не подстраиваться под изменения, — и компания теряет не только конкретного сотрудника, но и накопленную им экспертизу, которую сложно быстро восполнить наймом нового человека, даже с формально таким же набором навыков.
Разрозненные точечные меры защиты по каждой категории риска работают хуже, чем единая система, начинающаяся с явного назначения ответственного за риски ИИ — не обязательно отдельной штатной единицы, но конкретного человека или небольшой группы, которым подотчётны все шесть категорий рисков одновременно, а не разделены между ИТ-безопасностью, юридическим отделом и HR без единой точки координации.
Второй элемент системы — реестр всех сценариев использования ИИ в компании с оценкой риска для каждого: какие данные используются, затрагивает ли процесс решения о людях, есть ли резервный вариант при сбое, кто проверяет результат перед использованием. Без такого реестра компания часто не имеет полной картины того, где именно ИИ уже используется внутри организации, особенно если внедрение происходило постепенно и без централизованного контроля со стороны ИТ-отдела.
Третий элемент — регулярный пересмотр реестра и мер защиты, а не разовая оценка рисков при первом внедрении. Модели обновляются, появляются новые сценарии использования, а регуляторные требования меняются — система управления рисками, зафиксированная один раз и не пересматриваемая, довольно быстро перестаёт соответствовать реальному состоянию использования ИИ в компании.
Четвёртый элемент — понятный порядок эскалации при обнаружении проблемы. Сотрудник, заметивший, что ИИ-инструмент выдал некорректный или потенциально опасный результат, должен знать, кому и как об этом сообщить, не тратя время на выяснение, чья это зона ответственности. Отсутствие такого понятного канала — частая причина, по которой мелкие проблемы, о которых сотрудники в курсе месяцами, так и не доходят до людей, способных на них повлиять.
Следующий пример — иллюстративный, собирательный сценарий, а не описание конкретной компании. Розничная компания использовала ИИ-ассистента для составления ответов на отзывы клиентов на маркетплейсах — процесс casался только публичной, некритичной коммуникации, поэтому изначально не рассматривался как область повышенного риска и не проходил через формальную оценку.
Спустя несколько месяцев выяснилось, что ассистент, отвечая на негативные отзывы, иногда обещал клиентам конкретные компенсации и условия возврата, не согласованные с реальной политикой компании, — формально вежливые и убедительные ответы создавали юридически значимые обещания, которые бизнес не планировал выполнять. Проблему обнаружили не благодаря системе мониторинга, а случайно, когда один из клиентов публично потребовал выполнения обещанного ассистентом условия.
После инцидента компания внедрила простое правило: любой автоматический ответ, содержащий конкретные обязательства (сроки, суммы, условия возврата), помечается системой и требует подтверждения сотрудником перед публикацией, тогда как чисто эмоциональные, некритичные по содержанию ответы продолжают публиковаться автоматически. Случай показал типичную для многих компаний ошибку: риск оценивали по формальной категории процесса («ответы на отзывы» звучит некритично), а не по содержанию конкретных решений, которые процесс на самом деле принимает.
Показательно и то, как компания отреагировала после обнаружения проблемы: вместо того чтобы полностью отказаться от автоматизации ответов (что устранило бы риск, но и вернуло бы прежние затраты времени сотрудников), она сузила периметр полностью автоматического режима до безопасного подмножества сценариев, сохранив выгоду от автоматизации там, где она не создаёт юридического риска. Такой точечный, а не полярный ответ на обнаруженный риск обычно даёт лучший баланс пользы и защиты, чем крайние решения в любую сторону.
Небольшая компания или отдел не может одновременно и одинаково глубоко защититься от всех шести категорий риска — ресурсы на комплаенс, обучение и мониторинг всегда ограничены, и попытка охватить сразу всё распыляет их так, что ни одна категория не получает мер защиты, доведённых до реального результата. Более рабочий подход — оценить каждый сценарий использования ИИ по двум осям: вероятность реализации риска и тяжесть последствий, если он всё же реализуется, и в первую очередь закрывать сценарии, попадающие в зону одновременно высокой вероятности и высокой тяжести.
Практически это означает, что процесс, где ИИ участвует в решениях, напрямую затрагивающих права и деньги клиентов (отказ в услуге, ценообразование, компенсации), почти всегда попадает в приоритетную зону защиты — независимо от того, насколько редко там случаются ошибки, поскольку тяжесть последствий одной ошибки высока. А процесс с частыми, но малозначимыми ошибками — например, стилистически неидеальный черновик внутреннего письма — может подождать более тщательной защиты, если ресурсы ограничены.
Такая матрица должна периодически пересчитываться, а не составляться один раз: сценарий, изначально отнесённый к низкому риску, может переместиться в зону высокого приоритета по мере роста масштаба его использования — то, что было безопасным экспериментом на десяти клиентах, обычно требует пересмотра защиты, когда масштабируется на весь клиентский поток компании.
Отдельная, реже обсуждаемая категория — финансовые риски, не сводящиеся к прямой стоимости подписки. Компания, посчитавшая экономику внедрения ИИ только по цене лицензии в сравнении с сэкономленным временем сотрудников, часто не учитывает затраты на устранение последствий ошибок инструмента, время на повторную проверку результата в задачах повышенного риска и стоимость простоя при недоступности сервиса — совокупность этих статей способна заметно изменить итоговую картину окупаемости по сравнению с первоначальным расчётом.
Практическая мера защиты — считать полную стоимость владения инструментом, а не только подписку, ещё на этапе принятия решения о внедрении, включая консервативную оценку вероятных издержек по каждой из шести категорий риска. Такой расчёт не обязательно должен быть точным до рубля, но он заставляет заранее продумать вопросы, которые иначе всплывают уже после внедрения, когда изменить решение значительно сложнее и дороже, а первоначальный положительный бизнес-кейс, представленный руководству, уже нельзя пересмотреть без репутационных издержек для инициатора проекта внутри компании.
Большинство инцидентов, связанных с ИИ, обнаруживаются не благодаря системе мониторинга, а случайно — жалобой клиента, постом в соцсетях, вопросом журналиста. Это признак того, что мониторинг использования ИИ в компании либо отсутствует, либо ограничивается технической доступностью сервиса (работает или не работает), не затрагивая содержательное качество результата.
Практический минимум мониторинга, который стоит внедрить независимо от масштаба компании: периодическая выборочная проверка реальных результатов работы ИИ в каждом значимом процессе человеком, не участвовавшим в его настройке (свежий взгляд замечает то, что настройщик процесса уже перестал считать проблемой), отслеживание жалоб клиентов и внутренних вопросов сотрудников с явной пометкой «связано с ИИ» для накопления статистики по типам проблем, и мониторинг публичного упоминания компании в связке с темой ИИ в открытых источниках.
Более зрелый уровень мониторинга включает автоматическое отслеживание аномалий в самих ответах модели — например, резкий рост доли ответов определённого типа или неожиданное изменение тона коммуникации после обновления версии модели поставщиком, которое компания не инициировала и не тестировала заранее. Такой мониторинг требует отдельных технических усилий, но именно он позволяет обнаружить проблему до того, как её заметят клиенты, а не после того, как инцидент уже стал публичным и потребовал полноценного кризисного реагирования.