2,670
sections from 70 documents in our own knowledge base
the corpus of the assistant answering on this site
Hosting in Germany
Privacy & Hosting for Your AI Assistant
An AI chat assistant processes the requests of your visitors — which is why XICBOT aligns hosting and data processing rigorously with the GDPR: hosting in Germany, a data processing agreement under Art. 28 GDPR, data sovereignty in your hands, a clear deletion policy, and no sharing or selling of data.
In plain language
A chat assistant processes data from your visitors. That is why we align hosting with the GDPR. The data is stored on servers in Germany. A provider of language models writes the answers. This can also be outside the EU, based on contracts under the GDPR. We sign a data processing agreement with you. The data belongs to you, and you decide how long it is kept.
Ask your privacy questions View pricing
- Answers with a source reference
- Loads only after your consent
- No minimum term, cancellable monthly
The answers are generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses.
- 8 of 8
- questions without a basis declined instead of guessed
- XICBOT, own measurement series of 11 September 2026
-
Visitor:Where does the data from this chat actually end up?
-
Assistant:On servers in Germany; to produce the answer, the transcript also goes to a specialised model provider, possibly outside the EU on the basis of standard contractual clauses. The conversation is stored so the context still holds in the next sentence; who may read it is set out in the privacy policy.
-
Visitor:Can I have it deleted?
-
Assistant:Yes. I will name the route with its reference and pass the request to the operator — the decision is made there, not by me.
- Privacy policy · section on access and deletion linked · request handed over
-
Visitor:And if I withdraw my consent while you are in the middle of answering?
-
Assistant:Then the sentence in progress stops. The withdrawal is recorded before anything else happens; the half-written answer is not finished but carries a state of its own from then on. If the operator never required consent, there is nothing to withdraw — the interface rejects the attempt instead of pretending it did something.
- Withdrawal recorded · answer run in progress aborted · state of the answer: revoked
Ask it yourself, Assistant of this website
Automated assistantHow XICBOT Protects Your Data
An AI chat assistant only relieves your team if it does not turn data protection into a problem. As soon as an assistant talks to people on your website or in your shop, it processes personal data — questions, contact details, sometimes order or appointment requests. That is why XICBOT is built from the ground up so this processing is transparent, minimal and aligned with the General Data Protection Regulation. In concrete terms: hosting in Germany, a specialised model provider for the answers that may also work outside the EU on the basis of standard contractual clauses, a data processing agreement under Art. 28 GDPR, a clear deletion policy and the commitment that we neither share nor sell your data. Why this standard matters to us is explained under About us.
Data protection is not a single setting but an interplay of location, contract, technology and clear rules. We look at each of these layers and align them so your assistant is helpful in everyday use without accumulating data unnecessarily. The following building blocks are the starting point in every XICBOT project and are shaped concretely with you — to fit your industry and the tasks your assistant is meant to take on.
Hosting in Germany
Hosting and storage take place on servers in Germany. The answers are generated by a specialised model provider; processing may also take place outside the EU, safeguarded by standard contractual clauses under Art. 46 GDPR.
- The data processing agreement names the sub-processors individually
- Its sections on measures, retention and sub-processors are produced at delivery time from the same configuration the deletion runs work from
- Whatever cannot be evidenced in the delivered state sits in it as a placeholder rather than as a commitment — the agreement counts the open points itself
Data Processing Agreement
We conclude a data processing agreement with you under Art. 28 GDPR. You remain the controller under the GDPR, and we process the data solely on your instructions for the agreed purpose.
- The contract text lives in the source, not in the database: for every accepted version it stays readable which wording belonged to it.
- Acceptance is refused when the wording and the version number diverge.
- Three sections are generated only on delivery: the measures, deletion and return, and sub-processing.
- The deletion section lists your retention periods one by one and states where none has been set.
- You remain the controller as the operator of the embedding site; the access report names you.
Data Sovereignty With You
The content and conversation data belong to you. You decide which sources the assistant uses, which actions it may perform and how long data is retained.
- Which sources the assistant may read is your decision, source by source.
- Writing tools are set to confirmation ex works; without it only read tools explicitly set to automatic will run.
- Every tool call leaves a log line that is written before execution and updated afterwards.
- You can request your account's entire holdings as an export; it counts as complete only if no section failed and no table is missing.
- Secret columns such as keys and passwords never appear in that export.
Deletion Policy With Periods
Together we define retention periods and deletion rules. Data that is no longer needed is deleted in a governed way instead of being stored indefinitely — data minimisation as a principle.
- Eight kinds of object carry a retention period of their own; seven of them are set by you.
- An empty period explicitly means that there is no period: then no run removes anything. That is the factory state for enquiries, uploaded files and visitor attachments.
- For a new account the conversation period is pre-set to 90 days — it also applies to test and API conversations without a period of their own — and the log period to 30 days; you enter periods in days, and only your account's management may set them.
- The conversation run works daily, the housekeeping run hourly; both skip an account without a period instead of assuming one.
- If a visitor deletes their conversation, the route removes the messages, the conversation, the related knowledge gaps and the uploaded files; enquiries, appointment requests and carts stay with the operator as records of their own.
Encryption and Access Control
Transmission is encrypted via TLS, access is logged and rights are strictly limited to what is necessary. This keeps the circle of those who see data small and traceable.
- A visitor's address is never stored in clear text but as a hash with a fixed salt; with IPv6 the device part is dropped beforehand.
- There is no separate visitor table — what is not collected does not have to be protected.
- The transcript is shown to the operator masked: email address, phone number, IBAN and postal address appear as readable word placeholders.
- Clear text is seen only by someone with the role for it who states a reason; the log line is written before output, and if it fails there is no output.
- Masking takes effect before display, not before storage: the transcript remains stored until a retention period catches it.
- Error responses from the interface carry no class name, path, line number or call stack.
European or Self-Hosted Models by Arrangement
European or self-hosted language models are possible as a separate project by arrangement; they are not included in standard operation. We clarify the right framework in the initial consultation.
- The change affects answer generation alone; search, feature vector and language detection run in our own code regardless
- If the language model fails, the conversation sends the stored emergency answer — no matter which model sits behind it
- Which framework holds for your case is settled before the setup, not afterwards
The register of sub-processorsHosting is in Germany; the answers are generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses. What is handed over for this is the transcript and the excerpts from your knowledge base found for it. Which parties process data on our behalf is listed with purpose and location in the register of sub-processors in your account. If the register changes, you see the change there and can object to it.
Why the annex contains placeholdersThe annex on technical and organisational measures knows two states per item: demonstrable in the delivered build, or placeholder. A placeholder is explicitly not a promise; the contract counts the open items itself and the legal page in your account states their number. We consider that more honest than claiming a measure that cannot be shown in the build.
The consent gate sits before the first row is written
Many consent solutions ask once the data is already stored. Here the check comes first. If the operator requires consent, not a single row is created without it: no conversation, no message, no entry. The check happens before the first write and not only when the answer goes out. The same applies to a blocked visitor — they not only receive no answer, no conversation is created that would have to be deleted later.
Where consent exists, it hangs on the conversation and not on a token in the visitor's browser. A value in the browser can disappear; the conversation cannot. Recorded are the time and an imprint of the consent text, the version of your privacy policy and the page the window stood on. That makes it answerable later what someone consented to — not merely that they once did.
The opposite case belongs to the same decision. If an operator requires no consent, the conversation is created without any consent fields at all. A withdrawal then has nothing to act on, and the interface rejects it instead of reporting a success that does not exist. That is not a defect but the consequence of a decision taken before installation. We therefore work through it in the initial consultation, not in passing.
Nothing from the approach before the first word reaches the server either. Whether someone scrolls, moves the pointer or sits still is evaluated by the frame in the browser; the rule for it lives there and not in an evaluation on our side. No visitor profile is built in the process — there is no visitor table one could stand in.
The origin of an answer sits with its source
-
A knowledge source carries no retention of its own; uploaded files follow the period that applies to your account.
-
Type, label and content sit with every source, so the origin of an answer stays visible.
-
The answer check shows which source covers a question before anyone relies on it.
What a deletion does, in order
Deletion is where it shows whether a data protection promise was built or merely written. The following sequence is the route the deletion of an entire account actually takes in the source; a visitor deleting a single conversation takes the same steps on ordering and logging. What this route does not achieve is stated in the closing note below — that belongs in the same description.
-
Confirming with the word
Deleting an entire account can be started only by the owner, not by any member of the management, and only after typing the word required for it. If it is missing, the interface returns an error and deletes nothing.
-
Measuring the catalogue against the schema
Before the first delete statement the deletion catalogue is checked for completeness: missing tables, unknown tables and violations of the deletion order are measured against the database schema, not against a hand-kept list. Nothing is deleted against an incomplete catalogue. If the schema cannot be read, the verdict reads not measured, not complete.
-
The log line before the act
The line that records the deletion is written before anything is deleted, and in the same transaction. If it fails, the data stays and the response says that logging was not possible. The same order applies when a visitor deletes their single conversation. A deletion without a trace does not exist on this route.
-
Child before parent
Deletion follows the order of the catalogue, child before parent. A cycle in the schema is resolved by a dedicated step that runs before any deletion. If the database aborts the run because something was written elsewhere at the same time, the whole pass is repeated with a fresh read view instead of being left half finished.
-
What becomes a shell
User rows do not disappear, they are made unrecognisable: the email address is set to an address in the domain reserved for this, the name to a fixed placeholder, the password to a random value, the second factor is removed. The tenant itself remains as a shell with the same placeholder as its name, without an email address for invoices and without a VAT identification number until the period named in the contract has expired; after that the maintenance run removes it.
-
What deliberately remains
The activity log is the one catalogue entry that stays — the deletion itself is evidenced there. The response to the run names the holdings before and after, table by table, instead of merely reporting that something happened.
What goes with the conversation and what staysIf a visitor deletes their conversation, the messages, the conversation, the related knowledge gaps and the files they uploaded themselves go with it. The same applies when the operator deletes a conversation, an assistant is deleted or the conversation period expires. Enquiries, appointments and carts stay with the operator as records of their own and lose only the reference to the conversation. Appointments and carts follow the period for enquiries — appointments counted from the appointment date, carts from their handover; if no period is set for enquiries, no run removes them.
What remains after an account is deletedA deleted account leaves a shell with a placeholder in place of names, without user data or content; the log with the deletion entry stays with it, and as its only personal detail in plain text that entry records the email address of the person who confirmed the deletion, so that the deletion can be evidenced under Art. 5(2) GDPR. The shell stays for as long as the contract text states — 1095 days — after which the maintenance run removes it together with the log; what remains is one line in the operator trail that evidences the removal itself. The shell of an expired demo account goes 168 hours after it has been cleared. Backups hold 14 versions; deleted data only disappears there once those versions expire.
Data Protection Builds Trust, Not Just Compliance
For many companies, data protection is first of all an obligation — with an AI assistant, it quickly becomes a genuine factor of trust. Anyone who asks a question on a website or leaves contact details wants to know what happens to that information. An assistant that visibly handles data sparingly, is hosted in Germany and shares nothing with third parties lowers the barrier to entering a conversation at all. In this way, clean data processing pays off not only in legal certainty but also in the number of enquiries and completions your assistant generates.
For you as the operator, this also means less effort and less risk. Because the data processing agreement, the deletion policy and purpose limitation are settled from the start, the assistant can be added to your existing privacy policy and record of processing activities without detours. You do not have to clarify afterwards where data is stored or how long it is kept — these questions are already answered. And because we stay factual, we do not promise absolute security but a transparent processing aligned with the GDPR and the current state of the art.
Especially in sensitive industries such as practices, law firms or trade involving personal data, the handling of information decides whether a digital offer is accepted. What counts here is that the assistant is meant to hand over to a human on delicate topics rather than deciding on its own. European or self-hosted language models are possible as a separate project by arrangement; they are not included in standard operation. In this way, data protection and reliability combine into an offer your customers trust.
Reading and Acting — Data-Minimising and With Approvals
An assistant is only as privacy-friendly as the data flows it triggers. That is why XICBOT works on the principle of data minimisation: it reads only the sources you approve and performs only actions for which you have defined a function. It does not build profiles as a precaution and does not track visitors without a legal basis. How the assistant is trained from your own content and binds its answers to those sources is explained under Knowledge base & training. Typical content it reads includes:
The assistant performs actions only through clearly defined functions, each with its own approval. This prevents uncontrolled access to your systems, and every action is traceable. How the assistant is embedded technically with a short snippet, without loading a bloated third-party widget, is described on the Integration page. Typical approved actions include:
Answers From Your Sources, No Data Collection on the Side
The assistant binds its answers to your own content and triggers actions only through approved functions. The data flow is therefore manageable: requests are stored in Germany, answered bound to your content and not evaluated for external purposes; the answer is generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses. An AI assistant can be wrong — which is why we rely on source binding, handover to humans and later evaluation rather than unfounded claims.
- Website content and subpages you approve
- Shop catalogue based on Shopware Community Edition with products, prices and availability
- Opening hours, locations and contact details
- Documents, PDFs and data sheets from your knowledge base
- FAQs, help articles and internal knowledge base
- Free times, in the Custom package also calendar availability from a set-up calendar connection as well as order and delivery status from a connected inventory system
- Put together a cart in the chat and change quantities
- Apply a voucher or promotion and show shipping costs
- Take or reschedule an appointment request
- Leave a callback request as a note, once the visitor has confirmed it
- Hand a qualified lead to an inbox or, in the Custom package, to the CRM
- Create a support ticket (Custom package) and hand over to a human for sensitive topics
- Answers bound to your own, approved sources
- Actions only through defined functions with approval
- No selling and no sharing with third parties
What a visitor can do alone, without an account
In practice, data subject rights fail less often on the law than on the route to it. In the chat window, access, withdrawal and deletion hang on the conversation's identifier. Anyone with the window open needs no account for it, no login and no email to an address they cannot tell is being read.
Access to their own conversation
The access report comes from the conversation itself and from no second table. There is no separate visitor table: where nothing is collected, nothing has to be gathered together later.
- the start of the conversation and the page the window stood on
- the number of messages and the complete transcript
- the time of consent and, where present, of the withdrawal
- the operations triggered from the conversation
- the controller by name — that is the operator of the site, not the assistant
Withdrawal in mid-sentence
The withdrawal is set before anything else happens. An answer run that is currently writing aborts; the answer then carries a state of its own and not the same one as an answer that finished.
- The state of an answer is a field of its own, and revoked is one of its values.
- Consent hangs on the conversation, not on a browser value that can disappear.
- If the operator requires no consent, the interface rejects the withdrawal instead of reporting a success.
Deletion without a detour through us
A visitor deletes their conversation themselves, through the same identifier they write with. The log line comes before the deletion and in the same transaction: if it fails, nothing is deleted and the response says so.
- The messages, the conversation and uploaded files are removed.
- Enquiries, appointment requests and carts stay with the operator as records of their own.
- The same route with the same duties is open to the operator in their account.
What a visitor may upload
Attachments are switched off ex works until the operator enables them per assistant. Accepted is only what can be recognised as an image or PDF from its leading bytes — not what the file claims about itself.
- The type is measured from the content, not from the declaration that came with it.
- An attachment is never served executable: as a download, without type sniffing, without caching.
- Every storage and every retrieval appears in the log as a named operation.
The frame between page and conversation
The chat window runs in a frame of foreign origin. The embedding page cannot read the content of the frame. The conversation ID, however, sits with an expiry in the embedding page's storage, and anyone who knows it can retrieve the transcript; there is no further secret. Scripts there, including embedded third-party scripts, therefore have access to the transcript in principle.
- The notice that a machine is writing here comes from the server and cannot be removed on the embedding page.
- An error response carries no class name, path, line number or call stack.
- If the language model fails mid-stream, the half-written text is discarded and the fallback answer stored by the operator is sent.
If a data subject brings their request to us instead of to the operator of the site, we do not decide about their data but refer them back to the operator. That is written into the data processing agreement and is not a courtesy phrase: the controller decides on purpose and means of the processing, and the controller is the operator.
How We Set Up Data Protection
Data protection is not created at the end of a project but from the very start. We clarify the relevant data protection questions as early as the initial consultation, record the agreements in a contract and implement them technically. This way you know early which data the assistant processes, where it is stored and how long it is retained. The following process is the framework we tailor to your project together with you.
-
Initial Consultation and Privacy Clarification
In the free initial consultation we clarify which tasks your assistant should take on and which data is processed in the process. We discuss the hosting location, the model provider for the answers and your requirements for retention and deletion — clearly and without technical jargon.
-
Data Processing Agreement and Configuration
We conclude a data processing agreement with you under Art. 28 GDPR and define which sources the assistant may read and which actions it may perform with approval. Purpose limitation, data minimisation and access rights are defined cleanly in the process.
-
Consent: required or not
Before installation a decision is taken that cannot be made up for later: should your assistant require consent before it writes? If it does, no row is created without it. If it does not, the conversation is created without consent fields and a withdrawal has nothing to act on. We work through both cases with you, settle the consent text and the version of your privacy policy, and review what of it belongs in your record of processing activities.
-
Integration, First-Party on Request
The assistant is embedded in your website or shop with a short snippet, on request as first-party over a path on your own domain; no cumbersome third-party widget loads. We align the encrypted transmission, the consent behaviour and the embedding with your existing privacy policy.
-
Setting retention periods before the first visitor writes
Retention periods are the part of a deletion policy that actually deletes. For a new account the conversation period is pre-set to 90 days and the log period to 30 days; enquiries, uploaded files and visitor attachments have no period ex works, and without one no run removes anything. You enter the periods in days, and your account's management may set them. The data processing agreement then lists them one by one and states where none has been set.
-
Operation With a Deletion Policy
During ongoing operation, the agreed retention periods and deletion rules take effect. We operate, maintain and update the assistant on servers in Germany and remain your contact for data protection questions — even after launch.
What does not appear in this sequence is an unlocking by us. A newly created assistant is a draft: it answers only once you set it active and switch the widget on — two switches in your account, not in ours. The same holds for the retention periods, the approval of writing tools and the acceptance of the contract. We set up and accompany; each of these steps is triggered by you.
Setup once, operation monthly
Data protection is work during setup and a setting during operation. What happens once: setting retention periods, deciding on the consent gate, accepting the data processing agreement, limiting the assistant's role. What runs monthly afterwards is what carries those decisions out — deletion runs, log retention, information for visitors.
Two points cost the same on every tier because they are not settings: every deletion is logged before it happens — if the log line fails, nothing is deleted. And the plain text of a conversation can only be seen by the owner, with a stated reason and a log line. Neither can be switched off.
Start package
from 49 € per month net
Minimum term: none, cancellable monthly
- Hosting in Germany
- Data processing agreement under Art. 28 GDPR included
- Deletion policy with defined periods, no sharing, no selling
- European or self-hosted language models as a separate project by arrangement
All prices net, plus VAT Source: XICBOT price list, as of 11 September 2026
Data protection is included in every XICBOT plan. The entry-level Start package begins with a one-time setup from 990 € net and operation from 49 € per month net — including hosting in Germany, operation, maintenance, updates and GDPR-aligned data processing. More extensive plans can be found in the pricing overview; European or self-hosted language models are possible as a separate project by arrangement and are not included in standard operation. Every project begins with a free initial consultation and, on request, a free demo. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
What does the assistant load on your website?
Which address the loader comes from, what happens in the browser on the first page view and why the chat window runs in its own origin: the integration page sets it out step by step.
Third-Party Widget and XICBOT Compared
Many standard chatbots are embedded as a ready-made widget from an external provider. That is quick to install but shifts control over location, contracts and data usage to a third party. XICBOT takes the opposite route: individually built, hosted in Germany and with clear contractual rules. The comparison shows where the difference lies in everyday practice.
Third-party chatbot widget
- Hosting location: often outside the EU
- Contractual basis: blanket provider terms
- Data usage: use for external purposes possible
- Deletion: periods often intransparent
- Data sovereignty: with the provider
XICBOT
- Hosting location: Germany, answer generation also outside the EU on the basis of standard contractual clauses
- Contractual basis: data processing agreement under Art. 28 GDPR
- Data usage: no sharing, no selling
- Deletion: defined deletion policy with periods
- Data sovereignty: with you
Where the difference sits technicallyAn embedded window is either part of your page or it is not. Here the chat window runs in a frame of foreign origin: scripts on your page cannot read the content of the window, and the window does not read along on your page. The conversation ID, however, sits in your page's storage and is enough to retrieve the transcript, so scripts on your page have access to it in principle. And the notice that a machine is writing here comes from the server — it cannot be configured away on the embedding page.
Your Privacy Questions in the Initial ConsultationWould you like to know how the assistant fits into your existing privacy policy and your record of processing activities? In the free initial consultation we clarify location, model provider, retention and deletion concretely for your project — factually and without empty promises.
Further reading: GDPR-compliant AI assistants covers legal bases, data processing agreements and hosting, EU AI Act: transparency duties for AI chats explains the labelling obligations, and securing against prompt injection describes the technical safeguards against manipulated input.
Frequently Asked Questions About Privacy & Hosting
The short answers are here, the mechanics behind them further up this page: when consent is asked for, what a withdrawal does to an answer in progress, which retention periods exist and what a deletion does, in order.
One point appears in none of these answers and still belongs here: the controller within the meaning of the regulation remains the operator of the embedding site, not the assistant. The access report a visitor retrieves in the window names them; and a data subject who approaches the processor is referred back to the operator.
Where is the data hosted and processed?
Your assistant is operated in data centres in Germany. The answers are generated by a specialised model provider; processing may also take place outside the European Union, safeguarded by standard contractual clauses. European or self-hosted language models are possible as a separate project by arrangement; they are not included in standard operation. You can read this in the data processing agreement: it sits in the source, with nine fixed sections and three generated at delivery time from the same source the deletion runs work from — so the annex cannot change while the contract text goes stale. We define the right framework together in the initial consultation.
Do you conclude a data processing agreement (DPA)?
Yes. We conclude a data processing agreement with you under Art. 28 GDPR. You remain the controller under the GDPR, and we process the data solely on your instructions for the agreed purpose. It governs purpose limitation, technical and organisational measures as well as deletion and data minimisation, so you can cleanly add the assistant to your record of processing activities. Those measures are not a declaration of intent: tenant separation is enforced in every database query, not in the individual controller, the conversation history is displayed masked, and a plain-text retrieval requires the matching role, a stated reason and leaves a log line behind.
Is chat data shared or sold?
No. Your data is not sold and not passed on to third parties. The subprocessor register lists the self-operated language model gateway in Germany; behind it, the answers are generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses. Its purpose is generating the answers, what is passed on is the conversation history and the excerpts found for it in your knowledge base, and the legal basis is Article 28 GDPR. A visitor's address is never stored in clear text but as a salted fingerprint per account; for IPv6 the device part is dropped beforehand. Conversation analytics evaluate only what arises in your own account: no browser identification is read for it, and no profiles are built as a precaution.
How does the deletion policy work and how long is data stored?
Ten kinds of object have a declared retention period: conversations, test conversations, conversations through the interface, enquiries, appointments, basket handovers, uploaded files, visitor attachments, logs and login events. Seven of them are set by the Administration role, appointments and basket handovers follow the period for enquiries, login events that of the log; the interface accepts values from one to 3650 days. A new account starts with 90 days for conversations, which also apply to test and interface conversations without a period of their own, and with 30 days for the log; enquiries, uploaded files and visitor attachments have no period by default. No value explicitly means no period and deletes nothing, so an empty entry is not read as zero. Deletion is done by two runs, a daily one and an hourly one, in blocks and with a single summary line in the log instead of one line per conversation. A visitor can also delete their own conversation, without an account; their uploaded files go with it, while enquiries stay with the business. Details under privacy.
Can a European or self-hosted language model be used?
Yes, on request. As a separate project by arrangement, European or self-hosted language models are possible; they are not included in standard operation. In today's state, model access runs exclusively through a gateway of our own and through exactly one class in the code; the key for it sits in a file outside the program tree. Three model stages are configured, and a switch happens only on a temporary failure and only as long as no character of the answer has been shown yet. The subprocessor register lists our own gateway in Germany for this; behind it, the answers are generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses. Which option carries your case is what we discuss as part of the Custom package in the initial consultation.
Can the assistant be used in a GDPR-compliant way without tracking?
Yes, because there is nothing to track. The chat stores three entries with an expiry date in the browser — conversation id, consent and a visit marker — and no message content; if consent is required, the loader creates no entry of its own accord before consent, not even a visit marker. A handoff in session storage, valid for two minutes and removed on first read, is added only when a form on another page is to be filled in. The rules for proactive engagement are evaluated exclusively in the browser on your page: scrolling, pointer movement and standstill never reach the server. Analytics reads no browser identifier and stores no visitor address, only language and viewport class; an IP address is never stored in clear text anywhere, only as a hash with a fixed salt. Consent is checked before the first write. Details under privacy and hosting and integration.
Is the assistant data protection compliant?
Yes. Hosting is in Germany, with a data processing agreement, data sovereignty and a deletion concept; the answers are generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses. We do not pass on data and do not sell data. European or self-hosted language models are possible as a separate project by arrangement; they are not included in standard operation. In operation that means: an IP address is never stored in clear text anywhere, only as a hash with a fixed salt, an IPv6 address being truncated beforehand. Eight kinds of data each carry their own deletion deadline, seven of which you set yourself; every deletion at the end of a retention period is logged before it happens, and if the log row fails, nothing is deleted. The data processing agreement is laid out in twelve sections. Get in touch via the contact form.
If a question of yours is missing, it is probably one that can be answered only with your own case. The general ones are collected in the frequently asked questions; everything touching retention periods, tool approvals and your own record of processing activities belongs in the initial consultation and not in a list.
Free and Without Obligation
An AI Assistant That Considers Data Protection
In a free initial consultation we clarify how your assistant brings together hosting in Germany, a data processing agreement, data sovereignty and a deletion policy — and on request with a test assistant for your own website. Arrange a Consultation
What privacy questions does your project raise?
Tell us briefly about your project and your website address. We clarify the hosting location, model provider, data processing agreement, retention and deletion with you — factually and without sales pressure. You can reach us by phone at +49 5123 9579000.