ZeeDo Terms of Service

1. Who we are, who may use ZeeDo, and how these terms are accepted

1.1 The parties. These terms form a contract between ZeeDo GmbH, c/o Ramzy J A Abushaaban, Elsa-Neumann-Straße 53, 13629 Berlin, Germany, registered in the commercial register of the Amtsgericht Charlottenburg under HRB 292967 B and represented by its managing director, Ramzy J A Abushaaban ("ZeeDo", "we", "us"), and the Customer defined in section 2.

1.2 Business use only. ZeeDo is offered only to businesses and to people acting for business or professional purposes. It is not offered to consumers. This applies to every plan, including Free.

1.3 What every user affirms. Before a person can create an account or join an organisation, they must affirm that:

• they are acting for the purposes of a trade, business, craft or profession, their own or their employer's or client's, and not as a consumer;
• they are 18 or older; and
• where they accept on behalf of an organisation, they have authority to bind it.

A person who cannot truthfully make these statements may not use ZeeDo. If ZeeDo finds that an organisation's account is held or used by a consumer, it may close the account and end the contract with immediate effect.

1.4 Acceptance, the record and the confirmation. These terms are accepted in the product at signup. For the organisation, ZeeDo records the version of these terms that was accepted (the date of the version and a fingerprint of its exact text), the time of acceptance and the Member who accepted it. For each person, ZeeDo records the affirmation in 1.3 with the exact version of the text shown and the time. Both parties may rely on that record as evidence of which terms apply. A version of these terms applies to a contract from the time it is accepted, and changes to it follow section 23. When an organisation is created, and again when its first paid plan starts, ZeeDo will send the person who accepted and the Owners an email confirming the contract. It will name the versions in force of these terms (with the Acceptable Use Policy), the Data Processing Addendum and the Privacy Policy, give the address at which each version is kept, and attach each as a PDF. ZeeDo will keep every published version of each of these documents, unchanged, at its own address on zeedo.cloud.

1.5 Documents that form part of these terms. The Acceptable Use Policy and the Data Processing Addendum (the DPA) form part of these terms, and so does the signed order form for Enterprise. The Privacy Policy explains how ZeeDo processes personal data for its own purposes. It is information and is not part of the contract.

1.6 Contact. General: contact@zeedo.cloud. Legal notices: contact@zeedo.cloud, or by post to the address in 1.1. Support and switching requests: support@zeedo.cloud. Data protection: privacy@zeedo.cloud. Abuse reports, notices of illegal content and appeals: abuse@zeedo.cloud. Security vulnerabilities: security@zeedo.cloud. Under the EU Digital Services Act, contact@zeedo.cloud is ZeeDo's point of contact for authorities and support@zeedo.cloud its point of contact for users of the service. Both may be written to in English or German.

1.7 The Customer's main responsibilities, in short. The Customer decides what its bots do and is responsible for it. In particular, the Customer is responsible for: (a) the Instructions it and its Members give, and the tools, connections, credentials, standing approvals and released action classes it grants (sections 3 and 4); (b) the content and data it supplies or has its bots collect, including holding the rights to it and a lawful basis for processing it (sections 5 and 8); (c) its duties as controller under the GDPR and as deployer under the EU AI Act, including informing the people whose data its bots process and making sure the people who use ZeeDo for it understand how bots work (sections 5 and 7); (d) checking bot output before relying on it (section 6); (e) complying with the terms of the websites and services its bots use (section 5); (f) its Members, its staff and end users, and the people its bots contact (sections 3 and 5); (g) exporting and keeping its own copies of the data it needs (section 18); and (h) the correctness of its billing details and VAT ID (14.10). ZeeDo provides the service and the controls these terms name, and is responsible for them as sections 3.5, 19 and 20 state. This summary does not narrow or extend those sections.

1.8 Electronic contracting. The contract is concluded online. Between the parties, section 312i (1) sentence 1 nos. 1 to 3 and sentence 2 of the German Civil Code (BGB) do not apply (section 312i (2) sentence 2 BGB). Those provisions concern technical means to correct input errors before an order, the information listed in Article 246c of the Introductory Act to the German Civil Code, an electronic acknowledgment of the order, and when an order and its acknowledgment count as received. ZeeDo still sends the confirmation in 1.4. A delay or failure in sending it does not affect the contract. The Customer can retrieve, save and print these terms at any time from the page on which ZeeDo publishes them, and ZeeDo will provide each version as a PDF (1.4).

2. Definitions

• Customer means the business or professional for whom the organisation's account is held. On a paid plan it is the legal entity named at checkout. On Free it is the business or professional the person who signed up acts for.
• Organisation (or org) means the Customer's account on ZeeDo. An organisation holds one or more workspaces.
• Workspace means a unit inside an organisation with its own bots, integrations, memory, budget and machine. Plans are priced per workspace.
• Member means a person the Customer admits to its organisation, in any role (Owner, Admin, Manager, Member, Viewer or Billing). The Owners are the Members with the Owner role.
• Bot means an AI agent the Customer defines in a workspace, which acts through tools, a browser and a computer on the Customer's instructions.
• Output means anything a bot generates or produces, including text, files, images, audio, video and messages.
• Machine means the isolated cloud computer (a microVM) that ZeeDo runs for each workspace.
• Instruction means anything a Member or the Customer's systems give a bot to act on: a goal, a brief, a constraint, a message, a schedule, a policy setting, an approval, a standing approval, a connection, a credential or an API call.
• Approval gate means the product control that stops a bot before an action in a gated action class until an authorised Member decides.
• Action classes means the six closed classes of consequential action: Spend changes, Deletions, External messages, Merges, Publishing and Access changes.
• Standing approval means a written, scoped rule a Member grants that lets a bot perform a narrowly defined action without asking each time (for example, "Ads may set budgets up to €500/day").
• Commitment means paying, submitting a regulated filing, or defeating a human-verification challenge (such as a CAPTCHA). No bot is permitted to perform a Commitment (4.2).
• Enforced controls means the three controls ZeeDo operates outside the bot's reach and is responsible for: the approval gate, the payment-form stop together with the other Commitment refusals, and the egress policy (section 3.5).
• Takeover means a Member taking manual control of a bot's browser and desktop. Hand-off means a bot stopping and asking a Member to complete a step personally.
• Site registry means ZeeDo's list of the websites that bots may not visit (section 5.4).
• Customer Content means all data the Customer or its bots put into, create in, or retrieve into the service, including files, memory, recordings, run history, traces, messages and credentials.
• BYOK (an own key) means the Customer's own model-provider key. ZeeDo's model means model access that ZeeDo supplies as its own service, on its own provider account (sections 13.2 and 15). Included AI usage means the usage of ZeeDo's model that a plan includes in each billing month, and the one-time amount on Free (15.2). Extra usage means usage of ZeeDo's model beyond the included AI usage that the Customer has chosen to pay for (15.4).
• Plan means Free, Starter, Pro, Business or Enterprise.
• End of service means the date on which the clock in section 18.2 starts.

3. The agency model

3.1 What ZeeDo provides. ZeeDo provides the means for the Customer to run AI agents for its business: an isolated machine for each workspace, the tools and connections the Customer enables, the record in 3.8, and the enforced controls in 3.5. ZeeDo's obligation is that the enforced controls work as these terms (3.5, 4.1 and 4.2) and, for a workspace's egress policy, the product describe them. This is part of the description of the service, not a guarantee (19.3). ZeeDo does not choose a bot's goals or targets, and it does not promise that a bot will resist manipulation by content that third parties wrote (3.4).

3.2 The Customer directs its bots. The Customer is the principal, and each bot is the Customer's agent. A bot acts because the Customer or one of its Members instructed it, using credentials and connections the Customer supplied, inside limits the Customer set. The Customer decides what each bot is for, what it may access, which tools, connections and credentials it holds, which actions need approval, who may approve them, and which standing approvals exist.

3.3 The Customer is responsible for its bots' actions. As between the Customer and ZeeDo, every action a bot takes within the authority the Customer configured is an action of the Customer. This includes:

• actions a Member approved;
• actions in an action class the Customer released from approval (4.4);
• actions covered by a standing approval (4.5);
• actions a bot takes in response to an Instruction; and
• actions directed by the Customer's Members or employees, or by anyone using the Customer's credentials or API keys, unless that person obtained them through ZeeDo's breach of its obligations.

3.4 Actions induced by third-party content (prompt injection). Bots read web pages, emails, documents, tickets and tool results that third parties wrote. That content can try to instruct a bot, and no one can yet prevent this reliably. An action a bot takes within the tools, connections, credentials and standing approvals the Customer granted, and that no enforced control was documented to stop, remains the Customer's action under 3.3, even if third-party content induced it.

3.5 What ZeeDo is responsible for. For what bots do, ZeeDo's responsibility is limited to its enforced controls working as documented:

• the approval gate: an action that ZeeDo's systems place in a gated action class (4.1), executed without the approval the Customer's configuration required, or on arguments that differ from those approved;
• the payment-form stop and the Commitment refusals: a bot going past one of the stops in 4.2 although a sign named there was present; and
• the egress policy: outbound traffic leaving the machine that the workspace's egress policy, as documented, blocks.

ZeeDo's duty of skill and care for the rest of the service, such as its availability, the tools it provides working as described, and the safekeeping of Customer Content, is in section 19. Liability for a failure of an enforced control follows section 20. Nothing in sections 3 and 4 limits 20.1.

3.6 Chains of authority. The Customer is responsible for which Members hold which roles, for what they instruct, and for the API keys they create.

3.7 Autonomy moves responsibility. Each approval the Customer switches off and each standing approval it grants widens what its bots do unattended. Responsibility for those actions sits with the Customer.

3.8 The record. ZeeDo keeps an audit log of the actions Members and bots take in the service, with the actor, the time and a trace identifier. Its rows cannot be changed or deleted through the service, and an hourly copy is written to storage locked against change and deletion for 400 days. Each approval decision is recorded with its time, its actor and a digest of the exact arguments it approved. Each release of an action class and each consent in Schedule 1 is recorded with its time, its actor and the exact version of the text shown. Both parties may rely on this record as evidence of who authorised what, and when.

4. Approval gates and what bots never do

4.1 Gated by default. An action in one of the six action classes requires approval before execution unless the Customer has released that class for that bot. ZeeDo's systems place a tool call in an action class by the tool's entry in ZeeDo's tool registry. A message a bot sends through a connected message channel, and an email it sends in its browser from a webmail site that ZeeDo recognises to an address outside the organisation, are External messages. Before a bot presses a control on a website in its browser, ZeeDo may check what pressing it would do. A press that this check identifies as sending a message or a person's details is an External message, and one it identifies as publishing, as deleting or cancelling something, or as changing an account or its security settings is placed in Publishing, Deletions or Access changes; such a press follows that class's settings for the bot and may ask for approval. Other actions a bot takes on a website in its browser, including a press the check does not identify, are not placed in an action class and do not ask for approval. They are limited by the stops in 4.2, by the rules people set for the bot, and by the websites and accounts the Customer lets its bots use (5.4, 5.5).

4.2 Commitments are never permitted. No setting, plan, policy, standing approval or API call can permit a bot to pay for anything, enter a payment instrument, submit a regulated filing, or defeat a CAPTCHA or other human-verification challenge. ZeeDo's systems stop a bot:

• when it reaches a payment form (card fields, autocomplete="cc-*", or a payment frame of a provider such as Stripe, Adyen or PayPal): the bot can then no longer act on that page;
• before it presses a control whose name pays, transfers, orders, signs or files, or the submit control of a form that posts data, other than a sign-in form, on a website on ZeeDo's list of tax, banking, health and legal sites;
• when it meets a human-verification challenge that ZeeDo's systems recognise; and
• before it calls a tool that ZeeDo's tool registry marks as paying or filing.

The step is then handed to a Member. These stops recognise a Commitment by the signs this section names, and ZeeDo extends them over time. ZeeDo also runs additional checks, such as phrase lists in many languages, signals in the page and a model's reading of a control's labels, that can only add stops; they are not signs of this section. The Customer does not instruct a bot to perform a Commitment. Where the Customer gives a bot a tool or an account that can pay or file without showing one of these signs, the stops may not recognise it, and 3.3 applies.

4.3 Regulated categories are prepare-only. Work in a regulated category (tax, banking, health, legal) is prepared for the Customer's review. A bot is not permitted to file or submit it, and the stops in 4.2 apply. Work such as booking, shopping and travel is prepared up to the stops in 4.2, such as the payment form or the control that places an order, and a Member completes it.

4.4 Releasing a class from approval. An authorised Member may turn off approval for one action class on one bot, after three steps: a fresh re-authentication within the preceding five minutes, by a passkey, by a password with a one-time code from an authenticator app, or by a fresh sign-in through the Member's own Google or Microsoft account (for a Member who has used a passkey in the Organisation and holds no authenticator app, by the passkey); a plain statement of what that bot may now do unattended; and an explicit confirmation. For a sign-in through Google or Microsoft, ZeeDo relies on that account's own security, including its 2-step verification and whether the provider asks for the account's password or second step again, which the account holder and the provider control and ZeeDo cannot see. ZeeDo records the decision, the Member and the exact text shown. From that moment the Customer takes responsibility for that bot's actions in that class without per-action authorisation. An API key can never release a class. The Customer may lock an action class for a workspace, so that no bot in that workspace can be released from approval for that class.

4.5 Standing approvals. A standing approval is authority the Customer delegates. It is limited to the bot, connection, tool and condition, any daily limit, and the expiry shown when it is granted. Unless the Member chooses another date, it expires after ninety days. It is voided if the bot's brief, its manager or the underlying connection changes. A bot cannot create, widen or renew a standing approval. Spend that runs under a standing approval, through an account the Customer funds, is authorised in advance by the Customer within the stated limit.

4.6 Approvals expire and bind the exact action. An undecided approval expires 72 hours after it was raised, and the bot does not proceed on it. An approval covers the exact arguments shown. If the recipient, amount, path, repository or connection changes, the bot must ask again.

4.7 The Customer can always step in. On every plan, Free included, a Member with the right role may watch a bot's screen and take over the bot's browser and desktop, and a bot that must stop hands the step to a Member with an explanation (a hand-off), which the Member completes, for example in the live view of the bot's browser. Taking over a bot whose machine is asleep wakes the machine, which needs free capacity (9.1, 9.3).

5. The Customer's responsibilities

5.1 Rights and permissions. The Customer must hold every right, licence, consent and permission its bots exercise on its behalf, including access to each account a bot signs into, each system a bot changes, and each person a bot contacts.

5.2 Credentials. The Customer may store credentials in a workspace's vault, where they are kept encrypted with keys ZeeDo manages. Bots use them through the tools the Customer allows; the model never sees a credential, and no tool returns one to a model. An Owner or Admin of the workspace may reveal a stored credential after re-authenticating, and each reveal is recorded in the audit log. The Customer decides which credentials it stores and which bots may use them, is responsible for what its bots do with the access a credential gives, and revokes a credential when access should end.

5.3 Third-party terms. The Customer must comply with the terms of every third-party service its bots use, including websites, connectors, MCP servers and model providers.

5.4 Websites. ZeeDo's site registry names websites that bots may not visit, and ZeeDo's systems refuse a bot's requests to them. On other websites a bot acts as a person using a browser would. ZeeDo's systems obey a website's robots.txt for the pages a bot chooses to open itself. They do not apply it to pages a person opens while holding a bot's screen, or to a site where a person signed the bot in to the Customer's own account. There, the Customer's own access rights and the site's terms govern (5.3).

5.5 Signing in with the Customer's accounts. A Member confirms that the Customer holds the account a bot will use on a site, and that the Customer has the right to let a bot sign in and work in that account in this way, including under the site's own terms (Schedule 1). The product asks for this confirmation when a Member saves a credential for a site in a workspace that holds no current confirmation for that site, and each time a Member ticks it on a sign-in card for a site ZeeDo has not checked: a site that a bot chose while reading content from the web, that no person named for the bot, and that the workspace holds no sign-in for. Whether or not the product asks, the Customer's duties under 5.1 and 5.3 apply to every sign-in.

5.6 The registry is not a legal assessment. The site registry and the confirmations in 5.5 are a good-faith effort to respect the terms of websites. They are not a legal assessment for the Customer and do not relieve the Customer of 5.1 and 5.3.

5.7 Communications with third parties. The Customer is responsible for every message its bots send, including under marketing, privacy and consumer-protection law, and must not remove, alter or obscure the AI disclosure in section 7.

5.8 Members. Removing a Member ends that Member's sessions, revokes the API keys the Member created, and moves the bots that Member managed to an Owner of the organisation. Running bots keep running. The Customer is responsible for removing a Member whose access should end.

5.9 Acceptable use. The Customer must comply with the Acceptable Use Policy.

5.10 Data protection. For personal data in Customer Content, the Customer is the controller and ZeeDo its processor (8.3 and the DPA). The Customer is responsible for giving only lawful instructions, for having a legal basis for each processing its bots carry out, for informing the people whose data its bots process, for carrying out a data protection impact assessment where the law requires one, and for answering requests from data subjects. ZeeDo assists as the DPA describes. Section 2.5 of the DPA sets out these duties in full.

5.11 The Customer as deployer under the EU AI Act. As deployer (7.5), the Customer takes the measures that Article 4 of the AI Act requires to support the AI literacy of the people who use ZeeDo on its behalf. In any case, it makes sure that they, including its Members, understand AI and how bots work well enough to use them properly. It also carries a deployer's other duties.

5.12 The Customer's staff. Before bots or screen recordings process data about the Customer's own employees or other staff, the Customer informs them and, where the law requires it, involves their representatives, such as a works council. Compliance with employment and works-council law is the Customer's responsibility.

5.13 Sanctions. The Customer confirms that neither it nor any person who owns or controls it is subject to sanctions of the European Union, the United Nations, Germany or the United States, and that it will not use the service, or let anyone use it, from a territory subject to comprehensive sanctions or for the benefit of a sanctioned person. ZeeDo may refuse, restrict or end the service where sanctions law requires it or this statement is untrue. Sanctions of the United States count under this section, 10.4 and 24.4 only as far as EU and German law allow ZeeDo to observe them, in particular Council Regulation (EC) No 2271/96 and section 7 of the German Foreign Trade and Payments Ordinance (AWV).

5.14 Regulated services to others. Bots prepare the Customer's own affairs. The Customer must not use ZeeDo to provide legal, tax or other regulated services to third parties unless it holds the authorisation the law requires for them.

5.15 The Customer's own copies. The Customer keeps its own copies of the data it needs, by exporting or downloading it (18.1, 18.6) at intervals suited to the data's importance. ZeeDo's backups serve the operation of the service and are not a backup service for the Customer.

5.16 Financial entities. ZeeDo is not designed for the critical or important functions of a financial entity within the meaning of Regulation (EU) 2022/2554 (DORA). A financial entity may use ZeeDo for such functions only under an Enterprise order form that provides the contractual terms that regulation requires.

5.17 Bank, payment and other financial accounts. ZeeDo provides no payment service and no account information service, and it holds no funds (14.7, 14.8). The Customer decides whether a bot may use any of its bank, payment or other financial accounts, which ones, and within what limits. A bot uses such an account only through the Customer's own access, such as a credential the Customer stored (5.2), a connection it made (13.4) or a session in which a person signed the bot in to the account (5.4). The Customer is responsible for that choice and for its bots' use of those accounts, as 3.3, 5.1 and 5.3 provide, including towards each account's provider and under its terms, such as terms on sharing credentials or on automated access. The stops in 4.2 and the rule in 4.3 apply to these accounts as to any other. This does not limit 3.5 or 20.1.

6. Output and no professional advice

6.1 Output is generated by AI models. It can be wrong, incomplete or out of date. The Customer must review Output before relying on it.

6.2 No professional advice. ZeeDo does not provide tax, legal, medical or financial advice. Output in these areas is a draft prepared for the Customer's review, not advice from ZeeDo and not a substitute for a qualified professional. The first time a workspace gets a bot in a role that the product marks as a regulated category, such as the Analyst role, which prepares tax and finance work, the product asks the Member to confirm that its output is prepared for review, must be checked (by a qualified person where it matters) before it is relied on, and is never filed or submitted on the Customer's behalf (Schedule 1).

6.3 Output is not part of the agreed quality. The agreed quality of the service does not include that Output is accurate, complete, up to date or fit for a particular purpose. ZeeDo's duty is to provide the service as these terms describe it (19.1).

7. AI disclosure, provenance and the EU AI Act

7.1 Disclosure to people a bot contacts. A person a bot contacts is told that they are dealing with an AI agent: ZeeDo's systems add the line — {bot name}, an AI assistant at {org name} to the first message of each conversation or thread on each channel, and to the signature of every email a bot sends. The model does not write the line, and no plan or setting switches it off. ZeeDo may add it to further messages.

7.2 The Free badge. While a workspace is on Free, the same messages also carry the line Sent by a bot on ZeeDo — zeedo.cloud. It stops when the workspace moves to a paid plan.

7.3 What is not stamped. Neither line is added to files, to content a person sends, or to a form a bot fills in on a third party's page.

7.4 Generated media. Images, audio and video a bot generates and sends through ZeeDo carry C2PA provenance data, signed by ZeeDo outside the bot's machine.

7.5 Roles under the EU AI Act. ZeeDo is the provider of the ZeeDo agent system under the EU AI Act: it places the system on the market and designs its transparency features. The Customer is its deployer: it decides how, where and for what the system is used, and carries a deployer's duties, including taking measures to support the AI literacy of the people who use the system on its behalf (Article 4) and disclosing AI-generated or manipulated content it publishes where Article 50 (4) requires it.

7.6 Intended purpose and high-risk uses. ZeeDo is intended for automating a business's office and online work. It is not intended or designed for any use that makes an AI system high-risk under Article 6 (2) and Annex III of the EU AI Act, for example filtering job applications or evaluating candidates or employees, assessing creditworthiness, pricing life or health insurance, deciding on access to education or to essential public services, or identifying people by biometric data. The Customer must not use ZeeDo for such a use. A Customer that does so acts outside ZeeDo's intended purpose and is the provider of that high-risk AI system under Article 25 (1) (c) of the AI Act, with all of a provider's duties.

7.7 Transparency statement. Schedule 2 is ZeeDo's public transparency statement.

8. Customer Content

8.1 Ownership. As between the parties, the Customer owns Customer Content. ZeeDo claims no rights in Output. To the extent ZeeDo has any rights in Output, it transfers them to the Customer or, where a right cannot be transferred, grants the Customer an exclusive, perpetual, worldwide and royalty-free right to use the Output. ZeeDo does not warrant that Output is free of the rights of third parties. Before using Output, the Customer checks that its use does not infringe them.

8.2 Licence to ZeeDo. The Customer grants ZeeDo a non-exclusive right to host, copy, transmit, process and display Customer Content only as needed to provide, secure and support the service, and as the Customer instructs.

8.3 Personal data. ZeeDo processes personal data in Customer Content as the Customer's processor under the DPA.

8.4 No model training. ZeeDo does not use Customer Content to train or fine-tune any AI model, and ZeeDo's model uses only providers that do not train on it. ZeeDo's internal adversarial test suite uses fixtures, never Customer Content.

8.5 Operational data. ZeeDo may use data about use of the service that contains no Customer Content (for example, machine utilisation, counts and timings) to run, secure, bill and improve the service.

8.6 Location. Customer data is stored and processed in the EU (France, Germany and Ireland):

• bot machines, ZeeDo's own embedding and reranking models, the control-plane server and the primary file storage run at Scaleway in its Paris region (fr-par), France;
• a copy of the file storage is kept at OVH in Limburg, Germany;
• the database (Neon), the workflow service (Temporal Cloud), key management (AWS KMS) and transactional email (Amazon SES) run in Amazon Web Services' Frankfurt region (eu-central-1), Germany;
• the web application's functions run on Vercel in Frankfurt (fra1), Germany; and
• traces are kept by Langfuse in its EU region, in Ireland.

The DPA lists every sub-processor with its location, and section 6.1 of the DPA lists the exceptions. Among them, Members' sign-in data is processed by WorkOS in the United States, the web application's pages and responses pass through the location of Vercel's edge network nearest the user, and some sub-processors, or the companies they belong to, may access data from the United States, for example for support (section 6.4 of the DPA). Model requests leave that boundary as section 13 describes. On BYOK, they go to the model provider the Customer chooses. On ZeeDo's model, they are processed in the EU for an organisation of ZeeDo's EU region, except the reading of the rules people set for a bot and the check of what a control a bot is about to press would do, which may be served from the United States unless the organisation keeps every model check in the EU. To make bot memory and a workspace's tools searchable, ZeeDo's own embedding model turns memory text, memory searches and the descriptions of a workspace's connected tools into vectors, and ZeeDo's own reranking model orders memory search results, on ZeeDo's servers in France. Neither keeps a copy of the text. Where an Owner or Admin chose an embedding model of the Customer's own OpenAI account for a workspace, that workspace's memory text goes to OpenAI under the Customer's own terms, and OpenAI is the Customer's own processor for it. A bot sends data where the Customer directs it.

8.7 Region. An organisation's region is fixed when its first workspace is created. A move to another region is available only by contract.

9. Plans, fair use and limits

9.1 Plans. Each plan sets a slot size, a number of bots that can run at once, a number of bots that can be defined, a number of Members and a set of features. The current figures are:

"Guaranteed" scheduling means that ZeeDo never pauses or snapshots a paid workspace's running work to make room for another workspace, and that a paid workspace takes precedence over Free workspaces as 9.3 describes. It is not a promise that capacity is free at every moment: when none is, a paid workspace's run waits and starts as soon as capacity is free, and a take-over that has to wake a bot's machine can be refused until then. A machine that stays awake after its work has ended, and that no run and no person is using, may be put to sleep early to make room; it resumes from its snapshot when it is next needed. Section 11.1 applies.

9.2 Working hours are never billed. ZeeDo records how long bots work and shows it to the Customer. It does not charge for it.

9.3 Free scheduling. A Free workspace runs when the fleet has spare capacity. When a paid workspace needs that capacity, ZeeDo snapshots a Free workspace that no person is controlling at that moment, even while its bot is working, and resumes it later from that snapshot. A Free workspace whose bot's screen a person is controlling (a take-over, or a hand-off completed in the live view) is not snapshotted for this while that control lasts; if the capacity is still needed when it ends, it is snapshotted then. Free carries no availability or wake-time commitment.

9.4 Fair use (every plan). Unlimited working hours do not permit using a machine as general-purpose compute unrelated to the Customer's use of bots, such as cryptocurrency mining, media-transcoding farms or free hosting. Workloads must serve the Customer's own business. The rule is in the Acceptable Use Policy, section 4, with the three numbers the product enforces: a workspace is flagged when its machine averages 90% or more of its allotted vCPU across a rolling 6-hour window with zero model-token and tool-call cost records in that window. A flag notifies the workspace Owner and ZeeDo's abuse queue. Nothing is suspended automatically.

9.5 Business bot limit. The Business plan is limited to 200 defined bots. A marketing reference to "unlimited" on Business is subject to that number.

10. Suspension

ZeeDo operates two separate suspension regimes. Neither limits the other.

10.1 Fair use: never automatic. ZeeDo suspends a workspace for a fair-use breach only after all three of:

1. a written notice to the workspace Owner explaining the concern;
2. a 72-hour cure period in which the Customer may fix the workload or explain it; and
3. a decision by a person at ZeeDo that suspension is justified.

10.2 Abuse and security: immediate where needed. ZeeDo may restrict or suspend a bot, a workspace or an organisation immediately, including by automated means, where that is needed to stop:

• illegal activity, including child sexual abuse material;
• an attack on any system, or malware;
• a breach of sanctions or export-control law;
• a threat to the security or integrity of the service or other customers; or
• harm to third parties, including abusive traffic to websites and conduct that puts at risk the access of ZeeDo's bots to websites.

ZeeDo acts diligently, objectively and proportionately, and gives the Customer a statement of reasons as 10.6 describes. The Customer may appeal to abuse@zeedo.cloud or, for a suspended workspace, with the appeal form in the product. A person at ZeeDo reviews the appeal afresh and answers within 5 business days; where another person at ZeeDo can review it, that person did not take the original decision. ZeeDo lifts a restriction once it is no longer needed, unless it ends the contract under 24.4.

10.3 Non-payment. Section 17 applies.

10.4 Law, authorities and sanctions. ZeeDo may restrict or suspend the service, or a part of it, where a law, a court or an authority requires it, or where sanctions law requires it or the Customer's statement in 5.13 is untrue.

10.5 During a suspension. Where possible, ZeeDo limits a suspension to the affected bot or workspace, keeps the Customer's data, and keeps reads, exports and downloads available. Suspension does not start the clock in section 18.

10.6 Statement of reasons, and notices of illegal content. For each restriction under 10.1, 10.2 or 10.4, and for each termination under 24.4 that rests on content the Customer or its bots stored or sent, or on a breach of the Acceptable Use Policy, ZeeDo gives the Customer a statement of reasons by email to the Owners: no later than when the restriction or termination takes effect where a person at ZeeDo decides it, and without undue delay where the abuse detector imposes it. When a workspace is suspended under 10.2 or under the Acceptable Use Policy, the product also shows in that workspace, from the moment the suspension is recorded, why it was suspended and since when, the facts ZeeDo relied on, whether ZeeDo's abuse detector or a person decided, and how to appeal. The statement says:

• what was restricted, and for how long;
• the facts and circumstances ZeeDo relied on;
• whether automated means were used to detect the case or to decide on it;
• the ground for the restriction in these terms or in the law; and
• how the Customer can challenge the decision: for a restriction under 10.2, by the appeal 10.2 describes; otherwise by writing to abuse@zeedo.cloud, where a person at ZeeDo reviews it; and in every case before the courts.

ZeeDo leaves out what the law or an order of an authority does not allow it to say. Anyone may notify ZeeDo of content stored in the service that they consider illegal, by email to abuse@zeedo.cloud, as section 9 of the Acceptable Use Policy describes. ZeeDo acknowledges each notice and decides on it with reasons.

11. Availability and support

11.1 ZeeDo does not publish an availability percentage for any self-serve plan. An availability commitment with service credits is available only in an Enterprise order form. Service credits under such a commitment are set against any other claim for the same unavailability, which exists only as sections 19 and 20 allow. This does not limit 20.1.

11.2 Support is as shown in 9.1. A response target is the time within which ZeeDo aims to send a first reply; it is not a commitment to resolve an issue within that time. ZeeDo publishes a status page.

11.3 Booking, shopping and travel tasks are outside any service-level commitment.

12. API terms

12.1 The public API is available on paid plans. Starter keys are read-only. Pro and above may hold keys with write and admin scope. Free has no API keys.

12.2 API keys belong to the organisation, are scoped, may be limited to workspaces, and are stored hashed. The Customer must keep keys secret and rotate them if exposed.

12.3 The rate limit is 600 requests per minute and 10 concurrent streams per key, on every paid plan.

12.4 API versions are identified by URL prefix. ZeeDo may make additive changes without a new version and gives at least 12 months' overlap before a breaking change, unless the law, an authority or the security of the service requires the change sooner.

12.5 An API key cannot perform an action that requires a fresh re-authentication (4.4), including releasing an action class, granting a standing approval, managing API keys, changing SSO settings or deleting a workspace, and cannot take over or watch a bot's machine.

12.6 Webhook deliveries carry identifiers and non-personal fields only. Failed deliveries are retried for 24 hours, then kept for 7 days for replay.

13. Model providers and other third-party services

13.1 BYOK. With BYOK, the Customer contracts directly with its model provider and pays it. ZeeDo sends prompts and context to that provider on the Customer's instruction. The provider is the Customer's own processor or service provider, not ZeeDo's sub-processor, and its terms govern its processing.

13.2 ZeeDo's model. ZeeDo's model is the default for every workspace on every plan, Free included, unless a bot or its workspace uses the Customer's own key (BYOK) or an Owner or Admin has switched ZeeDo's model off for the workspace. Its requests go to OpenRouter and to the model provider named for each model on the sub-processor list: each model is served by one named provider. Every request is restricted to providers that keep no copy of prompts or responses (zero data retention) and do not train on them, and ZeeDo sets this restriction on each request itself. For an organisation of ZeeDo's EU region, requests go only through OpenRouter's EU endpoint and are processed in the EU; a request that cannot be served there fails and is not sent elsewhere. For an organisation of another region, requests go through the endpoint ZeeDo names for that region. There are two exceptions, the reading of the rules people set for a bot and the check of what a control a bot is about to press would do, which may be served from the United States under the same restriction unless an Owner or Admin turns on Keep every model check in the EU for the organisation. The DPA (5.5) describes what is sent for each. OpenRouter and the named model providers are ZeeDo's sub-processors under the DPA. ZeeDo chooses the models it offers and may change them (13.3).

13.3 Model changes. When a provider deprecates a model, ZeeDo shows a notice on every affected bot 30 days before the date, or as soon as it learns of the date where the provider gives less notice, and moves the bot to the provider's recommended successor on that date, unless the Customer pins the model. A change of the model ZeeDo's model uses, at a provider already named on the sub-processor list, follows this section. Adding or replacing a named model provider is a change of sub-processor, and ZeeDo gives notice of it as section 5.3 of the DPA describes.

13.4 Connectors. The Customer chooses which third-party services to connect. Their vendors provide their services to the Customer under their own terms and are not ZeeDo's sub-processors. ZeeDo is not responsible for a third-party service's availability or conduct.

14. Fees, currency and tax

14.1 Plans. Starter €39 / $39, Pro €149 / $149, Business €599 / $599, per workspace per month. Enterprise is priced by order form. Members are not billed.

14.2 Add-ons.

14.3 Billing cycle. Plans are billed monthly or annually in advance. Annual billing costs ten times the monthly price, except SSO and SCIM (twelve). A workspace or add-on added during a period is prorated and charged at once.

14.4 Currency. EUR for organisations whose billing country is in the EU when billing details are first saved, USD for all others. The currency is set once, by that first save, and does not change afterwards, including when the billing address later moves to another country.

14.5 Tax. Prices exclude VAT. Where the Customer gives a valid VAT ID, reverse charge applies where the law allows. ZeeDo checks EU VAT IDs with VIES; a tax ID is required for billing addresses in Switzerland, Liechtenstein, Norway and Iceland.

14.6 Payment. Self-serve payment is by the methods offered at Stripe Checkout, including card and, for billing in EUR (14.4), SEPA Direct Debit. Enterprise is invoiced, payable net 30.

14.7 No stored value. ZeeDo holds no customer funds. There are no prepaid balances, top-ups, wallets or stored value of any kind, and no credits other than a service credit under an Enterprise order form (11.1), which reduces fees and is not stored value. Annual fees are a prepayment of the subscription fee for the service only.

14.8 ZeeDo sells in its own name. Every amount on a ZeeDo invoice is the price of a service ZeeDo supplies in its own name and for its own account. ZeeDo does not collect, hold or transmit funds on behalf of any third party, and it does not pay any third party on the Customer's behalf.

14.9 Invoices. The Customer agrees to receive invoices and credit notes electronically, including as PDF, and in a structured electronic format when ZeeDo uses one.

14.10 Billing details and VAT. The Customer is responsible for the billing details it gives ZeeDo being correct and complete, including its legal name, address, billing country and VAT or other tax ID, and updates them without undue delay when they change. ZeeDo determines the tax on its invoices from those details. Where ZeeDo charged no German VAT because the Customer's details indicated that reverse charge applies or that the supply is outside German VAT, and the conditions for that turn out not to have been met, the Customer pays ZeeDo the VAT due on the supply against a corrected invoice. Where the Customer is responsible for details that were incorrect or out of date, it also compensates ZeeDo for the interest and surcharges a tax authority imposes on ZeeDo as a result.

14.11 When payment is due. An amount that ZeeDo collects from the payment method the Customer has given, by card or direct debit, is due on the invoice date and is collected from that payment method. An invoice that ZeeDo sends for payment instead, such as one for extra usage billed after a subscription has ended, is due within 14 days of the invoice date. An Enterprise invoice is due as 14.6 and the order form state.

15. ZeeDo's model, included AI usage and extra usage

15.1 What it is. ZeeDo's model is ZeeDo's own service: ZeeDo buys model capacity for its own account (through OpenRouter) and supplies access to it to the Customer in its own name. ZeeDo is the seller of record. The Customer has no contract with, and makes no payment to, OpenRouter or any model provider for usage of ZeeDo's model. It is the default (13.2), and the Customer may use BYOK instead at any time: with BYOK the provider bills the Customer directly, and ZeeDo adds no mark-up to that bill. Usage of ZeeDo's model is counted at ZeeDo's price in 14.2.

15.2 Included AI usage. Each billing month of a paid plan includes usage of ZeeDo's model up to a limit. ZeeDo sets each plan's included AI usage at its reasonable discretion (section 315 BGB), as a share of the plan fees received for the month. ZeeDo does not reduce that share during a paid period. A reduction takes effect only at the start of a paid period that begins at least 30 days after ZeeDo has notified the Owners of it by email and in the product; the Customer may then end the contract with effect from that date, and ZeeDo refunds fees paid in advance for the time after it. Only fees that have been received count: a yearly fee counts in equal parts for each month it pays for; an upgrade or an added workspace counts from when its charge is paid, for the time it covers; add-ons count for nothing. Until a month's own invoice is paid, the month has the smaller of what that invoice would bring and what the month before brought. While an organisation's first payment is on its way (a direct debit takes some business days), it has a small starting amount, counted into its first paid month. A trial, a granted plan and an Enterprise plan include usage only as ZeeDo sets it or the order form agrees it. On Free, an organisation receives a one-time amount, once per person, per organisation and per company, and none for an address on a temporary e-mail domain. Included AI usage is a limit, not money or stored value (14.7): it is not bought, held, carried over to another month, transferred or paid out, and what is not used in a month lapses at its end. The product shows how much of it has been used as a share, with the date it starts again, and not as an amount.

15.3 At the limit. ZeeDo tells the Owners and the Billing role by e-mail and in the product before the month's included AI usage is used up. When it is used up, the bots pause and nothing is lost. On a paid plan they go on when the next billing month starts, or at once with BYOK or with extra usage (15.4). On Free the ways on are BYOK or a paid plan. A call that is already running when the limit is reached is completed, and ZeeDo does not charge for the part of it beyond the limit.

15.4 Extra usage. On a paid plan whose first invoice has been paid, an Owner or a Billing member may turn on extra usage: usage of ZeeDo's model beyond the month's included AI usage, charged at ZeeDo's price in 14.2, plus tax. It is off until it is turned on, and it is turned on only with a monthly cap the Customer chooses; there is no default cap. ZeeDo refuses a request that would pass the cap and does not bill beyond it. The largest cap the Customer may set is, for the first 60 days after the organisation's first paid invoice, at most USD 25 a month; after that, the larger of one month's plan fees the organisation has paid and the largest invoice the organisation paid more than 60 days ago. ZeeDo may raise the largest cap for an organisation on request. Extra usage is not offered on Free.

15.5 How extra usage is billed. Extra usage is charged in arrears on the organisation's monthly invoice; on a yearly subscription, on an invoice at each monthly anniversary. When accrued unbilled extra usage reaches USD 25 in the organisation's first 60 days, or USD 200 after that, ZeeDo raises an interim charge against the subscription. For an organisation billed in EUR, the USD amount is converted at the euro reference rate the European Central Bank published for the invoice date, meaning the latest rate published on or before that date.

15.6 Payment trouble and refunds. If a payment fails, ZeeDo stops extra usage at once; the month's included AI usage continues, at no more than the last paid month brought, until the organisation becomes read-only (17.3). If a card network warns ZeeDo that a payment may be fraudulent, ZeeDo pauses ZeeDo's model for the organisation until it has checked the payment; if a payment is disputed, until the dispute is decided in ZeeDo's favour. BYOK keeps working throughout. An overdue Enterprise invoice stops extra usage only. A refund never deducts included AI usage that was used and never pays out included AI usage that was not; extra usage that was billed is not refunded with a plan fee.

16. Renewal, plan changes and cancellation

16.1 Renewal. Paid subscriptions renew automatically for the same period until cancelled.

16.2 Upgrade. An upgrade is prorated, charged at once, and takes effect at the bot's next wake.

16.3 Downgrade. A downgrade takes effect at the end of the paid period and is not refunded or credited. ZeeDo refuses a downgrade until the period ends if the workspace's running bots would not fit the lower plan. An organisation with a paid subscription cannot move back to Free.

16.4 Cancellation. The Customer may cancel at any time in the billing portal. Cancellation takes effect at the end of the current paid period. Fees paid in advance are not refunded, except under 15.2, 18.7, 23.2, 24.3, 24.4 or 26.2 or where mandatory law requires it. Section 18 applies from the end of the paid period. A switching request under 18.3 is a separate right.

16.5 Enterprise. Term, renewal and termination for Enterprise are set in the order form.

17. Late payment

17.1 ZeeDo retries card payments 1, 3, 5 and 7 days after the first failed attempt and emails the Customer after each failure. A failed direct debit is not re-presented automatically; the Customer pays on the invoice page or changes the payment method.

17.2 For 7 days after the first failed attempt the organisation keeps full access, except that extra usage of ZeeDo's model stops at once; the month's included AI usage continues (15.6).

17.3 If payment is still outstanding at the end of those 7 days, the subscription terminates for non-payment on the 8th day. That day is end of service, and section 18 applies: the organisation becomes read-only at once, and ZeeDo's model stops for it. ZeeDo waives the unpaid plan fees for the period in which service ends; extra usage already used remains payable.

17.4 Statutory default interest and the statutory flat-rate collection charge apply to overdue amounts.

17.5 Returned and reversed direct debits. Direct debits are collected under the SEPA Core scheme, under which the payer's bank refunds a debit at the payer's request within eight weeks of the debit without asking for a reason. A direct debit that is returned unpaid, or that the Customer or its bank reverses, does not settle the amount it was to collect: that amount stays due, or is due again from the day of the reversal, unless it was not owed. The Customer bears the charges that ZeeDo's bank or payment provider makes to ZeeDo for a returned or reversed debit, in the amount charged, unless the Customer is not responsible for the return or reversal. 15.6 describes what happens to ZeeDo's model meanwhile.

18. End of service, export, switching and deletion

18.1 Export at any time. While an organisation is active, and while it is read-only until day 60 of the end-of-service clock, an Owner or Admin can export its data as one archive signed by ZeeDo. The archive is produced within 24 hours and can be downloaded for seven days.

18.2 The end-of-service clock. One clock applies to every way an organisation's service ends: cancellation or non-renewal (at the end of the paid period), termination by either party (on its effective date), non-payment (17.3), and a switching request (18.5).

Reads, exports and downloads do not include content that ZeeDo has restricted under section 10 because it is illegal, or data that a law, a court or an authority forbids ZeeDo to make available, for as long as that applies.

18.3 Switching request. The Customer may at any time ask, in text form to support@zeedo.cloud, to switch to another provider of data processing services, to move its data to its own systems, or to have its exportable data erased (a switching request). A cancellation under 16.4 without a switching request follows 16.4. ZeeDo acts on a switching request made by an Owner or by a person with authority to represent the Customer, and confirms each request to the Owners (18.4). ZeeDo supports the Customer's exit strategy for the service, including by giving it all relevant information.

18.4 Notice period. A switching request starts a notice period. It ends at the end of the current monthly billing period or, on yearly billing, at the next monthly anniversary of the subscription. It never lasts more than two months. By the end of the notice period, the Customer tells ZeeDo in text form whether it switches to another provider (naming that provider and giving the details the switch needs), moves its data to its own systems, or wants its exportable data erased. It may say so in the request itself. If it has not chosen by then, ZeeDo treats the request as one for erasure: the contract then ends at the end of the notice period (18.5), and the Customer can still retrieve its data until day 60 of the clock in 18.2. ZeeDo confirms each switching request to the Owners in text form, with the date on which the notice period ends, and points out this consequence in that confirmation.

18.5 Transitional period and the end of the contract. Where the Customer switches to another provider or to its own systems, a transitional period of up to 30 days follows the notice period. During it, the contract and the service continue in full, and ZeeDo gives reasonable assistance with the switch, acts with due care to keep the Customer's business running, tells the Customer of known risks to continuity, and keeps a high level of security, for the data in transfer and until the end of the period in which the Customer can still retrieve it. The Customer may end the transitional period when the switch is complete, and may extend it once, for a period it chooses, by telling ZeeDo before it ends. If a transitional period of 30 days is technically impossible, ZeeDo tells the Customer so within 14 working days of the switching request, with its reasons and an alternative period of at most seven months, during which the service continues. The contract ends when the switch is complete: at the end of the transitional period, or earlier on the day the Customer tells ZeeDo that the switch is complete. Where the Customer chose erasure, the contract ends at the end of the notice period. ZeeDo confirms the end of the contract to the Owners. The day the contract ends under this section is end of service. The clock in 18.2 then runs: days 0 to 60 are the period in which the Customer can still retrieve its data, and ZeeDo erases all exportable data from its live systems on day 90 and from its backups within 30 days after that, except the records that 18.10 lists.

18.6 Exportable data. Everything the Customer and its bots put into or create in the service is exportable data, with its metadata:

• (a) in the signed archive: the organisation's records in every part of the service, one file per table in JSON Lines (among them bots and their settings, runs and steps, conversations, the board, approvals and standing approvals, automations, the metadata of connections and files, usage, cost and billing records, and members and roles); each workspace's memory (episodes, summaries, facts and relations, procedures and notes) and traces; the organisation's complete audit log as CSV; and a manifest listing every file with its SHA-256 hash, signed by ZeeDo;
• (b) the files bots made: each can be downloaded in the product and, on paid plans, through the public API; ZeeDo will add them to the archive;
• (c) screen recordings, while they are kept: they can be watched in the product; ZeeDo will make them exportable;
• (d) other content of a workspace machine's disk: ZeeDo will make it exportable.

Not exported, and why: the values of stored credentials, provider keys and sealed keys, and the state of browser sessions, because whoever held them could act in the Customer's accounts: the service hands out no provider key, sealed key or browser session, and a stored credential only to an Owner or Admin who reveals it in the product after re-authenticating (the Customer holds the originals); the identifiers the sign-in provider gives people; the binary model context inside run checkpoints (the checkpoints' records are exported); ZeeDo's internal notes, staff identities and detection signals about abuse and suspensions (what the Customer was told is exported); and the memory image of a running machine. Also not exported: the vectors ZeeDo computes from memory text and from tool descriptions to search them (the archive holds the text and names the model that computed the memory vectors, so they can be computed again); the amounts of included AI usage in money (the archive shows the share used and the dates); ZeeDo's own costs; the payment provider's raw event records (their identifiers, types and states are exported, and so are the invoice records); the addresses of browser push subscriptions and the signing secrets of webhooks, which work as passwords; unsent drafts of forms, which expire on their own; people's own display choices, such as the bots they pinned and the alerts they marked as read; records of sign-in sessions and of sign-ins in progress, and the event log the sign-in provider sends ZeeDo; and ZeeDo's internal bookkeeping, such as work queues, delivery logs, API answers kept 24 hours for retries, measurements of machine start-ups and the positions of its own jobs, which holds nothing beyond what the archive already holds.

Formats: a tar archive of UTF-8 JSON Lines and CSV (RFC 4180) files, with a manifest in JSON and a detached JWS signature (ES256) that ZeeDo's key set verifies, which ZeeDo sends on request and will publish; files in their original format.

ZeeDo's page "Data export and switching", at https://zeedo.cloud/legal/switching, describes the procedures, formats and limits in more detail, and states where ZeeDo's infrastructure is and how ZeeDo protects data held in the EU against unlawful governmental access (Article 28 of the EU Data Act).

18.7 Charges. ZeeDo charges nothing for a switching request, for switching or for exporting data. On monthly billing, the Customer pays the plan fees for the days the transitional period lasts, pro rata. On yearly billing, where the contract ends under 18.5 before the end of the year paid for, ZeeDo recalculates the yearly fee as the monthly price for each monthly period that has begun until the contract ends, and refunds the rest of the yearly fee; it never charges more than the yearly fee already paid. Extra usage already used remains payable.

18.8 Deleting sooner. If the Customer itself deletes a workspace or the organisation, deletion starts at once and deleted data is purged from backups within 30 days. Deleted data cannot be restored.

18.9 Free. A Free organisation has no paid period. If it is terminated, day 0 is the effective date of termination. A switching request on Free follows 18.3 to 18.5, with a notice period that ends at the end of the calendar month in which ZeeDo receives the request, and no fees.

18.10 What is kept after deletion. ZeeDo keeps, after deletion, only the records the Privacy Policy (section 6) and Annex 4 of the DPA list, for the periods they state, for example to meet its legal duties to keep records, to prevent abuse, and as evidence of the contract and of who authorised what. Among them are: audit and consent records for 400 days from their creation, and at most a month longer, because the log is deleted one calendar month at a time; invoices and credit notes for 8 years from the end of the calendar year of issue; the business letters ZeeDo sent, among them the contract confirmations and the notices of changes to these terms, the Acceptable Use Policy or the DPA, for 6 years from the end of the calendar year in which they were sent; and the records of who accepted which version of these terms, the Acceptable Use Policy and the DPA, and of objections, until the end of the third calendar year after the contract ended and at least as long as the confirmation.

19. The service and defects

19.1 The service. ZeeDo provides the service as these terms and the documentation for the Customer's plan describe, with reasonable skill and care.

19.2 Security measures. ZeeDo does not reduce the overall level of protection of the technical and organisational measures in Annex 2 of the DPA during a paid period.

19.3 What the service does not include. Beyond 19.1 and 19.2, the agreed quality of the service does not include that Output is accurate, complete or fit for a particular purpose (6.3), that a third-party service or website will accept a bot's access, or that the service is available without interruption (11.1). ZeeDo gives no guarantee (Garantie) unless an Enterprise order form expressly calls a statement a guarantee. Statements in marketing, decks or security questionnaires are not guarantees.

19.4 Reporting and remedying defects. The Customer reports a defect without delay, in text form, with the information ZeeDo needs to reproduce it. Where a defect is not reported without delay, the Customer's rights are limited as section 536c BGB provides. ZeeDo remedies a defect within a reasonable time. It may do so by a workaround that removes the defect's effect on the agreed use.

19.5 Reduction of fees. On a paid plan, where a defect reduces the fees owed, the Customer claims the reduction from ZeeDo as a repayment and does not deduct it from fees due, unless its claim is undisputed or finally established by a court.

19.6 Defects present at conclusion. Liability regardless of fault for defects that already existed when the contract was concluded (section 536a (1), first alternative, BGB) is excluded on every plan. Liability for fault follows section 20.

19.7 Free. Free is provided without charge, so on Free there are no fees to reduce. ZeeDo's liability for damage on Free follows section 20.

20. Liability

20.1 Unlimited liability. ZeeDo is liable without limit:

• for damage caused by intent or gross negligence;
• for injury to life, body or health;
• under the German Product Liability Act (Produkthaftungsgesetz);
• where it fraudulently concealed a defect; and
• under a guarantee it expressly gave, as far as the guarantee reaches.

20.2 Cardinal obligations. In other cases, ZeeDo is liable for slight negligence only for breach of a cardinal obligation: an obligation whose fulfilment makes proper performance of the contract possible in the first place and on whose fulfilment the Customer regularly relies. That liability is limited to the damage that was foreseeable and typical for this type of contract when the contract was concluded.

20.3 Indirect loss and loss of data. Where ZeeDo is liable for slight negligence under 20.2, it is not liable for indirect loss or for lost profit, unless such loss was foreseeable and typical for this type of contract when the contract was concluded. For loss of data that the Customer can export or download (18.6), its liability under 20.2 is limited to the effort of restoring the data from the copies the Customer would have had if it had exported or downloaded that data at intervals suited to the data's importance (5.15, 18.1).

20.4 Cap on paid plans. On a paid plan, ZeeDo's total liability under 20.2 is also limited to the greater of (a) the fees the Customer paid or must pay ZeeDo for the 12 months before the event giving rise to the claim and (b) USD 100 (EUR 100 for an organisation billed in EUR). If this cap is invalid, 20.2 still applies.

20.5 Free. On Free, which ZeeDo provides without charge, 20.2 and 20.3 apply, and ZeeDo's total liability under 20.2 is also limited to EUR 100. If this limit is invalid, 20.2 still applies.

20.6 Bot actions. ZeeDo is not liable for an action a bot took within the authority the Customer configured (3.3, 3.4), unless an enforced control failed to work as documented (3.5). Liability for such a failure follows 20.2 to 20.5. A defect of the service itself, such as a tool ZeeDo provides doing something other than what the bot requested, is not an action of a bot: it follows section 19 and 20.1 to 20.5. This does not limit 20.1.

20.7 Limitation period. Claims against ZeeDo for damages, for reimbursement of expenses or arising from defects become time-barred one year after the statutory limitation period starts (section 199 (1) BGB). This does not apply in the cases of 20.1.

20.8 People. The limits in this section also apply to the personal liability of ZeeDo's employees, representatives and agents, including those it uses to perform its obligations.

20.9 Data subjects. Nothing in these terms limits either party's liability to a data subject under Article 82 GDPR. Between the parties, a claim for recourse under Article 82 (5) GDPR follows this section.

21. Indemnity

21.1 The Customer indemnifies ZeeDo against claims of third parties, including the reasonable costs of legal defence, that arise from:

• the actions of its bots within the authority the Customer configured, including actions induced by third-party content (3.4);
• Instructions the Customer or its Members gave;
• Customer Content, and content its bots created or sent;
• messages its bots sent to third parties;
• the Customer's lack of a right or permission its bots exercised (5.1);
• a breach of the Acceptable Use Policy; or
• a breach of section 5 or of 7.6.

This does not apply where the Customer shows that it was not responsible for the circumstance that caused the claim.

21.2 The indemnity does not cover fines or other penalties imposed on ZeeDo. It does not apply to the extent a claim results from a failure of an enforced control (3.5) or from ZeeDo's own breach of these terms or of the law.

21.3 ZeeDo will notify the Customer of a claim promptly, let the Customer control the defence where the law allows, and cooperate reasonably. The Customer may not settle a claim that imposes an obligation on ZeeDo without ZeeDo's consent.

22. Confidentiality

Each party keeps confidential the other's non-public information that it receives under these terms, uses it only to perform this contract, and protects it with at least reasonable care. This does not apply to information that is public, already known, independently developed, or that a party must disclose by law. Customer Content and personal data are also governed by the DPA.

23. Changes

23.1 To the service. ZeeDo may develop and change the service where the change is reasonable for the Customer, taking ZeeDo's interests into account, for example to keep up with technology, the law, security or the services of its providers. ZeeDo will not remove a material feature of a paid plan during a paid period.

23.2 To these terms, the Acceptable Use Policy and the DPA.

• (a) Notice. ZeeDo gives at least 30 days' notice of a change, by email to the Owners and in the product. The notice includes the new text and the address at which it is kept, a summary of what changes, the date on which the change takes effect, and the Customer's right to object.
• (b) Changes that take effect unless the Customer objects. A change that the law or a court or authority requires, a change that does not disadvantage the Customer, and a technical or editorial change take effect on the date stated unless the Customer objects before that date. ZeeDo points out this consequence in the notice.
• (c) Objection. If the Customer objects, the change does not take effect for it. The Customer may then end the contract with effect from the date the change would have taken effect, and ZeeDo refunds the fees paid in advance for the time after that date. Otherwise the contract continues on the earlier version until ZeeDo ends it under 24.3.
• (d) Changes that need acceptance. A change to the main obligations (the scope of the service, fees other than under 23.3, the allocation of responsibility or liability between the parties, the Customer's duties, or the Customer's rights in its data) takes effect only when an Owner accepts it in the product. Without that acceptance, the contract continues on the earlier version until ZeeDo ends it under 24.3.
• (e) Urgent changes. Where the law or an authority requires a change sooner, ZeeDo gives as much notice as it can.
• (f) Record. ZeeDo records each notice, objection and acceptance against the organisation.

23.3 To prices. Prices change at most once a year, never during a paid subscription period, and with at least 30 days' notice by email to the Owners and in the product. A new price applies from the first paid period that starts after the notice period. The Customer may cancel before then (16.4), and the notice says so. The euro and dollar price lists are set separately and do not follow exchange rates.

24. Term and termination

24.1 The contract starts when these terms are accepted and runs until it ends under 16.4, 17.3, section 18 or this section. Section 18's provisions for the time after end of service, and sections 20, 21, 22 and 25, continue to apply after the contract ends.

24.2 The Customer may terminate at any time by cancelling (16.4) or, on Free, by deleting its organisation.

24.3 ZeeDo may terminate a paid subscription with 30 days' notice, effective at the end of a billing period, and refunds fees paid in advance for any period after the effective date. ZeeDo may terminate Free with 30 days' notice.

24.4 Either party may terminate for good cause without notice. Good cause for ZeeDo includes a serious breach of the Acceptable Use Policy, a breach of it that the Customer repeats after ZeeDo has warned it in text form, a case under 10.2 that is not resolved, an untrue statement under 1.3, and a case in which sanctions law requires it or the Customer's statement in 5.13 is untrue. Where the Customer terminates for good cause, or ZeeDo terminates for a cause the Customer is not responsible for, ZeeDo refunds the fees paid in advance for the time after the termination, as far as the law allows.

25. Governing law and jurisdiction

25.1 German law applies, excluding the UN Convention on Contracts for the International Sale of Goods (CISG).

25.2 Where the Customer is a merchant (Kaufmann), a legal person under public law or a special fund under public law, or has no general place of jurisdiction in Germany, the courts of Berlin, Germany, have exclusive jurisdiction for all disputes arising out of or in connection with these terms. ZeeDo may also sue the Customer at the Customer's general place of jurisdiction where that lies in a Member State of the European Union or in a state bound by the Lugano Convention. In all other cases the statutory rules on jurisdiction apply.

26. General

26.1 Entire agreement. These terms, the documents in 1.5 and, for Enterprise, the order form are the whole agreement. The signed order form prevails over these terms only where it says so expressly and names the section it changes. Where the DPA and these terms conflict on the processing of personal data, the DPA prevails.

26.2 Assignment. ZeeDo may transfer this contract to an affiliate or to a successor to its business, on notice to the Customer. If the Customer objects, it may end the contract with effect from the transfer, and ZeeDo refunds fees paid in advance for the time after it. The Customer may transfer the contract only with ZeeDo's consent, which ZeeDo will not refuse unreasonably.

26.3 Force majeure. Neither party is liable for a failure caused by events beyond its reasonable control. Such events on a party's side do not excuse its obligation to pay money that is due.

26.4 Notices. ZeeDo sends notices to the Owners' email addresses and in the product. The Customer sends notices to contact@zeedo.cloud or to the postal address in 1.1. Text form (section 126b BGB) is enough for any notice under these terms.

26.5 Language. These terms are published in English, and the English version is binding.

26.6 Severability, set-off and retention. If a provision is invalid, the rest remains in force. The Customer may set off or withhold payment only with claims that are undisputed, finally established by a court, or arise from the same contract. A reduction of fees for a defect follows 19.5.

Schedule 1 — In-product consent moments

The product asks for each of these confirmations at the moment shown. Each is rendered from a versioned entry in ZeeDo's catalogue of consent texts. Each confirmation is recorded in the audit log with the time, the actor, the text's id and version, the SHA-256 digest of the exact text shown, the version of these terms in force, and whether the person had just re-authenticated. The time is the moment the decision is saved after the person presses confirm.

There is no consent moment for a payment method, because no bot is permitted to pay (4.2).

Schedule 2 — AI transparency statement (EU AI Act, Article 50)

How ZeeDo tells people they are dealing with an AI

1. People who use ZeeDo. Bots are labelled as bots in the ZeeDo interface.
2. People a bot contacts. The first message a ZeeDo bot sends in each conversation or thread, on each channel, carries a line naming the bot and the organisation it works for, for example — Kai, an AI assistant at Trailpost. Every email a bot sends carries the same line in its signature. ZeeDo's systems add the line when the message is sent. The model does not write it, and no plan or setting turns it off. Where ZeeDo's systems send an email as a complete message, they also mark it as AI-generated in a machine-readable way, with the header fields X-AI-Generated: yes and X-AI-Disclosure, which gives the address of this statement, set when the message is sent and never by the model; an email a bot writes in a web page, or through a mail service's own tool, carries the line but not these fields, because there the mail service writes the header.
3. Generated media. Images, audio and video a bot generates and sends through ZeeDo carry C2PA provenance data, signed by ZeeDo outside the bot's machine.
4. What is not marked. The line is not added to a form a bot fills in on a third party's website, because it would be written into the data the form submits. Nor is it added to files, or to content a person sends.
5. Who does what. ZeeDo is the provider of the ZeeDo agent system: it places the system on the market and designs these transparency features. Each customer is the system's deployer: it decides how, where and for what its bots are used, and discloses AI-generated or manipulated content it publishes where Article 50 (4) of the AI Act requires it.