AI-суверенитет — ваш альфа-фактор: как избежать передачи альфа-фактора провайдеру размещенных моделей

27 июля 2026 г.

Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере

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

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

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

1. Договорная защита вашей «альфы»

1.1 Обеспечение надежного режима нулевого хранения данных (ZDR)

Одним из важнейших способов снижения этих рисков является получение договорных гарантий нулевого хранения данных (Zero Data Retention, ZDR). Разные Провайдеры размещаемых моделей используют разные концепции ZDR.

Надежный режим ZDR означает, что Провайдер размещаемых моделей не будет (1) хранить или иным образом регистрировать ваши промпты или ответы на диске (что было бы более постоянным, чем эфемерное хранение в оперативной памяти), (2) предоставлять ваши промпты или ответы для проверки человеком, (3) использовать ваши промпты или ответы для обучения своих моделей или улучшения своих сервисов, и (4) будет сохранять промпты и ответы в оперативной памяти только на время, необходимое для возврата ответа на запрос.

Надежный режим ZDR означает, что Провайдер размещаемых моделей не будет (1) хранить или иным образом регистрировать ваши промпты или ответы на диске (что было бы более постоянным, чем эфемерное хранение в оперативной памяти), (2) предоставлять ваши промпты или ответы для проверки человеком, (3) использовать ваши промпты или ответы для обучения своих моделей или улучшения своих сервисов, и (4) будет сохранять промпты и ответы в оперативной памяти только на время, необходимое для возврата ответа на запрос.

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

1.2 Ограничение использования вашей «альфы»

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

Передовой метод:

• Убедитесь, что условия ограничивают использование ваших данных Провайдером размещаемых моделей и (если Провайдер размещаемых моделей является гиперскейлером) любой AI Lab, участвующей в обработке, только предоставлением вам сервиса — лучше прямо указать это единственное разрешенное использование, чем пытаться создать длинный список различных ограничений, что создает риск что-то упустить. Кроме того, убедитесь, что ограничения на использование ваших данных распространяются как на платформу Провайдера размещаемых моделей, которую вы используете, так и на любую соответствующую AI Lab.
• Если вы не можете добиться вышеуказанного, как минимум не разрешайте использовать ваши данные для улучшения продукта или сервиса, который вы используете, включая, помимо прочего, обучение моделей. Обязательно свяжите обязательствами как Провайдера размещаемых моделей, так и любую AI Lab, участвующую в обработке.

1.3 Убедитесь, что лимиты ответственности достаточно высоки, чтобы договорная защита имела силу

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

Передовой метод:

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

2. Отслеживайте и разрешайте только те сервисы, которые покрываются вашей договорной защитой «альфы»

2.1 Бета-версии или другие сервисы, не соответствующие требованиям ZDR

Многие поставщики размещаемых моделей (Hosted Model Providers) не применяют обязательства по нулевому удержанию данных (ZDR) к услугам, находящимся на стадии бета-тестирования (также называемым «предварительный просмотр» или «pre-GA»). Некоторые службы, инструменты и API-эндпоинты также могут по умолчанию не подпадать под действие ZDR. Эти исключения могут попасть в ваши юридические условия различными способами: они могут содержаться в гиперссылках на специфические условия обслуживания, в специальном разделе условий для бета-сервисов или даже в примечании, согласно которому бета-сервисы исключаются из определения сервисов модели, к которым применяются обязательства ZDR. Статус «не подлежит ZDR» и «бета» может применяться не только к моделям, но и к конкретным конфигурациям вызовов API к этим моделям. Например, модель А может не быть бета-версией, но модель А, вызванная с использованием определенного бета-инструмента, функции или API, может быть исключена из ZDR. Дополнительная сложность заключается в том, что стандартные юридические условия поставщика размещаемой модели почти никогда не разъясняют, какие именно службы, функции и инструменты являются бета-версиями — обычно эта информация скрыта в постоянно меняющейся онлайн-документации или в консоли/портале поставщика (к которым, по понятным причинам, ИТ-отделы редко предоставляют юридическим командам доступ по умолчанию).

Рекомендация:

• Договорным путем обеспечьте широкий охват услуг (например, охватывающий любое использование любых API поставщика размещаемой модели, включая доступ к бета-сервисам), которые подпадают под вашу защиту данных, и убедитесь, что отсутствуют условия, подлежащие одностороннему изменению поставщиком модели (например, отсутствие условий по гиперссылкам).
• Если вы не можете получить вышеуказанное, работайте со своим ИТ-отделом над созданием актуального списка разрешенных моделей, инструментов, функций и API-эндпоинтов, которые подпадают под полученную вами защиту данных (часто это потребует исключения бета-сервисов). Регулярно обновляйте этот список на основе плановых проверок соответствующей документации поставщика и настройте операционные процессы для взаимодействия ИТ-отдела с юридическим отделом для проверки новых моделей, инструментов и функций перед тем, как разрешить их использование в вашей организации.
• Некоторые поставщики размещаемых моделей используют «бета-заголовок», который необходимо проактивно добавлять к вызовам API к бета-сервису, чтобы вызов прошел. Это может стать полезным техническим барьером для блокировки запрещенных сервисов — сотрудничайте с ИТ-отделом для автоматической блокировки вызовов, содержащих бета-заголовки, в качестве меры предосторожности.

2.2 Данные сохраняются при срабатывании классификатора безопасности

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

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

2.3 Промпты с изображениями или файлами вводят исключения ZDR

Многие поставщики размещаемых моделей не применяют ZDR к промптам, включающим изображения или файлы. Некоторые другие поставщики могут утверждать, что использование входных или выходных изображений (или взаимодействие с API-эндпоинтами изображений) подпадает под их (менее надежную) концепцию ZDR, в то время как в их документации могут быть скрыты положения о том, что в случае срабатывания определенных классификаторов безопасности весь контекст ваших промптов или ответов сохраняется поставщиком на диск и потенциально подлежит проверке человеком. Это может быть верно для некоторых приоритетных классификаторов безопасности, даже если мониторинг злоупотреблений отключен.

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

2.4 Некоторые конфигурации кэширования промптов могут хранить ваши данные дольше, чем необходимо

Некоторые поставщики размещаемых моделей предлагают функции (иногда обязательные для использования определенных моделей или API-эндпоинтов), включающие расширенное или улучшенное кэширование промптов. Хотя некоторая форма кэширования промптов может быть полезна для снижения задержки и затрат и может быть неизбежной, в идеале кэширование промптов должно иметь разумный TTL («Time-to-Live», указывающий, как долго данные сохраняются) и сохранять кэшированные промпты только в оперативной памяти в течение времени, необходимого для завершения сеанса, после чего кэш очищается. Это может соответствовать надежному ZDR. Нежелательные конфигурации кэширования промптов могут включать сохранение ваших промптов и ответов на диск в течение неоправданно длительных периодов времени.

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

2.5 Тщательно определяйте, какие условия применяются

Условия использования моделей могут варьироваться в зависимости от того, какую платформу поставщика размещаемых моделей вы используете и какую модель применяете. Во многих случаях гиперскейлеры (Hyperscalers) транслируют определенные условия от создателя модели и добавляют свои собственные условия поверх них.

Получайте истории Palantir на свою почту

Присоединяйтесь к Medium бесплатно, чтобы получать обновления от этого автора.

Запомнить меня для более быстрого входа

Рекомендация: обязательно тщательно проверяйте соответствующие условия для конкретной платформы поставщика размещаемых моделей, которую вы используете. Обратите внимание: если вы обеспечили выгодные индивидуальные условия от создателя модели (например, отключение мониторинга злоупотреблений), вы должны убедиться, что используемая вами платформа поставщика осведомлена об этих индивидуальных условиях и внедряет любую специальную обработку данных, такую как ZDR. Например, если вы используете модель, созданную AI Lab A (с которой у вас есть индивидуальные условия и гарантии), но получаете доступ к модели через Hyperscaler B, вам может потребоваться связать AI Lab A с Hyperscaler B, чтобы AI Lab могла подтвердить гиперскейлеру, что должна применяться специальная обработка данных.

2.6 Отказ от условий обработки данных

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

Рекомендация: в идеале у вас должны быть основные условия, которые имеют приоритет над любыми онлайн-условиями, исключающими защиту при обработке данных. Если этого добиться не удается, тщательно проверяйте новые сервисы, прежде чем добавлять их в свой список разрешенных. Такие отказы от ответственности при обработке данных могут применяться непосредственно к сервису или через его статус (например, если сервис помечен как «бета-версия», что влечет за собой применение условий бета-тестирования), поэтому обязательно проверяйте (i) конкретную документацию сервиса, (ii) любые специфические условия сервиса, которые есть у поставщика модели (часто это отдельная веб-страница, представленная в виде длинного списка сервисов и особых условий, применимых к ним), и (iii) условия, применимые к статусу интересующего вас сервиса.

2.7 Неожиданное включение сервисов

Некоторые поставщики размещаемых моделей могут автоматически включать или обновлять сервисы или модели до новых версий, на которые не распространяются ZDR или другие меры защиты суверенитета ИИ, описанные в этом документе, и вы не получите прямого уведомления об изменении таких условий (хотя изменение может быть раскрыто в одностороннем порядке в обновленной технической или договорной документации).

Рекомендация: в дополнение к мерам по снижению рисков, описанным в разделах 2.1 и 3.1, обеспечьте договорные гарантии того, что любая новая модель или сервис, которые не соответствуют ZDR или другим вашим требованиям к суверенитету ИИ, не будут включены для вашего арендатора без предварительного уведомления и вашего прямого письменного согласия.

2.8 Обеспечение границ соответствия надлежащей аккредитации

Не все поставщики размещаемых моделей и не все их сервисы соответствуют требованиям соответствия, которые могут потребоваться вашей организации для конкретных рабочих процессов — например, хотя многие из них могут иметь сертификат SOC2, у многих может не быть сертификации FedRAMP или аккредитации IL2, 4 или 5.

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

3. Ограничение способности поставщика размещаемой модели изменять условия в одностороннем порядке

3.1 Односторонние изменения онлайн-условий по гиперссылкам

Положения и условия поставщиков размещаемых моделей часто включают онлайн-условия, которые могут быть изменены поставщиками в одностороннем порядке. Часто это следствие того, что условия поставщика размещаемой модели включают гиперссылки на условия, которые могут быть обновлены в одностороннем порядке и вступить в силу без уведомления. Даже если вы успешно согласовали основные условия, они могут включать условия по гиперссылкам (например, на политики допустимого использования, специфические условия сервиса, условия обработки данных, условия ZDR и т. д.), которые могут быть обновлены поставщиком размещаемой модели в одностороннем порядке без уведомления. Поставщики размещаемых моделей часто обновляют эти условия по гиперссылкам таким образом, что это подрывает ZDR и другие аспекты суверенитета ИИ, обсуждаемые в этом документе.

Рекомендация:

• Стремитесь к индивидуальным договорным условиям, которые не включают онлайн-условия посредством ссылки; или, если вам необходимо включить ссылки, укажите, что эти связанные условия действуют только в редакции, существующей на дату вступления вашего договора в силу.
• Если вам удалось добиться вышеуказанного для некоторых, но не всех условий по гиперссылкам (т. е. некоторые условия по гиперссылкам могут быть изменены поставщиком размещаемой модели в одностороннем порядке), установите строгий порядок приоритетности в случае несоответствий или конфликтов между согласованными условиями и условиями по гиперссылкам, чтобы односторонние изменения условий по гиперссылкам не могли подорвать согласованные договорные гарантии, такие как ZDR.
• Если вам необходимо согласиться с условиями по гиперссылкам, которые поставщик размещаемой модели может изменить в одностороннем порядке, установите регулярные проверки (в идеале автоматизированные оповещения) для мониторинга любых изменений соответствующих онлайн-условий. Просмотр старых версий положений и условий (например, через https://web.archive.org/) может быть полезен для выяснения того, что именно изменилось.

3.2 Условия «click-through», представленные вашим сотрудникам, не являющимся юристами

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

Рекомендация: включите в договор условия, которые делают соглашения «click-through» недействительными. Если этого добиться не удается, проинформируйте пользователей консоли или платформы об этом риске и попросите их проконсультироваться с юридическим отделом перед принятием любых соглашений «click-through».

4. Снижение риска операционных сбоев

4.1 Сбои в бизнесе при срабатывании классификаторов безопасности

Положения и условия могут позволять поставщикам размещаемых моделей приостанавливать или прекращать обслуживание немедленно при определенных условиях, в том числе если они считают, что вы нарушаете любую из их политик допустимого использования (AUP), которые часто включают широкий набор ограничений, подверженных частым односторонним изменениям со стороны поставщика размещаемой модели. Даже при надежной настройке ZDR поставщики размещаемых моделей могут полагаться на классификаторы безопасности (которые хранят только метаданные, указывающие, сработал ли классификатор, а не промпт, вызвавший его срабатывание) для определения того, соблюдаете ли вы их AUP, и эти классификаторы часто чрезмерно чувствительны и могут ошибочно срабатывать на безобидные промпты. Это означает, что даже соответствующее требованиям использование их сервиса может привести к приостановке или прекращению обслуживания, что грозит сбоями в вашем бизнесе.

Рекомендация:

• Требуйте по договору, чтобы перед инициированием любого прекращения или приостановки обслуживания поставщик размещаемой модели предоставлял (а) уведомление в случае срабатывания классификатора безопасности, (b) период «расследования и устранения» для ваших команд безопасности и ИТ, чтобы оценить, что вызвало срабатывание классификатора, и сотрудничать с поставщиком размещаемой модели для установления того, что срабатывание было результатом ложноположительного результата, или согласовать меры по исправлению в случае истинно положительного результата, (c) гарантию того, что такой период «расследования и устранения» не дает поставщику размещаемой модели прав на получение или просмотр вашего альфа-кода, и (d) разумный буферный период для любой приостановки или прекращения обслуживания, достаточный для того, чтобы вы могли перейти на другую модель.
• Убедитесь, что ваша техническая организация внедрила соответствующую инфраструктуру наблюдаемости, чтобы иметь возможность отслеживать промпты, вызвавшие положительное срабатывание классификатора безопасности, для помощи в деэскалации любых обращений поставщика размещаемой модели по поводу флага. Большинство поставщиков размещаемых моделей внедряют идентификаторы промптов, и в случае инцидента могут предоставить вам идентификаторы нарушающих промптов, чтобы помочь вам в аудите.

4.2 Блокировка легитимных запросов к модели

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

Лучшая практика: добавьте четкие формулировки в договор, разрешающие ваши конкретные сценарии использования, и, по возможности, положения, гарантирующие, что Hosted Model Provider отключит соответствующие классификаторы безопасности. Не ограничивайтесь лишь исключением запретов на использование в вашем контракте.

4.3 Глобальные стандарты инференса, направляющие ваш трафик в запрещенные регионы

Многие Hosted Model Providers по умолчанию предоставляют услуги моделей, инструменты и функции в рамках глобальных стандартов инференса, которые распределяют нагрузку вашего трафика по инфраструктуре во всех регионах, где у них есть свободные мощности. Некоторые из этих регионов могут быть запрещены для вашей бизнес-деятельности в силу юридических или договорных требований, что приводит к инцидентам и/или сопутствующим сбоям в бизнесе. Hosted Model Providers не всегда открыто заявляют в своих контрактах или документации о том, какие именно регионы подпадают под действие глобальных стандартов инференса, а если и заявляют, эти списки часто могут в одностороннем порядке изменяться со стороны Hosted Model Provider.

Лучшая практика:

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

Основные выводы

Суверенный контроль над вашей альфа-версией требует детального контроля над тем, как ваши данные обрабатываются Hosted Model Providers. Защита, предлагаемая Hosted Model Providers, даже если они называют ее «ZDR» и даже если вы согласовали надежные условия ZDR, полна подводных камней и ловушек для неосторожных. Добивайтесь широких защитных условий в договорах, создайте процесс проверки и список разрешенных (allow-list) для новых сервисов, чтобы не выйти за рамки вашей защиты, пресекайте односторонние изменения в вашем соглашении и снижайте риск операционных сбоев, ограничивая то, что Hosted Model Providers могут делать, если они считают, что что-то пошло не так. Hosted Model Providers тщательно продумали, что их условия позволяют им делать с вашей альфа-версией — вам следует поступить так же.