
# Aktiivisen oppimisen silmukka älykkäämpään tietoturvakyselyautomaation

## Johdanto

Tietoturvakyselyt, vaatimustenmukaisuustarkastukset ja toimittajariskianalyysit ovat kuuluisia pullonkauloja nopeasti liikkuville SaaS‑yrityksille. Manuaalinen työ, joka vaaditaan standardien lukemiseen, todisteiden paikantamiseen ja narratiivisten vastausten laatimiseen, venyttää kauppasopimusten aikataulua viikkoihin. Procurizen AI‑alusta vähentää tätä kitkaa jo **automaattisesti luomalla vastauksia**, **kartoittelemalla todisteita** ja **järjestämällä työnkulkuja**. Kuitenkin pelkkä suuri kielimalli (LLM) ei voi taata täydellistä tarkkuutta alati muuttuvassa sääntelyympäristössä.

Tässä astuu kuvaan **aktiivinen oppiminen** – koneoppimisen paradigma, jossa malli valikoivasti pyytää ihmisen syötettä eniten epäselvistä tai korkean riskin tapauksista. Kun aktiivisen oppimisen palautesilmukka upotetaan kyselyputkeen, jokainen vastaus muuttuu datapisteeksi, joka opettaa järjestelmää parantumaan. Tuloksena on **itsensä optimoiva vaatimustenmukaisuuden avustaja**, joka älykköönsä kasvaa jokaisen täytetyn kyselyn myötä, vähentää ihmisen tarkistusaikaa ja luo läpinäkyvän auditointipolun.

Tässä artikkelissa käsittelemme:

1. Miksi aktiivinen oppiminen on tärkeä tekijä tietoturvakyselyautomaation kannalta.  
2. Procurizen aktiivisen oppimisen silmukan arkkitehtuuri.  
3. Keskeiset algoritmit: epävarmuusotanta, luottamuspisteytys ja kehotteen mukautus.  
4. Toteutuksen vaiheet: datankeruu, mallin uudelleenkoulutus ja hallinto.  
5. Todelliset vaikutusmittarit ja parhaita käytäntöjä.

---

## 1. Miksi aktiivinen oppiminen on pelin muuttaja

### 1.1 Yhdenkertaisen generoinnin rajoitukset

LLM:t loistavat mallin täydennyksessä, mutta ne eivät sisällä **alan‑kohtaisia perusteluja** ilman tarkkoja kehotteita. Tavallinen “luo vastaus” –pyyntö voi tuottaa:

- **Yleisiä kertomuksia**, joista puuttuu vaaditut sääntelyviitteet.  
- **Harhoitettuja todisteita**, jotka eivät kestä tarkistusta.  
- **Epäyhtenäistä terminologiaa** eri kyselyn osioissa.

Pelkkä generointiputki voidaan korjata ainoastaan jälkikäteen, jolloin tiimit joutuvat manuaalisesti muokkaamaan suuria osia tuotoksesta.

### 1.2 Ihmisen näkemys strategisena omaisuutena

Ihmistarkistajat tuovat:

- **Sääntelyosaamista** – esimerkiksi hienovaraiset erot [ISO 27001](https://www.iso.org/standard/27001) ja [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) välillä.  
- **Kontekstitietoisuutta** – tuote‑kohtaiset kontrollit, joita LLM ei pysty päättelemään.  
- **Riskiarviointikykyä** – priorisointi korkeasti vaikuttaville kysymyksille, joiden virhe voi pysäyttää kaupan.

Aktiivinen oppiminen käsittelee tätä asiantuntemusta **korkean arvon signaalina** eikä kuluna, pyytäen ihmisiltä vain ne kohdat, joissa malli on epävarma.

### 1.3 Jatkuva vaatimustenmukaisuus liikkuvassa maisemassa

Sääntely kehittyy; uusia standardeja (esim. **AI‑asetus**, **CISPE**) ilmestyy säännöllisesti. Aktiivinen oppiminen voi **uudelleenkalibroida** itseään aina, kun tarkistaja merkitsee poikkeaman, varmistaen että LLM pysyy linjassa uusimpien vaatimusten kanssa ilman täyttä uudelleenkoulutusta. EU‑asiakkaille suora linkki **[EU AI Act Compliance](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)**‑ohjeistukseen pitää kehotteiden kirjaston ajan tasalla.

---

## 2. Aktiivisen oppimisen silmukan arkkitehtuuri

Silmukka koostuu viidestä tiiviisti kytkeytyneestä komponentista:

1. **Kysymysten vastaanotto & esikäsittely** – normalisoi kyselyformaatteja (PDF, CSV, API).  
2. **LLM‑vastausgeneraattori** – tuottaa alkuluonnoksen hallituilla kehotteilla.  
3. **Epävarmuus‑ ja luottamusanalyysi** – antaa todennäköisyys‑pisteen jokaiselle vastaukselle.  
4. **Ihminen‑silmä‑puskurikeskus** – näyttää vain matalan luottamuksen vastaukset tarkistajalle.  
5. **Palaute‑keruu & mallipäivityspalvelu** – tallentaa tarkistajien korjaukset, päivittää kehotteiden mallipohjia ja käynnistää inkrementaalisen hienosäädön.

Alla on Mermaid‑kaavio, joka visualisoi tiedonvirran.

```mermaid
flowchart TD
    A["\"Kysymysten vastaanotto\""] --> B["\"LLM‑generointi\""]
    B --> C["\"Luottamuspisteytys\""]
    C -->|Korkea luottamus| D["\"Automaattinen julkaisu arkistoon\""]
    C -->|Alhainen luottamus| E["\"Ihmisen tarkistusjono\""]
    E --> F["\"Tarkistajan korjaus\""]
    F --> G["\"Palautevarasto\""]
    G --> H["\"Kehotteen optimizeri\""]
    H --> B
    G --> I["\"Inkrementaalinen mallin hienosäätö\""]
    I --> B
    D --> J["\"Audit‑polku & alkuperä\""]
    F --> J
```

*Keskeiset huomioitavat asiat:*

- **Luottamuspisteytys** käyttää sekä token‑tasoinen entropia LLM:stä että toimialakohtaista riskimallia.  
- **Kehotteen optimizeri** muokkaa kehotteiden mallipohjaa (esim. lisää puuttuvia kontrolliviitteitä).  
- **Inkrementaalinen mallin hienosäätö** käyttää parametri‑tehokkaita tekniikoita kuten **LoRA**, jotta uudet merkitykset otetaan huomioon ilman täyttä uudelleenkoulutusta.  
- **Audit‑polku** kirjaa jokaisen päätöksen, täyttäen sääntelyvaatimusten läpinäkyvyys‑ ja jäljitettävyysvaatimukset.

---

## 3. Silmukan taustalla olevat keskeiset algoritmit

### 3.1 Epävarmuusotanta

Epävarmuusotanta valitsee ne kysymykset, joihin malli on **vähiten varma**. Kaksi yleistä tekniikkaa:

| Tekniikka | Kuvaus |
|-----------|--------|
| **Marginaali‑otanta** | Valitsee tapaukset, joissa kahden parhaan token‑todennäköisyyden välinen erotus on minimaalinen. |
| **Entropia‑perusteinen otanta** | Laskee Shannon‑entropian token‑todennäköisyysjakaumasta; korkeampi entropia → korkeampi epävarmuus. |

Procurizessa yhdistämme molemmat: ensin lasketaan token‑tasoinen entropia, ja sen jälkeen lisätään **riskipaino** kysymyksen sääntelyvaikutuksen perusteella (esim. “Data Retention” vs. “Värimaailma”).

### 3.2 Luottamuspisteytysmalli

Kevyt **gradient‑boosted tree** -malli aggregoi seuraavat ominaisuudet:

- LLM‑token‑entropia  
- Kehotteen relevanssipiste (kosini‑samankaltaisuus kysymyksen ja kehotepohjan välillä)  
- Historian virheprosentti kyseiselle kysymysryhmälle  
- Sääntelyn vaikutuskerroin (tulee tietämyskartasta)

Mallista saadaan luottamuspiste 0 – 1; kynnys (esim. 0,85) määrittää, tarvitseeko vastaus ihmistarkistusta.

### 3.3 Kehotteen mukautus Retrieval‑Augmented Generation (RAG) –menetelmällä

Kun tarkistaja lisää puuttuvan viitteen, järjestelmä tallentaa **todiste‑katkelman** vektorivarastoon. Tulevat generoinnit hakevat tämän katkelman automaattisesti ja rikastuttavat kehotetta:

```
Kehotepohja:
"Vastaa seuraavaan SOC 2 -kysymykseen. Käytä todisteita {{retrieved_citations}}. Rajoita vastaus 150 sanaan."
```

### 3.4 Inkrementaalinen hienosäätö LoRA‑tekniikalla

Palautevarasto kerää **N** merkittyä pariita (kysymys, korjattu vastaus). LoRA‑menetelmällä (Low‑Rank Adaptation) hienosäätö tehdään vain pienelle osalle mallin painoja (esim. 0,5 %). Tämä lähestymistapa:

- **Vähentää laskentakustannuksia** (GPU‑tunnit < 2 viikossa).  
- **Säilyttää perusmallin tiedon** (estää katastrofaalisen unohtumisen).  
- **Mahdollistaa nopean käyttöönoton** (päivitykset 24‑48 h välein).

---

## 4. Toteutuksen tiekartta

| Vaihe | Välitavoitteet | Vastaava taho | Menestysmittari |
|-------|----------------|--------------|-----------------|
| **0 – Perusta** | Käyttöönotetaan vastaanotto‑pipeline; integroidaan LLM‑API; perustetaan vektorivarasto. | Platform Engineering | 100 % kyselyformaatteja tuettu. |
| **1 – Peruspisteytys** | Koulutetaan luottamuspisteytys historiallisella datalla; määritellään epävarmuus‑kynnys. | Data Science | >90 % automaattisesti julkaistut vastaukset läpäisevät sisäisen QA‑testin. |
| **2 – Ihmisen tarkistuspuisto** | Rakennetaan UI tarkistusjonolle; integroidaan audit‑logi. | Product Design | Keskimääräinen tarkistusaika < 2 min per matalan luottamuksen vastaus. |
| **3 – Palaute‑silmukka** | Tallennetaan korjaukset, käynnistetään kehotteen optimizeri, aikataulutetaan viikoittainen LoRA‑hienosäätö. | MLOps | Matala‑luottamus‑prosentti laskee 30 % kolmen kuukauden aikana. |
| **4 – Hallinto** | Otetaan käyttöön roolipohjainen pääsy, GDPR‑yhteensopiva datan säilytys, versioitu kehotekatalogi. | Compliance | 100 % audit‑valmis alkuperä jokaiselle vastaukselle. |

### 4.1 Datankeruu

- **Raaka‑syöte**: Alkuperäisen kyselyn teksti, tiedostohash.  
- **Mallin tuotos**: Luonnosvastaus, token‑todennäköisyydet, generointimetatiedot.  
- **Ihmistarkistus**: Korjattu vastaus, syy‑koodi (esim. “Puuttuva ISO‑viite”).  
- **Todiste‑linkit**: URL‑osoitteet tai sisäiset ID:t tukeville materiaaleille.

Kaikki data tallennetaan **append‑only‑tapahtumavarastoon**, jotta immuuttisuus säilyy.

### 4.2 Mallin uudelleenkoulutuksen aikataulu

- **Päivittäin**: Suoritetaan luottamuspisteytys uusille vastauksille; merkitään matalan luottamuksen tapaukset.  
- **Viikoittain**: Noudetaan kertyneet tarkistajien korjaukset; tehdään LoRA‑hienosäätö.  
- **Kuukausittain**: Päivitetään vektorivälineiden upotukset; arvioidaan kehotteiden “drift”‑ilmiöitä.

### 4.3 Hallintochhecklist

- Varmistetaan **PII‑poisto** ennen tarkistajien kommenttien tallentamista.  
- Suoritetaan **bias‑audit** LLM‑kielen osalta (esim. sukupuolineutraali ilmaisu).  
- Säilytetään **versiotunnisteet** jokaiselle kehotepohjalle ja LoRA‑tarkistukselle.

---

## 5. Mitattavat hyödyt

Pilottihanke, jossa kolme keskikokoista SaaS‑yritystä (keskiarvo 150 kyselyä/kk) käytti aktiivista oppimista kuuden kuukauden ajan, tuotti seuraavat tulokset:

| Mittari | Ennen silmukkaa | Silmukan jälkeen |
|---------|----------------|-------------------|
| **Keskimääräinen tarkistusaika per kysely** | 12 min | 4 min |
| **Automaattinen QA‑läpäisyprosentti** | 68 % | 92 % |
| **Ensiluonnoksen aika** | 3 h | 15 min |
| **Audit‑löydökset kyselyvirheistä** | 4 / neljännes | 0 |
| **Mallin drift‑tapahtumat (uudelleenkoulutus tarpeen)** | 3 / kk | 0,5 / kk |

Tehokkuuden lisäksi **audit‑polku**, joka on sisällytetty silmukkaan, täytti **[SOC 2 Type II](https://secureframe.com/hub/soc-2/what-is-soc-2)** -vaatimukset *muutoshallinnasta* ja *todisteiden alkuperästä*, vapauttaen juridisen tiimin manuaalisesta lokituksesta.

---

## 6. Parhaat käytännöt tiimeille

1. **Aloita pienestä** – Ota aktiivinen oppiminen käyttöön ensin korkean riskin osioissa (esim. tietosuojakontrollit, incident‑response).  
2. **Määritä selkeät luottamusrajat** – Säädä kynnys jokaisen sääntelykehyksen mukaan; SOC 2 vaatii tiukempaa kuin GDPR.  
3. **Kannusta tarkistajien palautetta** – Palkitse korjauksista (esim. gamifikaatio), jotta osallistuminen pysyy korkeana.  
4. **Seuraa kehotepohjien “drift”‑ilmiöitä** – Automaattiset testit vertaavat generoituja vastauksia viite‑katkelmiin.  
5. **Dokumentoi kaikki muutokset** – Jokainen kehotepohjan tai LoRA‑päivityksen versio on hallinnoitava Gitissä ja varustettu julkaisumuistiinpanoilla.

---

## 7. Tulevaisuuden suuntaviivat

### 7.1 Monimodaalinen todistusaineiston integrointi

Seuraavassa kehitysvaiheessa hyödynnetään **kuva‑LLM:eitä** sisällyttämään näyttökuvat, arkkitehtuurikaaviot ja koodikatkelmat, laajentaen todisteiden perusteita pelkän tekstin ohella.

### 7.2 Federatiivinen aktiivinen oppiminen

Yritykset, joilla on tiukat datan sijaintivaatimukset, voivat hyödyntää **federatiivista oppimista**: jokainen liiketoimintayksikkö kouluttaa paikallisen LoRA‑adapterin ja jakaa vain gradienttipäivitykset, säilyttäen luottamuksellisuuden.

### 7.3 Selitettävät luottamuspisteet

Yhdistetään luottamusarvot paikallisten selitysmapien (esim. SHAP token‑tasolle) kanssa, jotta tarkistajat näkevät miksi malli on epävarma – näin vähennetään kognitiivista kuormitusta.

---

## Yhteenveto

Aktiivinen oppiminen muuttaa hankintakelpoista tekoälyä **staattisesta vastausten tuottajasta dynaamiseksi, itsensä optimoivaksi vaatimustenmukaisuuden kumppaniksi**. Älykkäästi reitittämällä epäselvät kysymykset ihmistarkistajille, hioaen kehotteita jatkuvasti ja hyödyntäen kevyitä inkrementaalisia hienosäätömenetelmiä, Procurizen alusta pystyy:

- Leikkaamaan kyselyiden läpimenoaikaa jopa **70 %**.  
- Saavuttamaan **>90 %** ensimmäisen luonnoksen tarkkuuden.  
- Tarjoamaan **täydellisen audit‑polun**, jonka sääntelyviranomaiset hyväksyvät.

Aikakaudella, jolloin tietoturvakyselyt ohjaavat myyntinopeutta, aktiivisen oppimisen silmukan sisällyttäminen ei ole vain tekninen päivitys – se on strateginen kilpailuetu.