До 60% AI-проектов компании могут свернуть уже к 2026 году, если под ними нет данных, готовых к работе с моделями. На этом фоне архитектура ИИ перестает быть темой для слайдов стратегической сессии и превращается в вполне приземленный вопрос: во что ИТ-руководителю вкладываться сейчас, чтобы через полгода не получить дорогую, шумную и плохо управляемую игрушку.
Именно об этом пишет MIT Technology Review в материале, подготовленном в партнерстве с Elastic. Издание свело разговор о корпоративном ИИ к четырем базовым элементам: данным, контексту, управляемости и наблюдаемости, а также роли людей в контуре. Логика простая: модели меняются быстро, агентные системы становятся все сложнее, а фундамент, на котором они работают, менять на ходу дорого и больно.
Первая опора — данные. Здесь никакой магии не случилось: если в компании разрозненные источники, устаревшие системы, нестыкующиеся схемы и спорная зона ответственности за качество данных, ИИ это не починит. Наоборот, он лишь масштабирует хаос в виде галлюцинаций, перекосов и ответов, которым никто не верит. CIO Elastic Аднан Адил прямо связывает надежность моделей с качеством и доступностью данных: без корректного контекста они либо не дадут нужный уровень сервиса, либо начнут ошибаться там, где бизнес ждет уверенности. Для русскоязычной ИТ-аудитории это звучит знакомо: если внутри компании до сих пор спорят, чей это справочник, кто отвечает за мастер-данные и почему одно и то же поле в трех системах называется по-разному, разговор про продовый ИИ пока рано считать закрытым.
Второй элемент — context engineering, то есть проектирование контекста для модели. Это уже не про красивый промпт в духе «ответь как эксперт», а про всю среду вокруг запроса: какие данные вытягиваются, в каком виде подаются, что нужно исключить и как не утопить модель в лишнем шуме. В материале отдельно проводится граница между prompt engineering и context engineering: первый отвечает за формулировку запроса, второй — за то, чтобы модель вообще получила релевантную, актуальную и машиночитаемую информацию. В корпоративной практике это означает RAG, векторные базы, системы памяти, правила отбора контента и дисциплину вокруг real-time retrieval. Проблема в том, что многие компании по старой привычке думают: если контекста много, значит ответ будет лучше. На деле лишняя информация размывает релевантные сигналы, увеличивает задержки и раздувает стоимость, потому что токены тоже кто-то оплачивает.
Третья опора — governance и наблюдаемость LLM с первого дня, а не «добавим после пилота». Здесь статья бьет в нерв почти любого ИТ-директора: без четких правил доступа, контроля за retrieval-цепочками, ограничений на использование моделей и нормальной телеметрии корпоративный ИИ начинает потреблять больше данных, чем нужно, и создавать больше рисков, чем обещанной пользы. Это не только про безопасность, хотя поверхность атаки у таких систем действительно растет: prompt injection, утечки чувствительных данных, уязвимости моделей и вредоносные входы уже стали не теорией, а рабочим списком угроз. Это еще и про деньги. Чем хуже управляется архитектура ИИ, тем выше расходы на вычисления, API и сопровождение. Поэтому наблюдаемость в статье рассматривается не как приятный бонус для платформенной команды, а как инструмент контроля издержек, инженерной эффективности и качества решений.
Здесь же есть несколько цифр, которые полезно держать в голове. Gartner, по данным материала, прогнозирует отказ компаний от 60% AI-проектов к 2026 году, если у них не будет данных, подготовленных под ИИ. В отчете Elastic за 2026 год 85% ИТ-руководителей ожидают, что для внутренних генеративных приложений у них появится LLM observability. А в Deloitte Tech Executive Survey 2025 почти 70% респондентов сообщили о планах расширять команды именно в ответ на рост генеративного ИИ. Набор цифр показательный: рынок уже не спорит о том, нужен ли enterprise AI, но все отчетливее понимает, что без операционного контроля, метрик и внутренних специалистов он быстро превращается в статью расходов с туманным ROI.
Отсюда четвертый элемент — люди в контуре. На фоне разговоров о тотальной автоматизации этот тезис звучит даже слегка отрезвляюще. MIT Technology Review фактически напоминает: чем автономнее становятся системы, тем дороже ошибка в их настройке и тем выше ценность команды, которая умеет проектировать процессы, валидировать ответы, менять бизнес-логику и не путать демо с промышленной эксплуатацией. Речь не только о prompt engineering, хотя и он никуда не делся, но и об orchestration, change management, управлении доступами, ревизии процессов и накоплении институционального знания. Уход ключевых людей в таких системах стоит особенно дорого: вместе с ними из компании уходит понимание, почему агенту можно одно, нельзя другое и откуда он берет критичные для бизнеса данные.
Для разработчиков и продуктовых команд смысл заметки довольно приземленный. Если внутри компании обсуждают запуск ИИ-агентов, корпоративного ассистента, интеллектуального поиска или автоматизации back-office, смотреть стоит не только на модель и vendor pitch. Куда важнее проверить, есть ли единая и чистая база данных, понятные права доступа, механика реального обновления контекста, мониторинг качества ответов и люди, которые готовы поддерживать это не две недели пилота, а годами. Для бизнеса сигнал такой же простой: архитектура ИИ — это не отдельный проект рядом с основным ИТ-ландшафтом, а новый слой корпоративной инфраструктуры. Если собрать его на скорую руку, он быстро упрется либо в compliance, либо в стоимость, либо в потерю доверия со стороны пользователей.
Главный вопрос теперь не в том, сколько еще новых моделей и агентных фреймворков рынок увидит до конца года. Интереснее другое: сколько компаний успеют перейти от охоты за модными сценариями к скучной, но рабочей инженерии вокруг данных, контекста и контроля. Потому что именно эта скучная часть и определит, сможет ли архитектура ИИ выдержать масштабирование, а не рассыпаться после первого же роста нагрузки. Подробности исходного материала можно посмотреть в .