Представим, что компании нужен новый импорт клиентской базы. Разработчику важно знать названия полей, их типы, связи между таблицами, правила проверки и несколько трудных случаев: пропущенный телефон, две записи с одним адресом, старая дата в неожиданном формате. Настоящие фамилии, номера договоров и суммы операций для этой работы ничего не добавляют. Если заменить их вымышленными значениями, задача останется той же, а реальные записи не покинут исходную систему.
Это различие часто теряется в разговорах о конфиденциальности ИИ. Обсуждение сразу переходит к тому, обучается ли поставщик на запросах и сколько дней их хранит, хотя самый надёжный способ защитить данные проще: не передавать то, без чего можно выполнить работу. Политика провайдера становится важна только для оставшейся, уже сокращённой части информации.
Модели важны свойства данных, их владелец — нет
Программа должна правильно обработать форму данных; узнавать людей внутри неё ей незачем. Для расчёта скидки нужны диапазоны сумм и правила округления; для расписания — длительность занятий, пересечения и часовые пояса; для интеграции — поля, допустимые значения и ответы внешней системы. Всё это можно описать схемой и синтетическим набором, в котором сохранены нужные свойства, но нет настоящего клиента.
Хороший тестовый набор не обязан выглядеть правдоподобно. Его задача — воспроизвести ситуации, на которых продукт может сломаться: пустое обязательное поле, очень длинное имя, дублирующуюся запись, отменённый платёж или переход через границу месяца. Набор из вымышленных «Ивана Тестова» и «Марии Примеровой» иногда полезнее случайной копии рабочей базы, потому что сложные случаи в нём подобраны намеренно, вместо случайного набора из того, что нашлось в выгрузке.
Однако заменить только имя недостаточно. Человека можно узнать по редкому сочетанию должности, города, даты рождения и истории действий, поэтому подготовка данных должна смотреть на запись целиком. Если для проверки отчёта не важны ни город, ни точное время операции, эти поля лучше убрать или укрупнить, а не сохранять из осторожности «на всякий случай».
Реальные записи появляются только там, где без них нельзя проверить результат
Синтетические данные закрывают проектирование, основную разработку и большую часть автоматических проверок, но не гарантируют, что исходная система ведёт себя именно так, как написано в документации. Перед запуском иногда приходится проверить формат настоящей выгрузки, старые записи или поведение живой интеграции. Это не повод переносить всю базу в рабочие инструменты команды.
Проверку можно провести внутри системы заказчика, передать ограниченный фрагмент без лишних полей либо выполнить небольшой диагностический запрос и вернуть только его результат. Подход выбирают по задаче, но принцип остаётся одним: сначала используется минимальный доступ, а расширяется он лишь для конкретной недостающей проверки. Тогда у каждой переданной копии появляется объяснимая функция.
Поэтому вопрос подрядчику «вы берёте наши данные?» слишком общий. Точнее спросить, какие поля нужны для каждого этапа, чем нельзя заменить оригинал и где именно будет выполнена такая проверка. Если на этот вопрос есть предметный ответ, объём доступа обычно оказывается значительно меньше, чем предполагалось в начале.
«Не используем для обучения» и «не храним» означают разное
Когда после минимизации часть информации всё же проходит через внешний ИИ-сервис, нужно проверить его условия. В документации OpenAI для API указано, что запросы не используются для обучения моделей, если клиент сам не согласился ими делиться. При этом журналы контроля злоупотреблений по умолчанию могут хранить содержимое запросов и ответов до 30 дней, а разговоры, файлы и другие объекты с состоянием подчиняются отдельным срокам.
Anthropic также разделяет продукты и функции: входы и выходы стандартного API удаляются на стороне компании в течение 30 дней, тогда как переписка в корпоративных продуктах сохраняется, чтобы пользователь мог к ней вернуться. Из этих правил нельзя вывести общий рейтинг безопасности сервисов. Они показывают, почему условия нужно проверять для конкретной учётной записи и функции, а название модели само по себе почти ничего не объясняет.
У обоих поставщиков существуют особые режимы нулевого хранения для допущенных корпоративных клиентов, но они согласуются отдельно и распространяются не на каждую функцию. Файловое хранилище или подключённый внешний инструмент могут сохранять данные, потому что без этого не смогут работать. Нужный срок поэтому закрепляют на всём маршруте запроса, включая приложение и интеграции вокруг модели.
Корпоративный аккаунт удерживает работу внутри согласованных правил
Даже подходящий договор бесполезен, если сотрудник делает запрос через личную учётную запись. Внешне открыт тот же интерфейс, но компания уже не управляет настройками, доступом и историей действий. Поэтому одобренный рабочий аккаунт — такая же часть контура, как сервер или база данных.
Cyberhaven в отчёте за 2026 год зафиксировала заметный разброс доли личных аккаунтов между сервисами: от 24,9% для Gemini и 32,3% для ChatGPT до 58,2% для Claude и 60,9% для Perplexity. Это данные поставщика систем защиты среди его клиентов, а не универсальная оценка для любой компании, однако они показывают сам механизм: закупка корпоративного тарифа ещё не означает, что вся фактическая работа проходит через него.
Рабочая политика должна давать сотруднику удобный разрешённый маршрут, а не только перечислять запреты. Тогда ему не приходится выбирать между выполнением задачи и соблюдением правил, а компания может увидеть, какие инструменты используются и при необходимости закрыть доступ вместе с учётной записью.
Для персональных данных важна ещё и территория
Если проект обрабатывает персональные данные граждан России, место хранения определяется не только договором с провайдером. С 1 июля 2025 года часть 5 статьи 18 закона № 152-ФЗ не допускает при сборе запись, систематизацию, накопление, хранение, уточнение и извлечение таких данных с использованием зарубежных баз, кроме прямо перечисленных исключений.
Последующая трансграничная передача регулируется отдельно. Минцифры разъясняет, что она должна соответствовать статье 12, включая предварительное уведомление Роскомнадзора, если не действует исключение, тогда как хранение и уточнение персональных данных, в том числе копий, должны оставаться в российских базах. Конкретное правовое основание проверяет юрист, но архитектурное решение принимается раньше: оригиналы остаются в разрешённом контуре, а внешняя модель получает только те сведения, передача которых действительно нужна и оформлена.
Хорошая схема отвечает на пять конкретных вопросов
До начала работы стоит зафиксировать категории информации, а затем для каждой пройти один и тот же маршрут. Нужен ли модели оригинал или достаточно схемы и синтетического примера? Под какой корпоративной учётной записью выполняется запрос? Где появятся копии — в журнале, истории разговора, файле, кэше или внешней интеграции? В какой стране они находятся и когда удаляются? Кто сможет получить доступ во время проекта и что произойдёт после его завершения?
Такая карта не требует передавать подрядчику базу ради её составления. Наоборот, она заранее показывает, какие данные в разработку не попадут вовсе, где достаточно вымышленного набора и в каком редком месте понадобится контролируемая проверка на оригинале. Чем точнее описана задача, тем уже становится необходимый доступ.
Поэтому безопасность ИИ-разработки разумнее оценивать по объёму реальных данных, которые вообще пришлось показать за пределами исходной системы, а обещание одного поставщика остаётся лишь частью проверки. Если проект можно собрать на схеме, правилах и синтетических примерах, лучший срок хранения оригиналов у модели равен нулю: они ей просто не передавались.
Ещё больше интересного в телеграм-канале @kindaworks.