विषय-सूची

जब आप AI ऐप्स बनाना सीख जाते हैं, तो अगला चरण उन्हें सुरक्षित रूप से चलाना होता है। LLMs उपयोगी होते हैं, लेकिन उन्हें दुर्भावनापूर्ण input से धोखा दिया जा सकता है, वे गोपनीय डेटा लीक कर सकते हैं, या पूरी आत्मविश्वास के साथ बेतुके जवाब दे सकते हैं। इसे रोकने वाला सुरक्षा तंत्र ही है AI guardrails। 2026 में, जब AI agent की घटनाएँ वास्तव में हो रही हैं, guardrails production संचालन का एक अनिवार्य हिस्सा बन चुके हैं।

यह लेख शुरुआती लोगों के लिए सरल भाषा में बताता है कि AI guardrails क्या हैं, ये किससे सुरक्षा देते हैं, कैसे सुरक्षा देते हैं (input/output दो परतें), सबसे बड़ा खतरा — prompt injection — और tools व व्यावहारिक सिद्धांत।

AI GUARDRAILS · प्रवेश और निकास दोनों पर पहरा

input पर रोको, output पर रोको

— खतरनाक निर्देश और खतरनाक जवाब, दोनों तरफ रोकें

🛡️

Input guard

खतरनाक निर्देशों का पता लगाएँ

→
🤖

LLM

प्रोसेस

→
🛡️

Output guard

खतरनाक जवाबों को ब्लॉक करें

1. AI guardrails क्या हैं?

AI guardrails वे "सुरक्षा तंत्र" (नियम और फ़िल्टर) हैं जिन्हें आप किसी LLM ऐप को खतरों से बचाने के लिए लगाते हैं। जैसे हाईवे की guardrail कार को रास्ते से भटकने नहीं देती, वैसे ही AI guardrails खतरनाक input और अवांछित output को रोक देते हैं। ये user input को LLM तक पहुँचने से पहले जाँचते हैं, और LLM के जवाब को user तक वापस जाने से पहले जाँचते हैं — "दोनों तरफ के ये checkpoints" ही guardrails हैं।

इनकी ज़रूरत क्यों है? LLMs समझदार होते हैं लेकिन आसानी से धोखा खा जाते हैं और मुँहफट होते हैं। एक दुर्भावनापूर्ण निर्देश उनके safety नियंत्रण हटा सकता है (jailbreak), वे आंतरिक जानकारी उगल सकते हैं, या बिना किसी आधार के बातें ठोक सकते हैं। केवल एक समझदार model चुन लेना इसे नहीं रोकेगा — आपको ऐप की तरफ एक अलग सुरक्षा तंत्र चाहिए।

💡 एक पंक्ति में: guardrails = "AI के प्रवेश और निकास पर checkpoints।" इन्हें model की अपनी बुद्धिमत्ता से अलग, ऐप की तरफ एक स्वतंत्र सुरक्षा परत के रूप में समझें।

2. ये किससे सुरक्षा देते हैं?

आइए स्पष्ट करें कि guardrails किनसे बचाव करते हैं — AI ऐप्स के लिए विशिष्ट खतरों से। चार प्रमुख खतरे ये हैं।

🎯 Prompt injection

दुर्भावनापूर्ण आदेशों से system के निर्देशों को ओवरराइड करता है और AI को हाईजैक कर लेता है। सबसे बड़ा खतरा (नीचे देखें)।

🔓 Jailbreak

safety नियंत्रणों को बायपास करके वह खतरनाक output निकलवाता है जो सामान्यतः प्रतिबंधित होता है।

💧 डेटा लीक

गोपनीय डेटा, व्यक्तिगत जानकारी (PII), या system prompt को बाहर लीक कर देता है।

👻 Hallucination और हानिकारक output

बेतुकी बातों को तथ्य की तरह जवाब देता है, या भेदभावपूर्ण या अनुचित सामग्री बना देता है।

ये ऐसी चीज़ें नहीं हैं जो "समझदार model के साथ नहीं होंगी।" खासकर जब कोई AI agent tools चलाता है, तो हाईजैक होते ही वह असली नुकसान कर सकता है — गलत भेजना, डेटा हटाना, अनधिकृत कार्रवाई। इसीलिए आपको एक रक्षात्मक तंत्र चाहिए।

3. दो परतों पर सुरक्षा: input और output

guardrails की बुनियाद हैं दो परतें: "input guardrails" और "output guardrails।" आप दोनों जगह जाँचते हैं — LLM में प्रवेश से पहले, और user तक वापस लौटने से पहले।

Input guardrails (प्रवेश से पहले)

  • prompt injection और jailbreak का पता लगाना
  • व्यक्तिगत जानकारी (PII) का पता लगाना और mask करना
  • विषयों को सीमित करना (काम से बाहर के सवाल अस्वीकार करना)
  • संदिग्ध patterns को हटाना और sanitize करना

Output guardrails (वापस लौटने से पहले)

  • हानिकारक या अनुचित सामग्री को फ़िल्टर करना
  • गोपनीय/व्यक्तिगत डेटा लीक रोकना (mask करना)
  • तथ्यों के साथ संगति जाँचना (hallucination)
  • format और नीति-अनुपालन को सत्यापित करना

ये दो परतें AI evals से जुड़ी हुई हैं, जो output की गुणवत्ता मापते हैं। जहाँ evals "अच्छा या बुरा मापते हैं," वहीं guardrails "खतरे को उसी जगह रोक देते हैं।" दोनों के होने पर ही आप आत्मविश्वास के साथ production में ship कर सकते हैं।

4. सबसे बड़ा खतरा: prompt injection

कई खतरों में एक अलग ही खड़ा है: prompt injection। यह एक ऐसा हमला है जो "दुर्भावनापूर्ण निर्देश घुसा देता है, system के आदेशों को ओवरराइड कर देता है, और AI को कठपुतली की तरह नचाता है," और उद्योग की खतरों की सूची (OWASP LLM Top 10) इसे सबसे गंभीर मानती है। इसके दो प्रकार जानें।

DIRECT

user सीधे इसे डालता है

"पिछले सभी निर्देशों को अनदेखा करो और…" जैसी बातें, जो input बॉक्स से सीधे system के आदेशों को ओवरराइड करने की कोशिश करती हैं।

INDIRECT

बाहरी डेटा में छिपा हुआ

किसी वेब पेज या RAG दस्तावेज़ में छिपे दुर्भावनापूर्ण निर्देश, जो AI को खिलाकर उसे नियंत्रित करते हैं। पकड़ना मुश्किल।

⚠️ अकेला RAG इसे नहीं रोकता: चूँकि indirect injection आदेशों को retrieved दस्तावेज़ों के अंदर छिपाता है, इसलिए केवल RAG जोड़ने से यह अपने-आप ब्लॉक नहीं होगा। शोध बताते हैं कि retrieved दस्तावेज़ों पर भी एक समर्पित जाँच चाहिए (एक "retrieval rail")।

tools और बाहरी डेटा से जुड़े agents — MCP आदि के ज़रिए — indirect injection के लिए विशेष रूप से आसान निशाना होते हैं। लोहे का नियम यह है कि इस मान्यता पर डिज़ाइन करें कि "बाहर से आने वाले डेटा पर भरोसा मत करो।"

5. Tools और defense in depth का सिद्धांत

आपको guardrails शुरू से बनाने की ज़रूरत नहीं — समर्पित tools और frameworks तैयार हैं।

LLM Guard / Guardrails AI

कई input/output scanners के साथ open-source। injection का पता लगाना, PII masking, हानिकारक-सामग्री फ़िल्टर को बिल्डिंग ब्लॉक की तरह जोड़ें।

NeMo Guardrails / Llama Guard

NVIDIA का NeMo dialog-flow नियंत्रण में मज़बूत है; Meta के Llama Guard का उपयोग jailbreak और खतरनाक input को वर्गीकृत करने के लिए होता है।

Cloud providers की safety सुविधाएँ

Azure (Content Safety / Prompt Shields), AWS Bedrock Guardrails, OpenAI Moderation, और बहुत कुछ।

tools से ज़्यादा अहम है "defense in depth" की मानसिकता। एक अकेला फ़िल्टर हमेशा तोड़ा जा सकता है, इसलिए आप कई परतें एक के ऊपर एक रखते हैं। इन व्यावहारिक सिद्धांतों को ध्यान में रखें।

  • परतों में बचाव करें: input validation → output filtering → execution isolation (sandbox) → लगातार निगरानी, एक के ऊपर एक रखें।
  • Least privilege: किसी agent को कुछ भी करने की tool अनुमतियाँ मत दें। उसे केवल उन्हीं कार्यों तक सीमित रखें जिनकी ज़रूरत है (permission डिज़ाइन मायने रखता है)।
  • मानव की मंज़ूरी: "अपरिवर्तनीय कार्रवाइयों" — ट्रांसफर, डिलीट, बाहरी भेजना — के लिए एक मानव जाँच डालें।
  • निगरानी जारी रखें: हमले की तकनीकें विकसित होती रहती हैं। logs पर नज़र रखें, नए patterns का पता लगाएँ, और अपडेट करें।

※ tool नाम और खतरों की श्रेणियाँ विभिन्न guides व खुलासों से ली गई हैं (जून 2026 तक)। सबसे अच्छा सेटअप use case और जोखिम-सहनशीलता के अनुसार बदलता है।

सारांश

AI guardrails पर तीन मुख्य बातें।

  • ये क्या हैं: input/output फ़िल्टर जो किसी LLM ऐप को खतरों से बचाते हैं। model की बुद्धिमत्ता से अलग एक स्वतंत्र सुरक्षा परत।
  • ये किससे बचाते हैं: prompt injection, jailbreak, डेटा लीक, hallucination/हानिकारक output। सबसे ऊपर injection।
  • कैसे बचाएँ: दो परतें (input/output) साथ में defense in depth। least privilege, मानव की मंज़ूरी, और लगातार निगरानी को मिलाएँ।

केवल AI "बनाना" नहीं बल्कि उसे "सुरक्षित रूप से चलाना" ही असली उपयोग की शर्त है। शुरुआत input और output में एक-एक सरल जाँच जोड़ने से करें। पूरी जोखिम-तस्वीर समझने के लिए इसके साथ AI agent की घटनाएँ और AI और साइबर सुरक्षा भी पढ़ें।

FAQ

Q. अगर मैं एक समझदार model (GPT या Claude) इस्तेमाल करूँ, तो क्या फिर भी guardrails चाहिए?

A. हाँ। शीर्ष models में safety सुविधाएँ होती हैं, लेकिन वे prompt injection या indirect हमलों को पूरी तरह नहीं रोक सकतीं। असली संचालन के लिए "defense in depth" — ऐप की तरफ स्वतंत्र guardrails लगाना — अनिवार्य है।

Q. क्या prompt injection को पूरी तरह रोका जा सकता है?

A. फ़िलहाल, 100% बचाव कठिन माना जाता है। इसीलिए केवल input पहचान पर भरोसा करने के बजाय, आप least privilege, मानव की मंज़ूरी, output फ़िल्टर, और निगरानी को एक के ऊपर एक रखकर "नुकसान को सीमित" करते हैं। सबसे बढ़कर, बाहरी डेटा को अविश्वसनीय मानें।

Q. क्या छोटे, अकेले डेवलपर के ऐप्स को इनकी ज़रूरत है?

A. अगर इनमें से कोई भी लागू हो — यह सार्वजनिक है, यह गोपनीय डेटा संभालता है, या यह tools चलाता है — तो हाँ। इसके विपरीत, केवल आपके अपने उपयोग वाले निजी प्रयोग के लिए न्यूनतम ही काफ़ी है। बुनियादी नियम: जोखिम के अनुपात में guardrails लगाएँ।

Q. guardrails और AI evals में क्या अंतर है?

A. evals "मापते हैं कि output अच्छा है या बुरा"; guardrails "खतरनाक input/output को उसी जगह रोक देते हैं।" अलग भूमिकाएँ, साथ में उपयोग होती हैं। रिश्ता यह है: evals जो कमज़ोरियाँ ढूँढते हैं, उन्हें guardrails से पैच करें।