Согласование LLM с юристами: одна страница без задержек

Почему согласование тянется

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

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

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

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

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

Обычно задержку создают четыре пробела:

• не указан точный набор полей в запросе;
• не описан маршрут данных и место хранения логов;
• не назначен владелец функции;
• меры контроля обсудили устно, но не зафиксировали.

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

Как должна выглядеть одна страница

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

Удобно собрать карточку из пяти коротких блоков:

1. Название функции и цель. Один абзац без общих слов. Например: "Чат-ассистент помогает оператору поддержки подготовить ответ по шаблонам и базе знаний. Он не отправляет сообщения без подтверждения сотрудника".
2. Путь данных. Кто отправляет запрос, через какой сервис он идет, какая модель обрабатывает текст, где формируется ответ и что сохраняется в логах. Если запрос идет через RU LLM, схема может выглядеть так: внутреннее приложение -> RU LLM -> выбранная модель -> ответ оператору. Отдельно укажите, где лежат логи и резервные копии.
3. Категории данных во входе, выходе и логах. Не вся схема полей, а понятные классы: ФИО, телефон, номер заказа, текст обращения, служебный идентификатор, ответ модели, технические метки.
4. Риски простыми словами. Короткие формулировки работают лучше длинных: "утечка ПДн в промпте", "неверный ответ клиенту", "лишние логи", "доступ без роли", "ответ без проверки человеком".
5. Меры контроля, которые уже стоят. Только факты: маскирование PII, срок хранения логов, роли доступа, аудит-трейлы, ручное подтверждение ответа, список разрешенных моделей.

Внизу достаточно служебного блока из трех строк: владелец функции, владелец данных и список согласующих. Обычно хватает ролей вроде продуктового менеджера, ИБ, юриста по 152-ФЗ, архитектора и руководителя поддержки.

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

Какие данные описать без лишней воды

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

Начните с источников. Не "интеграция с внутренними системами", а прямо: форма на сайте, чат поддержки, CRM, база знаний. Этого уже достаточно, чтобы увидеть контур обработки.

Потом перечислите входные поля на уровне фактических данных. Например:

• текст обращения клиента;
• номер заказа или заявки;
• имя и фамилия, если оператор передает их в диалог;
• фрагмент статьи из базы знаний;
• технические метки вроде языка, канала и времени обращения.

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

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

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

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

Как назвать риски простыми словами

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

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

Для карточки обычно хватает нескольких таких формулировок:

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

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

Если у вас российский контур и важен 152-ФЗ, называйте не "регуляторный риск", а конкретный сценарий: "в запрос попали ФИО и телефон клиента, а хранить их в таком виде нельзя". Тогда мера контроля напрашивается сама: маскирование полей, сокращение логов, хранение в РФ, аудит.

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

Какие меры контроля указать сразу

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

Сначала укажите, что сервис маскирует PII до отправки запроса. Лучше назвать поля прямо: телефон, почта, номер договора, ФИО и другие чувствительные значения система скрывает или заменяет метками. Фраза "работаем безопасно" не помогает. Помогает список фактических ограничений.

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

Минимальный набор

В карточке обычно достаточно такого набора:

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

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

Отдельной строкой добавьте план быстрого отключения функции. Кто принимает решение, где находится переключатель, сколько времени нужно на остановку. Хороший вариант - feature flag, смена маршрута или отзыв доступа к API за несколько минут.

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

Как заполнить страницу за 30 минут

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

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

Можно пройти по простому порядку:

1. За 5 минут опишите сценарий одной фразой: кто запускает запрос, что уходит в модель и какой результат получает сотрудник или клиент.
2. Выпишите входные поля из формы или API как есть. Не пересказывайте их своими словами. Лучше прямо: email, phone, order_id, comment, city.
3. Пометьте поля с персональными данными. Хватает короткой метки "ПД". Если есть свободный текст, отметьте и его: люди часто вписывают туда телефон, адрес или номер договора.
4. Отдельной строкой укажите, кто читает ответ модели. Один риск у внутреннего оператора, другой - у ответа, который уходит клиенту без проверки.
5. В конце добавьте 3-5 пар "риск - мера" и отправьте черновик юристу в тот же день. Например: ошибка в ответе - ручная проверка спорных случаев; утечка ПД - маскирование и короткий срок хранения логов; лишнее действие модели - запрет на запись в CRM без человека.

Если инфраструктура уже понятна, впишите и ее. Для российской команды это часто снимает половину вопросов еще на первом круге.

Пример для чат-ассистента поддержки

Клиент пишет в чат: "Где мой заказ 548921 и почему доставка сдвинулась?" Система передает в модель текст обращения и номер заказа. Модель не отвечает клиенту напрямую, а готовит черновик для оператора. Оператор читает текст, при необходимости правит его и только потом отправляет.

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

На одной странице это можно описать так:

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

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

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

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

Где команды сами тормозят процесс

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

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

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

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

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

Самый дорогой промах случается в конце. Команда уже выбрала провайдера, подключила SDK, провела демо, а потом несет бумагу на согласование. Любое замечание по маршруту данных, логам или 152-ФЗ в этот момент бьет по срокам и бюджету. Иногда приходится менять схему или заново проверять провайдера.

Перед отправкой полезно быстро проверить четыре вещи:

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

Быстрая проверка перед отправкой

Юристы редко спорят из-за самой LLM. Обычно работа встает там, где команда оставила пустые места: зачем нужна функция, какие данные она получает и кто ее выключит, если что-то пойдет не так.

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

Проверка за 5 минут

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

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

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

Не оставляйте без имени владельца функции. Нужны конкретный человек или роль, канал связи и срок пилота. Формулировка "команда ML" слишком расплывчата.

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

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

Что делать после первого согласования

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

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

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

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

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

После пилота назначьте короткий разбор с юристом и владельцем продукта. Нужны не общие выводы, а 3-5 решений: что оставить, что запретить, что добавить в карточку и в процесс. Когда одностраничное описание LLM живет вместе с функцией, следующее согласование занимает часы, а не недели.