Client Portal with an AI Assistant: secure self-service chat on your own trustee knowledge (RAG)

What is a client portal with an AI assistant?

A client portal is a secured, logged-in area where your clients exchange documents, check status and ask questions. The AI assistant is a chat element inside this portal that answers questions in natural language – but exclusively based on your own, released firm knowledge.

Technically the assistant relies on Retrieval-Augmented Generation (RAG). Instead of letting the language model answer freely, every question first triggers a search for relevant material in a searchable knowledge base (information sheets, FAQs, deadline calendars, terms, released mandate documents). Only these retrieved passages are then passed to the model as context, together with the instruction to answer solely from these sources and to cite the reference.

The difference from a generic chatbot is decisive: the assistant grounds answers primarily on the retrieved passages of your knowledge base rather than answering freely from its training data. This makes answers auditable and substantially reduces false statements – but does not eliminate them entirely. The reduction is substantial, yet domain- and quality-dependent: especially in a legal and tax context, a non-negligible residual risk of unsupported statements remains.

Important: such an assistant does not replace advice. It answers recurring, clearly documented questions in self-service and hands over anything unclear to a human.

Why this matters for trustee firms

Trustee firms answer the same questions every day: "Which documents do you need for the tax return?", "By when must the VAT statement be filed?", "How do I upload receipts?". These questions tie up qualified staff even though the answers have long been documented. A self-service assistant absorbs part of this volume – around the clock, in DE and EN.

The real leverage, however, is not only time savings but consistency and confidentiality. Answers come from a single, maintained source rather than from individuals' memory. And because the knowledge base may contain client data, heightened requirements apply: tenant isolation, access control and data protection under revDSG are not optional here but a basic prerequisite.

In Switzerland the fully revised Data Protection Act (revDSG) has applied since 1 September 2023. Among other things it requires transparency about data processing, privacy by design and privacy by default, and a clear purpose limitation. A client portal with AI must reflect these principles in its architecture from the outset – not bolt them on afterwards.

For firms that want to work with provider independence and a Swiss data location, the free choice of model and hosting components is an additional argument: a data location in Switzerland or in a state with an adequate level of protection (EU/EEA under the adequacy list in Annex 1 of the Data Protection Ordinance), with no further safeguards required for the EU/EEA; for providers in non-listed third countries, suitable safeguards under Art. 16 para. 2 revDSG are required (e.g. standard contractual clauses). This way you do not lock yourself into a single cloud provider.

Firms that serve EU clients or whose portal is accessible in the EU should also assess whether the EU AI Act applies extraterritorially. Core high-risk AI requirements (in particular human oversight, technical documentation, conformity assessment) apply from 2 August 2026. This is not a conclusive legal assessment – a specialist should be consulted.

How it works technically: architecture and security

The pipeline has five layers. First, preparation: documents are split into meaningful sections (chunks), enriched with metadata (client, visibility, language, source, date) and converted into vectors (embeddings). These land in a searchable knowledge base (vector database).

Second, retrieval: when a logged-in person asks a question, it is also translated into a vector and the most similar passages are searched – but filtered to what this person is allowed to see. Third, the answer: only the retrieved passages plus a strict system instruction ("answer solely from the sources; if the information is missing, say so and offer escalation; cite the reference") go to the language model.

Tenant isolation is the most sensitive point. The source filter must never live only in the prompt but must be enforced at the data layer: every search query carries the identity and permissions of the logged-in person, and the knowledge base returns only matching hits. This way the assistant structurally cannot cite documents from another mandate, even if someone asks for them.

RAG substantially reduces the hallucination risk compared with a generic chatbot – but does not eliminate it. Studies show residual error rates that depend heavily on retrieval quality and domain. Moreover, the knowledge base itself is an attack surface: compromised or manipulated source documents can produce false answers (knowledge poisoning), and poisoned documents can trigger prompt injection. Therefore, access control over the knowledge base, document integrity and the human escalation path are not optional add-ons but technical security obligations.

For revDSG compliance add: encryption in transit and at rest, a data location in Switzerland or the EU/EEA (adequate level of protection under Annex 1 of the Data Protection Ordinance, no further safeguards required; for other third countries, suitable safeguards under Art. 16 para. 2 revDSG, e.g. standard contractual clauses), a contract or demonstrable agreement with every processor under Art. 9 revDSG (no statutory written-form requirement under private law, but proof of authorisation required; where the GDPR also applies, a written agreement under Art. 28 GDPR), logging (who asked what) and defined retention and deletion periods. Provider independence helps you choose model and hosting so that no client data flows out for training purposes.

Practical rollout: step by step

1. 01Review the knowledge stock: collect FAQs, information sheets, deadlines, terms; remove outdated versions; mark sources with date and visibility.
2. 02Define data classes: public (for everyone), cross-mandate (for logged-in mandates) and mandate-specific (only the own mandate) – with clear access rules.
3. 03Build the knowledge base: split documents into chunks, add metadata, load as embeddings into a vector database; set the data location to Switzerland/EU.
4. 04Enforce tenant isolation at the data layer: every search query carries identity and permission; the filter applies before the language model, not only in the prompt.
5. 05Assess and, if applicable, carry out a Data Protection Impact Assessment (DPIA) under Art. 22 revDSG: AI-assisted processing of client data (new technology, large scale, sensitive financial/tax data) can present a high risk; the DPIA documents risks and measures. Where the GDPR applies: DPIA under Art. 35 GDPR.
6. 06Configure answer behaviour: strict instruction "only from sources, with reference, otherwise escalate"; language DE/EN; neutral, factual tone.
7. 07Define the escalation path: hand over to inbox/appointment/responsible person including the conversation when a source is missing, on uncertainty or on advisory questions.
8. 08Implement revDSG: agreement with the processor (proof of authorisation), encryption, logging, retention and deletion periods, a data protection notice in the portal.
9. 09Pilot with real questions: check answers against sources (faithfulness), collect misfires, refine the knowledge base and filters.
10. 10Go live and monitor: track metrics on hit quality, escalation rate and satisfaction; maintain the knowledge base regularly.

When an AI client portal makes sense

The approach fits when you receive recurring, well-documented questions in high volume and already maintain information sheets, FAQs or checklists. The cleaner your existing knowledge, the faster the assistant delivers reliable answers – RAG is only as good as the underlying knowledge base.

It also makes sense when you already run or plan to introduce a portal for document exchange. The assistant then builds on existing logins and permissions instead of creating a separate, unprotected chat island. Multilingual mandates (DE/EN) benefit particularly because one assistant can serve both languages from the same source.

Likewise suitable: procedural status questions ("Where does my tax return stand?") when the portal status is machine-readable and the assistant may reproduce it in a person-specific and correctly filtered way. This creates genuine self-service value without advisory risk.

When you should not (yet) use it

The assistant is not suited for individual legal, tax or investment advice. Such questions require case-by-case judgement and responsibility – they belong with a human. The assistant should not guess here but escalate cleanly. This is not legal advice.

Use is also problematic if your knowledge is incomplete, outdated or contradictory. The assistant will then cite sources, but the wrong ones – trust suffers more than with no assistant at all. Tidy up first, then go live.

Also refrain from productive use as long as tenant isolation, access control and a demonstrable agreement with the processor are not in place. Without enforced data separation, the most serious error looms: that one mandate's data appears in the answer to another mandate. Until this protective layer demonstrably works, the assistant must not process client-specific data.

FAQ

Related topics

Sources

1. KMU.admin.ch – Neues Datenschutzgesetz (revDSG) · 2026
2. Eidg. Datenschutz- und Öffentlichkeitsbeauftragter (EDÖB) · 2026
3. Bundesgesetz über den Datenschutz (DSG), Fedlex SR 235.1 · 2023 (Inkrafttreten 1.9.2023)
4. EUR-Lex – Verordnung (EU) 2024/1689 über künstliche Intelligenz (EU AI Act) · 2024
5. arXiv – Retrieval-Augmented Generation: A Comprehensive Survey (Preprint, under review) · 2025 (arXiv preprint, under review)