On-premise & private cloud
On-premise and private-cloud document AI deployment
Some documents cannot leave your network — banking supervision, healthcare rules, government classification, or a client contract that simply forbids it. I deploy the entire extraction stack, from OCR through normalization to the API your product calls, inside your own infrastructure, with the compliance documentation your auditors will ask for.
- Nothing leaves your network: models, queue, storage, and API all inside your perimeter
- Kubernetes, Docker Compose, or bare metal — whatever your operations team runs
- Air-gapped installation with an offline artifact bundle
- Architecture and data-flow documentation written for auditors
When the API is not an option
A hosted extraction API is the right answer for most teams most of the time. It stops being the right answer the moment a regulator, a supervisory authority, or a client contract says that customer documents may not be transmitted to a third-party processor.
At that point teams usually discover that 'self-hosted' in the AI tooling world often means 'self-hosted application, hosted models' — which does not satisfy the requirement at all, because the documents still reach an external inference provider.
This service deploys the whole path inside your perimeter: OCR models, vision models, the normalization model, the queue, the object storage, and the API surface. The only network traffic leaving your environment is whatever you explicitly choose to allow.
What gets deployed
Inference layer
Open-weight OCR, vision, and text models served on your GPUs behind an internal OpenAI-compatible endpoint. Sized from a measured evaluation, not a guess.
Processing pipeline
Ingestion, page routing, extraction, normalization, validation, and export — as containerised workers scaled to your document volume.
Queue and storage
Your Redis or equivalent for job orchestration, your Postgres and object storage for documents and results, with retention policies configured to your own rules.
API and integration surface
A documented internal HTTP API, optional MCP server for agent access, and API-key management with per-key quotas and usage logs.
Observability
Structured logging, processing metrics, GPU and queue dashboards, and alerting wired into whatever your operations team already uses.
Compliance pack
Architecture diagram, data-flow map, retention matrix, processing-activity description, and a statement of exactly which components touch document content. Written to be handed to an auditor.
Deployment path
1. Environment and constraint review
What you run, what your network policy permits, what your auditors require, what hardware exists. Constraints first, because they determine everything downstream.
2. Model evaluation and sizing
Open-weight models scored on your documents, hardware specified against your throughput. Detailed in the self-hosted vision-language model service, and included here.
3. Staged deployment
Non-production environment first, with your team present throughout so the deployment is understood rather than delivered as a black box.
4. Integration and validation
Your application switched onto the internal endpoint, load tested at peak, and accuracy re-validated against the benchmark in its final deployed configuration.
5. Compliance documentation and handover
The audit pack, the runbook, the upgrade procedure, and training for the team who will own it.
Deployment targets
| Target | Notes |
|---|---|
| Kubernetes (on-prem or managed) | Helm chart, HPA on queue depth, GPU node pools |
| Docker Compose on bare metal | Simplest option for single-node departmental deployments |
| AWS / GCP / Azure in your own account | Your VPC, your keys, your region — satisfies most data-residency rules |
| Air-gapped datacentre | Offline artifact bundle; no external network path at any stage |
| Hybrid | Sensitive documents processed internally, non-sensitive routed to hosted APIs for cost |
Included in every on-premise engagement
- Infrastructure-as-code for the full stack, in your repository
- Hardware sizing report with headroom for projected growth
- Accuracy validation in the final deployed configuration, not just in staging
- Backup, restore, and disaster-recovery procedure
- Model and application upgrade path with rollback
- Compliance and data-flow documentation
- Operations runbook and live training session
Frequently asked questions
Is this the same engine that runs Parse My Statement?
The architecture is the same and much of the pipeline is shared, with third-party model APIs replaced by self-hosted equivalents. If you want the bank-statement engine specifically, deployed and licensed for your own use, see the licensing page.
What hardware do we need?
It depends on model choice, quantization, and throughput, so the honest answer only comes after the evaluation. Departmental volumes commonly land on one to four modern datacentre GPUs; high-throughput pipelines need multi-node. The sizing report gives you a specific parts list with cost before you commit.
Can we start hosted and move on-premise later?
Yes, and it is often the sensible sequence — prove the workflow on the hosted API, then migrate once the requirement is real. Building the application against a provider-agnostic interface from the start makes that migration a configuration change rather than a rewrite.
Who operates it after handover?
Your team, with a runbook and training — that is the default and the goal. A support retainer is available for teams that would rather not own inference operations, covering upgrades, capacity planning, and incident response.
Will you sign our security and compliance paperwork?
Yes — NDA, DPA, and security addenda as required. Where I need access to your environment during deployment, that access is scoped, time-limited, and logged according to your own policy.
Tell me what your compliance rules actually require
The constraint usually determines the architecture. Send me the requirement — regulatory, contractual, or internal — and I will tell you what deployment shape satisfies it and roughly what it costs.
Related
Self-hosted VLM deployment
Deploy vision-language models on your own hardware
Set up open-weight vision-language and OCR models on your own GPUs or private cloud — Qwen3-VL, InternVL, and similar. Sizing, quantization, vLLM serving, throughput tuning, and accuracy validation.
Enterprise
Enterprise bank statement processing at volume
High-volume statement and document processing for finance, lending, and accounting teams — dedicated infrastructure, data-residency options, SLAs, custom schemas, and direct engineering access.
IP & source licensing
License the extraction engine, the source, or the whole product
Source-code licensing, perpetual IP licensing, and acquisition options for a production bank statement extraction engine with a published ground-truth accuracy benchmark.
Custom OCR engineering
Custom OCR development for documents that off-the-shelf OCR gets wrong
Custom OCR pipeline development for scanned, photographed, and low-quality documents — layout-aware extraction, confidence scoring, vision-model escalation, and ground-truth accuracy benchmarks.
This page is also available as markdown for AI agents: /services/on-premise-deployment.md · index at /llms.txt. Canonical URL: https://parsemystatement.com/services/on-premise-deployment.