Key facts
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Tenancy | Separate keys and retrieval indexes per tenant and environment |
| Deployment | Cloud, VPC, on-prem or air-gapped for enterprise customers |
| Auditability | Request, model and response logging for customer support and audit |
| Data grounding | Embeddings and RAG are live for in-product knowledge features |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing model | Flat monthly self-serve plans; no per-token billing on self-serve |
| Endpoint roadmap | Files, batch, assistants and fine-tuning are coming soon |
TL;DR
- Treat customer content in prompts as production data with a defined path.
- Isolate tenants in keys and indexes before shipping any AI feature.
- Publish subprocessor and residency details in your trust documentation.
- Design a kill switch and fallback for every AI-powered feature.
- Evaluate prompts like code: version, test and roll back.
How it works, step by step
- Classify the tenant data each planned AI feature will read or write.
- Choose deployment per feature: shared inference, dedicated VPC, on-prem or air-gapped.
- Issue per-tenant and per-environment keys with rotation and central inventory.
- Define log fields and retention: request ID, model, sources, output, tenant, feature.
- Add subprocessor and residency detail to your DPA and trust page.
- Version prompts and models, run evals in CI, and keep a kill switch per feature.
- Define rollback and customer communication for regressions or incidents.
Try it yourself
Open the RAG architecture builder →
Tenant data inside your product
Your product already holds customer content, and an AI feature adds a new path for that content to travel. Classification should record which feature reads which fields, whether prompts are logged, and whether outputs can be stored as customer data.
Most teams start with help content and public documentation, then extend to tenant content only where the contract permits it and the deployment keeps prompts, documents and embeddings inside the agreed boundary.
Keys, tenants and least privilege
Issue a distinct API key per tenant environment and per feature, with tighter scopes than an application key typically carries. Store keys in a secrets manager, rotate on a schedule, and revoke immediately when a customer offboards. Separate retrieval indexes per tenant so no feature can search across customers, and connect enterprise SSO and RBAC options so internal support access is auditable.
Never let a shared evaluation account hold production tenant content.
Residency, retention and subprocessor disclosure
Decide where inference happens for each feature and document it in your DPA and trust page. Region selection covers many requirements; VPC, on-prem and air-gapped deployment covers enterprise customers who require data to stay in their environment or country. Retention applies to prompts, outputs, logs and retrieval indexes, and must match what you promised in the contract.
Log enough to answer a customer audit: request ID, model and version, retrieved source identifiers, output, tenant and feature. See AI audit logs for a schema.
Model governance and rollback
Keep an approved model list with evaluation evidence, version your prompts, and run evaluations in CI so a prompt change is tested like a code change. Ground customer-facing answers with citations, and treat model changes as releases with a rollback plan. Give every AI feature a kill switch and a non-AI fallback, because enterprise customers ask about both. Bring-your-own-key and bring-your-own-cloud options help close deals where a customer insists on controlling the inference footprint.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Tenancy | Separate keys and indexes per tenant | Cross-tenant retrieval risk | Platform engineering |
| Identity | Scoped feature keys, rotation, SSO and RBAC options | Shared internal credentials | Security |
| Data boundary | Region choice plus VPC, on-prem or air-gapped | Residency absent from DPA | Legal and trust |
| Release safety | Prompt and model versioning with evals | Untracked prompt changes | Engineering |
| Rollback | Kill switch and fallback per feature | No way to disable a feature | Product |
| Customer control | BYOK and bring-your-own-cloud options | One deployment model for all | Enterprise sales |
Frequently asked questions
Does using Plugsky make us compliant?
No. Compliance is your program. Plugsky provides deployable controls - scoped keys, tenant separation, private deployment, logging - that you document in your own trust and compliance materials.
How do we isolate tenants?
Use a distinct key and retrieval index per tenant, never allow cross-tenant retrieval, and test the boundary as part of your release checklist.
What should we tell enterprise customers?
Where inference happens, which subprocessors are involved, what is logged, how long it is kept and how the feature can be disabled. Keep that answer current in your DPA and trust page.
Can customers bring their own cloud or key?
Yes. Plugsky supports private deployment options and BYOK-friendly patterns, and the OpenAI-compatible API keeps your product code unchanged.
How do we roll out a new model safely?
Version prompts, run evaluations in CI against a fixture set, canary the change, and keep a kill switch and fallback path per AI feature.
Is fine-tuning available for our product prompts?
Fine-tuning, files, batch and assistants endpoints are coming soon. Today, use retrieval and JSON mode with versioned prompts.
Where should a pilot start?
Pilot an internal feature on public documentation with the free plan, prove tenant isolation and logging, then ship customer-facing AI with per-tenant keys.