Карта не есть территория, или как мы пришли к ИИ-навигации по данным

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

По данным Gartner, не менее 30% проектов в области генеративного ИИ будут заброшены сразу после проверки концепта к концу 2025 года. IBM фиксирует, что только 25% ИИ-инициатив дали ожидаемый возврат инвестиций. McKinsey сообщает: лишь треть компаний масштабируют ИИ-программы на уровне всей организации, и большинство из тех, кто видит эффект, оценивают его как «менее 5% операционной прибыли (EBIT)». Это не приговор технологии — это диагноз подходу: ИИ внедряют ради самого ИИ, не ответив заранее на вопрос, какой конкретный эффект он должен принести.

Мы в «Первой Форме» шли иначе: внедряли ИИ точечно, под конкретные задачи, каждый раз отвечая на вопрос о том, какой измеримый результат хотим получить. Постепенно этот подход привёл нас к следующему шагу: мы создали в нашей BPM-платформе семантический слой — набор маршрутов, словарь терминов и правила резолвинга сущностей. Он позволяет связывать разрозненные системы и с помощью ИИ получать ответы на управленческие вопросы, опираясь на реальные данные.

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

Ответ «размазан» по пяти системам

Вот типичная ситуация для любой компании с развитой автоматизацией. Руководитель задаёт один из тех вопросов, которые кажутся рабочими и вполне конкретными.

Например: «Почему клиент, подписавший договор четыре месяца назад, до сих пор не вышел на первый бизнес-процесс в промышленной эксплуатации? Какие ключевые отклонения есть по проектам блока прямо сейчас? Каков финансовый статус этого контрагента?»

Ответ на каждый из этих вопросов существует, все факты где-то зафиксированы: в CRM, в проектном контуре, в комментариях к задачам, в расшифровках встреч. Но чтобы собрать из этих кусков выверенную картину, нужно или переключаться между несколькими системами и сводить данные вручную, или просить аналитика, а у него своя очередь задач. В итоге ответ приходит через полдня, день, а то и к концу недели.

Проблема не в том, что данных нет, а в том, что между данными и ответом нет навигации.

Почему привычные инструменты не закрывают задачу

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

• BI-витрина проектируется от данных: «вот что мы можем посчитать». Она хорошо отвечает на заранее известные вопросы — те, что заложили при разработке год назад. Но перед нетиповым запросом, который возник сегодня на совещании, дашборд беспомощен.

• Корпоративный поиск проектируется от индекса: «вот что мы можем найти». Он выдаёт документы, но не объясняет, как из найденного сложить ответ.

• RAG-решение чаще проектируется от индексации: как нарезать чанки, как эмбеддить, какую модель подключить. Но не от бизнес-вопроса пользователя. Оно впечатляет формулировками, но почти никогда не может показать, откуда именно взят каждый факт.

• Озеро данных проектируется от хранения: «вот что мы накопили». Данные там есть, но все они описывают прошлые события, а не актуальные статусы. Получить из озера ответ на вопрос «что происходит прямо сейчас» без дополнительной аналитики невозможно.

Ни один из этих инструментов не отвечает на ключевой вопрос: «Что именно нужно проверить, чтобы принять решение, и какие доказательства я приму?»

Карта не есть территория

Есть такой принцип из философии языка: карта не равна территории, которую описывает. Карта — это всегда упрощение, созданное под конкретную задачу.

Вспомним школу. У учителя географии было несколько карт одной и той же местности: физическая, политическая, климатическая. Контуры материков одни и те же, но каждая создана для разных вопросов. Туристу нужна одна, геологу — другая, синоптику — третья.

В любой компании с развитой автоматизацией уже существуют «карты» предметной области:

• CRM — карта продаж и взаимодействий;

• Проектный контур — карта работ, сроков и рисков;

• Сервис-деск — карта обязательств и инцидентов;

• Документооборот — карта решений и согласований;

• Учётные системы — карта денег, услуг, договорных обязательств.

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

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

В корпоративной навигации роль «графа дорог» выполняет семантический слой: словарь терминов, связи между объектами из разных систем, правила интерпретации событий. Например: «клиент» в CRM, «контрагент» в учётной системе и «заказчик» в проектном контуре — это один и тот же объект, и навигатор должен это знать.

Ответ без доказательств — не ответ.

Как устроен слой технически

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

Три принципа, которые определили архитектуру:

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

• Точечное применение ИИ. Языковая модель подключается только на двух этапах: семантический поиск и синтез ответа из нескольких источников. Всё остальное — детерминированные инструменты с предсказуемым результатом: SQL-запросы, regex-поиск по коду, API-вызовы.

• Проектирование от вопроса. Не «что мы можем подключить», а «что нужно проверить, чтобы ответить на этот конкретный вопрос этой конкретной роли».

На практике навигатор состоит из четырёх типов компонентов:

Каждый компонент решает ровно одну задачу — и ни один из них не является нейросетью. LLM подключается только на этапе синтеза ответа. Агент с tool-calling на каждом шаге выбирает нужный инструмент — поиск по коду, запрос к документации, доступ к данным или к задачам — в зависимости от типа запроса. Каждый факт в ответе сопровождается ссылкой на запись в системе-источнике, чтобы любую цифру можно открыть и проверить.

Кейс: починить уведомления за пять шагов

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

Навигатор выстраивает маршрут через три слоя, вот как это выглядит пошагово:

1. Определение модуля по симптому. «Не приходят уведомления» ведёт к подсистеме push-уведомлений, отвечающей за доставку нотификаций в браузер.

2. Документация. Бэкенд при новом сообщении определяет список получателей и отправляет им SignalR-событие с payload, в котором есть два списка — recipients и copyRecipients. Фронтенд у каждого получателя принимает событие, обрабатывает оба списка для корректной отрисовки уведомлений через Browser Notification API.

3. Код фронтенда. Объединение списков получателей сделано через spread-оператор JavaScript. Если один из списков приходит как null вместо пустого массива, spread-оператор выбрасывает TypeError: null не является iterable-значением, и выражение с разворачиванием падает. Ошибка тихая: интерфейс не ломается, но уведомление просто не появляется. Пользователь ничего не видит и не подозревает, что что-то пошло не так. Это объясняет часть случаев, но не все.

4. Код бэкенда и база данных. Навигатор находит вторую причину. В настройках push-уведомлений изначально было три режима: «не отправлять», «всегда» и «только когда офлайн». Со временем бэкенд перестал обрабатывать третий режим, но на фронтенде он по-прежнему существовал в перечислении типов, а у части пользователей в базе данных так и осталось это значение. Бэкенд получал неизвестный ему код и молча пропускал отправку.

5. Связь между слоями. Во фронтенде исходили из того, что список получателей всегда приходит в виде массива. Когда в одном из сценариев бэкенд вернул null, это ожидание нарушилось. Бэкенд-разработчик, убирая поддержку третьего режима уведомлений, не знал, что в базе остались пользователи с этой настройкой. Данные в базе — наследие старой логики — продолжали жить своей жизнью, невидимые ни серверу, ни клиенту. Три слоя — клиентский код, серверный код, данные — и ни один не видел проблему целиком.

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

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

Двойной цикл: как навигатор учится

Один из самых важных эффектов, который мы не планировали — это то, что произошло с документацией в ходе работы.

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

Это классический двойной цикл обратной связи:

• Первый цикл — корректируем ответы: нашли ошибку, исправили.

• Второй цикл — корректируем саму карту: обнаружили, что систематически теряем важный контекст, и меняем то, как фиксируем работу.

Дорожный навигатор обновляется автоматически через поведение автомобилей. Корпоративный — через осознанное участие людей. Это требует ритуала: регулярного разбора не только «правильно ли ответил навигатор», но и «достаточно ли полон цифровой след».

Почему это работает: три необходимых слоя

• Карта. Частотный анализ 1 500 тикетов заранее определил, что документировать в первую очередь, поэтому каждый документ отвечал на реальный вопрос. Итого было создано 900 документов.

• Инструменты. Ни один из инструментов набора не является «ИИ-продуктом» в привычном смысле. Языковая модель используется не как универсальный слой поверх всего, а только там, где без неё действительно теряется качество ответа. Всё остальное — детерминированные инструменты, потому что они надёжнее и предсказуемее.

• Правила. Мы зафиксировали шаблоны запросов, алгоритм разбора, формат постановки задачи и правила обновления документации. Без этого каждый разбор начинался бы с нуля, а с правилами маршрут становится воспроизводимым.

Карта + инструменты + правила = ответ с доказательствами. Убери любой из трёх — и навигатор перестаёт работать.

А это безопасно?

В связи с такой глубокой интеграцией ИИ в процессы возникают резонные вопросы: данные уйдут в облако? Кто ещё будет их видеть? Что будет, если мы захотим сменить языковую модель?

Отвечаем по порядку.

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

Видит каждый только своё: права доступа Картографа наследуются из существующих систем. Если сотрудник не имеет доступа к данным в CRM, он не получит их и через навигатор. Каждый запрос аудируется.

Модель можно заменить. Карта вашего бизнеса — словари терминов, связи между объектами, правила интерпретации, — остаётся у вас и не зависит от конкретного вендора. Это принципиальное архитектурное решение: знания о вашем бизнесе не должны быть заперты внутри модели.

Метод: как повторить у себя

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

• Выберите один поток создания ценности. Клиентский путь, закупка от заявки до поставки, инцидент от обращения до устранения. Чем уже граница — тем быстрее первый результат и тем проще понять, что именно работает.

• Соберите реальные вопросы, а не гипотезы. Не то, что «было бы полезно», а то, на что ваши люди тратят часы каждую неделю. Для каждого вопроса сразу зафиксируйте, какое действие должно следовать из ответа — иначе непонятно, по какому критерию оценивать результат.

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

• Опишите, как язык бизнеса соотносится с языком систем. «Клиент» в CRM, «контрагент» в учётной системе и «заказчик» в проектном контуре — это один и тот же объект, но навигатор должен явно знать об этом. Составьте словарь таких связей и зафиксируйте правила интерпретации ключевых событий: что значит «договор закрыт», что считается «просрочкой», с какого момента проект считается запущенным.

• И только после этого выбирайте инструменты. Не «внедряем ИИ», а «что здесь решает задачу оптимально по надёжности, скорости и стоимости». Языковая модель нужна там, где важна семантика и синтез из нескольких источников. Там, где достаточно точного поиска или SQL-запроса, — модель избыточна.

Что дальше

Кейс с разработкой — первый контур. Сейчас мы строим следующий: навигатор по клиентскому пути. Те же принципы, другая предметная область. Руководитель отдела продаж спрашивает: почему этот клиент подписал договор, но до сих пор не вышел на результат? Какие обещания давались на пресейле и что реально сделано? У кого из клиентов есть потенциал для допродажи?

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

Подход не требует замены существующих систем и не привязан к конкретной языковой модели. Он работает для любого стека: собственной платформы, ERP, Jira, Directum — можно связать все системы, в которых живут данные о процессах. Это возможно, потому что мы 25 лет проектируем системы автоматизации изнутри и понимаем, где в каждой из них искать нужный факт.

Рынок входит в фазу, когда «мы тоже делаем ИИ» перестаёт быть аргументом. Gartner, IBM и McKinsey фиксируют одно и то же: между моделью и реальным эффектом лежит не технология, а знание — контекст, схема понятий, навигация по цифровому следу. Компании, которые выстроят этот слой, получат не очередной ИИ-проект, а инфраструктуру для принятия решений, которая становится точнее с каждым новым вопросом.

Начните с одного вопроса, на который ваши люди тратят часы каждую неделю. Скорее всего, ответ уже есть в данных. Просто до него пока нет маршрута.