AI added og AI native er ikke det samme. Fra marketingsiden ser de identiske ud. Begge har en "AI" knap. Begge har en lanceringsvideo med OpenAI logoet. Begge har et slide, der hævder, at AI er i fundamentet. Begge lover at ændre, hvordan retail fungerer.
Driftsmæssigt kunne de ikke være mere forskellige.
Her er tre konkrete tests, du kan køre på enhver retailteknologileverandør på femten minutter. Leverandøren vil ikke kunne snyde med nogen af dem. Hver test er strukturel, hvilket betyder, at den ikke kan lappes med en omskrevet marketingside eller en feature release. Hvis svaret på alle tre er forkert, er AI'en added. Hvis svaret på alle tre er rigtigt, er AI'en native. Mellemvejen findes egentlig ikke.
Hvor AI'en faktisk bor (ikke bare sidder)
Den enkleste test. Åbn produktet. Find AI funktionen. Se, hvor den sidder i interfacet.
I et AI added produkt er AI'en et vindue. En chatpanel, der åbnes til højre. En knap mærket "Spørg AI", der producerer en sætning. En modal, der opsummerer rapporten, du allerede sad og kiggede på. Du skal gå til AI'en. Den kommer ikke til dig.
I et AI native produkt er AI'en operatørlaget. Den venter ikke på at blive spurgt. Den producerer output kontinuerligt, i de samme flader, brugeren allerede arbejder i. Den løfter problemet frem ved kassen, før chefen overhovedet har kigget. AI'en kommer til dig. Du kan se, hvordan det ser ud i Vera, vores retail copilot.
Forskellen er ikke æstetisk. Et chatvindue er noget, engineering teamet kan tilføje til næsten ethvert produkt på et kvartal. Et operatørlag kræver, at produktet er designet omkring AI'en fra begyndelsen. De to arkitekturer kan ikke sameksistere. Du kan ikke have begge. Den ene er added, den anden er native.
Bed leverandøren om at gennemgå deres travleste skærm, den, en butikschef faktisk bruger en lørdag. Tæl gangene, AI'en løfter noget frem uden at blive spurgt. Nul er AI added. Mere end nul er tættere på AI native.
Hvad AI'en faktisk beslutter (ikke bare beskriver)
Se på, hvad AI'en producerer. Lyt nøje til, hvad leverandøren faktisk påstår.
I et AI added produkt opsummerer AI'en. Den fortæller dig, hvad dashboardet allerede viste dig, i en sætning i stedet for et søjlediagram. Den genfortæller gårsdagen. Den er hjælpsom på den måde, en junior analytiker er hjælpsom. Den kan spare dig et klik, men den kan ikke spare dig en beslutning. En butikschef åbner systemet, læser, hvad AI'en sagde om gårsdagens salg, og skal stadig finde ud af, hvad der skal gøres ved det.
I et AI native produkt beslutter AI'en. Den ser på de samme data og fortæller dig, hvad du skal gøre nu. Den foreslår trækket, med prisen, butikken og øjeblikket. Butikschefen bekræfter eller overstyrer. Med ét tryk udfører systemet. Rapportering bliver beslutning bliver handling i samme flade. Butikschefen åbner systemet, og AI'en har allerede foreslået det næste træk.
De fleste retailteknologileverandører blander disse to sammen i et salgsopkald. De siger, "den kan svare på spørgsmål om dine data" (opsummering), og kalder det beslutningstagning. Lyt nøje. Opsummering og drift er ikke det samme produkt. Det ene forbedrer din rapportering. Det andet driver din forretning.
Bed leverandøren om et enkelt eksempel på et AI output, der endte i en udrullet handling, uden at et menneske skrev mere end én godkendelse. Hvis de ikke kan producere ét, er AI'en added.
Hvem byggede AI'en ind (og hvad sker der, når den ændres)
Det her er den sværeste test at køre, fordi svaret kræver, at man forstår virksomhedsstrukturen, ikke bare produktets features.
Spørg, hvem der har designet det nuværende produkt. Spørg, hvem der bestemmer, hvornår det ændres. Lyt til den organisatoriske struktur bag svaret.
Hvis virksomheden er hierarkisk, med produktudvalg, kvartalsvise roadmaps og tre lag mellem en kundeforespørgsel og en udrullet fix, blev virksomheden bygget til menneskelige operatører og fik AI boltet ovenpå bagefter. AI'en bliver bedre i det tempo, leverandørens releasecyklus tillader. Din forretning tilpasser sig produktet.
Hvis virksomheden er flad, med et lille team, gulvpersonale med i produktbeslutningerne og deploymentcyklusser målt i dage, blev virksomheden bygget omkring AI'en fra fundamentet. AI'en bliver bedre i det tempo, din forretning lærer den. Produktet tilpasser sig dig.
Karo blev bygget på den anden måde. Founder teamet brugte måneder på butiksgulve. Produktet ændrer sig, når gulvet siger til. Teamet er lille nok til, at du kender den person, der leverer dine fixes. Der er ingen lag mellem et kundeopkald og en udrullet release. Forskellen viser sig med det samme. En butikschef ringer lørdag, og det er løst inden lukketid. Læs mere om, hvordan vi arbejder.
Spørg leverandøren: hvor lang er loopen fra en kunde fortæller jer om et problem til en udrullet fix? Hvis svaret er mere end en uge, er virksomheden, der leverer softwaren, ikke bygget til AI tempo, uanset hvordan produktet ser ud i en demo.
Bundlinjen
Hvis svaret på alle tre tests er det rigtige svar, er systemet AI native. Hvis svaret på alle tre er forkert, er systemet AI added. Mellemvejen findes egentlig ikke.
Det betyder noget, fordi AI added og AI native kræver helt forskellige implementeringer, helt forskellige virksomhedsstrukturer og helt forskellige feedback loops. Du kan ikke eftermontere den ene i den anden. Du vælger på fundamentsniveau, og det valg forplanter sig gennem alt. Arkitekturen, organisationsstrukturen, hvordan produktet ser ud seks måneder inde, om dit lørdagsproblem bliver en mandagsfix eller en tirsdagsforespørgsel om en feature, der dør i en kvartalsplanlægningscyklus.
At forstå skellet er forudsætningen for at evaluere enhver retailteknologileverandør. Du kan stille tekniske spørgsmål, indtil du er udmattet, men hvis leverandøren er AI added på fundamentsniveau, vil ingen feature release gøre den native.
Se en dybere udforskning af den organisatoriske side af skellet.