Skip to content

Data Processing Agreement

Version 2026.06.4 · Between AttachKit (Processor) and Customer (Controller). Use this as the DPA between your organization and ours. Print to PDF and sign on both sides; we'll countersign on request via our contact form.

1. Background

Customer uses AttachKit(the "Service") and in doing so may have us process Personal Data on Customer's behalf. This DPA forms part of the agreement between Customer and AttachKitand sets out the terms governing Processor's processing of Personal Data as a processor under the GDPR / UK GDPR.

2. What we process (subject matter + duration)

3. Processor obligations

4. Sub-processors

Customer authorizes Processor to engage the following sub-processors:

"Local AI mode" — two different settings, with opposite egress. Two per-device settings ship under that one name. They are not variants of one feature, and the name does not tell Customer which is which: they differ in where the request goes, which is the only reliable way to read them.

The setting in the sign + draft tools (Counsel Mode). On the flows that offer it, the end user's browser posts straight to an Ollama instance the end user runs; Processor's servers are never contacted and receive nothing. No Personal Data leaves the device on those flows, and no AI sub-processor is invoked. Intentionally out of the sub-processor list — that model runs on the end user's own machine (Customer infrastructure) and Processor engages no one to run it. As with the cloud-import entry above, this is the end user's own infrastructure rather than a sub-processor of Processor's; it is not processing Processor performs at all.

The setting in account settings (sent to us as an X-Use-Local-Ai request header). This one does not keep Personal Data on the device. The request comes to Processor exactly as it otherwise would; what the setting changes is which model answers it, not whether a request happens. Where the deployment has a self-hosted model configured (OLLAMA_BASE_URL), Processor hands the text to that model instead of the third-party AI provider — but that model is Processor's own, not Customer's. Despite the shared name, nothing about this setting causes inference to run on Customer infrastructure. Where the deployment has no such model configured, the features that check the setting decline rather than quietly falling back to the cloud. Also out of the sub-processor list, but for a different reason — not because it is Customer-controlled infra, which it is not: a model Processor self-hosts introduces no third party, so that inference is processing Processor performs itself, already covered by this DPA. Were the setting ever pointed at a model a third party operates, that third party would be a new sub-processor and the notice commitment below would apply.

Neither setting covers every AI feature, and we deliberately do not print which features each one covers: that list has been written down wrong twice, which would make a per-feature claim here the least trustworthy sentence on this page. Only the narrowing direction is safe to state — with the account setting on, the PDF agent and whole-document translate refuse to run rather than fall back to the cloud (their text never leaves the page), while any feature that does not check that setting reaches the AI sub-processor exactly as described above. For the build Customer is actually running, DevTools → Network is authoritative.

Processor will notify Customer at least 30 days in advance of any new sub-processor, giving Customer the right to object.

5. International transfers

Where Personal Data is transferred outside the EEA/UK, transfers are governed by the EU Standard Contractual Clauses (Module 2 — controller to processor) or the UK International Data Transfer Addendum, as applicable. Processor will assist Customer in completing transfer impact assessments on request.

6. Deletion + return

On termination, Processor will delete or return all Personal Data within 30 days, unless retention is required by law. Customer can trigger immediate deletion via the in-app GDPR delete flow, which cascades across profile, signatures, subscriptions, sessions, and related tables.

Send-to-sign and QR-phone-handoff documents specifically. The stored ciphertext is deleted, not merely de-identified — for a document, the stored bytes ARE the Personal Data, so redacting the metadata around them would not be erasure. Three routes reach it: the sending user deletes the request themselves (available on a completed request, not only a pending one); the GDPR delete flow above removes every request that user sent; and failing both, every request expires 7 days after creation regardless of status and is deleted by a sweep that runs once a day, so it goes at expiry or within a day of it. Where the data subject was a recipient rather than the sender, Processor redacts their address out of the sending Customer's request and leaves that request standing — a recipient's Art. 17 request is not authority to destroy another controller's document.

7. Audits

On reasonable notice (minimum 30 days) and at Customer's expense, Processor will make available the information necessary to demonstrate compliance with this DPA and allow for audits by Customer or a third-party auditor mandated by Customer. Processor may satisfy this obligation by sharing relevant SOC 2 reports or equivalent third-party attestations from its sub-processors.

Annex 1 — Technical + Organizational Measures

Reproduced here in summary; the full per-control breakdown, cryptography stack, and verification steps live on our security page.

Need a signed countersignature or a redlined version? Terms · Privacy · Contact