OWASP AI Testing Guide v1.0: käytännön checklist AI/LLM-ominaisuuksien testaukseen

OWASP julkaisi AI Testing Guide v1.0 -oppaan (11/2025). Se on käytännönläheinen yritys tehdä AI-järjestelmien testauksesta yhtä toistettavaa kuin “perinteisestä” softasta — mutta huomioiden ne riskit, jotka ovat AI:lle ominaisia.

Tärkein ajatus oppaassa tiivistyy tähän:

• Pelkkä security ei riitä → tavoite on AI:n luotettavuus (trustworthiness).

Luotettavuus sisältää toki tietoturvan, mutta myös mm. hallusinaatiot, harhat/bias, selitettävyys, yliohjautuva agenttikäyttäytyminen sekä datan vuoto eri muodoissa.

Tässä postauksessa tiivistän oppaan käytännön malliksi ja checklistiksi, jonka voi ottaa käyttöön tiimissä nopeasti.

Mikä OWASP AI Testing Guide on?

OWASP AI Testing Guide tarjoaa:

• standardoidun metodologian AI- ja LLM-järjestelmien testaukseen
• toistettavia testitapauksia neljään kerrokseen:
  • AI Application (sovellus: promptit, agentit, UI, integraatiot)
  • AI Model (malli: robustius, myrkytys, inference-hyökkäykset)
  • AI Infrastructure (infra: supply chain, resurssit, plugin-rajat)
  • AI Data (data: training/runtime exposure, minimointi, suostumus)

Käytännössä opas toimii “karttana” siihen, mitä kaikkea AI-järjestelmässä pitää testata, jotta se on tuotannossa turvallinen ja ennustettava.

Miksi AI-testauksessa on eri riskit kuin normaalissa softassa?

Opas nostaa esiin AI:n tyypilliset vikamoodit, jotka eivät ratkea perinteisellä unit/integration-testillä:

• prompt injection / jailbreak
• epäsuora prompt injection (kun malli lukee ulkoista sisältöä)
• sensitive data leak (datan vuoto vastauksissa)
• hallucinations & misinformation
• bias / fairness -ongelmat
• agentin liiallinen toimijuus (unsafe agency)
• supply chain + data/model poisoning
• drift (mallin tai datan muutos ajan myötä)

Käytännön checklist: mitä testata, kun julkaiset AI/LLM-ominaisuuden

Alla oleva lista on tiivistetty oppaan “Application/Model/Infra/Data” -jaottelun mukaan. Ajatus: tee näistä toistettavat testit, ei kertaluonteista “katsotaan nyt”.

1) Application layer (AITG-APP)

• Prompt injection: pystyykö käyttäjä ohittamaan ohjeet ja policyt?
• Indirect prompt injection: jos malli lukee web-sivuja/Slack-viestejä/tikettejä, voiko ulkoinen sisältö kaapata ohjauksen?
• Sensitive data leak: vuotaako PII/asiakasdata/salaisuudet vastauksissa, lokissa tai välimuisteissa?
• Unsafe outputs: tuottaako malli vaarallista ohjeistusta tai vahingollista sisältöä?
• Agentic behavior limits: jos agentti saa työkaluja (API:t, Jira, email), pysyykö se sallituissa rajoissa?
• Prompt disclosure: paljastaako malli järjestelmäpromptin tai sisäiset ohjeet?
• Model extraction: voiko käyttäjä “kalastella” mallin toimintaa tai sisäistä tietoa liian pitkälle?
• Hallucinations: kuinka usein malli keksii faktoja ja miten se näkyy käyttäjälle?
• Over-reliance: ohjaako UX käyttäjää liialliseen luottamiseen (“AI sanoi joten se on totta”)?
• Explainability & interpretability: pystyykö käyttäjä/ylläpito ymmärtämään miksi vastaus syntyi (lähteet, perustelut)?

2) Model layer (AITG-MOD)

• Evasion attacks: toimiiko malli “oudolla mutta sallituilla” syötteillä (robustius)?
• Runtime poisoning: voiko tuotantodata tai käyttäjäsyöte myrkyttää toimintaa (esim. RAG-muisti, cache, feedback loop)?
• Poisoned training sets / fine-tuning: miten varmistetaan että fine-tuning data ei sisällä haittaa?
• Membership inference / inversion: voiko mallista päätellä koulutusdataa tai palauttaa yksittäisiä tietoja?
• Robustness to new data: miten mitataan suorituskyky kun data muuttuu?
• Goal alignment: onko malli linjassa organisaation policyjen ja tarkoituksen kanssa?

3) Infrastructure layer (AITG-INF)

• Supply chain tampering: mallit, riippuvuudet, containerit, CI/CD — mitä varmistuksia?
• Resource exhaustion: pystyykö hyökkääjä ajamaan kustannukset/latenssin ylös (DoS / token flood)?
• Plugin boundary violations: jos LLM käyttää plugineja/työkaluja, vuotaako data tai ylittääkö se oikeudet?
• Capability misuse: pystyykö agentti käyttämään kyvykkyyksiä väärin (esim. “tee 200 API-kutsua”)?
• Dev-time model theft: miten suojataan mallit/avaimet kehitysvaiheessa?

4) Data layer (AITG-DAT)

• Training data exposure: mitä dataa mallissa on, ja voiko se vuotaa?
• Runtime exfiltration: voiko käyttäjä ohjata mallin ulosmittaamaan dataa (prompt injection + tool access)?
• Dataset diversity & coverage: kattaako data relevantit variaatiot vai syntyykö sokeita pisteitä?
• Data minimization & consent: tallennetaanko vain tarpeellinen ja onko suostumus/ohjaus kunnossa?

“Common failure modes” (mitä usein käy tuotannossa)

• RAG hakee “hyvännäköisen” mutta väärän lähteen → malli esittää sen faktana.
• Agentti saa liikaa oikeuksia → yksi prompt injection muuttuu oikeaksi muutokseksi järjestelmässä.
• Promptit ja guardrailit ovat hardcodattuja, mutta niitä ei testata regressiona.
• Datan minimointi unohtuu → lokit/välimuistit sisältävät arkaluontoista dataa.
• Ei ole mittareita driftin havaitsemiseen → laatu heikkenee hiljaa.

Miten tästä tehdään tiimille “normaalia tekemistä”

Suositus: tee AI-testauksesta osa delivery pipelinea:

• threat modeling AI-arkkitehtuuriin (app/model/infra/data)
• toistettavat testipaketit (prompt injection, data leak, unsafe outputs…)
• observability: lokit, audit trail, feedback, drift-mittarit
• selkeä “stop the line” -kriteeri: milloin AI-ominaisuus ei saa mennä tuotantoon

CTA (Byte)

Jos teillä on AI/LLM-ominaisuus tuotannossa (tai menossa sinne), voidaan auttaa:

• määrittelemään AI testing -framework teidän arkkitehtuuriin
• rakentamaan testipaketit (ml. prompt injection / indirect injection / data leak)
• tekemään “agentic tools” -rajoitukset ja audit trail -malli
• tuomaan testaus osaksi CI/CD:tä (ja säästämään tuotantokaaokselta)

Laita viestiä, niin katsotaan teidän setup läpi 60–90 minuutissa ja tehdään konkreettinen testisuunnitelma.

---

Lähde: OWASP AI Testing Guide v1.0 (PDF)