Data Processing Information for Clients

This page explains, in plain terms, how personal data is handled when we design, build and maintain workflows for you. It is an overview of what our data-processing agreement covers, not the agreement itself.

1. Why a data-processing agreement is needed

Building and maintaining an automation usually means we can see personal data in your systems: enquiries, customer records, invoices, tickets. Where that happens, data-protection law (GDPR, UK GDPR and the Swiss FADP) requires a written agreement setting out who is responsible for what. We sign a data-processing agreement (DPA) with every client before we access production data. [Insert reference to the DPA template used, e.g. based on the EU standard contractual clauses under Art. 28(7) GDPR or the ICO’s processor contract guidance.]

2. Roles

You are the controller: you decide why and how personal data in your business is processed. [LEGAL ENTITY NAME] acts as your processor when we access, configure or operate workflows that handle that data on your instructions. The workflow platforms, model providers and hosting services used inside your accounts are engaged by you directly or, where we engage them on your behalf, are listed as subprocessors. We never become the controller of your customers’ data.

3. Client-owned accounts

Wherever practical, workflows are built inside accounts that you own and pay for: your automation platform, your model-provider account, your hosting. This keeps the contractual relationship with each vendor between you and them, keeps the data inside your tenancy, and means nothing stops working if our engagement ends. We are granted least-privilege access for the duration of the work and removed afterwards. We do not hold your credentials as the only copy.

4. Subprocessors

Every proposal includes a vendor and subprocessor inventory for the specific workflow: which platform runs it, which model provider processes text, where each is hosted, and what data reaches it. Where an EU-hosted or private model option is required, we say so in the proposal. Changes to the inventory during the engagement are notified to you in writing and require your approval. [Insert your standard list of subprocessors, their locations and the transfer mechanism for any outside the EU/EEA or UK.]

5. Security measures

The technical and organisational measures we apply on every engagement include:

• Least-privilege access and separate development and production credentials
• Secrets stored in an appropriate vault, never in workflow notes or source control
• Data minimisation: only the fields a step needs are passed to it, and only to the systems that need them
• Retention rules for logs and intermediate data, agreed with you
• Encryption in transit and at rest where the platform supports it
• Run logs, error alerts, model and cost monitoring and an audit trail of automated actions
• Confidence thresholds and human approval for sensitive outputs
• Fallback path when a vendor or model fails, and a documented kill switch
• Backup and export of workflows and configuration
• Regression tests after model updates
• Test data or anonymised samples during development wherever possible

6. Breach process

If we become aware of a personal-data breach affecting data we process for you, we notify your named contact without undue delay and in any case within [NOTIFICATION PERIOD, e.g. 24 hours] of becoming aware, with what is known at that point: what happened, which data and systems are affected, what we have done to contain it and what we recommend. We support you with the information you need to assess and, where required, notify your supervisory authority within the statutory 72 hours. Rollback and kill-switch procedures are documented in the runbook handed over at launch.

7. Instructions, assistance and audits

We process data only on your documented instructions, which are set out in the statement of work and the workflow design. We assist you with data-subject requests that involve the workflows we maintain, with data-protection impact assessments where the use case requires one, and we make available the information needed to demonstrate compliance with the processor obligations. Audit rights and their practical arrangements are set out in the DPA.

8. End of the engagement

At the end of an engagement our access is removed, any copies of your data held for development or support are deleted or returned as you instruct, and you receive full documentation and exports of every workflow. Because the workflows live in your accounts, they continue to run.

9. Where specialist review is required

We design privacy, access controls, human oversight and documentation into each workflow, then identify where specialist legal or security review is required. We do not describe any workflow as compliant with the GDPR or the EU AI Act as such; compliance depends on your role, the data and the use case. Workflows involving special categories of data, decisions about individuals, or use cases classified as high-risk under the EU AI Act are scoped through a separate assessment before any build.

Contact for data-processing questions: [CONTACT EMAIL]. See also the privacy policy and security and governance. Last updated: [DATE].