【Yunqi-observation】Yunqi-konferensen är inte svaret – det är en karta över vad AI-industrin satsar på

Den här gången på Yunqi-konferensen var det största utbytet inte ytterligare några nya modeller eller nya företag att minnas – det var själva sättet att läsa mässan som hade förändrats.

Tidigare, när jag gick på teknikkonferenser, var det lätt att luta sig mot några standardslutsatser: det en stor aktör väljer att tala om representerar sannolikt framtiden; begrepp som upprepas från scenen är med stor sannolikhet branschkonsensus; och när en produkt väl fått en egen monter tycks det också innebära att den mognat tillräckligt. Efter att ha sett tillräckligt många sådana evenemang är det dock lätt att glida över i andra änden – att se konferensen som ett rent marknadsföringsevenemang, montern som reklam och presentationerna som ytförpackning.

Båda sätten att se det på är för bekväma.

En mässa har förstås en marknadsföringsdimension, men marknadsföring är i sig information. När en leverantör väljer att lägga budget, produktchefer, ingenjörsteam, säljteam och monterytor på en viss riktning avslöjar det åtminstone två saker: vad man vill att marknaden ska tro på – och vilka problem man aktivt försöker göra till produkter.

Därför ser jag nu hellre en stor teknikkonferens som ett högdensitetsprovfält för hela branschen. Den ger inga svar, men den ger dig sampel, signaler, motexempel – och en karta över “vilken framtid branschen väljer att satsa på”.

1. Dela först upp mässans “liv och rörelse” i olika evidensnivåer

Den här gången började jag medvetet bryta ner en teknisk riktning i fem nivåer:

Berättelseskikt → Produktskikt → Driftskikt → Affärsskikt → Intäktsskikt
(Narrative → Product → Production → Business → Revenue)

Överst finns Berättelseskiktet (Narrative) – det leverantörerna vill att marknaden ska tro på. Exempelvis att agenter (Agent) blir arbetslivets nya ingång, att företag behöver AI-native-arkitekturer, att kontext (Context) blir en kärntillgång, och att multi-agent-system snart tar sig an allt mer komplexa uppgifter. Sådana påståenden är viktiga – de visar vart organisationers uppmärksamhet och kapital är på väg, men de är ändå bara bedömningar och satsningar.

Nästa nivå ner är Produktskiktet (Product) – det som faktiskt finns att visa upp, anropa och leverera. På mässmontrarna syns kompletta gränssnitt, API:er, arbetsbänkar och styrplattformar, vilket visar att en viss riktning har lämnat konceptstadiet och blivit produkt. Mellan “kan demonstreras” och “körs stabilt över tid” finns dock fortfarande ett stort avstånd.

Därunder ligger Driftskiktet (Production) – produkten är på riktigt på plats i kundens processer, körs kontinuerligt och börjar möta verklighetens utmaningar: behörigheter, data, revision, återställning, kostnad och samordning mellan organisationer. Först då är det fråga om skarp drift.

Längre ner hittar vi affärsnivån (Business), och där måste man fortsätta att fråga: vad förändrades faktiskt när lösningen sattes i drift? Kortades ledtiderna? Ökade konverteringen? Sjönk personalkostnaden? Gick det att testa fler annonsvarianter? Eller gjorde det en affärsprocess som tidigare var omöjlig plötsligt genomförbar?

Längst ner, och som samtidigt är den mest konkreta nivån, ligger intäktsnivån (Revenue): är kunderna villiga att betala löpande, för vilket utfall betalar de, och under vilka villkor sker förnyelsen?

Nyttan med ramverket är att det hindrar oss från att blanda samman helt olika typer av bevis. En monter kan visa att en riktning är värd att lyftas fram, ett forum avslöjar vilken bild en leverantör vill befästa, verkliga kundreferenser stärker trovärdigheten på produktions- och affärsnivå, och det är löpande intäkter som slutgiltigt verifierar intäktsnivån.

Att ett område är hett på konferensen innebär alltså inte automatiskt att “nu är det dags att investera”.

2. Den tydligaste förändringen: allt fler lager växer fram ovanpå modellerna

Under de senaste åren har AI-samtalet nästan uteslutande handlat om själva modellerna: parameterstorlek, benchmark, inferensförmåga, pris, kontextfönster, bildkvalitet och kodningskapacitet.

På plats den här gången känner jag tydligt att tyngdpunkten håller på att flytta sig.

Modeller är fortfarande viktiga, men systemlagret ovanpå modellerna har vuxit märkbart. Datagrund, modellintegration, token-hantering, agent runtime, sandbox, kontext, minne, skills, browser use, computer use, verifiering, observabilitet, behörigheter, revision, kostnadskontroll – allt fler av dessa förmågor bryts ut och paketeras som egna produkter.

Skälet är enkelt: avståndet mellan en modell som kan besvara frågor och en modell som kan tas in i en produktionsprocess och tillförlitligt leverera arbete – det är ett helt tekniskt system i sig.

Om du tillbringar en dag på en mässa möter du fem–sex produkter med helt olika namn, men i praktiken rör de sig alla mot samma arkitektur. QwenWork visar hur agenter i isolerade miljöer anropar flera verktyg för att utföra arbete. Qoder handlar om kontext, kravspecifikation (Spec), testramverk (Harness), verifiering, minne och multi-modell-routing. Den fristående leverantören TinyFish låter agenter kliva in i riktiga webbsidor och utföra uppgifter. WonderClip bryter ner videoproduktion i manus, storyboard, källmaterial, generering, granskning, versionering och batchproduktion. Alibaba Clouds OpenSearch Agentic Search för sökningen vidare till planering (Planning), resonemang (Reasoning), minne (Memory), handling (Action) och utvärdering (Evaluation).

De förefaller höra till helt olika domäner, men den underliggande arkitekturen konvergerar:

Context → Planning → Skill → Execution → Verification → Memory → Business Outcome

Modeller blir gradvis en av de viktigaste komponenterna, medan produktvärdet i allt högre grad hamnar i systemen ovanför.

Tre. Kontext håller på att gå från “indatamaterial” till långsiktig tillgång

Qoder har en bild i en presentation som säger det rakt ut:

Model power is a commodity. Context is the asset.

Citatet är givetvis vinklat av leverantören, men det pekar på en verklig fråga: ju starkare modellerna blir och ju billigare de blir att använda, desto mer hamnar faktorn som avgör om en agent kan fungera långsiktigt på vad den faktiskt vet.

I ett moget programvaruprojekt finns arkitekturbegränsningar, historiska beslut, modulberoenden, kodstandarder, dokumenterade fallgropar och produktionshistorik. I ett företag finns organisationsrelationer, behörigheter, SOP:er, dokumentation, gruppchattar, affärsregler och kundstatus. I ett varumärke finns produktinformation, visuella riktlinjer, historiskt material, annonsdata och kanalbegränsningar.

Denna information dyker inte upp automatiskt bara för att man byter till en starkare modell.

Så Qoder bygger Repo Wiki, Memory och Knowledge Cards för kodarkiv, QwenWork lägger tonvikt på Enterprise Context, och OpenSearch fokuserar på långtidsminne, uppgiftsminne och kontextkomprimering. De försöker alla lösa samma problem: att låta agenterna slippa börja från noll med att tolka sin omgivning vid varje ny körning.

Det innebär också att de Prompt Libraries som många team tidigare gillat att bygga upp kanske inte har så högt långsiktsvärde som man föreställt sig. En Prompt fungerar mer som ett sätt att anropa en uppgift – det som faktiskt ger sammansatt effekt över tid är affärskontext, beslutshistorik, valideringsresultat, felorsaker och återanvändbara kompetenser.

Fyra. AI-produkters konkurrens rör sig från “enskild funktion” mot “komplett arbetsflöde”

WonderClip ger mig en särskilt tydlig känsla av detta.

Tittar man bara på kapabilitetslistan är mycket inte nytt: bildgenerering, videogenerering, översättning, dubbning, materialbyte, massproduktion. Varje funktion för sig kan lätt täckas av modellleverantörer, videoredigeringsprogram eller andra SaaS-tjänster.

Men produktstrukturen som visades live rör sig redan mot ett mer komplett produktionssystem:

Upload the script → Review the breakdown → Prepare the assets → Generate in bulk

Därefter följer Storyboard, Canvas, anpassade skills, delade assets, teamsamarbete och versionshantering. Produkten har åter placerat “generering” mitt i arbetsflödet.

Det ger en direkt insikt för den som utvecklar AI-applikationer.

Om produktens kärna fortfarande är “ladda upp något, låt AI bearbeta det, ladda ner resultatet” är det lätt för nästa modelluppgradering att krympa dess värde. Ett starkare spår är att ta ägarskap över hela det arbete som användaren ändå behöver utföra.

Ta e-handelsinnehåll som exempel: att byta produkt, byta bakgrund, översätta eller lägga på ny röst är var för sig ganska ytliga funktioner. Tar man ytterligare ett steg uppåt bör produktens objekt gradvis bli varumärke (Brand), enskild produkt (SKU), kampanj (Campaign), marknad (Market), kreativ strategi (Creative Strategy), materialvarianter (Variants), distributionskanaler (Distribution) och resultat (Performance). Genereringen är bara utföraren – det verkliga värdet ligger i hela den kreativa driftsprocessen (Creative Operations Workflow).

Fem. Agenten rör sig från att “svara på frågor” till att “slutföra uppgifter”

Idag när jag lyssnade på Alibaba Cloud OpenSearch:s (Alibabas molnsöktjänst) dragning om agentbaserad sökning, dök det upp en utvecklingsöversikt som säger en hel del.

Tidigare handlade söktekniken om att gå från Query (sökfråga) till Results (resultat). Generativ AI flyttade fram positionerna till Question (fråga) → Answer (svar). Agentbaserad sökning tar ytterligare ett steg och förskjuter fokus från Goal (mål) till Action (handling).

Det innebär att själva sökfunktionen håller på att omdefiniera sin roll.

En framtida Research Agent kommer sannolikt att automatiskt bryta ner en fråga, lägga upp en sökplan, anropa flera sökkällor, komplettera med ytterligare sökningar, korsverifiera resultaten, bilda mellanliggande slutsatser och därefter kalla på andra verktyg för att fortsätta exekveringen. Sök-API:er börjar alltmer likna den infrastruktur som en agent använder för att hämta extern kontext.

Det förändrar också hur vi följer SEO (sökmotoroptimering) och GEO (generative engine optimization). Tidigare låg fokus på Impressions, Clicks och Ranking. Framöver behöver vi dessutom bevaka AI Visibility, Citations, Mentions och AI Referral – och huruvida den trafiken i slutändan leder till Signup, Paid och Retention.

Sökningen har inte försvunnit – den har börjat byggas in i en större uppgiftsloop.

Sex. Företags-AI:s verkliga utmaningar flyttar in på organisationsnivå

På konferensen togs många tekniska frågor kring AI i företag upp: data, behörigheter, säkerhet, styrning (governance), modellintegration, molnarkitektur, agentplattformar.

Allt det där är viktigt. Men efter att ha hört ett par företagscase fastnade jag mer för en annan fråga:

Vem har egentligen incitament att faktiskt använda det?

Tänk er att en anställd använder AI och komprimerar ett arbete som normalt tar 8 timmar till 5 timmar. Vad händer med de 3 timmar som blir över? Om svaret bara är “ge hen mer arbete” är drivkraften att driva AI framåt sannolikt ganska svag.

Ett annat exempel: om AI-teamets KPI:er är antal lanserade agenter och anropsvolym har teamet incitament att ständigt lägga till nya funktioner; affärsverksamheten står för kostnaden att anpassa processer; IT och säkerhet står för risken vid fel; och den slutliga intäktsökningen kan inte tydligt tillskrivas någon. I en sådan organisation kan införandet gå långsamt även om tekniken finns på plats.

Företags-AI kan inte bara handla om arkitektur (Architecture) – det är incitamentsdesignen (Incentive Design) som utgör det verkliga taket.

Tekniska problem kan lösas med pengar, organisationsproblem kan man inte alltid lösa ens med pengar. Innan ett projekt drar igång bör man åtminstone reda ut: roller (Role), nyckeltal (KPI), nytta (Benefit), kostnad (Cost), risk (Risk) och beslutsrätt (Decision Right). Den som får nyttan bör också bära risken, ha beslutsrätten och stå för resultatet.

Många så kallade “AI-implementeringsproblem” visar sig i slutändan handla om organisationsdesign.

Sju. De mest vilseledande nyckeltalen är ofta de som ser mest intuitiva ut

Qoder (AI-kodassistent) hade en sida i en presentation som gjorde starkt intryck på mig:

Generation rate is a vanity metric.

De jämförde andelen AI-genererad kod i olika faser och betonade samtidigt att leveranscykeln (Delivery Cycle) inte hade kortats i samma takt. De specifika siffrorna kommer från leverantörens egna fallstudier och kan inte direkt användas som branschbenchmark (Benchmark), men logiken bakom håller.

När AI sänker kostnaden för att skriva kod (Coding) flyttas flaskhalsarna istället till krav (Requirement), kontext (Context), arkitektur (Architecture), kodgranskning (Review), test (Test), integration (Integration), driftsättning (Deployment) och acceptanstest (Validation).

Därför kan mått som kodgenereringstakt, antal tokens, antal AI-agenter, anropsvolym och mängden genererade bilder hamna som lokala effektivitetsindikatorer. Det som verkligen betyder något är helhetsresultatet: har ledtiden (Lead Time) blivit kortare? Har den manuella arbetstiden (Human Minutes) minskat? Har andelen uppgifter som godkänns vid första försöket (First-pass Acceptance Rate) ökat? Har kostnaden per godkänd uppgift (Cost per Accepted Task) sjunkit? Och har de affärsmässiga nyckeltalen faktiskt rört på sig?

För mig fungerade konferensen som en tankeställare: bli inte bländad av hur mycket “AI har gjort” – fokusera på vad hela systemet faktiskt har förändrats till följd av det.

Åtta. Konferensen erbjuder ett vad – men bedömningsrätten måste du hålla i din egen hand

Det som lättast händer på en konferens är att man låter omvärlden bestämma ens prioriteringar.

Ett ämne som lyfts fram ofta från scenen får en att känna att man borde utforska det. En stor aktör som satsar stort får en att känna att man måste hänga på. En produkt som verkar avancerad får en att tro att man själv också borde bygga något motsvarande.

Den här gången vill jag hellre återföra allt detta till en enklare fråga:

Vilket av mina beslut förändrar den här informationen egentligen?

Om den bara får mig att tänka “det var intressant”, då är det input.

Om den däremot får mig att ompröva Build, Buy eller Ignore, att flytta produktens gränser, att stoppa ett projekt med lågt värde, att rita om ett arbetsflöde, eller att omdefiniera ett experimentmått – då har den faktiskt landat i beslutet.

Apsara Conference (Alibabas årliga molnkonferens) är inte svaret.

Det är snarare en karta över branschens satsningar. Kartan visar vart andra rör sig, vilka vägar som börjar bli trånga, vilken infrastruktur som håller på att ta form, och vilka problem som börjar produktifieras i stor skala.

Vilken väg man till slut väljer måste ändå utgå från det egna företagets mål, begränsningar, resurser och evidens.

Det är också det jag helst vill ta med mig från teknikkonferenser numera: att få se fler satsningar, och samtidigt behålla rätten att själv göra bedömningen.

Om du håller på att utvärdera var enterprise AI ska ta sin start, vilka riktningar som är värda att satsa på, och vilka som bara är bubblor uppblåsta av narrativ – hör av dig så pratar vi. Vi erbjuder specialiserad rådgivning inom AI-transformation: från teknikval och organisationsdesign till mätsystem. Vi hjälper dig att omsätta konferensernas brus i en egen, grundad bedömning. Mejladress: [email protected].

Vidareläsning: Sju steg till AI-transformation – en systematisk genomgång av hela vägen från idé till faktisk AI-nytta i verksamheten.

Om serien

「云栖观察」 är IAIUSE:s branschnära fältserie. Med utgångspunkt i Apsara Conference 2026 (云栖大会, Alibabas årliga molnkonferens) bryter vi – med forskarens blick – ner de verkliga förändringar som pågår i AI-industrin: vi jagar inte heta nyheter, vi tittar på var satsningarna görs och hur starka bevisen faktiskt är.

Serien täcker systemlagret ovanför modellerna, Agent-implementering, Context-tillgångar, AI-organisationsdesign i stora företag och migrationen av konkurrensenheter i AI-produkter – sammanlagt omkring tio delar.

Jag har nära åtta års erfarenhet av konsultverksamhet och affärsanalys i storföretag, bland annat på IBM, med projekt inom telekom, bank, försäkring och tillverkning. Därefter har jag fortsatt operativt inom operatörsprodukter, internetprodukter och AI-applikationsutveckling – med behovsanalys, produktdesign och leverans över teamgränser. Bedömningarna i denna serie vilar på mina egna fältobservationer och korsverifiering mot branschen. De bär en tydlig författarposition och representerar inte någon enskild leverantörs syn.