Enterprises को cloud AI से दो चीज़ें चाहिए, और ये दोनों अलग-अलग दिशाओं में खिंच सकती हैं।
वे चाहते हैं कि AI प्रदाता प्लेटफ़ॉर्म को गंभीर दुरुपयोग से बचाए।
लेकिन वे यह भी चाहते हैं कि प्रदाता संवेदनशील business data को न retain करे और न पढ़े।
जैसे-जैसे AI systems लंबे कार्य संभालने लगते हैं, इन दोनों आवश्यकताओं में तालमेल बैठाना और कठिन होता जाता है।
कोई एक अनुरोध हानिरहित दिख सकता है।
लेकिन अनुरोधों का पूरा क्रम कुछ बिल्कुल अलग दिखा सकता है।
OpenAI की Private Safety Processing इसी समस्या को हल करने का एक प्रयास है।
इसका विचार कहने में सरल है:
स्वचालित safety systems को कई interactions के बीच के patterns जाँचने दिया जाए, और OpenAI के कर्मियों को ग्राहक के मूल content तक पहुँच न दी जाए।
इस विचार के पीछे का architecture ज़्यादा दिलचस्प है।
Zero Data Retention कठिन क्यों हो जाता है
OpenAI पहले से पात्र API ग्राहकों को Zero Data Retention, यानी ZDR, उपलब्ध कराता है।
OpenAI के अनुसार ZDR में ग्राहक के prompts और model responses processing के बाद retain नहीं किए जाते, और enterprise data का उपयोग model training में तब तक नहीं होता जब तक ग्राहक स्पष्ट रूप से अनुमति न दे।
यह उन संगठनों के लिए मूल्यवान है जो इन्हें संभालते हैं:
- वित्तीय जानकारी
- स्वास्थ्य data
- गोपनीय business दस्तावेज़
- बौद्धिक संपदा
- स्वामित्व वाला शोध
लेकिन safety systems को परंपरागत रूप से retain किए गए context से लाभ मिलता रहा है।
एक अनुरोध की कल्पना कीजिए:
“यह industrial control system कैसे काम करता है?”
यह जायज़ हो सकता है।
फिर एक और:
“कौन-सी safety protections remote commands को रोकती हैं?”
और बाद में:
“कोई व्यक्ति alarms बजाए बिना उन सुरक्षाओं को कैसे bypass कर सकता है?”
जोखिम शायद तभी साफ़ दिखे जब इन interactions को एक साथ देखा जाए।
अगर हर interaction तुरंत गायब हो जाए, तो sessions के आर-पार safety analysis कहीं ज़्यादा कठिन हो जाता है।
इससे एक टकराव पैदा होता है:
privacy कहती है कि कम retain करो
जबकि
safety को शायद ज़्यादा context चाहिए।
OpenAI का उत्तर: content को ग्राहक के नियंत्रण में रखना
ZDR के साथ Private Safety Processing में चुने हुए records customer-controlled cloud storage (ग्राहक-नियंत्रित cloud storage) में रखे जाते हैं, OpenAI के नियंत्रण वाले पढ़ने योग्य storage में नहीं।
OpenAI फ़िलहाल ग्राहक storage के लिए इन जैसी services को सपोर्ट करता है:
- AWS S3
- Azure Blob Storage
- Google Cloud Storage
ये records एन्क्रिप्टेड होते हैं।
उस सुरक्षित data तक पहुँचने के लिए ज़रूरी storage और key authorization को ग्राहक नियंत्रित करता है।
OpenAI ग्राहक के content की पढ़ने योग्य प्रति रखने के बजाय operational metadata और इस बात का संदर्भ रखता है कि सुरक्षित record कहाँ संग्रहीत है।
यह सामान्य trust model को बदल देता है।
इसके बजाय कि:
संवेदनशील content प्रदाता को भेजो → प्रदाता उसे संग्रहीत करे → प्रदाता उसकी समीक्षा करे
डिज़ाइन कुछ इस तरह का हो जाता है:
ग्राहक एन्क्रिप्टेड content अपने पास रखता है → approved सुरक्षित system उसे अस्थायी रूप से process करता है → सीमित safety परिणाम सुरक्षित environment से बाहर आता है
यह अंतर केंद्रीय है।
इस figure का accessible text विकल्प
दो flows साथ-साथ। एक उदाहरणात्मक पारंपरिक मॉडल: ग्राहक का content provider environment में जाता है, फिर safety review होता है, और प्रदाता content को retain या review कर सकता है। सुरक्षित मॉडल, जैसा OpenAI के दस्तावेज़ों में बताया गया है: customer-controlled encrypted storage से data एक attested protected runtime में जाता है, फिर स्वचालित safety analysis होता है, और केवल एक सीमित safety signal बाहर निकलता है। विस्तृत सुरक्षित परिणाम एन्क्रिप्टेड रूप में customer-controlled storage में लौटा दिया जाता है, जिसे डैश वाली वापसी रेखा से दिखाया गया है। सुरक्षित सीमा के भीतर के दो चरण डैश वाली रूपरेखा से बनाए गए हैं और उन पर लेबल लगे हैं, और हर चरण पर text लेबल है, इसलिए कोई भी अर्थ रंग पर निर्भर नहीं है।
Safety system इंसानों से ज़्यादा देख सकता है
Architecture का सबसे दिलचस्प हिस्सा Safety Review Runtime है।
OpenAI इसे hardware-attested computing environment बताता है, जिसे इस तरह डिज़ाइन किया गया है कि approved workload सुरक्षित ग्राहक content को decrypt कर सके, जबकि human operators नहीं कर सकते।
यह runtime स्वचालित safety review करता है।
केवल पहले से तय safety signals और approved operational metadata को ही plaintext में सुरक्षित environment से बाहर आने की अनुमति है।
विस्तृत परिणाम एन्क्रिप्टेड ही रहते हैं और customer-controlled storage में लौटा दिए जाते हैं।
अवधारणा के स्तर पर:
एन्क्रिप्टेड ग्राहक content
↓
Hardware-protected safety runtime
↓
स्वचालित analysis
↓
सीमित safety signal
प्रदाता को शायद यह पता चले:
गंभीर जोखिम की एक परिभाषित श्रेणी पाई गई
बिना इसके कि उसे यह मिले:
ग्राहक की पूरी बातचीत।
यह सिर्फ़ यह कह देने से कहीं ज़्यादा दिलचस्प architecture है कि data एन्क्रिप्टेड है।
इस figure का accessible text विकल्प
तीन ज़ोन। ज़ोन 1, ग्राहक: सुरक्षित storage का स्वामी है, key authorization को नियंत्रित करता है, और retention तथा configuration संभालता है। ज़ोन 2, सुरक्षित सीमा के भीतर, protected runtime: पढ़ने योग्य content को अस्थायी रूप से process करता है और approved safety workload चलाता है। ज़ोन 3, provider operations: सीमित safety signals प्राप्त करता है और सामान्य सुरक्षित processing के दौरान उसे पूरा पढ़ने योग्य ग्राहक content नहीं मिलना चाहिए। एन्क्रिप्टेड records ग्राहक से protected runtime में जाते हैं, और सीमित safety signals runtime से provider operations में जाते हैं। Protected runtime को डैश वाली रूपरेखा से बनाया गया है और उस पर सीमा के भीतर होने का लेबल है, इसलिए कोई भी अर्थ रंग पर निर्भर नहीं है।
अकेला encryption इस समस्या को हल नहीं करेगा
अगर keys OpenAI के पास होतीं और उसके कर्मचारी records को खुलकर decrypt कर सकते, तो privacy की सीमा कहीं ज़्यादा कमज़ोर होती।
Private Safety Processing कई controls के एक साथ काम करने पर निर्भर है:
- customer-controlled storage
- ग्राहक द्वारा प्रबंधित key authorization
- hardware attestation
- सीमित workloads
- पहले से तय output schemas
- मानव पहुँच पर प्रतिबंध
मुद्दा सिर्फ़ यह नहीं है:
कि data एन्क्रिप्टेड है।
मुद्दा यह है:
कि system यह सीमित करने का प्रयास करता है कि उसे कौन और क्या decrypt कर सकता है, कौन-सी processing हो सकती है, और उसके बाद कौन-सी जानकारी बाहर जा सकती है।
यह पारंपरिक एन्क्रिप्टेड storage से ज़्यादा confidential computing architecture के क़रीब है।
Safety outputs जानबूझकर सीमित रखे गए हैं
एक और महत्वपूर्ण बारीकी output की सीमा है।
सुरक्षित runtime से अपेक्षित नहीं है कि वह पूरा analysis या मूल बातचीत OpenAI को वापस भेजे।
यह पहले से तय, सीमित signals भेज सकता है, जो बताते हैं कि किस प्रकार की safety चिंता पाई गई।
यह इसलिए मायने रखता है क्योंकि input processing सुरक्षित होने पर भी output के चरण में privacy खो सकती है।
ऐसे safety system की कल्पना कीजिए जो तकनीकी रूप से मूल दस्तावेज़ छिपा दे, लेकिन ऐसा विस्तृत सारांश बनाए जिसमें उसकी सारी संवेदनशील जानकारी हो।
तब encryption से बहुत कम हासिल होगा।
इसलिए output को सीमित रखना privacy architecture का हिस्सा है।
यह OpenAI से आगे भी एक उपयोगी सिद्धांत है:
किसी private computation system को न सिर्फ़ यह नियंत्रित करना चाहिए कि inputs कौन पढ़ सकता है, बल्कि यह भी कि उसके outputs कौन-सी जानकारी बता सकते हैं।
Zero retention का शाब्दिक अर्थ यह नहीं कि कहीं भी कुछ संग्रहीत नहीं है
शब्दावली में सावधानी चाहिए।
Private Safety Processing में चुने हुए सुरक्षित records safety के उद्देश्य से customer-controlled storage में रह सकते हैं।
OpenAI के मौजूदा दस्तावेज़ों के अनुसार ग्राहकों को उन एन्क्रिप्टेड records को कम से कम 30 दिन तक retain करना होता है।
इसलिए “Zero Data Retention” का अर्थ यह नहीं है:
कि inference के बाद data की कोई भी प्रति कहीं भी मौजूद नहीं है।
इसका अर्थ है कि प्रदाता ग्राहक के content को उन सामान्य provider-controlled (प्रदाता-नियंत्रित) abuse-monitoring logs में retain नहीं करता जो ZDR की प्रतिबद्धता के दायरे में आते हैं।
PSP में सुरक्षित records ज़रूरी safety अवधि तक ग्राहक के storage और key controls के अधीन रहते हैं।
यह अंतर security और compliance टीमों के लिए मायने रखना चाहिए।
ग्राहक पर ज़िम्मेदारी भी आती है
यह architecture ग्राहकों को ज़्यादा नियंत्रण देता है, लेकिन काम कम नहीं करता।
PSP के साथ ZDR इस्तेमाल करने वाले संगठनों पर इन्हें बनाए रखने की ज़िम्मेदारी होती है:
- storage configuration
- क्षेत्रीय storage आवश्यकताएँ
- encryption permissions
- key authorization
- retention lifecycle
- connectivity
- validation
- safety notices पर प्रतिक्रिया
OpenAI इन्हें स्पष्ट रूप से ग्राहक की ज़िम्मेदारियों के रूप में दस्तावेज़ित करता है।
इसका मतलब है कि Private Safety Processing कोई ऐसा checkbox भर नहीं है जो AI को private बना दे।
यह एक operational security निर्भरता जोड़ती है।
अगर storage या key configuration ग़लत हो, तो safety pipeline शायद अपेक्षित ढंग से काम न करे।
Enterprise privacy सिर्फ़ अनुबंध का वादा न रहकर, धीरे-धीरे architecture की समस्या बनती जा रही है।
अपवाद अब भी हैं
“private” शब्द को निरपेक्ष नहीं समझना चाहिए।
OpenAI कानूनी अपवादों का उल्लेख करता है, जिनमें प्रतीत होने वाली बाल यौन शोषण सामग्री (apparent child sexual abuse material) शामिल है, जहाँ flag की गई images को कानून के अनुसार manual review और रिपोर्टिंग के लिए फिर भी retain किया जा सकता है।
OpenAI के व्यापक data-control दस्तावेज़ उन परिस्थितियों का भी वर्णन करते हैं जहाँ गंभीर जोखिम की जाँच ज़रूरी होने पर कुछ विशिष्ट ग्राहकों के लिए retention policies बदल सकती हैं, और सूचना की आवश्यकताएँ लागू policy पर निर्भर करती हैं।
इसलिए सही व्याख्या यह नहीं है:
कि OpenAI कभी कुछ भी access या retain नहीं कर सकता।
सही व्याख्या यह है:
यह architecture ग्राहक के नियंत्रण को कहीं ज़्यादा मज़बूती से बनाए रखने और नियमित मानव पहुँच को रोकने के लिए डिज़ाइन किया गया है, जबकि परिभाषित safety और कानूनी तंत्र फिर भी बने रहते हैं।
ये दोनों दावे बहुत अलग हैं।
एजेंट persistent होने पर यह क्यों और अहम हो जाता है
यह समस्या तब और अहम हो जाती है जब AI अलग-थलग prompts से आगे बढ़कर लंबे समय तक चलने वाले एजेंट तक पहुँचता है।
एक chatbot शायद कुछ ही आदान-प्रदान process करे।
एक एजेंट यह सब कर सकता है:
- आंतरिक systems तक पहुँचना
- code चलाना
- घंटों तक काम करना
- बार-बार अनुरोध करना
- बाहरी services से interact करना
- मूल user अनुरोध के बाद भी कार्य जारी रखना
इसलिए safety signals शायद किसी एक prompt में नहीं, बल्कि पूरे कार्य के दौरान उभरें।
OpenAI स्पष्ट रूप से लंबे agentic interactions को उन कारणों में गिनता है जिनकी वजह से safety systems को व्यापक context चाहिए।
इसका मतलब है कि privacy architecture को भी विकसित होना पड़ेगा।
हर अनुरोध को अलग-अलग जाँच लेना शायद अब पर्याप्त न रहे।
लेकिन पूरे enterprise workflows को केंद्रीय रूप से retain करना शायद स्वीकार्य न हो।
Private Safety Processing इन दोनों छोरों के बीच का रास्ता खोजने का एक प्रयास है।
क्या यह पूरी तरह प्रमाणित है?
अभी तक नहीं।
OpenAI के तकनीकी दस्तावेज़ अब इतने विस्तृत हैं कि अपेक्षित architecture को समझा जा सके, लेकिन security के कई दावे अब भी मुख्यतः OpenAI के अपने दावे हैं।
यह system कई महत्वपूर्ण मान्यताओं पर निर्भर है:
- hardware attestation अपेक्षित ढंग से काम करता है
- केवल approved workloads को ही decryption की क्षमता मिलती है
- key permissions सही ढंग से configured रहती हैं
- सीमित outputs संवेदनशील जानकारी leak नहीं करते
- operational metadata से कोई अप्रत्याशित जानकारी नहीं मिल जाती
- implementation दस्तावेज़ में बताए गए डिज़ाइन से मेल खाता है
ये सभी ऐसे क्षेत्र हैं जहाँ स्वतंत्र तकनीकी जाँच मायने रखेगी।
जब OpenAI ने अगस्त में Private Safety Processing की घोषणा की थी, तब बाहरी कवरेज ने सही ही कहा था कि architecture का विवरण अभी प्रकाशित नहीं हुआ था।
तब से OpenAI ने implementation के काफ़ी ज़्यादा दस्तावेज़ प्रकाशित किए हैं।
इससे पारदर्शिता बेहतर होती है।
लेकिन इससे प्रदाता के दस्तावेज़ स्वतंत्र सत्यापन नहीं बन जाते।
Private Inference के बारे में क्या?
DevDay 2026 में OpenAI ने Private Safety Processing को एक व्यापक दिशा के अंतर्गत रखा, जिसे उसने Private Intelligence कहा, और बताया कि इस साल की शरद ऋतु (fall) में Private Inference के एक preview की योजना है।
यह और भी महत्वपूर्ण बन सकता है।
Private Safety Processing safety review के रास्ते की रक्षा करती है।
Private Inference संभवतः model inference में ही privacy से जुड़ी समस्या को संभाल सकता है।
लेकिन इसके architecture को ज़िम्मेदारी से समझाने के लिए अभी पर्याप्त सार्वजनिक तकनीकी दस्तावेज़ मौजूद नहीं हैं।
सवाल बने हुए हैं:
- Inference कहाँ चलता है?
- Encryption keys को कौन नियंत्रित करता है?
- कौन-सा hardware trust mechanism इस्तेमाल होता है?
- क्या OpenAI के operators memory को जाँच सकते हैं?
- ग्राहक data की सुरक्षा के साथ-साथ model की सुरक्षा कैसे की जाती है?
- स्वतंत्र रूप से क्या attest किया जा सकता है?
- Confidential inference से performance पर कितनी लागत आती है?
जब तक ये विवरण प्रकाशित नहीं होते, Private Inference को तकनीकी निष्कर्ष नहीं, बल्कि निगरानी रखने योग्य विषय (watch item) ही बने रहना चाहिए।
मेरा नज़रिया: privacy और safety का एक-दूसरे के विपरीत विकल्प होना ज़रूरी नहीं
Enterprise AI की चर्चाएँ अक्सर एक सीधा समझौता सामने रखती हैं:
या तो प्रदाता safety के लिए गतिविधि की जाँच कर सकता है
या
ग्राहक का data private रहता है।
Private Safety Processing एक तीसरी architectural संभावना सुझाती है।
कड़े नियंत्रण वाली computing सीमा के भीतर मशीनों को वह जाँचने दिया जाए जो human operators नहीं जाँच सकते।
केवल सीमित safety signals को बाहर जाने दिया जाए।
मूल records को ग्राहक के storage और key controls के अधीन रखा जाए।
इससे भरोसे की ज़रूरत ख़त्म नहीं होती।
ग्राहक को अब भी इन पर भरोसा करना पड़ता है:
- hardware
- implementation
- attestation system
- safety workload
- प्रदाता के enforcement तंत्र
लेकिन यह बदल देता है कि वह भरोसा कहाँ रखा जाता है।
शायद यही ज़्यादा महत्वपूर्ण बदलाव है।
Enterprise AI privacy का भविष्य शायद इस पर निर्भर न रहे कि प्रदाता यह वादा करें:
“हम नहीं देखेंगे, हम पर भरोसा कीजिए।”
वह शायद धीरे-धीरे ऐसे architectures पर निर्भर होता जाए जिन्हें इस तरह डिज़ाइन किया गया हो कि:
सामान्य संचालन के दौरान प्रदाता के अपने लोगों को भी तकनीकी रूप से देखने से रोक दिया जाता है।
अगर वह architecture विश्वसनीय साबित होता है, तो privacy और safety को शायद एक ही switch के दो विपरीत छोर मानने की ज़रूरत न रहे।
वे system में डिज़ाइन किए गए अलग-अलग controls बन सकती हैं।
स्रोत और आगे पढ़ने के लिए
स्रोतों की समीक्षा: 2 अक्टूबर 2026।
- OpenAI — Offering Zero Data Retention for Frontier Models. Private Safety Processing का OpenAI द्वारा परिचय, और privacy बनाम safety की वह समस्या जिसे यह संभालने के लिए डिज़ाइन की गई है।
- OpenAI API — ZDR with Private Safety Processing. मौजूदा तकनीकी दस्तावेज़, जिनमें customer-controlled storage, सुरक्षित safety runtime, सीमित outputs और ग्राहक की ज़िम्मेदारियाँ शामिल हैं।
- OpenAI API — Data Controls in the OpenAI Platform. मौजूदा retention policies, ZDR का व्यवहार, endpoint की सीमाएँ और safety-retention के अपवाद।
- OpenAI — DevDay 2026 Announcements. DevDay का सारांश, जिसमें Private Intelligence और Private Inference के नियोजित preview का उल्लेख है।
- The Register — OpenAI Chases Anthropic’s Biz Customers with Zero Data Retention Pledge. शुरुआती स्वतंत्र कवरेज, जो safety monitoring और enterprise data-retention आवश्यकताओं के बीच के तनाव को रेखांकित करता है।
- TechCrunch — OpenAI Seeks to One-Up Anthropic with New Customer Privacy Protections. Enterprise privacy चिंताओं और प्रतिस्पर्धी safety-retention तरीकों के बारे में स्वतंत्र संदर्भ।