Внешний ИИ получает рабочие данные: что согласовать с поставщиком до подключения

Корпоративный тариф куплен, разрешение на данные ещё не получено

В учебном обсуждении проекта: покупка доступа к ИИ ещё не означает согласование передачи клиентских данных.

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

Это учебная ситуация. Мы не описываем клиента НТА и не утверждаем, что какой-либо поставщик нарушает свои обещания. Задача статьи — помочь специалисту закупок и договорного контроля подготовить ограниченный допуск конкретной услуги. Не «разрешить нейросети всё», а определить один маршрут: какие сведения уходят, зачем, на каких условиях и кто остановит передачу при изменении этих условий.

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

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

Что именно покупает компания

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

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

Это различие видно в тарифах GigaChat API для юридических лиц, обновлённых 7 октября 2026 года. Страница разделяет предложения действующих клиентов разных контрагентов. Новым клиентам и тем, кто ранее не покупал пакеты, с 1 сентября указан канал Cloud.ru. Поэтому формулировка «мы согласовали GigaChat» слишком широка: она не отвечает, какое именно предложение прошло проверку.

Ниже сравниваются два конкретных варианта: Yandex AI Studio, модель YandexGPT Pro 5.1 в синхронном режиме с оплатой потребления; и пакет 300 миллионов токенов GigaChat Lite у ООО «СалютДевайсы» для действующего клиента. Второй вариант не предлагается как способ нового подключения. Мы выбрали его, потому что публичные условия позволяют показать существенную договорную границу. Условия Cloud.ru, другого контрагента, индивидуального соглашения или локальной поставки надо изучать заново.

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

Сначала состав данных, потом условия обработки

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

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

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

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

Когда обработка поручается другому лицу, часть 3 статьи 6 152-ФЗ «О персональных данных» задаёт содержание поручения. В числе требований — данные, операции, цели, конфиденциальность, безопасность, подтверждающие документы по запросу оператора, в том числе до обработки, и уведомление оператора о предусмотренных законом нарушениях. Это неисчерпывающий пересказ нормы: она содержит также ссылки на другие обязательные требования закона. Поручение связано с согласием субъекта, если федеральный закон не предусматривает иное. Это основание для профильной проверки отношений, а не доказательство эффективности нейросети. Конкретное правовое основание и применимость остальных требований устанавливают по обстоятельствам организации.

Два корпоративных предложения дают разные основания

У Yandex Foundation Models публичные условия отдельно предусматривают поручение обработки данных из запросов и специальный параметр, запрещающий использование информации для отладки и обучения моделей. Одновременно клиент должен обеспечить необходимые основания и права на передачу. Эти положения не превращают любой текст CRM в разрешённый: надо сопоставить фактический состав с ограничениями и применимой редакцией. Основание — пункты 5.1–5.4.1 условий сервиса, действующих с 22 декабря 2025 года.

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

У выбранного пакета GigaChat API важен другой вывод. Пункт 9.6 публичного соглашения ООО «СалютДевайсы» не предполагает передачу персональных данных физических лиц, кроме контактных лиц сторон для их взаимодействия. Поэтому из покупки этого пакета нельзя вывести разрешение отправлять обращения клиентов с персональными данными. Это ограничение данного договорного канала; оно не является утверждением обо всех услугах под брендом GigaChat. См. соглашение о доступе к пакетам, обновлённое 31 августа 2026 года.

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

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

Почему запрет обучения не означает отсутствие хранения

Использование запросов для улучшения модели и сохранение данных для работы функции отвечают на разные вопросы. В первом случае обсуждают дополнительную цель использования. Во втором — существование истории, файла или другого ресурса, нужного выбранному сценарию. Можно запретить первую цель и продолжать пользоваться функцией, которая сохраняет отдельные объекты. Противоречия здесь нет; противоречие возникает в слишком коротком обещании «данные не остаются».

Для AI Studio техническая инструкция описывает заголовок x-data-logging-enabled: false. Он ограничивает использование содержимого переданных запросов для улучшения сервиса. Проверять нужно конкретный маршрут, включая используемую библиотеку и повторные вызовы. Однажды установленный флажок в другом приложении не подтверждает поведение вашей интеграции. См. инструкцию отключения логирования.

Отдельная политика хранения AI Studio различает журналы сервиса, аудитные записи, трассировку, данные API и использование запросов для улучшения. Для самостоятельных объектов Responses указан срок 30 дней, для Conversations — 365 дней; у связанных с Conversations ответов действуют отдельные правила диалога. Параметр store=false позволяет не сохранять ответ Responses для последующего использования, но тогда недоступны зависящие от него возможности продолжения. Файлы и поисковые индексы рассматриваются отдельно; применимость автоматического удаления зависит от API.

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

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

×

Схема НТА по документации Yandex AI Studio на 14 октября 2026 года. Настройка использования запросов и хранение ресурсов решают разные задачи.

Четыре уровня подтверждения условия

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

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

Однако наблюдение заголовка запроса не позволяет увидеть внутреннюю инфраструктуру поставщика. Нельзя написать в акте, что все копии удалены, если команда проверила лишь отсутствие файла в доступном списке. Такое свидетельство полезно, но его предел должен быть назван: объект больше не доступен через проверенный интерфейс. Договорное подтверждение удаления и проверка доступного объекта — разные основания, которые могут дополнять друг друга.

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

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

×

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

Что уточнить в договоре и о третьих лицах

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

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

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

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

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

Как проверить интеграцию до рабочих данных

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

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

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

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

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

Как принять ограниченное решение

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

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

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

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

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

Когда пересматривать условия и как прекратить передачу

Допуск относится к определённому состоянию услуги. Новая редакция договора, смена контрагента, модели, API, тарифа, состава данных или подключение сохраняемой истории могут изменить основания. Пункты 10.2–10.4 рассмотренного соглашения GigaChat предусматривают изменение условий и действия при несогласии. Поэтому проверка документов — не только шаг перед первой оплатой. Конкретный порядок наблюдения за изменениями компания назначает своему ответственному.

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

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

Порядок удаления согласовывают до накопления данных. Какие объекты доступны клиенту? Кто выполняет удаление? Какие сроки и исключения установлены договором? Что можно проверить самостоятельно, а что подтверждает поставщик? Не нужно обещать мгновенное уничтожение всех резервных копий, если такого основания нет. Точность здесь полезнее сильной формулировки: она позволяет заранее понять, подходит ли срок и объём прекращения обработки требованиям компании.

Если выход из сервиса затрагивает историю и незавершённые задачи CRM, одного отключения модели мало. Подход к проверке сохранённого результата раскрыт в статье НТА о выходе из облачной CRM. Здесь важно сохранить границу: прекращение внешних вызовов, удаление ресурсов и продолжение рабочего процесса — связанные, но самостоятельные задачи.

Границы, которых это сравнение не снимает

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

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

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

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

Если сведения получает расширение браузера, надо учитывать и его собственный маршрут доступа и передачи. Для этого есть отдельный разбор НТА о проверке ИИ-расширений перед доступом к CRM. Условия прямого API не разрешают автоматически использовать посредника с другими полномочиями. В карточке согласования должен быть именно тот путь, который реально выполняется.

Карточка согласования одного сервиса

После объяснения механизмов можно заполнить рабочий артефакт. Ниже — шаблон НТА для одного продукта, тарифа и класса данных. Он не содержит заранее разрешающих значений. В каждой строке указывают основание и ответственного; неизвестность сохраняют явно и связывают с действием до допуска.

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

НТА может обследовать поток данных, определить границы раскрытия и спроектировать ограниченную интеграцию ИИ с CRM. Это работа с конкретным маршрутом и согласованным результатом; она не подменяет договорное решение покупателя и не обещает универсального допуска внешней модели. До обращения к исполнителю читатель уже может заполнить карточку и показать, какие сведения или подтверждения ему нужны.

Тест понедельником

Возьмите один планируемый вызов внешнего ИИ из CRM. Попросите показать его учебный образец, название услуги, контрагента и применимые документы. Затем задайте два отдельных вопроса: используются ли запросы для улучшения и какие ресурсы сохраняются для работы функции. Если вместо двух ответов звучит «у нас корпоративный тариф», основания допуска ещё не восстановлены.

Найдите в карточке одного ответственного за неизвестное условие и одно событие пересмотра. Уточните, что остановит новые запросы и кто разберётся с уже созданными объектами. Не нужно проверять всё на реальной клиентской переписке: сначала команда должна объяснить и подтвердить выбранный маршрут на синтетическом примере.

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

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.