Trust

Being integrated is not the same as processing your data.

Last updated: September 2026

Acadex uses external services for specific parts of the product.

But a service being technically supported does not mean that it receives data from every user.

For model providers in particular, we distinguish between three things:

supported — Acadex can technically work with the provider.

approved — the provider or processing profile is permitted for a particular account.

used — data is actually sent to that provider for a particular request.

For institutional accounts, the approved set can be restricted technically.

This page explains the external services involved in Acadex, what they are used for, and where processing depends on configuration.

Core infrastructure

STRATO GmbH

Acadex’s central application infrastructure is hosted with STRATO GmbH.

This includes the application environment and primary database infrastructure used by Acadex.

The backups managed by Acadex are also stored in Germany.

STRATO acts as an infrastructure and hosting provider.

For the Acadex infrastructure described here, we use hosting in Germany.

Purpose: application hosting, database infrastructure, backups

Processing location: Germany

Model providers

Language models are one component of Acadex.

Depending on the task and account configuration, Acadex can work with models from different providers.

Conversation content or other request data is sent to a model provider only when that provider is actually used to process the request.

Simply appearing on this page does not mean that a provider receives data from every Acadex account.

Mistral AI

Acadex can use models provided through the Mistral AI API.

For the Mistral API configuration used by Acadex, use of API inputs and outputs for model training has been disabled.

Mistral hosts customer data in the European Union by default, but individual features can involve different processing or transfer conditions.

We therefore do not turn that general statement into a blanket claim that every possible Mistral feature always remains exclusively within the EU.

Mistral also offers regional inference and Zero Data Retention for eligible API usage.

Those are separate controls.

A regional endpoint determines where supported inference is processed.

Zero Data Retention determines whether supported request and response content is retained after processing.

Using one does not automatically imply the other.

For institutional accounts with stricter requirements, Acadex can restrict use to a processing profile that has been reviewed for the required endpoint, model, features, training settings, and retention controls.

OpenAI

Acadex can work with models provided through the OpenAI API.

OpenAI does not use API inputs and outputs to train its models by default unless the customer explicitly opts in.

Standard API usage and specialised data-retention configurations are not the same thing.

OpenAI offers additional data controls, including Zero Data Retention for eligible organisations and endpoints.

OpenAI also offers European data-residency options for eligible API projects and supported endpoints.

Acadex does not describe an OpenAI EU processing profile as available merely because OpenAI offers the underlying capability.

Such a profile is only made available once the corresponding Acadex project, endpoint, models, retention controls, and processing path have been implemented and verified.

Anthropic

Acadex can work with Claude models from Anthropic.

For Anthropic’s commercial API, inputs and outputs are not used for model training by default.

Under Anthropic’s standard API retention policy, API inputs and outputs are generally deleted from its backend within 30 days, subject to documented exceptions and alternative contractual arrangements such as eligible Zero Data Retention agreements.

A direct Anthropic API connection is not currently treated by Acadex as an approved processing profile for institutions that require research content to remain within an EU processing path.

That does not mean Claude models are categorically incompatible with such a requirement.

The model and the technical route used to reach it are separate questions.

Google Cloud

Google Cloud can provide access to Google models and selected partner models through its AI infrastructure.

Google states that customer data in its managed AI services is not used to train or fine-tune AI models without the customer’s prior permission or instruction.

Google also offers geographic processing controls for supported services and models.

This is particularly relevant because supported Claude models can now be accessed through EU multi-region endpoints on Google Cloud.

That creates a possible processing path in which Acadex communicates with Google Cloud infrastructure in the EU while using a Claude model.

The same principle can apply to supported Google models through suitable regional infrastructure.

These paths are not described as available in Acadex until the relevant integration has been implemented, tested, and contractually reviewed.

Features that introduce additional retention or processing — such as certain grounding, logging, stateful, or preview functionality — must be evaluated separately.

A provider profile is therefore more specific than simply saying “Gemini” or “Claude”.

Why we use processing profiles.

A model name does not tell you where a request was processed.

It does not tell you which API endpoint was used.

It does not tell you whether content was retained.

And it does not tell you which contractual processing chain applied.

For institutional accounts, Acadex can therefore define processing profiles such as an approved EU route rather than merely maintaining a list of allowed model names.

A profile can specify the provider, endpoint, region, permitted models, relevant features, and data-retention requirements.

Users inside that institutional account can then be restricted to the approved profiles.

What happens when no external model is needed?

Not every operation in Acadex requires a language-model request.

Bibliographic retrieval, calculations, internal database operations, search-index access, and other deterministic functions can take place without sending the underlying data to a model provider.

Acadex only involves an external model provider when the requested operation actually requires one.

Embeddings are generated locally.

Acadex uses embeddings for functions such as semantic retrieval and memory search.

These embeddings are generated locally within Acadex’s own infrastructure.

We do not send this content to a separate external embedding API.

Our vector and search infrastructure is also operated as part of Acadex rather than through an external hosted vector-database provider.

Web search

When Acadex needs information from the public web, it can use a self-hosted instance of SearXNG as its search layer.

SearXNG itself runs within infrastructure controlled by Acadex and is not an external analytics service.

Depending on the search engines or sources queried through it, a search request may still result in information being sent to external search services.

Web search is therefore conceptually separate from searching Acadex’s own bibliographic and internal data.

We do not use web searches to build advertising or behavioural profiles.

Bibliographic data sources

Acadex works with external sources of scholarly metadata, including information about publications, researchers, authorship, and citations.

These services primarily provide data to Acadex.

They do not automatically receive Acadex conversations, uploaded documents, memories, or account content simply because their bibliographic records are used in an answer.

The specific bibliographic sources used by Acadex are documented separately alongside the product where appropriate.

Payments

Where paid Acadex plans or additional paid services are purchased online, payment processing can be handled through Stripe.

Stripe processes the information necessary to carry out the payment and related billing operations.

Acadex does not use Stripe as an analytics or advertising provider.

Institutional customers can also be billed by invoice, so institutional use does not require payment by credit card.

Push notifications

If you enable push notifications, delivery may require the push infrastructure associated with your browser, operating system, or device.

Push notifications are optional.

The exact technical delivery path can therefore depend on the platform you use.

Disabling push notifications does not prevent you from using the core Acadex research functionality.

Product metrics stay inside Acadex.

We do not send our first-party Product Metrics to model providers for analytics purposes.

Acadex does not currently use Google Analytics, Mixpanel, Amplitude, Meta Pixel, LinkedIn Insight Tag, session-recording platforms, or comparable external behavioural analytics services.

Website statistics and product events are processed on our own infrastructure.

Conversation content, uploaded documents, memories, research topics, and bibliographic search queries are not used for our own Product Analytics.

We want to know whether Acadex is being used — not what people are researching.

A provider can be available without being available to you.

This distinction is particularly important for institutions.

Acadex may technically support a provider while an institution has decided that the provider must not be used for its accounts.

In that case, the restriction is enforced at the account level.

Individual users cannot simply bypass the institutional configuration by selecting another model.

Conversely, adding support for a new provider to Acadex does not automatically add that provider to an existing institution’s approved processing chain.

The institution-specific list matters.

For institutional customers, the general list on this page is not a substitute for the concrete subprocessor configuration that applies to that institution.

The relevant contractual documentation should identify the external processors that may actually receive personal data under the agreed configuration.

Where the institution restricts model providers or processing regions, those restrictions can be reflected in the corresponding contractual annexes.

This avoids treating every provider Acadex might technically support as a subprocessor for every customer.

External services do not automatically receive everything.

A model provider involved in one request does not automatically receive:

your complete Acadex account, all previous conversations, every uploaded document, your entire memory store, your watchlists, or Acadex’s internal Product Metrics.

Acadex sends the information required for the particular function being performed.

Which information is necessary depends on the feature and processing path.

Data minimisation is therefore part of the architecture, not just a statement in the Privacy Policy.

Services change. Documentation should change with them.

Providers change models, endpoints, retention controls, regional availability, and contractual terms.

Acadex can also add, replace, or remove external services over time.

When that changes the way personal data is processed, we update the relevant documentation and, where required, inform institutional customers through the applicable contractual process.

A new technical integration does not silently override an institution’s existing provider restrictions.

Need the configuration for your institution?

We can document the processing path that would apply to your organisation rather than asking you to assess every service Acadex could theoretically use.

That can include the approved model providers, processing profiles, geographic restrictions, relevant subprocessors, and Technical and Organisational Measures.

Discuss institutional requirements →

Further documentation

Security & Privacy →

Technical and Organisational Measures →

Data Processing Agreement →

Privacy Policy →

Acadex for Institutions →