Så bygger du tillförlitlig AI: Ett ramverk med fyra pelare för projektteam
Den här artikeln är anpassad från ett avsnitt av podcasten The Digital Project Manager, med ett samtal mellan programledaren Galen Low och Cal Al-Dhubaib, chef för AI & datavetenskap på Further. Lyssna på det här.
Ansvar för tillit: Brist på individuellt ansvar undergräver ofta tilliten i AI-projekt och försvårar ansvarsutkrävandet.
Tillitsutveckling: Ett ramverk som kallas tillitsutveckling främjar ett gemensamt språk mellan olika intressenter i AI-design.
Fyra pelare: Tillförlitlig AI bygger på fyra pelare: förväntningshantering, beslutsdesign, styrning och tillitsinfrastruktur.
Projektfrågor: Team bör överväga tre viktiga frågor för att säkerställa effektiv styrning och riskhantering i AI-lösningar.
Mätning av tillit: Användarbeteende fungerar som en viktig indikator på tillit och effektivitet i AI-system.
Varför förtroende behöver en ansvarig
De flesta AI-projekt stöter på samma problem innan de ens kommer igång: ingen har uttryckligen ansvar för huruvida systemet går att lita på. Cal Al-Dhubaib, chef för AI & datavetenskap på Further, har sett detta utspela sig i olika branscher, och han är tydlig med grundorsaken. ”Det enkla svaret är att ingen äger det som standard, och det är det stora problemet”, säger han.
Ingen äger det [AI-förtroendet], och det är det stora problemet.
Problemet är inte brist på engagemang — det är brist på tydlighet kring vems uppgift det faktiskt är. ”En intressant sak med ansvar är att om det är allas ansvar så äger ingen det, och därför behöver man i slutändan en person som tar ansvar för den här aspekten”, förklarar Al-Dhubaib. På Further är den principen inte bara teoretisk. ”Vi har faktiskt utsett en sådan person för vart och ett av de här AI-projekten, så att vi kan se till att vi ställer rätt frågor.”
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Vad förtroendearbete faktiskt är
Al-Dhubaibs svar på ansvarsbristen är ett ramverk som han kallar förtroendearbete — i grunden ett gemensamt språk för de många discipliner som berör ett AI-system. ”Det är en gemensam kommunikationsverktygslåda som hjälper olika yrkesroller som samarbetar kring utformningen av AI-lösningar och införandet av AI-lösningar att prata mer konstruktivt om hur man bevarar förtroendet”, säger han.
Behovet av den gemensamma verktygslådan beror på hur fragmenterat samtalet vanligtvis är. Ingenjörer, riskansvariga, styrningsansvariga, UX-designers och affärsintressenter betraktar alla samma system genom olika perspektiv. ”Det behövdes ett gemensamt sätt för alla dessa människor att prata om samma sak och ha en liknande förståelse för på vilka sätt förtroendet kan kränkas av AI”, säger Al-Dhubaib, ”samt verktygslådor för hur man försvarar sig mot det.”
Det behövdes ett gemensamt sätt för alla dessa människor att prata om samma sak och ha en liknande förståelse för på vilka sätt förtroendet kan kränkas av AI.
De fyra pelarna för tillförlitlig AI
Förtroendearbete kan delas upp i fyra praktiska pelare — hantering av förväntningar, beslutsdesign, styrning och förtroendeinfrastruktur. Var och en behandlar en annan punkt där AI-system tenderar att förlora människors förtroende.
Pelare 1: Hantering av förväntningar
Den första pelaren handlar om omfattning. Generativa AI-system är ofta alltför öppna för sitt eget bästa, och denna öppenhet kan överväldiga just de användare som systemen är tänkta att hjälpa. ”Det är bra att ha ett begränsat antal saker som jag kan göra med det här verktyget”, konstaterar Al-Dhubaib.
Han nämner ett verkligt exempel från sitt arbete med Behr Paint, där målet var att minska beslutströttheten vid färgval. ”Du går till Home Depot och ser den stora visningen av färger”, säger han och beskriver hur kunder — inklusive han själv — fastnar. ”Och du blir väldigt överväldigad om du måste välja.” Lösningen var inte mer AI — utan en mer avgränsad och mer genomtänkt upplevelse.
Pelare 2: Beslutsdesign
Den andra pelaren handlar om de skyddsregler som omger de beslut ett AI-system tillåts fatta. ”Hur ger du användarna rätt mängd information och rätt mängd skyddsregler så att de vet hur systemet ska användas på ett bra sätt?” frågar Al-Dhubaib.
I Behr Paint-projektet innebar detta att dra en tydlig gräns för vilken typ av råd AI:n säkert kunde ge. Färgval var helt okej; allt som rörde färgblandning eller applicering krävde att ärendet lämnades över till en människa. ”Om samtalet någon gång börjar glida åt det hållet uppmanar den snabbt användaren med: här är vår hjälplinje för hjälp med just den här frågan”, säger Al-Dhubaib.
Om samtalet någon gång börjar glida åt det hållet uppmanar den snabbt användaren med: här är vår hjälplinje för hjälp med just den här frågan.
Systemet byggdes också med skyddsräcken för anseendet i åtanke — ”det låter sig inte heller mobbas till att säga saker som du inte vill att det ska säga, för att sedan skärmdumpas och spridas över hela internet.”
Pelare 3: Styrning
Den tredje pelaren behandlar en fråga som inte kan besvaras av ingenjörer ensamma: vad betyder ens ”rättvist” eller ”korrekt” för just det här företaget? Al-Dhubaib beskriver ett projekt som omfattade en modell för antagning av studenter, där kunden ville säkerställa kvaliteten bland olika demografiska grupper. ”Det finns 22 olika sätt att beräkna rättvisa”, säger han. ”Och ärligt talat ligger det utanför ingenjörens ansvarsområde. Jag kan berätta vilken formel det är och hur man beräknar den på flera olika sätt. Jag kommer att behöva luta mig mot er när ni ska säga: vilken är er policy? Hur ser ni på den här definitionen och vad är korrekt för er?”
Det styrningsarbetet slutar inte vid interna beslut — det måste också kommuniceras utåt. Som Al-Dhubaib uttrycker det dokumenteras allt detta och delas ”i ett användarvänligt systemkort”.
Pelare 4: Tillitsinfrastruktur
Den sista pelaren omfattar de verktyg och processer som håller ett AI-system ärligt när det väl är i drift. Han illustrerar pelaren genom en kontrast mellan två välkända snabbmatskedjor. Den ena tog bort sitt AI-system för röstbeställningar efter att det inte konsekvent kunde ta emot korrekta beställningar.
Den andra valde en annan strategi: ”Å andra sidan har vi Domino's, där 80 % av deras beställningar via telefon nu hanteras av ett AI-system”, med mänskliga arbetsledare som övervakar samtal i realtid och ingriper vid behov, samt ”lämpliga granskningsåtgärder på plats för att säkerställa att beställningarna fortsätter att överensstämma med det användaren sa.” Skillnaden låg enligt Al-Dhubaib inte i den underliggande tekniken. ”Jag tror inte att detta var ett misslyckande när det gäller tekniken, utan snarare ett misslyckande med att sätta rätt skyddsräcken runt tekniken.”
Jag tror inte att detta var ett misslyckande när det gäller tekniken, utan snarare ett misslyckande med att sätta rätt skyddsräcken runt tekniken.
Tre frågor som varje projektteam bör ställa
Utöver de fyra pelarna erbjuder Al-Dhubaib projektteam ett enkelt verktyg för diagnos i alla samtal om AI-styrning — tre frågor som ställs i tur och ordning.
För det första: ”Vad har ni gjort på förhand för att testa och säkerställa att ni har minimerat den potentiella skadan eller de potentiella riskerna som är inneboende i den här AI-lösningen?” För det andra, när systemet är i drift: ”Hur ska ni veta när det gör ett misstag?” Och för det tredje — frågan som enligt honom oftast förbises — ”Vad gör ni då? Hur får ni det gjort? Har ni faktiskt stresstestat den planen?”
Så vet du om det fungerar
Tillit är inte bara en designprincip; den går att mäta. Al-Dhubaib pekar på användarnas beteende som en av de tydligaste signalerna ett team har. ”Uppnår användaren ert mål?” frågar han och återkommer till Behr-exemplet — når människor faktiskt fram till att lära sig mer om en färgspecifikation, slutföra interaktionen och återvända till verktyget.
I slutändan kopplar han nyttan direkt tillbaka till tilliten: ”Vi är helt enkelt inte användbara — eftersom det också är en del av tilliten.”
Slutsatsen
Tillitsarbete är inte en checklista som läggs till i slutet av ett projekt — det är en serie designval som görs under hela processen, kring vad systemet ska och inte ska göra och vem som ansvarar för varje beslut. Som Al-Dhubaib uttrycker det: ”Ni måste definiera vad som är korrekt och vilka antaganden ni tänker göra gällande. Det här är alla designval som kan göras som en del av tillitsarbetet.”
Vill du ha fler insikter som dessa? Registrera dig för ett kostnadsfritt DPM-konto för att höra från fler experter som dessa.
