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

13 мин чтения

27 июля 2026 г.

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

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

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

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

1. Защитите свою альфу с помощью контракта

1.1 Обеспечьте надежную защиту с нулевым сохранением данных (ZDR)

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

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

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

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

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

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

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

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

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

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

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

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

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

• Следуйте стратегиям минимизации рисков из Раздела 3.1 для защиты от одностороннего изменения пределов ответственности Провайдерами хостинговых моделей.

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

2.1 Бета-версии или другие сервисы, на которые не распространяется ZDR

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

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

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

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

Получайте материалы Palantir на свой электронный адрес

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

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

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

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, причем эти классификаторы часто являются излишне чувствительными и могут ошибочно срабатывать на безопасные промпты. Это означает, что даже правомерное использование их сервиса может привести к приостановке или прекращению обслуживания, создавая угрозу сбоя в вашем бизнесе.

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

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

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

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

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

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

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

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

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

• Требуйте по договору, чтобы провайдер размещенных моделей не направлял ваш трафик в регионы, которые запрещены для вашей организации.

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

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

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

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