Документы для согласования LLM-проекта перед запуском

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

Проект тормозит не потому, что кто-то против LLM. Обычно команда приносит идею, но не показывает, как сервис реально будет работать после запуска.

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

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

У юристов своя причина для паузы. Фразы вроде "используем внешний LLM API" недостаточно. Им нужно понять, кто оператор данных, кто обработчик, какие данные вообще попадают в сервис и можно ли туда отправлять ПДн, коммерческую тайну или внутренние документы. Если роли сторон не названы прямо, согласование почти всегда зависает.

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

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

Кто смотрит пакет и что спросит

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

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

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

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

Платформенная команда смотрит на интеграцию в рабочий контур. Ей нужны ответы на четыре вопроса:

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

Если вы используете RU LLM, часть этих вопросов закрывается быстрее: для старта обычно достаточно заменить base_url на api.rullm.com, а текущие SDK, код и промпты можно оставить. Но платформенной команде все равно понадобятся схема логов, мониторинг, план отказа и порядок дежурства.

Минимальный пакет документов

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

Минимальный набор выглядит так:

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

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

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

Что написать в карточке проекта

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

Начните с задачи бизнеса одним абзацем. Без общих формулировок вроде "улучшим работу сотрудников". Лучше так: служба поддержки тратит до 15 минут на поиск ответа в базе знаний, поэтому компания тестирует LLM-ассистента, который предлагает оператору черновик ответа и сокращает время обработки обращения.

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

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

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

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

Что подготовить для ИБ

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

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

Отдельно опишите, где вы маскируете ПДн и секреты. ИБ хочет видеть не обещание, а правило: что именно скрывается, на каком этапе и что отправляется в модель после маскирования. Если в промпт может попасть токен, пароль, номер карты или e-mail, лучше прямо написать, как сервис это вырезает или заменяет.

Еще один полезный блок - схема доступа:

• кто читает промпты;
• кто видит ответы модели;
• кто имеет доступ к журналам;
• кто выдает и отзывает права.

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

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

Что нужно юристам и закупкам

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

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

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

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

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

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

Что показать платформенной команде

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

Покажите короткий технический diff. Какой SDK вы уже используете, какой base_url стоит сейчас и на какой endpoint переходите. Если у вас OpenAI-совместимый клиент, часто хватает замены адреса и нового API-ключа. Отдельно перечислите, что вы не меняете: формат промптов, парсинг ответа, бизнес-логику, пайплайн деплоя.

Нужны и рабочие параметры вызова. Не пишите "стандартные тайм-ауты". Платформенная команда хочет видеть числа: например, тайм-аут подключения 3-5 секунд, общий тайм-аут запроса 30-60 секунд, не более двух ретраев, лимиты по RPS и суточному бюджету. Если длинные ответы допустимы только в фоне, так и запишите.

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

• среды: dev, stage, prod и отдельные ключи для каждой;
• кто выдает и отзывает ключи;
• где хранятся секреты;
• кто смотрит метрики, логи и алерты;
• как команда откатывает модель или провайдера.

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

Отдельный блок посвятите наблюдаемости. Назовите владельца мониторинга по роли или по имени, а не просто "команда ML". Укажите, какие ошибки вы ловите: тайм-ауты, 429, 5xx, рост цены запроса, пустые ответы, выход за лимит токенов. Если ночью начнутся сбои, должно быть ясно, кто получает алерт и кто принимает решение об откате.

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

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

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

Начните с листа на одну страницу. В нем достаточно пяти блоков:

1. Цель сервиса - что он делает, кто им пользуется, какой процесс меняется после запуска.
2. Границы - какие данные можно отправлять, какие нельзя, где сервис работает, а где его использование запрещено.
3. Поток данных - от формы или API-вызова до логов, кэша, хранилища и удаления данных.
4. Внешний контур - какие модели, провайдеры, API и библиотеки участвуют в обработке.
5. Открытые вопросы - что еще не решено, кто отвечает и к какой дате даст ответ.

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

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

Если проект идет через RU LLM, в схему и таблицу удобно сразу добавить единый OpenAI-совместимый endpoint, режим хранения логов в РФ и описание маршрутизации по моделям и провайдерам. Это помогает ИБ и юристам быстрее понять границы обработки.

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

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

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

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

Для ИБ в этом кейсе важны не общие обещания, а конкретные меры:

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

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

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

Частые ошибки

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

Чаще всего ошибки такие:

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

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

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

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

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

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

Особенно часто ломается схема данных. Команда пишет "отправляем обращения пользователей", но не показывает состав полей. Для юристов и ИБ этого мало. Нужно явно указать: текст обращения, номер договора, телефон, e-mail, внутренний ID, вложения, системные метки. Если поле не передается, это тоже лучше записать.

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

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

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

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

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

Соберите runbook на один экран

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

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

В первый день включите то, что потом нельзя восстановить задним числом:

• логи запросов и ответов в допустимом объеме;
• метки по сценарию, среде, версии промпта и модели;
• лимиты на токены, бюджет, rate limit и число пользователей;
• аудит действий админов и историю смены настроек.

Отдельно сверьте поставщика с требованиями по РФ и 152-ФЗ. Смотрите не только договор, но и реальную схему: где лежат логи и бэкапы, кто оператор персональных данных, как маскируется PII, можно ли быстро выгрузить аудит для ИБ и юристов.

Если команде нужен OpenAI-совместимый шлюз без переписывания SDK, кода и промптов, такие детали лучше проверять до запуска, а не после первой проверки ИБ. Для этого сценария часто рассматривают RU LLM: у сервиса единый OpenAI-совместимый endpoint, хранение логов и бэкапов в РФ, встроенные PII-маскирование и аудит-трейлы, а B2B-инвойсинг идет в рублях. Это не заменяет ваш пакет документов, но заметно сокращает путь от одобрения до пилота.