Маршрутизиране на AI API, съобразено със запазването на данни: Приложете ZDR, политики за пребиваване и регистриране на шлюза

Екипите по сигурността не само трябва да знаят кой модел е най-евтиният, най-бързият или най-мощният. Те трябва да знаят дали конкретна заявка може законно и оперативно да бъде изпратена до конкретен доставчик, крайна точка, регион, функция и режим на регистриране.

Това е по-трудно, отколкото звучи. Един модел може да е приемлив за обикновен вътрешен чат, но не и за PII на клиента. Доставчикът може да предложи нулево задържане на данни за един API път, докато функцията за заземяване на търсене съхранява подкани и изходи за фиксиран период. Регионът може да поддържа пребиваване на съхранение, но не и режима на обработка, който очаквате. Притежаваните от разработчиците регистрационни файлове може да могат да се конфигурират, докато регистрационните файлове за наблюдение на злоупотреби на доставчик следват различна политика.

Практическият отговор е да преместите решенията за задържане от отделните приложения към шлюза на AI API. Шлюзът трябва да класифицира заявката, да я оцени спрямо матрица на възможностите на доставчика, да блокира несъвместими функции, да насочва само към одобрени профили на модели и да записва решение за политика, без да съхранява необработени подкани по подразбиране.

Проблемът с четеца: условията за поверителност на доставчика не са контроли по време на изпълнение

Повечето екипи започват с електронна таблица или преглед на сигурността, който казва кои доставчици на AI са одобрени. Това е полезно, но не е достатъчно за производствен маршрут.

Приложенията правят избор по време на изпълнение:

• Кой идентификатор на модел трябва да обработи тази заявка?
• Трябва ли заявката да използва заземяване на търсене, качване на файл, изпълнение на код, групова обработка, бързо кеширане или съхранени разговори?
• Кой регион или крайна точка трябва да обработи заявката?
• Може ли системата да регистрира необработената подкана за отстраняване на грешки?
• Може ли резервното маршрутизиране да изпрати същата заявка до друг доставчик?

Всеки от тези избори може да промени профила на задържане. Заявка, която е била съвместима в режим на обикновен чат, може да стане несъответстваща, когато разработчикът включи заземяване или постоянно съхранение на разговори. Резервно правило, предназначено за надеждност, може случайно да насочи регулирани данни към път на доставчик, който не е одобрен за нулево задържане на данни, постоянно пребиваване на данни или контроли за наблюдение на злоупотреби.

Препоръка: третирайте поведението на задържане като първокласно ограничение за маршрутизиране, а не като документация, прикачена към акаунт на доставчик.

Факти, които трябва да се кодират, преди да се създаде политика

Точните условия варират според доставчика, продукта, договора, региона, крайната точка и функцията. Не разчитайте на памет или еднократен преглед. Изградете матрица, притежавана от източника, и я актуализирайте, когато условията се променят.

Няколко текущи документа на обществени доставчици илюстрират защо това е необходимо:

• OpenAI: Пребиваването на данни на API е документирано като конфигурирано за проект, като регионалните заявки изискват специфични за региона префикси на домейн. OpenAI също така разграничава поддръжката за съхранение от поддръжката за обработка по региони и отбелязва допълнителни изисквания за региони извън САЩ. OpenAI заявява, че пребиваването на данни на API извън САЩ изисква одобрение за контроли за наблюдение на злоупотреби и изменение на модифицираното запазване.
• Anthropic: Anthropic документира нулево задържане на данни за случаи на търговска употреба, свързани с API, като същевременно отбелязва, че някои свързани продукти или емисии за съответствие имат отделни модели на задържане, включително по-дълго задържане за емисия за активност и преписи на отдалечени сесии.
• Google Gemini: Условията на API на Gemini разграничават неплатените и платените услуги. За неплатени услуги Google може да използва изпратено съдържание и генерирани отговори за подобряване на продуктите; за платените услуги Google казва, че подканите и отговорите не се използват за подобряване на продуктите. В документацията на ZDR API за разработчици на Gemini се казва, че регистрационните файлове за наблюдение на злоупотреби с платени услуги обикновено запазват подкани и отговори за ограничен период от време, докато одобрените ZDR проектират ясно потребителско съдържание и идентифицируеми метаданни преди регистриране.
• Съхранение за специфични функции: В документацията на Gemini се посочва, че Grounding с Google Търсене и Grounding с Google Карти съхраняват подкани, контекстна информация и генериран резултат за 30 дни, без начин да деактивирате това хранилище, когато се използват тези функции.
• Регистрационни файлове, притежавани от разработчици: В документацията за регистриране на API на Gemini се казва, че регистрационните файлове на API, притежавани от разработчици, могат да се съхраняват до 55 дни по подразбиране за проекти с активирано таксуване и че разработчиците могат да избират по-кратки прозорци като 7, 14 или 28 дни.
• Управление на риска: Generative AI Profile на NIST препоръчва наблюдение на съдържанието, генерирано от AI, за рискове за поверителността и свързване на политиките за генериране на AI със съществуващи данни, софтуер, правни процеси, процеси за съответствие и управление на риска.

Това са факти, които трябва да се проверят спрямо текущата документация на доставчика преди внедряване. Архитектурният урок е стабилен: задържането не е едно логическо значение на ниво доставчик.

Архитектура: машина за политика на шлюз в пътя на заявката

Шлюзът, който поддържа задържане, има пет основни компонента:

1. Класификатор на чувствителността на заявката: обозначава натоварването преди маршрутизиране.
2. Матрица на възможностите на доставчика: описва доставчик, модел, крайна точка, регион, задържане, регистриране и поведение на функциите.
3. Правила за политика като код: преобразувайте изискванията за сигурност в решения за разрешаване, отказ или преглед на време на изпълнение.
4. Слой за шлюз на функции: блокира функции, променящи запазването, освен ако не е изрично разрешено.
5. Слой за одит и анализ: записва полезни метаданни, без да съхранява необработени подкани по подразбиране.

Не е необходимо порталът да разбира всеки правен нюанс. Той трябва да наложи решенията, които вашите екипи по правни въпроси, сигурност, съответствие и платформа са одобрили.

Стъпка 1: класифицирайте чувствителността на заявката, преди да изберете модел

Започнете с малка класификационна таксономия. Трябва да е достатъчно просто, за да го използват разработчиците, но достатъчно изразително, за да ръководи политиката.

Примерни етикети за чувствителност:

• публично: публична документация, маркетингово копие, съдържание на публичен уебсайт.
• вътрешен: непублична информация за компанията с ниска чувствителност.
• поверително: стратегия, договори, клиентски контекст, непубликувани подробности за продукта.
• customer_pii: имена, имейли, адреси, идентификатори на акаунти, преписи за поддръжка.
• регулирани: здравни, финансови, правни, образователни или специфични за юрисдикцията защитени данни.
• изходен_код: собствен код, конфигурация, файлове с архитектура.
• идентификационни данни: тайни, токени, пароли, лични ключове. В повечето системи това трябва да бъде блокирано, а не маршрутизирано.

Класификацията може да идва от множество източници:

• Заглавка, предоставена от приложението, като X-Data-Class: customer_pii.
• Политика за наемател, при която целият трафик от регулиран клиент се третира като регулиран, освен ако не бъде понижен от одобрено правило.
• Политика за крайна точка, където обобщаването на билета за поддръжка е по подразбиране customer_pii.
• Олекотено сканиране на съдържание за идентификационни данни, очевидни лични данни или нарушения на правилата.

Препоръка: не разчитайте изцяло на автоматичното откриване. Изисквайте от приложенията да декларират предвидения клас данни, след което използвайте сканиране, за да хванете очевидни несъответствия или принудете по-безопасен клас.

Стъпка 2: изградете матрица за възможности на доставчик

Матрицата на възможностите е източникът на истина, който рутерът оценява. Той трябва да бъде версиран, прегледан и тестван като производствена конфигурация.

Примерни полета:

<пре><код>{ "profile_id": "provider_x.chat.eu.zdr", "доставчик": "доставчик_x", "модел": "модел-голям", "api_family": "chat_completions", "крайна точка": "https://eu.example-provider.com/v1", "регион": "ес", "processing_residency": ["eu"], "storage_residency": ["eu"], "zdr_eligible": вярно, "zdr_contract_required": вярно, "training_use": "not_used_for_training_on_paid_api", "abuse_monitoring": "approved_modified_retention_required", "developer_log_retention_days": 0, "raw_prompt_logging_allowed": невярно, "поддържани_функции": { "plain_chat": вярно, "стрийминг": вярно, "tool_calls": вярно, "search_grounding": невярно, "maps_grounding": невярно, "file_upload": невярно, "партида": невярно, "stored_conversations": невярно }, "последно прегледано": "2026-08-01", "source_refs": ["security-review-123", "vendor-doc-version-abc"] }

Използвайте профили на модели, а не необработени идентификатори на модели. Профилът съчетава модел, доставчик, крайна точка, регион, набор от функции и позиция на задържане. Разработчиците изискват model_profile: compliant_summarization, а не само model: fastest-large-model.

Препоръка: включете договорните предпоставки в матрицата. Даден маршрут не е одобрен от ZDR само защото доставчик предлага ZDR някъде. Одобрява се само когато вашият акаунт, проект, регион и крайна точка отговарят на необходимите условия.

Стъпка 3: напишете правила за политика като код

Правилата на правилата трябва да са изрични, тествани и четими от екипите по сигурността и платформата.

Примерни правила в псевдокод:

откажи, ако data_class == "идентификационни данни"
  причина "идентификационните_данни_не трябва_да_се_изпращат_на_модел"
позволява само ако data_class в ["regulated", "customer_pii"]
  и profile.zdr_eligible == true
  и profile.zdr_contract_required_satisfied == вярно
  reason_on_failure "model_profile_not_zdr_eligible"
откажи, ако residency_required == "eu"
  и "eu" не в profile.processing_residency
  причина "region_processing_not_supported"
deny if data_class в ["confidential", "customer_pii", "regulated"]и request.raw_prompt_logging == вярно
  причина "raw_prompt_logging_not_allowed"
откажи, ако request.features.search_grounding == true
  и policy.requires_zdr == вярно
  и profile.feature_storage.search_grounding_days > 0
  причина "grounding_requires_retained_content"
откажи, ако fallback_profile.retention_level < primary_profile.retention_level
  причина "fallback_weakens_retention_policy"

Тези правила трябва да се изпълняват преди избор на доставчик и отново преди резервен вариант. Резервното маршрутизиране е често срещан източник на случайно отклонение в правилата: основният маршрут може да е съвместим, докато резервният маршрут е просто наличен.

Стъпка 4: третирайте инструментите и функциите като способности за промяна на запазването

Не моделирайте задържането като свойство само на основния модел. Функциите често променят поведението за съхранение, регистриране или преглед.

Дайте на всяка функция свои собствени флагове на правилата:

• Заземяване на търсенето: може да съхранява подкани, извлечен контекст и генериран резултат в зависимост от условията на доставчика.
• Карти или заземяване на местоположение: може да въведе регистрационни файлове или правила за запазване, специфични за местоположението.
• Качване на файл: може да съхранява файлове отделно от подкани и отговори.
• Изпълнение на код: може да създаде временни файлове, регистрационни файлове за изпълнение или артефакти в пясъчника.
• Пакетни задания: може да имат различно поведение при задържане, нареждане на опашка и съхранение на резултати от синхронните извиквания на API.
• Съхранени разговори: умишлено запазват съдържанието и никога не трябва да бъдат скрити зад обща опция за чат.
• Табла за управление за оценка или преглед: могат да създадат работни процеси за преглед от човек или по-дълготрайни набори от данни.

Препоръка: направете включване на функциите за промяна на запазването на ниво наемател и маршрут. Ако разработчик активира grounding_search=true, шлюзът трябва да преоцени заявката спрямо правилата за съхранение на функции, преди да я изпрати нагоре.

Стъпка 5: запазване на анализите без съхраняване на необработени подкани

Маршрутизирането с съзнание за задържане не трябва да заслепява екипа на платформата. Можете да поддържате полезен анализ на използването на AI, като минимизирате съхранението на съдържание.

Безопасни телеметрични полета по подразбиране:

• ID на наемателя и ID на проекта
• идентификатор на хеширан или вътрешен API ключ
• идентификатор на профил на модел и идентификационен номер на доставчик
• заявка за време и регион
• входен, изходен, кеширан и разсъждаващ токен се броят, когато са налични
• закъснение, код на състоянието, брой повторни опити и резервно решение
• приблизителна и уредена цена
• етикет за класификация на данни
• версия на политиката и причина за решение за политика
• заявени и разрешени флагове за функции

Избягвайте да съхранявате необработени подкани и изходни данни на модела по подразбиране за поверителен трафик. Ако отстраняването на грешки изисква съдържание, използвайте контролиран работен процес:

• одобрение от клиент или наемател
• тесен времеви прозорец
• лимит на вземане на проби
• пропуск за редактиране
• отделен контрол на достъпа
• кратко изтичане
• журнал за проверка на това кой го е активирал и защо

Това е компромис. Блокирането на необработени регистрационни файлове за подкана затруднява отстраняването на грешки, поддръжката, прегледа на качеството и разследването на злоупотреби. Но съхраняването на всичко по подразбиране създава по-голяма повърхност за поверителност, нарушения и съответствие.

Стъпка 6: връщане на основателни причини за отказ

Общ 403 forbidden разочарова разработчиците и насърчава заобиколни решения. Върнете стабилна машинно четима причина и четимо от хора обяснение.

Примерен отговор:

<пре><код>{ "грешка": { "type": "policy_denied", "код": "заземяване_изисква_30_дневно_съхранение", "message": "Заземяването на търсенето не е разрешено за работни натоварвания, маркирани с requires_zdr, тъй като тази функция на доставчика съхранява подкана, контекст и изходно съдържание.", "request_id": "req_123", "policy_version": "политика-задържане-2026-08-01", "allowed_actions": [ "disable_search_grounding", "choose_profile:zdr_plain_chat", "request_exception" ] } }

Полезните кодове за отказ включват:

• model_profile_not_zdr_eligible
• region_processing_not_supported
• storage_residency_not_supported
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• fallback_weakens_retention_policy
• contract_prerequisite_missing
• credentials_detected

Стъпка 7: добавете работен поток за изключение, а не скрит байпас

Някои изключения са законни: реакция при инцидент, одобрено от клиента отстраняване на грешки, тестване за миграция или временно ограничение на доставчика. Шлюзът трябва да поддържа изключения, без да ги превръща в постоянна политика в сянка.

Всяко изключение трябва да включва:

• самоличност на одобряващия
• искащ екип или наемател
• връзка за билет или преглед на риска
• бизнес обосновка
• разрешени профили и функции на модели
• покрити класове данни
• срок на годност
• допълнителни изисквания за регистриране

Препоръка: направете изключенията по-тесни от обичайната политика. Избягвайте глобални превключватели като disable_retention_policy=true. Предпочитайте замени с обхват, като например „разрешаване на подкана за отстраняване на грешки за клиент A, крайна точка B, за 24 часа, с редактиране и одобрение за сигурност.“

Оперативен контролен списък

• Създайте матрица на възможностите на доставчика с версии.
• Задайте собственик за условията на доставчика, предпоставките за договора и прегледите на задържането.
• Изискване от приложенията да декларират клас данни, изискване за пребиваване и изисквани функции.
• Поверителен и регулиран трафик по подразбиране без необработено бързо регистриране.
• Представете инструменти, заземяване, качване на файлове, групови и съхранени разговори като отделни флагове за възможности.
• Изпълнете проверки на правилата преди основното маршрутизиране и преди резервното маршрутизиране.
• Версия на правилата за регистрационни файлове, профил на модела, клас данни, флагове за функции и причина за отказ.
• Пазете аналитичните метаданни отделно от подканите и изходното съдържание.
• Тест представител разрешава и отказва случаи в CI.
• Преглед на промените в правилата всеки път, когато доставчик промени условия, региони, крайни точки или функции.

Компромиси, които трябва да бъдат изрични

Стриктното маршрутизиране намалява избора. ZDR и ограниченията за пребиваване може да попречат на използването на най-новия модел, най-евтиния маршрут или богата на функции крайна точка.

Регионалното маршрутизиране може да увеличи забавянето или цената. Най-близкият съвместим регион може да не поддържа желания режим на обработка или може да изисква различен път на доставчик.

Гейтовете на функциите изненадват разработчиците. Разработчикът може да мисли, че активира само търсене, но сигурността вижда ново поведение при задържане. Документирането и съобщенията за отказ намаляват триенето.

Бързото минимизиране усложнява отстраняването на грешки. Екипите се нуждаят от редактирани проби, одобрени от клиента прозорци за отстраняване на грешки и надеждни метаданни, за да разследват проблеми, без да съхраняват всичко.

Матрицата изисква поддръжка. Условията на доставчика се променят. Пускане на нови модели. Регионите се разширяват. Функциите преминават от бета към производствена. Остарялата матрица е по-лоша от липсата на матрица, защото създава фалшива увереност.

Какво е препоръка и какво е прогноза?

Препоръки: наложете задържане на шлюза, класифицирайте заявките преди маршрутизиране, изградете матрица на възможностите на доставчика, блокирайте функциите, променящи запазването, по правила, избягвайте необработено записване на подкани по подразбиране и проверете всяко решение за правила.

Прогноза: Екипите на платформата за изкуствен интелект все повече ще третират положението на поверителността като част от избора на модел. Вместо да питаме „кой модел да използваме?“ приложенията ще поискат профил на модел, който отговаря на ограниченията за капацитет, цена, латентност, пребиваване и задържане.

Прогноза: специфичните за доставчика функции за поверителност ще продължат да се различават. Шлюзове, които нормализират само форматите на заявка и отговор, няма да са достатъчни; производствените екипи също ще се нуждаят от нормализиране на правилата.

Изпълнимо заключение

Маршрутизирането със запазване на данни не е отделно табло за управление на съответствието. Принадлежи към пътя на заявката.

Започнете с три резултата: таксономия на чувствителността на заявките, матрица на възможностите на доставчика с версии и малък набор от правила за политика като код за ZDR, пребиваване, необработено регистриране, резервни функции и функции за промяна на запазването. След това накарайте шлюза да връща ясни причини за отказ и да запази анализите, без да съхранява необработено съдържание по подразбиране.

Този дизайн централизира решенията, които иначе биха били разпръснати между опциите на SDK, променливите на средата, конзолите на доставчика и специфичните за екипа конвенции. Той също така предоставя на екипите по сигурността и платформата практическа следа за одит: коя заявка е разрешена, коя версия на политиката е приложена, кой профил на модела е избран и защо.

Свързано четене

• safe prompt регистриране и анализ на използването на ниво шлюз
• изграждане на матрица за възможности на доставчик по време на OpenAI-съвместима миграция на API
• инструменти за управляващ агент с обхват, одобрения и одитни пътеки