Help CentreQ-Hub AI — Security, Architecture and Data Handling
Q-Hub AI is off until your administrator turns it on. When enabled, your data is stored, indexed and embedded entirely within the UK (AWS London). Only the small amount of context needed to answer a specific question is sent to Google Vertex AI's London endpoint for the model to reason over. Every AI answer is filtered by the same permissions the user already has, and AI never publishes a compliance change on its own it drafts, a person approves.
Your data is never used to train AI models. Context sent to any LLM used now or in the future, will be used solely to generate a response to the specific request. It is not retained by the model provider, used to improve models, or shared with any third party for training purposes.
1. Who this page is for
This page is written for IT, security and data protection teams reviewing Q-Hub's AI features. It explains what the AI can see, how it works, where data is processed and stored, and what controls you have. If you need contractual detail, see the Data Processing Agreement (DPA) and Sub-Processor List in this knowledge base.
2. AI is off by default
No AI feature is available on your account until an administrator explicitly enables it. Until that point, no Q-Hub data is prepared for AI, indexed for AI search, or sent to any model provider.
Once enabled, control stays with your administrators in Admin → AI, where they choose which parts of the platform the AI cannot access, manage Knowledge Bases, and monitor usage.
3. What the AI can see
Data type | What is included | How it is triggered |
|---|---|---|
System data |
| Enabling AI for the company |
Document content | All text that could be recognised from your document context. | When an administrator adds a document, area, folder to a knowledge base. |
Not included today: the full contents of files stored in DocHub (PDFs, Word documents and similar). Only document metadata is indexed. Full file content will be introduced later via the Knowledge Base feature, and will remain opt-in.
4. How it works
Q-Hub uses a retrieval-augmented generation (RAG) architecture built specifically for compliance data. In plain terms, the platform prepares a searchable index of your own records, finds the handful that are relevant to a question, and asks a language model to reason over just those.
Prepare. Eligible records are converted into plain text and split into meaningful chunks, with metadata attached recording which company, module, record and version each chunk came from. This runs on a nightly cycle and when records change.
Index. Those chunks are turned into numerical embeddings (via Voyage AI models running on Q-hubs defined and controlled infrastructure on AWS) and stored in MongoDB. This is what makes search work by meaning rather than exact keywords.
Retrieve. When a user asks a question, Q-Hub searches that index, always scoped to your company alone, and filters the results against that individual user's access permissions before anything is assembled.
Generate. Only the retrieved, permission-checked context is sent to our UK hosted AI infrastructure (currently via Google Vertex AI), for the model to reason over and write an answer. Answers include citations back to the source records where available.
Some features work differently and involve no language model at all — the AI search bar is pure vector search, with no model call and no generated text.
5. Where your data is processed and stored
Component | What it does | Region |
|---|---|---|
AWS infrastructure | Core platform, file storage, AI job orchestration, embedding generation (SageMaker) | UK — London (eu-west-2) |
MongoDB Atlas | Your records and the AI vector index | UK — London (eu-west-2) |
Google Vertex AI (Gemini) | Reasoning and text generation only. Receives the retrieved context for a specific request; it is not a store of your data. | UK — London regional endpoint (europe-west2) |
All storage, embedding and indexing of your data stays within the UK. The Vertex AI integration is configured against the London regional endpoint.
Other AI-related sub-processors
A further provider appear on our Sub-Processor List and is worth explicitly mentioning, because it is not part of the in-platform AI features described above:
Anthropic (Claude) — is an internal Q-hub tool that is used only to format and normalise metadata during certain onboarding activities. It is not part of day-to-day AI features and can be opted out of. Turning AI on for your application does not in any way connect or provide Anthropic access to your data.
The full list, including processing locations, is maintained on the Sub-Processor List page. To be notified of changes, email support@q-hub.co.uk.
6. Separation between customers
Q-Hub is multi-tenant, and the AI layer inherits the same isolation as the rest of the platform:
Every AI request derives the company from the authenticated user's session token. It is never taken from anything the browser sends, so a request cannot be manipulated to reference another company.
Vector search is always scoped to a single company. One customer's data, derived context or AI output never informs another customer's results.
Every indexed chunk carries the owning company on it, and retrieval filters on that before results are returned.
7. Access control — users only see what they could already see
AI does not act as a bypass around your permission model. Retrieved results are filtered against the requesting user's own access rights before they reach the model or the screen. Records that are hidden or archived are excluded from the retrievable set, and permission checks are designed to fail closed — if access cannot be confirmed, the record is withheld rather than shown.
Access is decided by the platform before retrieval, not by asking the model to police itself.
8. Human oversight — AI drafts, people approve
This is a deliberate design rule rather than a configuration option. The model is treated as a suggestion engine, never an authority.
AI can generate reports, summaries, assessments and drafts automatically.
AI cannot publish or finalise live compliance records. Publishing a document, form or process change, marking compliance status as final, or closing an issue all require human approval.
Actions that change data require explicit user confirmation before they are committed, and run with that user's own privileges — never an elevated service account.
Anything the model produces that is written back to the database is validated server-side against a strict schema, with ownership fields set by the platform and any record references re-checked against the user's access.
9. Handling untrusted content
Documents, uploaded reports, OCR output and form content are treated as data, not instructions. Where an external file is processed — for example importing a third-party audit report — its text is explicitly delimited and the model is instructed not to act on any instruction contained within it. This protects against prompt-injection attempts hidden inside uploaded content. Generated text is also sanitised before being displayed.
10. Retention and removal
Indexed content exists for as long as the underlying record is live in your account. It is derived from your data and is subject to the same retention terms.
Deletion propagates. When a record is deleted, or a form or process is up-issued to a new version, the associated index entries are removed. When a record is archived, its index entries are hidden and excluded from search; unarchiving restores them.
Removing a feature from AI Brain stops its entry and row content being refreshed into the index.
Disabling AI stops all AI processing for your account.
11. Logging and audibility
Every AI call is logged with the company and user that triggered it, along with usage volume. For features that generate content written back into the platform, both the model output and the stored result are recorded, so a specific generation can be reviewed after the fact. Platform monitoring and alerting run through Q-hub standard report and logging systems.
12. Underlying security controls
Data encrypted in transit and at rest, consistent with the wider platform.
No secrets, internal identifiers or infrastructure detail placed into model prompts.
Rate limits and size caps on AI endpoints and on ingestion volume.
Every AI feature is assessed against the OWASP Top 10 for LLM Applications before release, covering prompt injection, sensitive information disclosure, improper output handling, excessive agency and unbounded consumption.
13. Certifications and legal basis
Intelligent Quality Ltd (trading as Q-Hub) holds ISO 27001 and Cyber Essentials certification, and operates in line with the UK GDPR and the Data Protection Act. Q-Hub acts as processor and you remain controller of your data. Our Data Processing Agreement covers AI processing alongside all other processing activities, and our sub-processor obligations extend to the AI providers listed above.
14. What your team controls
Whether AI is enabled at all.
Which forms, processes and registers content, you do not want to be passed to an LLM.
Which Knowledge Bases exist and what they contain.
Which users can access AI features, through your existing user access levels.