Alla större konsultföretag erbjuder sina egna färdigutvecklade arkitekturramverk, modeller eller referensarkitekturer för generativ AI och agentbaserad AI. Försäljningsargumentet är nästan identiskt från företag till företag: ”Vi har gjort det här förut, vi har sammanställt mönstren, och om ni utgår från vår ritning kommer ni snabbare i mål.” Det är en urgammal konsultteknik. Få kunden intresserad av en färdig lösning, och fakturera sedan timmarna för att anpassa den. Kunden blir, som så ofta är fallet, den som drar det kortaste strået. För att ge en tydlig bild av vad som finns på marknaden just nu är det på sin plats med en kort lista:

• McKinsey publicerar en öppen referensarkitektur för skalning av generativ AI, uppbyggd kring återanvändbara applikationsmönster såsom kunskapshantering, chattbotar för kunder och agentbaserade arbetsflöden, samt delade tjänster för retrieval-augmented generation (RAG), inbäddning, omrankning och avsiktsklassificering, sammanbundna med infrastruktur som kod och policy som kod.
• Deloitte har publicerat en AI-agentarkitektur, ett ramverk för multiagent-system och en plan för ett ”agentbaserat företag” som positionerar autonoma agenter som företagets operativa logik.
• Capgemini lanserade sitt Resonance AI Framework i juli 2025, med stöd av RAISE-galleriet med generativ AI och agentmönster, och lovar att omsätta AI-ambitioner till mätbara affärseffekter.
• Infosys erbjuder en referensarkitektur i fem lager för mogen företags-AI som en del av sin satsning på Topaz, där varje lager har sina egna roller, gränssnitt och driftsättningsmodell.
• TCS säljer AI WisdomNext, en aggregerings- och orkestreringsplattform som möjliggör modellbyte och distribuerar färdigbyggda agenter utan leverantörsberoende.
• Accenture främjar en AI-arkitektur för det intelligenta företaget, en ”AI-hjärna” som är inriktad på agentorkestrering och beslutsintelligens.

En viktig anmärkning: Varje ramverk tjänar olika syften och riktar sig till olika målgrupper. Det finns andra, och fler tillkommer varje kvartal. Jag listar dessa endast som exempel, inte för en detaljerad granskning; läs om dem och dra dina egna slutsatser. Min oro gäller inte något enskilt ramverk, utan mönstret att behandla ett enda som utgångspunkt.

Jag förstår exakt varför dessa ramverk skapades. De är verktyg för att sälja konsulttimmar. Ett färdigt ramverk ger ett säljteam något konkret att presentera för en it-chef. Det berättar en lockande historia, och, för att vara rättvis, är en del av tankegångarna i dessa dokument verkligen bra. Problemet är inte att ett färdigt ramverk är fel. Problemet är vad som händer när man använder dem.

Ett bra svar eller det bästa?

När man bygger ett AI-system skapar man ett system som utnyttjar dynamiskt beteende som en funktionell fördel för applikationen. Det beteendet beror helt och hållet på era krav. För varje givet AI-problem finns det ungefär 5 000 möjliga kombinationer av arkitektur och tekniska lösningar som fungerar. Men bara en är optimerad för just dina krav. Arkitekten och arkitekturteamet måste ta reda på vilken det är, och det enda sättet att göra det är att utgå från kraven och arbeta sig fram mot arkitekturen, inte tvärtom.

Ett färdigbyggt ramverk grumlar vattnet. Både konsulterna och kunderna fastnar i en statisk idé eller ett statiskt koncept, och försöker sedan tvinga in sin problemdomän i det. Det är bakvänt. I vartenda fall jag har sett bara under de senaste två åren slutar denna dynamik med att företag implementerar teknikmönster som helt enkelt inte behövs. Vektordatabaser där ett sökindex skulle räcka. Multiagent-orkestrering där en enda modell och bra instruktioner skulle räcka. Lager på lager av styrning och mellanprogramvara som ingen har bett om, motiverat med att ”det ingår i ramverket”.

Kostnaden för någon annans plan

Resultatet blir en enormt underoptimerad arkitektur som, enligt min direkta erfarenhet, kostar någonstans mellan 10 och 20 gånger mer att driva än vad en fullt optimerad arkitektur skulle göra. Och jag menar fullt optimerad i bemärkelsen en arkitektur där teamet började från noll, införlivade sina egna krav och arbetade sig fram till målet. Inget ramverk som distraherade dem. Ingen modell. Inga arkitektoniska konceptuella knep. De löste helt enkelt problemet.

Tänk på vad den multiplikatorn innebär i konkreta pengar. En månatlig faktura för inferens som borde vara 50 000 dollar blir istället 500 000 till 1 000 000 dollar. Inte för att tekniken är dyr, utan för att arkitekturen valdes innan kraven hade förståtts, och varje efterföljande beslut ärvde det misstaget.

Vad du istället bör göra

Fokusera på krav, processer och önskade resultat för att utforma din arkitektur. Lägg ner tid i början på att förstå vilket dynamiskt beteende applikationen faktiskt behöver, vilka data den hanterar, vilka gränser för latens och kostnad den måste hålla sig inom, och hur ett fel ser ut.

Arbeta igenom idéer och koncept på ett ärligt sätt, utan att ta hänsyn till leverantörers immateriella rättigheter. När du gör detta kommer du att lägga ungefär en fjärdedel av kostnaden på att ta dig från idé till utveckling, och det resulterande systemet kommer att kosta ungefär en tiondel så mycket att driva varje månad. Dessa siffror är inte teoretiska. De är vad jag observerar när team utför arkitekturarbetet på rätt sätt, jämfört med när de börjar med ett ramverk och fyller i resten i efterhand.

Ramverk är inte helt värdelösa. Som utbildningsmaterial, som en översikt över mönster eller som en checklista för att säkerställa att man har beaktat styrning eller övervakbarhet har de ett visst värde. Men de bör vara det sista man tittar på, inte det första, och de bör aldrig vara det man utformar arkitekturen utifrån.

Dags att slå larm

Jag ser alldeles för många av dessa uppdrag för att inte säga något nu. Det som är frustrerande är att detta är samma dynamik som utspelade sig vid molnmigreringar för ett decennium sedan, med big data innan dess, och med ERP innan dess. En färdigkonceptualisering säljs in som en genväg. Kunderna anammar den för att slippa tänka igenom saker ordentligt, men det krävs ändå att man tänker igenom saker ordentligt, denna gång med en driftskostnad som är tio gånger högre än den borde vara.

Jag önskar att konsultföretagen skulle ompröva värdet av dessa ramverk. De bra företagen anställer utmärkta arkitekter. Arkitekter, ni vet att varje optimering är en avvägning och att avvägningar bara är meningsfulla i sammanhanget av specifika krav. Istället för att sälja färdiga, statiska ritningar, arbeta tillsammans med kunderna för att utforma deras arkitektur utifrån deras problem. Ni kanske säljer färre snabbstartspaket, men ni kommer att behålla kunderna i årtionden, och era referensarkitekturer kommer att sluta vara marknadsföringsknep och istället bli det de påstår sig vara.

Marknadsföringsbruset finns överallt just nu, och någon måste höja rösten för att höras över bruset. Krav först. Arkitektur sedan. Ramverk sist, om ens alls.#ArtificialIntelligence #GenerativeAI #CloudArchitecture #CloudComputing