Разбираемся, какие AI-показатели действительно отражают эффективность | Автор: Марина Погодина
Метрики искусственного интеллекта звучат скучно до тех пор, пока не прилетает первый запрос от Роскомнадзора или не падает прод — и ты внезапно понимаешь, что количество подписчиков в чат-боте и красивый график MAU никого не волнуют. Метрики искусственного интеллекта в России сегодня — это не про «о, у нас 10 тысяч диалогов в неделю», а про то, насколько точно модель отвечает, сколько минут она реально экономит людям и можно ли потом спокойно спать, зная, что 152-ФЗ не висит над головой, как бетонная плита. Особенно, если вы подключаете ИИ к персональным данным: рекрутмент, продажи, сопровождение клиентов, внутрикорпоративные сервисы.
Я пишу в первую очередь для российских специалистов — тех, кто строит чат-ботов, ИИ-агентов, интеграции в n8n и Make, для продактов, айтишников и людей из комплаенса, которых внезапно сделали «ответственными за ПДн». Мы поговорим о том, какие метрики ИИ реально имеют смысл в российских реалиях, какие цифры обожают инвесторы, но от которых нет толку, и как собрать систему, где метрики не противоречат 152-ФЗ и требованиям к локализации. И, да, подписчики и «охваты» будут, но на своём, очень скромном месте.
Чтобы было не слишком абстрактно, давай познакомлю: есть у меня одна знакомая, Настя, продакт в небольшой российской EdTech-компании. Настя запустила умного чат-бота для поддержки студентов, и буквально за месяц похвасталась: «Смотри, 18 тысяч диалогов, у нас там вообще огонь». Я кивнула, спросила, какие у них метрики качества, сколько времени экономят тьюторам и как они учитывают обработку ПДн студентов. Настя помолчала, глотнула кофе и сказала: «Ну, пока смотрим только на количество чатов и новых пользователей, но потом добавим остальное». В этой статье я покажу, как Настя аккуратно выбралась из этой метриковой ловушки и почему эти 18 тысяч диалогов оказались не главным успехом, а просто фоном.
Зачем вообще мерить ИИ и почему подписчики мало что говорят
Что не так с цифрой «подписчики бота» и «пользователи модели»?
Я заметила, что первая метрика, к которой тянется рука, когда появляется новый ИИ-сервис, — это количество пользователей, диалогов, сессий, подписчиков в Telegram-боте. Это удобно, быстро, кажется чем-то понятным, и можно красиво показать на слайде руководству. Но в реальности для оценки эффективности AI-систем, особенно если вы работаете в России и обрабатываете персональные данные, эти цифры почти ничего не говорят о пользе и очень мало — о рисках. Представь себе чат-бот, который собрал 10 тысяч e-mail без нормального согласия по 152-ФЗ: снаружи выглядит как рост, внутри это скорее бомба замедленного действия, потому что одно обращение в Роскомнадзор может превратить эти «подписки» в строку штрафа.
Вот как это выглядит на практике: бизнес инвестирует время и деньги в интеграции, подключает n8n или Make, связывает форму на сайте, бота в Telegram, CRM и модель распознавания текста. Отчитываются: «У нас в воронке уже 5 тысяч лидов, это же супер». А потом выясняется, что в политике конфиденциальности «обработка персональных данных» есть, а отдельного, явно выраженного согласия на обработку для конкретной цели — нет. В такой конфигурации метрика «подписчики» превращается в метрику «потенциальные заявители с жалобой». Это критично, потому что штрафы за нарушения по ч.2 ст.13.11 КоАП измеряются миллионами, и этот риск не отражён ни в одном стандартном дашборде продукта.
Для полноты картины я обычно добавляю ещё один слой: бизнесу важны деньги и время, регулятору — законность, пользователям — качество и удобство. Количество подписчиков довольно слабо связано с первым (если не считать очень простые воронки), почти не связано со вторым и только частично — с третьим. Получается, что мы смотрим на метрику, которая не отвечает ни за одну ключевую цель, зато удобна для красивых презентаций. Это означает, что если ваша основная цифра в отчете — «подписчики», вы, скорее всего, недомеряете всё интересное и переоцениваете то, что легко растёт.
Здесь помогает простая ментальная проверка: что изменится в бизнесе, если подписчиков станет вдвое больше? Часто ответ такой: нагрузка на ИИ увеличится, косты на инфраструктуру подрастут, риски по ПДн вырастут, а реальная выручка или эффективность останутся примерно прежними. И наоборот: если количество «подписчиков» уменьшится, но вы поднимете качество ответов и снизите среднее время обработки запросов, пользователям станет проще, а бизнесу дешевле. Странно фокусироваться на метрике, которая в прямом виде не отражает ни ценность, ни риски (но мы упорно так делаем годами).
Чтобы не остаться совсем без цифр, я не предлагаю выкидывать подписчиков из отчётов, но отношусь к ним как к «фоновой статистике»: да, полезно знать, насколько система загружена, как она масштабируется, но судить о её ценности по этим цифрам — примерно как оценивать ресторан по количеству выданных меню, а не по тому, доели ли люди свои блюда. Для ИИ в российских реалиях, особенно работающего с персональными данными, полезнее сразу двигаться в сторону метрик качества, эффективности и комплаенса.
Перед тем как двинуться дальше, зафиксирую простой тезис: метрика «подписчики/пользователи» сама по себе ничего не говорит о том, насколько хорошо работает ваш ИИ и насколько безопасно он встроен в контур ПДн. Она может быть удобным индикатором нагрузки, но не должна быть главной звездой дашборда. Это означает, что наш фокус нужно сместить на другие цифры — и как раз их мы сейчас разложим по полочкам.
Чтобы визуально заякорить это смещение фокуса, я люблю выделять в заметках короткую фразу: подписчики — это шум, качество и риск — сигнал.
Как связать цели бизнеса, закона и пользователей в одной системе показателей
Когда я первый раз столкнулась с задачей «давай придумаем метрики для нашего ИИ-сервиса», разговор быстро превратился в спор: одни тянулись к продуктовым метрикам (retention, NPS, MAU), вторые — к техническим (latency, uptime, количество запросов), третьи — к юридическим («чтобы не было штрафов», формулировку я не придумала). Попытка впихнуть всё в один список привела к хаосу, пока мы не сели и не нарисовали на доске три столбца: бизнес, пользователь, регулятор. В каждый столбец начали выписывать, что для них на самом деле успех. Оказалось, что все трое говорят про один и тот же ИИ, но видят три совершенно разные реальности.
Если держать в голове только одну из этих реальностей, метрики получаются кривыми. Например, чисто бизнесовый взгляд даёт фокус на ROI, конверсию, выручку и снижение затрат, но совершенно теряется вопрос: а законно ли то, что мы делаем с данными? Чисто юридический подход порождает тонны документов и галочек, но работы с качеством моделей там минимум, потому что юристам часто достаточно того, что всё хранится в РФ, есть согласие и модель угроз по ФСТЭК, а как именно ИИ классифицирует тикеты поддержки — уже третий план. Пользовательский взгляд, наоборот, упирается в удобство, скорость и полезность ответов, и там борьба идёт за секунды и проценты точности.
Вот как это выглядит на практике: я часто спрашиваю команду, которая внедряет ИИ в поддержке, три очень приземлённых вопроса. Первое: «Сколько времени вы экономите оператору на одном обращении?» Второе: «Насколько снизилось среднее время реакции для клиента?» Третье: «Где у вас зафиксировано согласие на обработку ПДн и как устроена локализация хранения?» Иногда ответы стройные, иногда — очень рваные (нет, подожди, есть нюанс: учет согласий «где-то в CRM», которая физически находится за границей, перестал быть вариантом). И каждый раз становится видно, что баланс между тремя столбцами даёт куда более устойчивую картинку, чем попытка померить «любой ценой рост пользователей».
Это означает, что перед выбором конкретных цифр для отслеживания, полезно честно ответить себе: какую задачу решает ИИ-система в этом процессе, какие данные она использует, кто несёт ответственность за инциденты и как мы это покажем цифрами. Проще всего начать с трёх наборов показателей: для бизнеса — экономия времени и денег, для пользователя — качество и скорость, для комплаенса — количество инцидентов и полнота закрытия требований 152-ФЗ. Все остальное уже надстраивается сверху как детализация.
Чтобы зафиксировать это в голове, удобно проговорить одну фразу вслух: любая метрика ИИ должна объяснять, как она влияет хотя бы на один из трёх слоёв — деньги, опыт пользователя, законность. Если она не привязана ни к одному из них, скорее всего, это просто красивая, но бессмысленная картинка. Дальше мы перейдем к более предметным цифрам и тому, как они выглядят в реальных проектах.
Какие вопросы к цифрам ИИ стоит задать в первую очередь
Прежде чем рисовать сложные дашборды, я обычно предлагаю команде короткий чек-ин: несколько прямых вопросов, которые вылавливают слабые места в логике измерений. Здесь работает формат «представь себе ситуацию»: у вас уже есть AI-агент, он подключён к рабочим процессам (поддержка, продажи, HR), люди им пользуются, а вы хотите понять, хорошо ли он работает. Что вы спросите у системы в первую очередь? Не «сколько подписчиков», а «насколько он точен», «как он ускоряет обработку», «какие риски он добавляет».
Вот как это звучит в реальности: руководитель поддержки говорит «У нас ИИ закрывает 40% обращений без оператора», а я спрашиваю: «А какая у вас доля ошибочных ответов, которые все равно попадают к человеку, только через 15 минут и с раздражением клиента?» И тут начинается поиск: а у нас нет единой метрики ошибок, мы не размечаем такие кейсы, операторы правят ответы вручную, но это нигде не фиксируется. В этот момент обнаруживается, что метрики ИИ ограничиваются технической статистикой и подсчётом диалогов, а качество и риск остаются на уровне ощущения.
Это как с Настиным ботом для студентов: 18 тысяч диалогов выглядят красиво, пока не задаешь вопрос: «Сколько из них пришлось переспросить у человека, потому что бот ответил некорректно?» И второй: «Как вы учитываете обращения, где студент пишет свои контакты и личные данные?» Когда ответы расползаются, становится понятно, что над метриками ещё работать и работать, а подписчики здесь вообще не при чём. Чтобы не зависнуть в абстракциях, дальше мы перейдем к конкретной структуре полезных метрик для ИИ-систем.
Прежде чем двигаться в сторону конкретных чисел, зафиксируем мысль на полях в виде небольшой цитаты, чтобы мозг зацепился:
Метрики ИИ, которые начинаются и заканчиваются на «подписчики» и «количество диалогов», — это как смотреть на ледяную гору только по снежинкам на поверхности: красиво, но очень мало информации про то, что происходит под водой.
Какие метрики ИИ действительно имеют смысл в российском бизнесе
Как измерять качество работы модели без академических учебников
Когда люди слышат «метрики качества ИИ», они вспоминают про precision, recall, F1, ROC-AUC и прочие академические чудеса, которые неплохо смотрятся в статьях, но плохо живут в реальных компаниях, где у HR нет времени вспоминать, что там такое «полнота». В реальности я чаще всего вижу другой подход: либо метрик качества почти нет, либо есть один суррогат — «количество решённых задач», и к нему привязывают всё подряд. Для российских компаний, особенно работающих с ПДн, гораздо полезнее делать гибрид: взять 1-2 классические метрики и рядом положить понятные бизнесу показатели.
Вот как это выглядит на практике: если у вас AI-классификатор обращений в поддержку, можно честно померить долю правильных классификаций (это и есть по сути accuracy), но объяснять команде я обычно не через формулы, а через фразу: «Из 100 обращений бот угадал тему в 92 случаях». Дальше добавляем ещё одну плоскость: «И в скольки из этих 92 случаев клиент не вернулся с переспросом?» Здесь появляется пользовательская оценка качества, и она иногда сильно отличается от сухих процентов. В российских реалиях я добавляю ещё одну метрику — «доля обращений с ПДн, обработанных без ручного вмешательства», чтобы удерживать зону риска под контролем (хотя сама я так формализую далеко не каждый проект, честно).
Если говорить об ИИ-агентах, которые собирают и обрабатывают персональные данные, туда хорошо ложится связка: «точность» + «устойчивость к странным вводам» + «наличие фильтра по ПДн». Иначе говоря, насколько модель аккуратна не только с фактами, но и с тем, что именно она записывает, спрашивает и отправляет дальше по интеграциям. Качество тут — не только про правильный ответ, но и про корректный сценарий обработки данных. Это означает, что я отдельно бы замеряла, сколько сессий ушло в ручную проверку из-за сомнений модели или триггеров по ПДн, и как эта доля меняется во времени.
Для людей, которые не любят формулы, работает один маленький трюк: объяснить, что у метрики качества всегда есть «допустимая зона» и «красная зона». Например, если у вас 90% корректных ответов, но «красные» 10% приходятся на кейсы с финансовыми или медицинскими данными, лид по продукту вряд ли будет счастлив. Наоборот, 85% общей точности, но почти ноль критических ошибок в чувствительных сценариях могут быть вполне комфортными. Я поняла, что здесь важно не гнаться за абстрактным «чем выше, тем лучше», а проговорить приоритизацию зон риска.
Чтобы это не растворилось в разговоре, я обычно оставляю себе пометку в документации проекта с простой фразой: качество ИИ — это не только проценты, но и распределение ошибок по рискам. Именно оно потом спасает от неприятных сюрпризов, когда регулятор или клиент спрашивает: «А как вы контролируете, что модель не делает опасных вещей?».
Как скорость и экономия времени превращаются в внятные метрики
Второй блок, без которого метрики искусственного интеллекта в бизнесе превращаются в сборник теорий, — это измерение времени. Не абстрактного «ускорили», а вполне конкретного: сколько минут и часов экономится за счёт ИИ и сколько эта экономия стоит. В российской реальности это ещё и вопрос организационных привычек: далеко не у всех компаний есть культура замера времени до и после изменений. Но если её аккуратно построить, метрики сами начинают вываливаться в внятные формулы.
Представь рекрутмент: без ИИ рекрутер тратит 5 минут на первичный просмотр одного резюме, у него 100 резюме в день, это 500 минут, почти целый рабочий день. С AI-фильтром, который отбрасывает заведомо неподходящие заявки и подсвечивает «тёплых» кандидатов, рекрутер реально смотрит только 40 резюме и тратит по 3 минуты. Время падает до 120 минут, выгода в три с лишним часа в день. Дальше это умножается на количество рекрутеров и на их ставку, и выходят вполне конкретные рубли. Это и есть тот самый ROI от внедрения ИИ, который всех волнует, только выраженный через очень бытовую метрику.
Аналогичный подход прекрасно ложится на автоматизацию журналов, инструктажей и прочей документальной рутины по ПДн. Когда мы внедряли автоматизацию журналов проверок с помощью российской платформы, вроде QForm, iспользуя формы вместо Excel, количество ручных действий сократилось настолько, что вместо 11 проверок в год с кучей бумаги появилась модель «постоянного трекинга» в системе. Метрика там выглядела почти смешно: «время на подготовку к проверке Роскомнадзора» до и после. Дни превратились в часы, а это уже история не про подписчиков, а про сохранённые нервы конкретных людей.
Чтобы такую экономию системно увидеть, полезно зафиксировать начальные значения: сколько в среднем времени занимает ручной процесс сейчас, сколько шагов в нём участвуют, какие роли тратят на это часы. Это скучно, но без этого сложно потом показать эффект от ИИ. Здесь работает следующая мысль: экономия времени — это не ощущение, это разница между «было» и «стало» в минутах и шагах процесса. Странно, но многие забывают сделать этот замер до запуска, а потом приходится восстанавливать «как было» по памяти, и цифры уже не такие убедительные.
В моих записях по проектам есть одна фраза, которую я обвожу кружком каждый раз, когда речь заходит про ROI: если вы не меряете время, вы не сможете честно посчитать окупаемость ИИ. Красивые графики «роста пользователей» этого не заменят, сколько бы нулей там не было.
Как встроить метрики комплаенса по 152-ФЗ в общую картину
Третий уровень, который редко попадает на красивые дашборды, но очень интересует руководство и юристов, — это метрики комплаенса: насколько наш ИИ безопасен для ПДн и как мы можем это показать цифрами. В России после ужесточения требований к локализации данные граждан РФ должны храниться и обрабатываться на российских серверах, а любые «гугл-формы» и зарубежные CRM в качестве первичной точки сбора внезапно превратились в риск не только юридический, но и репутационный. Плюс Роскомнадзор начал автоматический мониторинг сайтов на зарубежные скрипты и неправильные cookie, так что игра «авось не заметят» стала плохой стратегией.
Я на практике заметила, что здесь полезнее всего завести несколько очень простых метрик, даже если они сначала живут в Excel или в QForm/PrivacyLine. Например: «количество процессов, где используется ИИ и обрабатываются ПДн», «доля таких процессов, по которым оформлено уведомление в Роскомнадзор», «количество инцидентов или потенциальных инцидентов за период», «наличие и актуальность модели угроз и мер защиты по ФСТЭК». Эти цифры звучат немного канцелярски, но именно они показывают, насколько ИИ встроен в контур ПДн по-взрослому, а не «как получится».
Чтобы не превращать это в бюрократический лагерь, я люблю добавлять человеческий ракурс: «сколько времени DPO (или ответственный за ПДн) тратит в месяц на сбор реестров и подготовку к проверкам». Если внедряется система класса PrivacyLine, где все процессы, системы и хранилища описаны в одном окне, метрика времени уходит вниз в разы. И вот это уже понятная цифра для бизнеса: вместо разрозненных файлов мы видим структурированную картину, и ИИ-интеграции попадают туда как отдельная строка с понятными атрибутами.
Звучит сухо, но это критично потому, что без таких метрик ИИ-проекты часто существуют «сами по себе», а ПДн живут «сами по себе», и в какой-то момент они сталкиваются. Лучше, когда они изначально лежат в одной таблице. Я для себя формулирую это так: метрики ИИ без метрик комплаенса по ПДн в России — половина картины и чаще всего не та половина, которая интересует регулятора. Бизнесу спокойнее, когда на этот вопрос есть не только «мы всё учли», но и конкретные единички в таблице.
Чтобы связать всё в одно предложение, я иногда проговариваю такую фразу вслух, когда оформляю документацию проекта, и это помогает команде поймать общий фокус: качественный ИИ в российской компании — это не только точность и скорость, но и отсутствие звонков из Роскомнадзора. В цифрах это выглядит менее романтично, но зато даёт руководству ощущение контроля, а это дорогого стоит.
Как связать метрики ИИ с реальными процессами, а не с презентациями
Как описать процесс, чтобы из него сами вылезли метрики
Когда мы обсуждаем метрики искусственного интеллекта, часто кажется, что речь идёт про абстрактные числа, которые где-то живут сами по себе. На практике всё сильно проще и сложнее одновременно: если честно описать процесс «как он есть», метрики вылезают почти автоматически. Я люблю начинать с очень приземлённой визуализации: нарисовать на доске или в Miro путь одного запроса — от момента, когда пользователь что-то вводит, до того момента, когда процесс завершается и данные оседают где-то в системе. В этот момент становится видно, где ИИ действительно влияет на результат, а где просто «красивый слой между формой и CRM».
Вот как это выглядит: возьмём Настин кейс со студенческим ботом. Пользователь пишет вопрос, бот его принимает, прогоняет через модель, выдает ответ, иногда поднимает запрос на оператора, иногда собирает дополнительные данные (ФИО, номер договора, контактный телефон), иногда открывает тикет в системе. Если мы раскладываем это по шагам, у нас получается цепочка: входящий запрос — обработка моделью — принятие решения (ответить самому или передать человеку) — сбор ПДн (если он есть) — запись в систему. В каждом звене цепочки можно задать по одному-двум вопросам, и на них уже можно навесить метрики.
Например, «что происходит на шаге отвечания самому»: сколько ответов остаётся без повторного вопроса, сколько возвращается с ремаркой «вы не поняли», сколько уходит на оператора. На шаге сбора ПДн можно замерить процент сессий, где бот запросил лишние данные, или процент сессий, где согласие на обработку ПДн явно зафиксировано. Так, шаг за шагом, из простой диаграммы получается вполне полноценная схема метрик. Это звучит громоздко, но после первого раза уже не так страшно.
Помнишь мой холодный кофе из начала (в смысле момент, когда Настя кивала и говорила «потом добавим»)? Когда мы сели с ней и прогнали процесс их бота через такую цепочку, выяснилось, что у них метрики есть только на входе и выходе: количество диалогов и количество тикетов в системе. Всё, что происходило между, жило в слепой зоне. Самое болезненное оказалось даже не качество ответов, а отсутствие логики по ПДн: бот собирал данные «на всякий случай», без чёткого разграничения, что действительно нужно для ответа, а что нельзя просить без отдельного согласия. После визуализации процесса стало гораздо проще понять, где и какие цифры нужно завести.
Чтобы заякорить этот момент, я обычно подсвечиваю одно короткое наблюдение: метрики процесса ИИ рождаются не из отчетов, а из честного описания пути одного запроса. Без этого легко уйти в красивые, но бессмысленные числа.
Как автоматизация через n8n и Make помогает «поймать» нужные цифры
Когда процессы описаны, следующий шаг — понять, где брать сами данные для метрик. Зачастую они уже есть, просто живут в логах, в CRM, в чатах и в разных сервисах. Здесь на сцену выходят любимые интеграционные платформы: n8n, Make и им подобные, которые позволяют не только автоматизировать действия, но и аккуратно «поднимать» нужные цифры. В российской реальности это ещё и способ соблюсти требования локализации: можно выстроить схему, где все ПДн хранятся в российских системах, а за рубеж при необходимости уходит только обезличенная аналитика.
Вот как это выглядит на практике: у нас есть бот, который работает в Telegram, он пишет события в лог, а по webhook они попадают в n8n. Там мы берём каждое событие (новый диалог, ответ бота, пересылка оператору), добавляем к нему признаки — была ли в нём обработка ПДн, был ли ответ успешным, сколько времени заняло взаимодействие, — и отправляем это уже в аналитическую базу, например, на российский сервер или в локализованную BI-систему. n8n в этом смысле действует как конструктор, который помогает превратить сырые события в структурированные записи, по которым потом строятся дашборды.
В Make логика та же, только коннекторы и интерфейс другие. Главное, что я в этих историях ценю: возможность вешать условия и фильтры. Например, можно задать правило «если в сообщении есть номер телефона, то фиксировать флаг ‘ПДн’, а текст для аналитики обезличивать». Или «если ответ бота был скорректирован оператором, то записать это как отдельный тип события». Это не только про качество, но и про комплаенс: мы явно видим, сколько у нас сессий с ПДн и как они живут в системе.
Иногда напоминаю себе, что звучит всё это слегка технократично, но это критично, потому что без такой прослойки интеграций метрики либо остаются на уровне «на глазок», либо собираются вручную человеком, что в долгую плохо масштабируется. Я поняла, что чем раньше мы подключаем интеграционный слой в проект с ИИ, тем проще потом разговаривать о цифрах без споров «а у меня по-другому посчиталось». Чтобы не превратить это в религию, люблю фиксировать короткую мысль: интеграция — это не только автоматизация действий, но и автоматизация измерений.
Перед тем как уйти в следующий блок, оставлю небольшую цитату, которая неплохо отражает суть связки «ИИ + интеграции + метрики»:
Если ваш ИИ что-то делает, но вы не можете сказать, сколько времени, ошибок и рисков он добавил или убрал, значит, он живёт отдельно от вашей управляемой реальности.
Чем помогают отраслевые примеры: рекрутмент, поддержка, внутренние сервисы
На этом этапе часто звучит вопрос: «Ну хорошо, а как это выглядит не на уровне теории, а в живых отраслях?» Я тестировала подход с процессными метриками ИИ в трёх типичных российских сценариях: рекрутмент, клиентская поддержка и внутренние сервисы для сотрудников (те же HR-боты или сервис-дески). В каждом случае набор метрик немного разный, но паттерн повторяется: качество, время, комплаенс, плюс несколько продуктовых чисел.
В рекрутменте полезными оказались такие вещи, как «доля резюме, отфильтрованных ИИ без потери сильных кандидатов», «среднее время от отклика до первого контакта», «количество жалоб кандидатов на некорректное обращение с их ПДн». В поддержке — «процент обращений, закрытых ботом без участия оператора», «среднее время первого ответа», «количество случаев, когда ИИ ошибочно запросил лишние персональные данные». Во внутренних сервисах — «доля типовых запросов, решаемых ИИ», «экономия времени сотрудников на поиске информации», «количество инцидентов доступа к данным, которые пришлось разруливать вручную».
Каждый раз, как только мы накладывали эту матрицу на реальный процесс, обнаруживались интересные перекосы. В одной компании бот в поддержке гордо закрывал 60% тикетов, но при этом каждый пятый «закрытый» тикет возвращался с переспросом, а сбор согласий на обработку ПДн для раздела с личными данными был оформлен через одну строчку в политике, а не через отдельный чекбокс. В другой — ИИ прекрасно помогал сотрудникам находить внутренние регламенты, но в логах не было вообще никакого разграничения по уровням доступа, и любой запрос логировался максимально подробно. Это означало, что метрики качества были супер, а метрики комплаенса — нулевые.
Чтобы это не растворилось в массе информации, я часто проговариваю для команды одну ключевую фразу и даже выделяю её в документах: любая отраслевая метрика ИИ всё равно упирается в три оси — качество ответа, скорость работы и безопасное обращение с данными. Всё остальное — вариации, адаптированные под конкретный домен.
Как история с Настиным ботом превратилась в рабочую систему метрик
Что произошло, когда мы начали разбирать Настин кейс по шагам
Возвращаясь к той самой Насте из EdTech, с которой мы начали: спустя пару недель после нашего разговора она написала мне в мессенджер что-то вроде «я тут посмотрела на наши метрики и немного испугалась, можно созвониться?». Оказалось, что на фоне растущего количества диалогов и позитивных отзывов от студентов вдруг всплыл вопрос от службы безопасности: как именно бот обращается с персональными данными и что мы можем показать в случае, если Роскомнадзор придёт с проверкой. До этого вопрос комплаенса жил чуть в стороне, а теперь внезапно стал очень реальным.
На созвоне мы сделали ровно то, о чём я писала выше: нарисовали путь одного запроса, шаг за шагом. На входе студент писал в бота с анонимного аккаунта, задавал вопрос, иногда указывал своё имя или почту, дальше модель пыталась выдать ответ. Если бот считал, что вопрос сложный, он просил ввести номер договора или телефон для связи и передавал тикет человеку. Все эти шаги существовали в голове команды, но нигде не были формализованы. В тот момент Настя сама сказала: «Мы вроде делаем много всего, но цифрами можем показать только объём диалогов и время ответа, а с ПДн у нас пока каша».
Когда мы начали выписывать, какие данные где обрабатываются, выяснилось, что логирование происходило в нескольких местах, часть событий хранилась в зарубежном сервисе, часть — в локальной базе. При этом согласие на обработку ПДн студенты давали через общий пользовательский договор, где обработка была прописана одним абзацем. В теории этого могло бы хватить, но риск остался: бот явно просил больше данных, чем нужно было для ответа на вопрос, а отдельного подтверждения от студента не было. Помнишь ту фразу про холодный кофе? Здесь он стал ещё и метафорой легкой паники.
Именно на этом этапе стало ясно, что без пересборки системы метрик и процессов Настин бот продолжит расти по «подписчикам», но будет тащить за собой растущую тень юридического риска. Чтобы не пугать никого словом «аудит», мы решили назвать это «наведение порядка в цифрах» и двигаться по шагам. Для себя я сформулировала маленькое наблюдение: к моменту, когда тебя впервые спросили «а что у вас с ПДн в ИИ», ты уже опоздал с построением системы метрик на пару месяцев. Лучше не доводить до этого вопроса, но если уж довели — выбираться всё равно возможно.
Я люблю в таких местах текста оставлять одну фразу почти как стикер: красивый бот без понятных метрик качества и комплаенса — это как быстрый автомобиль без ремня безопасности. Пока всё хорошо — приятно, но в случае удара цифры вообще не в вашу пользу.
Как мы сформировали набор метрик для бота и что туда вошло
Когда картина процесса стала чуть более чёткой, мы с Настей перешли к следующему шагу: выбрать небольшой, но осмысленный набор метрик для ИИ. Я предложила ограничиться тремя группами: качество, эффективность и комплаенс. Внутри качества мы договорились отслеживать «долю ответов, не требующих участия человека», «долю ответов, которые студент уточнил или оспорил», а также «долю ответов, которые оператор скорректировал перед отправкой». Первое число показывало, насколько бот действительно решает задачи, второе — где он «плавает», третье — помогало увидеть зону, в которой потребуется дообучение модели.
В эффективности мы выбрали «среднее время ответа бота», «среднее время от первого вопроса до финального решения», «количество запросов в пике нагрузки», чтобы понимать, как ИИ ведёт себя, когда на него обваливаются студенты в дни дедлайнов. Отдельно измеряли «время, которое тьюторы тратят на ответы без бота» и «после», чтобы оценить экономию. Для этого пришлось пару недель пожить в режиме двойного учёта, но результат стоил того: цифры показали, что ИИ действительно отъел у тьюторов существенную часть рутины, несмотря на неидеальную точность.
В блоке комплаенса мы зафиксировали «количество сессий с ПДн», «долю сессий, в которых бот запросил минимально необходимый набор данных», «наличие явного согласия на обработку ПДн перед сбором чувствительных данных», а также «количество инцидентов, связанных с некорректной обработкой ПДн», даже если это были мягкие, внутренние кейсы, а не официальные жалобы. Сначала цифры были неутешительными: бот действительно просил телефон и номер договора «на всякий случай», гораздо чаще, чем это требовалось. Но именно эти цифры позволили команде увидеть масштаб проблемы без истерик.
Помнишь ту ситуацию с холодным кофе? Здесь она впервые сменилась на горячий чай и список задач в Notion. Настя честно призналась: «Если бы я раньше знала, что можно так структурировать метрики, я бы вообще в отчёты про подписчиков не упиралась». Я сама улыбнулась и подумала (вслух уже не сказала): да, многие из нас начинают с того, что проще всего посчитать, а не с того, что действительно показывает картину.
Чтобы эта история не потеряла свою практическую ценность, я оставила в проектной документации короткую заметку: набор метрик ИИ не должен быть гигантским, но в нём обязательно должны быть представители трёх семейств — качество, эффективность, комплаенс. И отдельно сноску: метрики «подписчиков» и «охватов» живут рядом, но не в центре.
Как мы встроили метрики в ежедневную работу, а не оставили в презентации
Один из рисков любых метрик в том, что они легко превращаются в разовый артефакт: собрались, обсудили, записали, сделали пару скриншотов в презентацию, на этом всё. Я поняла, что если метрики ИИ не вшить в регулярный ритм команды, они очень быстро перестают обновляться, а старые числа живут в Wiki как старые фотографии. Поэтому с Настей мы сразу договорились, что выбранные показатели будут видны в двух местах: на дашборде для команды и в ежемесячном коротком отчёте для руководства. Без бюрократии, но с понятной структурой.
Технически это выглядело так: часть метрик мы начали собирать через интеграции (логирование в базу, парсинг событий, простые скрипты на стороне бота), часть — через опросы тьюторов и ручной флаг «ответ бота был некорректен». Раз в неделю система автоматически собирала сводку, и Настя на созвоне команды делала 10-минутный обзор, где говорила не «у нас теперь 25 тысяч диалогов», а «у нас доля автозакрытых запросов выросла на 8%, а количество лишнего запроса ПДн упало вдвое». Руководству такая форма понравилась даже больше, чем просто большие числа.
Отдельно мы завели простой журнал инцидентов с ПДн, где фиксировали все случаи, когда бот запросил лишние данные или неправильно их обработал. Это делалось без охоты на ведьм, скорее как калибровка: понять, где сценарии нужно пересмотреть, а где добавить ограничения. Со временем таких записей стало меньше, и именно это число оказалось одним из самых «успокаивающих» для службы безопасности. Забавно, что на фоне этих разговоров кто-то из команды однажды заметил: «А помните, как мы раньше радовались гордой цифре ’10 тысяч пользователей’?»
Я люблю такие моменты отмечать короткой фразой, которую даже выделяю в тексте: метрики ИИ работают, только если по ним реально принимаются решения каждую неделю, а не раз в квартал. В Настином кейсе это вылилось в вполне устойчивую практику: бот перестал быть «игрушкой с цифрами» и стал сервисом, чьи метрики вплетены в общую систему управления качеством и комплаенсом.
Какие ошибки в метриках ИИ встречаются чаще всего и как их обойти
Чем опасна любовь к «тщательно подобранным» цифрам без контекста
Когда я первый раз увидела презентацию по одному ИИ-проекту из финансового сектора, меня насторожила не сама модель, а слайды с метриками: всё было красиво, но подозрительно гладко. Точность 97%, время ответа меньше секунды, снижение нагрузки на операторов на 40%. Звучит как мечта, пока не начинаешь задавать вопросы: на каких данных мерили, какие кейсы исключили, что происходит с редкими, но критичными сценариями, как учитываются инциденты с ПДн. Выяснилось, что для презентации взяли только «чистый» пласт данных, а проблемные куски аккуратно вынесли за скобки. Это классика: «тщательно подобранные» цифры, которые хорошо смотрятся, но не помогают принимать реальные решения.
Я на практике заметила, что кристально красивые графики без неровностей часто означают либо очень простую задачу, либо очень серьёзную фильтрацию данных перед показом. Для ИИ, который живёт в боевом режиме, характерны колебания: пики нагрузки, странные запросы, изменения в поведении пользователей. Если отчёт по метрикам выглядит как линейка с идеальными трендами, есть риск, что часть реальности просто не добирается до дашборда. Особенно опасно это для комплаенса: инциденты, связанные с ПДн, любят спрятаться в углах, а потом внезапно выйти наружу, когда кто-то пишет жалобу.
Здесь работает довольно скучная, но честная практика: регулярно просматривать «сырой» срез данных по ИИ, не только агрегированные цифры. Посмотреть несколько логов диалогов, где модель ошиблась, проверить пару сессий с ПДн от и до. Это помогает поймать вещи, которые не видны на усреднённых графиках. Я поняла, что даже 10-15 минут такой проверки в неделю дают гораздо больше понимания реальности, чем час созвона по идеально вылизанным дашбордам (звучит странно, но работает).
Я люблю фиксировать для себя короткую формулу, чтобы не расслабляться: чем красивее метрики ИИ, тем больше смысла проверить, что осталось за пределами выборки. И отдельно подсвечиваю одну фразу, которую я иногда озвучиваю вслух на встречах, когда чувствуется слишком много полировки:
Если у вас нет ни одной «некрасивой» цифры по ИИ, вероятно, вы смотрите не на весь ИИ, а только на светлую сторону его луны.
Почему попытка измерить всё сразу убивает здравый смысл
Другой перекос — противоположный: вместо пары ключевых метрик команда пытается замерить вообще всё. Сотни показателей, куча графиков, десять вкладок в BI-системе. В такой ситуации обсуждение эффективности ИИ превращается в игру «кто найдёт более выгодную для себя цифру». Продакт показывает рост конверсии в один сценарий, юрист — снижение количества инцидентов, техдир — улучшение латентности, а в итоге никто не может сказать, что на самом деле происходит. Я несколько раз заходила в такие проекты и ловила себя на мысли, что массивность данных не компенсирует отсутствия фокуса.
На практике я стараюсь ограничивать первый набор метрик до 10-15 показателей, не больше. Это не означает, что остальные числа неважны, просто они живут уровнем ниже, как детализация. На верхнем уровне полезно видеть: 2-3 показателя качества, 2-3 эффективности, 2-3 по комплаенсу, чуть-чуть продуктовых. Всё. Если в отчёте 40 метрик, большинство людей перестаёт их читать после четвертой строки. Лучше постепенно добавлять новые числа, когда действительно возникает вопрос, на который существующие не отвечают, а не «на всякий случай».
Интересный момент: как только команда соглашается на небольшой, но жёстко приоритизированный набор показателей, разговоры становятся проще. Не нужно листать бесконечные дашборды, чтобы понять, стоит ли разворачивать новую фичу или откатывать её. Я однажды чуть не сорвалась и сказала «забудь, что я только что сказала — давай оставим только три метрики», когда очередная дискуссия ушла в обсуждение пятнадцатой производной от конверсии. Потом мы действительно сократили набор и всем стало легче.
Чтобы не скатиться к минимализму «измеряем только один показатель и всё», я для себя держу в голове другую формулу: метрики ИИ должны быть достаточно богатыми, чтобы отражать сложность системы, но достаточно компактными, чтобы по ним можно было принимать решения без головной боли. Это тонкий баланс, но его стоит искать.
Как игнорирование метрик по ПДн приводит к неожиданным сюрпризам
Самая болезненная ошибка, которую я вижу в российских проектах с ИИ, — полное отсутствие или декоративность метрик по персональным данным. То есть ИИ при этом активно использует ПДн, собирает, анализирует, высылает уведомления, но нигде не видно, сколько сессий было с чувствительными данными, какова доля сессий без согласия, как часто происходят нарушения регламента. Всё внимание уходит на точность модели, экономию времени и рост пользователей, а зона ПДн живёт как будто сама по себе. До тех пор, пока не появляется проверка или жалоба.
Я однажды помогала компании, у которой был прекрасный AI-ассистент для сотрудников, очень удобный, с быстрым поиском по внутренним документам. По метрикам качества и скорости всё было отлично. Но, когда мы сели смотреть, как устроена работа с ПДн, выяснилось, что в логах бота хранились запросы, где сотрудники писали о клиентах по ФИО, с номерами договоров и иногда даже с паспортными данными. Система логировала всё подряд, без фильтров, и эти логи хранились на сервере, который команда использовала просто «как удобно, он же надёжный». Вопрос локализации и разделения прав доступа там не поднимался вообще.
Когда мы посчитали, сколько таких сессий было за последние полгода, у безопасности слегка изменилось выражение лица. Метрика «количество сессий с ПДн в логах» внезапно стала важнее точности ответа модели. Пришлось в спешке пересматривать архитектуру, добавлять фильтрацию, а часть логов аккуратно и законно «зачищать», оставляя только обезличенные данные. Если бы эти показатели отслеживались с самого начала, компания сэкономила бы себе немало нервов и консультаций с юристами.
Чтобы не повторять подобные истории, я держу в голове одну простую фразу, которую теперь часто озвучиваю на старте проекта: если ИИ хоть как-то касается ПДн, у него обязаны быть свои отдельные метрики по данным — даже если они сначала живут в самом простом виде. И ещё одна короткая мысль, которую я выделяю, чтобы она точно не потерялась:
Метрики по ПДн в проектах ИИ — это не опция «для галочки», а страховка от сценария «много лет всё было нормально, пока не стало очень нехорошо».
Как построить свою систему метрик ИИ шаг за шагом
С чего начать: быстрый каркас для любой компании
Когда люди доходят до этого места, почти всегда всплывает вопрос: «Окей, а с чего начать именно нам, чтобы не утонуть в деталях?» Я поняла, что хорошо работает простой трёхшаговый каркас, который можно применить к любому ИИ-проекту: описать процессы, выделить ключевые точки влияния ИИ и на эти точки навесить по 2-3 метрики. Не нужно сразу строить идеальную BI-систему, достаточно честно ответить себе на несколько базовых вопросов.
Для удобства восприятия я обычно формулирую это как последовательность шагов. Они не волшебные, но помогают не забыть критичные элементы. Порядок такой:
- Понять, где именно в процессе участвует ИИ и что он делает за людей.
- Определить, какие данные он использует и какие ПДн могут попадать в его зону.
- Выбрать по две-три метрики на каждую из трёх осей: качество, эффективность, комплаенс.
- Проверить, откуда можно брать данные для этих метрик (логи, CRM, BI, формы).
- Решить, как часто вы будете на них смотреть и кто за них отвечает.
Каждый шаг по отдельности звучит очевидно, но в сумме они дают более внятную систему, чем десяток хаотичных показателей. Особенно помогает пункт про частоту и ответственность: если у метрики нет «хозяина» и она не попадает в регулярный обзор, она быстро умирает. И наоборот, когда у качества ответов есть владелец в продукте, у времени ответа — владелец в поддержке, а у ПДн — владелец в комплаенсе, цифры начинают жить.
Я для себя много раз убеждалась, что система метрик ИИ не должна рождаться как один огромный документ, её лучше строить итерациями. Сначала базовый каркас на квартал, потом корректировка по итогам, добавление новых показателей, когда это действительно нужно. Попытка придумать всё сразу провоцирует перфекционизм и откладывание. А если начать с малого, появляется шанс, что это вообще дойдет до продакшена, а не останется в красивой таблице.
Какие инструменты помогают не утонуть в таблицах и отчётах
Когда каркас понятен, возникает практический вопрос: где всё это хранить и как не утонуть в Excel. На рынке уже есть российские решения, заточенные под ПДн и комплаенс, вроде PrivacyLine или тех же QForm, которые помогают держать реестры процессов, систем и хранилищ в одном месте. Параллельно с ними живут BI-системы и самописные дашборды. Я не привязана к какому-то одному стеку, но люблю, когда инструменты поддерживают логику «одно окно» для разных ролей: продакта, DPO, технаря.
Вот как это может выглядеть: реестр обработки ПДн и процесса с ИИ ведётся в PrivacyLine, где для каждого процесса есть поля «используется ИИ», «какие модели», «какие ПДн», «какие меры защиты». Для замера качества и эффективности используется отдельный дашборд, например, в BI, который подтягивает события из логов и CRM. Между ними есть связка: если метрика по ИИ показывает рост количества инцидентов, это отражается в реестре как отдельная запись, и DPO видит, где нужно усилить контроль или поменять настройки. В QForm, например, удобно фиксировать сами документы — приказы, журналы, согласия — и автоматизировать выдачу и учёт.
Где-то посередине этой экосистемы обычно живут интеграции типа n8n, которые связывают все системы так, чтобы не пришлось руками переносить данные об инцидентах или метриках. У меня в практике была компания, где DPO тратил по полдня на сбор разрозненных Excel перед каждыми внутренними проверками. После внедрения системы реестров и простых автоматизаций время сократилось до пары часов. И да, это тоже метрика ИИ и комплаенса, хотя звучит скорее как история про организацию труда.
Чтобы не перегружать выбором инструментов, я часто формулирую для команды небольшой критерий: любой выбранный стек должен позволять связать ИИ, ПДн и бизнес-метрики в одну картину, доступную разным ролям. Если для этого нужно прыгать между пятью системами и собирать всё руками, стоит подумать, как это упростить. На своём сайте promaren.ru я иногда разбираю такие связки на примерах, но общая идея всегда одна: не усложнять архитектуру там, где можно сделать проще.
Здесь мне нравится подчёркивать одну короткую мысль, я даже визуально её выделяю: инструмент не обязан быть «модным», он должен помогать вам честно видеть цифры и не нарушать закон. Всё остальное — бонус.
Как встроить метрики ИИ в культуру команды, а не только в отчёты
Самая тихая, но важная часть всей истории — культурная. Можно придумать идеальную систему метрик, выбрать лучшие инструменты, написать регламенты, а потом обнаружить, что в команде метрикам просто не доверяют или используют их как аргумент в спорах, а не как способ учиться. Я много раз видела, как метрики ИИ превращались либо в «палочную систему» («должно быть 95% точности, иначе виноват продакт»), либо в «фоновый шум» на встречах. Ни то, ни другое не помогает.
Гораздо лучше работает другой подход: относиться к метрикам как к обратной связи от системы, а не как к приговору. Если точность падает — это не «вы плохо работаете», а «в данных что-то изменилось, надо посмотреть, что именно». Если количество инцидентов с ПДн растёт — это не повод искать виноватых, а сигнал: сценарии устарели, комплаенс не дотягивает, пора обновляться. В такой культуре люди охотнее поднимают проблемные цифры наверх, а не прячут их в надежде, что «само рассосётся».
Я поняла, что одной из лучших инвестиций времени бывает короткий, но честный разговор с командой о том, зачем вообще нам эти метрики ИИ. Не для отчёта ради отчёта, а для трёх вещей: чтобы улучшать качество, защищать пользователей и компанию от рисков и экономить время людей на рутине. Когда эти три цели проговорены и зафиксированы, гораздо проще объяснить, почему «подписчики» — не главный герой, а ПДн и комплаенс — не «про то, чтобы мешать жить», а про то, чтобы не влететь на штрафы и блокировки.
В такие моменты я иногда ловлю себя на желании поставить рядом большой стикер с фразой: метрики ИИ — это безопасный способ признаться, что мир сложнее, чем нам хотелось бы, и всё равно продолжать в нём работать. Звучит чуть пафосно, но если убрать лишние слова, суть остаётся верной.
Чем всё закончилось у Насти и что из этого полезно забрать себе
К этому моменту, думаю, логично вернуться к Насте и её студенческому боту, чтобы не бросать историю в воздухе. Спустя примерно три месяца после нашего первого холодного кофе у неё на столе стоял уже вполне горячий чай и аккуратный дашборд с метриками. Подписчики, кстати, тоже были, просто сдвинуты в сторону: «Аудитория» — отдельный блок, без венца на голове. В центре были три группы показателей: качество, эффективность, комплаенс. И самое приятное — часть цифр реально изменилась за эти месяцы.
По качеству доля вопросов, решаемых ботом без участия человека, выросла примерно с 45 до 62%, а доля обращений, где студент писал «вы не поняли» или «это не то», упала почти вдвое. По эффективности среднее время ответа осталось примерно тем же, но общее время тьюторов на ответы сократилось на 30-35%, что для небольшой команды оказалось критичным. Из чисто человеческого: тьюторы перестали ночевать у ноутбуков в периоды сессий, потому что бот взял на себя львиную долю типовых вопросов.
Самое интересное было в блоке комплаенса. После пересмотра сценариев бот перестал спрашивать номер договора и телефон «по умолчанию», эти поля появлялись только там, где действительно нужны, и только после отдельного согласия. Доля сессий с ПДн, в которых не было явного согласия, сократилась практически до нуля. Логи перестроили так, чтобы в аналитика уезжали только обезличенные данные. Вместо разрозненных файлов появился нормальный реестр процессов с ИИ, связанный с общей системой ПДн компании. Количество «инцидентов» по внутреннему журналу за квартал было меньше пяти, и все они оказались скорее учебными, чем катастрофическими.
Если перевести это в часы, Настина команда сэкономила примерно 80-100 человеко-часов в месяц только на поддержке студентов. Это не считая нервов и того факта, что служба безопасности перестала смотреть на ИИ как на потенциальную проблему. В деньгах эффект тоже был заметен, но для меня главное было другое: метрики искусственного интеллекта перестали быть у них декоративным украшением и стали рабочим инструментом, по которому реально принимались решения.
Меня особенно порадовал один момент: на внутреннем совещании, где Настя показывала прогресс по ботам, кто-то из менеджеров спросил: «А сколько теперь у нас подписчиков?» Настя улыбнулась, показала цифру, а потом добавила: «Но честно, это теперь не самая интересная метрика. Гораздо важнее, что у нас стало меньше ошибок и ноль проблем с ПДн». Этот короткий диалог, наверное, лучше всех описывает, что именно я хотела донести этим текстом.
Получается, что для российских компаний, которые работают с ИИ и ПДн, по-настоящему ценно не количество «подписчиков», а качественная связка трёх групп цифр: как хорошо модель решает задачи, сколько времени она экономит людям и насколько аккуратно она обращается с персональными данными по 152-ФЗ и связанным требованиям. Всё остальное — либо надстройка, либо приятная статистика. И да, кофе иногда будет остывать, пока вы рисуете процессы и спорите о метриках, но через пару месяцев становится заметно, что это были очень хорошо вложенные градусы температуры.
Куда двигаться дальше, если хочется не просто читать, а пробовать
Если во время чтения текста у тебя хотя бы пару раз мелькала мысль «у нас всё примерно так же, только цифры другие», это уже хороший знак — значит, тема действительно про живую работу, а не про абстрактные концепции. Следующий логичный шаг обычно не в том, чтобы развернуть огромную систему мониторинга за неделю, а в том, чтобы выбрать один конкретный процесс с ИИ и честно посмотреть на него в описанной оптике: процесс — точки влияния ИИ — метрики по качеству, эффективности и ПДн.
Для тех, кто любит руками трогать инструменты, хорошим вариантом будет собрать небольшой прототип: через n8n или Make привязать бота или ИИ-агента к простой базе, начать логировать ключевые события, а потом построить по ним первые дашборды. Не обязательно делать это сразу в проде, можно на отдельном тестовом кусочке процесса. В какой-то момент становится почти физически ощутимо: система оживает, когда у неё появляются честные цифры, а не только красивые интерфейсы.
Если хочется больше разборов именно российских кейсов, с учетом 152-ФЗ, локализации, Роскомнадзора и наших очень земных ограничений, я периодически выкладываю такие истории и схемы в телеграм-канале MAREN — там можно посмотреть на реальные связки автоматизации и ИИ, задать вопросы и обсудить, как это всё уживается с комплаенсом. На сайте promaren.ru я собираю более структурные материалы и примеры, как связать ИИ, автоматизацию и управление данными, чтобы люди возвращали себе часы, а не получали сверху ещё одну пачку задач.
Мне самой ближе такой подход: не превращать ИИ в магию и не делать из комплаенса страшилку, а шаг за шагом строить прозрачные процессы, где метрики не пугают, а помогают. Если после этой статьи ты хотя бы один раз посмотришь на цифру «количество пользователей бота» и спросишь себя «а что за ней стоит по времени, качеству и ПДн?», значит, мы с тобой продвинулись в одну сторону. А дальше уже дело за малым. Ну, почти малым 🙂
Что ещё полезно знать про метрики ИИ и ПДн
Как определить, какие метрики ИИ нужны именно моей компании?
Лучше всего начать с процессов, а не с цифр: выберите один-два ключевых сценария, где ИИ реально участвует в работе, опишите путь запроса от пользователя до результата и отметьте, где ИИ что-то решает за людей. На эти точки влияния и вешайте метрики: по одной-две на качество ответа, эффективности по времени и безопасности по ПДн. Если метрика не привязана к конкретному шагу процесса и не влияет на решения, её можно смело откладывать на потом.
Можно ли обойтись без сложных метрик и смотреть только на «время реакции» и «подписчиков»?
Теоретически можно, но это будет очень суженная картинка: вы будете видеть только, насколько быстро и массово система отвечает, но почти ничего не узнаете о точности, ошибках и рисках. Для простых, неперсональных сервисов этого иногда хватает, но как только в дело вступают ПДн, регулятор и деньги, такой набор становится опасно недостаточным. Лучше добавить хотя бы пару метрик по качеству и по ПДн, иначе управлять системой почти невозможно.
Что делать, если у нас нет ресурсов на полноценный аудит метрик и ПДн?
В такой ситуации разумнее всего начать с малого: выберите один самый критичный процесс с ИИ и проведите «микро-аудит» только его. Оцените, какие данные там проходят, как они хранятся, какие есть уязвимости, и заведите хотя бы несколько ключевых метрик. Это уже снизит риски и даст вам первый опыт, который позже можно будет масштабировать. Полная, идеально формализованная система не нужна с первого дня, важнее запустить хоть минимальный контур контроля.
Как часто нужно пересматривать метрики ИИ и обновлять их?
Разумный ритм для большинства компаний — короткий обзор основных метрик раз в неделю или две внутри команды и более детальный пересмотр набора показателей раз в квартал. За это время успевают проявиться новые паттерны в данных, изменения пользовательского поведения и регуляторные требования. Если метрики остаются неизменными годами при живом ИИ-сервисе, это сигнал, что вы, скорее всего, не замечаете чего-то важного.
Нужно ли явно показывать пользователям, что их данные обрабатывает ИИ?
Если ИИ обрабатывает персональные данные, прозрачность коммуникации с пользователями становится частью добросовестной практики, даже если закон напрямую не требует отдельной плашки «это сделал ИИ». Полезно ясно прописать в политике и пользовательских документах, что используются автоматизированные системы, какие данные обрабатываются и для каких целей, и обеспечить возможность обратиться к человеку. Это снижает риски недоверия и жалоб, особенно когда речь идёт о чувствительной информации.
Можно ли использовать зарубежные AI-сервисы, если данные клиентов из России?
С 2025 года требования к локализации ужесточаются: первичный сбор, запись и хранение ПДн граждан РФ должны происходить на российских серверах, а трансграничная передача возможна только при соблюдении дополнительных условий. Это означает, что использовать зарубежные AI-сервисы допустимо лишь в сценариях без ПДн или при грамотной схеме обезличивания и локализации. Если сервис предполагает отправку «сырых» персональных данных за рубеж, это становится прямым риском с точки зрения 152-ФЗ.
Что делать, если Роскомнадзор уже задал вопрос про ИИ и ПДн, а у нас нет метрик?
В такой ситуации важно оперативно собрать и задокументировать фактическую картину: какие процессы используют ИИ, какие данные там проходят, где и как они хранятся. Параллельно стоит запустить хоть минимальный контур метрик по ПДн и инцидентам, чтобы показать регулятору, что вы осознаёте риски и принимаете меры. Лучше честно показать текущий уровень зрелости и план по его повышению, чем пытаться имитировать идеальную систему, которой в реальности нет.