स्केलेबल सुरक्षा प्रश्नावली स्वचालन के लिए कंपोज़ेबल एआई माइक्रो‑सेवाओं की आर्किटेक्चर

एंटरप्राइज़ेज़ सुरक्षा प्रश्नावली, विक्रेता आकलन और अनुपालन ऑडिट की लगातार बढ़ती धारा में डूब रही हैं। पारंपरिक मोनोलिथिक टूल्स इस गति से ताल नहीं मिला पाते, ख़ासकर जब उन्हें विभिन्न उत्पाद इकोसिस्टम्स के साथ एकीकृत करना होता है, बहुभाषी अनुरोधों को समर्थन देना होता है, और रीयल‑टाइम ऑडिट ट्रेल प्रदान करना होता है।

एक कंपोज़ेबल माइक्रो‑सेवा आर्किटेक्चर, जो बड़े भाषा मॉडलों (LLMs) और रिट्रिवल‑ऑगमेंटेड जनरेशन (RAG) के चारों ओर निर्मित है, स्वचालन को स्केल करने का एक तरीका प्रदान करता है, साथ ही नियामक उद्योगों की माँग वाली लचीलापन और शासन को भी बनाए रखता है। इस गाइड में हम करेंगे:

• कोर डिज़ाइन सिद्धांतों को रेखांकित करना जो सिस्टम को सुरक्षित, ऑडिटेबल और विस्तारित करने योग्य बनाते हैं।
• मेरमेड के साथ दर्शाए गए एक रेफ़रेंस इम्प्लीमेंटेशन को walkthrough करना।
• दिखाना कि प्रत्येक सर्विस को कैसे स्वतंत्र रूप से कुबर्नेटिस, सर्वरलेस FaaS, या एज रनटाइम्स पर डिप्लॉय किया जा सकता है।
• डेटा गवर्नेंस, ऑब्ज़रवेबिलिटी और निरंतर सुधार के लिए ठोस सर्वश्रेष्ठ‑प्रैक्टिस सिफ़ारिशें प्रदान करना।

TL;DR: प्रश्नावली स्वचालन प्लेटफ़ॉर्म को छोटे, स्पष्ट रूप से परिभाषित सेवाओं में विभाजित करें, LLM को एक स्टेटलेस इनफ़रेंस लेयर के पीछे रखें, और सिंगल सोर्स ऑफ ट्रुथ को बनाए रखने के लिए इवेंट‑ड्रिवन पाइपलाइन का उपयोग करें, जिससे प्रमाण और संस्करण नियंत्रण दोनों सम्भव हो।

1. क्यों एक विशाल मोनोलिथ बनाने की बजाय कंपोज़ करने का चयन करें?

कंपोज़ेबल मॉडल “आप वही बनाते हैं जो आपको चाहिए, और आप वही बदलते हैं जो अब ज़रूरत नहीं” सिद्धांत को अपनाता है। यह सुरक्षा प्रश्नावली की गतिशील प्रकृति से मेल खाता है, जहाँ नए कंट्रोल फ्रेमवर्क (जैसे ISO 27001 Rev 2) नियमित रूप से आते हैं और टीमों को तेज़ी से अनुकूल होना पड़ता है।

2. कोर आर्किटेक्चरल स्तंभ

1. स्टेटलेस API गेटवे – UI, SaaS कनेक्टर्स और बाहरी टूल्स के लिए एंट्री पॉइंट। ऑथेंटिकेशन, अनुरोध वैलिडेशन और थ्रॉटलिंग को संभालता है।
2. डोमेन‑स्पेसिफिक माइक्रो‑सेवाएँ – प्रत्येक बाउंडेड कॉन्टेक्स्ट को संलग्न करता है:
   • प्रश्नावली सेवा – प्रश्नावली मेटाडाटा, वर्जनिंग और टास्क असाइनमेंट को सहेजती है।
   • एविडेंस सेवा – आर्टिफैक्ट्स (नीतियां, स्क्रीनशॉट, ऑडिट लॉग) को इम्यूटेबल ऑब्जेक्ट स्टोर में प्रबंधित करती है।
   • AI ऑर्केस्ट्रेशन सेवा – प्रॉम्प्ट्स को कंपोज़ करती है, RAG पाइपलाइन चलाती है, और उत्तर ड्राफ्ट लौटाती है।
   • चेंज‑डिटेक्शन सेवा – एविडेंस अपडेट्स को देखती है, प्रभावित उत्तरों के पुनर्मूल्यांकन को ट्रिगर करती है।
   • नोटिफ़िकेशन सेवा – स्लैक, टीम्स या ईमेल इवेंट्स को स्टेकहोल्डर्स तक पुश करती है।
3. इवेंट बस (Kafka / Pulsar) – EvidenceUploaded, AnswerDrafted आदि डोमेन इवेंट्स की कम से कम एक बार डिलीवरी सुनिश्चित करती है।
4. ऑब्ज़रवेबिलिटी स्टैक – OpenTelemetry ट्रेस, Prometheus मेट्रिक्स और Loki लॉग्स।
5. पॉलिसी‑ऐज़‑कोड इंजन – उत्तर को “फ़ाइनल” चिह्नित करने से पहले Rego या OPA में लिखे अनुपालन नियमों का मूल्यांकन करता है।

सभी सेवाएँ gRPC (लो लेटेंसी के लिए) या REST (बाहरी इंटीग्रेशन के लिए) के माध्यम से संवाद करती हैं। डिज़ाइन “डंब पाइप, स्मार्ट एंडपॉइंट्स” को प्रोत्साहित करता है—बिज़नेस लॉजिक जहाँ होना चाहिए, वहीं रहता है, जबकि बस केवल संदेश ले जाता है।

3. डेटा फ्लो – प्रश्न से ऑडिटेबल उत्तर तक

नीचे एक मेरमेड डायग्राम है जो एक सामान्य अनुरोध लाइफ़साइकल को दर्शाता है।

  flowchart TD
    subgraph UI["User Interface"]
        UI1["\"Web UI\""] -->|Submit questionnaire| AG["\"API Gateway\""]
    end

    AG -->|Auth & Validate| QMS["\"Questionnaire Service\""]
    QMS -->|Fetch template| AIOS["\"AI Orchestration Service\""]
    AIOS -->|Retrieve relevant evidence| ES["\"Evidence Service\""]
    ES -->|Evidence objects| AIOS
    AIOS -->|Generate draft answer| RAG["\"RAG Pipeline\""]
    RAG -->|LLM output| AIOS
    AIOS -->|Store draft| QMS
    QMS -->|Emit AnswerDrafted| EB["\"Event Bus\""]
    EB -->|Trigger| CDS["\"Change‑Detection Service\""]
    CDS -->|Re‑run if evidence changed| AIOS
    CDS -->|Emit AnswerUpdated| EB
    EB -->|Notify| NS["\"Notification Service\""]
    NS -->|Push to Slack/Email| UI

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style AG fill:#bbf,stroke:#333,stroke-width:1px
    style QMS fill:#bfb,stroke:#333,stroke-width:1px
    style AIOS fill:#ffb,stroke:#333,stroke-width:1px
    style ES fill:#fbb,stroke:#333,stroke-width:1px
    style RAG fill:#fdd,stroke:#333,stroke-width:1px
    style CDS fill:#ddf,stroke:#333,stroke-width:1px
    style NS fill:#cfc,stroke:#333,stroke-width:1px

फ़्लो में मुख्य क्षण:

1. उपयोगकर्ता नई प्रश्नावली सबमिट करता है या मौजूदा को चुनता है।
2. API गेटवे JWT वैलिडेट करता है, रेट‑लिमिट चेक करता है, और क्वेश्चननेयर सर्विस को फ़ॉरवर्ड करता है।
3. प्रश्नावली सेवा टेम्पलेट खींचती है और AI ऑर्केस्ट्रेशन सेवा को इवेंट पोस्ट करती है।
4. AI ऑर्केस्ट्रेशन रिट्रिवल स्टेप करता है—यह एविडेंस सर्विस को सभी उन आर्टिफैक्ट्स की पूछताछ करता है जो वर्तमान कंट्रोल से संबंधित हैं (वेक्टर समानता या कीवर्ड मैच के माध्यम से)।
5. प्राप्त कंटेक्स्ट और प्रॉम्प्ट टेम्पलेट को RAG पाइपलाइन में भेजा जाता है (उदा., openAI/gpt‑4o‑preview)।
6. ड्राफ्ट उत्तर प्रश्नावली सेवा में वापस संग्रहीत किया जाता है, “पेंडिंग रिव्यू” चिह्नित।
7. चेंज‑डिटेक्शन सेवा नए एविडेंस अपलोड पर नज़र रखती है। यदि कोई नीति अपडेट होती है, तो वह प्रभावित उत्तरों के लिए RAG पाइपलाइन को फिर से ट्रिगर करती है।
8. अंतिम समीक्षक ड्राफ्ट को स्वीकार या संपादित करता है; स्वीकार करने पर पॉलिसी‑ऐज़‑कोड इंजन सभी नियम बाधाओं को संतुष्ट करता है, फिर इसे इम्यूटेबल ऑडिट लॉग में कमिट कर दिया जाता है।

4. इम्प्लीमेंटेशन विवरण

4.1. API गेटवे (Envoy + OIDC)

• रूटिंग – POST /questionnaires/:id/answers → questionnaire-service।
• सिक्योरिटी – स्कोप लागू (questionnaire:write)।
• रेट‑लिमिट – प्रति टेनेंट 100 रिक्वेस्ट/मिनट, जिससे नीचे‑स्थ LLM लागत सुरक्षित रहती है।

4.2. प्रश्नावली सेवा (Go)

type Questionnaire struct {
    ID          string            `json:"id"`
    Version     int               `json:"version"`
    Controls    []Control        `json:"controls"`
    Drafts      map[string]Answer `json:"drafts"` // key = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}

• रिलेशनल डेटा के लिए PostgreSQL, इवेंट्स के लिए EventStoreDB।
• gRPC मेथड्स: GetTemplate, SaveDraft, FinalizeAnswer।

4.3. एविडेंस सेवा (Python + FastAPI)

• फ़ाइलें MinIO या AWS S3 में एन्क्रिप्शन के साथ संग्रहीत।
• सामग्री को Qdrant (वेक्टर DB) में इंडेक्स किया जाता है, जिससे समानता खोज संभव होती है।
• एंडपॉइंट POST /search क्वेरी लेता है और टॉप‑k आर्टिफैक्ट IDs लौटाता है।

4.4. AI ऑर्केस्ट्रेशन सेवा (Python)

def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""You are a compliance specialist.
    Using the following evidence, answer the question concisely:\n{context}\n\nQuestion: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content

• RAG – वेक्टर सर्च को एक सिस्टम प्रॉम्प्ट के साथ मिलाते हैं जो मॉडल को एविडेंस IDs उद्धृत करने का निर्देश देता है।
• कैशिंग – उत्पन्न उत्तर 24 घंटे तक स्टोर होते हैं, जिससे समान LLM कॉल दोहराए नहीं जाते।

4.5. चेंज‑डिटेक्शन सेवा (Rust)

• EvidenceUploaded इवेंट्स को सबस्क्राइब करती है।
• नए आर्टिफैक्ट का हैश गणना कर मौजूदा एविडेंस के साथ डिफ निकालती है।
• यदि डिफ़ निर्धारित थ्रेशहोल्ड से अधिक हो, तो AnswerRequiresRegen प्रकाशित करती है।

4.6. नोटिफ़िकेशन सेवा (Node.js)

• AnswerDrafted, AnswerFinalized, AnswerRequiresRegen को सुनती है।
• स्लैक ब्लॉक्स, टीम्स एडैप्टिव कार्ड या ईमेल टेम्प्लेट बनाती है।
• डेडुप्लीकेशन – प्रत्येक प्रश्नावली में बदलाव के लिए एक बार ही नोटिफ़िकेशन भेजती है।

5. सुरक्षा एवं गवर्नेंस

6. स्केलिंग रणनीतियाँ

1. हॉरिज़ॉन्टल पॉड ऑटोस्केलिंग (HPA) – GPU उपयोगिता (nvidia.com/gpu) के आधार पर AI ऑर्केस्ट्रेशन पॉड्स को स्केल करें।
2. बर्स्ट‑एबल क्यूज़ – उच्च‑ट्रैफ़िक टेनेंट्स को अलग करने के लिए Kafka पार्टिशनिंग उपयोग करें।
3. कोल्ड‑स्टार्ट कमी – LLM इनफ़रेंस सर्वर के लिए एक वार्म पूल रखें (उदा., KEDA के कस्टम स्केलर से)।
4. कॉस्ट कंट्रोल – टेनेंट‑वाइज़ टोकन‑आधारित बजट लागू करें; ओवर‑यूज़ पर स्वचालित थ्रॉटल या चार्जिंग लागू करें।

7. ऑब्ज़रवेबिलिटी और निरंतर सुधार

• डिस्ट्रिब्यूटेड ट्रेसिंग – OpenTelemetry स्पैन UI अनुरोध → API गेटवे → AI ऑर्केस्ट्रेशन → RAG → एविडेंस सर्विस को कवर करते हैं।
• मेट्रिक्स – answer_draft_latency_seconds, evidence_upload_bytes, llm_token_usage।
• लॉग एग्रीगेशन – प्रत्येक सर्विस में request_id को प्रोपेगेट करें और संरचित JSON लॉग्स रखें।
• फ़ीडबैक लूप – उत्तर फ़ाइनल करने के बाद समीक्षक टिप्पणी (review_score) एकत्र करें। इन्हें रीइन्फोर्समेंट लर्निंग मॉडल में फ़ीड करें जो प्रॉम्प्ट टेम्परेचर या वैकल्पिक एविडेंस स्रोतों को समायोजित करता है।

8. मौजूदा टीमों के लिए चरण‑बद्ध माइग्रेशन पाथ

इन चरणों को क्रमिक रूप से अपनाकर टीमें “बिग‑बैंग” जोखिम से बचती हैं और शीघ्र ROI प्रदर्शित कर सकती हैं (आमतौर पर 30‑50 % प्रश्नावली टर्नअराउंड में कमी)।

9. स्टैक के भविष्य‑प्रूफ़िंग उपाय

• फ़ेडरेटेड लर्निंग – प्रत्येक टेनेंट के डेटा पर हल्के एडाप्टर ट्रेन करें, बिना कच्चा डेटा बाहर निकाले, जिससे उत्तर की प्रासंगिकता बढ़े और डेटा सर्वेयरिटी बनी रहे।
• ज़ीरो‑ट्रस्ट सर्विस मेष – Istio या Linkerd के साथ mTLS का उपयोग करके इंटर्सर्विस ट्रैफ़िक को सुरक्षित रखें।
• सेमांटिक गवर्नेंस – पॉलिसी‑ऐज़‑कोड इंजन को एविडेंस और कंट्रोल भाषा के बीच सेमांटिक समानता को वैलिडेट करने के लिए विस्तारित करें।
• जेनरेटिव ट्रेसबिलिटी – प्रत्येक उत्तर के साथ उपयोग किए गए LLM पैरामीटर (temperature, top‑p, सिस्टम प्रॉम्प्ट) को ऑडिट लॉग में संग्रहीत करें, ताकि फॉरेन्सिक जांच संभव हो।

10. निष्कर्ष

एक कंपोज़ेबल माइक्रो‑सेवा आर्किटेक्चर सुरक्षा प्रश्नावली स्वचालन को कष्टदायक मैन्युअल कार्य से स्केलेबल, ऑडिटेबल और निरंतर बेहतर बनने वाले इंजन में बदल देता है। जिम्मेदारियों को अलग करके, LLM को स्टेटलेस RAG लेयर के पीछे रखकर, और इवेंट‑ड्रिवन बैकबोन के साथ सिंगल सोर्स ऑफ ट्रुथ को कायम रखकर, संगठन:

• विक्रेता आकलनों का उत्तर कुछ मिनटों में दे सकते हैं, दिनों की बजाय।
• डेटा गवर्नेंस और ऑडिट ट्रेल को हमेशा अपडेट रख सकते हैं।
• नियामकों को स्पष्ट, इम्यूटेबल प्रमाण प्रदान करके अनुपालन का बोझ घटा सकते हैं।

छोटे से शुरू करें, तेज़ी से दोहराएँ, और माइक्रो‑सेवा सिद्धांत को गाइड बनाकर वह भविष्य सुनिश्चित करें जहाँ अनुपालन एक फ़ीचर है, बाधा नहीं।

देखें भी

• OPA पॉलिसी‑ऐज़‑कोड फॉर माइक्रो‑सेवाएँ