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

все числа и суммы;

все сроки и обещания;

все условия, которые могут трактоваться как обязательство;

любые утверждения, которые ссылаются на договор или регламент;

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

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

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

Чеклист безопасности: что проверяется всегда перед отправкой

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

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

Пример логики чеклиста:

данные обезличены;

нет ФИО, телефонов, email, адресов, ID;

нет коммерческих условий в исходном виде, если это запрещено политикой;

если есть суммы/сроки/обязательства – включён строгий режим;

все числа и сроки проверены по источнику правды;

текст не содержит лишних обещаний и гарантий;

тон соответствует стандарту компании;

есть понятный следующий шаг;

текст согласован в соответствии с моделью согласований;

результат сохранён в правильном месте и в актуальной версии.

Чеклист должен быть не абстрактным, а проверяемым. Не «убедитесь, что всё правильно», а «проверены суммы и сроки по источнику правды».

Журнал инцидентов: как фиксировать ошибки, чтобы система становилась сильнее

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

Журнал инцидентов нужен, чтобы превратить ошибку в улучшение процесса.

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

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

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

Хранение и доступ: единый источник шаблонов и контроль версий

Безопасность – это не только «что отправляем в ИИ». Это ещё и «что делаем с результатом».

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

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

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

Артефакт: политика данных на одну страницу

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

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

Политика данных и безопасности для использования ИИ в компании

Цель политики

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

Запрещено передавать в ИИ в исходном виде

Персональные данные клиентов и сотрудников: ФИО, телефоны, email, адреса, документы, даты рождения, аккаунты, ID в CRM и любые уникальные идентификаторы.

Коммерчески чувствительные данные: конкретные цены, скидки, маржинальность, условия договоров и оплаты, внутренние финансовые показатели, детали переговоров под NDA.

Данные доступа: пароли, токены, ключи, конфигурации безопасности и любые секреты инфраструктуры.

Допустимо только после обезличивания

Кейсы клиентов, переписки и проектные материалы допускаются только в виде пересказа без идентификаторов и уникальных деталей.

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

Безопасно

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

Строгий режим обязателен, если в результате есть

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

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

Проверка фактов

Всегда проверяются: числа, суммы, сроки, условия оплаты и ответственности, ссылки на договор/регламент, факты о клиенте.

Источник правды: ______________________ (договор/CRM/прайс/регламент/база знаний).

Если источника правды нет – факт не утверждается, используется формулировка «уточним и подтвердим».

Чеклист безопасности перед отправкой внешнего результата

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

Инциденты

Любое нарушение правил фиксируется в журнале инцидентов. Цель фиксации – улучшение правил и шаблонов. Ответственный за журнал: ______________________.

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

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

Глава 4 Промпты и стандарты работы: как добиться стабильного качества, а не «удачных попыток»

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

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

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