How do you design an AI architecture for regulated data?

Key facts

Design driver	Data classification per workload, not model choice
Isolation tiers	Cloud, VPC, on-prem, air-gapped and bring-your-own-cloud
Residency	Region pinning per workspace including GCC, EU, US and APAC
Key custody	BYOK via cloud KMS or HSM; customer-controlled revocation
PII controls	no-PII, detect-only and passthrough modes; no-PII default for embeddings
Audit	Key and admin events plus per-request logs, exportable to SIEM
Contractual frame	Terms at /legal/terms and service commitments at /legal/sla
Compliance posture	SOC 2 Type II and ISO 27001 readiness in progress (not yet certified)

TL;DR

• Classification decides architecture; architecture does not create compliance.
• Pin residency per workload and verify it with configuration evidence.
• Keep prompts, embeddings, logs and backups inside the same boundary.
• Encrypt with keys you can revoke, and log every model call.
• Choose the lightest isolation tier that passes your strictest review.

How it works, step by step

1. Classify data into tiers — public, internal, confidential, regulated — per AI use case.
2. Map each use case to its regulator, retention rules and cross-border constraints.
3. Choose the isolation tier that satisfies the strictest data class in scope.
4. Pin the region and verify residency with a workspace configuration export.
5. Define key custody: provider-managed, BYOK or HSM, with revocation authority clear.
6. Set PII handling mode per workload and test redaction on realistic data.
7. Add audit logging, human review for high-impact decisions and a tested incident path.

Try it yourself

Open the sovereign AI readiness score →

Reference layers for regulated AI

1. Ingress and policy: classify inputs, redact or tokenise sensitive fields, and block data classes the workload must not see.
2. Identity and authorization: SSO, SCIM and RBAC so access follows your joiner-mover-leaver process.
3. Inference boundary: the region or deployment tier where prompts and completions are processed.
4. State: prompt history, embeddings, logs and backups — each with residency, retention and deletion rules.
5. Governance: approved model list, prompt review, evaluation gates and change control.
6. Assurance: audit export, access reviews and an incident playbook with evidence collection.

Draw the diagram store by store. Most compliance surprises come from a log or vector index nobody remembered to include.

Choosing the deployment tier

• Shared cloud with region pinning: right when data can leave the building but not the jurisdiction, and the vendor's controls satisfy your review.
• VPC: right when data must not leave your cloud account; Plugsky runs inside your network with your KMS and peering.
• On-prem: right when the data path itself is in scope for audit, or when network policy forbids external inference.
• Air-gapped: right for classified environments with no internet path, accepting manual update logistics for models.
• Bring-your-own-cloud: right when procurement requires your cloud spend and your account boundary.

Controls that survive audit

Controls fail in the gaps between systems. Define who can read prompts, who can revoke keys, how long each store keeps data, and what evidence proves deletion — then test each one. PII mode belongs at the boundary: no-PII where strict redaction is required, detect-only where you want visibility, passthrough only with a documented justification. Key custody should be revocable by you, whether through BYOK to your KMS or a dedicated HSM. Audit logs need actor, action, resource and timestamp, exported to the SIEM you already operate rather than a tool only one team can read.

Where Plugsky fits — and the honest gaps

Plugsky supports region pinning, VPC, on-prem and air-gapped deployments, scoped keys, SSO/SCIM and RBAC on Enterprise, BYOK/HSM, PII modes and SIEM audit export — all behind an OpenAI-compatible API, so the architecture does not need special application code per tier. Gaps to record: SOC 2 Type II and ISO 27001 are readiness in progress rather than completed certificates, and specialist regulated endpoints such as audio, images and fine-tuning are coming soon. Document those as tracked risks with compensating controls, and keep contractual commitments anchored to /legal/terms and /legal/sla.

Honest comparison

Architecture choice	Plugsky	Hyperscaler platform	Internal build
Residency control	Region pinning per workspace	In-country regions for many services	Your facilities
Isolation depth	Cloud, VPC, on-prem, air-gapped	Shared tenancy with dedicated options	Your design
Key custody	Provider KMS, BYOK or dedicated HSM	Cloud KMS and HSM services	You operate the HSM
PII controls	Three documented modes with redaction	Varies by service	You implement
Audit	Key/admin events plus request logs, SIEM export	Native cloud audit logs	Custom pipeline
Certification status	SOC 2 / ISO 27001 readiness in progress	Completed audits in many regions	Your own programme

Frequently asked questions

Where should an AI architecture start?

With data classification. Decide which classes may enter the system, then apply residency, isolation, key custody and PII controls to match. Starting from model choice leads to retrofitted compliance.

How do I keep regulated data in one jurisdiction?

Pin the workspace region so inference, logs and storage stay there, place your vector store in the same region, and verify with a configuration export. Failover and support access need explicit treatment because they cause unintended transfers.

When do we need on-prem instead of VPC?

When the data path itself is in scope for audit, when network policy forbids external inference, or when sector rules require physical control. VPC is usually sufficient when the requirement is account-boundary control rather than physical.

Can we use our own encryption keys?

Yes. BYOK integrations cover AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault and HSMs, so you control rotation and revocation. Match the assurance level to your sector rules.

How should PII be handled?

Choose a mode per workload: no-PII for strict redaction, detect-only where visibility matters, passthrough only with documented justification. Embeddings default to no-PII and should stay that way for sensitive corpora.

What audit evidence should the architecture produce?

Per-request logs with model, region, tokens, latency and request ID, plus audit logs for key and admin actions, all exportable to your SIEM. Deletion procedures need evidence too, including derived vectors.

Is Plugsky certified for regulated industries?

SOC 2 Type II and ISO 27001 are documented as readiness in progress rather than completed. Some frameworks map to controls you can verify today, but record certification status as pending and confirm evidence during diligence.

How do we avoid lock-in while staying compliant?

Keep the OpenAI-compatible core as the contract and isolate provider-specific extensions. That keeps residency changes — cloud, VPC, on-prem — a configuration move rather than a rewrite.