Koppla AI till befintliga system: så går det till

Demon tog en eftermiddag. En AI-agent läste en exempelfaktura, plockade ut leverantör, belopp och förfallodag och skrev in dem prydligt i en tabell. Alla på mötet var överens: nu gör vi det här på riktigt.

Sedan kom frågorna som ingen hade ställt under demon. Var kommer fakturorna egentligen in? Vem har behörighet till affärssystemet? Har det ett API, och ingår det i er licens? Vad händer när agenten inte kan läsa ett fält? Var hamnar datan medan modellen läser den?

Tre månader senare fungerar modellen fortfarande fint. Projektet har fastnat på den andra listan.

Modellen är den enkla delen

Dagens språkmodeller räcker till för de flesta uppgifter på ett företag. Läsa ett dokument, sortera ett mejl, skriva ett svarsutkast: allt det kan du testa i ett chattfönster på fem minuter, och oftast fungerar det.

Det som tar tid är allt runt omkring. Agenten måste hämta sin indata någonstans och lämna resultatet någon annanstans. På ett företag med 20 till 300 anställda betyder det ofta ett affärssystem som är tio år gammalt, ett dokumentsystem som ingen riktigt förstår, en gemensam inkorg, några Excelfiler som är viktigare än de borde vara och kanske en databas som en extern utvecklare byggde 2014.

Att koppla AI till befintliga system är till största delen just det arbetet. Det är oglamoröst, och det avgör om projektet blir av.

Fyra sätt att koppla in en agent

Det finns inget enda rätt sätt. Jag brukar gå igenom alternativen i den här ordningen och ta det första som fungerar pålitligt.

API. Har systemet ett dokumenterat gränssnitt, använd det. Fortnox, Visma och de flesta nyare CRM- och ärendesystem har ett, ibland bara i en dyrare licensnivå eller efter att någon har bett leverantören slå på det. Ett API ger tydliga behörigheter, strukturerad data och en logg över vad som hänt. Kontrollera tidigt att det klarar det du behöver: vissa API:er låter dig läsa nästan allt och skriva nästan inget.

Mejl som gränssnitt. Underskattat. Många processer går redan via mejl: beställningar, fakturor, frågor från leverantörer. Agenten läser från en egen inkorg och svarar därifrån, eller skickar resultatet till den som behöver det. Inget ändras i kärnsystemet, och alla vet redan hur man kollar vad som hänt. Finns inget API är det här ofta den snabbaste vägen.

Filer i en mapp. En delad mapp där dokument hamnar och agenten hämtar dem, eller där agenten lägger en CSV-fil som affärssystemet läser in under natten. Gammaldags och väldigt robust. Många äldre system har en fullt fungerande importfunktion som ingen använder eftersom det är tråkigt att fylla i filen för hand. Det bryr sig inte agenten om.

RPA, som sista utväg. Robotic process automation klickar sig igenom ett gränssnitt som en människa skulle göra. Det fungerar när inget annat gör det, till exempel med ett gammalt skrivbordsprogram utan API och utan import. Men det går sönder när en knapp flyttas, och det är svårt att se varför det misslyckades. Jag använder det bara när de andra tre är uteslutna, och planerar för underhållet från första dagen.

Ofta blir svaret en blandning. Fakturan kommer via mejl, agenten läser den och resultatet går in i affärssystemet via importmappen. Det är helt i sin ordning. Det viktiga är att varje steg syns och går att kontrollera.

EU-drift och GDPR från början

Frågan “vart tar datan vägen?” hör hemma i första samtalet, inte i det sista. Fakturor innehåller namn och bankuppgifter. Kundmejl innehåller allt folk väljer att skriva. Skickar agenten det till en modell som körs utanför EU behöver du ett skäl, en rättslig grund och ett avtal som täcker det.

Enklare är att välja EU-drift från början. De stora modellleverantörerna erbjuder det, ofta via de stora molnplattformarna med datacenter i Stockholm, Frankfurt eller Dublin. Lägg till ett personuppgiftsbiträdesavtal, en tydlig regel om vad som loggas och hur länge, och en kontroll av att agenten bara ser den data den behöver för sin uppgift.

Att reda ut det i början tar några dagar. Att reda ut det efter driftstart, när dataskyddsombudet ser upplägget för första gången, kostar betydligt mer. Mer om det i vart tar din data vägen när du använder AI.

Testa på riktiga fall före driftstart

En demo med fem rena exempeldokument säger nästan ingenting. Riktiga fakturor är sneda skanningar, tvåsidiga PDF:er med totalsumman på sida två, och så den där leverantören som skriver förfallodagen i mejltexten i stället för på fakturan.

Så innan agenten gör något på egen hand kör du den på riktiga fall. Ta några veckors faktiska inflöde, låt agenten hantera det parallellt med personen som gör jobbet i dag, och jämför. Var är de överens? Var skiljer de sig, och vem hade rätt? Vilka fall markerar agenten som osäkra, och borde den det?

Det ger dig två saker. En realistisk felfrekvens, så att du kan bestämma var agenten behöver en mänsklig kontroll. Och en uppsättning testfall som du kan köra om varje gång något ändras, oavsett om det är prompten, modellen eller leverantörens fakturamall.

Först då slår du på den. Även efter det för du logg: vad som kom in, vad agenten beslutade och vad den skrev var. När något ser konstigt ut i affärssystemet tre veckor senare vill du hitta orsaken på några minuter.

Var du börjar

Välj en process där du redan vet var indatan kommer ifrån och vart den ska. Ta tidigt reda på vilka av de fyra kopplingssätten som finns: be om API-åtkomst, kolla importfunktionerna, titta på inkorgen. Bestäm drift och personuppgiftsbiträde innan du bygger. Samla sedan riktiga fall att testa på.

Vill du ha hjälp med den första processen börjar mitt arbete med AI-automatisering precis där: systemen du har, datan du får använda och ett test på dina egna fall innan något går live.