Выбор модели для комплаенса: как собрать пакет фактов

Почему комплаенс просит факты, а не обещания

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

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

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

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

Это хорошо видно на практике. Допустим, банк хочет запустить чат для поддержки. Фраза "мы выбрали известную модель" не помогает. А карточка с версией модели, провайдером, местом хранения логов, сроком удаления, маскированием PII и аудит-логами уже дает основу для решения.

Что включить в карточку выбора модели

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

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

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

Минимальный состав карточки обычно такой:

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

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

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

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

Как описать логи и трассировку

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

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

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

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

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

Полезно добавить маленький сценарий разбора. Например: "Жалоба клиента поступила в 14:20. Команда ищет request_id из CRM, находит вызов за 14:18, видит модель, провайдера, статус 429 и задержку 18 000 мс. После этого команда проверяет повторные попытки и лимиты по ключу". Один такой пример снимает много лишних вопросов.

Как разложить риски по полкам

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

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

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

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

Отдельно про fallback

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

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

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

Как описать хранение и удаление данных

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

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

Обычно хватает четырех блоков:

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

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

Срок хранения фиксируйте по каждому слою, а не одной строкой на весь сервис. Например, текст запроса может храниться 14 дней для разбора инцидентов, аудит-логи - 180 дней для проверок, резервные копии - 30 дней до автоматического удаления. Такой формат гораздо легче согласовать, чем фразу "храним недолго".

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

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

Какие меры контроля и доступы нужны

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

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

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

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

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

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

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

Как собрать пакет на согласование

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

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

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

Свести пакет удобно в простую таблицу:

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

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

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

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

В рабочем варианте бот не отправляет в модель сырой текст клиента как есть. Перед вызовом система маскирует ИИН, номер карты и другие фрагменты, по которым можно узнать человека. Если клиент пишет: "Проверьте карту 4400 1234 5678 9999 и ИИН 990101300123", модель получает уже очищенный текст с маркерами вместо чувствительных полей.

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

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

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

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

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

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

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

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

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

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

Короткая проверка перед отправкой

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

Перед отправкой проверьте пять вещей:

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

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

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

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

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

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

Если команде нужен один API для работы с разными моделями и при этом важны единые аудит-логи, маскирование PII и хранение данных в Казахстане, можно посмотреть AI Router на airouter.kz. У сервиса один OpenAI-совместимый эндпоинт, а в карточке согласования все равно стоит фиксировать конкретные модели, провайдеров и правила хранения по каждому сценарию.