Portable AI deployment: run in our cloud or in the client's own tenant

Portable AI deployment: core logic, connectors and a deployment shell for managed or in-tenant runs.

Situation

Smaller clients want a managed service. Larger industrial clients, mostly Microsoft shops, want AI systems to run inside their own cloud, under their own access rules, with data kept in the EEA. Building each product twice was not an option.

Task

Design one architecture that runs on Stratas's managed stack or inside a client's tenant, and that passes client IT and procurement review.

Action

Architecture

Three layers. Core logic holds the agents and business rules. The connector layer talks to the client's systems. The deployment shell is the only part that changes between targets.

Two targets. Managed infrastructure on Trigger.dev, Supabase and Vercel, or the client's own Azure or AWS tenant, with Azure AI Foundry for models in the tenant.

Implementation

EEA data residency and data sovereignty by design.
Access control that follows the client's own identity setup.
A client-facing security architecture document and an IT onboarding template.
Model options for data-sovereign deployments, including open-weight models and self-hosting.

Verification

Security documentation prepared to clear client IT and procurement review.

Result

One codebase, two deployment targets.
A ready answer for IT and procurement: architecture, data residency and access control documented up front.

Skills evidenced

Solution architecture for enterprise AI deployment.
Security and compliance: EEA data residency, access control and documentation.
Cloud platforms: Azure, AWS and managed infrastructure.

Portable lessons

Isolate what changes. Keeping the deployment shell separate made a second target cheap.
Write the security document before the sale. Procurement moves faster when the answers already exist.