The processor terms — and where they stop applying.
A DPA governs what a processor may do with personal data it holds. On the hosted API we hold it and these terms matter. In a VPC or air-gapped deployment we never receive it, so most of what follows has nothing to attach to.
Who is the controller, and of what.
| Deployment | Customer content | Account, billing and licensing data |
|---|---|---|
| Hosted API | Tileward is the processor. You are the controller, or a processor for your own customer. | Tileward is the controller. |
| Your VPC | No Tileward processing. The content, the context store and the audit records stay in your account. On committed-use billing, an aggregate usage count only — see below. | Tileward is the controller. |
| On-prem, air-gapped | No Tileward processing, and no network path by which there could be. | Tileward is the controller. |
Committed-use Enterprise billing reports an aggregate count, not a log: seats active, tokens sent, tokens received from the model, and the number of tiles actively used since the last report, rolled up for the billing period. It carries no prompt, completion or document content, no tile names or configuration, and no per-user or per-request detail — which is why it falls outside the personal-data processing this addendum governs. See the privacy policy for the same description.
{
"period_start": "2026-07-01",
"period_end": "2026-07-31",
"seats_active": 14,
"tokens_sent": 4820193,
"tokens_received": 1902744,
"tiles_active": 6
}
The report carries no account identifier beyond whatever the billing connection already carries.
What is processed, and why.
The description a processor addendum has to contain, for the hosted service.
| Item | Detail |
|---|---|
| Subject matter | Providing governed inference: running a model, storing and retrieving conversation context, classifying requests against a topic policy, and recording the decision. |
| Duration | For the term of the customer's subscription, plus the retention windows in the privacy policy. |
| Nature and purpose | Storage, retrieval, classification and generation, on the customer's instructions, for the customer's own purposes. |
| Categories of data subject | The customer's staff who hold seats and keys; and any individual whose personal data the customer chooses to put into a prompt, a stored document or a conversation. |
| Categories of personal data | Account identifiers for seat holders. Beyond that, whatever the customer sends — Tileward does not control it and cannot enumerate it in advance. |
| Special category data | Not something Tileward designs for or screens for. If a customer puts health, biometric, religious, political or similarly sensitive content into a prompt, a stored document or a conversation, Tileward processes it the same as any other content — same limitation as the row above, and no Art. 9-specific safeguard beyond what already applies to personal data generally. |
What a processor has to commit to.
Acting only on instructions
Tileward processes customer content only to provide the service and only as the customer instructs, unless the law requires otherwise. Using the service is the instruction; a documented change to it is a change to the instruction.
Confidentiality of personnel
Anyone at Tileward with access is bound to confidentiality.
Security measures
The technical and organisational measures are described on the security page, which stands as Annex II. SOC 2 Type II and ISO 27001 are in progress; the certifications section says where each stands.
Sub-processors
Listed on the sub-processor page, which stands as Annex III.
No training, ever
Tileward does not use customer content (prompts, stored context, documents or audit records) to train, fine-tune or evaluate any model, in aggregate or de-identified form or otherwise. Tileward compresses and governs models trained elsewhere, and does not build or improve models on customer data. The privacy policy makes the same commitment.
Two clauses that got a decision instead of a template.
Data subject requests versus the audit trail
Tileward assists the customer in responding to access, correction, deletion and portability requests. The complication is Governance: an audit record exists to prove what was refused and when, and deleting one on request destroys the artifact the customer bought it for. So closing an account is immediate and irreversible for content, as set out under Return and deletion below, while audit records are not part of that deletion: they run out the same per-plan retention window as any live account.
Breach notification
If Tileward becomes aware of a breach affecting customer content, we notify the customer without undue delay, by email to the account or security contact on file, with what is known at the time — the nature of the incident, the customer data affected so far as we can tell, and what is being done about it — and we update that notice as the picture gets clearer. The commitment is to tell you as soon as we reasonably can, not to hold the news until every fact is confirmed.
The rest of it.
Return and deletion. Before terminating, the customer can export audit records as CSV or JSON, or through webhook or SIEM export where the plan includes it. On termination the account is marked deleted, locked out and its keys revoked at once, and in that same transaction every tile created privately for the customer, any message text captured by the guard, and everything Tileward Context holds for the account is erased in full — and the Context account itself is closed, so credentials issued against it stop working rather than merely finding an empty store. Immediately, with no grace period. Audit records are unaffected by termination itself: they continue to age out under the per-plan retention window in the privacy policy, open account or closed.
Precedence. Where this addendum and the terms of service conflict on the processing of personal data, this addendum governs.
Signature. When counsel has a version they are happy with, it becomes a document that gets signed alongside an order form, not a web page.