Institutional documents

Data Processing Agreement

When an institution uses Acadex to process personal data on its behalf, the relationship may require a Data Processing Agreement under Article 28 GDPR.

Acadex provides such an agreement for institutional use where the legal roles require one.

The agreement is intended to describe the processing that actually takes place — including the institution’s approved provider configuration — rather than simply attaching a generic processor template to every contract.

When is a DPA relevant?

A Data Processing Agreement is relevant where an institution acts as the controller and Acadex processes personal data on that institution’s documented instructions.

This can apply, for example, to personal data contained in:

• research conversations,
• uploaded documents,
• saved memories,
• research materials,
• watchlists,
• and other content processed through an institutional Acadex account.

Whether Acadex acts as a processor depends on the actual purpose and allocation of responsibilities.

It does not depend only on what the parties call the relationship.

Acadex is not necessarily a processor for everything.

Even where Acadex acts as a processor for institutional research content, some processing can take place for Acadex’s own purposes.

For those activities, Acadex may act as an independent controller.

This can include processing required for:

• account and contract administration,
• billing,
• service security,
• prevention of abuse,
• compliance with legal obligations,
• and our limited first-party Product Metrics.

We therefore distinguish between:

processing carried out on the institution’s instructions

and

processing Acadex carries out for its own legitimate purposes and responsibilities.

The DPA governs the first category.

Our Privacy Policy describes the latter.

What does the DPA cover?

The Acadex DPA addresses the areas required for processing on behalf of an institutional controller.

This includes matters such as:

• subject matter and duration of the processing,
• nature and purpose of the processing,
• categories of personal data,
• categories of data subjects,
• documented instructions from the controller,
• confidentiality,
• technical and organisational measures,
• engagement of subprocessors,
• support with data-subject requests,
• support with security and compliance obligations,
• deletion or return of data,
• information and audit obligations.

The concrete processing description is contained in the contractual annexes rather than being left implicit.

The processing description should match the deployment.

An institution should be able to understand what Acadex is actually being asked to process.

The relevant annex therefore describes matters such as:

• the Acadex services being used,
• the purpose of the processing,
• the expected categories of users,
• the types of personal data involved,
• and the duration of processing.

This description can differ between institutional deployments.

A research group working primarily with public bibliographic information may have a different processing context from an institution that allows users to upload documents containing personal data.

The contract should reflect that difference.

Model providers are part of the processing configuration.

Acadex can work with different language-model providers.

That does not mean every technically integrated provider becomes a subprocessor for every institutional customer.

For institutional accounts, permitted processing profiles can be defined and technically restricted.

The DPA can therefore document which external processing paths are permitted for that institution.

A model name is not enough.

The relevant processing path is more specific than a label such as:

Mistral

GPT

Claude

or

Gemini

A processing profile can also determine:

• which provider receives the request,
• which API endpoint is used,
• where supported processing takes place,
• which models are permitted,
• which retention controls apply,
• and which provider features may be used.

This matters because the same model family can sometimes be available through different technical routes.

For institutional processing, the contractual description should follow the actual route rather than the marketing name of the model.

Supported does not mean approved.

Acadex distinguishes between three states.

Supported

Acadex has technically integrated the provider or processing route.

Approved

The provider or processing profile is permitted for a particular institutional account.

Used

The provider actually receives personal data for a particular request.

A provider can therefore appear in Acadex’s general technical documentation without being part of an individual institution’s processing chain.

Institution-level restrictions are technically enforced.

If an institution approves only a particular set of processing profiles, Acadex can restrict the account accordingly.

Individual users should not be able to bypass that restriction by choosing another model inside a conversation.

This allows contractual processing requirements to be reflected in technical configuration.

The DPA and its annexes can document those restrictions.

Adding a provider to Acadex does not automatically add it to your DPA.

Acadex may integrate additional model providers or processing routes as the product develops.

That does not automatically change an existing institution’s approved processing configuration.

If a new provider would need to process personal data on behalf of an institution, the applicable contractual and subprocessor-change process must be followed.

Institutional restrictions remain in effect until they are changed through the applicable process.

EU processing requirements can be documented.

Some institutions require research content to be processed only through defined European processing paths.

Where Acadex supports and has verified a suitable processing profile, that requirement can be reflected in the institutional configuration and contractual documentation.

We do not treat a route as approved merely because a provider advertises a European processing option.

Before a profile is offered for this purpose, the relevant implementation must be checked for matters such as:

• endpoint and region,
• supported models,
• retention settings,
• training controls,
• additional provider features,
• and the contractual processing chain.

Planned routes are not described as available until they have been implemented and verified.

Product Metrics are separated from research content.

Acadex processes a limited number of operational and product metrics for its own purposes.

These can include information such as:

• registration,
• activation,
• plan or seat status,
• subscription state,
• credit usage,
• and aggregated commercial metrics.

Where Acadex determines the purpose of that processing itself, it does not form part of the institution’s processing instructions under the DPA.

Acadex acts as controller for that processing where the legal conditions for that role are met.

At the same time, we deliberately exclude research content from our own Product Analytics.

We do not use:

• conversation content,
• uploaded document content,
• saved memories,
• research topics,
• research interests,
• or bibliographic search queries

for our own Product Analytics.

Technical and Organisational Measures

The DPA is accompanied by documentation of Acadex’s Technical and Organisational Measures.

These measures cover areas including:

• access control,
• administrative authentication,
• encryption,
• secret management,
• development and production separation,
• logging,
• deletion,
• backups,
• incident response,
• external processing,
• and institutional provider restrictions.

The TOM document is versioned.

It describes the controls actually in place for the relevant version rather than combining current controls with an undifferentiated roadmap.

Technical and Organisational Measures →

Subprocessors

Where Acadex uses another processor to process personal data on behalf of the institution, the applicable subprocessor requirements are addressed in the DPA.

The relevant list should reflect the processors that may actually receive personal data under the institution’s agreed configuration.

This is particularly important for model providers.

A public list of every service Acadex can technically integrate is not automatically the institution-specific subprocessor list.

External Services & Sub-processors →

Changes to subprocessors

External infrastructure and model providers can change over time.

The DPA defines how relevant changes to subprocessors are handled.

Where required, institutional customers receive information about changes before the new processor is used for the processing covered by their agreement.

Any applicable contractual right to object is governed by the DPA.

Adding technical support for a provider elsewhere in Acadex does not bypass this process.

Instructions from the institution

Where Acadex acts as processor, personal data is processed on documented instructions from the institution unless processing is required by applicable law.

Those instructions are defined through the contract, the agreed use of Acadex, the institutional configuration, and any lawful additional instructions accepted under the agreement.

The instruction framework does not mean that every individual user may independently change the institution’s processing configuration.

Institution-level restrictions take precedence over individual model preferences.

Confidentiality

Persons authorised to process personal data on behalf of Acadex are subject to confidentiality requirements.

Access is limited according to operational role and need.

Administrative access to production systems is deliberately restricted.

More detail is contained in the Technical and Organisational Measures.

Data-subject requests

Where Acadex acts only as processor for particular personal data, the institution remains responsible for handling data-subject requests as controller.

Acadex supports the institution as required under the DPA and applicable law.

If a request concerning processor-controlled institutional data is submitted directly to Acadex, we may need to forward or coordinate that request with the institution.

This is separate from requests concerning processing for which Acadex itself acts as controller.

Security incidents

Where a personal-data breach affects information processed by Acadex on behalf of an institutional controller, Acadex informs the controller in accordance with the DPA and applicable law after becoming aware of the breach.

The information available can be supplemented as the investigation progresses.

Our incident-response process covers containment, investigation, assessment, documentation, communication, and corrective measures.

Security & Privacy →

Deletion and return of data

The DPA defines what happens to personal data processed on behalf of an institution when the relevant services end.

Depending on the applicable agreement and legal requirements, data is deleted or returned as required.

Deletion from active systems does not necessarily remove data from every existing backup at the same moment.

Backup copies can remain until the applicable backup retention period expires.

They remain subject to protection and are not intended to be returned to ordinary productive use merely because a backup exists.

Institutional documentation

For an institutional review, we can provide documentation including:

• the Data Processing Agreement,
• the applicable processing description,
• Technical and Organisational Measures,
• the relevant subprocessor configuration,
• provider-profile information,
• privacy documentation,
• and answers to security or procurement questionnaires where needed.

The exact documentation depends on the proposed deployment.

Can we use our own DPA?

Yes.

If your institution has its own standard Data Processing Agreement or processor terms, we can review them.

We do not require the use of our template simply because it is ours.

The important point is that the resulting agreement accurately reflects:

• the actual allocation of roles,
• the processing carried out through Acadex,
• the agreed processing configuration,
• the subprocessors involved,
• and the technical measures actually in place.

A contract that accurately describes the system is more useful than one that merely uses familiar wording.

Is the public DPA page itself the contract?

No.

This page explains how we approach institutional data processing.

It is not itself the Data Processing Agreement and does not replace the signed or otherwise validly concluded contractual document between Acadex and an institution.

The binding DPA contains the complete contractual provisions and annexes applicable to the specific institutional relationship.

Acadex is still in Early Access.

Our institutional documentation is being developed alongside the product.

The fundamental distinction between controller processing, processor processing, provider restrictions, and institution-specific subprocessors is already part of the architecture.

Some operational parameters elsewhere in our security documentation are still being formalised.

We document those open points rather than filling them with assumptions.

Before a DPA is used as a binding institutional contract, the final contractual version should undergo legal review.

Start with the actual requirements.

If your institution is considering Acadex, the most useful first step is usually to identify the requirements that matter for the deployment.

That can include:

• whether a DPA is required,
• which categories of personal data may be processed,
• which model providers are permitted,
• whether research content must remain within a defined geographic processing path,
• which subprocessors may be used,
• which security documentation is required,
• and whether your institution has its own contractual template.

We can then document the configuration that actually applies.

Discuss institutional use →

Further documentation

Technical and Organisational Measures →

External Services & Sub-processors →

Security & Privacy →

Privacy Policy →

Acadex for Institutions →