ईयू एआई ओम्निबस ने अहम बदलाव किए, लेकिन अनुपालन के लिए अभी भी वर्ज़न कंट्रोल की ज़रूरत है
मुख्य बातें
- प्रत्येक ओम्निबस-निर्भर धारणा के लिए मालिकों के साथ AI Act ट्रैकर्स को संस्करणबद्ध रखें।
- प्रस्तावित राहत को तब तक अस्थायी मानें जब तक अंतिम पाठ और मार्गदर्शन इसकी पुष्टि न कर दें।
- वर्गीकरण संबंधी निर्णयों का दस्तावेज़ीकरण करें, भले ही प्रशासनिक दायित्व कम होते दिखाई दें।
सरलीकरण प्रशासनिक काम को कम कर सकता है, लेकिन AI Act योजनाओं में फिर भी मालिक, धारणाएँ और ऑडिट ट्रेल्स ज़रूरी होते हैं।
सरलीकरण प्रशासनिक काम को कम कर सकता है, लेकिन AI Act योजनाओं में फिर भी ज़िम्मेदार व्यक्ति, मान्यताएँ और ऑडिट ट्रेल्स होने चाहिए।
ऑम्निबस सुनने में ऐसा लगता है जैसे किसी ने फाइलिंग कैबिनेट को करीने से जमा दिया हो। अनुपालन टीमों को इस आवाज़ पर शालीनता से संदेह करना चाहिए। EU AI Omnibus कुछ प्रशासनिक झंझट कम कर सकता है, लेकिन यह शासन की सबसे पुरानी समस्या भी पैदा करता है: आपके ट्रैकर में मौजूद नियम शायद वही नियम न हो जो बातचीत के बाद बचा रहे। अनुपालन कैलेंडर कोई नीति-स्थिति नहीं है; यह समय-सीमाओं के साथ जुड़ा एक बदलाव लॉग है।
पैकेज व्यापक है, और यही पहली जटिलता है
PwC का कहना है कि यूरोपीय आयोग ने 19 नवंबर, 2025 को Digital Omnibus प्रकाशित किया, इसे AI नियामकीय राहत के रूप में पेश किया, जबकि कई प्रश्न अनसुलझे रहे। Morrison Foerster इस पैकेज को 2029 तक AI Act, Data Act, GDPR, ePrivacy Directive और साइबर सुरक्षा कानूनों में सभी व्यवसायों के लिए प्रशासनिक बोझ कम से कम 25% और छोटे व मध्यम उद्यमों के लिए कम से कम 35% घटाने के प्रयास के रूप में वर्णित करता है। Bruegel भी 19 नवंबर को जारी दो मसौदा कानूनों का वर्णन करता है, जो कई EU कानूनों में संशोधन करेंगे, जिनका घोषित लक्ष्य सरलीकरण और सुव्यवस्थित करना है। यह उपयोगी संदर्भ है, लेकिन यह जानने का विकल्प नहीं है कि आप कौन-से AI सिस्टम चलाते हैं, हर सिस्टम किस कानूनी श्रेणी में आता है, और कौन-सी साक्ष्य फाइल यह बात साबित करती है।
व्यापकता इसलिए मायने रखती है क्योंकि कई कानूनों में सरलीकरण दायित्वों को हटाने के बजाय उन्हें बगल में खिसका सकता है। किसी एक फाइल में संरेखित परिभाषा फिर भी उत्पाद टीम से डेटा मैप, खरीद अनुबंध की धारा, या मॉडल वर्गीकरण रिकॉर्ड अपडेट करने की मांग कर सकती है। बिल्डरों के लिए सीख थोड़ी नीरस लेकिन व्यावहारिक है: जब तक लागू होने वाला पाठ इसका समर्थन न करे, किसी नीति उद्देश्य को उत्पाद आवश्यकता में न बदलें। दूसरे शब्दों में, कम फॉर्म का मतलब कम कर्तव्य नहीं होता।
प्रस्तावित राहत को assumptions कॉलम में रखना चाहिए
Morrison Foerster का दिसंबर 2025 क्लाइंट अलर्ट इस बात का उपयोगी उदाहरण है कि कार्यान्वयन योजनाओं को version control की जरूरत क्यों होती है। इसमें AI Act के Article 6(3) के तहत high risk classification से छूट प्राप्त AI सिस्टमों के प्रदाताओं के लिए EU database registration requirement को हटाने के प्रस्ताव का वर्णन किया गया, जिसमें केवल तैयारी संबंधी कार्यों के लिए उपयोग किए जाने वाले सिस्टम भी शामिल हैं। यह ठीक वैसा वाक्य है जो टीमों को बहुत जल्दी कोई workflow हटाने के लिए लुभाता है। इसे assumptions log में तब तक रहना चाहिए जब तक अंतिम पाठ, मार्गदर्शन और संगठन की कानूनी व्याख्या सभी एक ही दिशा में संकेत न करें। CCIA के मई 2026 के sealed AI Omnibus deal के विवरण ने परिणाम को ऐसे रूप में प्रस्तुत किया जिसमें EU वार्ताकारों ने अवसर खो दिए, जो हर प्रस्ताव को मिली हुई राहत मानने के विरुद्ध चेतावनी है। सरल संचालन नियम यह है: classification memo रखें, use case description रखें, और वह trigger रखें जो legal को बताता है कि कब कोई तैयारी वाला tool कुछ अधिक महत्वपूर्ण बन गया है। यदि registration duty बदलती है, तब भी evidence file यह समझाती है कि सिस्टम का आकलन उस तरह क्यों किया गया था। नियामक आमतौर पर vibes के बजाय records पसंद करते हैं, और इस आदत को योजना में शामिल करना समझदारी है।
Version control ही अनुपालन योजना है, paperwork theater नहीं
Tech Policy Press रिपोर्ट करता है कि EU विधायकों ने 7 मई, 2026 को सुबह 4:30 बजे AI Omnibus पर सहमति हासिल की, जिससे कड़े समय-सारणी के तहत हुई छह महीने की बातचीत प्रक्रिया का सबसे कठिन चरण पूरा हुआ। वही रिपोर्ट कहती है कि प्रक्रिया का लक्ष्य मूल 2 अगस्त, 2026 की समय-सीमा से पहले खत्म करना था। यह समय-निर्धारण operational risk समझाता है: टीमों के पास योजनाएँ अपडेट करने के लिए पर्याप्त संकेत हैं, लेकिन उन्हें freeze करने के लिए पर्याप्त अंतिमता नहीं है। सही प्रतिक्रिया wait and see pause नहीं है; यह managed branch है। उत्पाद और governance टीमों के लिए इसका मतलब है कि प्रत्येक AI Act obligation के साथ status, source, date और owner होना चाहिए। एक कॉलम उन obligations को चिह्नित करे जो वर्तमान में लागू AI Act के तहत स्थिर हैं। दूसरा कॉलम Omnibus dependent assumptions को चिह्नित करे, स्रोत के लिंक और उस condition के साथ जो उत्तर बदल देगी। तीसरा कॉलम प्रभावित business control की पहचान करे, जैसे inventory, classification, registration, transparency notice, vendor review, या audit evidence।
बची हुई अनिश्चितता ही वह जगह है जहाँ builder अटकते हैं
Bruegel का तर्क है कि Commission के digital और AI omnibus प्रस्ताव regulatory compliance costs कम करके EU productivity growth को तेज करने के दबाव का जवाब देते हैं, लेकिन यह भी कहता है कि योजनाएँ नई असंगतियाँ पैदा करती हैं और transformative reform से कम रह जाती हैं। यही हिस्सा builder सबसे पहले अनुभव करते हैं। कोई startup राजनीतिक महत्वाकांक्षा का अनुपालन नहीं करता; वह text, guidance, supervisory practice और customer due diligence questionnaires का अनुपालन करता है। जब ये परतें असहमत होती हैं, तो सबसे सुरक्षित सिस्टम वह है जो दर्ज करता है कि कल का उत्तर क्यों बदला। इसलिए PwC की framing, regulatory relief with questions remaining, headline से कम और implementation instruction से अधिक है। AI Act टीमों को अभी inventories अपडेट करनी चाहिए, assumptions को स्पष्ट रूप से चिह्नित करना चाहिए, और केवल इसलिए controls नहीं हटाने चाहिए कि किसी proposal ने कभी relief का सुझाव दिया था। अंतिम पाठ, supervisory guidance और sector specific interpretations पर नजर रखें, खासकर जहाँ AI governance privacy, cybersecurity और data access rules से overlap करता है। सरलीकरण अभी भी मदद कर सकता है, लेकिन audit के दौरान केवल वही version मदद करेगा जिसका आप evidence दे सकते हैं।
