Key facts
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Channel separation | Separate keys per channel, brand and environment |
| Deployment | Cloud, VPC, on-prem or air-gapped for customer data |
| Auditability | Request, model and response logging for support and dispute review |
| Data grounding | Embeddings and RAG are live for catalogues, policies and returns |
| Structured output | JSON mode returns returns and order records in fixed schemas |
| Models | 30+ models behind one OpenAI-compatible API |
| Endpoint roadmap | Images, moderation, files and fine-tuning are coming soon |
TL;DR
- Keep payment data out of prompts, indexes and transcripts entirely.
- Issue per-channel keys so support tools cannot see store systems.
- Ground product and returns answers in current catalogue data.
- Log requests, sources and reviewers for dispute reconstruction.
- Keep refund, resale and fraud decisions with named humans.
How it works, step by step
- Inventory AI use cases across support, search, merchandising, store ops and returns.
- Classify data by customer sensitivity, payment content and channel exposure.
- Choose deployment per class: cloud, VPC, on-prem or air-gapped.
- Issue per-channel and per-brand keys with rotation and central inventory.
- Define log fields and retention: request ID, model, sources, output, channel, agent.
- Approve a model allow-list and refresh the product index on a schedule.
- Require human review for refunds, fraud flags and regulated product claims.
Try it yourself
Open the AI data residency checklist →
Customer, payment and product data
Retail data spans public product information, internal pricing and inventory, customer profiles, order history and payment references. Each class needs its own handling rule, and payment data should never pass through an assistant or retrieval index.
Start with catalogue content and public policy, then extend to customer and order data only on deployments that keep prompts, documents and embeddings inside the agreed boundary.
Keys, channels and least privilege
Issue a distinct API key per channel, brand, application and environment. Store keys in a secrets manager, rotate on a schedule, and revoke them when a vendor or marketplace integration ends. Enterprise SSO and RBAC options keep console access aligned with store and contact-centre turnover, where staff move between roles quickly.
Never let a support assistant hold a key that can reach store operations systems, and keep personal identifiers out of prompts where retrieval can supply only the fields a task needs.
Residency, retention and omnichannel audit trails
Decide where processing happens and how long records live. Region selection covers many needs; VPC, on-prem and air-gapped deployment covers markets with stricter customer-data requirements. Retention applies to prompts, outputs, logs and retrieval indexes, and transaction records follow their own schedules.
Log enough to reconstruct a customer interaction: request ID, model and version, retrieved source identifiers, output, channel and handling agent. See AI audit logs for a schema.
Model governance and product accuracy
Keep an approved model list with evaluation evidence and re-test when versions change. Refresh the product and policy index on a schedule so availability, pricing and returns answers stay current, and require citations for anything customer-facing. Refunds, fraud decisions and regulated claims stay with named humans, and the checklist should capture escalation paths for peak periods when volumes spike. Image and moderation endpoints are coming soon; plan visual search around that status.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Channel separation | Separate keys per channel, brand and environment | One key across all systems | Security engineering |
| Identity | Scoped keys, rotation, enterprise SSO and RBAC options | Shared store credentials | IT security |
| Payment boundary | Payment references excluded from prompts and indexes | Card data in transcripts | Payments team |
| Retention | Configurable logging of requests and responses | No defined retention | Privacy Office |
| Grounding | Embeddings and RAG over catalogue and policy | Outdated stock answers | Merchandising |
| Review | Citations and structured output for agents | Automated refund promises | Customer operations |
Frequently asked questions
Does using Plugsky make us compliant?
No. Compliance is your program. Plugsky provides deployable controls - scoped keys, channel separation, private deployment, logging - that you document and audit against your own payment and privacy obligations.
Can customer data stay in one region?
Yes. Region selection covers many requirements, and VPC, on-prem and air-gapped deployment keeps data inside a chosen environment or country.
What should we log?
Request IDs, model names and versions, retrieved sources, outputs, the channel and the handling agent, retained under your policy so disputes and complaints can be reconstructed.
How do we keep product answers accurate?
Refresh the retrieval index from the catalogue and policy system on a schedule, require citations, and test a sample of answers each release.
Can we use AI for returns and refunds?
Retrieval can prepare and explain returns, but refund and dispute decisions stay with named staff following your policy, especially during peak periods.
Are visual search and image features available?
Images, moderation and file endpoints are coming soon. Chat, streaming, JSON mode, function calling, embeddings, RAG and agents are live today.
Where should a pilot start?
Pilot on public catalogue and policy content with the free plan, validate accuracy and logging, then extend to customer workflows on private deployment.