Lesson 125 — Advanced

Regions, Residency & Compliance

Model sirf "available" nahi hota — kisi na kisi region mein available hota hai, aur tumhari compliance team kehti hai data usi region mein rahe jahan allow hai. Is lesson mein hum dekhenge ye dono constraints kaise aapas mein bhidte hain, aur bhidant ko kaise resolve karte hain.

⏱ 10 min• Advanced• Identity, Networking & Tenancy

Models region-wise exist karte hain

Kya hai?

Har managed model kuch hi regions mein deployed hota hai. Catalog mein har entry ke saath available regions listed hain — tumhara allowed region us list se intersect hona chahiye, tabhi design possible hai.

Kab kaam aata hai?

Project shuru karte waqt — region choose karte hi tumhara model menu chhota ho jaata hai. Aur jab naya model aaye jo tumhare region mein nahi ho — tab bhi.

Kahan milta hai?

Model catalog pages par, platform availability docs mein, aur deployment errors mein (model not available in this region wala message).

Mechanism simple hai: model ka inference capacity physical racks par hoti hai, aur provider har region mein har model nahi rakhta — demand, regulation aur capacity ke hisaab se. Isliye region pehle choose karo, model baad mein — ulta karo toh rework pakka.

Workflow: Allowed regions likho (residency rules se) → un regions mein kya models available hain catalog mein check karo → intersection mein se model choose karo. Ye order ulta kiya toh best model chun kar region constraint pe atak jaoge.

Data residency aur localization

Residency ka matlab: data ek specific geographic boundary ke andar hi rahe — store bhi, process bhi. Sirf store nahi, inference ka path bhi matter karta hai.
Sector rules upar hain: banking, telecom, health jaise sectors ke apne regulators apne data-handling rules rakhte hain — general law se upar wali compliance hoti hai. Tumhara data kaunsa hai, pehle ye classify karo.
Processing ≠ storage: "data store region mein hai" sufficient nahi — inference cross-region ho raha hai toh residency phir bhi violate ho sakti hai.
Cross-region inference: kuch platforms explicitly options dete hain ki data processing kis region se ho. Ye option legally meaningful hai — default pe mat chhodo.

Honest framing: Compliance team ko "platform ne bola hai safe hai" nahi chahiye — unhe specific chain chahiye: data kahan store, kahan process, kaun tak access, kitne din tak. Har sawaal ka written answer rakho, assumption nahi.

Retention aur training terms — likhit mein

# Har platform ke liye ye checklist bharo (docs/terms se, guess se nahi)
platform: X
retention:
  request_logs: "kitne din tak? (numbers mein likho)"
  prompt_payloads: "logged bhi hote hain ya nahi?"
training:
  data_used_for_training: "yes | no | opt-in option hai"
  opt_out_kaise: "kaunsa setting, kaun enable karta hai"
access:
  who_can_see_logs: "platform staff ka access hai ya nahi"
deletion:
  delete_request_ka_flow: "kaise, kitne din mein"

Retention: platform kitne din request logs rakhta hai — ye number platform ke docs/terms mein likha hota hai, guess nahi. Payload logging option alag se ON/OFF hota hai.
Training terms: tumhara data provider ke model ko train karne mein jaata hai ya nahi — ye term sheet mein likha hota hai, aur aksar opt-out option hota hai. Opt-out ON karo, default par trust mat karo.
Staff access: "kya platform ki team bhi logs dekh sakti hai" — ye compliance ka poochha jaata hai. Written answer rakho.
Deletion flow: user deletion request aaye toh platform logs bhi delete honge — flow kya hai, timeline kya hai.

Snapshot rakho: Terms badalte hain. Har quarter ek snapshot lo (date ke saath) ki us waqt retention aur training terms kya thin. Incident ya audit ke waqt ye snapshot tumhara proof hai.

Governance ke saath connection

Ye sab naya nahi hai — governance phase mein humne naam diya tha: residency, deletion aur third-party processing requirements. Ab wahi requirements managed platform par enforce ho rahi hain: region filter, training opt-out, deletion flow, CMK.

Governance ne requirement likhi thi ("data India mein rahe") — ab wo region setting ban gayi.
Governance ne third-party processing naam tha — ab wo terms checklists ban gayi (training, staff access).
Governance ne deletion bola tha — ab wo platform ka delete-request flow ban gaya.
Ye loop complete tab hota hai jab requirements doc aur platform settings ek doosre se match karein — mismatch hi risk hai.

Model tumhare region mein nahi hai — ab kya

sawaal: required model, required region — dono available nahi

option 1: cross-region inference
  -> residency rule check karo — allow hai toh documented exception banao
option 2: doosra model jo tumhare region mein hai
  -> apne task pe eval chala kar quality prove karo
option 3: documented exception ya workaround
  -> compliance sign-off ke saath, risk register mein likha hua

option jo NAHI hai: andhere mein cross-region data bhej dena

Documentation hi asli deliverable: Is lesson ka sabse important output code nahi, ek one-page decision record hai — kya data ja raha hai, kahan process ho raha hai, kitne din tak, kaun dekh sakta hai. Ye page har AI project ke saath hona chahiye.

Exercise

Question: Platform catalog mein har model entry ke saath kya listed hota hai jo design space decide karta hai?

Question: Data kab tak platform ke logs mein rehta hai — ye number kahan se milta hai, guess se nahi?

Question: Tumhara data provider ke model ko train karne mein jaaye isko rokne ka option kya kehlata hai?

Question: Model required region mein nahi hai — teen options mein se ek: cross-region, doosra model, ya documented exception?

Common mistakes

Model chun kar region filter lagana: Best model chun liya, phir pata chala allowed region mein nahi available — poori design rework. Fix: allowed regions pehle likho, catalog usse filter karo.
Retention/training defaults par bharosa: Platform ka default policy kabhi bhi badal sakta hai, aur aksar opt-in hi hota hai. Fix: terms padh kar explicitly opt-out karo, snapshot rakho.
Compliance ko one-time check samajhna: Model catalog, regions aur terms badalte rehte hain — ek baar ki review stale ho jaati hai. Fix: quarterly review, catalog changes ke saath.
Processing aur storage ka farq bhool jaana: Data store region mein hai, par inference cross-region ho raha hai — residency phir bhi violate. Fix: processing path bhi document mein likho.

Desi example: Har cheez har sheher mein nahi milti

Chhote sheher mein har brand ka showroom nahi hota — jo milta hai wahi chunna padta hai, ya bada sheher jaana padta hai. Model bhi wahi: har region mein har model nahi hota, aur residency rules kehta hain sheher mat chhodo:

allowed regions: [A, B]
required model:  [X, Y]

X available in [B, C]  -> intersection: B  -> yahin deploy karo
Y available in [C, D]  -> intersection: none -> alag model ya exception

Interview angle — yahan se sawaal aate hain

Q: Model availability aur region ka kya rishta? — Har model specific regions mein deployed hota hai; allowed region aur catalog region ka intersection design space hai.
Q: Data residency ka technical enforcement kaise hoti hai? — Region pinning, cross-region processing options, aur private connectivity ke saath documented flow.
Q: Retention terms kahan se aati hain? — Platform docs/terms se; guess nahi. Snapshot rakho, opt-out explicitly enable karo.
Q: Required region mein model na ho toh? — Cross-region (documented), doosra model (eval se prove), ya signed exception — andhera option kabhi nahi.

Lesson complete?

Residency aur compliance ka frame clear. Agla lesson — Capacity, Quotas & Cost — mein dekhenge platform ki limits kaise kaam karti hain aur spend kaise forecast aur control karte hain.