Where Your Documents Live (and Where They Don't)

Before any conversation about capabilities, accuracy, or workflow — before any technical evaluation at all — the first question is always the same: "Where does our data go?"

It's the right question. For regulated institutions, private equity firms handling deal-sensitive material, and boards reviewing governance documents, the answer determines whether a platform is even worth evaluating.

Here is a direct answer.

Embeddings never leave your environment

At the core of any AI document intelligence system is the embedding model — the component that converts text into mathematical vectors so documents can be searched semantically rather than by keyword.

Most platforms call an external API for this. Every paragraph of every document is sent over the network to a third-party service, converted to a vector, and sent back. This happens thousands of times per document set. It's the most data-intensive operation in the pipeline, and for most vendors, it's the one they control least.

Vela takes a different approach. We ship an embedding model that runs locally — on the same hardware as the rest of the platform. It's a compact, purpose-built model (768-dimensional, L2-normalised) running on an optimised inference engine. No network calls. No external APIs. No data leaving the device.

The vectors it produces are stored in VelaDoc — Vela's own JSON document database, built specifically for AI workloads and with integrated vector search. Everything from document upload through parsing, embedding, and storage in VelaDoc runs inside the deployment. No external service touches the document during ingestion. Analysis is a separate stage with its own data flow, described below.

This isn't a premium add-on or an enterprise tier feature. It's the default.

Document storage is yours

Raw documents — the PDFs, spreadsheets, Word files, and financial filings that enter the system — are stored wherever you configure them. Vela supports both object storage and block storage:

• Object storage. S3-compatible — AWS S3, Azure Blob, GCP Cloud Storage, or an on-premise service like MinIO.
• Block storage. A direct-attached drive (local disk, SAN) or a network-mounted drive (NFS, SMB) on infrastructure you control.

The platform connects to whatever storage endpoint or mount point you configure. In an on-premise deployment, documents never leave your network. In a cloud deployment, they reside in the cloud provider and region you select. Vela does not mandate a storage provider.

All storage is encrypted at rest (your provider's or filesystem's standard encryption) and all transfers are encrypted in transit via TLS.

What actually goes to an AI provider

This is where the honest conversation begins. At certain points in the pipeline, content does flow to an AI provider — an API call to a language model or a vision model. The question is: how much content, when, and under what controls.

Document parsing

When documents are ingested, there are two modes:

Local extraction. For text-based documents (searchable PDFs, DOCX, spreadsheets, HTML, JSON, XML, XBRL, CSV), content is extracted entirely on-device using local parsers. No external API is involved. The full text of these documents never leaves your environment.

Vision-assisted extraction. For scanned PDFs, images, and documents where layout and visual elements carry meaning (tables, charts, diagrams), a vision model processes rendered page images. This requires an API call to an AI provider. However:

• Pages are rendered as images and sent individually — the provider never receives the assembled document.
• You choose the provider. Vela supports multiple AI providers and allows you to configure custom endpoints, including private deployments (Azure OpenAI, self-hosted models, or any API-compatible service your organisation operates).
• Vision extraction is optional. If your security posture requires it, you can restrict processing to local extraction only, accepting the trade-off that scanned or image-heavy documents won't be fully parsed.

Analysis and assessment

When Vela evaluates documents — extracting evidence, scoring against criteria, producing assessments — it sends content to a language model. This is the point where AI reasoning happens, and it requires an API call.

But what's sent is carefully bounded.

The platform uses semantic search to retrieve only the specific passages relevant to the question being asked. A 500-page PDF is not sent to the model. A 10,000-row spreadsheet is not sent to the model. Instead, the system identifies the precise segments that contain relevant evidence — often a handful of paragraphs from across multiple documents, sometimes a single field in a table — and sends only those segments, along with the evaluation criteria.

At any given moment, the model receives a narrow, targeted slice of content. Typically an order of magnitude less than what a conventional retrieval system would provide, and many orders of magnitude less than the source document set. The full documents remain in your storage, indexed in your database, searchable via your local embeddings. The AI provider sees only what's necessary for the specific analytical task.

Your provider, your terms

Vela does not mandate which AI provider you use. The platform supports multiple providers — including the option to point to your own hosted endpoints. This means:

• You choose the provider whose data handling policies meet your requirements.
• You use your own API keys, under your own contractual terms with that provider.
• Vela's own agreements with every supported AI provider already prohibit training on submitted content. That's the baseline, not an opt-in.
• If your organisation has negotiated additional terms — a custom DPA, restricted regions, tighter retention windows — those terms govern on top of ours.

Every major AI provider offers enterprise terms that explicitly exclude customer data from model training. These are standard commercial agreements, the same kind of agreements that govern your use of cloud email, document management, and collaboration tools today. The mechanism for data protection in AI is the same mechanism enterprises already use for every other cloud service: contractual controls, backed by regulatory enforcement.

The on-premise option

For organisations where no data can leave the network boundary under any circumstances, Vela can be deployed entirely on-premise:

• Embeddings run locally (default behaviour, no change needed).
• Vector search runs locally (database is self-hosted).
• Document storage is local (on-premise object storage like MinIO, or a direct-attached / network-mounted drive).
• Document parsing uses local extraction only (no vision API calls).
• Analysis uses a self-hosted language model or a private API endpoint within your network (though results may vary greatly).

In this configuration, zero data leaves your infrastructure. The trade-off is that self-hosted language models are generally less capable than frontier cloud models, and vision-based document parsing is unavailable without a vision-capable model endpoint. But the option exists, and it's a configuration choice, not a product tier.

The honest position

No system that uses AI for document analysis can guarantee that zero content ever flows to an external service — unless it uses only locally-hosted models for every operation. That's a real option, with real trade-offs in capability.

The practical answer for most organisations is a hybrid: local embeddings and search (no data leaves), local extraction for text-based documents (no data leaves), and targeted API calls to a chosen provider for vision extraction and analytical reasoning (minimal data, under your contractual terms, using your keys, with your provider).

This is the same model enterprises use for every cloud service. The question isn't "does data ever leave my network?" — for most organisations using cloud email, cloud storage, and cloud collaboration, that ship has sailed. The question is: "Do I control where it goes, how much goes, who can access it, and under what terms?"

With Vela, the answer to all four is yes.