AWS gjør SageMaker kompatibel med OpenAI-API-et

AWS gjør et lite API-grep med stor styringsbetydning: SageMaker AI får OpenAI-kompatible endepunkter for sanntids-inferens.

Det betyr at applikasjoner som allerede bruker OpenAI SDK, LangChain eller Strands Agents kan kalle modeller på SageMaker ved å endre endpoint-URL. Ifølge AWS trengs det ikke egen klient, SigV4-wrapper eller omskriving av applikasjonskode.

Dette er ikke en ny modellnyhet. Det er en kontrollnyhet. OpenAI-formatet er i ferd med å bli standardgrensesnittet mange utviklere bygger agent- og chatbot-løsninger rundt. Når AWS nå lar SageMaker snakke samme språk, flyttes konkurransen fra modellnavn til hvor virksomheten vil kjøre inferens, hvem som styrer tilgangene, og hvor data og logger faktisk ligger.

OpenAI-formatet blir infrastruktur

AWS skriver at SageMaker-endepunkter nå eksponerer en /openai/v1-sti som tar imot Chat Completions-forespørsler og returnerer svar fra containeren, også med streaming. OpenAI-kompatible endepunkter er slått på for alle SageMaker-endepunkter og inference components som bruker standard SageMaker-API-er og SDK-er.

For en CIO er dette viktig av én enkel grunn: store deler av AI-stacken er allerede skrevet rundt OpenAI-klienter. Mange interne verktøy, agentrammeverk, gateways og eval-løp antar at de kan sende chat-completion-kall. Hvis et selskap må skrive om dette for hver leverandør eller hvert privat modellmiljø, blir flyttbarhet i praksis et PowerPoint-ord.

AWS forsøker å fjerne den friksjonen. Samme applikasjon kan i prinsippet peke mot et SageMaker-endepunkt som kjører Llama, Mistral, Qwen eller en egen finjustert modell. Det gjør ikke migrering risikofritt. Men det senker terskelen for å teste om arbeidslaster kan flyttes fra en ekstern modell-API til egen skykonto, egen GPU-kapasitet og egne IAM-regler.

Agentene kan kjøres på eid infrastruktur

AWS løfter særlig frem agentiske arbeidsflyter. Selskapet skriver at team som bygger multi-step agents med Strands Agents eller LangChain kan kjøre disse på egne SageMaker-endepunkter, samtidig som agentene fortsatt bruker det OpenAI-kompatible grensesnittet de ble bygget for.

Det er den relevante vinkelen for norske virksomheter. Spørsmålet er ikke bare hvilken modell som svarer best. Spørsmålet er hvor agenten får lov til å kjøre når den skal lese dokumenter, slå opp i systemer, klassifisere kundehenvendelser, skrive kode eller foreslå handlinger.

Hvis inferens kjører i en ekstern modellplattform, må risikoen styres gjennom databehandleravtaler, logging, retention, modellvilkår og leverandørens sikkerhetsregime. Hvis inferens kjører i egen AWS-konto, flyttes mer av styringen til virksomhetens eksisterende skyoppsett: IAM, VPC, CloudWatch, nettverkskontroll, KMS, kostnadsstyring og intern revisjon. Det er ikke automatisk tryggere. Men det er mer styrbart hvis organisasjonen faktisk har moden sky-governance.

Tokenene er også en risiko

Lanseringen er ikke bare en utviklerforenkling. AWS innfører også tidsbegrensede bearer tokens for SageMaker-endepunktene. Tokenene kan være gyldige i opptil 12 timer og genereres fra eksisterende AWS-credentials. AWS skriver at det ikke trengs egne API-nøkler, men understreker samtidig at tokenet har samme autorisasjon som de underliggende AWS-legitimasjonene.

Det er en klassisk styringsfelle. Når et system blir kompatibelt med populære OpenAI-klienter, kan det også bli lettere å lime inn tokens i notebooks, miljøvariabler, logger eller agentkonfigurasjoner. AWS anbefaler korte levetider, minst mulig IAM-rettigheter, ingen lagring på disk og ingen logging av tokens.

For ledere betyr det at API-kompatibilitet må følges av tydelige regler for secrets management. Hvem får generere tokens? Hvilke SageMaker-endepunkter kan de nå? Kan agentene selv hente nye tokens? Blir tokenbruk logget? Finnes det sperrer mot at en utviklerrolle med for brede rettigheter blir brukt som generell AI-nøkkel?

Dette handler om leverandørmakt

AWS posisjonerer SageMaker som et sted der selskaper kan samle flere modeller bak ett grensesnitt. Et team kan for eksempel kjøre en generell Llama-modell, en finjustert Mistral-modell for domeneoppgaver og en mindre klassifiseringsmodell gjennom samme OpenAI SDK. Hver modell kan få egen ressursallokering via inference components.

Det er en praktisk produktnyhet. Men den større konsekvensen er strategisk: OpenAI-API-et er blitt en de facto standard, også hos konkurrenter. Det gir kjøpere mer forhandlingsmakt hvis de bygger arkitektur som kan flyttes. Det gir også risiko hvis virksomheten låser hele agentplattformen til ett API-mønster uten å ha kontroll på evals, kost, datakrav og observability på tvers av modeller.

Norske ledere bør lese denne typen lansering som et tegn på hvor AI-markedet går. Modellene blir mer utskiftbare på overflaten. Kontrollplanet blir viktigere. De beste AI-organisasjonene kommer ikke bare til å spørre hvilken modell som er best. De kommer til å spørre hvor modellen kjører, hvem som kan kalle den, hvordan kallene logges, hva det koster, og hvor raskt arbeidslasten kan flyttes hvis pris, sikkerhet eller regulatoriske krav endres.

Det er mindre glamorøst enn modellshow. Men det er her enterprise-AI blir drift. Og drift er der regningen, risikoen og ansvaret havner.

Kilder og medier

• Primærkilde: AWS, «Announcing OpenAI-compatible API support for Amazon SageMaker AI endpoints», publisert 20. mai 2026: https://aws.amazon.com/blogs/machine-learning/announcing-openai-compatible-api-support-for-amazon-sagemaker-ai-endpoints/
• AWS viser til eksempelnotebook på GitHub for SageMaker/OpenAI-kompatibel inferens: https://github.com/aws-samples/sagemaker-genai-hosting-examples/blob/main/03-features/openai/sagemaker-inference-openai-api.ipynb
• Thumbnail: GPT/OpenAI Image 2 / hogby.ai.