Koostettavissa oleva AI-mikropalveluarkkitehtuuri skaalautuvaan turvallisuuskyselyautomaation

Yritykset hukkuvat yhä kasvavan turvallisuuskyselyjen, toimittajaraporttien ja vaatimustenmukaisuustarkastusten aallon alla. Perinteiset monoliittiset työkalut eivät pysy perässä, erityisesti kun niiden täytyy integroida erilaisiin tuotekohtaisiin ekosysteemeihin, tukea monikielisiä pyyntöjä ja tarjota reaaliaikaisia auditointilokeja.

Koostettava mikropalveluarkkitehtuuri, joka on rakennettu suurten kielimallien (LLM) ja hakupohjaisen generoinnin (RAG) ympärille, tarjoaa tavan skaalata automaatiota säilyttäen joustavuuden ja hallittavuuden, joita säädellyt alat vaativat. Tässä oppaassa:

• Käymme läpi ydin­suunnitteluperiaatteet, jotka pitävät järjestelmän turvallisena, auditointikelpoisena ja laajennettavana.
• Käymme läpi viite­implementaation, joka on kaavattu Mermaid‑kaavioon.
• Näytämme, miten jokainen palvelu voidaan ottaa käyttöön itsenäisesti Kubernetesissa, serverless‑FaaS‑ympäristössä tai reunapalvelimilla.
• Annamme konkreettisia parhaiden käytäntöjen suosituksia tietohallinnon, observatiivisuuden ja jatkuvan parantamisen osalta.

TL;DR: Pilko kyselyautomaatioplatformi pieniin, hyvin määriteltyihin palveluihin, anna LLM‑mallien toimia tilattoman inferenssikerroksen takana ja hyödynnä tapahtumapohjaisia putkistoja säilyttääksesi totuudenlähteen todisteille ja versionhallinnalle.

1. Miksi koottaa sen sijaan, että rakennettaisiin valtava monoliitti?

Koostettava malli omaksuu ”rakennat vain mitä tarvitset ja korvaat vain mitä et enää halua” -filosofian. Se sopii hyvin turvallisuuskyselyiden dynaamiseen luonteeseen, jossa uudet hallintakehykset (esim. ISO 27001 Rev 2) ilmestyvät säännöllisesti ja tiimien on pystyttävä reagoimaan nopeasti.

2. Keskeiset arkkitehtuuripilarit

1. Tilaton API‑yhdyskäytävä – UI:n, SaaS‑liittimien ja ulkoisten työkalujen sisäänmeno. Käsittelee autentikoinnin, pyynnön validoinnin ja nopeusrajoituksen.
2. Toimialakohtaiset mikropalvelut – kukin kapseloi rajatun kontekstin:
   • Questionnaire Service – tallentaa kyselyn metatiedot, versioinnin ja tehtävänjakojen tiedot.
   • Evidence Service – hallinnoi artefakteja (politiikat, kuvakaappaukset, auditointilogit) muuttumattomassa objektivarastossa.
   • AI Orchestration Service – kokoaa promptit, ajaa RAG‑putken ja palauttaa vastausluonnokset.
   • Change‑Detection Service – tarkkailee evidenssin päivityksiä, käynnistää uudelleenarvioinnin vaikuttaville vastauksille.
   • Notification Service – työntää Slack‑, Teams‑ tai sähköpostiviestejä sidosryhmille.
3. Tapahtumaväylä (Kafka / Pulsar) – takaa ainakin kerran -toimituksen domain‑tapahtumille (esim. EvidenceUploaded, AnswerDrafted).
4. Observatiivisuus‑pinon – OpenTelemetry‑spanit palvelujen välillä, Prometheus‑metriikat ja Loki‑lokit.
5. Policy‑as‑Code‑moottori – arvioi vaatimustenmukaisuussäännöt (kirjoitettu Rego‑tai OPA‑kielellä) ennen kuin vastaus merkitään “lopulliseksi”.

Kaikki palvelut kommunikoivat gRPC‑rajapintojen (matala latenssi) tai REST‑rajapintojen (ulkoiset integraatiot) kautta. Suunnittelu kannustaa tyhjiin putkiin, älykkäisiin päätelaitteisiin—liiketoimintalogiikka asuu siellä, missä sen kuuluu, kun taas väylä toimii vain viestien kuljettajana.

3. Tietovirta – Kysymyksestä auditointikelpoiseen vastaukseen

Alla on Mermaid‑kaavio, joka visualisoi tyypillisen pyynnön elinkaaren.

  flowchart TD
    subgraph UI["Käyttäjärajapinta"]
        UI1["Web-käyttöliittymä"] -->|Lähetä kysely| AG["API-yhdyskäytävä"]
    end

    AG -->|Autentikoi & validoi| QMS["Questionnaire Service"]
    QMS -->|Hae mallipohja| AIOS["AI Orchestration Service"]
    AIOS -->|Hae relevantti evidenssi| ES["Evidence Service"]
    ES -->|Evidenssiobjektit| AIOS
    AIOS -->|Generoi luonnos vastaus| RAG["RAG‑putki"]
    RAG -->|LLM‑output| AIOS
    AIOS -->|Tallenna luonnos| QMS
    QMS -->|Lähetä AnswerDrafted‑tapahtuma| EB["Tapahtumaväylä"]
    EB -->|Käynnistä| CDS["Change‑Detection Service"]
    CDS -->|Uudelleenarvioi jos evidenssi muuttui| AIOS
    CDS -->|Lähetä AnswerUpdated‑tapahtuma| EB
    EB -->|Ilmoita| NS["Notification Service"]
    NS -->|Push Slackiin/Sähköpostiin| 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

Tärkeitä hetkiä virrassa:

1. Käyttäjä lähettää uuden kyselyn tai valitsee olemassa olevan.
2. API‑yhdyskäytävä validoi JWT‑tunnuksen, tarkistaa nopeusrajoituksen ja välittää pyynnön Questionnaire Service‑palveluun.
3. Questionnaire Service hakee kyselyn mallipohjan ja lähettää tapahtuman AI Orchestration Service‑palveluun.
4. AI Orchestration tekee haku‑vaiheen – se kysyy Evidence Service‑palvelulta kaikki merkitykselliset artefaktit kyseiseen kontrolliin (vektorinen samankaltaisuus tai avainsanahaku).
5. Haetut kontekstit yhdistetään prompt‑malliin ja syötetään RAG‑putkeen (esim. openAI/gpt‑4o‑preview).
6. Luonnosvastauksen tallennetaan takaisin Questionnaire Service‑palveluun merkinnällä “odottaa tarkistusta”.
7. Change‑Detection Service tarkkailee uusia evidenssi‑latauksia. Jos politiikka päivittyy, se käynnistää RAG‑putken vaikutettuihin vastauksiin uudelleen.
8. Lopulliset tarkistajat hyväksyvät tai muokkaavat luonnosta; hyväksynnän jälkeen Policy‑as‑Code‑moottori varmistaa, että vastaus täyttää kaikki sääntöehdot ennen kuin se kirjataan muuttumattomaan auditointilokiin.

4. Toteutuksen yksityiskohdat

4.1. API‑yhdyskäytävä (Envoy + OIDC)

• Reititys – POST /questionnaires/:id/answers → questionnaire-service.
• Turvallisuus – Pakota scope‑t (questionnaire:write).
• Nopeusrajoitus – 100 pyyntöä/min per tenant, jotta LLM‑kustannuksia suojataan.

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"` // avain = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}

• Käyttää PostgreSQL‑tietokantaa relaatiotietoihin ja EventStoreDB‑tapahtumavalikoimaan.
• Tarjoaa gRPC‑metodit GetTemplate, SaveDraft, FinalizeAnswer.

4.3. Evidence Service (Python + FastAPI)

• Tallentaa tiedostot MinIO‑ tai AWS S3‑säiliöihin säilyttämällä buksin‑tasolla salauksen.
• Indeksoi sisällön Qdrant‑vektoritietokantaan hakukelpoisuutta varten.
• Tarjoaa päätepisteen POST /search joka vastaanottaa kyselyn ja palauttaa top‑k artefaktin ID:t.

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"""Olet vaatimustenmukaisuuden asiantuntija.
    Käyttäen alla olevaa evidenssiä, vastaa kysymykseen tiiviisti:\n{context}\n\nKysymys: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content

• RAG – Yhdistää vektorihakun ja järjestelmä‑promptin, joka ohjeistaa mallin listaamaan evidenssi‑ID:t.
• Välimuisti – Säilyttää luodut vastaukset 24 h, jotta samat LLM‑kutsut vältetään.

4.5. Change‑Detection Service (Rust)

• Tilaa EvidenceUploaded‑tapahtumat.
• Laskee hashin uudelle artefaktille ja vertaa sitä olemassa olevaan evidenssiin kullakin kontrollilla.
• Jos ero ylittää konfiguroitavan rajan, julkaisee AnswerRequiresRegen‑tapahtuman.

4.6. Notification Service (Node.js)

• Kuuntelee AnswerDrafted, AnswerFinalized, AnswerRequiresRegen.
• Muotoilee Slack‑lohkoja, Teams‑Adaptive‑Cardeja tai sähköpostipohjia.
• Tukee deduplikointia – ilmoitus lähetetään vain kerran per muutos per kysely.

5. Turvallisuus & Hallittavuus

6. Skaalausstrategiat

1. Horisontaalinen pod‑skaalaus (HPA) – Skaalaa AI Orchestration -podi GPU‑käytön (nvidia.com/gpu) perusteella.
2. Burst‑kestävät jonot – Hyödynnä Kafka‑partitiointia eristääksesi liikenteen isojen tenanttien välillä.
3. Kylmäkäynnistyksen vähennys – Pidä LLM‑inferenzisäiliöiden lämpövarasto aktiivisena KEDA:n avulla (räätälöity skaalaus).
4. Kustannusten hallinta – Ota käyttöön token‑pohjainen budjetointi per tenantti; rajoita tai veloita ylitykset automaattisesti.

7. Observatiivisuus & Jatkuva parantaminen

• Distribuoitu tracing – OpenTelemetry‑spanit UI‑pyynnöstä → API‑yhdyskäytävä → AI Orchestration → RAG → Evidence Service.
• Mittaustiedot – answer_draft_latency_seconds, evidence_upload_bytes, llm_token_usage.
• Lokien aggregointi – Strukturoitu JSON‑loki request_id -tunnisteella, joka kulkee kaikkien palveluiden läpi.
• Palaute‑silmukka – Vastauksen lopullisen hyväksynnän jälkeen kerää tarkastajan kommentit (review_score). Syötä nämä reinforcement learning‑malliin, joka säätää promptin lämpötilaa tai valitsee vaihtoehtoisia evidenssi­lähteitä.

8. Askel‑as‑askel – Siirtymäpolku nykyisille tiimeille

Inkrementaalisesti omaksumalla koostettavan arkkitehtuurin tiimit voivat välttää “big‑bang”‑riskit ja osoittaa varhaisen ROI:n (yleensä 30‑50 % aikaisuusväheneminen kyselyiden läpimenoajassa).

9. Tulevaisuuden kestävä rakenne

• Federated Learning – Kouluta kevyitä adaptoijia jokaisen tenantin omassa datassa siirtämättä raakadataa ulkopuolelle, parantaen vastausten relevanssia säilyttäen datasuvereniteetin.
• Zero‑Trust Service Mesh – Hyödynnä Istio‑ tai Linkerd‑ratkaisua, jossa kaikki sisäiset palvelukutsut on suojattu mutual TLS:llä.
• Semanttinen hallinta – Laajenna Policy‑as‑Code -moottoria tarkistamaan, että ei ainoastaan vastaus sisällä oikeita tietoja, vaan myös evidenssi on semanttisesti yhtenevä kontrollin kielen kanssa.
• Generatiivinen jäljitettävyys – Tallenna tarkat LLM‑asetukset (lämpötila, top‑p, system‑prompt) jokaisen vastauksen yhteyteen forensiikan vuoksi.

10. Yhteenveto

Koostettava mikropalveluarkkitehtuuri muuttaa turvallisuuskyselyautomaatio kivuliaasta käsityöstä skaalautuvaksi, auditointikelpoiseksi ja jatkuvasti kehittyväksi moottoriksi. Jakamalla vastuut, hyödyntämällä LLM‑malleja tilattoman RAG‑kerroksen takana ja yhdistämällä kaikki tapahtumapohjaiseen selkärankaan, organisaatiot voivat:

• Vastaamaan toimittajojen arviointiin minuuteissa eikä päivissä.
• Pitää vaatimustenmukaisuusevidenssi aina ajantasaisena automaattisen muutostunnistuksen avulla.
• Tarjota tarkastajille selkeän, muuttumattoman auditointipolun.

Aloita pienestä, iteroi nopeasti, ja anna mikropalvelu‑filosofian ohjata sinua kohti tulevaisuutta, jossa vaatimustenmukaisuus on ominaisuus, ei pullonkaula.

Katso myös

• OPA Policy‑as‑Code mikropalveluille