Experten: Frågorna du måste ställa till din AI-konsult innan avtalet skrivs under

– Alla leverantörer kan hjälpa till att bygga något, men det är färre som faktiskt kan hjälpa till att förvalta, vidareutveckla, övervaka och säkerställa att lösningen fortsätter skapa affärsvärde månader och år senare, säger Anders Åberg på Pears.

Hans budskap är att företag behöver ställa betydligt skarpare frågor innan de skriver avtal. Den första handlar om referenser. Inte i form av en snygg demo eller ett isolerat proof of concept, utan verkliga system i produktion.

– Kan de visa referenscase med liknande komplexitet? Inte en demo utan ett system i produktion, med faktiska användare och mätbara affärsresultat. Fråga specifikt om utmaningarna under vägen och hur de sedan hanterades.

För it-chefer är det också viktigt att förstå vilket team som faktiskt kommer att leverera. Ett bolag kan ha senior kompetens i organisationen, men det betyder inte automatiskt att den kompetensen finns i det team som tilldelas kunden.

– Fråga efter CV:n för de faktiska personer som ska arbeta med er. Bolagets seniorkompetens och den kompetens ni faktiskt får tillgång till är ofta inte alls samma sak, säger Anders Åberg.

Data avgör både värde och risk

En annan central fråga gäller data. I AI-projekt är det ofta just datan som avgör både värdet och risken. Därför räcker det inte med allmänna formuleringar om säkerhet eller kvalitet.

– Hur hanterar ni vår data? Lagras den hos er? Används den för modellträning? Vad händer med den om engagemanget avslutas? Otydliga svar här är en varningssignal.

Vilka är de tydligaste tecknen på att en potentiell partner saknar djupare AI-kompetens?

– Det som höjer flest varningsflaggor enligt vår erfarenhet på Pears är konsulter som oavbrutet pratar om modeller och verktyg, dessutom med en massa buzzwords, men som aldrig riktigt kommer in på kundens faktiska verksamhet.

– En partner med verkligt djup börjar enligt vårt synsätt alltid i själva affären. Vilket problem är det som ska lösas, hur mäts värdet, vem äger lösningen efteråt och det landar faktiskt i tekniken sist av allt. Saknas det perspektivet märks det snabbt. En annan varningssignal är om teamet som säljer in heller inte är samma personer som faktiskt ska leverera.

– Mitt bästa tips är att be dem berätta om ett projekt som misslyckades och framförallt vilken lärdom de då drog av detta. Den som inte kan svara på det har antingen aldrig varit i skarp drift, alternativt än värre egentligen, saknar förmåga att reflektera över sitt eget arbete.

Beroendefrågan bör komma upp på bordet tidigt. En seriös partner bör enligt Anders Åberg inte bygga in kunden i ett beroende, utan tvärtom skapa förutsättningar för självständighet över tid. Därför bör organisationen fråga hur leverantörens exitstrategi ser ut redan innan samarbetet inleds.

– Vad är er strategi för exit just för oss? En seriös partner designar för att ni ska bli självständiga. Om svaret är vagt bör ni fundera på om ni är på väg att påbörja bygget av ett beroende.

För många AI-initiativ blir mätningen en annan fallgrop. Tekniska nyckeltal kan vara viktiga, men de säger inte tillräckligt om lösningen faktiskt skapar nytta i verksamheten.

– Hur mäter ni framgång och vem definierar det? Tekniska KPI:er utan koppling till affärsmål är inte tillräckligt. Fråga hur de historiskt kopplat teknisk leverans till ren affärsnytta, säger Anders Åberg.

Måste veta vem som agerar om något går snett

När AI-lösningen väl är i produktion förändras också kraven. Då räcker det inte att projektet fungerade i utvecklingsmiljön. System kan gå sönder, användare kan bete sig annorlunda än väntat och organisationen behöver veta vem som agerar när något händer.

– Hur ser er incidenthantering ut i produktion? Alla system går sönder. Fråga om SLA, eskaleringsvägar och hur de kommunicerat dessa under incidenter hos tidigare kunder, säger han.

En avgörande fråga handlar om handlingsfrihet. Företag som investerar i AI bör inte låsa in sig i långa avtal utan tydliga möjligheter att utvärdera om samarbetet faktiskt fungerar.

– Vad händer om vi sedan inte är nöjda efter tre månader? Kontraktsstrukturen bör ge er handlingsfrihet. Långa bindningstider utan utvärderingspunkter gynnar bara leverantören, säger Anders Åberg.

Enligt Pears är det ofta efter lanseringen som AI-projekt på allvar börjar tappa fart. Tekniken kan fungera, men användningen utebli. Orsaken ligger då inte nödvändigtvis i modellen, utan i processerna runt omkring.

– Vi ser ofta organisationer som investerat betydande belopp i AI-initiativ där tekniken faktiskt fungerar men där användningen uteblir. Inte för att modellen är dålig, utan för att processerna, ägarskapet, utbildningen eller förändringsledningen helt enkelt aldrig kom på plats, säger Anders Åberg.

Vad är det som oftast går snett när projekt tappar fart efter lansering?

– Projektet firas vid lanseringen, som ett avslut fastän det allt som oftast är då som det egentliga arbetet börjar. Absolut vanligaste minan det trampas på här är att initiativ finansieras och bemannas som byggprojekt, istället för något som senare också ska förvaltas. När bygget väl är klart, försvinner såväl uppmärksamheten som budget och när projektteamet skingras är det inte längre någon som äger lösningen – precis när modellen börjar driva, när data förändras eller då användarna stöter på friktion och det verkligen hade behövts som bäst.

Måste en CIO släppa ifrån sig ägandeskapet över AI-projekten i vissa fall?

– Nej, CIO:n ska absolut inte släppa taget, men måste sluta vara ensam ägare! Bara för att AI sällan är ett rent teknikprojekt betyder det inte per automatik att IT ska kopplas bort. Tvärtom skulle jag snarare påstå, men man blandar ofta ihop två sorters ägandeskap: det tekniska, det vill säga arkitektur, säkerhet samt data governance och så själva värdeägandeskapet, alltså ansvaret för att lösningen faktiskt används och kommer skapa nytta.

– Det tekniska hör definitivt hemma hos CIO:n men värdeägandeskap måste sitta i verksamheten, hos den som äger processen eller problemet som lösningen ska förbättra. När en CIO försöker äga båda får man ofta precis det vi ser gång på gång när vi blir inkopplade: en teknik som fungerar men som ingen i verksamheten känner ägarskap för och därför aldrig heller använder. CIO:ns roll bör alltså förändras snarare än krympa. Förenklat, från att vara byggherre till istället den som möjliggör och säkrar.