PoC (Proof of Concept)

PoC er en kort, teknisk afprøvning der viser, om en AI-idé kan fungere i praksis. En PoC arbejder typisk med et lille datasæt, få scenarier og uden rigtige brugere, og den fokuserer på teknisk gennemførlighed, ikke på drift, brugertilfredshed eller forretningscasen. Resultatet er enten et ja/nej på om idéen er mulig, eller en liste over næste tekniske problemer.

Sådan virker en PoC i praksis

En PoC er en prøve, ikke et produkt. Typisk vælger I et repræsentativt datasæt, måske en CSV med 12.000 linjer eller ti PDF-rapporter, og I lader leverandøren eller et internt team køre en model på det. I måler nogle få tekniske mål: nøjagtighed, fejltyper og om løsningen kan hente data fra de filer, I rent faktisk bruger. Brugere er som regel ikke involveret; det handler om at bekræfte teknikken.

Analogi: det er som at tage en bil på en kort prøvetur rundt om blokken. Du finder ud af, om motoren starter og rattet drejer, men du ved ikke, om bilen kan klare en længere tur med last eller vintervejr.

Når leverandøren tilbyder en gratis PoC: hvad skal du se efter

Leverandører reklamerer ofte med gratis eller billig PoC. Som beslutningstager skal du kræve klarhed på: scope, succesmål og dataejerskab. Spørg direkte om disse punkter, før I starter:

• Hvad er succeskriteriet? (fx >80% korrekt klassifikation på et udvalgt datasæt)
• Hvilke data bruger I? Er det altså produktionsdata, eller et lille, renset udsnit?
• Hvem ejer resultaterne, koden og eventuelle modeller efter endt PoC?
• Hvad koster integration til drift senere, og hvem gør det?
• Hvilken dokumentation får I, prototype, kode eller blot en rapport?

Husk, en PoC kan vise teknisk potentiale, men den siger ingenting om brugernes vilje til at ændre arbejdsgange, om løbende drift eller om totaløkonomi. Mange projekter går i stå efter PoC, fordi der ikke er planlagt et pilotforløb, ansvar eller budget til næste fase.

Eksempel: PoC hos en økonomichef i en mellemstor grossist

Økonomichefen i en grossist får tilbudt en PoC for automatisk at matche indkøbsfakturaer med indkomne ordrer. Det er midt i regnskabsårets første kvartal, og regnskabet skal lukkes om tre uger. IT leverer et udsnit: 4.500 fakturalinjer fra sidste kvartal i en enkelt CSV. Leverandøren kører PoC på to uger og returnerer en prototype, der rammer rigtigt på 78 procent af linjerne.

Modstanden dukker op, da økonomichefen beder om en plan for drift: IT siger, data fra tidligere år er fyldt med varierende leverandørkoder, og fakturaer kommer som skannede PDF’er fra nogle leverandører. PoC’en brugte kun den pæne CSV; den siger ikke noget om de skannede PDF’er, eller hvad det kræver at få løsningen ind i økonomisystemet. To IT-konsulenter brugte i alt 20 timer på at dokumentere kravene, og økonomichefen må beslutte, om der er budget til en pilot, eller om PoC’en blot blev en teknisk demonstrator.

PoC er ikke det samme som pilot eller produktion

En pilot involverer rigtige brugere i et kontrolleret miljø, overvågning af adoption og ofte integration med dele af jeres drift. Produktion er fuld drift med SLA, sikkerhed, backup og vedligehold. PoC beviser kun, at noget kan lade sig gøre teknisk; den beviser ikke, at det virker i jeres hverdag, at medarbejdere vil bruge det, eller at det kan driftes økonomisk.

Sådan går I videre fra en PoC

1. Beslut på forhånd hvad et ja betyder: definer succes og et klart scope for en pilot.
2. Undersøg data og integration: lav en kort rapport om, hvad der mangler for at køre i drift, og estimer tid og pris.
3. Tildel ejerskab: peg på en intern ansvarlig for pilot, drift og budget.
4. Planlæg pilot med rigtige brugere og mål for adoption, ikke kun tekniske metrics.
5. Forbered kontrakt og databehandling: afklar ejerforhold til modeller, kode og persondata, inden I betaler mere.

En PoC kan være et stærkt beslutningsværktøj, men kun hvis I kræver klare succeskriterier, kortlægger hvad den ikke viser, og planlægger næste skridt, før I lukker projektet ned.

Valget om PoC er sjældent kun teknisk. Retningen sættes med AI-rådgivning.