Генеративный ИИ в компании

Как связать эксперименты с бизнес-результатом

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

Нельзя запускать проект, не понимая, какой KPI вы изменяете. При этом метрика успеха должна быть не технической, а строго бизнесовой. Техническая метрика — это, например, «насколько хорошо отвечает агент» или «каков процент распознавания». Но она не гарантирует никакого бизнес-эффекта. Бизнесовая метрика — это «на сколько процентов мы сократили время обработки заявки и сколько денег сэкономили» или «как выросла конверсия в целевое действие». Если в 40% случаев заявку теперь обрабатывает агент без участия человека, это прямая экономия 40% трудовых затрат. Отметим, что в ряде случае рекомендуется также определять и технические метрики качества ответа модели, например, фактологическая точность ответов через оценку человеком или процент галлюцинаций, однако как дополнительную к основной бизнес-метрике.

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

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

Где генеративный ИИ усиливает процесс? 

Неготовность процессов к внедрению ИИ остаётся самой частой и самой дорогой ошибкой, приводящей к провалу в 80% случаев. Выбор процесса для автоматизации требует не меньшей тщательности, чем выбор модели. Автоматизация — это всегда про «тропинки» рабочих процессов.

Необходимо смоделировать разные ситуации, например, здесь менеджер должен согласовать с руководителем, а что будет, если руководитель не отвечает? Что происходит при положительном и отрицательном решении? Такое моделирование с участием непосредственных исполнителей позволяет увидеть реальные ветвления, узкие места и зоны неопределённости. Это необходимо, чтобы четко определить узкое место в процессе, где человек сталкивается с проблемами или теряет много времени. А также определить место в процессе, где человек передает управление ИИ и забирает его обратно. При выборе процессов и операций для автоматизации стоит опираться на несколько критериев. Советы по выбору областей для пилотов мы детально описали в Части 6 «Как найти процессы, где ИИ действительно эффективен?», здесь коротко повторим основное.

1. Выбирайте операции с большим количеством однотипных регламентных решений, где сотрудник действует по инструкции. Нельзя браться за процессы, регламенты размыты, а также где требуется креативность.
   
2. Выбирайте области, где есть максимум качественных, размеченных данных — например, с бухгалтерских документов, которые четко регламентированы благодаря законодательным требованиям.
   
3. Выбирайте операции, где есть понятный критерий качества и измеримый результат.
   
4. Выбирайте операции, где на входе и выходе должен быть текст — письма, документы, обращения, код, резюме.
   
5. Выбирайте области, где цена ошибки невелика, чтобы сбои модели не приводили к катастрофическим последствиям. Нельзя браться за те чести процессов, где ответственность за результат высока.

Данные — главный актив, который почти всегда оказывается проблемой 

По оценкам экспертов, в каждом проекте по внедрению генеративного ИИ, от 30 до 40% времени уходит на сбор, очистку и подготовку данных. Бизнес часто говорит: «у нас всё есть, мы дадим доступ», но, когда специалисты начинают смотреть, оказывается, что данных мало, или они находятся в совершенно хаотическом состоянии, или есть только входные данные и выходной результат, и полностью отсутствует информация о логике принятия решений. Для обучения ИИ-агентов нужны не только хорошо размеченные данные, но и внутренняя логика: причины выбора того или иного решения, критерии, на которые ориентировался сотрудник и логика ветвлений. Почему HR-менеджер принял решение о найме конкретного кандидата? Почему изменилась цена в коммерческом предложении? Почему подготовлен именно такой документ, а не альтернативный?

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

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

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

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

Инфраструктура и чем плох on-premise 

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

Стартовать пилот проще в облачном сервисе от внешнего провайдера: там быстрее и дешевле на входе. Облачные провайдеры предлагают готовые среды, предустановленные библиотеки и возможность арендовать мощности по мере необходимости. Но большинство крупных и средних российских компаний испытывают панический страх перед облаками из-за регуляторных требований, рисков утечки данных и отсутствия контроля над физической инфраструктурой. И размещать генеративную модель локально, на собственных серверах (on-premise) — это единственный вариант, другое, как правило, даже не обсуждается.

Настройка драйверов, обеспечение совместимости, конфигурирование кластеров, поддержка отказоустойчивости — всё это требует инженеров в области ИИ и машинного обучения, которых сейчас на рынке катастрофически мало. А без них купленные GPU-карты превратятся в дорогой хлам. 

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

При этом нужно предусмотреть ресурсы не только на разработку, но и на поддержку, масштабирование и регулярное обновление. 

Лидер, команда и компетенции 

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

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

Команда пилота критически важна и здесь компании столкнуться с кадровым голодом. Сегодня рынок переполнен молодыми инженерами и студентами, которые быстро осваивают новые технологии и могут «на коленке» собрать прототип за выходные. На нынешнем уровне развития технологий это не сложно. Тем не менее, кадровый голод в области ИИ очень высок, катастрофически не хватает квалифицированных ИИ- и MLOps-инженеров (Machine Learning Operations). Это специалисты, которые умеют раскатывать ИИ-решения в промышленную эксплуатацию: сопровождать масштабные ИИ-решения, настраивать драйверы, обеспечивать отказоустойчивость, масштабировать железо, мониторить производительность.

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

Безопасность и соответствие законодательству 

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

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

Кто следит за тем, чтобы в промты не попадали конфиденциальные данные? Кто защищает от промт-инъекций — специально сконструированных запросов, которые заставляют модель выдавать запрещённую информацию? Какие метрики безопасности будут использованы для оценки рисков? Эти вопросы должны быть проработаны до старта пилота, и они настолько важны, что эксперты рекомендуют ввести роль владельца рисков. 

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

*** 

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

Комментарии 0