Пять вопросов, на которые должны отвечать ваши данные, прежде чем с ними начнёт работать ИИ-агент

Сабер приводит яркий пример. На стол руководства ложится операционный отчёт, собранный ИИ. В нём написано, что выручка в регионе за прошлый месяц выросла на 15%.

Финансовый директор задаёт четыре вопроса:

1. Налог включён?
2. Возвраты вычтены?
3. Когда данные обновлялись последний раз?
4. Из какой таблицы взята цифра?

Если ответов нет, показатель в 15% не годится для решения. Отчёт сгенерировался за секунды, а проверять его теперь придётся полдня руками. Экономии не случилось, добавилась новая работа.

Мы видим ровно такую динамику на проектах, только без всякого ИИ. Два человека приносят на совещание разные цифры по одному показателю, и дальше час уходит на выяснение, чья методика правильная. Разница в том, что раньше расхождение всплывало на совещании и был повод разобраться. Агент проговорит одну из версий уверенным тоном и не оговорится, что версий было три.

Аналитик в этой ситуации умеет нажать на тормоз. Увидев, что две системы дают разную выручку, он остановится, проверит определение, уточнит время загрузки, спросит у финансистов, что означает пустое значение. Эти паузы работают как неформальная система контроля, которую никто не описывал в регламенте.

Отсюда простая мысль, вокруг которой и построен чек-лист: агент не чинит данные, он их усиливает вместе со всеми дефектами.

FanRuan формулирует пять вопросов, на которые должны отвечать данные, пригодные для работы ИИ. Мы разделяем позицию вендора, поэтому дальше по каждому пункту добавим то, чего в материале нет: как это проверить у себя за пару часов.

1. Как считается эта метрика
Самая частая находка на старте проекта: показатель называется одинаково, а считается по-разному. Отгрузка с возвратами и без. Выручка с НДС и без. Активный клиент за 30 дней и за 90. Валовая маржа, в которую в одном подразделении входит логистика, а в другом нет.

Пока с этим работают люди, система как-то функционирует: аналитик помнит, что в отчёте для коммерции своя логика, и мысленно поправляет. Агент не может этого сделать — он возьмёт то определение, которое найдёт первым.

Как проверить. Выберите пять ключевых показателей и запросите формулу их расчёта у трёх сотрудников из разных подразделений. При расхождении ответов хотя бы по одному показателю подключение агента преждевременно. На следующем этапе формируется реестр метрик, включающий формулу, источник, гранулярность, исключения и владельца, уполномоченного изменять определение. Такой реестр должен храниться в семантическом слое BI, а не в текстовом документе, — в противном случае агент не сможет к нему обратиться.

2. Откуда взялась эта цифра
Каждый вывод должен прослеживаться до конкретного набора данных, отчёта или системы-источника. Пользователю нужно видеть не только число, но и путь его получения.

Как проверить. Возьмите один показатель из управленческого отчёта и попробуйте пройти его до строки в исходной системе. Засеките время. Если у вас это заняло больше получаса с участием двух человек, то в момент, когда цифру назовёт агент, разбирательство займёт столько же. Только теперь оно начнётся после того, как на цифру уже отреагировали.

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

Как только данные тянет агент и сам рассылает сводки, тот же фильтр становится контуром безопасности. Появляются вопросы, которых раньше не было. От чьего имени агент ходит в данные: от имени задавшего вопрос или от собственной технической учётки с расширенными правами? Что происходит, когда руководитель одного дивизиона просит сравнить свои показатели с соседним? Кому уйдёт рассылка, если в списке получателей есть человек с более узкими правами, чем у автора запроса?

Как проверить. Пересмотрите матрицу доступа до пилота, а не после. Отдельно разведите права на чтение модели и права на получение рассылки, они не совпадают. Убедитесь, что в логах видно, кто и что запрашивал через агента.

4. Насколько данные свежие
Человек, открывающий дашборд, обычно знает, что продажи обновляются ночью, а данные из MES приезжают с задержкой в час. Агент этого не чувствует и ответит на вопрос про сегодняшнее утро вчерашними цифрами, не сделав оговорки.

Как проверить. Зафиксируйте расписание обновления по каждому источнику и вынесите метку актуальности в модель так, чтобы она попадала в ответ. «Доля годной продукции 94,2% по состоянию на 06:00» и просто «94,2%» — это ответы разной надёжности.

Сюда же относится сценарий «данных нет». Загрузка упала, витрина пустая. Агент, который в этот момент отвечает «продажи составили ноль», опаснее агента, который отвечает «данные за вчера не загрузились».

5. Понимает ли ИИ смысл вашего бизнеса
Названия столбцов — это ещё не экспертиза. Руководитель спросит «сколько мы отгрузили в Питере», а в модели увидит sales_qty с кодом региона. Проблема в том, что «Питер» для одного означает город, а для другого — весь Северо-Западный федеральный округ. И это совершенно разные показатели.

Как проверить. Соберите список реальных вопросов, которые звучали на совещаниях за последний квартал. Не гипотетических, а тех, что задавали живые люди. Сверьте с моделью и честно отметьте, на какие вопросы данных нет. Обычно оказывается, что часть вопросов упирается в отсутствие связей между системами, и это задача хранилища, а не ИИ.

Таким образом, задав пять вопросов, вы можете проверить главное: согласованность, прослеживаемость, доступ, актуальность и смысл. Чем яснее компания отвечает на эти вопросы до пилота, тем меньше времени уйдёт на перепроверку результатов после.

Подключить модель напрямую к базе — это быстрый способ собрать красивое демо, но плохой способ выйти в промышленную эксплуатацию.

В сырой среде перемешано всё: тестовые таблицы, старые версии витрин, временные поля и противоречивые определения разных департаментов. Без контекста управления агент выберет неверный источник, и никто не заметит. Хуже того: запросы на естественном языке могут обойти фильтры, которые работали в интерфейсе, потому что в данных их просто нет.

Подключать агента нужно на уровне проверенных моделей, согласованных метрик, настроенных прав и зафиксированной логики расчётов. FanRuan называет этот подход Built on Trusted BI — именно так устроена Dora. С инженерной точки зрения это означает, что границы работы агента определяются не текстом запроса, а слоем данных.

Сабер предлагает оценивать готовность данных к работе с ИИ по четырём связанным уровням. Это удобная шкала для самооценки.

Connect. Источники собраны в единую среду: ERP, MES, WMS, CRM, IoT, файлы, базы. Понятно, где что лежит, кто владелец и как часто данные меняются.

Prepare. Устранены расхождения в форматах и мастер-данных, построены модели по предметным областям, метрики зафиксированы стандартно.

Govern. Есть управление метриками, каталог, правила качества, контроль доступа и происхождение данных. Проверочный вопрос уровня звучит так: ясно ли, что означает цифра, виден ли путь её получения и безопасно ли её отдавать.

Serve. Проверенные активы открыты для потребителей, включая агентов, а проблемы, найденные в работе, возвращаются на уровень Govern.

Уровни образуют цепочку. Если выпадает хотя бы одно звено, экономия времени на генерации отчёта съедается временем на проверку этого отчёта.

Масштабные программы data governance идут годами, а изолированные пилоты редко дают результат, который можно применить повторно. Есть третий путь: выбрать одну задачу, которая действительно создаёт проблемы, и навести порядок в данных ровно под неё.

Допустим, команда тратит два дня в неделю на подготовку управленческого отчёта. Двигайтесь от него назад: какие данные он использует, кто утвердил метрики, когда данные обновляются, кто имеет право их видеть, как проверяется финальный результат. Такой разбор сразу подсвечивает критичные пробелы, и чинить нужно только их.

От себя добавим два критерия выбора первого сценария. Первый: частая задача с низкой ценой ошибки. Утренняя операционная сводка, контроль остатков, регулярные вопросы по продажам. Не финансовая отчётность, не расчёт бонусов, не то, что уходит наружу. Второй: понятная граница данных, один-два источника, а не «все данные компании».

И заранее договоритесь, кто проверяет ответы агента и по каким критериям. Без этого пилот сводится к субъективным впечатлениям: от «вроде неплохо» до «что-то он напутал» — и решение о промышленной эксплуатации на таком базисе не принимается. Мы рекомендуем собрать набор из 30−50 контрольных вопросов с эталонными ответами (рассчитанными вручную) и оценивать три категории: полностью верные ответы, правдоподобные, но неверные, и обоснованные отказы. Третья категория — самая важная. Агент, который умеет отвечать «на этот вопрос данных нет», полезнее агента с высоким процентом уверенных, но непроверенных ответов.

И ещё один пункт, на котором часто спотыкаются проекты.

ИТ отвечает за архитектуру, платформу, права, безопасность и мониторинг. Бизнес отвечает за смысл метрик, пороги аномалий и требования к результату. Дата-агент не встанет в рабочий процесс, если одна из сторон в этом не участвует.

Пример из производства. ИТ может подтянуть данные из цеховых систем, которые фиксируют выпуск по линиям и сменам, простои и брак, и данные системы контроля качества, но при каком отклонении бить тревогу, какие разрезы проверять первыми и в какой момент передавать задачу человеку, решают руководители производства и качества. Пока эти правила не согласованы, у агента нет критерия, что считать проблемой.

Дата-агенты закрывают тот самый разрыв, о котором мы говорим всё это время. Между «показатель просел» и «ответственный получил задачу» лежит цепочка ручной работы, и её действительно можно отдать машине.

Только опирается эта цепочка на слой, который агент не создаёт: метрики, права, актуальность, семантика, критерии проверки. Этот слой полезен сам по себе. Компании, которые его уже построили, получили эффект ещё до появления ИИ в повестке, и теперь просто окажутся готовы раньше остальных.