# Стоимость PoC с ИИ для реальных проектов

> Стоимость PoC с ИИ составляет от 15 000 до 150 000 долларов. Сравните бюджеты, факторы цены, границы работ и условия фиксированной оплаты.

Проверка концепции ИИ должна помочь принять решение, а не дать еще одну красивую демонстрацию. Если результат не позволяет понять, финансировать идею, изменить ее, купить готовое решение или закрыть проект, бюджет потрачен зря, даже если модель эффектно выглядела на встрече.

Для планирования я использую диапазон от 15 000 до 150 000 долларов. На нижней границе находится узкий рабочий процесс с чистыми данными и одной интеграцией. На верхней границе находится агентная система или сценарий из регулируемой отрасли, где нужны несколько систем, серьезная оценка, проверка безопасности и правдоподобный путь к промышленной эксплуатации. Это мои ориентиры для оценки проектов, а не универсальный прайс-лист. Итоговую сумму меняют ставки команды, состояние данных, уровень риска и доказательства, которые нужно получить в конце.

При оценке PoC полезно отделять новизну модели от неопределенности разработки. Знакомая модель, подключенная к шести ненадежным системам, может стоить дороже специальной модели, которую проверяют на одном чистом наборе данных. Основатели часто считают расходы на ИИ и не замечают всю обвязку. Обычно первый большой счет приходит именно за нее.

## Стоимость PoC с ИИ должна покупать решение

Бюджет должен соответствовать ценности и сложности решения, которое вам предстоит принять. Команде с вопросом «Может ли языковая модель достаточно хорошо классифицировать эти обращения в поддержку, чтобы оператор проверял результат?» нужно меньше доказательств, чем команде с вопросом «Может ли система одобрять страховые требования без неприемлемого финансового и регуляторного риска?»

Сформулируйте решение до технического задания. В полезной формулировке есть четыре части: пользователь, задача, измеримый порог и последующее действие. Например: «Если помощник правильно ответит минимум на 85 процентов из 200 утвержденных тестовых вопросов, укажет предоставленный источник и сохранит медианное время ответа ниже пяти секунд, мы профинансируем промышленный пилот». Эти числа приведены для примера, это не готовые нормативы. Ответственный руководитель должен выбрать пороги с учетом экономики и риска конкретного процесса.

Так становятся видны различия между тремя понятиями, которые команды постоянно смешивают:

- Прототип доказывает, что конкретное взаимодействие технически можно создать.
- PoC проверяет, выполняется ли определенное техническое или деловое утверждение при заданных условиях.
- Промышленный пилот проверяет окружающую ИИ операционную систему с реальными пользователями, средствами контроля, поддержкой и мониторингом.

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

Небольшой PoC часто занимает от четырех до восьми недель. Проект с большим объемом данных, отраслевыми ограничениями или несколькими интеграциями может занять от восьми до шестнадцати недель. Срок должен соответствовать циклу обучения, а не формальному календарю. Если эксперты способны разметить только двадцать примеров в неделю, дополнительные инженеры не ускорят появление доказательств.

## Реалистичный бюджет зависит от типа PoC

У разных типов PoC разная структура расходов, поэтому одно среднее число бесполезно. Диапазоны ниже предполагают небольшую команду опытных специалистов, ограниченный сценарий, готовые облачные сервисы или модели там, где они подходят, и письменную оценку результатов. Они не включают широкий промышленный запуск, круглосуточную поддержку, крупные лицензии на ПО и существенную закупку данных.

| Тип PoC | Ориентир бюджета | Обычный срок | Что должен доказать бюджет |
| --- | ---: | ---: | --- |
| Автоматизация процесса с готовой моделью | 15 000-30 000 долларов | 3-6 недель | Одна ограниченная задача проходит через процесс с приемлемыми затратами на проверку человеком |
| Поисковый помощник по знаниям компании | 20 000-45 000 долларов | 4-8 недель | Ответы полезны, опираются на разрешенные материалы, учитывают права доступа и приходят достаточно быстро |
| Прогнозная модель на структурированных данных | 30 000-75 000 долларов | 6-12 недель | Доступные признаки превосходят текущий базовый метод на отложенном наборе данных |
| Распознавание изображений, речи или извлечение из документов | 40 000-100 000 долларов | 6-14 недель | Система обрабатывает реальные образцы с нужной точностью и допустимой долей исключений |
| Агентная или близкая к промышленной система | 50 000-150 000 долларов | 8-16 недель | Система выполняет ограниченный процесс с контролем, журналом действий и ограниченными последствиями отказа |

Автоматизация процесса обходится дешевле всего, когда модель делает одно узкое преобразование, а человек утверждает результат. Например, готовит черновик ответа, относит входящий запрос к категории или извлекает поля перед проверкой сотрудником. Цена быстро растет, если под словом «автоматизация» на самом деле скрывается переделка всего процесса.

Поисковому помощнику нужен не один экран чата. Нужны загрузка документов, разбиение на фрагменты или другой метод поиска, управление доступом, тестовый набор, правила указания источников и порядок работы с вопросами без ответа. Публичный справочный бот по пятидесяти чистым страницам окажется у нижней границы. Внутренний помощник по договорам, заявкам и документам с доступом по ролям быстро поднимется выше.

В традиционном прогнозном проекте на разметку и восстановление признаков часто уходит больше денег, чем на обучение модели. Если целевой результат не записан, фиксируется непоследовательно или становится известен только через долгое время, проект может провалиться еще до выбора алгоритма. Достоверный PoC сравнивает модель с текущим правилом или решением человека, а не с нулем.

Стоимость работы с изображениями, речью и документами растет вместе с разнообразием образцов. Десять чистых счетов одного шаблона могут создать впечатление, что извлечение уже готово. Добавьте сканы, фотографии с телефона, рукописный текст, несколько языков и таблицы на разных страницах, и очередь исключений покажет другую картину.

Агентные системы стоят дороже всего, потому что команда должна проверять действия, а не только ответы. В объем работ входят права инструментов, повторные попытки, частичное выполнение, точки подтверждения, восстановление состояния и журнал действий. Сценарная демонстрация успешного пути может убедительно выглядеть за 20 000 долларов, но она не отвечает на вопрос, безопасно ли агенту работать с реальным заказом, репозиторием или записью клиента.

## Полная оценка включает больше, чем работу с моделью

Защищаемая оценка включает исследование задачи, данные, реализацию, интеграцию, проверку и передачу результата. Если одной из этих строк нет, кто-то, скорее всего, решил, что ее бесплатно выполнит другая команда.

В оценке PoC я ожидаю увидеть следующие блоки работ:

1. Проектирование решения: границы сценария, базовый уровень, метрики успеха, условия провала и назначенный владелец решения.
2. Готовность данных: доступ, выборка, очистка, разметка, проверка прав и зафиксированный набор для оценки.
3. Создание системы: выбор модели или сервиса, промпты или признаки, поиск, оркестрация и минимальный пользовательский интерфейс.
4. Подключение и контроль: обязательные интеграции, аутентификация, журналирование, подтверждение человеком и обработка тайм-аутов или плохих результатов.
5. Оценка и передача: повторные тесты, разбор ошибок, расчет расходов, описание архитектуры и рекомендация.

Для поискового помощника стоимостью 40 000 долларов разумное распределение может выглядеть так: 5 000 долларов на проектирование решения, 8 000 на подготовку данных, 12 000 на поиск и приложение, 7 000 на одну интеграцию и управление доступом, 8 000 на оценку и передачу. Это рабочий пример бюджета, а не таблица тарифов. Он помогает рано обнаружить расхождения. Если клиент ожидает пять интеграций, а строка подключения оплачивает только одну, объем работ определен неверно еще до начала.

Расходы на использование модели во время PoC часто невелики по сравнению с разработкой, проверкой отраслевыми экспертами и подготовкой данных. Из этого не следует, что стоимость обработки запросов можно игнорировать. Во время теста измеряйте токены, вызовы, минуты медиа или время ускорителя, затем пересчитайте их на ожидаемый объем. Архитектура, которая проходит проверку качества, но теряет деньги на каждой выполненной задаче, не подтверждает деловую гипотезу.

Внутреннее время тоже входит в бюджет, даже если его нет в счете подрядчика. Владельцы продукта отвечают на вопросы о процессе. Специалисты по безопасности проверяют доступ. Отраслевые эксперты размечают примеры и разрешают спорные случаи. Финансовая или операционная команда проверяет экономику одной операции. Дешевое предложение, которое незаметно забирает сотни часов сотрудников, дешевым не считается.

## Плохие данные увеличивают бюджет до запуска модели

Неопределенность данных чаще всего увеличивает разумную исходную оценку. Команды говорят, что накопили данные за годы, а затем обнаруживают, что полезные поля лежат в выгрузках с меняющейся схемой, метки отражают несколько противоречащих друг другу политик, а разрешение на использование записей для тестирования модели никто не выдает.

Проведите платную проверку готовности данных до фиксации полной цены PoC, если выполняется хотя бы одно из условий:

- Команда не может предоставить репрезентативную выборку за два рабочих дня.
- Желаемый результат не записывается напрямую или его смысл со временем менялся.
- Конфиденциальные записи требуют маскирования, локального хранения или юридической проверки.
- Изображения, аудио или документы различаются по источнику, формату, языку или качеству.
- Отраслевые эксперты не согласны друг с другом по поводу правильного ответа для одних и тех же примеров.

Проверка должна завершиться реестром данных, профилем выборки, правилом разметки, разрешением на доступ и оценкой доли пригодного материала. Она также должна найти утечку целевого признака. Если признак описывает событие, которое произошло после прогнозируемого решения, модель покажет отличный результат в рабочей тетради и провалится на первом живом случае.

Не используйте итоговый тестовый набор для ежедневной настройки промптов и модели. Если команда постоянно смотрит на тестовые ошибки и подстраивается под них, тест превращается в обучающие данные. Разделяйте примеры по единице, которая будет иметь значение в работе. Для поддержки клиентов это может быть разделение по клиентам или периодам, а не случайное распределение сообщений из одного разговора между наборами.

Синтетические данные подходят для проверки форматов, обработки крайних случаев и нагрузки на систему. Сами по себе они не доказывают работу на неаккуратном человеческом поведении, которое генератор не воспроизвел. Дополняйте ими редкие случаи и проверяйте известные сбои. Для принятия решения оставьте достаточно реальных, репрезентативных образцов.

Если проверка показывает, что меткам нельзя доверять, остановитесь и исправьте процесс измерения. Более сложная модель на двусмысленных целях дает лишь более дорогую двусмысленность. Это полноценный результат PoC, потому что он предотвращает крупные расходы на основе ложной уверенности.

## Интеграции, контроль и оценка приносят сюрпризы

Количество интеграций само по себе плохо предсказывает цену. Трудозатраты зависят от поведения подключения. Читать стабильную выгрузку совсем не то же самое, что писать в рабочую систему с лимитами запросов, подробными правами, повторяющимися событиями и деловыми последствиями, если повторная попытка выполнится дважды.

Оценивайте каждое подключение по конкретному контракту: чтение или запись, способ аутентификации, доступные среды, объем данных, требование к задержке, поведение при ошибке и ответственный владелец. Если тестовой среды нет, для PoC может понадобиться имитатор или обратимое действие. Эта работа должна входить в объем. Формулировка «подключить CRM» объемом работ не считается.

Требования безопасности меняются вместе с границей действий. Помощнику, который читает публичную документацию, достаточно базовой защиты приложения. Системе, которая читает закрытые договоры, нужны передача личности пользователя, фильтрация по правам, решение о сроке хранения и доказательство того, что один пользователь не получит материалы другого. Агенту, который меняет записи, нужны инструменты с минимальными правами, правила подтверждения, идемпотентность и журнал действий.

NIST делит работу в AI Risk Management Framework на функции Govern, Map, Measure и Manage. Для PoC я бы не превращал весь фреймворк в бумажную процедуру. Я взял бы из него дисциплину: описать контекст и затронутых людей, выбрать меры для существенных рисков, записать остаточный риск и назначить одного владельца, который решит, позволяют ли доказательства перейти к следующему этапу. Реестр риска из четырех строк, который меняет архитектуру, лучше сорока страниц, которые никто не использует.

На оценку нужен отдельный бюджет, потому что качество не сводится к одному числу. Для поискового помощника могут понадобиться правильность ответа, опора на источник, корректный отказ, тесты прав доступа, задержка и стоимость одного решенного вопроса. Для системы извлечения важна точность полей вместе с долей документов, которые отправляются на проверку человеку. Для агента нужны доля выполненных задач, число недопустимых и повторных действий, а также восстановление после сбоя инструмента.

Сравнивайте с методом, который используется сейчас. В Rules of Machine Learning Google советует сначала определить метрики, выбрать простую первую модель и наладить конвейер. Я согласен с требованием простоты, но PoC не всегда нужна промышленная инфраструктура. Ему нужна достаточная часть реального пути данных и выполнения, чтобы проявить проверяемую неопределенность. Остальное можно имитировать, если явно записать, что еще не доказано.

## Фиксированная цена требует фиксированных доказательств

Фиксированная цена работает, когда зафиксированы входные данные, границы и доказательства приемки. Она не работает, когда покупатель предлагает подрядчику за одну сумму принять на себя неизвестное качество данных, бесконечные комментарии участников и неописанные интеграции. Подрядчик либо добавит большую премию за риск, либо защитит прибыль заявками на изменение объема.

Чистая схема состоит из исследования по фиксированной цене, за которым следует PoC по фиксированной цене. Исследование снимает вопросы доступа, изучает образцы, утверждает базовый метод и создает матрицу приемки. После этого вторая цена покрывает известную работу. Если неопределенность остается высокой, разделите PoC на этапы с верхним пределом расходов и решением об остановке после каждого.

Хорошее соглашение с фиксированной ценой описывает:

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

Никогда не пишите «работающий ИИ-помощник» в условиях приемки. Такая фраза не разрешит спор по счету. Используйте наблюдаемые доказательства, например: «На тестовом наборе v1 система дает утвержденный или равноценный допустимый ответ минимум на 170 из 200 вопросов, указывает подтверждающий источник для каждого ответа, не показывает ни одного документа за пределами группы доступа тестового пользователя и укладывается в согласованное время в 95 процентах запусков».

Фиксированная цена не должна фиксировать технические решения. Разрешите команде заменить модель, метод поиска или промпт, если результат и ограничения не меняются. Покупка конкретной реализации может запереть обе стороны в слабом подходе. Покупайте доказательства и материалы для передачи.

Платежные этапы должны соответствовать снятию рисков. Практический график может привязать платежи к утвержденному объему и доступу к данным, сквозной базовой версии, завершению оценки и итоговой передаче. Не привязывайте основную сумму к красивой демонстрации. Иначе презентация получает награду раньше доказательств.

## Матрица приемки не дает демонстрации обмануть вас

Матрицу приемки нужно создать до реализации, потому что она определяет, что именно должен выяснить проект. Она превращает расплывчатую цель в случаи, которые проходят проверку, проваливаются или обнаруживают отсутствующее правило.

Для помощника службы поддержки по базе знаний я мог бы использовать такой компактный вариант:

| Утверждение | Проверка | Порог | Доказательство | Решение при провале |
| --- | --- | --- | --- | --- |
| Отвечает на известные вопросы | Запустить 200 зафиксированных и утвержденных вопросов | 85% допустимых ответов | Результат по каждому вопросу и заметка проверяющего | Разобрать группы ошибок и повторить тест один раз |
| Подтверждает каждый ответ | Проверить возвращенные источники | У 100% ответов есть допустимое подтверждение | Найденный фрагмент и идентификатор источника | Не запускать пилот до исправления |
| Соблюдает права | Провести поиск с несколькими ролями | Ни одного документа без разрешения | Журнал проверки доступа | Остановить проект и пересмотреть архитектуру |
| Вписывается в процесс | Пять операторов используют систему на ограниченной очереди | Время проверки достигает выбранной цели | Временные отметки задач и обратная связь | Переделать взаимодействие или отклонить сценарий |
| Имеет приемлемую стоимость операции | Воспроизвести ожидаемую смесь задач | Ниже утвержденной цены выполненной задачи | Журнал использования и расчет расходов | Изменить архитектуру или отклонить экономику |

Значения приведены для примера. Повторно использовать стоит структуру. У каждого утверждения есть тест, выбранный бизнесом порог, доказательство, которое сохранит силу после встречи, и последствие. Без последнего столбца команды незаметно снижают планку после получения результатов.

Оценивайте группы ошибок, а не только общий балл. Если помощник дает 90 процентов правильных ответов в целом, но ошибается почти во всех вопросах о правилах отмены, решение о запуске зависит от частоты этой категории и цены неверного ответа. Среднее значение скрывает сосредоточенный риск.

Записывайте конфигурацию каждого запуска: версию модели, версию промпта или признаков, настройки поиска, версию набора данных и существенные системные параметры. Данных должно хватать для воспроизведения результата. Снимок экрана с удачным ответом доказывает только то, что один удачный ответ когда-то появился.

В материалы для передачи включите отвергнутые подходы и оставшиеся неизвестные. Будущим инженерам нужно знать, почему метод не сработал, какие тесты нестабильны и что в PoC имитировалось. Иначе промышленная команда заплатит за повторное открытие того же результата.

## Небольшая опытная команда обычно обходится дешевле

Для большинства PoC нужны от двух до четырех активных разработчиков, а не уменьшенная копия корпоративной программы. В практичной команде может быть один технический руководитель, который отвечает за архитектуру и результат, один инженер по ИИ или данным и один продуктовый инженер для процесса и интеграции. Отраслевой эксперт и специалист по безопасности участвуют неполный день. В узком проекте один человек способен исполнять несколько ролей, но у каждой обязанности все равно должен быть владелец.

Дополнительные специалисты ускоряют независимые задачи, однако в PoC много последовательных решений. Выбор модели зависит от образца данных. Поток приложения зависит от ранних ошибок. Схема оценки зависит от того, что проверяющие способны оценивать одинаково. Пять разработчиков не распараллелят отсутствующее определение слова «правильно».

Опытные специалисты стоят дороже в день и часто дешевле в пересчете на полученный ответ. Они быстро отказываются от привлекательных тупиков, повторно используют проверенные компоненты и понимают, когда упрощение для демонстрации обесценит тест. Начинающие сотрудники хорошо помогают в работе с ясными границами, но предложение, основанное в основном на дешевых часах, может потратить эти часы на поиск самих границ.

При сравнении подрядчиков дайте им одну и ту же одностраничную постановку и попросите вынести предположения отдельно. Изучите предложенную оценку, исключения, время сотрудников клиента, права на результаты и пробелы до промышленной версии. Низкая сумма без разметки, проверки безопасности и разбора ошибок означает другой продукт, а не лучшую цену.

Спросите, кто на самом деле будет работать над проектом. Регалии продавцов ничего не значат, если названный технический руководитель исчезает после стартовой встречи. Попросите один обезличенный пример тестового материала, например матрицу приемки или анализ сбоев, вместо подборки красивых снимков интерфейса. Так вы проверите, как команда рассуждает о доказательствах.

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

Права на результат тоже влияют на цену. Уточните, кому принадлежат специальный код, промпты, размеченные примеры, тестовые случаи и созданная документация, а какие повторно используемые компоненты остаются подрядчику. Дешевый PoC, который нельзя поддерживать или повторно тестировать без первой команды, способен создать дорогую зависимость. Когда важна скорость, такой обмен может быть приемлемым, но сделайте выбор до подписания договора.

## Дешевый PoC работает только для узкого вопроса

PoC дешевле 15 000 долларов может принести пользу, если данные уже есть, процесс состоит из одного шага, подходит готовая модель, а для решения достаточно ограниченных доказательств. Недельное техническое исследование может показать, разбирается ли нужный формат файла, выдерживает ли API требуемое время ответа и заметен ли вообще прогнозный сигнал на небольшой размеченной выборке.

Не покупайте дешевый PoC, если решение несет высокий риск или его результату должны доверять несколько подразделений. Сокращение оценки, контроля доступа или отраслевой проверки не убирает работу. Оно переносит ее на время после демонстрации, когда ожидания изменить труднее.

Инструменты без программирования и с небольшим объемом программирования подходят для проверки взаимодействия или внутреннего процесса с умеренной нагрузкой. Они сокращают работу над интерфейсом и оркестрацией, если готовые подключения соответствуют вашим системам. Они не исправляют слабые метки, не определяют успех и не отменяют проверку прав и сбоев. Используйте их, когда они подходят проверяемой неопределенности, а не потому, что словосочетание «PoC с ИИ» якобы требует специальной разработки.

Сравнение с покупкой готового продукта часто дает правильный ответ. До заказа разработки проверьте, покрывает ли продукт поставщика типовой процесс и имеет ли ваше отличие значение для клиентов или операций. Разрабатывайте, если собственные данные, особый процесс, необычные средства контроля или существенная экономика одной операции создают преимущество. Покупайте, если процесс стандартен, а настройка быстрее приводит к решению.

Популярный совет «просто сделайте чат-бота по своим документам» неверен для многих первых проектов. Он популярен, потому что демонстрацию легко собрать, а интерфейс понятен руководителям. Он не работает, если никто регулярно не задает вопросы, права доступа запутаны или ответ не запускает полезное действие. Начните с дорогого ручного решения или передачи работы, затем определите, где ИИ сократит время или число ошибок.

## Готовность к промышленной работе требует отдельного бюджета

Успешный PoC разрешает принять следующее решение, но не отменяет промышленную разработку. Следующий бюджет может включать отказоустойчивую инфраструктуру, мониторинг, поддержку, обучение пользователей, реагирование на инциденты, доступность, проверку поставщика, управление жизненным циклом данных и усиление интеграций. Эти статьи нельзя тайком включать в оценку PoC, но и бесплатными после него они не станут.

Попросите команду PoC составить отчет о разрыве до промышленной версии с тремя столбцами: доказано, частично доказано и не проверено. Поисковый помощник мог доказать качество ответов на зафиксированном наборе, частично проверить фильтрацию прав в одной среде и не проверить промышленную нагрузку, восстановление после аварии и регулярное обновление содержания. Такая формулировка не дает фразе «PoC прошел» превратиться в «продукт готов».

Оцените следующий этап до итоговой презентации. Оценка может остаться диапазоном, но должна назвать дорогие неизвестные и вероятные операционные расходы. Тогда руководители сравнят полную стоимость с ожидаемой экономией или выручкой, а не только с привлекательной ценой первого эксперимента.

Критерии закрытия проекта нужно включить в исходное соглашение. Остановитесь, если пригодные данные не поддерживают утверждение, базовый метод уже удовлетворяет деловую потребность, обязательный контроль разрушает экономику или владелец процесса не станет внедрять изменение. Остановленный PoC с записанными доказательствами выполнил свою задачу.

В oleg.is я использую аудит команды и ИИ с фиксированной ценой, чтобы найти экономию на разработке и выбрать первое ограниченное изменение до финансирования крупного проекта. Для PoC с ИИ действует та же дисциплина: сначала платите за снятие неопределенности, которая может сделать бессмысленным каждый следующий доллар.

Не заканчивайте проект постановочной демонстрацией и аплодисментами. В конце должны остаться результаты на зафиксированном тесте, группы ошибок, расчет расходов, реестр рисков, пробелы до промышленной версии и подписанное решение. Если команда не может собрать этот пакет, PoC создал ПО, но не создал доказательство.