Разработка ИИ-решений отличается от классической разработки ПО степенью непредсказуемости: модели деградируют после деплоя, галлюцинируют, дрейфуют вместе с данными. Российский фреймворк AI КОМП-АС предлагает методологию, которая снижает этот риск через жёсткую документацию требований и поэтапную проверку гипотез на всей дистанции — от замысла до эксплуатации.
Центральный артефакт подхода — PRD, Product Requirements Document. Это верхнеуровневый документ, отвечающий на три вопроса: что именно реализуется, как это должно работать и зачем это нужно бизнесу. Без него команда разработки лишена общего ориентира и вынуждена принимать решения вслепую. Авторы фреймворка проводят прямую аналогию со строительством: как ни один объект не возводится без технического проекта и сметы, так и ни одна ИИ-разработка не должна стартовать без PRD и архитектурного дизайна.
Первый блок PRD — бизнес-гипотеза и метрики. Авторы настаивают на декомпозиции: если целевая метрика слишком высокоуровневая, её нужно разложить до той составляющей, на которую конкретное решение влияет напрямую. Пример из фреймворка: исходная цель — рост MRR на 10%. После декомпозиции выделяется под-метрика trial-to-paid conversion rate — именно она отражает эффект ИИ-инструмента, помогающего переводить пробных пользователей в платящих. Отслеживать именно её, а не агрегированный доход, означает получать честную обратную связь о работе системы.
Бизнес-метрики нужно декомпозировать до уровня, где влияние конкретного ИИ-решения можно измерить напрямую.
Второй блок — продуктовый дизайн. Функциональные требования оформляются в виде пользовательских историй (User Stories), а для понимания общей картины рекомендуется User Stories Mapping — визуализация сценариев в порядке их выполнения. Это помогает команде расставить приоритеты: что войдёт в MVP, а что отложится до поздних релизов. MVP здесь понимается классически — те 20% функциональности, которые несут 80% ценности.
Отдельно фреймворк акцентирует специфику ИИ-продуктов: любая модель начинает деградировать сразу после деплоя и не застрахована от галлюцинаций и дрифта данных. Из этого следует принцип Human in the Loop — человек должен оставаться в цепочке принятия решений, особенно в критических точках процесса. Ответственность за результат лежит на пользователе, а не на системе. Авторы используют точную метафору: ИИ-инструмент — это электрический рубанок в руке столяра, он повышает скорость работы, но качество изделия определяет мастер.
Третий блок — архитектурный дизайн. Для его описания рекомендуется C4-нотация: четыре уровня абстракции — Context, Containers, Components, Code. Уровень C1 позволяет вовлекать бизнес в обсуждение без технических деталей, уровень C4 даёт разработчикам детализацию до конкретных атомарных блоков. Такой подход обеспечивает единый язык для всех участников проекта.
При выборе технологического стека фреймворк советует руководствоваться принципом минимальной достаточности: использовать инструменты, соразмерные задаче, а не самые новые или мощные. Стоимость инференса тяжёлых моделей и дорогих API напрямую влияет на TCO — Total Cost of Ownership. Если этот показатель превысит экономический эффект от внедрения, проект окажется убыточным вне зависимости от технического качества решения. Второй принцип — качество данных важнее выбора модели: именно подготовка и доставка данных определяет итоговое качество ИИ-сервиса.
