AI Addendum

Last Updated: August 1, 2026

This Addendum governs Customer's use of the artificial intelligence features of the Orgo platform ("AI Features"). It supplements the Organization Terms of Service and the Data Processing Agreement ("DPA").

Order of precedence. Where this Addendum conflicts with the DPA in respect of Personal Data, the DPA prevails. Where it conflicts with the Organization Terms of Service on any other matter, this Addendum prevails for the AI Features only.

1. What the AI Features are

Feature	What it does	Availability
Ask Orgo	Translates a question written in plain language into a query against the Customer's own data	Available to administrators
List suggestions	Proposes member list criteria from a plain-language description	Available to administrators
Support assistant	Answers questions about configuring and using Orgo, drawing on Orgo's published product documentation	Available to administrators through in-product chat
MCP server	Lets Customer connect an AI assistant of its own choosing to Orgo's API, so that the assistant can read and — where the token permits — write Customer's records	Available to administrators who create an access token; no access exists until one is created

These four are not alike, and this Addendum does not treat them as if they were. Ask Orgo and list suggestions send a question and the shape of the database to Orgo's model provider, and nothing more (Section 2). The support assistant sits outside the Customer's workspace entirely (Section 2a). The MCP server is the opposite of both: real member records leave Orgo, to an assistant Orgo has no relationship with (Section 2b). Read Section 2b before enabling it.

Orgo does not offer AI-assisted moderation of discussions, and no AI Feature of Orgo's own processes member-written content. If such a capability is introduced, Section 8 applies.

2. What is transmitted, and what is not

This section is the substance of this Addendum. It describes the architecture, not an intention.

Transmitted to the model provider:

the text of the question or description submitted by the Customer's administrator;
the structure of the Customer's database — table and field names, with no values;
any image the administrator chooses to attach to a question — for example a screenshot pasted into the chat box in order to ask for the same figures from live data.

Not transmitted, under any circumstance, by these features:

member records, in whole or in part;
the results of the generated query;
files, documents or media stored in the Customer's workspace;
direct messages, discussion posts or comments;
payment data.

The query generated from the administrator's question is compiled and executed inside Orgo's own infrastructure in AWS Frankfurt (eu-central-1). The results are returned to the administrator from that infrastructure and are never sent to the model provider.

Two routes therefore exist by which Customer Personal Data can reach the model provider, both at the administrator's own choice. A free-text question is written by a human and could contain a personal identifier if the administrator types one. An attached image is more direct still: a screenshot of an existing report may show member data on its face. That is why the model provider is listed as a Subprocessor in Annex 3, and why this Addendum exists rather than a statement that no personal data is involved.

An administrator who does not wish member data to reach the model provider should not attach images containing it. Orgo cannot inspect the content of an attached image before it is transmitted.

2a. The support assistant

The support assistant is addressed separately because what reaches it differs from the other AI Features.

Transmitted to the assistant:

the question or message written by the Customer's administrator;
the administrator's name, email address and organisation name, so that a support conversation can be attributed and continued.

Not transmitted, under any circumstance:

member records, or any other content of the Customer's database;
discussion posts, comments, direct messages or files;
payment data.

The assistant answers from Orgo's published product documentation. It has no connection to any Customer workspace, cannot query Customer data, and performs no analysis on it. Its scope is how to configure and use Orgo, not what a Customer's data contains.

The administrator's name, email address and organisation name are Personal Data for which Orgo acts as Controller, as business contact details of the person requesting support — not as Processor on the Customer's behalf. Where an administrator chooses to include Customer Personal Data in the text of a support request, Orgo processes it as Processor under the DPA.

An administrator may ask for a human at any time, and is never required to interact with the assistant to reach support. Response targets, severity levels and escalation are set out in the Organization Terms of Service, Section 6.4.

The provider of the support assistant is listed in Annex 3 — Subprocessors.

2b. The MCP server

The MCP server is an interface, not a model. Orgo supplies no artificial intelligence here at all: it exposes its API over the Model Context Protocol so that an AI assistant chosen by Customer — Claude, ChatGPT, or any other MCP-compatible client — can call that API on Customer's behalf.

(a) What this means for Customer's data

Sections 2 and 2a describe features in which member records never leave Orgo. This one is different, and Customer must understand the difference before enabling it. An assistant connected through the MCP server reads Customer's actual records — members, events, payments, and the other areas the token covers — and, where the token grants write access, creates and modifies them. Those records leave Orgo's infrastructure and reach the assistant Customer selected.

That is the purpose of the feature, not a defect in it. But it is a disclosure of Personal Data to a third party, and the remainder of this Section allocates responsibility for it.

(b) Who the assistant's provider is, in law

The provider of an assistant Customer connects is not Orgo's Subprocessor. Orgo has no contract with it, does not select it, cannot inspect it, and receives nothing from it. Orgo's role is to answer an authenticated API call from a token Customer's own administrator created.

Accordingly:

Orgo processes on Customer's documented instruction when it responds to such a call. The creation of a token, and its scope, constitute that instruction.
The provider of the assistant is Customer's own processor or subprocessor, and Customer is responsible for the arrangements required by Article 28 GDPR with it.
Where that provider is outside the EEA, Customer is responsible for the transfer mechanism and for its own transfer impact assessment. Orgo makes no representation about any such provider.
Anthropic's listing in Annex 3 is for the features in Section 2 only. It does not extend to an assistant Customer connects through the MCP server, even where that assistant happens also to be built on Anthropic's models.

(c) The controls Orgo provides

Only tenant administrators can create a token. Until one is created, no assistant has any access.
A token is scoped per administrator, not shared across the organisation. It carries the identity of the administrator who created it.
Each token sets None, Read, or Write independently across the covered areas, and enforcement is default-deny: an operation the token does not grant is refused.
A read-only token rejects every modification attempt, and is the appropriate starting point.
Tenant isolation is enforced at the persistence layer. A call scoped to one organisation cannot reach another's data.
Each token records when it was last used, and every change to a token's permissions is written to an audit log.
A token may be revoked at any time by an administrator, with immediate effect.

(d) What Customer is responsible for

Customer shall:

select the assistant and satisfy itself as to that provider's security, retention and training practices — in particular whether it uses submitted data to train models;
grant each token the narrowest scope that meets the need, and prefer read-only where writing is not required;
revoke tokens when an administrator changes role or leaves;
ensure administrators understand that data retrieved through an assistant has left Orgo and is no longer governed by this Addendum or the DPA;
assess, before enabling write access, that an assistant acting on a misread instruction can create or alter records — and that Section 6 requires human review before Output is acted on.

Where Customer's workspace contains special categories of data under Article 9 GDPR — political opinions or religious beliefs, which are processed by design in some organisations — a read-scoped token exposes them to the assistant. This is not prohibited, but it is a decision for Customer to take deliberately and to record in its own documentation. Where the workspace contains children's data, Annex 5 to the DPA applies, and Customer should consider Section 7 (administrator access and safeguarding) and Section 8 (data minimisation) of that Annex before granting any token access to it.

(e) Stated limitations

So that Customer can assess this feature rather than assume a capability that is not in place:

Orgo cannot see what an assistant does with data after it is returned. The audit log records the calls a token made; it does not and cannot record the assistant's downstream storage, transmission or use.
Orgo cannot verify an assistant provider's claims about retention, training or onward disclosure, and does not attempt to.
Orgo does not restrict which assistants may be connected. Any MCP-compatible client presenting a valid token is served. Orgo therefore cannot prevent Customer from connecting a provider Customer has not assessed.
Orgo's liability does not extend to the assistant. Nothing in this paragraph limits Orgo's liability for its own processing, including its obligation to enforce token scope and tenant isolation correctly.

These limitations are stated expressly so that Customer can assess them rather than assume a capability that is not in place.

3. Model provider

Ask Orgo and list suggestions are delivered using models provided by Anthropic PBC, San Francisco, United States. The support assistant is delivered by the provider identified in Annex 3.

Anthropic is listed in Annex 3 — Subprocessors, with the applicable transfer mechanism and security certifications.
Anthropic does not train its models on data submitted through its commercial API.
Any change of model provider is a Subprocessor change and triggers the 30 days' advance notice and right to object set out in Annex 3, section 1.3.

This Section does not apply to the MCP server, for which Customer selects the assistant and no model provider is engaged by Orgo. See Section 2b(b).

4. Training and improvement

Orgo does not use Customer Input or Output to train or fine-tune any model, whether its own or a third party's, and does not permit its model provider to do so.

This is not a matter of configuration alone: for Ask Orgo and list suggestions, no member record is transmitted in the first place (Section 2), and what is transmitted is excluded from training under the model provider's commercial terms.

Orgo cannot make this commitment on behalf of an assistant Customer connects through the MCP server. Whether that provider trains on data it receives is a matter between Customer and that provider — see Section 2b(d).

5. Ownership

Input — the questions and descriptions a Customer submits — remains the Customer's.
Output — the generated query and its results — is the Customer's, as between Orgo and the Customer. Results are drawn from the Customer's own data and were always the Customer's.
Orgo claims no licence over Customer Input or Output beyond what is necessary to operate the AI Features for that Customer.

6. Accuracy, and what Customer must not rely on

AI Features are probabilistic. A generated query may misinterpret a question.

Output is provided as is, with no warranty of accuracy or fitness for a particular purpose.
Customer must apply human review before acting on Output in any decision that has a legal or similarly significant effect on an individual — including membership status, eligibility, discipline, exclusion, financial obligation or access to benefits.
Orgo does not make automated decisions producing legal or similarly significant effects on data subjects through the AI Features within the meaning of Article 22 GDPR.
Where Customer grants an assistant write access through the MCP server, the assistant acts on Customer's authority, not Orgo's. An assistant that misreads an instruction can create or alter records. Customer is responsible for the consequences of actions taken under a token it issued, and Orgo's obligation is limited to enforcing the scope of that token correctly.

7. Acceptable use

Customer shall not use the AI Features to:

attempt to extract data belonging to another tenant, or to circumvent the permission model;
reconstruct, reverse engineer or benchmark the underlying model, or build a competing model;
generate unlawful content, or content that infringes the rights of others;
process special categories of data under Article 9 GDPR for a purpose Customer has no lawful basis for;
submit credentials, payment card data or authentication secrets in question text.

In relation to the MCP server, Customer shall additionally not:

share an access token outside the administrator it was issued to, or embed one in a client accessible to people who are not authorised administrators;
use a token to circumvent a permission a user would not have in the Orgo interface;
connect an assistant for the purpose of bulk extraction of Customer's database as a route around the export controls and rate limits in the Organization Terms of Service.

Orgo may suspend access to the AI Features, without suspending the rest of the Services, where use breaches this Section and is not remedied after notice — or immediately, where continued use presents a material security or legal risk. In the case of the MCP server, suspension may take the form of revoking a specific token rather than disabling the feature for the whole organisation.

8. Changes to the AI Features

Orgo may add, modify or withdraw AI Features. A withdrawal that materially reduces functionality Customer relies on will be notified at least 30 days in advance, except where withdrawal is necessary to address a security, legal or data protection risk — as was the case for AI-assisted discussion moderation.
Introducing an AI Feature that transmits categories of data beyond those in Section 2 requires 30 days' advance notice and, where a new provider is involved, the Subprocessor process in Annex 3.
A model hosted within Orgo's own infrastructure is a processing operation under the existing DPA, not a Subprocessor disclosure. Orgo will nonetheless state on the Trust & Security page which AI Features run where.

9. Availability and turning the features off

AI Features are provided as part of the Services and carry no separate availability commitment.
The MCP server is off until Customer turns it on. No assistant has access until an administrator creates a token, and an administrator may revoke any token at any time, with immediate effect.
A Customer that does not wish the other AI Features to be used in its workspace may request that they be disabled by writing to privacy@orgo.space. Orgo will confirm in writing and record the instruction.

10. Liability

Orgo's liability arising from the AI Features is subject to the limitations in the Organization Terms of Service. Nothing in this Addendum limits liability that cannot be limited under applicable law, including liability under Article 82 GDPR.

11. Term

This Addendum applies for as long as Customer has access to the AI Features. Sections 4, 5 and 10 survive termination.

12. Contact

S.C. ORGO INFORMATICS SRL Str. Gheorghe Grigore Cantacuzino nr 14, etaj PARTER, ap 1, Ploiești, județul Prahova, Romania J29/2796/2019 · CIF RO41650396

Data protection and this Addendum: privacy@orgo.space
Security issues: security@orgo.space