Иногда доступ к ИИ-модели пропадает без предупреждения, и у команды не остается времени на миграцию. Антон Фокин, CEO Qtim, объясняет на примере Fable 5, как подготовить продукт к такому сценарию.
12 июня 2026 года Anthropic получила директиву США об экспортных ограничениях для Fable 5 и Mythos 5. Она касалась иностранных граждан, но компания не могла проверить гражданство пользователей в реальном времени и поэтому отключила обе модели для всех клиентов. С момента релиза прошло три дня.
Доступ к Fable 5 по всему миру вернули 1 июля, через 19 календарных дней. Mythos 5 26 июня восстановили лишь для части американских организаций. Причину полного отключения Anthropic объяснила в заявлении, а сроки и порядок восстановления доступа — в следующем обновлении.
Полное отключение модели — крайний случай. Бывает, что новую модель выпускают позже или после обновления приходится заново проверять интеграцию. Такие ограничения можно назвать «замедлением ИИ», так как доступ сохраняется, но команда дольше ждет новых возможностей или тратит время на адаптацию. Независимая проверка — одна из причин, по которым может задержаться новый релиз.
Почему аудит не отключает работающую модель
Дарио Амодеи предложил предоставлять независимым исследователям доступ к мощным ИИ-моделям еще до их публичного запуска, причем проверять они должны не только готовую систему, но и процессы ее обучения, тестирования и обеспечения безопасности. По его замыслу, внешние эксперты смогут изучать выявленные риски, проверять, насколько разработчик соблюдает собственные требования безопасности, и публиковать результаты оценки без редакционного контроля со стороны компании, за исключением ограниченного круга конфиденциальных сведений.
Такую работу может выполнять, например, независимая исследовательская организация METR, которая уже занимается оценкой возможностей и потенциально опасного поведения передовых моделей. Однако полномочий регулятора у нее нет — исследователи могут обнаружить проблему, сообщить о ней разработчику и публично предупредить о рисках, но самостоятельно запретить релиз, приостановить распространение модели или отключить доступ через API они не могут.
Окончательное решение о выпуске модели остается за разработчиком с учетом требований регуляторов, однако независимые оценки позволяют проверить его выводы о безопасности. OpenAI уже привлекает сторонние организации к тестированию моделей на разных этапах разработки и внедрения. Исследователи изучают, насколько система способна помогать в проведении кибератак, создании биологического или химического оружия, обходить защитные ограничения и действовать вопреки заданным целям. Отдельное внимание уделяется надежности самих методов проверки.
Три сценария для ИИ-продукта
Для продукта, работающего через API внешней LLM, последствия проверок безопасности и решений поставщика могут быть разными. В первых двух случаях доступ к модели сохраняется, хотя команде приходится корректировать планы или интеграцию. В третьем привычный способ обращения к модели перестает работать.
1. Новая модель выходит позже
Независимая проверка обнаруживает риск, который разработчик не успел устранить до предполагаемой даты запуска. Компания переносит релиз, усиливает защитные механизмы или ограничивает отдельные возможности модели. Например, откладывает доступ к автономным функциям, пока не убедится, что система не выполняет потенциально опасные действия без контроля пользователя.
Если предыдущая версия продолжает поддерживаться, текущая интеграция работает без изменений. Однако команде, которая рассчитывала на новые возможности модели, приходится пересматривать сроки разработки и откладывать функции, зависящие от ее появления.
2. Модель меняет поведение
Поставщик обновляет ограничения, правила безопасности, лимиты или саму модель, доступную через API. При этом запросы продолжают обрабатываться, но привычные сценарии могут давать другой результат. Например, модель начинает чаще отказывать в выполнении определенных инструкций, иначе вызывает внешние инструменты или меняет структуру ответа, на которую рассчитывает приложение.
Подобные изменения предусмотрены самой природой LLM. В документации OpenAI указано, что поведение моделей может различаться даже между версиями внутри одного семейства. Поэтому разработчикам рекомендуют закреплять конкретные версии моделей и регулярно проверять качество ответов на собственных тестовых задачах. После обновления команде может потребоваться заново проверить промпты, обращения к сервисам и обработку результатов.
3. Доступ к модели прекращается
Причиной могут стать экспортные ограничения, санкции, требования законодательства или изменение политики поставщика. Иногда прекращение поддержки известно заранее. Например, Anthropic ведет список выводимых из эксплуатации моделей и обычно предупреждает об их отключении как минимум за 60 дней. Это дает разработчикам время проверить замену и перенести интеграцию.
Однако юридические ограничения могут вступить в силу без такого переходного периода. Тогда продукту приходится переключаться на резервную модель, а если подходящего аналога нет, временно ограничивать функции, зависящие от недоступного API. При этом простая замена адреса запроса не гарантирует прежнего качества: другая модель может хуже справляться с отдельными задачами или требовать изменения инструкций.
История Fable 5 показывает, как выглядит третий сценарий на практике. Модель стала доступна 9 июня 2026 года, а уже 12 июня Anthropic пришлось отключить ее для всех клиентов после получения экспортной директивы правительства США. Доступ восстановили 1 июля, хотя решению властей предшествовало сообщение об обходе защитных механизмов, отключение не было результатом оценки METR или планового вывода модели из эксплуатации. Разработчики продуктов столкнулись с внешним решением, сроки которого не могли предусмотреть заранее.
Для команды и клиентского сервиса последствия различаются
Во время ограничений команда Qtim использовала Fable 5 для анализа и аудита проектов. Быстро подобрать замену не удалось — другие модели справлялись с отдельными задачами, но одного инструмента с сопоставимыми возможностями команда не нашла. Рабочие процессы сохранились, однако часть операций, которые раньше выполнял ИИ, снова потребовала больше времени и участия специалистов. Особенно это ощущалось в задачах, связанных с изучением больших объемов кода, проверкой архитектурных решений и поиском потенциальных проблем.
По опыту одной компании нельзя определить, насколько сильно подобное отключение замедлит работу других команд. Однако исследование METR помогает понять, почему потеря привычной модели может оказаться чувствительной. С февраля по апрель 2026 года организация опросила 349 технических специалистов, включая разработчиков, исследователей и руководителей. Участники оценивали, насколько ИИ увеличивает ценность выполняемой ими работы, и медианные оценки по разным вопросам составили от 1,4 до 2 раз, а ускорение выполнения задач респонденты оценивали в 3 раза.
Опыт Qtim также показывает, почему одного запасного сервиса может оказаться недостаточно. Большая часть сотрудников использует Claude, часть работает с OpenAI, а для отдельных задач подходят Kimi, DeepSeek и GigaChat. Выбор зависит от того, насколько хорошо конкретная модель справляется с работой и какие ограничения возникают при ее использовании в проекте. У Claude пока нет одной прямой замены для всех сценариев — модели по-разному обрабатывают длинный контекст, следуют сложным инструкциям, вызывают внешние инструменты и формируют ответы. При переходе команде приходится заново проверять те операции, для которых раньше использовалась недоступная модель.
Во внутренней работе последствия можно частично компенсировать перераспределением задач между сотрудниками, изменением сроков или временным возвращением к ручной проверке. Для клиентского продукта ситуация сложнее, поскольку зависимость от поставщика становится заметна пользователю. Если модель отвечает за поиск по базе знаний, обработку обращений или генерацию документов, недоступность API может нарушить работу соответствующей функции. Пользователь при этом обычно не знает, какой именно сервис находится за интерфейсом приложения, и воспринимает ошибку как проблему самого продукта.
Чтобы сбой внешнего API не распространялся на остальные компоненты системы, в архитектуре предусматривают тайм-ауты, ограниченное число повторных запросов, очереди задач и резервные сценарии. Один из распространенных механизмов называется circuit breaker — запрос можно направить резервной модели, сохранить в очереди или сообщить пользователю о временном ограничении функции. При такой подготовке отказ поставщика не обязательно приводит к остановке всего продукта.
Как подготовить переключение
Один из способов уменьшить зависимость от конкретного поставщика — вынести взаимодействие с LLM в отдельный программный слой. Такой коннектор принимает запросы от приложения, преобразует их в нужный формат и направляет к API Anthropic, OpenAI, GigaChat или другого провайдера. Если доступ к основной модели прекращается, команде не приходится менять обращения к ней во всех частях продукта. Достаточно изменить маршрутизацию запросов и при необходимости адаптировать их обработку внутри коннектора.
Однако единый интерфейс решает прежде всего техническую часть миграции. Даже при одинаковом формате API результаты работы моделей могут различаться. Anthropic в рекомендациях по работе с Claude отдельно разбирает изменения в выполнении инструкций, использовании инструментов и настройках при переходе между поколениями моделей. В связи с этим переключение коннектора еще не означает, что приложение сможет работать в прежнем режиме.
Для проверки заранее собирают набор типовых задач из реальной работы продукта. Например, если модель анализирует документы, оценивают полноту извлечения информации и корректность ссылок на исходный текст. Если управляет внешними инструментами, проверяют выбор функции, передачу параметров и обработку ошибок. Для каждого сценария сравнивают точность, частоту сбоев, задержку ответа и стоимость обработки. Это позволяет заранее определить, какие функции можно перенести на резервную модель без заметных изменений, а какие потребуют доработки или временного ограничения.
Проверить сценарий до сбоя
Проверять резервный контур лучше в условиях, приближенных к реальному отказу поставщика. Для этого на тестовом стенде отключают доступ к основному API у одной критичной ИИ-функции и наблюдают, что происходит с запросами, пользовательским интерфейсом и зависимыми сервисами. Важно проверить всю последовательность:
- как быстро система обнаруживает сбой;
- перестает ли отправлять повторные запросы;
- включается ли резервная модель;
- получает ли пользователь понятное сообщение, если функцию временно нельзя выполнить.
Отдельно нужно проверить восстановление после сбоя. Когда основной поставщик снова становится доступен, приложение должно корректно возвращать запросы на прежний маршрут, не терять накопленные задачи и не создавать повторные операции. Это особенно важно для сервисов, где модель взаимодействует с базами данных, CRM или другими внешними системами.
О зависимости от одного поставщика говорят несколько признаков: без его API перестает работать ключевая функция продукта, у команды нет проверенного порядка переключения, а альтернативная модель ни разу не тестировалась на реальных сценариях. При этом резервирование не обязательно означает постоянную оплату нескольких одинаковых моделей. Для одних продуктов достаточно упрощенного режима работы, для других потребуется полноценный запасной провайдер с заранее согласованными условиями доступа.
История Fable 5 показывает, что даже у крупного поставщика модель может стать недоступной в течение одного дня по причинам, которые разработчики клиентских продуктов не контролируют. Предусмотреть конкретное решение регулятора невозможно, но можно заранее определить функции, зависящие от внешней модели, подготовить порядок переключения и проверить его на практике. Тогда внезапное ограничение с меньшей вероятностью затронет весь сервис, а у команды останется возможность продолжать работу, пока основной доступ не восстановится.