Data Processing Agreement

Last updated: August 5, 2026

Version: 1.0
Effective date: August 5, 2026

This Data Processing Agreement (the "DPA") is entered into between skilder.ai SA, Unlimitrust Campus, Route des Flumeaux 52, 1008 Prilly, Switzerland ("skilder") and any counterparty whose contract with skilder incorporates it by reference (the "Customer"). On the Customer's request, skilder countersigns a dated copy of this DPA.

1. Subject matter, scope, and relationship to other documents

a) This DPA governs the processing of Personal Data carried out by skilder as Processor (or sub-processor) on behalf of the Customer under the contract that incorporates it by reference — a subscription contract governed by the Terms of Service (the "Terms") or a partnership agreement (the "Principal Contract") — in accordance with Art. 28(3) GDPR and Art. 9 of the Swiss nFADP.

b) "Personal Data", "Controller", "Processor", and "Personal Data Breach" have the meanings given in Regulation (EU) 2016/679 ("GDPR") and in the Swiss Federal Act on Data Protection of 25 September 2020 ("nFADP"). Capitalised terms not defined here have the meaning given in the Principal Contract or the Terms. "Customer Artefacts" (Skills, Roles, MCP Tools, and related artefacts, as defined in §2 of the Terms) are referred to as "Capabilities" in partnership agreements; the two terms are equivalent for the purposes of this DPA.

c) Where the Principal Contract is a partnership agreement, "Customer" means the Partner, and the Direct, Delegated Workspace, and Embedded Scenarios have the meaning given in that agreement. For a Customer bound by an ordinary subscription contract, only the provisions matching its situation apply.

d) The Terms contain a clause serving as data processing agreement "until and unless the parties enter into a separate data processing addendum" (§10.1 of the Terms); this DPA constitutes that separate addendum. It restates and refines the commitments of that clause without creating a divergent regime; in case of contradiction on data-protection matters, this DPA prevails.

e) Transparency about the state of the platform. The Services are an evolving product under active development (§22 of the Terms). Annex A describes the measures actually implemented and expressly lists the measures and features that are not (yet) provided. The Customer acknowledges having read Annex A and contracts in full knowledge of its contents; matters declared "not covered" in Annex A are matters not expressly addressed by the Services within the meaning of §22 of the Terms, which the Customer is responsible for assessing and addressing through its own controls where it deems necessary.

2. Roles

a) Direct Scenario / ordinary subscription. The Customer (or the End Customer that subscribed directly) is the Controller; skilder is its Processor. A service provider that creates and manages Customer Artefacts for an end customer acts, depending on the nature of its services, either as that end customer's Processor or as a separate Controller; that qualification belongs to their own relationship and is documented between them.

b) Delegated Workspace and Embedded Scenarios. The Customer (Partner) is the Controller, or the Processor of its End Customer where the End Customer is itself the Controller. skilder acts as the Customer's Processor and, in the chain, as the End Customer's sub-processor within the meaning of Art. 28(2) and (4) GDPR. The Customer warrants that it holds the relevant End Customer's authorisation to engage skilder as sub-processor and that its contract with the End Customer imposes obligations compatible with this DPA.

c) End users unknown to skilder (Embedded Scenario). Where end users are not known to skilder, skilder has no means of identifying them or responding to their requests directly. The Customer is the sole point of contact for data subjects; it transmits the necessary instructions to skilder (in particular for the exercise of data-subject rights) and skilder acts on them under the conditions of Article 7.

3. Description of the processing

Element	Description
Subject matter	Provision of the Services (creation, configuration, and execution of Customer Artefacts; connection to the Customer's systems; processing of content and Trace Data)
Duration	Term of the Principal Contract, plus the Transition Period (Article 13) and the retention periods of Article 11
Nature	Hosting, storage, structuring, transmission, execution of AI inference, logging
Purposes	Performance of the Principal Contract and the Terms; support; security
Categories of data	User identification and contact data (name, e-mail, role), connection and usage data, Workspace content and data from connected systems (the substance of which is determined by the Controller), Trace Data (AI prompts and outputs, execution traces: agent sessions, tool calls with inputs, outputs, errors and timestamps, conversations)
Data subjects	Users of the Customer and of its end customers; individuals whose data appears in content and connected systems
Special categories	Not envisaged by default; if the Customer or its end customers process them through the Services, the Customer ensures the legal basis and any additional required measures

4. Instructions

skilder processes Personal Data exclusively on the Customer's documented instructions (the Principal Contract, the Terms, the configuration of the Services by the Customer and its authorised users, and any subsequent written instruction), except where required by Swiss or EU law, in which case skilder informs the Customer before processing, to the extent permitted. skilder informs the Customer if, in its opinion, an instruction infringes the GDPR or the nFADP.

5. Confidentiality and personnel

skilder ensures that persons authorised to process Personal Data are bound by confidentiality (contractual or statutory) and receive appropriate training. Access to production environments is limited to authorised personnel, with multi-factor authentication (MFA) on infrastructure and administration accounts.

6. Security

a) skilder implements appropriate technical and organisational measures (Art. 32 GDPR; Art. 8 nFADP) as described in Annex A, comprising at minimum: encryption in transit (TLS 1.2+, terminated at the infrastructure boundary); encryption at rest of secrets and credentials (AES-256-GCM) using deployment-scoped, purpose-dedicated keys with a documented key-rotation and re-encryption procedure; an authenticated, TLS-encrypted internal message bus with per-service identities and per-subject permissions; logical tenant segregation per Workspace, enforced at a single authorisation choke point (least-privilege RBAC); structured technical logging; daily backups of the production database and files, rotated on the schedule in force (Article 11); documented incident-management procedures.

b) Connector credentials (MCP configuration secrets, OAuth tokens) and AI-provider API keys are encrypted at rest and are never returned in cleartext by the platform's APIs; OAuth tokens are per-user activations. The Workspace vault ("Vault") is, by design, a secret store whose values are retrievable by authorised Workspace members; it is outside the scope of the preceding sentence (Annex A, Section 3).

c) skilder evolves its measures with the state of the art; an evolution may not reduce the overall level of security during the term of the Principal Contract.

7. Assistance to the Controller

Taking into account the nature of the processing, skilder assists the Customer through appropriate technical and organisational measures: (a) in responding to data-subject requests (access, rectification, erasure, restriction, portability, objection) — in the Delegated Workspace and Embedded Scenarios, requests are received and handled by the Customer, with skilder executing the corresponding instructions; (b) in complying with Arts. 32 to 36 GDPR (security, breach notification, data protection impact assessments, prior consultation), taking into account the information available to skilder.

How this works in practice: deletion of a user account and the associated personal data is available self-service and executes as an immediate, cascading hard delete. Access, rectification, and portability requests are handled manually by skilder on the Customer's written instruction, within a maximum of thirty (30) days per request; the platform does not currently provide a self-service export tool for an individual data subject's personal data (Annex A, Section 3).

8. Notification of Personal Data Breaches

skilder notifies the Customer of any Personal Data Breach affecting Personal Data processed on its behalf without undue delay and in any event within forty-eight (48) hours of becoming aware of it, with the information reasonably available (nature, approximate categories and volumes, likely consequences, measures taken or proposed), supplemented as it becomes available. Notification to authorities and to data subjects is the responsibility of the competent Controller in the chain; skilder provides reasonable cooperation.

9. Sub-processors

a) General authorisation. The Customer generally authorises skilder to engage the sub-processors listed at /legal/subprocessors, comprising as of this version:

Sub-processor	Service	Country	Transfer safeguard
Infomaniak Network SA	Primary hosting and managed AI inference (Infomaniak AI Tools)	Switzerland	None required
PostHog Inc. (EU Cloud)	Product analytics, error tracking, and session replay	Germany (EU)	None required (intra-EEA)
Brevo (Sendinblue SAS)	Transactional and engagement e-mail	France (EU)	None required (intra-EEA)
Linear Orbit, Inc.	Internal issue tracking; support exchanges may be recorded there	United States	SCCs 2021/914 + Swiss Transfer Annex
Attio Ltd.	CRM (user contact data) — effective upon go-live of the CRM synchronisation	United States / United Kingdom	SCCs 2021/914 + Swiss Transfer Annex
Mollie B.V.	Billing and payments — effective upon launch of self-serve billing	Netherlands (EU)	None required (intra-EEA)

The graph database and the message bus are self-managed by skilder in Switzerland and are not sub-processors.

b) Changes. skilder gives thirty (30) days' prior notice of any addition or replacement of a sub-processor (subscription mechanism described at /legal/subprocessors). The Customer may object in writing, on reasonable data-protection grounds, before the notice period expires; in case of objection, the parties seek a solution in good faith and, failing that, the Customer may terminate the affected part of the Principal Contract without penalty.

c) Obligations. skilder imposes on its sub-processors, by contract, data-protection obligations substantially equivalent to those of this DPA, and remains fully liable to the Customer for their performance.

d) BYOK. Where the Customer (or its end customer) connects its own AI-model provider API keys (Bring Your Own Key), the provider concerned is the Customer's processor (or service provider), not skilder's: the Customer concludes and manages its contractual relationship (including DPA and transfer safeguards) with that provider directly, bears its costs and compliance, and passes them through to its end customers in accordance with the pass-through clauses of the Principal Contract. skilder is not responsible for processing carried out by the BYOK provider.

e) Customer-configured OAuth integrations. Any third-party connector the Customer connects from its Workspace (e.g. Google Workspace, Microsoft 365, Zoho, or Attio as the Customer's own tool) is the Customer's processor, not skilder's.

10. Location, international transfers, and AI inference

a) Default location. Primary hosting of the Services is in Switzerland (Infomaniak Network SA); the database and the message bus are self-managed in Switzerland. Default AI inference runs on models hosted in Switzerland (Infomaniak AI Tools), with a contractual no-training commitment on customer content. No AI provider other than the Swiss default is connected to a Workspace without a configuration action by the Customer.

b) Choice of AI providers. The Customer controls, per Workspace, which AI providers are connected and which models are exposed. The platform does not currently provide a technically enforced region-pinning control (a system-enforced "Switzerland-only" or "EU-only" block): control over inference location results from the Customer's configuration choices (Annex A, Section 3). In the Delegated Workspace and Embedded Scenarios, the Customer is responsible for configuring providers in line with its commitments to its end customers.

c) Transfers. Any transfer of Personal Data to a country that does not ensure an adequate level of protection is governed by the European Commission's Standard Contractual Clauses (Decision 2021/914), supplemented by the Swiss Transfer Annex and, where applicable, the UK IDTA/Addendum, together with appropriate supplementary measures.

d) No training. No content of the Customer or its end customers is used to train AI models without separate written consent (unconditional commitment restated from §5.3(a) of the Terms).

11. Trace Data and retention periods

a) Trace Data. Trace Data (AI prompts and outputs, execution traces: agent sessions, tool calls with inputs, outputs, errors and timestamps, conversations) is collected by default to operate, debug, secure, and improve the Services (§5.3(b) of the Terms). Actual state, expressly declared: the platform does not currently apply an automatic purge to Trace Data; it is retained for the term of the Principal Contract and then deleted in accordance with Article 13. The Customer may at any time: (i) disable agent-session recording from Workspace settings; (ii) request in writing that Trace Data collection be disabled for one or more Workspaces, which skilder implements within ten (10) business days (certain debugging, evaluation, and support features then being unavailable or degraded); (iii) request in writing the early deletion of a Workspace's Trace Data. A per-Workspace configurable retention period (90-day default) with automatic purge is on skilder's roadmap; its entry into service will be notified as a Customer-favourable update to this DPA and will apply without a new signature.

b) Retention periods. Unless a legal obligation requires otherwise:

Category	Period
Account data (closed account)	Deleted immediately on closure via a cascading hard delete, and in any event within 90 days
OAuth tokens and BYOK keys	Deleted immediately on disconnection or revocation, and in any event within 30 days; upstream revocation (RFC 7009) attempted where the provider supports it
Trace Data	Term of the Principal Contract (see 11(a)); earlier deletion on request
Technical and security logs	Structured application logs retained under skilder's operational policy; 12-month target, not contractually guaranteed at this time (Annex A, Section 3)
Commercial and accounting records	10 years (Art. 958f Swiss CO)
Backups	Daily backups; off-site copies retained for 30 days, then overwritten

c) At the end of the Principal Contract, Article 13 (exit) applies, subject to the periods above.

12. Audits

The Customer (or an independent auditor mandated by it, not a competitor of skilder and bound by confidentiality) may audit compliance with this DPA at most once per twelve (12)-month period, on thirty (30) days' written notice, during business hours, without disrupting operations, and at its own cost. skilder may satisfy this obligation by providing up-to-date audit reports or certifications (SOC 2 Type II, ISO 27001, or equivalents), accepted as equivalent; skilder declares that it holds no such certification as of this version (Annex A, Section 3); for as long as that is the case, audits are conducted on documentation (description of measures, configuration extracts, written responses) and, where there are serious grounds (a significant Personal Data Breach, a request from a supervisory authority), on site.

13. Exit: export, deletion, and return

a) Transition Period. From the end of the Principal Contract, the Customer benefits from a single thirty (30)-day transition period during which its Workspaces remain accessible for export and migration purposes (the "Transition Period"), consistent with §13.4 of the Terms. The platform does not currently apply a technical read-only lock during this period; the Customer is responsible for freezing its own write activity (Annex A, Section 3). At the end of the Transition Period, Customer Content and Customer Artefacts are permanently deleted.

b) Export of Customer Artefacts. During the Transition Period, the Customer may export each Skill as a ZIP archive conforming to the open Agent Skill standard (a SKILL.md markdown file with YAML metadata plus resource files), with round-trip fidelity, accompanied where applicable by the standard mcp.json file (list of suggested MCP Servers, multi-editor format, secrets replaced by variable placeholders) and by skilder's own extensions file.

c) Access to logs. During the Transition Period, the Customer retains access to execution logs (agent sessions, tool calls with inputs, outputs, errors and timestamps, conversations) through the platform's GraphQL API, in standard structured formats (JSON). No dedicated bulk-export function exists; skilder provides reasonable extraction assistance on request (documentation, example queries), and any service exceeding reasonable assistance may be charged at skilder's then-current rates.

d) Non-exportable secrets. Connector credentials (configuration secrets, OAuth tokens) and AI-provider API keys are encrypted at rest (AES-256-GCM) with deployment-scoped keys and are never returned in cleartext by the platform's APIs; OAuth connections are per-user activations. For these security reasons — and not as a commercial restriction — connector configuration (credentials, secrets, OAuth activations) is not exportable; it must be re-established by its holder in any target environment using its own credentials and authorisations. Secrets the Customer has placed in the Workspace Vault remain retrievable by authorised Workspace members until the end of the Transition Period. Where Workspaces are handed over to end customers under a handover provided for in the Principal Contract, the Customer informs the end customers concerned and cooperates reasonably in the transition.

e) Deletion and return. At the end of the Transition Period, skilder, at the Customer's choice expressed no later than that date, permanently deletes or returns (in the formats and within the limits above) the Personal Data and Workspace data processed on its behalf, and deletes existing copies, subject to Workspaces transferred in accordance with the Principal Contract, the retention periods of Article 11 (including backup rotation), and legal obligations.

14. EU AI Act

skilder acts as provider of the platform within the limits set by the Terms; the "deployer" obligations under Regulation (EU) 2024/1689 for AI systems used through the Services fall to the Customer within the meaning of the Terms — in the Delegated Workspace and Embedded Scenarios, to the Customer (Partner), which is responsible for passing them through to its end customers in accordance with the pass-through clauses of the Principal Contract (in particular: human oversight, use in accordance with intended purpose, information of exposed persons, input-data governance).

15. Liability and changes

a) Liability under this DPA is subject to the liability regime of the Principal Contract (including any specific cap it provides), subject to the mandatory provisions of the GDPR (in particular Art. 82) and the nFADP.

b) skilder may update this DPA; changes are notified to the Customer with thirty (30) days' prior notice and the objection regime of the Principal Contract applies. Updates to Annex A that add a measure or lift a declared limitation (a change favourable to the Customer) take effect on publication, without prior notice. The applicable version is the one in force at the date of the Principal Contract, subject to updates notified as above.

Annex A — Technical and organisational measures; expressly declared limitations

This Annex forms an integral part of the DPA. It distinguishes what is implemented, what is expressly not covered as of this version, and what is on the roadmap with no committed timeline. The items in Section 3 are binding disclosures within the meaning of Article 1(e): the Customer contracts in full knowledge of these limitations.

1. Implemented measures

Encryption in transit: TLS 1.2+ on all public interfaces (terminated at the infrastructure boundary); TLS on the internal message bus.
Message-bus authentication: connections to the NATS bus are authenticated, with per-service identities and per-subject permissions; anonymous connections are refused.
Encryption at rest of secrets: AES-256-GCM (authenticated encryption, random IV) for AI-provider API keys, OAuth secrets and tokens, MCP server configuration secrets, and Vault secrets, using deployment-scoped, purpose-dedicated keys (data / passwords / sessions), with a documented, idempotent key-rotation and re-encryption procedure.
No credential read-back: the platform's APIs never expose in cleartext the AI-provider API keys, OAuth client secrets, access/refresh tokens, or MCP configuration secrets (the fields are absent from output schemas).
Per-user OAuth tokens: each OAuth connection is bound to an individual user; self-service revocation with a call to the provider's revocation endpoint (RFC 7009) where one exists.
Logical tenant segregation: Workspace-membership checks enforced at a single authorisation choke point (admin/member/owner RBAC, least-privilege CASL abilities) across all resolvers.
Cascading deletion: self-service account deletion with immediate hard deletion of dependent personal data (sessions, OAuth connections, secrets, conversations); Workspace deletion with cascading purge by scheduled garbage collection.
API keys: versioned key format with a public display prefix and checksum; configurable expiry; scopes narrowing a key's authority; usage telemetry (last used); per-key rate limiting.
Delegation without credential replay: the backend acts towards the runtime using short-lived, signed, never-persisted delegation assertions, replacing re-use of user keys.
Backups: daily backups of the production database and files, with off-site copies retained for 30 days; pre-production environments are fed from filtered exports that exclude customer Workspaces and null out encrypted secrets.
Logging: structured application logs (machine-readable events) covering significant security events (account deletion, access revocations, administrative operations).
Organisation: MFA on production infrastructure and administration accounts; personnel confidentiality obligations; least-privilege provisioning; separated development, staging, and production environments.

2. Roadmap (no committed timeline; entry into service will be notified per Article 15(b))

Per-Workspace configurable Trace Data retention (90-day default) with automatic purge.
Personal-data redaction filter for tool-call inputs/outputs, activatable per Workspace.
A dedicated, queryable audit log for key-authenticated API traffic, with a defined retention period.
Enforceable region pinning of inference providers ("Switzerland-only" / "EU-only").
Differentiated subscription plans (including an Enterprise plan with an opt-in Trace Data regime and custom retention).
A technical read-only lock on Workspaces during the Transition Period.

3. Expressly declared limitations (not covered as of this version)

The Customer acknowledges that the following are not provided as of this version and that their absence is factored into its risk assessment (Article 1(e) of this DPA; §22 of the Terms):

No automatic Trace Data purge: no retention period is automatically applied to execution traces; control over duration is exercised through the written requests provided for in Article 11(a).
No plan-differentiated regime: there is no Enterprise plan with Trace Data collection disabled by default; the default regime (collection on, deactivation on request) applies to all Customers.
No per-Workspace encryption keys and no external KMS: encryption at rest relies on deployment-scoped, purpose-dedicated keys; there is no per-Workspace key envelope and no external key-management service.
Workspace Vault is retrievable by design: secrets the Customer places in the Vault are readable in cleartext by authorised Workspace members; the Customer must not place secrets there that it does not intend to make accessible to its own members.
No enforceable region pinning of inference: inference location results from the Customer's provider configuration (the default being exclusively Swiss); no technical block prevents a Customer Workspace admin from configuring a provider outside Switzerland/the EU.
No dedicated audit log with guaranteed retention: traceability relies on structured application logs and the in-product tool-call history; "12-month / 24-month" durations are not contractually guaranteed.
No native multi-factor authentication for Users: platform sign-in is by verified e-mail or OAuth identity providers (the Customer may impose its own MFA upstream through its identity provider); the platform offers no native second factor.
No read-only lock during the Transition Period: export access is normal access; freezing writes is the Customer's responsibility.
No bulk log export and no per-data-subject self-service portability tool: extraction is via the GraphQL API (Article 13(c)) and, for data-subject requests, by manual handling (Article 7).
No SOC 2 / ISO 27001 certification as of this version; audits proceed per Article 12.
No personal-data redaction in traces: tool-call inputs/outputs are recorded verbatim; it is the Customer's responsibility to govern the data its Customer Artefacts pass through the platform.