7 ошибок конфиденциальности данных ИИ-агентов, которые незаметно сливают данные вашей компании (и как их избежать)

Большинство утечек данных через ИИ-агентов происходит не из-за того, что модель тайком запоминает вашу компанию. Они вызваны ошибками конфигурации и архитектуры, которые вы можете назвать и исправить. Главные из них: работа на аккаунте потребительского уровня, чьи настройки по умолчанию обучаются на ваших вводных данных, передача агенту широких прав одного человека, подключение публичного агента к внутренним системам и сохранение «смертельной триады» нетронутой (приватные данные, недоверенный контент и внешний канал отправки), так что одна инъекция промпта может прочитать ваши данные и отправить их наружу. Именно по этому последнему сценарию EchoLeak (CVE-2025-32711) раскрыл чувствительные данные через Microsoft 365 Copilot из специально составленного письма, без единого клика пользователя. Решения не экзотичны, и почти все они являются решениями, принятыми до запуска агента, а не чек-листом, переданным вам после того, как что-то утекло.

Это список, который мы прорабатываем, прежде чем поместить построенного нами агента внутрь стека другой компании, написанный так, чтобы нетехнический владелец мог распознать те же ошибки в своей собственной системе или у подрядчика. Если вы предпочтёте, чтобы мы держали эту линию там, где она должна быть для вас, посмотрите, как мы выстраиваем ответственное управление ИИ и рисками. Всё, что ниже, в любом случае ваше для использования.

Сначала разграничение, которое размывает почти каждая статья на эту тему, потому что ошибиться здесь значит совершить ошибку номер ноль. Есть два совершенно разных способа, которыми данные утекают через агента, и у них совершенно разные решения:

• Обработка данных провайдером. Хранит ли провайдер модели ваши вводные данные или обучается на них? Это контракт, который вы подписываете, и уровень аккаунта, который вы выбираете. Решается условиями и конфигурацией.
• Эксфильтрация во время выполнения. Можно ли обмануть агента в момент его работы, чтобы он отправил ваши данные туда, куда не должен? Это решается архитектурой, а не контрактом.

Цифры опросов говорят, что покупатели чувствуют это, даже если не могут назвать. В исследовании Cloudera, охватившем почти 1500 старших ИТ-руководителей в 14 странах, 96% планируют расширить использование ИИ-агентов в течение следующего года, и при этом 53% (более половины) называют конфиденциальность данных главным препятствием для внедрения. Семь ошибок ниже это место, где этот страх становится реальной утечкой, и где живёт решение.

Ошибка 1: запуск рабочих агентов на аккаунтах потребительского уровня

Это самая дешёвая ошибка и самая лёгкая для исправления. Кто-то подключает рабочий процесс к личному ChatGPT или потребительскому аккаунту Gemini, потому что он уже под рукой, и теперь данными вашего бизнеса управляют потребительские условия, которые никогда для них не предназначались.

Разрыв между потребительским и корпоративным уровнями резкий. На корпоративной стороне паттерн одинаков у всех провайдеров: никакого обучения на ваших данных по умолчанию, короткое окно хранения для мониторинга злоупотреблений и более строгие опции по запросу. API OpenAI хранит данные 30 дней для мониторинга злоупотреблений, а затем удаляет их и по умолчанию на них не обучается. С 14 сентября 2025 года Anthropic сократил срок хранения логов API с 30 дней до 7, а вводные и выходные данные API никогда не используются для обучения. Vertex AI от Google (корпоративный уровень) настраивается без использования данных для обучения. На потребительской стороне настройки по умолчанию переворачиваются: потребительский ChatGPT хранит разговоры бессрочно, пока вы их не удалите, а срок хранения у потребительского Gemini достигает 36 месяцев, и данные могут использоваться для улучшения продуктов.

Решение: поместите каждого рабочего агента на корпоративный API или бизнес-аккаунт, а не на личный логин. Технология идентична. Условия нет, и именно условия составляют всю разницу между данными, которые остаются под управлением, и данными, которые незаметно становятся обучающим материалом.

Ошибка 2: избыточные права, которые наследует агент

Самая распространённая утечка во время выполнения не хитра. Агенту передают доступ одного сотрудника, или, хуже того, ключ администратора, так что технически он может видеть всё, что видит этот человек. Затем ему задают вопрос, или обманом подводят к вопросу, который выходит далеко за пределы его работы.

Cloud Adoption Framework от Microsoft формулирует правило прямо: «Предоставляйте агентам доступ только к тем конкретным источникам данных, которые требуются для их функции. Не давайте широкий доступ ко всем данным организации». Агенту поддержки не нужна ваша система начисления зарплаты. Агенту планирования не нужна база данных клиентов. Когда агент действует от имени человека, он должен наследовать разрешения этого человека, безопасно передавая его идентичность, чтобы агент службы поддержки показывал сотруднику только его собственную запись в кадрах, а не всех подряд.

Решение: дайте каждому агенту собственную идентичность с минимально необходимыми правами и заставьте его наследовать разрешения действующего пользователя, а не носить постоянный супернабор. Тест прост. Если завтра агента обманут, ущерб будет ограничен узким набором, который ему предоставили, а не всем, до чего мог дотянуться один аккаунт с избыточными правами.

Ошибка 3: публичные агенты, подключённые к внутренним данным

Чат-бот на вашем сайте и агент, который составляет внутренние отчёты, это два разных мира безопасности, и утечка происходит в тот момент, когда кто-то позволяет им разделить общий бэкенд. Публичный агент принимает ввод от кого угодно в интернете. Если этот же агент может также запрашивать внутренние бизнес-данные, вы построили дверь из публичного веба прямо в свои приватные системы.

Фреймворк Microsoft проводит здесь самую жёсткую черту: «Публичные агенты не должны иметь доступ к внутренним бизнес-данным». Держите конфиденциальное и публичное разделёнными физической или логической границей (в их примере используются отдельные группы управления «corp» и «online»). Суть в том, что граница структурна, а не надежда на то, что промпт устоит.

Решение: поставьте реальную границу между агентами, которые принимают недоверенный публичный ввод, и агентами, которые касаются конфиденциальных данных. Если один агент действительно должен делать и то, и другое, это самый рискованный дизайн, который вы можете выбрать, и ему нужны меры, разрывающие триаду, из следующих ошибок, а не просто аккуратный системный промпт.

Ошибка 4: игнорирование смертельной триады

Это ошибка, которая превращает первые три в настоящую эксфильтрацию. Саймон Уиллисон, независимый эксперт, придумавший термин «инъекция промпта», назвал «смертельную триаду» для ИИ-агентов: три условия, которые, будучи объединёнными, позволяют одной внедрённой инструкции украсть ваши данные.

Когда присутствуют все три, злоумышленник прячет инструкцию внутри недоверенного контента. Модель, по словам Уиллисона, «с радостью выполнит любые инструкции, которые до неё доходят, независимо от того, пришли они от её оператора или из какого-то другого источника». Она читает ваши приватные данные и отправляет их наружу, и ничто в промпте не говорило ей не доверять письму.

Жёсткая часть и причина, по которой это архитектура, а не проблема инженерии промптов: «мы по-прежнему не знаем, как предотвратить это на 100% надёжно». Задокументированные эксплойты затронули Microsoft 365 Copilot, MCP-сервер GitHub и GitLab Duo. За одну неделю в январе 2026 года уязвимости непрямой инъекции промпта были раскрыты в четырёх инструментах продуктивности на ИИ, все по одному и тому же паттерну триады.

Решение: разорвите одно звено. Запретите внешний канал отправки, чтобы украденным данным некуда было деться, или никогда не позволяйте агенту, который читает недоверенный контент, одновременно иметь доступ к приватным данным в том же контексте. Вам не нужно выигрывать невыигрываемую битву по перехвату каждой инъекции. Вам нужно убедиться, что даже успешная инъекция не имеет пути наружу.

Ошибка 5: отношение к EchoLeak как к чужой проблеме

Стоит назвать один реальный инцидент, потому что «смертельная триада» звучит абстрактно, пока вы не увидите её в действии. EchoLeak (CVE-2025-32711) была атакой без кликов (zero-click) на Microsoft 365 Copilot. Злоумышленник отправил специально составленное письмо. Copilot, выполняя свою обычную работу, обработал это письмо (недоверенный контент), имел доступ к внутренним данным пользователя (приватные данные) и располагал способом отправить информацию наружу (внешняя связь). Скрытая инструкция завершила раскрытие чувствительных данных вообще без какого-либо взаимодействия пользователя. Никто ничего не нажимал.

Ошибка здесь в предположении, что утечка требует невнимательного сотрудника. EchoLeak не требовал никакого. Защита, которая имела значение, была не «обучите персонал распознавать фишинг», потому что человеку нечего было распознавать. Защита была архитектурной: агент, который не может одновременно читать контент, контролируемый злоумышленником, и эксфильтровать данные, не может быть обращён против вас таким образом.

Решение: считайте, что атака без кликов это модель угрозы, а не исключение. Если ваш агент читает что-либо, на что может повлиять посторонний (письмо, веб-контент, загруженные файлы, тикеты), и он также может отправлять данные наружу, у вас есть дыра в форме EchoLeak, пока вы не закроете одну из этих двух возможностей или жёстко не оградите канал отправки.

Ошибка 6: отсутствие границы по размещению или хранению данных

Некоторые утечки это не драматичные эксфильтрации, это медленный дрейф. Данные оказываются хранимыми в регионе, на который вы никогда не соглашались, или лежат в логах дольше, чем позволяет ваша политика, просто потому что никто не установил границу. Фреймворк Microsoft перечисляет это как базовое управление: определите расположение каждого источника данных, среды выполнения агента и хранилища результатов, держите данные в регионах или локально (on-prem), которые соответствуют вашей политике размещения, и держите их зашифрованными при хранении.

Обнадёживающая новость, которую почти ни одна статья не формулирует прямо, это то, насколько многое можно зафиксировать. Корпоративный паттерн у всех провайдеров это отсутствие обучения по умолчанию плюс короткое окно хранения плюс более строгие гарантии по запросу. Anthropic предлагает подходящим предприятиям соглашение о нулевом хранении данных (Zero Data Retention, ZDR), по которому вводные и выходные данные не хранятся дольше, чем нужно для проверки на злоупотребления. OpenAI предлагает ZDR через согласованное соглашение и размещение данных. Оба позволяют вам выбирать, где живут данные. Самостоятельный хостинг открытой модели (например, с Ollama) держит данные полностью локально с нулевым хранением у третьих сторон.

Решение: определите и задокументируйте границу до запуска. Какой регион хранит данные, как долго живут логи, нужен ли вам ZDR и должно ли извлечение чувствительных данных выполняться в вашей собственной VPC или локально (on-prem). ZDR обычно доступен только для API и согласуется, и он не покрывает автоматически каждый продукт, если вы его не добавите, поэтому детали важны.

Ошибка 7: отношение к приватности как к чек-листу, который вы передаёте

Последняя ошибка структурна. Большинство руководств, включая превосходный фреймворк Microsoft, предполагает, что вы сами построите агента и будете им управлять, поэтому вам вручают стопку из 3000 слов про идентичности Entra, метки Purview и группы управления. Это правильный ответ для большой ИТ-команды. Для большинства бизнесов это чек-лист, у которого ни у кого нет времени или специализированного навыка, чтобы полностью его реализовать, поэтому он отгружается наполовину, и пробелы это ровно те места, где данные утекают.

Ошибка в отношении к мерам контроля как к документации, а не как к архитектуре, за которую кто-то отвечает от начала до конца. Чек-лист, который перечисляет «изолируйте конфиденциальные данные» и «ограничьте внешние интеграции доверенными MCP-серверами», хорош лишь настолько, насколько хорош человек, который это подключает, проверяет каждую внешнюю связь и поднимает план реагирования на инциденты, чтобы быстро отключить агента, когда что-то идёт не так.

Решение: убедитесь, что одна сторона действительно владеет границей, а не только документом. Либо вы строите внутреннюю способность реализовывать и поддерживать весь стек, либо у вас есть оператор, который проектирует эти сценарии отказа как невозможные и обслуживает их, с опубликованной границей, на которую вы можете указать. Неправильная золотая середина это список мер контроля и никого, кто отвечает за то, чтобы они держались.

Как выстраиваются семь ошибок и решений

Вот все семь в одном месте, отсортированные по тому, является ли решение контрактом, который вы подписываете, или архитектурой, которую вы строите. Это разделение самый быстрый способ понять, какая команда владеет каждым из них.

Обратите внимание, что только две из семи решаются контрактом. Остальные пять это архитектура и ответственность, та часть, которую PDF с лучшими практиками не может сделать за вас. Это также честная причина, по которой авторитетные источники оставляют пробел: они говорят вам, что строить, а не кто построит это правильно внутри ваших конкретных систем.

Что на самом деле никогда не покидает периметр, когда граница выстроена правильно

Легко прочитать семь ошибок и заключить, что ИИ-агенты это минное поле для приватности. Это не так, когда линия проведена осознанно. На корпоративных условиях ваши вводные данные не являются обучающими, а срок хранения это дни, а не вечность (7 для API Anthropic, 30 для OpenAI, затем удаление). С ZDR они не хранятся дольше проверки на злоупотребления. С зафиксированным размещением данных они остаются в вашем регионе. С извлечением через VPC или локально (on-prem) чувствительные данные вообще не покидают ваш периметр. С маскированием на границе поля, которые никогда не должны путешествовать, удаляются до того, как что-либо будет отправлено. С минимально необходимыми правами, наследующими разрешения пользователя, агент может дотянуться только до того, до чего уже мог дотянуться действующий человек.

Это конкретная, защитимая граница, и способность сформулировать её прямо это и есть весь смысл. Опасность никогда не была в том, что модель тихо впитает вашу компанию. Она в семи ошибках конфигурации и архитектуры выше, каждую из которых можно предотвратить до того, как первый агент выйдет в работу.

Это работа, которую мы делаем внутри стеков других компаний: выбор условий, определение прав идентичностей, изоляция публичного от конфиденциального, разрыв триады и владение границей, чтобы она держалась. Если вы хотите, чтобы эти ошибки были спроектированы как невозможные в ваших агентах до того, как они коснутся чего-либо реального, запишитесь на бесплатную консультацию ниже, и мы вместе составим карту вашей границы.