Data Processing Agreement (DPA)

This Data Processing Agreement (“DPA”) is entered into by and between the entity signing or agreeing to these terms online or via an executed Order Form (“Customer”, acting as Data Controller) and Beings Beam Ltd (trading as “Beings”, a company incorporated under the laws of England and Wales with company number 13484197, hereinafter “Beings”, acting as Data Processor).

Preamble

WHEREAS, Beings provides its products and services, which may include artificial intelligence agent and orchestration software and associated cloud services (the “Services”), pursuant to the Master Services Agreement or other principal commercial agreement entered into between the parties (the “Agreement”);

WHEREAS, in providing the Services, Beings may process certain personal data on behalf of the Customer within the runtime environments of the Services; and

WHEREAS, the parties desire to supplement the Agreement to incorporate these data protection terms to ensure compliance with Data Protection Legislation, including the UK GDPR (as amended by the Data (Use and Access) Act 2025) and the EU GDPR.

THEREFORE, the parties agree as follows:

Section 1: Definitions and Interpretation

1.1 Statutory Definitions: The terms “Controller”, “Processor”, “Data Subject”, “Personal Data”, “Personal Data Breach”, “Processing”, and “Supervisory Authority” shall have the structural meanings assigned to them under applicable Data Protection Legislation.

1.2 Custom AI-Native Definitions: For the purposes of this DPA and the runtime environment provided by Beings, the following terms shall have the specific meanings set forth below:

  • “Agent Prompts” means any text, code, voice inputs, files, data sets, or structural payloads inputted, uploaded, or transmitted into the Services by or on behalf of the Customer to instruct, contextualise, or program a digital agent executed within the Beings ecosystem.
  • “Agent Outputs” means the text, data arrays, automated actions, execution code, API requests, or structured outputs generated autonomously or semi-autonomously by digital agents within the Services in response to Agent Prompts or environment states.
  • “Customer Content” means all data provided by, or generated on behalf of, the Customer through its use of the Services that contains personal data, including (where the Services use AI agents) Agent Prompts and Agent Outputs.
  • “Customer-Provisioned Models” (also referred to as “Bring Your Own Key” or “BYOK”) means any artificial intelligence large language models (LLMs), foundational algorithms, or API endpoints that are integrated into the platform via the Customer’s independent, external API credentials, corporate contracts, or local/on-premise deployments controlled entirely by the Customer.
  • “Data Protection Legislation” means all applicable regional, national, and international laws and regulations governing the privacy, security, and processing of Personal Data, including but not limited to:
    • (i) the UK GDPR (as defined in the Data Protection Act 2018 and updated by the Data (Use and Access) Act 2025);
    • (ii) the EU GDPR (Regulation (EU) 2016/679);
    • (iii) the EU AI Act (Regulation (EU) 2024/1689);
    • (iv) applicable United States state-level privacy laws (including the California Consumer Privacy Act as amended by the CPRA); and
    • (v) the Swiss Federal Act on Data Protection (“FADP”), each as amended, replaced, or superseded from time to time.
  • “Operational Telemetry” means metadata systematically generated by the platform performance, usage, and infrastructure routing layers of the Beings environment, including but not limited to: aggregate token usage metrics, system latency, execution graph traversal statistics, runtime error codes, security events, and platform utilisation metrics, which do not contain raw Customer Content or unmasked personal data.
  • “Vendor-Provisioned Models” means the third-party foundational AI models or API nodes engaged by Beings and executed utilising platform computing layers managed by Beings. The Services are model-agnostic; the sub-processor list referenced in Annex C is the authoritative source of approved model providers, and the Agreement or Order Form specifies which of those apply to a given deployment.

1.3 Construction: References to any statute, enactment, or statutory framework shall include references to that legal authority as extended, amended, consolidated, or re-enacted from time to time (specifically incorporating updates mandated by the UK Data (Use and Access) Act 2025 and shifting designations of the Information Commission).

Section 2: Scope of Application and Role Allocation

2.1 Scope: This DPA applies to the Processing of Personal Data contained within Customer Content (including, where the Services use AI agents, Personal Data uploaded via Agent Prompts or generated within Agent Outputs) by Beings on behalf of the Customer in providing the Services.

2.2 Role Allocation: The parties acknowledge and agree that for the purposes of this DPA and Data Protection Legislation:

  • (a) The Customer acts as the Data Controller (or as a processor executing instructions on behalf of a third-party controller) with respect to Customer Content; and
  • (b) Beings acts as the Data Processor with respect to the Customer Content processed within the platform’s execution paths and memory boundaries.

2.3 Structure of Processing Instructions: The Agreement, this DPA, and the specific configurations, tool connections, and programmatic logic designed or enabled by the Customer within the Services constitute the Customer’s complete and documented instructions to Beings for the Processing of Personal Data. Beings shall process Customer Content only in accordance with these documented instructions, unless required to do otherwise by applicable law to which Beings is subject.

2.4 Application to AI features: Provisions of this DPA that refer to AI agents, foundation models, Agent Prompts, Agent Outputs, Vendor-Provisioned Models, or related inference processing apply only to the extent the relevant Services include such features for the Customer. All other provisions apply to the Services generally.

Section 3: The AI Data Carve-Out (Operational Telemetry and Aggregated Data)

3.1 Independent Controller Status for Telemetry: The Customer acknowledges and explicitly agrees that Operational Telemetry systematically generated by the Beings platform performance, infrastructure routing, and orchestration layers is not Customer Content. To the extent that any Operational Telemetry is deemed to contain or constitute Personal Data under applicable Data Protection Legislation, Beings acts as an independent Data Controller of such data.

3.2 Permitted Use of Operational Telemetry: Beings may process, analyse, and retain Operational Telemetry for its own independent, lawful business purposes, including:

  • (a) Monitoring platform health, security, and integrity;
  • (b) Calculating API usage, computing consumption, and tracking token overhead;
  • (c) Debugging agent execution pathways, systemic errors, and latency bottlenecks; and
  • (d) Optimising real-time model routing, semantic caching efficiencies, and platform performance.

3.3 Anonymised and Aggregated Data: The parties agree that data that has been stripped of individual identifiers, anonymised, or aggregated such that it can no longer identify a natural person (“De-Identified Data”) does not constitute Personal Data under Data Protection Legislation.

3.4 Exclusion from DPA Scope: This DPA does not apply to De-Identified Data. Beings reserves the right to generate De-Identified Data from the execution of the Services and may use, retain, and exploit such data to improve agent logic, enhance internal platform capabilities, optimise systemic memory routing, and train or validate its proprietary orchestrator routing algorithms without restriction or reference to this DPA, provided that such data remains fully anonymised and is never re-identified.

Section 4: Obligations of the Processor (Beings)

4.1 Compliance with Instructions: Beings shall process Customer Content only on behalf of and in strict accordance with the documented instructions of the Customer (including as programmatically executed via the customer’s agent profiles and pipeline configurations), unless Beings is required to do otherwise by UK, EU, or member state law to which Beings is subject. In such a case, Beings shall inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

4.2 The Zero-Training Guarantee: Beings explicitly covenants and guarantees that it shall not use Customer Content (including any personal data contained within Agent Prompts or Agent Outputs) to train, fine-tune, retrain, or improve any public, foundational, or cross-tenant large language models (LLMs) or artificial intelligence systems owned by Beings or its third-party sub-processors, unless explicitly requested and configured by the Customer via an opt-in platform capability.

4.3 Personnel Confidentiality: Beings shall ensure that its employees, contractors, and any other personnel authorised to process Customer Content within the platform’s infrastructure are subject to binding statutory or contractual obligations of confidentiality, and that they receive adequate training regarding data protection and security protocols.

4.4 Security of Processing: Beings shall implement and maintain the appropriate technical and organisational measures specified in Annex B (Technical & Organisational Measures) of this DPA to ensure a level of security appropriate to the risks of processing Customer Content within the Services.

Section 5: Customer Responsibilities and AI Guardrails

5.1 Lawful Basis for Agent Ingestion: The Customer is solely responsible for ensuring that it has established and maintains a valid lawful basis (including, where necessary, explicit individual consent or legitimate interest frameworks) under Data Protection Legislation for all Personal Data ingested into the Services via Agent Prompts. The Customer warrants that it has provided all necessary transparency disclosures and privacy notices to its respective Data Subjects regarding how its configured agents will process their data.

5.2 Automated Decision-Making (ADM) Compliance: To the extent that the Customer configures, programs, or deploys Beings agents to perform automated processing that results in decisions producing legal effects or similarly significantly affecting natural persons (under Article 22 UK/EU GDPR and the UK Data (Use and Access) Act 2025):

  • (a) The Customer acknowledges that it acts as the sole decision-maker and Deployer of the AI system;
  • (b) The Customer is entirely responsible for implementing appropriate safeguards for the Data Subject, including providing clear pathways for human intervention, mechanisms for the Data Subject to express their point of view, and a methodology to contest the automated agent’s output; and
  • (c) The Customer shall ensure that its use of agents for ADM aligns with the updated parameters of the UK Data (Use and Access) Act 2025 regarding safeguards and notifications.

5.3 Sensitive and Special Category Data Gate: The Customer shall not configure, instruct, or allow Beings agents to collect, process, or synthesise special categories of personal data (as defined under Article 9 of the UK/EU GDPR, including medical, genetic, biometric, or political data) or criminal conviction data, unless:

  • (a) The Customer has provided prior written notice to Beings;
  • (b) The parties have mutually executed a specific High-Risk Data Addendum; and
  • (c) The Customer has confirmed an absolute lawful exemption applies under Data Protection Legislation and has conducted a comprehensive Data Protection Impact Assessment (DPIA).

Beings assumes no liability under this DPA for unauthorised or unnotified Special Category Data processed within the platform.

5.4 Protected Health Information (HIPAA): Where the Customer is a covered entity or business associate (as defined under the U.S. Health Insurance Portability and Accountability Act, “HIPAA”) and the Services will be used to process protected health information (“PHI”), the parties shall execute Beings’ Business Associate Agreement (BAA), which supplements this DPA and governs the Processing of such PHI. Beings shall not process PHI until a BAA is in place.

Section 6: Sub-processors and Infrastructure Mapping

6.1 General Written Authorisation: The Customer hereby grants Beings general written authorisation to engage third-party sub-processors (including Vendor-Provisioned Models and cloud hosting providers) to process Customer Content on behalf of the Customer. The active list of sub-processors approved by the Customer at the time of executing this DPA is set forth in Annex C.

6.2 The “Bring Your Own Key” (BYOK) Firewall: The parties explicitly agree that where the Customer configures the Services to utilise Customer-Provisioned Models (e.g., the Customer plugs in their own corporate API keys for OpenAI, Azure, or runs local open-source models), such model providers are not sub-processors of Beings.

  • (a) Customer-Provisioned Models are classified as Third-Party Services controlled entirely by the Customer.
  • (b) Beings operates merely as a conduit passing data to these endpoints at the Customer’s explicit programmatic instruction.
  • (c) Beings assumes zero liability, oversight, or data protection obligations regarding the processing, retention, or breaches occurring within Customer-Provisioned Models.

6.3 Notification of Sub-processor Changes: Beings shall maintain a current list of its active sub-processors and make it available to the Customer on request (or by email notification). Beings shall provide the Customer with at least thirty (30) days’ prior notice of any intended appointment of a new sub-processor or structural replacement of a Vendor-Provisioned Model node, except where an immediate replacement is required to mitigate a critical security vulnerability, a service outage, or a third-party model deprecation, in which case Beings shall notify the Customer as soon as reasonably practicable.

6.4 Objection Mechanism: The Customer may object to the appointment of a new sub-processor on legitimate data protection grounds by notifying Beings in writing within thirty (30) days of receiving the notification.

  • (a) In the event of a valid objection, Beings shall use reasonable endeavors to provide an alternative configuration of the Services or route processing away from the contested sub-processor.
  • (b) If Beings is unable to provide an alternative within thirty (30) days, either party may terminate the affected portion of the Services or the Agreement for convenience without penalty.

6.5 Flow-Down Obligations: Where Beings engages a sub-processor under Section 6.1, Beings shall enter into a formal, binding written agreement that imposes data protection obligations no less restrictive than those imposed on Beings under this DPA. Beings remains fully liable to the Customer for the performance of its sub-processors’ data protection obligations.

Section 7: Data Subject Rights and Regulatory Assistance

7.1 Data Subject Requests (DSARs): Taking into account the nature of the processing, Beings shall implement appropriate technical and programmatic tools within the Services to assist the Customer, insofar as reasonably practicable, in responding to individuals exercising their rights under Data Protection Legislation (including rights of access, rectification, portability, and erasure).

7.2 Operational Limits within Agent Memory: The Customer acknowledges that digital agents utilise complex data pipelines, including transient context windows, short-term semantic caches, and long-term vector databases (embeddings).

  • (a) If a Data Subject requests the absolute erasure of their Personal Data, Beings shall assist the Customer by providing mechanisms to purge the relevant records from the Customer’s single-tenant vector stores and persistent database silos.
  • (b) The Customer acknowledges that due to the mathematical nature of machine learning weights, Beings cannot surgically excise personal data from foundational models, which is why the Zero-Training Guarantee in Section 4.2 serves as the primary safeguard.

7.3 Regulatory Cooperation: Beings shall notify the Customer without undue delay if it receives a request directly from a Data Subject or a Supervisory Authority (such as the UK ICO or an EU DPA) regarding the processing of Customer Content. Beings shall not respond to such requests directly unless explicitly authorised by the Customer or required to do so by applicable law.

7.4 Data Protection Impact Assessments (DPIAs): Taking into account the nature of the processing and the information available to Beings, Beings shall provide reasonable assistance to the Customer to enable them to conduct DPIAs or prior consultations with Supervisory Authorities. This includes providing architectural documentation detailing sandbox boundaries, context truncation rules, and token routing workflows, particularly when the Customer is evaluating the high-risk deployment of autonomous agents under the EU AI Act or UK Data Legislation.

7.5 Costs of Assistance: The standard tools, documentation, and information that Beings makes generally available are provided at no additional charge. Where assistance requested under this Section 7 goes materially beyond that — or is repetitive, voluminous, or manifestly unfounded — Beings may charge the Customer a reasonable fee based on its administrative cost of providing the assistance.

Section 8: Security and Audits

8.1 Technical and Organisational Measures (TOMs): Beings shall implement, maintain, and enforce the administrative, physical, and technical safeguards specified in Annex B to protect Customer Content against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access.

8.2 Silo Guarantee and Logical Isolation: Taking into account the proprietary nature of the Services, Beings specifically covenants that, where the Services store persistent Customer Content:

  • (a) Customer Content, short-term agent memory states, and long-term vector embeddings shall be stored within containerised, single-tenant, or logically isolated per-silo data stores behind strict credential and sandbox boundaries; and
  • (b) Beings shall enforce programmatic blocks to guarantee absolute isolation between tenants, ensuring that data processed within the execution path of one customer’s agents cannot contaminate, leak into, or be processed by the agents or memory stores of another customer.

8.3 Audit Rights and Equivalency: The Customer has the right to verify Beings’ compliance with its obligations under this DPA. To balance the Customer’s regulatory verification requirements with the security of Beings’ proprietary software and multi-tenant hosting infrastructure, the parties agree to the following audit protocol:

  • (a) Certifications as Primary Proof: The Customer agrees that the review of Beings’ current, independent third-party security certifications—specifically including its annual SOC 2 Type II audit report and/or ISO/IEC 27001 certification—shall fully satisfy the Customer’s initial right to audit under Data Protection Legislation.
  • (b) Bespoke Audits: If the Customer can demonstrate that the standard certification reports are insufficient to satisfy their regulatory requirements, or if a Supervisory Authority mandates an independent assessment, Beings shall permit the Customer (or a mutually agreed, independent third-party auditor bound by strict non-disclosure terms) to conduct a remote, structured audit.
  • (c) Audit Limitations: Any audit conducted under Section 8.3(b) must be requested with at least thirty (30) days’ prior written notice, occur during regular business hours, minimise disruption to platform operations, and occur no more than once per calendar year (unless following a confirmed Personal Data Breach). Under no circumstances shall the Customer or its auditors be granted physical access to Beings’ data centres or direct logical access to Beings’ source code, proprietary weights, or orchestrator routing algorithms. The Customer shall bear all financial costs associated with such an audit.

Section 9: Personal Data Breach Notification

9.1 Verification and Clock Trigger: Beings shall notify the Customer in writing without undue delay, and in any event within seventy-two (72) hours, of becoming aware of a Personal Data Breach affecting Customer Content within the Services environment. For clarity, “becoming aware” means Beings has established a reasonable degree of certainty that a security incident leading to a Personal Data Breach has occurred, rather than mere detection of an unverified anomaly.

9.2 Content of Notification: To the extent known at the time of disclosure, the breach notification provided by Beings shall include:

  • (a) A description of the nature of the Personal Data Breach, including the approximate categories and number of Data Subjects and Customer Content records compromised;
  • (b) The identity and contact details of Beings’ data protection officer or security point of contact;
  • (c) The likely consequences or impact of the security incident on the affected Services; and
  • (d) A description of the remedial measures taken or planned by Beings to mitigate the adverse effects of the incident.

9.3 Provisional Reporting: Where it is not possible to provide the complete information specified in Section 9.2 simultaneously, Beings may provide the information in phases without undue further delay as it becomes available through forensic analysis.

9.4 Mitigation Actions: Beings shall immediately take all commercially reasonable operational steps to mitigate the effects of any confirmed Personal Data Breach, restore platform integrity, and secure the affected Customer environments.

9.5 No Admission of Fault: The notification of or response to a Personal Data Breach by Beings under this Section 9 shall not be construed or interpreted as an admission of fault, negligence, or liability by Beings regarding the security incident.

Section 10: Data Retention, Return, and Erasure

10.1 Expungement Upon Termination: Within thirty (30) days of the termination or expiration of the Agreement, or upon the Customer’s written request, Beings shall delete or return all Customer Content (including Personal Data resident within any active agent memory configurations, contextual histories, and siloed data stores) held in Beings’ own systems, unless applicable UK, EU, or member state law requires the continued preservation of such Personal Data. Deletion by sub-processors is addressed in Section 10.4.

10.2 Differentiated Data Erasure Lifecycles: The Customer acknowledges that data processing within the Services occurs across structurally distinct layers with differing retention profiles:

  • (a) Transient Inference Cache: Prompts, context variables, and intermediate agent scratchpad reasoning arrays passed to Vendor-Provisioned Models are processed transiently and are not persistently retained by Beings post-inference. They remain subject to the security, compliance, and anti-abuse caching windows enforced by downstream foundation-model infrastructure, which may be up to ninety (90) days, or zero where an approved zero-retention / abuse-logging opt-out is in place with the relevant provider.
  • (b) Persistent Vector Memory Silos: Customer-configured agent memories, episodic histories, and semantic embeddings are retained persistently within the Customer’s isolated database silo for the duration of the Services, and are purged entirely upon the execution of the deletion procedures set forth in Section 10.1.

10.3 Archive and Backup Survival: To the extent that Customer Content is resident within Beings’ automated disaster recovery and backup archives, such data shall be structurally isolated and rendered beyond the scope of active processing. Beings shall ensure that such archived copies are permanently and securely overwritten, destroyed, or deleted in accordance with Beings’ standard backup retention cycle, which shall not exceed thirty (30) days from the initial deletion request.

10.4 Sub-processor Deletion Timelines: Beings shall procure deletion of Customer Content held by its sub-processors within the wind-down period applicable to the relevant sub-processor. Beings shall not represent to the Customer deletion timelines shorter than those its sub-processors actually provide.

Section 11: General Commercial Provisions and Order of Precedence

11.1 Order of Precedence: This DPA supplements the Agreement. In the event of any structural conflict, ambiguity, or inconsistency between the provisions of the Agreement (MSA) and this DPA, the parties agree to the following resolution protocol:

  • (a) Data Protection Matters: This DPA shall prevail and override the Agreement solely regarding the technical obligations, processing instructions, and privacy rules governing the handling of Customer Personal Data.
  • (b) Commercial and Liability Matters: The Agreement (MSA) shall absolutely prevail over this DPA regarding all commercial parameters, including but not limited to: governing law, jurisdiction, indemnification procedures, and financial limitations or caps on liability.

11.2 Integration of Liability Caps: The parties explicitly agree that any financial liability arising out of or related to breaches of this DPA, regulatory non-compliance, or data protection failures under Data Protection Legislation shall be subject to the aggregate limitations of liability and caps set forth in the Agreement (MSA). Under no circumstances shall this DPA be construed to create an independent, separate, or uncapped pool of financial liability.

11.3 Governing Law and Jurisdiction: This DPA and any non-contractual obligations arising out of or in connection with it shall be governed by, construed, and enforced in accordance with the governing law and jurisdiction clauses specified in the Agreement (MSA), without causing local fragmentation of the legal framework.

11.4 Severability: If any individual provision of this DPA is held by a court of competent jurisdiction or an applicable Supervisory Authority to be invalid, illegal, or unenforceable, the validity, legality, and enforceability of the remaining provisions shall not be affected, and shall continue in full contractual force.

11.5 Data Protection Contact: Beings’ Data Protection Officer is Dave Johnstone (trust@beings.com), Beings Beam Ltd, 7 Bell Yard, London, England, WC2A 2JR. Notices to Beings under this DPA may be sent to that contact.

11.6 Online Version and Precedence of Negotiated Terms:

  • (a) Online version. The current version of this DPA is published at beings.com/data-processing-agreement/ and may be updated by Beings from time to time. The version in effect at the relevant time is incorporated into the Agreement by reference; the parties may also accept it via click-through at sign-up or append it to an Order Form.
  • (b) Negotiated terms prevail. Where the parties have separately executed a negotiated or amended DPA or addendum, that signed document supersedes and prevails over the online version with respect to that Customer, and subsequent updates to the online version shall not modify those signed terms unless the parties agree in writing.
  • (c) Notice of changes. Beings will provide reasonable prior notice of any material change to the online version of this DPA (and notice of sub-processor changes in accordance with Section 6.3).

Global Jurisdictional Modules (Schedules)

These regional schedules supplement the core DPA and are automatically activated based on the geographical location of the Data Subjects and the applicable legal jurisdiction governing the Customer Content.

Schedule 1: UK GDPR & Data Transfer Module

  1. Application: This Schedule 1 applies solely to the Processing of Customer Content subject to the UK GDPR and the Data Protection Act 2018 (as amended by the Data (Use and Access) Act 2025).
  2. International Data Transfers: Where the execution of the Services or the routing of digital agents requires the transfer of Customer Content out of the United Kingdom to a country that has not been granted an adequacy regulation by the UK Government, the parties hereby incorporate and execute the UK Addendum to the EU Standard Contractual Clauses (issued by the Information Commissioner’s Office under Section 119A of the Data Protection Act 2018) as appended below:
    • (a) Table 1 (Parties): The details match the Preamble of this DPA.
    • (b) Table 2 (Selected SCCs): Incorporates the EU SCCs as modified by this Schedule.
    • (c) Table 3 (Annexes): The technical specifications correspond directly to Annex A and Annex B of this DPA.
    • (d) Table 4 (Termination): Either party may terminate the UK Addendum in accordance with its standard terms.
  3. Alignment with the Data (Use and Access) Act 2025:
    • (a) The parties acknowledge that under the updated UK framework, the definitions of automated processing and the governance surrounding data subject complaints have been modified.
    • (b) Beings shall maintain standard compliance logs to assist the Customer in meeting its statutory transparency obligations under the revised UK data legislation.

Schedule 2: European Union (EEA) GDPR Module

  1. Application: This Schedule 2 applies solely to the Processing of Customer Content subject to the EU GDPR (Regulation (EU) 2016/679) regarding Data Subjects located within the European Economic Area (EEA).
  2. Incorporation of Standard Contractual Clauses (SCCs): For international data transfers from the EEA to third countries without an adequacy decision, the parties hereby incorporate by reference the European Commission’s Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914):
    • (a) Module Selection: Module Two (Controller-to-Processor) applies where the Customer is a Controller, and Module Three (Processor-to-Processor) applies where the Customer is a processor acting on behalf of a third-party controller.
    • (b) Clause 7 (Docking Clause): The optional docking clause is incorporated.
    • (c) Clause 9 (Sub-processors): Option 2 (General Written Authorisation) applies, matching the thirty (30) day notification window specified in Section 6.3 of this DPA.
    • (d) Clause 11 (Redress): The optional wording regarding independent dispute resolution is excluded.
    • (e) Clause 17 (Governing Law) & Clause 18 (Choice of Forum): The parties select the law and courts of Ireland for the resolution of EEA data transfer disputes.
  3. EU AI Act Shared Responsibilities:
    • (a) The Customer acknowledges that if it deploys Beings agents for use cases classified as “High-Risk” under the EU AI Act (Regulation (EU) 2024/1689), the Customer acts as the Deployer of the AI system.
    • (b) While Beings provides the underlying Services and technical logs, the Customer bears all statutory obligations under the AI Act regarding human oversight, input data quality validation, continuous post-deployment monitoring, and local regulatory reporting.

Schedule 3: United States Privacy Module

  1. Application: This Schedule 3 applies to the Processing of Customer Content belonging to residents of the United States where state-level comprehensive privacy laws apply (including but not limited to the California Consumer Privacy Act as amended by the CPRA, and equivalent statutory frameworks in Virginia, Colorado, Texas, and other applicable states).
  2. Role Clarification: The parties acknowledge and agree that Beings acts strictly as a Service Provider (under the CCPA/CPRA) and a Processor under general US state privacy frameworks.
  3. Processing Constraints: Beings explicitly covenants that it:
    • (a) Shall not “Sell” or “Share” Customer Personal Data as those terms are statutory defined under US privacy laws;
    • (b) Shall not retain, use, or disclose Customer Personal Data for any commercial purpose other than the specific business purposes defined in the Agreement and this DPA, or as otherwise permitted by applicable US privacy legislation;
    • (c) Shall not retain, use, or disclose Customer Personal Data outside of the direct business relationship established between Beings and the Customer; and
    • (d) Shall not combine Customer Personal Data received from the Customer with personal data received from, or on behalf of, separate clients, except to the extent necessary to perform systemic network debugging or platform routing optimisations permitted under the regulations.
  4. Compliance Certification: Beings certifies that it understands the contractual restrictions set forth in this Schedule 3 and agrees to comply with them fully. Beings shall notify the Customer without undue delay if it determines that it can no longer meet its obligations under applicable US state privacy laws.

Schedule 4: Swiss Data Protection Module

  1. Application: This Schedule 4 applies solely to the Processing of Customer Content subject to the Swiss Federal Act on Data Protection (“FADP”) regarding Data Subjects located within Switzerland.
  2. Terminology Alignment: For the purposes of this Schedule, references within the core DPA to the “GDPR”, “UK GDPR”, or “Supervisory Authority” shall be read as references to the “FADP” and the Swiss Federal Data Protection and Information Commissioner (FDPIC) respectively. References to “Personal Data” shall encompass personal data as defined under the revised FADP (restricted to natural persons).
  3. International Data Transfers from Switzerland:
    • (a) To the United Kingdom: The parties acknowledge that Switzerland recognises the United Kingdom as providing an adequate level of data protection. Transfers of Swiss Customer Content to Beings’ UK infrastructure are executed in reliance upon this adequacy recognition.
    • (b) Onward Transfers to Third Countries: To the extent that Beings transfers Swiss Customer Content onwards to sub-processors located in countries without an adequacy decision from the Swiss Federal Council (e.g., certain US-based model endpoints), the parties hereby incorporate the EU Standard Contractual Clauses (SCCs) selected in Schedule 2, subject to the following Swiss Modifications mandated by the FDPIC:
      • (i) The FDPIC shall act as the competent supervisory authority insofar as the data transfer governs Data Subjects protected under the Swiss FADP.
      • (ii) The term “Member State” must not be interpreted in a way that excludes Data Subjects in Switzerland from suing for their rights in their place of habitual residence (Switzerland) in line with Clause 18(c) of the SCCs.
      • (iii) The Clauses shall protect the data of natural persons in Switzerland to the exact extent mandated by the FADP.
  4. High-Risk and Special Category Processing: In accordance with Section 5.3 of the core DPA, the Customer shall not input, or instruct the Services to process, Swiss special-category data (as defined under the FADP, including health, genetic, or biometric data) unless the parties have executed a separate, mutually agreed High-Risk Data Addendum. The single-tenant sandbox and per-silo isolation protocols in Annex B support the data-integrity and isolation baselines required for such processing where that addendum is in place.

Technical Appendices (Annexes)

Annex A: Details of Processing

1. Categories of Data Subjects

The Personal Data processed within the Services may involve the following categories of natural persons, determined entirely by the Customer’s deployment configurations and use of the Services:

  • Employees, contractors, temporary staff, and internal users of the Customer.
  • Customers, prospects, clients, subscribers, and end-users of the Customer.
  • Suppliers, vendors, partners, and business associates of the Customer.
  • Any other third-party individuals who voluntarily or involuntarily communicate with, input data into, or are analysed by the digital agents deployed by the Customer.

2. Categories of Personal Data

The Personal Data processed encompasses any data arrays or unstructured information contained within Customer Content (Agent Prompts and Agent Outputs). This includes, but is not limited to:

  • Core Identifiers: Names, titles, aliases, business email addresses, telephone numbers, and corporate contact details.
  • Professional Data: Job titles, employers, department allocations, employment histories, CVs, and performance evaluations.
  • Communication Logs: Text transcripts, email threads, chat logs, voice payloads, and contextual metadata processed during agent workflows.
  • Commercial Data: Transaction histories, billing preferences, procurement logs, invoice numbers, and financial record references.
  • Technical Footprints: IP addresses, device identifiers, user credentials, and platform login details linked to individual end-users.

3. Special Categories of Personal Data (Subject to Section 5.3)

By default, the Customer is prohibited from injecting Special Category Data into the platform. If a specific High-Risk Data Addendum has been executed, authorised categories may include:

  • Health, medical, or clinical record summaries.
  • Biometric authentication tokens or facial geometry vectors.
  • Racial, ethnic, religious, or political affiliations explicit within unstructured text prompts.

4. Nature and Purpose of Processing

The nature and purpose of the Processing under this DPA consists of the provision of the Services to the Customer, which, where the relevant Services use AI agents, includes:

  • The execution, orchestration, and dynamic routing of AI agents.
  • The translation of Agent Prompts into machine-readable states, semantic embeddings, and context strings for execution.
  • The processing of Customer Content through Vendor-Provisioned Models to generate Agent Outputs.
  • The transient caching of inputs and intermediate variables to support stability, error debugging, and response generation.
  • The logical storage and indexing of interaction history within isolated, per-silo data stores to maintain continuous agent memory.

5. Duration of Processing and Retention Parameters

Processing Layer Data Retention Protocol Purge SLA
Transient Inference Cache Retained temporarily in-memory by Beings solely to complete the immediate real-time API call to the foundation-model node. Automatically overwritten upon completion of inference. Subject to the foundation-model provider’s enterprise retention terms — up to 90 days, or zero where an abuse-logging opt-out applies.
Persistent Vector Memory Silos Stored securely within the Customer’s containerised, single-tenant database silo to maintain agent memory and history. Maintained for the duration of the active subscription. Purged from Beings’ own systems within 30 days of contract termination; sub-processor deletion per Section 10.4.
Operational Telemetry Aggregate, de-identified platform utilisation metadata retained by Beings for system optimisation and performance auditing. Retained indefinitely by Beings as independent Controller (fully anonymised).

Annex B: Technical & Organisational Measures (TOMs)

Beings maintains a comprehensive, written information security programme designed to isolate, protect, and secure Customer Content processed within the Services. The core technical controls include:

1. Logical Isolation and Per-Silo Sandbox Architecture

  • Siloed Containment: Customer data paths are strictly compartmentalized. Each customer deployment operates within an isolated container runtime environment behind a dedicated credential boundary.
  • Vector DB Separation: Agent memory systems and vector embeddings are stored in single-tenant data stores or logically ring-fenced database clusters utilising strict Row-Level Security (RLS) policies. Cross-tenant queries are structurally prevented at the database schema layer.
  • Memory Contamination Preventions: System routing layers are programmatically restricted from injecting historical data or embeddings belonging to Tenant A into the semantic context window or reasoning loop of an agent executing for Tenant B.

2. Data Encryption Standards

  • Encryption in Transit: All Customer Content travelling across public networks or between the Beings platform and external API model nodes is encrypted utilising Transport Layer Security (TLS 1.3) or strong cryptographic protocols.
  • Encryption at Rest: All persistent database files, short-term caches, and vector embedding tables are encrypted at rest using Advanced Encryption Standard (AES-256) keys.

3. Access Control and Key Management

  • Zero-Access Personnel Policy: Beings limits access to live production databases to a minimum number of authorised operations engineers. Access requires mandatory Multi-Factor Authentication (MFA) and is managed via Just-In-Time (JIT) least-privilege tokens.
  • Credential Vaulting: For Customer-Provisioned Models (BYOK), API keys and secret variables are stored in dedicated hardware security modules (HSMs) or enterprise-grade secret vaults, encrypted with unique master keys, and never printed to system logs.

4. Vulnerability Management and AI-Specific Security

  • Prompt Injection Mitigations: The platform implements real-time semantic validation layers to detect and intercept adversarial prompt injection attempts before payloads enter the agent execution loop.
  • Continuous Monitoring: Production clusters undergo automated configuration tracking, continuous vulnerability scanning, and third-party penetration testing at least annually.

Annex C: Approved Sub-processor Directory

Beings maintains its current list of approved sub-processors — including each sub-processor’s name, processing activity, and data-centre location — as a separate document made available to Customers on request. That list is maintained and updated in accordance with Section 6.3 (Notification of Sub-processor Changes), which governs prior notice and the Customer’s objection rights.

The Services are model-agnostic; the foundation-model provider(s) engaged for a given deployment may be a subset of those listed and are specified in the Agreement. All listed sub-processors are engaged under enterprise data protection agreements that include contractual “zero-training” protections for enterprise API traffic. Customer-Provisioned Models (BYOK) are not sub-processors of Beings and are excluded under Section 6.2.

Login

Try for free