FileGPT.dev designs and implements private RAG systems for technical document workflows. This page explains the architecture principles, security controls, and practical limitations in transparent technical terms.
1. Architecture principle: sovereignty by design
Every customer project receives its own isolated infrastructure — no shared multi-tenant stack. The system architecture follows these principles:
- Documents enter from approved sources (DMS, file system, ERP export) into the defined environment.
- Parsing, OCR, and normalisation run within the agreed infrastructure boundary.
- Embeddings are generated locally or within a customer-controlled cloud tenant — not via external public APIs unless explicitly agreed.
- The vector index is stored separately by tenant, project, and permission model.
- The language model receives only the document passages approved for the specific request.
- Answers include source references; access events and changes are recorded in an auditable manner.
2. Security principles
- Least privilege: authenticated endpoints and role-based access controls are applied across all document and retrieval operations.
- Data minimisation: the language model receives only the excerpts relevant to a request — not complete document archives.
- Physical and logical isolation: documents, embeddings, and models remain within the defined system boundary. No transfer to third-party tenants or public APIs without explicit agreement.
- Defence in depth: input validation, rate limiting, and controlled storage access reduce abuse risk.
- Permission inheritance: existing roles from DMS, ERP, or identity providers (OIDC, Entra ID) are inherited — the AI does not create new access rights.
3. Data storage and processing
- Documents are stored in the agreed environment; deletion occurs on Customer instruction or after contractually defined retention periods.
- Extracted text, document chunks, and embeddings are linked to source documents and removed when documents are deleted.
- Queries, responses, and audit events are logged within the system boundary.
- Telemetry and operational logs remain within the agreed infrastructure and are not transmitted to third-party services without customer agreement.
4. Encryption and transport
- Communication between client and system, and between system components, is transmitted over TLS.
- Storage and database encryption at rest is provided by the infrastructure providers of the respective deployment.
- For air-gapped environments, external network communication is eliminated entirely; the configuration is documented during the assessment.
5. AI models: selection and control
The language model is selected jointly with the customer during the assessment — based on the information classification, infrastructure, and use case. Options range from locally operated open-source models (vLLM, Ollama) to contractually controlled enterprise API services.
Customer data is not used to train proprietary models. Processing by third-party models occurs exclusively on the basis of the configuration agreed and documented within the project.
6. Monitoring and abuse prevention
- Authentication checks on all protected endpoints and server actions.
- Schema validation on ingestion and query requests.
- Rate limiting and access controls for upload, retrieval, and deletion operations.
- Operational logs for reliability and incident analysis, retained within the agreed system boundary.
7. Known limitations and residual risk
- Generative outputs can be incorrect even when source references are displayed. Human review remains necessary.
- Retrieval may select the wrong passage; tables may lose structural information during parsing.
- No security system can eliminate all risk or guarantee zero incidents.
- Configurations outside the defined stack (network, identity provider, backup systems) can materially affect the risk profile and are the customer's responsibility.
9. Security contact
Security and compliance questions can be sent to info@filegpt.dev.