Контрольный список DPA для AI gateway должен делать больше, чем просто подтверждать, что у поставщика есть юридическая страница. Для покупателей маршрутизации моделей главный вопрос в том, совпадает ли подписанное соглашение об обработке данных с тем маршрутом, который ваше приложение будет фактически использовать: логи gateway, вышестоящие поставщики моделей, доступ службы поддержки, региональная маршрутизация, правила хранения, права на удаление и уведомление об инцидентах.
Используйте этот контрольный список DPA для AI gateway перед одобрением единого слоя доступа к моделям, DPA для LLM gateway или соглашения об обработке данных AI API. Это не юридическая консультация. Это практический перечень подтверждающих материалов для команд платформы, безопасности, закупок и юристов, которым нужно, чтобы DPA соответствовал техническому поведению маршрутизации.
Flatkey подходит для этой проверки, потому что текущий публичный сайт позиционирует flatkey.ai вокруг одного API-ключа, базового URL, совместимого с OpenAI, по адресу https://router.flatkey.ai/v1, видимости использования и затрат, журналов запросов, маршрутизации моделей и доступа к провайдерам через одну панель управления. Рассматривайте эти страницы продукта как устаревшие материалы для первичной оценки. Для утверждения приложите подписанную форму заказа, DPA, настройки учетной записи и любое подтверждение от службы поддержки, которое определяет вашу реальную нагрузку.
Если вы выстраиваете более широкий набор контролей, сопоставьте эту проверку с контрольным списком GDPR для AI API gateway, контрольным списком AI API gateway для enterprise, контрольным списком хранения данных AI API и актуальными тарифами Flatkey.
Контрольный список DPA для AI Gateway: начните с маршрута
Первая ошибка — рассматривать поставщика в целом. DPA должен соответствовать конкретному маршруту. Чат-бот поддержки, пакетный классификатор документов, ассистент для программирования и мультимодальный рабочий процесс с медиа могут иметь разные классы данных, конечные точки, условия провайдера, поведение хранения и доступ службы поддержки.
Перед юридической проверкой зафиксируйте следующие факты о маршруте:
| Поле маршрута | Вопрос для ответа | Подтверждение для сохранения |
|---|---|---|
| Владелец рабочей нагрузки | Кто владеет функцией и данными, которые через нее передаются? | Владелец продукта, владелец платформы, рецензент по безопасности |
| Среда | Это разработка, staging, production или клиентская среда? | Конфигурация маршрута, имя проекта, тег среды |
| Семейство конечных точек | Это вызов chat, responses, messages, image, video, embeddings, files или workflow с инструментами? | Конечная точка gateway и конечная точка вышестоящего провайдера |
| Класс данных | Будут ли проходить подсказки, файлы, изображения, аудио, контент клиентов, учетные данные или регулируемые данные? | Примечание о классификации данных и пример обезличенной нагрузки |
| Путь провайдера | Какие поставщики моделей могут получить запрос при обычной маршрутизации и при резервном переключении? | Политика маршрута, список провайдеров, порядок резервирования |
| Путь логирования | Какие системы могут хранить метаданные запросов, подсказки, ответы, ошибки, тикеты в поддержку или выгрузки? | Настройки gateway, документация провайдера, конфигурация наблюдаемости |
| Путь хранения | Что хранится у gateway, у вышестоящего провайдера, в инструментах поддержки и в резервных копиях? | DPA, документы о конфиденциальности, настройки хранения, процедура удаления |
| Область утверждения | Что одобрено и что потребует новой проверки? | Запись о решении и дата истечения срока проверки |
Контрольный список DPA для AI gateway должен завершаться записью об утверждении, привязанной к конкретному маршруту, а не общим заявлением, что «AI одобрен».
Десять вопросов по обработке данных, которые должны задать покупатели
Используйте эти вопросы как основной контрольный список DPA для поставщика AI при любой покупке, связанной с маршрутизацией моделей.
| # | Вопрос по DPA | Почему это важно для маршрутизации моделей | Приемлемые доказательства |
|---|---|---|---|
| 1 | Кто является контролером, обработчиком и субобработчиком для каждого маршрута? | Шлюз может обрабатывать данные напрямую, а также передавать их вышестоящим поставщикам моделей. | Подписанный DPA, список субобработчиков, карта маршрутов/поставщиков |
| 2 | Какие категории данных входят в объем обработки? | "Данные API" могут включать промпты, результаты, загруженные файлы, изображения, журналы, метаданные, биллинговые данные и обращения в поддержку. | Приложение с категориями данных, примеры полезной нагрузки, настройки аккаунта |
| 3 | Какие поставщики могут получить запрос? | Динамическая маршрутизация и резервное переключение могут менять цепочку обработки. | Политика маршрутизации, список разрешенных поставщиков, правила резервного переключения |
| 4 | Сохраняются ли промпты и результаты? | Журналы шлюза и журналы мониторинга злоупотреблений у поставщика могут иметь разное поведение в части хранения. | Конфигурация хранения шлюза, элементы управления данными у поставщика, подтверждение ZDR/MAM, где применимо |
| 5 | Какие метаданные сохраняются? | Даже если содержимое не хранится, метаданные могут раскрывать пользователей, рабочие нагрузки, стоимость, время, IP-адреса или ID клиентов. | Схема журналов, поля аналитики, пример выгрузки биллинга |
| 6 | Какой доступ к поддержке разрешен? | Проверки службой поддержки могут раскрывать записи запросов, скриншоты, журналы или метаданные аккаунта. | Политика доступа поддержки, записи о прозрачности доступа, процесс редактирования тикетов |
| 7 | Какие субобработчики используются? | DPA неполон, если в нем не раскрываются сервисы, которые обрабатывают данные клиентов. | Актуальный список субобработчиков и процесс уведомления |
| 8 | Какой процесс удаления или возврата существует? | Закупкам нужно знать, как удаляются или экспортируются сохраненное содержимое, журналы, файлы и записи аккаунта. | SLA на удаление, шаги в API/панели, примечание об исключениях для резервных копий |
| 9 | Где обрабатываются и хранятся данные? | Региональная маршрутизация, регионы поставщиков, команды поддержки и журналы могут находиться не в одном и том же месте. | Условия по локализации данных, настройка региона маршрута, документация по регионам поставщика |
| 10 | Какие уведомления об инцидентах и доказательства аудита будут доступны? | Покупателям нужен срок для уведомления об утечке, коммуникации по инциденту и предоставления доказательств после проблемы маршрутизации. | Условия уведомления в DPA, SLA, контакт по безопасности, отчет аудита, рабочий процесс по инцидентам |
Если ответ меняется в зависимости от endpoint, функции, поставщика или уровня аккаунта, зафиксируйте это исключение в контрольном списке DPA для AI gateway, а не сглаживайте его.
Сопоставьте формулировки DPA с технической обработкой
Контракты с обработчиком в стиле статьи 28 фокусируются на предмете, сроке, характере, цели, категориях данных, правах контролера, инструкциях обработчика, конфиденциальности, безопасности, субобработчиках, удалении или возврате и содействии в реализации прав субъектов данных. Это юридические термины. Но покупателю шлюза все равно нужно перевести их в инженерные факты.
Используйте такую карту соответствия:
| Термин DPA | Техническая интерпретация для AI gateway |
|---|---|
| Предмет | Инференс модели, маршрутизация, учет, логирование, биллинг, поддержка и администрирование аккаунта |
| Срок | Срок действия контракта, а также то, как долго хранятся журналы, файлы, тикеты поддержки и резервные копии |
| Характер и цель | Передача запросов поставщикам моделей, возврат результатов, измерение использования, обнаружение злоупотреблений, поддержка инцидентов |
| Категории персональных данных | Содержимое промптов, содержимое ответов, загруженные файлы, идентификаторы пользователей, IP-адреса, метаданные аккаунта, контакты для биллинга |
| Инструкции обработчика | Разрешенные маршруты, заблокированные классы данных, одобренные поставщики, обязательства не использовать данные для обучения, настройки хранения |
| Субобработчики | Вышестоящие поставщики моделей, облачный хостинг, платежи, аналитика, поддержка, мониторинг, электронная почта и поставщики безопасности |
| Меры безопасности | Шифрование, контроль доступа, журналирование, управление ключами, сегментация, процесс устранения уязвимостей, доказательства аудита |
| Удаление или возврат | Удаление контента, удаление файлов, истечение срока хранения журналов, редактирование тикетов поддержки, формат экспорта, исключения для резервных копий |
Именно здесь разваливаются многие проверки соглашений об обработке данных для AI API. DPA может говорить, что обработчик действует по инструкциям, тогда как продуктовый маршрут тихо допускает резервное переключение между несколькими поставщиками. В записи об утверждении должно быть указано, какие поставщики разрешены, какие заблокированы и кто может менять эту политику.
Проверьте хранение по endpoint и функции
Элементы управления данными у поставщиков часто зависят от функции. Документация OpenAI по элементам управления данными платформы описывает ограничения на обучение через API, стандартное хранение для мониторинга злоупотреблений, одобренные элементы управления Zero Data Retention или Modified Abuse Monitoring и поведение состояния приложения на уровне endpoint. Документация Anthropic по хранению данных API разделяет обработку Claude API и обработку через облачные маркетплейсы и объясняет право на ZDR в зависимости от функции. Документация Google Gemini Developer API ZDR объясняет ограничения на обучение для платных сервисов и случаи на уровне функций, когда промпты, ответы, файлы, grounding, состояние или поведение кэша все еще могут иметь значение.
Это означает, что "у нас есть ZDR" недостаточно для DPA LLM gateway. Спросите:
- Подпадает ли именно этот конечный адрес под контроль хранения?
- Одобрены ли именно этот проект, организация или аккаунт?
- Ведёт ли резервный маршрут к поставщику или функции, на которые не распространяется покрытие?
- Меняют ли файлы, изображения, аудио, видео, инструменты, веб-поиск, выполнение кода, кэширование контекста, пакетные задания или stateful-разговоры срок хранения?
- Обрабатываются ли журналы мониторинга злоупотреблений, состояние приложения, журналы шлюза, записи поддержки, биллинговые записи и резервные копии отдельно?
Для производственного маршрута сохраните матрицу хранения в одной строке:
| Система | Содержимое хранится? | Метаданные хранятся? | Срок хранения | Путь удаления | Доказательство |
|---|---|---|---|---|---|
| Приложение | Да или нет | Да или нет | Внутренняя политика | Процесс удаления в приложении | Внутренняя карта данных |
| Шлюз | Да или нет | Да или нет | Настройка аккаунта или условие поставщика | Панель/API/поддержка | Доказательства шлюза |
| Поставщик A | Да или нет | Да или нет | Контроль поставщика | Политика поставщика | Документы поставщика |
| Резервный Поставщик B | Да или нет | Да или нет | Контроль поставщика | Политика поставщика | Документы поставщика |
| Инструмент поддержки | Да или нет | Да или нет | Политика по тикетам | Редакция/удаление тикетов | Доказательства поддержки |
Контрольный список DPA для AI gateway считается завершённым только тогда, когда у каждой сохраняемой копии есть владелец, причина и путь удаления или истечения срока действия.
Рассматривайте журналы шлюза отдельно от условий поставщика
Журналы шлюза полезны для надёжности, контроля затрат, отладки и аудиторской проверки. Но это также отдельная поверхность обработки данных. Публичная документация по gateway от поставщиков инфраструктуры показывает, почему покупателям следует задавать этот вопрос прямо: журналы запросов могут включать пользовательские промпты, ответы модели, поставщика, временную метку, статус, использование токенов, стоимость, длительность и метаданные клиента, а ограничения на постоянное хранение журналов могут различаться в зависимости от тарифа.
Задайте эти вопросы по журналированию до подписания:
- Может ли шлюз хранить полные промпты или ответы, или только метаданные?
- Можно ли отключить журналирование промптов и ответов для каждого маршрута, окружения, рабочей области или клиента?
- Можно ли исключать, маскировать, хэшировать или редактировать чувствительные поля перед записью в журнал?
- Копируются ли журналы в аналитику, хранилища данных, системы оповещения, тикеты поддержки или экспорт?
- Кто может просматривать журналы, и фиксируется ли каждый доступ?
- Можно ли удалять журналы досрочно, экспортировать их для аудита или исключать из рабочих процессов поддержки?
- Охватывает ли DPA журналы как данные клиента, системные данные или и то и другое?
В этом и заключается разница между юридической проверкой DPA и операционным контрольным списком DPA для AI gateway. Если ваша политика безопасности требует, чтобы промпты не хранились, маршрут должен доказать, что шлюз, поставщик и процессы поддержки следуют тому же правилу.
Проверьте субпроцессоров и переключение поставщиков
Непосредственный аккаунт у поставщика обычно имеет одну основную цепочку обработки. Маршрутизатор моделей может иметь более длинную цепочку, потому что один маршрут приложения может затрагивать шлюз, вышестоящего поставщика, инструменты наблюдаемости, платёжную инфраструктуру, инструменты поддержки и облачный хостинг. Если включён fallback, запрос может перейти ко второму поставщику, когда первый поставщик недоступен.
Пакет DPA должен отвечать на вопросы:
| Вопрос о субпроцессоре | Что проверить |
|---|---|
| Текущие субпроцессоры | Есть ли опубликованный список, и включает ли он хостинг, поставщиков моделей, поддержку, аналитику и биллинговых вендоров? |
| Уведомление об изменениях | Как покупатель получит уведомление о новых субпроцессорах? |
| Право возражения | Может ли покупатель возразить, расторгнуть договор, отключить маршрут или ограничить поставщика? |
| Разрешённый список поставщиков | Может ли отдел закупок одобрить ограниченный набор поставщиков для конкретной нагрузки? |
| Поведение fallback | Можно ли отключить fallback для чувствительных маршрутов? |
| Региональный охват | Согласованы ли субпроцессоры и регионы поставщиков с требованиями покупателя к резидентности данных? |
| Договорная передача обязательств | Охватывают ли обязательства субпроцессоров конфиденциальность, безопасность, удаление и поддержку инцидентов? |
Для покупателей Flatkey объединяйте публичные доказательства маршрута и ценообразования со средствами контроля на уровне аккаунта. Если ваш маршрут использует один ключ для нескольких моделей, доказательства DPA всё равно должны показывать, какие вышестоящие поставщики могут обрабатывать каждый одобренный класс данных.
Запрашивайте доказательства по поддержке, инцидентам и аудиту
Доступ поддержки легко упустить из виду, потому что обычно он возникает уже после сбоя. Для проверки DPA шлюза поддержка — это часть обработки.
Запросите:
- Контакт поддержки и путь эскалации для инцидентов безопасности или конфиденциальности.
- Могут ли сотрудники поддержки видеть промпты, ответы, журналы, загруженные файлы, скриншоты или метаданные клиента.
- Ограничен ли по времени доступ поддержки, одобряется ли он и журналируется ли.
- Доступны ли записи о прозрачности доступа для подходящих аккаунтов.
- Как редактируются тикеты поддержки, если в них содержатся примеры промптов или ответов.
- Какой срок уведомления об инциденте применяется в рамках DPA, условий, SLA или приложения по безопасности.
- Поможет ли поставщик с запросами субъектов данных, удалением, экспортом и запросами регулятора.
Фреймворк NIST по управлению рисками ИИ полезен здесь как ориентир для governance, потому что он побуждает организации управлять, картировать, измерять и контролировать риски ИИ, а не утверждать маршрут один раз и забывать о нём. Для маршрутизатора моделей это означает, что проверка DPA должна быть возобновляемой. Назначьте дату повторной проверки, ответственных за доказательства и перепроверяйте условия провайдера перед крупными изменениями маршрута.
Соберите пакет доказательств
Практический результат — небольшой пакет доказательств, который могут прочитать юридический отдел, служба безопасности, закупки и платформенные команды.
| Элемент пакета | Файл или запись для сохранения |
|---|---|
| Сводка маршрута | Нагрузка, владелец, endpoint, класс данных, одобренные провайдеры, поведение при fallback |
| DPA | Подписанное соглашение об обработке данных и любое приложение по безопасности или региональное приложение |
| Карта данных | Поток prompt/output от приложения к gateway, к провайдеру и к логам/поддержке |
| Матрица хранения | Сроки хранения для gateway, провайдера, приложения, поддержки, биллинга и резервных копий |
| Доказательства субпроцессоров | Актуальный список субпроцессоров и процесс уведомления об изменениях |
| Контроли аккаунта | Одобрение ZDR/MAM, локализация данных, настройки логирования, allowlist маршрутов, настройки редактирования |
| Пример логов | Редактированный пример, показывающий сохранённые поля, а не секреты |
| Процесс удаления | Как контент, файлы, логи, тикеты и записи аккаунта удаляются или возвращаются |
| Процесс инцидента | Сроки уведомления, контакт, эскалация и доступные доказательства после события |
| Решение об одобрении | Рецензенты, исключения, дата истечения и триггеры изменения маршрута |
Для Flatkey добавьте актуальные публичные доказательства с главной страницы, политики конфиденциальности, страницы с ценами, условий, SLA и панели аккаунта. Публичные страницы могут помочь покупателям предварительно оценить сервис, но для окончательного решения должны использоваться доказательства, привязанные к конкретному аккаунту.
Красные флаги, при которых следует приостановить одобрение
Приостановите проверку маршрута, если что-либо из этого не прояснено:
- DPA называет вендора gateway, но не путь к upstream-провайдеру модели.
- Fallback может отправить чувствительные данные неутверждённому провайдеру.
- Логи prompt или output включены, но DPA или security review не покрывают их.
- Вендор заявляет «no training», но не может ответить по срокам хранения, доступу поддержки, удалению или субпроцессорам.
- ZDR обещан в широком смысле, но выбранный endpoint, функция или аккаунт не имеют права на это.
- Тикеты поддержки могут включать необработанные prompts без процесса редактирования.
- Изменения субпроцессоров не имеют пути уведомления.
- Региональная маршрутизация предполагается, но не подтверждена договором, настройкой аккаунта или доказательствами использования.
- Цены, логи и экспорт использования содержат идентификаторы клиентов, которые не были включены в карту данных.
- У одобрения нет владельца или даты пересмотра.
Эти красные флаги не всегда означают, что вендор непригоден. Они означают, что контрольный список DPA для AI gateway ещё не завершён.
Как выглядит хорошее одобрение
Хорошая запись об одобрении короткая и проверяемая:
| Поле одобрения | Пример формулировки |
|---|---|
| Область | "Маршрут triage для production support, только текстовые prompts, без загрузки файлов, только утверждённые провайдеры A и B." |
| Класс данных | "Текст обращения клиента после редактирования секретов и платёжных данных на уровне приложения." |
| Логирование | "Gateway хранит только метаданные. Приложение хранит отредактированный transcript в течение 30 дней. Срок хранения у провайдера соответствует утверждённому контролю аккаунта." |
| Ограничения | "Без web search, загрузки файлов, входных изображений, пакетной загрузки или fallback вне allowlist." |
| Доказательства | "DPA подписан, список субпроцессоров сохранён, матрица хранения приложена, конфигурация маршрута экспортирована." |
| Возобновление | "Проверить снова перед добавлением провайдеров, сменой семейств endpoint, включением полных логов prompt или отправкой регулируемых данных." |
Этот формат делает DPA операционным. Разработчики знают, что они могут маршрутизировать. Закупки знают, что было одобрено. Служба безопасности знает, что мониторить. У юридического отдела есть доказательства, а не разрозненные обещания.
Итоговый контрольный список DPA для AI Gateway
Прежде чем покупать или расширять маршрутизатор моделей, подтвердите следующие пункты:
- Контрольный список DPA для AI gateway указывает точный маршрут, endpoint, список провайдеров, политику fallback и класс данных.
- Соглашение об обработке данных для AI API покрывает prompts, outputs, файлы, логи, метаданные, тикеты поддержки, записи биллинга и субпроцессоров, где это применимо.
- Логирование gateway и сроки хранения у провайдера рассматриваются как отдельные системы.
- Заявления о ZDR, no-training или изменённых сроках хранения привязаны к конкретному аккаунту, проекту, endpoint и функции.
- Смена провайдера имеет allowlist, владельца и триггер для пересмотра.
- Удаление, экспорт, доступ поддержки, уведомление об инциденте и уведомление об изменении субпроцессора зафиксированы письменно.
- Публичные страницы вендора рассматриваются как датированное screening evidence, а не как замена подписанному DPA.
- У одобрения есть владелец, дата истечения и правило для изменения маршрута.
Если вашей команде нужен один API key и одна панель для доступа к нескольким моделям, начните с Flatkey и держите этот контрольный список DPA для AI gateway рядом с технической проверкой маршрута. Получите ключ, подтвердите текущие контроли аккаунта и одобряйте каждый маршрут с той же дисциплиной, которую вы применяете к любому другому production data processor.
Источники для изучения
- Главная страница Flatkey
- Тарифы Flatkey
- Политика конфиденциальности Flatkey
- Условия обслуживания Flatkey
- Соглашение об уровне обслуживания Flatkey
- Руководство ICO по договорам
- Контроль данных OpenAI
- Дополнение OpenAI об обработке данных
- API Anthropic и хранение данных
- Gemini Developer API: нулевое хранение данных
- Логирование Cloudflare AI Gateway
- Тарифы Cloudflare AI Gateway и постоянные логи
- Фреймворк управления рисками ИИ NIST
