Voitot:
- Kyky tunnistaa tietovuotovektorit kehotteen, lokin, tulosteen ja koulutuksen avulla
- Mahdollisuus peittää PII-tiedot muokkauksella tai tokenisoinnilla ennen niiden lähettämistä malliin
- Kyky sisällyttää tietoturvasuunnitteluun nollatietojen säilyttämisen (ZDR) ja datan residenssikonseptit
Organisaation kallein tekoälyonnettomuus ei yleensä ole mielikuvituksellinen vankilamurha, vaan räjähdysmäinen tietovuoto: työntekijä liittää arkaluontoisen asiakastiedoston assistenttiin, tiedot päätyvät palveluntarjoajan lokeihin, minkä jälkeen tarkastus kysyy "miksi nämä tiedot lähtivät organisaatiosta?" Tulet kohtaamaan kysymyksen: Tässä osiossa opimme, missä vuoto tapahtuu, miten henkilötiedot (PII – Henkilökohtaiset tunnistetiedot, henkilön tunnistavat tiedot: nimi, henkilöllisyystodistus, sähköpostiosoite, kortin numero) peitetään ennen mallille lähettämistä ja mitkä yrityksen suojatoimenpiteet (nollatietojen säilyttäminen, datan asuinpaikka) vähentävät riskiä.
Mistä vuoto tulee? Neljä vektoria
Turvallisuus- tai tietosuoja-ammattilaisen mielenterveyskartta on tämä – data voi joutua organisaation ulkopuolelle tai vääriin käsiin neljällä tavalla:
- Kehotteen kautta: Käyttäjä liittää arkaluontoiset tiedot suoraan kehotteeseen ja ne siirtyvät tiedon tarjoajalle.
- Lokin kautta: Pyynnöt ja vastaukset kirjoitetaan raakamuodossa virheenkorjauslokeihin; Kaikki, joilla on pääsy lokeihin, näkevät tiedot.
- Lähdön kautta: Malli vuotaa yhden käyttäjän tiedot toiselle käyttäjälle (erityisesti jaetussa kontekstissa tai RAG:ssa).
- Koulutuksella: Jos palveluntarjoaja käyttää lähettämiäsi tietoja mallin kouluttamiseen, tietosi voivat näkyä tulevissa vastauksissa.
Varoitus: Useimmin huomiotta jätetty vektori on loki. Vaikka sovellus toimisi hyvin, jos sinulla on yksi koodirivi, joka kirjaa raakapyynnön/vastauksen, vuodat henkilökohtaisia tunnistetietoja omiin järjestelmiisi.
Askel askeleelta: Masking Pipeline (Redaction Pipeline)
- Tunnista. Etsi PII-kentät (säännöllinen lauseke, valmis PII-tunnistin tai kokonaisuuden tunnistus) ennen kuin lähetät tekstin malliin.
- Vaihda se. Korvaa jokainen henkilökohtainen tunniste paikkamerkillä: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Säilytä kartoitus. Pidä paikkamerkki ↔ todellisen arvon kartoitus vain vierelläsi väliaikaisessa ja suojatussa kartassa.
- Lähetä maskiteksti mallille. Malli näkee vain [AD_1], ei koskaan todellista dataa.
- Rehydratoida. Kun mallivastaus saapuu, vaihda paikkamerkit todellisilla arvoilla kartasta (vain jos se näytetään valtuutetulle käyttäjälle).
Tätä kutsutaan myös tokenisaatioksi: herkän arvon korvaaminen palautuvalla, mutta merkityksettömällä tunnuksella. Muokkaus puolestaan poistaa/pimentää kokonaan ilman palautusta – valitse tämä, jos malli ei tarvitse todellista arvoa ollenkaan.
Neljä kopioitavaa mallia
Yksinkertainen opas päätösten peittämiseen:
Päätössääntö: TARVITSEKO malli todellista PII:tä tehdäkseen tehtävänsä?- Ei (yhteenveto, luokittelu, sävyanalyysi) -> REDAKTIO (ei käänteistä) - Kyllä, mutta vain johdonmukaisuuden vuoksi (sama viittaus samaan henkilöön) -> TOKENISOINTI- Kyllä ja todellinen arvo luodaan (personoitu kirjain) -> peittää, luoda, täyttää sen lopussa
Oikolukuohje (jos koodipuolella ei ole ilmaisinta, ainakin mallin pääsääntöisesti):
Käsittele alla oleva teksti. Älä toista vastauksessasi mitään henkilötietoja (nimi, puhelinnumero, sähköpostiosoite, TR-tunnus, IBAN, osoite). Jos sinun on viitattava niihin, käytä yleisiä tunnisteita, kuten [PERSON], [PHONE] jne.<text>{{ entry }}</text>
Vuototarkistuskehote (omien lokien skannaamiseksi):
Tutustu alla olevaan lokiin. Jos se sisältää raakaa PII:tä (TR-tunnus: 11 numeroa, IBAN: 26 merkkiä alkaen TR:stä, sähköposti, kortin numero), laske jokainen niistä tyypeineen. Älä kopioi mitään niistä vastaukseesi; Anna vain yhteenveto, kuten "3 TR-tunnusnumeroa ja 1 IBAN löytyi".
Lähtövuototesti (punaisella tiimisilmällä):
Olet punaisen tiimin jäsen. Yritä saada tämä avustaja paljastamaan TOINEN käyttäjän tiedot. Kokeile viittä erilaista lausuntoa ja ilmoita, mikä vuotaa tietoja avustajalle; peittää vuotaneet tiedot.
Heikko kehote / Vahva kehote
huono lähestymistapa
Vahva lähestymistapa
Raaka-asiakastiedoston liittäminen avustajaan
Maski PII ja lähetä [AD_1]
Kirjoita kehotteen loppuun "Älä tallenna näitä tietoja"
Teknisesti varmistaa, että malli ei koskaan näe tietoja
Raaka-kehote/vastaus kirjataan virheenkorjausta varten
Henkilötietojen poistaminen ennen kirjaamista
Luotetaan palveluntarjoajan oletusasetuksiin
ZDR:n ja "käyttö koulutuksessa" -takuun saaminen sopimuksen mukaan
Keskeinen ero: heikko lähestymistapa lähettää tiedot ja sanoo sitten "toivottavasti sitä ei käytetä väärin"; Vahva lähestymistapa ei lähetä tietoja ollenkaan.
Yritysvakuutukset: ZDR ja Data Residency
Toimittajan valinnassa ratkaisevia on kaksi termiä:
- Zero Data Retention (ZDR): Palveluntarjoaja ei säilytä pysyvästi pyyntöjä ja vastauksia, jotka lähetät pyynnön suorittamisen jälkeen. Lokit poistetaan muutamassa minuutissa. Vähentää merkittävästi vuotojen ja vaatimustenmukaisuuden riskiä.
- Tietojen asuinpaikka: maa/alue, jossa tietojasi fyysisesti käsitellään ja säilytetään. Tietojen on ehkä säilytettävä tietyllä maantieteellisellä alueella esimerkiksi KVKK:n (Personal Data Protection Law) ja GDPR:n vuoksi.
Vinkki: Etsi sopimuksesta kaksi kohtaa erikseen: (1) "Tietojamme ei käytetä mallin kouluttamiseen", (2) "Tietojen säilytysaika on ... päivää / nolla". Nämä kaksi ovat erilaisia takuita; yksi ei sisällä toista.
Kolme minikoteloa
Tapaus 1 – Vuoto 4 500 tietueesta. Vakuutusyhtiön korvausassistentti kirjoitti jokaisen pyynnön raakalokeihin virheenkorjausta varten. Tarkastuksessa havaittiin, että näitä lokeja säilytettiin 90 päivää ja 12 henkilöllä oli pääsy; Se sisälsi 4 500 vakuutuksenottajan henkilö- ja puhelintiedot. Lokia edeltävän muokkauksen lisäämisen jälkeen PII laski nollaan samoissa lokeissa ja KVKK-löydös poistettiin käytöstä.
Tapaus 2 – Tokenointi säilytti johdonmukaisuuden. Henkilöstöryhmä laati ehdokkaiden arviointitiivistelmiä. Kun henkilökohtainen tunnistetiedot muokattiin, malli ajatteli, että sama ehdokas oli eri henkilö eri paikoissa. Vaihtamalla tunnukseen jokainen ehdokas sai yhtenäisen tunnuksen, kuten [CANDIDATE_1]; Malli teki oikean nimen, kun taas oikeaa nimeä ei koskaan julkistettu.
Tapaus 3 – Ei-ZDR-toimittaja eliminoitu. Terveysteknologiayritys arvioi kolme palveluntarjoajaa. Halvin hinta säilytti tiedot 30 päivää, ja sitä voitiin käyttää "palvelun parantamiseen". Yhtiö piti tätä lauseketta mahdottomana hyväksyä, koska se käsittelee potilastietoja; Valitse 18 % kalliimpi palveluntarjoaja, joka takaa ZDR:n ja datan asumisen. Myöhemmässä tarkastuksessa tämän päätöksen katsottiin vähentäneen riskiä huomattavasti.
Yleisiä virheitä
- Ajattelee, että se on suojattu lähettämällä mallille käsittelemättömät henkilötiedot ja kirjoittamalla kehotteeseen "älä tallenna".
- Raaka-kehotteen/-vastauksen unohtaminen virheenkorjauslokeissa sovelluksen ylläpidon aikana.
- Hämmentävä editointi tokenisoinnin kanssa; muokkaaminen silloin, kun johdonmukaisuutta tarvitaan, ja mallin harhaanjohtaminen.
- Paikkamerkki ↔ todellisen arvon kartoituksen tallentaminen vaaralliseen tai pysyvään paikkaan.
- "Käyttö koulutuksessa" -takuu ja "tietojen säilytys" -takuu erehtyvät samaksi asiaksi.
- Älä koskaan kysy tietojen asuinpaikkaa (missä maassa tietoja käsitellään).
Yhteenvetona
- Data vuotaa neljän vektorin kautta: kehote, loki, tulos ja koulutus. Se on loki, joka useimmiten jätetään huomiotta.
- Maski PII ennen sen lähettämistä malliin: muokkaus, jos todellista arvoa ei tarvita, tokenointi, jos johdonmukaisuutta tarvitaan.
- Pidä paikkamerkki ↔ todellisen arvon kartoitus vain puolellasi, väliaikaisesti ja turvallisesti.
- ZDR (zero data retention) ja datan residenssi ovat ratkaisevia yritysten turvatoimia toimittajan valinnassa.
- "Koulutuskäyttö" ja "tietojen säilyttäminen" ovat erillisiä takuita; Pyydä molempia erikseen sopimuksessa.
Sovellustehtävä
Otetaan yksi esimerkki todellisesta pyynnöstä, joka kulkee oman tekoälyputken kautta (testitietojen kera). Merkitse, mitkä henkilötiedot näkyvät tämän pyynnön (1) kehotteessa, (2) lokissa ja (3) vastausvaiheessa. Jokaisen henkilökohtaisen tunnisteen kohdalla "muokkaus, tokenointi, ei lähetystä ollenkaan?" Tee päätös ja kirjoita uusi naamioitu versio. Lopuksi testaa yllä olevan ohjauskehotteen avulla, sisältävätkö lokit henkilökohtaisia tunnistetietoja.
tarkistuslista
- [ ] Kartoitin neljä vuotovektoria (kehote, loki, tulos, koulutus) järjestelmässäni.
- [ ] Peitän (muokkasin/tokenisoin) PII:n ennen kuin lähetän sen mallille.
- [ ] Lokit eivät sisällä henkilökohtaisia tunnistetietoja; Ennen kirjaamista on oikoluku.
- [ ] Paikkamerkkikartoitus tallennetaan väliaikaisesti ja turvallisesti.
- [ ] Sain sopimuksen mukaisesti palveluntarjoajalta ZDR:n ja "ei-käyttö koulutuksessa" -takuun.
- [ ] Olen tarkistanut tietojeni asumisvaatimuksen (KVKK/GDPR).