DataGov 2.0: куда смотреть, чтобы ИИ-агенты не сожгли ваш бюджет

Искусственный интеллект стал неотъемлемой частью нашей жизни и в том или ином виде внедряется практически в любой крупной компании. Все это порождает новые объекты управления, которые уже не укладываются в классический DataGov. Поэтому DataGov 2.0 — это эволюционное развитие. Data Governance остается фундаментом, но к нему добавляются Model Governance, AI Risk Management и слой, который поставляет AI-ready данные в ИИ-системы.

Меня зовут Екатерина Яковлева, я руковожу центром DataGov группы компаний МТС. Сегодня поговорим о том, как поменялись привычные подходы в DataGov и что с этим делать. На основе моего опыта внутри MWS разберем, как понять, какие ИИ-инструменты уже живут в компании, сколько стоит один запрос, что можно смело отдать агентам, а что лучше оставить за человеком.

DataGov 1.0 больше не закрывает задачи

Data Governance версии 1.0 — это управление данными как активами. У всех данных есть владельцы, описание, классификация, определены качество и жизненный цикл. Если в методике DataGov 1.0 мы собирали реестр data-объектов, следили за исполнением стандартов и помогали превращать разрозненные данные в данные, которым можно доверять, то с приходом ИИ требования расширяются: DataGov 2.0 — это еще и управление ИИ-активами, то есть моделями, промптами, агентами, RAG-корпусами, эмбеддингами, векторными индексами, а еще контроль стоимости работы с ИИ.

Раньше все было просто. Data Asset — это данные, которые имеют ценность для бизнеса.

В классическом пайплайне с данными мы брали их, заносили в каталог, размечали по категориям и выстраивали Data lineage. Сразу становилось видно, где что сломалось и почему, а на выходе мы получали качественные Data products. DataGov 1.0 как раз и отвечал за то, как все это устроено: как описать таблицы и поля, назначить владельцев, следить за качеством, управлять доступом и понимать, сколько данные живут.

Но с появлением ИИ возникли новые активы — AI Assets.

Здесь нужен другой пайплайн. Сначала работаем с машинными данными: терминами, связями, правилами, контекстом. А уже на этой основе действуют RAG, ML и ИИ-агенты. Ищем подходящие куски, а потом подкладываем их в LLM. Так модель не придумывает ответы, а формирует их по данным из источников. ИИ-агент из обычной модели превращается в активную систему. Она умеет вызывать инструменты, API и что-то делать по факту. А дальше все встраивается в бизнес-процессы компании. И замыкает картину мониторинг: следим за качеством, рисками, расходами и тем, реально ли мы получили эффект, ради которого все затевалось.

И тут вдруг выясняется, что объекты управления у нас изменились. Раньше мы в основном работали с data assets. Теперь надо управлять моделями и их версиями, промптами, эмбеддингами и векторными индексами. А еще RAG-корпусами, ИИ-агентами и доступными им инструментами, датасетами для обучения и тестирования, синтетическими данными, логами запросов и ответов, оценками качества и даже стоимостью работы ИИ. У всех этих новых сущностей должны быть владельцы, жизненный цикл, контроль доступа, качество, стоимость и риски. Поэтому на сцену выходит DataGov 2.0, который включает в себя DataGov 1.0, Model Governance, AI Risk Management и семантический слой. DataGov при этом остается основой.

Главные задачи AI Gov

Так для чего же нужен DataGov 2.0?

Если совсем коротко, то для решения этих трех главных задач: 

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

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

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

Ландшафт применения ИИ внутри компании

Для начала нужно увидеть ландшафт. Звучит легко, но на деле все сложнее: большинство компаний не могут ответить даже на базовый вопрос — сколько у них ИИ-кейсов и кто за них отвечает. Один собрал чат-бота, другой прикрутил LLM к внутреннему поиску, третий купил SaaS с ИИ-функциями, а четвертый просто болтает с DeepSeek в рабочем ноутбуке. И пока все это не сведено в отдельный реестр, управлять этим попросту не выйдет. 

Я собрала главное, что помогает провести аудит применения ИИ в компании.

Первое — разработка и инфраструктура. Смотрим репозитории, где мелькают LLM, RAG, embedding, prompt, agent, плюс ML-сервисы и пайплайны деплоя. Облака: OpenAI API, ML-платформы, notebook-среды, GPU-кластеры, inference endpoints.

Второе — деньги. Договоры с AI/SaaS-провайдерами, лицензии, счета за API, GPU и специализированные платформы. Часто именно здесь всплывают кейсы, о которых никто в компании не помнит.

Третье — безопасность и данные. DLP-события, обращения к внешним AI-сервисам, секреты и API-ключи, сетевые запросы к LLM-провайдерам. Рядом — датасеты, эмбеддинги, векторные индексы.

Четвертое — люди и процессы. Кто прошел AI-обучение, кто внутри компании стал AI-чемпионом, какие заявки на пилоты подавали. Плюс бизнес-процессы: автоматизация решений, прогнозирование, рекомендации, классификация, генерация контента.

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

Многие компании уже ведут такие реестры. Например, Unilever совместно с Holistic AI создали AI inventory и процесс AI risk management, чтобы отслеживать системы, технологии, затраты и документацию. Chevron вместе с Responsible AI Institute выпустили мануал, как вести учет ИИ-систем и управлять связанными с ними рисками. IBM тоже не отстает, ведь с реестром можно назначить ответственного и вести всю систему по одним правилам от начала и до конца. 

А компании уровня FAANG, основные из которых Amazon, Netflix, Google, вообще формируют реестр «на лету»: у них есть Model Registry, граф метаданных, централизованное управление жизненным циклом моделей. Это позволяет переиспользовать артефакты, быстрее разбираться с инцидентами и не создавать дубли.

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

Как описать ИИ-кейс и управлять полномочиями агента

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

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

Снизить стоимость применения ИИ

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

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

Повысить качество ответов и решений ИИ

Третья задача governance в ИИ — качество, и здесь мы обычно видим одну и ту же картину. Команда собрала RAG, взяла самую большую модель, настроила гибридный поиск, а пользователи все равно остаются недовольными. Почему? Да потому что качество толком не оценивают. Без набора данных для оценки вы не понимаете, где именно проседает система: на поиске документов, на генерации ответа или на отказе.

При разработке набора данных для оценки RAG мы рекомендуем такой подход. Сначала выбрать один повторяющийся аналитический вопрос. Потом собрать 30 реальных примеров запросов. Для каждого указать ожидаемый ответ и источник, откуда система должна была его взять. Отдельно добавить негативные случаи: данных недостаточно, доступ запрещен, версии ответа конфликтуют. И только после этого измерять ключевые метрики. 

Теперь про метрики. Часто команды смотрят только на финальный ответ, ну максимум еще на recall и precision. Этого мало, RAG надо оценивать на каждом этапе.

Документы: актуальность, дубли, владельцы, доступ. Плюс границы фрагментов, заголовки, даты, продукт, права.

Поиск: точность попадания, полнота охвата, доля успешных находок и отсечение того, к чему нет доступа.

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

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

Шаги внедрения ИИ-Governance в компании

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

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

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

Финальный этап — встраивание в платформу. Здесь мы автоматизируем проверки качества, чтобы они срабатывали сами, а не по напоминанию. Вводим policy-as-code, чтобы они жили не в документах, а в коде, настраиваем журналирование промптов, моделей и происхождения данных. Мониторим качество, стоимость и риски, формируем стандартный путь от идеи до production, чтобы команды не изобретали велосипед. И, конечно, обучаем персонал, имеющий дело с ИИ в работе.

Главный принцип здесь такой: стандарты должны быть встроены в delivery и дата-процессы, а не лежать в документации. Если правило нельзя проверить автоматически или оно не встроено в пайплайн, оно не работает. Ручные реестры рано или поздно нужно менять на автоматические проверки качества и policy-as-code. Пусть это занимает много времени на старте, зато governance потом становится частью системы, а не отдельной функцией, которая всех раздражает. 

Основные выводы

Подытожу сказанное.

1. ИИ-объекты стали частью DataGov со всеми вытекающими последствиями.

2. Экономику кейса считаем на старте, а не когда бюджет уже начал пропадать.

3. Без набора данных для оценки вы не узнаете, что чинить. И оценивать нужно каждый этап пайплайна, а не только финальный ответ.

4. На вход в ИИ — данные, готовые к работе с ИИ. За счет них точность RAG растет примерно с 40% до 95%.

5. У каждого кейса есть паспорт системы. У агента минимум прав: разрешено, разрешено с валидацией, запрещено.

6. Правила governance живут в пайплайне, а не в документе.

Мы прошли большой путь от новых объектов управления до конкретных шагов по организации governance в ИИ-кейсах. DataGov потихоньку становится центром управления ИИ-активами. Раньше мы управляли таблицами, справочниками и дата-продуктами, а теперь рядом с ними встали модели, промпты, агенты, RAG-корпуса, эмбеддинги, векторные индексы, наборы данных для оценки и стоимость вычислений. 

С чего начать? Не пытайтесь объять необъятное, начните с реестра ИИ-кейсов. А если у вас остались вопросы, пишите их в комментариях, постараюсь на все ответить!