From Private Endpoint to Production Capability
An organisation can deploy Microsoft Foundry behind a private endpoint and still not have a production-ready AI capability. The network may be private while the operating model is unclear, identity may be centralised while an agent holds more authority than intended, retrieval may use approved documents while ignoring who is allowed to see each one, and a model may be deployed from a South African region while its inference runs elsewhere. This six-part series moves from a secure-looking diagram to a capability that can be governed, operated and defended: platform and product boundaries, verified network paths and DNS, identity and the AI gateway, retrieval as a data security system, agent authority and human approval, and the evaluation, incident, cost and ownership work that begins after deployment. One fictional South African medical scheme administrator carries the examples. Product names, preview states and regional availability change often: re-check them before you design. Not legal advice.
6 articles
- Part 1The platform is not the product: boundaries for enterprise AI on Microsoft FoundryThe first Foundry deployment usually becomes a shared platform by accident. Part 1 separates the landing zone, the AI platform, each AI product and the operating model, sets out what should be shared, and shows how to decide between one Foundry resource and several.11 min read
- Part 2Private by design: the network paths of an enterprise AI platform"We use private endpoints" does not explain how an AI system is protected. Part 2 maps ingress, east-west and egress paths, treats DNS as part of the security boundary, separates human, workload and operator access, and lists the evidence a production review should demand.11 min read
- Part 3Identity before intelligence: who may call the model, and on whose authorityAn API key proves possession of a secret, not who is asking or what they may do. Part 3 covers the identity chain, Foundry's roles, what an AI gateway can and cannot enforce, model routing, semantic caching, and why a resource in South Africa North does not mean inference in South Africa.12 min read
- Part 4RAG is a data security systemRetrieval-augmented generation is usually sold as a quality technique. In an enterprise it is also an authorisation system: a passage can be relevant to the question and still forbidden to the person asking. Part 4 covers permission-aware retrieval, ingestion as part of the product, prompt injection through documents, and why grounded is not the same as correct.12 min read
- Part 5Agents change the risk boundary: authority, approval and tool contractsA chatbot can give a wrong answer. An agent can take a wrong action, and some actions cannot be undone. Part 5 sets out the authority envelope, the choice between delegated, application and brokered authority, what human approval has to mean in practice, and why every tool needs a contract with idempotency built in.11 min read
- Part 6Production begins after deployment: operating an enterprise AI productA successful deployment proves the deployment worked, not that the AI product is accurate, safe, affordable or supportable. Part 6 covers observability across seven layers, evaluation as release management, service levels the platform can influence, AI incidents, the whole bill, the minimum operating model and a production acceptance checklist.12 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala