Вероятностный результат
Классическое ПО детерминировано: нажал кнопку — получил предсказуемый результат, и тестирование проверяет совпадение с эталоном. Языковая модель отвечает вероятностно: на сто одинаковых вопросов она может ответить девяносто раз правильно и десять раз ошибиться, и «пропатчить баг в одной строке» здесь не существует. Это меняет саму приёмку: вместо «работает/не работает» фиксируются метрики — доля корректных ответов на тестовой выборке, доля эскалаций на человека, время ответа. Заказчик ИИ-проекта должен понимать: приёмка идёт по статистике, и честный подрядчик показывает выборку, на которой она набрана.
Данные — это часть продукта
В обычной разработке исходный код — главный актив. В ИИ-разработке активов два: код обвязки и данные — обучающие примеры, база знаний, промпты. Датасет надо версионировать (какой версией базы отвечал ассистент в марте?), чистить (мусор на входе — галлюцинации на выходе) и защищать (утёкшая база знаний — это утёкшая интеллектуальная собственность). Отсюда целые дисциплины, которых в классических проектах нет: подготовка данных для RAG, защита обучающих данных, учёт ИИ-активов.
Тестирование: не QA, а лаборатория
Обычный тест-инженер гоняет сценарии «ожидание — результат». ИИ-тестирование ближе к эксперименту: наборы вопросов, эталонные ответы, замеры качества до и после каждого изменения, поиск галлюцинаций и jailbreak-сценариев. К этому добавляется безопасность: промпт-инъекции, попытки вытащить системный промпт, злоупотребление полномочиями агентов. Зрелые команды проводят красные командные тесты до релиза. Частые ошибки заказчиков на этом этапе — вера, что «модель умная, сама справится», разобраны в ответе какие ошибки чаще всего при внедрении ИИ.
Договор и деньги
Классический контракт: фиксированное ТЗ, фиксированный срок. В ИИ-проектах жёсткая фиксация «всего» — ловушка для обеих сторон: качество модели на ваших данных нельзя пообещать до измерений. Отсюда лестничная модель, ставшая отраслевой нормой: разбор бесплатно за 1 день → аудит от 90 000 ₽ → прототип от 90 000 ₽ → MVP от 690 000 ₽ → пилот от 480 000 ₽ → промышленный контур 0,9–1,2 млн ₽. Каждая ступень оплачивается после измеримого результата предыдущей. Почему ИИ-проекты выходят дороже сметы, если строить их по классической схеме, — в ответе почему ИИ-проекты дороже сметы.
Релиз — это середина, не конец
Обычную систему сдали — и она работает годами. ИИ-система без сопровождения деградирует: документы устаревают, вопросы пользователей меняются, появляются новые сценарии атак. Сопровождение ИИ — от 50 000 ₽/мес за качество и базу знаний — не «навязанная услуга», а часть стоимости владения, как бензин для автомобиля. Это прямое следствие вероятностной природы: качество — не свойство кода, а статистика, которую надо поддерживать.
Что это значит для заказчика
- Требуйте метрики приёмки в договоре: выборка, доля корректных ответов, критерий успеха пилота.
- Спрашивайте про данные до старта: кто готовит, кто владеет, где хранится, как защищается.
- Планируйте сопровождение в бюджете с первого дня, а не как «неожиданные расходы» после релиза.
- Бойтесь фиксированных обещаний качества до измерений — это признак подрядчика, который не измерял.
Как составить ТЗ, учитывающее вероятностную природу, — в гайде как составить ТЗ на ИИ-ассистента; помощь с методологией — на странице услуги ИИ-консалтинг; примеры ассистентов — в разделе ИИ-ассистенты.
Кто входит в ИИ-команду
Классическая команда — аналитик, разработчик, тестировщик, проектировщик. В ИИ-проекте к ним добавляются роли, которых раньше не было. Дата-инженер готовит данные: собирает, чистит, нарезает, версонирует. Промпт-инженер проектирует инструкции модели и фильтры — от его работы зависит половина качества ответов. ML-инженер отвечает за контур: векторные базы, ретривер, метрики. Специалист по ИИ-безопасности проверяет контур на инъекции и утечки — на чувствительных данных это обязательная роль, а не роскошь. Для заказчика это практично значит: спрашивайте на старте, кто именно в команде отвечает за данные и за качество — если ответ «все», значит никто. В небольших проектах роли совмещаются, но вопросы про данные и метрики закрываются всегда.
Что заказчик должен подготовить сам
- Владельца процесса: человека, который знает, как процесс устроен сейчас и что считается хорошим результатом.
- Документы и данные: хотя бы в «сыром» виде — подрядчик почистит, но найти их может только заказчик.
- Правила игры: что можно в облако, что нельзя; кто подписывает доступы; как быстро отвечают смежные отделы.
- Терпение к измерениям: первые метрики будут неидеальными — это нормально, проект этим и отличается от «установил и работает».
Опыт один и тот же у всех зрелых команд: скорость ИИ-проекта упирается не в модель, а в скорость решений заказчика. Данные, доступы и ответы на вопросы — вот что отличает проект на 6 недель от проекта на 6 месяцев.
Признаки зрелого ИИ-подрядчика
Сводка раздела в виде сигналов, которые видны на первой встрече. Зрелый подрядчик предлагает лестницу, а не один большой контракт; сам спрашивает про данные и их режимы; называет метрики приёмки до вопроса о них; спокойно говорит «это делаем прототипом за 90 000 ₽, а не контуром за миллион»; различает RAG, fine-tuning и интеграцию как разные работы; про ошибки модели отвечает процессом (эскалация, источники, выборки), а не лозунгом. Незрелый — продаёт «искусственный интеллект вообще», боится вопросов про галлюцинации и не может объяснить, из чего состоит цена. Эта разница видна за час разговора — дешевле потратить этот час, чем год расхлёбывать.
Итог
ИИ-разработка отличается от обычной не языком программирования, а тремя свойствами продукта: вероятностный результат (приёмка по метрикам), данные как актив (версионирование и защита) и бесконечный цикл (сопровождение качества). Кто понимает эти три отличия до старта — получает управляемый проект с лестницей ступеней. Кто требует «сделать как обычный сайт, только с ИИ» — получает то, за что потом платит дважды. Практический старт одинаков для всех: бесплатный разбор за 1 день и лестница ступеней вместо одного большого контракта — это и есть ИИ-разработка, отражённая в коммерческой модели.