
# AI‑ohjattu jatkuva todisteiden alkuperän kirjanpito toimittajakyselyiden tarkastuksissa

Turvallisuuskyselyt ovat B2B‑SaaS‑sopimusten portinvartijoita. Yksi epämääräinen vastaus voi pysäyttää sopimuksen, kun taas hyvin dokumentoitu vastaus voi nopeuttaa neuvotteluja viikkoja. Kuitenkin vastauksia edeltävät manuaaliset prosessit – politiikkojen kerääminen, todisteiden poiminta ja vastausten kommentointi – ovat täynnä inhimillisiä virheitä, versioiden hajaantumista ja tarkastuspainajaisia.  

Tässä astuu kuvaan **Jatkuva todisteiden alkuperän kirjanpito (CEPL)**, tekoäly‑ohjattu, muuttumaton tietue, joka tallentaa jokaisen kyselyn vastauksen koko elinkaaren, raaka‑lähdedokumentista lopulliseen tekoälyn tuottamaan tekstiin. CEPL muuntaa hajanaisen politiikkojen, tarkastusraporttien ja hallintotodisteiden joukon koherentiksi, todistettavaksi kertomukseksi, johon sääntelyviranomaiset ja kumppanit voivat luottaa ilman loputonta takaisinkytkentää.

Alla tarkastelemme CEPL‑arkkitehtuuria, datavirtaa ja käytännön hyötyjä, ja näytämme, miten Procurize voi integroida tämän teknologian antaakseen compliance‑tiimillesi ratkaisevan etulyöntiaseman.

## Miksi perinteinen todistusten hallinta epäonnistuu

| Ongelma | Perinteinen lähestymistapa | Liiketoiminnan vaikutus |
|---------|----------------------------|--------------------------|
| **Versioiden sekasorto** | Useita kopioita politiikoista jaetuilla asemilla, usein epäyhtenäisiä. | Epäs一致​vastaukset, päivittämättömät tiedot, compliance‑aukot. |
| **Manuaalinen jäljitettävyys** | Tiimit kirjaavat manuaalisesti, mikä dokumentti tukee mitäkin vastausta. | Aikavaativaa, virhealttiina, tarkastusvalmiita dokumentteja harvoin valmiina. |
| **Jäljitettävyyden puute** | Ei muuttumatonta lokia siitä, kuka on muokannut mitä ja milloin. | Tarkastajat pyytävät “todista alkuperä”, mikä aiheuttaa viiveitä ja menetettyjä kauppoja. |
| **Skaalautuvuuden rajoitukset** | Uusien kyselyiden lisääminen vaatii todistekartan uudelleenrakentamista. | Operatiivisia pullonkauloja vendor‑kantansa kasvaessa. |

Nämä puutteet korostuvat, kun tekoäly luo vastauksia. Ilman luotettavaa lähdeketjua tekoälyn tuottamia vastauksia voidaan pitää “mustana laatikkona”, mikä heikentää niiden lupaa nopeudesta.

## Ydinajatus: Muuttumaton alkuperä jokaiselle todisteelle

Alkuperän kirjanpito on aikajärjestyksessä oleva, manipulointia havaitseva loki, joka kirjaa **kuka**, **mitä**, **milloin** ja **miksi** jokaiselle datapisteelle. Yhdistämällä generatiivinen tekoäly tähän kirjanpitoon saavutetaan kaksi tavoitetta:

1. **Jäljitettävyys** – Jokainen tekoälyn luoma vastaus linkitetään täsmälleen ne lähdedokumentit, annotaatiot ja muunnosvaiheet, joista se syntyi.  
2. **Eheys** – Kryptografiset tiivisteet ja Merkle‑puut takaavat, että kirjaa ei voida muokata ilman havaitsemista.

Tuloksena on **yksi totuuden lähde**, jonka voi esittää tarkastajille, kumppaneille tai sisäisille tarkistajille sekunneissa.

## Arkkitehtuurinen suunnitelma

Alla on korkean tason Mermaid‑kaavio, jossa on CEPL‑komponentit ja datavirta.

```mermaid
graph TD
    A["Source Repository"] --> B["Document Ingestor"]
    B --> C["Hash & Store (Immutable Storage)"]
    C --> D["Evidence Index (Vector DB)"]
    D --> E["AI Retrieval Engine"]
    E --> F["Prompt Builder"]
    F --> G["Generative LLM"]
    G --> H["Answer Draft"]
    H --> I["Provenance Tracker"]
    I --> J["Provenance Ledger"]
    J --> K["Audit Viewer"]
    style A fill:#ffebcc,stroke:#333,stroke-width:2px
    style J fill:#cce5ff,stroke:#333,stroke-width:2px
    style K fill:#e2f0d9,stroke:#333,stroke-width:2px
```

**Komponenttien kuvaus**

| Komponentti | Rooli |
|------------|-------|
| **Source Repository** | Keskitetty säilytyspaikka politiikoille, tarkastusraporteille, riskirekistereille ja tukimateriaaleille. |
| **Document Ingestor** | Jäsentää PDF:t, DOCX:t, markdown‑tiedostot ja poimii rakenteellista metatietoa. |
| **Hash & Store** | Luo SHA‑256‑tiivisteen jokaiselle artefaktille ja tallentaa sekä tiedoston että tiivisteen muuttumattomaan objektivarastoon (esim. AWS S3 Object Lock). |
| **Evidence Index** | Tallentaa upotukset vektoridatabaseen semanttista haun nopeuttamiseksi. |
| **AI Retrieval Engine** | Hakee kyselyn perusteella relevantit todisteet. |
| **Prompt Builder** | Rakentaa kontekstirikkaan kehotteen, joka sisältää todisteotteen ja alkuperämetadata. |
| **Generative LLM** | Tuottaa luonnollista kieltä noudattaen compliance‑rajoituksia. |
| **Answer Draft** | Alustava tekoälyn tuottama vastaus, valmis ihmisen tarkistettavaksi. |
| **Provenance Tracker** | Kirjaa kaikki ylöspäin suuntautuvat artefaktit, tiivisteet ja muunnosvaiheet, joilla luotiin luonnos. |
| **Provenance Ledger** | Lisää‑vain‑lokitiedosto (esim. Hyperledger Fabric tai Merkle‑puuperusteinen ratkaisu). |
| **Audit Viewer** | Interaktiivinen käyttöliittymä, joka näyttää vastauksen ja sen täydellisen todistusketjun tarkastajille. |

## Vaihe‑käsittely

1. **Ingestio & Tiivistys** – Kun politiikka‑dokumentti ladataan, Document Ingestor poimii tekstin, laskee SHA‑256‑tiivisteen ja tallentaa sekä tiedoston että tiivisteen muuttumattomaan varastoon. Tiiviste lisätään myös **Evidence Index**‑tietokantaan nopeaa hakua varten.  
2. **Semanttinen haku** – Kun uusi kysely saapuu, AI Retrieval Engine suorittaa vektorihakukyselyn ja palauttaa top‑N todisteet, jotka parhaiten vastaavat kysymyksen semantiikkaa.  
3. **Kehote‑rakennus** – Prompt Builder syöttää jokaisen todisteen otteen, sen tiivisteen ja lyhyen viitteen (esim. “Policy‑Sec‑001, Section 3.2”) rakenteelliseen LLM‑kehotteeseen. Tämä varmistaa, että malli voi viitata lähteisiin suoraan.  
4. **LLM‑generointi** – Fine‑tuned‑compliance‑LLM tuottaa vastauksen, joka viittaa annettuihin todisteisiin. Koska kehotteessa on eksplisiittiset viitteet, malli oppii käyttämään jäljitettävää kieltä (“Policy‑Sec‑001:n mukaan …”).  
5. **Alkuperän kirjaus** – Kun LLM käsittelee kehotteen, Provenance Tracker lokittaa:  
   - Kehoite‑ID  
   - Todiste‑tiivisteet  
   - Mallin versio  
   - Aikaleima  
   - Käyttäjä (jos tarkistaja tekee muokkauksia)  

   Nämä tiedot serialisoidaan Merkle‑lehdeksi ja liitetään append‑only‑kirjanpitoon.  
6. **Ihmisen tarkistus** – Compliance‑analyytikko tarkistaa luonnoksen, lisää tai poistaa todisteita ja finalisoi vastauksen. Kaikki manuaaliset muokkaukset luovat lisäkirjauksen, säilyttäen koko muokkaushistorian.  
7. **Tarkastus‑vienti** – Audit Viewer tuottaa PDF‑tiedoston, jossa on lopullinen vastaus, hyperlinkitetty lista todisteista ja kryptografinen todiste (Merkle‑juuri), että ketjua ei ole manipuloitu.

## Mittarit ja hyödyt

| Mittari | Ennen CEPL:ää | CEPL:n jälkeen | Parannus |
|---------|----------------|----------------|----------|
| **Keskimääräinen vasteaika** | 4‑6 päivää (manuaalinen kokoaminen) | 4‑6 tuntia (AI + automaattijälki) | ~90 % lyhenys |
| **Tarkastus‑vastausaika** | 2‑3 päivää manuaalista todistusten keruuta | < 2 tuntia paketin tuottamiseen | ~80 % lyhenys |
| **Viitteiden virheprosentti** | 12 % (puuttuvat tai virheelliset viitteet) | < 1 % (tiiviste–varmistettu) | ~92 % lyhenys |
| **Kauppojen viiveet** | 15 % sopimuksista viivästyy kyselypulmien takia | < 5 % viivästyy | ~66 % lyhenys |

Nämä parannukset vaikuttavat suoraan voiton kasvuun, compliance‑henkilöstön kustannusten alenemiseen ja organisaation maineeseen läpinäkyvyyden suhteen.

## Integraatio Procurize‑järjestelmään

Procurize on jo vahva keskittäjä kyselyille ja tehtävien ohjaukselle. CEPL:n lisääminen edellyttää kolme liitäntäpistettä:

1. **Varastohook** – Kytke Procurize‑dokumenttivarasto CEPL:n käyttämään muuttumattomaan objektivarastoon.  
2. **AI‑palvelupäätepiste** – Avaa Prompt Builder‑ ja LLM‑palvelut mikropalveluina, joita Procurize kutsuu kyselyn määrittyessä.  
3. **Kirjanpito‑UI‑laajennus** – Upota Audit Viewer uutena välilehtenä Procurize‑kyselyn tieto‑sivulle, jotta käyttäjät voivat vaihtaa “Vastaus” ja “Alkuperä” -näkymän välillä.

Koska Procurize noudattaa modulaarista mikropalveluarkkitehtuuria, nämä lisäykset voidaan toteuttaa pilottitiimeille ja skaalata koko organisaatioon ajan myötä.

## Käytännön esimerkit

### 1. SaaS‑toimittaja suuriin yrityspalveluihin
Yrityksen turvallisuustiimi vaatii todisteet **datankryptauksesta levossa**. CEPL:n avulla compliance‑vastaava painaa “Luo vastaus”, saa tiiviin lausunnon, joka viittaa tarkkaan salauspolitiikkaan (tiiviste‑varmistettu) ja linkin avainten‑hallinnan tarkastusraporttiin. Enterprise‑tarkastaja tarkistaa Merkle‑juuren minuuteissa ja hyväksyy vastauksen.

### 2. Jatkuva valvonta säädellyillä aloilla
Fintech‑alusta tarvitsee todistaa **SOC 2 Type II**‑vaatimuksen neljännesvuosittain. CEPL suorittaa automaattisesti samat kehotteet uusimmilla audit‑todisteilla, tuottaen päivitetyt vastaukset ja uuden kirjanpitotapahtuman. Sääntelyviranomaisen portaali hakee Merkle‑juuren API‑kutsulla ja vahvistaa, että todisteketju on muuttumaton.

### 3. Incident‑response‑dokumentointi
Kriittisessä hyökkäyssimulaatiossa security‑tiimi tarvitsee nopeasti vastauksen **tapahtuman havaitsemiskäytännöistä**. CEPL hakee relevantin pelisuunnitelman, kirjaa sen tarkat versiotiedot ja luo vastauksen, jossa on nolla‑tietämys‑todiste todisteen eheydestä – täten tarkastajan “todista alkuperä” -pyyntö täytetään välittömästi.

## Turvallisuus‑ ja yksityisyyskysymykset

- **Tietojen luottamuksellisuus** – Tiedostot salataan lepotilassa asiakkaan hallinnoimilla avaimilla. Vain valtuutetut roolit voivat purkaa ja tarkastella sisältöä.  
- **Zero‑knowledge‑todisteet** – Erittäin arkaluontoisille todisteille kirjanpito voi tallentaa vain zero‑knowledge‑todisteen sisällyttämisestä, jolloin tarkastaja voi vahvistaa olemassaolon paljastamatta raakatietoja.  
- **Pääsynhallinta** – Provenance Tracker noudattaa roolipohjaista pääsyä: tarkistajat voivat muokata vastauksia, tarkastajat vain katsella kirjanpitoa.

## Tulevaisuuden kehityssuunnat

1. **Hajautettu kirjanpito partnerien kesken** – Mahdollistaa useiden organisaatioiden jakaa yhteisen alkuperä‑kirjanpidon kolmannen‑osapuolen riskiarvioille säilyttäen kunkin osapuolen datasilosin.  
2. **Dynaaminen politiikasyntyyppi** – Hyödyntää kirjanpidon historiaa meta‑mallin kouluttamiseen, joka ehdottaa politiikkapäivityksiä toistuvien kysymysten aukkojen perusteella.  
3. **Tekoäly‑pohjainen poikkeamien tunnistus** – Valvoo kirjanpitoa reaaliaikaisesti ja hälyttää compliance‑tiimin epätavallisista muutostavoista.

## Päästään alkuun viidessä vaiheessa

1. **Ota käyttöön muuttumaton varasto** – Määritä objektivarasto, jossa on WORM‑politiikat.  
2. **Kytke Document Ingestor** – Hyödynnä Procurize‑API:a viedäksesi olemassa olevat politiikat CEPL‑putkeen.  
3. **Käynnistä Retrieval‑ ja LLM‑palvelut** – Valitse compliance‑sopiva LLM (esim. Azure OpenAI eristetty data‑alue) ja konfiguroi kehotemalli.  
4. **Ota käyttöön Provenance‑kirjaus** – Integroi Provenance Tracker SDK osaksi kyselyn työnkulkua.  
5. **Kouluta tiimi** – Järjestä workshop, jossa opastetaan Audit Viewer:n käyttö ja Merkle‑todisteiden tulkitseminen.

Noudattamalla näitä askelia organisaatiosi siirtyy “paperi‑kustannus painajaisesta” **kryptografisesti todistettavaksi compliance‑moottoriksi**, jonka avulla turvallisuuskyselyt muuttuvat pullonkaulasta kilpailuetuun.

---

## <span class='highlight-content'>Katso</span> myös

- [NIST SP 800‑37 Rev 2 – Riskienhallintakehys](https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final)
- [ISO/IEC 27001:2022 – Tietoturvallisuuden hallintajärjestelmä](https://www.iso.org/standard/73906.html)
- [OpenZeppelin – Merkle‑puun todisteet auditoitavasta datasta](https://docs.openzeppelin.com/contracts/4.x/api/utils#MerkleProof)
- [Microsoft Azure Confidential Computing Documentation](https://learn.microsoft.com/azure/confidential-computing/)