152-ФЗ: какие данные в LLM API проверить до обработки

Начните с карты данных и цели

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

Для каждого поля спросите, можно ли выполнить задачу без него. Например, вместо полного профиля часто достаточно обезличенного фрагмента или внутреннего ID. Такая минимизация снижает технический риск и стоимость, но не делает процесс автоматически соответствующим требованиям. Решение о допустимости, основаниях и обязанностях по 152‑ФЗ принимает компетентная юридическая и информационная безопасность команды на основе вашего сценария и документов.

Сократите данные до отправки в модель

Добавьте server-side слой подготовки: удаление лишних полей, маскирование email и телефонов, псевдонимизацию идентификаторов, ограничение длины контекста и allowlist источников RAG. Не рассчитывайте, что пользователь случайно не вставит секрет. Валидируйте типы вложений, запрещайте загрузку .env, ключей, паролей и токенов, а для документов определите допустимые категории до индексации.

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

Не путайте ключи, доступ и данные

API key RussiaAPI — это секрет приложения, а не средство идентификации конечного пользователя. Его нельзя помещать в мобильный клиент, браузер, файл в Git или сообщение поддержки. Разделите ключи по окружениям и приложениям, назначьте владельца, ограничьте доступ к секрет-хранилищу и подготовьте ротацию. Не просите и не принимайте внешние ключи, cookie, пароли либо коды подтверждения — они не нужны для нормальной интеграции.

Доступ к данным реализуйте отдельно: аутентификация пользователя, авторизация на документ, проверка tenant, аудит обращения и отзыв прав. В RAG сначала фильтруйте документы по правам, а уже потом строите контекст. Одна ссылка на объект или знакомый ID не должны давать доступ к чужим записям. Практический план по ключам есть в материале о командных API-ключах.

Пример: минимизация перед серверным запросом

Этот пример Node.js 18+ показывает только техническую подготовку текста перед вызовом разрешённой модели. Регулярные выражения не гарантируют полное удаление персональных данных и не заменяют аудит сценария; они полезны как один из защитных слоёв. Секрет берётся из окружения, а в лог возвращается только безопасный статус. Перед выпуском подтвердите доступный model ID и свойства обработки по текущему каталогу и договорной документации.

function minimize(text) {
  return text.replace(/\b[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}\b/g, '[email]')
    .replace(/\+?\d[\d ()-]{8,}\d/g, '[phone]').slice(0, 6_000);
}
const content = minimize(input.text);
const res = await fetch('https://russiaapi.com/v1/chat/completions', {
  method: 'POST', headers: { authorization: `Bearer ${process.env.RUSSIAAPI_API_KEY}`, 'content-type': 'application/json' },
  body: JSON.stringify({ model: process.env.RUSSIAAPI_TEXT_MODEL, messages: [{ role: 'user', content }] }),
  signal: AbortSignal.timeout(12_000)
});
if (!res.ok) throw new Error(`llm_status_${res.status}`);
console.log('request completed with minimized content');

Не отправляйте оригинальный prompt в систему ошибок «для удобства». При необходимости расследования сохраните внутренний request ID, версию redaction-правила, длину текста и HTTP-класс. Доступ к таким журналам должен быть ограничен, а срок хранения — заранее определён. Дополнительные практики redaction собраны в статье о безопасных логах.

Проверьте договоры, географию и сроки

Инженер не должен угадывать место хранения, перечень субподрядчиков, срок retention или допустимость трансграничной передачи. Соберите актуальные документы RussiaAPI и применимых поставщиков, условия вашего договора, DPA при наличии и внутреннюю политику. Сверьте, какие данные реально отправляются, какие варианты модели разрешены, как обрабатываются запросы на удаление и кто отвечает на обращения субъектов данных.

Если ответ неизвестен, пометьте функцию как неготовую для персональных данных и используйте синтетические тесты до решения владельца риска. Не заявляйте пользователю, что сервис «полностью соответствует 152‑ФЗ» только по наличию шифрования или маскирования. Соответствие зависит от роли организации, цели, процессов, документов, организационных мер и применимого права. Эта статья не заменяет консультацию квалифицированного юриста.

Логи, наблюдаемость и инциденты

Метрики LLM API можно строить без содержимого запроса: latency, класс статуса, количество токенов при необходимости, возраст очереди и внутренний request ID. Prompts, ответы, Bearer-токены, ссылки на документы и персональные поля по умолчанию исключайте. Если бизнесу действительно нужна выборка для контроля качества, задайте отдельное основание, доступ, минимальный объём, срок и процедуру удаления вместе с ответственными специалистами.

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

Чек-лист перед production

1. Есть карта данных, цель, владелец, получатели, retention и удаление для каждого потока.
2. Контекст минимизирован до отправки, а RAG фильтрует документы по правам до поиска.
3. Собственные ключи хранятся server-side, роли и аудит доступа разделены.
4. Логи и traces не содержат ключей, prompts, ответов и прямых идентификаторов по умолчанию.
5. Юристы и ИБ подтвердили применимые документы, договорные и трансграничные вопросы.

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