Comments 17
Волков бояться в лес не ходить. Намного больше шансов, что кто-то из сотрудников сольёт вас конкурентам, чем ИИ. Да и вообще ценная для других информация есть максимум 0.01% пользователей ИИ.
«Волков бояться» — плохой аргумент для ИБ. Тут надо смотреть не только на вероятность, но и на ущерб, и на цену защиты. А то получаем «вероятность 1/2: утечёт или нет».
Да, сотрудник может слить данные конкурентам. Я даже видел компанию, где ключи от серверной были у охраны и у (!) уборщицы (причём да, в серверной был порядок и не было пыли; а охрана — потому что в случае пожара кто проследит за пожарными?): сотрудники шутили, что вместо взлома за миллион денег куда дешевле будет заплатить уборщице, чтобы она ночью пришла и выдернула диски из серверов и хранилок.
Но из этого не следует, что внешний LLM‑контур можно игнорировать. Это просто ещё один канал передачи данных наружу: логи, хранение, подрядчики, юрисдикция, посредники, непонятный объём контекста.
И «ценная информация есть у 0.01% пользователей» — слабый тезис. Ценность — это не только секретная формула. Хосты, домены, версии ПО, куски логов, топология, клиенты, фрагменты кода и тикетов — всё это вполне полезный материал. Модель такое выделит из текста легко.
Поэтому вопрос не в панике и не в запрете ИИ, а в призыве «мыть руки перед едой (а не когда уже в инфекционку после немытого помидора повезли)»: думать, что можно отправлять наружу, что надо маскировать, а что вообще не должно уходить во внешнюю модель.
Вы не на собеседовании, не надо так преукрашивать важность специалиста ИБ. Вообще ничего плохого не случится если ИИ узнает версию ПО, домены, хосты и логи.
Если только запросы не из компании OpenAI в DeepSeek или наоборот.
В нашей компании специалисты ИБ очень мешали работать, мы даже думали, что их специально подослали.
Если им надо будет они легко это получат от любого сотрудника компании который уже очень много от себя написал.
Прямо отлично Вас понимаю.
Но из того, что плохая ИБ мешает, не следует, что рисков нет. Версии ПО, домены, хосты и логи сами по себе могут быть не страшны. Вопрос в сочетаниях. Один лог — мусор. Много логов плюс версии, внутренние имена, ошибки, куски конфигов, тикеты и фрагменты кода — уже карта инфраструктуры.
И да, часть этого можно получить от сотрудников. Но это не аргумент за то, чтобы добавлять ещё один неконтролируемый канал. По такой логике можно и production‑логи в публичный pastebin выкладывать: «если надо, всё равно достанут».
Думать об этом имеет смысл не потому, что завтра точно взломают, а потому что подумать стоит дёшево и уменьшает площадь утечки.
Ну и да, никогда не знаешь, кому ты понадобишься. Помните, книга есть такая, «Яйцо кукушки» Клиффорда Столла. Полностью «The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage“
Правильно я вас понимаю, вы считаете что данные какой-либо компании из РФ, например. Могут быть интересны компании OpenaAI например?
Более чем интересны. А если учесть, что OpenAI спокойно могут передавать данные государственным органам, то это хороший и почти легальный способ следить за тем, что просиходит в чужой стране. И на фоне внутренних колебаний вставлять свои 5 копеек
Зная, что происходит в Сбере, Газпроме, Роснефти и т.д. - можно легко предсказать куда надавить и какие новые санкции ввести. И даже не надо для этого никакие тайны красть, сотрудники сами загрузят отчет и попросят "сделать красиво для начальства". А там уже дело за малым, возьми данные, быстро проанализиуй и придумай, как это использовать во вред
Вот да, не то чтобы закошмариить, но...
в США есть механизмы вроде FISA Section 702, где возможна принудительная помощь американских провайдеров при сборе внешней разведывательной информации по иностранным целям за пределами США. Причём, это не "по желанию", а, как у нас с РКН и фильтрацией, "кто не все, того накажем" и многими проблемами. И миллиардными компаниям явно защищать данные клиента за $20 (да, да, знаю, что "$20 - это $20!", но тут масштаб немного другой) резона нет.
у Китая своё: Закон о национальной разведке прямо говорит, что организации и граждане должны поддерживать, помогать и сотрудничать с разведывательной работой, а разведорганы могут запрашивать необходимую поддержку. Например, DeepSeek в privacy policy прямо пишет, что собирает и обрабатывает user input, может использовать данные для улучшения и тренировки технологии, хранит данные в КНР, а также может раскрывать данные по юридическим требованиям, регуляторам и госорганам. У Alibaba Cloud Model Studio, наоборот, в FAQ заявлено, что данные клиентов не используются для обучения моделей, передаваемые данные шифруются, а сервис доступен в разных регионах, включая Singapore, US, Beijing, Hong Kong и Germany.
Как говорится, "подумайте, и мы подумаем!" )
чет однобокая статья
факты в том что уже было достаточно судебных разбирательств в америке когда сам openai сливал данные чата полиции просто потому что
сколько он реально сливал (ведь до суда я думаю не все дошло) и сколько ноунейм-индусов имеют доступ к вашим чатам вот это действительно хороший вопрос безопасности
а за проекты и "воровство" - скорее сама компания что предоставляет АИ будет собирать общие "метрики идей" что бы отслеживать что люди "обсуждают создавать". отдельные чаты человека в этом плане никому нафиг не упали ведь те кто имеют доступ к вашему чату, имеют еше и в миллионам других и даже если ваш чат выделяется из серой массы (нет)то все равно вчитываться в него будет разве что новичок на этой работе, а вынести что-то из этого и вовсе 0%
Тут бы мух от котлет отделить. Ну и да, сначала решить, с каким именно провайдером вы работаете, чтобы потом понимать, на чьи обещания вы вообще юридически полагаетесь.
Мысль изначально верная: данные отправляются вовне. Такое и до LLM требовало внимания. Просто раньше это были почта, SaaS, тикеты, облачные хранилища, подрядчики и удалённые админы, а теперь к этому добавились модели, агенты, коннекторы и IDE-помощники.
Ок, отправили мы данные в облачную модель — что дальше, какие риски?
Во-первых, данные могут пойти на улучшение модели, если это не отключено условиями тарифа или настройками. Во-вторых, они могут остаться в логах, бэкапах и внутренних системах провайдера. В-третьих, их иногда могут читать люди — например, если диалог попал на проверку безопасности, разбор жалобы или расследование инцидента. В-четвёртых, есть подрядчики, юрисдикция провайдера и законные запросы госорганов, о которых клиент может вообще ничего не узнать.
И тут важно не говорить «у всех одинаково». Не одинаково. У OpenAI для Business, Enterprise и API по умолчанию заявлено, что пользовательские входы и выходы не используются для обучения моделей, если организация сама явно не включила такой режим. У Anthropic для коммерческих продуктов и API похожая логика: по умолчанию не используют входы и выходы для обучения, но если отправить feedback, может сохраниться весь связанный диалог. У Google тоже разные режимы: consumer Gemini — одна история, Workspace с корпоративными условиями — другая. У DeepSeek — уже другая юрисдикция и другая политика обработки данных. То есть вопрос не «ChatGPT или не ChatGPT», а конкретно: какой сервис, какой тариф, какой договор, какая настройка, какой retention и кто является стороной договора.
Отдельный риск — посредники. Если я иду напрямую в ChatGPT, Claude или Gemini, то хотя бы примерно понятно, с кем у меня отношения: вот провайдер, вот его условия, вот его настройки. А если я иду через агрегатор вроде OpenRouter, AIHubMix, proxy-сервисы, «дешёвые ключи», появляется второй слой. Посредник может честно обещать одно, но сам запрос он дальше отдаёт конечному исполнителю. И договор между посредником и этим исполнителем — уже отдельная история, которую обычный пользователь чаще всего не видит.
Это особенно заметно на недорогих open-weight моделях. Условный небольшой Qwen, Llama, DeepSeek или Mixtral через агрегатор — это не всегда «одна модель в одном месте». Сегодня запрос может уйти к одному inference-провайдеру, завтра к другому, а при сбое — к третьему, если не отключены fallback-и. У OpenRouter это прямо описано: по умолчанию он может маршрутизировать запросы между провайдерами, можно выбирать конкретных провайдеров, отключать fallback-и, запрещать провайдеров с хранением данных и включать Zero Data Retention. Но если этого не сделать, экономия на токенах легко превращается в схему «мы даже примерно не знаем, у кого в итоге оказался наш prompt».
Причём «не обучаем на ваших данных» и «ничего не храним» — это разные обещания. Провайдер может не обучать модель на ваших запросах, но всё равно хранить их для abuse‑monitoring, биллинга, отладки, расследования инцидентов или по юридическим причинам. И вот «их» юрилические причины хранить (а как долго — нам никто не скажет) «им» куда ближе, чем требования «нашей» ИБ.
И это мы пока говорим о случаях, когда в модель сознательно отправляется, скажем, кусок исходников — пусть даже не всегда удачно выбранный, но хотя бы примерно понятный кусок.
А есть ещё менее прозрачный процесс: коннекторы, MCP, IDE-агенты и прочие «помощники». Человек думает, что отправил модели кусок кода, а на деле агент может видеть репозиторий, историю git, локальные файлы, тикеты, документацию, скриншоты, логи — и часто даже то, что вообще не собирались показывать. Поэтому простое правило «не вставляйте пароли в ChatGPT» уже слабовато.
Нужно делить данные по классам. Публичное и неважное можно отправлять в обычные сервисы, но лучше с отключённым обучением. Рабочие внутренние данные — только через корпоративный тариф, API или свой шлюз, где понятны правила хранения, логи, доступы и ответственность. Клиентские данные, персональные данные, финансы, NDA и production-логи — только после очистки, обезличивания или через отдельный защищённый контур. Ключи, токены, приватные сертификаты, сырые дампы и критичные инциденты лучше вообще не отдавать внешней модели.
Для coding-agent нужны отдельные ограничения: песочница, доступ только к нужным файлам, запрет на чтение .env, ключей и секретов, отдельный пользователь без production-доступа, запрет лишнего сетевого доступа, список разрешённых команд, логирование действий и ручное подтверждение опасных операций.
И локальная модель тоже не решает всё автоматически. Если вокруг неё стоят облачные плагины, внешние MCP-серверы, телеметрия, общий векторный поиск и неочищенные логи, то это уже не совсем «локальная» схема.
Нормальная политика должна звучать не как «ИИ запрещён», а как: какие данные, в какие модели, через какой канал, с каким хранением, аудитом и ответственным владельцем можно отправлять. Без этого любой ChatGPT, Claude, Gemini, Cursor, OpenRouter или локальный агент превращается в неучтённый канал передачи данных наружу.
P.S. Отдельный практичный слой защиты — локальная псевдонимизация перед отправкой в модель. Реальные хосты, домены, IP, логины, имена клиентов, внутренние URL и названия проектов заменяются локальным фильтром на условные host-01, customer-03, service-a, internal-domain.test. Таблица соответствий остаётся у нас, наружу уезжает только обезличенный текст. Главное — делать замену стабильной внутри одной задачи, чтобы модель не потеряла связи между логами и конфигами. Это не абсолютная защита: по структуре инцидента, версиям, путям и редким ошибкам всё равно можно раскрыть контекст. Но как дополнительный слой перед облачной моделью — вполне разумно.
Вот про историю гит правильно. Потому что даже можно почистить репозитории от sensitive данных, но их можно увидеть в истории гита. И вроде есть разные скрипты, которые от определённых файлов вычищают всю историю гита, но тогда старые комиты могут перестать собираться потому что какие-то важные данные могли быть не вынесены в env файлы поэтому нужно какие-то нужные для запуска файлы нужэно грохнуть целиком, и эффект может быть сопоставим с полным удалением всей истории гита.
Добавляем то, что проблемы могут быть из-за багов сами агентов. С тем же клодом такой прикол был: https://habr.com/en/companies/ddosguard/news/1018916/, на плагин Continue был заведен баг на то, что он отправляет телеметрию, хотя в настройках было выставлено не отправлять. И если селф хостед можно как-то контролировать, то с проприетарным софтом это всё черный ящик, который по сути может делать что угодно и пользователь не имеет представления о том, что происходит.
Те, кто отправляют содержимое репозитория в модель — репоэксфильтраторы.
Те, кто изучают поведение репоэксфильтраторов — репоэксфильтратологи.
Те, кто читают репоэксфильтратологов перед подключением IDE-агента, — превентивные репоэксфильтратологоконсультанты.
Те, кто ненавидят превентивных репоэксфильтратологоконсультантов и говорят «он же просто посмотрит структуру проекта» — репоэксфильтратологоконсультантофобы.
Те, кто доказывают репоэксфильтратологофобам, что в контекст улетели .env, миграции, тестовые дампы и config.old — контекстоэксфильтратологоаналитики.
Те, кто после контекстоэксфильтратологоаналитиков срочно пишут .aiignore, но забывают про историю git — квазиконтекстосанитизаторы.
Те, кто проверяют квазиконтекстосанитизаторов через локальный шлюз, аудит, псевдонимизацию и список реально отправленных файлов — антиэксфильтратоаудитологи.
Те, кто выдают себя за антиэксфильтратоаудитологов, но запускают агента от пользователя с доступом к production и фразой «он просто посмотрит структуру проекта» — квазиантиэксфильтратоаудитологоагентозапускаторы.
P.S. Так выпьем, чтобы нас не называли такими зверскими словами!
Если я использую LLM, то мои промпты никуда не уходят. Поэтому название статьи неверное.
Если в человеке есть что-то уникальное и выдающиеся то навряд ли он пользуется этими заурядными AI. И точно он уже с детства "под колпаком". И навряд ли среднестатистический человек можете выдать какие-то уникальные идеи, но он может спровоцировать себя какими-то острыми вопросами и темами!
А что только про LLM? Google Translate тоже сливает данные ФБР, Христо Грозев спалил это в последнем расследовании https://youtu.be/A9m0FnFg9M0?t=1000
Ваши секреты внутри LLM. Куда уходят промпты и чего стоит опасаться?