Как да изградите рутер за правила за запазване на данни за API на LLM с множество доставчици

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

Лесно се пропуска режимът на повреда. Екипът започва със завършване на чат без състояние. Маршрутът е приемлив. По-късно някой добавя качване на файл, съхранена история на разговори, уеб заземяване, пакетна обработка или векторно хранилище. Името на модела може да остане същото, но поведението на данните се променя. Обикновен рутер за забавяне или разходи може тихо да изпраща регулирани или обвързани с клиентски договор подкани към път, който съхранява съдържание по-дълго, отколкото позволява работното натоварване.

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

Факти, които да се третират като ограничения на дизайна

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

• OpenAI гласи, че API данните не се използват за обучение или подобряване на модели, освен ако клиентът не се съгласи. Отговарящите на условията клиенти могат да конфигурират Мониторинг на модифицирани злоупотреби или Нулево задържане на данни на ниво организация или проект след одобрение.
Нулевото задържане на данни на
• OpenAI променя поведението на крайната точка, включително третира параметъра store за Отговори и завършвания на чат като false, но някои крайни точки и възможности все още могат да съхраняват състоянието на приложението и не отговарят на условията за нулево задържане на данни.
• Anthropic документира нулево задържане на данни за Claude API, тъй като не съхранява клиентски подкани или отговори в покой след връщането на отговора API, но покритието зависи от крайната точка и допустимостта на функциите.
• Anthropic гласи, че някои Claude функции или обхванати модели може да изискват запазване и може да не са налични при нулево запазване на данни, освен ако не са изрично разрешени.
• Google Облак документира, че Gemini данните от Enterprise Agent Platform не се използват за обучение или фина настройка на AI/ML модели без предварително разрешение или инструкции, но нулевото задържане на данни изисква конкретни действия и може да не е възможно за някои разширени функции.
• Google Облак документира, че Grounding с Google Търсене съхранява извлечени регистрационни файлове на заявки и контекст за до три дни и не може да деактивира това съхранение за тази функция. Той препоръчва Web Grounding за предприятие, когато се изисква нулево запазване на данни.
• Microsoft документира, че хостваните от Azure модели, продавани от Azure, не предоставят подкани и завършвания на OpenAI или други доставчици на модели и не ги използват за обучение на основни модели без разрешение или инструкции.
• Microsoft документира, че типът на внедряване на Azure влияе върху местоположението на обработка. Глобалните внедрявания могат да обработват подкани и отговори във всяка география, където е внедрен моделът, докато внедряванията на DataZone ограничават обработката до избраната зона. Съхранените данни остават в зададената от клиента география.
• Microsoft документира, че някои функции на Azure с поддържане на състоянието съхраняват данни, включително файлове, векторни хранилища, хронология на съобщенията за отговори, нишки на Асистенти, входове за групова обработка и съхранени завършвания.
• Документи на Microsoft, които са одобрили клиентите да могат да променят наблюдението на злоупотреби и че порталът на Azure или CLI може да показва ContentLogging=false, когато съхранението на данни за наблюдение на злоупотреби е изключено.

Това не са подробности за ръбовете. Те означават, че рутерът трябва да оцени заедно крайната точка, функцията, одобрението на акаунта и региона. Етикет за целия доставчик като „разрешен ZDR“ е твърде груб за производствена политика.

Референтна архитектура

Осъзнат мултимоделен AI API шлюз се нуждае от пет компонента в пътя на заявката:

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

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

Дефиниране на канонична политика за задържане

Започнете с обект на политика, неутрален спрямо доставчика. Не копирайте терминологията на един доставчик във вътрешния си договор. Вашата вътрешна политика трябва да описва какво е разрешено да прави работното натоварване, а не как конкретен доставчик предлага контрол.

{
  "policy_id": "support_no_retention_eu_v1",
  "max_content_retention": "none_after_response",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["EU"],
  "stateful_storage_allowed": false,
  "file_storage_allowed": false,
  "grounding_allowed": false,
  "batch_processing_allowed": false,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "route_decision_with_provider_evidence"
}

За по-малко ограничени работни натоварвания използвайте изрично отпускане, вместо липсващи полета:

{
  "policy_id": "internal_analytics_standard_v1",
  "max_content_retention": "30_days",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["US", "EU"],
  "stateful_storage_allowed": true,
  "file_storage_allowed": true,
  "grounding_allowed": true,
  "batch_processing_allowed": true,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "metadata_and_decision"
}

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

Изграждане на регистъра на възможностите на доставчика

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

Полезният запис включва:

• provider: доставчик или облачна платформа.
• account_scope: организация, проект, внедряване, абонамент или клиент, където настройката е одобрена.
• endpoint: чат, отговори, съобщения, партида, файлове, асистенти, вграждания, заземяване, хранилище за вектори или друга API повърхност.
• model_family и по избор model_id: тъй като допустимостта на модела може да е различна.
• region_mode: глобално, регионално, зона за данни, посочена от клиента география или специфичен за доставчика еквивалент.
• content_retention: без съхранение след отговор, запазване при наблюдение на злоупотреби, запазване на състоянието на приложението, извлечени регистрационни файлове с фиксирана продължителност или неизвестно.
• training_use: деактивирано по подразбиране, включване или неизвестно.
• human_review: активиран, променен, деактивиран или неизвестен.
• stateful_storage: дали крайната точка или функция съхранява състояние на разговор, файлове, векторни данни, завършвания или групови входове.
• feature_flags: заземяване, файлове, инструменти, кеш, съхранени изходи, пакет, асистенти или еквивалентни възможности.
• evidence: име на изходния документ, URL, дата на извличане и дата на преглед от собственика.

Пример:

{
  "capability_id": "azure-openai-gpt4o-datazone-chat-zdrlike-v3",
  "provider": "azure_openai",
  "account_scope": "prod-subscription-123",
  "endpoint": "chat_completions",
  "model_family": "gpt-4o",
  "region_mode": "datazone_eu",
  "content_retention": "abuse_monitoring_disabled_when_contentlogging_false",
  "training_use": "disabled_without_permission",
  "human_review": "modified_abuse_monitoring_approved",
  "stateful_storage": false,
  "features": {
    "files": false,
    "vector_store": false,
    "stored_completions": false,
    "grounding": false,
    "batch": false
  },
  "evidence": {
    "source": "provider_data_privacy_and_abuse_monitoring_docs",
    "retrieved_at": "2026-10-08",
    "review_owner": "security-architecture"
  }
}

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

Класифицирайте заявката преди маршрутизиране

Класификацията трябва да се извърши преди избора на модел. Един добър класификатор съчетава статични метаданни и проверка на заявката:

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

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

function resolvePolicy(request) {
  const base = policyForApiKey(request.apiKeyId);
  const tenant = tenantContractPolicy(request.tenantId);
  const features = detectRequestedFeatures(request);
  const sensitivity = classifyPayload(request);

  return strictestApplicablePolicy([base, tenant, features, sensitivity]);
}

На практика това означава, че ключът за поддръжка на клиенти може по подразбиране да не се запазва, докато ключът за вътрешно експериментиране може да позволи по-широко маршрутизиране. Ако същият ключ за поддръжка направи опит за качване на файл, ефективната политика трябва да включва file_storage_allowed=false, освен ако не съществува одобрен маршрут с възможност за работа с файлове.

Оценете политиката преди маршрутизирането на разходите или забавянето

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

function eligibleRoutes(request, policy, capabilities) {
  return capabilities.filter((route) => {
    if (!regionAllowed(route, policy.allowed_regions)) return false;
    if (!retentionAllowed(route, policy.max_content_retention)) return false;
    if (!trainingAllowed(route, policy.training_allowed)) return false;
    if (!humanReviewAllowed(route, policy.human_review_allowed)) return false;
    if (request.usesFiles && !policy.file_storage_allowed) return false;
    if (request.usesFiles && route.features.files !== true) return false;
    if (request.usesGrounding && !policy.grounding_allowed) return false;
    if (request.requiresState && !policy.stateful_storage_allowed) return false;
    if (route.content_retention === "unknown") return false;
    return true;
  });
}

function routeRequest(request) {
  const policy = resolvePolicy(request);
  const candidates = capabilityRegistry.findByModelIntent(request.modelIntent);
  const eligible = eligibleRoutes(request, policy, candidates);

  if (eligible.length === 0) {
    return deny("RETENTION_POLICY_NO_ELIGIBLE_ROUTE", policy.policy_id);
  }

  return chooseByCostLatencyAndHealth(eligible);
}

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

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

Изрично блокиране на рискови комбинации от функции

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

• NO_RETENTION + FILE_UPLOAD: откажете, освен ако конкретната крайна точка на файла и настройката на акаунта не са одобрени за правилото.
• NO_RETENTION + VECTOR_STORE: откажете, освен ако векторното хранилище не е във вашето собствено контролирано хранилище и доставчикът никога не получава постоянно състояние на файла.
• NO_RETENTION + STORED_RESPONSE: принудителен отговор на паметта се изключва или отказва, ако крайната точка не може да деактивира паметта.
• EU_ONLY + GLOBAL_DEPLOYMENT: откажете, ако може да се извърши обработка извън разрешения регион или зона за данни.
• NO_RETENTION + WEB_GROUNDING: откажете, ако функцията за заземяване съхранява извлечени регистрационни файлове на заявка или контекст извън правилата.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: потискане на подканите и съдържанието за завършване от регистрационните файлове и проследяванията на приложението.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: откажете, освен ако функцията не е изрично допустима според одобрените контроли на акаунта.

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

{
  "error": {
    "code": "RETENTION_POLICY_DENIED",
    "reason": "NO_RETENTION_POLICY_DISALLOWS_FILE_STORAGE",
    "policy_id": "support_no_retention_eu_v1",
    "requested_feature": "file_upload",
    "approved_alternatives": [
      "send extracted text without provider file storage",
      "use internal document retrieval with metadata-only provider call",
      "request policy approval for controlled file processing"
    ]
  }
}

Отделно регистриране на изводи от оперативната телеметрия

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

За строги работни натоварвания запазете:

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

Потискане или редактиране:

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

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

Изпращане на одиторски доказателства за всяко решение

Записът за проверка трябва да обяснява защо даден маршрут е разрешен или отказан. Не се нуждае от пълно съдържание, за да бъде полезно.

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_42",
  "policy_id": "support_no_retention_eu_v1",
  "policy_version": 7,
  "decision": "allow",
  "provider": "anthropic",
  "endpoint": "messages",
  "model_family": "claude",
  "region_mode": "approved_region",
  "features": {
    "files": false,
    "grounding": false,
    "stateful_storage": false,
    "batch": false
  },
  "logging_mode": "metadata_only",
  "capability_record_id": "anthropic-claude-messages-zdr-v5",
  "capability_evidence_date": "2026-10-08",
  "reason_codes": [
    "POLICY_MATCHED_NO_RETENTION",
    "REGION_ALLOWED",
    "STATELESS_ENDPOINT",
    "CONTENT_LOGGING_SUPPRESSED"
  ]
}

За отказани заявки запазете същата структура с decision=deny и кодове на причина като REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY или STATEFUL_STORAGE_NOT_ALLOWED.

Използване на договорни тестове за правила за задържане

Маршрутизирането на задържане трябва да има автоматизирани тестове. Важните тестове не са само единични тестове за отделни доставчици; те са договорни тестове за поведение на политика в комбинации от доставчици.

Тестовите случаи с висока стойност включват:

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

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

Оперативна собственост

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

Присвояване на собственици за:

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

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

Компромиси

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

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

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

Бързото и завършващо редактиране защитава чувствителните данни, но отслабва отстраняването на грешки и прегледа на качеството. Използвайте възпроизводими метаданни за заявка, детерминистични тестови приспособления, контролирано вземане на проби за разрешени натоварвания и документиран достъп до счупено стъкло, когато правилата го позволяват.

Препоръки

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

Прогноза: Маршрутизирането на задържането ще стане стандартен слой на шлюза

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

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

Приложимо заключение

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

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

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

• неутрален спрямо доставчик LLM дизайн за наблюдение