Så väljer ni AI-konsult: 10 frågor att ställa

Vi är själva AI-konsulter, så läs det här med den vetskapen. Vi har ändå skrivit den, av två skäl: en köpare som ställer de här frågorna får ett bättre projekt oavsett vem som vinner det, och frågorna nedan är de vi själva helst får.

1. Vem skriver koden?

Varför det spelar roll: i den här branschen är avståndet mellan den som säljer och den som bygger ofta stort. Ni får en säljare på första mötet, en lösningsarkitekt på andra, och i vecka tre en konsult som aldrig hört era förutsättningar och som läser samma kravdokument som ni skrev för en månad sedan. Varje överlämning kostar precision.

Ett bra svar: namn på personerna, vad de gör, och att minst en av dem sitter med redan i första samtalet. Ett dåligt svar handlar om team, kapacitet och resurser utan att någon nämns vid namn.

2. Vem driftar lösningen efter leverans?

Varför det spelar roll: ett AI-system är inte klart när det levereras. Modeller uppdateras, API:er ändras, leverantörer byter versioner och verkligheten runt systemet rör på sig. Någon måste märka när det slutat fungera, och den som byggde det märker det snabbast.

Ett bra svar beskriver konkret vad drift innebär: övervakning, vad som händer vid fel, svarstider och vad det kostar per månad. Ett dåligt svar är att ni får koden och sedan är det ert. Det kan vara helt rätt om ni har egen utvecklingsavdelning, och är ett dolt problem om ni inte har det.

3. Får vi fast pris?

Varför det spelar roll: löpande räkning flyttar hela risken till er. Med en väl avgränsad uppgift ska leverantören kunna sätta ett pris, och att kunna göra det är i sig ett bevis på att de förstått problemet.

Ett bra svar: fast pris för ett avgränsat arbete, med tydligt angivet vad som ingår och vad som skulle vara ett tillägg. Ett rimligt svar är också att en förstudie eller kartläggning görs till fast pris först, och att bygget prissätts när omfattningen är känd. Ett dåligt svar är ett fast pris på något ingen ännu har definierat, för det betyder att någon kommer att bråka i vecka fem, antingen om pengar eller om vad som lovades.

4. Vem äger koden och lösningen?

Varför det spelar roll: om ni inte äger det ni betalat för är ni bundna till leverantören för all framtid. Det är den vanligaste formen av inlåsning i branschen, och den syns sällan i offerten.

Ett bra svar: ni äger koden, den ligger i ert repository, den körs på era konton hos molnleverantören och era API-nycklar är era. Fråga specifikt var koden lagras och vem som står på molnkontot. Ett dåligt svar är att lösningen körs på leverantörens plattform utan att ni kan flytta den, eller att en licensavgift tillkommer för att fortsätta använda något ni redan betalat för att bygga.

5. Referenser, eller transparens?

Varför det spelar roll: alla vill se referenser, och referenser är samtidigt det lättaste att göra vaga. Kundnamn utan siffror säger ingenting, och siffror utan kundnamn ännu mindre. Nittio procent snabbare handläggning kan betyda vad som helst när ingen får veta vad som mättes.

Ett bra svar: antingen ett case med kundens godkännande där ni får ringa kunden, eller en ärlig genomgång av ett projekt utan namn där de berättar vad som gick fel och hur de löste det. Det andra är faktiskt mer användbart än det första. Ett dåligt svar är en logotypvägg och ett antal projekt som ingen kan verifiera.

Vi publicerar själva inga kundnamn eller siffror utan kundens uttryckliga godkännande, vilket i skrivande stund betyder att vår kundcasesida är kortare än vi skulle önska. Ni får i stället bedöma oss på hur vi resonerar och vad vi tar betalt.

6. Hur hanterar ni säkerhet och personuppgifter?

Varför det spelar roll: det är ni som är personuppgiftsansvariga, oavsett vem som byggt systemet. Ett svar som stannar vid att leverantören är GDPR-kompatibel betyder ingenting, eftersom kompatibilitet inte är en egenskap hos en produkt utan hos en behandling.

Ett bra svar går igenom vilka uppgifter som passerar systemet, var de behandlas, vilka underleverantörer som finns i kedjan, hur länge loggar sparas och hur gallringen sker. Ett riktigt bra svar innehåller frågan tillbaka: vilka uppgifter finns egentligen i det här flödet? Bakgrunden går vi igenom i AI och GDPR.

7. Vad händer om effekten uteblir?

Varför det spelar roll: det är den obekväma frågan, och reaktionen säger mer än svaret. Alla projekt lovar nytta. Få har talat om i förväg hur man skulle se att den inte kom.

Ett bra svar innehåller två delar: hur ni mäter, bestämt innan bygget börjar och i era egna siffror, och vad som händer om målet inte nås, exempelvis en period av justering som ingår eller ett beslutstillfälle där ni kan avbryta. Ett dåligt svar är att effekten kommer att synas, eller ett resonemang om att förändringsarbete tar tid. Det senare är sant och samtidigt en utmärkt förklaring till varför ingenting hände.

Fråga också rakt ut: har ni sagt nej till ett projekt någon gång, och varför? En leverantör som aldrig avrått en kund från något har antingen haft osannolik tur eller inte lyssnat.

8. Hur snabbt är något i drift?

Varför det spelar roll: långa projekt utan mellanleveranser är den vanligaste orsaken till att AI-satsningar rinner ut i sanden. Efter nio månader har sponsorn bytt roll, förutsättningarna ändrats och ingen minns längre varför projektet startade.

Ett bra svar: något avgränsat i drift på veckor, inte kvartal, och en tydlig beskrivning av vad som är minsta möjliga första leverans. Ett dåligt svar är en projektplan i faser där det första som når riktiga användare ligger i fas tre. Fråga också vad ni själva behöver bidra med och när, för det är oftast där tiden faktiskt går.

9. Vilka modeller använder ni, och varför?

Varför det spelar roll: svaret avslöjar om leverantören är teknikstyrd eller problemstyrd. Ett företag som bara har en modell för alla uppgifter har antingen ett djupt partnerskap eller en tunn verktygslåda, och ni bör veta vilket.

Ett bra svar kopplar modellvalet till uppgiften och till era krav: en stark modell där omdöme krävs, en billigare där volymen är hög och uppgiften enkel, och en europeisk eller lokal körning om uppgifterna kräver det. Det bör också framgå att lösningen går att byta modell i, eftersom rangordningen mellan leverantörerna ändras ungefär varje halvår. Ett dåligt svar är namnet på en modell utan motivering, eller påståendet att modellvalet inte spelar någon roll.

10. Vad kostar det löpande?

Varför det spelar roll: bygget är en engångskostnad, driften är för alltid. Vi ser regelbundet kalkyler där byggpriset jämförts med årsbesparingen och den löpande kostnaden glömts bort helt.

Ett bra svar delar upp det i tre poster: modellanrop och infrastruktur, som beror på volym, förvaltning och övervakning, som är en månadskostnad, och vidareutveckling, som är arbete ni beställer när ni vill. Ett bra svar innehåller också en uppskattning av modellkostnaden vid er faktiska volym, inte bara en formel. Ett dåligt svar är att driften är försumbar, för det är den ibland och ibland inte, och skillnaden ligger i hur systemet är byggt.

Signaler att ta på allvar

Utöver svaren finns det ett par saker som är värda att lägga märke till under processen.

• Den som säljer avråder aldrig från något. En leverantör som tycker att allt ni föreslår är en utmärkt idé kommer att bygga allt ni föreslår, inklusive det ni inte borde ha byggt.
• Alla svar handlar om teknik. Om ingen frågar hur arbetet går till idag och vem som utför det kommer lösningen att passa ett flöde som inte finns.
• Ordet skräddarsytt utan innehåll. Fråga vad som är standard och vad som byggs specifikt för er, och varför just den gränsen.
• Ingen frågar efter era data. Datakvalitet sätter taket för allt som byggs, och en leverantör som inte vill se underlaget tidigt kommer att upptäcka problemet när ni redan betalat.
• Offerten saknar avgränsning. Det som inte ingår är minst lika viktigt som det som ingår, och det är billigare att bråka om det nu.

Och en sista sak som gäller oss lika mycket som alla andra: en liten leverantör är två personer och har en gräns. Ska ni driva ett program över flera avdelningar med parallella spår i ett år är det inte oss ni ska anlita, och det säger vi hellre på första mötet än i vecka tolv.