DATA PROCESSING AGREEMENT
Data Processing Agreement
This DPA forms part of the service agreement between Seleya Labs Inc. (“Seleya”) and the customer accepting it with the Terms or an identified Enterprise order (“Customer”). It applies to personal information in Customer Content processed on the Customer’s behalf. It states contractual duties; publication is not evidence that an agreement, supplier instrument or transfer schedule has been executed.
“Applicable Law” means data-protection law applicable to the particular processing, including GDPR, UK GDPR, POPIA and relevant Swiss law. POPIA personal information includes juristic-person information within its scope. The agreement’s accepted version must be preserved; earlier published texts are available.
1. Roles and scope
The Customer may be a controller / responsible party or a processor acting for another controller. Seleya acts as processor / operator, or subprocessor as appropriate. The Customer must identify its role and obtain any upstream authority needed.
This DPA does not cover Seleya’s separate controller purposes described in the Privacy Policy. Customer content in support or diagnostics remains subject to this DPA where processed on behalf of the Customer; calling it “support data” does not change that role.
TTL’s own invoicing is separate from service processing. Where TTL Technologies (Pty) Ltd supplies personnel/services with customer-content access, Seleya must place that processing under appropriate written operator/subprocessor terms and Customer authorisation. Common ownership does not replace those duties.
2. Processing details and instructions
Annex A describes the service processing; a completed customer-specific schedule adds the purchased deployment, enabled sources/tools, restrictions, retention and permitted destinations.
The agreement, this DPA, an agreed schedule and lawful use of enabled features provide documented instructions. Automatic routing and background tasks must remain within that scope. Additional lawful instructions may be given through the authorised contact; the parties must resolve any scope/cost consequences without withholding legally required assistance.
Seleya must process only on documented instructions, including for transfers, unless Applicable Law requires otherwise; it must notify the Customer of such a legal requirement before processing unless law prohibits notification. If Seleya considers an instruction unlawful, it must inform the Customer promptly and pause the affected instruction while it is resolved.
3. Customer duties
The Customer determines its lawful grounds, notices, data accuracy, retention instructions and authority for connected sources. Where it acts as a processor, it must remain within its controller’s instructions. Customer duties do not exclude Seleya’s own duties or liability.
Special personal information, information about children and other regulated categories require a permitted processing schedule, lawful ground, necessary safeguards, vendor permission and any applicable prior authorisation. Do not submit these categories to an unapproved service path. A contractual warranty alone cannot remedy a provider prohibition or create a legal ground.
4. Confidentiality and authorised people
Seleya must ensure that all authorised personnel are bound by enforceable confidentiality and processing/security obligations, receive appropriate instructions and access content only for an authorised purpose. These duties cover founders, contractors and personnel working through an affiliate, including South African access.
It must maintain and review appropriate access, revoke access when authority ends and prevent unauthorised onward disclosure. It remains responsible for its performance and engaged subprocessors as required by law.
5. Security and assessment
Seleya must implement appropriate technical and organisational measures under Applicable Law and Annex C, considering the risk, nature and scale of processing. It must assist the Customer with required security assessment, DPIAs, prior consultation and POPIA assessments/authorisations, taking account of the processing and information available.
Material changes must not reduce agreed protection. A certification, hosting location or encryption claim is not accepted evidence for a layer or service outside its demonstrated scope.
6. Rights requests and regulatory assistance
Seleya must assist with access, correction, deletion, restriction, portability and objection through appropriate measures. It must refer direct requests about Customer-controlled content to the authorised Customer without undue delay, unless law requires another response, and must not disclose content to an unauthorised requester.
It must provide information and cooperation reasonably required for the Customer’s compliance, investigations and regulator requests. Ordinary assistance necessary to meet this DPA is included; exceptional customer-specific work may be reasonably priced by agreement, but fees or negotiation must not obstruct mandatory duties or incident response.
7. Subprocessors and changes
The service recipients are identified in Annex B. A customer-specific schedule must identify which recipients act as Seleya’s subprocessors for that service and the correct contracting entities. Independent controller and Customer-contracted services are identified separately.
Subject to required lawful safeguards, the Customer grants general authorisation for the identified subprocessors. Seleya must bind them to obligations that meet Applicable Law and are no less protective for the relevant processing, including confidentiality, security, rights assistance, prompt incident escalation, return/deletion and onward-transfer protection. Seleya remains responsible for their performance where law requires.
For a new or replacement subprocessor, Seleya must give the designated Customer contact at least 30 days’ advance notice, identifying purpose, locations and relevant protection. A website edit alone is not notice. The Customer may object on reasonable data-protection grounds during that period. The parties must seek a workable remedy, such as a supported alternative or disabling the affected feature. A model label alone is not a verified regional remedy.
If unresolved before activation, the affected processing must not proceed for that Customer; either party may terminate the affected service with a refund of unused prepaid fees. An urgent change necessary to address a documented threat or legal requirement may use the shortest practicable notice, prompt explanation and appropriate alternatives. This exception does not waive lawful processing or transfer requirements. More protective accepted customer-specific notice rights continue to apply.
8. No training
Seleya must not use Customer Content to train, fine-tune or develop any AI model, and must not permit its subprocessors to do so. This obligation is core and non-derogable. It must ensure that applicable provider services, agreements and settings support it. Customer-specific retrieval, indexing and memory do not authorise model training.
If Seleya breaches this obligation, the Customer may terminate immediately and receive a refund of all fees paid in the 12 months preceding the breach, without prejudice to other remedies and without double recovery for the same loss. The duty survives for retained content.
9. Personal-information incidents
Seleya must notify the Customer without undue delay after becoming aware of a personal-data breach affecting Customer Content. Where it is a POPIA operator and section 21(2) applies, it must notify the responsible party immediately when it has reasonable grounds to believe information has been accessed or acquired by an unauthorised person. No investigation-completion requirement delays initial notice.
Provide known facts promptly and further information in stages: the nature and affected categories, approximate scale if known, likely consequences, containment/mitigation and a contact. Preserve relevant evidence, cooperate and support the Customer’s legal notifications.
The Customer’s controller/responsible-party duties remain separate: GDPR Article 33 generally imposes a 72-hour authority deadline where notification is required; POPIA section 22 requires applicable authority/data-subject notice as soon as reasonably possible, subject to its statutory qualifications. These are not a uniform 72-hour permission for Seleya to wait. Seleya must impose compatible escalation on engaged operators.
10. Return, deletion and retained copies
At the Customer’s choice when processing services end, Seleya must return the personal information and delete existing copies, or delete it, unless Applicable Law requires storage. It must carry out valid deletion instructions without undue delay and provide completion information on request. It may not routinely retain all former content for 12 months.
Return must use a usable agreed electronic format and include information and relevant attachments/derived records within the processing scope. Practical limitations must be identified and addressed through assistance; they do not remove the obligation. The agreed schedule must identify actual timeframes, provider-managed copies, backup expiry and any lawful exceptions.
Deletion must address active content, indexes, embeddings, memories, stored machine/browser state and engaged subprocessors where applicable. Backups must be isolated from ordinary processing, expire under a documented schedule, and not restore deleted content to use. A legal retention exception requires an identified ground, limited scope, restricted use and eventual deletion.
During any return/deletion period, this DPA continues to apply. Seleya must not re-ingest deleted connected content contrary to instructions.
11. Compliance information and audits
Seleya must make available information needed to demonstrate this DPA’s compliance and allow and contribute to audits, including inspections, by the Customer or its mandated auditor as required by Applicable Law.
Use proportionate evidence review first where adequate, protecting other customers’ information. Ordinary audit planning may use reasonable notice, confidentiality, timing and scope. Those arrangements must not restrict regulator powers or necessary audits following an incident, a reasonable compliance concern or inadequate evidence. There is no absolute once-per-year or 30-day restriction on a mandatory audit right.
Vendor reports can support the relevant service scope; they do not certify Seleya or automatically replace a legally required audit. Audit cost allocation must be reasonable and cannot obstruct mandatory rights. Seleya must promptly disclose if an instruction relating to this section infringes Applicable Law.
12. Records and cooperation
Each party must keep the records required for its role. Seleya must maintain sufficient service, recipient, instruction, access, retention and incident information for its obligations and assist the Customer with relevant regulator cooperation. It must notify the Customer if it cannot meet a material obligation and agree lawful remediation or cessation of the affected processing.
13. International transfers
Seleya must not make a restricted transfer without an applicable lawful route. This public DPA is not a completed EU SCC, UK Addendum or vendor transfer instrument. A reference to one does not prove acceptance or coverage.
For an EEA transfer, establish the parties/roles, exporter and importer territorial scope, recipients, purposes, onward access, applicable mechanism and required assessment. The EU 2021 SCCs are used only where legally applicable, in their unaltered mandatory form with the correct module, elections, parties, annexes and valid acceptance. If they do not fit the importer’s processing, another lawful mechanism is required; do not deem them executed by choosing a model.
UK and Swiss transfers require the applicable extension, adaptation or other lawful mechanism and completed details. A Data Privacy Framework route requires a current official certification covering the exact entity, data and service; Seleya does not claim such certification here.
For POPIA transfers relying on a binding agreement, section 72(1)(a) requires adequate protection with substantially similar processing conditions and onward-transfer protection. Seleya must apply those protections to covered natural and juristic-person information and require compatible downstream safeguards. Consent or another exception can be used only if its statutory conditions are genuinely met.
Customer instructions, use of the Service and a paid plan do not by themselves create a transfer derogation or remedy a missing safeguard. Where a required route cannot be established, the affected processing must be suspended or replaced with a lawful alternative. Contact support@spock.chat for the safeguard information applicable to your scope.
14. Liability and precedence
The accepted service agreement’s liability provisions apply, subject to nonwaivable Applicable Law and rights/liabilities under mandatory transfer clauses. Nothing restricts a data subject’s statutory remedy, a regulator’s powers or mandatory SCC liabilities.
This DPA prevails for personal-information processing; applicable mandatory transfer provisions prevail for their subject. Its governing law follows the accepted agreement except where Applicable Law or the transfer instrument requires otherwise. A change to a public URL does not amend a preserved accepted pack.
Annex A Processing schedule
| Item | Standard service scope |
|---|---|
| Subject matter and purpose | Supply of the instructed Spock workspace, AI/agent and connected services. |
| Duration | The service term and the necessary return/deletion period; identified lawful retention exceptions only. |
| Operations | Collection/import, storage, extraction/OCR/transcription, indexing/embeddings, retrieval, inference, output creation, memory/background tasks, hosted machine/browser work, instructed integrations/channels, relevant support/security, return and deletion. |
| Data subjects | Customer personnel, contractors, clients, suppliers, contacts and individuals referred to in supplied/retrieved material. |
| Information | Identifiers, contact/role details, communication and document content, images/audio, context/memory, connection/session state, relevant activity metadata and instructed outputs. |
| Restricted categories | Special personal information, children’s information, regulated/confidential categories requiring an expressly permitted workflow and safeguards. |
| Frequency | On-demand processing; persistent storage and scheduled/background work where enabled. |
| Authority and geography | Customer-authorised instructions; international recipients and SA administration as qualified in Annex B. No default EU-only inference promise. |
| Customer-specific additions | Customer role/upstream authority; scope and sources; allowed/restricted data; tools/models/destinations; retention/export/backup schedule; contacts; applicable transfer instrument and evidence. |
Annex B Recipients and locations
This is the service recipient inventory, not a representation that every recipient is active for every customer or that every required account agreement has been verified. Entity names must be matched to the actual account/service before completing a customer-specific transfer schedule. “Global” includes potential storage, compute, support or onward access outside the EEA and South Africa.
| Provider or recipient | Purpose and role qualification | Location and scope qualification |
|---|---|---|
| Hetzner Online GmbH | Main application infrastructure; subprocessor for relevant hosted content. | Actual server/backup facilities must be confirmed; a provider’s European base is not every resource’s location. |
| DigitalOcean | Database hosting; content subprocessor. | Frankfurt database endpoint observed; contracting entity, replica/backup and support scope require account verification. |
| Amazon Web Services (S3) | Object storage; content subprocessor. | Configured bucket reports Frankfurt, eu-central-1; all production copies and AWS contracting entity require account verification. |
| Cloudflare | R2 storage; website/CDN/security; transactional email. Role depends on service and data. | R2 Western Europe placement observed, default jurisdiction; separate from a binding EU-jurisdiction restriction. Delivery, security and email can involve global processing. |
| Google Cloud | Compute for Seleya’s own models/embeddings; infrastructure subprocessor. | Current GPU deployment and account/service locations require confirmation; not described as EU-only. |
| OpenAI | Model/API tasks; subprocessor for request content where engaged by Seleya. | Entity, endpoints, persistent state and selected region depend on account/service; international processing. |
| Google Gemini | Model/API tasks, including supported multimodal/utility work. | Distinguish paid Gemini Developer API from Vertex AI and Google Cloud; account, region, training and retention conditions require verification. |
| Anthropic | Direct model/API tasks where enabled. | Actual entity/account and direct versus managed route matter; international processing. |
| Fireworks | Hosted model/API tasks. | Model/service-specific account, deployment, onward recipients and retention; international processing. |
| xAI | Optional model route in the provider registry; not established as recently used for all customers. | Account/entity and any Seleya relay must be separately mapped before use; no transit-only relay claim. |
| Daytona | Hosted machines/code/browser execution and persistent working state where enabled. | Region, US legal recipient, data-category permission and subprocessor-role coverage require account/service confirmation. |
| Serper | Web search, including queries an agent prepares. | Queries can contain personal information; legal entity, destinations, retention and applicable agreement require verification. |
| ZenRows | Web retrieval where enabled. | Spain-based provider does not prove EU-only processing; paid-service agreement and downstream processing scope matter. |
| Slack / Salesforce | Internal support/reporting/operational alert delivery. | Can receive submitted text, identifiers and error context; persistent workspace and international processing. |
| Stripe | Payments, billing and fraud functions; independent controller and processor roles depend on purpose. | Account-country entity and payment/DPA scope; international processing. Payment credentials are handled by Stripe. |
| Google Firebase Cloud Messaging | Enabled push notifications, tokens and delivery. | Service-specific/global processing; distinct from Gemini and GPU hosting. |
| Meta / WhatsApp, Telegram, Microsoft Teams | Enabled communication channels. | Provider and customer-account roles differ; channel messages/identifiers can traverse provider infrastructure internationally. Not all are Seleya subprocessors. |
| Customer-connected apps, Google/Microsoft accounts and MCP services | Instructed retrieval/actions under the relevant account. | Customer-provider relationship must be distinguished from Seleya-procured processing; destinations and provider notices apply. |
| TTL Technologies (Pty) Ltd and authorised personnel | Enterprise billing separately; authorised service/personnel access where supplied. | South Africa. All current personnel can access production/content; authority and written obligations must cover the actual arrangement. |
The accepted customer schedule identifies authorised subprocessors and their applicable safeguards. Notice of new/replacement subprocessors follows section 7; adding detail here does not constitute customer notice or retroactive acceptance. The Trust Center carries the inventory update history.
Annex C Security obligations
Seleya must maintain measures appropriate to the processing risk, including:
- encrypted transport using appropriately configured TLS; suitable protection of stored content, credentials, keys and backups;
- authenticated, authorised access; appropriate privileged-account MFA, access review, prompt revocation and confidentiality/instruction duties;
- separation of customer and environment access, permission checks for retrieved and shared content, and controlled secrets;
- secure development and vulnerability/dependency handling; logging and monitoring proportionate to the purpose and minimised where content is involved;
- machine/browser isolation and lifecycle controls, including persistent files and sessions; safeguards for connected accounts and consequential agent actions;
- documented incident handling, immediate POPIA operator escalation where required and timely staged customer assistance;
- documented retention, return/deletion and backup-restoration procedures addressing derived data and recipients;
- supplier/account/transfer review and evidence for the actual enabled processing.
These are required safeguards, not an attestation that each has been independently verified. Service-specific measures and material limitations must be recorded in the customer schedule and compliance information. There is no Spock SOC 2 claim or blanket TLS 1.3-only, EU-only or universal vendor-retention guarantee.