Project Lily: люди читают переписки с ChatGPT

404 Media 14 сентября сообщило, что OpenAI нанимает сотни подрядчиков читать поток реальных запросов пользователей ChatGPT — вплоть до целых диалогов — и оценивать ответы бота. Имена пользователей проверяющим не показывают, персональные данные компания старается вычищать, но признаёт, что чувствительные детали проходят фильтр. У ChatGPT больше 900 миллионов пользователей, и большинство из них об этом не знает.

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

Что именно говорит источник

Публикация вышла 14 сентября 2026 года в 404 Media за подписью Джозефа Кокса. Основание — утёкшие внутренние документы и реальные промпты, которые издание видело своими глазами.

Ключевые утверждения:

• OpenAI нанимает сотни подрядчиков, читающих поток реальных запросов пользователей;
• проверяющие видят целые диалоги, а не отдельные реплики;
• задача команд — оценивать и критиковать ответы бота, чтобы улучшать их;
• внутренние документы показывают, что бота учат не очеловечивать себя и быть менее угодливым;
• имена пользователей подрядчикам не показывают;
• OpenAI заявляет, что старается удалить персональные данные до того, как промпт дойдёт до проверяющего, но признаёт, что чувствительные детали всё равно проходят;
• Anthropic подтвердила изданию, что тоже использует проверку людьми.

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

Почему это важнее, чем кажется

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

Отсюда и риск. Люди используют чат-бота как психотерапевта, помощника по работе и собеседника, и выкладывают туда подробности жизни, которых не сказали бы незнакомому человеку. Именно этот разрыв между ожиданием и практикой публикация и вскрывает.

Чего мы не утверждаем

Здесь важно не додумывать за вендоров.

Мы не утверждаем, что то же самое происходит с запросами через API. Публикация описывает поток пользователей ChatGPT — потребительского продукта с собственными условиями. У API и корпоративных договоров условия обработки данных обычно отдельные, и разбираться нужно по документам конкретного вендора.

Мы не утверждаем, что OpenAI нарушила свои правила. В материале нет такого вывода, и компания сама описывает попытку удалять персональные данные перед просмотром.

Мы не знаем, какая доля запросов попадает на просмотр. Числа в открытой части нет, и подставлять своё мы не станем.

Что из этого следует для рабочих данных

Практический вывод не в том, чтобы перестать пользоваться моделями. Он в том, чтобы перестать считать окно чата приватным по умолчанию — и перестроить работу под это допущение.

Три уровня, по которым стоит разложить свои сценарии.

Первый — что вообще не отправляется. Персональные данные клиентов, медицинские сведения, паспортные и платёжные реквизиты, коммерческая тайна с грифом. Не «отправляется осторожно», а не отправляется. Правовую сторону мы разбирали в материале коммерческая тайна и нейросети.

Второй — что отправляется обезличенным. Большинство рабочих задач не требует настоящих имён и номеров. Заявка клиента разбирается на поля одинаково хорошо, если вместо «Иванов Иван, +7 900…» стоит «Клиент 1, телефон скрыт». Подстановка обратно делается на вашей стороне после ответа.

Третий — что отправляется как есть. Публичные тексты, описания товаров, код без секретов, черновики статей. Здесь вся эта осторожность лишняя и только мешает работать.

Как разделить контуры технически

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

Здесь же уместно сказать про наш контур прямо. Содержимое запросов на стороне KeyDealer не сохраняется: остаются токены, модель, сумма, статус и время, перечень опубликован в llms.txt. Один ключ открывает каталог из 53 позиций, 40 из них доступны сейчас, оплата российской картой в рублях, ставки от 1 ₽ за миллион токенов. Обратная сторона честная: текст запроса по обращению в поддержку мы не восстановим, потому что его у нас нет.

Про хранение и ротацию самих ключей — в материале как хранить API-ключи, а про то, что и зачем писать в журнал на своей стороне, — в разборе логирование запросов к моделям.

Чем просмотр людьми отличается от обучения на ваших данных

Эти две вещи постоянно смешивают, а последствия у них разные.

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

Просмотр людьми — это оценка качества ответов. Текст не уходит в веса, но его читает человек. Для коммерческой тайны разницы почти нет: прочитанное прочитано. Для персональных данных разница есть, и она правовая.

Практический вывод один: спрашивать у вендора нужно про оба режима отдельно, а не про «безопасность» вообще. И ответ брать из условий договора, а не из маркетинговой страницы.

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

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

Отсюда два правила. Не кладите в системный промпт то, что не готовы увидеть у конкурента. И не храните рабочие промпты только в чужом интерфейсе — про это мы писали в материале хранение промптов у вендоров.

Как выглядит обезличивание на практике

Не как юридическая процедура, а как десять строк кода перед вызовом.

Берётся текст запроса, из него по регулярным выражениям и справочнику вынимаются сущности: имена, телефоны, адреса электронной почты, номера карт и документов. Каждая заменяется меткой с номером — «Клиент 1», «Телефон 1», «Документ 1». Соответствие меток и настоящих значений хранится в памяти процесса ровно на время запроса. Ответ модели возвращается с метками, и подстановка делается обратно у вас.

Три вещи, которые ломают эту схему:

• Контекст, из которого человек узнаётся без имени. «Директор единственной в городе типографии» — это идентификация, даже если ФИО вырезано. Регулярка такое не ловит, и решать это приходится на уровне сценария.
• Вложения. Скан договора уходит целиком, и обезличивание текста запроса тут не помогает вовсе.
• История диалога. Обезличили первое сообщение, а на пятом шаге подставили настоящие данные «для точности» — и вся цепочка ушла как есть.

Как проверить, что у вас уходит наружу

Способ грубый и работающий: включите на своей стороне запись запросов на один рабочий день и прочитайте их глазами. Не выборку — всё, что ушло за день.

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

После этого запись выключают: хранилище с текстами запросов — это ровно та ответственность, от которой вы пытаетесь уйти.

Какие ошибки делают после таких новостей

Три, и все они дорогие по-своему.

Запрещают всё. Приказ «нейросетями не пользоваться» не выполняется: сотрудники продолжают работать через личные аккаунты, и теперь уже вне всякого контроля. Рабочий доступ с понятными правилами безопаснее запрета.

Считают, что корпоративный тариф решает вопрос сам. Он меняет условия обработки, но не отменяет необходимость чистить данные на входе. Условия читают, а не предполагают.

Чистят данные вручную. Обезличивание, которое делает человек перед отправкой, работает ровно до первого аврала. Если оно не встроено в код, его нет.

Что нужно, чтобы навести порядок за день

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

Дальше заведите отдельные ключи под контуры на keydealer.ru/login и добавьте обезличивание в код там, где оно нужно. Чек-лист на внедрение есть в материале чек-лист перед внедрением модели.

Что держать в голове

Первое. Новость не про то, что кто-то поступил плохо. Она про то, что обучение моделей включает людей, читающих реальные диалоги, — и это нормальная практика отрасли, о которой пользователю просто не говорили прямо.

Второе. Единственное, что вы контролируете, — содержимое запроса. Не политику вендора, не поведение подрядчика, не срок хранения. Поэтому работа начинается с того, что вы кладёте в запрос, а не с того, кому доверяете.

Третье. Разделение контуров стоит час работы и снимает большую часть вопроса. Публичное — в общий контур, чувствительное — либо обезличенным, либо никак. Что мы за проект и что храним — на странице о проекте и в llms.txt.