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

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

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

Практическая форма фиксации KPI может быть очень простой: таблица в рабочем документе или трекере, где на каждую задачу отмечается длительность, число итераций и статус «принято/на доработку». Формат не важен. Важна регулярность.

KPI безопасности: обезличивание, проверка фактов, инциденты

Безопасность – это не отдельная тема «для юристов». Это часть управляемости внедрения. Чем раньше вы введёте безопасность как измеряемый показатель, тем меньше будет сопротивления и тем выше доверие руководства.

Для пилота достаточно трёх показателей.

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

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

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

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

Риски внедрения: репутационные, юридические, операционные

Риски – это не список страшилок. Это карта того, где вы обязаны поставить ограничители и проверки.

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

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

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

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

Definition of Done: какие артефакты обязаны появиться

Чтобы внедрение не распалось на разговоры и эксперименты, вам нужен чёткий критерий «готово». Это и есть Definition of Done для внедрения на 14 дней.

Готово не означает «все умеют». Готово означает: есть рабочие сценарии, есть стандарты, есть измерения, и есть артефакты, которые делают результат воспроизводимым.

Минимальный набор артефактов, который стоит требовать через 14 дней:

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

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

Чеклист качества. Короткий список того, что проверяется всегда: факты, тон, следующий шаг, сроки, отсутствие запрещённых формулировок, соответствие условиям.

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

Трекер KPI. Простой механизм сбора метрик по пилоту: время, скорость цикла, качество, правки, SLA и показатели безопасности.

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

Этого достаточно, чтобы внедрение стало управляемым. Если вы сделаете больше – отлично, но именно этот минимум делает внедрение устойчивым.

Двухрежимная модель: «быстро» и «строго»

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

Двухрежимная модель решает это на уровне правил.

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

Режим «строго» – для задач повышенного риска. Его цель – избежать ошибок и репутационных потерь. В этом режиме обязательны: обезличивание, проверка фактов, сверка с источником правды (договор, CRM, база знаний), контроль формулировок и, при необходимости, утверждение владельцем процесса или руководителем.

Важно заранее определить, какие задачи относятся к «строгому» режиму. Обычно это: юридические формулировки, условия оплаты, публичные заявления, ответы на претензии, любые тексты, где есть конкретные обязательства, суммы, сроки и ответственность.

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

Принцип масштабирования: сначала стандарты, потом объём

Масштабирование – это не «подключить ещё людей». Масштабирование – это способность воспроизводить результат без героизма.

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

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

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

Артефакт: паспорт внедрения

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

Паспорт внедрения должен быть настолько коротким, чтобы его реально читали. В идеале – одна-две страницы. Он включает:

Цель на 14 дней. Описанная как результат, а не как деятельность. Например: «Сократить время подготовки коммерческого предложения на X%, уменьшить количество правок до Y, повысить скорость ответа в поддержке до SLA Z, при этом обеспечить обезличивание в N% задач и проверку фактов в M% случаев повышенного риска».

Три процесса пилота. С названиями, владельцами и кратким описанием, что считается входом и выходом.

KPI пилота. 4–6 метрик с базовой точкой и целевым значением на 14 дней.

KPI безопасности. Минимальный набор метрик и правило фиксации инцидентов.

Риски и ограничители. Коротко: какие задачи только в «строгом» режиме, что нельзя делать, где обязательна проверка.

Артефакты, которые обязаны появиться. Шаблоны, чеклисты, правила данных, трекер KPI, пакеты документов по процессам.

Ответственные роли. Владелец внедрения, владелец безопасности, владельцы процессов.