Источник, который мы не смогли прочитать: заметка о провалах AI-пилотов

Каждый руководитель платформы сталкивался с одним и тем же: кликаешь по ссылке из Slack-треда и видишь только крутящийся экран «проверка браузера». Именно это произошло, когда мы попытались получить исходный материал для этой статьи. URL на Let's Data Science вернул интерстициал с проверкой браузера вместо статьи, поэтому здесь нет ни цитат, ни цифр, ни названий компаний для анализа.

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

Ключевые детали

URL содержит слаг enterprises-see-ai-pilots-fail-to-scale, что указывает на то, что исходный материал освещал распространённую проблему остановки корпоративных AI-пилотов до выхода в продакшн. Подтвердить это мы не можем. Зато можем подтвердить, что тело ответа содержало ровно две читаемые человеком строки: «We're verifying your browser» и «Website owner? Click here to fix.» Всё. Никакого заголовка, никакого авторства, никакого текста.

Это Cloudflare-подобная бот-проверка или нечто функционально идентичное. Она сработала на стандартный запрос из стандартной сети, что означает: правила на стороне издателя настроены достаточно агрессивно, чтобы блокировать не только скрейперы, но и обычных вторичных читателей. Ирония в том, что издание о data science закрывает статью об AI-адаптации за антибот-стеной, — её замечают все.

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

Поэтому вместо того чтобы придумывать статистику о провалившихся пилотах, поговорим о том, что на самом деле говорит нам пустая страница. Инженерная история здесь — не «корпорации видят, как AI-пилоты не масштабируются». Инженерная история в том, что в 2026 году значительная часть веба недоступна для агентов и пайплайнов, которые enterprise-AI-команды получают задание строить. Если ваш retrieval-стек не может прочитать статью, её не может прочитать ни ваша RAG-система, ни ваш research-агент, ни ваш краулер конкурентной разведки. Блокировщик перед человеком-читателем — тот же блокировщик перед ботом, которого вы только что запустили.

Почему это важно для разработки AI

Каждая команда, строящая агентные рабочие процессы прямо сейчас, сталкивается с этой стеной и замалчивает это. Демо отлично выглядят на курируемых доменах. Потом агент выходит в открытый веб и возвращает вежливое молчание, потому что половина источников за Cloudflare, Akamai, PerimeterX или за логином. Сбой происходит тихо. Агент не говорит «меня заблокировали». Он говорит «на основе доступной информации» и галлюцинирует остальное.

Моё мнение: проблема бот-стен — это единственный наиболее недооценённый риск надёжности в производственных агентных системах сегодня. Выглядит как проблема с контентом. На самом деле это проблема распределённых систем, потому что поведение вашего агента теперь зависит от того, чьи правила WAF сработали в эту минуту. Это система, которую нельзя покрыть регрессионными тестами.

Посмотрите, как это преподносят крупные вендоры. Документация Claude по computer use и вызову инструментов предполагает, что целевые страницы рендерятся. Документация платформы OpenAI по инструментам для браузинга и веб-поиска предполагает то же самое. Спецификация Model Context Protocol определяет, как инструменты предоставляют ресурсы, но не определяет, что делать, когда ресурс говорит «докажи, что ты человек». Именно в этом пробеле умирают пилотные проекты.

Неудобный вывод: если ваша AI-дорожная карта зависит от веб-масштабного retrieval, вы неявно зависите от того, что чужие эвристики определения ботов останутся мягкими. Этого не будет. Издатели ужесточают правила, а не смягчают, в ответ на судебные иски об обучающих данных с 2023 по 2025 год. Команды, которые считали «модель просто может это прочитать» базовой возможностью, тихо обнаруживают, что чтение теперь — это переговоры.

Это имеет конкретные бюджетные последствия. Пилот, который тратит первые три месяца на prompt engineering, а четвёртый — на обнаружение того, что 40% целевых источников возвращают интерстициал, — это пилот, который убивают на квартальном ревью. И в постмортеме обвинят «галлюцинации» вместо инфраструктуры. Этот неверный диагноз и приводит к тому, что тот же сбой повторяется в следующей компании.

Влияние на отрасль

Для команд в iGaming и финтехе ставки выше, чем в корпоративном AI в целом. Комплаенс-процессы, KYC-обогащение, fraud intelligence, агрегация рыночных данных — всё это опирается на получение внешних источников по требованию. Если регулируемый рабочий процесс принимает решение на основе «доступной информации», а доступная информация была молча усечена бот-стеной, у вас проблема с документацией в тот момент, когда аудитор спрашивает, как модель пришла к своему выводу.

Команды, с которыми я работал в операционно-насыщенных доменах, начали рассматривать внешний fetch как поверхность надёжности первого класса — со своими SLO, своим алертингом и своими резервными уровнями. Это правильный инстинкт. Вы не хотите узнать в 2 часа ночи, что ваш агент по проверке санкций выдавал уверенные ответы на основе кешированных страниц трёхнедельной давности, потому что каждый живой запрос отражался от challenge-страницы.

Вертикали ad-tech и крипто-данных занимаются этим дольше всех, именно поэтому их краулеры дорогие, операционно сложные и укомплектованные персоналом. Новички из корпоративного IT скоро выучат тот же урок с гораздо более высокими затратами, потому что в бюджете закладывали «один API-вызов», а получили небольшую внутреннюю команду скрейпинга. Это два инженера из десятичеловечной платформенной команды, и они редко учтены в изначальном бюджете AI-пилота.

Коротко: бот-стенный налог реален, он растёт, и он находится именно там, куда AI-бюджеты отказываются смотреть.

За чем следить

Три сигнала в ближайшие несколько кварталов. Первый: выпустят ли крупные вендоры моделей собственный лицензированный retrieval, маршрутизирующий через платные соглашения с издателями, а не через сырой fetch. Это переносит расходы с вашего инфра-счёта на их счёт — хорошо для надёжности, плохо для прозрачности маржи. Второй: определят ли MCP или преемник стандартную семантику «в доступе отказано», чтобы агенты хотя бы честно сообщали о своих слепых зонах, а не конфабулировали. Третий: начнут ли издатели предлагать уровни доступа, читаемые агентами — бесплатные или платные, — чтобы вернуть себе трафик, который они массово блокируют.

Если ничего из этого не произойдёт, ожидайте, что многие постмортемы AI-пилотов в 2026 и 2027 годах тихо придут к выводу, что модель была в порядке, а проблема была в инфраструктуре. Скучный ответ. Обычно верный.

Ключевые выводы

• Исходная статья для этого материала была недоступна за стеной проверки браузера, поэтому данный анализ сообщает этот факт, а не придумывает контент вокруг него.
• Интерстициалы бот-обнаружения — это риск надёжности первого порядка для любого агента или RAG-системы, работающей с открытым вебом, и они дают сбой молча.
• Агентные фреймворки и протоколы пока не определяют стандартную семантику «меня заблокировали», что подталкивает модели к уверенным галлюцинациям.
• Регулируемые вертикали, такие как iGaming и финтех, должны рассматривать внешний fetch как отслеживаемую SLO-поверхность, а не как предполагаемую возможность.
• Закладывайте реалистичный бюджет: внешний retrieval в enterprise-масштабе обычно требует выделенной инженерии, а не строки в счёте за LLM API.