Данные и код клиентов

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

Куда идут данные

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

• Локальная работа (CLI, IDE, десктопное приложение): файлы остаются на машине разработчика, но всё, что агент прочитал или получил из вывода команд, отправляется модели в составе запросов. Если агент открыл .env или прочитал дамп базы, это содержимое ушло провайдеру.
• Облачные задачи: репозиторий клонируется в контейнер в инфраструктуре OpenAI, и агент работает там. Документация указывает, что сохранённое состояние виртуальной машины облачной задачи можно восстановить в течение семи дней после последнего хода (cloud environments).
• Ревью в GitHub или GitLab: провайдер получает доступ к репозиторию через интеграцию.

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

Обучение и хранение: что подтверждено

По документации OpenAI на октябрь 2026 года:

• Для ChatGPT Enterprise OpenAI указывает, что по умолчанию бизнес-данные не используются для обучения, данные шифруются при передаче и хранении. Там же оговорка: покрытие зависит от тарифа, конфигурации, поверхности и региона (work admin FAQ).
• Чаты Codex создают метаданные репозитория и окружения, вывод команд, диффы и логи. Точные классы данных, сроки хранения и способы удаления документация отсылает смотреть в документации Compliance API — то есть готового ответа на странице нет.
• Логи Compliance Logs Platform хранятся 30 дней; если нужно дольше, их надо выгружать к себе.
• При работе через API-ключ действуют правила данных API: по умолчанию данные не используются для обучения, логи мониторинга злоупотреблений хранятся до 30 дней, режим нулевого хранения (Zero Data Retention, ZDR) требует предварительного одобрения OpenAI (your data).

Что не подтверждено — и что спрашивать

Здесь важно не додумывать за поставщика.

• ZDR для Codex. Документация прямо говорит, что локальный доступ к компьютеру в связке с Work Cloud не обеспечивает строгого нулевого хранения. Поддерживает ли ZDR сам Codex при входе через ChatGPT или в облаке — в открытой документации мы подтверждения не нашли. Если клиент требует нулевого хранения, запросите у OpenAI письменный ответ для вашего договора.
• Сертификации. Портал доверия OpenAI (trust.openai.com) перечисляет SOC 2 Type 2, ISO/IEC 27001 и другие. В заявленном охвате отчёта SOC 2 за 2025 год названы API Platform, ChatGPT Enterprise, Edu и Team; Codex отдельно не упомянут. Входит ли он в охват как часть ChatGPT Enterprise — уточните у поставщика. На том же портале есть отдельный документ по безопасности Codex, на который ссылается гайд по развёртыванию, — запросите его.
• Резидентность данных. Документация оговаривает, что резидентность данных и инференса покрывает только подходящий контент и поддерживаемые сценарии. Не считайте, что она распространяется на всё.
• Личные тарифы. Правила данных для личных подписок отличаются от рабочего пространства и управляются самим пользователем. Для клиентского кода это аргумент против личных аккаунтов (см. урок про доступ).

Договоры и NDA

Типичные пункты клиентских договоров, которые задевает агент:

• Передача третьим лицам. NDA часто запрещает раскрывать конфиденциальную информацию кому-либо, кроме сотрудников и согласованных подрядчиков. Является ли облачный провайдер модели таким «третьим лицом» — вопрос толкования конкретного договора.
• Субподрядчики и обработчики. Если в договоре есть перечень согласованных сервисов, провайдера модели в нём может не быть.
• Персональные данные. Дамп продовой базы с данными пользователей клиента — отдельная категория, с требованиями законодательства о персональных данных.
• Место обработки. Договор может ограничивать страны или юрисдикции обработки.

Мы не даём юридических заключений: соответствие конкретного договора — решение вашего юриста. Задача техдира — принести ему точное техническое описание: что уходит, куда, сколько хранится, что подтверждено документами, а что нет.

Классы проектов

Практичный способ превратить это в правило — разделить проекты на классы и для каждого записать режим:

Класс проекта стоит хранить там, где его видит команда: в карточке проекта в трекере и в AGENTS.md репозитория. Нарушения чаще случаются по незнанию, чем по злому умыслу.

Гигиена данных в репозитории

Независимо от класса:

• Никаких боевых дампов в рабочей папке. Для разработки — сиды и фикстуры с выдуманными данными.
• Секреты — вне репозитория и под deny_read; ключи интеграций в разработке — тестовые.
• Телеметрия: при экспорте OpenTelemetry содержимое промптов по умолчанию скрыто; документация рекомендует держать otel.log_user_prompt = false, чтобы клиентский контекст не оседал в ваших логах.
• В облачных окружениях используйте сетевые секреты, которые подставляются прокси, а не обычные переменные окружения.