Designa för att AI:n kan ha fel

En AI-funktion har fel ibland. Det är inte en bugg som ska lagas bort — det är en egenskap gränssnittet måste designas för.

Fyra frågor som varje AI-funktion ska besvara i designen:

1. Hur märker användaren att det blev fel?
2. Hur enkelt är det att rätta?
3. Vad händer när funktionen inte fungerar alls?
4. Uppmuntras användaren att kontrollera, eller att lita?

Ett vanligt antimönster: ett färdigt, självsäkert svar utan källa, utan möjlighet att redigera, och utan väg vidare om det är fel. Då har designen gjort felet till användarens problem utan att ge några verktyg.

Motsatsen: ett förslag som går att redigera, med källa bredvid, och en knapp för «gör det manuellt i stället».

Mönster som fungerar, och vad var och ett löser:

Mönster	Löser
Förslag, inte beslut	användaren behåller kontroll och ansvar
Redigerbart resultat	rättning kostar en sekund i stället för att börja om
Källa bredvid svaret	kontroll är ett klick bort
Osäkerhet i ord	«jag är osäker här» säger mer än «0,62»
Ångra, alltid	sänker tröskeln att prova
Väg förbi AI:n	funktionen blir aldrig en återvändsgränd
Tydlig AI-märkning	krav i EU:s AI-förordning för syntetiskt innehåll

Antimönster:

Antimönster	Varför det skadar
Konfidenssiffra utan förklaring	«87 % säker» på vad?
Förklaring som är efterhandskonstruktion	ökar förtroendet utan att öka tillförlitligheten
Dold AI-användning	användaren kan inte kalibrera sin tillit
Svårare att rätta än att acceptera	designen väljer åt användaren

Skiss i tre lägen. Varje AI-funktion bör ritas i tre tillstånd innan den byggs:

┌─ FUNGERAR ─────────────┐  ┌─ OSÄKER ───────────────┐  ┌─ TRASIGT ──────────────┐
│ Förslag:               │  │ Förslag (osäkert):     │  │ Kunde inte skapa ett   │
│ ┌────────────────────┐ │  │ ┌────────────────────┐ │  │ förslag just nu.       │
│ │ redigerbar text    │ │  │ │ redigerbar text    │ │  │                        │
│ └────────────────────┘ │  │ └────────────────────┘ │  │ [Skriv själv]          │
│ Källa: nod X  ⓘ        │  │ ⚠ Kontrollera mot      │  │ [Försök igen]          │
│ [Använd] [Ändra]       │  │   källan innan du       │  │ [Kontakta läraren]     │
│ 👍 👎                  │  │   använder detta.       │  │                        │
└────────────────────────┘  └────────────────────────┘  └────────────────────────┘

Det tredje läget är det som oftast glöms — och det som avgör om användaren kan få något gjort en dålig dag.

Särskilt för barn och unga: tydligt att det är en maskin, inga mörka mönster som förlänger användningen, och en synlig väg till en vuxen. Det är både designprinciper och krav i AI-förordningen och dataskyddslagstiftningen.

Skissa en verklig funktion. Ta AI-grafens «föreslå nästa övning» och rita den i de tre lägena ovan — på papper, det går fortare.

Besvara sedan de sju frågorna:

#	Fråga	Ditt svar
1	Framgår det att förslaget kommer från AI?
2	Vad ser eleven när systemet är osäkert?
3	Hur ändrar eleven förslaget?
4	Vad händer om tjänsten är nere?
5	Kan eleven se varför förslaget gavs?
6	Finns en väg till en människa?
7	Uppmuntras eleven att tänka själv?

Testa sedan skissen på någon annan med tre uppgifter:

1. «Använd förslaget.»
2. «Förslaget är fel — gör något annat i stället.»
3. «Ta reda på varför systemet föreslog detta.»

Uppgift 2 och 3 är de som avslöjar problemen. Om testpersonen tvekar mer än några sekunder är designen otydlig — och det är mycket billigare att upptäcka på papper än efter att funktionen är byggd.

En sista kontroll: gå tillbaka till skissen och räkna antalet klick för att acceptera mot antalet för att rätta. Är det fler för att rätta har designen tagit ställning åt användaren.