ГК «Солар» проанализировала, что именно сотрудники отправляют в публичные ИИ‑сервисы — и выяснила, что конфиденциальная информация встречается в заметной доле запросов. Больше всего рискуют команды разработки: вместе с вопросами про ошибки в коде во внешний контур нередко уезжают фрагменты архитектуры, токены и ключи доступа.
Публичные ИИ‑сервисы всё чаще становятся «вторым экраном» для работы: спросить, как поправить ошибку, попросить сделать выжимку из документа или быстро собрать черновик письма. Но у этой привычки есть неприятная сторона: вместе с рабочим контекстом во внешний сервис можно случайно отправить то, что вообще не должно покидать периметр компании.
ГК «Солар» (провайдер решений в области кибербезопасности) изучила практику использования публичных ИИ‑сервисов в крупных российских компаниях. По данным анализа, в 38% зафиксированных взаимодействий с ИИ встречалась конфиденциальная информация. В исследование вошли 12 000 взаимодействий, собранных в рамках пилотов DLP‑системы Solar Dozor за январь—июнь 2026 года. Также указано, что суммарно анализ охватил пилотные проекты в 150 компаниях из разных отраслей (финансы, промышленность, ритейл, телеком, ИТ, госсектор).
Что именно «утекает» в промпты и загрузки
Среди обращений, где выявлялась конфиденциальная информация, распределение выглядело так:
- 41% — исходный код и конфигурации;
- 30% — персональные, финансовые и другие чувствительные данные;
- 18% — сведения, относящиеся к интеллектуальной собственности;
- 11% — пароли, токены и API‑ключи.
Отдельно выделяется последняя категория: ключи и токены опасны не «перспективным ущербом», а прямым доступом к системам. Даже одна случайно вставленная строка из .env или конфигурации CI/CD может превратить «быстрый вопрос к ассистенту» в инцидент.
Почему больше всего рискуют разработчики
По данным «Солара», 43% взаимодействий с передачей корпоративной информации приходится на команды разработки. Причина простая: разработчики используют ИИ как ускоритель рутины — для разборов ошибок, рефакторинга, генерации тестов, пояснений к логам и конфигам. И почти всегда это требует контекста: фрагмента кода, части трассировки, кусочка конфигурации.
Проблема в том, что технический контекст часто «цепляет» лишнее. Например:
- в логах встречаются внутренние адреса, имена сервисов, идентификаторы пользователей;
- в конфигурациях могут быть параметры интеграций и секреты;
- в коде бывают подсказки о структуре системы и правилах авторизации.
Коммерческие подразделения тоже в зоне риска: на них, по данным анализа, приходится 26% обращений с чувствительной информацией. В таких запросах могут «всплывать» материалы из CRM, условия сделок, переписки и клиентские базы — ровно то, что удобно быстро «причесать» с помощью генеративного ассистента.
Как это превращается в управленческую задачу, а не только в ИБ‑политику
В публикации подчёркивается: публичный ИИ для бизнеса — уже рабочий инструмент, а не эксперимент. Поэтому ставка только на запреты редко работает: сотрудники всё равно ищут быстрый способ решить задачу.
«Солар» описывает подход к управлению использованием ИИ на двух уровнях:
- Контроль доступа к сервисам: какие инструменты допустимы, кому и для каких сценариев.
- Контроль содержимого: какие категории данных нельзя отправлять во внешний контур (в тексте, файлах, вставках из буфера обмена).
Идея понятная: сохранить полезные сценарии (ускорение разработки, аналитики, подготовки документов), но снизить риск утечек. В заметке также упоминается роль обучения сотрудников: важно объяснять не абстрактную «кибергигиену», а конкретные правила работы с промптами — какие данные нельзя вставлять и почему даже «безобидный кусок кода» может быть чувствительным.
Практический вывод для команд разработки
Главный сигнал из исследования простой: утечки через ИИ чаще происходят не из злого умысла, а из привычки делиться контекстом. Если в компании разрешены публичные ассистенты, стоит заранее договориться о базовых правилах:
- не отправлять в запросы секреты, токены, ключи и содержимое переменных окружения;
- для разборов ошибок использовать обезличенные логи и минимальные фрагменты кода;
- разделять «попросить объяснить» и «вставить половину репозитория»;
- включить проверку на чувствительные данные там, где это возможно (на уровне шлюза/прокси и DLP‑контуров).
ИИ действительно экономит время, но цена одной неосторожной вставки может оказаться слишком высокой — особенно когда в промпт уезжает то, что открывает доступ к инфраструктуре.
