Политика редактирования AI API — это свод правил о том, что ваша команда может отправлять в модель, что она может сохранять после ответа модели, что попадает в журналы запросов и что видит поддержка, когда клиент открывает обращение. Это важно, потому что промпты и ответы больше не являются просто временными входными данными разработчика. Они становятся записями для отладки, доказательствами для аудита, скриншотами, экспортами, вложениями в обращениях в поддержку и материалами для проверки закупок.
Слабая версия этой политики говорит: «не логируйте чувствительные данные». Этого недостаточно. Командам нужны решения на уровне полей, ответственные, окна хранения и обработка исключений до того, как производственный трафик попадет в шлюз модели. Хорошая политика редактирования AI API подсказывает инженерии, когда блокировать запрос, безопасности — когда маскировать данные, поддержке — когда редактировать обращение, а закупкам — какое доказательство подтверждает, что процесс контролируется.
Flatkey полезен в этом обсуждении, потому что текущий публичный сайт позиционирует flatkey.ai как один API-ключ для официального трафика GPT, Claude, Gemini и других моделей с аналитикой использования, контролем затрат и одним счетом по нескольким провайдерам. Рассматривайте это как единое пространство доступа и проверки. Не воспринимайте это как замену собственной классификации данных, юридической проверки, политики хранения или процесса редактирования обращений в поддержку. Перед внедрением проверьте точные настройки учетной записи, журналы, экспорты, поведение хранения и охват DPA в своей учетной записи покупателя.
Политика редактирования AI API: краткая версия
Политика редактирования AI API должна отвечать на пять операционных вопросов до того, как промпт попадет в production:
| Вопрос | Решение политики | Ответственный |
|---|---|---|
| Какие данные запрещены в промптах? | Блокировать секреты, платежные данные, необработанные учетные данные, закрытые ключи и неподдерживаемые регулируемые данные до вызова API | Ответственный за безопасность |
| Какие данные можно замаскировать и отправить? | Заменять прямые идентификаторы токенами, хешами, метками или синтетическими заглушками, если качество задачи при этом сохраняется | Ответственный за приложение |
| Что хранится в журналах? | По умолчанию предпочтительны журналы только с метаданными; сохранять фрагменты полезной нагрузки только для утвержденных случаев отладки | Ответственный за платформу |
| Что может видеть поддержка? | Редактировать клиентские промпты, ответы, вложения, скриншоты и трассировки перед передачей в обращение | Ответственный за поддержку |
| Когда можно обходить редактирование? | Требовать указанное исключение, цель инцидента, ограничение доступа, дату хранения и одобрение юриста/безопасности | Ответственный за управление |
Практическая цель не в том, чтобы удалить каждую полезную деталь. Цель — сохранить достаточно доказательств для отладки, сверки использования и поддержки клиентов, не превращая промпты, ответы, логи или обращения в неуправляемые чувствительные записи.
Начните с карты данных, а не со списка regex
Редактирование промптов LLM обычно дает сбой, когда команды начинают с узкого списка регулярных выражений. Regex помогают находить очевидные шаблоны, но они не определяют политику. Начните с картирования того, где появляется трафик AI:
| Поверхность записи | Типичные поля | Обработка по умолчанию |
|---|---|---|
| Тело промпта | Текст пользователя, аргументы инструментов, загруженный контекст, извлеченные документы, системные инструкции | Классифицировать до отправки; блокировать или токенизировать чувствительные значения |
| Вывод модели | Сгенерированный ответ, цитаты, вызовы инструментов, код, структурированный JSON | Проверять перед отображением, хранением, экспортом или копированием в обращение |
| Метаданные шлюза | Провайдер, модель, статус, задержка, количество токенов, ID запроса, рабочее пространство, среда | Сохранять для эксплуатации и биллинга, если только это не раскрывает чувствительный контент |
| Журнал полезной нагрузки шлюза | Промпт, ответ, вход/выход инструментов, вложения, входные данные для embeddings | Выключен по умолчанию или debug vault с коротким сроком хранения |
| Обращение в поддержку | Сообщение клиента, скопированный промпт, ответ, скриншоты, HAR-файлы, stack traces | Редактировать перед широким распространением; отделять доказательства инцидента от обычной поддержки |
| Экспорт аналитики | Строки затрат, строки использования, метки клиента/команды, категории ошибок | Де-идентифицировать метки, когда экспорты покидают операционную команду |
Эта карта должна стать приложением к вашей политике редактирования AI API. Она дает проверяющим место для конкретных вопросов: какие поля классифицируются, какие маскируются, какие сохраняются и какая роль может утверждать исключения.
Классифицируйте промпты до вызова модели
Контроли хранения у провайдера важны, но они не заменяют гигиену промптов. Текущая документация OpenAI по контролю данных API говорит, что данные API не используются для обучения моделей OpenAI, если клиент явно не дает согласие, но также описывает журналы мониторинга злоупотреблений, которые могут содержать промпты, ответы и производные метаданные и храниться до 30 дней по умолчанию. Документация Anthropic по API и хранению данных аналогично различает соглашения по обработке данных, zero data retention и случаи, когда входные и выходные данные, помеченные как связанные с безопасностью, могут храниться.
Это означает, что ваша политика не должна опираться только на утверждение «провайдер не будет использовать это для обучения». Политика редактирования AI API для production должна определять, что никогда не пересекает границу:
| Тип данных | Рекомендуемое действие | Пример замены |
|---|---|---|
| API-ключи, токены сеанса, OAuth refresh-токены, закрытые ключи | Заблокировать запрос и уведомить владельца | SECRET_BLOCKED |
| Номера платёжных карт и банковские реквизиты | Заблокировать, если только не существует соответствующего требованиям, одобренного платёжного процесса | PAYMENT_FIELD_REMOVED |
| Пароли или ответы для восстановления | Заблокировать и создать security ticket | CREDENTIAL_REMOVED |
| Прямые персональные идентификаторы, не нужные для качества задачи | Токенизировать или обобщить | CUSTOMER_4821, city_region |
| Account ID, необходимые для отладки | Хешировать или использовать внутренний surrogate ID | acct_hash_... |
| Внутренние системные промпты и скрытый policy text | Не раскрывать пользователю или в обращениях в поддержку | SYSTEM_CONTEXT_REDACTED |
Классификатор промптов не обязан быть идеальным, чтобы приносить пользу. Ему нужны пути эскалации. Если запрос содержит credential, блокируйте его. Если он содержит персональные данные, которые модели не нужны, маскируйте их. Если продукту действительно нужен конфиденциальный value, требуйте документированную цель, ограниченный маршрут модели, владельца хранения и reviewer.
Для команд, создающих собственные классификаторы, Google Sensitive Data Protection — полезный официальный справочный материал по концепциям de-identification и redaction transformation. Используйте его как источник паттернов проектирования, а не как доказательство того, что у какого-либо одного gateway эти controls включены.
Сканируйте outputs до того, как они станут records
Конфиденциальность prompt output часто упускают, потому что команды воспринимают ответ модели как элемент отображения. На практике outputs копируются в tickets, сохраняются в истории чатов, встраиваются в analytics, прикрепляются к bug reports и вставляются в письма клиентам. Ваша политика для outputs должна покрывать как минимум четыре риска:
| Риск для output | Control |
|---|---|
| Модель повторяет конфиденциальное содержимое prompt | Сканировать сгенерированный текст до сохранения и передачи в поддержку |
| Модель раскрывает системные инструкции или скрытый context | Выявлять и блокировать patterns утечки policy/preamble |
| Модель выдумывает персональные или финансовые факты | Требовать review с учётом source-aware перед использованием в регулируемой сфере или при влиянии на клиента |
| Модель включает небезопасный code, secrets или credentials | Помещать в quarantine и направлять на security review |
Категория риска OWASP LLM02 sensitive information disclosure рассматривает раскрытие как риск модели и приложения, который может включать персональные данные, финансовые сведения, медицинские записи, конфиденциальные бизнес-данные, credentials и юридические документы. Это полезное напоминание: политика редактирования AI API — это не только фильтрация input. Это также проверка output, контроль хранения и управление workflow поддержки.
Для высокорисковых workflows храните сгенерированный ответ отдельно от raw prompt. Храните redacted transcript для рутинных операций и сохраняйте raw evidence только в ограниченном incident vault, когда есть одобренная цель.
Сделайте AI API log redaction в первую очередь ориентированным на metadata
AI API log redaction должен начинаться с default, ориентированного на metadata-first. Большинству platform teams нужны request ID, model names, status codes, latency, token counts, route attempts, environment, owner и cost fields. Им не всегда нужны raw prompt и raw response.
Документация Cloudflare по logging для AI Gateway — хороший пример того, почему это различие важно: в ней отдельно описаны controls для сбора logs и для сбора log payloads, а также поля DLP, когда срабатывают policies. Документация Vercel по observability для AI Gateway описывает logging затрат, использования моделей и observability metrics для мониторинга и отладки. Эти примеры — не заявления о возможностях Flatkey. Они показывают operating pattern, который должен оценить каждый покупатель gateway: metadata, payload, DLP signals, retention и deletion — это отдельные решения.
Используйте эту log policy как базовый уровень:
| Поле лога | По умолчанию | Исключение |
|---|---|---|
| Request ID, workspace, environment, route, model, provider | Сохранять | Нет; необходимо для поддержки и аудита |
| Status, error code, latency, retry/fallback event | Сохранять | Нет; необходимо для review надёжности |
| Token usage and cost estimate | Сохранять | Де-идентифицировать customer/team labels в finance exports, когда это требуется |
| Prompt and response body | По умолчанию не хранить | Debug vault с коротким сроком хранения и именованным incident |
| Аргументы tools и output tools | Редактировать по полям; хранить только одобренные фрагменты | Security incident или воспроизводимый bug case |
| Категория DLP match | Сохранять policy IDs и categories | Не хранить сам найденный secret |
Политика редактирования AI API также должна определять механизмы удаления. Кто может удалить log? Кто может наложить legal hold? Что происходит с производной analytics после удаления raw payload? Если команда не может ответить на эти вопросы, log payloads не готовы к широкому production use.
Редактируйте обращения в поддержку, прежде чем они начнут распространяться
Обращения в поддержку — это то место, где часто происходят утечки при тщательно выстроенных инженерных мерах контроля. Клиент вставляет полный промпт в тикет. Инженер прикладывает трассировку с телом запроса. На скриншоте виден ключ. Макрос поддержки пересылает цепочку другому вендору. Внезапно чувствительная запись оказывается уже не только на пути модели; она попадает в службу поддержки, уведомление по электронной почте, экспорт из хранилища и ретроспективу инцидента.
Ваша политика редактирования AI API должна рассматривать поддержку как отдельную поверхность:
| Артефакт поддержки | Требуемая проверка |
|---|---|
| Скопированный промпт или ответ модели | Редактируйте идентификаторы, секреты и регулируемые данные до широкого доступа в поддержке |
| Скриншот | Обрезайте или размывайте ключи, email-адреса, ID клиентов, тела запросов и скрытые промпты |
| HAR-файл или трассировка | Удаляйте заголовки авторизации, cookies, payload'ы и подписанные URL |
| Вложение в тикет | Редактируйте или удаляйте чувствительные файлы перед эскалацией |
| Эскалация вендору | Передавайте минимальные данные для воспроизведения, а не исходный контент клиента |
Официальная API-документация Zendesk поддерживает эту операционную модель, описывая редактирование строк в комментариях к тикетам, а также отдельную точку редактирования вложений к комментариям. Даже если ваша команда использует другой help desk, смысл политики тот же: редактирование в поддержке должно быть отдельным, явно названным процессом, а не разовой уборкой после того, как кто-то заметил утечку значения.
Определяйте исключения до инцидентов
Каждой строгой политике нужен контролируемый путь исключений. Без него команды либо неформально обходят политику, либо сохраняют слишком мало доказательств для решения производственных проблем.
Используйте такую запись об исключении:
| Поле | Требуемое значение |
|---|---|
exception_id |
Уникальный ID, связанный с инцидентом или расследованием |
business_purpose |
Отладка, проверка мошенничества, проверка безопасности, legal hold или поддержка с согласия клиента |
data_scope |
Точные разрешённые поля, а не "полный payload" по умолчанию |
access_group |
Названные люди или роль с доступом, ограниченным по времени |
retention_until |
Дата или событие, завершающее исключение |
reviewer |
Безопасность, юристы, privacy или владелец продукта |
customer_notice_required |
Да/нет с обоснованием |
deletion_or_redaction_task |
Последующая задача в тикете, которая замыкает процесс |
Путь исключений должен быть достаточно строгим, чтобы предотвратить небрежный доступ к исходному payload, и достаточно быстрым для реагирования на инциденты. Для обычной отладки сначала используйте синтетические воспроизведения или редактированные фикстуры. Для legal hold сохраняйте только тот объём, который требуется юристам. Для поддержки клиентов запрашивайте согласие перед использованием исходного контента, предоставленного клиентом, вне первоначального контекста поддержки.
Закрепите ответственность в политике
Политика без ответственных становится документом на полке. Назначьте решения по поверхностям:
| Поверхность | Основной владелец | Резервный владелец | Периодичность проверки |
|---|---|---|---|
| Классификатор промптов и правила блокировки | Инженерия безопасности | Платформа приложений | Ежемесячно и после инцидентов |
| Сканер ответов | Продуктовая инженерия | Trust and safety | Ежемесячно |
| Поля логов шлюза | Платформенная инженерия | Инженерия безопасности | Ежеквартально |
| График хранения | Privacy/юристы | Инженерия безопасности | Ежеквартально |
| Процесс редактирования в поддержке | Операции поддержки | Операции безопасности | Ежемесячно |
| Де-идентификация экспортов и аналитики | Операции данных/финансов | Privacy/юристы | Ежеквартально |
| Утверждение исключений | Совет по безопасности/privacy | Руководитель инцидента | Для каждого исключения |
Пересматривайте политику редактирования AI API после крупных изменений модели, появления новых модальностей, новых инструментов поддержки, новых обработчиков данных и любого инцидента, связанного с раскрытием промпта или ответа. Редактирование — это не разовый проект с регулярными выражениями. Это живой контроль, который следует за жизненным циклом AI-трафика.
Как покупателям Flatkey следует использовать эту политику
Если ваша команда оценивает унифицированный доступ к AI API, используйте эту политику как чек-лист для закупки. Задавайте одни и те же вопросы, независимо от того, идёт ли трафик через прямые аккаунты провайдера, внутренний прокси или управляемый шлюз:
- Какие поля запросов видны в логах, экспортах, счетах, дашбордах и рабочих процессах поддержки?
- Можно ли отключить, ограничить по области или по времени логирование payload?
- Кто может видеть исходные промпты и ответы?
- Как редактируются тикеты поддержки и вложения?
- Какие настройки хранения являются договорными, настраиваемыми или только операционной практикой?
- Как провайдер обрабатывает субпроцессоров, объём DPA, legal hold и запросы на удаление?
- Какие доказательства покупатель может экспортировать для аудита, не экспортируя исходный контент клиента?
Текущие публичные страницы Flatkey позиционируют его вокруг одного ключа, доступа к моделям, аналитики использования, контроля затрат, предоплаченного баланса и одного счета между провайдерами. Это делает его подходящим местом для централизации операционного обзора AI API. Покупателю по-прежнему нужно проверить настройки на уровне аккаунта, прежде чем считать любой шлюз системой учета для конфиденциальности, хранения или доказательной базы поддержки. Для актуального контекста по тарифу, моделям и пополнению см. цены Flatkey перед утверждением.
Чек-лист внедрения
Используйте этот чек-лист перед первым запуском в production:
- Классифицируйте поля промпта, ответа, метаданных, логов, тикета, скриншота и экспорта.
- Блокируйте секреты и учетные данные до запроса к AI API.
- Токенизируйте или обобщайте персональные идентификаторы, которые не нужны для качества задачи.
- По умолчанию храните только логи метаданных и требуйте утверждения для захвата сырых полезных нагрузок.
- Установите короткое окно хранения для утвержденных debug-данных.
- Проверяйте ответы перед сохранением, экспортом аналитики или передачей в поддержку.
- Редактируйте обращения в поддержку, вложения, скриншоты и трассировки перед эскалацией.
- Документируйте ответственных за исключения, даты хранения и задачи на удаление.
- Проверяйте контроль данных у провайдера, условия DPA, объем subprocessor и настройки аккаунта.
- Пересматривайте политику редактирования AI API после инцидентов, появления новых моделей и нового инструментария поддержки.
Часто задаваемые вопросы
Что такое политика редактирования AI API?
Политика редактирования AI API определяет, какие чувствительные поля должны быть заблокированы, замаскированы, токенизированы, сохранены, удалены или утверждены для промптов, выходных данных модели, логов шлюза, экспортов и обращений в поддержку. Она более конкретна, чем заявление о конфиденциальности, потому что назначает обработку и владельцев на уровне полей.
Достаточно ли нулевого хранения данных у провайдера?
Нет. Нулевое хранение данных или измененное хранение может снизить хранение на стороне провайдера, но не классифицирует ваши собственные промпты, не очищает ваши логи, не редактирует обращения в поддержку и не управляет экспортами. Рассматривайте хранение у провайдера как один из контролей внутри более широкой политики редактирования AI API.
Должны ли логи AI API включать промпты и ответы?
Логи только с метаданными должны быть настройкой по умолчанию для большинства production-трафика. Сохраняйте сырые промпты и ответы только тогда, когда цель отладки или соответствия требованиям утверждена, доступ ограничен, срок хранения короткий, а задача на очистку отслеживается.
Как поддержка должна обрабатывать промпты клиентов?
Поддержка должна запрашивать минимально необходимое воспроизведение, редактировать скопированные промпты и ответы перед широким распространением, удалять секреты из трассировок и скриншотов, а сырые доказательства хранить только в ограниченном инцидентном или support-процессе с ответственным за срок хранения.
С чего должна начать команда Flatkey?
Начните с внутренних связей между логированием полезной нагрузки, хранением данных и управлением шлюзом: изучите логирование полезной нагрузки AI API, сопоставьте это с чек-листом хранения данных AI API, привяжите к вашему чек-листу GDPR для шлюза AI API, затем получите ключ и проверьте настройки на уровне аккаунта перед production.
Итог
Надежная политика редактирования AI API — это та политика, которой могут пользоваться ваши разработчики, команда поддержки, специалист по проверке конфиденциальности и ответственный за финансы. Сохраняйте полезные метаданные. Маскируйте или блокируйте чувствительные значения до того, как они распространятся. Храните сырые полезные нагрузки только для именованных исключений. Редактируйте обращения в поддержку перед эскалацией. Затем используйте обзорный слой шлюза, актуальную документацию провайдера и собственные доказательства DPA, чтобы показать, что политика не просто записана, а действительно работает.
