Глава 2. ПРОМПТ С КОТЯТАМИ
Первое, что люди попросили у нейросети — сделать котёнка.
Не в буквальном смысле. Просто первые несколько месяцев генеративный ИИ использовали примерно так: нарисуй мне котика в стиле Мане, придумай смешную подпись к фото, напиши поздравление коллеге на день рождения. Игрушка. Развлечение. Технология, с которой безопасно экспериментировать, потому что ставки нулевые.
Потом люди не поменяли привычку. Они просто поменяли содержимое промпта.
Если в компании появляется новая технология, её сначала используют не по назначению.
Так было с электронной почтой, которую придумали для обмена сообщениями, а получили рассылку «СРОЧНО! ПРОЧИТАЙ ДО КОНЦА, ИНАЧЕ НЕ БУДЕТ СЧАСТЬЯ». Так было с мессенджерами, которые задумывались для общения, а превратились в основной канал пересылки документов, паролей, сканов паспортов, рабочих поручений, голосовых сообщений и семейных ссор. Так было с облаками, где должен был храниться корпоративный контент, а в итоге нашлись папки new_final_final2, contracts_old, не трогать, точно не удалять и, конечно, “Новая папка”.
С искусственным интеллектом случилось то же самое.
Его подавали как помощника для умных людей. А первыми по-настоящему счастливыми пользователями стали те, кто просто не хотел писать письма самостоятельно.
#
В одной крупной компании — название мы, конечно, не скажем, потому что у нас книга не про скандалы, а про жизнь, что иногда даже хуже, — новый ИИ-помощник появился ранней весной. Появился он, как обычно, не по решению службы безопасности, не после архитектурного комитета и не в результате трёхмесячного пилота.
Он просто появился.
Сначала кто-то из маркетинга купил подписку на личную карту. Потом дизайнер сказал, что модель неплохо придумывает слоганы. Потом юрист попросил «просто немного вычитать договор». Потом продакт-менеджер загрузил туда расшифровку встречи, потому что сам слушать её второй раз был не готов. Потом финансовый директор попросил «сделать краткое резюме по отчёту, но только без лишней воды».
А потом один инженер загрузил туда кусок внутренней документации.
Не потому что был злодеем. Не потому что хотел слить коммерческую тайну конкурентам. И даже не потому что был идиотом, хотя этот вариант в службах безопасности обычно рассматривают первым.
Просто ему нужно было быстро разобраться, почему интеграция с новым API опять падает в самом неподходящем месте. Документация была написана человеком, который явно считал, что комментарии в коде — это слабость духа.
Внутренний чат молчал. Коллега из соседней команды был в отпуске. Начальник спрашивал, когда будет готово. А модель отвечала быстро, вежливо и без фразы «я сейчас на встрече».
Инженер вставил текст и написал:
Объясни простыми словами, что здесь происходит.
Модель объяснила.
Потом он вставил ещё кусок.
Модель снова объяснила.
Потом он загрузил конфиг, чтобы модель подсказала, где ошибка.
Модель подсказала.
Потом он загрузил логи.
И вот тут, дорогой читатель, где-то в недрах корпоративной безопасности должна была завыть сирена, покраснеть лампочка, хлопнуть дверь и прибежать человек с табличкой «Нельзя».
Но ничего не произошло.
Потому что никакой сирены ещё не было.
#
В старой кибербезопасности всё было хоть как-то понятно.
Есть файл. Он либо вредоносный, либо нет. Есть ссылка. Она либо ведёт на фишинг, либо нет. Есть IP-адрес. Он либо плохой, либо пока не попался. Есть письмо от «службы поддержки», в котором написано: «Срочно подтвердите свой аккаунт, иначе мы будем вынуждены отключить вам заработную плату». Тут даже без машинного обучения можно догадаться, что где-то рядом пасётся преступник.
Но что делать с промптом?
Промпт — это вроде бы просто текст. Человек спрашивает модель. Модель отвечает. Никаких исполняемых файлов. Никаких макросов. Никаких архивов с паролем 123. Никакого классического криминального запаха.
Пахнет максимум офисом.
Однако именно в этом офисном запахе пряталась новая проблема. В промпт можно положить что угодно: договор, переписку, список клиентов, финансовую модель, таблицу под названием зарплаты_финал, архитектурную схему продукта, который ещё не вышел на рынок.
В старом киберпанке зло выглядело эффектно: чёрные терминалы, зелёные буквы, хакеры в капюшонах, корпорации, неон, дождь и синтезаторная музыка.
В новом киберпанке всё гораздо смешнее.
Человек сидит в светлом офисе, пьёт капучино на овсяном молоке и пишет в нейросеть:
Сократи этот документ до трёх пунктов, только сохрани все важные детали.
Раньше для утечки нужно было хотя бы отправить файл наружу. Теперь достаточно было попросить модель «сделать красиво».
#
Служба безопасности той самой компании узнала о происходящем не сразу.
Сначала они заметили странный рост трафика к внешнему AI-сервису. Потом выяснили, что сервисом пользуются не три энтузиаста из маркетинга, а уже половина офиса. Потом подняли прокси-логи и увидели, что туда уходят объёмы текста, слишком большие для обычного вопроса «как вежливо послать подрядчика».
Началось расследование.
Расследования в корпоративной безопасности вообще редко похожи на кино.
Никто не сидит в тёмной комнате перед голографическим экраном. Никто не кричит: «Увеличь! Ещё! Отрази в зрачке!» Обычно всё выглядит гораздо скромнее: несколько усталых людей смотрят в логи, пьют кофе, строят запросы, спорят о временных зонах и пытаются понять, почему пользователь из отдела закупок в 02:17 ночи отправил наружу 11 мегабайт текста.
Пользователь, кстати, потом объяснил просто:
— Я дома работал. Хотел договор сократить.
— А зачем весь договор загружали?
— Ну чтобы модель понимала контекст.
Контекст она, конечно, поняла.
Вместе с ценами, условиями, штрафами, контактами, внутренними комментариями и пометкой юриста: «Этот пункт лучше не показывать клиенту до финального раунда».
Дальше нашли инженера с логами. Потом продакта с расшифровками встреч. Потом HR, который попросил модель сравнить кандидатов, загрузив туда резюме, внутренние оценки интервьюеров и комментарий «этот вроде норм, но странный». Потом ещё одного сотрудника, который вообще ничего не загружал, а просто спросил:
Как обойти корпоративный запрет на использование внешних AI-сервисов?
#
В любой нормальной компании после такого начинается собрание.
Собрание — это древний корпоративный ритуал, во время которого люди, уже знающие ответ, объясняют проблему людям, которые могли бы узнать ответ из письма, но всё равно хотят презентацию.
На встречу пришли безопасность, юристы, IT, комплаенс, HR, представитель бизнеса и человек из «цифровой трансформации», который выглядел так, будто происходящее одновременно подтверждает его правоту и портит ему квартальные KPI.
Безопасность сказала:
— Нужно всё запретить.
Бизнес сказал:
— Нельзя всё запретить.
Юристы сказали:
— Нужно понять, что именно уже ушло.
IT сказали:
— Мы можем заблокировать домены.
Цифровая трансформация сказала:
— Но тогда люди уйдут в мобильные приложения.
HR спросил:
— А можно просто провести обучение?
На этой фразе в комнате повисла особенная тишина. Такая тишина бывает, когда кто-то предлагает тушить пожар корпоративным вебинаром.
В итоге, как обычно, родилось компромиссное решение. То есть решение, которым недовольны все, но зато оно выглядит разумно в протоколе.
Внешние AI-сервисы решили ограничить. Для сотрудников — выпустить памятку. Для ключевых команд — поднять корпоративный доступ к проверенной модели. Для безопасности — внедрить средство контроля промптов. Для руководства — подготовить доклад о рисках.
Доклад назвали «Безопасное использование генеративного ИИ в бизнес-процессах».
Это был уже первый тревожный знак.
Когда в названии документа появляется слово «безопасное», значит, до этого оно было примерно как получилось.
#
Так на рынке появился новый герой — LLM-firewall.
Название, конечно, условное. Кто-то называет это AI Security Gateway. Кто-то — Prompt Security. Кто-то — Data Loss Prevention for GenAI. Кто-то придумывает ещё более длинное название, чтобы продукт казался дороже.
Идея простая: поставить между пользователем и моделью умного пограничника.
Пользователь отправляет запрос — пограничник смотрит, нет ли там персональных данных, секретов, ключей доступа, внутренней документации, токсичного контента, попытки jailbreak, просьбы написать вредоносный код или фразы «сделай так, чтобы никто не узнал».
Модель отвечает — пограничник снова смотрит, не выдала ли она чего лишнего. Например, инструкцию по обходу защиты, внутренние данные, чужой секрет или уверенную галлюцинацию, которая завтра попадёт в письмо клиенту.
На бумаге всё прекрасно.
В реальности — начинается обычная жизнь.
Слишком строгий фильтр мешает работать. Слишком мягкий — ничего не ловит. Пользователи жалуются, что модель стала «тупой». Безопасность жалуется, что пользователи стали «слишком умными» и обходят ограничения через личные телефоны. Бизнес жалуется, что конкуренты уже внедрили ИИ, а мы опять обсуждаем политику использования. Юристы жалуются всегда, это часть профессии.
Поставщик решения уверяет, что всё решается настройками.
Настройки оказываются отдельным искусством.
Нужно понять, какие данные действительно нельзя отправлять наружу. Какие можно, но только в обезличенном виде. Какие модели разрешены. Где хранятся логи. Кто имеет к ним доступ. Что делать с промптами, в которых сотрудник нечаянно написал пароль. Что считать инцидентом. Как не превратить службу безопасности в редакцию, которая вручную читает чужие вопросы нейросети.
Потому что промпты — это не только риск.
Это ещё и зеркало компании.
По ним видно, кто чем занимается, кто чего не понимает, кто пишет отчёты за пять минут до дедлайна, кто просит модель «сделай вид, что проект идёт по плану», а кто честно спрашивает: «как объяснить начальнику, что задача бессмысленная».
Так что новый инструмент безопасности быстро превращается не только в защиту, но и в источник неприятных знаний.
А неприятные знания в корпорациях любят меньше, чем утечки.
#
Здесь мы подходим к важному отличию ИИ от старых технологий.
Старые системы безопасности в основном контролировали действия: файл отправлен, ссылка открыта, процесс запущен, порт доступен, пароль введён.
ИИ заставляет контролировать намерения.
Пользователь может задать невинный вопрос, который на самом деле является попыткой обойти запрет. Или задать опасный вопрос без всякого злого умысла. Или попросить модель «улучшить скрипт», а в скрипте окажется инструмент для перебора паролей. Или загрузить внутренний документ не потому, что хочет его украсть, а потому что не умеет писать краткое содержание.
В старом мире безопасность часто отвечала на вопрос: что произошло?
В новом ей придётся всё чаще отвечать на вопрос: что человек пытался сделать?
А это уже скользкая дорожка.
Потому что между защитой компании и тотальным наблюдением за сотрудниками граница тоньше, чем хотелось бы написать в презентации для совета директоров.
Особенно когда речь идёт о текстах, вопросах, черновиках и мыслях, которые человек ещё не успел превратить в действие.
Компании, конечно, скажут: мы не читаем мысли, мы защищаем данные.
И будут отчасти правы.
Но сотрудники всё равно начнут писать промпты так, будто их читает начальник, безопасник, юрист и мама.
Качество работы модели от этого, надо сказать, не улучшится.
#
Через несколько месяцев после первого инцидента та самая компания внедрила корпоративный LLM-firewall.
Теперь сотрудники могли пользоваться моделью официально. Запросы фильтровались. Секреты маскировались. Персональные данные ловились. Опасные инструкции блокировались. На дашборде появились красивые графики: количество запросов, категории рисков, топ-пользователи, динамика внедрения.
Руководству понравилось.
Особенно графики.
На очередной встрече директор по цифровой трансформации радостно сообщил, что компания «перешла к управляемому использованию генеративного ИИ». Служба безопасности сказала, что риски «существенно снижены». Бизнес сказал, что продуктивность «потенциально выросла». Юристы сказали, что нужно обновить политику обработки данных. HR предложил провести обучение.
На этот раз никто уже не смеялся.
Потому что обучение действительно было нужно.
Сотрудникам объяснили простые вещи. Не загружать конфиденциальные документы без необходимости. Не вставлять ключи и пароли. Не отправлять персональные данные. Не доверять ответам модели без проверки. Не использовать личные аккаунты для рабочих задач. Не просить модель сделать то, за что потом будет стыдно на внутреннем расследовании.
Вопросов было много.
Самый честный задал один разработчик:
— А если я не знаю, можно ли отправлять конкретный кусок текста?
Безопасник ответил:
— Тогда не отправляйте.
Разработчик кивнул с видом человека, которому только что предложили лечить все болезни сном и тёплой водой.
И вот тут стало окончательно понятно: проблема не в конкретном сервисе, не в одном домене и не в отсутствии очередной коробки.
Проблема в том, что технология стала полезной быстрее, чем компания научилась с ней жить.
А когда технология действительно полезна, запрет работает плохо. Люди будут искать обходные пути не потому, что они плохие. А потому, что у них есть работа, дедлайны, начальники, клиенты и привычка использовать самый короткий путь между страданием и результатом.
Безопасность может сколько угодно рисовать красные линии.
Но если за красной линией лежит инструмент, который экономит человеку три часа жизни, кто-нибудь обязательно принесёт стремянку.
#
Но настоящий финал этой истории случился позже.
Через полгода в компании проводили внутренний аудит использования ИИ. И выяснилось странное: количество попыток отправить чувствительные данные через официальный шлюз снизилось. Это была хорошая новость.
Плохая новость состояла в том, что часть сотрудников действительно ушла в обходные каналы.
Кто-то пользовался личным телефоном. Кто-то пересылал фрагменты себе в мессенджер. Кто-то заменял названия клиентов на «Компания А» и «Компания Б», искренне полагая, что теперь документ стал обезличенным. Кто-то фотографировал экран, распознавал текст и скармливал его внешней модели.
Один особенно творческий сотрудник переводил куски документа на испанский, отправлял модели, а потом переводил ответ обратно.
Зачем на испанский — никто так и не понял.
Видимо, в его личной модели угроз испанский язык служил криптографическим протоколом.
А потом случилось то, что делает эту историю не смешной.
Конкурент выпустил обновление своего продукта. Архитектура нового модуля была устроена нестандартно — именно так, как компания планировала сделать свой. Не похоже. Не «вдохновлено». Именно так: те же зависимости между сервисами, тот же нетривиальный способ обработки очереди, который инженер придумал сам и которым гордился.
Продакт-менеджер смотрел на чужой релиз и чувствовал что-то неприятное, у чего не было хорошего названия.
Может, совпадение. Отрасль небольшая, умные люди думают похоже. Может, утечка через партнёра. Может, бывший сотрудник. Может, тот самый промпт с архитектурной схемой, который инженер отправил в модель восемь месяцев назад.
Доказать ничего нельзя.
Инженер, кстати, тоже ничего не помнил.
В тот день он отправил сорок семь промптов.
Это был тридцать второй.