Проверка области SOC 2 AI API gateway не должна начинаться с бейджа. Она должна начинаться с простого вопроса: какую систему, за какой период, какие контролы, зависимости и обязанности, лежащие на стороне покупателя, отчёт на самом деле охватывал?
Это различие важно для маршрутизации моделей. AI API gateway может находиться между вашим приложением и несколькими поставщиками моделей, семействами конечных точек, журналами, процессами поддержки, записями биллинга и путями резервного переключения. Отчёт SOC 2 Type 2 может быть полезным доказательством для описанной системы вендора gateway и охваченных критериев trust services. Но его не следует считать доказательством того, что каждый upstream-поставщик модели, каждый маршрут, каждая настройка хранения prompt-ов, каждая конфигурация учётной записи покупателя или каждое будущее изменение модели одобрены.
Используйте этот чек-лист области SOC 2 AI API gateway, когда закупки, безопасность, юристы и platform engineering должны решить, что отчёт должен доказать, что он не должен доказывать, и какое дополнительное подтверждение должно входить в пакет на утверждение.
Flatkey релевантен для этой проверки, потому что текущий публичный сайт позиционирует flatkey.ai как AI API gateway и платформу model operations для маршрутизации официального трафика GPT, Claude, Gemini и других моделей через один ключ, с поверхностями для dashboard, billing, routing, usage и operational evidence. Публичные страницы Flatkey и страницы поиска сертификатов — это только предварительные скрининговые доказательства. Для продакшн-утверждения запросите приватный отчёт SOC 2, подписанный контракт/DPA, где применимо, настройки аккаунта, конфигурацию маршрутов и подтверждение поддержки для той рабочей нагрузки, которую вы будете запускать.
Для более широкого контекста закупок сопоставьте эту статью с чек-листом доказательств SOC 2 для AI API gateway, пакетом доказательств для закупки AI gateway и оценкой рисков поставщика AI API.
Область SOC 2 AI API Gateway: Краткая таблица решений
Первая страница проверки должна отделять доказательства из отчёта от дополнительных доказательств, которые должен предоставить покупатель.
| Область проверки | Что отчёт SOC 2 должен помочь доказать | Что он не должен доказывать сам по себе |
|---|---|---|
| Юридическое лицо | Какая сервисная организация была проверена | Что покрыты все аффилированные лица, реселлеры или upstream-поставщики моделей |
| Граница системы | Какая платформа, сервисы, локации, инфраструктура, люди и процессы входят в описанную систему | Что каждая функция dashboard, семейство конечных точек, маршрут клиента или будущая интеграция входят в scope |
| Период отчёта | Период, охваченный проверкой Type 2 | Что текущие контролы не изменились после окончания периода |
| Категории trust services | Какие критерии были охвачены, например security, availability, confidentiality, processing integrity или privacy | Что были проверены категории, которые не были выбраны |
| Проверенные контролы | Какие контролы аудитор тестировал и каковы были результаты за период | Что были протестированы конфигурация покупателя, политика маршрутизации или класс данных рабочей нагрузки |
| Исключения | Были ли отмечены исключения в контролях и как на них отреагировало руководство | Что исключения несущественны для вашей конкретной рабочей нагрузки |
| Организации субсервиса | Включены ли основные зависимости, выведены ли за рамки или покрываются другими отчётами | Что охвачены хранение upstream-модели, обучение, логирование или региональное поведение поставщика |
| CUECs | Какие компенсирующие контролы пользовательской организации должен выполнять покупатель | Что вендор отвечает за хранение ключей покупателя, редактирование, allowlist-ы провайдеров или классификацию данных на уровне приложения |
Это базовое правило области SOC 2 AI API gateway: отчёт — это доказательство, относящееся к описанной системе сервисной организации за определённый период. Это не универсальное одобрение каждого AI-канала, который может создать ваша команда.
Зафиксируйте Пять Полей Области До Изучения Контролей
Не начинайте с поиска безупречного мнения. Начните с пяти полей.
| Поле | Вопрос покупателя | Доказательство для сохранения |
|---|---|---|
| Юрлицо | Какая сервисная организация была подвергнута аудиту? | Титульная страница отчёта, юридическое лицо, контрагент по договору, поиск сертификата, если он публичный |
| Система | Какие сервисы, инфраструктура, команды, процессы и потоки данных включены? | Описание системы, список продуктов/сервисов, схема границы системы |
| Период | Какой период Type 2 охватывал отчёт? | Дата начала, дата окончания, bridge letter при необходимости |
| Критерии | Какие категории trust services были включены? | Scope по security, availability, processing integrity, confidentiality, privacy |
| Зависимости | Какие организации субсервиса и CUECs влияют на мнение? | Метод inclusive/carve-out, список субсервисов, список контролей покупателя |
Для AI gateway поле системы заслуживает наибольшего внимания. «API gateway» может означать только маршрутизацию base URL, а может также включать доступ к dashboard, каталог моделей, баланс аккаунта, учёт usage, журналы запросов, оповещения, workflows поддержки, реагирование на инциденты и управление ключами. Приватный отчёт должен показать вам, что входило в описание системы. Если этого нет, попросите вендора сопоставить область отчёта с точным маршрутом, который вы планируете использовать.
Что Должен Доказать Отчёт SOC 2 Для AI Gateway
Сфокусированный отчёт SOC 2 Type 2 должен помочь покупателю ответить на эти вопросы.
| Область доказательства | Полезные доказательства SOC 2 | Интерпретация для AI gateway |
|---|---|---|
| Проектирование и функционирование контролей | Контроли, протестированные за период отчёта | Работали ли контроли доступа, управления изменениями, мониторинга, реагирования на инциденты, управления поставщиками и связанные контроли для описанной системы gateway |
| Область охвата доступности | Критерии доступности, мониторинг, близкий к SLA, процессы инцидентов, если включены | Имелись ли у охватываемого сервиса определённые контроли мониторинга и реагирования, а не будет ли доступен каждый провайдер модели |
| Область охвата конфиденциальности и приватности | Критерии и контроли, если эти категории включены | Были ли изучены контроли обработки данных клиентов для описанной системы, а не имеет ли каждая функция провайдера одинаковую настройку хранения |
| Управление изменениями | Проверенные релизы, утверждения и контроли изменений | Контролировались ли изменения кода/конфигурации gateway, а не может ли маршрут, одобренный покупателем, быть позже изменён покупателем |
| Контроли доступа | Доступ сотрудников, привилегированный доступ, проверка администраторов, контроли управления учётными записями | Контролировался ли доступ со стороны поставщика, а не хранил ли покупатель API-ключи безопасно |
| Логическая безопасность | Контроли аутентификации, авторизации, логирования, уязвимостей и мониторинга | Существовали ли описанные средства безопасности gateway, а не маскируют ли приложения покупателя секреты перед отправкой запросов |
| Управление поставщиками | Контроли субсервисных организаций и мониторинга поставщиков | Управлялись ли зависимости от поставщиков, а не покрывает ли SOC 2, DPA или настройка хранения каждого вышестоящего провайдера ваш маршрут |
Именно здесь область SOC 2 AI API gateway становится практической. Отчёт может поддержать проверку рисков поставщика. Но его всё равно нужно перевести в факты маршрута: семейство конечных точек, класс данных, разрешённый список провайдеров, политика резервного переключения, логирование запросов/ответов, хранение метаданных, доступ службы поддержки и путь удаления.
Что отчёт не должен доказывать
Самая частая ошибка при закупке — использовать отчёт SOC 2 как замену решениям, для которых он не предназначен.
Не используйте отчёт сам по себе, чтобы доказать:
| Утверждение | Почему это требует дополнительной проверки |
|---|---|
| «Все провайдеры моделей покрыты». | Вышестоящие провайдеры могут быть субсервисными организациями, исключёнными из охвата или находиться вне отчёта gateway. Запросите карту провайдеров и применимые доказательства по каждому провайдеру. |
| «Никакие запросы или ответы нигде не хранятся». | Логи gateway, журналы мониторинга злоупотреблений у провайдера, состояние приложения, тикеты поддержки и резервные копии могут иметь разное поведение хранения. |
| «Обучение не применяется ни к одному маршруту». | Обязательства по обучению и хранению часто зависят от провайдера, аккаунта, конечной точки и функции. Сохраняйте доказательства на уровне аккаунта. |
| «Резервный маршрут одобрен». | Резервный маршрут может отправлять данные другому провайдеру или в другой регион. В записи об одобрении должны быть указаны разрешённые провайдеры резервного маршрута. |
| «Приложение покупателя соответствует требованиям». | SOC 2 касается контролей сервисной организации. Маскирование данных покупателем, хранение ключей, классификация данных и контроли доступа к приложению — это ответственность покупателя. |
| «Проверка privacy или DPA выполнена». | SOC 2 — это не подписанный DPA, не оценка передачи данных, не уведомление о конфиденциальности, не BAA и не обязательство по региональной обработке. |
| «Текущее состояние идентично периоду отчёта». | Период отчёта мог закончиться несколько месяцев назад. Запросите bridge letters, текущие политики, текущую конфигурацию маршрутов и недавние доказательства. |
| «Цена, доступность модели и результаты SLA гарантированы». | Каталоги моделей, цены, лимиты запросов провайдера и доступность третьих сторон могут изменяться вне рамок отчёта SOC 2. |
Если поставщик говорит: «SOC 2 это покрывает», попросите его указать точный раздел, формулировку границы системы, охваченный критерий, контроль, результат теста и любую заметку о CUEC или субсервисной организации.
Читайте о субсервисных организациях до утверждения провайдеров
AI gateway может зависеть от облачного хостинга, платёжных систем, аналитики, инструментов поддержки, средств наблюдаемости, инструментов безопасности и вышестоящих провайдеров моделей. Отчёт SOC 2 должен объяснять, как рассматриваются субсервисные организации. Обычно покупатели видят один из двух подходов:
| Метод | Что это значит для покупателя |
|---|---|
| Инклюзивный метод | Соответствующие контроли субсервисной организации включены в охват отчёта. Проверьте, какие контроли включены. |
| Метод исключения | Субсервисная организация исключена из охвата отчёта. Изучите отдельные доказательства и компенсирующие контроли субсервисной организации. |
Для маршрутизации моделей исключения имеют значение. Отчёт SOC 2 gateway может покрывать контроли управления поставщиками у gateway, оставляя OpenAI, Anthropic, Google или другого вышестоящего провайдера вне проверяемой системы. Это не делает отчёт бесполезным. Это означает, что при проверке области SOC 2 AI API gateway нужно включить строку доказательств по провайдеру для каждого утверждённого маршрута.
Документация провайдера показывает, почему это нельзя вывести из общих соображений. Документация OpenAI по данным API разделяет журналы мониторинга злоупотреблений, состояние приложения, Zero Data Retention, Modified Abuse Monitoring и поведение, специфичное для конечной точки. Документация Anthropic по хранению данных API объясняет, что разные API и функции имеют разные требования к хранению, а ZDR — это соглашение, которое клиенты запрашивают для подходящих сценариев использования. Документация Cloudflare по логированию AI Gateway показывает, как шлюз может предоставлять prompts, responses, provider, timestamp, token usage, cost, duration, DLP actions и управление логированием на уровне payload. Это примеры поверхностей управления, которые покупатель должен проверить для любого маршрута шлюза, а не утверждения о частном отчёте Flatkey.
Рассматривайте CUEC как работу покупателя, а не как шаблонный текст
Взаимодополняющие пользовательские контроли организации не являются заполнителем. Это контроли, которые покупатель должен выполнять, чтобы контроли сервисной организации имели смысл.
Для AI gateway типичные работы со стороны покупателя по CUEC включают:
| Контроль, принадлежащий покупателю | Какие доказательства сохранить |
|---|---|
| Хранение и ротация ключей | Путь в secret manager, владелец, дата ротации, аварийный runbook для ротации |
| Одобрение маршрута | Одобренные семейства конечных точек, allowlist провайдеров, политика fallback, классы данных |
| Редактирование prompt | Правила редактирования на уровне приложения, тестовый transcript, примеры заблокированных полей |
| Проверка доступа | Список администраторов, владельцы ключей, запись об увольнении/выводе из доступа, проверка доступа к панели |
| Политика логирования | Хранятся ли prompts и outputs, правило только метаданных, срок хранения |
| Мониторинг использования | Владелец бюджета, настройки квот, пороги оповещений, периодичность проверки финансами |
| Процесс обработки инцидентов | Request IDs, путь эскалации в поддержку, пакет доказательств, ответственные за уведомления |
| Триггер продления | Дата пересмотра и триггеры для новых провайдеров, семейств конечных точек, классов данных или изменений логирования |
Хорошая записка по SOC 2 AI API gateway scope должна связывать список CUEC с инженерной работой. Если покупатель должен редактировать секреты перед отправкой prompts, согласование должно ссылаться на тест редактирования. Если покупатель должен утверждать providers модели, конфигурация маршрута должна показывать allowlist.
Специфические для Flatkey доказательства проверки, которые нужно запросить и сохранить
Текущие публичные страницы Flatkey, проверенные 11 июля 2026 года, подтверждают использование Flatkey в этом процессе закупки, но не заменяют доказательства на уровне конкретного аккаунта.
| Доказательство | Что показала публичная проверка | Как использовать |
|---|---|---|
| Главная страница | Flatkey публично позиционирует сервис вокруг официальных GPT, Claude и Gemini API через один ключ, маршрутизацию моделей, просмотр на панели, видимость использования, стоимости, маршрутизации и ошибок. | Используйте как датированное доказательство проверки продукта. Не считайте это областью частного SOC 2 отчёта. |
| Страница цен и pricing API | Публичные поверхности цен/каталога возвращали живую страницу цен и ответ pricing API с 158 строками моделей и семействами конечных точек, включая openai, openai-response, anthropic, image-generation и openai-video. |
Используйте только как снимок каталога на дату проверки. Доступность моделей и конечных точек может меняться. |
| Страница SLA | SLA указывает, что он применяется к размещённой панели, API gateway, routing, metering и account services, которыми управляет Flatkey, и исключает сторонних провайдеров AI-моделей и другие внешние системы. | Используйте, чтобы обозначить, чем Flatkey управляет напрямую, а что зависит от сторонних сервисов. |
| Страницы privacy и terms | Публичные страницы политики обсуждают доступ к API, маршрутизацию моделей, записи об использовании, биллинг, поддержку, сторонних провайдеров моделей и изменяемые правила моделей/провайдеров. | Используйте как доказательство проверки; финальное одобрение всё равно требует подписанных условий и подтверждения обработки данных на уровне маршрута. |
| Проверка сертификата | Публичный поиск CAI показал сертификат VOC AI Inc. USA-SOC2-220513, SOC 2 Type II, активен, период с 15 июля 2025 года по 14 июля 2026 года. |
Используйте только как публичный поиск. Запросите фактический отчёт SOC 2 и подтвердите охватываемую систему, критерии, период, исключения, CUEC и обработку subservice. |
Для Flatkey или любого AI API gateway одобрение должно звучать так: "Публичные страницы проверены; частный отчёт запрошен; доказательства по маршруту приложены; неподтверждённые допущения перечислены."
Соберите пакет доказательств от области охвата к маршруту
Итогом этой проверки должен быть небольшой пакет доказательств, а не расплывчатое одобрение.
| Элемент пакета | Файл для сохранения | Владелец |
|---|---|---|
| Отчёт SOC 2 | Частный отчёт, период отчёта, критерии, мнение, исключения, bridging letter при необходимости | Закупки/безопасность |
| Карта области охвата | Границы системы отчёта, сопоставленные с dashboard, gateway, API, metering, logs, support и конфигурацией маршрутов | Инжиниринг платформы |
| Карта провайдеров | Утверждённые провайдеры, порядок резервирования, обработка subservice, отдельные доказательства по провайдеру | Безопасность/платформа |
| Карта данных | Prompts, outputs, files, metadata, billing records, logs, support tickets, backups | Безопасность/юристы |
| Матрица хранения | Сроки хранения gateway, provider, application, support и backup по семействам endpoint | Безопасность/юристы |
| Запись CUEC | Контроли покупателя и доказательства того, что каждый из них реализован | Платформа/безопасность |
| Доказательства тестирования | Один успешный запрос с низким риском и один ожидаемый сбой с request IDs и замаскированными logs | Инжиниринг платформы |
| Меморандум об утверждении | Область охвата, ограничения, открытые риски, имена проверяющих, триггер обновления | Бизнес-владелец/закупки |
Этот пакет также служит связующим звеном между проверкой SOC 2 и инженерной эксплуатацией. Когда добавляется новый провайдер, класс модели, режим логирования или класс данных, команда должна понимать, какие файлы нужно обновить.
Красные флаги, из-за которых следует приостановить утверждение
Приостановите утверждение, если что-то из перечисленного не решено:
- Отчёт SOC 2 недоступен, а предоставлена только badge или lookup по сертификату.
- Период отчёта завершился, и нет ни bridging letter, ни актуальных доказательств.
- В описании системы не указано явно, включает ли оно путь gateway, который вы планируете использовать.
- В отчёте исключены релевантные subservice organizations, и отдельные доказательства по провайдерам не приложены.
- Выбранные категории trust services не соответствуют заявленному риску покупателя, например privacy или confidentiality.
- CUECs требуют от покупателя контролей, которые ещё не внедрены.
- Предполагается, что логирование prompts/outputs отключено, но ни account, ни route evidence этого не подтверждают.
- Fallback может отправить данные неутверждённому провайдеру.
- Support может просматривать содержимое request, но доступ support, хранение tickets и redaction не документированы.
- Утверждение не имеет владельца, даты окончания или триггера изменения маршрута.
Эти красные флаги не всегда означают, что вендор не проходит проверку. Они означают, что review области SOC 2 AI API gateway scope не завершён.
Практическая формулировка утверждения
Полезная формулировка утверждения короткая, конкретная и проверяемая:
| Поле | Пример формулировки |
|---|---|
| Доказательство отчёта | "Отчёт SOC 2 Type 2 проверен для Vendor X, период A to B, критерии security и availability, без не принятых исключений для этого маршрута." |
| Утверждённая область | "Production text-only support workflow через утверждённый base URL gateway и chat endpoint." |
| Провайдеры | "Provider A primary, Provider B fallback; без image, video, file, web-search или batch endpoint." |
| Класс данных | "Customer support text после application-level redaction; без payment data, secrets, PHI или regulated records." |
| Логирование | "Gateway metadata logs разрешены; raw prompt/output logging отключено или отдельно одобрено; доказательства хранения provider приложены." |
| Контроли покупателя | "Ключи хранятся в secret manager, ежеквартальный review доступа, route allowlist, ежемесячный review использования, назначен владелец инцидентов." |
| Триггер обновления | "Обновить до добавления провайдеров, включения новых семейств endpoint, изменения логирования, маршрутизации regulated data или после истечения периода SOC 2." |
Именно это и должно означать "approved". Разработчики знают, какой маршрут могут использовать. Закупки знают, какие доказательства были проверены. Безопасность знает, что отслеживать. Юристы знают, какие допущения всё ещё требуют формулировок в договоре.
Итог
Review SOC 2 AI API gateway scope ценен, когда он остаётся точным. Отчёт должен помогать доказать описанную систему проверенной service organization, охваченные критерии, работу контролей, период отчёта, исключения, обработку subservice и обязанности покупателя. Его не следует растягивать до доказательства каждого маршрута, провайдера, настройки хранения, поведения fallback, условия DPA, заявления о data residency или конфигурации покупателя.
Для Flatkey начните с текущих публичных доказательств, затем запросите частный отчёт SOC 2 и сопоставьте его с маршрутом, который ваша команда действительно будет запускать. Если вам нужен один API key и одна dashboard для доступа к нескольким моделям, получите ключ, приложите чек-лист SOC 2 AI API gateway scope к пакету для закупки и утверждайте каждый production route с явными доказательствами по provider, logging, retention и CUEC.
Часто задаваемые вопросы
Что такое SOC 2 AI API gateway scope?
SOC 2 AI API gateway scope — это границы отчёта SOC 2, применимые к AI API gateway. Они включают проверяемую организацию, описанную систему, период отчёта, категории trust services, протестированные контроли, subservice organizations, исключения и принадлежащие покупателю CUEC.
Доказывает ли SOC 2, что охвачен каждый provider для AI model?
Нет. SOC 2 может показать, как поставщик шлюза управляет описанной системой и её зависимостями, но upstream-провайдеры моделей могут быть включены в объём, исключены из него или покрываться отдельными доказательствами. Покупателям следует сохранять карту провайдеров для каждого утверждённого маршрута.
Доказывает ли отчёт SOC 2 Type 2 отсутствие хранения промптов?
Не сам по себе. Сроки хранения промптов и ответов могут различаться в шлюзе, у upstream-провайдеров, в состоянии приложения, тикетах поддержки, журналах и резервных копиях. Покупателю следует проверить доказательства хранения данных для конкретных конечных точек, аккаунтов и маршрутов.
Что должно запросить закупочное подразделение после того, как увидит значок SOC 2?
Запросите приватный отчёт SOC 2, период отчёта, охваченные критерии, описание системы, исключения, подход к субсервисным организациям, CUECs, при необходимости bridge letter, карту провайдеров, конфигурацию маршрутов, настройки логирования, матрицу хранения и, где применимо, подписанный контракт / доказательства DPA.
Как часто следует обновлять пересмотр области охвата?
Обновляйте пересмотр области охвата AI API gateway по SOC 2, когда истекает период отчёта, когда поставщик предоставляет новый отчёт, перед добавлением провайдера или семейства конечных точек, перед маршрутизацией нового класса данных, при изменении логирования или хранения, а также после существенных инцидентов.
Источники для ознакомления
- Главная страница Flatkey
- Тарифы Flatkey
- Политика конфиденциальности Flatkey
- Условия обслуживания Flatkey
- Соглашение об уровне сервиса Flatkey
- Поиск сертификата CAI SOC 2 для USA-SOC2-220513
- Набор услуг AICPA SOC
- Критерии доверительных сервисов AICPA 2017 с пересмотренными точками фокуса
- Критерии описания SOC 2 AICPA 2018
- Контроли данных API OpenAI
- API Anthropic и хранение данных
- Логирование Cloudflare AI Gateway
