Data ni behöver för AI — och data ni inte behöver

Nästan varje samtal om AI i ett företag kommer förr eller senare till data. Ofta i form av en oro: vår data är inte tillräckligt bra, den ligger i för många system, vi har inte städat på flera år. Ibland i form av en plan: först bygger vi ett datalager, sedan en dataplattform, och sedan börjar vi med AI.

Båda reaktionerna är förståeliga, och båda leder ofta fel. Det här kapitlet handlar om vilken data ett första AI-flöde faktiskt behöver, vilken data som kan vänta och hur ni tar reda på skillnaden utan att starta ett flerårigt dataprojekt.

Den vanligaste missuppfattningen

Den vanligaste missuppfattningen är att AI kräver stora mängder historisk data som modellen ska tränas på. Det stämde för tidigare generationer av maskininlärning, där en modell för att förutsäga till exempel kundbortfall behövde tusentals historiska exempel för att lära sig mönstret.

Dagens språkmodeller fungerar annorlunda. De är redan tränade på enorma mängder text och kan läsa, skriva och resonera. Det de behöver från er är inte träningsdata, utan tre andra saker:

1. Instruktioner som beskriver uppgiften, reglerna och vad ett bra resultat är.
2. Rätt information vid rätt tillfälle, till exempel kundens order när ett ärende om en försenad leverans ska besvaras.
3. Exempel som visar hur uppgiften brukar lösas och som används för att testa att systemet gör rätt.

Det förändrar frågan. Den är inte längre "har vi tillräckligt med data för att träna en modell?" utan "finns informationen som behövs för uppgiften, och kan systemet komma åt den?".

Tre sorters data i ett AI-flöde

För att bedöma datan i ett flöde hjälper det att dela upp den i tre sorter.

Det som kommer in

Det flödet börjar med: ett mejl, en faktura, en beställning, en ansökan, ett ärende. Det här är ofta ostrukturerad text eller dokument, och det är precis vad språkmodeller är bra på att läsa. Ni behöver inte städa den i förväg, men ni behöver veta vilka varianter som förekommer. Kommer fakturor som PDF, som bild, som e-faktura? Skriver kunderna på svenska, engelska, båda?

Det som slås upp

Den information systemet behöver hämta för att lösa uppgiften: kunddata, ordrar, artiklar, avtal, priser, policyer. Den finns oftast i era befintliga system, och det är här kvaliteten spelar störst roll. Om artikelregistret har dubbletter eller kundregistret saknar organisationsnummer kommer systemet att göra fel, på samma sätt som en ny medarbetare skulle göra fel.

Det som visar vad rätt är

Exempel på hur uppgiften har lösts tidigare, med facit. Hur kategoriserades de senaste tusen ärendena? Vilket konto konterades fakturorna på? Vilka svar skickades till kunderna? Den här datan används för att skriva instruktioner, testa systemet och mäta kvaliteten. Den behöver inte vara stor, men den behöver vara representativ.

Vad ett första flöde behöver

För ett första flöde är kraven oftast mindre än man tror. Det behöver:

• Tillgång till det som kommer in, i den form det kommer.
• Läsåtkomst till de system där uppslagsinformationen finns, via ett gränssnitt eller en export.
• Ett par hundra representativa exempel med facit för att testa och mäta.
• Skrivåtkomst till det system där resultatet ska hamna, eller en kö där en människa tar över.

Det behöver inte ett datalager, en dataplattform, fem års historik eller en fullständigt städad kunddatabas. Det behöver bara att den data som just det här flödet använder är tillräckligt bra för just den här uppgiften.

Så bedömer ni datakvaliteten

Ett enkelt sätt att bedöma om datan räcker är att tänka på en ny medarbetare. Om en kompetent person som är ny på jobbet skulle klara uppgiften med samma information som systemet får, finns det goda förutsättningar. Om personen skulle behöva fråga en kollega varje gång, saknas något.

Gör sedan en praktisk kontroll. Ta ett urval av riktiga fall, gärna femtio till hundra, och gå igenom dem ett och ett.

• Finns all information som behövs för att lösa fallet?
• Finns den i ett system, eller bara i någons huvud eller i en mejlkorg?
• Stämmer den, eller måste den kontrolleras mot något annat?
• Är facit tydligt, eller skulle två erfarna medarbetare vara oense?

Räkna hur stor andel av fallen som klarar alla fyra frågorna. Den andelen är en bra första uppskattning av hur stor del av flödet som kan automatiseras, och den används direkt i kalkylen för projektet.

Vanliga dataproblem, och vad ni gör åt dem

Vissa problem återkommer i nästan alla företag. De flesta går att hantera utan att stoppa projektet.

Kunskap som bara finns i huvuden. Regler som "den här kunden ska alltid ha fraktfritt" eller "den här leverantören skickar alltid fakturan två gånger" finns sällan dokumenterade. Kartläggningen är rätt tillfälle att skriva ner dem. Det är en av de mest värdefulla effekterna av ett AI-projekt, även för de delar som inte automatiseras.

Dubbletter och inkonsekvenser. Samma kund finns två gånger, samma artikel har tre namn. Städa det som påverkar det första flödet, inte hela registret. Bygg systemet så att det flaggar osäkra matchningar i stället för att gissa.

Data i dokument i stället för i system. Avtal i PDF, prislistor i kalkylark, instruktioner i delade mappar. Det går ofta att låta AI läsa dokumenten direkt, men se till att det finns en tydlig källa och att gamla versioner inte ligger kvar och förvirrar.

Data som inte går att komma åt. Ett äldre system utan gränssnitt kan vara ett verkligt hinder. Lösningar finns, till exempel exporter, mellanlager eller att systemet läser det en människa annars hade läst. Men det påverkar kostnaden och bör synas tidigt i planeringen.

Data som kan vänta

Lika viktigt som att veta vad som behövs är att veta vad som kan vänta. Följande behövs sällan för ett första flöde:

• Ett gemensamt datalager för hela företaget. Det kan bli värdefullt när flera flöden behöver samma data, men det är inte ett krav för att börja.
• Historik längre än några månader. För att skriva instruktioner och testa räcker ett representativt urval av nyliga fall.
• Städning av alla register. Städa det flödet använder. Resten kan vänta tills ett flöde behöver det.
• En egen tränad modell. I de flesta fall räcker en befintlig modell med bra instruktioner och tillgång till rätt information.

Det betyder inte att datan är oviktig. Det betyder att arbetet med datan bör drivas av de flöden som ska använda den, inte göras i förväg i hopp om att den ska komma till nytta någon gång.

Vem som äger datan

Ett dataproblem som sällan syns i tekniska planer är ägarskapet. Vem ansvarar för att artikelregistret stämmer? Vem bestämmer vilken version av prislistan som gäller? Vem rättar när en kund finns två gånger?

I många företag är svaret oklart, och det märks först när ett AI-system börjar använda datan. En människa som hittar en konstig uppgift frågar en kollega och går vidare. Ett system gör fel, och felet upprepas tills någon rättar källan.

Utse därför en ägare för varje datakälla som det första flödet använder. Ägaren behöver inte vara tekniker. Det ska vara den person i verksamheten som vet vad som är rätt och har mandat att bestämma det. Bestäm också hur fel rapporteras och rättas. Ett enkelt sätt är att systemet samlar de fall där datan var bristfällig i en lista som ägaren går igenom varje vecka.

Det låter som administration, men det är ofta det som avgör om systemet blir bättre eller sämre över tid.

När är datan tillräckligt bra?

Det finns ingen gräns där datan plötsligt blir bra nog. Men det finns en praktisk tumregel: datan är tillräckligt bra när systemet kan hantera de vanliga fallen rätt och känner igen när det inte kan.

Det andra ledet är viktigast. Ett system som vet när det är osäkert och lämnar över till en människa kan fungera bra även med ofullständig data. Ett system som gissar när det är osäkert är farligt även med nästan perfekt data.

Därför är det sällan rätt att vänta på bättre data. Bygg systemet så att osäkra fall flaggas, mät hur stor andel som flaggas och på grund av vad, och använd den informationen för att prioritera vilken data som ska förbättras först. Då blir dataarbetet styrt av verkliga behov i stället för av en allmän känsla av att allt borde vara bättre.

Säkerhet och dataskydd

Data i ett AI-flöde ska hanteras med samma omsorg som data i alla andra system, och ibland med lite mer.

• Välj var datan behandlas. Använd leverantörer som behandlar data inom EU när det gäller personuppgifter, och som avtalsmässigt inte använder er data för att träna sina modeller.
• Ge systemet minsta möjliga åtkomst. Ett system som ska kategorisera ärenden behöver inte kunna läsa löner. Begränsa åtkomsten till det flödet behöver.
• Logga vad systemet gör. Vilken information hämtades, vilket beslut fattades, vem granskade? Det gör det möjligt att följa upp fel och att visa hur systemet fungerar.
• Ta med dataskyddsansvarig tidigt. Personuppgifter kräver en rättslig grund och i vissa fall en konsekvensbedömning. Det är enklare att bygga in från början än att lägga till i efterhand.

Mer om hur säkerheten byggs in i själva systemet finns i kapitlet från pilot till drift.

Ett exempel

Ta ett tänkt tjänsteföretag som vill automatisera sorteringen av inkommande kundärenden. Ärendena kommer via mejl och ett webbformulär, cirka 800 i veckan, och sorteras i dag manuellt till fem team.

Det som kommer in är fritext på svenska och engelska, ibland med bilagor. Det som slås upp är kundregistret, för att se vilket avtal kunden har, och en lista över teamens ansvarsområden. Det som visar vad rätt är finns i ärendesystemet, där varje ärende har ett team och en kategori.

Kartläggningen visar tre saker. Kundregistret har dubbletter för en del större kunder, vilket påverkar vilket avtal som hittas. Teamens ansvarsområden finns bara som muntlig kunskap. Och ungefär vart tionde ärende har sorterats om efter att det kommit till fel team, vilket betyder att facit inte alltid är rätt första gången.

Inget av det stoppar projektet. Dubbletterna för de största kunderna städas. Ansvarsområdena skrivs ner, vilket alla teamen dessutom har nytta av. Och facit hämtas från var ärendet till slut hamnade, inte var det först lades. Hela dataarbetet tar några veckor, inte några år.

När systemet sedan är i drift visar flaggningen var det fortfarande brister. Kanske är det ärenden från en viss kundgrupp som ofta blir osäkra, eller en kategori som teamen själva tolkar olika. Det blir nästa sak att rätta, och så fortsätter det. Datan blir bättre för att den används, inte för att den städades i förväg.

Sammanfattning

• Dagens AI behöver sällan träningsdata. Den behöver instruktioner, rätt information vid rätt tillfälle och exempel att testa mot.
• Dela upp datan i tre sorter: det som kommer in, det som slås upp och det som visar vad rätt är.
• Ett första flöde behöver tillgång till sin egen data och ett par hundra representativa exempel, inte ett datalager.
• Bedöm kvaliteten genom att gå igenom riktiga fall. Andelen som har all information som behövs är en bra första uppskattning av vad som kan automatiseras.
• Låt flödena driva dataarbetet. Städa det som används, och låt resten vänta.
• Bygg in säkerhet och dataskydd från början. Hur ni hittar det första flödet beskrivs i kapitlet om att hitta det manuella arbetet.