Сначала водопровод, потом «умный» дом: почему бизнесу не удается масштабировать ИИ без порядка в данных

Особенно остро вопрос стоит перед компаниями, работающими с критической информационной инфраструктурой. По оценке «К2Тех», только 20% субъектов КИИ обладают достаточным уровнем зрелости данных и процессов управления ими. Еще 55% потребуется доработка существующих систем и подходов, а 25% — их существенная трансформация. Исследование основано на более чем 80 предпроектных обследованиях и аудитах, а также опросе 150 представителей компаний — субъектов КИИ. Это данные одного исследования, и переносить их на весь российский бизнес нельзя. Но они хорошо показывают масштаб накопленного долга в крупных организациях со сложным ИТ-ландшафтом. Компании начали внедрять ИИ раньше, чем разобрались с данными, на которых он должен работать.

По данным глобального исследования McKinsey, 88% респондентов сообщили, что их организации регулярно используют ИИ хотя бы в одной бизнес-функции. При этом масштабировать ИИ-программы на уровень всей компании смогли только около трети. Похожий разрыв показывает IBM CEO Study 2025, в котором участвовали 2000 руководителей из 33 стран и 24 отраслей. По оценкам опрошенных, ожидаемую отдачу принесли только 25% ИИ-инициатив, а в масштабе всей организации были развернуты 16%. Половина респондентов признала, что быстрые инвестиции в технологии привели к появлению разрозненных, плохо связанных между собой решений.

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

Управление данными (data governance) можно сравнить с водопроводом, отоплением и канализацией в доме. Это критические системы: они требуют точного проектирования, не терпят ошибок и почти всегда остаются «в фоне». Заказчики охотнее обсуждают фасад, интерьер, места вывода розеток и технологии «умного» дома. Инженерные коммуникации начинают интересовать их только тогда, когда происходит авария или розетка оказывается в неудобном месте и до нее нужно тянуть удлинитель. Ситуация с корпоративными данными долгое время было такой же. Пока сотрудники вручную компенсировали ошибки и нестыковки, руководство могло не замечать реального состояния ИТ-архитектуры и процессов. Отчет в итоге собирался, договор находился, заявка попадала нужному специалисту — значит, формально процесс работал.

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

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

Согласно исследованию «К2Тех», только у 20,3% респондентов массивы данных полностью готовы и размечены для работы алгоритмов. В 42,6% организаций они требуют очистки или консолидации, а четверть участников назвала низкое качество данных главным препятствием для реализации ИИ-проектов. Здесь легко обвинить саму технологию: слишком требовательная, слишком капризная, не способная работать с реальной корпоративной информацией. Но ИИ ничего не сломал. Он просто показал состояние данных с рентгеновской четкостью.

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

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

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

Данные могут быть технически безупречными и при этом направлять модель к неверному решению. Один из наиболее известных примеров описан в исследовании, опубликованном в журнале Science.

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

После замены показателя доля темнокожих пациентов, которые должны были получать дополнительную помощь, увеличилась с 17,7 до 46,5%. В исходных таблицах не было технической ошибки. Неверным оказался смысл показателя, выбранного в качестве основания для решения. Это пример работы не генеративного ИИ, а классического прогнозного алгоритма. Но он хорошо показывает общий принцип: качество данных нельзя свести к отсутствию пустых полей и дублей. Нужно понимать, что именно измеряет показатель и соответствует ли он той задаче, которую бизнес передает системе. Поэтому управление данными нельзя отдавать исключительно ИТ-подразделению. Только бизнес способен определить, что означает конкретный показатель, какое решение принимается на его основании и к чему приведет ошибка.

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

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

Показателен опыт Morgan Stanley. Банк не ограничился подключением языковой модели к корпоративным документам. Для каждого сценария использования была создана система оценки качества, ответы проверялись специалистами, а изменения регулярно тестировались на контрольном наборе вопросов. По данным Morgan Stanley, внутренним ИИ-помощником стали пользоваться 98% команд финансовых консультантов. В кейсе OpenAI указано, что система работает с массивом из 100 тыс. документов. Для проверки качества применяются экспертная оценка ответов, отдельные тестовые наборы и ежедневные регрессионные тесты. В процессах, связанных с клиентскими коммуникациями, консультант проверяет и при необходимости редактирует подготовленный ИИ материал.

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

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

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

После этого формируется контрольный набор реальных примеров, на котором можно проверить работу решения. Заранее устанавливаются допустимый уровень ошибки, случаи обязательной проверки человеком и порядок исправления обнаруженных проблем. Только после этого пилот имеет смысл масштабировать. Так появляется минимально необходимый контур управления данными для конкретной задачи. Компания не получает идеальные данные раз и навсегда — это в принципе невозможно. Зато она понимает, какие сведения использует ИИ, кто за них отвечает и почему результату можно доверять. Именно это отличает эффектную демонстрацию от промышленной системы. Пользователь видит удобный интерфейс и быстрый ответ модели. Но надежность решения создается гораздо раньше — в правилах, справочниках, версиях, правах доступа и ежедневной работе людей, отвечающих за данные. «Умный» дом начинается не с датчиков и голосового помощника. Он начинается с того, что за стеной правильно проложены трубы.