Hvorfor AI-initiativer stopper opp på arkitektur, ikke modeller

De fleste organisasjoner som startet et AI-initiativ de siste to årene, har en fungerende demo et sted. Langt færre har en agent eller en assistent som kjører hver dag inne i en reell prosess, med en eier, et budsjett og et tall som forteller ledelsen om den er verdt å beholde. Gapet mellom de to handler sjelden om modellen.

Modellen svarer på spørsmålet den får. Arkitekturen avgjør om den i det hele tatt kan stilles det riktige spørsmålet.

Hvor tiden faktisk går

Når vi ser på et initiativ som har stoppet opp, går de samme tre tingene igjen i nesten hvert eneste tilfelle.

• Dataene agenten trenger, ligger ikke der agenten kan nå dem. De ligger i et fagsystem uten et brukbart grensesnitt, i en delt postkasse eller i et regneark som én person vedlikeholder. Demoen fungerte fordi noen limte inn dataene for hånd.
• Ingen eier integrasjonen. Å koble agenten til systemene den skal lese fra og skrive til, behandles som en detalj som kan tas senere. Det er som regel mesteparten av arbeidet, og det er den delen som krever samme omhu som enhver annen integrasjon: identitet, feilhåndtering, versjonering og overvåking.
• Styringen kommer i etterkant. Spørsmålene en sikkerhetsgjennomgang eller en revisor vil stille (hva har denne agenten tilgang til, hvem godkjente den, hva er endret siden), besvares ved rekonstruksjon i stedet for ved design. Det er tregt, og det gjør hver ny agent vanskeligere å godkjenne enn den forrige.

Hva som bør fikses først

Rekkefølgen betyr noe, fordi hvert steg gjør det neste billigere.

Start med prosessen, ikke teknologien. Velg én prosess som betyr noe, pek på personen som eier den, og skriv ned hva bedre ville sett ut som, på en måte som kan måles etter at løsningen er satt i drift. Hvis den setningen ikke lar seg skrive, er initiativet ikke klart for en agent ennå.

Gjør deretter dataene tilgjengelige på en styrt måte. Det betyr som regel en liten mengde integrasjons- og dataarbeid som ikke har noe med AI å gjøre: et grensesnitt mot kildesystemet, en tydelig regel om hvilke data som får forlate det, og en identitet agenten kjører under. Dette er arkitekturarbeidet, og det kan gjenbrukes: den andre agenten på samme fundament tar en brøkdel av tiden.

Først da velger og justerer dere modellen. På dette tidspunktet er valget langt mindre avgjørende enn det så ut i starten, fordi agenten er forankret i data den har lov til å bruke og begrenset til handlinger den har lov til å utføre. Å bytte modell senere blir en konfigurasjonsendring i stedet for et prosjekt.

Styringsgevinsten

Team som bygger i denne rekkefølgen, får noe de ikke planla for: å godkjenne den neste agenten blir rutine. Oversikten, tilgangsreglene og eierskapet finnes fordi de var en del av designet, så gjennomgangen blir en kontroll i stedet for en etterforskning. Det er det som lar en organisasjon gå fra én agent til tjue uten at den tjueførste blir en risiko ingen kan beskrive.

Det er mindre spennende enn en ny modell. Det er også forskjellen mellom et initiativ som stopper opp og ett som skalerer.