Research needs room. Processing needs control.

Institutional accounts can be restricted to processing profiles that have been approved for the required geographic scope. We do not treat the location of a provider's headquarters as sufficient.

What matters is the actual processing path: provider, endpoint, model, relevant features, retention settings, and contractual framework. If an institution requires EU processing of research content, only profiles that meet that requirement are made available in that account. The restriction is enforced technically.

Acadex supports or integrates models from providers including Mistral, OpenAI, Anthropic, and Google. Which of those are available to a particular account depends on its configuration, and an institution can restrict the permitted selection.

Supporting a provider within Acadex does not mean that provider automatically processes institutional data.

No. That would be too broad a claim for a system that can work with multiple external model providers.

Acadex's central application infrastructure, primary database, and the backups we manage are operated or stored in Germany. For external model providers, the processing location depends on the specific processing profile in use. Institutional accounts with geographic requirements can therefore be restricted to approved European processing paths.

We deliberately distinguish between “research content is processed within the EU” and the much broader claim that “every technical data point always remains exclusively within the EU”. Those are not the same statement.

Yes. Provider availability can be restricted for an institutional account — for example, an institution may allow only a defined set of processing profiles.

A user cannot override that restriction from within an individual conversation. This allows model choice to remain flexible without making the institution's data-processing requirements optional.

Acadex does not use conversations, documents, or saved memories to train its own AI models.

For external model providers, the applicable handling depends on the relevant API and contractual configuration. For institutional processing profiles, we review the available training and data controls before approving the profile. For our Mistral API usage, use of API inputs and outputs for model training is disabled.

Yes. For institutional processing carried out on behalf of a customer, we provide a Data Processing Agreement under Article 28 GDPR.

It covers the scope and purpose of processing, categories of data, documented instructions, confidentiality, subprocessors, deletion, security incidents, and audit rights. The institution's approved provider configuration can be documented in its annexes.

Yes. If your institution uses its own standard Data Processing Agreement, we can review it.

What matters to us is that the contract accurately describes the processing that actually takes place. We do not require institutions to use our template simply because it is ours.

Our Technical and Organisational Measures cover administrative access, authentication, encryption, secret management, environment separation, external processing, logging, product metrics, deletion, backups, recovery, development and deployment, and incident response.

The document is versioned and describes the current state of the system. Planned controls are not presented as already implemented.

That depends partly on the institution's configuration. Our core infrastructure is hosted in Germany with STRATO.

Which model providers additionally receive an institution's personal data depends on the processing profiles approved for that institution. We therefore distinguish between the public list of services Acadex can use and the concrete list relevant to a particular institutional deployment.

No. We currently use no external web analytics platforms, advertising networks, retargeting pixels, session-recording services, or marketing tracking pixels.

We generate a limited set of operational and product metrics on our own infrastructure. Research content is not analysed for that purpose.

Our central application infrastructure and PostgreSQL database are operated in Germany. The backups managed by Acadex are also stored in Germany.

External services may have different processing locations depending on the institutional configuration. Those are documented separately.

Yes. Users can delete conversations, saved memories, and uploaded documents directly within Acadex. An account can also be deleted entirely.

Our deletion architecture includes database relationships designed to remove dependent user data, together with automated checks intended to identify user-data tables that are not covered by the expected deletion logic. Deleted information can remain in existing backups until the applicable backup rotation expires.

Account-linked product metric data is generally deleted together with the account unless another legal retention requirement applies.

Aggregated statistics may remain where they can no longer be linked back to an individual account.

Yes. Institutional seats are assigned to individual users; shared user accounts are not intended.

Chats, saved memories, documents, and watchlists belong to the individual user's workspace. Seats can be reassigned organisationally without requiring several people to share the same account.

Not yet. Institutional single sign-on through Shibboleth, DFN-AAI, or comparable systems is not currently generally available.

If SSO is a requirement for a real deployment, we want to know. A concrete rollout dependency is much more useful to our prioritisation than a hypothetical feature request.

Our administrative systems are protected with multi-factor authentication. MFA for individual Acadex user accounts is not yet generally available.

We document that as an open point rather than implying otherwise.

Not currently. Acadex does not yet hold ISO 27001 certification or a SOC 2 report. We also have not yet completed a formal external penetration test.

Instead of using those labels as a substitute for detail, we document the security measures that are currently in place.

Yes. Institutional customers can pay by invoice.

We can include information such as billing addresses, purchase order numbers, procurement references, and other required billing details. A credit card is not required.

Not as a standard product today. We do not currently publish a general uptime guarantee.

If a deployment has specific requirements around availability, support, or response times, we can discuss them. We would rather define an SLA once the underlying infrastructure and monitoring can support the commitment than publish a number first and build around it later.

Yes. Security, privacy, and procurement questionnaires can be sent to info@acadex.io.

Where the answer already exists in our documentation, we will point you to it. Where it does not, we will answer separately.