AI og produktutviklingHafsteinn Runarsson · AI Konsulent26 Sept 2026 · 11 min

AWS Bedrock: norsk guide til modeller, RAG, agenter og sikkerhet

Amazon Bedrock er AWS-plattformen for å bygge generative AI-applikasjoner og agenter med flere grunnmodeller bak et felles tjenestelag. Den passer best når virksomheten allerede bruker AWS, trenger sentral tilgangsstyring og vil kunne evaluere flere modeller uten å drifte modellinfrastruktur selv. Valget bør likevel tas ut fra datakrav, regiontilgjengelighet, forventet trafikk og hvor mye plattformbinding teamet aksepterer.

Denne guiden viser hvordan en norsk virksomhet kan vurdere Amazon Bedrock, designe en RAG-løsning eller agent og komme frem til en produksjonsplan som kan testes.

Hva er AWS Bedrock?

Amazon Bedrock er en fulladministrert AWS-tjeneste for tilgang til grunnmodeller og bygging av generative AI-applikasjoner. AWS beskriver tjenesten som et felles lag for modeller fra flere leverandører, med API-er og tilleggsfunksjoner for blant annet modellvalg, kunnskapsbaser, sikkerhetsfiltre og agenter.

Det betyr at teamet kan bruke en ferdig modell uten å sette opp GPU-er eller drifte selve modellserveren. Bedrock erstatter ikke applikasjonen rundt modellen. Du må fortsatt bygge brukerflyt, integrasjoner, tilgangsstyring, logging, evalueringer og feilbehandling.

En typisk løsning består av:

• en webapp, intern arbeidsflate eller API som mottar forespørselen
• et applikasjonslag som validerer input og velger riktig arbeidsflyt
• Amazon Bedrock for modellkall
• egne datakilder via RAG når svaret skal bygge på virksomhetens kunnskap
• verktøy eller API-er som en agent kan bruke til å utføre avgrensede handlinger
• evaluering, logging, kostnadsgrenser og menneskelig godkjenning rundt hele flyten

Skillet er viktig: modellen genererer et forslag, mens systemet avgjør hvilke data den får se og hvilke handlinger den får utføre.

Når passer Amazon Bedrock?

Amazon Bedrock passer godt når AWS allerede er en sentral del av teknologistakken og generativ AI skal inn i en løsning med tydelige krav til tilgang, nettverk og drift. Da kan modellkall inngå i de samme arkitektur- og sikkerhetsprinsippene som resten av AWS-miljøet.

Bedrock er ofte et fornuftig valg når:

• teamet vil sammenligne flere modeller gjennom én plattform
• løsningen skal bruke IAM, privat nettverkstilkobling og AWS-logging
• RAG-data allerede ligger i eller skal kobles til AWS
• modellen skal inngå i en større applikasjon med API-er, køer og hendelser
• virksomheten trenger sentrale guardrails og sporbarhet
• bruksmønsteret krever flere prismodeller eller kapasitetstyper over tid

Bedrock er ikke automatisk riktig fordi resten av systemet ligger i AWS. En direkte modell-API kan være enklere for en smal prototype. Microsoft Foundry kan være mer naturlig når identitet, data og drift allerede er samlet i Azure. Microsofts egen oversikt beskriver blant annet felles rollebasert tilgang, nettverk, policyer, modeller og agenter i Azure.

Vurder derfor tre alternativer:

• Amazon Bedrock: passer når AWS-integrasjon, modellvalg og et samlet kontrollag veier tungt.
• Microsoft Foundry: passer når Entra ID, Azure-policyer og Azure-datatjenester er premisset for løsningen.
• Direkte modell-API: passer når teamet trenger et smalt grensesnitt, rask tilgang til leverandørens nyeste funksjoner og kan bygge styring og observability selv.

Det beste valget er det som gir lavest samlet systemrisiko, ikke nødvendigvis lavest pris per token.

Hvordan velger du modell i Amazon Bedrock?

Riktig modell velges med et fast evalueringssett, ikke med en kort demo i en lekeplass. Modellutvalget og regional tilgjengelighet endres, og AWS ber brukere kontrollere modellstøtte per region for den konkrete modellen.

Start med 30–100 realistiske oppgaver fra arbeidsflyten. Fjern eller anonymiser personopplysninger før testdata deles. Definer deretter hva et godt svar betyr.

Vurder hver kandidat på disse punktene:

• Oppgavekvalitet: løser svaret faktisk oppgaven, og følger det format og instruksjoner?
• Norsk språk: håndterer modellen fagspråk, tone og tvetydighet på norsk?
• Faktagrunnlag: bruker den hentet kontekst riktig, og sier den fra når grunnlaget mangler?
• Verktøybruk: velger den riktig funksjon og riktige argumenter i agentflyten?
• Latenstid: er svartiden akseptabel i den faktiske brukerreisen?
• Kostnad: hva blir totalen for input, output, retrieval, guardrails, evaluering og øvrige AWS-tjenester?
• Region og dataflyt: er modellen og funksjonene tilgjengelige i regionene arkitekturen krever?
• Robusthet: tåler løsningen ufullstendige data, tvetydige spørsmål og forsøk på prompt injection?

Gi kriteriene vekter før testen. En kundeserviceassistent kan vekte presisjon og trygg eskalering høyere enn kreativitet. En intern skriveassistent kan tåle mer variasjon, men fortsatt kreve at fortrolige data behandles riktig.

Velg gjerne to modeller til pilotfasen. Kjør det samme evalueringssettet ved hver modell- eller promptendring. Da kan teamet bytte modell på grunnlag av målte resultater i stedet for magefølelse.

Slik bygger du RAG med Amazon Bedrock

En god RAG-løsning begynner med innholdskvalitet og tilgangskontroll, ikke med valg av vektordatabase. RAG henter relevante utdrag fra egne kilder og sender dem som kontekst til modellen før svaret genereres.

Amazon Bedrock Knowledge Bases kan håndtere deler av retrieval-flyten. En produksjonsløsning trenger likevel bevisste valg rundt dokumentstruktur, metadata, oppdeling, oppdatering og hvilke kilder den enkelte bruker kan hente fra.

En enkel referansearkitektur ser slik ut:

1. Kilder som håndbøker, produktsider eller saksdata klargjøres og merkes med eier, språk, sensitivitet og tilgang.
2. En indekseringsjobb deler innholdet i egnede utdrag og oppdaterer søkeindeksen når kilden endres.
3. Brukerens spørsmål autentiseres og berikes med tillatte filtre.
4. Retrieval henter et lite sett relevante utdrag.
5. Applikasjonen bygger prompten med oppgave, kontekst og svarformat.
6. Modellen lager et svar med henvisning til kildene som faktisk ble hentet.
7. Systemet logger kvalitetssignaler, men unngår å legge sensitive data i fritekstfelt og unødvendige logger.

Test retrieval og generering hver for seg. Hvis riktig avsnitt aldri hentes, hjelper det lite å bytte til en større modell. Mål minst:

• om relevant kilde finnes blant de hentede resultatene
• om svaret støttes av den hentede konteksten
• om svaret avstår når kilden ikke dekker spørsmålet
• om tilgangsfiltre hindrer at brukeren får se data fra feil område
• om en innholdsoppdatering blir synlig innen avtalt tid

Den praktiske kvalitetsgevinsten ligger ofte i bedre metadata, bedre oppdeling og bedre evalueringsdata, ikke i en mer komplisert agent.

Slik bygger du en agent med Amazon Bedrock

En produksjonsagent bør få få, tydelige verktøy og minst mulig myndighet. En agent skiller seg fra en vanlig chat ved at modellen kan velge handlinger, for eksempel å slå opp en ordre, opprette et utkast eller sende en sak til godkjenning.

AWS beskriver Bedrock AgentCore som et lag for å bygge, koble til og følge opp agenter med autentisering, tilgangskontroll, tracing og evaluering. Disse funksjonene reduserer noe plattformarbeid, men de avgjør ikke hva agenten bør få lov til å gjøre.

Bruk dette mønsteret:

1. Start med én arbeidsflyt og ett tydelig resultat.
2. Beskriv hvert verktøy med stramt inputformat og eksplisitte feilmeldinger.
3. Gi verktøyet minst mulige rettigheter.
4. Skill mellom lesing, utkast og irreversible handlinger.
5. Krev menneskelig godkjenning før betaling, publisering, sletting eller utsending med vesentlig konsekvens.
6. Legg inn grenser for antall steg, kjøretid og kostnad.
7. Logg verktøyvalg, resultat og avvik på en måte som kan revideres uten å lagre mer persondata enn nødvendig.
8. Test avbrudd, timeout, doble kall og delvis feil før produksjon.

En nyttig pilot lar ofte agenten hente informasjon og lage et forslag, mens et menneske godkjenner handlingen. Mer autonomi kan legges til først når evalueringsdata viser at arbeidsflyten er stabil.

Sikkerhet og EØS: hva må vurderes?

Amazon Bedrock gir sikkerhetsmekanismer, men virksomheten beholder ansvaret for konfigurasjon, formål og dataflyt. AWS-dokumentasjonen om databeskyttelse beskriver dette som et delt ansvar og anbefaler blant annet minst mulige IAM-rettigheter, TLS, aktivitetslogging og kryptering.

For en norsk virksomhet bør sikkerhetsgjennomgangen minst dekke:

• hvilke personopplysninger og forretningshemmeligheter løsningen behandler
• behandlingsgrunnlag, databehandleravtaler og interne sletteregler
• hvilken AWS-region og eventuell kryssregional inferens som brukes
• hvor prompt, svar, logger, embeddings og kildeutdrag lagres
• hvem som har tilgang gjennom IAM, applikasjonsroller og supportprosesser
• hvordan nøkler, hemmeligheter og tjenestekontoer roteres
• hvordan prompt injection, datalekkasje og misbruk testes
• hvilke handlinger som alltid krever menneskelig godkjenning
• hvordan brukere får vite at de møter et AI-system der det er relevant
• hvordan hendelser oppdages, begrenses og følges opp

AWS opplyser også at modellleverandørene ikke har tilgang til Bedrocks modell-distribusjonskontoer, logger, kunde-prompter eller svar. Det er nyttig informasjon, men det erstatter ikke en konkret vurdering av hele løsningen rundt modellen.

Amazon Bedrock Guardrails kan filtrere bestemte innholdskategorier og sensitiv informasjon i input og modellrespons. Guardrails er ett kontrollag. Du trenger fortsatt autorisasjon i applikasjonen, validering av verktøykall, egne evalueringssett og menneskelig kontroll der konsekvensen er høy.

Behandle GDPR og bransjekrav som juridiske og organisatoriske spørsmål, ikke som en avkrysningsboks i AWS-konsollen. Få en kvalifisert person til å vurdere den faktiske dataflyten før produksjon.

Hva koster AWS Bedrock?

Kostnaden bestemmes av hele arbeidsflyten, ikke bare tokenprisen. AWS-prissiden viser at pris avhenger av modell, leverandør, modalitet og kapasitetstype. Kunnskapsbaser, guardrails, evaluering og andre komponenter kan ha egne kostnader.

Bruk denne månedlige modellen før pilot:

1. Estimer antall oppgaver, ikke bare antall brukere.
2. Mål gjennomsnittlig input og output på ekte testoppgaver.
3. Legg til retrieval, reranking, guardrails og embedding-kall.
4. Legg til lagring, logger, nettverk og øvrige AWS-tjenester.
5. Regn inn feil, retry og agentsteg.
6. Sett et tak per oppgave og per måned.
7. Kjør sensitivitetsanalyse for lav, forventet og høy trafikk.

En enkel formel er:

månedskostnad = modellkall + retrieval + guardrails + lagring + logging + øvrig infrastruktur

Ikke bruk leverandørens eksempelregnestykke som budsjett. Mål tokenbruk og antall steg i din egen pilot. En rimelig modell kan bli dyr hvis agenten løper i mange steg, mens en dyrere modell kan bli billigere totalt hvis den løser oppgaven med færre kall og mindre etterarbeid.

Kostnadskontroll bør bygges inn fra starten:

• maksimumslengde på input og output
• timeout og maks antall agentsteg
• caching der svar faktisk kan gjenbrukes
• enklere modell for klassifisering og ruting
• varsler på forbruk og avvik
• prøvetaking av logger fremfor ukritisk full logging

Fra pilot til produksjon

En god pilot beviser én arbeidsflyt med realistiske data, målbare evals og en tydelig eier. Den prøver ikke å bevise at "AI fungerer" generelt.

Bruk denne rekkefølgen:

1. Avgrens oppgaven. Beskriv hvem som gjør hva i dag, hvilke data som brukes og hva som kan gå galt.
2. Sett en baseline. Mål dagens kvalitet, tidsbruk, feil og eskaleringer uten å love en bestemt forbedring.
3. Velg arkitektur. Avgjør om behovet er et vanlig modellkall, RAG, en agent eller tradisjonell automasjon.
4. Lag evalueringssettet. Ta med normale saker, sjeldne saker, manglende data og misbruksforsøk.
5. Bygg minste komplette flyt. Inkluder autentisering, logging, feilhåndtering og menneskelig overstyring, ikke bare prompten.
6. Kjør skyggetest. La løsningen foreslå resultater uten å utføre irreversible handlinger.
7. Gå gjennom sikkerhet og dataflyt. Dokumenter region, tilgang, lagring, sletting og leverandøravhengigheter.
8. Lanser begrenset. Start med få brukere eller lavrisikosaker og følg kvalitet, kostnad og feil.
9. Definer stoppkriterier. Rull tilbake eller stans hvis kvalitet, sikkerhet eller kostnad går utenfor avtalte grenser.

Produksjon betyr at teamet kan oppdage og håndtere feil, ikke at modellen aldri tar feil.

Vanlige feil med Amazon Bedrock

De dyreste feilene oppstår ofte rundt modellen. En demo kan se god ut selv om datatilgang, evalueringsgrunnlag og feilhåndtering ikke er klare.

Unngå særlig disse mønstrene:

• å velge modell etter ett imponerende eksempel
• å sende hele dokumenter til modellen uten retrieval-strategi
• å gi en agent brede API-rettigheter for å spare utviklingstid
• å bruke guardrails som erstatning for vanlig tilgangskontroll
• å logge sensitive promptdata i fritekst
• å mangle testtilfeller for tomme, motstridende eller utdaterte kilder
• å budsjettere bare med pris per token
• å lansere uten eier for kvalitet, kostnad og hendelser
• å bygge tett mot én modell uten en plan for endringer i pris, region eller funksjoner

En enkel løsning med gode grenser slår som regel en avansert agent som ingen kan forklare eller drifte.

Er AWS Bedrock det samme som Amazon Bedrock?

Ja. Det offisielle produktnavnet er Amazon Bedrock, mens mange søker etter AWS Bedrock fordi tjenesten er en del av Amazon Web Services. Begge uttrykkene viser til den samme plattformen.

Er Amazon Bedrock en egen AI-modell?

Nei. Amazon Bedrock er en plattform som gir tilgang til grunnmodeller og funksjoner rundt dem. Selve modellen velges ut fra oppgave, region, kvalitet, pris og andre krav.

Kan Amazon Bedrock brukes til RAG?

Ja. Amazon Bedrock Knowledge Bases støtter en administrert retrieval-flyt for å hente relevant informasjon fra egne datakilder før modellen svarer. God RAG krever fortsatt ryddige kilder, metadata, tilgangsfiltre og egne tester for retrieval og svar.

Kan Amazon Bedrock brukes til AI-agenter?

Ja. Amazon Bedrock har tjenester for agenter og verktøybruk. Start med avgrensede verktøy og menneskelig godkjenning for handlinger med økonomisk, juridisk eller operasjonell konsekvens.

Bruker AWS dataene våre til å trene modellene?

Nei. AWS opplyser i sin FAQ at verken AWS eller tredjepartsleverandørene bruker input eller output fra Amazon Bedrock til å trene Amazon Nova, Amazon Titan eller tredjepartsmodeller. Virksomheten må likevel kartlegge egen lagring, logging, retention og alle andre tjenester i løsningen før den behandler sensitive data.

Er Amazon Bedrock riktig for norske virksomheter?

Det kan være riktig når AWS-tilpasning, tilgangsstyring, modellvalg og produksjonsdrift passer kravene. Norsk virksomhet må i tillegg kontrollere regiontilgjengelighet, dataflyt, personvern, språkresultater og kostnad for den konkrete løsningen.

Neste steg

Start med én arbeidsflyt, et evalueringssett og et arkitekturvalg som kan forklares på én side. Da får du et bedre beslutningsgrunnlag enn en generell chatbot-demo.

Daia bygger AI-agenter og copiloter som del av full-stack produkter, med scope, pris, timing, tilgang og overlevering avtalt for hvert oppdrag. Start en samtale hvis du vil vurdere Amazon Bedrock, RAG eller en agent for en konkret arbeidsflyt.