Работает, но врёт: как геоблокировки ломают ИИ-систему незаметно
Поиск в системе не работал минимум три недели, а мониторинг был зелёный: ИИ-агент съедал ошибку инструмента и спокойно отвечал по памяти. Разбираю класс поломок, при которых всё "работает", - блокировки по географии, тихие отказы и то, как их вообще заметить.
Самая дорогая поломка - не та, при которой всё падает. Падение видно сразу, его чинят за час. Дорого стоит поломка, при которой система продолжает отвечать, отчётность зелёная, а результат тихо стал хуже.
Расскажу про класс таких поломок, с которым в России теперь сталкивается любой, кто строит ИИ-системы: отказ внешнего сервиса по географическому признаку.
Что случилось
В одной системе ИИ-ассистент умеет искать в интернете - это отдельный инструмент, который он вызывает, когда своих знаний не хватает. Я полез в журналы по другому поводу и от нечего делать посмотрел статистику вызовов поиска.
За всё окно хранения журналов - две недели, 335 вызовов - успешных не было ни одного. Ноль. Поиск был мёртв как минимум с начала месяца.
При этом в системе не горело ничего. Запуски числились успешными, пользователи не жаловались, поддержка была спокойна. Причина проста и от этого неприятна: ИИ-агент устроен так, что ошибку инструмента он обрабатывает сам. Инструмент не ответил - агент пожал плечами и ответил по памяти. Формально диалог завершён успешно. Фактически человек получил ответ без свежих данных и не узнал об этом.
Почему это гео, а не сломанный ключ
Дальше началась диагностика, которая заняла бы дни, если бы не одна привычка: при странном отказе внешнего сервиса первым делом сравнить его поведение из разных точек.
Сервис отвечал кодом 403 и html-страницей балансировщика вместо нормального json. С зарубежного адреса тот же самый ключ давал 200. С двух независимых российских адресов - 403. Запрос вообще без ключа с тех же российских адресов получал аккуратный 401 в json - то есть сеть проходит, адрес не забанен, отвечает именно приложение. Режется конкретно аутентифицированный вызов.
Это важное различение. Битый ключ даёт 401 и внятное сообщение. Гео даёт 403 и страницу-заглушку. Разница в одну цифру, а выводы противоположные: в первом случае перевыпускаете ключ, во втором перевыпуск не поможет никогда.
Отдельная ловушка того же семейства: один известный шлюз к языковым моделям отвечает на запросы из дата-центров кодом 403 с формулировкой про политику безопасности, а в другом сценарии - кодом 401. То есть 401 от него с сервера - это не протухший ключ, а тот же самый блок. Я потратил на эту догадку время дважды и теперь держу её записанной.
Масштаб проблемы шире, чем кажется
Проверка соседних сервисов с тех же адресов дала пёструю картину: часть поисковых API режет российские адреса наглухо, часть работает без вопросов. Отдельная история - мессенджеры: исходящие в один популярный мессенджер из российского облака стабильно упираются в таймаут. У этого есть красивое следствие: если алерты о сбоях настроены туда же, то оповещатель падает на отправке оповещения. Про аварии не узнаёт никто, и мониторинг снова зелёный.
Общий вывод простой: в 2026 году доступность внешнего сервиса - это не константа, а переменная, зависящая от того, откуда вы вышли в интернет. Причём меняется она без предупреждения и без письма на почту.
Что с этим делать
Считать внешний сервис ненадёжным по умолчанию. Не потому, что он плохой, а потому, что канал до него вам не принадлежит.
Ловить тихие отказы отдельно. Мониторинг "процесс завершился успешно" здесь бесполезен. Нужны метрики результата: сколько вызовов инструмента вернули данные, а не ошибку; какая доля ответов агента опиралась на поиск. Хорошая проверка на здравый смысл - раз в месяц открыть журналы и посмотреть, что вообще происходит внутри успешных запусков.
Не гасить ошибки внутри агента молча. Если инструмент не ответил, это должно попадать в журнал сбоев и в оповещения, даже если агент справился без него. Умение агента выкручиваться - достоинство для пользователя и катастрофа для эксплуатации.
Держать канал наружу отдельным узлом. У меня весь исходящий трафик к зарубежным сервисам идёт через один управляемый шлюз. Когда точка выхода перестаёт работать, я меняю её в одном месте, а не в пятнадцати интеграциях. За последний год я менял её дважды - оба раза внезапно.
Иметь запасного поставщика. Не абстрактно, а конкретно: проверенный и настроенный второй сервис того же назначения, на который переключаются одной настройкой.
Не строить алерты на канале, который может отвалиться. Оповещения о сбоях должны идти по маршруту, независимому от того, что они охраняют.
Что забрать себе
- Успешный запуск не равно полученный результат. Особенно у ИИ-агентов: они умеют молча работать без инструментов.
- При странной ошибке от внешнего сервиса сравните ответ с другой точки выхода до того, как перевыпускать ключи.
- 403 со страницей-заглушкой и 401 в json - разные диагнозы. Смотрите не только на код, но и на формат ответа.
- Точка выхода в интернет - это архитектурный элемент. Заложите её отдельно, чтобы менять в одном месте.
- Канал оповещений о сбоях не должен зависеть от того же, что ломается.
Новые разборы - на почту
Разборы задач автоматизации: что автоматизировать, сколько это стоит и что даёт в цифрах. Одно письмо на статью, без рекламы чужих продуктов.
