कॉर्पोरेट प्रबंधन और शासन: व्यक्तिगत उपयोग और कॉर्पोरेट उपयोग दो अलग बातें हैं
📚 सीरीज़ नेविगेशन: पिछला लेख 38 शब्दावली पूरे Codex अध्याय में प्रयुक्त तकनीकी शब्दों की एक संदर्भ मार्गदर्शिका है, जहां आप किसी भी कठिन शब्द का अर्थ देख सकते हैं। यह लेख Codex अध्याय का अंतिम और वैकल्पिक लेख है: यह मुख्य रूप से टीम प्रशासकों / तकनीकी प्रमुखों के लिए है, जो बताते हैं कि एक कंपनी पूरी टीम में सुरक्षित, नियंत्रित और ऑडिट करने योग्य तरीके से Codex को कैसे लागू कर सकती है। यदि आप व्यक्तिगत उपयोगकर्ता हैं, तो आप इस लेख को छोड़ सकते हैं, क्योंकि पिछले 38 लेख आपके लिए पर्याप्त हैं; लेकिन यदि आपको कभी टीम के लिए इसे प्रबंधित करना पड़े, तो आप इस लेख को देख सकते हैं। यह हमारा अंतिम पड़ाव है, और लेख के अंत में मैं पूरे Codex अध्याय का समापन करूँगा।
एक कड़वी बात: व्यक्तिगत उपयोग और कॉर्पोरेट उपयोग दो पूरी तरह से अलग बातें हैं।
जब आप इसे व्यक्तिगत रूप से उपयोग करते हैं, तो आपकी चिंता केवल यह होती है कि "क्या मॉडल स्मार्ट है, क्या यह तेज़ है, और क्या इसे उपयोग करना आसान है।" लेकिन जब आप वह व्यक्ति होते हैं जो यह तय करता है कि "कंपनी के 200 इंजीनियर इसका उपयोग करेंगे," तो आपके दिमाग में आने वाले प्रश्न ये होते हैं — "क्या हमारे कोड का उपयोग मॉडल ट्रेनिंग के लिए किया जाएगा? क्या मैं यह देख सकता हूँ कि किसने क्या बदलाव किए? यदि किसी ने गलती से उत्पादन (production) कॉन्फ़िगरेशन को rm -rf कर दिया, तो क्या मैं उसे रोक सकता हूँ?"
मैंने स्वयं इस अंतर को महसूस किया है। इस वर्ष अप्रैल में मैंने एक मित्र की छोटी टीम के लिए Codex का मूल्यांकन किया, और मैंने बहुत उत्साह के साथ उसे दिखाया कि यह कितना शक्तिशाली है। लेकिन उसने मुझसे केवल एक प्रश्न पूछा: "क्या OpenAI हमारे ग्राहकों के कोड का उपयोग मॉडल ट्रेनिंग के लिए करेगा?" मैं वहीं निरुत्तर हो गया — मैंने इस बारे में पढ़ा ही नहीं था, और मुझे दस्तावेज़ देखने पड़े। तब मुझे समझ आया: प्रशासकों (administrators) के लिए, "शासन (governance)" केवल एक अतिरिक्त सुविधा नहीं है, बल्कि उपकरण के उपयोग की पूर्व-शर्त है।
यह लेख इसी पूर्व-शर्त को स्पष्ट करेगा।
इस लेख को पूरा पढ़ने के बाद, आपको मिलेगा:
- व्यक्तिगत और टीम/कॉर्पोरेट संस्करणों के बीच का वास्तविक अंतर
- लॉगिन और खाता प्रबंधन: प्रशासकों के लिए SSO, SCIM और RBAC का महत्व
- सबसे महत्वपूर्ण डेटा सुरक्षा प्रश्न: क्या कोड का उपयोग ट्रेनिंग के लिए होगा, डेटा कहाँ रहेगा, और कितने समय तक सुरक्षित रहेगा
- पूरी टीम के लिए सुरक्षा सीमाएं तय करने के लिए एक केंद्रीय नीति फ़ाइल (central policy file) का उपयोग करना
- ऑडिट और अनुपालन: किसने क्या किया, किस मॉडल का उपयोग हुआ, और बिलिंग रिपोर्ट कैसे निकालें
- बजट और कोटे का नियंत्रण
- प्रशासकों के लिए एक "लॉन्च से पहले की त्वरित चेकलिस्ट"
⚠️ नीचे दिए गए सभी विशिष्ट पृष्ठ, कमांड, कॉन्फ़िगरेशन और व्यवहार Codex के प्रशासक सेटअप दस्तावेज़ पर आधारित हैं; मॉडल के नाम, सदस्यता पैकेज और उपलब्धता की सीमाएं आपके अनुबंध के अनुसार भिन्न हो सकती हैं, हमेशा अपने व्यवस्थापक कंसोल में दिखाई देने वाले विकल्पों को ही आधार मानें। कॉर्पोरेट शासन क्षमताएं मुख्य रूप से ChatGPT Business / Enterprise पैकेज से जुड़ी होती हैं।
01 व्यक्तिगत और कॉर्पोरेट संस्करणों में अंतर: नियंत्रण की क्षमता
बहुत से लोग सोचते हैं कि कॉर्पोरेट संस्करण केवल "व्यक्तिगत संस्करण + अधिक कोटा" है। ऐसा नहीं है।
सादृश्य: घर की रसोई और एक बड़ी चेन की केंद्रीय रसोई। जब आप अपने घर में खाना बनाते हैं, तो चाकू कहाँ रखना है, आँच कितनी रखनी है, और हाथ कब धोना है, यह पूरी तरह से आपका निर्णय है; कोई रोकने वाला नहीं है और न ही इसकी आवश्यकता है। लेकिन एक बड़ी चेन की केंद्रीय रसोई में केवल "खाना बनाना" पर्याप्त नहीं है — आपके पास एक समान कार्यप्रणाली होनी चाहिए, सुरक्षा पास और आईडी कार्ड होने चाहिए (यह तय करने के लिए कि कौन कहाँ जा सकता है), सुरक्षा कैमरे होने चाहिए, और लागत का हिसाब होना चाहिए। कॉर्पोरेट संस्करण में मिलने वाली क्षमताएं इसी "नियंत्रण" से जुड़ी होती हैं, न कि केवल काम करने की क्षमता से।
दोनों के बीच का अंतर इस तालिका से समझें:
| आयाम | व्यक्तिगत संस्करण (Plus / Pro आदि) | टीम / कॉर्पोरेट संस्करण (Business / Enterprise) |
|---|---|---|
| उपयोगकर्ता | केवल आप स्वयं | प्रशासक द्वारा प्रबंधित, भूमिकाओं के अनुसार अधिकार |
| लॉगिन विधि | अपना खाता और पासवर्ड | अनिवार्य SSO (Single Sign-On), MFA, SCIM द्वारा खाता सिंक |
| सुरक्षा सीमा | स्थानीय स्तर पर sandbox और स्वीकृति | प्रशासक द्वारा केंद्रीय नीति लागू करना, जिसे उपयोगकर्ता बदल नहीं सकते (requirements.toml) |
| डेटा ट्रेनिंग | खाता सेटिंग्स के अनुसार | कॉर्पोरेट डेटा का उपयोग ट्रेनिंग के लिए नहीं होता, आधिकारिक वादा |
| ऑडिट | उपलब्ध नहीं | गतिविधियों के लॉग और ऑडिट रिपोर्ट निर्यात करने की सुविधा |
| उपयोग की निगरानी | बुनियादी विवरण | विश्लेषिकी (Analytics) डैशबोर्ड + API, व्यक्तिगत और उत्पाद स्तर पर रिपोर्ट |
| प्रबंधन | प्रबंधन की आवश्यकता नहीं | विशिष्ट Codex Admin भूमिका, जो नीतियां, वातावरण और रिपोर्ट संभालती है |
आप देख सकते हैं कि दाईं ओर के कॉलम की सभी क्षमताएं नियंत्रण से जुड़ी हैं। व्यक्तिगत उपयोगकर्ता को इनकी आवश्यकता नहीं होती, लेकिन प्रशासक के लिए यही सबसे महत्वपूर्ण हैं।
एक और बात जो शुरू में भ्रमित कर सकती है: Codex दो हिस्सों में बंटा है — "स्थानीय (local)" और "क्लाउड (cloud)", और दोनों को अलग से सक्रिय किया जाता है।
Codex local में डेस्कटॉप ऐप, CLI और IDE एक्सटेंशन शामिल हैं, जहाँ कोड डेवलपर के कंप्यूटर के सैंडबॉक्स में चलता है। Codex cloud में क्लाउड टास्क, कोड रिव्यू आदि शामिल हैं, जहाँ काम रिमोट कंटेनर में चलता है और इसके लिए कोड रिपॉजिटरी (जैसे GitHub) को कनेक्ट करना होता है।
प्रशासक केवल स्थानीय, केवल क्लाउड, या दोनों को चालू कर सकता है। यह निर्णय सीधे यह तय करता है कि कोड किस मशीन पर संसाधित होगा, जो डेटा सुरक्षा का पहला निर्णय है।
💡 संक्षेप में: कॉर्पोरेट संस्करण में नियंत्रण की क्षमताएं होती हैं — अधिकार प्रबंधन, नीतियां, ऑडिट और लागत नियंत्रण, जो प्रशासकों के लिए आवश्यक हैं।
02 खाता प्रबंधन: SSO, SCIM और RBAC तीन महत्वपूर्ण स्तंभ
जब किसी टीम के लिए उपकरण लागू किया जाता है, तो पहली समस्या यह होती है कि सभी को खाते कैसे दिए जाएं और किसी कर्मचारी के जाने पर उन खातों को सुरक्षित रूप से कैसे बंद किया जाए। यदि आप यह काम मैन्युअल रूप से करेंगे, तो यह बहुत कठिन होगा और सुरक्षा जोखिम भी बना रहेगा।
इसी समस्या के समाधान के लिए SSO, SCIM और RBAC का उपयोग किया जाता है।
सादृश्य: कंपनी का आईडी कार्ड और सुरक्षा पास सिस्टम। SSO का मतलब है "एक आईडी कार्ड से सभी दरवाजों का खुलना" (हर सिस्टम के लिए अलग पासवर्ड की आवश्यकता नहीं); SCIM का मतलब है "HR सिस्टम में भर्ती या इस्तीफा होने पर सुरक्षा पास का स्वतः चालू या बंद होना" (आईटी टीम को मैन्युअल रूप से खाता बंद करने की आवश्यकता नहीं होती); RBAC का मतलब है "कार्ड पर अधिकार का स्तर — इंटर्न केवल काम करने की जगह जा सकता है, और केवल फाइनेंस टीम ही सर्वर रूम में जा सकती है" (भूमिका के अनुसार अधिकार)।
इनका सरल विवरण:
SSO (Single Sign-On) — कर्मचारी कंपनी के एकीकृत लॉगिन (जैसे Okta या Azure AD) का उपयोग करके Codex में प्रवेश करते हैं। प्रशासक सुरक्षा बढ़ाने के लिए MFA (Multi-Factor Authentication) भी अनिवार्य कर सकते हैं।
SCIM (स्वचालित खाता सिंक) — यह Codex उपयोगकर्ताओं को आपकी पहचान प्रदाता (IdP) सेवा से जोड़ता है। जब कोई नया कर्मचारी शामिल होता है, तो उसे स्वतः खाता मिल जाता है; और जब कोई जाता है, तो उसका खाता स्वतः बंद हो जाता है। यह ऑडिट और केंद्रीय नियंत्रण के लिए बहुत महत्वपूर्ण है।
RBAC (Role-Based Access Control) — प्रशासकों के लिए यह बहुत महत्वपूर्ण है। आधिकारिक रूप से सुझाया गया भूमिकाओं का विभाजन इस प्रकार है:
- सभी Codex उपयोगकर्ताओं के लिए एक "Codex Users" समूह बनाएं;
- नीतियां और कॉन्फ़िगरेशन प्रबंधित करने वाले कुछ चुनिंदा लोगों के लिए "Codex Admin" समूह बनाएं;
- "Codex प्रबंधन" के अधिकार केवल Codex Admin समूह को ही दें।
ऐसा विभाजन क्यों आवश्यक है? क्योंकि Codex Admin के पास बहुत अधिक अधिकार होते हैं — वह पूरे कार्यक्षेत्र की उपयोग रिपोर्ट देख सकता है, सुरक्षा नीतियां बदल सकता है, और क्लाउड वातावरण का प्रबंधन कर सकता है। यदि यह अधिकार सभी को दे दिया जाए, तो सुरक्षा खतरे में पड़ सकती है। आधिकारिक नियम यही है: प्रबंधन के अधिकार कम से कम लोगों को दें।
व्यवस्थापक स्तर पर सेटअप का सामान्य क्रम इस प्रकार है:
1. ChatGPT कॉर्पोरेट कंसोल → Workspace Settings → Settings and Permissions में जाएं
2. "Allow members to use Codex Local" चालू करें → इससे स्थानीय टूल्स (App/CLI/IDE) सक्रिय होंगे
3. क्लाउड के लिए: "Allow members to use Codex cloud" चालू करें और GitHub कनेक्ट करें
4. Custom Roles में जाएं, Codex Users और Codex Admin समूह बनाएं और अधिकार बांटें
5. SCIM का उपयोग करके इन समूहों को अपने IdP से जोड़ेंनए कार्यक्षेत्रों में Codex local डिफ़ॉल्ट रूप से सक्रिय होता है; यदि किसी उपयोगकर्ता को 403 - Unauthorized की त्रुटि आती है, तो इसका मतलब है कि या तो स्थानीय उपयोग का स्विच बंद है या वह अधिकृत समूह में शामिल नहीं है।
💡 संक्षेप में: SSO प्रवेश को नियंत्रित करता है, SCIM खातों के स्वतः सिंक को, और RBAC अधिकारों को नियंत्रित करता है; प्रबंधन के अधिकार हमेशा सीमित लोगों को ही दें.
03 डेटा सुरक्षा: क्या कोड का उपयोग ट्रेनिंग के लिए किया जाएगा
यह डेटा सुरक्षा से जुड़ा सबसे महत्वपूर्ण प्रश्न है। आधिकारिक दस्तावेज़ों के अनुसार:
- कॉर्पोरेट डेटा का उपयोग मॉडल ट्रेनिंग के लिए नहीं किया जाता (No training on enterprise data)
- स्थानीय उपकरण (App, CLI, IDE) जीरो डेटा रिटेंशन (Zero Data Retention) का समर्थन करते हैं, जिससे कोड डेवलपर की मशीन पर ही रहता है
- डेटा निवास (residency) और प्रतिधारण (retention) नीतियां आपके ChatGPT Enterprise अनुबंध के अनुसार काम करती हैं
- डेटा एन्क्रिप्शन: स्टोरेज में AES-256 और ट्रांसफर में TLS 1.2+
- अनुपालन ऑडिट के लिए Compliance API उपलब्ध है
इन नीतियों का अर्थ प्रशासकों के लिए इस प्रकार है:
पहला, क्या डेटा का उपयोग ट्रेनिंग के लिए होगा? बिल्कुल नहीं — कॉर्पोरेट डेटा का उपयोग OpenAI मॉडलों को प्रशिक्षित करने के लिए नहीं करता है। यह कॉर्पोरेट संस्करण का एक महत्वपूर्ण वादा है।
दूसरा, कोड कहाँ और कितने समय तक रहेगा? स्थानीय उपकरण जीरो डेटा रिटेंशन (ZDR) का समर्थन करते हैं — कोड डेवलपर के कंप्यूटर पर ही संसाधित होता है और OpenAI सर्वर पर स्थायी रूप से सहेजा नहीं जाता। क्लाउड संस्करण में कोड रिपॉजिटरी कनेक्ट होने के कारण, डेटा निवास और प्रतिधारण आपके Enterprise अनुबंध की सेटिंग्स के अनुसार होता है। इसलिए "स्थानीय बनाम क्लाउड" का चयन केवल प्रदर्शन पर नहीं, बल्कि डेटा सुरक्षा प्राथमिकताओं पर भी आधारित होता है।
तीसरा, क्या डेटा को किसी विशिष्ट क्षेत्र में सीमित किया जा सकता है? हाँ, आप नीति फ़ाइल में enforce_residency (जैसे enforce_residency = "us") सेट करके डेटा प्रोसेसिंग को निर्दिष्ट क्षेत्र तक सीमित कर सकते हैं।
यहाँ एक महत्वपूर्ण बात समझें: ऑडिट लॉग और "कोड प्रतिधारण (code retention)" दो अलग बातें हैं। Codex गतिविधियों के ऑडिट लॉग अधिकतम 30 दिनों तक सुरक्षित रखे जाते हैं; जबकि "जीरो डेटा रिटेंशन (ZDR)" का संबंध आपके कोड को ट्रेनिंग के लिए सुरक्षित न रखने से है। एक रिकॉर्ड रखने के लिए है, और दूसरा डेटा के अनधिकृत उपयोग को रोकने के लिए।
सादृश्य: बैंक का सुरक्षा कैमरा और आपकी जमा राशि की सुरक्षा। सुरक्षा कैमरा (ऑडिट लॉग) सुरक्षा के लिए कुछ समय तक रिकॉर्डिंग रखता है; और आपकी जमा राशि का सुरक्षित होना एक अलग वादा है। आपको दोनों की आवश्यकता है, लेकिन दोनों अलग हैं।
💡 संक्षेप में: कॉर्पोरेट डेटा का उपयोग ट्रेनिंग के लिए नहीं होता, स्थानीय उपयोग में डेटा सहेजा नहीं जाता, और डेटा को विशिष्ट क्षेत्र में सीमित किया जा सकता है — ऑडिट लॉग का 30 दिन तक रहना और कोड का सहेजा न जाना दो अलग नीतियां हैं।
04 केंद्रीय नीति लागू करना: पूरी टीम के लिए सुरक्षा सीमाएं तय करना
अध्याय 15 और 16 में हमने देखा था कि स्थानीय स्तर पर sandbox, स्वीकृति और requirements.toml को कैसे सेट किया जाए — वह व्यक्तिगत कंप्यूटर के लिए था। लेकिन एक प्रशासक के रूप में, आप सभी कंप्यूटरों पर जाकर मैन्युअल रूप से कॉन्फ़िगरेशन नहीं बदल सकते।
कॉर्पोरेट संस्करण में इसका समाधान यह है: प्रशासक केंद्रीय नीति फ़ाइल जारी करता है, जिसे उपयोगकर्ता बदल नहीं सकते।
सादृश्य: स्टोर के लिए मुख्य कार्यालय द्वारा जारी नियम पुस्तिका। मैनेजर रोज़मर्रा के छोटे निर्णय ले सकता है; लेकिन महत्वपूर्ण नियम (जैसे खाद्य सुरक्षा नियम, बिलिंग नियम) मुख्य कार्यालय द्वारा तय किए जाते हैं और उन्हें बदला नहीं जा सकता। Codex की कॉर्पोरेट नीति वही नियम पुस्तिका है।
आधिकारिक तौर पर नीतियों को दो श्रेणियों में बांटा गया है:
| प्रकार | विवरण | क्या उपयोगकर्ता बदल सकता है |
|---|---|---|
| Requirements (अनिवार्य नियम) | प्रशासक द्वारा तय किए गए सुरक्षा नियम: अनुमत सैंडबॉक्स स्तर, अनुमति नीतियां, इंटरनेट एक्सेस, अनुमत MCP सर्वर्स आदि। | नहीं बदल सकता, टकराव होने पर Codex स्वतः सुरक्षित स्तर पर आ जाएगा |
| Managed defaults (托管默认值 - प्रबंधित डिफ़ॉल्ट) | Codex शुरू होने पर लागू होने वाली डिफ़ॉल्ट सेटिंग्स | उपयोगकर्ता सत्र के दौरान इसे बदल सकता है, लेकिन दोबारा शुरू होने पर यह डिफ़ॉल्ट पर आ जाएगी |
दोनों नीतियां TOML फ़ाइलों के रूप में होती हैं, जिन्हें requirements.toml (अनिवार्य नियम) और managed_config.toml (प्रबंधित डिफ़ॉल्ट) कहा जाता है। सबसे आसान तरीका "क्लाउड नीति प्रबंधन" है — Codex नीति पृष्ठ पर नियम लिखें और उन्हें उपयोगकर्ता समूह से जोड़ दें। जब उपयोगकर्ता लॉगिन करेंगे, तो नियम स्वतः उनके सिस्टम पर लागू हो जाएंगे।
उदाहरण के लिए, यदि आप पूर्ण अधिकार (danger-full-access / --yolo) को प्रतिबंधित करना चाहते हैं, तो यह नियम लागू करें:
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]इससे कोई भी उपयोगकर्ता सुरक्षा नियमों को बाईपास नहीं कर पाएगा और सुरक्षित सैंडबॉक्स में ही काम करेगा।
यदि आप प्रायोगिक क्षमताओं (जैसे कंप्यूटर नियंत्रण) को बंद करना चाहते हैं, तो:
[features]
browser_use = false
in_app_browser = false
computer_use = falseया यदि आप महत्वपूर्ण कमांड्स के लिए अनिवार्य स्वीकृति चाहते हैं:
[rules]
prefix_rules = [
{ pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "推送 / 提交前必须人工确认" },
]ध्यान दें: अनिवार्य नियमों में केवल "prompt" (स्वीकृति मांगना) या "forbidden" (प्रतिबंधित करना) का ही उपयोग किया जा सकता है, "allow" का नहीं — नीतियां केवल सुरक्षा बढ़ाने/सख्त करने के लिए होती हैं, अधिकार ढीले करने के लिए नहीं।
यदि आप MDM (Mobile Device Management) टूल्स का उपयोग करते हैं, तो आप सिस्टम-स्तर पर फ़ाइलों के माध्यम से भी इसे लागू कर सकते हैं। Mac/Linux और Windows पर इनके पाथ अलग होते हैं, जबकि क्लाउड नीति सभी प्लेटफ़ॉर्म्स के लिए एक समान काम करती है।
💡 संक्षेप में:
requirements.tomlके माध्यम से केंद्रीय नीति लागू करें, जो क्लाउड प्रबंधन द्वारा सबसे आसान है; नीतियां केवल सुरक्षा बढ़ाने के लिए काम करती हैं, अधिकार ढीले करने के लिए नहीं।
05 ऑडिट और अनुपालन (Compliance): गतिविधियों की जांच करना
नीति लागू करने के बाद, यह आवश्यक है कि आप यह देख सकें कि किसने, कब, कौन सा मॉडल उपयोग किया और क्या काम किया।
आधिकारिक तौर पर तीन प्रकार की निगरानी सुविधाएं दी गई हैं:
| उपकरण | कार्य | लक्षित उपयोगकर्ता |
|---|---|---|
| Analytics डैशबोर्ड | बुनियादी विश्लेषण: सक्रिय उपयोगकर्ता, उपयोग की मात्रा, कोड रिव्यू फीडबैक | प्रशासकों की दैनिक निगरानी के लिए |
| Analytics API | दैनिक उपयोग के डेटा को अपने BI/डेटा सिस्टम में सिंक करना | रिपोर्ट तैयार करने के लिए |
| Compliance API | विस्तृत गतिविधियों के लॉग निर्यात करना, जिन्हें सुरक्षा प्रणालियों (SIEM/DLP) से जोड़ा जा सके | सुरक्षा और ऑडिट विभाग के लिए |
दैनिक कार्यों के लिए Analytics डैशबोर्ड पर्याप्त है — जहाँ आप CLI, IDE और क्लाउड में टोकन की खपत और सक्रिय उपयोगकर्ताओं की रिपोर्ट देख सकते हैं और डेटा को CSV / JSON में डाउनलोड कर सकते हैं। ध्यान रखें कि डेटा रिपोर्ट में 12 घंटे तक का विलंब हो सकता है।
विस्तृत जांच के लिए Compliance API का उपयोग किया जाता है, जो निम्नलिखित डेटा प्रदान करता है: भेजा गया प्रॉम्प्ट, Codex का उत्तर, उपयोगकर्ता आईडी, मॉडल का नाम, टोकन का उपयोग और समय।
लॉग डाउनलोड करने का सामान्य कमांड:
curl -L -H "Authorization: Bearer YOUR_COMPLIANCE_API_KEY" \
"https://api.chatgpt.com/v1/compliance/workspaces/WORKSPACE_ID/logs?event_type=CODEX_LOG&after=2026-03-01T00:00:00Z"यह आपको लॉग फ़ाइलों की सूची देगा जिन्हें आप डाउनलोड करके अपने SIEM सिस्टम में एकीकृत कर सकते हैं।
दो महत्वपूर्ण बातें ध्यान में रखें:
पहला, ऑडिट लॉग केवल 30 दिनों तक सुरक्षित रहते हैं — यदि आपको लंबे समय तक डेटा सुरक्षित रखना है, तो नियमित रूप से लॉग निर्यात करके सहेजें।
दूसरा, केवल ChatGPT लॉगिन द्वारा किए गए कार्य ही ऑडिट लॉग में शामिल होते हैं। API की (API key) का उपयोग करके किए गए कार्य इस रिपोर्ट में नहीं आते, उनके लिए API प्रबंधन कंसोल में देखना होगा।
ऑटोमेशन कार्यों के लिए उपयोग किए जाने वाले access tokens को सुरक्षित रखें:
- इन्हें पासवर्ड की तरह सुरक्षित रखें, लॉग्स में न दिखाएं, इनकी वैधता अवधि (7/30/60/90 दिन) निर्धारित करें, और उपयोग के बाद बंद कर दें;
- सार्वजनिक CI वातावरण या साझा प्रणालियों में इनका उपयोग करने से बचें ताकि ये लीक न हों।
मेरा सुझाव है कि access token की वैधता अवधि "स्थायी/अनंत" न रखें। इससे सुरक्षा जोखिम बढ़ता है और प्रबंधन कठिन हो जाता है।
💡 संक्षेप में: सामान्य कार्यों के लिए Analytics डैशबोर्ड और सुरक्षा ऑडिट के लिए Compliance API का उपयोग करें; लॉग्स केवल 30 दिनों तक रहते हैं और API की का उपयोग इसमें शामिल नहीं होता।
06 लागत नियंत्रण: बजट के भीतर काम करना
अंत में, खर्चों के प्रबंधन की बात करते हैं।
खर्चों की निगरानी के लिए Analytics डैशबोर्ड / API का उपयोग करें — जहाँ आप यह देख सकते हैं कि किस विभाग या उपयोगकर्ता ने कितना कोटा खर्च किया है।
सादृश्य: घर का बजट। यह जानने के लिए कि खर्च कहाँ हुआ, केवल कुल राशि देखना काफी नहीं है, बल्कि यह देखना होता है कि भोजन, यात्रा और किराए पर कितना खर्च हुआ। Analytics की विस्तृत रिपोर्ट आपको यही वर्गीकरण प्रदान करती है।
लागत नियंत्रण के तीन मुख्य उपाय:
पहला, नीतियों के स्तर पर नियंत्रण: requirements.toml लागू करते समय सुरक्षा सीमाओं को सख्त रखना स्वतः ही खर्च को नियंत्रित करने में मदद करता है।
दूस处, मॉडल और सोचने की क्षमता का स्तर: सोचने की क्षमता को बढ़ाना अधिक खर्चीला होता है। आप managed_config.toml में डिफ़ॉल्ट सोचने की क्षमता को मध्यम (model_reasoning_effort = "medium") पर सेट कर सकते हैं, ताकि सभी संतुलित स्तर से शुरुआत करें और केवल आवश्यकता होने पर ही इसे बढ़ाएं। सरल कार्यों के लिए gpt-5.4-mini का उपयोग करें।
तीसरा, सेवा स्तर (service tier): आप डिफ़ॉल्ट रूप से flex मोड सेट कर सकते हैं ताकि अनावश्यक रूप से fast मोड का कोटा खर्च न हो।
लागत नियंत्रण की सही रणनीति:
| ❌ जोखिम भरी रणनीतियां | ✅ सुरक्षित और नियंत्रित रणनीतियां |
|---|---|
| केवल महीने के अंत में बिल देखना | हर सप्ताह Analytics रिपोर्ट की जांच करना |
सभी को डिफ़ॉल्ट रूप से xhigh क्षमता देना | डिफ़ॉल्ट रूप से medium देना, और ज़रूरत पड़ने पर मैन्युअल रूप से बढ़ाना |
| सभी को महंगे मॉडलों और सभी फ़ीचर्स की अनुमति देना | नीतियों द्वारा अधिकारों को सीमित रखना और केवल योग्य उपयोगकर्ताओं को अधिकार देना |
| बिलों की जांच करने वाला कोई न होना | किसी एक व्यक्ति को उपयोग और लागत की निगरानी की ज़िम्मेदारी सौंपना |
खर्चों की समय-समय पर समीक्षा करने की आदत डालें, और全员 (all-member) लागू करने से पहले छोटे स्तर पर परीक्षण करें।
💡 संक्षेप में: Analytics से उपयोग की निगरानी करें, सोचने की क्षमता को डिफ़ॉल्ट रूप से संतुलित रखें, और नियमित रूप से बजट की समीक्षा करें।
07 निष्कर्ष
इस लेख में हमने प्रशासक के दृष्टिकोण से Codex को कॉर्पोरेट स्तर पर लागू करने के महत्वपूर्ण पहलुओं को समझा:
- कॉर्पोरेट संस्करण का मुख्य उद्देश्य नियंत्रण है — अधिकार प्रबंधन, नीतियां, ऑडिट और लागत नियंत्रण।
- खाता प्रबंधन: SSO लॉगिन को नियंत्रित करता है, SCIM खातों के स्वतः सिंक को, और RBAC अधिकारों को नियंत्रित करता है।
- डेटा सुरक्षा: कॉर्पोरेट डेटा का उपयोग ट्रेनिंग के लिए नहीं होता, स्थानीय उपयोग में डेटा सहेजा नहीं जाता, और इसे विशिष्ट क्षेत्र में सीमित किया जा सकता है।
- केंद्रीय नीति:
requirements.tomlके माध्यम से नियम लागू करें जिन्हें उपयोगकर्ता बदल नहीं सकते। - ऑडिट: Analytics डैशबोर्ड से रिपोर्ट देखें और Compliance API से लॉग डाउनलोड करें; लॉग केवल 30 दिनों तक रहते हैं।
- लागत: बजट की नियमित जांच करें और डिफ़ॉल्ट रूप से संतुलित मॉडलों व सोचने की क्षमता का उपयोग करें।
यहाँ लॉन्च से पहले की त्वरित चेकलिस्ट दी गई है, जिसका आप उपयोग कर सकते हैं:
- [ ] यह तय कर लिया है कि स्थानीय, क्लाउड या दोनों का उपयोग करना है (डेटा सुरक्षा के लिए महत्वपूर्ण)
- [ ] विभिन्न विभागों के लिए ज़िम्मेदार व्यक्तियों (सुरक्षा प्रमुख, विश्लेषिकी प्रमुख) को नियुक्त कर दिया है
- [ ] Codex Users और Codex Admin समूह बना दिए हैं और अधिकार विभाजित कर दिए हैं
- [ ] SSO / MFA / SCIM सेटअप पूरा कर लिया है ताकि खातों का प्रबंधन स्वतः हो सके
- [ ]
requirements.tomlनीति फ़ाइल लागू कर दी है ताकि सुरक्षा नियम सक्रिय हो सकें - [ ] Analytics और Compliance API की सेट कर ली है और लॉग डाउनलोड की जांच कर ली है
- [ ] access token की वैधता सीमा तय कर दी है
- [ ] बजट की समीक्षा करने का चक्र निर्धारित कर लिया है
इसके साथ ही, हमारा Codex अध्याय यहाँ समाप्त होता है।
हमने शुरुआत से लेकर अब तक Codex के सभी महत्वपूर्ण पहलुओं को समझा है — पर्यावरण सेटअप से लेकर CLI, डेस्कटॉप ऐप, IDE एक्सटेंशन और क्लाउड संस्करण तक; AGENTS.md, config.toml, सैंडबॉक्स स्तर, अनुमति नीतियां, MCP, उप-एजेंट, Skills और Hook को समझा; और अंत में कॉर्पोरेट प्रबंधन के बारे में जाना।
ट्यूटोरियल को पूरा पढ़ने के लिए बधाई — बहुत कम लोग पूरी श्रृंखला को समाप्त कर पाते हैं।
लेकिन केवल पढ़ना पर्याप्त नहीं है, वास्तविक सीख अभ्यास से ही आती है। हमारा सुझाव है कि आप अपने किसी वास्तविक कार्य — जैसे कोई छोटा बग ठीक करना, कोई स्क्रिप्ट लिखना या कोड में सुधार करना — के लिए Codex का उपयोग करके देखें। जब आप इसका व्यावहारिक रूप से उपयोग करेंगे, तभी आप इसे सही से समझ पाएंगे।
उपकरण केवल एक साधन है, असली मूल्य इस बात में है कि आप इसके माध्यम से क्या परिणाम प्राप्त करते हैं। आगे बढ़ें और व्यावहारिक अनुभव प्राप्त करें!