Home / Blogg / Technical Blog Posts Devops Masterminds / Ditt team använder redan AI. Ta kontroll över den med Azure AI Foundry

Gå igenom vilket företag som helst och AI-berättelsen börjar oftast före strategin. Någon har sammanfattat ett kundsamtal i ChatGPT. En produktchef har klistrat in en backlogg i Claude. En analytiker har bett Copilot förklara ett kalkylblad som förmodligen inte borde ha laddats upp någonstans.

Inget av detta är illvilligt. Människor har hittat verktyg som gör svårt arbete lättare, och de använder dem eftersom verksamheten inte har gett dem ett godkänt alternativ som är lika användbart.

Den vanliga reaktionen är en policy som säger nej. Blockera de publika sajterna, skicka en påminnelse om konfidentiell information och hoppas att problemet har försvunnit.

Det har det inte. Det har bara flyttat någonstans där det är svårare att se.

AI-problemet är ett kontrollproblem

Publika AI-verktyg är utmärkta på att få ett första utkast på pränt. De står också utanför de kontroller som de flesta organisationer redan använder för att skydda sina data. Säkerhetsteamet kan inte konsekvent se vad som skickas in. Juridik kan inte ge ett tydligt svar om var det behandlas. En produktägare kan inte begränsa en assistent till de dokument den faktiskt behöver. Och när en tillsynsmyndighet, kund eller styrelseledamot frågar vem som hade tillgång till vad är svaret ofta ett policydokument.

Risken är inte att ChatGPT, Claude eller Copilot automatiskt är osäkra. Risken är att ett konsumentkonto, en privat inloggning eller en icke godkänd webbläsarflik inte är en företagsmässig driftmodell. Den ger er inte en egen identitetsgräns, en egen nätverksgräns, ett eget spårbarhetsunderlag eller ett driftsättningsval som ert dataskyddsteam kan granska.

Det väger tyngre i Europa. Datalokalisering är numera en upphandlingsfråga. DORA, NIS2, branschreglering och kundavtal har gjort den till det. En användbar AI-policy måste besvara mer än om människor får använda ett verktyg. Den måste besvara vilka data som får nå det, vem som får fråga, var förfrågan behandlas och hur resultatet kontrolleras innan det påverkar en kund eller ett beslut.

Förbud är ingen AI-strategi

Ni kan förbjuda varje publik assistent i företaget. Era medarbetare kommer ändå att se AI i verktygen de köper, hos leverantörerna de arbetar med och hos konkurrenterna de möter. Trycket försvinner inte för att policyn säger nej. Det blir skugg-IT, och skugg-IT är den minst styrbara formen av innovation som finns.

Den bättre frågan är: vad skulle göra det användbara till det säkra?

För organisationer som redan kör på Azure är Azure AI Foundry svaret. Det ger verksamheten den förmåga människor sträcker sig efter, samtidigt som modellen, dataanslutningen och driftkontrollerna hamnar tillbaka innanför den Azure-miljö företaget redan styr.

Vad Azure AI Foundry förändrar

Foundry är inte en chattbot. Det är plattformen för att bygga och driva AI-applikationer, assistenter och agenter. Era team kan välja en lämplig modell, koppla den till godkända verksamhetsdata, testa kvaliteten på svaren och placera den bakom en applikation som använder er egen identitets- och behörighetsmodell.

Det är skillnaden mellan att människor kopierar känslig information till en allmän promptruta och att de får en ändamålsbyggd assistent som bara känner till den dokumentation, produktdata eller process den behöver känna till.

Den driftmodellen är den saknade andra halvan av AI Agents Done Right: From Experiment to Enterprise-Ready Platform, där vi skrev om att behandla AI-agenter som infrastruktur från dag ett.

Azure AI Foundry-plattformen: en modellkatalog med foundational-, öppen källkods-, uppgifts- och branschmodeller, under den tjänsterna Azure OpenAI, AI Search, AI Agent, Content Safety och Machine Learning, och därunder ett lager med utvärderingar, anpassning, styrning, övervakning och observability, nåbart från Copilot Studio, Visual Studio, GitHub och Foundry SDK

De viktiga förmågorna är okomplicerade.

Val utan ännu en plattform. Modellkatalogen låter team välja mellan Microsoft-stödda och andra lämpliga modeller för olika uppgifter: sammanfatta dokument, besvara frågor mot en godkänd kunskapsbas, klassificera en förfrågan eller hjälpa en servicedesk. Modellen blir ett medvetet tekniskt och kommersiellt val, inte vilket publikt verktyg någon råkade öppna först.

Data förblir en del av er miljö. För modeller som säljs av Azure anger Microsoft att prompter, completions, embeddings och träningsdata inte är tillgängliga för andra kunder eller modellleverantörer, och inte används för att träna generativa AI-foundationmodeller utan ert tillstånd eller er instruktion. Det är ett väsentligt annat avtal än att anta att ett publikt verktyg beter sig som en privat företagstjänst. Det exakta åtagandet beror fortfarande på modellen och driftsättningsvägen, så kontrollera det innan ni godkänner ett användningsfall i stället för att behandla en modellkatalog som en generell garanti.

Identitet och behörigheter förblir era. Microsoft Entra ID, rollbaserad åtkomstkontroll och managed identities gör att en person eller en agent bara får de behörigheter den behöver. En HR-assistent ärver inte åtkomst till ekonomi. En produktassistent behöver inte hela dokumentbiblioteket. Det låter självklart, men det är just den kontroll som saknas när känsliga prompter lämnar organisationen via ett ohanterat konto.

Nätverket blir inte en eftertanke. Privata slutpunkter, integration med virtuella nätverk och Azure Policy kan hålla arbetslasten innanför samma gränser som de applikationer och data den betjänar. Nycklar hör hemma i Key Vault. Åtkomst loggas. Policyer kan hindra en bekväm men icke regelefterlevande konfiguration från att tyst nå produktion.

Kvalitet och säkerhet driftas, de förutsätts inte. Foundry ger team möjligheter till utvärdering, spårning och övervakning så att de kan testa om en assistent är korrekt, förankrad i rätt källor och beter sig som avsett. Content Safety och Prompt Shields lägger till ytterligare ett lager där en assistent hanterar extern indata. En modell bör vara användbar innan den släpps, observerbar efter att den släppts, och stoppas när den överskrider en gräns. Så driftas mjukvara. AI bör inte få något undantag från det.

Datalokalitet är ett designval, inte en logotyp

Det här är delen att ta på allvar. Att köra på Azure betyder inte automatiskt att varje förfrågan stannar i ett visst land, eller ens inom EU. Driftsättningstypen är avgörande.

En Global-driftsättning kan behandla prompter och svar i Azure-platser runt om i världen, även om lagrade data förblir i den Azure-geografi ni valt. Det kan vara rätt val för en arbetslast med låg risk och hög skala. Det är inte valet man gör av misstag för kunduppgifter, reglerade data eller immateriella tillgångar.

För arbetslaster som kräver behandling inom EU väljer ni modell och driftsättningsväg därefter. Med en DataZone-driftsättning skapad i en EU-medlemsstat kan prompter och svar behandlas i det landet eller i en annan EU-medlemsstat. Där kravet är en viss Azure-region använder ni en regional driftsättning och bekräftar modellens tillgänglighet där. Skillnaden hör hemma i designunderlaget och riskbedömningen, inte begravd i ett plattformsteams konfigurationsanteckningar.

Lagrade data kräver samma uppmärksamhet. Samtalshistorik, uppladdade filer, vektorindex och applikationsloggar kan alla ha egna egenskaper för lagringstid och plats. Foundry ger er kontrollerna för att utforma detta ordentligt; det tar inte bort behovet av att klassificera data, sätta gallringsregler och avgöra vad som aldrig ska skickas till en modell.

Med andra ord: datalokalitet är inte ett marknadsföringspåstående. Det är ett arkitekturbeslut som era säkerhets-, juridik- och produktteam kan granska.

Ge människor ett godkänt sätt att använda AI

Det första användningsfallet behöver inte vara ett stort transformationsprogram. Välj en uppgift människor redan utför i publika verktyg: hitta ett svar i intern dokumentation, utforma ett svar utifrån godkända mallar, sammanfatta ett ärende eller klassificera en inkommande förfrågan.

Bygg en assistent kring en liten, godkänd datamängd. Ge den en managed identity med lägsta möjliga behörighet. Håll slutpunkten privat där arbetslasten kräver det. Välj rätt regional eller EU DataZone-driftsättning. Testa med verkliga men kontrollerade exempel. Logga resultaten. Sätt en människa vid den punkt där utdata blir en kundkommunikation, ett finansiellt beslut eller en systemändring.

Då blir policyn lättare att upprätthålla, eftersom den inte längre ber människor avstå från en användbar förmåga. Den ger dem den godkända platsen att använda den.

Det är det verkliga värdet i Azure AI Foundry. Det är inte en snyggare promptruta. Det är företagsplattformen för AI för organisationer som vill ha den snabbhet deras medarbetare redan ser, utan att ge upp kontrollen över de data, den identitet och den lokalitet som gör verksamheten till deras.

Det finns ingen universallösning för molnet. Därför möter vi er där ni är.

AI:n finns redan i er organisation. Att avgöra var den körs, under vems identitet och under vilka kontroller är fortfarande ert beslut, och det är lättare fattat nu än under en revisionsdeadline. Boka ett direkt samtal med DevOps Masterminds CTO Rinie Huijgen.

Dela den här bloggen