Привет, Хабр. Меня зовут Андрей Коптелов, я бизнес‑архитектор, много лет работающий на стыке управления бизнес‑процессами и корпоративной архитектурой.
Одним из направлений моего развития является обучение, где я являюсь менеджером нескольких образовательных продуктов. Последние годы применяю LLM и AI‑агентов в своей практике.
В этой статье я разобрал 9 ошибок продуктового менеджера при внедрении AI в продукты.
Внедрение искусственного интеллекта (AI) в продукты компании перестало быть экзотикой, стало рутиной и превратилось в стандартное ожидание пользователей.
Но для менеджера продукта это одновременно и возможность, и риск. Желание быстро выпустить «AI‑функциональность продукта» часто приводит к тому, что команда тратит свои ресурсы на то, что не только не решает реальных проблем пользователей, но и не влияет на бизнес‑метрики.
Я собрал 9 типичных ошибок при внедрении AI в продукты с примерами из сферы обучения, где у меня есть опыт.
Возможно, этот чек‑лист поможет вам не наступить на грабли, на которых уже кто‑то побывал. И да, в этой статье термины AI‑агент, AI‑помощник и чат‑бот используются как синонимы.
1. Решение в поиске проблемы (AI ради AI)
Менеджеры продуктов часто предлагают внедрить помощника чат‑бота, только потому, что «это уже есть у конкурентов» или «просто это тренд», не проверяя гипотезу о реальной пользе для пользователя.
Пример из жизни: одна онлайн‑школа запустила «карьерного консультанта» для слушателей, построенного на базе AI‑агента, чтобы помочь слушателям подобрать трек своего дальнейшего развития.
Но по факту опросов оказалось, что выпускникам был нужен не диалог с чат‑ботом, а простой и актуальный чек‑лист с требуемыми на рынке навыками и ссылками на нужные курсы школы.
Взаимодействие с чат‑ботом было менее удобно для пользователей, а его поддержка обходилось компании существенно дороже, чем поддержание актуальности чек‑листа.
Как надо: перед добавлением AI‑функциональности в бэклог своего продукта ответьте на вопрос: какую конкретную проблему пользователя мы решаем?
Если внедрение AI‑агента в процесс не делает процесс быстрее, дешевле или качественнее по сравнению с существующим решением, то можно пока подождать с внедрением.
2. Игнорирование качества данных (Мусор на входе — мусор на выходе)
Практика показывает, что ожидание того, что большая языковая модель (LLM) волшебным образом сама разберется в устаревших или неструктурированных документах, часто не оправдывается. Работа с контентом — это такая же продуктовая задача, как понимание потребностей клиента и проработка пользовательского интерфейса продукта.
Пример из жизни: на учебной платформе был создан AI‑помощник, который был подключен к существующей базе знаний, при этом сам контент не привели в порядок, в результате, чат‑бот начал уверенно рекомендовать слушателям изучать материалы по информационным системам, которые уже не применяются в России, что вызвало недовольство пользователей.
Как надо: внедрение AI‑агентов начинается с анализа правильности и актуальности существующего контента, а также перевода его в машиночитаемый и структурированный формат, лучше воспринимаемый AI.
Поэтому нужно обязательно предусмотреть не только актуализацию материалов, но и перевод их в машиночитаемый и структурированный вид для повышения качества работы AI‑агентов. LLM должна получать на вход только не проверенные, размеченные и свежие данные, а в идеале — чтобы каждый фрагмент имел ссылку на конкретный урок курса.
3. Ориентация на метрики активности пользователей
По мне, так измерение успеха внедренной AI‑функциональности в продукте по количеству запросов и сгенерированных ответов, вместо оценки реального влияния на бизнес или учебный процесс — это рискованный путь.
Пример из жизни: в одном из учебных продуктов коллеги получили большое количество запросов слушателей к AI‑помощнику, однако, это не снизило количество запросов к тьютерам (сотрудникам, поддерживающим слушателей в учебном процессе), так как слушатели все равно переспрашивали у них, не доверяя ответам AI‑помощника, что почти не снизило загрузку персонала.
Как надо: свяжите использование AI‑агентов с метриками существующего процесса, например, снижением среднего времени проверки домашних заданий, уменьшением нагрузки на тьютеров, поддерживающих учебный процесс, ростом процента слушателей, завершивших курс в плановые сроки, и так далее. Если использование AI‑агентов улучшает показатели, то вы на правильном пути.
4. Пренебрежение принципом «Human in the loop» (Человек в контуре)
Попытка полностью автоматизировать критически важные процессы или процессы, где пока присутствуют субъективные решения, например, оценку знаний, без возможности человеческого контроля и апелляции часто приводит к негативу.
Пример из жизни: система автоматической оценки эссе слушателей на основе AI поставила слушателю неудовлетворительную оценку из‑за излишне стандартизированного алгоритма оценки, не учитывающего всех возможных нюансов ответа. При этом способа штатной апелляции к преподавателю не предусмотрели, что привело к негативному отзыву слушателя.
Как надо: AI‑агенту нужно передавать часть рутинной работы, оставляя возможность обработки сложных сценариев и арбитража спорных ситуаций. Всегда должен быть штатный выход на сценарий эскалации на человека, например, кнопка «уточнить оценку» должна быть видна и доступна.
5. Недооценка экономики внедрения и использования AI
При внедрении AI часто делается фокус только на стоимости разработки при игнорировании операционных расходов, в которые входят не только стоимость токенов, но и поддержка инфраструктуры.
Пример из жизни: небольшая онлайн школа запустила акцию «Пройди тестирование по своим навыкам» для генерации базы контактов. Внутри сервиса использовались вызовы к внешней LLM.
По факту оказалось, что многие пользователи проходили тестирование по несколько раз, ведь в конце их ждал бейдж с финальной оценкой, которую они и пытались улучшить. По результатам нескольких дней работы пришлось срочно «убрать» LLM из процесса, меняя LLM на классическое тестирование, чтобы счет от провайдера LLM не превысил маркетинговый бюджет.
Как надо: считайте стоимость операционной поддержки еще на этапе проработки AI‑функциональности для продукта. Внедряйте ограничители, например, лимиты запросов в день или маршрутизацию простых вопросов к более дешевым моделям. Или обходитесь вообще без AI, если есть такая возможность.
6. Проблемы с конфиденциальностью данных
Часто можно встретить перекладывание ответственности за данные на пользователя или разработчиков, в то время как именно продуктовые решения напрямую влияют на нарушения конфиденциальности.
Пример из жизни: слушатели курсов, выполняя домашнее задание по описанию процессов, могут начать загружать в платформу данные из компаний, где они работают. С учетом того, что при проверке заданий применяется внешняя LLM для их обработки, эти данные могут уйти за контур организации или даже страны, что может привести к нарушению законов.
Как надо: менеджер продукта должен изначально закладывать безопасность использования AI в своем продукте. Как минимум нужно добавить предупреждения о запрете загрузки конфиденциальных данных, как максимум — использовать маскирование информации или даже развернуть локальную LLM для работы.
7. Отсутствие регулярной работы по повышению качества работы AI
Проектирование пользовательского пути в расчете на то, что AI‑агент никогда не ошибается, и всегда выдает фактически точную информацию, — это тупиковый путь.
Пример из жизни: AI‑помощник ответил слушателю на заданный им вопрос по расчету стоимости процесса, на основании этого студент сделал домашнее задание, которое преподаватель не принял из‑за ошибки в алгоритме расчета.
В результате возникли вопросы к качеству работы AI‑помощника.
Как надо: всегда управляйте ожиданием пользователя через дисклеймеры «ИИ может ошибаться, проверяйте информацию». С точки зрения повышения качества ответов AI‑агентов — это может решаться через поиск по верифицированной базе знаний (RAG) с обязательным требованием в промпте к LLM указывать источник ответа.
8. AI как дополнительная возможность, а не часть процесса
Сейчас часто можно увидеть внедрение AI как отдельной, изолированной вкладки или сервиса, который требует от пользователя лишних действий, вместо того чтобы быть бесшовной частью основного сценария.
Пример из жизни: на учебной платформе появилась кнопка «Помощь с выполнением задания», которая открывала отдельное окно, куда слушателю приходилось вручную копировать текст своей задачи, а затем копировать ответ обратно в окно платформы обучения.
Как надо: делайте AI контекстным и невидимым, если студент допустил ошибку в ответе на платформе, AI‑помощник должен подсветить строку и предложить подсказку прямо там, не заставляя пользователя никуда переходить.
9. Запуск AI‑функциональности без регулярной петли обратной связи
Отношение к AI‑функциональности в продукте как к завершенному проекту после внедрения, без сбора данных о том, как пользователи реагируют на работу AI, приведет к ее быстрой деградации.
Пример из жизни: AI‑помощник по анализу резюме для аналитиков не указывал в своих рекомендациях навыки в области AI, которые стали требоваться в последний год.
В результате пользователи теряли интерес к сервису. При этом команда продукта не собирала эту обратную связь и не корректировала алгоритмы работы, что привело к оттоку пользователей.
Как надо: внедряйте механизмы сбора обратной связи с первого дня. Можно использовать явные способы, такие как кнопки «полезно / бесполезно», или неявные — время чтения ответа или досрочный выход из диалога. Эти данные должны регулярно анализироваться для доработки алгоритмов продукта.
В качестве заключения
AI — это не серебряная пуля, а мощный инструмент, и если вы автоматизируете хаос, вы получите масштабированный хаос, умноженный на стоимость токенов.
Для продуктового менеджера работа с внедрением AI‑функциональности в свой продукт — это не только тренировка навыков работы с LLM, но и «классический» опыт понимания проблемы пользователя, работы с метриками, контроля экономики продукта и проектирования удобного пользовательского пути.
Внедряйте AI не потому, что это модно, а потому, что вы нашли способ сделать ваши процессы действительно эффективнее.
Внедрение ИИ часто начинается с идеи: «добавим помощника», «автоматизируем процесс», «сделаем продукт умнее». Но без проверки гипотезы, понятных метрик и расчета ценности такая функция может остаться дорогой экспериментальной возможностью.
На открытых уроках разберем, как продуктовым менеджерам пройти путь от идеи ИИ‑продукта до измеримого результата:
8 октября в 20:00. «Как запустить ИИ‑продукт: от бизнес‑гипотезы до первых измеримых результатов». Записаться
21 октября в 20:00. «Как посчитать ценность ИИ: метрики и ROI, которые нужны менеджеру». Записаться
А полный список бесплатных уроков сентября можно посмотреть в дайджесте.
