Azure AI Foundry er Microsofts stærkeste satsning på virksomhedsstyring, men et dårligt første køb. Det er platformen, der forener Azure OpenAI Service, Azure AI Search og Azure Machine Learning under ét kontrolplan, én identitetsmodel og ét sted, hvor du kan overvåge, hvad dine agenter rent faktisk foretager sig.
Betragt det som et kontroltårn. Fantastisk, når fyrre fly cirkler rundt. Meget dyrt, når du kun ejer ét fly. Det er grunden til, at Azure AI Foundry først for alvor giver mening ved dit andet eller tredje use case frem for det første. (Microsoft omdøbte det til Microsoft Foundry ved Ignite i november 2025. De fleste kontrakter og jobbeskrivelser nævner stadig Azure AI Foundry, så det er den betegnelse, vi bruger her. Det er den samme platform.)
Nu til den del, som produktsiderne udelader. De fleste Azure AI Foundry-projekter fejler ikke på grund af modellen. De fejler i de to uger efter demoen, når nogen spørger, hvem der godkender det, agenten lige har gjort, og ingen har et svar. Platformen var aldrig flaskehalsen. Dataene lå i tre systemer med tre forskellige tilladelsesmodeller, og den forretningsansvarlige, der skulle acceptere eller afvise outputtet, var aldrig blevet udpeget.
Azure AI Foundry samler de AI-tjenester, du sandsynligvis allerede betaler for: Azure OpenAI Service, Azure AI Search, Azure Machine Learning og Microsoft Fabric. Ét kontrolplan. Én identitetsmodel. Ét lag til overvågning.
Rebrandingen til Microsoft Foundry var ikke blot kosmetisk; indholdet ændrer på, hvad du rent faktisk køber.
Så hvad får du egentlig ud af det? Ikke nødvendigvis innovation. Du får muligheden for at køre mere end én AI-arbejdsbyrde, uden at hver enkelt bliver til sit eget governance-projekt. Det er hele argumentet for en platform frem for en punktløsning, og det kan kun betale sig, hvis du har planer om at bygge mere end én ting.
Relateret IC-læsning: Guide til Azure Machine Learning-deployment og MLOps
Hvert samarbejde, vi indleder, starter med de samme fire spørgsmål. Det er kedelige spørgsmål. Men de forudsiger bedre end noget teknisk, om et AI-transformationsprogram når frem til produktion.
Giv hver dimension en score 0 til 3, hvor 0 betyder slet ikke sandt, og 3 betyder fuldt ud sandt i dag.
Kan agenten få adgang til de nødvendige data på en lovlig, teknisk og tilstrækkelig ren måde til, at det er brugbart? Det handler ikke om, hvorvidt vi har dataene. De reelle spørgsmål er, om de ligger i et system med et API, om rettighedsstyringen fungerer, når en agent læser dem på vegne af en bruger, og om et menneske ville kunne genkende det svar, den producerer.
Den fejl, vi ser: vidensbasen eksisterer, men den er 40 % forældet, og ingen har ansvaret for den. Agenten gentager derefter med fuld overbevisning en politik, der blev udfaset i 2023.
Er der en navngiven person, ikke en komité og ikke "forretningen", som vil acceptere eller afvise det, agenten producerer? En person, hvis job bliver bedre, hvis det virker?
Den fejl, vi ser: AI-projektet tilhører innovationsteamet. Den proces, det automatiserer, tilhører driften. Driften blev aldrig spurgt. Pilotprojektet fungerer fantastisk, men bliver aldrig taget i brug.
Ved I, hvad der sker, når agenten tager fejl? Hvem står til ansvar, hvordan ser revisionssporet ud, og hvor er det nødvendigt med et menneske i loopet?
Den fejl, vi ser: dette udskydes til "før go-live", og derefter blokerer det for go-live i fire måneder. I regulerede sektorer er det den hyppigste årsag til, at en fungerende prototype aldrig bliver lanceret.
Vil teamet, der modtager outputtet, ændre deres arbejdsgang? Er de blevet informeret? Er der nogen, hvis mål bliver ændret?
Den fejl, vi ser: agenten udarbejder svaret, og udkastet bliver ignoreret, fordi ingen reelt har fået mindre at lave. De skal nu både gennemgå AI-output og udføre den oprindelige opgave. Mere arbejde. Ikke mindre.
| Score | Fase | Hvad du skal gøre |
|---|---|---|
| 0 til 3 | Udforskning | Byg ikke noget endnu. Flaskehalsen er ikke platformen. Udpeg en beslutningsansvarlig og få styr på dataejerskabet først. Typisk fire til otte ugers uglorificeret arbejde, og billigere end et slagent pilotprojekt. |
| 4 til 6 | Pilotprojekt | Et afgrænset udsnit, ingen platformforpligtelse. Bevis den forretningsmæssige gevinst på et enkelt workflow, før du arkitekturdesignere noget som helst. |
| 7 til 9 | Udrulning | Azure AI Foundry er berettiget. Byg til produktion fra dag ét med governance og evaluering indbygget fra starten frem for tilføjet efterfølgende. |
| 10 til 12 | Flåde | Du er klar til adskillige agenter under fælles governance. Det er her, platformens økonomi endelig vender til din fordel. |
Oftest er de virksomheder, der ankommer med en overbevisning om, at de er på Implementering scoret et sted i Pilotfasen. Det er ikke ment som en kritik. Det er den normale tilstand for en organisation, der har kørt AI-eksperimenter i atten måneder uden at have truffet en platformbeslutning.
Dette er den del, som de fleste leverandører springer over, så lad os være direkte.
Azure AI Foundry har intet licensgebyr. Microsoft opkræver betaling for de underliggende tjenester, som platformen orkestrerer, så din faktura vil vise Azure OpenAI Service, Azure AI Search, Azure Machine Learning og lagring. Der vil ikke stå en linje med navnet "Foundry". Det forvirrer økonomiafdelinger med imponerende pålidelighed.
Tag en agent til skadesbehandling, der håndterer 20.000 sager om måneden. Hver sag bruger cirka 6.000 input-tokens (selve sagen plus den hentede kontekst) og 800 output-tokens.
Derefter kommer den del, der reelt afgør business casen: det tekniske arbejde med at indlæse og vedligeholde dokumentgrundlaget, samt den tid, korrekturlæsere bruger på at opbygge og vedligeholde evalueringssættet. Dette måles i personuger frem for dollars pr. token, og det første år vil det typisk overstige platformomkostningerne markant.
Opstil din egen case ud fra Azure-prisberegneren, og betragt alle offentliggjorte prisintervaller – også vores – som en størrelsesorden snarere end et budget. Forskellen mellem to umiddelbart ens implementeringer er enorm og skyldes næsten udelukkende dokumentmængde og forespørgselsmønstre.
Brug Microsoft Copilot , hvis du har brug for AI i Microsoft 365, Dynamics eller GitHub, og du kan leve med, hvordan det fungerer direkte fra start. Det er billigere, hurtigere og kræver intet ingeniørteam.
Brug Azure AI Foundry når mindst to af følgende punkter gør sig gældende:
Er intet af dette tilfældet? Køb Copilot-licenser og stop med at læse. Vi vil hellere fortælle dig det nu end efter en indledende analysefase.
.webp)
Governance er grunden til, at virksomheder vælger Azure AI Foundry frem for billigere alternativer. Det er også her, de fleste prototyper dør. Fire spørgsmål afgør, om din løsning bliver lanceret.
Kan agenten se noget, som brugeren ikke kan?Dette er den fejltype, der afslutter projekter. En agent, der indekserer en dokumentbase og besvarer spørgsmål ud fra den, kan lække indhold, som den spørgende bruger ikke har ret til at se. Løsningen er, at hentning af data skal respektere dine eksisterende rettigheder, så agenten arver brugerens adgang i stedet for at have ubegrænset adgang selv. Foundry understøtter dette gennem RBAC (rollebaseret adgangskontrol: rettigheder tildelt en rolle som f.eks. "skadebehandler" frem for enkeltpersoner, så adgangen følger jobbet i stedet for personen) og identitetsbevidst hentning af data. Det sker ikke ved et uheld. Du er nødt til at indbygge det fra starten.
Hvem står til ansvar, når det går galt?Entra Agent ID giver agenten en identitet i biblioteket, hvilket gør dens handlinger sporbare og mulige at tilbagekalde. Uden en sådan bliver "AI'en gjorde det" til en revisionsanmærkning, du ikke kan svare på.
Hvor befinder dataene sig fysisk, og hvem har adgang til dem?Valg af model påvirker datalagring. Foundry hoster mange modeller direkte, men tredjepartsmodeller, der tilgås via kataloget, har deres egne vilkår. Hvis du opererer under EU's krav til datalagring, er dette et indkøbsspørgsmål snarere end et teknisk spørgsmål, og det bør afklares, før du vælger en model, frem for efter du har bygget på den.
Hvad forhindrer agenten i at gøre noget skadeligt?Indholdsfiltrering, guardrails og interventionspunkter for prompts, output og værktøjskald. Det interventionspunkt, der betyder mest i en virksomhed, er værktøjskaldet: det øjeblik, hvor en agent holder op med at svare og begynder at handle i et system. Et trin med menneskelig godkendelse her er normalt forskellen på, om et risikoudvalg godkender eller afviser.
Og den risiko, som ingen skriver på en slide? Lydløs forringelse. En modelversion opdateres, agenten bliver i det skjulte dårligere, og ingen opdager det i seks uger, fordi der ikke findes et evalueringssæt. Hvilket er præcis grunden til, at vi bygger et sådant, før vi bygger noget som helst andet.
To ting har ændret sig så markant siden 2025, at ældre vejledninger nu er misvisende.
Agentorkestrering. Microsoft har lagt sine to agent-frameworks, AutoGen (forskningsprojektet for multi-agenter) og Semantic Kernel (enterprise-SDK'et), sammen i Microsoft Agent Framework, som er udviklet af de samme teams. Det understøtter to orkestreringstilstande, og valget mellem dem er en forretningsbeslutning forklædt som en teknisk beslutning.
Microsofts egen dokumentation indeholder en linje, der er værd at læse højt for ethvert team, der gaber over for meget: Hvis du kan skrive en funktion til at håndtere opgaven, så skriv funktionen i stedet for at bruge en agent.
Multimodal kapacitet. Foundry Tools dækker tekst, dokumenter, billeder, tale og video på én platform. I praksis betyder det, at en skadesagent kan læse taksatorens noter, policen i PDF-format og fotografiet af den bulede motorhjelm i ét samlet workflow frem for at skulle igennem tre integrationer og overleveringer. For dokumenttunge brancher er det typisk her, den virkelige tidsbesparelse ligger. Det er også et område, der kronisk bliver underprioriteret, fordi teams låser sig fast på chatbots og stopper med at lede videre.
De fleste implementeringsplaner er de samme fem faser med forskellige navne. Vurdering, design, pilot, skalering, optimering. De er ikke ligefrem forkerte. De er bare ikke særlig sigende. Her er, hvad vi gør anderledes.
Før vi overhovedet tænker på arkitektur, tager vi 200 virkelige cases fra den pågældende proces og sætter os sammen med virksomhedsejeren, mens de definerer, hvad et korrekt svar er. Det er kedeligt arbejde. Det er også den mest værdifulde uge i hele forløbet, fordi det skaber et evalueringsværktøj: et fast sæt af virkelige cases med kendte, korrekte svar, der automatisk køres mod agenten, hver gang der ændres noget. På den måde kan du bevise, at systemet er blevet bedre, i stedet for at skulle diskutere det.
Springer du dette over, vil du seks måneder senere stå og diskutere, om agenten er blevet dårligere. Baseret på mavefornemmelser.
Her er formen på det værktøj, vi efterlader. Det er bevidst ikke det eksempel, man finder i Microsofts dokumentation, som blot måler én kvalitetsmetrik og spytter et tal ud. Tre ting er anderledes, og hver af dem stammer fra et projekt, hvor den manglende kontrol kostede os dyrt. Vi måler på tre dimensioner i stedet for én. Vi nægter at lade en model vurdere eskalering, for "burde denne sag være gået til et menneske?" er et spørgsmål, du skal kunne forsvare over for en tilsynsmyndighed uden at sige "det mente en anden model". Og det stopper hele processen i stedet for blot at logge en advarsel, som ingen læser.
# eval_harness.py — IC pattern for Azure AI Foundry agents
# Runs on every model change, prompt change and index rebuild. Blocks the deploy.
import json, sys
from dataclasses import dataclass
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
# The golden set comes out of ground-truth week: real cases, labelled by the
# business owner who has to live with the output. Each record carries WHO
# labelled it and WHEN, because in 14 months someone will dispute a label,
# and "the business agreed" is not an answer.
GOLDEN_SET = "eval/golden_set.jsonl" # ~200 cases, versioned in git
BASELINE = "eval/baseline.json" # scores from the last shipped build
@dataclass
class Case:
id: str
payload: dict
expected_outcome: str # the label
must_escalate: bool # ground truth: does this REQUIRE a human?
visible_to: str # the requesting user's identity
@dataclass
class Result:
correct: bool
escalation_ok: bool # deterministic, not model-judged
permission_ok: bool # did it cite anything this user cannot see?
def evaluate(agent, case: Case) -> Result:
run = agent.run(case.payload, on_behalf_of=case.visible_to)
# Gate 1. Correctness. Model-judged is acceptable here, with a rubric.
correct = judge_outcome(run.outcome, case.expected_outcome)
# Gate 2. Escalation. NOT model-judged. The agent either handed off or it
# did not. Silent over-confidence on a must-escalate case is the failure
# that ends projects, and a fuzzy scorer will not catch it.
escalation_ok = (run.escalated == case.must_escalate)
# Gate 3. Permission integrity. Every citation the agent returned must be
# readable by the user who asked. This catches the leak BEFORE a user does.
permission_ok = all(
can_read(case.visible_to, source.id) for source in run.citations
)
return Result(correct, escalation_ok, permission_ok)
def main() -> int:
client = AIProjectClient(endpoint=FOUNDRY_ENDPOINT,
credential=DefaultAzureCredential())
agent = client.agents.get(AGENT_ID)
cases = [Case(**json.loads(line)) for line in open(GOLDEN_SET)]
results = [evaluate(agent, c) for c in cases]
scores = {
"accuracy": mean(r.correct for r in results),
"escalation": mean(r.escalation_ok for r in results),
"permission": mean(r.permission_ok for r in results),
}
baseline = json.load(open(BASELINE))
# Permission is absolute. One leak fails the build. There is no tolerance
# band here, and every client who argued for one later agreed.
if scores["permission"] < 1.0:
fail(f"PERMISSION LEAK on {count_failures(results)} case(s). Blocked.")
# Accuracy and escalation are graded against the LAST SHIPPED BUILD, not an
# absolute bar. Absolute bars get negotiated downward. Regressions do not.
for gate in ("accuracy", "escalation"):
drift = scores[gate] - baseline[gate]
if drift < -0.02: # 2pp regression tolerance
fail(f"{gate} regressed {drift:.1%} vs shipped build. Blocked.")
print(f"PASS {scores} (baseline {baseline})")
return 0
if __name__ == "__main__":
sys.exit(main())
Et PoC beviser, at teknologien virker. Alle ved allerede, at teknologien virker. Så i stedet bygger vi én smal sti hele vejen til produktion: én arbejdsgang, én datakilde, rigtige brugere, rigtige rettigheder, et rigtigt revisionsspor. Bevidst begrænset i omfang. Bevidst komplet i dybden.
Pointen er, at det bringer integrations- og styringsproblemer op til overfladen i uge tre, hvor de er billige at løse, frem for i måned fem, hvor de ikke er det.
Entra Agent ID, RBAC, indholdsfiltre og eskalering til mennesker konfigureres alt sammen under den første "skive". Hos regulerede kunder er dette ikke til forhandling. Hos uregulerede kunder er det det, der sikrer, at anden og tredje use case ikke koster lige så meget som den første.
Testmiljøet fra fase 1 fungerer som portvagt for alle releases. Ingen agenter udvider deres anvendelsesområde, før de har bestået testen på sager, de aldrig har set før. Det er forskellen på en velsmurt flåde og et rod.
Vi sørger for, at jeres team ejer både testmiljøet og runbooken – ikke kun koden. En partner, der skal geninddrages ved hver eneste modelopdatering, har ikke gjort sit arbejde færdigt.
For en enkelt, veldefineret arbejdsgang tager det få uger at udvikle en første, funktionel version til produktion. Men den reelle begrænsning er næsten aldrig selve teknikken. En realistisk tidslinje ser således ud.
Sikkerhedsgodkendelsen er punktet, hvor to identiske projekter kan ende med at adskille sig med et kvartal. Spørg derfor enhver potentiel partner, hvad deres tidslinje forudsætter om jeres organisation, og vær skeptisk over for alle, der svarer, før de har kigget på jeres datagrundlag.
Sammenligningen af funktioner betyder langt mindre, end leverandørerne gerne vil have det til. I praksis er beslutningen for længst truffet for dig af to ting: hvor dine data ligger, og hvor din identitetsmodel kører. Lad os alligevel sammenligne dem, for du bliver spurgt om det før eller siden.
| Funktion | Azure AI Foundry | AWS Bedrock | Google Vertex AI |
|---|---|---|---|
| Stærkest når | Din organisation kører på Microsoft: Entra, M365, Fabric, Dynamics | Dine data og arbejdsbelastninger allerede ligger i AWS | Din datateknologi allerede ligger i BigQuery |
| Governance-model | Directory-native (Entra Agent ID, RBAC). Den stærkeste af de tre til regulerede virksomheder | Solid IAM, tyndere agent-governance-lag | Stærke ML-værktøjer, governance mindre agent-centreret |
| Bedst til | Agentflåder under fælles governance | Modeladgang og bredde | Reel ML-eksperimentering frem for samling af agenter |
| Vær opmærksom på | Navneændringer/rebranding og migrationsdeadlines | Enterprise-governance kræver mere opsætning | Svageste match, hvis dine medarbejdere bruger M365 |
Her er det strategiske perspektiv frem for det tekniske. At vælge den platform, hvor dine data ikke ligger, blot fordi den scorede højere i en sammenligningstabel, er en beslutning, du kommer til at betale for i form af integrationsarbejde hvert kvartal de næste fem år. Integrationsomkostninger akkumuleres. Funktionsforskelle udlignes.
Hvilket fører til en lidt ubehagelig erkendelse. Hvis I er en Microsoft-virksomhed, er spørgsmålet om platformen stort set allerede besvaret, og det virkelige arbejde ligger i det førnævnte spørgsmål om parathed. Tre måneders leverandørvurdering er ofte tre måneder, hvor man undgår den svære samtale.
Microsofts samlede platform til udvikling, implementering og styring af AI-applikationer og agenter. Den er placeret oven på Azure OpenAI Service, Azure AI Search og Azure Machine Learning og giver dem ét kontrolplan, én identitetsmodel og ét centralt sted til at overvåge, hvad dine agenter foretager sig.
Selve platformen er licensfri, og du kan oprette et projekt og udforske mulighederne uden omkostninger. Du betaler for de underliggende tjenester: modelinferens (tokens), Azure AI Search, lagring, beregningskraft og overvågning. Det er altså gratis at komme i gang, men ikke gratis at køre. Omkostningerne fremgår af din Azure-regning under de enkelte tjenestenavne frem for under "Foundry".
Azure OpenAI Service er én komponent. Azure AI Foundry er platformen udenom. OpenAI Service giver dig model-endpoints; Foundry tilføjer modelkataloget (herunder ikke-OpenAI-modeller som f.eks. Anthropic Claude), værktøjer til agenter, hentning af data, evaluering, overvågning og styring. Hvis du kun har brug for et model-endpoint, behøver du ikke Foundry. Hvis du har brug for at køre agenter i produktion og dokumentere deres handlinger, så gør du.
Vælg Copilot, hvis du ønsker AI i Microsoft 365, Dynamics eller GitHub og kan acceptere standardfunktionaliteten, da Copilot er et færdigt produkt. Vælg Azure AI Foundry, hvis du har brug for at bygge noget, der er specifikt for din virksomhed, tilgå dine egne data under dine egne tilladelser eller overholde regulatoriske krav. Foundry er en platform til at bygge produkter, og du bør ikke købe en platform til at løse et problem, som et produkt allerede løser.
Ja. Microsoft omdøbte det ved Ignite i november 2025, og produktbetingelserne fra januar 2026 gjorde navneskiftet officielt. Dine kontrakter og interne dokumentation kan referere til begge navne.
Model-endpoints er REST-API'er, så de kan kaldes fra ethvert sprog. Til udvikling af agenter fokuserer Microsoft Agent Framework i øjeblikket på Python og C#/.NET, og Microsoft har lovet fuld ligestilling mellem de to ved generel tilgængelighed. Hvis jeres ingeniørteam primært arbejder i Java, Go eller TypeScript, er værktøjerne til agenter mere begrænsede, og det bør I undersøge, før I lægger jer fast. Det er en reel begrænsning, som ikke fremhæves i markedsføringen.
Jeres eksisterende inferens-workloads fortsætter med at køre, så navneskiftet kræver ikke en migrering. Tidsfristerne er dog reelle. Supporten til Azure ML SDK v1 ophører den 30. juni 2026, og supporten til CLI v1 ophørte allerede i september 2025, jf. Microsofts egen migreringsvejledning. Alt, der er bygget på azureml-sdk , kræver en plan nu. Assistants API bliver også udfaset, så tjek den aktuelle dato på Microsoft Learn, før I planlægger ud fra den.
Fire stykker, i den rækkefølge de typisk giver problemer. Tilladelseslækage, hvor en agent viser indhold, som den forespørgende bruger aldrig burde se. Stille forringelse, hvor agenten gradvist bliver dårligere efter en modelopdatering, uden at det opdages af evalueringssættet. Platform-udskiftning, fordi to rebrandings på tolv måneder og reelle udfasningsfrister betyder, at dokumentation og træning hurtigt bliver forældet. Og omkostningsskred, fordi token-forbruget stiger med brugen, og uden model-routing stiger det hurtigere end værdien. Alle fire kan håndteres. Ingen af dem håndteres som standard.
En produktionsklar "thin slice", altså én arbejdsgang med rigtige brugere og reel styring, tager nogle uger at udvikle. Den samlede tid er normalt længere, og den variable faktor er intern: sikkerhedsgodkendelse og adgang til data tager rutinemæssigt to til seks uger og er den største årsag til tidsplanforskydninger. Vær varsom med enhver tidsplan, der gives, før nogen har kigget på jeres datalandskab.
En platform-ingeniør, der har ansvaret for Azure-abonnementet og dets identitetsmodel, en navngiven forretningsansvarlig for hvert use case, og compliance involveret før udviklingen starter frem for ved godkendelsen. Hvis I ikke kan pege på den person, der skal acceptere eller afvise agentens output, er I ikke klar. Det er dog et problem, der kan løses på fire uger, ikke fire måneder.
Det virker. Men økonomien favoriserer organisationer, der kører mere end én AI-arbejdsgang, fordi platformens værdi ligger i at styre mange agenter samlet frem for hver for sig. Med kun ét use case eksisterer den fordel endnu ikke.
Fordelen ved Azure AI Foundry ligger i governance frem for selve kapaciteten, da alle større platforme kan tilgå en god model. Det, Foundry giver dig, er en flåde af agenter, der kører under ét fælles regelsæt. Det er netop derfor, investeringen først tjener sig hjem ved dit andet eller tredje use case, ikke det første.
Regningen er ikke en licens, for der findes ingen licens. Det handler om tokens, retrieval, ingestion og mennesker – og ingestion er den post, ingen budgetterer med. Alt andet bliver afgjort, før en eneste linje kode er skrevet, baseret på fire ukurante forudsætninger: tilgængelige data, en navngiven beslutningstager, en klar governance-strategi og et team, der er villigt til at ændre deres arbejdsgange.
Er platformen den svære del? Nej, selvfølgelig ikke. Det er dig, der er den svære del.
Vurdér dig selv ud fra Foundry Readiness-modellen. Hvis du lander i Udforskning, er det mest nyttige, vi kan gøre for dig, at sige det højt. Og hvis du ønsker en second opinion på, hvor du reelt befinder dig, eller hvis du har en prototype, der ikke kan komme i produktion, og du ikke kan gennemskue hvorfor, så tag fat i os.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
Inês Silva er projektleder med mere end fire års erfaring med at skrive om softwarelevering, agile metoder og tech-ledelse. Da hun startede sin karriere som udvikler, bidrager Inês med en ægte, dybdegående teknisk forståelse til ledelsessiden. Hun elsker at bygge bro mellem den overordnede forretningsstrategi og den daglige tekniske udførelse, og hun brænder for at dele praktiske tips, der hjælper teams med at samarbejde bedre og levere fremragende produkter.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
