Medium: написание PRD для AI-продуктов — фреймворк для вероятностных систем

О чём статья

Нима Тораба — продуктовый стратег с опытом в Samsung и Rogers Media — опубликовал на Medium в апреле 2026 года руководство, закрывающее практический пробел: традиционные PRD исходят из того, что код детерминирован, данные стабильны, а круг стейкхолдеров ограничен. AI-системы работают иначе — они выдают вероятностные результаты, требуют постоянного управления данными и вовлекают юридический отдел, службу доверия и безопасности и специалистов по данным как активных участников процесса спецификации. Статья предлагает семичастный фреймворк для написания PRD, соответствующих реальному поведению AI-продуктов.

Контекст и структура

Руководство состоит из семи разделов: концептуальный переход от традиционных к AI-ориентированным требованиям; стратегическое определение — соответствие решения задаче и описание «золотых» сценариев использования; стратегия данных — происхождение, требования к актуальности и наследование прав доступа; поведение модели — бюджет латентности, стратегии оценки и обработка ошибок; UX и дизайн взаимодействия — как передавать неопределённость AI и управлять латентностью в интерфейсе; безопасность и риски — спецификации отказа, красные команды и протоколы включения человека в процесс; и совместная работа и жизненный цикл — разработка с приоритетом оценки и мониторинг после запуска.

Ключевые выводы

Наиболее практичный вклад статьи — переход от PRD как документа передачи к PRD как операционному контракту, который развивается на протяжении жизни продукта. Тораба выделяет несколько требований, которые традиционные шаблоны полностью упускают. Таблица требований к актуальности должна фиксировать допустимый возраст данных для каждого источника в системе — без неё инженеры будут угадывать и либо переинвестируют в синхронизацию реального времени, либо выпустят модель, рассуждающую на основе устаревших входных данных. Системные персонажи — описания того, как AI должен вести себя с точки зрения тона, паттернов отказа и выражения неопределённости — должны присутствовать в спецификации как первичный артефакт, а не как дополнение от дизайнера. Критерии приёмки должны быть верифицируемы автоматически и сформулированы вероятностно — не в виде размытых определений вроде «интуитивно» или «быстро».

Вопросы безопасности получают собственный раздел, а не абзац в приложении. Тораба утверждает, что спецификации отказов, пороги допустимой галлюцинации и пути эскалации к ручной проверке — это продуктовые решения, а не инженерные, и они должны присутствовать в PRD наравне с описанием функциональности.

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

Кому полезна статья

PM, которые выпускали традиционный software и теперь отвечают за AI-функциональность, которая была плохо специфицирована в предыдущих итерациях. Также полезно руководителям кросс-функциональных направлений — юридического и службы доверия — которые хотят понять, чем требования к AI отличаются от требований к software и где их участие влияет на продуктовые решения. Семичастная структура позволяет внедрять её частично — команда может применить разделы по стратегии данных и поведению модели, не переписывая весь шаблон PRD.