Komponibilna AI mikro‑servisna arhitektura za skalabilnu automatizaciju upitnika o sigurnosti

Poduzeća se guše u sve većem toku upitnika o sigurnosti, procjena dobavljača i revizija usklađenosti. Tradicionalni monolitni alati teško prate tempo, osobito kada moraju integrirati s različitim ekosustavima proizvoda, podržavati višestruke jezike i pružati stvarne revizijske zapise u stvarnom vremenu.

Komponibilna mikro‑servisna arhitektura, izgrađena oko velikih jezičnih modela (LLM‑ova) i generiranja prošireno pretragom (RAG), nudi način za skaliranje automatizacije uz očuvanje fleksibilnosti i upravljanja koje regulirane industrije zahtijevaju. U ovom vodiču ćemo:

• Izložiti temeljne principe dizajna koji održavaju sustav sigurnim, revizijskim i proširivim.
• Proći kroz referentnu implementaciju prikazanu Mermaid‑om.
• Pokazati kako svaki servis može biti neovisno implementiran na Kubernetesu, serverless FaaS‑u ili edge runtime‑ovima.
• Ponuditi konkretne preporuke najboljih praksi za upravljanje podacima, promatranje i kontinuirano poboljšanje.

TL;DR: Razdijelite platformu za automatizaciju upitnika na male, jasno definirane servise, postavite LLM‑ove iza bezstanja sloja inferencije i koristite radne tokove temeljene na događajima kako biste održali jedinstveni izvor istine za dokaze i kontrolu verzija.

1. Zašto sastaviti nego izgraditi ogroman monolit?

Komponibilni model prihvaća filozofiju „gradite ono što trebate i zamijenite ono što ne“. Odgovara dinamičnoj prirodi upitnika o sigurnosti, gdje se redovito pojavljuju novi okviri za kontrolu (npr. ISO 27001 Rev 2) i timovi moraju brzo prilagoditi.

2. Temelji arhitektonskih stupova

1. Stateless API Gateway – ulazna točka za UI, SaaS konektore i vanjske alate. Rukuje autentikacijom, validacijom zahtjeva i ograničavanjem brzine.
2. Mikro‑servisi specifični za domenu – svaki enkapsulira ograničeni kontekst:
   • Questionnaire Service – pohranjuje metapodatke upitnika, verzioniranje i zadatke.
   • Evidence Service – upravlja artefaktima (politike, screenshotovi, revizijski zapisi) u nepromjenjivom objekt‑storeu.
   • AI Orchestration Service – sastavlja promptove, pokreće RAG pipeline‑e i vraća nacrte odgovora.
   • Change‑Detection Service – prati promjene dokaza, pokreće ponovno vrednovanje zahvaćenih odgovora.
   • Notification Service – šalje Slack, Teams ili email obavijesti dionicima.
3. Event Bus (Kafka / Pulsar) – osigurava at‑least‑once isporuku domena događaja (npr. EvidenceUploaded, AnswerDrafted).
4. Observability Stack – OpenTelemetry trace‑ovi kroz servise, Prometheus metrika i Loki zapisi.
5. Policy‑as‑Code Engine – procjenjuje pravila usklađenosti (napisana u Rego ili OPA) prije nego što se odgovor označi „finalnim“.

Svi servisi komuniciraju putem gRPC (za nisku latenciju) ili REST (za vanjske integracije). Dizajn potiče glupe cijevi, pametni krajnji – poslovna logika živi tamo gdje pripada, dok cijev samo prenosi poruke.

3. Tok podataka – od pitanja do revizijskog odgovora

Ispod je Mermaid dijagram koji vizualizira tipičan životni ciklus zahtjeva.

  flowchart TD
    subgraph UI["Korisničko sučelje"]
        UI1["\"Web UI\""] -->|Pošalji upitnik| AG["\"API Gateway\""]
    end

    AG -->|Autentikacija & Validacija| QMS["\"Questionnaire Service\""]
    QMS -->|Dohvati predložak| AIOS["\"AI Orchestration Service\""]
    AIOS -->|Preuzmi relevantne dokaze| ES["\"Evidence Service\""]
    ES -->|Objekt dokaza| AIOS
    AIOS -->|Generiraj nacrt odgovora| RAG["\"RAG Pipeline\""]
    RAG -->|LLM izlaz| AIOS
    AIOS -->|Spremi nacrt| QMS
    QMS -->|Emitiraj AnswerDrafted| EB["\"Event Bus\""]
    EB -->|Okida| CDS["\"Change‑Detection Service\""]
    CDS -->|Ponovo pokreni ako su dokazi promijenjeni| AIOS
    CDS -->|Emitiraj AnswerUpdated| EB
    EB -->|Obavijesti| NS["\"Notification Service\""]
    NS -->|Pošalji u 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

Ključni momenti u toku:

1. Korisnik predaje novi upitnik ili odabire postojeći.
2. API Gateway provjerava JWT, provjerava brzinu, prosljeđuje zahtjev Questionnaire Service‑u.
3. Questionnaire Service povlači predložak upitnika i šalje događaj AI Orchestration Service‑u.
4. AI Orchestration izvršava korak pretrage – upita Evidence Service za sve artefakte koji su relevantni za trenutnu kontrolu (koristeći vektorsku sličnost ili ključne riječi).
5. Dohvaćeni kontekst, zajedno s predložakom prompta, podupiru RAG pipeline (npr. openAI/gpt‑4o‑preview).
6. Nacrt odgovora se pohranjuje natrag u Questionnaire Service, označen kao „čeka reviziju“.
7. Change‑Detection Service prati učitavanja novih dokaza. Ako se politika ažurira, ponovno aktivira RAG pipeline za pogođene odgovore.
8. Konačni revizori prihvaćaju ili uređuju nacrt; pri prihvaćanju, Policy‑as‑Code Engine potvrđuje da odgovor zadovoljava sva pravila prije nego što se trajno zabilježi u nepromjenjivi revizijski zapis.

4. Detalji implementacije

4.1. API Gateway (Envoy + OIDC)

• Routing – POST /questionnaires/:id/answers → questionnaire-service.
• Security – Nametanje opsega (questionnaire:write).
• Rate limiting – 100 zahtjeva/min po klijentu radi zaštite troškova LLM‑a.

4.2. Questionnaire Service (Go)

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

• Koristi PostgreSQL za relacijske podatke, EventStoreDB za domenske događaje.
• Izlaže gRPC metode GetTemplate, SaveDraft, FinalizeAnswer.

4.3. Evidence Service (Python + FastAPI)

• Pohranjuje datoteke u MinIO ili AWS S3 uz enkripciju na razini bucket‑a.
• Indeksira sadržaj u Qdrant (vektorska DB) radi pretrage sličnosti.
• Nudi endpoint POST /search koji prima upit i vraća top‑k ID‑ove artefakata.

4.4. AI Orchestration Service (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 – kombinira vektorsku pretragu s system promptom koji instruiše model da citira ID‑ove dokaza.
• Caching – Pohranjuje generirane odgovore 24 h kako bi izbjegao duple LLM pozive.

4.5. Change‑Detection Service (Rust)

• Pretplaćuje se na EvidenceUploaded događaje.
• Izračunava hash novog artefakta i izvodí diff nasuprot postojećim dokazima povezanima s svakom kontrolom.
• Ako diff premaši konfigurabilni prag, objavljuje AnswerRequiresRegen.

4.6. Notification Service (Node.js)

• Prima AnswerDrafted, AnswerFinalized, AnswerRequiresRegen.
• Formatira Slack blokove, Teams Adaptive Cards ili email predloške.
• Podržava deduplication – obavijest se šalje najviše jednom po promjeni po upitniku.

5. Sigurnost i upravljanje

6. Strategije skaliranja

1. Horizontal Pod Autoscaling (HPA) – skalirajte AI Orchestration podove prema GPU utilaciji (nvidia.com/gpu).
2. Burst‑able queues – koristite Kafka particioniranje za izolaciju visoko prometnih najmodavaca.
3. Smanjenje hladnog starta – održavajte zagrijavu grupu kontejnera za LLM inference (npr. pomoću KEDA s prilagođenim skalera).
4. Kontrola troškova – primijenite budgetiranje tokena po najmodavcu; automatski ograničite ili naplaćujte prekomjernu potrošnju.

7. Promatranje i kontinuirano unapređenje

• Distribuirano praćenje – OpenTelemetry spans od UI‑a → API Gateway → AI Orchestration → RAG → Evidence Service.
• Metrike – answer_draft_latency_seconds, evidence_upload_bytes, llm_token_usage.
• Log agregacija – Strukturalni JSON zapisi s request_id proslijeđenim kroz sve servise.
• Petlja povratne informacije – Nakon finalizacije odgovora, zabilježite komentare revizora (review_score). Učitajte ih u reinforcement learning model koji prilagođava temperaturu prompta ili bira alternativne izvore dokaza.

8. Korak‑po‑korak plan migracije za postojeće timove

Inkrementalnim usvajanjem komponibilne arhitekture timovi izbjegavaju rizik „big‑bang“ i mogu pokazati rani ROI (često 30‑50 % smanjenje vremena za obradu upitnika).

9. Buduće pripreme stacka

• Federated Learning – Trenirati lake adaptera na podacima svakog najmodavca bez premještanja sirovih dokaza, čime se povećava relevantnost odgovora uz poštivanje suvereniteta podataka.
• Zero‑Trust Service Mesh – Koristiti Istio ili Linkerd s mutual TLS-om za osiguranje međuservičnog prometa.
• Semantička upravljačka pravila – Proširiti Policy‑as‑Code engine tako da ne provjerava samo sadržaj odgovora, nego i semantičku sličnost između dokaza i jezika kontrola.
• Generativna trasabilnost – Pohraniti točnu temperaturu, top‑p i sistemski prompt uz svaki odgovor radi forenzičke inspekcije.

10. Zaključak

Komponibilna mikro‑servisna arhitektura pretvara automatizaciju upitnika o sigurnosti iz bolnog ručnog zadatka u skalabilni, revizijski i kontinuirano poboljšavajući motor. Razdvajajući odgovornosti, koristeći LLM‑ove putem bezznačajnog RAG sloja i povezujući sve pomoću događajnog okvira, organizacije mogu:

• Odgovarati na procjene dobavljača u minutama, umjesto dana.
• Držati dokaze uvijek ažurnim uz automatizirano otkrivanje promjena.
• Pružiti regulatorima jasan, nepromjenjiv revizijski zapis.

Započnite malim, iterirajte brzo i dopustite da vas filozofija mikro‑servisa vodi prema budućnosti u kojoj je usklađenost značajka, a ne usko grlo.

Pogledajte također

• OPA Policy‑as‑Code za mikro‑servise