Ответственный за ИИ в небольших компаниях: остановите расползание пилотов заранее

Почему начинается хаос пилотов

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

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

Сначала обычно ломается не качество моделей, а базовые операции:

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

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

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

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

Что на самом деле контролирует ответственный за ИИ

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

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

В большинстве небольших компаний этот человек контролирует четыре вещи:

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

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

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

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

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

Кому стоит взять эту роль

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

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

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

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

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

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

Какие правила написать до первого пилота

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

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

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

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

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

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

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

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

Постройте один маршрут проверки для новых инструментов

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

Большая комиссия по согласованию не нужна. Нужны простая форма заявки и понятный маршрут проверки. Форма должна начинаться с задачи, которую нужно улучшить, а не с названия инструмента. «Мы хотим сократить время ответа поддержки на 20 минут на тикет» — полезно. «Мы хотим Tool X» — нет.

Короткой формы достаточно, если она спрашивает:

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

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

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

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

План настройки на 30 дней

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

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

1. Дни 1–7: Назначьте ответственного и приостановите все новые покупки, тесты и регистрации команд в ИИ-инструментах. Текущую работу не останавливайте, но перестаньте добавлять новые приложения. Эта короткая пауза дает ответственному стабильную точку старта.
2. Дни 8–14: Составьте список всех активных пилотов. Отметьте, кто ими пользуется, какую проблему они решают, какие данные туда попадают и сколько они стоят в месяц. Многие команды обнаруживают три инструмента для одной и той же задачи, как только все записывают.
3. Дни 15–21: Опубликуйте простые правила. Решите, какие данные людям нельзя вставлять во внешние инструменты, кто может одобрить новый пилот, сколько длится тест и куда отправлять заявки. Достаточно одной формы или одного общего почтового ящика.
4. Дни 22–30: Сократите список. Оставьте пилоты с самым понятным применением и самым низким риском. Остальное остановите, отмените неиспользуемые места и задайте оставшимся пользователям один прямой вопрос: это действительно экономит время или нет?

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

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

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

Простой пример компании

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

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

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

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

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

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

Ошибки, которые создают еще больше работы

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

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

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

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

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

Если пилот не меняет реальную работу, остановите его. Если он экономит время, но нарушает ваши правила, исправьте правила или уберите инструмент. Кто-то должен быстро принять это решение.

Краткая проверка перед следующим пилотом

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

1. Кто отвечает за этот пилот? Один человек должен одобрить тест, собрать обратную связь и решить, что будет дальше.
2. Какие данные попадут в инструмент? Уточните заметки клиентов, договоры, чаты поддержки и исходный код.
3. Сколько будет стоить платный тариф после теста? Бесплатный план скрывает реальную сумму.
4. Какое правило остановки? У каждого пилота должна быть дата и точка принятия решения.

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

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

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

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

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

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

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