Како направити рутер са смерницама за задржавање података за ЛЛМ АПИ-је са више добављача

ЛЛМ рутер са више добављача не би требало да прво бира модел, а касније да поставља питања о задржавању. Ако је ток посла за подршку означен као без задржавања, мрежни пролаз мора да зна да ли изабрани добављач, крајња тачка, регион, подешавање налога и комбинација функција могу да испоштују то обећање пре него што захтев напусти ваше границе.

Режим грешке је лако пропустити. Тим почиње са завршетком ћаскања без држављанства. Рута је прихватљива. Касније, неко додаје отпремање датотека, сачувану историју разговора, веб уземљење, групну обраду или векторско складиште. Назив модела може остати исти, али се понашање података мења. Једноставан рутер са кашњењем или трошковима може нечујно да шаље регулисане упите или упите везане за купац на путању која чува садржај дуже него што то радно оптерећење дозвољава.

Практично решење је да ставите контроле задржавања ЛЛМ података испред рутирања модела. Рутер треба да класификује захтев, да га упореди са канонском политиком задржавања, могућностима добављача филтера, блокира недозвољене функције и емитује доказе за доношење одлуке.

Чињенице које треба третирати као ограничења дизајна

Руковање подацима добављача није једнообразно и ретко се обухвата само именом провајдера. Следеће чињенице су важне када се дизајнира рутер који је свестан задржавања:

• OpenAI наводи да се подаци API не користе за обуку или побољшање модела осим ако се клијент не одлучи. Клијенти који испуњавају услове могу да конфигуришу модификовано праћење злоупотребе или нулто задржавање података на нивоу организације или пројекта након одобрења.
Нулто задржавање података
• OpenAI мења понашање крајње тачке, укључујући третирање параметра store за одговоре и довршавање ћаскања као нетачно, али неке крајње тачке и могућности и даље могу да чувају стање апликације и не испуњавају услове за нулто задржавање података.
• Anthropic документује нулто задржавање података за Claude API као не чување корисничких упита или одговора у мировању након што се одговор API врати, али покривеност зависи од крајње тачке и квалификованости функције.
• Anthropic наводи да неке функције Claude или покривени модели могу захтевати задржавање и да могу бити недоступни под нултим задржавањем података осим ако нису посебно овлашћени.
• Google Цлоуд документује да се Gemini подаци Ентерприсе Агент Платформе не користе за обуку или фино подешавање АИ/МЛ модела без претходне дозволе или инструкција, али нулто задржавање података захтева посебне радње и можда неће бити могуће за неке напредне функције.
• Google Цлоуд документује да Гроундинг витх Google Сеарцх чува изведене упите и евиденције контекста до три дана и не може да онемогући то складиште за ту функцију. Препоручује се Веб Гроундинг фор Ентерприсе када је потребно нулто задржавање података.
• Мицрософт документи које Азуре хостује моделе које продаје Азуре не чине упите и довршавања доступним OpenAI или другим добављачима модела и не користе их за обуку основних модела без дозволе или инструкција.
• Мицрософт документи чији тип примене Азуре утиче на локацију обраде. Глобалне примене могу да обрађују упите и одговоре на било којој географској локацији где је модел распоређен, док ДатаЗоне примене ограничавају обраду на изабрану зону. Сачувани подаци остају на географској локацији коју одреди корисник.
• Мицрософт документи у којима неке Азуре функције које садрже стање чувају податке, укључујући датотеке, складишта вектора, историју порука одговора, нити помоћника, улазе за групну обраду и сачуване довршетке.
• Мицрософт документи који су одобрили клијенте могу да мењају надгледање злоупотребе и да Азуре портал или CLI може да прикаже ContentLogging=false када је складиштење података за праћење злоупотребе искључено.

Ово нису детаљи о ивици. Они значе да рутер мора заједно да процени крајњу тачку, функцију, одобрење налога и регион. Ознака на нивоу добављача као што је „ЗДР омогућен“ је превише груба за смернице производње.

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

Гејтвеј више модела АИ 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: назив изворног документа, УРЛ, датум преузимања и датум прегледа власника.

Пример:

{
  "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 кључни опсег: закупац, тим, окружење, апликација и тип радног оптерећења.
• Ознаке уговора: без задржавања, само за ЕУ, контроле сличне ХИПАА, финансијски подаци, поверљиво за клијенте или само за интерно.
• Тип корисног оптерећења: слободан текст, документ, слика, референца датотеке, унос за уграђивање, резултат алата или преузети контекст.
• Коришћење функција: веб уземљење, отпремање датотека, складиште вектора, групни задатак, сачувана историја разговора, позиви алаткама или складиштење одговора.
• Режим евидентирања: пун садржај је дозвољен, редиговани садржај дозвољен, само метаподаци или без садржаја евиденције апликације.
• Регионални савети: локација корисника, пребивалиште података закупца, регион пројекта или регион примене.

Не ослањајте се само на аутоматско откривање осетљивих података. Користите декларисану политику радног оптерећења из кључа 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"
    ]
  }
}

Одвојено евидентирање закључака од оперативне телеметрије

Политика задржавања не би требало да приморава мрежни пролаз да постане слеп. Обично можете да одржавате оперативну телеметрију без чувања садржаја за брзе или довршене поруке.

За строга оптерећења сачувајте:

• ИД захтева и ИД праћења;
• идентификатори закупца, пројекта, кључа API и радног оптерећења;
• ИД смерница и верзија смерница;
• провајдер, крајња тачка, модел, примена и регион који се користи;
• заставице функција тражене и дозвољене;
• шифре разлога за доношење одлуке;
• број токена, кашњење, статусни код и метаподаци о трошковима;
• хешеви или стабилни отисци прстију за уклањање дупликата, ако је одобрено смерницама.

Потисните или редигујте:

• необрађене упите;
• необрађени довршетак;
• отпремљен садржај датотеке;
• излази алата који садрже податке о клијентима;
• преузет контекст из осетљивих система;
• провајдер отклања грешке које дуплицирају садржај.

Овде се рутирање задржавања повезује са провајдер-неутралним ЛЛМ посматрањем. Уочљивост би требало да докаже шта се догодило без проширења скупа система који задржавају осетљив садржај.

Емитовање ревизијских доказа за сваку одлуку

Ревизијски запис треба да објасни зашто је рута дозвољена или одбијена. Није потребан пун садржај да би био користан.

{
  "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.

Користите тестове уговора за правила задржавања

Рутирање задржавања треба да има аутоматизоване тестове. Важни тестови нису само јединични тестови за појединачне провајдере; они су тестови уговора за понашање смерница међу комбинацијама добављача.

Тест случајеви високе вредности укључују:

• Смернице забране задржавања плус отпремање фајлова би требало да се одбију осим ако не постоји одређена одобрена рута за датотеке.
• Смернице само за ЕУ плус глобална примена треба да одбију чак и када је модел иначе доступан.
• Смернице нултог задржавања плус сачувана историја конверзација би требало да одбију или принудно искључи складиштење када је подржано.
• Функција уземљења са задржавањем изведеног дневника би требало да се одбије у складу са смерницама без задржавања.
• Смернице евидентирања само метаподатака треба да потискују садржај брзих и довршених података из трагова, евиденција и извештаја о грешкама.
• Запис о могућностима добављача са непознатим задржавањем треба да одбије за регулисана оптерећења.
• Резервни режим након прекида рада добављача треба да остане унутар квалификованог скупа рута.
• Групна обрада би требало да одбије када крајња тачка групе складишти улазне датотеке дуже него што смернице дозвољавају.

Такође тестирајте дрифт. Када се запис о могућностима промени, систем би требало да покаже на које смернице и руте утиче пре него што промена стигне до производње.

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

Најтежи део није писање првог евалуатора. Он одржава регистар актуелним и спречава недокументоване изузетке.

Доделите власнике за:

• каденце прегледа документације добављача;
• статус одобрења за контроле на нивоу налога као што је модификовано праћење злоупотребе или нулто задржавање података;
• регионални инвентар примене;
• испуњавање услова за датотеке, складишта вектора, уземљење, групе и ускладиштене одговоре;
• ток рада изузетака од политике;
• задржавање записа ревизије и контрола приступа;
• поруке о грешкама које се односе на програмера и одобрене алтернативе.

Сваки запис о способности треба да има датум прегледа. Ако истекне, строге смернице би требало да престану да му верују или да захтевају ручно одобрење. Документи добављача и понашање функција се пречесто мењају да би ово била статичка конфигурација.

Размишљања

Рутер за строго задржавање смањује доступне изборе модела. Неки модели прегледа, АПИ-ји са стањем, алати за уземљење и токови рада датотека биће недоступни за осетљива радна оптерећења. То је поента контроле, али тимовима производа су потребне јасне алтернативе.

Регионално рутирање може повећати кашњење или трошкове када је најбржа примена глобална, али радно оптерећење захтева одређену географску локацију или зону података. Учините ово видљивим у телеметрији како би тимови разумели зашто је захтев користио скупљу или спорију руту.

Блокирање функција са подацима о стању може да подстакне тимове да изграде сопствени меморијски слој. То је можда права архитектура, али јој је и даље потребна политика складиштења, радни ток брисања, шифровање, контрола приступа и евиденције ревизије. Премештање стања изван добављача не уклања рад управљања.

Брзо редиговање и довршавање штити осетљиве податке, али слаби отклањање грешака и преглед квалитета. Користите репродуцибилне метаподатке захтева, детерминистичке тестове, контролисано узорковање за дозвољена радна оптерећења и документовани приступ ломљеном стаклу тамо где смернице то дозвољавају.

Препоруке

• Примените задржавање и боравак пре усмеравања модела, а не као проверу накнадне обраде.
• Моделне могућности на нивоу добављача, крајње тачке, функције, региона и одобрења налога.
• Користите понашање одбијања по подразумеваној вредности за регулисана или уговором везана радна оптерећења.
• Третирајте отпремање датотека, векторске продавнице, веб уземљење, групну обраду и сачувану историју разговора као засебне димензије смерница.
• Задржи оперативну телеметрију чак и када садржај брзих и довршених мора бити потиснут.
• Емитујте записе ревизије који укључују смернице, руту, доказе о могућностима, регион, ознаке за складиштење и шифре разлога.
• Пишите тестове уговора за комбинације функција високог ризика и резервно понашање.

Предвиђање: Ретенционо рутирање ће постати стандардни слој мрежног пролаза

Вероватни правац је да усмеравање задржавања постане стандардни слој у корпоративним ЛЛМ платформама, слично ограничењима стопе, контролама буџета и видљивости. Како добављачи додају више алата за праћење стања, опција уземљења, кеша, датотека, агената и функција управљане меморије, безбедна рута ће мање зависити од назива модела, а више од пуне путање извршења.

То је предвиђање, а не тренутни универзални захтев. Тренутни захтев је једноставнији: ако ваш тим не обећава задржавање, регионалну обраду, никакву употребу обуке или људски преглед, вашем мрежном пролазу је потребно довољно логике политике и доказа да докаже да је сваки захтев пратио та ограничења.

Закључак који се може применити

Изградите рутер за задржавање као капију политике испред избора добављача. Дефинишите канонску политику задржавања, класификујте сваки захтев пре рутирања, одржавајте регистар могућности добављача са датумом, подразумевано одбијте небезбедне комбинације и евидентирајте доказе ревизије без задржавања осетљивог садржаја.

Циљ дизајна није пронаћи добављача који је увек сигуран. Циљ је да се докаже да је одређени захтев, користећи одређену крајњу тачку и скуп функција, под одређеним налогом и регионом, задовољио смернице пре него што је послат.

Сродно читање

• провајдер-неутрални дизајн ЛЛМ посматрања