DEV Community: Alex Pechenizkiy

What Are Azure AI Services in 2026? A Complete Overview

Alex Pechenizkiy — Tue, 01 Sep 2026 17:31:24 +0000

Microsoft's Azure AI Services have evolved dramatically. If you are building AI-powered applications in 2026, the platform looks nothing like it did two years ago. Five core services, new pricing models, and a RAG pattern that has become the default architecture.

TL;DR

Azure AI Services in 2026 centers on five pillars: OpenAI Service, AI Search, Document Intelligence, Speech, and Vision. The winning production pattern is Document Intelligence for ingestion, AI Search for indexing, and OpenAI for querying -- the same RAG architecture behind Microsoft 365 Copilot. Start with a multi-service resource and prototype in AI Studio.

The Azure AI Landscape

Azure AI Services is Microsoft's umbrella for cloud-based AI capabilities. Instead of building machine learning models from scratch, you call an API and get intelligence back. Simple.

The platform now covers five core areas:

1. Azure OpenAI Service

The flagship. Access to GPT-4, GPT-4o, and the latest models directly through Azure's infrastructure. Key advantages over using OpenAI directly:

Enterprise security -- your data stays within Azure's compliance boundary
Private networking -- VNet integration, Private Endpoints
Managed capacity -- Provisioned Throughput Units (PTUs) for predictable performance
Regional availability -- deploy models in the Azure region closest to your users

2. Azure AI Search (formerly Cognitive Search)

The backbone of RAG (Retrieval-Augmented Generation) architectures. Combines traditional search with vector search and semantic ranking:

Hybrid search (keyword + vector) out of the box
Integrated vectorization -- no separate embedding pipeline needed
Skillsets for document cracking (PDFs, images, Office docs)

If you are building anything with Power Automate and AI on a governed foundation, AI Search is often the missing piece that ties enterprise data to language models.

3. Azure AI Document Intelligence

Extracts structured data from documents. Invoices, receipts, contracts, forms -- feed it a PDF and get JSON back. The prebuilt models handle common document types with zero training.

4. Azure AI Speech

Real-time speech-to-text, text-to-speech, and translation. The custom neural voice feature lets you create a synthetic voice that sounds like a specific person (with consent, obviously).

5. Azure AI Vision

Image analysis, OCR, face detection, and custom image classification. The Florence foundation model powers most of these capabilities now.

Which Azure AI Service Should You Use?

The most common question I hear: "Which service do I actually need?" Here is a 40-word answer. If you need chat or text generation, use Azure OpenAI. If you need search over your data, use AI Search. For document extraction use Document Intelligence. Speech and Vision cover their respective domains.

If you need...	Use this
Chat, text generation, reasoning	Azure OpenAI Service
Search over your own data + AI	Azure AI Search
Extract data from documents	Document Intelligence
Voice interaction	Azure AI Speech
Image/video understanding	Azure AI Vision

The Pattern That Works

Most production Azure AI applications in 2026 follow this pattern:

Ingest documents with Document Intelligence
Index them in Azure AI Search (with vectors)
Query using Azure OpenAI + Search (RAG pattern)
Present results through a Copilot-style interface

This is the architecture behind Microsoft 365 Copilot, and you can build the same pattern for your own data. For organizations already running governance on Power Platform, layering AI Search on top of existing Dataverse data is a natural next step.

Building with Azure AI?

I write about Azure AI architecture, Power Platform integration, and production patterns weekly. Follow me on LinkedIn to get notified when new deep dives drop.

What the Docs Do Not Tell You

A few things I have learned building on Azure AI Services:

PTU pricing is a trap for prototypes. Pay-as-you-go is cheaper until you hit consistent, predictable volume. Do the math before committing.
AI Search index rebuilds are slow. Plan for indexer schedules and incremental updates from day one, not as an afterthought.
Multi-service resources share quota. If Document Intelligence spikes, it can starve your Speech API calls. Monitor per-service usage even under the umbrella resource.
Region matters more than you think. Not all models are available in all regions. Check Azure OpenAI model availability before picking your region.

Getting Started

The fastest path:

Create an Azure AI Services multi-service resource (one endpoint, all services)
Use Azure AI Studio as your playground
Start with Azure OpenAI + AI Search for a RAG prototype
Add specialized services as you need them

The free tier gives you enough quota to prototype. Production pricing is pay-per-use.

If you are coming from the Power Platform side, check out how governance and naming discipline applies the same structured approach to AI integrations.

This is the first of many posts exploring Azure AI capabilities. Follow along as we dive deeper into each service with practical examples and real architectures.

This article was originally published at az365.ai. I'm Alex Pechenizkiy, an Azure and Power Platform solutions architect writing honest, vendor-neutral analysis of the Microsoft AI stack. More at az365.ai.

Building AI Solutions on Azure: The Architecture That Actually Works

Alex Pechenizkiy — Mon, 31 Aug 2026 19:46:37 +0000

Microsoft's Azure AI architecture diagram shows 5 boxes with arrows. A user query goes in. A grounded response comes out. Clean. Simple. Wrong.

The real Azure AI architecture has 15 components, 3 pricing traps, and at least 2 patterns that stop working the moment you move past a demo. I have built production AI solutions on Azure for enterprise clients, and the gap between the marketing diagram and the actual deployment is where projects fail.

This is the architecture from someone who builds it. Real service names, real pricing as of March 2026, and honest guidance on what breaks at scale.

TL;DR

Azure AI in 2026 centers on Microsoft Foundry, GPT-4.1 (1M context, 5x cheaper than GPT-4o), and hybrid RAG with AI Search. A production enterprise RAG solution runs $600-1,100/month for a mid-market workload. AI Search is the silent budget killer. Start with classic RAG unless you can tolerate preview-breaking changes.

The Service Map in 2026: What Changed and What It Is Called Now

If you set up "Azure AI Studio" 18 months ago, you need to catch up. The platform has been rebranded twice. Azure AI Studio became Azure AI Foundry, which became Microsoft Foundry. Your existing deployments still work, but the portal experience and SDK surface have shifted significantly.

Here is what actually matters in the current stack:

Microsoft Foundry is the control plane. It is where you deploy models, manage agents, run evaluations, and connect data sources. The Foundry Agent Service hit GA with production-ready AI agents, including real-time voice. The new azure-ai-projects v2 beta SDK unifies agents, inference, evaluations, and memory in a single package. Multi-agent workflows can now be built visually in the portal.

Azure OpenAI Service is the model runtime. This is where your GPT-4.1, GPT-5.2, and o-series deployments live. Same service, same endpoints, same API - it just sits inside Foundry now instead of being a standalone resource.

Azure AI Search is the retrieval layer for RAG. Vector search, keyword search, semantic ranking. This has not been rebranded (yet), and it remains the most important service in any production RAG architecture.

Cognitive Services still exist as individual APIs (Vision, Speech, Language, Document Intelligence), but Microsoft is folding them into Foundry's unified surface. For new projects, go through Foundry. For existing deployments, the standalone APIs still work.

Two newer capabilities worth knowing: Foundry MCP Server (Preview) is a cloud-hosted Model Context Protocol server at mcp.ai.azure.com that connects from VS Code and Visual Studio with Entra auth. Foundry Local lets you run large multimodal models fully disconnected on local hardware with APIs that mirror the cloud surface. Both are early, but they signal where Microsoft is heading.

For a deeper look at each service and where they fit, see What is Azure AI Services in 2026.

The Models: What to Deploy and What It Costs

Model selection is your first architecture decision and it determines your cost structure for the life of the project. Here is the lineup as of March 2026:

Model	Context Window	Input $/M tokens	Output $/M tokens	Best For
GPT-4.1	1M tokens	$1.00	$4.00	High-context RAG, document processing
GPT-4o	128K tokens	$5.00	$15.00	Existing production apps, multimodal
GPT-4o-mini	128K tokens	$0.15	$0.60	High-volume, cost-sensitive workloads
GPT-5.2	400K tokens	Preview	Preview	Reasoning-heavy, complex analysis
o3	N/A	$2.00	$8.00	Chain-of-thought reasoning tasks
text-embedding-3-small	N/A	$0.02	N/A	RAG embeddings (default choice)
text-embedding-3-large	N/A	$0.13	N/A	Higher-accuracy embeddings

The headline: GPT-4.1 is the new default for most projects. It is 5x cheaper on input and 3.75x cheaper on output than GPT-4o, and it has a 1M token context window. Unless you need GPT-5.2's reasoning capabilities or GPT-4o-mini's rock-bottom pricing for high-volume scenarios, GPT-4.1 is where you start.

The 1M token context window on GPT-4.1 is real, but it does not mean you should stuff 10,000 pages into a single prompt. Retrieval quality matters more than context window size. I will come back to this in the RAG section.

The o-series models (o3, o4-mini) are purpose-built for reasoning. They are not general-purpose chat models. Use them when the task requires multi-step logical analysis - code review, mathematical proofs, complex decision trees. Do not use them for document summarization or Q&A. You are paying for reasoning tokens you do not need.

Batch API cuts costs by 50% for non-real-time workloads. If you are processing documents overnight, generating embeddings for a new corpus, or running bulk evaluations, batch is the first cost optimization to implement.

How Does RAG Actually Work on Azure?

The Retrieval-Augmented Generation pattern is the foundation of most enterprise AI on Azure. The concept is simple: instead of asking the LLM to answer from its training data, you retrieve relevant documents first and include them in the prompt. The implementation is where it gets complicated.

Here is the production architecture, not the 5-box version:

User submits a query The query hits your orchestration layer - Semantic Kernel, LangChain, or Azure AI Agent Service. This is custom code you write and deploy on App Service or Functions.
Query goes to Azure AI Search A hybrid query runs three search methods in parallel: BM25 keyword matching, vector similarity search against your embedding index, and semantic ranking that re-ranks the top results by meaning. Results are merged using Reciprocal Rank Fusion.
Top chunks are retrieved The search returns the top 5-10 document chunks with relevance scores. Each chunk was previously split from source documents, enriched with metadata, embedded, and indexed.
Chunks are injected into the prompt Your orchestrator builds a system prompt with the retrieved chunks, citation metadata, and instructions. This prompt goes to Azure OpenAI.
LLM generates a grounded response GPT-4.1 or GPT-5 produces an answer based on the retrieved context, with citations pointing back to source documents.
Response is returned with citations The user sees the answer plus links to the original documents. Content safety filters run on both input and output.

That is 6 steps and at least 8 Azure services (App Service, AI Search, Azure OpenAI, Blob Storage, Key Vault, Application Insights, Entra ID, Content Safety). The marketing diagram shows 3 boxes.

Classic RAG vs Agentic Retrieval

Microsoft now offers two approaches, and the choice matters:

Classic RAG is the proven path. You query Azure AI Search, get results, pass them to the LLM, return the response. Simple pipeline, millisecond query times, GA features only, and you control every timeout and retry. If your system is in production or you cannot tolerate preview-breaking changes, this is the right choice.

Agentic Retrieval (Preview) is the new approach. The LLM decomposes complex questions into focused subqueries, executes them in parallel across multiple knowledge sources, and synthesizes results. It can query SharePoint and Bing directly without indexing, and it inherits Entra ID permissions. For greenfield projects that can tolerate preview instability, this is where Microsoft is investing.

My recommendation: start with classic RAG. Migrate to agentic retrieval when it reaches GA and you have validated it against your specific data. The preview label is not cosmetic. I have seen breaking changes in preview APIs that required rewriting orchestration logic on short notice.

What Breaks at Scale

Three things consistently break in production RAG deployments:

Chunking strategy matters more than model choice. Bad chunks with GPT-5 produce worse results than good chunks with GPT-4o-mini. Sentence-based splitting works for narrative documents. Fixed-size splitting works for structured data. Neither works well for tables, forms, or multi-column PDFs without preprocessing. Clean your data before embedding. Run the same cleaning operations on queries that you ran on chunks. Lowercased chunks need lowercased queries.

Terminology mismatches kill retrieval quality. Users ask about "PTO policy for remote workers" but the documents say "time off," "telecommute," "recent hires." Hybrid search with semantic ranking addresses this, but it is not perfect. You need to test with real user queries, not the queries you assume users will ask.

Response time expectations create architecture pressure. Users expect 3-5 second answers. A simple RAG query with keyword + vector + semantic ranking + LLM generation runs 2-4 seconds on a good day. Add agentic retrieval with multiple subqueries and you are looking at 8-15 seconds. The architecture decision between classic and agentic is partly a latency decision.

The Cost Math Nobody Publishes

Here is a real cost estimate for a mid-market enterprise workload: 50,000 documents, 500 users, roughly 10,000 queries per day.

Component	Azure Service	Tier	Monthly Cost
LLM (query generation)	Azure OpenAI GPT-4.1	Global Standard	$200-500
Embeddings	text-embedding-3-small	Standard	$10-30
Search index	Azure AI Search	S1 (Standard)	$250
Semantic ranker	AI Search add-on	Per 1,000 queries	$50-100
Orchestrator	App Service / Functions	B1-S1	$50-100
Document storage	Blob Storage	Hot tier	$10-20
Monitoring	Application Insights	Pay-as-you-go	$20-50
Total			$600-1,100/month

That is the honest number. Not the "$20/month AI chatbot" from the demo. Not the six-figure enterprise quote from a systems integrator. A properly architected mid-market RAG solution with monitoring, security, and production-grade infrastructure.

Three pricing traps I see repeatedly:

Trap 1: AI Search tier escalation. You start on Basic ($74/month) because your vector index fits in 2 GB. Six months later, your document corpus has grown and you need S2 at $1,000/month. The jump from Basic to S1 is manageable. The jump from S1 to S2 is 4x. Plan your storage growth before you commit to a tier. The good news: self-service tier upgrades are now in preview, so you can scale up without recreating indexes.

Trap 2: Provisioned vs Standard deployment. Provisioned Throughput Units (PTUs) give you reserved capacity and predictable costs. But the minimum commitment is significant, and PTUs only make sense at sustained high volume. Most teams should start with Standard (pay-per-token) and migrate to Provisioned when monthly token spend consistently exceeds the PTU cost. Do the math before you sign.

Trap 3: Total cost vs Azure OpenAI cost. Azure OpenAI token pricing is competitive. But total Azure cost runs 15-40% higher than calling OpenAI directly when you factor in the support plan, data transfer, Blob Storage, networking, and Key Vault. The trade-off is enterprise security, compliance, private networking, and regional data residency. For regulated industries, that premium is worth it. For a startup building a chatbot, maybe not.

Scaling Triggers That Change the Math

100K+ documents push you to S2 AI Search ($1,000/month) or storage-optimized tiers ($2,500+/month)
High sustained throughput justifies PTU commitment over pay-per-token
Multi-region deployment multiplies the entire cost stack by region count
Fine-tuning adds compute costs for training runs on top of inference costs

Want architecture reviews like this for your Azure AI project?

Follow Alex on LinkedIn for cost breakdowns, architecture patterns, and honest takes on what works in production.

Power Platform Integration: The Bridge Between Pro-Dev and Citizen AI

Most enterprise organizations do not choose between custom Azure AI and Power Platform AI. They need both. The architecture question is where the boundary sits.

Azure OpenAI Connector is a Premium connector for Power Automate and Power Apps. It calls Azure OpenAI endpoints directly from flows and canvas apps. Requires a Premium license (per user or per app). Use this when you need GPT capabilities inside an existing Power Platform workflow without building a custom API. The AI-powered flow review pattern shows what this looks like in practice.

Copilot Studio is the low-code surface for building AI-driven agents. It integrates with Azure OpenAI, Azure AI Search, and Microsoft Graph. Deploy agents across websites, Teams, and other channels. For organizations that want AI assistants without custom code, Copilot Studio is the entry point.

Dataverse as a RAG source is the pattern I see gaining traction. Your CRM data, case records, knowledge articles - all sitting in Dataverse - can be surfaced through custom APIs or Service Bus integration to Azure AI Search. Virtual tables can integrate AI-enriched data back into Dataverse without replication. The Power Platform governance baseline covers how structured governance makes this integration manageable.

One thing to watch: AI Builder credits are transitioning to Copilot Studio Credits. Seeded credits from Power Apps Premium and D365 licenses are available until November 1, 2026, then they disappear. If your AI Builder consumption relies on seeded credits, plan your budget now.

The honest take on when to build custom Azure AI vs adopt Copilot is a decision framework I cover in the next article in this series.

What the Architecture Diagrams Leave Out

After building production AI solutions on Azure, here is what I wish someone had told me upfront:

The naming churn is real and it affects your team. Azure AI Studio became Azure AI Foundry became Microsoft Foundry. Documentation references all three names. Internal training materials go stale. Your team members search for "Azure AI Studio" tutorials and find outdated guidance. Budget time for re-education every 6-12 months.

Content safety filtering adds latency and occasionally blocks legitimate queries. The built-in content filters are non-negotiable in Azure OpenAI (unlike calling OpenAI directly). They protect you from liability, but they also add 100-300ms to every request and sometimes flag medical, legal, or HR content as harmful. You need a plan for false positives.

Monitoring is not optional, and Application Insights alone is not enough. You need token usage tracking, retrieval quality metrics (are you returning relevant chunks?), groundedness evaluation (is the LLM making things up?), and cost attribution by department or use case. Microsoft's GenAIOps guidance documents this, but most teams discover the need after the first invoice surprise.

Model Router (Preview, May 2025) auto-selects the best underlying model per prompt. Interesting concept, but I would not use it in production yet. You lose cost predictability and debugging clarity when you cannot tell which model answered a given query.

The GPT-RAG Solution Accelerator (github.com/Azure/GPT-RAG) is the best starting point for a production deployment. Zero-Trust architecture, network isolation, NL2SQL agent capabilities, and Responsible AI guardrails included. It is opinionated, which is exactly what you want when standing up enterprise AI infrastructure.

The Architecture Decision That Matters Most

Every team I work with wants to talk about models. GPT-4.1 vs GPT-5.2. Context windows. Reasoning capabilities. Those choices matter, but they are reversible. You can swap models in an afternoon.

The decision that actually determines project success is retrieval architecture. How you chunk documents, how you build your search index, how you handle multi-source data governance. Get that wrong and no model will save you. Get it right and even GPT-4o-mini delivers useful results.

Start with hybrid search (keyword + vector + semantic ranking) on Azure AI Search. Use GPT-4.1 for generation. Monitor costs weekly. Build your architecture diagrams before you write code. And test with real user queries from day one, not synthetic benchmarks.

The "$20 AI chatbot" from the demo becomes a $600-1,100/month production system. That is still dramatically cheaper than the pre-AI alternative of hiring 3 analysts to manually search 50,000 documents. But architects need honest numbers, not marketing slides.

Build with the real architecture. Budget with the real costs. Ship with the real constraints. That is how AI on Azure actually works.

Microsoft AI Builder Series

AI Certifications in 2026 - Which ones actually matter
Building AI on Azure - The architecture that works
Copilots vs Custom AI - When to build and when to buy

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Microsoft AI Certifications in 2026: Which Ones Actually Matter

Alex Pechenizkiy — Sun, 30 Aug 2026 17:51:25 +0000

Half of Microsoft's AI certifications are retiring by June 2026. Three exams gone, six replacements launching in overlapping waves, a brand new executive tier nobody saw coming, and zero clear guidance from Microsoft on what to do if you are mid-study right now. I have been through 20 years of Microsoft certification cycles. This one is the messiest transition I have seen.

TL;DR

AI-900, AI-102, and DP-100 retire by June 30, 2026. The replacements (AI-901, AI-103, AI-200, AI-300) launch in beta between April and May. For developers, take AI-102 before June or wait for AI-103 GA. For ML engineers, grab the AI-300 beta at 80% off. For architects, AB-100 is the hardest and most valuable cert in the new lineup. For everyone else, AB-730 is the $99 baseline that proves you can actually use AI at work.

The Great Reset: What Is Retiring and What Replaces It

Microsoft announced the retirements in a Tech Community blog post that buried the timeline details. Here is the actual transition map.

Retiring Exam	Retirement Date	Replacement	Replacement Status
AI-900 (Azure AI Fundamentals)	June 30, 2026	AI-901 (Azure AI Fundamentals v2)	Beta April 2026, GA expected June 2026
AI-102 (Azure AI Engineer Associate)	June 30, 2026	AI-103 (Azure AI App and Agent Developer)	Beta April 2026, GA expected June 2026
DP-100 (Azure Data Scientist Associate)	June 1, 2026	AI-300 (MLOps Engineer Associate)	Beta now, GA expected May 2026

Notice the problem. DP-100 retires June 1 but AI-300 might not be GA until May. AI-900 retires June 30 but AI-901 enters beta in April. There is a window where the old exam is dead and the new one is not fully live. If you are planning to certify, timing matters.

There is also a second wave of entirely new certifications that did not exist before:

New Exam	Level	Cost	Status
AB-730 (AI Business Professional)	Fundamentals	$99	Live
AB-731 (AI Transformation Leader)	Fundamentals	$99	Live
AB-900 (M365 Copilot and Agent Administration)	Fundamentals	$99	Live
AB-100 (Agentic AI Business Solutions Architect)	Expert	$165	Live
AI-200 (Azure AI Cloud Developer)	Associate	$165	Beta April 2026, GA expected July 2026
SC-500 (Cloud and AI Security Engineer)	Associate	$165	Beta May 2026, GA expected July 2026

That is 9 new or replacement exams. Microsoft now has more AI-specific certifications than AWS and Google combined. Whether that is a good thing depends on which ones you pick.

The Certifications That Actually Matter

I am ranking every new Microsoft AI certification by practical career value. Not marketing value. Not resume-padding value. What actually changes your job prospects or daily work.

Tier 1: Take These

AI-300 (MLOps Engineer Associate) - The real engineer cert.
This replaces DP-100 and it is a genuine upgrade. The old Data Scientist Associate exam tested you on Azure ML Studio notebooks and scikit-learn pipelines. AI-300 tests MLOps infrastructure: GitHub Actions for model CI/CD, Bicep templates for Azure AI Foundry deployment, model monitoring, RAG pipeline optimization, and generative AI operations. This is what ML engineering actually looks like in 2026.

Study time: 50-70 hours. The beta is open right now with Microsoft's standard 80% beta discount for the first 300 testers (check learn.microsoft.com for the current beta promo code, since codes change per cohort). At roughly $33 instead of $165, this is the best deal in the current certification cycle.

If I were starting today as a data scientist or ML engineer, this is my first cert. No contest.

AB-100 (Agentic AI Business Solutions Architect) - The hardest one.
This is expert-level and requires an active associate certification as a prerequisite. The exam covers multi-agent AI system design across Dynamics 365, Power Platform, Copilot Studio, and Azure AI. Not many people have deep knowledge across all four platforms. That small candidate pool is exactly what makes this cert valuable.

Study time: 60-80 hours. Cost: $165. If you work at the intersection of D365 and AI and you are already building agentic governance into Power Platform projects, this is the cert that separates you from everyone else. We took this one apart domain by domain in the AB-100 decode: what the Deploy-heavy weighting signals, the prerequisite gate that catches PL-600 holders, and a three-week prep plan.

AI-103 (Azure AI App and Agent Developer Associate) - The developer default.
This replaces AI-102 with a stronger focus on Azure AI Foundry, agentic patterns, and Copilot Studio integration. If you build AI-powered applications on Azure, this will be your primary credential starting mid-2026.

The problem: it is not GA yet. Beta is expected April 2026. If you need a cert now, take AI-102 before June 30. Your AI-102 credential stays valid for one year after the retirement date, and the knowledge overlaps significantly with AI-103.

Tier 2: Situationally Valuable

AB-730 (AI Business Professional) - The baseline everyone should have.
This is the $99, 15-20 hour certification that proves you can use generative AI tools productively. Prompt engineering, business content drafting, AI-assisted analysis. It is not technical. That is the point. Every knowledge worker who uses M365 Copilot daily should have this. If you manage a team, make this the standard.

AB-900 (Copilot and Agent Administration Fundamentals) - For IT admins.
Heavy on Microsoft Purview, DLP policies, DSPM for AI, and SharePoint oversharing prevention. If you are the person responsible for rolling out Copilot licenses and making sure nobody accidentally shares confidential data through AI, this is your cert. Niche but critical.

SC-500 (Cloud and AI Security Engineer Associate) - The security crossover.
Beta expected May 2026. If it covers LLM application security, Purview DSPM for AI, and Copilot data protection as expected, this fills a gap that nobody else in the market has addressed. Security engineers who understand AI-specific attack surfaces are in short supply.

Tier 3: Strategic But Not Urgent

AB-731 (AI Transformation Leader) - The one nobody is talking about.
This is the first Microsoft certification explicitly designed for executives. Not technical people. Not developers. Directors, VPs, and department heads who need to understand AI business value, responsible AI governance, and adoption strategy.

The exam covers three domains: AI business value assessment (35-40%), Microsoft AI capabilities (35-40%), and implementation strategy (20-25%). Study time is 20-30 hours. Cost is $99.

Here is why this matters even if you are technical. Your CTO or VP of Engineering probably cannot articulate what Microsoft's AI stack actually does. They know "Copilot" and maybe "Azure OpenAI" and that is it. AB-731 gives them a structured framework for AI investment decisions. If you are trying to get AI initiatives funded, sending your leadership team through AB-731 prep materials removes the biggest blocker: executives who do not understand what they are approving. The Power Platform governance baseline is a good primer on why governance matters before you hand leadership the AB-731 study guide.

AI-901 (Azure AI Fundamentals) - Wait for it.
Direct replacement for AI-900. If you have zero AI background and want a fundamentals credential, wait for this instead of rushing through AI-900 before retirement. The content will be updated for 2026 tooling. Beta expected April, GA expected June.

AI-200 (Azure AI Cloud Developer Associate) - TBD.
Beta expected April 2026. The differentiation from AI-103 is not clear yet. This appears to be a broader cloud developer cert with AI integration focus, but until the study guide drops, I cannot recommend it over AI-103.

Do Certifications Actually Affect Your Career?

Here is the real question. Do these credentials translate to money and job offers?

Role	Salary Range (USD, 2026)	Cert Premium vs Uncertified
AI/ML Engineer (certified)	$120,000 - $200,000	+15-25%
Azure AI Engineer (AI-102/AI-103)	$110,000 - $165,000	+12-20%
MLOps Engineer (AI-300 target)	$130,000 - $180,000	+15-25%
Data Scientist (DP-100/AI-300)	$115,000 - $170,000	+12-20%

Certified professionals earn 15-25% more than uncertified peers in equivalent roles. That is not my opinion. That is what the salary data shows across multiple surveys.

But here is the nuance. Entry-level AI hiring dropped 73.4% in 2025. The market is not looking for people who can pass a fundamentals exam. It is looking for mid-to-senior practitioners who can ship production AI systems. A fundamentals cert alone does not move the needle. An associate or expert cert stacked on top of real project experience does.

The ROI math on AI-300: $165 exam fee (or $33 at beta pricing), 50-70 hours of study, and an MLOps Engineer role pays $130,000-$180,000. If certification moves you even one salary band, the return on 60 hours of study time is measured in tens of thousands of dollars per year.

Building AI solutions on Azure?

Start with the architecture patterns that actually work in production. What are Azure AI Services in 2026 maps the full service catalog, and Copilots vs Custom AI covers build-vs-buy decisions for real projects. Follow Alex on LinkedIn for architecture deep dives.

Microsoft vs AWS vs Google: The Honest Comparison

	Microsoft	AWS	Google Cloud
AI-specific certs	10+	2	2
Fundamentals tier	AI-901, AB-730, AB-731, AB-900	AI Practitioner ($150)	None
Developer/Engineer tier	AI-103, AI-200, AI-300	ML Specialty ($300)	Professional ML Engineer ($200)
Architect/Expert tier	AB-100	None	None
Security + AI cert	SC-500	None	None
Business/Executive cert	AB-730, AB-731	None	None
Cloud market share	~24%	~31-33%	~10-12%
Salary range	$110K - $200K	$130K - $165K	$140K - $170K

Microsoft has the broadest certification portfolio by far. AWS has two AI certs. Google has two. Microsoft has ten and counting.

Does breadth mean quality? Not automatically. But it does mean Microsoft is the only vendor where a business analyst, a developer, an ML engineer, an architect, a security engineer, and an executive can all get role-appropriate AI credentials from the same platform. AWS and Google do not have a cert for your CTO. Microsoft does.

The salary numbers are interesting. Google Cloud ML Engineer certification correlates with the highest single-cert salary bump at roughly 25%. AWS ML Specialty appears in 40% more job postings than competitors for ML-specific roles. Microsoft Azure AI sits in the middle on both metrics but has 3x more certification paths.

My honest take: if you work in a Microsoft shop (D365, Power Platform, M365, Azure), Microsoft certs are the obvious choice. If you are cloud-agnostic and optimizing purely for salary, Google's ML Engineer cert has the best ROI per exam. If you want the most job postings to apply to, AWS ML Specialty gives you volume.

Most competitive professionals hold one vendor cert plus one vendor-neutral credential (Stanford ML Specialization, fast.ai, or Deep Learning Specialization). The vendor cert proves you can deploy. The theory cert proves you understand why.

The Free Credentials Everyone Ignores

Microsoft offers Applied Skills assessments. These are free, hands-on lab credentials. Not traditional exams. You complete a real task in a sandbox environment and earn a credential if you pass.

Current AI-related Applied Skills:

Create agents in Microsoft Copilot Studio - build and deploy a working agent
Develop generative AI apps with Azure OpenAI and Semantic Kernel - code-level assessment
Generate reports with AI research agents - practical AI application
Prepare security and compliance to support Microsoft 365 Copilot - governance skills

These do not carry the weight of a full certification on a resume. But they are free, they prove hands-on ability (not just exam knowledge), and they take 2-4 hours each. If you are building a Copilot-powered solution and want to validate your skills without spending $165, start here.

What I Would Actually Do

If I were planning my certification path right now, here is exactly what I would do based on career stage.

Early career (0-3 years):
Wait for AI-901 (April beta). Pass it. Then immediately start studying for AI-103. Those two credentials plus a GitHub portfolio of actual projects is enough to get interviews. Skip AB-730 unless your employer pays for it. Your time is better spent building things.

Mid-career developer (3-7 years):
Take AI-102 right now, before June 30. The content overlaps with AI-103 and you get a valid credential immediately instead of waiting for a beta. Then stack the Semantic Kernel Applied Skills credential on top. If you are building AI-powered apps on Azure, the combination of AI-102 + hands-on Semantic Kernel experience puts you ahead of 90% of candidates.

Senior engineer or ML specialist (7+ years):
AI-300 beta. Today. The standard 80% beta discount is available for the first 300 testers (check learn.microsoft.com for the current code, since beta promo codes rotate per cohort). This is the most technical cert in the new lineup and it validates what you probably already do: MLOps pipelines, model deployment, monitoring, and generative AI operations. At roughly $33, the risk-reward ratio is absurd.

Architect:
AB-100, but only after you have a qualifying associate cert (that is a hard prerequisite). If you already hold AI-102 or any of the 14 qualifying associate certs, start studying now. If you are building agentic solutions across D365 and Azure AI, this is the credential that proves cross-platform architecture competence. Small candidate pool means high differentiation.

Manager or director:
AB-731 (AI Transformation Leader). The $99 you spend and 20-30 hours you invest will give you the vocabulary and framework to evaluate AI initiatives, set governance policy, and make funding decisions without depending on your technical team to translate everything. Then send your entire team through AB-730.

IT admin managing Copilot rollout:
AB-900 first, then the Applied Skills credential for Copilot security and compliance. These two together cover the governance side of AI deployment that most organizations are ignoring until something goes wrong.

The Timeline That Matters

Here is what to do month by month.

March 2026: Decide your path. If you are taking AI-102 or DP-100, register now. If you want the AI-300 beta discount, apply before slots fill.

April 2026: AI-901 and AI-103 betas open. Early adopters can take these at reduced cost. Beta scores take longer to process (8-10 weeks).

May 2026: SC-500 beta opens. AI-300 expected GA. Last full month to take DP-100 before June 1 retirement.

June 2026: AI-900, AI-102, DP-100 all retired by June 30. AI-901 expected GA. AI-103 expected GA. The old era is officially over.

July 2026: AI-200 and SC-500 expected GA. The full new certification portfolio is in place.

The window between now and June is the most important. After June, the path is clear. Right now, you have a choice between the known (old exams with defined study guides) and the unknown (new exams with beta-quality materials). I would take the known exam now and the new exam later. Having both on your profile shows continuity.

The certification market is shifting from "prove you know AI concepts" to "prove you can deploy AI systems." Every new exam in the 2026 lineup emphasizes hands-on skills, production deployment, and operational concerns over theory. That is the right direction. Study accordingly.

Microsoft AI Builder Series

AI Certifications in 2026 - Which ones actually matter
What Are Azure AI Services in 2026 - The full service map
Copilots vs Custom AI - When to build and when to buy

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

15 Rules for Perfect Architecture Diagram Arrows

Alex Pechenizkiy — Sat, 29 Aug 2026 17:27:43 +0000

I built a programmatic checker that scores architecture diagram arrows against 15 quality rules, then ran it on the 52 diagrams shipped on this site.

41 failed.

Not "borderline." Failed. Crossed arrows. Diagonal segments. Edges routing through shapes. Exit points bunched together. The checker is mechanical and applied to my own published artifacts, so this isn't a study, it's a self-audit: ~79% of diagrams I'd already shipped had routing issues the human eye glosses over.

The 15 rules below are the rules the checker enforces. Every diagram shipped after the audit passes all of them.

TL;DR

Professional architecture diagrams require orthogonal-only edges, zero crossings, zero edge-through-shape violations, evenly distributed exit points, 20px clearance from shapes, and grid-aligned waypoints. These aren't style preferences - they're geometric constraints that can be checked programmatically. Most auto-routed diagrams fail at least 3 of these 15 rules.

The 3 Critical Rules (Zero Tolerance)

These three rules have zero tolerance. Violate any one of them and the diagram looks amateur, regardless of everything else.

Rule 1: Orthogonal Only

Every segment of every edge must be either perfectly horizontal or perfectly vertical. No diagonals. No curves. No "close enough."

The test: Take any two consecutive points on an edge path. Either their X coordinates are identical (vertical segment) or their Y coordinates are identical (horizontal segment). If both differ, the segment is diagonal.

Why it matters: Diagonal edges look unintentional. They suggest the tool auto-routed the edge and nobody reviewed it. A single diagonal segment in an otherwise clean diagram breaks the visual consistency.

The fix: Insert a waypoint at the bend point to split the diagonal into two orthogonal segments. Choose the L-shape (horizontal-first or vertical-first) that creates fewer crossings with other edges.

Rule 2: Zero Crossings

No two edges may intersect at any point along their paths.

The test: Decompose every edge into horizontal and vertical segments. For every pair of edges, check all H-V segment pairs. A crossing occurs when a horizontal segment's Y value falls between a vertical segment's Y endpoints AND the vertical segment's X value falls between the horizontal segment's X endpoints.

Why it matters: Crossed edges force the reader to trace which line goes where. With more than two crossings, the diagram becomes a puzzle instead of a communication tool.

The fix: Re-route the shorter edge by adding waypoints that go around the crossing point. Use the "highway" pattern - route the edge outside the main diagram area, then back in.

Rule 3: Zero Edge-Through-Shape

No edge segment may pass through the bounding box of any shape that is not the edge's source or target.

The test: For each edge segment, check intersection with every non-source, non-target shape. A horizontal segment at y=100 from x=50 to x=300 passes through a shape at (120, 80, 160, 60) because the segment's Y is within the shape's vertical bounds and the segment's X range overlaps the shape's horizontal bounds.

Why it matters: This is the most egregious violation. An arrow that goes through a box looks broken. It's the first thing anyone notices. It screams "nobody reviewed this diagram."

The fix: Add two waypoints that route the edge around the shape, maintaining at least 20px clearance. Route below (shape.bottom + 20), above (shape.top - 20), or to the side.

The 4 Routing Quality Rules

These affect how professional the routing looks. They're the difference between "acceptable" and "polished."

Rule 4: Minimal Bends

Each edge should have the minimum number of bends needed to reach its target without violating Rules 1-3. Extra bends add visual noise.

The test: For each edge with N waypoints, simulate removing each intermediate waypoint. If the path is still valid without it, the waypoint is unnecessary.

Rule 5: Consistent Exit/Entry Points

When multiple edges exit the same side of a shape, they must be evenly distributed. Not all bunched at the center.

The formula: For N edges exiting the same side, position each at (i + 1) / (N + 1). Three edges from the right side should exit at Y positions 0.25, 0.50, and 0.75. Not 0.33, 0.50, 0.67. And definitely not all at 0.50.

Why it matters: Bunched exit points create overlapping edge segments near the shape. The first few pixels of each edge look like one thick line instead of separate paths.

Rule 6: Symmetrical Fan-Out

When one source connects to multiple targets, the routing pattern must be visually symmetrical around the center axis.

The pattern: All edges exit the source at evenly distributed points. All edges travel to a shared "highway" line (a vertical or horizontal guide). Each edge turns on the highway toward its target. The result: zero crossings, perfect symmetry.

Rule 7: Symmetrical Fan-In

Same as Rule 6 but reversed. Multiple sources converging on one target must enter at evenly distributed points with symmetrical routing.

The 3 Spacing Rules

These control the whitespace around edges. Tight diagrams with edges brushing against shapes look cramped and hard to read.

Rule 8: 20px Clearance

Every edge segment must maintain at least 20px distance from any non-source, non-target shape boundary.

The test: For each edge segment, find the closest shape boundary that isn't the edge's source or target. If the distance is less than 20px, the edge is too close.

Why it matters: Tight clearance makes it ambiguous whether an edge connects to a shape or just passes by it. 20px of whitespace removes the ambiguity.

Rule 9: No Overlapping Edges

Two different edges may not share the same path segment. Parallel edges on the same line look like one thick edge.

The fix: Offset parallel edges by 10px perpendicular to the shared segment direction. Two horizontal edges at y=100 become one at y=95 and one at y=105.

Rule 10: Label Placement

Every edge label must be centered on the edge's longest segment, not overlapping any shape, and have a white background so the label is readable even where it crosses the edge line.

The 5 Polish Rules

These are the finishing touches. They distinguish "good" from "publication-ready."

Rule 11: Flow Direction Consistency

The primary flow direction must be consistent. If the diagram flows left-to-right, more than 70% of edges should follow that direction. Feedback loops and secondary relationships are exceptions.

Rule 12: Edge Ordering Preservation

Parallel edges connecting the same columns of shapes must maintain their vertical order. If edge A's source is above edge B's source, edge A's path should remain above edge B's path at every point.

Rule 13: Right-Angle Precision

Every bend must be exactly 90 degrees. This is guaranteed by Rule 1 - if all segments are orthogonal, all bends are right angles.

Rule 14: Connection Point Accuracy

The first waypoint of each edge must exactly match the calculated exit point on the source shape. No floating-point drift. exitX=0.5 on a shape at x=100 with width=200 means the edge starts at x=200. Exactly.

Rule 15: Waypoint Grid Alignment

All waypoints must be on the 10px grid. Round every coordinate: x = Math.round(x / 10) * 10.

How I Check These Programmatically

I wrote a TypeScript engine that parses .drawio XML, extracts all vertices and edges, decomposes edge paths into segments, and runs every rule as a geometric check.

// Rule 2: Zero Crossings
// Check every pair of edges for H-V segment intersections
for (const segA of edgeA.segments) {
  for (const segB of edgeB.segments) {
    if (segA.direction === 'H' && segB.direction === 'V') {
      if (segA.y > segB.minY && segA.y < segB.maxY &&
          segB.x > segA.minX && segB.x < segA.maxX) {
        violations.push('CROSSING');
      }
    }
  }
}

The scoring: 30 points for Rules 1-3 (critical), 25 for Rules 4-7 (routing), 25 for Rules 8-10 (spacing), 20 for Rules 11-15 (polish). Pass threshold: 95 out of 100. Not 70. Not 80. One crossed arrow in a professional diagram is one too many.

Results From the Self-Audit

The checker scored all 52 diagrams shipped on this site at audit time. The breakdown:

Score Range	Count	Status
100/100 (perfect)	11 diagrams	Simple horizontal flows - no routing challenges
80-94 (close)	8 diagrams	Minor exit point distribution or clearance issues
60-79 (needs work)	8 diagrams	Edge-through-shape violations, bunched exits
Below 60 (rewrite)	25 diagrams	Multiple crossings, diagonals, edges through shapes

The diagrams that scored 100 were all simple left-to-right horizontal flows. Easy routing. No fan-out. No feedback loops. The moment a diagram had more than one flow direction, the auto-router started creating violations.

The fix for every failing diagram was the same: add explicit waypoints to each edge instead of relying on the auto-router. When you specify the exact path, the path is exact.

What I'd Recommend

Start with Rules 1-3. If your diagrams have no diagonal segments, no crossings, and no edges through shapes, they're already better than 90% of architecture diagrams in the wild.

Then add Rule 5 (exit distribution) and Rule 8 (clearance). These two rules account for most of the "it looks off but I can't explain why" feeling in diagrams.

Finally, enforce Rule 15 (grid alignment). When every waypoint snaps to a 10px grid, the entire diagram feels ordered even if you can't articulate why.

The remaining rules are polish. They matter for publication. They don't matter for a whiteboard sketch.

The 15 rules above pass mechanical review. Apply them by hand, or wire them into your diagram tooling so the bad arrows never get drawn in the first place.

For the technical pipeline behind these diagrams, see Architecture Diagrams with Draw.io MCP and Claude.

Generating 20+ Architecture Diagrams in Minutes: A Batch-Generation Pattern

Alex Pechenizkiy — Fri, 28 Aug 2026 23:21:06 +0000

When a CTO needs architecture documentation for a 350-person enterprise running 15 systems with zero existing diagrams, the timeline rarely permits weeks of Visio work. The traditional manual approach yields maybe five diagrams before the deadline, and they are outdated before the ink dries.

The batch-generation approach: define the system as code, render diagrams programmatically, and iterate visual quality through automated checks. The same definition produces 20 or more diagrams in the time it takes to draw one by hand.

TL;DR

A TypeScript script generates 20+ enterprise architecture diagrams as Draw.io XML: ERDs, network topologies, CI/CD pipelines, integration maps, security models. Each diagram exports to SVG with Azure icons embedded. Every diagram passes automated quality gates (grid alignment, color palette, edge routing) and a visual QA review loop before publishing. The full set generates in minutes per batch.

The Running Example: Cascade Dynamics

Cascade Dynamics is the canonical az365 fictional company used across multiple articles. The architecture is designed to be plausible and complete enough to exercise every diagram category, while staying entirely synthetic. None of it maps to a specific real engagement.

The setup: a 350-person firm modernizing its case-management platform. The fictional environment inherits an Oracle 19c database that has been running for 15 years, and is building a hybrid platform on Azure plus Power Platform while keeping the legacy system alive during the transition.

The stack spans:

Legacy: Oracle 19c on-prem, SFTP batch feeds, Windows Server VMs
Azure: AKS, App Services, Cosmos DB, Azure SQL, API Management, Service Bus, Azure OpenAI
Power Platform: Dataverse for case management, Power Automate for approvals, Power BI for dashboards
Security: Entra ID with Conditional Access, Key Vault, Sentinel

This is the kind of environment where architecture documentation is not optional. It is a compliance requirement. And it is the kind of environment where nobody has time to draw diagrams by hand.

How Do You Generate 20+ Diagrams from Code?

The pattern is straightforward. A TypeScript script contains helper functions for common diagram elements (icons, rectangles, containers, edges) and a specification array where each diagram is a function that returns Draw.io XML.

// Helper: Azure icon with label
function iconBlock(x, y, iconPath, label) {
  const id = addIcon(x, y, iconPath);
  addLabel(x - 20, y + 60, 90, 20, label);
  return id;
}

// One diagram = one function
{ name: 'cascade-cicd-pipeline', fn: () => {
  const ado = iconBlock(30, 70, 'devops/Azure_DevOps.svg', 'Azure DevOps');
  const build = step(140, 80, 140, 55, 'Build', 'Compile + unit tests', blue);
  const test = step(320, 80, 140, 55, 'Test', 'Integration + security', amber);
  addEdge(ado, build, 'push');
  addEdge(build, test);
  // ...
}}

Run the script. It generates 20+ .drawio files, exports each to SVG (with Azure icons embedded, transparent backgrounds), and validates against the quality gate. The whole batch completes in minutes.

The 5 Categories Every Enterprise Architecture Needs

Every complex system needs at least these five diagram categories. Skip any of them and there will be blind spots that cost time during incident response, audits, or onboarding.

Category	Diagrams	Who Reads Them
Data Architecture	ERDs, data flows, event architecture, state machines	Developers, DBAs, compliance
Infrastructure + Security	Network topology, zero trust, identity, monitoring	Platform engineers, security, auditors
DevOps + Deployment	CI/CD, environment topology, IaC, container architecture	DevOps, release managers
Integration + AI	Integration map, AI pipelines, RAG architecture, migration path	Architects, data engineers, AI team
Power Platform + Governance	Platform footprint, approval flows, environments, governance	CoE team, admins, business owners

Data Architecture: ERDs, Flows, Events, and State Machines

The Core ERD

This is always diagram #1. Before anyone writes a line of code, they need to see the data model. The Cascade Dynamics Dataverse schema has 6 core tables across 3 domains: clinical (blue), provider (green), and administrative (amber/purple/gray).

Core ERD for Cascade Dynamics. Color-coded by domain: clinical (blue), provider (green), scheduling (amber), documents (purple), audit (gray). All relationships labeled with cardinality.

What makes this ERD useful: column-level detail (not just table names), color coding by domain, and relationship cardinality on every edge. The ai_summary column on the Document table signals immediately that AI processing is happening at the data layer.

For a deeper look at generating beautiful ERDs from Dataverse schemas, see Generate a Beautiful Dataverse ERD in 5 Minutes.

Data Ingestion Pipeline

The Oracle-to-Azure migration runs nightly batch feeds through SFTP. This diagram shows the flow from legacy to cloud, splitting structured data to Azure SQL and documents to Cosmos DB.

Nightly data ingestion from legacy Oracle. SFTP batch upload to Blob Storage triggers Data Factory, which routes structured data to SQL and documents to Cosmos.

Event-Driven Architecture

Service Bus handles the async event distribution. Three topic categories (case events, document events, audit events) feed into Function App consumers. This is the backbone. Every state change in the system flows through here.

Service Bus topology with 3 topic categories and 4 Function consumers. Each consumer has a single responsibility: notification, AI processing, search indexing, or compliance logging.

Case Lifecycle State Machine

Cases move through 7 states with a decision gateway. The rejection loop (Returned to Draft) is the one that causes the most bugs. State transitions that go backward need careful handling in Power Automate.

Case lifecycle state machine. The 'Returned' state loops back to Draft. This backward transition is where most workflow bugs live.

Infrastructure + Security: Network, Zero Trust, Identity, and Observability

Network Topology

Hub-spoke VNet design. The hub hosts the firewall, bastion, and DNS. App and data spokes are peered to the hub. On-premises Oracle connects through VPN/ExpressRoute. This is the diagram the network team and auditors ask for first.

Hub-spoke network topology. Hub VNet (10.0.0.0/16) peers to app and data spokes. On-premises connection via VPN/ExpressRoute to the legacy Oracle environment.

Zero Trust Security Model

Entra ID at the center, four pillars radiating out: Conditional Access (MFA), Key Vault (managed identities), Sentinel (SIEM), and NSG Rules (micro-segmentation). Each pillar maps to a concrete implementation below it.

Zero trust security model. Every component maps from a principle (Conditional Access) to an implementation (MFA required for all users, all apps).

Identity Architecture

The authentication flow from end to end. Users authenticate through Entra ID, pass Conditional Access (MFA + device compliance), receive a JWT, hit API Management, and get routed to the appropriate backend API. This is the diagram to hand to the penetration testing team.

End-to-end identity flow. Every request passes through 4 checkpoints before reaching backend services.

Monitoring and Observability

Three telemetry sources (App Services, AKS, Functions) feed into Application Insights and Log Analytics, which converge on Azure Monitor. From there, security events go to Sentinel and operational metrics go to dashboards. This is how a team answers "what broke at 3 AM."

Observability stack. Three telemetry sources converge on Azure Monitor, which routes security alerts to Sentinel and operational metrics to Power BI dashboards.

DevOps + Deployment: CI/CD, Topology, IaC, and Containers

CI/CD Pipeline

Azure DevOps runs the pipeline. Code push triggers build and unit tests, then integration and security testing, then an approval gate, then staging with smoke tests, and finally production with blue-green deployment. The ACR (Container Registry) stores the images.

CI/CD pipeline with 5 stages. The approval gate between testing and staging is where most deployments pause for human review.

Deployment Topology

Three environments, each with identical resource sets. Dev (blue), Test/UAT (amber), Production (green). The promote/approve edges show the one-way flow. Nothing goes backward from prod to dev.

Deployment topology. Each environment has identical resource types (App Service, SQL, Cosmos) with promotion gates between them.

Infrastructure as Code

Bicep templates in git, committed to an Azure DevOps pipeline that runs ARM what-if validation, then deploys to resource groups. Azure Policy validates compliance at every deployment. No manual portal clicks allowed.

Infrastructure as Code pipeline. Bicep templates are the single source of truth. Azure Policy validates every deployment against compliance rules.

Container Architecture

The AKS cluster hosts 4 workloads: Clinical API, Document API, Event Processor, and an Auth Sidecar (DaemonSet). ACR provides container images, Application Gateway handles ingress, and Key Vault provides secrets through the auth sidecar.

AKS cluster architecture. The Auth Sidecar (DaemonSet) handles secret rotation from Key Vault so application pods never touch secrets directly.

Integration + AI: APIs, Document Processing, RAG, and Migration

Enterprise Integration Map

API Management sits at the center. On the left: consumer systems (Power Platform, Power Pages portal, mobile app). On the right: backend services (App Services, Functions). Below: legacy Oracle and Dataverse. Every system-to-system call routes through APIM.

Enterprise integration map. APIM is the single gateway for all system-to-system communication. The legacy Oracle adapter (dashed line) handles the SFTP/CDC bridge.

AI Document Processing Pipeline

Documents flow through 6 steps: upload, blob storage, AI Document Intelligence (form extraction), Azure OpenAI (summarization), Cosmos DB (storage), and a Power App (display). A reviewer uploads a scanned form and gets a structured summary in the case management app.

AI document processing pipeline. Documents go from PDF to structured summary in seconds. Doc Intelligence extracts fields, OpenAI generates the summary, Cosmos stores the results.

RAG Architecture

The Retrieval-Augmented Generation pattern. A user asks a question, Azure OpenAI sends a vector search to AI Search, which fetches relevant documents from Cosmos DB. The documents flow back to OpenAI as context for a grounded response with citations.

RAG architecture. The feedback loop (OpenAI to Search to Cosmos to OpenAI) ensures every response is grounded in actual documents, not hallucinated.

Legacy Modernization Path

The migration from Oracle to Azure is a 6-month project. Data Migration Service handles the schema and data transfer, with structured records going to Azure SQL and documents to Cosmos DB. A parallel run period validates data consistency before the Oracle cutover.

Legacy modernization path. The 6-month parallel run is non-negotiable for regulated systems. Validate data consistency before decommissioning anything.

Power Platform + Governance: Landscape, Approvals, Environments, and CoE

Power Platform Footprint

The complete Power Platform map. Dataverse is the center of gravity. Power Apps drives the case management UI, Power Automate handles workflow, Power BI powers dashboards, and Copilot Studio provides the AI assistant. API Management bridges the Power Platform to Azure backend services.

Power Platform footprint. Dataverse is the center of gravity. Every platform component reads from and writes to the same data layer.

Approval Flow Architecture

Cases need 3 approval steps: manager review, specialist review, and compliance check. Power Automate orchestrates the multi-step approval with parallel notifications at each stage.

Multi-step approval flow. Three sequential gates, each with different reviewers and criteria. The compliance check at the end is the one that catches policy violations.

Environment Strategy

The standard Dev to Test/UAT to Production promotion path. Solutions export as unmanaged from Dev, import as managed into Test, and deploy to Production only after approval. Connection references and environment variables handle the per-environment configuration.

Environment promotion strategy. Dev is unmanaged (experiment freely), Test imports managed solutions, Production accepts managed solutions only.

Governance Model

The Center of Excellence toolkit sits at the middle. DLP policies block risky connectors, CoE Starter Kit provides inventory and compliance tracking, and Environment Groups handle routing rules. Below: Solution Checker gates code quality, Approval Gates control prod promotion, and Azure Policy enforces infrastructure compliance.

Governance model. Three pillars (DLP, CoE, Environment Groups) each map to concrete enforcement mechanisms. Azure Policy extends governance to the infrastructure layer.

Why Not Use Visio, Lucidchart, or Miro?

The table below contrasts a typical manual Visio workflow against the script-based approach. Times are illustrative, not measured benchmarks.

Capability	Manual Tools	Batch Generation
Time for 20 diagrams	Days to weeks	Minutes per batch
Version control	Binary files, no diffs	XML in git, meaningful diffs
Consistency	Manual, varies by author	Code-enforced palette and layout
Update cost	Redraw from scratch	Change one line, regenerate
Azure icons	Download, import, position	648 icons referenced by path
Quality assurance	Eyeball it	Automated quality gate + visual QA
License cost	Per-seat license required	Open source toolchain

The real advantage is not speed. It is the fact that these diagrams are code. When the architecture changes, change the script and regenerate. The diagrams stay current because updating them costs nothing.

The Visual QA Loop That Catches What Code Reviews Miss

Automated quality gates check structure: grid alignment, color palette compliance, edge routing, icon usage. They catch the mechanical errors. But they miss the aesthetic problems that make a diagram confusing: tangled routing, clipped labels, poor spacing, crossed edges.

The fix: export each diagram to PNG, read it visually, critique, fix, and regenerate. The PNG review catches what the structural check cannot. Both checks together give full coverage.

For every diagram in this article, the pipeline was:

Generate .drawio XML from the TypeScript spec
Run the quality gate (grid, palette, edges, icons), which must pass
Export to PNG at 2x scale
Visually review the PNG for aesthetic issues
Fix any coordinate issues in the script
Re-generate and re-verify
Export final SVG with transparent background and embedded icons

The result: 20+ diagrams that are structurally correct AND visually clean. No tangled arrows. No clipped text. No crossed edges.

For more on the diagramming pipeline, see Architecture Diagrams with Draw.io MCP and Claude Code. For the broader argument about keeping documentation alive in git, see Living Documentation in Git.

Recommended Starting Point

Start with 5 diagrams, not 20. Every enterprise needs at minimum: an ERD, a network topology, an integration map, a CI/CD pipeline, and an environment strategy. Those five cover 80% of the questions stakeholders will ask.

Build the batch script incrementally. Add one diagram at a time, verify it looks right, commit. Avoid trying to design all 20 at once.

Use the visual QA loop from day one. Diagrams ship with broken icons, dark backgrounds, and tangled arrows often enough that the export-to-PNG-and-look step is non-negotiable. Every time.

The goal is not perfect diagrams. The goal is diagrams that exist, that are accurate, and that update when the architecture changes. If a documentation strategy requires someone to manually update Visio files, the documentation will be wrong by next week.

Code-generated diagrams are living documentation. That is the entire point.

Building architecture documentation that stays current? Check out how agentic development works in practice and the full diagramming pipeline with Draw.io MCP.

Agentic Development with Claude Code: The Setup That Actually Works

Alex Pechenizkiy — Thu, 27 Aug 2026 23:25:48 +0000

Most developers use Claude Code like a chatbot. They type a question, get an answer, type another question. Each session starts from zero. No memory of what you built yesterday, no reusable patterns, no quality standards.

That is not agentic development. That is autocomplete with extra steps.

TL;DR
Claude Code becomes a production system when you give it three things: persistent memory (CLAUDE.md + MEMORY.md), specialized agents (20+ prompt files with scoring rubrics), and automated pipelines (skills that chain agents with quality gates). This article shows the exact setup that produces the published articles you can browse at az365.ai/blog.

What Makes Development "Agentic"?

A chatbot answers questions. An agent completes tasks. The difference is not the model - it is the environment you build around it.

An agentic setup has four layers:

Project instructions that persist across sessions (CLAUDE.md, AGENTS.md)
Memory that accumulates knowledge over time (feedback, preferences, project state)
Specialized agents with defined roles, inputs, outputs, and quality gates
Skills that chain agents into repeatable pipelines

Without these layers, every session is a blank slate. With them, session 50 is dramatically more productive than session 1 because the system has learned your codebase, your preferences, and your quality standards.

Layer 1: Project Instructions (CLAUDE.md)

CLAUDE.md is the file Claude Code reads at the start of every session. It is your leverage point. Every instruction there saves you from repeating yourself in every conversation.

A minimal CLAUDE.md points to your real instructions:

# Claude Instructions
All project rules are in: **[AGENTS.md](./AGENTS.md)**
Read that file in full before writing any code.

AGENTS.md contains the operational details: project structure, coding rules, common mistakes to avoid, MCP server references, and the full agent inventory. Keeping instructions in a separate file means you can update them without touching the root config.

What goes in project instructions

Technology stack with exact versions (not "use React" but "Astro 5.x + Tailwind CSS 4.x via @tailwindcss/vite")
Common mistakes with fixes (a table of past failures prevents repeating them)
MCP servers with tool descriptions and workflows
CLI commands so the agent can operate your tools without guessing syntax
Writing rules if your project involves content (no em dashes, no AI slop phrases)

The key insight: project instructions are not documentation for humans. They are configuration for an AI agent. Write them like you are programming behavior, not explaining concepts.

We document every architectural decision this way. The same principle applies to living documentation in git - if it is not in the repo, it does not exist.

Layer 2: Persistent Memory

Memory is what makes session 50 better than session 1. Claude Code supports a file-based memory system at ~/.claude/projects/<project>/memory/.

Memory types

Type	What It Stores	Example
user	Your role, preferences, expertise level	"Senior architect, new to React frontend"
feedback	Corrections and confirmed approaches	"Never use --svg-theme auto, it breaks with OS dark mode"
project	Ongoing work, goals, decisions	"Merge freeze after March 5 for mobile release"
reference	Pointers to external systems	"Pipeline bugs tracked in Linear project INGEST"

How memory compounds

Memory accumulates feedback rules across sessions. Each rule prevents a specific mistake from recurring:

"All repos under crmvet/ must be --private"
"Always WebFetch verify after push - never say should deploy"
"SVG export needs --svg-theme light --embed-svg-images"
"Draw.io XML needs HTML entity-encoded in value attributes"

Without memory, I would need to re-explain each of these every session. With memory, the agent reads them automatically and applies them without prompting.

Layer 3: Specialized Agents

An agent is a prompt file that defines a role, inputs, outputs, and quality gates. It is not a chatbot conversation - it is a job description for an AI worker.

Anatomy of an effective agent

# Agent: Diagram Creator

## Role
Create Draw.io diagrams from visual plans using the MCP server.

## Input
- Build spec from /diagram-architect
- Article .mdx file for context
- Azure2 icon catalog

## Process
1. Build on canvas via Draw.io MCP
2. Run programmatic review (score >= 70)
3. Fix issues, re-review
4. Export .drawio + SVG

## Output
- .drawio source file
- .svg for the live site

## Quality Checks
- [ ] All positions on 10px grid
- [ ] Azure2 icons for all services
- [ ] All colors from approved palette
- [ ] Combined review score >= 70

The quality checks are what separate an agent from a prompt. Without measurable gates, you get inconsistent output. With them, you get a standard.

How many agents do you need?

We run 20 agents across two sites:

Category	Count	Examples
Content creation	4 writers + editor + researcher	Site-specific voice, 10 quality gates
Planning	3 (content, SEO, series)	Scoring rubrics, cannibalization checks
Visual	3 (strategist, architect, creator)	Diagram pipeline with MCP
Review	5 (content + 4 diagram critics)	0-100 scoring, weighted dimensions
Ops	5 (publisher, visual QA, LinkedIn, refresh, planner)	Deploy verification, staleness monitoring

You do not need 20 agents on day one. Start with 3: a writer, an editor, and a reviewer. Add agents when you find yourself giving the same instructions repeatedly.

Our naming conventions article was the first test of the writer + editor pipeline. The governance series tested batch production across multiple articles with parallel agents.

Layer 4: Skills (Reusable Pipelines)

A skill is a prompt template that users invoke with a slash command. Skills chain multiple agents into a repeatable workflow.

/write-post → Writer Agent → Editor Agent → Review Agent → Publisher Agent

Each invocation follows the same process, applies the same quality standards, and produces consistent output. The skill is the pipeline - the agents are the stages.

Skills we use daily

Skill	What It Does
`/write-post`	Full article production with anti-AI-detection checks
`/review-content`	4-dimension scoring: SEO, quality, engagement, conversion
`/review-diagram`	4 critic agents: layout, brand, storytelling, export
`/drawio`	Architecture diagrams with 648 Azure2 icons
`/diagram-architect`	Plan layout before building (coordinates, icons, edges)
`/capture-idea`	Store raw brain dump as structured backlog item

The Pipeline That Produces Articles

Here is the full lifecycle, from idea to published article:

Capture (/capture-idea) - raw brain dump to structured idea
Plan (/plan-content) - score and prioritize against existing content
Research (Researcher agent + Microsoft Learn MCP) - verify facts against official docs
Write (Writer agent, site-specific voice) - draft with opinions and real examples
Edit (Editor agent, 10 quality gates) - no em dashes, no employer names, no AI slop
Review (/review-content) - score 0-100, fix until >= 70
Visual Plan (Visual Strategist) - what diagrams, where, what type
Diagram Architect - calculate coordinates, resolve icons, plan edges
Diagram Build (Draw.io MCP) - create on canvas or batch generate
Diagram Review (4 critics) - layout, brand, storytelling, export
Export (draw.io CLI) - .drawio to SVG with embedded icons
Publish (Publisher agent) - git commit, push, verify live deployment
LinkedIn (LinkedIn Writer) - algorithm-optimized post

Each step has a defined input, output, and quality gate. If any gate fails, work goes back to the responsible agent with specific fix instructions.

The red dashed arrows are the feedback loops. A content review score below 70 sends the article back to the writer. A diagram review failure sends it back to the builder. No step is "done" until its quality gate passes.

This pipeline produced every article on this site, including the flow inventory governance piece, the environment strategy guide, and the solution-aware flows article.

MCP Servers: Extending the Agent's Reach

Model Context Protocol servers give your agents access to external tools and data. Three MCP servers power our setup:

MCP Server	What It Provides
Microsoft Learn	Search and fetch official Microsoft documentation
Draw.io	Programmatic diagram creation with Azure2 icons
Google Trends	Trending topics and news for content research

The key lesson with MCP: always verify capabilities by testing, not by assuming. Our Draw.io MCP server required a browser open on localhost:3000 for the WebSocket connection. The tools list said nothing about this requirement. We discovered it when every tool call hung indefinitely.

What Went Wrong (Twice)

Before sharing the lessons, here are two disasters that shaped the system.

The Dark Mode Export Disaster. A batch of diagrams was exported to SVG and deployed to production before anyone checked the live site in dark mode. Every diagram had a black background with dark green shapes, completely unreadable. The root cause: --svg-theme auto uses CSS light-dark() which responds to the OS dark mode preference, not the site's theme toggle. The fix was --svg-theme light with a CSS card wrapper in the blog layout. The first deploys had asset-routing bugs that the publish-check gate now catches.

The HTML Encoding Bug. Draw.io stores HTML in XML attributes. The value Dev must be encoded as Dev in the .drawio file. Draw.io then decodes it and renders the HTML. The batch generator had the encoding wrong, first too little (raw tags in XML = malformed), then too much (double-encoded = literal  showing on screen). Raw HTML rendering bugs slipped through before publish-check gating was added.

Both bugs had the same root cause: no visual review step in the automated pipeline.

The fix: a mandatory quality loop. Build the diagram, run 4 critics, check the combined score. Below 70? Back to the builder with specific fix instructions. Above 70? Export and deploy. No exceptions. The Layout Critic and Brand Critic run programmatically and scored 100/100. But neither of them could see that the exported SVG looked terrible. The fix: always verify the deployed output with WebFetch or a screenshot before declaring success.

What I Learned Building This System

1. Never accept "can't do it" from the agent

When Claude said it could not export SVGs, the correct response was "research how." The draw.io desktop CLI had --export --format svg all along. Push back on capability claims.

2. Test on the live site, not in the editor

Diagrams were built in batches before anyone checked the deployed result. The first deploy showed dark backgrounds and broken icons. Checking after the first diagram would have caught the issue immediately instead of multiplying the rework.

3. Build the review system before the production system

The content pipeline came first, with no quality gates for diagrams. Building the critic agents before batch-generating diagrams would have caught the arrow alignment, broken icons, and dark mode issues before they hit production.

4. Memory prevents repeat mistakes

Every debugging session produced a feedback memory entry. "SVG export needs --svg-theme light" is the kind of knowledge that shortens the iteration loop measurably; calibrate to your own setup.

5. Think systems, not tasks

"Fix this diagram" is a task. "Build a pipeline that produces correct diagrams every time" is a system. The system takes longer to build but pays back on every subsequent diagram.

Getting Started: Your First 30 Minutes

Create CLAUDE.md in your project root. Point it to your coding standards.
Create one feedback memory for your strongest preference (naming conventions, test patterns, deployment rules).
Create one agent for the task you do most often. Define role, input, output, quality checks.
Create one skill that invokes that agent with /your-command.
Run it and iterate. The first version will be rough. By version 3, it will be faster than doing it manually.

The gap between "using Claude Code" and "building with Claude Code" is the same gap between typing commands and writing scripts. One is interactive. The other is infrastructure.

Build the infrastructure.

Architecture Diagrams with Draw.io MCP Server and Claude Code - how we built the diagram pipeline
Power Automate Flow Inventory - what parallel agents built end-to-end on this pipeline

Logic Apps as MCP Servers - The Architecture That Actually Works

Alex Pechenizkiy — Wed, 26 Aug 2026 14:37:11 +0000

Microsoft just turned Azure Logic Apps into MCP servers. In preview, as of March 2026. This means your 1,400+ Logic Apps connectors - Dataverse, SharePoint, SQL, Outlook, SAP, ServiceNow - are now callable tools for AI agents in Claude Code, VS Code Copilot, or Cursor.

That's the headline. Here's what the docs don't tell you.

TL;DR

Azure Logic Apps Standard can now act as remote MCP servers, exposing workflows as tools for AI agents. There are two approaches: direct (fast, no governance) and via API Center (enterprise, full governance). Easy Auth is NOT optional. Standard Logic Apps have hosting costs (~$160/month minimum). The connector auth question - whose credentials does the AI agent use? - is a governance gap the docs skip.

What Is an MCP Server and Why Should You Care?

MCP - Model Context Protocol - is the open standard that lets AI agents call external tools. When you ask Claude Code to "send an email to the project team," it needs a tool that actually sends email. The MCP server provides that tool.

Until now, building an MCP server meant writing TypeScript or Python that wraps an API. You'd build an HTTP endpoint, handle auth, parse requests, call the downstream service, return results. For every integration. Manually.

Logic Apps as MCP servers changes this. You pick a connector, select the actions you want to expose, and Azure builds the MCP endpoint. The AI agent discovers the tools and calls them. No custom code.

The architecture is straightforward:

MCP Client (Claude Code, VS Code, Cursor) connects to your MCP server
MCP Server (Logic App Standard) exposes workflows as callable tools
Connectors (1,400+) do the actual work - querying databases, sending emails, creating records
Enterprise Systems (Dataverse, SQL, SharePoint, SAP) are the final destinations

The protocol is JSON-RPC 2.0 over Server-Sent Events (SSE). The transport is HTTP. Your MCP server runs in Azure, your MCP client runs locally. Remote, not local.

How Do You Set Up Logic Apps as an MCP Server?

There are two approaches. Microsoft presents them as equivalent options. They're not.

Two approaches: Direct is fast but has no rate limiting or discovery. API Center adds governance but requires APIM setup.

Approach 1: Direct from Logic App (Fast, No Governance)

Open your Logic App Standard in the Azure portal. Under Agents, you'll see a new MCP servers blade. Create a server, select existing workflows or build new ones, choose auth (OAuth or API key), done.

Your AI agent connects directly to the Logic App's MCP endpoint. No intermediary.

When to use this: Dev/test environments. Personal productivity tools. Internal prototyping. Situations where you control both the client and the server.

What's missing: No rate limiting. No usage analytics. No API key rotation policy. No centralized catalog for other teams to discover your server. If someone hammers your endpoint, there's no throttle.

Approach 2: Via API Center (Enterprise, Full Governance)

The enterprise path adds two layers: API Management for security and rate limiting, and API Center for discovery and governance.

The stack becomes: MCP Client -> API Management -> API Center -> Logic App Standard -> Connectors -> Enterprise Systems.

You create the MCP server through API Center's portal, which registers it as a governed API. API Management handles auth, rate limiting, and usage tracking. Other teams can discover your MCP server through the API Center catalog.

When to use this: Production environments. Multi-team organizations. Anything touching customer data. Compliance-regulated industries.

What you get that Direct doesn't: Centralized discovery, rate limiting, usage analytics, API key management through APIM, and audit trails.

The Auth Problem Nobody Talks About

Easy Auth is mandatory. Without it, your MCP server accepts calls from anyone. The docs bury this 8-step setup.

The docs mention Easy Auth like it's a checkbox. It's not. Here's the setup:

Create an app registration in Entra ID
Note the application (client) ID
Set the issuer URL with your tenant ID
Configure the allowed token audience (with trailing slash - yes, the trailing slash matters)
Set identity requirements (specific identities or any identity)
Set tenant requirements (allow or deny cross-tenant)
Set App Service authentication to allow unauthenticated access (yes, this is correct - Easy Auth handles it at a different layer)
Choose your auth method: OAuth 2.0 or API Key

API keys support 3 expiration durations: 24 hours, 7 days, 30 days. There's no custom duration. There's no automatic rotation. You generate a key, it expires, you generate a new one.

The governance gap the docs skip: When your MCP server calls a connector - say, the Outlook connector to send email - whose credentials are used? The answer: the credentials stored in the Logic App's API connection. This means the AI agent sends email AS whoever set up the Outlook connection. If that's a shared mailbox, fine. If that's your personal account, every AI agent user sends email as you.

This is a governance question you need to answer before exposing any connector that creates, updates, or sends data. Read/query connectors are less risky. Write connectors need a service account or shared connection.

What Does This Actually Cost?

This is the part that surprises people coming from Consumption Logic Apps.

Component	Consumption	Standard (MCP Server)
Hosting model	Pay per execution	Always-on App Service Plan
Minimum cost	$0 (idle = free)	~$160/month (WS1 plan)
Scaling	Automatic, per-trigger	Manual or autoscale rules
MCP support	No (event-driven, no persistent endpoint)	Yes (persistent HTTP endpoint)
Connectors	Same 1,400+	Same 1,400+

Standard Logic Apps run on a Workflow Service Plan or App Service Environment v3. Per the Azure Logic Apps pricing page, the entry-level Workflow Standard plan (WS1) is priced per vCPU-hour and works out to roughly $160/month for the minimum always-on configuration at list rates (region and reservation discounts vary; check the Azure pricing calculator for your scenario).

You're paying for an always-on compute instance because MCP servers need a persistent HTTP endpoint. Consumption Logic Apps are event-driven - they spin up on trigger, execute, and shut down. You can't run an MCP server on something that shuts down between calls.

For dev/test with light usage, this is a real cost consideration. For production with multiple teams calling the server, $160/month is noise.

Five High-Value Patterns to Build With This

Now that every Logic App connector is an MCP tool, the interesting question is: which connectors become the most useful AI agent tools? Five candidate patterns:

1. Dataverse query tool. Let Claude Code query your Dataverse tables by describing what you want in natural language. "Find all active cases assigned to a given user" translates to a FetchXML query through the Dataverse connector. Useful for Power Platform developers who live in the terminal.

2. SharePoint document search. Your AI agent can search SharePoint document libraries, read file metadata, and pull content. Combine this with Azure OpenAI for a RAG pattern that doesn't require a custom indexer.

3. Automated incident response. Connect to Azure Monitor alerts, ServiceNow tickets, and Teams notifications. When an alert fires, the AI agent reads the alert, creates a ServiceNow incident, and posts to the on-call Teams channel. All through MCP tools backed by Logic App connectors.

4. Approval workflow trigger. Start a Power Automate approval from your AI agent. "Send this deployment for manager approval" becomes a tool call that triggers the approval flow, waits for the response, and returns the result.

5. Multi-system data aggregation. Pull data from SQL, Dataverse, and a REST API in one agent conversation. Each query is a separate MCP tool. The AI agent orchestrates the calls and synthesizes the results. No custom middleware needed.

Honest Take

This is a genuinely useful capability. The 1,400+ connector library is Logic Apps' superpower, and exposing it to AI agents through MCP is the right move. For anyone who has been wrapping APIs in custom MCP server code, this eliminates most of that work.

But the execution has gaps:

Gap 1: Cost model mismatch. Most developers experimenting with MCP servers want something cheap or free for prototyping. Standard Logic Apps have a minimum monthly cost. Microsoft should offer a Consumption-compatible MCP endpoint, even if it's limited.

Gap 2: Auth complexity. Easy Auth setup is 8 steps with tenant configuration, app registration, and audience URIs. For something called "Easy" Auth, it's not easy. A one-click "secure this endpoint" option would help adoption.

Gap 3: Connector credential governance. The docs don't address whose credentials the AI agent uses when calling write connectors. This is the first question any security team will ask.

Despite the gaps, this is usable today for read-only Dataverse and SQL queries in dev environments. For production write operations, wait until Microsoft clarifies the credential governance story, or build a service account pattern around it.

The architecture diagram at the top of this article was generated using the Draw.io MCP diagramming pipeline. When the architecture changes (and it will, this is preview), the diagram regenerates from spec. Keeping diagrams current is what makes them worth drawing.

For more on building Azure architecture diagrams from code, see Architecture Diagrams with Draw.io MCP and Claude. For the geometry rules behind clean diagrams, see 15 Rules for Perfect Architecture Diagram Arrows.

Architecture Diagrams with Draw.io MCP Server and Claude Code

Alex Pechenizkiy — Tue, 25 Aug 2026 14:36:50 +0000

"Can you draw me an architecture diagram?"

That used to mean: open Visio (if you have a license), spend 30 minutes fighting with connectors, export a PNG, paste it into a Word doc that nobody will update. Or worse: open PowerPoint and draw boxes with arrows.

TL;DR

The Draw.io MCP server lets Claude Code generate architecture diagrams from plain text descriptions. Describe your system, get a version-controlled .drawio file in seconds. Free, git-friendly, and no Visio license required.

Now I describe what I want in plain text and Claude generates a Draw.io architecture diagram in seconds. No Visio license. No manual dragging. Version-controlled XML that diffs in git as part of your living documentation.

How Do You Generate Architecture Diagrams with Claude and Draw.io?

You describe the system in plain English and Claude produces valid Draw.io XML through the MCP server. The diagram opens in your browser for review, and you save the .drawio file directly into your repo's /docs folder. The entire process takes under a minute for most diagrams, compared to 30+ minutes of manual work in Visio or Lucidchart.

The Setup

The Draw.io MCP server runs locally and renders diagrams from mxGraphModel XML. Claude Code connects to it through the MCP protocol and can create diagrams from text descriptions.

Install the Draw.io MCP server Add it to your .mcp.json config. It runs locally on port 3000 and opens a browser-based editor.
Describe what you want Tell Claude: 'Create a swimlane diagram showing the performance review process with 4 lanes: Employee, Manager, HR, System.' Claude generates the XML.
Review and refine The diagram opens in your browser at localhost:3000. Adjust positioning if needed, or ask Claude to modify specific elements.
Save the XML Copy the .drawio file to your /docs folder. Commit to git. It's now versioned with your code.

What It Generates

Here's a swimlane process diagram generated the same way:

Swimlane diagram for a performance review process. Four lanes, decision gateway, system automation steps.

Claude handles these diagram types well:

Diagram Type	Quality	Best For
Swimlane / process flow	Excellent	Business processes, approval workflows, user journeys
Entity Relationship Diagram	Good	Dataverse schema visualization, data models
Integration map	Good	System context diagrams, API connections
State machine	Excellent	Record status flows, lifecycle diagrams
Data flow	Good	Source-to-target mapping, ETL pipelines
Sequence diagram	OK	API call sequences (Mermaid is better for these)

Real Example: D365 Integration Architecture

I described this to Claude:

"Create a Draw.io architecture diagram showing: Dynamics 365 CE in the center, connected to Azure AI Search (for document indexing), an external ERP via Azure Service Bus, Power Automate for email notifications, and Dataverse audit log feeding into Power BI. Use blue for Azure services, green for D365, gray for external systems."

30 seconds later:

Integration architecture generated from a text description. Color-coded by system type, labeled connections, legend included.

Would it have taken me 30 minutes in Visio? More.

What It Gets Right

Structure and layout. Claude understands that swimlanes have horizontal lanes, ERDs have relationships, integration maps have system boundaries.
Color coding. Tell it your color scheme and it applies consistently.
Labeling. Connection labels, system names, data flow descriptions.
XML validity. The generated mxGraphModel XML renders correctly in Draw.io every time.

What It Gets Wrong

Complex layouts. Diagrams with 20+ elements sometimes overlap. You need to drag things around manually.
Pixel-perfect positioning. It approximates positioning. Fine for working diagrams, not for presentation slides.
Your specific codebase. Claude doesn't know your actual table names or API endpoints unless you tell it. Paste your schema or API spec for accurate diagrams.
Aesthetic polish. The diagrams are functional, not beautiful. If you need presentation-quality, use Draw.io's manual tools for final polish.

The 80/20 rule

Claude generates 80% of the diagram in 30 seconds. You spend 5 minutes on the remaining 20% (positioning, fine-tuning labels). Total: 6 minutes vs 30+ minutes from scratch.

The Prompt Pattern That Works

Be specific. Don't say "draw an architecture diagram." Say:

Create a Draw.io diagram showing:
- [System A] connects to [System B] via [protocol/method]
- [System C] reads from [System B] on a [schedule]
- Use [color] for [category], [color] for [category]
- Include a legend in the top-right corner
- Layout: left-to-right flow

The more context you give, the better the output. Paste your actual table names, API endpoints, or flow definitions for maximum accuracy. For Dataverse projects, you can export your schema with XrmToolBox and feed it directly to Claude for an accurate ERD.

Building a documentation practice for your Power Platform team? Follow Alex on LinkedIn for more patterns on AI-assisted architecture and living docs.

Compared to Other Tools

Tool	Cost	AI Generation	Git Friendly	Collaboration
Draw.io + Claude	Free	Yes (text to diagram)	Yes (XML diffs)	Via git
Visio	$15/mo	No	No (binary format)	SharePoint co-edit
Lucidchart	$8/mo	Limited AI	No	Real-time co-edit
Miro	$8/mo	No	No	Real-time co-edit
Mermaid	Free	Yes (Claude writes Mermaid)	Yes (text format)	Via git

Draw.io + Claude wins on cost (free), AI generation (full diagrams from text), and git friendliness (XML diffs). It loses on real-time collaboration - you collaborate through pull requests, not simultaneous editing.

What's Next

Next article: using this workflow to generate ERDs from XrmToolBox schema exports. Export your Dataverse schema, feed it to Claude, get a visual ERD in 5 minutes.

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

AI Copilots vs Custom AI on Azure: When to Build and When to Buy

Alex Pechenizkiy — Mon, 24 Aug 2026 14:34:24 +0000

Microsoft wants you to buy Copilot for everything. Email summaries, meeting recaps, document drafts, code completions, security investigations, sales forecasting. Six Copilot products, all pitched as the answer to your AI strategy.

Sometimes they are right. M365 Copilot plugs into Word, Excel, Outlook, and Teams with zero custom code. For horizontal productivity across an organization, nothing else comes close.

But sometimes you are paying $30/user/month for 500 users when Azure OpenAI would handle the same workload for $300/month total. That is not a rounding error. That is $15,000/month vs $300/month. And the gap only widens as your use case gets more specific.

I have built both. Copilot deployments for general productivity. Custom Azure AI solutions for domain-specific workflows. The answer is never "always build" or "always buy." The answer is knowing where the crossover point is for your specific situation.

TL;DR

Copilot wins for horizontal productivity across M365. Custom Azure AI wins for domain-specific workloads at scale. The crossover point is around 15-20 users for single-purpose AI features. Most enterprises need both - Copilot for the broad surface, custom AI for the vertical depth, and Copilot Studio as the bridge between them.

The Microsoft Copilot Ecosystem in 60 Seconds

Six products carry the Copilot name. They share branding but not much else.

Product	What It Does	Pricing Model	Cost
M365 Copilot	AI in Word, Excel, Outlook, Teams, PowerPoint	Per-seat	$30/user/month (Enterprise)
D365 Copilot	AI in Sales, Service, Finance, Supply Chain	Per-seat add-on	$50/user/month
Copilot Studio	Low-code custom copilot builder	Consumption	$200/month per 25K credits
Security Copilot	Threat analysis in Defender, Sentinel	Consumption (SCUs)	$6/SCU on-demand
GitHub Copilot	Code completions, agents, PR reviews	Per-seat	$19/user/month (Business)
Power Platform Copilot	Natural-language app/flow building	Included	Part of Power Platform license

The pricing models are already a signal. M365 and D365 Copilot charge per seat regardless of usage. Security Copilot and Copilot Studio charge by consumption. That distinction matters enormously when you start doing cost math.

One more pricing detail that changes the calculus: Microsoft is launching M365 E7 in May 2026 at $99/user/month. It bundles Copilot with agent management and identity tools. If you are already on E5 at $57/user/month, the upgrade to E7 makes Copilot effectively $42/user/month instead of a $30 add-on. The bundle math is different from the add-on math.

When Copilot Is the Right Answer

I am not anti-Copilot. I have seen it save real time in real organizations. The use cases where it excels share three characteristics.

Horizontal productivity. Every knowledge worker sends emails, attends meetings, and edits documents. M365 Copilot automates the repetitive parts of all three. Meeting summaries alone save 15-30 minutes per meeting for every attendee who skipped or joined late. An Australian government pilot measured roughly 1 hour/day saved per user on summarization and drafting, with 61% reporting improved work quality.

Data already in Microsoft Graph. Copilot is grounded in your SharePoint files, Exchange emails, Teams chats, and OneDrive documents. If your organization's knowledge already lives there, Copilot can find it and reason over it without building anything. No RAG pipeline. No vector database. No embedding model. It just works.

No dev team required. M365 Copilot is an admin toggle, not a development project. Enable it, assign licenses, train users. Time-to-value is days, not months. For organizations without AI engineering talent, this is the only realistic path to AI adoption.

The Forrester numbers back this up. Their Total Economic Impact study of M365 Copilot found 116% ROI over 3 years for a composite organization - $36.8M in benefits against $17.1M in costs. For SMBs, the ROI was up to 353% within 3 years.

But here is the part Microsoft does not put in the press release.

When Custom AI Wins

Gartner surveyed IT leaders in 2025. 40% were piloting M365 Copilot. Only 5% of completed pilots moved to large-scale deployment. Most enterprises remain 12-18 months from scaled rollout.

Why? Because the moment you move past general productivity, Copilot's per-seat model breaks down and its customization ceiling becomes visible.

Domain-specific knowledge. Your legal contracts, medical records, engineering specifications, and proprietary databases do not live in Microsoft Graph. Copilot cannot reason over data it cannot see. Custom RAG pipelines on Azure OpenAI connect to any data source through any API.

Custom reasoning chains. Copilot follows pre-built interaction patterns. If you need multi-step agent workflows - retrieve from three systems, cross-reference, apply business rules, generate a structured output - you need Azure AI Foundry orchestration.

Fine-tuning. When GPT-4o does not understand your industry terminology, classification schemes, or output formats, Azure OpenAI supports fine-tuning. A fine-tuned o4-mini model costs roughly $1.70/hour for hosting plus token costs. That is expensive for experimentation but cheap for production workloads that run 24/7.

Model selection. Azure AI Foundry gives you access to the full model marketplace: OpenAI, Meta Llama, Mistral, Phi. Pick the right model for the right task. Use GPT-4o for complex reasoning and GPT-4o-mini for high-volume classification. Copilot gives you whatever model Microsoft chose.

Cost at scale. This is the big one.

How Much Does Copilot Actually Cost vs Custom Azure AI?

Here is the math Microsoft does not show you in the sales deck.

M365 Copilot Enterprise at $30/user/month:

Users	Monthly Cost	Annual Cost
100	$3,000	$36,000
500	$15,000	$180,000
1,000	$30,000	$360,000
5,000	$150,000	$1,800,000

Now compare that to a custom chatbot built on Azure OpenAI. Same use case: employees asking questions about internal knowledge. 1,000 queries/day across the organization, averaging 500 input tokens and 1,000 output tokens per query.

Custom Azure OpenAI (GPT-4o-mini) cost:

Input: 15M tokens/month x $0.15/1M = $2.25/month
Output: 30M tokens/month x $0.60/1M = $18.00/month
Azure infrastructure (App Service, AI Search, storage): $200-500/month
Total: $220-520/month regardless of user count

Read that again. $220-520/month for unlimited users vs $15,000/month for 500 licensed seats.

The crossover point

For a single AI feature - an internal knowledge chatbot, a document classifier, a summarization pipeline - custom AI becomes cheaper than Copilot at roughly 15-20 users. Below that, Copilot's zero-development-cost advantage wins. Above that, the per-seat model bleeds money for targeted use cases.

But this comparison is not entirely fair. Copilot does not just answer questions. It summarizes emails, drafts documents, recaps meetings, analyzes spreadsheets, and surfaces information across the entire M365 surface. Replicating all of that on Azure OpenAI would cost far more than $520/month - and you would spend months building it.

The real comparison is not Copilot vs custom AI. It is Copilot for everything vs Copilot for productivity + custom AI for domain-specific work.

Scenario	Copilot Cost (500 users)	Custom AI Cost	Winner
General productivity (email, docs, meetings)	$15,000/month	Not feasible to replicate	Copilot
Single domain chatbot (internal KB)	$15,000/month	$300-800/month	Custom AI
10 specialized workflows	$15,000/month	$2,000-5,000/month	Custom AI
Productivity + domain-specific	$15,000 + $2,000	N/A	Hybrid

The hybrid row is where most enterprises land. And that is where Copilot Studio enters the picture.

Building your AI strategy?

Follow Alex on LinkedIn for architecture deep dives and cost analysis on Azure AI decisions.

The Hybrid Pattern: Copilot + Custom AI + Copilot Studio

The smartest deployments I have seen run three layers.

Layer 1: Copilot for horizontal productivity. Email drafting, meeting summaries, document generation, Teams chat, Excel analysis. Every knowledge worker gets this. The per-seat cost is justified because every user touches these features daily.

Layer 2: Custom Azure AI for vertical depth. Domain-specific RAG pipelines, custom classification, specialized agents, external-facing chatbots. These serve specific teams or workflows. The consumption model scales with usage, not headcount. A legal team of 20 running contract analysis does not require 500 Copilot licenses.

Layer 3: Copilot Studio as the bridge. This is the product most "build vs buy" articles ignore, and it is the one that fills the gap between layers 1 and 2.

Copilot Studio lets you build custom copilots on Microsoft infrastructure without managing Azure resources directly. It connects to enterprise data via 1,500+ Power Platform connectors. It extends M365 Copilot with declarative agents - custom instructions, custom knowledge, custom actions - that show up right inside Teams and the M365 app.

The pricing is consumption-based: $200/month per 25,000 Copilot Credits. No per-seat charges.

Copilot Studio vs Azure AI Foundry

The bridge layer has its own decision point. When do you use Copilot Studio, and when do you go full Azure AI Foundry?

Criteria	Copilot Studio	Azure AI Foundry
Builder persona	Business users, IT admins	AI developers, data scientists
Code requirement	Low-code / no-code	Pro-code (Python, REST APIs)
Model control	Pre-selected models	Full model marketplace + fine-tuning
Deployment speed	Hours to days	Weeks to months
Integration	M365 and Power Platform native	Any system via APIs
Data residency	Microsoft-managed	Full Azure control
Custom model training	No	Yes (fine-tuning, distillation)
Best for	Internal agents, M365 extensions, FAQ bots	Custom RAG, multi-model pipelines, products

My rule of thumb: if a business analyst can describe the use case in a Teams message, start with Copilot Studio. If the requirements include "fine-tune," "multi-model," or "embed in our product," go straight to Azure AI Foundry.

The 5-Question Decision Framework

Before you commit budget to either path, answer these five questions. They will tell you where you land.

Where does the data live? If your data is in Microsoft Graph (SharePoint, OneDrive, Exchange, Teams), Copilot can reach it natively. If it is in proprietary databases, legacy systems, or external APIs, you need custom AI with a RAG pipeline.
How many people need this specific AI feature? Per-seat Copilot pricing favors broad adoption. If 500 people need email summaries, Copilot is the answer. If 20 people need contract analysis, custom AI at $300-800/month beats 20 Copilot licenses at $600/month - and it scales to 200 users at the same price.
Do you have AI engineering talent? Custom Azure AI requires Python developers who understand embeddings, prompt engineering, and orchestration frameworks. If your team is all Power Platform, start with Copilot Studio. If you have data scientists, Azure AI Foundry unlocks capabilities Copilot cannot match.
Is AI part of your product or just internal tooling? If AI is a feature your customers interact with, build custom. Copilot is designed for internal productivity, not external products. Azure AI Foundry gives you the APIs, model selection, and SLAs needed for customer-facing AI.
Does the base model understand your domain? Test it. Send GPT-4o 10 real questions from your domain. If it answers 8+ correctly, Copilot or a simple RAG pipeline is enough. If it struggles with your terminology, classification schemes, or output formats, you need fine-tuning - and that means Azure AI Foundry.

If you answered "Microsoft Graph," "500 users," "no AI engineers," "internal tooling," and "base model works" - buy Copilot. Do not overthink it.

If you answered "proprietary databases," "20 users," "we have data scientists," "customer-facing," and "needs fine-tuning" - build on Azure AI Foundry. The consumption model will save you money and the customization will differentiate your product.

If you answered a mix - and most enterprises do - you need the hybrid pattern. Copilot for the broad surface. Custom AI for the vertical depth. Copilot Studio to bridge the simple custom needs without spinning up a full Azure project.

The Adoption Reality Check

Here is what the analyst data actually says, stripped of vendor spin.

90%+ of Fortune 500 companies are using M365 Copilot. That sounds like universal adoption until you realize only ~15M paid seats exist globally out of ~400M+ potential M365 users. That is roughly 3.3% penetration. The awareness and budget gap is real.

80% of Fortune 500 are also using Azure AI Foundry. Enterprises are not choosing one path. They are running both in parallel.

The Gartner data is the most telling: most enterprises remain 12-18 months from scaled Copilot deployment. The top barriers are data readiness, ROI measurement, and regulatory fit. If your governance layer is not in place, scaling either path is risky. A law firm reduced 7-day contract drafts to 7 hours. But a 5,000-employee company is spending an additional $1.8M/year on M365 Copilot licenses, and finance teams are demanding clear proof of value.

The ROI is real for the right use cases. The waste is real when Copilot is deployed to users who never open it.

Where I Would Put the Money

Stop treating this as a binary choice. The right answer for most organizations above 200 employees is all three layers.

Deploy M365 Copilot to users who live in Outlook, Teams, and Word - your knowledge workers, managers, and executives. Measure adoption monthly. Cut licenses for users with less than 5 Copilot interactions per week.

Build custom AI on Azure OpenAI for the 2-3 domain-specific workflows where your competitive advantage lives. Start with GPT-4o-mini at $0.15/$0.60 per million tokens. Move to fine-tuned models only after you prove the base model cannot handle your domain.

Use Copilot Studio to fill the gaps - the internal FAQ bot, the HR policy agent, the IT helpdesk copilot. These are the use cases too custom for M365 Copilot but too simple for a full Azure AI Foundry project.

The organizations wasting money right now are the ones that bought 5,000 Copilot licenses because the sales rep showed a good demo. The organizations getting real value are the ones that mapped their AI use cases first, matched each one to the right layer, and measured the results. (For the governance foundation that makes mapping possible, start with environment strategy and flow inventory.)

Build where you differentiate. Buy where you do not.

Microsoft AI Builder Series

AI Certifications in 2026 - Which ones actually matter
Building AI on Azure - The architecture that works
Copilots vs Custom AI - When to build and when to buy

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.

Azure OpenAI PTU vs PAYG: The Real Break-Even Table

Alex Pechenizkiy — Sun, 23 Aug 2026 14:16:03 +0000

Every Azure OpenAI cost calculator on the internet tells you the same thing. PTU breaks even at roughly 150 to 200 million tokens per month for GPT-5. Below that volume, pay-as-you-go wins. Above, provisioned wins. Pick a number, sign the reservation, move on.

That math is wrong, or at least incomplete. Calculators assume 100% sustained utilization of the PTU deployment. Many production workloads run well below 100% sustained utilization; calibrate against your own telemetry. The gap between calculator math and reality is where, in the worked example below, a 15-PTU yearly reservation can cost more every month than the equivalent pay-as-you-go bill.

I pulled Microsoft's own published per-PTU throughput numbers, current 2026 pricing, and ran the actual table for GPT-5 and friends. Here is what you should see before signing anything.

TL;DR

GPT-5 Global PAYG is $1.25 per million input tokens and $10 per million output. GPT-5 Global PTU is roughly $1 per PTU per hour, $260 per PTU per month reserved, $221 per PTU per month on a yearly reservation. Minimum deployment is 15 PTUs (so $10,800 per month hourly, $3,900 monthly reserved, $3,315 yearly reserved). Each PTU gives you 4,750 input TPM, with one output token costing the same utilization as eight input tokens. At 100% utilization 24/7 on a typical 8K-in/1K-out workload, PAYG and yearly-reserved PTU break even at roughly $3,800/month. At 40% sustained utilization (closer to most production workloads), yearly PTU costs the same $3,315 while PAYG drops to $1,540. PTU is a great deal only when you can saturate the deployment and commit to a year. It is a trap when you cannot.

The break-even curve the calculators hide: at the utilization most production workloads actually run, PAYG stays cheaper than a yearly PTU reservation.

How PTU Billing Actually Works

A Provisioned Throughput Unit (PTU) is a unit of model processing capacity Microsoft sells you on a fixed hourly rate. You deploy a model in PTU mode, you reserve a number of PTUs, and you pay for those PTUs whether you use them or not. The model's TPM (tokens per minute) capacity is a function of how many PTUs you bought.

Three flavors exist:

Global Provisioned: cheapest, requests routed across global capacity
Data Zone Provisioned: middle tier, requests stay within a continental data zone
Regional Provisioned: most expensive, requests stay in a specific region

Global is what most architects pick. Data zone and regional cost more for compliance scenarios.

The minimum deployment is 15 PTUs for Global and Data Zone, scaling in increments of 5. Regional starts at 50 PTUs for most models. You cannot deploy "1 PTU of GPT-5 to test." The smallest GPT-5 PTU deployment is 15 PTUs.

Three billing modes exist for the PTUs you reserve:

Hourly: flexible, no commitment, expensive
Monthly reserved: substantial discount, 1-month commitment
Yearly reserved: biggest discount, 1-year commitment

Reservations are a financial construct, not a deployment construct. You buy reservations through the Azure portal Reservations page, and they automatically apply discount to any matching deployment in the same scope, region, and deployment type. Microsoft's own guidance:

Reservations guarantee a discounted price for the selected term. They don't reserve capacity on the service or guarantee that it will be available when a deployment is created. It's highly recommended that customers create deployments prior to purchasing a reservation to protect against over-purchasing.

So the safe order is: deploy first (paying hourly), confirm capacity is available, then buy the reservation. You will pay hourly for at least a few days while you are sizing.

GPT-5 Pricing as of April 2026

Confirmed pricing for the GPT-5 family on Azure OpenAI / Foundry:

Model	PAYG input ($/M)	PAYG output ($/M)	Cached input ($/M)	PTU hourly ($/PTU/hr)*	Min PTUs
gpt-5 (Global)	$1.25	$10	$0.13	~$1.00	15
gpt-5-mini	$0.25	$2	(same 90% cache)	~$1.00	15
gpt-5-nano	$0.05	$0.40	(same 90% cache)	~$1.00	15
gpt-5-pro	$15	$120	(same 90% cache)	varies	15
gpt-5.4	(varies)	(varies)	(varies)	varies	15

*PTU hourly rates vary by model and region. The Azure Pricing Calculator is the authoritative source. The $1/PTU/hour figure for GPT-5 Global is based on 2026 Azure OpenAI pricing for GPT-5 Global PTU, with monthly reservations landing near $260/PTU/month and yearly reservations near $221/PTU/month.

A handful of additional billing levers apply:

Cached input is roughly 10% of standard input rate (90% cache savings)
Batch API offers 50% off async workloads
Yearly reservation is roughly 70% off hourly PTU pricing
Monthly reservation is roughly 64% off hourly PTU pricing

The hourly to yearly-reserved gap is huge. A 15-PTU GPT-5 deployment costs $10,800/month hourly, $3,900/month on a monthly reservation, and $3,315/month on a yearly reservation. Same capacity, 70% cost difference, just from the term commitment.

Throughput Per PTU: The Number That Drives Everything

Microsoft publishes the input-TPM-per-PTU for each model. This is the number that determines how much PAYG-equivalent traffic your PTU deployment can absorb.

Model	Input TPM per PTU	Output:input ratio	Min PTUs (Global)
gpt-5	4,750	1 output = 8 input	15
gpt-5-mini	23,750	1 output = 8 input	15
gpt-5.4	2,400	1 output = 8 input (assumed)	15
gpt-5.3-codex / 5.2 / 5.2-codex	3,400	1 output = 8 input	15
gpt-5.1 / 5.1-codex	4,750	1 output = 8 input	15
gpt-4.1	3,000	1 output = 4 input	15
gpt-4.1-mini	14,900	1 output = 4 input	15
gpt-4.1-nano	59,400	1 output = 4 input	15
gpt-4o	2,500	1 output = 4 input	15
gpt-4o-mini	37,000	1 output = 4 input	15
o3	3,000	varies	15
o4-mini	5,400	varies	15
o1	230	varies	15

A few things jump out from this table:

gpt-5-nano would be a TPM monster except OpenAI did not release nano on Azure at the time of writing. gpt-4.1-nano remains the cheapest high-throughput option on PTU.
gpt-5.4 actually costs more in PTU terms than gpt-5, because its TPM per PTU is roughly half (2,400 vs 4,750). If your workload runs the same throughput on either model, you would need almost twice as many PTUs for gpt-5.4 to keep up.
o1 is brutally low at 230 TPM per PTU. Reasoning models have high per-request token costs and PTU sizing for them gets expensive fast.
Cached tokens are 100% deducted from utilization, meaning cache hits do not consume PTU capacity. That is a significant lever for prompt-caching-friendly workloads.

The output:input ratio matters because it determines how a typical mixed-shape request consumes utilization. For GPT-5, an output token "weighs" 8x an input token toward your TPM-per-PTU budget. So a request with 8K input and 1K output consumes 8,000 + (1,000 × 8) = 16,000 utilization tokens per minute against your 4,750-per-PTU budget.

The Real Break-Even Table for GPT-5

Run the math on a 15-PTU GPT-5 Global deployment, the smallest possible. Workload assumption: 8K input tokens, 1K output tokens per request.

Throughput ceiling: 15 PTUs × 4,750 input TPM = 71,250 effective input TPM. Each request consumes 16K weighted (8K input + 8 × 1K output). So the deployment caps at 71,250 / 16,000 = 4.45 requests per minute, or 6,400 requests per day, or roughly 192,000 requests per month at 100% utilization.

Token volume at 100% utilization: 192,000 requests × 8K input = 1.54B input tokens, plus 192,000 × 1K output = 192.5M output tokens.

PAYG cost at 100% utilization:

Input: 1.54B × $1.25/M = $1,925
Output: 192.5M × $10/M = $1,925
Total PAYG at 100%: ~$3,850/month

PTU costs for the same 15 PTUs:

Hourly: 15 × $1 × 720 = $10,800/month
Monthly reserved: 15 × $260 = $3,900/month
Yearly reserved: 15 × $221 = $3,315/month

Now run the table at different utilizations. Math derived from Microsoft published per-PTU TPM specs and 2026 Azure OpenAI list pricing. Calibrate against your own workload telemetry before committing.

Utilization	PAYG cost ($/mo)	PTU hourly	PTU monthly reserved	PTU yearly reserved	Best choice
100% (24/7 saturated)	$3,850	$10,800	$3,900	$3,315	Yearly reserved
80%	$3,080	$10,800	$3,900	$3,315	PAYG
60%	$2,310	$10,800	$3,900	$3,315	PAYG (large gap)
40% (typical production)	$1,540	$10,800	$3,900	$3,315	PAYG
20% (chatbot off-peak)	$770	$10,800	$3,900	$3,315	PAYG
10%	$385	$10,800	$3,900	$3,315	PAYG (10x gap)

The break-even utilization for yearly-reserved PTU vs PAYG is roughly 86% sustained. At 86% sustained 24/7 utilization, PAYG and yearly PTU cost the same. Below that, PAYG wins. Above that, PTU wins.

86% sustained utilization 24/7 is hard. It means you have ~6.4 GPT-5 requests per minute, every minute, every hour, every day, including 4am Sunday. Real production workloads almost never sustain that profile. They have peaks, valleys, seasonal patterns, weekends that drop to 10% of weekday traffic.

Hourly PTU never beats PAYG. Monthly reservation breaks even at roughly 100% utilization, which means it never beats PAYG in practice. The only PTU billing mode that actually wins on cost is the yearly reservation, and only when you can saturate the deployment.

The Three Scenarios Where PTU Actually Wins

PTU is a real bargain in three workloads. If yours fits one of these, sign the yearly reservation. If not, stay on PAYG.

1. High-volume customer-facing chatbot at scale.
A consumer chatbot serving thousands of concurrent users from peak waking hours can hit 70-90% sustained utilization on a properly-sized PTU deployment. The traffic shape is predictable, the load is steady-state, and the latency floor of PTU (versus PAYG queueing) matters for user experience. Yearly reservation is the right call.

2. Heavy batch processing pipelines.
A document processing pipeline that runs continuously through a queue of millions of documents can deliberately saturate a PTU deployment. You design the throughput to match the PTU ceiling. Each worker pulls from the queue at the rate the deployment can serve. Utilization stays at 95%+ by construction.

That said, the Batch API at 50% off PAYG often beats this anyway if the pipeline is not latency-sensitive. Always cost-compare batch + PAYG against PTU + saturate before signing.

3. Latency-critical real-time applications with predictable traffic.
PTU gives you guaranteed latency. PAYG can hit queueing delays at peak. A trading-floor copilot, an emergency dispatch assistant, a real-time fraud-decision system has business reasons to pay for guaranteed latency that the cost calculator does not capture. PTU wins when the cost of a slow response is bigger than the cost of unused capacity.

The Hybrid Pattern: PTU + PAYG Spillover

The architecture pattern most production teams should look at:

Deploy PTU sized for your baseline load (the floor of your traffic graph)
Configure PAYG spillover for traffic that exceeds the PTU capacity
Use Azure API Management or Azure Foundry routing to direct traffic to PTU first, then PAYG when PTU is saturated

This works because:

Baseline traffic gets the PTU price (cheap when saturated, predictable latency)
Spike traffic gets the PAYG price (no commitment, scales with load)
You only commit to the PTU size you can fully utilize 24/7
Cache lives on PTU side, free utilization, the most valuable cost lever you have

Sizing the PTU floor is the part most teams get wrong. Look at your historical per-minute traffic. Find the 30th percentile (yes, low). That is your PTU floor for cost-optimal hybrid. Going higher means you over-pay for unused PTU during quiet hours.

What Caching Actually Does to the Math

Cached input tokens are 100% deducted from PTU utilization and cost only ~10% of standard input rate on PAYG. This is the single biggest cost lever in the entire model.

If 70% of your input is cached (typical for chatbot with system prompt + RAG context):

PAYG effective input cost: 0.30 × $1.25 + 0.70 × $0.13 = $0.466/M (62% lower than no cache)
PTU throughput: 70% of input load is free, so the same PTU serves 3.3x more total requests

The PAYG-to-PTU break-even shifts dramatically when caching is in play. Workloads with heavy prefix caching can saturate a PTU deployment at much lower request volume, because each request consumes less utilization.

If you are running with 70% cache hits and 8K/1K request shape, the effective PAYG cost drops to ~$2,200/month at the same 192K request count. The PTU yearly reservation at $3,315/month never beats it unless utilization stays at 100%, which caching makes harder because each cached request takes longer to fill the PTU budget.

In other words: caching makes PAYG dramatically more competitive. Tune caching first, then revisit the PTU question.

Pre-Flight Checklist Before Buying a PTU Reservation

Run this before signing anything.

Pull historical TPM data from Azure Monitor. Look at the last 30 days, p50 / p90 / p99 of input + output TPM, day-of-week and hour-of-day patterns.
Calculate sustained utilization. Average TPM divided by deployment ceiling. If the answer is below 70%, you do not want PTU.
Map workload type. Is it customer-facing latency-critical? Heavy batch? Variable RAG agent? PTU wins for the first two, loses for the third.
Test the Batch API at 50% off for any async work. If batch covers your jobs, PTU is rarely the right answer.
Estimate cache hit rate. If you can hit 50%+ prefix cache hits, run the math with cached pricing - PAYG looks much better.
Check capacity availability. Quota does not equal capacity. Deploy first, confirm capacity, then reserve. Microsoft says it explicitly.
Pick the right reservation term. Hourly is for benchmarks. Monthly reservation rarely beats PAYG. Yearly reservation is the real PTU value, but only for workloads you are confident will run for a year.
Plan for spillover. Configure PAYG spillover before you go live, so spike traffic does not get queued or rejected.

How This Generalizes Beyond GPT-5

The same math applies to GPT-5-mini, gpt-4.1, gpt-4o, and the rest of the lineup. Different TPM-per-PTU and different PAYG rates give different break-even points, but the structural answer is the same:

Hourly PTU never wins on cost (use it for benchmarks only)
Monthly reservation rarely wins (60-65% break-even utilization, possible in narrow cases)
Yearly reservation wins at high sustained utilization (depends on saturation; see the break-even math above)

For mini models like gpt-4o-mini at 37,000 TPM per PTU, the throughput per dollar is much higher, so PTU break-even shifts. But the same utilization caveat applies. You still need to actually use the capacity.

If you want to skip the spreadsheet, the rule of thumb that holds for GPT-5 family:

If your sustained utilization is below 70%, stay on PAYG with caching. If you can saturate above 85% on a yearly reservation, PTU wins; the magnitude depends on sustained utilization (see the break-even math above). Anywhere in between is a coin flip and depends on workload-specific factors.

What This Tells You About Azure AI Cost Architecture

Two takeaways for architects designing AI cost models in 2026.

First: cost calculators are sales tools. They optimize for "PTU sounds good" not "your actual workload." Every published break-even comparison assumes 100% utilization because that is the chart that sells reservations. Build your own model with your own traffic data, or you are agreeing to the optimistic case.

Second: caching, batching, and routing matter more than provisioning mode. Most teams worry about PTU vs PAYG for weeks before they have implemented prefix caching. Implement caching first. Implement batch routing for async work. Then look at the residual cost shape and decide whether PTU adds value. In many cases, the answer becomes "no" once caching is in.

The senior architect's role here is to push back on the procurement-first answer. Microsoft sells reservations because they are good for Microsoft's revenue forecasting. Sometimes they are good for your cost picture. Often they are not. The data you need to know which is in your Azure Monitor logs, not in the calculator.

AI Governance Framework for Microsoft Enterprises: Operational Controls That Ship

Alex Pechenizkiy — Sat, 22 Aug 2026 14:13:52 +0000

Most AI governance frameworks are PDFs. Two hundred pages of principles, three pages of policy, zero working controls. The IT director gets handed the document, schedules a workshop to "operationalize the framework," and six months later the only thing that has shipped is a slide deck that mentions "responsible AI" eleven times.

This is not what governance looks like. Governance, when it works, is a set of automatic gates wired into the systems that already run the business. It is the agent identity that gets revoked when an employee leaves. The DLP policy that blocks the high-risk connector before the user finishes the workflow. The Foundry trace that tells the audit team which tenant invoked which model with which prompt at 2am. It is not a slide. It is a control.

Microsoft sells most of the tools you need: Purview for data governance, Entra for agent identity, Foundry for observability, Agent Governance Toolkit for runtime compliance grading. What Microsoft does not sell is the framework that ties them together. That gap is where most AI governance programs fail, and it is what this article fixes.

TL;DR

A working AI governance program for Microsoft enterprises has six operational components: AI inventory + shadow AI discovery, AI Bill of Materials, risk classification with approval gates, data residency + access controls, audit + observability, and incident response. Microsoft Purview + Entra + Foundry + Agent Governance Toolkit cover most of the tooling. ISO 42001 (which Microsoft Azure AI Foundry, Security Copilot, and M365 Copilot have all certified against) is your scope. EU AI Act high-risk obligations land August 2026, so implement now and get audited next. This article gives you the framework, the Microsoft-tool mapping, and a 90-day implementation plan.

The six operational components, each mapped to the Microsoft tool that delivers it. Governance is controls wired into running systems, not a slide deck.

Why Most AI Governance Programs Fail

Three failure modes account for almost every stalled AI governance program I have audited.

Failure mode 1: Policy without controls. The legal team writes a 40-page Responsible AI policy. It says employees must use AI ethically, must not feed customer data to non-approved models, must classify AI risk before deployment. None of this is enforced anywhere except in the document itself. Six months later, the audit reveals 200 unsanctioned ChatGPT subscriptions on company cards and a Power Automate flow that emails customer financial data to an unapproved Anthropic API endpoint. The policy did not lose. The policy was never connected to anything.

Failure mode 2: Controls without ownership. IT enables Microsoft Purview, configures DLP policies on the M365 Copilot rollout, and sets up Foundry observability. Nobody owns the alerts. The Purview audit log fills up with sensitive data classifications nobody reviews. The Foundry trace flags a prompt injection attempt at 3am and the alert goes to a team mailbox that nobody monitors. Tools exist. Operations do not.

Failure mode 3: The framework is too big to start. The team reads NIST AI RMF, Big-4 advisory whitepapers, and the EU AI Act and tries to build a single program covering all of them. Two quarters in, scope creep has the program covering 47 controls, the implementation roadmap is 18 months, and nothing has shipped. Better to ship six controls in 90 days and add the rest in increments.

The fix for all three is operational governance: small, owned, automatic. Six components, mapped to the Microsoft tools you already have or can buy, each with a named owner and a measurable signal.

The Six Components of a Working Framework

Component	What it does	Microsoft tool that delivers it	Owner role
1. AI Inventory + Shadow AI Discovery	Knows every AI system in use: sanctioned and unsanctioned	Purview Data Map + Entra Workload Identity + Defender for Cloud Apps	IT Director / CoE Lead
2. AI Bill of Materials (AIBoM)	For each AI system, lists the model, training data, prompts, dependencies, and evaluation results	Foundry model catalog + custom AIBoM templates	AI Architect / Lead Engineer
3. Risk Classification + Approval Gates	Routes AI initiatives to the right governance path: self-serve, IT-approved, board-approved	Purview Risk + Power Platform managed environments + Entra access reviews	Risk Officer / Compliance Lead
4. Data Residency + Access Controls	Ensures AI sees only the data it should, in the region it should	Purview DLP + Sensitivity Labels + Copilot data grounding controls + Entra Conditional Access	Compliance / Privacy Lead
5. Audit + Observability	Captures every AI inference, tool call, and decision for review	Foundry observability + Purview Audit + Sentinel for AI	Security Operations / SOC
6. Incident Response for AI	Red team, jailbreak detection, kill switch when an AI system goes wrong	Microsoft Agent Governance Toolkit + Foundry safety filters + Sentinel playbooks	Security Incident Lead

Six components. Six owners. Each has a Microsoft product that does most of the work. That is the framework.

The rest of this article walks through each component with what it actually means, what to configure, and what the failure mode looks like when you skip it.

Component 1: AI Inventory + Shadow AI Discovery

You cannot govern what you cannot see. Most enterprises think they have 5 to 10 AI systems. The inventory reveals 30 to 200, depending on size.

What to build:

A central registry of every sanctioned AI system: model, owner, business purpose, data classification, deployment environment, last review date.
Active discovery for shadow AI: Defender for Cloud Apps to detect SaaS AI tools (ChatGPT, Claude direct, Perplexity, etc.). Power Platform CoE Toolkit inventory for AI features inside flows and apps. Entra Workload Identity inventory for service principals making OpenAI / Anthropic API calls.
A monthly "drift report": new shadow AI detected, sanctioned systems that drifted out of compliance, decommissioned systems that still hold credentials.

Microsoft tools:

Microsoft Purview Data Map for data flow visibility (which datasets are reaching which AI systems).
Defender for Cloud Apps for SaaS AI discovery (the unsanctioned consumer AI side).
Entra Workload Identity + Conditional Access for workload identities for service-principal AI access.
Power Platform CoE Toolkit if Power Platform AI is in scope.

The failure mode if you skip this: Six months in, the SOC discovers a Power Automate flow that has been emailing customer PII to a free-tier Anthropic API endpoint for the last 90 days. Nobody knew it existed. There was no policy to violate because there was no inventory to register against.

Component 2: AI Bill of Materials

Borrowed from the SBOM (Software Bill of Materials) concept, the AIBoM is a per-AI-system disclosure of what is inside.

What an AIBoM contains:

Field	Example
System name	Customer Support Triage Copilot
Owner	Customer Operations Director
Model(s) used	Azure OpenAI gpt-5, Claude Sonnet 4.6 (fallback)
Training data sources	None (inference only); RAG corpus = 12,400 KB articles from /support/kb
System prompt	Linked to repo path
Evaluation results	Foundry agent evaluation: groundedness 0.91, harm under 0.5%, last run 2026-04-20
Risk class	Medium (customer-facing, no PII exposure, no financial outputs)
Compliance scope	ISO 42001 §6.1.4 risk treatment; EU AI Act limited-risk transparency obligation
Last review	2026-04-15

Microsoft tools:

Azure AI Foundry model catalog as the model-registry source of truth.
Foundry evaluation runs as the recurring quality signal.
GitHub or Azure DevOps repos for system prompt versioning and the AIBoM YAML/JSON itself.
Purview Sensitivity Labels applied to the AIBoM so it is audit-discoverable.

The failure mode if you skip this: Auditor asks "which model does the support triage agent use, and when did you last evaluate it for harm?" Three engineers and the operations director cannot give a consistent answer. Six weeks of cleanup work follows.

Component 3: Risk Classification + Approval Gates

Not every AI initiative needs board approval. Most need almost no approval. The framework has to route initiatives to the right governance path or it becomes a bottleneck nobody respects.

A working three-tier classification:

Risk class	Examples	Approval path	Controls required
Low	Internal productivity (M365 Copilot for individuals), draft generation, code completion, internal chat over public docs	Self-serve with guardrails (DLP, conditional access, license assignment)	Purview DLP, M365 Copilot grounding controls, no PII flows
Medium	Customer-facing agents on internal data, RAG over confidential corpus, agent-to-agent workflows inside the tenant	IT review + AIBoM + Foundry evaluation gates	Foundry agent evaluation thresholds, Sentinel monitoring, named owner
High	Decisions affecting customers (credit, hiring, healthcare), agent-to-external-system actions, AI in regulated workflows	Risk Officer + Legal + Compliance review; board notification for new high-risk	Full ISO 42001 Annex A controls, EU AI Act high-risk obligations, red team + incident response plan

The point of the tiering is to make low-risk initiatives frictionless and high-risk initiatives genuinely reviewed. A flat policy that requires a 40-page review for every Copilot use case loses to shadow IT. A flat policy that requires no review for high-risk credit decisions loses to the regulator.

Microsoft tools:

Power Platform managed environments to enforce DLP and connector limits per environment tier.
Entra Conditional Access + access reviews for the service principals running medium and high-risk agents.
Purview Risk Management for the workflow that escalates an initiative from one tier to the next.

Component 4: Data Residency + Access Controls

AI sees what you let it see. Two failure modes here: too restrictive (Copilot is enabled but it cannot find anything useful, adoption stalls) and too permissive (Copilot answers questions using HR salary data the asker should not see).

What to configure:

Sensitivity labels on every dataset, applied automatically via Purview classification rules.
M365 Copilot grounding controls: explicitly designate SharePoint sites, Teams, and M365 groups that Copilot can or cannot ground responses on. (Microsoft expanded this control significantly in 2026.)
Purview DLP policies on Power Platform connectors and Foundry agents, blocking high-sensitivity data from low-tier AI systems.
Region pinning for high-residency workloads: Foundry deployments restricted to the regions your contracts permit. (Note: Claude on Foundry only deploys in East US 2 and Sweden Central. See Claude on Azure: The Marketplace Billing Trap for why this matters for governance scope.)

Microsoft tools:

Purview Information Protection (sensitivity labels, classification, DLP).
Microsoft 365 Copilot data grounding controls.
Entra Conditional Access with location and device conditions for AI workload identities.

Component 5: Audit + Observability

Without audit logs, an AI program cannot answer the basic governance question: "what did the AI do, and when, for whom, with what data?"

What to capture, in three layers:

Layer	What it logs	Microsoft tool
Application	User prompt, response, tool calls invoked, latency	Foundry observability, Application Insights
Data	What sources the model accessed, which sensitivity labels were touched	Purview Audit, Purview eDiscovery
Identity	Which user or service principal invoked which model, with what conditional access state	Entra sign-in logs, Defender for Identity

The cross-cutting tool: Microsoft Sentinel for AI, which correlates the three layers and runs detection rules. The OWASP Top 10 for Agentic Applications (published 2026) maps directly into Sentinel content packs as detection logic.

Concrete signals to alert on:

Prompt-injection patterns hitting a customer-facing agent
Output containing data outside the user's sensitivity label scope
Service principal making OpenAI API calls outside business hours from non-corporate IP
Agent tool-call rate spikes (potential runaway loop)
Foundry evaluation drift (groundedness drops below threshold week-over-week)

The failure mode if you skip this: Auditor asks "show me everything Copilot did with customer financial data in Q3." You have nothing. Or you have raw logs in 14 different systems and no way to correlate them.

Component 6: Incident Response for AI

When an AI system goes wrong, the response cannot be "we will look into it on Monday." Operational governance includes a tested response plan.

What to have ready:

Red team scope: monthly or quarterly adversarial testing of medium and high-risk AI systems. Microsoft's PyRIT (open source) automates a lot of this.
Jailbreak detection: Foundry safety filters at the model level + Sentinel correlation rules at the audit level.
Kill switch: a documented procedure to disable an AI system in under 15 minutes. For Foundry agents, this is a deployment-state change. For Copilot, it is a license assignment removal. For Power Platform AI features, it is a DLP policy promotion to "block."
Communication template: who gets told (legal, customer team, regulator if EU AI Act high-risk), in what order, with what severity classification.

Microsoft tools:

Microsoft Agent Governance Toolkit (open source, April 2026) for runtime security and automated compliance grading.
PyRIT for adversarial testing.
Foundry safety filters + Sentinel playbooks for detect + respond.

ISO 42001: Your Scope, Not Your Plan

ISO/IEC 42001:2023 is the world's first AI management system standard. Microsoft Azure AI Foundry Models, Microsoft Security Copilot, and M365 Copilot have all certified against it. The standard does not give you a framework. It gives you a measurable scope.

What ISO 42001 requires (loosely):

A documented AI management system (the six components above are most of it)
Risk treatment based on AI-specific risks (the OWASP Top 10 for Agentic Applications maps closely)
Continuous improvement loop (the audit + observability layer feeds this)
Senior leadership accountability (the risk classification + approval-gates component, escalated)

Why it matters even if you do not certify: EU AI Act high-risk obligations take effect August 2026. Customers will increasingly require ISO 42001 certification (or equivalent evidence) from vendors as a procurement gate. If you are selling AI-enabled software into regulated industries, you will be asked. Implementing the framework now means you are 70% of the way to certification when you decide to pursue it.

Microsoft's certification of its own AI products is a meaningful signal. It also means that when you build on top of Foundry, Copilot, or Security Copilot, you can inherit some of the controls. Your AIBoM should explicitly note where you are leveraging Microsoft's certified controls vs implementing your own.

EU AI Act: What Changes August 2026

The EU AI Act is in force, and high-risk AI obligations take effect August 2026. If you operate in the EU, sell to EU customers, or process EU residents' data with AI, this matters.

What "high-risk" means in practice:

AI used in employment decisions (hiring, performance, dismissal)
AI used in essential services (credit, insurance, education)
AI used in critical infrastructure
AI used in law enforcement, migration, or judicial proceedings
Biometric identification systems

What high-risk obligations require (selected):

Risk management system across the AI system lifecycle
Data governance covering training data quality and bias
Technical documentation (read: AIBoM)
Logging that allows traceability of AI decisions
Human oversight measures
Accuracy, robustness, and cybersecurity controls
Conformity assessment before placing on the market

If your AI inventory has any high-risk systems, the August 2026 deadline is your forcing function. The six-component framework above is the implementation. Microsoft Agent Governance Toolkit explicitly maps to EU AI Act, HIPAA, and SOC2 in its compliance grading.

A 90-Day Implementation Plan

Days	Focus	Deliverable
1-15	Inventory	Working AI inventory (sanctioned + shadow), Defender for Cloud Apps deployed, Purview Data Map mapping confirmed
16-30	AIBoM	Template defined, top 10 highest-risk AI systems documented, repos established
31-45	Risk classification	Three-tier policy approved, approval workflows wired into Power Platform managed environments + Entra access reviews
46-60	Data + access	Sensitivity labels rolled, Copilot grounding controls configured, DLP policies promoted
61-75	Observability	Foundry observability + Purview Audit + Sentinel detection content packs deployed and named owners assigned
76-90	Incident response	Red team run on top 3 systems, kill switch tested, communication template approved

This is aggressive. A realistic enterprise lands in 120-180 days for the first cycle, then accelerates as the team learns the toolchain. The point of the 90-day plan is to set the direction. Even partial completion in 90 days beats a complete framework on paper that nobody implements.

What This Tells You About AI Governance Architecture

Three takeaways for the IT director planning a 2026 governance program.

First: stop looking for the perfect framework. NIST AI RMF, ISO 42001, EU AI Act, and Big-4 advisory frameworks all converge on roughly the same operational components. Pick one (ISO 42001 if you might certify, NIST AI RMF if you operate under US federal scope), implement the six components against it, iterate. The differences between frameworks are smaller than the gap between "policy on paper" and "controls in production."

Second: Microsoft's tooling is good enough to start. Purview + Entra + Foundry + Agent Governance Toolkit covers 80% of the controls a typical enterprise needs. The remaining 20% (deep model evaluation, specialized red-teaming, multi-cloud AI inventory) often requires third-party tools, but you do not need them on day one. Implement what Microsoft ships, then decide where the gaps actually hurt.

Third: governance accelerates AI adoption, it does not slow it down. The teams I have seen succeed with M365 Copilot at scale all had a working governance program before the rollout. The teams that stalled were the ones treating governance as a Q4 afterthought. Counterintuitively, when employees know there is a clear approval path for medium-risk AI use, they bring more ideas forward, not fewer. Shadow AI thrives in ambiguity.

Shadow AI Governance for Microsoft Enterprises: Discovery to Control

Alex Pechenizkiy — Fri, 21 Aug 2026 14:26:36 +0000

Almost every enterprise has shadow AI. The numbers are not subtle: 98% of organizations have employees using unsanctioned AI tools. More than 80% of workers admit to using unapproved AI at work. About 45% do not tell their employer. The kicker: 31% of IT teams cannot detect unauthorized AI in real time, and only 30% of organizations have full visibility into employee AI usage.

The financial exposure is real. The average cost of a shadow AI data breach has reached $4.2M. 52% of firms say shadow AI complicates regulatory compliance, and 44% have already faced compliance violations from unauthorized AI use.

The C-suite is not as alarmed as the SOC. 69% of executives report being comfortable with shadow AI use, prioritizing speed over privacy. That gap, between executive tolerance and operational risk, is exactly where shadow AI compounds. Until the breach.

This article is the operational playbook to fix it on a Microsoft stack. Discovery in 30 days. Three-tier graduation. Microsoft tools you already own (Defender for Cloud Apps, Purview, Entra, Power Platform CoE Toolkit). Sentinel detection rules to catch new shadow AI as it emerges.

It is the operational deep-dive on Component 1 of the framework in AI Governance Framework for Microsoft Enterprises. Read that one first if you want the full six-component picture.

TL;DR

Shadow AI lives in four distinct layers, each with a different Microsoft tool that finds it: SaaS AI (Defender for Cloud Apps, 31,000-app catalog), browser extensions (Edge management + DLP), Power Platform AI features (CoE Toolkit), and service principal API calls to OpenAI / Anthropic / etc. (Entra Workload ID + Conditional Access). A 30-day sprint produces a baseline inventory. The graduation framework routes findings into three tiers: block (high risk), sanction with controls (medium risk), or self-serve with guardrails (low risk). Block-everything fails because it pushes shadow AI to personal devices. The win is making the sanctioned path easier than the shadow path.

The four layers shadow AI hides in, each with the Microsoft tool that surfaces it. The win is making the sanctioned path easier than the shadow path.

Why Shadow AI Is Different From Shadow IT

Shadow IT is a known governance problem. Marketing buys a SaaS tool, processes customer data through it, the security team finds out at the next audit. The pattern is familiar and the controls are mature: SaaS discovery, IT approval workflows, vendor risk assessment.

Shadow AI looks similar on the surface and behaves differently in three important ways.

It moves through the browser, not the credit card. Most shadow AI is consumed via free-tier ChatGPT, Claude, Perplexity, or browser extensions. There is no SaaS subscription to detect via expense reports. The user opens a tab, pastes data, gets an answer, closes the tab. No procurement signal.

It happens fast. A marketing analyst can paste a customer list into ChatGPT and get a segmentation analysis in 90 seconds. The "should we use AI for this" conversation never happens. By the time governance asks, the analysis is already in a deck.

It is celebrated by leadership. Shadow IT was usually a nuisance. Shadow AI is often praised as "innovation" by executives who do not understand that the marketing analyst just trained an external model on customer data. 69% of C-suite is comfortable with it, the surveys say. The CISO is less comfortable.

The Microsoft tooling story has caught up to this reality, but the operational adoption has not. Most organizations have the licenses for Defender for Cloud Apps, Purview, Entra, and the Power Platform CoE Toolkit. Far fewer have the policies, alerts, and named owners that make those tools work.

The Four Layers Shadow AI Lives In

Every shadow AI source falls into one of four layers. Each has a different discovery method and a different Microsoft tool that handles it.

Layer	Examples	Microsoft tool that finds it	Detection signal
1. SaaS AI	ChatGPT, Claude direct, Perplexity, Mistral chat, Hugging Face Spaces, Replit AI	Defender for Cloud Apps (31,000-app catalog, 90+ risk factors)	Network traffic from corporate endpoints to known AI domains
2. Browser AI Extensions	ChatGPT extensions, Copilot extensions, Notion AI, Grammarly AI, browser-based agents	Edge for Business management + DLP browser endpoint policies	Installed extension inventory, DLP detection of paste-to-AI
3. Power Platform / Copilot Studio AI	Maker-built Copilot Studio agents, AI Builder usage in Power Apps, GPT actions in Power Automate	Power Platform CoE Toolkit (admin center inventory + governance dashboards)	AI Builder credit consumption, Copilot Studio agent inventory, AI-tagged connector usage
4. Service Principal API Calls	Developer service principals calling OpenAI / Anthropic / Cohere APIs from internal apps	Entra Workload Identity + Conditional Access for workload identities + Defender for Cloud (cloud-native)	Outbound API calls from Azure/M365 service principals to AI provider endpoints

Most enterprises focus on layer 1 (SaaS AI) and ignore the other three. Layer 4 is often the highest-risk because it is developers building AI features into internal tools without oversight. Layer 3 is the fastest-growing because Microsoft is actively pushing Copilot Studio and AI Builder to citizen developers.

A complete shadow AI inventory covers all four layers. A SaaS-only inventory misses 60-70% of the actual exposure.

The 30-Day Discovery Sprint

A working baseline inventory comes from a focused 30-day discovery effort. This is not "boil the ocean." It is targeted instrumentation per layer.

Week 1: SaaS AI discovery (layer 1)

Action: Stand up Defender for Cloud Apps cloud discovery if not already. Configure log collectors against your firewall and proxy logs. Filter the discovered apps to the AI category.

What you get: A ranked list of every AI service accessed from corporate networks, with user count, traffic volume, and risk score from Microsoft's 90-factor catalog.

Owner: SOC analyst + Information Security manager.

Common discovery: 50-200 distinct AI services accessed per month, with 5-10 services accounting for 80% of usage. The top of the list is almost always ChatGPT, then a long tail of niche tools.

Week 2: Browser AI discovery (layer 2)

Action: Inventory installed extensions across managed Edge browsers via Edge for Business. Configure DLP browser endpoint policies to flag paste events into AI-tagged domains. Cross-reference with Defender for Cloud Apps.

What you get: Installed-extension inventory by user, plus a stream of paste-into-AI events with source app and content sensitivity classification.

Owner: Endpoint security team + Information Protection lead.

Common discovery: ChatGPT and Copilot extensions installed by 30-50% of knowledge workers. Grammarly AI nearly universal. Niche extensions (Jasper, Otter.ai meeting capture) clustered in marketing and sales.

Week 3: Power Platform AI discovery (layer 3)

Action: Run the Power Platform CoE Toolkit if not already deployed. Filter the maker inventory for AI Builder usage, Copilot Studio agents, and AI-tagged connectors. Pull the AI consumption credit report.

What you get: Inventory of every Copilot Studio agent, every AI Builder model, every flow using GPT actions, with maker, environment, and usage metrics.

Owner: Power Platform CoE lead + IT Director.

Common discovery: 10-50 maker-built Copilot Studio agents per enterprise (most undocumented), AI Builder model sprawl across the default environment, GPT actions embedded in flows that nobody knows about.

Week 4: Service principal AI discovery (layer 4)

Action: Pull Entra sign-in logs for workload identities. Filter for outbound calls to OpenAI, Anthropic, Cohere, Azure OpenAI (cross-tenant), and other AI provider endpoints. Cross-reference with Conditional Access policies. Tag service principals that lack a documented owner.

What you get: A ranked list of service principals making AI API calls, by call volume and provider, with named or orphaned ownership.

Owner: Identity governance lead + Application security.

Common discovery: 5-20 service principals making OpenAI / Anthropic API calls. About a third are orphaned (the developer left, the credentials persist). About a fifth use personal API keys hardcoded in app config (the worst pattern).

After 30 days you have a baseline inventory across all four layers. The output is a single dashboard or registry where every shadow AI source is logged with: layer, owner (or "orphan"), risk classification, and recommended action.

From Discovery to Control: The Three-Tier Graduation Framework

Discovery alone does not change anything. The framework that turns the inventory into action is a three-tier graduation policy. Every shadow AI source ends up in one of three buckets.

Tier	What goes here	Action	Microsoft control
Sanction with self-serve guardrails	Low-risk uses: drafting, summarization over public information, code completion, internal search over non-confidential corpus	Approve. Onboard to M365 Copilot or other sanctioned alternative. Document in inventory.	M365 Copilot rollout + Purview DLP for paste-blocking on confidential data
Sanction with controls	Medium-risk uses: customer-facing assistants, RAG over confidential data, agent-to-system actions, AI-augmented analytics with PII	Move to a sanctioned platform (Foundry, Copilot Studio with governance). AIBoM. Owner. Evaluation gates. Sentinel monitoring.	Foundry observability + AIBoM templates + Power Platform managed environments
Block + provide alternative	High-risk uses: regulated decisions (credit, hiring, healthcare), processing of restricted data, agent-to-external-systems with external write access	Block at the network and DLP layer. Route the user to the sanctioned alternative.	Defender for Cloud Apps app-blocking + Purview DLP enforce + Entra Conditional Access deny

The mistake most programs make is starting with tier 3 ("block ChatGPT") as the default. Block-everything fails for one specific reason: it pushes shadow AI from corporate endpoints to personal phones, where you cannot see it at all. Better to make the sanctioned path easier than the shadow path.

That means M365 Copilot rolled out with low friction (no procurement gate for individual use), Foundry with templates for common business scenarios, Copilot Studio with starter kits for citizen makers. Combine the carrot (sanctioned tools that actually work) with the stick (DLP blocks on confidential data going to unsanctioned destinations).

Sentinel Detection Rules: The Ongoing Layer

The 30-day sprint produces a baseline. Shadow AI keeps emerging. Detection content packs in Microsoft Sentinel are the ongoing instrumentation.

Five detection rules every Microsoft tenant should have:

Spike in outbound traffic to unsanctioned AI domains. Catches the "marketing analyst pastes the customer list into a brand-new tool" pattern. Threshold: 50%+ increase in week-over-week volume.
Paste of high-sensitivity content into AI-tagged browser tabs. From the DLP browser endpoint policy. Severity scaled to sensitivity label.
New Copilot Studio agent created in default environment. Power Platform admin signal. Auto-routes to CoE for review.
Service principal making first call to AI provider endpoint. From Entra workload identity sign-in logs. Triggers ownership confirmation flow.
AI Builder consumption spike. From Power Platform admin metering. Catches a maker building an AI feature that scales unexpectedly.

These five rules cover most net-new shadow AI emergence in the four layers. Each rule should route to a named owner with a 24-48h SLA, not a team mailbox.

What NOT to Do

Three failure modes that kill shadow AI programs and how to avoid them.

Failure 1: Block-everything by default. The CISO announces "no AI tools without IT approval" and blocks ChatGPT, Claude, and Perplexity at the firewall on Friday. By Monday, half the marketing team is using their personal phones to paste the same customer data into the same tools. You see less, the risk is the same, the relationship with the business is worse. Ship sanctioned alternatives FIRST.

Failure 2: Treat shadow AI as a one-time inventory project. A three-month consultant engagement produces a beautiful inventory PDF. Six months later it is stale because nobody owns the ongoing detection. Make discovery a recurring process with named owners and automated alerts, not a project with a deliverable.

Failure 3: Expose the inventory to the wrong audience too soon. The full shadow AI inventory contains business-sensitive information about which teams are using which tools. If you publish it broadly before you have a remediation plan, the result is internal political fallout instead of governance progress. Share with leadership, security, and the CoE first. Build the graduation plan. Then communicate to affected teams with the path forward, not just the violations.

Connecting Back to the Six-Component Framework

This article is operational depth on Component 1 of the AI Governance Framework for Microsoft Enterprises. Component 1 (AI Inventory + Shadow AI Discovery) is the foundation: you cannot govern what you cannot see.

The other five components depend on it:

Component 2 (AIBoM) documents what is in your inventory; it depends on the inventory existing.
Component 3 (Risk Classification + Approval Gates) routes new initiatives, but the policy only works if discovered shadow AI is also routed through the same gates.
Component 4 (Data Residency + Access Controls) enforces what should and should not flow to AI; it needs the inventory to know what is in scope.
Component 5 (Audit + Observability) captures every AI inference; the SaaS-AI detection layer is most of that observability.
Component 6 (Incident Response for AI) activates on detection signals; the same Sentinel rules described above are where most AI incidents fire first.

In other words, fixing shadow AI is the cheapest 30 days you can spend on AI governance because it accelerates everything downstream.

A 90-Day Goal

If you only adopt one specific outcome from this article, make it this:

Within 90 days, every AI usage in your tenant is either in the sanctioned-with-self-serve tier (M365 Copilot, approved Foundry agents, Copilot Studio agents in managed environments) or it is detected within 24 hours.

That goal is binary, measurable, and rare. Most enterprises today operate at "detected within a quarter, if at all." Hitting 24-hour detection moves the program from compliance theatre to operational governance.

The 30-day discovery sprint is the first third. The graduation framework and Sentinel detection rules are the next two-thirds. Microsoft Purview, Defender for Cloud Apps, Entra, and the Power Platform CoE Toolkit do most of the heavy lifting if you turn them on, configure them, and assign named owners.