Kort svar
En AI-policy ska svara på fem frågor: vilka verktyg som är tillåtna, vilka uppgifter som aldrig får matas in, vad som alltid granskas av en människa, vem som ansvarar, och vad man gör när något gått fel. Tio punkter på två sidor räcker. Längre dokument läses inte och styr därför ingenting.
Varför en policy behövs nu
De flesta företag vi träffar tror att de ska införa AI någon gång framöver. De har redan gjort det. Någon på ekonomi klistrar in leverantörsavtal i ett chattfönster, en säljare låter ett verktyg skriva offerttexter, en chef spelar in möten i en tjänst ingen har granskat. Det sker på privata konton, utan avtal, och utan att någon vet vilka uppgifter som lämnat huset.
Det är därför en policy inte är ett dokument för framtiden. Den beskriver vad som redan pågår, och gör det till något ni har bestämt i stället för något som bara händer.
En sak till, som är värd att säga inför ledningen: en policy vars enda budskap är att AI inte får användas fungerar inte. Den flyttar bara användningen till telefonerna, där ni har noll insyn. Den policy som fungerar pekar ut en tillåten väg som är bekväm nog att folk väljer den.
Det finns dessutom ett skäl som brukar väga tyngst i praktiken: någon kommer att fråga. En upphandlare, en större kund i ett leverantörsformulär, ett försäkringsbolag eller en revisor. Frågan lyder oftast om ni har en dokumenterad hantering av AI-verktyg, och det är en betydligt trevligare fråga att få när svaret är två sidor som redan finns.
De tio punkterna
Det här är den struktur vi rekommenderar. Skriv ert eget innehåll under varje rubrik, men hoppa inte över någon av dem, för de täcker olika sorters risk.
1. Tillåtna verktyg
Räkna upp vilka AI-verktyg som får användas i arbetet, med namn, och säg vilken kontotyp som gäller. Företagslicens, aldrig privatkonto. Ange också hur någon får ett nytt verktyg godkänt, för annars kommer beslutet att fattas i tysthet av den som behöver det. En rad räcker: nya verktyg godkänns av IT-ansvarig innan de används på företagets uppgifter.
2. Uppgifter som aldrig matas in
Den viktigaste punkten, och den som ska vara mest konkret. Personuppgifter utöver det uppgiften kräver, känsliga personuppgifter som hälsa och facklig tillhörighet, löner och uppgifter om enskilda anställda, material under sekretess, inloggningsuppgifter och nycklar, samt kod eller underlag ni inte äger rätten att sprida. Formulera det som exempel ur er egen vardag, inte som juridiska kategorier, annars känner ingen igen situationen när den uppstår.
3. Granskningskrav
Vad som alltid läses av en människa innan det lämnar huset eller får konsekvenser. Vår standardformulering: allt som går till kund, allt som innehåller siffror eller belopp, allt som blir bindande, och allt som rör en enskild person. Lägg till att den som skickar är ansvarig för innehållet, oavsett vilket verktyg som skrev det.
4. Ansvar
Vem äger policyn, vem svarar på frågor och vem beslutar om undantag. Ett namn, inte en avdelning. I mindre bolag är det oftast vd eller den som redan är IT-ansvarig, och det är helt tillräckligt. En policy utan namngiven ägare uppdateras aldrig.
5. Loggning och spårbarhet
För byggda system: vad som loggas, hur länge det sparas och vem som kan läsa loggarna. För verktyg som köps: hur länge leverantören sparar era konversationer och vad ni gör med den vetskapen. Sätt en gallringstid, och lägg den i systemet i stället för i en rutin som någon ska komma ihåg i mars.
6. Krav på leverantörer
Vad som måste vara på plats innan ett verktyg får användas: personuppgiftsbiträdesavtal, besked om var behandlingen sker, träning på era uppgifter avstängd, och en beskriven process för radering vid uppsägning. Skriv också att kravet gäller hela kedjan, alltså även underleverantörer, för det är där det brukar spricka. Resonemanget bakom kraven går vi igenom i AI och GDPR.
7. Utbildningskrav
Vem som ska ha genomgått vad innan de använder verktygen i arbetet, och hur nyanställda får samma sak. Det behöver inte vara omfattande, en till två timmar räcker långt, men det ska vara ett krav och inte ett erbjudande. Skriv in att policyn gås igenom vid introduktionen, annars gäller den bara dem som var på plats den dagen den skrevs.
8. Incidenthantering
Vad man gör när något gått fel: fel uppgifter klistrades in, ett felaktigt svar skickades till en kund, ett verktyg användes utanför listan. Ange vem man säger det till och att det ska ske samma dag. Det viktigaste i den här punkten är tonen. En policy som låter som att misstag straffas ger er noll rapporterade incidenter och lika många lösta.
9. Uppdatering
När policyn ses över och av vem. Var sjätte månad är rimligt i det här området, oftare än ni är vana vid för styrdokument. Skriv in datum för senaste översyn i dokumentet så att alla ser hur gammalt det är. En AI-policy från förra året är en historisk handling.
10. Kommunikation
Var policyn finns, hur den introduceras och om ni berättar för kunder att AI används i era processer. Den sista frågan hoppas ofta över och kommer alltid tillbaka: har ni bestämt svaret i förväg blir det ett lugnt svar i stället för ett förvirrat. Är AI-användningen del av en behandling av personuppgifter ska det dessutom framgå av er information till registrerade.
Så inför ni den utan att den blir en hyllvärmare
Det svåra med en policy är inte att skriva den. Det svåra är att den ska påverka vad någon gör en tisdag när de har bråttom. Sex saker gör skillnaden.
- Håll den på två sidor. Behöver ni en bilaga för de tekniska detaljerna, gör en bilaga. Huvuddokumentet ska gå att läsa på fem minuter.
- Skriv den på svenska som folk pratar. Behandling av personuppgifter i tredjeland betyder ingenting för en säljare. Kundens namn och personnummer klistras aldrig in i ett chattfönster betyder något.
- Ge en tillåten väg, inte bara förbud. Om folk vet vilket verktyg de ska använda och hur, behöver de inte improvisera.
- Fråga dem som redan använder AI innan ni skriver. De vet vilka situationer som uppstår, och de kommer att ignorera en policy som inte känns igen.
- Gå igenom den på en timme, med exempel. Ett utskick läses inte. En timme där ni går igenom fem verkliga situationer sitter kvar.
- Kontrollera efter tre månader att den stämmer med verkligheten. Gör den inte det är det policyn som ska ändras, inte verkligheten som ska förnekas.
Ett tecken på att ni gjort rätt: någon kommer och frågar om ett nytt verktyg får användas, i stället för att bara börja använda det. Då styr dokumentet på riktigt.
Ett tecken på att ni gjort fel: policyn hänvisar till verktyg som inte längre finns, eller förbjuder något som hela företaget gör ändå. Båda är vanliga efter ett år, och båda går att rätta på en halvtimme om någon har ansvaret för att titta.
Två fällor är värda en egen varning, eftersom vi ser båda ofta.
- Att kopiera en mall rakt av. Mallar är utmärkta som struktur och värdelösa som innehåll. En policy som förbjuder verktyg ni inte använder och tiger om det ni faktiskt gör ger er dokumentationen utan styrningen, vilket är det sämsta av två världar.
- Att låta policyn ersätta ett beslut. Ett dokument som säger att AI ska användas ansvarsfullt betyder ingenting förrän någon bestämt vilka verktyg som gäller och vem som betalar för dem. Policyn styr hur ni använder AI, den avgör inte om ni ska.
Vanliga frågor
Måste vi ha en AI-policy enligt lag?
Ingen lag kräver ett dokument som heter AI-policy. Däremot kräver GDPR att ni kan visa hur personuppgifter behandlas, och AI-förordningen ställer krav beroende på hur ni använder AI. En kort policy är det enklaste sättet att både styra användningen och kunna visa att ni gjort det.
Hur lång ska en AI-policy vara?
Två sidor för huvuddokumentet. Tekniska detaljer, leverantörskrav och listan över godkända verktyg kan ligga i bilagor som uppdateras oftare. Ett tjugosidigt dokument läses av den som skrev det och av ingen annan.
Vem bör äga policyn i ett mindre bolag?
En namngiven person med mandat att säga nej, oftast vd eller den som redan ansvarar för IT. Det viktiga är inte titeln utan att det finns någon att fråga när en ny situation dyker upp, för det gör den ungefär varannan månad i det här området.