Slack viser hvorfor AI-drift blir multi-cloud

Slack har publisert en teknisk gjennomgang av hvordan selskapet har bygget om AI-infrastrukturen sin fra relativt enkel modellservering til multi-cloud drift. Det er en ingeniørtekst, men poenget er strategisk: AI i stor skala handler ikke bare om hvilken modell som svarer best. Det handler om tilgjengelighet, leverandørrisiko, kapasitet og kontroll.

Slack skriver at selskapet tidlig sto overfor en klassisk bedriftsutfordring: store språkmodeller måtte leveres med sikkerhet, ytelse og stabilitet som passet en global arbeidsplattform. Første steg var AWS SageMaker, blant annet fordi Slack trengte kontroll, modelltilgang og sikkerhetsoppsett som kunne støtte krav som FedRAMP. Selskapet beskriver også en escrow-VPC-modell der kundedata ble holdt privat for Slack, samtidig som modellvektene hos leverandøren ikke ble eksponert for Slack.

Etter hvert ble arkitekturen mer krevende. Nye modeller, bedre versjoner og optimaliseringer kom raskere i andre tjenestelag, blant annet Amazon Bedrock. For et produkt der modellkvalitet påvirker brukeropplevelsen direkte, ble ventetid på nye modellversjoner et forretningsproblem. Slack beskriver deretter en bevegelse mot Bedrock, og senere et bredere multi-cloud oppsett der Google Cloud Vertex AI også brukes. Begrunnelsen er ikke pyntet med sky-romantikk. Den er praktisk: regional robusthet, tilgang til flere modeller, mindre sårbarhet for GPU-knapphet og raskere innovasjon.

Dette er relevant for norske ledergrupper fordi mange virksomheter er på vei inn i samme problem, bare med mindre volum. Først testes Copilot, Claude, Gemini eller interne RAG-løsninger som enkeltstående prosjekter. Så blir bruken reell. Flere avdelinger bygger arbeidsflyter på toppen. Kostnadene øker. Modellene endres. Leverandørene prioriterer forskjellige regioner og produkter. Plutselig er AI ikke lenger et eksperiment, men en del av driften. Da blir arkitekturen et styrespørsmål.

Slack peker spesielt på robusthet mot regionale hendelser og knapphet på GPU-kapasitet. Det er ikke teoretisk. De siste to årene har AI-kapasitet vært en knapp ressurs, og leverandørene har pakket de beste modellene og funksjonene inn i egne plattformer. En virksomhet som binder all AI-kritisk funksjonalitet til én modell, én skyregion eller én produktvei, kjøper enkelhet på kort sikt og opsjonskostnad på lang sikt.

Multi-cloud er likevel ikke en gratis forsikring. Det gjør arkitekturen dyrere og mer kompleks. Det krever felles policy for logging, dataklassifisering, tilgang, nøkkelhåndtering, kostnadskontroll og observability på tvers av leverandører. Det krever også en beslutning om hvilke arbeidslaster som faktisk fortjener redundans. Det meste bør ikke bygges dobbelt. Men prosesser som er tett på kundeopplevelse, sikkerhet, salg, drift eller juridiske forpliktelser må vurderes annerledes enn en intern skriveassistent.

Den viktigste lærdommen fra Slack er derfor ikke at alle skal kopiere samme skyvalg. Lærdommen er at AI-plattformen må designes for endring. Modellene byttes raskt. Prisene endres. Tilgangen flytter seg. Regulatoriske krav blir strammere. Bedriftene trenger et kontrollplan som kan rute oppgaver til riktig modell og riktig leverandør, uten at hver produktgruppe bygger sin egen snarvei.

For CIO og CISO betyr det fire konkrete spørsmål. Hvilke AI-funksjoner er virksomhetskritiske nok til å trenge failover? Hvilke data kan sendes til hvilke modellplattformer? Hvordan måles kvalitet, forsinkelse og kostnad på tvers av modeller? Og hvem eier avvik når en modellversjon endres uten at forretningsprosessen er testet på nytt?

Slack sin tekst er også et varsel om at leverandørstyring blir mer teknisk. Klassiske skykontrakter, databehandleravtaler og risikovurderinger er ikke nok hvis AI-laget endrer seg ukentlig. Virksomheter trenger løpende evalueringer, modellkatalog, budsjettgrenser og en operasjonell evne til å flytte trafikk. Det er samme disiplin som moden sky- og SRE-drift, bare med flere variable.

For styret er saken enkel å formulere: Hvis AI skal inn i kjerneprosesser, må ledelsen kunne forklare hvordan tjenesten holdes oppe når modell, region eller leverandør svikter. Det spørsmålet bør stilles før agentene får skrive kode, tolke kontrakter eller påvirke kundedialog. Slack viser at de store plattformene allerede bygger for dette. Resten av markedet bør følge etter med nøktern hastighet.

Kilder og medier

Primærkilde: Slack Engineering, "Slack AI: The Path to Multi-Cloud", publisert 28. mai 2026: https://slack.engineering/slack-ai-the-path-to-multi-cloud/ Kildekreditering: Slack Engineering / Shaurya Kethireddy. Thumbnail: OpenAI Image 2 / hogby.ai