# Three ways to deploy: from air-gap to cloud > Most firms think sovereign AI = on-prem or nothing. That is a false binary. There are three tracks, and most regulated SMEs will end up on Track B. - URL: https://artcode.software/blog/three-deployment-tracks-regulated-sme - Author: Artur Kluz, Founder, AI architect (https://www.linkedin.com/in/arturkluz/) - Published: 2026-05-19 - Updated: 2026-10-18 - Language: en - Tags: sovereign-ai, deployment, azure-openai, ai-act, compliance - Publisher: ArtCode Software (https://artcode.software) Most firms I talk to think sovereign AI is a binary choice: on-prem or nothing. You either buy a GPU server and run open-weights models in your own rack, or you give up on compliance entirely and pipe everything to a US cloud API. That frame is wrong. It is also expensive. There are three deployment tracks, not two. The second track is where most regulated SMEs will actually land. This post maps all three, with a deep dive into the track most firms overlook entirely: Azure OpenAI with EU data boundary. **In short.** Deploying AI in a regulated SME is not a choice between on-prem and a US cloud but between three tracks: A (full sovereignty, air-gap), B1 (hybrid) and B2 (cloud API with an EU data boundary, for example Azure OpenAI). The data class picks the track, so the first step is data classification and a deployment map. ## The false binary "Cloud = non-compliant" versus "on-prem = expensive" is the wrong conversation. The right conversation starts with a simpler question: which data class are we talking about? Your marketing team's blog draft does not need the same deployment boundary as your client's source code. Your public-facing chatbot answering questions from a public FAQ does not need the same boundary as an internal tool that reads client contracts. Different data classes, different deployment tracks, different cost profiles. Once you split the problem by data class, the binary collapses. Most firms have at least three distinct classes. Most firms will use at least two of the tracks below. ## Track A: Full sovereign (air-gap) This is the track everyone thinks of first. On-prem hardware, open-weights model (Qwen, Llama, Mistral), inference served through vLLM on your own GPU. Zero egress. Full audit surface. I covered the hardware specifics in the [April coding model post](/blog/open-weights-coding-apr-2026). The short version: a single NVIDIA RTX PRO 5000 Blackwell 48 GB workstation runs Qwen3-Coder-30B-A3B at AWQ 4-bit, 45-60 tok/s sustained at 64 K context. The CapEx is roughly 40-60k PLN for the machine. OpEx is near-zero beyond electricity and cooling - no usage-based bills from a third party, no vendor API keys, no usage dashboards that someone else controls. Track A is the right answer when the data class is genuinely sensitive. Think FinTech source code covered by KNF Rekomendacja D. Medical records under RODO. Legal documents under tajemnica adwokacka. Client grant applications. M&A due diligence materials. Any data where "it left the building" is an unacceptable sentence in a compliance conversation. The trade-off is real. Track A gives you the highest control and the fullest compliance surface. DORA Article 28? Covered, because there is no third-party processor. AI Act Article 12 logging? You own the logs, the schema, the retention. Audit trail from prompt to response? Deterministic hash of every prompt template, every tool call, every response. It also gives you the highest upfront cost and requires in-house ops capability. Someone needs to maintain the machine, update the vLLM version, rotate the model weights when a new checkpoint ships. For a five-person fintech, that "someone" is often the CTO wearing a second hat. ## Track B1: Hybrid Track B1 splits the workload. Sensitive inference stays on-prem (Track A). Non-sensitive tasks go to a cloud API (Track B2, below). The key skill here is not infrastructure. It is data classification. You need a clear, written answer to the question: which prompts contain regulated data and which do not? Concrete example. A Warsaw software house building integrations for a bank spółdzielczy has three distinct workloads: (1) code generation against client-specific integration code, which touches the client's internal API schemas and test fixtures with production-like data; (2) internal HR document drafting, which contains employee PII; (3) marketing copy and public blog content for their own website. Workload 1 goes Track A. Workload 2 goes Track A or B1 depending on the PII sensitivity and your HR system's existing data boundary. Workload 3 goes Track B2, because the worst-case compliance exposure on public marketing copy is approximately zero. The cost profile is moderate: some CapEx for the on-prem machine plus moderate OpEx for the cloud API usage. The compliance profile requires two separate policies, clear data-flow diagrams showing which data hits which track, and ideally a decision matrix that your team can apply without calling the CTO every time. ## Track B2: Cloud API with EU data boundary (Azure OpenAI deep dive) This is the track most firms overlook, and it is the one I get the most questions about. So here is the full answer. **Can a regulated SME use Azure OpenAI and stay compliant?** Yes, under specific conditions. Not by default. Not "out of the box." But yes, if you configure it correctly. Here is what the research shows. ### What Azure OpenAI actually offers to an SME You do not need an enterprise agreement. Azure OpenAI is available on pay-as-you-go. You create an Azure subscription, request access to the Azure OpenAI Service (there is a short form, not a procurement negotiation), and you are provisioned within days. Pricing is the real story. Azure OpenAI uses a pay-as-you-go model - you pay for what you use, with no fixed monthly fee or minimum commitment. Microsoft publishes detailed rates on their pricing page ([Azure OpenAI pricing](https://azure.microsoft.com/en-us/pricing/details/azure-openai-service/)). For context: at typical marketing-team usage - say, drafting fifty blog posts and two hundred social media updates per month - the total cost is usually small; work it out on Microsoft's current price list. The calculation is transparent. The pricing page is public and the math is straightforward. ### The EU Data Boundary: the setting that actually matters Azure OpenAI offers two data processing options: Global Standard and Data Zone Standard. Global Standard means Microsoft can process your data in any Azure region worldwide. Prompts and completions may traverse US infrastructure. For regulated EU workloads, Global Standard is off the table. Data Zone Standard (EUR) means processing stays within the EU data boundary. Microsoft commits that data at rest and data in transit remain within EU regions. This is the setting you need. The catch: **Poland Central does not have Azure OpenAI.** The Azure OpenAI service is available in a subset of Azure regions, and Poland Central is not one of them. The closest EU regions with Azure OpenAI availability are Sweden Central and Germany West Central (Frankfurt). Both are within the EU data boundary. Both are technically fine for Polish SMEs under current regulatory guidance. But you need to know this before you open the Azure portal and wonder why the dropdown does not show Poland. ### AI Act compliance: the shared responsibility Here is the part Microsoft's marketing skips. Microsoft provides the infrastructure compliance. Azure OpenAI under Data Zone EUR meets the physical data residency requirement. Microsoft's SOC 2, ISO 27001, and the Azure EU Data Boundary documentation give you the vendor-side evidence you need for your own compliance dossier. What Microsoft does **not** provide: AI Act compliance for your use case. The AI Act's obligations fall on the deployer (you), not the infrastructure provider. Specifically: - **Article 50 (transparency):** If you deploy a chatbot, you must inform users they are interacting with an AI system. This is your responsibility. Microsoft does not do it for you. - **Article 12 (logging):** High-risk AI systems must automatically log events during operation. Azure OpenAI gives you diagnostic logs through Azure Monitor. But the logs are raw - you need to configure which events to capture, how long to retain them, and in what schema they sit. A default Azure OpenAI deployment logs enough for billing, not enough for a DORA audit. - **Penalties:** The AI Act allows fines up to €15 million or 3% of annual worldwide turnover for breaching the obligations of providers, deployers and other operators, including the transparency duties of Article 50, and up to €35 million or 7% for prohibited practices (Article 99); in both cases the higher amount applies, and for SMEs the lower one. The fines fall on the party that breached its own obligations. The shared responsibility model is: Microsoft handles the infrastructure layer (physical security, network isolation, data residency). You handle the application layer (use-case classification, transparency notices, audit logging, conformity assessment). ### When Track B2 is the right call Track B2 fits data classes that are public or low-sensitivity: - Public website content, blog drafts, SEO copy, social media posts - Customer-facing chatbots answering from a public FAQ or public documentation - Internal drafts that contain no client data, no PII, and no regulated content - Marketing material, sales outreach templates, event descriptions - Regulatory documents that are already public (published guidelines, public tender specs) It does **not** fit: source code under client NDA, medical records, financial transaction data, internal legal opinions, RFP responses containing client data, any document covered by professional secrecy. ### The honest drawbacks Three things you should know before committing to Track B2. **No price guarantee.** Azure OpenAI is PAYG. Usage-based pricing has consistently trended downward across the industry, but Microsoft can change the price. For a product that scales to millions of queries, the risk is real and you should model it. **Model deprecation.** Azure OpenAI deprecates older model versions. GPT-4o-mini will not be the cheapest model forever. When Microsoft retires a model, you have a window to migrate; check its length in the current model retirement policy. This is manageable but it means your application's dependency graph includes a model version, and that version has an expiration date that someone needs to track. **Vendor lock-in is moderate but real.** The OpenAI API schema is widely implemented (open-source vLLM supports it, most inference libraries speak it). Switching from Azure OpenAI to a self-hosted vLLM endpoint with the same API surface is technically straightforward. But the operational switching cost - reconfiguring networking, retesting, recertifying your compliance documentation - is not zero. Build with an abstraction layer from day one and the lock-in shrinks to a weekend migration. Build directly against the Azure SDK with no abstraction and the lock-in is what you made it. ## Which track for which data class A simple decision matrix, derived from the regulatory obligations of a typical Polish regulated SME: - **Client contracts, source code, medical records, legal documents, M&A materials** → Track A. The data class is sensitive, the regulatory exposure is high, and the cost of a compliance failure exceeds the CapEx of a GPU workstation by orders of magnitude. - **Internal HR docs, financial forecasts, internal strategy memos** → Track A or B1. If your HR system already has a strong data boundary, B1 may suffice. If not, default to A. - **Public website content, marketing, SEO, social media, event materials** → Track B2. The data is public. The worst-case exposure is someone reading your draft blog post. Use the cheapest, fastest option. - **Customer support on public docs, FAQ chatbots** → Track B2. The source material is public. The prompts contain user questions about public information. No regulated data crosses the wire. - **RFP responses containing client data, due diligence responses, regulatory filings in draft** → Track A or B1. If the response references a specific client's infrastructure or data, Track A. If it is generic capability description, B2. ## The real work Most regulated SMEs do not need a PhD in LLMs. They need a data-classification exercise and a deployment map. This is what the [AI Readiness Audit](/#zalacznik-1) delivers: classified data assets, matched deployment tracks, and a compliance checklist mapped to the regulations that apply to your sector. It takes roughly two weeks of part-time engagement and costs from PLN 4,900 net. The pattern I see repeatedly: firms over-invest in Track A for workloads that belong in Track B2, while under-investing in Track A where it actually matters. They buy a 50k PLN GPU server to generate marketing copy, but send client contract analysis prompts to a public API. The cost is backwards and the risk is backwards. Fix the classification first. The deployment tracks follow naturally. --- If you do not yet have a data-classification baseline, the fastest way to get one is the [“Does AI make sense for your process?” consultation](https://artcode.software/#consultation): 60 minutes online, PLN 299 total, with a short written summary within 3 business days. We discuss one process and establish what to test next. I credit the fee against an audit ordered within 30 days.