Due diligence для маленькой AI-команды перед проверкой покупателем

Почему покупателей настораживают маленькие AI-команды

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

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

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

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

Опасения становятся совсем очевидными на простом примере. Если сбой начался в 2 часа ночи, кто получит оповещение, кто сможет откатить релиз и кто решит, безопасно ли выкатывать AI-сгенерированный патч? Если ответы размыты, покупатель начинает снижать оценку бизнеса.

Маленькие команды всё равно могут выглядеть сильными. Разница в контроле. Покупатели доверяют скорости, когда одновременно видят владельцев процессов, этапы проверки и чёткие границы того, что AI может делать сам.

Сначала составьте карту ответственности

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

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

Для каждой области назначьте одного основного владельца и одного запасного. Используйте имена, а не должности. «Инженерия» — это слишком расплывчато. «Майя отвечает за выкладку в прод, Алекс — запасной» — уже понятно.

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

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

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

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

Напишите runbooks для работы, которая не может остановиться

Покупателю недостаточно услышать: «Обычно этим занимается Сам». Ему нужно доказательство, что работа продолжится, даже если один человек заболел, спит или ушёл. Хорошие runbooks превращают знания в голове в простые инструкции.

Делайте их короткими. Часто хватает одной страницы. Если задача требует большего, разбейте её на короткий чек-лист и отдельную заметку на случай исключений.

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

Пишите шаги простым языком. По возможности избегайте внутреннего жаргона. «Откройте дашборд, проверьте уровень ошибок и остановите релиз, если сбои превысят 2%» — куда лучше, чем тяжёлый абзац, полный командного сленга.

Каждый runbook должен отвечать на одни и те же практические вопросы. Где хранятся доступы? Кто может получить их сегодня? Кто отвечает первым, а кто подстраховывает? Сколько обычно занимает задача, если всё идёт нормально?

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

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

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

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

Объясните, где помогает AI, а где решение принимает человек

Покупатели не паникуют из-за того, что вы используете AI. Они паникуют, когда не понимают, кто на самом деле принимает решения. Вам нужен простой учёт того, что агенты делают каждый день, где человек проверяет результат и кто принимает финальное решение.

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

Такая детализация быстро успокаивает людей. Она показывает, что AI ускоряет рутинную работу, а люди по-прежнему контролируют всё, что может сломать продукт, навредить клиентам или создать юридические проблемы.

Зафиксируйте AI-стек

Перечислите точные модели, инструменты и цепочки prompt'ов, от которых зависит команда. Укажите провайдера, задачу, которую он выполняет, инструмент, который это запускает, и запасной вариант на случай сбоя. Если один агент пишет SQL, скажите, кто проверяет изменения в базе данных. Если другой обрабатывает поддержку, укажите, когда тикет передаётся человеку.

Храните шаблоны prompt'ов, системные правила и правила утверждения в одном месте. Достаточно репозитория с версиями или контролируемой внутренней папки. Покупатели хотят видеть, что prompt'ы не разбросаны по чатам и личным заметкам.

Ограничьте, кто может менять автоматизацию

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

Если покупатель спросит: «Кто сможет завтра изменить support-бота?» — вы должны ответить одним предложением.

Зафиксируйте контроль над расходами

Покупатели начинают нервничать, когда затраты живут в пяти разных дашбордах, а никто не может объяснить общий месячный счёт. Маленькая AI-команда может выглядеть эффективной на поверхности, но проверка усложняется, если облачные расходы, использование моделей, софт и счета подрядчиков лежат в разных местах.

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

Месячные лимиты важны не меньше текущих расходов. Поставьте жёсткий потолок для каждой крупной категории и добавьте пороги оповещения до того, как лимит будет достигнут. Распространённая схема — оповещение на 70%, ещё одно на 85% и ручная проверка до того, как кто-то поднимет лимит. Покупатели не ждут идеальной стабильности. Им нужно доказательство, что никто не проснётся утром с неожиданным счётом.

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

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

Храните доказательства в одной папке или data room. Складывайте туда счета, выгрузки использования, договоры подрядчиков и ежемесячные сводки. Если покупатель спросит, почему в феврале изменились расходы, ваша команда должна ответить за две минуты, а не за два дня.

Покажите, что компания сможет продолжить работу

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

Чаще всего это важнее, чем сам размер команды. Маленькие команды выглядят безопасно, если ответственность понятна, доступы контролируются, а рутинная работа не живёт только в голове у одного человека.

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

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

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

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

Отпуск — хороший тест. Если основатель может исчезнуть на неделю, а компания всё равно выпускает обновления, отвечает клиентам и обрабатывает оповещения, это многое говорит покупателю. Здесь «AI-first operations» перестаёт звучать как лозунг и начинает означать что-то практическое: система продолжает работать, даже когда один человек отходит в сторону.

Простой сценарий buyer review

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

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

Следующий вопрос не менее прямой: «Как AI-написанные изменения попадают в продакшен?» Размытый ответ вредит вам. Чёткий runbook успокаивает людей.

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

Потом они спрашивают про деньги. «Почему расходы на модель выросли в прошлом квартале?»

Откройте данные по использованию по команде, проекту или рабочему процессу. Возможно, новый batch job или скачок объёма prompt'ов поднял расходы на три недели. Это нормально, если вы можете это объяснить. Затем покажите лимит, который вы добавили после всплеска, кто получает оповещение, когда расходы переходят порог, и что происходит, когда использование достигает предела.

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

План подготовки на 30 дней

Тридцать дней достаточно, чтобы превратить разрозненные знания в доказательства, готовые для покупателя, если работать просто и прямо. Цель очень понятная: показать, кто за что отвечает, как делается работа и что не даёт расходам расползаться.

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

Во вторую неделю напишите runbooks для работы, которую нельзя ставить на паузу. Начните с деплоев, инцидентов и проблем с оплатой. Хороший runbook короткий. Он должен объяснить новому человеку, что запускает задачу, куда войти, какие шаги сделать и когда эскалировать. Если продакшен ломается в 2 часа ночи, команде не нужно гадать.

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

Четвёртая неделя нужна для проверки под давлением. Проведите mock buyer Q&A с командой и используйте настоящие вопросы. Кто может быстро выпустить hotfix? Что произойдёт, если основной AI-процесс сломается? Какие вендоры сложно заменить? Где лежат доступы? Обычно часовой drill быстрее выявляет слабые места, чем ещё один документ.

К 30-му дню вам не нужна идеальная компания. Вам нужна компания, которую другой оператор может понять за один присест.

Ошибки, которые вызывают тревогу

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

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

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

Лучший ответ звучит конкретно: «Этот агент готовит тест-кейсы. Инженер проверяет их перед merge. Мы его оставили, потому что он экономит около шести часов в неделю и не касается продакшена». Это показывает намерение, границы и ответственность.

Если покупатель указывает на любую систему и спрашивает, кто ею владеет, как она работает, сколько стоит и что будет при сбое, ваша команда должна ответить за две минуты.

Быстрые проверки перед встречей с покупателем

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

Скорость почти так же важна, как и сам ответ. Если вы можете открыть одну папку или один короткий документ и за минуты ответить на обычные вопросы, встреча остаётся спокойной.

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

Расходы тоже должны быть легко показаны. Храните один актуальный вид облачных затрат, счетов за AI API, подписок на софт и оплат подрядчикам. Если кто-то спросит, что изменилось в этом месяце, вы должны ответить без поиска по старым счетам и пяти дашбордам.

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

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

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

Полезно правило: если покупатель спрашивает «кто этим владеет, сколько это стоит и как оно продолжает работать», вы должны ответить на каждый пункт примерно за минуту.

Что делать дальше

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

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

Превратите каждый повторяющийся вопрос покупателя в документ. Если кто-то спрашивал, кто отвечает за биллинг, где лежат prompt'ы, как работают деплои или кто может отозвать доступ, запишите ответ один раз и держите его в пакете документов. Вторая встреча должна быть легче первой, потому что меньше ответов живёт только в чьей-то голове.

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

Потом проверьте документы вживую. Проведите один tabletop-drill для сбоя сервиса. Возьмите вероятный сценарий отказа, поставьте таймер на 30 минут и пройдите, кто что делает, кто общается с клиентами и как команда откатывает изменения.

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

Со стороны может помочь внешний взгляд, если команда слишком близка к собственному процессу. Oleg Sotnikov на oleg.is делает такую Fractional CTO работу со стартапами и небольшими компаниями, в том числе проверяет техническую операционку, инфраструктуру и AI-процессы перед важными проверками.

Приходите на встречу с четырьмя чистыми вещами: картой ответственности, runbooks, контролем расходов и заметками по обоим drill'ам. Это покажет покупателю, что компания работает на процессах, а не на памяти.