Главное
Оценивать AI-проект нужно по рабочим потокам, а не по числу экранов или цене токенов. Самые большие неизвестные обычно находятся в данных, интеграциях, правилах доступа, критериях качества и обработке исключений. Поэтому сначала нужен ограниченный discovery с stop/go критериями.
У AI-проекта редко ломается оценка из-за цены модели. Гораздо чаще диапазон разъезжается из-за неизвестных в данных, интеграциях, правах, человеческих handoff и критериях качества. Поэтому разговор о сроках и бюджете имеет смысл только после разборки рабочего процесса.
Практически это означает: сначала ограниченный discovery, затем проверка ключевых неизвестных и только потом производственный объём. Такой подход соответствует и NIST AI RMF, и инженерной логике поставки сложных систем.
Главные драйверы срока и цены
Самые дорогие части AI-проекта обычно не видны на первом экране. Это качество исходных данных, нестабильные API, ручные обходы процесса, настройка evaluation, безопасность действий и операционный контур после запуска.
- Процесс: сколько ролей, исключений и состояний реально существует.
- Данные: где лежат источники, кто владелец и как обновления влияют на результат.
- Интеграции: есть ли тестовый контур, идемпотентность и понятная документация.
- Эксплуатация: мониторинг, журналы, SLA, поддержка, rollback и стоимость ошибки.
Почему discovery экономит деньги, а не удлиняет проект
Если неизвестные не разобраны в начале, они всё равно проявятся позже — уже как переделка архитектуры, change request или спор о приёмке. Небольшой discovery нужен не ради красивого документа, а чтобы превратить риск в измеримую проверку и зафиксировать stop/go критерии.
Честная оценка на старте
На первой встрече разумно обещать не точную смету, а границы версии, список ключевых неизвестных и формат следующего проверочного этапа. Чем больше подтверждённых фактов о данных, ролях и интеграциях, тем уже становится диапазон. Ранняя точная цифра без этих входов обычно просто откладывает риск на период после договора.
Что включить в диапазон, кроме разработки
В производственный диапазон должны входить подготовка и миграция данных, eval и негативные сценарии, управление доступами, observability, запуск, обучение владельца процесса и период стабилизации. Отдельно указываются внешние API, inference, инфраструктура и допущения по нагрузке.
Приёмка привязывается к наблюдаемому результату: версия развернута, контрольный набор пройден, критические ошибки отсутствуют, handoff работает, а владелец получает журналы и процедуру rollback.
Сравнение
Основные драйверы оценки
| Поток | Что входит | Что увеличивает неопределённость |
|---|---|---|
| Процесс | Роли, шаги, исключения, handoff | Нет владельца или baseline |
| Данные | Источники, очистка, права, обновление | Низкое качество и неизвестные доступы |
| AI | Модель, prompt, retrieval, инструменты | Нет контрольного набора |
| Интеграции | API, события, состояния, ошибки | Legacy и ручные обходы |
| Эксплуатация | Логи, мониторинг, поддержка, стоимость | Не определены SLA и release gate |
Что проверить
Что подготовить для честной оценки
- Описать один приоритетный процесс и текущий baseline.
- Назвать пользователей, владельца процесса и стоимость критической ошибки.
- Показать реальные примеры данных и ограничения доступа.
- Выделить интеграции и действия, которые влияют на внешние системы.
- Согласовать критерии stop/go и состав результата пилота.
Как мы подходим к задаче
CENTURY разделяет оценку на discovery, проверку ключевых неизвестных и промышленный контур. Диапазон уточняется по доказательствам; ранняя точная цифра без данных обычно лишь прячет риск в change requests.