Key facts
| Vision input | Images and documents passed in chat completions messages (live) |
| Embeddings | /v1/embeddings for semantic search and matching (live) |
| RAG | Built-in vector store and retrieval collections (live) |
| Image generation | /v1/images/generations with plugsky-imagine-xl and plugsky-imagine-fast — coming soon |
| Audio | /v1/audio/transcriptions and /v1/audio/speech with whisper-plugsky — coming soon |
| Residency | Region pinning; VPC, on-prem and air-gapped deployment |
| PII handling | No-PII mode auto-redacts, detect-only tags, passthrough for your controls |
| Review | Human verification for anything that affects a customer or account |
TL;DR
- Vision in chat completions is live for documents, forms and statements.
- Embeddings and RAG are live for policy and product knowledge.
- Image generation and audio endpoints are coming soon — plan, do not ship.
- Redact identifiers before inference and pin the workspace to a region.
- Keep human verification ahead of any customer-affecting action.
How it works, step by step
- Pick one document workflow — statement extraction, form intake or policy search — with a measurable error rate.
- Pass page images or scans into chat completions and extract structured fields with JSON mode.
- Index policy and product documents with embeddings and query them through built-in RAG.
- Redact identifiers before inference and set the PII mode your policy requires.
- Pin the workspace to one region and keep keys scoped per environment.
- Route extractions through human verification, then track accuracy before widening the workflow.
Original data
Try it yourself
Open the RAG architecture builder →
What is live today for banks
Three capabilities are production-ready. Vision input in chat completions lets a model read scanned statements, forms, invoices and identity documents sent as image content in the messages array. Embeddings turn text into vectors for semantic search and matching. Built-in RAG stores and retrieves documents from private collections, so assistants answer from your policies rather than from memory.
Together they cover the document-heavy middle of banking operations: extracting fields from paperwork, matching transactions to policies, and answering staff questions with citations. None of it requires a specialist vision vendor or a separate retrieval stack.
A document workflow you can build now
Take statement extraction as a concrete case. Send each page image with a strict instruction to return JSON fields — account mask, period, balances, transaction lines. Validate the JSON against a schema, reject anything malformed, and route low-confidence or high-value extractions to a human. Pair the extraction with RAG so the assistant can also answer "what is our policy on this fee?" in the same conversation.
- Redaction: run no-PII mode plus your own gateway pass before any customer identifier reaches a prompt.
- Residency: pin inference, embeddings and logs to one region, or run in your VPC, on-prem or air-gapped.
- Verification: keep a named reviewer releasing anything that changes an account or a customer record.
The roadmap, and how to plan for it
Be precise about what is not here yet. Image generation via /v1/images/generations and audio transcription or speech via /v1/audio/transcriptions and /v1/audio/speech are marked coming soon in the docs. Do not design a customer-facing workflow that depends on them today.
You can still plan: keep a thin interface between your application and the model call so swapping in an audio endpoint later is a configuration change, and benchmark language support for your markets with your own evaluation set. Request body size tops out at 16 MB, so large multi-page scans should be split per page rather than sent as one payload.
Honest comparison
| Capability | Plugsky status | Typical alternative | Planning note |
|---|---|---|---|
| Document and image understanding | Live via vision in chat completions | Separate vision API | Validate fields against a schema |
| Semantic search | Live embeddings endpoint | Third-party vector service | Store vectors with your data |
| Document retrieval | Live built-in RAG collections | External RAG stack | Keep collections per use case |
| Image generation | Coming soon | Image vendor | Do not ship customer flows yet |
| Audio transcription and speech | Coming soon (whisper-plugsky planned) | Speech vendor | Plan interface flexibility |
Frequently asked questions
Can Plugsky read scanned documents today?
Yes. Vision input in chat completions accepts images, so statements, forms and similar documents can be sent directly and extracted into structured JSON.
Is document data stored or used for training?
Request and response bodies are not stored, and prompts are not used to train models. You should still minimise and redact identifiers before inference.
Can we generate images or transcribe calls?
Not yet. Image generation and audio endpoints are coming soon per the docs; design workflows that do not depend on them today.
Does this work in our region or on-prem?
Yes. Pin workspaces to a region, or deploy in your VPC, on-prem or air-gapped where customer data cannot leave the environment.
How accurate is extraction?
Accuracy depends on document quality and your schema. Validate output against a strict JSON schema and keep human review for anything that affects an account.
Can it answer questions about our policies?
Yes. Embed your policy library into a retrieval collection and have the assistant cite retrieved passages rather than relying on model memory.
How should a pilot start?
One document type, one measurable error rate, human verification in the loop, and the free plan to build against before scaling.