Обучается ли корпоративный ИИ на данных компании: что проверить в тарифе и договоре

Короткий ответ: по умолчанию нет. В рассмотренных нами коммерческих продуктах OpenAI и Anthropic обучение моделей на ваших запросах и ответах по умолчанию отключено. Но «модель не обучают» не означает «ничего не хранят». История чатов, загруженные файлы, отзывы об ответах и вызовы внешних инструментов регулируются отдельными правилами.

Главное условие: вывод относится к конкретному продукту, функции и договору, а не к бренду в целом. У личного аккаунта сотрудника, корпоративного рабочего пространства и API разные условия.

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

Короткий ответ и ограничения тарифа

Вопрос «обучается ли ChatGPT Enterprise или Claude for Work на наших данных» обычно звучит как один. На деле за ним стоят три разные ситуации, и правила для каждой отличаются.

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

API. Компания встраивает модель в собственный продукт или процесс: чат-бот на сайте, обработку заявок или внутренний поиск. OpenAI относит API Platform к бизнес-продуктам, для которых действует правило об отсутствии обучения по умолчанию. Anthropic также прямо называет Anthropic API среди коммерческих продуктов. Если доступ предоставляет посредник или другая облачная платформа, проверьте и условия этого маршрута. Хранение зависит от конкретных функций API и выбранного режима.

Личный аккаунт. Если сотрудник открывает ИИ-сервис из личного аккаунта, корпоративные гарантии на этот разговор не распространяются. Переносить условия потребительского аккаунта на Enterprise или API некорректно, как и наоборот. Поэтому вопрос «какой тариф выбрать» нельзя отделять от вопроса «чем сотрудники уже пользуются».

Есть ещё одно предостережение, связанное с названиями. Поставщики переименовывают и объединяют тарифы. Ориентируйтесь не на название в счёте, а на два факта. Во-первых, относится ли ваш аккаунт к бизнес-продуктам в документации поставщика. Во-вторых, подписаны ли соответствующие условия. Фиксируйте дату проверки. Для нашего исследования это 11.10.2026. Справочные статьи Anthropic, проверенные при подготовке материала, имели версии от 18.08.2026 и 01.07.2026, а страницы OpenAI динамические и не имели фиксированной даты.

Четыре разных действия с данными, которые нельзя смешивать

Фраза «наши данные в безопасности» часто описывает один из четырёх процессов. Обещание поставщика обычно касается только одного из них. Разделим их.

1. Обучение модели. Использование ваших запросов и ответов для улучшения будущих версий модели. Именно этого чаще всего опасаются владельцы бизнеса, и именно это покрывает обещание «не обучаем по умолчанию».

2. Хранение истории. Чаты, файлы и проекты остаются в рабочем пространстве, чтобы сотрудник мог к ним вернуться. Это полезная функция. Но пока история не удалена по правилам хранения, данные существуют у поставщика, а доступ к ним есть у тех, кому его предоставили в вашем рабочем пространстве.

3. Журналы и обработка для безопасности. Отдельно от истории поставщик может вести технические записи, например для выявления злоупотреблений. Есть ли такая обработка в вашем продукте, какие данные она охватывает и как долго длится, указано в документации и договоре. Оба поставщика описывают режимы и сроки хранения отдельно от правила об обучении.

4. Передача внешнему инструменту. Когда ИИ вызывает коннектор к CRM, почте, облачному диску или стороннему сервису, данные выходят за пределы модели. На этом маршруте действуют условия соответствующего инструмента и ваши настройки доступа, а не только обещание поставщика модели.

Итак, «модель не обучается» закрывает первый пункт. Остальные три требуют отдельной проверки, отдельных настроек и часто отдельных документов.

Учебный пример: один договор, три маршрута

Этот сценарий вымышлен и нужен только для иллюстрации. Менеджер загружает договор с поставщиком в корпоративный ИИ-чат и просит перечислить условия оплаты и штрафные санкции. Чтобы сверить реквизиты, модель через коннектор обращается к CRM и получает карточку контрагента. Ответ оказался полезным, и менеджер ставит ему положительную оценку с комментарием.

Для ответственного за данные здесь не одно событие, а три независимых маршрута:

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

Что обещают OpenAI и Anthropic: сравнение правил

Таблица ниже содержит только сведения, подтверждённые документацией поставщиков в рамках исследования от 11.10.2026. Если конкретное значение не указано, мы пишем «уточнить». Неизвестный срок хранения не равен нулю; заполнять такие ячейки предположениями нельзя.

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

Отдельно о ZDR (Zero Data Retention, режим нулевого хранения). Это не синоним отказа от обучения. Отказ от обучения описывает, используются ли ваши данные для улучшения модели. ZDR описывает условия хранения и, согласно документации OpenAI, относится к определённым возможностям API. То есть он доступен не для каждого сценария. Если ваша архитектура рассчитывает на ZDR, проверьте каждую включённую функцию, а не только название режима.

Где возникают исключения

Большинство неприятных сюрпризов появляется не в основном правиле, а в исключениях. Вот пять мест, которые стоит проверить в первую очередь.

Обратная связь. Кнопки оценки ответа кажутся безобидными, поэтому их редко обсуждают при выборе тарифа. Anthropic прямо указывает, что переданная обратная связь может использоваться для обучения и что администратор может отключить этот механизм. Решите, нужны ли вам оценки вообще. Если да, договоритесь, для каких данных их не ставят, и проверьте соответствующую настройку в панели администратора.

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

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

Специальные модели. Справка Anthropic о хранении данных отдельно упоминает исключения, в том числе Covered Models. Если ваш сценарий использует модели или функции с отдельными условиями, выясните, какие правила действуют именно для них, а не для продукта в целом.

Договорные режимы. Часть условий действует не по умолчанию, а как отдельный режим. Пример — ZDR в OpenAI, который применяется к определённым возможностям API. Зафиксируйте в договоре или официальной переписке с поставщиком, какие именно режимы применяются к вашей организации, и храните эти документы вместе с датой.

Что администратор проверяет перед подключением

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

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

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

Роли. Определите, кто является администратором, кто имеет доступ к разговорам других сотрудников или экспорту данных, кто согласует новые интеграции. Чем меньше людей с широкими правами, тем проще установить, кто и когда видел конкретные данные.

Сроки удаления. Выясните, что происходит с чатами и файлами, когда сотрудник их удаляет, и что происходит при увольнении сотрудника. Сравните эти сроки с внутренней политикой хранения документов. Если ответа в документации нет, обозначьте это как открытый вопрос к поставщику, а не как «ноль».

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

Договор и документы. Соберите в одну папку бизнес-условия, соглашение об обработке данных (если оно нужно в вашем случае) и редакции политик с датой проверки. Отдельно запишите, как поставщик уведомляет об изменениях условий и кто в компании читает такие уведомления. О договорах с обработчиком и требованиях к персональным данным подробнее говорится в нашей статье о GDPR и HIPAA.

Как принять решение: паспорт разрешённого сценария

Общее правило «ИИ можно» или «ИИ нельзя» на практике не работает. Сотрудник не понимает, распространяется ли запрет на короткое письмо клиенту, а разрешение не отвечает на вопрос о медицинской справке. Работает решение для конкретного сценария. Мы предлагаем оформлять его как короткий паспорт на одну страницу.

Зачем нужны владелец и дата повторной проверки? Условия поставщиков меняются, а новые функции появляются без вашего участия. Паспорт, составленный один раз, через полгода может описывать уже другой продукт.

Что сделать в ближайшее время:

1. Выпишите два-три реальных сценария, в которых сотрудники уже используют или хотят использовать ИИ.
2. Для каждого нарисуйте маршруты данных, как в примере с договором: диалог и файлы, интеграции, обратная связь.
3. Заполните таблицу правил поставщика с датой проверки. Неизвестные значения обозначьте как открытые вопросы.
4. Проверьте настройки администратора: обратная связь, коннекторы, роли, удаление.
5. Оформите паспорт для каждого сценария и назначьте владельца, который повторно проверит условия к установленной дате.

Если после этого остаются открытые вопросы к поставщику, это нормальный результат. Лучше понимать, чего именно вы не знаете, чем полагаться на общую фразу о безопасности.

Часто задаваемые вопросы