If someone asks you to prove your content is compliant, what do you actually send?
AI Technology

If someone asks you to prove your content is compliant, what do you actually send?

When a client, platform, or regulator asks for proof of AI content compliance, a disclosure label is not enough on its own. This is the evidence pack that actually holds up: a timestamp, a signature, a content hash, and a link anyone can check without contacting you.

S
Swiss Trust Layer Editorial Team· Legal & Compliance
·August 10, 2026· 8 मिनट पढ़ें

कोई सबूत मांगता है। एक क्लाइंट जो सप्लायर प्रश्नावली भर रहा है, एक प्लेटफ़ॉर्म जो शिकायत के बाद आपके अकाउंट की समीक्षा कर रहा है, एक वकील जो केस फ़ाइल तैयार कर रहा है, या एक लाइसेंसिंग पार्टनर जो किसी सामग्री का उपयोग करने से पहले उसकी जांच कर रहा है। अनुरोध अक्सर ढीले शब्दों में आता है, "क्या आप दिखा सकते हैं कि यह सामग्री AI-अनुपालित है", और यह ढीलापन एक वाक्य में दो अलग-अलग सवालों को छुपा देता है।

एक अनुरोध में छिपे दो सवाल

पहला सवाल यह है कि क्या सामग्री को प्रकाशन के समय सही तरीके से लेबल किया गया था। EU AI एक्ट के अनुच्छेद 50, विनियमन (EU) 2024/1689 के तहत, जो 2 अगस्त 2026 से लागू है, एक डिप्लॉयर, यानी जो कोई AI-जनरेटेड या AI-संशोधित सामग्री प्रकाशित करता है, उसे वहां प्रकट करना होगा जहां कोई व्यक्ति उससे रूबरू हो। अनुच्छेद 50 वास्तव में क्या मांगता है, इसकी पूरी व्याख्या बताती है कि यह किसे बाध्य करता है और इसके दायरे में क्या आता है।

दूसरा सवाल यह है कि क्या आप बाद में उस डिस्क्लोज़र को साबित कर सकते हैं। एक लेबल केवल यह बताता है कि आप क्या दावा करते हैं। अकेले यह नहीं दिखाता कि वास्तव में क्या हुआ, कौन शामिल था, या कब हुआ। यह एक रिकॉर्ड है, और रिकॉर्ड एक लेबल से अलग चीज़ है: अलग समय पर बनाया गया, अलग तरीके से रखा गया, और आपसे अलग किसी के द्वारा सत्यापित। और यही वह चीज़ है जो असल में मांगी जाती है, जैसे ही सवाल "क्या आपने इसे लेबल किया" से बदलकर "इसे साबित करो" हो जाता है।

अकेले लेबल क्यों पर्याप्त नहीं है

एक लेबल आपके अपने पेज पर, आपके अपने CMS में रहता है, जिसे आपकी अपनी टीम किसी भी समय बदल सकती है। इसके उद्देश्य के लिए यह बिल्कुल सही है: पाठक को, जिस पल वह सामग्री से रूबरू होता है, यह बताना कि इसे AI से बनाया या बदला गया है। लेकिन जैसे ही कोई इसे सबूत के रूप में लेता है, यह पर्याप्त नहीं रह जाता, क्योंकि जिस पक्ष से लेबल पर भरोसा करने को कहा जा रहा है, वह वही पक्ष है जिसने इसे लिखा।

सप्लायर प्रश्नावलियां, संविदा विवाद, और प्लेटफ़ॉर्म समीक्षाएं अलग-अलग शब्दों में आती हैं लेकिन आख़िर में एक ही मूल सवाल पर पहुंचती हैं: क्या आपके संगठन के बाहर कोई व्यक्ति आपकी बात मान लिए बिना और आपके सिस्टम तक पहुंच की ज़रूरत के बिना इसकी पुष्टि कर सकता है। आपके CMS का स्क्रीनशॉट इसका जवाब नहीं देता। न ही आपकी प्रक्रिया समझाता एक ईमेल थ्रेड, और न ही किसी फ़ाइल की "अंतिम संशोधन" तारीख, जो हर बार खुलने पर बदल जाती है, संपादन की तो बात ही छोड़िए।

सवाल पूछे जाने से पहले असल में क्या मौजूद होना चाहिए

दूसरी नज़र में भी टिकने वाले प्रमाण-पैकेज के चार हिस्से होते हैं। इनमें से कोई भी अनुच्छेद 50 के डिस्क्लोज़र की जगह नहीं लेता; ये उसके नीचे बैठते हैं और उसे टिकने का आधार देते हैं।

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

सटीक फ़ाइल पर एक क्वालिफ़ाइड टाइमस्टैंप। RFC 3161 मानक के अनुसार बना, और ZertES या eIDAS के अंतर्गत एक क्वालिफ़ाइड ट्रस्ट सर्विस द्वारा जारी टाइमस्टैंप, यह साबित करता है कि एक विशिष्ट फ़ाइल, बाइट दर बाइट, ठीक उसी रूप में एक निश्चित क्षण पर मौजूद थी। बाद में एक भी अक्षर बदल दें और टाइमस्टैंप फ़ाइल से मेल खाना बंद कर देता है। यह "अंतिम संशोधन" वाली समस्या हल कर देता है: तारीख गणितीय रूप से सामग्री से ही जुड़ी होती है, न कि फ़ाइल-सिस्टम के किसी ऐसे फ़ील्ड से जिसे संपादन-अधिकार रखने वाला कोई भी बदल सकता है या जो फ़ाइल खुलते ही रीसेट हो जाती है।

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

सार्वजनिक रूप से पंजीकृत कंटेंट हैश, फ़ाइल सौंपे बिना। स्वयं सामग्री का एक ISCC हैश एक सार्वजनिक, खोजने योग्य डेटाबेस में दर्ज होता है। यह मूल फ़ाइल को उजागर नहीं करता, केवल उससे निकाला गया एक फ़िंगरप्रिंट देता है। यह सामग्री को स्वयं, न कि केवल आपकी किसी विशेष प्रति की अभिरक्षा को, कुछ ऐसा देता है जिसे कोई लाइसेंसिंग संस्था, कोई प्लेटफ़ॉर्म, या यह जांच कि कोई टेक्स्ट या इमेज कहीं ऐसी जगह तो नहीं आ गई जहां नहीं आनी चाहिए थी, बाद में बिना पहले आपसे संपर्क किए मिला सके। यही वह हिस्सा है जिसे अकेले टाइमस्टैंप और हस्ताक्षर कवर नहीं करते: सामग्री की अपनी ट्रेसेबिलिटी, चाहे मूल फ़ाइल किसी के भी पास हो।

व्यवहार में आप असल में क्या भेजते हैं

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

इसकी तुलना अनुपालन अनुरोध के सामान्य जवाब से करें: Slack बातचीत का PDF एक्सपोर्ट, Google Doc की वर्ज़न हिस्ट्री का स्क्रीनशॉट, या एक ईमेल में एक पैराग्राफ जो बताता है कि टीम "हमेशा AI उपयोग प्रकट करती है"। इनमें से हर एक आंतरिक रहता है, संपादन-योग्य रहता है, और पूरी तरह इस पर निर्भर करता है कि प्राप्तकर्ता आपके सिस्टम और आपकी नीयत पर भरोसा करे। एक सत्यापन लिंक में इनमें से कोई भी कमी नहीं होती, और यही वह ठोस कारण है कि रिकॉर्ड को प्रकाशन के समय ही बनाया जाए, न कि अनुरोध आने के बाद जोड़-तोड़ कर तैयार किया जाए।

असल में कौन पूछता है, और कब

शायद ही कभी कोई नियामक सबसे पहले दस्तक देता है। ज़्यादातर यह किसी क्लाइंट की खरीद टीम होती है जो नियमित सप्लायर जांच कर रही होती है, या संविदा विवाद में कोई प्रतिपक्ष जो रिकॉर्ड इकट्ठा कर रहा होता है, या कोई प्लेटफ़ॉर्म जो शिकायत का जवाब दे रहा होता है, या कोई लाइसेंसिंग पार्टनर जिसे किसी सामग्री का उपयोग करने से पहले उसकी उत्पत्ति जाननी होती है। इनमें से कोई भी स्थिति ज़्यादा पहले से चेतावनी नहीं देती, और कोई भी तब तक इंतज़ार नहीं करती जब तक आप मूल फ़ाइल या उसे आठ महीने पहले लिखने वाले व्यक्ति को ढूंढ रहे होते हैं।

असल में आपको इसमें से कितना चाहिए

हर सामग्री को अपने पीछे पूरे प्रमाण-पैकेज की ज़रूरत नहीं होती। एक सोशल मीडिया कैप्शन जो एक दिन में फ़ीड एल्गोरिदम से गायब हो जाता है, अगर उसे कभी कोई चुनौती न दे तो व्यावहारिक जोखिम बहुत कम रखता है। यह पैकेज सबसे ज़्यादा उस हर चीज़ के लिए मायने रखता है जो संभावित रूप से किसी क्लाइंट की कानूनी टीम, किसी नियामक, या किसी अदालत के सामने पहुंच सकती है: भुगतान किए गए डिलिवरेबल्स, कोई भी ऐसी चीज़ जो सक्रिय डिस्क्लोज़र दायित्व वाले बाज़ार में प्रकाशित होती है, और कोई भी ऐसा दावा जिसे कोई महीनों बाद चुनौती दे सकता है।

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

याद रखने लायक संक्षिप्त संस्करण

जो कोई आपसे किसी सामग्री का अनुपालन साबित करने को कहता है, वह असल में चार छोटे सवाल पूछ रहा होता है: क्या प्रकाशित हुआ, किसने प्रकाशित किया, कब, और क्या मैं आपसे संपर्क किए बिना खुद इसकी जांच कर सकता हूं। एक डिस्क्लोज़र लेबल पहले सवाल का जवाब देता है, और वह भी तभी जब इसे पढ़ने वाला व्यक्ति पहले से आप पर भरोसा करता हो। एक क्वालिफ़ाइड टाइमस्टैंप "कब" का जवाब देता है। एक क्वालिफ़ाइड हस्ताक्षर "किसने" का जवाब देता है। एक पंजीकृत कंटेंट हैश "क्या" का जवाब देता है, ऐसे रूप में जो तब भी टिका रहता है जब मूल फ़ाइल कभी किसी के साथ साझा न की जाए। वह रिकॉर्ड भेजें जो चारों का जवाब दे। लेबल को दोहराना पांचवां जवाब नहीं है, यह वही जवाब दोबारा है।

Swiss Trust Layer AG के साथ अपने काम की रक्षा करें

Swisscom Trust Services द्वारा समर्थित न्यायालय-प्रमाणित e-Seal के साथ अपनी बौद्धिक संपदा को सील करें।

मुफ्त डेमो बुक करें

Related Articles

Week in review: Article 50, copyright proof, and what changed
AI & Technology

Week in review: Article 50, copyright proof, and what changed

Article 50 took effect on 2 August. A week of writing about it comes down to one idea: the rule asks you to make a statement, and a statement is only as good as what you can produce when somebody asks you to back it up.

August 8, 2026Read more →
The four AI labels every EU publisher needs, and what each one means
AI & Technology

The four AI labels every EU publisher needs, and what each one means

AI generated, AI modified, AI assisted, human authored. Four statements cover almost everything a publishing team produces. This is what separates them, how to decide in under a minute, and why an inaccurate label is a worse position than a missing one.

August 4, 2026Read more →
A checkbox is not proof: labelling versus evidence under the AI Act
AI & Technology

A checkbox is not proof: labelling versus evidence under the AI Act

A label and a record look identical on a page and behave completely differently the moment somebody questions them. This is what separates a self-declaration from evidence, why the usual internal records do not close the gap, and what a qualified timestamp changes.

August 3, 2026Read more →
Article 50 is live today. Here is how to prove your content is compliant.
AI & Technology

Article 50 is live today. Here is how to prove your content is compliant.

The transparency obligations in Article 50 of the EU AI Act apply from today. This is what the obligation actually requires, why a label alone leaves the burden of proof with the publisher, and the four parts of a record that somebody outside your organisation can check.

August 2, 2026Read more →
What EU AI Act Article 50 actually asks you to do, in plain terms
AI & Technology

What EU AI Act Article 50 actually asks you to do, in plain terms

Article 50 of the EU AI Act applies from 2 August 2026. This is a plain reading of what it asks for: who it binds, what content is in scope, what labelling actually means in practice, and the three questions worth settling before Monday morning.

August 1, 2026Read more →