Обезличивание данных перед LLM API: инженерный чек-лист

Нарисуйте поток данных до первого запроса

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

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

Подменяйте значения в изолированном backend

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

Регулярные выражения полезны для очевидных email и телефонов, но не покрывают свободный текст, изображения, OCR и редкие комбинации. Добавьте валидацию типов, лимит длины, политику вложений и негативные тесты. Не пытайтесь лечить неполную маску повторной отправкой тех же данных в надежде получить «лучший» ответ. Если поле нельзя безопасно исключить, остановите сценарий до подтверждения допустимой цели, договора и технических мер. Это не юридическая консультация и не обещание соответствия требованиям.

Проверьте логи, трассировку и поддержку

Самая частая утечка происходит не в основном ответе, а вокруг него. Настройте allowlist полей для журналов: внутренний request ID, время, статус, latency, версия адаптера и нормализованный код обычно достаточны. Никогда не пишите Authorization, RUSSIAAPI_API_KEY, полный prompt, ответ пользователя, cookie или экспорт HTTP-заголовков. Проверьте error handler: необработанное исключение не должно сериализовать объект запроса целиком.

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

Ограничьте доступ и пересматривайте решение

Ключ RussiaAPI хранится только в защищённом server-side окружении и принадлежит вашему проекту. Frontend обращается к вашему backend, где проверяются пользовательские права, лимиты, тип входа и выбранный маршрут. Не просите у клиента ключи OpenAI, Anthropic или другого поставщика и не передавайте cookie, пароль или код подтверждения «для диагностики». Если текущий каталог или контракт не подтверждает функцию, отметьте её как непроверенную и не строите на ней обязательный процесс.

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

Server-side пример

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

const email = /\b[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}\b/g;
const phone = /\+?\d[\d() -]{7,}\d/g;
export function minimizePrompt(text) {
  if (typeof text !== 'string' || text.length > 8_000) throw new Error('invalid_input');
  return text.replace(email, '[EMAIL]').replace(phone, '[PHONE]');
}

export async function sendSafePrompt(text) {
  const content = minimizePrompt(text);
  return 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 }] })
  });
}

Проверьте синтаксис командой node --check, добавьте аутентификацию своего маршрута, rate limit, ограничение входа и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.

Что фиксировать в рабочем контуре

До запуска назначьте владельца сценария, версию адаптера, внутренний ID операции, разрешённый model ID и измеримый критерий результата. В безопасном журнале обычно достаточно времени, HTTP-класса, нормализованного кода, latency и request ID, если он есть. Не записывайте Authorization, полный prompt, ответ пользователя, временные URL или выгрузку заголовков: для первичной диагностики они не нужны и повышают риск утечки.

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