Från idé till pilot: vad är PoC, prototyp och pilot?

Varför börja med en avgränsad testfas?

Projekt med språkmodeller eller maskininlärning innehåller osäkerheter som inte alltid går att lösa på papper. Det kan vara oklart om datan räcker, om modellen klarar verksamhetens språk, om användarna litar på resultatet eller om lösningen går att integrera med befintliga system.

En avgränsad testfas gör osäkerheterna synliga och omvandlar dem till beslutspunkter. Syftet är inte att bygga en imponerande demo, utan att samla tillräckligt med bevis för att välja nästa steg.

En bra pilot ska inte bevisa att tekniken är spännande. Den ska ge underlag för ett affärsbeslut.

Förstudie, PoC, prototyp och pilot – skillnaden

Förstudie: är problemet värt att lösa?

Förstudien undersöker behov, berörda användare, tillgängliga data, risker och möjliga lösningsvägar. Här ska ni kunna beskriva vilket arbetsmoment som förändras, vem som äger nyttan och hur ett bättre utfall kan mätas.

Leveransen är vanligen en avgränsning, en första kravbild, identifierade risker och en rekommendation. En förstudie behöver inte innehålla fungerande kod.

Proof of Concept: är den kritiska idén tekniskt möjlig?

En PoC testar den mest osäkra tekniska hypotesen. Kan en matchningsmodell rangordna relevanta alternativ? Kan en språkmodell hämta rätt avsnitt ur verksamhetens dokument? Går den nödvändiga datakällan att ansluta?

En PoC kan vara liten och tekniskt rå. Den behöver inte ha ett färdigt gränssnitt eller stöd för många användare. Däremot måste testet ha ett tydligt godkänt resultat: vad behöver fungera för att hypotesen ska anses styrkt?

Prototyp: hur kan lösningen fungera för en användare?

Prototypen gör idén möjlig att använda och utvärdera i ett sammanhängande flöde. Den kan innehålla ett enkelt gränssnitt, flera tekniska komponenter och realistiska exempeldata. Här går det att samla in feedback om begriplighet, arbetsflöde och vilka funktioner som faktiskt behövs.

En prototyp är fortfarande inte byggd för full drift. Behörigheter, övervakning, incidenthantering och kapacitet kan vara förenklade. Det måste vara tydligt för testarna vad som är tillfälligt.

Pilot: fungerar lösningen i verksamheten?

Piloten prövar lösningen med verkliga användare, verkliga arbetsuppgifter och en avgränsad del av den faktiska miljön. Fokus flyttas från enbart teknisk prestanda till användning, nytta, risk och förvaltning.

En pilot behöver därför ha definierade användargrupper, behörigheter, support, mätetal och en plan för hur fel hanteras. Den ska avslutas med ett beslut: skala upp, ändra inriktning, genomför en ny avgränsad test eller avsluta.

Produktion: håller lösningen över tid?

I produktion måste lösningen fungera för avsedda användare med stabila integrationer, rätt åtkomst, övervakning, dokumenterad kvalitet och tydligt ägarskap. Den behöver tåla förändringar i data, modeller, kostnader och verksamhetens krav.

Vilken fas passar ert behov?

Utgå från den största obesvarade frågan.

• Om ni inte kan formulera problemet eller nyttan: börja med en förstudie.

• Om den tekniska genomförbarheten är osäker: gör en PoC.

• Om ni behöver förstå användarflödet: bygg en prototyp.

• Om tekniken fungerar men effekten i verksamheten är okänd: genomför en pilot.

• Om nytta, kvalitet och risk är tillräckligt bevisade: planera för produktion.

Det är inte alltid nödvändigt att använda alla benämningar eller göra separata projekt av varje fas. I ett litet initiativ kan PoC och prototyp genomföras tillsammans. Det viktiga är att frågorna inte hoppas över.

Vad ska mätas i en pilot?

Måtten ska kopplas till det problem piloten ska lösa. För en kunskapsassistent kan det vara tid till rätt information, andel svar med stöd i rätt källa och antal ärenden som behöver eskaleras. För en prognosmodell kan det vara prognosfel jämfört med en enkel baslinje och hur utfallet påverkar lager eller planering.

En balanserad pilot mäter minst fyra områden:

• Verksamhetsnytta: tid, kvalitet, kostnad, intäkt eller annan relevant effekt.

• Teknisk kvalitet: precision, relevans, stabilitet, svarstid och kapacitet.

• Risk och säkerhet: felaktiga svar, behörighetsöverträdelser, dataläckage och incidenter.

• Användning: hur ofta lösningen används, i vilka uppgifter och varför användare avstår.

Mät alltid mot en baslinje. Utan nuläge går det inte att veta om piloten har förbättrat arbetet.

Data, säkerhet och användare måste finnas med från början

Att skjuta upp säkerhet och dataskydd till produktionsfasen skapar ofta ombyggnad. Redan i testfasen behöver organisationen veta vilken information som används, vem som får se den och om personuppgifter eller sekretesskyddat material behandlas.

Användarna behöver också delta tidigt. En tekniskt korrekt lösning kan misslyckas om den hamnar utanför det verkliga arbetsflödet eller kräver mer kontrollarbete än den sparar.

NIST:s ramverk betonar att riskhantering behöver löpa genom systemets livscykel, inte läggas till som en slutkontroll.[1] Digg rekommenderar på motsvarande sätt att offentliga aktörer utgår från behov, information och ansvar när de fattar beslut om generativ teknik.[2]

Tre exempel på avgränsade tester

Matchning mellan profiler och möjligheter

En PoC kan testa om en flerspråkig embeddingmodell kan rangordna jobb eller utbildningar utifrån ett begränsat antal anonymiserade profiler. Nästa steg är att granska relevans, snedvridning och vilka delar av personinformationen som bör påverka matchningen.

Efterfrågeprognoser

En första modell kan tränas på en tydligt avgränsad tidsserie och jämföras med en enkel statistisk baslinje. Om modellen ger stabil förbättring kan fler faktorer, platser och arbetsflöden läggas till i en pilot.

Chatt på interna dokument

En prototyp kan anslutas till en begränsad dokumentmängd och testas av en utvald grupp. Frågorna bör omfatta korrekta svar, saknat underlag, motstridiga dokument och information som användaren inte ska få se.

När är lösningen redo för produktion?

En pilot är redo att gå vidare när verksamhetsägaren kan svara ja på följande frågor:

• Har vi visat en mätbar förbättring jämfört med nuläget?

• Är kvaliteten tillräcklig för uppgiften och dokumenterad med representativa tester?

• Är datakällor, rättslig grund och informationsklassning hanterade?

• Följer åtkomsten användarens faktiska behörighet?

• Vet användaren när resultatet måste kontrolleras av en människa?

• Finns ägare för produkt, data, säkerhet och förvaltning?

• Kan vi övervaka kostnad, kapacitet, fel och förändringar över tid?

Om svaret är nej behöver det inte betyda att idén ska avslutas. Piloten kan ha gjort sitt jobb genom att visa exakt vad som måste förändras.

Vanliga misstag

Det vanligaste misstaget är att välja teknik före problem. Ett annat är att bygga för många funktioner innan den kritiska hypotesen är testad. Projekt fastnar också när en pilot saknar beslutsägare eller när den bedöms utifrån entusiasm i stället för mätetal.

Undvik även att behandla prototypkod som automatiskt produktionsklar. En demo kan sakna nästan allt som krävs för stabil drift: identitet, loggning, övervakning, felhantering, kostnadskontroll och plan för modellbyten.

Checklista inför en pilot

• Ett avgränsat verksamhetsproblem och en namngiven problemägare.

• En prioriterad användargrupp och verkliga arbetsuppgifter.

• Tillgängliga, tillåtna och kvalitetsgranskade data.

• Identifierade säkerhets-, integritets- och regelkrav.

• Mätetal, baslinje och acceptanskriterier.

• Tidsram, budget och tydliga beslutspunkter.

• En plan för förvaltning eller avveckling efter piloten.

Källor

1. NIST, AI Risk Management Framework:
   https://www.nist.gov/itl/ai-risk-management-framework

2. Digg, Ta medvetna beslut om att skaffa generativ AI:
   https://www.digg.se/ai-for-offentlig-forvaltning/riktlinjer-for-generativ-ai/ta-medvetna-beslut-om-att-skaffa-generativ-ai