Key facts
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Deployment | Cloud, VPC, on-prem or air-gapped for R&D and IP protection |
| Auditability | Request, model and response logging for research review trails |
| Data grounding | Embeddings and RAG are live for literature, protocols and reports |
| Structured output | JSON mode returns extraction and review records in fixed schemas |
| 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 and fine-tuning are coming soon |
TL;DR
- Classify published literature separately from unpublished research data.
- Treat protocols, lab records and IP as confidential by default.
- Prefer on-prem or private deployment for programs with IP sensitivity.
- Log model, sources and reviewer so research outputs can be reconstructed.
- Keep a named scientist accountable for anything that informs a study.
How it works, step by step
- Inventory AI use cases across literature review, protocol support, analysis and reporting.
- Classify content by publication status, confidentiality, partner rights and IP value.
- Choose deployment per class: region-selected cloud, VPC, on-prem or air-gapped.
- Issue per-program and per-application keys with rotation and central inventory.
- Define log fields and retention: request ID, model, sources, output, reviewing scientist.
- Approve a model allow-list with evaluation evidence and re-test on version changes.
- Require scientific review and source citation before output informs a study.
Try it yourself
Open the RAG architecture builder →
Research data and IP classification
Life sciences content spans published literature, internal protocols, experimental data, partner-confidential material and patentable IP. Each class needs its own rule, and unpublished results usually carry the tightest handling requirement because disclosure can affect a filing or a partnership.
Most programs start with published literature and standard operating procedures, then extend to experimental data only on private deployments where prompts, datasets and embeddings stay inside the organisation.
Keys, labs and least privilege
Issue a distinct API key per program, application and environment, and keep them in a secrets manager with a rotation schedule. Research groups reorganise often, so connect enterprise SSO and RBAC options to keep console permissions aligned with current project membership, including visiting scientists and external collaborators.
Never place compound identifiers or unpublished results in prompts where retrieval can supply only the passage a task requires.
Residency, retention and research audit trails
Decide where processing happens and how long records live. Region selection covers many residency needs; VPC, on-prem and air-gapped deployment covers programs that require data to stay inside the organisation or a specific country. Retention applies to prompts, outputs, logs and retrieval indexes, and research records follow their own long schedules.
Log enough to reconstruct an output: request ID, model and version, retrieved source identifiers, output and the reviewing scientist. See AI audit logs for a schema.
Model governance and scientific review
Keep an approved model list with evaluation evidence, and re-run evaluations when versions change. Ground answers in cited literature and current protocols so scientists can verify quickly, and mark AI-generated summaries as drafts. A qualified scientist remains accountable for conclusions, so the checklist should name the reviewer for each workflow that informs a study, a filing or a partner update.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Identity | Scoped keys per program, rotation, SSO and RBAC options | Shared lab credentials | IT security |
| Data boundary | Cloud, VPC, on-prem or air-gapped deployment | Unpublished data in shared tools | Research operations |
| Retention | Configurable logging of requests and responses | No defined schedule | Quality and records |
| Audit trail | Request, model and source logging | Outputs not traceable | Scientific governance |
| Grounding | Embeddings and RAG over literature and protocols | Unsourced AI summaries | Knowledge management |
| Review | Citations and structured output for scientists | AI drafts treated as findings | Principal investigator |
Frequently asked questions
Does using Plugsky make us compliant?
No. Compliance is your program. Plugsky provides deployable controls - scoped keys, private deployment, logging - that you document and audit against your own research and privacy obligations.
Can unpublished research stay inside the organisation?
Yes. VPC, on-prem and air-gapped deployments keep prompts, documents and embeddings inside your environment, and the API stays OpenAI-compatible.
What should we log?
Request IDs, model names and versions, retrieved source identifiers, outputs and the reviewing scientist, retained under your policy so research outputs can be reconstructed.
How do we keep IP safe during pilots?
Pilot on published literature and standard procedures first, then move confidential or patentable content to private deployment with scoped keys.
Is fine-tuning available on internal datasets?
Fine-tuning, files and batch endpoints are coming soon. Today, use retrieval over approved literature and protocols with citations.
Can external collaborators get access?
Yes, with separate scoped keys per partner and program, explicit expiry, and retrieval indexes that expose only the material each collaboration covers.
Where should a pilot start?
Pilot on published literature and internal standard procedures with the free plan, verify citations and logging, then extend to experimental data on private deployment.