Ответственность за ИИ: назначьте 3 лидеров, пока проекты не застопорились

Почему общая ответственность тормозит работу с ИИ

Общая ответственность за ИИ звучит справедливо. На практике она тормозит команды.

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

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

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

Чёткая ответственность за ИИ не означает, что один человек контролирует всё. Это значит, что три названных человека отвечают за три разные задачи:

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

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

Три владельца и их зоны ответственности

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

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

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

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

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

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

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

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

Как выбрать лидера по рискам

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

Не отдавайте эту роль самому громкому любителю ИИ. Дайте её человеку, который уже сегодня говорит да или нет по рискам. Так ответственность остаётся простой и не появляется ещё один слой споров.

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

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

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

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

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

Этого достаточно для первого пилота.

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

Как выбрать лидера по процессу

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

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

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

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

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

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

В небольших компаниях на раннем этапе эту роль часто берёт на себя фракционный CTO, потому что он может выстроить путь от идеи до релиза и заметить, где ИИ подходит, не ломая процесс. Oleg Sotnikov на oleg.is часто работает со стартапами именно так: держит процесс практичным, компактным и привязанным к реальной работе, а не к широким планам по ИИ.

Как выбрать лидера по внедрению

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

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

Здесь важна доверительная атмосфера. Люди должны спокойно говорить: «Этот шаг отнимает время» или «Подсказка работает, но проверка занимает слишком долго». Лидеру по внедрению тоже нужно терпение. Запуск ИИ редко проваливается потому, что инструмент плохой. Обычно он проваливается потому, что люди получают один неудачный результат, сомневаются и возвращаются к старому способу.

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

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

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

Как настроить это в первые 30 дней

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

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

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

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

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

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

Такой подход менее эффектный, чем большой запуск, но за 30 дней он даёт больше.

Простой пример из реальной команды

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

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

Чёткая ответственность быстро всё исправляет.

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

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

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

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

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

Ошибки, которые создают путаницу

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

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

Ещё одна проблема — формальная ответственность без полномочий. Менеджер добавляет «ИИ» в существующую должность, но у команды по-прежнему нет права принимать решения, правил проверки или времени на эту работу. Это не ответственность. Это ярлык.

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

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

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

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

Быстрая проверка перед запуском

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

• Попросите трёх человек в команде назвать владельцев по памяти. Все должны назвать одни и те же три имени.
• Проверьте разделение решений. Один человек отвечает за риск, один — за процесс, и один — за внедрение. Если два человека могут одобрить один и тот же вопрос, путаница быстро проявится.
• Запишите простые правила использования данных и проверки результатов. Команда должна понимать, что можно отправлять в инструменты ИИ, что должно оставаться за пределами, и кто проверяет результаты до того, как они попадут к клиентам, руководителям или в производственные системы.
• Сначала выберите один небольшой пилот и дайте сотрудникам один понятный путь помощи — это может быть общий чат, один ящик входящей почты или конкретный человек.

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

Если хотя бы одного из этих элементов нет, остановитесь и исправьте это до расширения.

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

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

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

Сделайте первый запуск маленьким, используйте одну понятную метрику и проверьте результаты через две недели. Цель вроде «сократить время подготовки первого черновика с 40 минут до 15» даёт команде конкретную проверку. «Использовать ИИ чаще» — нет.

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

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