Почему именно доступ к ИИ, а не его функциональные возможности, представляет реальный риск зависимости
В этой статье рассматриваются недавние инциденты с контролем за экспортом моделей Claude и GPT-5.6 с целью доказать, что доступ к ИИ-моделям является нестабильным фактором, независимым от их базовых возможностей.
Что на самом деле отличает аренду интеллекта от его владения?
Примерно три года индустрия сосредотачивалась совершенно на неверных показателях.
Велись ожесточённые дискуссии по поводу критериев оценки, способности к логическому мышлению, уровня галлюцинаций и размера окна контекста — всего того, что служило показателями того, насколько умны эти системы.
Но сегодня более важен другой вопрос: у кого находится кнопка, которая может выключить этот интеллект?
12 июня 2026 года правительство США ввело ограничения на экспорт двух новейших моделей Anthropic — Claude Fable 5 и Claude Mythos 5.
По этому распоряжению Anthropic была обязана прекратить доступ иностранным гражданам, независимо от того, находились ли они физически внутри или снаружи Соединённых Штатов.
Anthropic заявила, что у неё нет надёжного способа мгновенно подтвердить национальность.
Столкнувшись с этим, компания предприняла радикальные меры: она отключила оба продукта для всех иностранцев, включая сотрудников самой компании.
Прошло восемнадцать дней, прежде чем правительство сняло ограничения. 1 июля Fable 5 снова стал доступен во всем мире, а Mythos 5 был восстановлен для определенной группы американских организаций после получения одобрения от властей 26 июня.
OpenAI затем пошла практически таким же путем, но начав с противоположной стороны.
26 июня OpenAI запустила GPT-5.6, однако по требованию правительства изначально ограничила ее доступ небольшой группе заранее проверенных партнеров, личности которых уже были сообщены властям. OpenAI публично заявила, что не хочет, чтобы такой способ внедрения с участием правительства стал стандартной практикой в будущем.
К 9 июля GPT-5.6 стала доступна всем.
Подумайте о том, что на самом деле раскрывает эта последовательность событий.
Ничего не было конфисковано, удалено или повреждено из-за ошибок в коде.
Тем не менее в течение определённого времени некоторые из самых мощных коммерческих систем искусственного интеллекта, существующих в настоящее время, технически функционировали, но были недоступны для тех самых пользователей, которые их хотели использовать.
Вся эта ситуация добавляет ещё один слой к постоянным дискуссиям о темпах развития искусственного интеллекта — речь теперь идёт не только о том, насколько быстро мы должны развивать его возможности, но и о том, насколько тщательно следует планировать поэтапное внедрение и предоставление доступа.
Настоящий урок заключается не в том, что доступ исчезает. Он заключается в том, что доступ действует как независимая переменная, отделённая от самих возможностей, управляемая собственной логикой, развивающаяся по собственному графику и способная измениться в любом направлении быстрее, чем любая организация сможет отреагировать.
Это гораздо более тревожная реальность, чем медленно закрывающееся окно, потому что с уменьшающимся окном ещё можно что-то придумать. С ситуацией, когда переключатель изменяется по административному решению в непредсказуемом направлении в течение нескольких дней, справиться невозможно.
Вот вопрос, над которым стоит задуматься: если модель, от которой вы зависите, исчезнет за одну ночь, сможет ли ваша работа выжить?
Владение — это не загрузка
Когда люди чувствуют зависимость, их первая реакция — попытаться что-то приобрести.
Скачайте открытые веса, сохраните их на жестком диске и рассчитывайте на спокойствие. Однако наличие набора параметров покрывает лишь мизерную часть того, что требуется для истинной независимости, и смешивание этих понятий создаёт особый вид ложной безопасности — аналог в искусственном интеллекте покупки резервного генератора, после чего так и не проверяют, включается ли он.
Функциональный агент, выполняющий значимую работу, на самом деле представляет собой набор из по меньшей мере пяти компонентов: сами веса модели, движок инференса, обрабатывающий их, накопленный контекст проекта, инструменты, которые он может вызывать, и набор средств оценки, позволяющий определить, действительно ли замена выполняет свои функции.
Загруженный файл модели — это лишь один из элементов этого набора.
Настоящая независимость требует наличия юридического права на использование модели, среды выполнения инференса, которую можно воссоздать исключительно на основе документации, возможности свободного экспорта состояния проекта, прав на использование инструментов, находящихся под контролем вашего приложения, а не поставщика, а также доказательств того, что заменяющая система действительно способна выполнить работу.
Уже юридический аспект оказывается более сложным, чем кажется на первый взгляд.
«Открытые веса» и «открытый исходный код» — это не синонимы: определение Инициативы по открытому исходному коду предполагает гораздо большее, чем простую возможность скачивания параметров, и лицензия с либеральными условиями на этапе выполнения не автоматически распространяется на все модели, которые могут работать с ней.
Необходимо внимательно прочитать конкретную лицензию, регулирующую каждый продукт, и хранить её копию вместе с этим продуктом.
Вопрос принадлежности данных находится совершенно в другой плоскости. Согласно коммерческим условиям Anthropic, клиенты сохраняют права на всё, что они предоставляют, владеют результатами работы между двумя сторонами, а Anthropic запрещено использовать контент клиентов для обучения с помощью этих сервисов. Простое отправление вашего контента поставщику не приводит к переходу прав собственности от вас. Остаётся ли этот контент у поставщика дальше — это ещё один отдельный вопрос, ответ на который зависит от конкретного продукта, контракта и настроек, а не от того, что вы когда-то где-то прочитали.
Всё это не является аргументом против использования хостингованных моделей.
Это просто напоминание о том, что фраза «мы владеем нашим ИИ» подразумевает пять-шесть отдельных условий, каждое из которых должно соблюдаться, и большинство команд даже не утруждают себя проверкой ни одного из них.
Арифметика самодостаточности
Расчёт количества памяти, необходимой модели, — это простая часть задачи: берётся количество параметров, умножается на количество битов, используемых на каждый параметр, затем полученное значение делится на восемь.
Модель с восемью миллиардами параметров при точности 16 бит требует примерно шестнадцать гигабайт; при снижении точности до 4 бит этот показатель сокращается примерно в четыре раза. Модель с семьюдесятью миллиардами параметров занимает около ста сорока гигабайт при 16 битах или примерно тридцать пять гигабайт при 4 битах.
Обычно на этом люди прекращают размышлять о требованиях к аппаратному обеспечению, и именно этот расчёт они выполняют наиболее точно.
Настоящие ошибки проявляются позже, на более поздних этапах работы.
Кэш KV — структура, хранящая состояние внимания на протяжении всего диалога, — увеличивается по мере удлинения окон контекста, а также растет с каждым одновременно обрабатываемым запросом.
Архитектуры типа «смесь экспертов» создают дополнительные сложности: поскольку каждый токен активирует лишь часть сети, фактические вычисления за один токен остаются незначительными, но каждый эксперт, будь он активен или нет, всё равно должен находиться где-то в памяти.
Знание количества активируемых параметров позволяет оценить стоимость обработки за один токен, но оно ничего не говорит о том, сколько места занимает модель.
Перенос части модели в другое место не решает проблему хранения, он лишь перемещает её — и теперь возникает дополнительная плата за передачу данных, которой раньше не было.
Модель, успешно загруженная в память, ещё не доказала, что способна обслуживать запросы пользователей.
Скорость обработки запроса, скорость генерации и общее время выполнения задачи — это три отдельных показателя, и высокая скорость ввода запроса ничего не говорит о том, наскоро будет сгенерирован длинный ответ.
На самом деле важной является нагруженная работа — большие документы, несколько одновременных пользователей, вызовы инструментов, которые постоянно повторяются в цикле.
Тестирование с одним коротким запросом скрывает именно те задержки в очереди и конфликты памяти, которые делают локальную обработку проблематичной при одновременном использовании несколькими людьми.
Все эти ошибки связаны одной закономерностью: каждая из них использует цифру, легкую для приведения, и ошибочно считает её основным ограничивающим фактором.
Проведите собственные тесты на оборудовании, которое у вас уже есть, или арендуйте ресурсы с точно такой же конфигурацией, которую вы оцениваете, прежде чем принимать решение.
Покупка дополнительных ресурсов до того, как вы определите настоящее место узкого места, — это хороший способ обеспечить его сохранение.
Запрос — это не разрешение
Самое серьезное недопонимание при проектировании агентов почти совсем не связано с тем, какая модель используется.
Когда модель генерирует запрос на использование инструмента, это всего лишь просьба, ничего больше.
Какой-то отдельный механизм должен решить, будет ли эта просьба действительно выполнена.
Удивительно легко создать систему, в которой этот отдельный механизм фактически представляет собой саму модель, доверяющую себе, при этом в запросе присутствует вежливое указание о необходимости соблюдения определенных рамок.
Это всего лишь предпочтение, а не реальный лимит, и именно предпочтения используются в атаках типа инъекции запросов.
Любые данные, которые агент получает из внешних источников, считаются ненадежным входным материалом.
Файл README может содержать инструкции, предназначенные для вашего агента. То же самое касается комментариев в исходном коде, текста записей в системе отслеживания проблем или обычной веб-страницы.
Решение заключается не в более умных инструкциях, а в более строгой модели разрешений: ограничить доступ только утвержденным набором путей, а не всей файловой системой, установить лимиты на размер файлов, контролировать возможность записи данных, выполнять тесты в временной среде, не допускать доступа рабочего процесса к учетным данным развертывания и требовать, чтобы человек проверял любой патч перед его отправкой в производственную среду.
Запуск собственных локальных процессов обработки данных и ограничение прав доступа к инструментам — это две разные проблемы, и легко ошибочно предположить, что решение одной автоматически решает и другую.
Хранение весов самостоятельно определяет местоположение ваших данных и зависит ли ваша система от онлайн-состояния другой компании. Это совершенно не влияет на действия, которые агент фактически имеет право выполнять.
Команды, которые смешивают эти два аспекта, в итоге получают полностью самохостинговую модель, способную всё равно наносить неограниченный ущерб собственной базе кода.
На уровне целой команды та же логика подсказывает разместить авторизованный шлюз перед точкой входа для выполнения запросов, установить лимиты использования на пользователя и определить чёткую политику для каждого рабочего процесса — выполнять его локально, использовать разрешённую хостинговую модель или направлять на проверку человеку.
Сохраняйте точки контроля перед повторной попыткой выполнения неудачных шагов, а любые инструменты с побочными эффектами следует разрабатывать так, чтобы они были идемпотентными, чтобы попытка восстановления не могла тайно повторить уже выполненное действие.
Почему надежность действует против вас
Представьте, что каждый шаг в рабочем процессе агента имеет независимую вероятность успеха 95 процентов. Если соединить десять таких шагов в цепочку, общая вероятность успеха снижается примерно до шестидесяти процентов — 0,95 в десятой степени равно примерно 0,599.
Если увеличить количество шагов до двадцати, вероятность успеха упадет примерно до тридцати шести процентов.
На самом деле шаги в реальном мире не являются полностью независимыми, поэтому рассматривайте это скорее как иллюстрацию, чем как точный показатель. Тем не менее это демонстрирует то, что никакое качество модели не может изменить: надежность каждого отдельного шага не суммируется, а умножается, причем экспоненциально с увеличением длины цепочки.
Если повысить надежность каждого шага с 95% до 98%, вероятность успеха для десятишаговой последовательности вырастет с 60% до 82%. Но если добавить еще десять шагов к процессу с надежностью 95%, это полностью снимет полученный прирост.
Это меняет то, чего следует ожидать от небольшой локальной модели. Её настоящая задача — не быть исключительно мощной, а обеспечивать надёжность в рамках короткого, узкоспециализированного рабочего процесса, который легко проверять и в котором можно быстро восстановиться при возникновении сбоев.
И что крайне важно, количество шагов в этом процессе не определяется весами модели. Это выбор, который вы делаете при разработке приложения.
Сокращение числа этапов, проверка промежуточных результатов и наличие точек контроля, позволяющих возобновить работу после сбоя без полной перезагрузки, обычно обеспечивают большую надёжность, чем замена на более крупную модель.
Именно поэтому оценка не может оставаться расплывчатой или основанной на анекдотах.
Возьмите пятьдесят задач из вашего реального списка дел, для каждой из которых укажите ожидаемый результат в месте, куда агент не имеет доступа и не может что-либо изменить.
Отслеживайте корректность — были ли вызовы инструментов действительно валидными, какова задержка, сколько попыток коррекции потребовалось и сколько времени заняло у человека устранение проблем — всё это измеряется при реалистичных объемах данных и уровнях одновременной обработки, с оценкой по заданным вами пороговым значениям, прежде чем станет ясно, какая модель окажется эффективнее.
Одно различие заслуживает отдельной колонки в ваших телеметрических данных: недоступная модель и модель, дающая некорректный ответ, представляют собой совершенно разные виды сбоев.
Первый — это проблема маршрутизации и восстановления; второй — проблема качества.
Если объединить их в одно число коэффициента успеха, вы потеряете именно ту информацию, которая позволяет определить, требуется ли для решения проблемы больше мощностей, лучшая модель или более простая и ограниченная по объему задача.
Что вы на самом деле покупаете
Единственное сравнение, которое имеет смысл проводить, — это стоимость за одну принятую задачу.
Сравнение цен токенов подразумевает сравнение несопоставимых вещей; сравнение принятых заданий — сопоставимых. При использовании локальной инфраструктуры ваши расходы включают амортизацию оборудования, электроэнергию, техническое обслуживание, время простоя и усилия на проверку. При использовании хостингового решения расходы состоят из токенов, попыток повторной обработки и усилий на проверку.
Необходимо выполнять один и тот же набор задач при одинаковых критериях принятия как на локальной, так и на хостинговой платформе — в противном случае сравнение становится формальностью.
Расчеты приводят к ожидаемому результату.
Предположим, что локальная инфраструктура обходится вам в шестьсот долларов в месяц на фиксированные расходы, причем каждое принятое задание стоит два цента при локальной обработке по сравнению с двадцатью центами при использовании хостингового API. Точка безубыточности достигается примерно при 3,333 принятых заданиях в месяц.
Эти цифры носят иллюстративный характер, они не являются результатами измерений, но основная закономерность остаётся прежней: выполнение вычислений локально — это вложения с фиксированными затратами, которые окупаются только при превышении определённого объёма работы, а в противном случае приводят к убыткам.
Большинство команд остаются ниже этого порога.
Именно здесь честная картина использования локальных ИИ-решений резко отличается от маркетинговых обещаний.
При убыточности локальные вычисления не являются более дешёвым вариантом, и утверждения об обратном делают такой выбор необоснованным сразу при первой проверке цифр.
На самом деле вы покупаете возможность выбора — гарантию того, что сможете продолжать работу даже при изменении условий доступа, в соответствии с вашими требованиями.
Цена таких опций определяется уровнем волатильности, а не ожидаемыми средними результатами.
Если недавние сбои что-то и показали, так это то, что эта волатильность реальна, что она проистекает из административных решений, а не технических, и что она возникает без предупреждения.
Это веская причина для траты средств.
Но это другая причина, чем та, которая обычно приводится, и её следует оправдывать по собственным достоинствам, а не маскировать под меру по сокращению расходов.
Тест, который действительно что-то показывает
Всё это не зависит от веры в то, что законы масштабирования будут продолжать действовать, что какое-то окно доступа действительно закрывается или что AGI в конечном итоге сможет или не сможет поместиться в определённое количество VRAM.
Это прогнозы, и риск зависимости не требует того, чтобы они сбылись.
Всё, что от вас требуется, — это осознание того, что система, на которую вы полагаетесь, может перестать функционировать по причинам, не связанным ни с её производительностью, ни с вашим поведением. Так было с электросетями, подводными кабелями и платежными сетями, и теперь это явно касается также передовых моделей ИИ.
Практические решения не вызывают воодушевления. В основном они подразумевают изучение навыков, которые вы сейчас считаете само собой разумеющимися или полагаете, что кто-то другой уже занимался ими за вас.
Попробуйте следующее: полностью воссоздайте свою инфраструктуру на основе имеющихся у вас заметок и резервных копий, затем передайте эти же заметки другому инженеру и посмотрите, как он попытается выполнить воссоздание самостоятельно. Это одно упражнение научит вас гораздо большему о том, насколько вы действительно самодостаточны, чем любое количество удачных бесед с моделью, которая происходит сегодня онлайн. То, что модель доступна прямо сейчас, ничего не говорит о завтрашнем дне, и единственным настоящим доказательством устойчивости является способность вашей системы функционировать без нее.
Связанные статьи
- ReAct Explained: Как ИИ-агенты сочетают рассуждения с действиями в реальном мире — Узнайте, как фреймворк ReAct объединяет рассуждения и использование инструментов для работы ИИ-агентов, а также в чем он отличается от моделей Chain-of-Thought, RL и других моделей рассуждений.