ओपन-वेट एआई स्रोत: माइक्रोसॉफ्ट, एनवीडिया विश्लेषण

आधुनिक AI इंफ्रास्ट्रक्चर की सबसे अजीब बात यह है कि कोई मॉडल एक सामान्य फ़ाइल की तरह आ सकता है और फिर किसी छोटे-से विदेश नीति मुद्दे जैसा व्यवहार कर सकता है। आप weights डाउनलोड करते हैं, evals चलाते हैं, शायद उन्हें बदलते भी हैं, और अचानक सवाल केवल यह नहीं रहता कि मॉडल सही जवाब देता है या नहीं। सवाल यह भी हो जाता है कि production में चल रही चीज़ वास्तव में वही है या नहीं जिसे आपने डाउनलोड किया था। Microsoft और NVIDIA इस सवाल को “बस अंदाज़े” वाले विभाग से निकालकर operations में ला रहे हैं, जहाँ इसकी असली जगह है—incident runbooks और उस coffee machine के पास, जिसने बहुत कुछ देखा है।

Microsoft और NVIDIA provenance को बोरिंग बना रहे हैं, और यह अच्छी बात है

Help Net Security के अनुसार, Microsoft और NVIDIA ने एक संयुक्त पेपर में चेतावनी दी कि अपने infrastructure पर open-weight AI चलाने वाले संगठनों को वे safety और security controls खुद देने पड़ सकते हैं जिन्हें कोई hosted AI provider आम तौर पर संभालता। Open weights के साथ यही सौदा है: ज़्यादा control, ज़्यादा inspectability, ज़्यादा local autonomy, और ज़्यादा responsibility जब artifact नकली मूँछ लगाकर production में पहुँच जाए। Help Net Security open-weight models को ऐसे systems के रूप में बताता है जिनके learned weights प्रकाशित किए जाते हैं ताकि दूसरे लोग उन्हें "download, inspect, modify and run them" कर सकें। दूसरे शब्दों में, model file अब केवल उम्मीदों वाला कोई blob नहीं है; यह आपकी software supply chain का हिस्सा है।

Help Net Security रिपोर्ट करता है कि पेपर teams को "establish provenance before behavior" की सलाह देता है, यानी cryptographic signing का उपयोग करके यह पुष्टि करना कि प्राप्त file वही है जो original publisher ने release की थी। उसी report में कहा गया है कि जिन models के पास signature नहीं है, उनकी integrity को open risk के रूप में दर्ज किया जाना चाहिए। यह चमकदार काम नहीं है, लेकिन dependency pinning भी नहीं है, और फिर भी किसी तरह सभ्यता इस बात पर निर्भर करती है कि package managers trench coat पहने raccoons न बनें।

@title Behavior से पहले provenance
@source Help Net Security

  Publisher
     │
     ▼
  Open weight model
     │
     ├→ Download inspect modify run
     │
     ▼
  Cryptographic signing
     │
     ├→ File matches original
     └→ No signature open risk

@caption Provenance checks teams द्वारा उसके behavior को judge करने से पहले model artifact को verify करते हैं।

Signatures vibes से बेहतर क्यों हैं

InfoQ बड़े supply-chain सवाल को परिचित engineering terms में रखता है: system में आने वाले हर artifact के लिए teams को पता होना चाहिए कि वह कहाँ से आया, claimed source भरोसेमंद है या नहीं, और provenance verify किया जा सकता है या नहीं। Presentation इस सोच को AI models as code पर स्पष्ट रूप से लागू करती है और cryptographic signing को एक practical mechanism के रूप में बताती है। यह कोई अजीब AI अनुष्ठान नहीं है। यह वही adult supervision है जिसे software teams पहले से code, infrastructure definitions, और policy files पर लागू करती हैं, अब बस इसे उन model weights तक बढ़ाया जा रहा है जो business workflows के अंदर बढ़ती मात्रा में बैठे हैं।

यह फर्क मायने रखता है क्योंकि behavior tests pass हो सकते हैं जबकि provenance अज्ञात ही रहता है। कोई model staging में summarize, classify, या acceptable outputs generate कर सकता है, और फिर भी teams यह साबित करने में असमर्थ रह सकती हैं कि उन्होंने कौन-सा artifact deploy किया। यह chef की identity verify करने के लिए soup चखने जैसा है। शायद उपयोगी हो, लेकिन chain of custody तो बिल्कुल नहीं।

Risk register के दाँत निकल आए हैं

Help Net Security रिपोर्ट करता है कि Microsoft और NVIDIA guidance open-weight AI risks को पाँच categories में समूहित करती है: cybersecurity, data protection, content, human and AI interaction, और bias। उसी report में कहा गया है कि ये categories 30 और specific risk types में टूटती हैं। Practical lesson यह नहीं है कि हर open-weight deployment कोई भूतहा vending machine है। बात यह है कि model operations को अब origin, integrity, evaluation, और residual risk की acceptance के लिए स्पष्ट records चाहिए।

यहीं पर open-weight adoption operationally दिलचस्प हो जाता है। अगर आपकी team कोई model डाउनलोड करती है, उसे modify करती है, और internally deploy करती है, तो आपने flexibility पा ली है, लेकिन आपने वे checks भी inherit कर लिए हैं जिन्हें कोई closed provider शायद API boundary के पीछे छिपा देता। यह open weights से बचने की वजह नहीं है। यह उन्हें अंदर tensors वाले जादुई PDFs के बजाय powerful dependencies की तरह treat करने की वजह है।

Builders को आगे क्या करना चाहिए

Help Net Security की reporting पहला कदम राहतभरी स्पष्टता से बताती है: behavior evaluate करने से पहले provenance verify करें। Practice में, इसका मतलब है signed model artifacts को preference देना, deployment के हिस्से के रूप में signatures check करना, और unsigned models को known risks के रूप में record करना—न कि evidence की अनुपस्थिति को एक गर्म security blanket मानकर दिखावा करना। InfoQ का supply-chain framing अगली layer की ओर इशारा करता है: model origin, artifact verification, और trust decisions को उसी workflow का हिस्सा बनाइए जिसे teams पहले से code और infrastructure के लिए use करती हैं।

AI builders के लिए takeaway ताज़गी देने वाला और unsexy है। Responsible path कोई बड़ा benchmark slide या ज़्यादा loud model card नहीं है। यह जानना है कि आपने क्या pull किया, उसे किसने publish किया, वह बदला या नहीं, और customers, analysts, या उस एक executive को जवाब देने देने से पहले आपने कौन-सा risk स्वीकार किया जो पूरी spreadsheets chat boxes में paste कर देता है। Open weights teams को ज़्यादा agency देते हैं; provenance checks यह सुनिश्चित करते हैं कि वह agency improv compliance में न बदल जाए। Model open हो सकता है, लेकिन आपका production environment GPUs वाला lost and found bin नहीं होना चाहिए।