re-ai-gov Skriv upp mig på väntelistan

Kennisbank

Vad som faller utanför scope, och varför det kan förändras

En indelningsfråga, ingen lista

Frågan vilka tillämpningar som faller utanför scope låter som en fråga om en lista. Det är den inte. Om något faller inom eller utanför scope är en indelning som beror på vad en tillämpning gör, i vilken kontext, och för vem. Samma teknik kan i en tillämpning förbli utan uppmärksamhet och i en annan hamna under full uppmärksamhet. En fast lista över uteslutna tillämpningar existerar därför inte — väl ett antal faktorer som bestämmer indelningen.

Vad indelningen beror på

Den första faktorn är tillämpningens funktion: vad beslutar eller rekommenderar systemet, och för vem har det konsekvenser. Ett verktyg som skriver om intern text ligger annorlunda än ett verktyg som medbeslutar om en ansökan, en jobbansökan eller ett anspråk. Den andra faktorn är risknivån som hänger vid den funktionen: ju större konsekvenserna för människor är, desto mer förskjuts en tillämpning mot den tyngre delen av spektrumet. Den tredje faktorn är organisationens egen roll: den som bara använder ett system bedöms annorlunda än den som anpassar det, tränar det vidare eller sammanställer det från andras komponenter. Vad denna rollfördelning exakt innebär och när den förändras beskrivs på sidorna om skillnaden mellan leverantör och användare av ett AI-system och om ögonblicket då en användarroll övergår i ett annat ansvar.

En fjärde faktor är teknisk till sin natur, men juridiskt relevant: vad en organisation själv ändrar i en befintlig modell förändrar ibland organisationens position i helheten. En modell som köps in oförändrad hamnar annorlunda i bilden än en modell som finjusteras på egna data eller byggs in i en egen process. Den gränsen — när anpassning innebär en rollförändring — behandlas på sidan om vad som förändras när en modell själv anpassas.

Vad som förändras när situationen förändras

Eftersom indelningen beror på dessa faktorer är scope inte en fast egenskap hos ett verktyg utan ett utfall som kan ändras. En chattbot som började som intern skrivhjälp kan, så snart den även besvarar kundfrågor som leder till ett beslut, hamna i en annan del av spektrumet. En modell som köptes in som en färdig produkt kan, efter anpassning på egna data, innebära en annan roll för organisationen. En tillämpning som idag gäller som low-impact kan imorgon väga tyngre eftersom sammanhanget den används i har förändrats — ett annat team, ett annat beslut, en annan grupp människor som påverkas av utfallet.

Detta är precis varför en engångsindelning inte räcker. En klassificering som fastställts vid införandet säger ingenting om vad ett verktyg gör ett år senare. Vad som idag bör tas in under scope och vad som kan planeras för senare är därför i sig en fråga som beror på det aktuella läget — utvecklad på sidan om ordningen mellan vad som kräver uppmärksamhet nu och vad som kan följa senare.

Varför detta inte kan avläsas från IT-listan

Indelningen i och utanför scope blir svårare av ett praktiskt problem: den officiella listan över inköpta eller godkända verktyg är inte samma lista som de verktyg som verkligen används. Team tar AI-funktionalitet i bruk utan att låta det gå genom en ansökningsprocess — inte av ovilja, utan eftersom det är lättillgängligt och löser ett problem. Denna skugg-AI är precis den del som gör en indelning i eller utanför scope omöjlig, så länge ingen vet att tillämpningen existerar.

Den som vill komplettera den bilden måste fråga efter den — och då utan att frågan känns som en förtäckt anklagelse. Så snart en medarbetare misstänker att ett ärligt svar leder till en sanktion uteblir svaret och verktyget förblir under radarn. En inventering som byggts på avräkning ger därför per definition en ofullständig bild — och en ofullständig bild gör varje indelning i scope preliminär.

Dokumentera vad indelningen var, och varför

Eftersom scope kan förskjutas är dokumentationen av indelningen minst lika viktig som indelningen själv. Vem beslutade att en tillämpning föll utanför scope, på vilken information baserat, och vid vilken tidpunkt — sådana frågor blir obesvarbara så snart dokumentationen saknas. Hur en organisation gör den typen av beslut inrättningsbara och spårbara beskrivs på sidan om en beslutslogg som gör oversightbeslut spårbara, och hur den indelningen på ett igenkännbart sätt återkommer i det dokument medarbetare faktiskt konsulterar, på sidan om en AI-policy som ansluter till vad människor verkligen gör.

Från indelning till innehållet i arbetet

Indelningsfrågan — vad som faller inom scope och vad som inte gör det — handlar om risk och ansvar, inte om vad en tillämpning betyder för själva arbetet. Den andra frågan, vad en uppgift exakt kan lämna över till AI, är en separat beräkning. Arbetsskanningen från FTE TO AI räknar per uppgift ut vilken del av arbetet som kan tas över, oavsett frågan om hur den tillämpningen hamnar i governance-indelningen.

Andrewde assistent van de Responsible AI Scan

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.