Невидимые данные становятся одной из самых дорогих проблем для корпоративного ИИ: агент выглядит умным на демо, а в реальной компании спотыкается о то, чего не видит. Именно эту мысль разбирает Нитин Сингхал в колонке о том, почему невидимые данные ломают AI-агентов в больших организациях. Для русскоязычной IT-аудитории вывод неприятный, но полезный: если агенту не дали живой контекст бизнеса, никакая красивая orchestration-схема не спасет.
Как пишет The New Stack, проблема не в том, что у компаний совсем нет данных. Наоборот, в крупных институциях и enterprise-структурах данных обычно слишком много, но значимая их часть не попадает в поле зрения команды, которая строит платформу, и самого AI-агента. Снаружи все выглядит аккуратно: есть хранилище, есть витрины, есть интеграции, есть модель, умеющая ходить по инструментам. Под водой остается организационный пласт: неформальные исключения, локальные правила, ручные обходные процессы, конфликтующие источники истины, запаздывающие обновления и контекст, который знают люди, но не знает система.
Сингхал использует метафору айсберга, и она здесь работает без скидок. Видимая часть данных обычно хорошо описана: таблицы, API, документы, доступные каталоги, формальные бизнес-процессы. Невидимая часть менее удобна и потому часто игнорируется на этапе проектирования. Это может быть знание о том, какой из двух источников считается главным только в одном филиале, почему один и тот же атрибут трактуется по-разному у разных команд, или в какой момент данные считаются достаточно свежими для действия, а в какой уже нет. Для обычной BI-системы это неприятно. Для AI-агента, который должен принимать решения или выполнять цепочку действий, это уже источник системных сбоев.
Именно здесь ломается популярная логика последних двух лет: если подключить LLM к корпоративным данным и дать ей инструменты, получится цифровой сотрудник. На презентации это часто выглядит убедительно, потому что демонстрация идет по видимому, чистому и заранее подготовленному слою данных. В бою агент сталкивается не с презентацией, а с организацией. А организация редко бывает линейной. В ней полно серых зон, временных договоренностей, несинхронизированных систем и процессов, которые «вообще-то так не должны работать», но работают годами. Для человека это раздражающий фон. Для агента это дыра в реальности.
Почему проблема бьет именно по агентам
Классический аналитический отчет может пережить неидеальные данные: пользователь увидит странность, задаст вопрос, уточнит источник. AI-агент работает иначе. Он не просто отвечает, а действует: ищет, сравнивает, выбирает, инициирует шаги, иногда без постоянного контроля человека. Поэтому невидимые данные опасны не только как причина неточного ответа, но и как причина неверного действия. Если в компании существует скрытый слой ограничений, исключений и зависимостей, агент начинает принимать формально логичные, но организационно неверные решения.
Для разработчиков это означает довольно приземленную вещь: качество агентной системы определяется не только качеством модели, prompt engineering или набором tools. Критичнее то, насколько команда умеет извлекать и формализовать скрытый контекст. Иначе проект упрется в ложную диагностику. Ошибка будет выглядеть как «модель галлюцинирует», «retrieval работает нестабильно» или «агент плохо планирует шаги», хотя корень проблемы в другом: нужного куска реальности просто не было в доступном контексте. Модель тут выступает не источником магии, а честным усилителем беспорядка.
Для продактов и IT-руководителей в этом материале тоже есть неприятный сигнал. Многие корпоративные проекты вокруг AI-агентов стартуют с выбора платформы, вендора, модели, guardrails и метрик внедрения. Это нормальные вопросы, но колонка Сингхала напоминает о более раннем этапе, который часто недооценивают: картировании организационных знаний. Если компания не понимает, какие данные у нее реально используются для решений, где живут исключения и кто владеет контекстом, то бюджет уходит не в автоматизацию, а в ускоренное масштабирование путаницы. Сначала агент делает одну ошибку на десять задач, потом его начинают обвешивать костылями, а потом все удивляются, почему эксплуатация оказывается дороже обещанного.
Что из этого следует для команд
В тексте нет сенсационного анонса продукта, новой модели или громких финансовых цифр. И в этом его ценность. The New Stack фактически описывает менее заметный, но более важный сдвиг рынка: разговор про AI-агентов выходит из фазы «что они в принципе умеют» в фазу «насколько организация готова дать им реальную картину мира». Для российского рынка это особенно знакомо. У крупных компаний почти всегда есть исторически сложившийся ландшафт из нескольких хранилищ, старых внутренних систем, Excel-процессов, ручных регламентов и командных договоренностей, которые не отражены в единой схеме. Если поверх этого слоя быстро натянуть агентную архитектуру, она будет воспроизводить все накопленные противоречия с машинной скоростью.
Практический вывод довольно жесткий. Перед внедрением AI-агента нужно не только собирать датасеты и настраивать доступы, но и выявлять организационные слепые зоны: какие данные считаются неофициальными, но реально влияют на решения; где существуют локальные правила; какие поля интерпретируются по-разному; какие процессы живут вне систем и держатся на людях. Без этой работы разговоры о fully autonomous agent быстро превращаются в корпоративный театр технологий. Агенту можно дать длинный контекст, RAG, function calling и аккуратные политики безопасности, но если он не видит критичную часть айсберга, он все равно пойдет неверным курсом.
На этом фоне главный вопрос для ближайших лет звучит не так уж модно: кто в компании отвечает за перевод скрытого организационного знания в машиночитаемую форму. Победят, скорее всего, не те, кто первым подключил самую громкую модель, а те, кто сумел показать агенту не только витрину данных, но и подводную часть бизнеса. Иначе AI-агенты останутся умными стажерами с доступом к API, которые уверенно действуют ровно до первого столкновения с реальной корпоративной жизнью.