SaaS करारातील डेटाची मालकी: डच कायद्यानुसार तुमच्या डेटाची मालकी कोणाकडे आहे?

डच आणि युरोपियन युनियनच्या कायद्यानुसार, डेटावर कोणाचीही मालकी नसते, त्यामुळे तुम्ही क्लाउड प्लॅटफॉर्मवर ठेवलेली माहिती कोण वापरू शकते, कॉपी करू शकते, निर्यात करू शकते आणि हटवू शकते, हे कायदा नव्हे, तर तुमच्या SaaS करारातील डेटा कलम ठरवते. डच नागरी संहितेच्या (Burgerlijk Wetboek, BW) कलम ३:२ नुसार ' झाक ' (zaak) म्हणजे मानवी नियंत्रणास सक्षम असलेली एक मूर्त वस्तू, आणि डेटा सेट ही मूर्त वस्तू नाही. ग्राहकाकडे प्रत्यक्षात करारात्मक हक्कांचा एक संच असतो, जो काही ठिकाणी कॉपीराइट, डेटाबेस हक्क, व्यापार गुपित संरक्षण आणि GDPR द्वारे अधिक मजबूत केलेला असतो. त्यामुळे, अस्पष्ट शब्दरचना प्रश्न अनुत्तरित ठेवत नाही: ती तो प्रश्न सेवा पुरवठादाराच्या बाजूने निकाली काढते.

SaaS करारातील डेटाची मालकी हा मालमत्तेचा प्रश्न नसून, कराराचा प्रश्न का आहे?

डच मालमत्ता कायदा 'गोएडेरेन' (goederen ) म्हणजे मूर्त वस्तू आणि मालमत्ता हक्क या संकल्पनांवर काम करतो (कलम ३:१ बी.डब्ल्यू.). डेटा या दोन्हीपैकी कोणत्याही श्रेणीत येत नाही. तुम्ही सर्व्हर किंवा मशीनप्रमाणे डेटा सुपूर्द करू शकत नाही, गहाण ठेवू शकत नाही किंवा परत मिळवू शकत नाही. ही अशी उणीव नाही जी न्यायालयांनी गुपचूप भरून काढली आहे; तर हे अशा प्रणालीचे एक हेतुपुरस्सर वैशिष्ट्य आहे, ज्यात एखादा विशिष्ट नियम प्रतिबंधित करत नाही तोपर्यंत माहिती मुक्तपणे प्रसारित होते. याचा व्यावहारिक परिणाम स्पष्ट आहे. जर तुमच्या करारामध्ये तुमच्या डेटाबद्दल काहीही उपयुक्त माहिती नसेल, तर तुमच्याकडे माघार घेण्यासाठी कोणताही पर्यायी मार्ग उरत नाही.

चार कायदे माहितीला काही प्रमाणात संरक्षण देतात आणि तुमची माहिती प्रत्यक्षात त्यापैकी कोणत्या कायद्यांतर्गत येते हे जाणून घेणे महत्त्वाचे आहे. तुम्ही प्लॅटफॉर्मवर अपलोड केलेला किंवा तयार केलेला मूळ मजकूर, प्रतिमा, रेखाचित्रे आणि सॉफ्टवेअर यांना 'ऑटर्सवेट' (Auteurswet) कायद्यांतर्गत कॉपीराइट मिळतो, जो कायद्यानुसार आपोआप तुमचा होतो आणि केवळ त्यांच्या सर्व्हरवर होस्ट केल्यामुळे तो प्रदात्याकडे हस्तांतरित होत नाही. एखाद्या संरचित संग्रहाला 'डेटाबँकेनवेट' (Databankenwet) कायद्यांतर्गत 'सुई जेनेरिस' (sui generis) डेटाबेस अधिकार मिळू शकतो, जिथे तुम्ही त्याची सामग्री मिळवण्यासाठी, सत्यापित करण्यासाठी किंवा सादर करण्यासाठी भरीव गुंतवणूक केलेली असते. तथापि, प्रस्थापित युरोपियन न्यायनिर्णयांनुसार, मूळ डेटा तयार करण्यासाठी केलेली गुंतवणूक त्या मर्यादेत गणली जात नाही. व्यावसायिक मूल्य असलेली गोपनीय व्यावसायिक माहिती, जी गुप्त ठेवण्यासाठी वाजवी उपाययोजनांद्वारे संरक्षित आहे, ती 'वेट बेस्चेर्मिंग बेड्रिज्स्गेहेमेन' (Wet bescherming bedrijfsgeheimen) कायद्यांतर्गत येते, जो युरोपियन युनियनच्या 'ट्रेड सिक्रेट्स डायरेक्टिव्ह'ची डच अंमलबजावणी आहे. आणि वैयक्तिक माहिती 'जीडीपीआर' (GDPR) द्वारे नियंत्रित केली जाते, जो तुमच्या कंपनीऐवजी संबंधित व्यक्तींना अधिकार प्रदान करतो.

त्या चार श्रेणींच्या बाहेरील सर्व काही, जे बहुतेक SaaS डिप्लॉयमेंटमध्ये बहुतांश असते, ते पूर्णपणे कराराच्या अंतर्गत येते. ट्रान्झॅक्शन लॉग, टेलिमेट्री, कॉन्फिगरेशन सेटिंग्ज, वापराच्या पद्धती, सेन्सर रीडिंग्ज आणि त्यांच्यावर आधारित ॲनालिटिक्स हे केवळ तुमच्या करारानुसार संरक्षित असतात. एखादे कलम वाचण्यापूर्वी समजून घेण्याची ही सर्वात महत्त्वाची गोष्ट आहे.

कलम अस्पष्ट असल्यास काय चुकते?

डेटा कलमातील संदिग्धता क्वचितच अपघाती असते आणि त्यामुळे काही ठराविक समस्या निर्माण होतात. पहिली समस्या म्हणजे 'लॉक-इन': असा करार ज्यात कोणताही निर्यात फॉरमॅट, कोणतेही वेळापत्रक किंवा किंमतीची कमाल मर्यादा दिलेली नसते, तो प्रकल्प सोडणे हा एक निर्णय न राहता एक सामान्य बाब बनतो. दुसरी समस्या म्हणजे सेवा पुरवठादाराच्या परवान्यातील व्याप्तीचा विस्तार, जिथे सेवा देण्याच्या उद्देशाने दिलेला अधिकार नकळतपणे उत्पादन विकास आणि व्यावसायिक वापरापर्यंत विस्तारतो. तिसरी समस्या म्हणजे अनुपालनातील त्रुटी, कारण GDPR नुसार नियंत्रकाला हे माहित असणे बंधनकारक आहे की वैयक्तिक डेटावर कुठे आणि कोणाद्वारे प्रक्रिया केली जाते, आणि जो करार या प्रश्नांची उत्तरे देत नाही, तो उत्तरदायित्वाच्या तत्त्वाचे पालन करणे अशक्य करतो. चौथी समस्या म्हणजे तुमच्या अटींऐवजी सेवा पुरवठादाराच्या अटींनुसार डेटा हटवला जाणे, ज्यात तुमचे स्थलांतर पूर्ण होण्यापूर्वीच संग्रह (आर्काइव्ह) पुसून टाकला जातो.

यापैकी काहीही असामान्य नाही. बहुतेक तयार सेवा अटींमध्ये हीच मानक बाब असते, आणि याच कारणामुळे क्लाउड कराराची तपासणी भाडेपट्टा किंवा वितरण करारासारखीच केली पाहिजे. नेदरलँड्समधील क्लाउड करारामध्ये काय तपासावे याचा आमचा आढावा , डेटा कलम ज्या व्यापक व्यावसायिक चौकटीत बसते, ती स्पष्ट करतो.

डेटा क्लॉजमध्ये काय म्हटले पाहिजे

एक व्यवहार्य डेटा कलम तीन गोष्टी करते: ग्राहक डेटा म्हणून काय गणले जाते हे ते स्पष्ट करते, त्या डेटामधील सर्व हक्क ग्राहकाकडेच राहतील असे ते नमूद करते, आणि ते प्रदात्याच्या परवान्याची व्याख्या त्याच्या व्याप्तीऐवजी उद्देशानुसार करते. उद्देशावरील मर्यादा हाच सर्वात महत्त्वाचा भाग आहे. सेवा चालवण्यासाठी प्रदात्याला तुमचा डेटा होस्ट करणे, त्यावर प्रक्रिया करणे, तो प्रसारित करणे आणि प्रदर्शित करणे खरोखरच आवश्यक असते, आणि कोणताही सुज्ञ ग्राहक याला आक्षेप घेत नाही. ग्राहकाने अशा परवान्याला आक्षेप घ्यावा जो करार संपुष्टात आल्यानंतरही लागू राहतो, उप-परवान्यापर्यंत विस्तारित होतो, किंवा प्रदात्याला उपयुक्त वाटणाऱ्या कोणत्याही उद्देशासाठी वापराचा समावेश करतो.

पहिल्या वाचनात सारख्या दिसणाऱ्या दोन रचनांची तुलना करा. ग्राहक डेटा वापरण्याचा, पुनरुत्पादित करण्याचा, सुधारित करण्याचा आणि वितरित करण्याचा परवाना , जो कायमस्वरूपी आणि अपरिवर्तनीयपणे दिला जातो, तो सेवा पुरवठादाराला तुमच्या माहितीवर उत्पादने तयार करण्याचा आणि तुम्ही निघून गेल्यानंतरही ते करत राहण्याचा अधिकार देतो. या कराराअंतर्गत सेवा प्रदान करण्याच्या एकमेव उद्देशाने ग्राहक डेटा ऍक्सेस करण्याचा आणि त्यावर प्रक्रिया करण्याचा परवाना , जो करार संपल्यावर समाप्त होतो, तो मात्र तसा अधिकार देत नाही. फरक केवळ काही शब्दांचा आहे आणि तो ठरवतो की तुमचा ऑपरेशनल डेटा तुमची मालमत्ता आहे की त्यांचा कच्चा माल.

आणखी दोन मुद्दे नेहमीच दुर्लक्षित केले जातात. ग्राहक डेटाची व्याख्या करताना, त्यात केवळ तुम्ही अपलोड केलेल्या सामग्रीचाच नव्हे, तर तुमच्या कर्मचाऱ्यांनी प्लॅटफॉर्मवर तयार केलेल्या सामग्रीचाही समावेश करा, कारण तिकीट, टिप्पण्या, कार्यप्रवाह संरचना आणि भाष्ये ही अनेकदा प्रणालीवरील सर्वात मौल्यवान सामग्री असते. आणि प्राप्त व एकत्रित डेटाचा स्पष्टपणे उल्लेख करा, कारण केवळ ग्राहक डेटाचा समावेश असलेले कलम , सेवा पुरवठादाराने त्यातून गणना केलेल्या सर्व गोष्टींना तुमच्या संरक्षणाबाहेर ठेवते.

डच करार कायद्याच्या मानक अटी आणि मर्यादा

बहुतेक SaaS करार प्रदात्याच्या सामान्य अटी आणि शर्तींवर केले जातात, ज्यामुळे BW कलम ६:२३१ ते ६:२४७ लागू होतात. येथे दोन नियम महत्त्वाचे आहेत. BW कलम ६:२३४ नुसार, प्रदात्याने करार होण्यापूर्वी किंवा करार होताना अटी उपलब्ध करून दिल्या पाहिजेत, आणि इलेक्ट्रॉनिक पद्धतीने केलेल्या करारांसाठी त्या अशा स्वरूपात पुरवल्या पाहिजेत की ग्राहक त्या साठवून ठेवू शकेल आणि त्यांची पुनरावृत्ती करू शकेल; नंतर बदलणारी केवळ एक लिंक पुरेशी नाही. BW कलम ६:२३३(अ) नुसार, जर सर्व परिस्थितींचा विचार करता, एखादी अट दुसऱ्या पक्षासाठी अवाजवीपणे जाचक असेल, तर ती रद्द करण्यायोग्य ठरते.

तो दुसरा मार्ग व्यवसायांच्या अपेक्षेपेक्षा अधिक मर्यादित आहे. कलम ६:२३५ बीडब्ल्यू (BW) नुसार, जर प्रतिपक्ष कलम २:३६० बीडब्ल्यूच्या अर्थाअंतर्गत एक कायदेशीर संस्था असेल जिने आपले सर्वात अलीकडील वार्षिक हिशेब प्रकाशित केले असतील, किंवा करार झाला त्या वेळी तिच्याकडे पन्नास किंवा अधिक कर्मचारी असतील, तर तिला कलम ६:२३३ आणि ६:२३४ वर अवलंबून राहण्यास मनाई आहे. त्यामुळे, मोठ्या डच कंपन्या करार झाल्यानंतर कठोर डेटा कलमातून युक्तिवाद करून सुटका करून घेऊ शकत नाहीत. तसेच, जो पक्ष स्वतः नेहमी त्याच किंवा जवळपास त्याच मानक अटी वापरतो, त्यालाही हे शक्य नाही. बहुतेक प्रस्थापित व्यवसायांसाठी, स्वाक्षरीपूर्वीची वाटाघाटी हीच एकमेव खरी संधी असते.

जेथे मानक अटी कोणताही दिलासा देत नाहीत, तेथे कलम ६:२४८(२) बीडब्ल्यू (BW) कायम राहते: करारातून उद्भवणारा नियम तेव्हा लागू होत नाही, जेव्हा दिलेल्या परिस्थितीत, तो लागू करणे वाजवीपणा आणि निष्पक्षतेच्या मानकांनुसार अस्वीकार्य असेल. डच न्यायालये व्यावसायिक संबंधांमध्ये ही चाचणी मर्यादित स्वरूपात लागू करतात, आणि जेव्हा पुरवठादाराने हेतुपुरस्सर किंवा जाणीवपूर्वक केलेल्या निष्काळजीपणामुळे नुकसान केले असेल, तेव्हा ती वापरण्यास ते लक्षणीयरीत्या अधिक इच्छुक असतात. हा एक सुरक्षा झडप आहे, वाटाघाटीची रणनीती नाही.

परदेशी कायदा आणि मंच कलमे

अनेक SaaS करार सेवा पुरवठादाराच्या मूळ अधिकारक्षेत्रातील कायदा आणि न्यायालये निवडतात. रोम I रेग्युलेशननुसार, व्यवसाया-व्यवसायासाठी कायद्याची निवड सामान्यतः वैध आहे, आणि ब्रसेल्स I बिस रेग्युलेशननुसार युरोपियन युनियनमधील न्यायालयाची निवड देखील वैध आहे. या निवडीमुळे GDPR बंद होत नाही, जो युरोपियन युनियनमधील आस्थापनेच्या संदर्भात प्रक्रिया करण्यावर आणि युरोपियन युनियनमधील लोकांना सेवा देण्यावर लागू होतो; किंवा डेटा कायद्याचे स्विचिंग नियमही बंद होत नाहीत, जे युरोपियन युनियनमधील ग्राहकांना डेटा प्रक्रिया सेवा देणाऱ्या सेवा पुरवठादारांना, तो कोठेही स्थापित असला तरी, बंधनकारक ठरतात. GDPR ऐवजी सेवा पुरवठादाराच्या देशांतर्गत गोपनीयता कायद्याचे पालन करण्याचे वचन देणारे कलम हा एक दोष आहे, तपशील नाही.

तुमचा डेटा परत मिळवणे: युरोपियन युनियन डेटा कायद्यानुसार आता काय आवश्यक आहे

१२ सप्टेंबर २०२५ पासून डेटा कायदा (नियम (ईयू) २०२३/२८५४) लागू झाला आहे, आणि त्यातील डेटा प्रोसेसिंग सेवांमध्ये बदल करण्यासंबंधीच्या अध्यायात SaaS तसेच पायाभूत सुविधा आणि प्लॅटफॉर्म सेवांचा समावेश आहे. यामुळे, पूर्वी केवळ वाटाघाटींवर अवलंबून असलेले अनेक मुद्दे वैधानिक किमान हक्कांमध्ये रूपांतरित झाले आहेत, आणि हे प्रदात्याच्या मानक अटींमध्ये काय म्हटले आहे याचा विचार न करता केले जाते. क्लाउड कॉन्ट्रॅक्टिंगमधील गेल्या अनेक वर्षांतील हा सर्वात महत्त्वपूर्ण बदल आहे, आणि त्या तारखेपूर्वी स्वाक्षरी केलेल्या अनेक करारांमध्ये हे बदल प्रतिबिंबित करण्यासाठी सुधारणा करण्यात आलेली नाही.

मुख्य जबाबदाऱ्या खालीलप्रमाणे आहेत. पुरवठादाराने करार, तांत्रिक, व्यावसायिक आणि संघटनात्मक अडथळे दूर केले पाहिजेत, जे ग्राहकाला करार रद्द करण्यापासून आणि दुसऱ्या पुरवठादाराकडे किंवा स्वतःच्या ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चरकडे जाण्यापासून रोखतात. स्विचिंग प्रक्रिया सुरू होण्यापूर्वी पुरवठादार जास्तीत जास्त दोन महिन्यांची सूचना देऊ शकतो. अनिवार्य संक्रमणकालीन कालावधी, ज्या दरम्यान पुरवठादाराने स्थलांतरासाठी समर्थन देणे सुरू ठेवले पाहिजे, तो तीस कॅलेंडर दिवसांचा आहे. जर या कालावधीत स्विच करणे तांत्रिकदृष्ट्या अव्यवहार्य असेल, तर हा कालावधी जास्तीत जास्त सात महिन्यांपर्यंत वाढवता येतो. संक्रमणकालीन कालावधी संपल्यानंतर, निर्यात करण्यायोग्य डेटा आणि डिजिटल मालमत्ता हटवण्यापूर्वी ग्राहकाला किमान तीस दिवसांचा डेटा पुनर्प्राप्ती कालावधी मिळाला पाहिजे. पुरवठादाराने ओपन इंटरफेस उपलब्ध करून दिले पाहिजेत आणि संरचित, सामान्यतः वापरल्या जाणाऱ्या, मशीन-वाचनीय फॉरमॅटमध्ये निर्यात केली पाहिजे.

एका निश्चित वेळापत्रकानुसार शुल्क टप्प्याटप्प्याने रद्द केले जात आहेत. १२ जानेवारी २०२७ पर्यंत चालणाऱ्या संक्रमण काळात, एखादा प्रदाता केवळ स्विचशी संबंधित त्याला प्रत्यक्ष आलेला खर्चच वसूल करू शकतो, ज्यामुळे बाहेर पडण्याचा दंड म्हणून वापरल्या जाणाऱ्या निर्गमन शुल्कावर आधीच बंदी घालण्यात आली आहे. १२ जानेवारी २०२७ पासून स्विचिंग शुल्क पूर्णपणे नाहीसे होतील: एखादा प्रदाता स्विच सुलभ करण्यासाठी आवश्यक असलेल्या कार्यांसाठी, किंवा त्याच्या परिसराबाहेर डेटा ट्रान्झिटसाठी शुल्क आकारू शकणार नाही.

याचे तीन व्यावहारिक परिणाम होतात. जुन्या अटींवर केलेले करार या नियमांच्या आधारे पुन्हा तपासले पाहिजेत, कारण त्यांच्याशी विसंगत असलेले कलम सेवा पुरवठादाराला वाचवत नाही. नव्वद दिवसांच्या निर्यातीच्या कालावधीचे आश्वासन आता उदार राहिलेले नाही; सूचना आणि संक्रमणकालीन कालावधी एकत्र जोडल्यावर ते वैधानिक किमान मर्यादेच्या जवळ पोहोचते. आणि वापरण्यायोग्य फॉरमॅटमध्ये निर्यात करण्याच्या आवश्यकतेला खरी ताकद आहे, कारण कोणताही प्रतिस्पर्धी प्लॅटफॉर्म स्वीकारू शकत नाही अशा मालकीच्या स्कीमामध्ये केलेला डंप जबाबदारीतून मुक्त करत नाही. जिथे तुम्ही अवलंबून असलेली सेवा अत्यंत सानुकूलित (customised) असेल, तिथे फॉरमॅट, स्कीमा डॉक्युमेंटेशन आणि मायग्रेशन सपोर्टची वचनबद्धता तरीही करारात समाविष्ट करा. वैधानिक किमान मर्यादा ही एक किमान मर्यादा आहे, मायग्रेशन योजना नाही.

हटवणे, बॅकअप आणि प्रोसेसर करार

जेव्हा प्लॅटफॉर्मवर वैयक्तिक डेटा असतो, तेव्हा प्रदाता जवळजवळ नेहमीच प्रोसेसर असतो आणि तुम्ही कंट्रोलर असता, आणि GDPR च्या कलम २८ नुसार प्रक्रियेचा विषय, कालावधी, स्वरूप आणि उद्देश, डेटा आणि डेटा विषयांच्या श्रेणी, आणि कंट्रोलरच्या सूचना यांचा समावेश असलेला एक लेखी करार आवश्यक असतो. संबंध संपुष्टात आल्यावर कलम २८(३)(g) हे कलम महत्त्वाचे ठरते: संबंध संपुष्टात आल्यावर, प्रोसेसरने, कंट्रोलरच्या पसंतीनुसार, सर्व वैयक्तिक डेटा हटवावा किंवा परत करावा आणि अस्तित्वात असलेल्या प्रती हटवाव्यात, जोपर्यंत युरोपियन युनियन किंवा सदस्य राष्ट्राचा कायदा डेटा संग्रहित करणे आवश्यक ठरवत नाही. जर तुमचा करार प्रदात्याला निवड करण्याची मुभा देत असेल, तर तो मानकांची पूर्तता करत नाही. GDPR अंतर्गत कंट्रोलर आणि प्रोसेसरच्या भूमिकांबद्दलचे आमचे स्पष्टीकरण, प्रत्येक पक्षाची नेमकी भूमिका काय आहे हे कसे निश्चित करावे हे सांगते, आणि डेटा प्रक्रिया करारावरील आमचे मार्गदर्शक मसुदा तयार करण्याबद्दल तपशीलवार माहिती देते.

बॅकअपच्या बाबतीतच डेटा हटवण्याची आश्वासने सहसा अयशस्वी ठरतात. सक्रिय सिस्टीममधून डेटा काढून टाकला जाईल या आश्वासनात आर्काइव्ह, स्नॅपशॉट आणि आपत्कालीन पुनर्प्राप्ती प्रतींबद्दल काहीही सांगितले जात नाही, आणि 'ऑटोरिटाइट पर्सून्सगेगेन्स' (Autoriteit Persoonsgegevens) चे ऑडिटर या तिन्हीबद्दल विचारणा करतील. पर्यवेक्षकीय पद्धतीनुसार हे मान्य आहे की बॅकअपमध्ये कोणतीही सूक्ष्म फेरफार केली जात नाही: स्वीकारलेला दृष्टिकोन असा आहे की, हटवण्यासाठी चिन्हांकित केलेला डेटा वापराबाहेर ठेवला जातो, तो चालू सिस्टीममध्ये पुनर्संचयित केला जात नाही, आणि जेव्हा बॅकअप त्याच्या सामान्य रोटेशनमध्ये ओव्हरराइट केला जातो तेव्हा तो नाहीसा होतो. त्यामुळे, करारामध्ये रोटेशनचा कालावधी, चिन्हांकित केलेला डेटा पुन्हा समाविष्ट केला जाणार नाही याची हमी, आणि एकदा चक्र पूर्ण झाल्यावर डेटा हटवल्याची लेखी पुष्टी, या गोष्टी स्पष्टपणे नमूद केल्या पाहिजेत. डेटा हटवल्याच्या प्रमाणपत्राची मागणी करारामध्ये करा, जेव्हा तुम्हाला त्याची गरज असेल तेव्हा नाही.

सुरक्षेच्या जबाबदाऱ्यांनाही तितकीच वागणूक मिळायला हवी. GDPR च्या कलम ३२ नुसार नियंत्रक आणि प्रक्रियाकर्ता या दोघांकडूनही योग्य तांत्रिक आणि संघटनात्मक उपाययोजना करणे आवश्यक आहे, आणि करारामध्ये या उपाययोजना पुरवठादाराकडे असलेल्या आणि तो टिकवून ठेवण्यास सहमत असलेल्या प्रमाणपत्राशी जोडल्या गेल्या पाहिजेत, जसे की ISO/IEC 27001 किंवा ऑडिट किंवा तपासणीच्या अधिकारासह असलेला सध्याचा SOC 2 Type II अहवाल. NIS2 निर्देशाची डच अंमलबजावणी असलेला 'सायबरबेव्हेलिग्सवेट' (Cyberbeveiligingswet) १५ ऑगस्ट २०२६ रोजी लागू झाल्यापासून, त्याच्या कार्यक्षेत्रातील संस्थांनी NCSC कडे नोंदणी करणे आणि महत्त्वपूर्ण घटनांची माहिती मिळाल्यापासून चोवीस तासांच्या आत त्याची नोंद करणे, त्यानंतर बहात्तर तासांच्या आत अधिक तपशीलवार सूचना देणे बंधनकारक आहे. जोपर्यंत तुमचा पुरवठादार तुम्हाला त्या मुदती पूर्ण करण्यासाठी पुरेशा वेगाने सतर्क करण्यास करारानुसार बांधील नसेल, तोपर्यंत या मुदती पूर्ण करणे अशक्य आहे, म्हणून करारातील सूचनेची मुदत तासांमध्ये मोजली गेली पाहिजे.

एआय प्रशिक्षण आणि प्राप्त डेटा

व्युत्पन्न डेटा म्हणजे अशी माहिती जी एखादा प्रदाता तुमच्या माहितीवरून तयार करतो: बेंचमार्क, भाकिते, प्रवृत्ती गुण, कार्यक्षमता अहवाल आणि मूळ संचावर प्रशिक्षित केलेल्या मॉडेलचे वेट्स. डेटावर कोणताही मालकी हक्क नसल्यामुळे, तो कोण वापरू शकतो याचे कोणतेही पूर्वनिर्धारित उत्तर नाही, आणि ज्या तर्काने तुमचा मूळ डेटा करारासाठी राखून ठेवला जातो, त्याच तर्काने व्युत्पन्न स्तरदेखील तिथेच राहतो. जे कलम आउटपुट आणि विश्लेषणाबद्दल काहीही न सांगता ग्राहक डेटाचे काळजीपूर्वक संरक्षण करते , ते मूळ घटकांचे संरक्षण करते आणि संपूर्ण पदार्थच उघड करते.

लक्ष देण्याजोगा शब्दप्रयोग म्हणजे सेवा सुधारणा कलम, जे सामान्यतः सेवा पुरवठादाराच्या सेवा आणि मॉडेल्स सुधारण्यासाठी व विकसित करण्यासाठी अनामिक किंवा एकत्रित ग्राहक डेटा वापरण्याचा अधिकार देते. ते न तपासता स्वीकारण्यात दोन गोष्टी चुकीच्या आहेत. पहिली गोष्ट म्हणजे, GDPR अंतर्गत अनामिकीकरणासाठी एक उच्च निकष आहे: सेवा पुरवठादाराकडे उपलब्ध असलेल्या इतर डेटाचा विचार करता, डेटा तेव्हाच अनामिक मानला जातो जेव्हा कोणत्याही मार्गाने त्याची पुन्हा ओळख पटण्याची वाजवी शक्यता नसते. छद्मनामित नोंदी, आणि एखाद्या वैयक्तिक ग्राहकाला वेगळे करण्यासाठी पुरेसे सूक्ष्म असलेले एकत्रित डेटा, हे वैयक्तिक डेटाच राहतात आणि त्याच दस्तऐवजात इतरत्र तुम्ही वाटाघाटी केलेल्या प्रोसेसर निर्बंधांच्या अधीन राहतात. दुसरी गोष्ट म्हणजे, अनामिकीकरण व्यावसायिक गोपनीयतेबद्दल काहीही सांगत नाही. तुमची किंमत रचना, मार्जिन डेटा, ग्राहक मिश्रण आणि अंतर्गत प्रक्रिया डेटा संरक्षणाच्या दृष्टीने पूर्णपणे अनामिक असू शकतात आणि तरीही ती अशी स्पर्धात्मक गुप्त माहिती असू शकते, जी तुमच्या प्रतिस्पर्धकांना विकल्या जाणाऱ्या उत्पादनाला पुरवली जावी, असे तुम्हाला मुळीच वाटणार नाही.

'वेट बेशरमिंग बेड्रिज्स्गेहेमेन' (Wet bescherming bedrijfsgeheimen) कायद्यांतर्गत व्यापार गुपित संरक्षण तेव्हाच उपयोगी पडते, जेव्हा तुम्ही माहिती गुप्त ठेवण्यासाठी वाजवी पावले उचललेली असतात, आणि सेवाशर्तींमध्ये मॉडेल प्रशिक्षणासाठी तिच्या वापरास संमती देणे हे वाजवी पावलाच्या जवळजवळ विरुद्ध आहे. कृत्रिम बुद्धिमत्तेचे नियमन देखील ही उणीव भरून काढत नाही: युरोपियन युनियनचा एआय कायदा (EU AI Act) एआय प्रणाली कशा विकसित केल्या जाऊ शकतात, बाजारात आणल्या जाऊ शकतात आणि वापरल्या जाऊ शकतात याचे नियमन करतो, आणि पारदर्शकतेची कर्तव्ये लादतो, परंतु तो प्रशिक्षण डेटा किंवा मॉडेल आउटपुटमधील हक्कांचे वाटप करत नाही. हे वाटप करारानुसार असते, याचा अर्थ संरक्षणात्मक कलम गृहीत धरण्याऐवजी त्याचा मसुदा तयार करावा लागतो.

एका सुयोग्य सूत्रानुसार, मूळ, व्युत्पन्न आणि एकत्रित डेटामधील सर्व हक्क ग्राहकाकडेच राहतात; सेवा पुरवठादार तो डेटा केवळ करारानुसार सेवा देण्यासाठीच वापरू शकतो; उत्पादन विकास, बेंचमार्किंग, मॉडेल प्रशिक्षण किंवा प्रकाशनासाठी कोणत्याही वापराकरिता प्रत्येक प्रकरणानुसार पूर्व लेखी संमती आवश्यक असते; आणि एकदा दिलेली संमती उप-परवाना किंवा पुनर्विक्रीपर्यंत विस्तारित होत नाही. जर एखादा सेवा पुरवठादार मॉडेल प्रशिक्षणासाठी सूट स्वीकारणार नसेल, तर ती त्याच्या व्यवसाय मॉडेलबद्दल एक उपयुक्त माहिती असते, आणि नवीन उत्पादन बाजारात आणल्यानंतर माहिती मिळण्यापेक्षा करारावर स्वाक्षरी करण्यापूर्वीच ती जाणून घेणे अधिक चांगले असते.

डच कायद्यानुसार दायित्वाची मर्यादा

उत्तरदायित्व मर्यादेचे कलम हे ठरवते की तुमच्या डेटा संरक्षणाचे वास्तविक मूल्य काय आहे. सेवा प्रदाते सामान्यतः मागील सहा किंवा बारा महिन्यांत भरलेल्या शुल्काएवढेच उत्तरदायित्व मर्यादित ठेवतात, जे मध्यम आकाराच्या सबस्क्रिप्शनमध्ये गंभीर उल्लंघनामुळे होणाऱ्या नुकसानीच्या तुलनेत नगण्य असते. डच कायदा अशा मर्यादांना प्रतिबंधित करत नाही; दोषमुक्तीची कलमे तत्त्वतः वैध आहेत आणि व्यावसायिक पक्षांनी वाटाघाटी करून ठरवलेल्या जोखमीच्या वाटपाचा न्यायालये आदर करतात.

तथापि, ते अमर्याद नाहीत. कलम ६:२४८(२) बी.डब्ल्यू. अंतर्गत, जेव्हा वाजवीपणा आणि निष्पक्षतेच्या मानकांनुसार दोषमुक्तीच्या कलमावरील अवलंबन अस्वीकार्य असेल, तेव्हा ते बाजूला ठेवले जाते, आणि सर्वोच्च न्यायालयाच्या न्यायनिर्णयांनुसार कर्जदाराच्या हेतूने किंवा जाणीवपूर्वक केलेल्या निष्काळजीपणामुळे, किंवा त्याच्या व्यवसायाच्या व्यवस्थापनाची जबाबदारी सोपवलेल्या व्यक्तींच्या निष्काळजीपणामुळे झालेले नुकसान हे एक आदर्श उदाहरण मानले जाते. जिथे कलम सर्वसाधारण स्वरूपाचे असते, तिथे कलम ६:२३५ बी.डब्ल्यू. द्वारे वगळलेला नसलेला पक्ष देखील कलम ६:२३३(अ) बी.डब्ल्यू. अंतर्गत त्यावर आक्षेप घेऊ शकतो. दोन्ही मार्गांवर नुकसान झाल्यानंतर, काही खर्चाने आणि कोणत्याही हमीशिवाय युक्तिवाद केला जातो. मर्यादेवर वाटाघाटी करणे अधिक स्वस्त आहे.

दोन अपवादांवर आग्रह धरणे महत्त्वाचे आहे. गोपनीयतेचे आणि सुरक्षेच्या जबाबदाऱ्यांचे उल्लंघन हे सर्वसाधारण मर्यादेच्या बाहेर किंवा त्यापेक्षा लक्षणीयरीत्या जास्त मर्यादेखाली असले पाहिजे, कारण नेमक्या याच धोक्यापासून तुम्ही संरक्षण खरेदी करत आहात. आणि बौद्धिक संपदा नुकसानभरपाई अमर्याद असावी, कारण पुरवठादाराच्या स्वतःच्या सॉफ्टवेअरमधून उद्भवणारा तृतीय-पक्षाचा उल्लंघनाचा दावा हा एक असा धोका आहे ज्याची तुम्ही तपासणी किंवा नियंत्रण करू शकत नाही. हे देखील लक्षात घ्या की करारातील मर्यादा केवळ करारातील पक्षांनाच बंधनकारक असते. ती GDPR च्या कलम ८२ अंतर्गत डेटा धारकाच्या नुकसानीच्या दाव्याला मर्यादित करत नाही, आणि ती 'ऑटोरिटाइट पर्सून्सगेगेवेन्स' (Autoriteit Persoonsgegevens) द्वारे लादल्या जाणाऱ्या प्रशासकीय दंडांनाही मर्यादित करत नाही, जे सर्वात गंभीर उल्लंघनांसाठी जागतिक वार्षिक उलाढालीच्या चार टक्क्यांपर्यंत पोहोचतात. प्रोसेसरने काय देण्याचे मान्य केले होते याची पर्वा न करता, हे सर्व धोके नियंत्रकावरच येतात.

प्रदाता अयशस्वी झाल्यास सातत्य

दिवाळखोरी ही अशी परिस्थिती आहे, जी बहुतेक करारांसाठी सर्वात वाईट ठरते. जर एखाद्या डच सेवा पुरवठादाराला दिवाळखोर घोषित केले गेले, तर 'फायलिसेमेंट्सवेट'च्या कलम ३७ नुसार, प्रतिपक्षाला विश्वस्ताला कराराची पूर्तता केली जाईल की नाही याची पुष्टी करण्यासाठी एक वाजवी लेखी मुदत देण्याची परवानगी मिळते; जर विश्वस्ताने पुष्टी दिली नाही, तर तो तुमच्याकडून पूर्ततेची मागणी करण्याचा हक्क गमावतो, परंतु यामुळे सेवा चालू राहील असे गृहीत धरता येत नाही. व्यवहारात, मालमत्तेची विल्हेवाट लागेपर्यंत प्लॅटफॉर्म बंद ठेवला जाऊ शकतो आणि तुमचा डेटा अशा पायाभूत सुविधांवर पडून राहतो, ज्या विश्वस्त विकण्याचा प्रयत्न करत असतो.

SaaS साठी केवळ सोर्स कोड एस्क्रो ही समस्या सोडवत नाही, कारण एनव्हायरमेंट, कॉन्फिगरेशन आणि डेटाशिवाय कोड ठेवणे निरुपयोगी आहे. जी गोष्ट प्रभावी ठरते ती म्हणजे एक सातत्यपूर्ण व्यवस्था, जी या तिन्ही गोष्टींचा समावेश करते: सोर्स कोड आणि बिल्ड निर्देशांची नियमित ठेव, प्रोव्हायडरच्या मालमत्तेबाहेर ठेवलेल्या तुमच्या डेटाची दस्तऐवजीकृत स्वरूपातील अद्ययावत प्रत, आणि केवळ दिवाळखोरीऐवजी दिवाळखोरी व दीर्घकाळ सेवा खंडित होणे या दोन्हींचा समावेश असलेले रिलीज ट्रिगर. एस्क्रो व्यवस्था आणि नेदरलँड्समधील सॉफ्टवेअर एस्क्रोवरील आमचे लेख हे स्पष्ट करतात की यांची रचना कशी केली जाते आणि रिलीजमधून प्रत्यक्षात काय मिळते.

सही करण्यापूर्वी काय तपासावे

SaaS प्रदात्याची योग्य ती चौकशी करणे म्हणजे मुख्यत्वे असे प्रश्न विचारणे, ज्यांची उत्तरे एक सुव्यवस्थित पुरवठादार लेखी स्वरूपात देऊ शकेल. प्रदात्याकडे कोणती प्रमाणपत्रे आहेत, त्यांचे शेवटचे ऑडिट कधी झाले होते, आणि ते संपूर्ण कालावधीसाठी ती प्रमाणपत्रे टिकवून ठेवण्यास वचनबद्ध असतील का? डेटा कुठे साठवला जातो आणि त्यावर प्रक्रिया केली जाते, त्यात कोणते उप-प्रोसेसर सामील आहेत, आणि उप-प्रोसेसरमधील बदलाची सूचना कशी दिली जाते व त्यावर आक्षेप कसा घेतला जातो? त्यांचा घटनांचा इतिहास काय आहे, आणि शेवटच्या घटनेदरम्यान त्यांनी संवाद कसा साधला होता? यापैकी कोणत्याही प्रश्नाचे लेखी उत्तर देण्यास टाळाटाळ करणे, हेच एक उत्तर आहे.

वाटाघाटी सुरू करण्यापूर्वी, तुम्ही कोणत्या अटींवर तडजोड करणार नाही हे अंतर्गत पातळीवर ठरवणे महत्त्वाचे आहे. व्यवसाय, आयटी आणि कायदेशीर विभाग यांच्यात ही भूमिका आधीच निश्चित केल्याने, खरेदी प्रक्रियेच्या शेवटी अंतिम मुदतीच्या दबावाखाली ती सोडून देण्याची वेळ टळते. एक व्यवहार्य किमान अट अशी आहे की, मूळ आणि व्युत्पन्न डेटावरील सर्व हक्क तुमच्याकडेच राहतील; सेवा पुरवठादाराचा परवाना केवळ सेवा देण्यापुरता मर्यादित असेल आणि तो करारासोबतच संपुष्टात येईल; डेटा कायद्याने परवानगी दिलेल्या खर्चापेक्षा जास्त खर्च न आकारता, दस्तऐवजीकृत, मशीन-वाचनीय स्वरूपात निर्यात उपलब्ध असेल; डेटा हटवण्याच्या प्रक्रियेत बॅकअपचाही समावेश असेल आणि त्याची लेखी पुष्टी केली जाईल; घटनेची सूचना तासांमध्ये मोजली जाईल; आणि गोपनीयता, सुरक्षा व बौद्धिक संपदा नुकसानभरपाई सामान्य दायित्वाच्या मर्यादेबाहेर असतील. ही अट सेवा पुरवठादाराच्या कागदपत्रांमधील दुरुस्त्यांची यादी म्हणून सादर करण्याऐवजी, व्यवसाय करण्याची एक अट म्हणून मांडा, आणि चर्चा वेगळ्या दिशेने जाईल.

एकदा ती अंतर्गत भूमिका निश्चित झाली आणि तांत्रिक योग्य ती तपासणी पूर्ण झाली की कायदेशीर पुनरावलोकन करा. त्या टप्प्यावर, वकील व्यवसायाला नेमके काय हवे आहे हे शोधण्याऐवजी शब्दरचनेवर काम करत असतो, जे अधिक जलद आणि लक्षणीयरीत्या स्वस्त आहे. आणि करारातून बाहेर पडण्याचा पर्याय पूर्णपणे खुला ठेवा. जो सेवा पुरवठादार स्वतःच्या निष्काळजीपणाची जबाबदारी स्वीकारत नाही, किंवा ज्याचा महसूल तुमच्या डेटावरील हक्कांवर अवलंबून आहे, तो अशी भागीदारी देऊ करत नाही जी केवळ मसुदा तयार करून सुधारता येईल.

करारनाम्याच्या शब्दरचनेची तुलना केली

हा नमुना सुसंगत आहे: कमकुवत आवृत्ती एका परिणामाचे वर्णन करते, तर संरक्षक आवृत्ती एका कार्यप्रणालीशी बांधील राहते. ज्या कलमाची एखाद्या स्वरूपाच्या, कालावधीच्या किंवा विशिष्ट मानकाच्या आधारे चाचणी करता येत नाही, त्याची अंमलबजावणी गरजेच्या वेळी केली जाऊ शकत नाही.

कालावधी दरम्यान डेटाचे स्थान, उप-प्रक्रिया करणारे आणि ऑडिट अधिकार

डेटा नेमका कुठे आहे हे जर तुम्ही निश्चित करू शकत नसाल, तर डेटावरील हक्कांना फारसे महत्त्व उरत नाही. GDPR च्या कलम २८(२) नुसार, प्रोसेसरने दुसऱ्या प्रोसेसरला नियुक्त करण्यापूर्वी कंट्रोलरची परवानगी घेणे आवश्यक आहे, आणि जर ती परवानगी सर्वसाधारण असेल, तर कंट्रोलरला होणाऱ्या संभाव्य बदलांविषयी किंवा नवीन जोडण्यांविषयी माहिती देणे आवश्यक आहे, जेणेकरून कंट्रोलर आक्षेप घेऊ शकेल. व्यवहारात, बहुतेक SaaS प्रदाते प्रकाशित उप-प्रोसेसर सूची आणि सर्वसाधारण परवानगीसह काम करतात, जे स्वीकारार्ह आहे, जर करारामध्ये सूचना कालावधी निश्चित केला असेल, तुम्हाला आक्षेप घेण्याचा खरा हक्क दिला असेल, आणि तुम्ही आक्षेप घेतल्यास काय होईल हे नमूद केले असेल: एक व्यवहार्य कलम कोणत्याही दंडाशिवाय आणि संपूर्ण डेटा निर्यातीसह करार समाप्त करण्याची परवानगी देते.

त्याच कारणास्तव ठिकाण महत्त्वाचे ठरते. जर वैयक्तिक डेटा युरोपियन इकॉनॉमिक एरियाच्या बाहेर जात असेल, तर GDPR च्या प्रकरण V नुसार एका हस्तांतरण यंत्रणेची आवश्यकता असते, मग ती पर्याप्ततेचा निर्णय असो, युरोपियन कमिशनची मानक करार कलमे असोत किंवा बंधनकारक कॉर्पोरेट नियम असोत. यासोबतच, गंतव्य देशाचा कायदा व्यवहारात त्या सुरक्षा उपायांना कमकुवत करतो की नाही याचे मूल्यांकन करणे आवश्यक असते. पर्याप्ततेच्या निर्णयांचे वेळोवेळी पुनरावलोकन केले जाते आणि त्यांना युरोपियन न्यायालयांमध्ये एकापेक्षा जास्त वेळा आव्हान दिले गेले आहे, त्यामुळे जो करार केवळ एका पर्याप्ततेच्या निर्णयावर अवलंबून असतो आणि इतर कशाचीही तरतूद करत नाही, तो कमकुवत असतो. जर वापरात असलेली यंत्रणा बंद पडली, तर सेवा पुरवठादाराला स्वतःच्या खर्चाने एक पर्यायी यंत्रणा लागू करण्यास सांगा आणि ज्या देशांमधून सहाय्यक कर्मचारी वातावरणात प्रवेश करू शकतात त्या देशांची माहिती उघड करण्यास सांगा; ही यादी अनेकदा डेटा संग्रहित केलेल्या देशांपेक्षा अधिक व्यापक असते.

शेवटी, एका व्यवहार्य पडताळणी अधिकारावर आग्रह धरा. GDPR च्या कलम २८(३)(h) नुसार, प्रोसेसरवर अनुपालन सिद्ध करण्यासाठी आवश्यक माहिती उपलब्ध करून देण्याची आणि कंट्रोलर किंवा त्याने नियुक्त केलेल्या ऑडिटरद्वारे आयोजित केलेल्या तपासणीसह ऑडिटमध्ये सहभागी होण्याची व त्याला परवानगी देण्याची जबाबदारी आहे. प्रोव्हायडर्स सामान्यतः हे एका वार्षिक प्रमाणन अहवालापुरते मर्यादित ठेवतात, जे एका सामायिक प्लॅटफॉर्मसाठी वाजवी आहे, परंतु केवळ तेव्हाच जेव्हा तो अहवाल अद्ययावत असेल, तुम्ही वापरत असलेल्या सेवांचा त्यात समावेश असेल आणि जिथे अहवालात मोठी त्रुटी किंवा एखादी घटना घडल्याचे उघड होते, तिथे पाठपुरावा करणारे प्रश्न विचारण्याचा व तपासणी करण्याचा अधिकार त्यात असेल. ते ट्रिगर्स त्या कलमात लिहा. जो ऑडिट अधिकार केवळ अमूर्तपणे वापरला जाऊ शकतो, तो कधीच वापरला जात नाही.

SaaS करार डेटा मालकीबद्दल वारंवार विचारले जाणारे प्रश्न

कोणते कलम सर्वात महत्त्वाचे आहे?

तुमच्या डेटासाठी प्रदात्याच्या परवान्याची व्याख्या करणारे कलम, कारण त्यामुळेच मालकी हक्काचे विधान अंमलबजावणीयोग्य बनते. जर पुढच्याच परिच्छेदात तोच डेटा कोणत्याही उद्देशासाठी वापरण्याचा कायमस्वरूपी, अपरिवर्तनीय, जागतिक परवाना दिला असेल, तर 'ग्राहकाकडे मालकी हक्क कायम राहतो' असे सांगणाऱ्या वाक्याला फारसे महत्त्व नसते. हे दोन्ही एकत्र वाचा आणि उद्देशावरील मर्यादा, समाप्तीशी निगडित अंतिम तारीख, आणि व्युत्पन्न व एकत्रित डेटाचा स्पष्ट संदर्भ शोधा.

माझी सेवा पुरवणारी कंपनी दिवाळखोर झाल्यास मला माझा डेटा परत मिळू शकेल का?

जर तुम्ही त्याची आगाऊ व्यवस्था केली असेल तरच. डच दिवाळखोरीमध्ये, विश्वस्त सेवा चालू ठेवण्यास बांधील नसतो, आणि 'फायलिसेमेंट्सवेट'च्या कलम ३७ नुसार, कामगिरीची पुष्टी करण्यात अयशस्वी होण्याचा व्यावहारिक परिणाम म्हणजे कराराची पूर्तता होत नाही. दिवाळखोरीत असलेल्या कंपनीविरुद्धचा करारानुसार निर्यातीचा हक्क हा एक दावा आहे, उपाय नाही. विश्वसनीय संरक्षण ही एक सातत्य व्यवस्था आहे जी तुमच्या डेटाची एक अद्ययावत, दस्तऐवजीकृत प्रत आणि ती चालवण्याचे साधन सेवा पुरवठादाराच्या मालमत्तेबाहेर ठेवते, ज्यात एक मुक्तता ट्रिगर असतो जो दिवाळखोरी आणि सेवेतील सततच्या अपयशाला कव्हर करतो.

जीडीपीआरचे पालन माझ्या कंपनीच्या डेटा अधिकारांचे संरक्षण करते का?

नाही, आणि हा गैरसमज धोक्याचे एक सामान्य कारण आहे. GDPR व्यक्तींच्या वैयक्तिक डेटाच्या संदर्भात त्यांचे संरक्षण करते आणि त्या व्यक्तींना अधिकार प्रदान करते, ग्राहक म्हणून तुमच्या कंपनीला नाही. एखादा प्रदाता वैयक्तिक डेटावर निर्दोषपणे प्रक्रिया करू शकतो आणि तरीही तुमच्या व्यावसायिक डेटाचा, तुमच्या व्यवहारांच्या इतिहासाचा आणि त्यावर आधारित विश्लेषणाचा वापर करण्यासाठी करारानुसार परवाना धारण करू शकतो. वैयक्तिक डेटाचे अनुपालन आणि व्यावसायिक डेटाचे अधिकार हे वेगवेगळे प्रश्न आहेत आणि त्यासाठी स्वतंत्र कलमांची आवश्यकता आहे.

डेटा कायदा माझ्या करारातील तरतुदींपेक्षा श्रेष्ठ आहे का?

सेवा बदलण्याच्या बाबतीत, बहुतांशी होय. डेटा कायद्याचे प्रकरण VI हे युरोपियन युनियनमधील ग्राहकांना डेटा प्रोसेसिंग सेवा देणाऱ्या सेवा पुरवठादारांना लागू होते आणि ते सूचना कालावधी, संक्रमणकालीन कालावधी, निर्यात स्वरूप आणि शुल्कासंबंधी किमान हक्क निश्चित करते, ज्यांचे उल्लंघन करारामध्ये करता येत नाही. तथापि, मुदतीदरम्यान तुमचा डेटा कोण वापरू शकेल, प्राप्त केलेल्या डेटाची मालकी कोणाकडे असेल, किंवा सुरक्षेच्या घटनेत काय होईल, हे ते ठरवत नाही. या बाबी करारासाठी राखून ठेवल्या जातात.

कसे Law & More मदत करू शकता

आयटी वकील Law & More आम्ही डच आणि आंतरराष्ट्रीय व्यवसायांसाठी SaaS आणि क्लाउड करारांचे पुनरावलोकन आणि वाटाघाटी करतो, ज्यामध्ये डेटाचे अधिकार, प्रोसेसर करार, स्विचिंग आणि बाहेर पडण्याच्या तरतुदी, सुरक्षा वचनबद्धता आणि दायित्व यांचा समावेश असतो. जेव्हा बाहेर पडण्याची प्रक्रिया अयशस्वी होते, तेव्हा आम्ही सातत्य व्यवस्था आणि प्रदात्यांसोबतच्या विवादांवरही सल्ला देतो. आयटी कायदा मार्गदर्शक व्यापक चौकट मांडा. करारावर स्वाक्षरी करण्यापूर्वी त्याचे मूल्यांकन करून घ्यायचे असल्यास, किंवा आधीच अंमलात असलेल्या करारावर आपली भूमिका जाणून घ्यायची असल्यास, कृपया आमच्याशी संपर्क साधा.