Den förändrade molnprognosen

En mönster jag har sett förut

Jag arbetade professionellt när molnet blev en sak. Från den utgångspunkten såg jag den initiala antagandet: upphetsningen, flexibiliteten, känslan att allt skulle gå snabbare. Det ledde till en massiv antagande, där varje arbetsbelastning var en kandidat och varje leverantör hade en molnhistoria.

Antagandet var dock bara den första halvan av vad jag såg. Sedan såg jag den andra sidan av det: repatriering. Företag flyttar specifika arbetsbelastningar tillbaka, frågar om varje applikation verkligen behöver molnflexibilitet. Den andra flytten skedde av en anledning. Med ekonomiska förändringar och arbetsbelastningsmognad upphörde antagandena som gjorde molnet till det uppenbara valet för allt att gälla när organisationer började undersöka dem i skala.

Eftersom jag har levt den fulla bågen en gång, känner jag igen dess form när den börjar formas igen. Nu, när jag hjälper företag att reda ut vad AI faktiskt ska göra i deras miljöer, börjar den massiva antagande/repatrieringsmönstret att se bekant ut.

Molnkorrektionen

För att se varför likheten är viktig, hjälper det att börja med vad som faktiskt hände med molnet, på sina egna villkor. Flytten till molnet var rationell. Den avlägsnade friktion, gav organisationer flexibilitet och hastighet, och var meningsfull för arbetsbelastningar som var osäkra eller snabbt föränderliga. Den var rationell på grund av den specifika typen av arbete den var byggd för. DevOps-team gick molnet först eftersom molnet var byggt för arbete som är iterativt, variabelt eller svårt att förutsäga.

Men det de byggde för stannade inte still. Molnet förändrades inte, men arbetsbelastningarna gjorde det. När processer mognade och blev förutsägbara, fick organisationer kännedom om kostnaderna kring att få tillbaka sin egen data. Avgifter för utgående data, lagringskostnader, överföringsavgifter: utgifter som var lätta att ignorera när flexibiliteten var värd det, och svåra att ignorera när arbetsbelastningarna stabiliserades. 2024, efter år av att ta betalt för datautgång, avskaffade AWS, Azure och Google Cloud alla sådana avgifter för kunder som migrerade bort från deras plattformar, som DataCenterDynamics rapporterade.

När dessa kostnader blev synliga, slutade matematiken att fungera för en växande andel av portföljen. Ekonomiskt som hade gjort molnet till en bra strategi med några nackdelar blev ekonomiskt icke livskraftigt för en växande uppsättning AI-orienterade arbetsbelastningar. Företag skärpte sina pennor och frågade om varje applikation verkligen behövde vad molnet tillhandahöll. När de faktiskt körde siffrorna, var svaret, för många arbetsbelastningar, nej.

De ackumulerade svaren blev en korrektion som branschen felmärkte. Den korrektionen kom att kallas “molnrepatriering”, och den beskrivs felaktigt oftast. Det är faktiskt arbetsbelastningsmognad: mogna företag som lär sig att matcha varje arbetsbelastning till den infrastrukturmässiga modellen som passar den. Data stöder den selektiva läsningen snarare än den helhetsläsningen. IDC fann att cirka 80% av organisationerna förväntar sig någon form av repatriering under de kommande 12 månaderna, även om färre än 10% har repatrierat hela arbetsbelastningar, enligt rapportering i CIO.com.

Läs korrekt, slutsatsen är inte att molnet var ett misstag. Molnet förblir värdefullt, men det upphörde att vara universellt. Den mogna tillståndet är hybrid: molnet där det har tjänat sin plats, privat eller dedikerad infrastruktur överallt annars.

Samma korrektionskurva, annan teknik

Den bågen är avslutad och märkt nu. Samma form börjar synas med AI. Varje enda leverantör, varje enda konferens, varje enda försäljningssamtal just nu handlar om AI. Mättnaden är identisk med vad jag såg hända med molnet. Utgifterna under bullret är verkliga: Gartner förutspår att den globala generativa-AI-utgiften kommer att nå 644 miljarder dollar 2025, en ökning med 76,4% jämfört med föregående år.

Samma mättnad antyder den kommande korrektionen. Jag tror att en liknande korrektion är på väg, inte för att AI är dåligt, utan för att samma dynamik som producerade molnrepatriering tillämpas här också. Det kommer på grund av att organisationer trycker hårt på AI-drivna arbetsflöden utan att alltid veta, inom sina egna miljöer, hur historien slutar. Antagande-mognadsgapet är mätbart: McKinsey finner att 88% av organisationerna nu rapporterar regelbunden AI-användning i minst en funktion, men majoriteten är fortfarande i pilotfas och endast cirka 39% rapporterar företagsnivå EBIT-påverkan.

Tryck för hårt utan en strategi och uppgörelsen är inte ett kanske. Den korrektionen kommer. Den kommer alltid. Du trycker för hårt utan en strategi, och så småningom tvingar ekonomin och den operativa verkligheten en uppgörelse.

Det finns redan ett namn för den korrektiva mönstret, och det är inte mitt. AI-repatriering, handlingen att flytta specifika uppgifter ut ur sannolikhetsbaserade AI-system och tillbaka till deterministiska arbetsflöden när dessa uppgifter blir stabila och upprepningsbara, är inte ett begrepp jag har uppfunnit. Det är ett mönster jag ser utvecklas. Jag är inte ensam om att se det: Gartner förutspår att mer än 40% av agenter AI-projekt kommer att avbrytas senast 2027, med hänvisning till ökade kostnader, oklar affärsnytta och otillräckliga riskkontroller.

Vad AI-korrektionen ser ut som

För att förutse korrektionen, hjälper det att ha rena definitioner för de två typerna av arbetsflöden som är inblandade.

Ett deterministiskt arbetsflöde är regelbaserat, förutsägbart och upprepningsbart. Samma ingång och samma regler producerar samma utgång, varje gång. Det är snabbt, det är fast. Det gör exakt vad det är utformat för att göra, ingenting mer, ingenting mindre. Ett sannolikhetsbaserat arbetsflöde använder AI eller modellbaserat resonemang för att tolka sammanhang och producera ett sannolikt svar. Det är användbart när processer inbegriper tvetydighet, ostrukturerad information eller bedömningsbeslut där fasta regler bryts ned och inferenser bär lasten.

Med definitionerna fastställda, svarar tidsfrågan sig själv. Sannolikhetsbaserade arbetsflöden är ofta rätt verktyg tidigt när processer inte är fullständigt förstådda. De blir problematiska när företag fortsätter att använda dem när processer är förtydligade.

Ett konkret arbetsflöde gör den tidiga kontra sena distinktionen handgriplig. En del av det arbetsflödet behöver verkligen AI. Att identifiera rätt konto från en samtalsinspelning, till exempel, kräver inferenser som ett deterministiskt system inte kan göra. Andra delar, som att fästa en fil till en post eller publicera en avisering, är deterministiska uppgifter. En fast regel, ett direkt API-anrop, är samma utgång varje gång. Jag är skyldig till detta själv: jag bygger just nu en intern automatisering som kopplar samman samtalsinspelningar, dirigerar information till vårt CRM, tilldelar åtgärdsobjekt och skickar uppdateringar till Slack.

Frestelsen är att köra allt genom AI, och den frestelsen medför en verklig, återkommande börda. Medan det finns en frestelse att köra hela saken genom AI-medierade samtal, introducerar varje AI-samtal fördröjning och medför användnings- och infrastrukturkostnad. AI-system kräver övervakning, prompt-hantering och skyddsräcken, eftersom den underliggande modellen utvecklas konstant (och oförutsägbart) av dess ägare. Du vet aldrig när den kommer att börja fungera annorlunda; utgångar kan variera på sätt som skapar styrningsproblem i skala, snabbt.

Spelat ut tillräckligt långt, förvandlas den bördan till ren slöseri. Tänk på ett företag som använder AI för att analysera 50 000 supportbiljetter. AI identifierar de fem vanligaste lösningssökvägarna. Inledningsvis hanterar AI routningen sannolikhetsbaserat: läser varje biljett och gör en bedömning. Över tiden validerar företaget mönstren. Lösningssökvägarna är nu kända. Att omvandla dem till deterministiska arbetsflödesgrenar tar inte bort AI från processen, men det tar bort den redundanta metoden att betala AI för att återupptäcka svar som nu är kända.

Det är den sannolikhetsbaserade skatten: den tillagda kostnaden, fördröjningen och styrningsbördan av att köra AI som körning för arbete som inte längre kräver sannolikhetsbaserat resonemang.

Vad mogna driftsmodeller ser ut som

Om att köra lösta arbeten på AI är en skatt, är den mogna flytten att dela arbetet efter typ. Molnmognad producerade hybridinfrastruktur, molnet där det tjänat sin plats, dedikerad infrastruktur överallt annars. Jag förutspår att AI-mognad kommer att producera hybridåtgärder med samma logik.

Den delningen producerar en tydlig driftsregel. Sannolikhetsbaserade system är värdefulla där verklig tvetydighet finns. Människor är tvetydiga. Ostrukturerad data är tvetydig. Processer som inte är fullständigt förstådda är tvetydiga. Inferens är rätt verktyg för allt detta. Den andra delen av regeln är lika viktig: deterministiska system är där skala, kostnad, hastighet och styrning är viktiga. Det sannolikhetsbaserade lagret upptäcker och tolkar. Det deterministiska lagret kör.

På marken, två signaler berättar för dig vilken sida en given arbetsbelastning tillhör:

1. Om du hittar ditt team som förlitar sig på AI för något som har blivit stabilt, upprepningsbart och väl förstått, är det en kandidat för repatriering, eftersom du betalar en sannolikhetsbaserad skatt på deterministiskt arbete.
2. Om du hittar din deterministiska kod fylls med undantagshanterare och variationsöverväganden, är det ett tecken på att du kanske faktiskt behöver AI. Regelsamlingen försöker approximera inferens.

I praktiken ritas den gränsen som en förtroendetröskel. En specifik förtroendetröskel, att åta sig ett beslut när modellen är över 90% säker, eller misslyckas smidigt under den, är ofta där den gränsen ritas i praktiken.

Det omformulerar vad det innebär att vinna med AI. De mest framgångsrika företagen som antar AI kommer inte att vara de som använder det mest, utan de som vet när de ska använda det och när de ska komplettera det.