Du klikkede, fordi podcasten sagde, at Azure AI Foundry er en fælde, ikke? Godt – du er kommet til det rette sted. Her er løftet på forhånd: Copilots bryder sammen uden forankring (grounding), men værktøjer som Retriever-Augmented Generation (RAG) med Azure AI Search – hybrid og semantisk – plus evaluatorer for forankring, relevans og koherens er de faktiske rettelser, der forhindrer dig i at levere hallucinationer forklædt som svar. Vi springer markedsføringspræsentationerne over og viser dig overlevelseshåndbogen med reelle eksempler fra feltet. Abonnér på M365.Show nyhedsbrevet og følg livestreams med MVP-eksperter – det er dér, arrene og løsningerne findes. Og da de første revner normalt viser sig i multimodale apps, lad os starte dér. 2. Hvorfor multimodale apps fejler i den virkelige verden Når du ser en multimodal demo på scenen, ser den fejlfri ud. Præsentationsværten smider en tekstanmodning, et rent billede, måske endda et hurtigt stemmeinput, og modellen leverer et perfekt diagram eller et skarpt kontraktoversigt. Det hele føles som magi. Men i det øjeblik, du prøver det samme i en rigtig virksomhed, slides glansen hurtigt af. Demoer kører på uberørte input. Arbejdspladser kører på skrammel. Det er den reelle opdeling: i produktion giver ingen din model omhyggeligt iscenesatte skærmbilleder eller CSV-filer formateret af et standardiseringsudvalg. HR fodrer den med tværede offentlige ID’er. Indkøb trækker PDF-filer, der er i deres femte fax-generation. En i økonomi tager et billede af en faktura med et knækket Android-kamera. Multimodale modeller kan håndtere tekst, billeder, stemme og video – men de har brug for velindekserede data og hentning for at præstere under rodede forhold. Ellers beder du bare modellen om at improvisere på affald. Og ingen mængde GPU-forbrug retter op på “skrald ind, skrald ud.” Det er her, Retrieval-Augmented Generation (RAG) formodes at redde dig. Kort sagt: Modellen kender ikke din forretning, så du forbinder den til en videnskilde. Den henter et stykke data og former svaret omkring det. Når match’et er skarpt, får du nyttige, forankrede svar. Når det er sjusket, fritstiler modellen og spytter selvsikkert nonsens ud. Det er sådan, du ender med en chatbot, der sværger, at din virksomhed har en ny “Q3-rabatpolitik”, der ikke eksisterer. Den blev ikke bevidst – den trak bare de forkerte data. Azure AI Studio og Azure AI Foundry er begge baseret på dette mønster og understøtter alle former for modaliteter. Men hagen er, at RAG kun er så godt som dets data. Her er det centrale punkt, de fleste teams overser: Du kan ikke bare tilslutte én hentningsmetode og kalde det godt. Hvis du vil have resultater, der holder sammen, har du brug for hybrid søgeords- plus vektor-søgning, toppet med en semantisk genrangering (re-ranker). Det er indbygget i Azure AI Search. Det lader systemet balancere bogstavelige søgeordstræf med semantisk betydning og derefter omarrangere resultaterne, så den rigtige kontekst sidder øverst. Når du kæder det ind i din multimodale opsætning, kan modellen pludselig overleve skæve scanninger og uklare billeder i stedet for at hallucinere din compliance-politik ud af den blå luft. Lad os nu tale om, hvorfor så mange udrulninger falder til jorden. Virksomheder forventer polerede resultater på dag ét, men de budgetterer ikke med evalueringssløjfer. Uden kontrol af forankring, relevans og koherens, der kører i baggrunden, bemærker du ikke afvigelser, før brugerne allerede er brændt. Mange tidlige implementeringer fejler hurtigt netop af denne grund – outputtet lyder korrekt, men ingen har verificeret det mod kildens sandhed. Det behøver ikke at ende i fiasko. Carvana er en af Foundry-kundehistorierne, der beviser dette. De gjorde selvbetjenings-AI faktisk nyttig ved at finjustere hentning, forankre deres agenter korrekt og investere i observerbarhed (observability). Så her er den kontante konklusion: Multimodal AI bryder ikke sammen, fordi AI’en ikke er “smart nok”. Den bryder sammen, fordi dataene ikke er forberedt, indekseret eller overvåget. Fodr skrammel ind i hentningssystemet, spring evalueringer over, og se tilliden brænde. Men med hybrid søgning, semantisk genrangering og konstante evalueringer kan du behandle fakturaer, kontrakter og billeder med svar, der stadig lander i virkeligheden i stedet for fantasi. Og når forankringen er i orden, kommer en anden risiko til syne. For selvom datakanalerne er rene, kan systemet, der driver dem, stadig spinde ud. Det er dér, spørgsmålet skifter: Hjælper agenten, der koordinerer alt dette, faktisk din forretning, eller forvandler den bare i al stilhed dit IT-budget til bålbrændsel? 3. Hjælpsom agent eller dyrt “papirvægt”? En agent koordinerer modeller, data, triggere og handlinger – tænk på det som en trafikbetjent for dine automatiserede arbejdsgange. Denne kløft mellem den rene definition og den rodede virkelighed er der, hvor de fleste teams skrider ud. På papiret ser en agent fantastisk ud. Du giver den instruktioner, peger den mod dine data og apps, og den skal køre processer, hente svar og endda starte arbejdsgange. Men dette er ikke en perfekt kollega. Her er skelnen, som mange overser: Copilots og agenter er ikke det samme. En copilot er grundlæggende en prompt-ven. Du spørger, den svarer, og du bevarer kontrollen. Agenter træffer derimod beslutninger uden at vente på dig. De følger dine vage instruktioner til punkt og prikke, selv når resultaterne ikke giver mening. Det er dér, “automatiseringen” enten sparer reel tid eller snubler over i kaos, som du skal bruge dobbelt så lang tid på at rydde op. Sandheden er, at mange teams giver deres agent en jobbeskrivelse, der lyder som et valgflæsk: “Optimer processer. Giv indsigt. Hjælp mennesker.” Agenter uden afgrænsning holder sig ikke pænt i deres bane. De går amok. De opfinder problemer, der skal løses. De duplikerer poster. De kører i endeløse sløjfer. Mange organisationer rammer forhindringer tidligt, fordi de aldrig stramt afgrænsede deres agenter, aldrig tilføjede valideringstrin og aldrig instrumenterede telemetri. Uden disse beskyttelsesværn er dit skinnende nye værktøj blot en hensynsløs praktikant med administratorrettigheder. Og det er her, Microsofts stak faktisk giver dig brikkerne. Copilot Studio er lavkode-stedet, hvor udviklere designer agentens adfærd. Derefter er Azure AI Foundrys Agent Service den virksomheds-stillads, der sætter disse agenter i produktion med observerbarhed. Så hvordan ved du, om din agent faktisk er nyttig? * Reducerer den menneskelige timer, eller trækker den dit personale ind i fejlfindingsarbejde? * Indsamler du målinger som forankring, flydende sprog og koherens? * Har du telemetri på plads, så du kan opfange afvigelser, før brugerne begynder at klage? Vejen ud er ved at bruge Azure AI Foundrys observerbarheds-funktioner og indbyggede evaluatorer. Disse er ikke valgfri tilføjelser; de er den dokumenterede måde at måle forankring, relevans og koherens på. 4. Den autonome agent-fælde Autonome agenter er dér, hvor hypen bliver farlig. Fælden er simpel – de venter ikke på tilladelse. Copilots holder pause for dig. Autonome agenter gør ikke. Og når de træffer en dårlig beslutning, sker skaden øjeblikkeligt og spreder sig på tværs af din tenant. Copilots er reaktive, agenter er proaktive. I stedet for at sidde stille, indtil nogen skriver en prompt, afgrænser du agenter til at overvåge service-tilstand eller køre arbejdsgange automatisk. Men her er den vigtige kontekst: Autonome agenter i Copilot Studio er i dag stadig i preview. Og selv Microsoft siger, at du har brug for livscyklusstyring, beskyttelsesværn og Copilot Control System på plads, før du overvejer at rulle dem bredt ud. Hvad er overlevelses-tjeklisten? Tre “skal gøres” kommer før enhver iøjnefaldende automatisering: * Afgrænsning af identitet og adgang. Giv din agent minimale rettigheder. * Logning og tilbageførsel (rollback). Hver handling skal efterlade et spor, du kan auditere. * Indholds- og adfærdsfiltre. Microsoft kalder dette Azure AI Content Safety – filtre, der forhindrer en ivrig bot i at generere upassende svar. Ansvarlig AI handler også om etik. Forestil dig en HR-agent, der automatisk flagger medarbejdere som “risikable”, eller en økonomi-agent, der tilbageholder leverandørbetalinger, den fejlagtigt klassificerer som svindel. Dette er fejl med menneskelig påvirkning, der har juridiske konsekvenser. Observerbarhed er ikke valgfrit. Du skal bruge dashboards, der viser hvert skridt, en agent tager, og evaluatorer, der kontrollerer, om dens output var forankret, relevant og koherent med din politik. Og du har brug for “human-in-the-loop”-muligheder. Den rigtige analogi her er at lade en teenager lære at køre bil. Du afleverer ikke nøglerne og håber på det bedste. Du sidder på passagersædet, giver dem grænser og installerer bremser, du selv kan trykke på. Det er livscyklusstyring i praksis. 5. Azure AI Foundry: Din fabrik eller dit minefelt? Azure AI Foundry er Microsofts nye flagskib – en såkaldt “fabrik” for alt AI. Problemet? For mange teams går ind og behandler det som IKEA. De kaster modeller og forbindelser sammen uden instruktioner. Det, de ender med, er ikke et enterprise AI-system – det er et demo-legetøj, der vælter første gang, en rigtig bruger smider en rodet PDF ind. Sandheden er, at Foundry er et fabriksgulv, ikke din hackathon-legetøjskasse. Det betyder, at du skal sætte identitetsgrænser, pakke indholdssikkerhed rundt om enhver pipeline og bruge observerbarhed. Her er faktureringsfælden: Foundry-priser er forbrugsbaserede og knyttet til de specifikke tjenester, du bruger. Hver forbindelse, hvert hentningskald, hver besked måles og faktureres din tenant. Hvis du ikke estimerer omkostningerne og sporer br
