Пакет подтверждающих документов для закупки AI-шлюза должен сделать утверждение повторяемым. Это не папка с заявлениями поставщика. Это принадлежащее покупателю доказательство того, что службы безопасности, юридический отдел, инженеры платформы, финансовый отдел и владелец бизнеса рассмотрели одно и то же поведение шлюза до того, как через него пошел трафик.
Это важно, потому что AI-шлюз находится между вашими приложениями и поставщиками моделей. Он может влиять на ключи, маршруты, доступ к поставщикам, биллинг, обработку запросов и ответов, журналы, квоты, поведение при сбоях и реагирование на инциденты. Если в записи об утверждении указано только «страница доверия проверена», то следующее продление, аудит, сбой или вопрос о данных начнется с нуля.
Flatkey создан для команд, которым нужен единый интерфейс AI API-шлюза для доступа к моделям, маршрутизации, биллинга, аналитики использования и операционного контроля. Прежде чем утверждать любой шлюз, включая Flatkey, сохраните датированные доказательства, которые показывают, что было рассмотрено, кто это принял, какие предположения все еще требуют подтверждения на уровне учетной записи и что должно послужить поводом для пересмотра при продлении.
Краткий обзор пакета подтверждающих документов для закупки AI-шлюза
Используйте эту таблицу в качестве первой страницы пакета. Имя файла должно включать поставщика, среду, владельца бизнеса, дату утверждения и дату продления.
| Файл с доказательствами | Сохранить до утверждения | Владелец | Триггер для продления |
|---|---|---|---|
| Идентификация поставщика | Юридическое лицо, контактная информация службы поддержки, контрагент по договору, текущие условия, политика конфиденциальности, политика возврата средств и страницы SLA | Закупки и юридический отдел | Изменение юридического лица, условий, политики конфиденциальности, платежей или SLA |
| Область применения шлюза | Что будет обслуживать шлюз: семейства конечных точек, приложения, среды, поставщики моделей, псевдонимы моделей и классы данных | Инженеры платформы | Новое приложение, новое семейство конечных точек, новый поставщик, регулируемая рабочая нагрузка |
| Обработка данных | Политика конфиденциальности, DPA или условия обработки данных, настройки хранения, политика полезной нагрузки журналов, условия сквозной передачи поставщику и средства редактирования | Безопасность и юридический отдел | Изменение в логировании запросов/ответов, запрос ZDR, новая категория данных |
| Контроль доступа | Владельцы ключей, процесс создания ключей, график ротации, процедура увольнения, сервисные учетные записи и границы наименьших привилегий | Безопасность и платформа | Новая команда, обнаружен общий ключ, уход владельца, ротация производственного ключа |
| Аудит и журналы | Поля ID запроса, экспорт данных об использовании, атрибуция владельца, поля для биллинга, записи об ошибках и лимиты хранения | Безопасность и финансовый отдел | Запрос на аудит, инцидент, отсутствие владельца затрат, изменение поля журнала |
| Биллинг и квоты | Текущая страница с ценами, условия предоплаты или выставления счетов, лимиты квот, политика пополнения, процесс возврата средств и владелец бюджета | Финансы и операционный отдел | Изменение цены, новый класс моделей, исчерпание кредитов, проблема со счетом |
| Надежность | Страница состояния или процесс реагирования на инциденты, SLA, условия технического обслуживания, политика резервирования, проверка работоспособности маршрута и владелец отката | Инженеры платформы | Сбой, изменение маршрута поставщика, ухудшение задержки, неудачный дымовой тест |
| Подписание | Служебная записка об утверждении, открытые риски, исключения, протокол тестирования, принятые сценарии использования и дата рассмотрения | Владелец бизнеса | Любое существенное изменение в области применения, политике, ценах или архитектуре |
Практическое правило: если рецензенту понадобится тот же артефакт во время продления, инцидента, опроса по безопасности или финансового спора, он должен быть включен в пакет подтверждающих документов для закупки AI-шлюза.
Начните с идентификации, полномочий и области применения
Отдел закупок должен иметь возможность ответить на три вопроса, не открывая чат: кто является контрагентом, что мы покупаем и кто утвердил область применения?
Для Flatkey сохраните датированные копии общедоступных страниц, которые имеют значение для договора и операционной документации: главная страница, цены, условия, политика конфиденциальности, соглашение об уровне обслуживания и политика возврата средств. Текущая страница с ценами Flatkey описывает самостоятельное пополнение по предоплате, поддержку корпоративных закупок, единый баланс для моделей GPT, Claude, Gemini, DeepSeek, а также моделей для работы с изображениями, аудио и видео, и учет использования по модели, типу токена и журналам запросов. Сохраните ту страницу, которую вы просматривали, а не полагайтесь на запомненную цену или список моделей.
Затем определите область применения на языке покупателя:
| Вопрос об области применения | Доказательства для сохранения | Почему это важно |
|---|---|---|
| Какие среды будут использовать шлюз? | Список сред: разработка, стейджинг, продакшн, пакетная обработка и оценка | Предотвращает наследование непроверенного тестового исключения производственным трафиком |
| Какие приложения входят в область применения? | Названия приложений, владельцы и классификация данных | Позволяет службе безопасности сопоставить использование шлюза с реальными системами |
| Какие семейства конечных точек требуются? | Чат, ответы, сообщения, изображения, видео или маршруты для конкретных поставщиков | Позволяет избежать утверждения одного маршрута и случайного использования другого |
| Какие поставщики и модели разрешены? | Список поставщиков, псевдонимы моделей, кандидаты для резервирования и запрещенные модели | Обеспечивает соответствие маршрутизации закупкам и политике |
| Какие классы данных могут проходить через шлюз? | Статус данных: общедоступные, внутренние, клиентские, регулируемые, секреты, учетные данные или PHI | Определяет, достаточно ли доказательств DPA, хранения и редактирования |
Не рассматривайте общее утверждение шлюза как утверждение для каждой будущей модели, поставщика или класса данных. В пакете должно быть указано, что утверждено и что требует дополнительного рассмотрения.
Сохраняйте доказательства конфиденциальности, DPA и хранения как датированные свидетельства
Самая рискованная ошибка при сборе подтверждающих документов для закупки AI-шлюза — это путаница между общедоступной маркетинговой информацией и обработкой данных конкретной учетной записи. Общедоступные документы полезны для предварительной проверки. Для окончательного утверждения все равно потребуются подписанный контракт, соглашение об обработке данных (DPA), настройки учетной записи и любые условия конкретного поставщика, применимые к вашему трафику.
Сохраните эти файлы до утверждения:
| Артефакт данных | Что зафиксировать | Примечание для проверки |
|---|---|---|
| Политика конфиденциальности поставщика | Дата вступления в силу, охватываемые категории данных, данные учетной записи, данные об использовании API, данные поддержки, формулировки о хранении | Публичная политика не заменяет соглашение об обработке данных (DPA) |
| DPA или условия обработки данных | Юридическое лицо, субобработчики, формулировки о передаче данных, права на аудит, процесс при нарушении | Убедитесь, что оно соответствует вашему контрагенту |
| Хранение запросов и ответов | Хранятся ли запросы, результаты, файлы, эмбеддинги, изображения или журналы; TTL по умолчанию и настраиваемые TTL | Отделяйте хранение данных шлюзом от хранения данных поставщиком |
| Сквозная передача поставщику | Какие условия вышестоящего поставщика применяются, когда шлюз направляет трафик к этому поставщику | Шлюз может упростить доступ, но не отменяет обязательств перед нижестоящими системами |
| Элементы управления для редактирования и пропуска данных | Какие поля можно маскировать, пропускать или исключать из журналов | Необходимо перед работой с конфиденциальными данными или данными клиентов |
| Резидентность данных | Регион, резервное копирование, доступ поддержки и заявления о трансграничной обработке | Должно соответствовать юридическим и клиентским обязательствам |
Документация поставщиков показывает, почему это должно быть четко оговорено. Документация Anthropic по хранению данных API различает политику нулевого хранения данных (Zero Data Retention) и другие соглашения, а также отмечает, что некоторые функции или модели требуют хранения в течение определенных периодов. Документация Google Cloud по Gemini Enterprise Agent Platform аналогичным образом представляет нулевое хранение данных как нечто, чего клиенты достигают при соблюдении определенных условий и настроек. AI Risk Management Framework от NIST является добровольным руководством, но в нем четко указано, что надежное использование ИИ зависит от управления рисками на этапах проектирования, использования и оценки, а не от принятия на веру одного заявления поставщика.
Поэтому пакет документов, принадлежащий покупателю, должен включать как общедоступную документацию поставщика, так и подтверждения, специфичные для вашей учетной записи: скриншоты настроек, подписанные дополнения, подтверждения от службы поддержки и краткое изложение того, что все еще остается на уровне предположений.
Подтвердите контроль доступа перед передачей производственных ключей
Утверждение доступа — это не просто «кто может войти в систему». Для AI-шлюза это означает, кто может создавать ключи, ротировать их, просматривать использование, изменять маршруты, утверждать модели, пополнять баланс, экспортировать журналы и отключать трафик.
Сохраните в пакете страницу контроля ключей:
| Элемент контроля | Подтверждение для сохранения | Ошибка, которую нужно избежать |
|---|---|---|
| Владелец ключа | Именованный владелец-человек и резервный владелец для каждого производственного ключа | Ключ-сирота после изменений в команде |
| Область действия ключа | Среда, приложение, маршрут, набор поставщиков и набор моделей | Общий ключ, используемый для несвязанных рабочих нагрузок |
| Ротация | Дата последней ротации, дата следующей ротации и план экстренной ротации | Долгоживущий ключ без владельца |
| Офбординг | Как удаляется доступ, когда инженер или поставщик уходит | Бывший пользователь сохраняет доступ к маршруту или панели управления |
| Использование сервисного аккаунта | Использует ли автоматизация общие учетные данные пользователя, учетные данные сервисного аккаунта или идентификатор рабочей нагрузки | Неотслеживаемые изменения, внесенные автоматизацией |
| Хранение секретов | Путь в менеджере секретов, ссылка в CI/CD и скриншоты без секретов | Ключи API, появляющиеся в тикетах, документах или журналах |
Публичное позиционирование Flatkey, основанное на одном ключе и одной панели управления, полезно для сокращения разрастания учетных записей поставщиков. Отделу закупок все равно потребуется доказательство того, как ваша команда предотвратит превращение этого одного ключа шлюза в общий суперключ. Используйте эту статью вместе с обзором доступа к AI API и журналами аудита использования AI API при построении внутреннего процесса проверки.
Превратите заявления о ведении журналов в файлы аудита
Пакет подтверждающих документов для закупки AI-шлюза должен отвечать на вопросы: что произошло, кто был ответственным, сколько это стоило и что изменилось. Сохраняйте образцы экспортированных данных, а не просто скриншоты графиков с панели управления.
Минимальные поля аудита для проверки:
| Поле аудита | Почему это нужно проверяющим |
|---|---|
| ID запроса и временная метка | Помогает в восстановлении инцидентов и работе с тикетами поддержки |
| Ключ или метка владельца | Связывает трафик с ответственной командой или сервисом |
| Семейство конечных точек и маршрут | Показывает, использовал ли трафик утвержденный путь через шлюз |
| Запрошенная модель и предоставленная модель | Раскрывает поведение маршрутизации, резервного переключения и псевдонимов |
| Поставщик или вышестоящая учетная запись | Отделяет подтверждения от шлюза от подтверждений от нижестоящего поставщика |
| Единицы использования | Токены, изображения, секунды, единицы кэша или другие параметры для выставления счетов |
| Оценочная и фактическая стоимость | Позволяет финансовому отделу анализировать расходы и увеличение затрат из-за повторных попыток |
| Класс ошибки и количество повторных попыток | Показывает, привели ли сбои к дополнительным расходам |
| Статус редактирования | Подтверждает, были ли запросы/ответы записаны в журнал, замаскированы или пропущены |
Сохраните один положительный и один отрицательный тест. Положительный тест доказывает, что обычный запрос виден с ожидаемыми полями владельца, модели, стоимости и маршрута. Отрицательный тест доказывает, что неработающий ключ, заблокированный маршрут, событие квоты или недействительная модель фиксируются без раскрытия секретов.
Для оценки рисков поставщика свяжите эти доказательства с оценкой рисков поставщика AI API. Для эксплуатации свяжите их с регламентами по квотам, повторным попыткам и инцидентам, чтобы журналы были полезны при возникновении сбоев.
Сохраняйте доказательства по ценообразованию, биллингу и квотам
Финансовый отдел не должен утверждать AI-шлюз, основываясь только на заголовке с ценой. Пакет документов должен показывать, как команда будет понимать стоимость за единицу, предоплаченный баланс, записи о пополнении, обработку счетов, возвраты и бюджетные лимиты после запуска трафика.
Сохраните эти финансовые артефакты:
| Финансовый артефакт | Что сохранить |
|---|---|
| Текущая страница с ценами | Датированный PDF или скриншот с классами моделей, единицами измерения и формулировками корпоративного плана |
| Стоимость тестового запроса | ID запроса, модель, единицы ввода/вывода и стоимость, отображаемые на панели управления |
| Процесс пополнения баланса или выставления счетов | Запись о пополнении, образец счета, обработка налогов, платежный процессор или контактное лицо по корпоративному биллингу |
| Настройки квот | Скриншоты квот на уровне ключа, команды или аккаунта и их владелец |
| Политика возврата или оспаривания | Процесс для дублирующихся списаний, неверных удержаний, сбоев доставки, ошибок в счетах и доказательств для поддержки |
| Предположения для продления | Ожидаемое ежемесячное использование, сочетание моделей, диапазон роста и ответственный за пересмотр цен |
Ключевой контроль заключается не в том, приемлема ли сегодняшняя ставка. А в том, сможет ли финансовый отдел воспроизвести цепочку затрат позже. Цены и каталоги провайдеров меняются, особенно для текстовых, графических, аудио- и видеомоделей. Сохраняйте датированные доказательства и требуйте запуска процесса продления при добавлении нового класса моделей или маршрута провайдера.
Проведите дымовое тестирование для утверждения
Перед утверждением проведите один контролируемый тест через предлагаемый маршрут шлюза. Если производственный ключ еще не доступен, проведите его в песочнице с репрезентативными настройками и пометьте доказательства как «предварительные» (pre-production).
Используйте этот тест для утверждения:
- Создайте или выберите утвержденный тестовый ключ.
- Отправьте один запрос с низким риском через утвержденный базовый URL и семейство конечных точек.
- Зафиксируйте ID запроса, псевдоним модели, обслуживаемую модель (если доступно), маршрут, провайдера, задержку, единицы использования и предполагаемую стоимость.
- Убедитесь, что запрос появляется на панели управления или в экспорте под правильным владельцем.
- Спровоцируйте один ожидаемый сбой, например, неверная модель, недействительный ключ, превышение квоты или заблокированный маршрут.
- Убедитесь, что запись о сбое не раскрывает секреты или конфиденциальные данные.
- Сохраните путь отката: как отключить ключ, перенаправить трафик или вернуться к прямому доступу к провайдеру.
Текущий публичный сайт Flatkey направляет пользователей в консоль, на страницу с ценами, страницу моделей и к процессу регистрации, а также позиционирует платформу как решение для доступа через шлюз, маршрутизации, биллинга, аналитики использования и операционного контроля. Этого достаточно для составления плана тестирования для закупки. Но этого недостаточно, чтобы пропустить сбор доказательств, специфичных для аккаунта.
Итоговое утверждение должно включать открытые риски
Последняя страница пакета подтверждающих документов для закупки AI-шлюза должна быть протоколом решения, а не праздничным чек-листом.
Включите:
| Поле решения | Пример |
|---|---|
| Утвержденный сценарий использования | Помощник службы поддержки, внутреннее пакетное суммирование, оценка моделей или инструменты для разработчиков |
| Утвержденный маршрут | Базовый URL, семейство конечных точек, набор провайдеров, псевдонимы моделей и политика отката |
| Утвержденные данные | Только публичные, только внутренние, разрешены клиентские данные, исключены регулируемые данные или PHI разрешена только после подписания BAA |
| Требуемые средства контроля | Владелец ключа, лимит квоты, редактирование журналов, ежемесячный обзор, ответственный за инциденты |
| Открытые риски | DPA в ожидании, ZDR не включен, сквозная передача провайдеру не подтверждена, откат не утвержден |
| Дата пересмотра | Следующее продление, первый месяц эксплуатации или перед добавлением любого нового провайдера/класса моделей |
| Утверждающие лица | Отдел закупок, юридический отдел, отдел безопасности, платформа, финансовый отдел и владелец бизнеса |
Этот протокол обеспечивает честность процесса утверждения. Если риск принят, укажите, кто его принял и когда истекает срок действия этого решения. Если какое-либо утверждение все еще требует доказательств, не хороните его в переписке в чате.
Итог
Хорошие подтверждающие документы для закупки AI-шлюза превращают заявления поставщика в файлы, которые контролирует покупатель: датированные страницы с политиками, условия контракта, настройки аккаунта, владельцы доступа, экспорт аудита, тесты стоимости, протоколы дымового тестирования и триггеры продления.
Для Flatkey начните с сохранения текущих страниц продукта, цен, условий, конфиденциальности, SLA и политики возврата; определите точные приложения, маршруты, модели, провайдеров, классы данных и владельцев в рамках проекта; затем проведите небольшой тест шлюза перед утверждением для использования в производственной среде. Используйте чек-лист по корпоративному AI API-шлюзу для более широкого обзора контроля, затем получите ключ и храните протокол утверждения прикрепленным к команде, которая будет владеть трафиком.
Часто задаваемые вопросы
Что такое подтверждающие документы для закупки AI-шлюза?
Подтверждающие документы для закупки AI-шлюза — это принадлежащий покупателю пакет доказательств, который обосновывает утверждение AI API-шлюза. Он включает датированные страницы поставщика, подписанные условия, доказательства конфиденциальности и хранения данных, подтверждение контроля доступа, образцы аудита, записи о ценах, дымовые тесты и итоговое утверждение.
Достаточно ли страницы доверия для утверждения AI-шлюза?
Нет. Страница доверия — это предварительное доказательство, а не полный протокол утверждения. Покупатели должны сохранить страницу доверия, но им также необходимы объем контракта, статус DPA, настройки аккаунта, информация о владении доступом, образцы журналов, доказательства ценообразования и результаты тестов.
Кто должен владеть пакетом подтверждающих документов для закупки AI-шлюза?
Отдел закупок или юридический отдел могут отвечать за папку с контрактами, но платформенная инженерия должна отвечать за техническую документацию и доказательства дымового тестирования. Служба безопасности должна отвечать за данные, доступ и подтверждения аудита. Финансовый отдел должен отвечать за доказательства, касающиеся цен, использования, квот и счетов.
Как часто следует обновлять пакет подтверждающих документов?
Обновляйте его при продлении, после существенных изменений в политике или ценах, перед добавлением нового провайдера или класса моделей, перед маршрутизацией регулируемых данных и после любого инцидента, который изменяет рабочие предположения шлюза.
Что следует сохранить покупателям Flatkey до утверждения?
Покупатели Flatkey должны сохранять датированные копии главной страницы, страницы с ценами, условий, политики конфиденциальности, SLA, политики возврата средств, области действия моделей и маршрутов, плана владельца ключа, настроек квот, образцов аудита/логов, подтверждений выставления счетов и первого успешного дымового теста шлюза.
