Thought leaders

De Veranderende Cloudprognose

mm

Een Patroon Dat Ik Eerder Hebben Gezien

Ik werkte professioneel toen de cloud een ding werd. Vanuit dat perspectief zag ik de eerste adoptie: de opwinding, de flexibiliteit, het gevoel dat alles sneller zou gaan. Dit leidde tot een massale adoptie, waarbij elke workload een kandidaat was en elke leverancier een cloudverhaal had.

Adoptie was echter alleen de eerste helft van wat ik zag. Toen zag ik de andere kant ervan: repatriatie. Bedrijven verplaatsten specifieke workloads terug, vroegen zich af of elke applicatie echt cloudflexibiliteit nodig had. Die tweede verplaatsing gebeurde om een reden. Met economische verschuivingen en workloadmaturiteit, hielden de veronderstellingen die cloud de voor de hand liggende keuze maakten voor letterlijk alles, op te gelden zodra organisaties ze op grote schaal gingen onderzoeken.

Door de volledige boog een keer te hebben meegemaakt, herken ik de vorm wanneer deze weer begint te verschijnen. Nu, terwijl ik bedrijven help om uit te zoeken wat AI eigenlijk in hun omgeving zou moeten doen, begint het patroon van massale adoptie/repatriatie weer vertrouwd te lijken.

De Cloudcorrectie

Om te zien waarom de gelijkenis ertoe doet, helpt het om te beginnen met wat er eigenlijk met cloud is gebeurd, op zijn eigen voorwaarden. De overstap naar cloud was rationeel. Het verwijderde wrijving, gaf organisaties flexibiliteit en snelheid, en had zin voor workloads die onzeker of snel veranderend waren. Het was rationeel vanwege het specifieke soort werk waarvoor het was gebouwd. DevOps-teams gingen cloud-first omdat cloud was gebouwd voor werk dat iteratief, variabel of moeilijk te voorspellen was.

Maar het ding waarvoor ze bouwden, bleef niet stil. De cloud veranderde niet, maar de workloads deden dat wel. Toen processen volwassen werden en voorspelbaar werden, kregen organisaties de kosten rond het terugkrijgen van hun eigen gegevens beter in beeld. Egress-kosten, opslagkosten, overdrachtskosten: uitgaven die gemakkelijk te negeren waren toen de flexibiliteit het waard was, en moeilijk te negeren toen de workloads gestabiliseerd waren. In 2024, na jarenlang het in rekening brengen van data-egresskosten, schrapten AWS, Azure en Google Cloud allemaal die kosten voor klanten die van hun platforms migreerden, zoals DataCenterDynamics rapporteerde.

Toen die kosten zichtbaar werden, hielden de cijfers op te werken voor een groeiend deel van het portfolio. De economie die cloud een goede strategie had gemaakt met enige downside, werd economisch niet haalbaar voor een groeiend aantal AI-georiënteerde workloads. Bedrijven scherpten hun potloden en vroegen zich af of elke applicatie echt cloudflexibiliteit nodig had. Toen ze de cijfers daadwerkelijk uitvoerden, was het antwoord voor veel workloads nee.

Die opgeaccumuleerde antwoorden werden een correctie die de industrie verkeerd etiketteerde. Die correctie kreeg de naam “cloudrepatriatie” en wordt meestal verkeerd beschreven. Het is eigenlijk workloadmaturiteit: volwassen bedrijven leren elke workload te koppelen aan het infrastructuurmodel dat het past. De gegevens ondersteunen de selectieve lezing in plaats van de algehele lezing. IDC vond dat ongeveer 80% van de organisaties enige repatriatie in de komende 12 maanden verwacht, terwijl minder dan 10% hele workloads hebben teruggemigreerd, volgens een rapport in CIO.com.

Goed gelezen, is de conclusie niet dat cloud een fout was. Cloud blijft waardevol, maar het is opgehouden universeel te zijn. De volwassen staat is hybride: cloud waar het zijn plaats heeft verdiend, private of toegewijde infrastructuur overal elders.

Hetzelfde Correctiecurve, Andere Technologie

Die boog is nu afgerond en gelabeld. Dezelfde vorm begint zichtbaar te worden met AI. Elk enkel bedrijf, elke enkele conferentie, elke enkele verkoopgesprek gaat nu over AI. De verzadiging is identiek aan wat ik met cloud heb gezien. De uitgaven onder de ruis zijn echt: Gartner voorspelt wereldwijd generatief-AI-uitgaven van $644 miljard in 2025, een stijging van 76,4% ten opzichte van het voorgaande jaar.

Dezelfde verzadiging impliceert de komende correctie. Ik geloof dat een soortgelijke correctie komt, niet omdat AI slecht is, maar omdat dezelfde dynamiek die cloudrepatriatie produceerde, hier ook van toepassing is. Het komt omdat organisaties hard duwen in AI-gedreven workflows zonder altijd te weten, binnen hun eigen omgeving, hoe het verhaal eindigt. De adoptie-versus-maturiteitkloof is meetbaar: McKinsey vindt dat 88% van de organisaties nu regelmatig AI-gebruik in tenminste één functie rapporteert, maar de meerderheid nog steeds aan het testen is en slechts ongeveer 39% rapporteert over enterprise-niveau EBIT-impact.

Hard duwen zonder strategie en de afrekening is niet een misschien. Die correctie komt. Het komt altijd. U duwt te hard zonder strategie, en uiteindelijk dwingen de economie en de operationele realiteit een afrekening af.

Er is al een naam voor het correctiepatroon, en het is niet van mij. AI-repatriatie, het verplaatsen van specifieke taken uit probabilistische AI-systemen en terug naar deterministische workflows zodra die taken stabiel en herhaalbaar worden, is geen concept dat ik heb uitgevonden. Het is een patroon dat ik zie ontvouwen. Ik ben niet de enige die ernaar kijkt: Gartner voorspelt dat meer dan 40% van de agente AI-projecten tegen het einde van 2027 zal worden geannuleerd, met een verwijzing naar stijgende kosten, onduidelijke bedrijfswaarde en onvoldoende risicobeheersing.

Hoe De AI-correctie Eruitziet

Om de correctie te anticiperen, helpt het om schone definities te hebben voor de twee soorten workflows die betrokken zijn.

Een deterministische workflow is gebaseerd op regels, voorspelbaar en herhaalbaar. Dezelfde invoer en dezelfde regels produceren dezelfde uitvoer, elke keer. Het is snel, het is vast. Het doet exact wat het is ontworpen om te doen, niets meer, niets minder. Een probabilistische workflow gebruikt AI of modelgebaseerde redenering om context te interpreteren en een waarschijnlijke antwoord te produceren. Het is nuttig wanneer processen ambiguïteit, ongestructureerde informatie of oordeelsvellingen bevatten waarbij vaste regels falen en inferenties de lading dragen.

Met de definities vastgesteld, antwoordt de timingvraag zichzelf. Probabilistische workflows zijn vaak het juiste instrument in het begin wanneer processen nog niet volledig begrepen worden. Ze worden problematisch wanneer bedrijven ze blijven gebruiken wanneer processen zijn opgehelderd.

Een concreet workflow maakt die vroeg-te-late onderscheid tastbaar. Een deel van die workflow vereist echt AI. Het identificeren van het juiste account van een oproeptranscript, bijvoorbeeld, vereist inferenties die een deterministisch systeem niet kan doen. Andere delen, zoals het toevoegen van een bestand aan een record of het plaatsen van een melding, zijn deterministische taken. Een vaste regel, een directe API-aanroep, is elke keer hetzelfde resultaat. Ik ben zelf schuldig aan dit: ik bouw momenteel een interne automatisering die oproeptranscripten aan elkaar rijgt, informatie naar onze CRM routeert, actiepunten toewijst en updates naar Slack pusht.

De verleiding is om alles door AI te laten lopen, en die verleiding draagt een echte, terugkerende last. Terwijl er een verleiding is om alles door AI-gemedieerde oproepen te laten lopen, introduceert elke AI-oproep vertraging en draagt het gebruikskosten en infrastructuurkosten. AI-systemen vereisen monitoring, promptbeheer en beveiligingsmaatregelen, omdat het onderliggende model constant (en onvoorspelbaar) wordt ontwikkeld door de eigenaar. U weet nooit wanneer het anders gaat presteren; uitvoer kan variëren op manieren die governanceproblemen op grote schaal creëren, snel.

Als dit ver genoeg wordt doorgevoerd, verandert die last in pure verspilling. Denk aan een bedrijf dat AI gebruikt om 50.000 ondersteuningsTickets te analyseren. De AI identificeert de vijf meest voorkomende oplossingspaden. Aanvankelijk behandelt AI de routering probabilistisch: elke ticket lezen en een oordeel vellen. Na verloop van tijd valideert het bedrijf die patronen. De oplossingspaden zijn nu bekend. Het omzetten ervan in deterministische workflowtakken verwijdert AI niet uit het proces, maar verwijdert de overtollige praktijk van het betalen van AI om antwoorden te herontdekken die nu bekend zijn.

Dat is de probabilistische belasting: de extra kosten, vertraging en governance-last van het uitvoeren van AI als de runtime voor werk dat niet langer probabilistische redenering vereist.

Hoe Volwassen Operationele Modellen Eruitzien

Als het uitvoeren van opgelost werk op AI een belasting is, is de volwassen zet het splitsen van werk naar type. Cloudmaturiteit produceerde hybride infrastructuur, cloud waar het zijn plaats had verdiend, toegewijde infrastructuur overal elders. Ik voorspel dat AI-maturiteit hybride operaties zal produceren met dezelfde logica.

Die splitsing produceert een duidelijke operationele regel. Probabilistische systemen zijn waardevol waar echte ambiguïteit bestaat. Mensen zijn ambigu. Ongestructureerde gegevens zijn ambigu. Processen die nog niet volledig begrepen worden, zijn ambigu. Inferentie is het juiste instrument voor al deze dingen. De andere helft van de regel is net zo belangrijk: deterministische systemen zijn waar schaal, kosten, snelheid en governance ertoe doen. De probabilistische laag ontdekt en interpreteert. De deterministische laag voert uit.

Op de grond vertellen twee signalen u welke kant een bepaalde workload op moet:

  1. Als u vindt dat uw team afhankelijk is van AI voor iets dat stabiel, herhaalbaar en goed begrepen is, is dat een kandidaat voor repatriatie, omdat u een probabilistische belasting betaalt voor deterministisch werk.
  2. Als u vindt dat uw deterministische code vol zit met uitzonderingsbehandelaars en variabiliteitsoverwegingen, is dat een teken dat u mogelijk echt AI nodig heeft. De regelset probeert inferentie te benaderen.

In de praktijk wordt die grens getrokken als een vertrouwensdrempel. Een specifieke vertrouwensdrempel, toewijding aan een beslissing wanneer het model boven de 90% zeker is, of mislukken wanneer het onder die drempel zit, is vaak waar die grens in de praktijk wordt getrokken.

Welke het kader herschikt van wat winnen met AI eigenlijk vereist. De meest succesvolle bedrijven die AI adopteren, zullen niet die zijn die het meest gebruiken, maar die weten wanneer ze het moeten gebruiken en wanneer ze het moeten aanvullen.

Jon Howe is een dynamische en boeiende technische leider met meer dan 20 jaar ervaring in het helpen van organisaties bij het moderniseren van infrastructuur door automatisering, orkestratie en cloud-first-strategieën.

Als Principal Solutions Architect bij Myriad360, werkt hij nauw samen met ondernemingen om operaties te stroomlijnen, wrijving te verminderen en DevOps-gedreven leveringsmodellen mogelijk te maken.Bezoek Jon op LinkedIn.