Внутренняя политика использования LLM для всех команд

Почему правила быстро расходятся

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

С LLM это происходит еще быстрее, потому что сотрудники задают похожие вопросы каждый день. Можно ли вставить текст обращения клиента? Допустим ли фрагмент SQL-лога? Нужна ли маскировка перед отправкой? Если в общем документе нет прямого ответа, люди идут туда, где ответ проще получить: в личные сообщения или в соседнюю команду.

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

Часто проблема даже не в самом нарушении, а в том, что никто не видит, как появилось исключение. Кто его разрешил? На какой документ сослались? Это разовая мера или новое общее правило? Когда ответа нигде нет, сотрудники начинают опираться на пересказ: "нам вроде разрешали" или "в другом отделе так делают". Для тем вроде 152-ФЗ и LLM такой путаницы уже достаточно.

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

Что должен закрывать документ

Хорошая политика использования LLM - это не набор общих пожеланий. Ее задача проще и строже: разработка, поддержка и бизнес должны читать один и тот же текст и принимать одинаковые решения в похожих случаях.

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

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

• персональные данные
• служебные данные
• публичные данные
• типовой сценарий использования
• запрещенный сценарий

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

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

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

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

Кто за что отвечает

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

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

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

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

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

Какие данные можно и нельзя отправлять

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

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

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

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

Что маскировать до запроса

Перед отправкой запроса сотрудник заменяет конкретные поля на нейтральные метки вроде [CLIENT_ID] или [EMAIL]. Обычно маскируют четыре группы данных:

• ФИО, телефон, email, адрес, дату рождения
• паспортные данные, СНИЛС, ИНН, номер договора, номер полиса
• номера карт, счетов и платежные реквизиты
• логины, пароли, токены, API-ключи, cookie, session ID и внутренние ID

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

Если данные нужно хранить в РФ

Если закон, договор или внутренняя норма требуют хранить данные в РФ, сотрудник должен использовать только тот контур, где компания контролирует хранение логов и бэкапов внутри страны. Для 152-ФЗ это нельзя оставлять на уровне устной договоренности. Разрешенный путь нужно назвать прямо: какой сервис использовать, кто его одобрил и какие данные через него можно пропускать.

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

Как работать с LLM по шагам

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

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

Перед отправкой запроса

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

Обычно достаточно четырех проверок:

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

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

После ответа модели

Ответ модели сам по себе не считается готовым документом. Сотрудник проверяет факты, цифры, ссылки на внутренние правила и явные риски. Если модель предлагает действие, которое может задеть клиента, нарушить 152-ФЗ или увести команду в неверное решение, такой ответ нельзя пересылать дальше без проверки человеком.

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

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

Как фиксировать решения и спорные случаи

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

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

Для каждой записи полезно хранить один и тот же минимум:

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

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

Исключения тоже нужно записывать в реестр. Фразы "с нами это согласовали" недостаточно. Нужны имя согласующего, дата, причина, срок действия и границы исключения. Например: отдел поддержки может отправлять обезличенные обращения во внешний LLM-сервис до конца квартала, согласовал руководитель ИБ Иван Петров, повторное согласование нужно 1 июля.

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

После каждого изменения ставьте срок пересмотра. Даже хорошее временное правило быстро стареет, особенно там, где есть 152-ФЗ, новые модели и новые сценарии работы. Без даты пересмотра временное исключение обычно остается навсегда.

Пример рабочей ситуации

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

Сначала он чистит входные данные. Из переписки уходят ФИО, телефон, номер договора и другие прямые идентификаторы. Вместо них он ставит простые метки вроде "[клиент]", "[телефон]" и "[договор]". Даже если компания использует шлюз с маскированием PII и журналом запросов внутри РФ, этот шаг не пропускают. Автоматика помогает, но сотрудник отвечает за то, что отправляет.

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

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

Перед отправкой он смотрит на четыре вещи:

• нет ли в тексте выдуманных фактов
• совпадает ли статус обращения с CRM
• не ушли ли в ответ личные данные
• не звучит ли черновик слишком уверенно там, где нужна проверка

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

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

Где команды чаще ошибаются

Самый частый сбой начинается не с модели, а с привычки. Сотрудник копирует в чат сырой кусок из CRM, тикет-системы или письма клиента, чтобы "быстро переписать" ответ. Внутри такого фрагмента часто остаются имя, телефон, номер договора, адрес или детали заказа. Для компании под 152-ФЗ это уже не мелочь. Даже если у вас есть одобренный шлюз с маскированием PII и хранением логов в РФ, правило обезличивания все равно должно работать до отправки запроса.

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

Проблему легко узнать по таким фразам в промптах:

• "Если данных не хватает, придумай правдоподобный ответ"
• "Ответь уверенно, даже если точной информации нет"
• "Возьми похожий случай из памяти"
• "Не пиши, что нужен факт-чек"

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

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

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

Короткий чек-лист перед запуском

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

Перед публикацией проверьте пять вещей:

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

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

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

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

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

Рабочий темп обычно такой:

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

После утверждения политика должна стать частью найма и онбординга. Новым сотрудникам не нужен длинный курс. Обычно хватает короткого обучения на 20-30 минут с тремя вещами: какие данные нельзя отправлять, где работать с LLM можно и куда идти, если случай неочевидный.

Полезно закрепить это не только в документе, но и в ежедневной работе. Добавьте актуальную версию в базу знаний компании, включите подтверждение ознакомления в онбординг и раз в квартал разбирайте 2-3 свежих кейса на встрече команд. Так политика не расползется на версии "как договорились в прошлый раз".

Если компании нужен единый шлюз, хранение логов и бэкапов в РФ и аудит по каждому запросу, стоит отдельно оценить инфраструктурную часть. Например, RU LLM на rullm.com дает OpenAI-совместимый эндпоинт, хранение внутри РФ, встроенные аудит-трейлы и маскирование PII. Такой слой не заменяет внутреннюю политику, но заметно упрощает ее исполнение в одном контуре.

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