ИИ-продукты
Что такое ИИ-продукт
ИИ-продукт — это переиспользуемая способность компании решать повторяемый класс задач с помощью ИИ. Это может быть внутреннее решение, сервис, платформа или функциональный блок, который подключается в разных подразделениях и сценариях.
Ключевое отличие от разового пилота — переиспользуемость. Пилот закрывает один кейс одной команды. Продукт закрывает класс похожих задач для многих команд и живёт дольше одного проекта.
Без продуктового слоя компания под каждый запрос собирает новое решение: появляются дубликаты, один и тот же класс задач решается по-разному, пилоты не переиспользуются, ИТ и безопасность заново проверяют похожие решения, а эффект невозможно посчитать. Продуктовый слой превращает разрозненные решения в управляемый набор возможностей.
Характеристики ИИ-продукта
Любой ИИ-продукт — платформенный он или прикладной — описывается одним набором характеристик. Они задают общий язык: по ним продукты можно сравнивать, оценивать зрелость и принимать решение о развитии.
| Характеристика | Что описывает | Зачем нужна |
|---|---|---|
| Тип | Платформенный или прикладной | Определяет, кто пользователь и как продукт развивается |
| Класс задач | Какой повторяемый класс задач закрывает | Главный критерий: есть ли вообще продукт |
| Целевая аудитория | Для кого продукт: команды, роли, подразделения | Без аудитории продукт не переиспользуется |
| Владелец | Кто отвечает за ценность и развитие | Продукт без владельца деградирует |
| Переиспользуемость | Сколько сценариев и подразделений может обслужить | Отличает продукт от разового решения |
| Зрелость | Идея, пилот, эксплуатация, развитие, вывод из портфеля | Определяет, что с продуктом делать дальше |
| Риск-профиль | Доступ к данным и системам, цена ошибки | Задаёт глубину контроля и согласований |
| Деливери-трек | Как потребность закрывается и доводится до эффекта: артефакты, согласования, процессы | Задаёт маршрут реализации под тип продукта и риск автоматизируемого процесса |
| Контур поддержки | Кто сопровождает продукт после запуска | Без поддержки продукт умирает после пилота |
| Метрики | Использование, качество, эффект, стоимость | Показывают, оправдан ли продукт |
Эти же характеристики образуют минимальную карточку продукта в каталоге портфеля — единую запись, по которой видно, что это за продукт, для кого он и в каком он состоянии. Полная структура карточки описана в артефакте Карточка ИИ-продукта.
Два уровня ИИ-продуктов
Тип — первая характеристика продукта. По нему ИИ-продукты делятся на два уровня.
1. Платформенные ИИ-продукты
Платформенные продукты — это базовые технологические способности, на которых строятся прикладные решения.
Они не всегда напрямую решают бизнес-задачу, но дают компании возможность быстро создавать, тестировать и масштабировать ИИ-сценарии.
| Продукт | Что даёт компании |
|---|---|
| Корпоративная LLM | Единый доступ к языковым моделям, промптам, политикам, логированию и ограничениям |
| RAG-платформа | Поиск и генерация ответов на основе корпоративных знаний |
| ML-платформа | Обучение, развёртывание и мониторинг ML-моделей |
| Код-агент | Ускорение разработки, анализа кода, тестирования и документирования |
| Среда запуска агентов | Среда для запуска, контроля и мониторинга ИИ-агентов |
Платформенные продукты отвечают на вопрос:
Какие базовые ИИ-возможности есть у компании?
2. Прикладные ИИ-продукты
Прикладные ИИ-продукты — это сервисы, собранные поверх платформенных возможностей и ориентированные на конкретный класс задач. Они могут использовать сразу несколько платформенных продуктов.
Например, прикладной продукт «Ассистент по нормативным документам» может использовать LLM для генерации документации по шаблону, RAG-платформу для поиска релевантной информации и агентов под капотом для автоматизации рутинных шагов.
| Продукт | На чём может быть построен | Какой класс задач решает |
|---|---|---|
| Ассистент по базе знаний | LLM + RAG | Поиск ответов по документам |
| Генератор документов | LLM + шаблоны + автоматизация процессов | Подготовка типовых документов |
| Ассистент проектного менеджера | LLM + RAG + MCP Atlassian + агентский оркестратор | Статусы, протоколы, риски, планы |
| Анализатор обращений | LLM + ML-классификация + интеграции | Разбор обращений, маршрутизация, приоритизация |
| Ассистент разработчика | Код-агент + репозитории + документация | Разработка, ревью, тесты, документация |
| Агент для комплаенса | LLM + RAG + правила контроля | Проверка текстов, документов, операций |
Прикладные продукты отвечают на вопрос:
Какие повторяемые бизнес-задачи компания уже умеет решать с помощью ИИ?
Где смотреть полный список продуктов
Полный список классов не дублируется на этой странице. Он живёт в разделе Таксономия ИИ-продуктов: там зафиксированы 18 рыночных классов и их маппинг на операционный каталог из не более чем 10 деливери-треков.
Эта страница отвечает на другой вопрос: что считать ИИ-продуктом в операционной модели и как понять, заслуживает ли повторяющийся класс задач отдельного продукта. Таксономия помогает классифицировать рынок и запросы бизнеса; модель ИИ-продукта помогает принять управленческое решение внутри портфеля.
Как понять, какие ИИ-продукты вам нужны
Продуктовый портфель не проектируют «сверху», выбирая модные технологии. Его выводят из спроса — снизу вверх. Самый практичный способ — взять последние 30–50 ИИ-запросов компании и прогнать их через простое упражнение.
- 1Убрать названия отделов
- 2Сгруппировать по глаголам
- 3Сопоставить глаголы с продуктами
- 4Проверить правилом 3×5
Шаг 1. Убрать названия отделов. Описывайте не «ИИ для HR» или «проверка договоров для юристов», а функциональную потребность. За названием отдела почти всегда прячется один и тот же класс задач.
| Запрос | Функциональная потребность |
|---|---|
| HR-чатбот | искать и отвечать по внутренним знаниям |
| Проверка договоров | извлекать, сравнивать и проверять документы |
| Ассистент разработчика | генерировать, объяснять и ревьюить код |
| Риск-модель | прогнозировать вероятность, классифицировать события, находить аномалии |
Шаг 2. Сгруппировать по глаголам, а не по отделам. Почти все ИИ-запросы сводятся к небольшому набору глаголов: найти, обобщить, извлечь, сравнить, классифицировать, сгенерировать, спрогнозировать, автоматизировать, рекомендовать. Глагол, который повторяется у разных функций, — сигнал, что нужна переиспользуемая возможность, а не очередное решение под отдел.
Шаг 3. Сопоставить глаголы с продуктами. За каждым повторяющимся глаголом стоит кандидат в ИИ-продукт.
| Что нужно людям | Кандидат в ИИ-продукт |
|---|---|
| Находить ответы | Поиск по знаниям / RAG |
| Обрабатывать документы | Документный интеллект |
| Фиксировать встречи | Анализ встреч |
| Прогнозировать и оценивать | ML-платформа |
| Автоматизировать шаги | Автоматизация процессов / агенты |
| Быстрее собирать инструменты | Код-агент |
| Управлять всеми ИИ-инициативами | Платформа управления ИИ |
Шаг 4. Проверить правилом 3×5. Возможность достойна стать отдельным ИИ-продуктом, только если она:
- встречается минимум в 3 разных функциях;
- может поддержать минимум 5 реальных инициатив;
- имеет повторяемые требования к данным, безопасности и деливери;
- настраивается, а не собирается заново под каждый кейс;
- имеет владельца и дорожную карту.
Если кандидат не проходит правило 3×5 — это пока проект под конкретный кейс, а не продукт.
Кандидаты сразу распадаются на два уровня: то, что закрывает класс задач для пользователей, — прикладной продукт; то, что нужно сразу нескольким прикладным продуктам (доступ к LLM, поиск по знаниям, запуск агентов), — платформенный продукт.
По каждому продукту-кандидату решают делать / купить / взять через партнёра; выбор зависит от уникальности задачи, требований к данным и безопасности, скорости и стоимости. Портфель пересматривают не реже раза в квартал: рынок моделей и инструментов меняется быстрее большинства технологий, и часть решений «делать» со временем выгоднее заменить на «купить».
Антипример и правильный подход
Антипример. Юристы, HR, закупки, риски и ИТ — каждое подразделение просит свой отдельный RAG. В результате компания получает пять похожих решений, пять контуров поддержки, пять архитектурных проверок и пять разных подходов к безопасности.
Правильный подход. Компания видит общий класс задач — «поиск и ответы по документам» — и развивает один платформенный продукт, а поверх него собирает прикладные ассистенты:
- Ассистент юриста
- Ассистент HR
- Ассистент закупок
- Ассистент риск-менеджера
- Ассистент ИТ-поддержки
Базовая технология одна, а прикладные продукты адаптированы под разные классы пользователей и задач.
Ключевой принцип
Компания должна управлять не потоком разрозненных запросов, а портфелем переиспользуемых ИИ-продуктов, через которые эти запросы закрываются. Без этого внедрение ИИ превращается в набор несвязанных пилотов; с этим — компания получает меньше дублирования, быстрее деливери, понятную архитектуру, управляемую безопасность и прозрачную ответственность.
Связь с инициативами
ИИ-продукт отвечает на вопрос «какие переиспользуемые возможности есть у компании». Как именно компания проходит путь от бизнес-потребности до подтверждённого эффекта через эти продукты — тема раздела Портфель ИИ-инициатив: один продукт обслуживает много задач, одна задача может использовать несколько продуктов.