Александр Костин – Внедрение ИИ в компании: пошаговая система устранения хаоса (страница 4)

Зона ответственности владельца процесса включает несколько задач.

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

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

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

Он организует проверку результата. Не в смысле «сам всё проверяет». В смысле задаёт механизм: кто проверяет, по какому чеклисту, в каких случаях нужна его личная валидация.

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

Пользователи: кто и для чего применяет ИИ ежедневно

Пользователи – это не «все сотрудники». На пилоте пользователи – это конкретные люди, которые выполняют конкретные задачи в выбранных процессах. Они не обязаны быть энтузиастами. Они обязаны делать работу и фиксировать результаты. Чем честнее будут их наблюдения, тем быстрее компания выйдет на рабочий стандарт.

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

У пользователей в пилоте есть три обязанности.

Первая – применять ИИ в заданных сценариях, а не «по настроению». Пилот не проверяет, нравится ли инструмент. Пилот проверяет, даёт ли он эффект на типовых задачах.

Вторая – фиксировать метрики. Минимально: время на задачу, число итераций, итог «принято/на доработку», случаи, где пришлось отказаться от результата. Если пользователи не фиксируют фактуру, внедрение начинает строиться на ощущениях.

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

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

Редактор и контролёр качества: кто проверяет «перед отправкой»

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

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

Функции редактора качества на пилоте обычно такие.

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

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

Он обучает пользователей на практике. Не лекцией, а разбором реальных результатов: что исправили, почему, как предотвратить. Здесь важно не превращать разбор в публичное унижение. Разбор должен быть про улучшение процесса.

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

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

ИТ и админ: доступы, учётные записи, хранение материалов

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

ИТ/админ в контексте пилота не обязательно означает отдельный отдел. Это роль, которая отвечает за порядок в доступах и материалах. Его задача – создать минимальную инфраструктуру, которая позволяет работать безопасно и повторяемо.

Что входит в его ответственность.

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

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

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

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

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

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

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

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

Хорошая базовая модель строится на трёх уровнях.

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

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

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

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

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

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