Most agencies already know what an AI assistant can do. The questions that stall the project come from security and procurement: where the data sits, who processes it, who has access, and what gets deleted. Here are the answers, with the documentation behind them.
The communications team is usually convinced long before the project stalls. What stalls it is a risk assessment with questions no vendor can answer with a brochure: which subprocessors handle the content, what remains in the logs, and how deletion is documented.
These are the current public descriptions of the solution, not proof of certification. For a formal assessment they should be checked against the data processing agreement and security annex.
MotherX states that customer data is stored in the EU and that the solution is built for GDPR.
The data is not used to train public foundation models. Necessary text fragments are processed by AI subprocessors through APIs.
AES-256 at rest is stated, and TLS over HTTPS for documents, questions and API calls.
A tenant ID separates organisations in storage, vector index and logs, and queries are scoped to the right tenant.
Separate roles for uploading, crawling and viewing logs.
Uploads, crawling, questions and administrative changes are logged.
The GPT Module is stated to support Microsoft 365 and Google Workspace. Check plan and setup.
Data and conversations can be deleted. The exact process and deadline are confirmed in the agreement.
What the assistant should answer, and which documents and pages it answers from. The scope is what governs the risk.
Data processing agreement, subprocessor list and security annex. We send the current versions so they can go into the risk assessment.
One service or one subject area first. That gives real numbers on accuracy before you widen the scope.
Access is set per role, and the activity log gives traceability on what has been uploaded, changed and asked.
The same questions arrive at the service desk, in the mailbox and internally in the subject departments. The dashboard collects them, so you can see which routines and pages are not clear enough instead of guessing from individual cases.
MotherX states that customer data is stored in the EU and that the solution is built for GDPR. To clarify every processing location and subprocessor you should use the current data processing agreement and subprocessor list. We send both on request.
No. The data is used to find relevant context and generate answers in your own solution, not to train public foundation models. Necessary text fragments and questions may still be processed by AI subprocessors through APIs, which is not the same as training. The subprocessor list shows who is involved.
The technical security mechanisms are documented, but should not be read as proof of certification. If you ask about certification, penetration testing or audits, we send the current security documentation and answer concretely on what exists today rather than implying more.
A private cloud can be agreed on Enterprise. It is a project to be scoped, not a standard delivery, so scope and price are set in dialogue.
Normally you are the controller for your use of the solution, while MotherX acts as processor under agreement. The division of roles should be confirmed legally before it goes into a contract, and the data processing agreement is the starting point.
We send the data processing agreement, subprocessor list and security documentation, so the risk assessment can start on real ground.
Try for free →