Проверка входных данных перед AI API: безопасный минимум

Короткий ответ: сначала собственные правила и границы

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

Проверка должна происходить на сервере до запроса в AI API. Не доверяйте флагу из браузера вроде safe=true, выбранной пользователем модели или переданному tenant_id. Backend получает контекст из сессии, ограничивает число запросов, нормализует тип и отклоняет неожиданные поля. Если приложение использует внешний классификатор или документированную функцию поставщика, это лишь дополнительный сигнал: ложные срабатывания и пропуски возможны. Не обещайте, что такой сигнал гарантирует законность, права на контент или приемлемость результата.

Минимизируйте полезную нагрузку и доступ

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

Минимизация касается и ответа пользователю. Сообщение «запрос требует проверки» безопаснее, чем показ внутреннего правила, вероятности классификатора или технического ответа сторонней системы. Для поддержки сохраните request_id, policy_version, category и время, но не полный текст prompt, Authorization или содержимое файла. Доступ к этим событиям ограничьте ролями и периодом хранения, согласованным внутри организации. Телеметрия помогает измерить поток отказов, но не должна стать вторым, менее защищённым хранилищем пользовательского контента.

Добавьте очередь для спорных случаев

Не все входы нужно автоматически разрешать или блокировать. Для неоднозначного сценария сервер помещает операцию в очередь review_required, сообщает пользователю нейтральный статус и передаёт минимальный контекст уполномоченному сотруднику или отдельному процессу. Человек проверяет не только текст, но и право пользователя, цель продукта и локальные правила. Решение фиксируется как версия policy и безопасный reason code; оно не должно превращаться в коллекцию необработанных материалов в общей таблице логов.

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

Проверяйте модельный ответ отдельно от входа

Даже разрешённый вход не делает результат модели безопасным для следующего шага. Если модель возвращает JSON, ссылку, текст команды или классификацию, воспринимайте это как недоверенный ввод. Приложение проверяет schema, допустимые значения, tenant и бизнес-правила, прежде чем вызвать инструмент, записать данные или показать результат другому пользователю. Не исполняйте аргументы tools, URL, SQL-фрагменты и инструкции из model output без allowlist и server-side авторизации.

Полезно разделить события input_rejected, input_review_required, upstream_requested, output_invalid и completed. Такая модель помогает понять, на каком шаге возникла проблема, без хранения всего диалога. Повтор запроса связывайте с request_id и учитывайте последствия: для действий с созданием ресурса сначала проверьте статус предыдущей операции. Внешний timeout или 429 не доказывает, что проверка не состоялась; показывайте пользователю честный временный статус и ограничивайте повтор по собственной политике.

Измеряйте правила и пересматривайте их безопасно

Перед rollout соберите набор синтетических случаев: допустимый короткий текст, пустое поле, слишком большой вход, неизвестный MIME-тип, запрос без сессии, чужой tenant и случай, требующий review. Для каждого зафиксируйте ожидаемое состояние и отсутствие секретов в ответе и логах. Затем включите проверку для test tenant или небольшой доли запросов. Смотрите на долю отказов, ложные блокировки, время review и ошибки адаптера, но не публикуйте эти показатели как гарантию фильтрации или доступности.

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

Server-side пример

Пример показывает локальную проверку или контроллер на сервере. Ключи берутся только из окружения; до запуска подтвердите маршрут, model ID и параметры в текущем каталоге RussiaAPI.

export function screenInput({ text, mimeType, authenticated }) {
  if (!authenticated) return { state: 'access_denied' };
  if (typeof text !== 'string' || text.trim().length === 0 || text.length > 4000) return { state: 'invalid_input' };
  if (mimeType && !new Set(['text/plain', 'application/json']).has(mimeType)) return { state: 'review_required' };
  // Add product-specific rules here; never log the original text or credentials.
  return { state: 'approved', policyVersion: '2026-09-17' };
}

// Call a documented server-side RussiaAPI route only after this decision.
// Treat any model output as untrusted input and validate it again.

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