Где заканчивается прототип и начинается продукт: границы AI-архитектуры

> Демо закончилось в 16:40. Заказчик откинулся в кресле, посмотрел на экран, где AI-ассистент бодро отвечал на вопросы, и сказал фразу, которую я слышал, наверное, сотню раз:

Ну что, мы почти закончили? Я не стал отвечать сразу. Налил воды. Потому что знал: если сказать правду сейчас, человек решит, что я набиваю цену. А если промолчать — через три месяца он вернётся с вопросом, почему «почти готовый продукт» не выдерживает первого реального клиента. Давайте честно. То, что вы видели на экране, — это примерно 15% работы. Может, 20. Остальное — под водой. И сегодня я хочу показать, что именно там скрывается. Не чтобы напугать. Чтобы вы понимали, за что платите.

Улика первая: скелет, которого не видно

Начну с модели данных. Скучно? Ещё как. Но именно здесь закладывается всё остальное.

В прототипе данные живут там, где их удобно положить. Массив в памяти. Локальный JSON. Таблица на пять полей. Работает — и ладно.

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

Если положа руку на сердце — 80% проектов, которые я видел умирающими, умирали не из-за плохого кода. Они умирали из-за модели данных, которую слепили на коленке на второй неделе и потом героически тащили два года.

Модель данных — это не «таблицы». Это ответ на вопросы: что мы вообще храним, что считаем фактом, что — производным, а что можно пересчитать. Пока вы не ответили на эти вопросы, у вас нет продукта. У вас есть красивая картинка.

Улика вторая: интеграции и «счастливый путь»

Дальше — интеграции. Здесь начинается самое интересное.

В демо всё работает по «счастливому пути»: пользователь нажал, система ответила, данные сохранились. Красота. Но реальность — это когда внешний сервис отвечает через 30 секунд вместо двух, а иногда не отвечает вообще. Когда вебхук приходит дважды. Когда приходит вчерашний вебхук. Когда приходит вебхук, которого вы не ждали.

Помню проект, где мы подключили платежи. Всё работало идеально, пока один клиент не оплатил дважды одну подписку — потому что браузер завис, он нажал ещё раз, а идемпотентности мы не заложили. Мелочь? Да. Стоила двух дней разбирательств и одного неприятного разговора.

Интеграция — это не «мы подключили API». Это договор о том, как вы ведёте себя, когда партнёр ведёт себя странно. Retry. Идемпотентность. Очереди. Обработка ошибок, которые никто не предусмотрел, потому что их «не может быть».

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

Улика третья: роли, доступ и первый настоящий клиент

Дальше — роли. В прототипе обычно два типа пользователей: «я» и «все остальные». Иногда добавляется «админ», который может всё.

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

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

Я видел, как из-за одной неверной проверки прав клиент потерял контракт. Не потому что данные украли. А потому что менеджер конкурента увидел цифры, которые видеть не должен был. Система работала. Просто работала неправильно.

Улика четвёртая: аудит и чёрный ящик

Теперь про то, о чём вспоминают в последнюю очередь. Аудит.

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

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

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

Улика пятая: тест в три часа ночи

Отказоустойчивость — это не «сервер не падает». Это ответ на вопрос: что делает система, когда что-то уже упало?

Что будет, если упадёт база? Если отвалится внешний API? Если кончится место на диске? Если один из сервисов начнёт отвечать медленно, но не откажет? Если внезапно станет в десять раз больше запросов?

Прототип на эти вопросы не отвечает. Продукт — отвечает. Иногда ответ звучит как «мы деградируем аккуратно, показываем понятную ошибку и не теряем данные». Это тоже ответ. Главное, чтобы он был.

Помню, как мы впервые получили настоящую нагрузку. Всё было хорошо. До момента, когда один из сервисов начал молча копить очередь задач. Он не падал. Он просто не успевал. И узнали мы об этом не из мониторинга, а из звонка клиента: «А почему у меня цифры не обновляются?».

С тех пор я не верю в отказоустойчивость, которую не проверяли руками. Убить сервис, отключить базу, залить канал — и посмотреть, что будет. Если страшно — значит, вы ещё не в продукте.

Улика шестая: эксплуатация и счёт, о котором молчат И последнее. То, о чём на демо не говорят вообще.

Эксплуатация — это не разовая работа. Это то, что происходит каждый день после запуска. Мониторинг. Логи. Обновления. Бэкапы. Восстановление. Реакция на инциденты. Стоимость. Да, стоимость — потому что облако не бесплатное, и запросы к моделям тоже стоят денег.

Говоря языком цифр: я видел проекты, где счёт за инфраструктуру превышал выручку. Не потому что плохая архитектура. А потому что про неё никто не думал, пока не стало поздно.

Эксплуатация — это ответ на вопрос: кто и что делает, когда это самое «что-то» случается. Если ответа нет, у вас не продукт. У вас есть демо, которое однажды перестанет работать.

Развязка: айсберг

Вот и всё. Шесть слоёв. Модель данных. Интеграции. Роли. Аудит. Отказоустойчивость. Эксплуатация.

Ни один из них не виден на экране. Ни один не показывают на демо. Но именно они отличают прототип от продукта. Именно за них платит заказчик — часто сам не зная об этом.

Такова селяви, как говорят французы. Красивый экран — это верхушка айсберга. И если вы платите только за верхушку, вы получаете то, что рано или поздно тонет.

Я не питаю иллюзий: никому не нравится платить за то, чего не видно. Ни заказчику, ни инвестору. Но именно невидимая часть делает продукт продуктом, а не красивой картинкой.

И если вы спросите меня, где заканчивается прототип и начинается продукт, я отвечу так: прототип заканчивается там, где заканчивается «счастливый путь». Продукт начинается там, где вы начинаете думать о том, что будет, когда всё пойдёт не по плану.

Все в наших силах. Это порой элементарно — просто об этом нужно думать до, а не после.

Глоссарий терминов

• Прототип — ранняя версия системы, созданная для проверки идеи. Работает на демо-данных, не рассчитана на реальных пользователей и нагрузку.
• Продукт — система, готовая к эксплуатации реальными пользователями: выдерживает нагрузку, ошибки, обновления и время.
• AI-архитектура — структура AI-системы: слои данных, модели, интеграции, инфраструктура, границы ответственности между компонентами.
• Модель данных — формальное описание сущностей, их связей, полей и правил хранения. Один из ключевых артефактов архитектуры.
• Счастливый путь (happy path) — сценарий, в котором всё идёт по плану: данные корректны, сервисы доступны, пользователь ведёт себя ожидаемо.
• Интеграция — связь системы с внешним сервисом или другой системой. Описывается контрактом и сценариями поведения при сбоях.
• Идемпотентность — свойство операции давать один и тот же результат при повторном выполнении. Критично для платежей и вебхуков.
• Вебхук — механизм, при котором внешняя система сама отправляет уведомление о событии на ваш сервис.
• Production (прод) — рабочая среда, где система используется реальными пользователями под реальной нагрузкой.
• Нагрузка — объём запросов и данных, который система должна обрабатывать без деградации.
• Масштабирование — способность системы справляться с ростом нагрузки за счёт ресурсов или архитектурных решений.
• Отказоустойчивость — свойство системы продолжать работу при сбоях отдельных компонентов.
• Мониторинг — непрерывное наблюдение за состоянием системы: метрики, логи, алерты.
• Технический долг — накопленные компромиссы в коде и архитектуре, которые замедляют развитие и требуют переделок.
• Системное мышление — способность видеть систему целиком и понимать связи между её частями.
• Слой системы — отдельный уровень архитектуры: данные, логика, интеграции, инфраструктура, интерфейс.
• Границы системы — описание того, что входит в продукт, что остаётся снаружи и где проходит контур ответственности.
• API — программный интерфейс для взаимодействия между системами.
• Стек технологий — набор инструментов, языков и платформ, на которых строится система.
• Технические риски — вероятность и влияние сбоев, связанных с архитектурой, данными, интеграциями и инфраструктурой.