Why We Build on Microsoft Azure and Azure AI Foundry

Choosing the infrastructure an AI platform runs on is a decision with legal, commercial and technical consequences that are difficult to reverse. We build on Microsoft Azure, with AI processing through Azure AI Foundry and identity through Microsoft Entra ID. Here is the reasoning, including what we gave up.

Data residency was the deciding factor

Our customers are European businesses, and a large share of them handle personal data that must remain within the EU or EEA. Azure lets us fix the processing region and write it into the contract rather than treat it as a configuration default.

That single property eliminated several otherwise capable options. An architecture where we cannot state, precisely and contractually, where a customer's data is processed is not one we can offer to an Austrian company that will be asked the question by its own customers.

The contractual chain works

When we act as processor for a customer, we need a sub-processor arrangement that supports the commitments we make. Microsoft's data protection terms and their published sub-processor arrangements let us construct a chain that holds together under Art. 28 GDPR.

This is less exciting than model benchmarks and considerably more important in practice. A provider who cannot pass through the necessary contractual terms cannot be used for regulated work, however good the technology.

Identity was already solved

Most of our customers run Microsoft environments. Using Entra ID means access follows their existing accounts, their multi-factor authentication, their conditional access rules, and — critically — their offboarding process.

When an employee leaves, access ends because the account ends. No separate user list to maintain, no forgotten accounts. For a platform holding company knowledge, that is a material security property rather than a convenience.

The certifications carry weight

Building on infrastructure certified to ISO/IEC 27001, ISO/IEC 27018 and SOC 1/2/3 means the physical and platform layers come with independent attestation. We can point a customer's compliance team at those rather than asking them to take our word about a data centre.

To be clear about what this does and does not mean: it covers the infrastructure. It does not certify our application on top of it. We are careful not to imply otherwise, and you should be sceptical of any provider who blurs that line.

What we accepted in exchange

Model availability lags. New model versions frequently reach US regions before EU ones. We accept running a version or two behind in exchange for residency, and for the work we do — document processing, drafting, retrieval over customer documentation — the practical difference is small.

Concentration risk. Depending heavily on one provider is a genuine exposure. We mitigate it by keeping the model layer replaceable rather than woven through the application, so a change is a significant project rather than an impossible one. We do not pretend it is costless.

Cost. Managed services cost more than raw compute. Given the operating burden of doing it ourselves, and the security posture required, we consider it correct for our size — but it is a real premium, not a saving.

Our relationship with Microsoft

SW Technology Solutions is a member of the Microsoft AI Cloud Partner Program and works together with Microsoft. We state that plainly and no more strongly: we hold no Solutions Partner designation, and Microsoft does not endorse or bear responsibility for our services. Your contract is with us.

Why we publish this

Infrastructure choices are usually left implicit, which makes them hard to evaluate. If you are considering us, you should be able to see the reasoning and the trade-offs, and decide whether they match your priorities. If EU residency is not a constraint for you, some of our decisions will look conservative — and you would be right.

All Articles
Let’s Talk

about the process
AI should run.