Suojauksen rakentaminen: puolustukselliset toiminnot ja reaaliaikainen validointi
09.09.2026
Kun malli on vakaa ja tuottaa hyväksyttäviä tulosteita normaaliolosuhteissa, alkaa vaikeampi kysymys: miten se käyttäytyy, kun jokin menee vikaan, joko vahingossa tai tarkoituksella? Tässä vaiheessa yhdistyvät tietoturvatestaus, eettinen arviointi, ajonaikainen suojaus ja organisaation valmius vastata sääntelyn vaatimuksiin.
1. Red teaming ja hyökkäystestaus
Pääpolun eli happy pathin testaaminen on vasta alku. Kypsissä tekoälyn laatuohjelmissa järjestetään omia red team -harjoituksia, eli järjestelmällisiä yrityksiä saada järjestelmä pettämään. Esimerkkejä:
- Suojausten kiertoyritykset (jailbreak)
- Tietovuodot
- Käyttöoikeuksien laajentaminen työkalujen kautta (privilege escalation)
- Työkalujen turvaton suorittaminen
- Liian laaja toimivalta (excessive agency)
- Virheelliset tai monitulkintaiset syötteet
- Liiketoimintasääntöjen kiertäminen
Dokumentoi jokaisesta luokasta hyökkäysskenaariot, aja ne arviointitapauksina (evals) ja varmista, että suojaukset pitävät. Red teamingin havainnoista pitää tehdä myös regressiotestejä.
2. Prompt-injektio: suora ja epäsuora
Suora prompt-injektio (prompt injection) on ilmeisin tapaus: käyttäjä liittää chat-käyttöliittymään tekstin ”unohda kaikki aiemmat ohjeet”. Vaikeampi muoto on epäsuora prompt-injektio, jossa malli lukee haitallisia ohjeita epäluotettavasta tietolähteestä, esimerkiksi verkkosivulta tai sähköpostista.
Suojaustoimenpiteet:
- Käsittele haettua ja ulkoista sisältöä epäluotettavana datana
- Erota ohjeet datasta
- Rajoita työkalujen käyttöoikeuksia
- Vaadi valtuutus mallin ulkopuolelta
- Testaa, voiko syötetty sisältö muuttaa järjestelmän käyttäytymistä
- Varmista, ettei arkaluonteista kontekstia voi vuotaa ulos järjestelmästä
3. Ajonaikaiset suojakaiteet

Suojakaiteet (guardrails) toimeenpanevat suojaukset tuotannossa. Vakiintunut ratkaisu on kerroksittainen ajonaikainen tarkistus, joka kohdistuu sekä syötteisiin että tulosteisiin: syötteiden suodatus, tulosteiden suodatus, työkalujen valtuutus ja henkilötietojen (PII) tunnistus. Myös itse suojakaiteet on testattava.
4. Vaatimustenmukaisuus ja hallintamalli
Vankka tekoälyn laatuohjelma noudattaa keskeisiä viitekehyksiä, kuten EU:n tekoälyasetusta (EU AI Act), NIST AI RMF -kehystä ja ISO/IEC 42001 -standardia. Laadunvarmistus tuottaa näytön vaatimustenmukaisuudesta läpinäkyvyyden, jäljitettävyyden ja määriteltyjen virhetasojen avulla.
Tekoälyn vaatimustenmukaisuustestaus ei ole erillinen testausvaihe. Monet vaadituista kontrolleista nojaavat samaan jäljitettävyyteen, valvontaan, riskitestaukseen ja dokumentaatioon, jota kypsä laadunvarmistus jo tuottaa.

5. Varjotestaus ja jatkuva havainnointi

Arviointi jatkuu tuotantoympäristössä. Jatkuva havainnointi (observability) paljastaa sen, mitä tuotannon ulkopuolinen arviointi ei tavoita: uudenlaiset käyttäjien syötteet, datan jakauman muutokset todellisessa käytössä ja esiin tulevat toistuvat virhetyypit. Käytä varjotestausta (shadow testing) ehdokasversioiden vertaamiseen tuotantoliikenteeseen ilman vaikutusta käyttäjiin.
Tämä oli toinen blogi EvalOps sarjassamme. Seuraava blogi käsittelee tulosteiden älykkyyttä ja stokastisten tulosten hallintaa.
- Blog |
- AI |
- AI system QA |
- EvalOps |
- EvalOps



