Why a self-hosted vector database for financial services needs its own design
A self-hosted vector database fits a bank or insurer when retrieval over client documents, research and policies must run without sending embeddings to a third party. The short answer is that the database itself is rarely the hard part. The hard parts are treating embeddings derived from client data as regulated data, enforcing entitlements at query time, and proving who searched for what. Qdrant, Milvus and pgvector on PostgreSQL are the main fits to evaluate, and the choice depends on collection scale, filtering needs and the operations team you have available to run the platform.
Embeddings are a transformed copy of the source text. A vector can often be traced back to the document or record it came from, so most compliance teams treat it with the same classification as the source, including client identifiers and payload text stored alongside it. Confirm this classification with your data protection and records owners before the first pilot, and document which embedding model processes which source class. Storage also matters: Qdrant needs block-level storage and cannot run on NFS or S3-style object storage, so the infrastructure team must provision it inside your boundary before the platform is selected.
Access rules must apply at query time, not only at the document store. A relationship manager should retrieve only passages from clients and mandates they are entitled to see, which means each vector carries entitlement metadata and every search applies a filter tied to your identity provider. Qdrant offers JWT-based per-collection permissions and JSON audit logging of authenticated API operations, Milvus offers role-based access control and multi-tenancy at database, collection or partition level, and pgvector inherits PostgreSQL roles and row-level security. Ask each candidate to demonstrate a filtered query that a restricted user cannot widen, and keep query audit trails for the period your regulator expects. Under DORA, the backup and exit plans for this service must also be tested, so choose the platform your team can restore and migrate without vendor help.
Which financial regulations shape the vector store build
This table maps the financial regulations most likely to affect a self-hosted vector store to concrete build decisions. Read each row as a requirement, what it means for the store, and what evidence to prepare. The main takeaway is that DORA sets no certification scheme, so the evidence you produce is what an assessor will examine.
| Requirement | What it means for the build | Evidence to prepare |
|---|---|---|
| DORA Article 28(3): register of information | Record the vector store and its hosting arrangement as an ICT service in the register, including the platform, embedding pipeline and any managed or partner support. | Register entries with provider, location, function supported and the dependency on the embedding model and source systems. |
| DORA Article 30(2): stated locations and data return | Contracts with any implementation partner or hosting provider must state where vectors and source text are processed and stored, give advance notice of changes, and cover data return on termination or insolvency. | Signed contract clauses naming data regions, change-notice terms and a documented data return procedure for collections and snapshots. |
| DORA Article 28(8): tested exit strategy | If the vector store supports a critical or important function, document an exit path, such as export or re-indexing into another engine, and test it before it is needed. | A dated exit plan, a test restore into a second environment and the recorded result, including re-embedding time if vectors cannot be moved. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5): multi-factor authentication | Where the Safeguards Rule applies to a non-bank financial institution, require multi-factor authentication for any individual accessing an information system holding customer information, unless the Qualified Individual approves an equivalent control in writing. Vector store admin consoles and API access paths fall within this scope. | Written approval for any equivalent control, MFA configuration for the access paths used to reach the store, and access logs that show who connected. |
| SEC IT general control areas for SOX 404 (Release 33-8810) | Where the bank or insurer is an SEC registrant and a vector store feeds financial reporting or reporting-relevant analysis, treat program changes, computer operations and access to data as in-scope control areas. Re-indexing and schema changes become managed changes. | Change tickets for collection and index changes, operations runbooks, and records of who can modify or delete collections. |
| PCI DSS scope where cardholder data appears in source documents | If client documents, statements or correspondence contain primary account numbers, the vector store and its embedding pipeline may fall within the cardholder data environment. Confirm scope before ingestion, and mask or exclude card data where it is not needed for retrieval. | A scope statement showing whether the store is in or out of scope, data discovery results on source documents, and the segmentation evidence used to justify the boundary. |
| Per-collection access controls and entitlements | Regulators and assessors look for least-privilege access to data. Define collections by sensitivity and grant read or write rights per collection, with user entitlements applied at query time so retrieval respects what each user may see. | Access matrix by collection and role, JWT or API key configuration records, and test results showing a user cannot retrieve restricted chunks. |
| No certification scheme under DORA | DORA does not issue a certificate for a vector store. The only authority-issued attestation it provides for is that a threat-led penetration test met requirements (Article 26(7)), so do not present any vendor badge or self-attestation as DORA compliance. | Internal control statements, audit-ready evidence packs and, where relevant, a threat-led penetration test scoped to the store, reviewed with your supervisor and independent assessors. |
Which platform fits which bank or insurer situation
This fits a team that already runs PostgreSQL under mature backup, high availability and access controls, and whose embedded content is modest in volume. pgvector adds vector columns and similarity indexes to the database you already operate, so the vectors inherit its backup, replication and role model. The trade-off is that your control set is the one you already have, and it must be extended to cover the new data.
- Operational burden: the existing DBA and backup team absorbs the work, but index build time, memory for HNSW or IVF indexes and vacuum behavior on frequently re-embedded tables become new items on their runbook.
- Filtering: entitlement checks can sit in ordinary SQL joins against your permission tables, which helps auditors follow the logic.
- Limits: confirm the dimension limits, index types and filtered-search behavior for your embedding model and query pattern with the pgvector project and your own load tests.
- Restore evidence: your existing backup tooling covers the vectors, but you must prove that a restore brings back vectors consistent with their source documents.
- Split point: plan the move to a dedicated engine before query volume or collection size forces re-tuning of the shared database.
Before committing, confirm with your DBA team how vector indexes are rebuilt after a restore and who signs off on re-embedding work.
This fits a team that wants a vector store with its own access model, where permissions are scoped to individual collections and API operations are recorded. Qdrant's documentation lists admin and read-only API keys and TLS for REST and gRPC since v1.2.0, JWT-based granular access with per-collection read or write permissions since v1.9.0, and JSON audit logging of authenticated API operations since v1.17.0. The latest GitHub release cited in the supplied facts is v1.19.2, published October 5, 2026.
- Secure by configuration: the Qdrant security documentation states that self-deployed instances listen on all interfaces and have no authentication by default, so hardening is a day-one task.
- Storage: block storage with a POSIX-compatible file system is required, and NFS or S3-style object storage is not supported.
- High availability: the distributed deployment docs recommend at least three nodes so quorum survives a node failure, and replication doubles storage at a factor of 2.
- Deployment path: the community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so confirm which path your operations team can support.
- Cost: the open-source engine is free to self-host, but nodes, storage, on-call and upgrade testing are your cost. Hybrid Cloud and Private Cloud are priced through Qdrant sales.
Confirm with Qdrant which audit log fields are captured and whether they meet your retention rules.
This fits very large collections or many isolated tenants, where a bank or insurer needs multi-tenancy at database, collection, partition or partition-key level and role-based access control. Milvus is Apache-2.0 licensed under the LF AI and Data Foundation, and two release lines are maintained: v3.0.3, published October 14, 2026, and v2.6.25, published September 29, 2026. Milvus implements authentication, TLS and role-based access control.
- Architecture: stateless proxies, coordinators and worker nodes depend on etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log such as Woodpecker, Kafka or Pulsar.
- Operational burden: this is the heaviest stack of the three, with several stateful dependencies that each need backup, monitoring and upgrade procedures.
- Deployment modes: Milvus Lite, Standalone and Distributed serve different scales, so confirm which mode matches your recovery objectives.
- Managed option: Zilliz Cloud offers Serverless, Dedicated and bring-your-own-cloud models, which changes who operates the dependencies.
- Release line: confirm which line your platform team will standardize on and how upgrades between lines are tested.
Before choosing, ask your partner to show a restore test that covers etcd, object storage and the write-ahead log together, since DORA-style recovery evidence depends on that consistency.
Which platforms fit financial services and why
A bank or insurer rarely chooses a vector store on speed alone. The platform has to support per-collection permissions, encryption, audit evidence, and a restore process that an exit plan can rely on. The cards below cover the dedicated vector engines, the PostgreSQL option, and the gateway, tracing and lineage components that record who queried what.
Qdrant for dedicated vector search
Qdrant is licensed under Apache-2.0 and is free to self-host. Out of the box, though, a self-deployed instance listens on all network interfaces with no authentication, so API keys, TLS and JWT-based per-collection permissions must be configured before any client data is loaded. Plan for block storage with a POSIX file system, since network file systems and object storage are not supported. For production, the distributed docs recommend at least three nodes so quorum survives a node failure, and the enterprise operator is the path that includes zero-downtime upgrades.
Milvus for large collections
Milvus is Apache-2.0 licensed and ships authentication, TLS encryption and role-based access control. Its distributed mode is disaggregated, so a production cluster depends on etcd for metadata and on object storage such as MinIO, S3 or Azure Blob, plus a write-ahead log such as Kafka or Pulsar. Each of these is a backup, restore and exit item for the bank's register of ICT services. Confirm which deployment mode fits the workload, and ask your partner to test restores across all of these stores together.
pgvector on existing PostgreSQL
For teams that already run PostgreSQL in a controlled estate, pgvector keeps embeddings inside the database that already has backup, point-in-time recovery, replication and access controls under audit. Entitlements can be expressed in the same SQL that filters rows for the user. The trade-off is that index tuning, filter selectivity and memory sizing become database operations work. Ask whether the existing HA and backup runbooks have been tested against a restore that includes the vector indexes.
LiteLLM or APISIX for gateway logs
An AI gateway sits between applications and model providers and is the natural place to log each query, the caller identity, the model used and the policy decision. LiteLLM provides cost tracking, guardrails and logging, and Apache APISIX offers an AI gateway under Apache-2.0. Confirm which events the gateway records, where they are stored, and how long they are retained. Retention rules for these logs should be set with compliance and legal teams, not inherited from defaults.
Langfuse for query traces
Langfuse records traces of retrieval and generation steps, including which chunks were returned and how the answer was built. That helps reconstruct a disputed answer. The MIT license covers the core, but its ee directories are under separate terms, so confirm which features you run. Keep trace storage in your own database, and treat prompts and retrieved text as client data with the same access and retention rules as the source documents.
DataHub or OpenMetadata for lineage
Both catalogs are Apache-2.0 licensed and can record where each embedded collection came from, which source system fed it, who owns it and when it was last re-embedded. That lineage answers the questions examiners ask about data origin and deletion. Confirm that the connectors you need for your document stores exist and that catalog metadata stays inside the bank's boundary. Also check that catalog entries are updated when a source document is removed.
Phoenix only for internal use
Arize Phoenix is licensed under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service. An internal tracing deployment for bank staff is generally a different situation from offering it to clients, but the license terms should be read with counsel before any customer-facing use. Confirm the intended users, the hosting model and whether a partner or managed provider will operate it.
How a financial institution rolls out vector search in phases
The sequence moves vector search from a scoped, documented decision to a production service whose access rules, backups and audit trails have been tested before any client document is loaded. Each phase ends with evidence that the next one can rely on.
Scope the service and register it under DORA
The risk, compliance and architecture leads agree which document sets are in scope (client documents, research, policies), which business functions depend on the service, and whether it supports a critical or important function. The vector store and any hosting, storage or support providers are entered in the register of information on ICT contractual arrangements that DORA Article 28(3) requires. Done means a signed scope statement and a register entry that names the hosting location and the data processed, ready for the contract clauses DORA Article 30(2) requires.
Classify data and map entitlements from source systems
The data owners classify each source repository and the sensitivity of the text that will be chunked and embedded, since embeddings derived from client data inherit that sensitivity. The team then maps the access rules in the document management system, CRM or intranet to attributes that can be stored as filters on each chunk, so a user only retrieves what they may already open. Done means an entitlement matrix reviewed by the data owners and a test list of users with expected visible and hidden results.
Build a non-production environment with authentication and TLS
Engineers deploy the chosen engine (Qdrant, Milvus, Weaviate or pgvector) in a non-production environment inside the institution's infrastructure. Qdrant documents that self-deployed instances listen on all interfaces and have no authentication by default, so API keys or JWT-based access, per-collection permissions and TLS for REST and gRPC are configured before any real data is loaded. Done means a security engineer has verified that unauthenticated requests are refused and that the configuration is recorded as code.
Test restore and exit with version-matched snapshots
The operations team takes snapshots, restores them into a separate environment running the same engine version, and checks that point counts, payloads and filters match the source. They also rehearse the exit path, exporting vectors and metadata to a format another platform can read, which supports the exit strategy and transition plan DORA Article 28(8) requires for services supporting critical or important functions. Done means a written restore report with measured recovery steps, a documented exit procedure and a list of gaps with owners.
Run a controlled pilot with audit review
A small group of named users works with a limited document set chosen by the data owners. Query and API activity is captured in the engine's audit logs, and the compliance team samples those logs against the entitlement tests from earlier. The pilot also confirms that deletions and re-embedding after source changes propagate to the vector store. Done means a pilot report that records access exceptions, their root causes and the fixes applied, with the audit sample accepted by the control owner.
Hand over to production with runbooks and monitoring
Before go-live, the platform team delivers runbooks for upgrades, key rotation, backup schedules, restore drills, incident response and capacity changes, and the security team sets up monitoring and alerting on the service. Upgrades are planned against the vendor's release notes and tested in the non-production environment first. Done means a production readiness review signed by the service owner, the risk function and operations, plus a dated evidence folder that auditors can sample.
Integration points and deployment patterns for banks and insurers
Which source systems should a bank connect to a self-hosted vector database first?
Start with the repositories that hold the documents users already rely on: the document management system, the policy repository and, where advisers search client history, the CRM. Each connector should be a named, owned integration with a defined scope, such as which folders, document classes and retention statuses are indexed. Expect the largest effort in mapping metadata (owner, classification, effective date, jurisdiction) onto each chunk, because that metadata drives filtering later. Exclude records that the business has not approved for AI use, and confirm with the data owners in writing before any ingestion starts. Connector effort depends on how many systems you touch, whether they offer change feeds or only full exports, and how much the source metadata needs cleaning. Your own engineering team or DeployOpen can build these, under a fixed-scope agreement.
Where should the embedding pipeline run for regulated documents?
Run the embedding pipeline inside the institution's own data centre or cloud account, next to the source connectors and the vector store. Keep both the embedding model and its runtime in that boundary so document text never leaves it for vectorization. If you use a hosted embedding API, confirm where it processes data, what it retains and whether your contract covers it. Record which model and version produced each vector, because a model change means re-embedding the whole collection and keeping the old and new vectors apart during the switch. Ask the implementation partner how the pipeline handles failed jobs, deleted source documents and re-indexing, since those paths decide whether stale or withdrawn content stays searchable.
How do entitlements from the identity provider reach vector search results?
Entitlements should be stored as filterable payload on each vector, or enforced by collection or partition, and checked against the user's identity on every query. Qdrant supports JWT-based access control with per-collection read or write permissions, so you can separate collections by business line or sensitivity. Milvus provides role-based access control and multi-tenancy at database, collection, partition or partition key level. The sync job from the identity provider must refresh group membership on a schedule you define, and removed access must take effect quickly. Test this with users who should not see specific documents, because a filter that is applied only in the user interface is not an access control. Confirm the sync frequency and failure behaviour with your identity team before go-live.
What should gateway and audit logging capture for vector queries?
Log each authenticated query with the user or service identity, the collection searched, the time, the filter applied, the number of results returned and the source identifiers of the documents returned, without storing sensitive query text unless policy requires it. Qdrant provides JSON audit logging of authenticated API operations from version 1.17.0, so confirm that your deployed version includes it and that logs ship to your central store. Put a gateway in front of the database or the retrieval service to enforce authentication, rate limits and request tagging, and make sure gateway logs and database logs can be correlated. Retention periods come from your own record policies and regulator expectations, so confirm them with compliance. If the assistant is high-risk under the EU AI Act, Article 12 and Article 19 set logging duties for the system, so check that scope with counsel.
Which backup targets and storage do self-hosted vector stores need?
Qdrant needs block-level storage with a POSIX-compatible file system, SSD or NVMe drives are recommended, and it cannot run on network file systems such as NFS or on object storage such as S3. Use those services only as backup targets, not as the live data path. Take snapshots on a schedule, store them in an encrypted location separate from production, and test restores into a non-production cluster at the same version. Milvus uses object storage such as MinIO, S3 or Azure Blob for its data layer, along with etcd for metadata and a write-ahead log, so its backup scope is wider. Under DORA, the contract must state where data is processed and returned, so confirm restore time and data return procedures with the provider and your exit plan. Ask for documented restore test results rather than assumptions.
Can the vector database run in our own data centre or cloud account?
Yes, a self-hosted vector database can run in your own data centre or in a cloud account you control, which keeps embeddings and backups inside your boundary. Qdrant documents three production paths: the managed Qdrant Cloud, a community Kubernetes Helm chart and an enterprise Kubernetes operator offered as part of Qdrant Private Cloud. The Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so weigh that gap against your operations capacity. Qdrant Hybrid Cloud runs managed clusters on your own infrastructure, priced through Qdrant sales. Ask any partner to confirm which features your chosen path includes, and how upgrades, patching and on-call are split between your team and theirs. DeployOpen plans, implements, hardens and supports self-hosted platforms in the client's own cloud accounts, data centers or air-gapped networks.
Does a self-hosted deployment need a production cluster from day one?
Not necessarily, but a production cluster needs planning from the start. Qdrant's distributed deployment docs recommend at least three nodes for production so that quorum survives a node failure, and a shard count that is a multiple of the node count. A single node is suitable for a pilot on non-sensitive or synthetic data, but it does not provide high availability. Plan the target topology early, because moving from one node to a cluster changes networking, storage and backup procedures. Confirm with your architect how many nodes, which storage class and which replication factor you need, and remember that a replication factor of 2 doubles storage. Your own team or a partner can run this under a written scope.
Which evidence auditors and supervisors will ask for
This table maps each evidence item a bank or insurer is likely to be asked for to the component that produces it and the gap teams most often find. Read it as a checklist to agree before the assessment starts, not as a list of guaranteed passes. DeployOpen prepares the evidence, but auditors, supervisors and certification bodies issue the conclusions.
| Evidence item | Produced by | What the reviewer will check |
|---|---|---|
| Access control configuration | Qdrant admin and read-only API keys, JWT per-collection permissions (v1.9.0+), Milvus RBAC configuration | Exported role and permission settings, who can read or write each collection, and that no instance runs without authentication |
| Key and credential rotation records | Secrets manager or vault, Qdrant API key rotation logs, TLS certificate records | Rotation dates, owners, revoked keys and proof that default or shared credentials were replaced |
| Query audit logs and retention | Qdrant JSON audit logging (v1.17.0+), Milvus logs, gateway logs such as LiteLLM or APISIX | Which user or service queried which collection, when, and whether logs are shipped to protected storage for the retention period set by policy |
| Backup and restore test records | Qdrant snapshots, backup job reports, restore test runbooks and results | Dated restore tests, recovery time and point achieved, and proof that restored data was version-matched and checked |
| DORA register entry and data-location clauses | Organization's ICT third-party register, provider contracts, DeployOpen engagement documents | Entry for each ICT arrangement under DORA Article 28(3), stated hosting location and data processing location in contracts under Article 30(2) |
| Exit plan documentation | Documented exit strategy and transition plan, data export and return procedure | Tested exit steps for a critical or important function under DORA Article 28(8), including how vectors and source links are returned or deleted |
| Change records | Change tickets, version upgrade notes, configuration-as-code history | Approval, testing and rollback evidence for upgrades, re-embedding runs and changes to filtering or access rules |
How entitlement-aware filtering keeps retrieval within what each user may see
Entitlement checks belong inside the retrieval call, not in the chat interface. If the assistant retrieves the top matches across all collections and then hides some answers in the front end, the restricted text has already been returned to the application, may appear in logs and prompts, and can leak through citations or follow-up questions. The filter must be a condition the vector engine applies before ranking, derived from the caller's identity as verified by the bank's identity provider, and the application should never accept a user-supplied filter value as the authority. Each user's effective groups should be resolved server-side at query time, so a revoked entitlement stops applying on the next request rather than after a cache expires.
Map user groups to the structure the engine can enforce. Common options are one collection per confidentiality tier (for example, research available to all staff versus restricted deal material), partitions or partition keys for business lines or client segments, and payload fields such as department, client_group or classification that the query filters on. Qdrant can scope API keys and JWT claims to per-collection read permissions, and Milvus supports role-based access control and partition-level multi-tenancy, but the exact combination of payload filters, JWT claims and partition keys that is safe on your engine and version must be confirmed against its current documentation and tested, not assumed from this summary. Collections are the strongest boundary; payload filters are the most flexible and the easiest to misconfigure.
Permission changes must reach the index. When a user leaves a desk or a document's classification changes, the affected points need their payload updated or moved to another collection, and the copies in snapshots, backups and any re-embedding queue need the same treatment, otherwise a restore can reintroduce access that was withdrawn. Test with negative cases: a user without entitlement asking for the exact title of a restricted document, a query that paraphrases its content, a revoked user with a cached session, and a filter field omitted or malformed in the request. Record the expected and actual results as evidence, because a passing positive test alone shows nothing about what users cannot see.
What financial institutions ask before hiring help for vector search
What drives the cost and effort of a self-hosted vector search project?
Scope is the main driver: how many source systems feed the index, how many document types need parsing, and how complex the entitlement rules are. Entitlement-aware filtering, where each user only retrieves what they may see, usually adds the most design and testing work because permissions must be mirrored from identity and document systems. The operations model also matters, since a single node run by your team costs differently from a replicated cluster with monitored backups. Ask any partner for a quote that itemizes source systems, entitlement design, embedding pipeline, environments, backup and restore testing, and handover. Infrastructure is recurring and paid to your cloud or data center provider, while the implementation fee is one-time under a fixed-scope agreement.
Can a bank run a self-hosted vector database without an outside partner?
Many institutions have the platform skills in house, but the work tends to stall on the parts that are unfamiliar: deployment on block storage, authentication, per-collection permissions, and restore testing. Qdrant documents that a self-deployed instance listens on all network interfaces and has no authentication configured by default, so hardening is not optional. Qdrant's own documentation lists a community Helm chart and an enterprise operator, and the chart lacks features such as zero-downtime upgrades and automatic shard rebalancing. Decide early whether your team will operate the cluster after go-live, and whether an outside partner will cover design, hardening, and handover only.
How long does a rollout take?
Duration depends on the agreed scope and plan, not on a fixed template. A single collection fed from one document repository with simple access rules is a much smaller job than a multi-system deployment with entitlement mirroring, audit logging, and a disaster recovery test. Ask for a written plan with milestones, the environments included (development, test, production), and the acceptance criteria for each stage. Dependencies such as identity provider integration, security review cycles, and change approvals often set the pace more than the software does, so ask the partner to list them explicitly.
What does the work require from our own teams?
Expect time from four groups: data owners who confirm which documents may be indexed and who can see them, identity and access engineers who provide group and attribute data for filtering, platform engineers who provide compute, block storage, networking, and secrets handling, and risk or compliance staff who review evidence. The embedding pipeline also needs an owner who understands how documents are chunked and re-embedded when sources change. Agree on these named roles and the time each person commits before the statement of work is signed.
If the license is free under Apache-2.0, why pay for support?
Qdrant is licensed under Apache-2.0 and the open-source engine is free to self-host, but the license covers the software, not the operation of it. Your costs sit in infrastructure, implementation, security hardening, monitoring, upgrades, and on-call response, all of which are paid to people or providers. Qdrant's pricing page also lists Hybrid Cloud and Private Cloud options priced through its sales team, which is a separate commercial choice. Compare the total cost of your own staff time against a fixed-scope implementation or an ongoing support retainer, and confirm licence terms for any other components in your stack.
How does DORA affect our contract with an implementation partner?
DORA applies to financial entities in the EU since 17 January 2025, and its contract rules are set out in Article 30. Under Article 30(2), each ICT services contract must state where services are provided and data processed, require advance notice of changes, and cover data return on insolvency or termination. Article 28(3) requires you to keep a register of information on all ICT contractual arrangements, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. Ask your partner to draft these terms with you and to confirm that the exit plan covers vector stores, snapshots, and embedding data. This is a legal and compliance matter, so confirm the final wording with your counsel.
What audit trail should a vector search system keep for queries?
Record who issued each query, the collection searched, the time, and the access decision, and store those logs in a system that your retention rules can cover. Qdrant documents JSON audit logging of authenticated API operations since v1.17.0, which is a starting point, but you should confirm it captures the fields your audit team needs. For high-risk AI systems, Article 12(1) of the EU AI Act requires automatic event logging over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether your system falls into that category is a question for your legal team, so confirm it early.
How DeployOpen scopes and supports vector search in regulated institutions
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms inside the institution's own cloud accounts, data centers or private networks. For a vector store holding client documents, research and policies, that means the database, its embedding pipeline, its backup target and its access layer are all deployed where the bank or insurer already controls data residency. Work starts from a written scope that names the components in play, such as Qdrant or pgvector, the RAG application in front of it, the identity provider used for entitlements, and the backup and restore path. Deliverables and timelines are agreed in writing before work begins, so the institution's risk, procurement and architecture teams can review exactly what will be built and what will be handed over.
DeployOpen also prepares systems and evidence for assessments, but it does not issue audit reports, attestations or certifications. For a DORA-scoped entity, that means producing the configuration records, access rules, restore test results and monitoring output that the institution's internal audit, its independent auditors and its supervisors will sample, while the assessment outcome remains with those parties. The same applies to any control framework the institution is held to. Ask any partner, DeployOpen included, to show which artifacts it will hand over, who owns each one after handover, and which items the institution must still generate itself. Security testing of the RAG application and its API is available as a separate, scoped engagement, covering prompt injection, entitlement bypass through retrieval, and exposure of the vector database endpoints. Ongoing support, upgrades and continuous testing are available as retainers, which suits a store that will be re-embedded, patched and re-restored over several years. Confirm during scoping who holds the on-call duty, how version-matched upgrades are tested against a restored snapshot, and what the retainer covers before signing.
