जब एआई दस्तावेज़ को संपादित करता है, तो परिवर्तन की ज़िम्मेदारी किसकी है?

एक दस्तावेज़ यह दिखा सकता है कि किसने वाक्य बदल दिया, जबकि यह अनुमान लगाते रहने देता है कि अब इसे किसने अनुमोदित किया। जब एआई और लोग दोनों ने शब्दावली को संशोधित कर दिया, तो अंतिम संपादन के बगल में नाम होने से उस प्रश्न का उत्तर नहीं मिलता।

एक काल्पनिक समर्थन नीति पर विचार करें जो दो कार्यदिवसों के भीतर प्रतिक्रिया का वादा करती है। एक एआई पुनर्लेखन एक कार्यदिवस का प्रस्ताव रखता है। एक मानव संपादक इसे तीन कर देता है, और टीम लीड दस्तावेज़ को अनुमोदित करता है। जारी फ़ाइल सामान्य दिखती है। इसके इतिहास में एक अस्वीकृत प्रस्ताव, एक मानव संशोधन, और यह निर्णय शामिल है कि ग्राहकों को क्या अपेक्षित होना चाहिए।

उस परिवर्तन की ज़िम्मेदारी किसकी है? हमें योगदानों को अलग‑अलग पहचानना होगा तभी हम उन्हें जारी करने की ज़िम्मेदारी सौंप सकें। अन्यथा, “एआई‑सहायित” शब्द हमें यह बताने में बहुत कम मदद करता है कि अंतिम शब्दावली कैसे बनी।

संपादन को निर्णय से अलग करें

Microsoft की 29 सितंबर, 2025 की घोषणा कि Word में एजेंट मोड ने अपना फ्रंटियर रोलआउट शुरू किया ने संवादात्मक संपादन को दस्तावेज़ अनुप्रयोग में, प्रारम्भ में वेब पर, स्थापित किया। वह घोषणा रोलआउट तिथि को निर्धारित करती है, न कि यह कि कोई विशेष संगठन परिणामी परिवर्तनों की समीक्षा कैसे करता है।

एआई को इस प्रकार उपयोग करने वाली टीम के लिए उपयोगी प्रारंभिक बिंदु वह व्यक्ति है जो संपादन का अनुरोध करता है। उस व्यक्ति को उस सॉफ़्टवेयर से अलग रिकॉर्ड करें जो इसे उत्पन्न करता है। यदि कोई बाद में सुझाव को पुनर्लेखित करता है, तो उस योगदान को भी संरक्षित रखें। अनुमोदन एक अन्य क्रिया है, जो उस संस्करण से जुड़ी होती है जिसे समीक्षक ने वास्तव में देखा।

इन भूमिकाओं के लिए हर कार्य के लिए अलग‑अलग लोगों की आवश्यकता नहीं होती। एक संपादक पुनर्लेखन का अनुरोध कर सकता है, उसे संशोधित कर सकता है, और उसे अनुमोदित करने का अधिकार भी रख सकता है। अंतर अभी भी महत्वपूर्ण है: छोटे पैराग्राफ का अनुरोध करना अनिवार्य रूप से यह नहीं दर्शाता कि वह सॉफ़्टवेयर द्वारा किए गए हर परिवर्तन को अनुमोदित करता है।

यह W3C PROV डेटा मॉडल इस इतिहास का वर्णन करने के लिए एक शब्दावली प्रदान करता है। दस्तावेज़ और उनके संस्करणों को इकाइयों के रूप में, संपादन और अनुमोदनों को गतिविधियों के रूप में, तथा लोग और सॉफ़्टवेयर को एजेंट के रूप में दर्शाया जा सकता है। मॉडल उनके बीच के संबंधों का विवरण देता है। यह कानूनी उत्तरदायित्व निर्धारित नहीं करता और न ही लेखक फ़ील्ड में दिखाई देने वाले व्यक्ति की प्रामाणिकता स्थापित करता है।

तकनीकी लेखन या समर्थन सामग्री से जुड़े एआई‑सहायित दस्तावेज़ कार्यप्रवाह के लिए, इसका अर्थ है कि प्रत्येक रिकॉर्ड किए गए कार्य का क्या प्रतिनिधित्व है, इसे परिभाषित करना। एक टिप्पणी चर्चा में योगदान को पहचानती है। एक अनुमोदन को विशिष्ट शब्दावली जारी करने की अनुमति को पहचानना चाहिए। दोनों को एक ही सामान्य “समीक्षित” स्थिति देना रिकॉर्ड को कम उपयोगी बना देगा।

एक बदले हुए अंश के लिए रिकॉर्ड बनाएं

प्रतिक्रिया‑समय उदाहरण पर वापस आएँ। पुनर्लेखन उत्पन्न करने से पहले, अनुमोदित दो‑कार्यदिवस शब्दावली और उसके दस्तावेज़ संस्करण को संरक्षित रखें। प्रस्तावित परिवर्तन को एक पहचानकर्ता दें, फिर बाद के संशोधनों और निर्णयों को उससे जोड़ें।

निम्नलिखित एक उदाहरणात्मक डिजाइन है, जिसमें काल्पनिक पहचानकर्ता उपयोग किए गए हैं। यह किसी परीक्षणित उत्पाद या ऐसे स्कीमा का आउटपुट नहीं है जिसे हर दस्तावेज़ उपकरण समर्थन करता हो।

मानव संशोधन द्वारा प्रतिस्थापित होने के बाद भी एआई प्रस्ताव को रखें। यदि रिकॉर्ड केवल अंतिम तीन‑कार्यदिवस शब्दावली को रखता है, तो बाद का समीक्षक उस प्रविष्टि से पहले के सुझाव को पुनः निर्मित नहीं कर पाएगा। अस्वीकृत परिवर्तन इतिहास का हिस्सा होते हैं, भले ही वे प्रकाशित पाठ में न हों।

NIST की जुलाई 2024 की Generative AI Profile प्रोवेनेंस को सामग्री के स्रोत और इतिहास की जानकारी के रूप में वर्णित करती है, जिसमें संशोधन और स्रोत शामिल हैं। यह उद्गम और इतिहास दर्ज करने की प्रक्रियाओं और मानव समीक्षकों के बीच संबंध का मूल्यांकन करने की भी सिफ़ारिश करती है। तालिका इस विचार को दस्तावेज़ कार्यप्रवाह पर लागू करती है; यह NIST प्रमाणन चेकलिस्ट नहीं है।

आप इस रिकॉर्ड को दस्तावेज़ प्रणाली के भीतर या किसी जुड़े रिपॉज़िटरी में रख सकते हैं। किसी भी स्थिति में, जारी संस्करण के साथ संबंध को इतना स्पष्ट बनाएं कि कोई व्यक्ति इसे मूल संपादक की स्मृति पर निर्भर हुए बिना पुनः प्राप्त कर सके।

हैंडऑफ़ के बाद क्या बचता है, जांचें

निर्यातित फ़ाइल की अलग जाँच होनी चाहिए। संपादन के दौरान उपलब्ध इतिहास प्राप्तकर्ता द्वारा निरीक्षण किए जा सकने वाले इतिहास से अलग हो सकता है, यह एप्लिकेशन, फ़ॉर्मेट और निर्यात सेटिंग्स पर निर्भर करता है। यह न मानें कि हर PDF में योगदान का श्रेय दर्शाने वाली जानकारी खो जाती है, या यह कि दृश्यमान टिप्पणियों को संरक्षित करने से हर समीक्षा निर्णय संरक्षित हो जाता है।

Microsoft का वर्तमान Copilot के साथ संपादन के लिए दस्तावेज़ीकरण कहता है कि उसके परिवर्तन Track Changes का सम्मान करते हैं जब यह सुविधा सक्षम हो। यह उपयोगी कार्यक्षमता है। यह यह स्थापित नहीं करता कि आपका पूर्ण अनुमोदन इतिहास हर बाद के रूपांतरण या हैंडऑफ़ में बना रहता है।

अपनी टीम द्वारा वास्तव में उपयोग किए जाने वाले मार्ग का परीक्षण करें। उदाहरण दस्तावेज़ को समीक्षा और निर्यात के माध्यम से ले जाएँ, फिर रखे गए रिकॉर्ड का उपयोग करके स्वीकृत संशोधन और उसके अनुमोदक को पुनः प्राप्त करने का प्रयास करें। यदि जारी फ़ाइल वह इतिहास नहीं ले जा सकती, तो कहीं और एक नियंत्रित रिकॉर्ड रखें और उनके बीच का संबंध संरक्षित रखें।

कम स्पष्ट मामलों को भी ध्यान देना चाहिए। किसी सुझाव का केवल हिस्सा स्वीकार करें और रिकॉर्ड क्या कहता है, इसकी जाँच करें। दो समीक्षक एक ही आधार संस्करण पर काम करें, फिर यह निर्धारित करें कि कौन‑से परिवर्तन जारी फ़ाइल तक पहुँचे। अंत में, अनुमोदन के बाद उस भाग को संपादित करें और सत्यापित करें कि पहले का निर्णय चुपचाप नई शब्दावली की स्वीकृति में नहीं बदल गया है।

प्रदर्शित लेखक नाम को पहचान के लिए उपयोग करने से पहले उसे प्रमाणित खाते से जोड़ा जा सके, ऐसा होना चाहिए। इसी प्रकार, फ़ाइल का हैश मान जारी किए गए आर्टिफैक्ट की पहचान में मदद कर सकता है, लेकिन यह नहीं बता सकता कि प्रतिक्रिया‑समय प्रतिबद्धता सही है या नहीं। ये अलग‑अलग जाँचें हैं, और आपकी समीक्षा प्रक्रिया को इस अंतर को बनाए रखना चाहिए।

रिलीज़ से पहले अनुमोदन सीमा निर्धारित करें

शीर्षक के स्वरूप में बदलाव और ग्राहक के प्रति प्रतिबद्धता में बदलाव के लिए एक जैसे समीक्षा मार्ग अपनाना आवश्यक नहीं है। तय करें कि कौन‑से संपादन स्थापित नीति के तहत आगे बढ़ सकते हैं और कौन‑से को निर्दिष्ट व्यक्ति की स्वीकृति की आवश्यकता है। यह चयन इस बात को दर्शाना चाहिए कि परिवर्तन दस्तावेज़ उपयोग करने वाले लोगों के लिए क्या अर्थ रखता है।

यहाँ स्पष्ट AI निर्णय अधिकार के लिए तर्क व्यावहारिक हो जाता है। हमारे उदाहरण में, किसी को तीन कार्यदिवसों के भीतर प्रतिक्रिया की प्रतिबद्धता को अनुमोदित करने का अधिकार चाहिए। केवल फ़ाइल को संपादित करने की अनुमति को उस अधिकार का प्रमाण नहीं माना जाना चाहिए।

उस समीक्षक को निर्णय लेने के लिए पर्याप्त संदर्भ दें। मूल और प्रस्तावित शब्दावली को किसी भी मध्यस्थ मानव संशोधन के साथ दिखाएँ। अनसुलझे संघर्षों को दृश्यमान बनाएँ, और रिलीज़ के लिए इच्छित संस्करण की पहचान करें। एक समीक्षक जो केवल एक परिष्कृत अंतिम पैराग्राफ देखता है, उसे यह नोटिस करने का कारण नहीं मिल सकता कि प्रतिक्रिया समय बदल गया है।

उपयोगकर्ताओं को कार्यप्रवाह सौंपने से पहले यह तय करें कि रिलीज़ की ज़िम्मेदारी किसकी है। उस व्यक्ति को हर संपादन करने की आवश्यकता नहीं है, लेकिन उसे यह स्थापित करने का तरीका चाहिए कि आवश्यक समीक्षा हुई और वह जारी की जा रही फ़ाइल पर लागू है। असाइनमेंट को अस्पष्ट छोड़ने से दस्तावेज़ तैयार होने पर विवादित परिवर्तन को सुलझाना कठिन हो जाता है।

यह हर गोपनीय प्रॉम्प्ट को अनिश्चितकाल तक रखने की आवश्यकता नहीं रखता। अपने संगठन की पहुँच और प्रतिधारण नीति के तहत निर्णय को समझाने के लिए आवश्यक साक्ष्य रखें। यदि मॉडल‑संस्करण जानकारी उपलब्ध नहीं है, तो सीमा को रिकॉर्ड करें। एक उपयोगी इतिहास को अनुपलब्ध जानकारी को स्पष्ट रूप से दिखाना चाहिए, न कि ऐसे विवरण स्तर का संकेत देना चाहिए जिसे सिस्टम ने कभी दर्ज नहीं किया।

केवल वही संस्करण रिलीज़ करें जिसका आप हिसाब रख सकते हैं

एक महत्वपूर्ण परिवर्तन को रिलीज़ करने से पहले, उसे रिकॉर्ड के माध्यम से ट्रेस करने का प्रयास करें। मूल सुझाव खोजें, यह निर्धारित करें कि मानव संपादक ने क्या बदला, और उस संशोधन को स्वीकार करने के निर्णय को पुनः प्राप्त करें। फिर स्वीकृत संस्करण की तुलना वितरित की जा रही फ़ाइल से करें।

यदि वह कनेक्शन अनुपलब्ध है, तो समीक्षा परिवर्तन को रोकें। केवल यह याद रखना कि दस्तावेज़ “स्वीकृत” था, यह निर्धारित करने के लिए पर्याप्त नहीं है कि उन्होंने कौन‑सी शब्दावली को स्वीकृत किया।

एक संपादक को अपना योगदान समझाने में सक्षम होना चाहिए, बिना इसके कि AI के हर सुझाव को उसी संपादक का योगदान मान लिया जाए। रिलीज़ के ज़िम्मेदार व्यक्ति को यह सटीक रूप से जानना चाहिए कि वे क्या अधिकृत कर रहे हैं। हम लोगों से परिवर्तन के पीछे खड़े होने को नहीं कह सकते जबकि उन्हें यह जांचने का विश्वसनीय तरीका न दें कि वे परिवर्तन कैसे किए गए।