guardia-ai/gitlab-componentEU AI अधिनियम अनुपालन स्कैनर GitLab CI/CD पाइपलाइनों के लिए — AI/ML लाइब्रेरियों का पता लगाता है और MR टिप्पणियों के रूप में जोखिम वर्गीकरण पोस्ट करता है।
GitLab के साथ शुरुआत करना आसान बनाने के लिए, यहाँ अनुशंसित अगले चरणों की एक सूची दी गई है।
पहले से ही प्रो? बस इस README.md को संपादित करें और इसे अपना बनाएँ। इसे आसान बनाना चाहते हैं? नीचे दिए गए टेम्पलेट का उपयोग करें!
cd existing_repo
git remote add origin https://gitlab.com/guardia-ai/gitlab-component.git
git branch -M main
git push -uf origin main
GitLab में निर्मित सतत एकीकरण का उपयोग करें।
जब आप इस README को अपना बनाने के लिए तैयार हों, तो बस इस फ़ाइल को संपादित करें और नीचे दिए गए उपयोगी टेम्पलेट का उपयोग करें (या इसे जैसे चाहें वैसे संरचित करने के लिए स्वतंत्र महसूस करें - यह केवल एक शुरुआती बिंदु है!)। इस टेम्पलेट के लिए makeareadme.com का धन्यवाद।
हर प्रोजेक्ट अलग होता है, इसलिए विचार करें कि इनमें से कौन से अनुभाग आपके प्रोजेक्ट पर लागू होते हैं। टेम्पलेट में उपयोग किए गए अनुभाग अधिकांश ओपन सोर्स प्रोजेक्ट्स के लिए सुझाव हैं। यह भी ध्यान रखें कि जबकि एक README बहुत लंबा और विस्तृत हो सकता है, बहुत लंबा होना बहुत छोटे से बेहतर है। यदि आपको लगता है कि आपका README बहुत लंबा है, तो जानकारी काटने के बजाय दस्तावेज़ीकरण के किसी अन्य रूप का उपयोग करने पर विचार करें।
अपने प्रोजेक्ट के लिए एक स्व-व्याख्यात्मक नाम चुनें।
लोगों को बताएं कि आपका प्रोजेक्ट विशेष रूप से क्या कर सकता है। संदर्भ प्रदान करें और किसी भी संदर्भ का लिंक जोड़ें जिससे आगंतुक अपरिचित हो सकते हैं। यहाँ सुविधाओं की सूची या पृष्ठभूमि उपखंड भी जोड़ा जा सकता है। यदि आपके प्रोजेक्ट के विकल्प हैं, तो यह अंतर करने वाले कारकों को सूचीबद्ध करने के लिए यह एक अच्छी जगह है।
कुछ README पर, आप छोटी छवियाँ देख सकते हैं जो मेटाडेटा बताती हैं, जैसे कि क्या प्रोजेक्ट के सभी परीक्षण पास हो रहे हैं। आप अपने README में कुछ जोड़ने के लिए Shields का उपयोग कर सकते हैं। कई सेवाओं में बैज जोड़ने के निर्देश भी हैं।
आप जो बना रहे हैं, उसके आधार पर, स्क्रीनशॉट या यहाँ तक कि एक वीडियो शामिल करना एक अच्छा विचार हो सकता है (आप अक्सर वास्तविक वीडियो के बजाय GIF देखेंगे)। ttygif जैसे उपकरण मदद कर सकते हैं, लेकिन अधिक परिष्कृत विधि के लिए Asciinema देखें।
किसी विशेष पारिस्थितिकी तंत्र के भीतर, चीजों को स्थापित करने का एक सामान्य तरीका हो सकता है, जैसे कि Yarn, NuGet, या Homebrew का उपयोग करना। हालाँकि, इस संभावना पर विचार करें कि आपका README पढ़ने वाला कोई नौसिखिया है और अधिक मार्गदर्शन चाहेगा। विशिष्ट चरणों को सूचीबद्ध करने से अस्पष्टता दूर होती है और लोगों को जल्द से जल्द आपके प्रोजेक्ट का उपयोग करने में मदद मिलती है। यदि यह केवल किसी विशिष्ट संदर्भ में चलता है जैसे किसी विशेष प्रोग्रामिंग भाषा संस्करण या ऑपरेटिंग सिस्टम, या इसमें निर्भरताएँ हैं जिन्हें मैन्युअल रूप से स्थापित करना होगा, तो एक आवश्यकताएँ उपखंड भी जोड़ें।
उदाहरणों का उदारतापूर्वक उपयोग करें, और यदि संभव हो तो अपेक्षित आउटपुट दिखाएँ। उपयोग का सबसे छोटा उदाहरण इनलाइन रखना सहायक होता है जिसे आप प्रदर्शित कर सकते हैं, साथ ही अधिक परिष्कृत उदाहरणों के लिंक प्रदान करें यदि वे README में शामिल करने के लिए बहुत लंबे हैं।
लोगों को बताएं कि वे मदद के लिए कहाँ जा सकते हैं। यह एक इश्यू ट्रैकर, चैट रूम, ईमेल पता आदि का कोई भी संयोजन हो सकता है।
यदि आपके पास भविष्य में रिलीज़ के लिए विचार हैं, तो उन्हें README में सूचीबद्ध करना अच्छा है।
बताएं कि क्या आप योगदान के लिए खुले हैं और उन्हें स्वीकार करने के लिए आपकी क्या आवश्यकताएँ हैं।
जो लोग आपके प्रोजेक्ट में बदलाव करना चाहते हैं, उनके लिए शुरुआत कैसे करें, इस पर कुछ दस्तावेज़ीकरण होना सहायक होता है। शायद कोई स्क्रिप्ट है जिसे उन्हें चलाना चाहिए या कुछ पर्यावरण चर हैं जिन्हें उन्हें सेट करने की आवश्यकता है। इन चरणों को स्पष्ट करें। ये निर्देश आपके भविष्य के स्वयं के लिए भी उपयोगी हो सकते हैं।
आप कोड को लिंट करने या परीक्षण चलाने के लिए कमांड भी दस्तावेज़ित कर सकते हैं। ये कदम उच्च कोड गुणवत्ता सुनिश्चित करने और इस संभावना को कम करने में मदद करते हैं कि परिवर्तन अनजाने में कुछ तोड़ दें। परीक्षण चलाने के निर्देश होना विशेष रूप से सहायक होता है यदि इसके लिए बाहरी सेटअप की आवश्यकता होती है, जैसे ब्राउज़र में परीक्षण के लिए Selenium सर्वर शुरू करना।
उन लोगों के प्रति अपनी प्रशंसा दिखाएँ जिन्होंने प्रोजेक्ट में योगदान दिया है।
ओपन सोर्स प्रोजेक्ट्स के लिए, बताएं कि यह कैसे लाइसेंस प्राप्त है।
यदि आपके प्रोजेक्ट के लिए आपकी ऊर्जा या समय खत्म हो गया है, तो README के शीर्ष पर एक नोट डालें जिसमें कहा गया हो कि विकास धीमा हो गया है या पूरी तरह से बंद हो गया है। कोई व्यक्ति आपके प्रोजेक्ट को फोर्क करने या स्वेच्छा से मेंटेनर या मालिक के रूप में आगे आने का विकल्प चुन सकता है, जिससे आपका प्रोजेक्ट जारी रह सके। आप मेंटेनर्स के लिए स्पष्ट अनुरोध भी कर सकते हैं।
यह पता लगाने के अलावा कि आप किन AI लाइब्रेरियों का उपयोग करते हैं, स्कैनर आपके स्रोत को पढ़ता है और विशिष्ट पंक्तियों पर विशिष्ट दायित्वों की रिपोर्ट करता है:
| नियम | यह क्या देखता है |
|---|---|
GA-ART50-001 | एक उपयोगकर्ता-सामना करने वाला एंडपॉइंट जो एक मॉडल तक पहुँचता है, जिसमें रिपॉजिटरी में कहीं भी कोई खुलासा नहीं है कि प्रतिक्रियाएँ AI-जनरेटेड हैं |
GA-ART12-001 | एक मॉडल जो बिना किसी लॉगिंग, ऑडिट या ट्रेसिंग कॉल के दायरे में आह्वान किया गया है |
निष्कर्ष तीन तरीकों से दिखाई देते हैं: मर्ज रिक्वेस्ट पर एक टिप्पणी के रूप में, कोड क्वालिटी रिपोर्ट के माध्यम से मर्ज रिक्वेस्ट डिफ पर मार्कर के रूप में, और — एक API कुंजी के साथ — आपके Guardia डैशबोर्ड में एक रिकॉर्ड के रूप में जो ट्रैक करता है कि आपने कमिट दर कमिट क्या ठीक किया और क्या पेश किया।
include:
- component: gitlab.com/guardia-ai/gitlab-component/scan@main
inputs:
guardia_api_key: $GUARDIA_API_KEY # वैकल्पिक — रिकॉर्ड रखता है
code_analysis: 'true'
fail_on_findings: 'none'
निष्कर्ष अपने आप हल हो जाते हैं। कोड को ठीक करें — हमारा पैच या आपका अपना — और अगला स्कैन इसकी रिपोर्ट करना बंद कर देता है। क्लिक करने की कोई आवश्यकता नहीं।
इसके बजाय एक को स्वीकार करने के लिए, कोड में ऐसा कहें:
# guardia: ignore GA-ART50-001 — notice is rendered by the chat UI shell
यह कभी बिल्ड को विफल नहीं करता है, और यह git blame से लेखक के साथ एक दस्तावेजी जोखिम स्वीकृति के रूप में आपके डैशबोर्ड पर पहुँचता है, जो एक ऑडिटर देखना चाहता है।
पाँच साल पुराने रिपॉजिटरी में ऐसे निष्कर्ष होंगे जो वर्तमान में टीम पर किसी के कारण नहीं हुए हैं। उन्हें एक बार फ्रीज करें, और केवल नए काम को साफ होना होगा:
guardia-scan . --write-baseline .guardia/baseline.json
उस फ़ाइल को कमिट करें। आधाररेखित किए गए निष्कर्ष रिपोर्ट और आपके डैशबोर्ड में दिखाई देते रहते हैं — वे कभी भी जाँच को विफल नहीं करते हैं। बाद में पेश की गई कोई भी चीज़ ऐसा करती है।
प्रत्येक रन एक छेड़छाड़-स्पष्ट रिकॉर्ड लिख सकता है — क्या पाया गया, किस कमिट पर, नियम पैक के किस संस्करण के तहत, और उस समय प्रत्येक नियम की कितनी कानूनी समीक्षा हुई थी:
- uses: GharbiiAhmed/guardia-ai-action@v1
with:
evidence-file: guardia-evidence.json
evidence-signing-key: ${{ secrets.GUARDIA_EVIDENCE_KEY }} # वैकल्पिक
रिकॉर्ड हैश द्वारा श्रृंखलित होते हैं, इसलिए पिछले एक को बदलने से उसके बाद का हर रिकॉर्ड टूट जाता है। हस्ताक्षर कुंजी के बिना जो आंतरिक स्थिरता साबित करती है, प्रामाणिकता नहीं — रिकॉर्ड स्वयं यह कहता है, आपको अनुमान लगाने के लिए छोड़ने के बजाय।
निष्कर्ष बताते हैं कि आपका कोड क्या करता है और दायित्व को उद्धृत करते हैं। वे यह नहीं बताते कि आप उल्लंघन में हैं — कोई दायित्व लागू होता है या नहीं, यह आपके सिस्टम के उद्देश्य और तैनाती संदर्भ पर निर्भर करता है, जो कोई कोड स्कैन निर्धारित नहीं कर सकता है। नियम विनियमन (EU) 2024/1689 को शब्दशः उद्धृत करते हैं ताकि आप स्वयं तर्क की जाँच कर सकें।
पहचान पूरी तरह से ऑफ़लाइन चलती है। आपका स्रोत कभी भी रनर को नहीं छोड़ता है।