Кто должен отвечать за программу перехода на AI в стартапе?

Почему ответственность ломает AI-программы

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

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

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

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

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

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

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

Два теста, которые действительно важны

Обычно вопрос решают два теста: как быстро нужно принимать решения и сколько будет стоить ошибка.

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

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

Помогает простая таблица:

• Скорость решений: должен ли владелец решать ежедневно, еженедельно или ежемесячно?
• Цена ошибки: если он ошибётся, это съест несколько часов или ударит по клиентам и выручке?
• Обратимость: можно ли откатить изменение за день или на это уйдут недели?
• Масштаб: затрагивает ли изменение одну команду или всю компанию?

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

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

Сопоставляйте ответственного со скоростью работы и размером возможной ошибки.

Когда ответственность должен взять на себя фаундер

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

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

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

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

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

Ограничьте срок ответственности фаундера. Обычно 30–90 дней хватает, чтобы поставить цели, выбрать несколько ставок и снять блокеры. После этого ежедневное выполнение должно перейти к одному человеку, у которого есть пространство для работы. Фаундер всё ещё должен смотреть прогресс, но не должен застревать в правках промптов, выборе инструментов и деталях процессов.

Когда ответственность должен взять на себя операционный лидер

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

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

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

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

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

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

Когда ответственность должен взять на себя технический лидер

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

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

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

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

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

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

Когда ответственность должен взять на себя внешний советник

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

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

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

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

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

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

Как пошагово выбрать ответственного

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

Запишите первые три решения, которые команде нужно принять в ближайшее время. Сделайте их конкретными. Например: какой процесс автоматизировать первым, нужен ли человеческий контроль у customer-facing AI и кто может утверждать изменения в продукте или внутреннем процессе.

Дальше пройдите пять шагов:

1. Назовите человека, который может закрыть каждое решение за одну встречу.
2. Если для решения нужна цепочка согласований, значит, никто из этой цепочки пока не владеет работой.
3. Запишите ошибку, которая повредит сильнее всего, если проект пойдёт не так. Это может быть плохой результат для клиента, ошибки безопасности, потерянное время инженерной команды или запуск, которым сотрудники откажутся пользоваться.
4. Посмотрите, кто контролирует решения, связанные с этой ошибкой. Обычно именно этот человек и является лучшим владельцем.
5. Назначьте одного партнёра, который закроет пробелы. Если владелец понимает бизнес, но не технику, соедините его с техническим лидером или fractional CTO. Если владелец понимает технику, но не может менять процессы, соедините его с операционным лидером или фаундером.

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

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

Простой пример для стартапа

Представьте SaaS-компанию на 20 человек: четыре инженера, команда поддержки, один операционный лидер и фаундер, который всё ещё участвует в продажах. Компания хочет внедрить AI сразу в трёх местах: ответы поддержки, проверки качества перед релизом и заметки по продажам после демо. Это звучит разумно. Но на деле здесь три разных типа риска.

Фаундер должен отвечать за обещания клиентам и бюджет. Если AI меняет скорость ответов, скорость follow-up или то, что продажа говорит на демо, последнее слово должно быть за фаундером. Этот человек также может остановить команду от покупки лишних инструментов или от обещаний результатов до того, как процесс начнёт работать.

Технический лидер должен отвечать за автоматизацию QA и настройку инструментов. Это включает решение, как запускаются тесты, где именно AI вписывается в code review и что команда делает, если инструмент даёт плохой ответ. Эта работа слишком близка к поставке, чтобы инженерная команда ждала решений от кого-то снаружи каждый день.

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

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

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

Ошибки, которые уводят работу в сторону

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

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

Команды также тратят время на демо-театр. Они тестируют ботов для встреч, ассистентов для текста и внутренние chat tools, но так и не улучшают одну повторяющуюся задачу, которая каждую неделю съедает часы. Стартапу гораздо больше пользы даст минус 30 минут в triage поддержки, чем пять остроумных прототипов в слайд-деке.

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

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

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

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

Короткие проверки перед назначением роли

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

Задайте пять прямых вопросов:

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

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

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

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

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

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

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

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

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

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

Oleg Sotnikov делает такую работу через oleg.is как fractional CTO и startup advisor. Он помогает малому и среднему бизнесу выстраивать практичные планы внедрения AI, ужимать технический объём и возвращать ежедневную ответственность внутренней команде, когда первый запуск уже работает.

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