Innan en risknivå, en skyldighet eller en styrningsåtgärd får betydelse, måste det stå fast vilken roll er organisation spelar. Den som släpper ut ett AI-system på marknaden har andra ansvar än den som använder ett system som byggts av någon annan. Termen som används för detta är bekant: leverantör gentemot användare. Men indelningen i sig ligger inte fast i ett organigram. Den beror på vad en organisation gör med ett specifikt system, och det kan skilja sig per system, per avdelning och per tidpunkt.
Kärnfrågan är inte vem som har köpt eller installerat systemet, utan vem som har släppt ut det på marknaden eller gör det tillgängligt under eget namn. En organisation som köper in och använder programvara som den levereras, är i regel användare. En organisation som utvecklar ett system, låter utveckla det under sitt namn, eller anpassar ett befintligt system på ett sådant sätt att det funktionellt blir något annat, kan därmed hamna i rollen som leverantör. Det sistnämnda är ofta punkten där organisationer felbedömer situationen: att finjustera en modell, bygga ett eget lager ovanpå ett externt system, eller träna en chatbot på egna data kan förskjuta rollen utan att någon har uppfattat det som ett medvetet val. Vad som exakt räknas som en anpassning som förändrar rollen beskrivs på vad förändras när ni själva anpassar en modell.
De flesta organisationer är inte enbart leverantör eller enbart användare. En bank som använder en extern språkmodell för kundservice är i det avseendet användare, men om samma bank gör en internt utvecklad riskmodell tillgänglig för en annan avdelning eller för en kund, uppstår en leverantörsroll för det systemet. Det innebär att indelningen måste göras per tillämpning, inte en gång för hela organisationen. En inventering som per system fastställer vem som har byggt det, vem som har anpassat det och vem som använder det, är därför det enda sättet att besvara denna fråga strukturerat i stället för tillfälligt.
Rollen är ingen fast egenskap hos en organisation utan en status som kan förändras. En leverantör kan ändra sitt system på ett sätt som påverkar riskprofilen. En intern utvecklare kan vidareutveckla ett internt hjälpmedel till något som erbjuds utanför organisationen. Ett system som en gång kom in som ett enkelt verktyg kan efter en uppdatering utföra uppgifter som placerar det i en annan riskkategori. När denna förskjutning konkret inträffar och vad det innebär för vem som då är ansvarig, förklaras på när förändras er roll. För organisationer som vill förstå vad en förskjutning mot en högre risknivå innebär i praktiken, ger vad innebär en hög risknivå för er organisation en fördjupning.
Inte varje tillämpning som betecknas med artificiell intelligens faller inom ramen för vilken rollfördelningen är relevant. Vissa system faller utanför omfattningen som denna indelning gjorts för, och det är för en organisation lika viktigt att veta vad som faller utanför omfattningen som att veta vad som faller innanför. Annars läggs tid på klassificering av något som inte behövde klassificeras, eller förbises något eftersom det verkade för litet. Vilka tillämpningar som faller utanför denna ram och varför, beskrivs på vilka tillämpningar faller utanför omfattningen.
Att fastställa rollen är ett första steg, inte resultatet av en styrningsprocess. Efter indelningen kommer frågan om vad som faktiskt måste göras för varje roll och risknivå, och den frågan delas upp i två kategorier: vad som kräver omedelbar uppmärksamhet och vad som kan planeras på längre sikt. Dessa två kategorier blandas ofta ihop, med följden att brådskande frågor blir liggande medan tid läggs på något som ännu inte är akut. En översikt över vad som har prioritet i detta finns på vad måste göras nu och vad kan planeras. Den som vill fördjupa sig ytterligare i frågan om rollfördelningen, med de exakta kriterierna som avgör gränsen mellan leverantör och användare, finner den fördjupningen på är ni leverantör eller användare: vad avgör det.
Denna indelning är bara meningsfull om den tillämpas på vad som verkligen är i drift i organisationen, inte på vad som står på en godkänd lista. System som införts utan tillstånd räknas lika mycket, och rollen som hör till dem måste fastställas lika noggrant. Det kräver en inventering som går längre än IT-administrationen.
Så snart det är klart vilken roll en organisation spelar per system, flyttas uppmärksamheten naturligt till en annan fråga: vad gör dessa system egentligen, och hur stor del av arbetet tar de över. Den frågan ligger utanför styrningsgranskningen, men ansluter direkt till den. Arbetsgranskningen från FTE TO AI räknar per uppgift ut hur stor del av arbetet som kan tas över av AI, och ger därmed en bild av systemets påverkan vid sidan av bilden av de skyldigheter som hör till det.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.