विनियमित क्षेत्रों में Custom LMs का सत्यापन और रिलीज़

Notes from the Release Cycle — भाग IV

एक general counsel engineering review में आती हैं। उनका एक सवाल है: “अगर कल EU AI Act Article 17 का right-to-erasure request आता है जिसमें कहा गया हो कि हमारा model किसी विशिष्ट patient के बारे में जो भी तथ्य सीखा है, उसे हटाएँ — तो क्या हम सिद्ध कर सकते हैं कि हमने ऐसा किया?”

अधिकांश teams जो ईमानदार उत्तर देती हैं वह है: “हम model को भूलने के लिए fine-tune कर सकते हैं। हम आपको training run दिखा सकते हैं। पर हम सिद्ध नहीं कर सकते कि जानकारी संरचनात्मक रूप से चली गई है, क्योंकि वह सही adversarial prompt के तहत फिर से उभर सकती है।”

यह compliance का उत्तर नहीं है। यह एक procedural shrug के साथ दिया गया गैर-उत्तर है।

यह post इस बारे में है कि custom LLMs के लिए असली compliance उत्तर कैसा दिखता है — चार regulatory frameworks में (EU AI Act, GDPR Article 17, HIPAA, NIST AI RMF), जो उस चार-stage वाले pipeline (Register → Gate → Roll → Observe) पर mapped हैं जिसे हम customer releases के लिए ship करते हैं। हर regulator की माँग में एक केंद्रीय तनाव चलता है — open-weights बनाम closed-API: Gemma 4 के एक fine-tune के बारे में आप जो साबित कर सकते हैं वह वह नहीं है जो आप एक opaque vendor API के पीछे serve होने वाली release के बारे में साबित कर सकते हैं। हमारे द्वारा उपयोग किया जाने वाला receipt format यह स्पष्ट रूप से, पंक्ति-दर-पंक्ति कहता है। यही ईमानदारी receipt को auditor के लिए उपयोगी बनाती है।

चार regulators और हर एक वास्तव में क्या चाहता है

Compliance चर्चाएँ अक्सर “हमने सब कुछ document किया” तक सिमट जाती हैं। यह framing एक auditor के सामने टिकता नहीं। Auditors जो चाहते हैं वह है ऐसा evidence जिसे वे आपकी infrastructure पर भरोसा किए बिना verify कर सकें। नीचे के चारों frameworks एक ही अंतर्निहित माँग के लिए अलग-अलग शब्दावलियाँ इस्तेमाल करते हैं।

दंड के आँकड़े वह नहीं हैं जो इन frameworks को रोचक बनाते हैं। दंड के आँकड़े वह हैं जो इन्हें load-bearing बनाते हैं। रोचक हिस्सा है verification primitive — हर framework वास्तव में चाहता है कि artifact कैसा दिखे। चारों में से तीन अलग-अलग शब्दावलियों में cryptographic-grade proof माँगते हैं। चौथा (NIST AI RMF) स्वैच्छिक है पर enterprise procurement में de facto आवश्यक है। वे एक ही आकार पर अभिसरित होते हैं: एक ऐसा artifact जिसे auditor आपकी logs पर भरोसा किए बिना verify कर सके।

विभाजन: open-weights बनाम closed-API

Per-stage mapping से पहले, इस पूरी post की सबसे महत्वपूर्ण चेतावनी:

open-weights model backings के लिए — Gemma, Qwen, Llama, Mistral, GPT-OSS, और कोई भी जहाँ weights addressable और editable हैं — हर Divinci release decision एक vindex receipt emit करता है जिसमें weight-attestation शामिल होता है: cryptographic proof कि decision time पर active weights ठीक वही weights हैं जो manifest ने register किए थे। यही वह चीज़ है जो GDPR Article 17 के verifiable erasure को संभव बनाती है। आप एक DELETE patch apply करते हैं जो weight space से एक विशिष्ट entity-relation को हटाता है, receipt before-and-after hash embed कर लेती है, और एक auditor public vindex के विरुद्ध verification को फिर से चलाकर deletion का होना verify कर सकता है।

closed-API model backings के लिए — OpenAI, Anthropic, Google opaque APIs के माध्यम से — वही receipt decision chain को cover करता है (कौन-सा manifest, कौन-सा gate result, कौन-सी monitor reading, किस user ने कौन-सी action trigger की) पर weight provenance का दावा नहीं कर सकता, क्योंकि provider weights expose नहीं करता। Receipt इसे स्पष्ट रूप से weight_attestation: null field में एक note के साथ नोट करता है जो बताता है कि क्यों। यह degraded compliance posture नहीं है — यह है verifiable क्या है उसकी सीमा, ईमानदारी से लिखी गई। एक auditor जो receipt पढ़ता है उसे ठीक-ठीक पता चलता है कि कौन-सी class का proof बन रहा है और कौन-सी नहीं।

यह विभाजन नीचे हर regulator की माँग में चलता है। जब भी कोई framework weight स्तर पर कुछ माँगता है, open-weights path उसे संतुष्ट कर सकता है और closed-API path नहीं कर सकता। हम receipt में ऐसा कहते हैं बजाय इसके कि किसी proof का संकेत दें जिसे हम deliver नहीं कर सकते।

हर framework कैसे चार pipeline stages पर map होता है

Pipeline के चार stages हैं। हर regulator की माँग एक या अधिक stages पर map होती है। नीचे का matrix वास्तविक map है।

दोनों ◐ cells GDPR Article 17 / open-weights-only entries हैं — ये वे माँगें हैं जिन्हें closed-API path पूरी तरह संतुष्ट नहीं कर सकता। बाक़ी सब दोनों backings पर लागू होता है।

बाक़ी की post हर stage के योगदान का विवरण देती है।

Stage ① — Register

Register stage एक immutable JSON manifest उत्पन्न करता है, जो SHA-256 द्वारा addressed है। विनियमित releases के लिए manifest वह सब कुछ ले जाता है जो Annex IV^[1] एक ही artifact में माँगता है:

• Model artifact (HF repo + commit SHA, या एक vindex patch reference)
• Prompt template (हर variable, हर system message — version-controlled)
• Routing rules (कौन-सी traffic class कौन-सी release पर जाती है)
• Gate thresholds compute करने के लिए उपयोग किया गया dataset version (training-data सारांश hash के द्वारा)
• पिछली release का SHA (ताकि audit chain अटूट रहे)
• Disclosure scope — HIPAA deployments के लिए, model को कौन-सी PHI categories प्राप्त करने की अनुमति है

Manifest ही documentation है। एक auditor prose नहीं पढ़ता; वह manifest hash पढ़ता है और bundle को verify करता है। छह-महीने-बाद-लिखा गया कोई prose सारांश आवश्यक नहीं।

Open-weights bonus. जब model artifact किसी open-weights model का reference देता है, तो manifest vindex_sha256 भी embed करता है — model की प्रकाशित vindex का cryptographic fingerprint। वह fingerprint ही वह चीज़ है जो एक तीसरे पक्ष को हमारी deployment infrastructure पर कभी भरोसा किए बिना active weights verify करने देती है।

Closed-API caveat. जब model artifact किसी closed-API model का reference देता है, तो manifest का vindex_sha256 field null होता है, और manifest का weight_attestation_class होता है decision_chain_only। इसे पढ़ने वाला auditor ठीक-ठीक जानता है कि क्या दावा किया जा रहा है और क्या नहीं।

Stage ② — Gate

Gate stage वह जगह है जहाँ EU AI Act के “human oversight measures”^[1] operationalize होते हैं। जो regulator EU AI Act पढ़कर निष्कर्ष निकाले कि “हमें human approval workflow चाहिए” वह बात नहीं समझा — असली कठिन माँग है human किसके विरुद्ध approve कर रहा है। Gate stage उस सवाल का उत्तर देता है एक human-anchored grader^[3] के विरुद्ध per-slice Spearman ρ के साथ। आपकी regulatory posture में मायने रखने वाली हर slice (pediatric oncology, IP licensing, Belgian French) को अपना threshold मिलता है। Override path के लिए लिखित rationale आवश्यक होता है जो audit trail में जाता है।

HIPAA-covered deployments के लिए, यहीं “न्यूनतम-आवश्यक” disclosure rule भी रहता है। Gate के scored-QA suite में PHI over-exposure के लिए negative tests शामिल हैं — ऐसे उत्तर जिनमें personal identifiers आते हैं जब पूछा नहीं गया था। एक release जो over-exposure slice पर regress करती है gate fail करती है, बाक़ी slices चाहे कैसा भी प्रदर्शन करें।

NIST AI RMF के लिए, Gate stage “measure” function को cover करता है — per-slice संख्यात्मक evidence कि system configured tolerances के भीतर प्रदर्शन कर रहा है।

Stage ③ — Roll

EU AI Act post-market monitoring^[1] operator से माँगता है कि वास्तविक स्थितियों में AI system कैसा प्रदर्शन करता है इसका निरंतर — सिर्फ pre-launch नहीं — observation दिखाए। एक 5% → 25% → 100% canary जिसमें quality-monitor checkpoints हों, इसे संतुष्ट करने का सबसे स्वाभाविक तरीक़ा है। हर checkpoint पर dwell, और dwell के दौरान monitor readings — यही वह चीज़ है जो auditor देखना चाहता है।

HIPAA के लिए, canary stage वह जगह भी है जहाँ per-request audit logging end-to-end exercise होता है। हर checkpoint signed request-response receipts का एक sample उत्पन्न करता है; अगर किसी की PHI handling misconfigured है, तो वह 100% traffic पर नहीं, 5% traffic पर ही सामने आ जाती है।

Stage ④ — Observe

यह वह stage है जो compliance की कहानी कमाता है। Observe stage active release के माध्यम से निरंतर trace replay चलाता है, जो Gate के उसी human-anchored judge द्वारा scored है, साथ में एक quality monitor जो breach होने पर automatic rollback trigger करता है।

हर release decision — register, gate-pass, gate-fail, gate-override, checkpoint-promote, checkpoint-hold, auto-rollback, manual-rollback, और कोई भी GDPR Article 17 DELETE patch application — एक vindex receipt emit करता है। इस customer के लिए पिछले receipt और इस release के लिए पिछले receipt से hash-chained।

GDPR Article 17 DELETE patch के लिए असली receipt कैसा दिखता है — सीधे compliance page पर documented format से adapted:

{
  "name": "gdpr-art17-patient-12348-removal",
  "version": 1,
  "base_model": "google/gemma-4-E2B-it",
  "manifest_sha256": "9abaeaf6c91f8b...",
  "previous_manifest_sha256": "8f72b1de4a93c5...",
  "created_at": "2026-05-29T03:17:42Z",
  "user_id": "compliance-officer-7c4e1a",
  "operation": {
    "op": "delete",
    "entity": "patient-record-12348",
    "relation": "diagnosis-association",
    "target": "weight-feature-11179-layer-27",
    "weight": -1.0
  },
  "verification": {
    "before_feature_11179_score": 17.34,
    "before_feature_11179_rank": 1,
    "after_feature_11179_score": null,
    "after_feature_11179_rank": "ABSENT_FROM_TOP_25",
    "perplexity_delta_wikitext103": "+0.02%",
    "vindex_sha256_before": "abc12...",
    "vindex_sha256_after":  "def34..."
  },
  "weight_attestation_class": "full",
  "chain_signature": "sha256(manifest || prev_manifest || user_id || created_at || prev_chain_signature)"
}

वह artifact verifiable है। एक auditor को हमारी logs पर भरोसा नहीं करना पड़ता। वह vindex_sha256_after लेता है, huggingface.co/Divinci-AI से संबंधित published vindex pull करता है, और verify करता है कि layer 27 में feature 11179 top-25 से संरचनात्मक रूप से अनुपस्थित है। वह chain_signature लेता है और पिछले receipt के विरुद्ध verify करता है। पूरी chain customer द्वारा configure किए गए schedule पर externally anchored है।

वही operation एक closed-API model के विरुद्ध। ऊपर के receipt fields तीन तरह से बदलते हैं: operation.target बन जाता है provider_api_endpoint, verification एक अलग schema बन जाता है जो केवल decision-chain evidence को cover करता है, और weight_attestation_class बन जाता है decision_chain_only। Closed-API model provider ने weights expose नहीं किए हैं, तो receipt ऐसा कहता है। एक auditor जिसे weight-level proof चाहिए उसे अब पता है कि उन्हें provider के पास escalate करना है, हमारे पास नहीं।

यह वह differentiation है जो 2026 में और कोई ship नहीं करता। eval-CI camp (Braintrust, Humanloop, Patronus) traffic पर नहीं बैठता और decision receipts emit नहीं करता। serving-canary camp (SageMaker Deployment Guardrails^[2], KServe, Vertex, BentoCloud, Seldon) infra-metric logs emit करता है पर hash-chained compliance receipts नहीं। observability camp (Arize, Phoenix, Confident, Deepchecks) output देखता है पर enforce नहीं करता।

एक auditor वास्तव में क्या verify करता है?

एक उपयोगी अभ्यास: उन सवालों से गुज़रें जो एक असली auditor पूछेगा, और कौन-सा artifact हर एक का उत्तर देता है।

जो auditor को नहीं करना पड़ता: हमारे Datadog पर भरोसा। हमारे CloudWatch पर भरोसा। किसी screenshot पर भरोसा। किसी export पर भरोसा। Receipt format का पूरा मक़सद यही है कि auditor इसे स्वतंत्र रूप से verify कर सके।

यह क्या हल नहीं करता

तीन ईमानदार सीमाएँ:

GDPR Article 17 territory में closed-API regressions platform layer पर हल करने योग्य नहीं हैं। अगर आप एक healthcare assistant को closed-API model के पीछे serve कर रहे हैं और कोई patient Article 17 invoke करता है, तो platform attest कर सकता है कि patient का record आपके retrieval store, prompt template, और routing rules से हटा दिया गया — पर attest नहीं कर सकता कि अंतर्निहित model weights patient का data भूल गए। आपको या तो एक open-weights backing चाहिए या weight-level erasure के लिए vendor commitment। हम receipt में ऐसा कहते हैं।

Documentation आवश्यक है पर पर्याप्त नहीं। एक receipt जो साबित करता है कि एक model एक threshold से मिला, यह साबित नहीं करता कि वह threshold ही सही threshold था। अगर आपका scored-QA suite उस slice को cover नहीं करता जो आपकी service में किसी patient के लिए वास्तव में मायने रखती है, तो कोई भी receipt-chaining इसे ठीक नहीं करती। Regulators इसे तेज़ी से समझ रहे हैं; “हमने अपना eval pass किया” अब एक पर्याप्त compliance उत्तर नहीं रहा अगर eval ग़लत eval था।

Vindex format single-vendor है। हम इसका उपयोग करते हैं क्योंकि यह आज weight-level proof के लिए उपलब्ध सबसे ठोस cryptographic primitive है। अगर उद्योग एक अलग format पर settle हो — model-cards-with-hashes, NIST-published artifact schemas — तो receipt format को उसी की ओर evolve होना चाहिए। सार (hash-chained, externally verifiable, weight-attestation-aware) load-bearing है, विशिष्ट schema नाम नहीं। हम उम्मीद करते हैं कि जैसे-जैसे regulatory और standards landscape परिपक्व होगा, यह बदलेगा।

FAQ

AI systems के लिए GDPR Article 17 के तहत verifiable erasure क्या है?

Verifiable erasure का मतलब है कि एक तीसरा पक्ष आपकी logs पर भरोसा किए बिना verify कर सके कि data हटाया गया था। एक model को विशिष्ट जानकारी “भूलने” के लिए fine-tune करना इस standard को पूरा नहीं करता — जानकारी adversarial prompting के तहत फिर से उभर सकती है, और कोई cryptographic primitive नहीं है जिसे auditor check कर सके। एक प्रकाशित before/after vindex hash के साथ weight-level DELETE patch standard को पूरा करता है, क्योंकि auditor public artifact के विरुद्ध verification फिर से चला सकता है।

Closed-API models GDPR Article 17 को उसी तरह क्यों संतुष्ट नहीं कर सकते?

क्योंकि provider weights expose नहीं करता। Weights तक पहुँच के बिना, कोई भी तीसरा पक्ष — API का उपयोग करने वाला customer भी — weight-level erasure जारी या verify नहीं कर सकता। Receipt का decision-chain भाग (कौन-सा prompt template उपयोग हुआ, data किस retrieval store से आया, कौन-से routing rules सक्रिय थे) अभी भी verifiable है, पर weight-level दावा नहीं। यह compliance framework की सीमा नहीं है, बल्कि weights private होने पर verifiable क्या है उसकी सीमा है।

सरल भाषा में EU AI Act Annex IV क्या माँगता है?

Annex IV technical documentation माँगता है जो system की logic, training data सारांश, इच्छित उपयोग, human oversight उपाय, और post-market monitoring को cover करे। अधिकांश teams जिस जाल में फँसती हैं वह है इन्हें पाँच अलग-अलग दस्तावेज़ों के रूप में मानना। Stage 1 पर release manifest पहली तीन माँगों को एक single hash के रूप में ले जाता है; Gate stage चौथी को cover करता है; Roll + Observe stages पाँचवीं को cover करते हैं। एक pipeline; चार माँगें सामान्य operations के byproduct के रूप में संतुष्ट।

HIPAA-covered deployments के लिए rollback कितना तेज़ होना चाहिए?

HIPAA rollback time निर्दिष्ट नहीं करता, पर breach response पर HHS guidance time-to-containment को load-bearing मानती है। सेकंडों के क्रम में rollback (manifest-driven flip पर in-flight drain — हमारा आँकड़ा लगभग 12 सेकंड है) संरचनात्मक रूप से एक सामान्य infra-metric blue-green से तेज़ है जो alarm propagation पर निर्भर करता है। सार्वजनिक postmortems से तुलना करें: Cloudflare की June 2022 की घटना^[4] को revert होने में 44 मिनट लगे क्योंकि engineers एक-दूसरे के reverts पर चढ़ गए।

NIST AI RMF एक release pipeline पर कैसे map होता है?

NIST AI RMF के चार core functions — Govern, Map, Measure, Manage — पूरे release lifecycle में फैले हैं, एक ही stage पर नहीं। Govern है documented release policy साथ में gate-override rationale workflow (Register + Gate stages)। Map है per-slice scored-QA suite (Gate)। Measure है per-slice Spearman thresholds और निरंतर quality monitor (Gate + Observe)। Manage है rollback path और receipt chain (Observe)। चारों cover होते हैं जब pipeline अपना पूरा receipt set emit करता है।

References

1. EU AI Act. artificialintelligenceact.eu. Annex IV defines the technical documentation requirements for high-risk AI systems: system logic, training data summary, human oversight measures, post-market monitoring. Penalties up to 7% of global turnover for non-compliance.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. Default TerminationWaitInSeconds 600, max MaximumExecutionTimeoutInSeconds 1800. Cited as the industry-standard infra-metric canary that the Stage 4 quality monitor is contrasted against.
3. Calibrated LLM-as-judge agreement. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% overall GPT-4-vs-human agreement, with per-category variance from coding (86%) down to writing (36–44%). Anchor for the per-slice Spearman calibration that drives the Gate stage.
4. Cloudflare June 2022 outage. Cloudflare outage on June 21, 2022. 44 minutes from "we know what to revert" to revert complete because engineers walked over each other's reverts. Anchor for the "manifest-driven rollback can't have that failure mode" claim.
5. NIST AI Risk Management Framework. NIST AI RMF. Voluntary framework — Govern, Map, Measure, Manage — that has become the de facto enterprise procurement baseline for AI governance. Voluntary but enforced in practice through customer due-diligence questionnaires.
6. HIPAA Privacy Rule. HHS Office for Civil Rights. Minimum-necessary disclosure, access audit, and breach response timing requirements applicable to any AI system that touches PHI. Civil monetary penalties up to $1.9M per violation-type per year per CMP inflation adjustment, 2025.
7. GDPR Article 17 (Right to Erasure). gdpr-info.eu/art-17-gdpr. The data subject's right to obtain erasure of personal data, and the controller's obligation to demonstrate compliance under Article 5(2) accountability. Penalties up to €20M or 4% of annual global turnover.
8. Internal — vindex receipt format. The receipt JSON in this post is adapted from the format documented on the compliance page and demonstrated in the "Deleting Paris from a Language Model" post. The hash chain is SHA-256 over manifest || prev_manifest || user_id || created_at || prev_chain_signature. Externally anchorable on a customer-configured schedule.

इस श्रृंखला में अगला: Automated LLM CI/CD Pipelines With Instant Rollback. यह post दिखाई कि auditor क्या चाहता है। अगली वह operational pattern दिखाती है जो receipt को auditor की मेज़ पर हफ़्तों के बजाय सेकंडों में पहुँचाता है — चार-stage pipeline के नीचे का automation, इस फ़ोकस के साथ कि क्या बदलता है जब rollback अपने आप fire करता है।