Bygga en POC med AI på en vecka: Så gör vi

Många företag pratar om AI i månader. De har workshops, bygger strategier, tillsätter kommittéer och diskuterar risker tills alla i rummet har tappat energin. Det skrivs långa kravspecifikationer för system som ingen ens vet om de går att bygga. Vi på BijoyIQ gör tvärtom. Vi bygger en Proof of Concept (POC) på en vecka.

Varför just en vecka? För att momentum är allt. Om du inte kan bevisa att en idé har potential på fem dagar är det förmodligen fel idé eller fel angreppssätt. En vecka tvingar fram beslut. Det tvingar oss att skala bort allt fluff, ignorera funktioner som vore trevliga att ha och fokusera stenhårt på kärnan i problemet. Det handlar ju om att gå från prat till verkstad innan någon hinner boka in ett nytt uppföljningsmöte.

Här är exakt hur vi gör det dag för dag och vad du som kund kan förvänta dig av processen.

Dag 1: Hitta det riktiga problemet (och datan)

Måndagen handlar inte om kod. Den handlar om att förstå vad vi faktiskt försöker lösa. Ofta kommer en kund till oss och säger att de vill ha en AI som gör en viss sak. Efter en timmes samtal inser vi att det egentliga problemet är något helt annat.

Låt oss säga att ett företag vill ha en chatbot som svarar på kundfrågor. När vi gräver djupare visar det sig att kundtjänsten lägger 40 % av sin tid på att manuellt kategorisera inkommande mail och skicka dem till rätt avdelning. Chatbotten är en kul idé, men den automatiska kategoriseringen är det som faktiskt sparar pengar imorgon.

Vi ställer två brutala frågor:

Om vi löser detta, sparar det tid eller pengar på riktigt?
Har vi datan som krävs för att lösa det idag?

Det sista är avgörande. Vi bygger inte en POC på syntetisk data eller löften om att datan kommer sen när IT-avdelningen har tid. Vi använder det som finns. Om datan ligger i röriga Excel-filer, utdrag från ett gammalt affärssystem eller i en rörig inkorg är det där vi börjar. Målet är att avgränsa projektet så hårt att det går att bygga på några dagar. Vi väljer en specifik process, en specifik datamängd och ett tydligt mål.

Dag 2 och 3: Bygga snabbt och fult

Tisdag och onsdag är våra byggdagar. Här handlar det uteslutande om hastighet. Vi sätter inte upp komplexa mikrotjänster, vi bygger inte skalbar infrastruktur i molnet och vi bryr oss inte om CI/CD-pipelines. Vi bygger en prototyp som fungerar.

Ofta använder vi oss av vibecoding. Vi låter AI-verktyg hjälpa oss att skriva koden snabbt. Vi kopplar ihop API:er från OpenAI, Anthropic eller lokala modeller med kundens data. Vi skriver skript som rensar datan nödtorftigt och skickar in den i modellen.

Gränssnittet blir ofta extremt enkelt. Kanske en ful webbsida med en enda knapp, en Slack-bot som svarar när man pingar den eller ett Python-skript som spottar ur sig resultat i en terminal. Det ska inte vara snyggt. Det ska fungera tillräckligt bra för att vi ska kunna testa hypotesen.

Om vi bygger en AI som ska klassificera inkommande kundtjänstärenden vill vi se om den faktiskt kan träffa rätt på 100 historiska mail. Vi testar olika promptar och olika modeller. Vi letar efter den snabbaste vägen till ett svar på om det fungerar eller om det är för svårt.

Dag 4: Verklighetstestet

Torsdagen är dagen då vi låter prototypen möta verkligheten. Vi sätter den i händerna på de personer som faktiskt ska använda den. Inte cheferna, utan de som gör jobbet på golvet.

Det är här det blir intressant. Modellen kanske är fantastisk på att analysera text, men användarna hatar gränssnittet. Eller så inser vi att AI:n missar en specifik typ av ärenden som är viktiga för verksamheten, men som ingen tänkte på att nämna i måndags.

Vi sitter bredvid användarna. Vi ser hur de interagerar med systemet. Vi justerar promptar i realtid, skruvar på logiken och itererar snabbt. Det är nu vi ser om idén har vingar. Om användarna säger att det skulle spara dem två timmar om dagen vet vi att vi är på rätt spår. Om de säger att det tar längre tid än att göra det manuellt har vi lärt oss något viktigt och måste tänka om.

Dag 5: Utvärdering och nästa steg

Fredagen handlar om att svara på en enda fråga: Ska vi gå vidare?

En POC är ett experiment. Experiment kan misslyckas. Ibland inser vi att tekniken inte är mogen, att datan är för dålig, att hallucinationerna är för många eller att problemet inte var så stort som vi trodde. Då stänger vi ner projektet.

Det är en vinst i sig. Vi har sparat månader av utvecklingstid och hundratusentals kronor genom att döda en dålig idé snabbt. Företaget kan gå vidare till nästa idé utan att ha bränt hela sin innovationsbudget.

Men oftast ser vi potentialen. Vi har bevisat att det går. Vi har visat att AI kan lösa problemet med 85 % träffsäkerhet, och vi vet vad som krävs för att nå 95 %. Då tar vi fram en konkret plan för hur vi tar detta från ett fult hack till en riktig produkt. Vi estimerar kostnader, tidsåtgång och vilka resurser som krävs.

Vad du som kund ska förvänta dig

När du gör en veckolång POC med oss måste du vara beredd på några saker. Det är inte som ett vanligt IT-projekt.

Det kommer att vara fult. Gränssnittet vinner inga designpriser. Det kanske bara är svart text på vit bakgrund.
Det kommer att gå sönder. En POC är inte byggd för att hantera tusentals användare, konstiga specialfall eller oväntad input. Om du klickar för snabbt kanske den kraschar.
Det kräver din tid. Vi behöver dig tillgänglig för snabba beslut och feedback. Vi kan inte vänta tre dagar på ett godkännande från en styrgrupp. Om vi har en fråga på onsdag morgon behöver vi ett svar på onsdag förmiddag.
Fokus på funktion, inte form. Vi lägger noll tid på logotyper och färgval. All tid går till att få AI-modellen att göra rätt sak.

Målet är inte perfektion. Målet är insikt. Vi vill veta om idén bär.

Ett konkret exempel: Avtalsgranskning

För att göra det ännu tydligare kan vi titta på ett typiskt scenario. En kund inom juridik ville använda AI för att snabbt hitta risker i standardavtal.

Måndag: Vi kom överens om att bara fokusera på hyresavtal. Vi samlade in 50 gamla avtal där juristerna redan visste var riskerna fanns.
Tisdag: Vi byggde ett skript som läste in PDF-filerna och skickade texten till en språkmodell med en specifik prompt för att hitta klausuler om uppsägningstid och dolda avgifter.
Onsdag: Vi insåg att modellen missade vissa formuleringar. Vi justerade prompten och lade till en funktion som markerade exakt var i texten risken fanns.
Torsdag: Två jurister fick testa systemet på 10 nya avtal. De hittade några fel, vi justerade igen. På eftermiddagen konstaterade de att systemet hittade 90 % av riskerna på en bråkdel av tiden.
Fredag: Vi presenterade resultatet för ledningen. Beslutet togs att bygga en fullskalig version.

På fem dagar gick de från en vag idé till ett bevisat koncept.

Från POC till produktion

Att bygga en POC på en vecka är roligt, intensivt och ger snabba kickar. Men det är bara början. Att ta den där prototypen och göra den till en stabil, säker och skalbar lösning som hela företaget kan använda är ett helt annat projekt.

När vi går från POC till produktion måste vi tänka på saker som vi medvetet ignorerade under veckan. Hur hanterar vi personuppgifter? Hur ser vi till att systemet inte går ner om OpenAI har driftstörningar? Hur bygger vi ett gränssnitt som är tillgängligt och användarvänligt? Hur övervakar vi AI-modellens prestanda över tid så att den inte börjar hallucinera när datan förändras?

Det kräver en helt annan typ av arkitektur, säkerhetstänk och förvaltning. Om du vill veta mer om den resan och vad som faktiskt krävs när smekmånaden är över kan du läsa vår guide om vad som krävs för att ta en POC till produktion.

Vi vet att varje verksamhet är unik. Det som fungerar för ett företag kanske inte alls passar ett annat. Därför börjar vi alltid med att lyssna. Berätta var ni står idag och vart ni vill, så ger vi er en ärlig bedömning av vad som är realistiskt. Starta samtalet.