Как отдалить Skynet. Семь практических советов по безопасному внедрению ИИ в корпорации
В последние месяцы я регулярно читаю лекции на курсах по цифровому лидерству для топ-менеджеров различных компаний и наблюдаю одну и ту же картину. Взрывное использование искусственного интеллекта компаниями, даже если их руководители еще спорят об этом, а иногда и не знают о реальном положении дел. А сотрудники вовсю отправляют во внешние сервисы письма, договоры, куски кода, сводки по продажам, протоколы встреч и презентации, а все потому, что руководители просят модель собрать аналитику, придумать варианты решений, сократить текст, подготовить ответ клиенту или свести в одно целое разрозненные документы. Где-то это оформлено как пилот. Где-то живет в серой зоне, откуда и пошел термин Shadow AI по аналогии с Shadow IT, когда сотрудники начинают использовать то, что им предоставлено не компанией, а куплено за свои деньги. Где-то никто уже и не помнит, кто и когда первым начал.
Конечно, проблема не в самом ИИ, который хоть и не показывает еще прямой финансовой отдачи, но при правильном использовании действительно позволяет ускорять решение многих задач. Проблема в другом — компании внедряют его быстрее, чем успевают навести порядок в данных, доступах, ответственности и правилах. В итоге бизнес получает не только ускорение, но и новую зону неконтролируемого хаоса. Постоянно вижу на лекциях ситуации, когда руководители государственных корпораций и госорганов в открытую используют зарубежные сервисы от OpenAI или Anthropic, хотя им это явно запрещено законодательством. Бизнес же, менее скованный законодательными ограничениями, тоже часто и необдуманно делает то, что нельзя, — например, передает персональные данные в ИИ-сервисы (даже если они российские), не имея на то согласия субъектов персональных данных.
Обычно разговор про ИИ в компаниях быстро сводится к двум крайностям, поддерживаемым двумя направлениями, — бизнесом вкупе с ИТ и инфобезом. Первые видят только позитивный эффект: быстрее пишем, быстрее анализируем, быстрее принимаем решения. Другие видят только угрозы: утечки данных, галлюцинации, регуляторные претензии, репутационные потери. Обе позиции понятны и имеют право на существование, но все-таки реальность находится где-то посередине между этими точками зрения. На ИИ полезнее смотреть не как на что-то уникальное и новое, а как на еще одну производственную технологию, которая может дать прирост скорости, качества и пропускной способности (вспомним наше отношение к облакам, распределенным реестрам, виртуализации, контейнерам и т. п.). Но она же несет риски и меняет требования к управлению процессом.
Если говорить совсем приземленно, вопрос звучит так: как дать бизнесу ускорение и не потерять контроль. Позволю себе дать несколько советов, которые избавят от необходимости кусать потом локти, когда в результате необдуманного использования ИИ что-то пойдет не так — будет стерта база данных, произойдет утечка информации, будут приняты неверные решения или аудит найдет нарушения законодательства.
Определиться со сценариями использования
Первое, с чего стоит начать, и это не про безопасность, — перестать внедрять ИИ «вообще». У ИИ нет ценности самой по себе. Ценность появляется только там, где он снимает конкретное трение в работе. Например, ускоряет разбор документов, помогает сводить данные из нескольких источников, готовит черновики ответов, подсказывает варианты действий, помогает оператору, аналитику, юристу, продавцу или закупщику. Пока компания не ответила, какой именно участок работы она хочет ускорить или упростить, она почти наверняка купит красивую демонстрацию вместо рабочего инструмента.
Поэтому первый вопрос для руководителя должен звучать не «какую модель нам выбрать», а «какую именно функцию мы хотим передать машине, а какую оставить человеку». ИИ может помочь:
- анализировать;
- рекомендовать;
- автоматизировать повторяющиеся действия;
- в некоторых случаях действовать почти автономно.
Это четыре разных уровня вмешательства в процесс. Если их смешать, компания быстро теряет ориентиры. Черновик письма и рекомендация по ассортименту товаров — один уровень риска. Влияние на решение по выдаче кредита, закупку, отправку юридически значимого документа или производственное планирование — совсем другой. И несмотря на то будто кажется, что это про безопасность, это не так. Именно ответ на заданный вопрос позволяет позже определиться с мерами защиты и контроля.
Кстати, если вернуться к вопросу «какую модель нам выбрать». Посмотрим на так разрекламированные перед выходом Anthropic на IPO модели Mythos и Fable, которые американское правительство очень быстро заблокировало (и также быстро разблокировало), показав всему рынку, что надо покупать акции какая-то небольшая частная компания смогла напугать огромное государство. Многие считают, что эти модели могут ломать даже Агентство национальной безопасности США и скоро всему миру придет конец, поскольку уровень входа в киберпреступность с появлением этих моделей существенно снижается. Это не так. У нас в компании проводился анализ данных моделей, а также конкурентной GPT-Cyber-5.5 от OpenAI, и мы пришли к выводу, что аналогичных результатов можно достичь, используя и менее разрекламированные модели, даже открытые. Дело не в модели, а в обвязке вокруг нее, умении пользоваться ею, интегрировать в процессы и т. п.
Какими данными можно кормить ИИ?
Большинство разговоров про корпоративный ИИ почему-то начинают с выбора модели, платформы или поставщика. На практике все решает вопрос, какие данные сотрудники могут показывать этой системе. Если компания не ответила на него заранее, сотрудники ответят сами. Обычно очень быстро и без согласования. Отсюда и начинаются истории про утечки конфиденциальной информации, секретов у разработчиков, удаление служебной почты и т. п.
Для работы с ИИ полезно хотя бы вчерне разделить данные на зоны. В одной зоне лежит то, что и так публично или обезличено. В другой — внутренние рабочие материалы, с которыми можно работать только при понятных правилах. Еще дальше — чувствительные коммерческие данные, финансовые документы, договоры, сведения о клиентах, персональные данные, исходный код, результаты исследований, материалы по сделкам, стратегические планы. У каждой зоны должны быть свои ограничения. Не потому, что служба безопасности любит запреты, а потому, что цена ошибки при работе с этими данными разная. И достаточно просто еще раз пересмотреть и при необходимости обновить уже имеющиеся списки сведений конфиденциального характера, которые есть во многих компаниях. Иначе может повториться ситуация, как в одной компании, где ИИ-агент, участвующий в разработке ПО, удалил в Replit рабочую базу данных во время этапа заморозки кода (code freeze), когда запрещены любые изменения в проекте. Сам агент позже «признал», что выполнил несанкционированные команды и нарушил явные инструкции.
Именно здесь начинается разговор про реальные, хотя и не очень заметные утечки. Они при использовании ИИ часто выглядят как типичное рабочее действие. Сотрудник вставил в окно сервиса таблицу, чтобы «быстрее сделать выводы» (а то и вовсе использовал MS Excel с встроенным ChatGPT или Claude). Менеджер загрузил письмо клиента, чтобы «аккуратно переформулировать и подготовить ответ». Разработчик отправил кусок внутреннего кода, чтобы «проверить логику». Финансист свел цифры по выручке и марже, чтобы «получить красивое резюме для директора». Каждый отдельный шаг кажется безобидным, но в сумме компания получает новый канал выноса информации за пределы своего контура.
Политика разрешенного использования ИИ
Если компания просто говорит «публичный ИИ использовать нельзя», сотрудники находят обходные пути, так как они уже вкусили всю прелесть ИИ и не откажутся от него. Личные аккаунты, домашние устройства, пересылка файлов на личную почту, ручное копирование фрагментов, фотографирование на смартфон (при использовании мультимодальных ИИ-моделей разобраться в сотнях фотографий уже не сложно) — все это уже давно стало бытовой практикой там, где правила отстают от жизни.
Правильный подход должен быть иным. Компании нужна политика разрешенного и запрещенного использования. В ней должны быть не общие слова про осторожность, а конкретные ответы на простые и понятные вопросы:
- Какие сервисы допустимы?
- Для каких задач их можно применять?
- Какие данные загружать нельзя?
- Какие результаты нельзя использовать без проверки человеком?
- Кто согласует новые сценарии использования ИИ?
- Что логируется?
- Кто отвечает за нарушение правил?
Без такой рамки сотрудники все равно будут применять ИИ, только руководство не будет понимать, где именно и с какими рисками. Как говорится, если не можешь победить, возглавь.
Доверяй, но проверяй
Особая тема — управленческие решения. Генеративный ИИ хорошо упаковывает мысли и быстро выдает стройный ответ, уверенный тон и набор аргументов, которые легко принять за зрелый анализ. На этом месте у многих людей (и руководители не исключение) возникает опасное искушение: если текст звучит убедительно, значит, ему можно доверять. Но убедительность и надежность — не одно и то же. Гораздо реже, но модель может быть осознанно обманута или скомпрометирована. В любом случае она может ошибаться, путать источники, достраивать пробелы, сглаживать противоречия и прятать неуверенность за гладкой формулировкой.
Поэтому ИИ полезно встраивать в контур подготовки решений, но опасно делать его последней инстанцией. Он может собрать материалы, подсветить альтернативы, помочь заметить закономерности, подготовить черновик аналитической записки, сжать большой массив документов до удобного объема. Но там, где ошибка влияет на деньги, клиентов, правовой статус, репутацию или безопасность, то есть приводит к юридическим последствиям, право окончательного решения должно оставаться у человека. Иначе компания передает важную часть управления системе, которая не несет ответственности за последствия. И хотя споры о том, несет ли ИИ ответственность за свои действия (или не ИИ, а его разработчик, или тот, кто обучал модель, или готовил данные, или кто встраивал в облачный сервис) продолжаются, независимо от их исхода, лучше сразу продумать этот вопрос в своей стратегии использования ИИ.
И вновь я вернусь к вопросу о выборе модели. Если мы смотрим на систему с позиции «одна система — модель», то за деревьями мы перестаем видеть лес. Модель может стать внезапно недоступной из-за отключения Интернета или блокировки со стороны ее владельца, а еще у нас могут закончиться токены. В любом случае грамотная архитектура не должна быть зависимой только от одной модели, какой бы хорошей она ни казалась при тестировании. Должна быть выстроена иерархия применения моделей (по качеству, по цене, по доступности) и запросы между ними должны маршрутизироваться с помощью соответствующего инструмента (он же может выступать и в качестве MCP-сервера, реализующего функции безопасности, например, защиты от утечек информации, от промпт-инъекций и других ИИ-угроз).
Тут же встает вопрос автономности. У многих руководителей есть соблазн перейти от автоматизации к почти самостоятельным действиям системы. Пусть агент сам ищет данные, сам пишет письма, сам выставляет задачи, сам запускает процедуры, сам решает типовые обращения в каком-нибудь чате поддержки. В отдельных процессах это возможно. Но чем выше цена ошибки, тем ниже должна быть допустимая автономность. В зоне низкого риска система может помогать с рутиной. В зоне среднего риска — предлагать решения при обязательной проверке человеком. В зоне высокого риска нужен двойной контроль, ограничение полномочий и возможность быстро откатить действие. В критичных контурах автономность лучше не включать вовсе. И вновь мы приходим к матрице критичности ИИ-сервисов в зависимости от уровня принимаемых ими решений, которая станет основой для выстраивания политик доступа для агентов, журналирования их действий, аутентификации и авторизации и т. п.
«Ури, где у него кнопка?!»
Еще один практический вопрос, который компании часто пропускают: кто хозяин ИИ-проекта? Пока инструмент существует как общекорпоративная инновационная инициатива, он почти всегда живет красиво только на презентации. Как только дело доходит до промышленной эксплуатации, выясняется, что никто не отвечает за качество результата, за допустимые границы применения, за сбои, за пересмотр модели, за ущерб при ошибке, за контроль, и даже за то, кто имеет право выключить систему (а это не Электроник без кнопки из старого советского кино для детей — такая возможность должна быть предусмотрена).
Достаточно вспомнить недавнюю историю с руководительницей отдела AI Safety признанной в России экстремистской компании Meta, которая подключила ИИ-агента OpenClaw к своему почтовому ящику и попросила агента предлагать, что удалить или архивировать из электронных сообщений. Но агент «почему-то» начал просто удалять письма и игнорировал команды остановиться с телефона.
У любого серьезного сценария должен быть владелец процесса. Отдельно нужен тот, кто отвечает за риск. Нужны метрики пользы, понятные бизнесу, а не только разработчикам. Нужны критерии, при которых сценарий приостанавливают. Если у проекта ничего этого нет, он продолжает оставаться экспериментом. Это особенно опасно там, где ИИ уже встроили в реальные операции, а восторг от пилота еще не успел пройти.
Локальная vs облачная LLM
Компании, столкнувшись с блокировкой учетных записей в Claude или OpenAI, а также постоянно страдающие от блокировок Интернета, начинают задумываться о создании внутреннего контура, в котором размещается локальная модель (хоть Qwen, хоть Kimi, хоть GLM, хоть Mistral или Gemma). Такой контур нужен там, где компания хочет сохранить доверие к процессу. Он нужен и там, где необходимо формальное соответствие требованиям безопасности — например, на объектах КИИ, при обработке персданных или в государственных информационных системах. Если система работает с чувствительными данными, влияет на клиентов, помогает принимать финансовые, юридические или операционные решения, подключена к внутренним базам, почте, хранилищам документов, системам учета или аналитики, то вопрос уже не сводится к тому «хорошая ли модель».
Вопрос в том, кто и как контролирует среду, в которой она живет. Неслучайно законопроект о развитии ИИ в Российской Федерации, который к моменту выхода статьи может стать законом, делает акцент на суверенности применяемого в стране искусственного интеллекта. И хотя к этому законопроекту есть немалое количество вопросов, заложенная в нем идея может и должна быть рассмотрена применительно не только к целому государству, но и каждой компании, которая хочет строить на базе ИИ свой бизнес. А суверенность базируется на контроле — контроле моделей, обучающих данных (датасетов), весов, процесса обучения и т. п. И все это неотрывно связано с безопасностью, а точнее с конфиденциальностью, целостностью и доступностью как моделей ИИ, так и данных, с которыми и на базе которых она работает.
ИИ — это не только модель, но и интеграции
Повторю уже озвученный выше важный тезис: на практике риск часто находится не в самой модели, а в обвязке вокруг нее. Чем больше у ИИ интеграций, тем больше соблазн сделать из него удобный универсальный интерфейс ко всему внутри компании. Для бизнеса это выглядит очень привлекательно. Один помощник получает доступ к документам, сделкам, отчетам, переписке, клиентским данным и рабочим системам. Для управления рисками это означает, что в одной точке сходятся все информационные потоки, она начинает видеть и уметь слишком многое.
Недавно ИИ-агент взломал внутреннюю ИИ-платформу Lilli компании McKinsey и получил полный доступ на чтение и запись к публичному чат-боту всего за два часа. Сам чат-бот имел доступ к внутренней инфраструктуре компании — к 46,5 миллионам сообщений чата о стратегии, сделкам M&A, а также о взаимодействиях с клиентами наряду с 728 000 файлов, содержащих конфиденциальную информацию клиентов, 57 000 учетных записей пользователей и 95 системных промптов, контролирующих поведение ИИ. Хорошо, что это была просто демонстрация наступательных возможностей ИИ-агентов, занимающихся тестированием безопасности. Но что, если бы это сделали настоящие «плохие парни»?
Поэтому внутренний контур — вопрос не только про размещение модели и учет ею культурно-нравственных ценностей русского народа, но и про разграничение ролей, управление доступом, журналирование, проверку интеграций, хранение запросов, ответов и хода рассуждений (reasoning), а также про возможность остановить работу без остановки бизнеса (например, путем переключения на иную модель, пусть и менее продвинутую, но лучше контролируемую).
Тестируй, а не то проиграешь
И здесь полезно добавить еще один принцип: доверяй, но проверяй. Перед промышленной эксплуатацией любой ИИ-проект нужно испытывать так же, как испытывают новую технологию на серьезном производстве. Никто не запускает новую линию, новый станок, новую систему управления складом или новую рецептуру только потому, что все хорошо выглядело на демонстрации или даже пилоте. С ИИ должно быть точно так же. Перед запуском мало увидеть красивый результат на нескольких примерах. Нужно проверить, как система работает на реальных сценариях компании? Насколько точен ответ? Насколько стабильно ведет себя модель? Где именно она ошибается? Что происходит на неполных, противоречивых и двусмысленных входных данных? Какую цену несет единичная ошибка? Что будет, если ошибки окажутся системными или начнут каскадироваться (особенно в мультиагентском окружении)? Можно ли заметить сбой быстро? Можно ли отменить решение? Кто первым почувствует последствия: клиент, бухгалтерия, отдел продаж, юридическая служба, служба поддержки или производство?
Отдельно необходимо проверять и безопасность всего жизненного цикла. Не только самой модели, но и данных, подсказок, логов, истории обращений, подключенных систем и пользователей. Нужно понимать, нельзя ли через систему получить лишний доступ, вытащить лишние сведения, подмешать опасный ввод, заставить сервис выдать то, что он не должен выдавать, или использовать его как обходной маршрут к внутренним ресурсам. Во многих случаях проверять придется не только качество ответов, но и устойчивость всей связки «модель, данные, интеграции, права доступа, люди». Надо признать, что это делают редко; все-таки специалистов по тестированию безопасности ИИ у нас в стране пока маловато, но это перспективное направление, как таким когда-то стал и пентест (тесты на проникновение), эмулирующий действия хакера.
Last but not least
Иногда компания пытается автоматизировать процесс, который сам по себе плохо описан и не формализован. У него нет четких правил, нет владельца, нет нормальных критериев качества, сотрудники действуют по-разному, а спорные случаи решают, опираясь на опыт и ручное согласование. Если поверх такого процесса поставить ИИ, беспорядок не исчезнет. Как в известной поговорке об автоматизации хаоса: попытка внедрить ИИ в хаос только ускорить его, а не стабилизирует. Поэтому перед внедрением полезно честно спросить: у нас зрелый процесс, который можно усиливать за счет ИИ, или мы собираемся увеличить масштаб неопределенности?
В заключение хочется сказать, что руководителям, задумывающимся о внедрении ИИ, не нужна глубокая техническая экспертиза в этой теме. Им нужно не побояться задать до запуска любого сценария внедрения ИИ несколько жестких вопросов. Какой участок работы мы хотим улучшить? Какие данные и системы ИИ увидит и получит к ним доступ? Есть ли в компании официальный список разрешенных ИИ-сервисов? Какой ущерб возможен при ошибке? В каких процессах ИИ имеет право только советовать, а в каких — действовать? Кто подтверждает результат? Кто отвечает за риск? Кто остановит систему, если она начнет работать не так и поведет не туда? Если на эти вопросы нет четких ответов, компании, скорее всего, рановато идти в промышленную эксплуатацию искусственного интеллекта, как бы впечатляюще ни выглядел пилот. И кибербезопасность играет в ответах на эти вопросы не последнюю роль.
Корпоративный Skynet рождается не из сильного искусственного интеллекта и не по причине, что ИИ умнее человека и начинает пытаться его оберегать от своих же ошибок (хотя до AGI и тем более ASI нам еще далеко). Skynet рождается там, где менеджмент соглашается на интеграцию новой системы в процессы быстрее, чем успевает установить границы, правила и ответственность. Ускорение без управления и контроля редко заканчивается хорошо. И искусственный интеллект здесь не исключение.
Опубликовано 08.07.2026
