AI on your own data, without it leaving the company.
A private AI platform on your documents and systems: QM records, technical documentation, ERP, service reports. It answers like a colleague who has read everything, with a source reference per statement. Operated where your data lives, and no vendor trains on it.
- Answers only from your sources, with a reference per statement
- Permissions from your systems also apply in the AI
- Operated on-premises, in a private cloud or EU cloud
One data layer, two access paths
The knowledge is there. It is just scattered.
In medical technology, a company’s knowledge lives in evidence: technical documentation, QM records, supplier files, service reports. Every system has its own silo, and whoever needs an answer searches several of them or asks the person who knows.
Search instead of answers
Full-text search in the DMS finds documents, not answers. Whether the SOP found is the valid version, you check yourself.
Knowledge tied to people
Who knows which risk file holds the rationale is often a single person. When they leave, the access leaves with them.
Public AI is not an option
Complaint data, patient references, product internals: none of that may go to a vendor who trains on it. So AI stays out of exactly these documents.
Questions the platform answers
Examples from the areas where medical device manufacturers spend the most time searching.
- Quality management
„Which CAPAs for this product are open, and what was the root cause of the last three?“
- Technical documentation
„Where is the rationale for the risk classification of this component, and in which version?“
- Suppliers
„Which evidence is missing for the requalification of this supplier?“
- Service
„Which service reports exist for this serial number, and what was replaced last?“
- Sales
„What did we last offer this customer, and on which terms?“
- Regulatory
„Which of our instructions for use still reference the old version of the standard?“
Every answer names the source: document, section, version. Whoever may not see the source doesn’t get the answer either.
Not all data belongs in a vector database
A knowledge platform has to answer two kinds of questions: about knowledge that lives in text, and about facts that live in tables. Forcing both into the same technique yields plausible instead of correct answers for numbers. Hence two paths that meet in the same context of the model.
Unstructured data: semantics
- Parsing to Markdown, structure and metadata preserved
- Context-preserving chunking, embedding, vector index
- Hybrid search: semantic plus full text, metadata filters, reranking
Structured data: determinism
- Fixed data model instead of embeddings, no loss of accuracy
- Access via typed MCP tools (function calling)
- Deterministic answers to fact and number questions
Generation
- Answers only from retrieved context (grounding)
- Source reference per statement
- Permission scope already in retrieval
- Model-agnostic: local open-source models or EU API
Semantics for knowledge, determinism for facts. Only the combination carries real business processes.
Six layers, one platform
Every further source system docks onto the data layer. The architecture stays the same wherever it runs.
- Interface
Chat interface with role and permission scope, dashboards and reporting
- Orchestration
LLM gateway, model-agnostic: local open-source models and EU API models, routing by data class
- Access
Retrieval with hybrid search, metadata filters and reranking; MCP tools on the relational data model; MCP servers as wrappers for live APIs
- Data layer
PostgreSQL with pgvector: documents, chunks, embeddings, data model, history. Object storage for originals
- Ingestion
Delta sync on schedule, webhooks where available, error handling and resumability
- Source systems
QM system, DMS, ERP, PLM, file share, wiki, specialist systems
In stages, with a usable result at every stage
About four months to an extensible foundation. Every stage ends with a result you can use and a go decision for the next one.
Decision basis
System landscape, use cases and architecture decision: which sources first, which models, where operation runs.
Foundation
Platform, data layer, security and access concept. The permissions of your systems are adopted, not reinvented.
MVP
First system connection and productive use in one department, with real questions and real documents.
Expansion
Further source systems, operation and knowledge transfer to your IT.
- Go decision at every stage, no long-term commitment
- Effort visible at all times
- Duration is not effort: calendar time includes alignment and evaluation with the department
Same platform, a different focus depending on your role.
The knowledge stays in-house, and it becomes usable.
Your most experienced people spend less time searching and more on what you hired them for.
- No data leakage. The platform runs where your data lives. No vendor trains on complaints, risk files or customer data.
- Answers you can cite. Every statement has a source. That makes answers reliable in audits and in the team, not just plausible.
- A foundation, not a one-off. The data layer carries the first use case and every further one. The second source system costs a fraction of the first.
- ·Which documents and systems should be reachable first?
- ·Who may see what, and where is that defined today?
- ·On-premises, private cloud or EU cloud?
- ·Which department runs the MVP?
Open building blocks, no black box.
You can trace, replace and operate every component yourself.
- Model-agnostic. Local open-source models such as Llama, Mistral or Qwen, or EU API models. Routing by data class, switching without rebuilding.
- Permissions in retrieval. The scope from Entra ID or your identity provider applies at retrieval, not only in the interface. What someone may not see never enters the context window.
- Operation in your hands. PostgreSQL, object storage, containers. Documentation, deployment and knowledge transfer are part of the last stage.
- ·PostgreSQL with pgvector, object storage
- ·Hybrid search, reranking, metadata filters
- ·MCP tools and MCP servers for live APIs
- ·Llama, Mistral, Qwen, DeepSeek; Claude, GPT, Gemini via EU API
- ·Azure, AWS, Hetzner, on-premises
The private AI platform is a capability, not a package. It is part of AI adoption as the knowledge connection of a platform like Langdock, and it carries custom development projects.
Which documents should be able to answer first?
That’s what we work out in a first call: which sources, which questions, which operation. Feel free to bring one or two typical questions from your daily work.