Политика использования LLM в отделе продаж: шаблон регламента + risk‑матрица

«У нас есть бот, но никто не знает, что ему можно говорить». Эту фразу я слышу минимум раз в неделю. И каждый раз за ней стоит одна и та же история.

Компания купила подписку на ChatGPT или развернула своего AI-ассистента. Менеджеры начали пользоваться. Кто-то генерит письма. Кто-то готовит КП. Кто-то — и это уже интереснее — скармливает боту полную базу клиентов с контактами и историей покупок, чтобы «он лучше понимал контекст».

А потом звонит юрист и спрашивает: «Вы в курсе, что персональные данные наших клиентов теперь в логах OpenAI?»

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

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

Почему «разберёмся по ходу» не работает

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

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

А риски вполне реальные. Юридические — когда персональные данные утекают в облако, это потенциальное нарушение закона. Кто отвечает, если клиент подаст жалобу? Репутационные — бот нагаллюцинировал «факт», менеджер отправил клиенту, клиент поверил и потом обнаружил обман. Доверие потеряно. Финансовые — бот пообещал скидку 40%, которой не существует, менеджер это отправил, клиент ждёт именно такую цену.

И это не теоретические страшилки. Это реальные случаи из практики.

Из чего состоит рабочий регламент

Сразу оговорюсь: хороший регламент — это не талмуд на 50 страниц, который никто не откроет после подписания. Это компактный документ на 5-7 страниц, который реально читают и на который ссылаются в спорных ситуациях.

Вот семь разделов, без которых регламент не работает.

Раздел первый: про что вообще этот документ

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

Типичная ошибка — написать «регулирует использование AI в компании». Это слишком размыто. AI — это и рекомендательный алгоритм в CRM, и голосовой бот на горячей линии, и ChatGPT в браузере менеджера. Нужна конкретика.

Раздел второй: что можно делать с ботом

Это, как ни странно, не менее важно, чем список запретов. Потому что если сотрудник не понимает, для чего инструмент предназначен — он либо не будет им пользоваться вообще (и вы зря платите за лицензии), либо начнёт экспериментировать с тем, для чего он не предназначен.

Не пишите абстрактное «для повышения эффективности работы». Пишите конкретно: какие задачи, в каком контексте, с какими ограничениями.

Раздел третий: красные линии

А вот здесь нужна максимальная конкретика. «Нельзя использовать для обработки конфиденциальной информации» — это не правило. Потому что каждый по-своему понимает, что такое «конфиденциальная информация».

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

Раздел четвёртый: светофор для данных

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

Раздел пятый: кто за что отвечает

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

Поэтому заранее определите роли. Сотрудник отвечает за то, чтобы следовать правилам и проверять ответы бота перед использованием. Если система ведёт себя странно — сообщает руководителю. Руководитель отдела следит за соблюдением регламента, проводит обучение новичков, разбирает инциденты. IT и безопасность обеспечивают техническую сторону: логирование, ограничения, аудит. Владелец регламента (обычно кто-то из руководства или compliance) обновляет документ, собирает обратную связь, инициирует пересмотр.

Важно: не нужно превращать это в карательную систему. Цель — не наказать, а предотвратить. Если сотрудник сам сообщил о проблеме — это плюс, а не повод для выговора.

Раздел шестой: что делать, когда что-то пошло не так

Инциденты будут. Это нормально. Вопрос в том, как на них реагировать.

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

И прекратите использовать бота для этой конкретной задачи, пока не разберётесь, что произошло.

Раздел седьмой: как люди узнают про все эти правила

Написать регламент — это 20% работы. Остальные 80% — сделать так, чтобы его знали и соблюдали.

Новые сотрудники должны пройти обучение до того, как получат доступ к AI-инструментам. Не после, не «при случае» — до. Пары часов достаточно, если есть практические примеры и возможность задать вопросы.

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

Risk-матрица: шпаргалка для быстрых решений

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

Risk-матрица — это такая шпаргалка, которую можно распечатать и повесить рядом с монитором. Для каждого типа задачи она показывает уровень риска и что с этим делать.

Зелёная зона: можно не думать

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

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

Жёлтая зона: проверяй, прежде чем отправлять

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

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

Оранжевая зона: нужна осторожность

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

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

Красная зона: бот только помогает, не решает

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

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

Прежде чем запускать: что проверить

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

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

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

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

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

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

Три примера из реальной жизни

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

Бот для первичной квалификации лидов

Клиент заходит на сайт, открывает чат, и с ним начинает общаться AI-ассистент. Задача — понять, чего человек хочет, квалифицировать его и передать менеджеру.

AI-помощник для коммерческих предложений

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

Резюмирование звонков и встреч

Менеджер провёл звонок или встречу, запись автоматически расшифровывается и превращается в структурированное резюме для CRM.

Как это всё внедрить, чтобы работало

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

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

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

Третий этап: обучение. Пары часов достаточно. Главное — практика. Разберите конкретные ситуации: «вот это можно», «вот это нельзя», «а вот это — серая зона, давайте обсудим». Дайте людям возможность задать вопросы. Проведите короткий тест — не для наказания, а для проверки, что все поняли.

Четвёртый этап: жизнь. Следите за соблюдением, но без паранойи. Собирайте обратную связь — если какое-то правило постоянно нарушают, возможно, проблема в правиле, а не в людях. Разбирайте инциденты и near-misses (ситуации, когда почти случилось плохое). Обновляйте регламент на основе реального опыта.

Грабли, на которые наступают все

За время работы с разными компаниями я насмотрелся на одни и те же ошибки. Вот самые частые — чтобы вы их не повторяли.

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

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

Абстракции без примеров. «Запрещено передавать конфиденциальную информацию» — и человек сидит и думает: а название клиента — это конфиденциальная информация? А сумма сделки? Примеры конкретных ситуаций работают в разы лучше абстрактных формулировок.

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

«Написали и забыли». LLM-технологии меняются стремительно. То, что было актуально год назад, сегодня уже не работает. Появляются новые инструменты, новые риски, новые возможности. Регламент нужно пересматривать минимум раз в полгода — а лучше чаще.

Вместо заключения

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

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

Шаблон из этой статьи — отправная точка. Возьмите его, адаптируйте под свою специфику, согласуйте с юристами и безопасностью. Но главное — не оставляйте документ лежать в папке «Регламенты». Обучите людей. Объясните «почему». Собирайте обратную связь. Обновляйте на основе реального опыта.

И тогда фраза «у нас есть бот, но никто не знает, что ему можно говорить» уйдёт в прошлое.