Data Processing Engagement

(א) The personal data we process for you, and the purposes

This engagement is about the personal data of YOUR customers: the people who talk to your assistant on your published site, inside the assistant embedded in your own site, or through that site's MCP endpoint. You own that database. We hold it for you.

We process these categories, and no others:

• Visitor accounts: email address, name, the Google account identifier where a visitor signs in with Google, their status on your site, and when they were last seen.
• Sign-in codes: the six-digit code emailed to a visitor, stored as a hash and valid for fifteen minutes.
• Conversations: every question a visitor asks your assistant and the answer it gave, the screens they were shown, the actions taken, and a random identifier that groups one visit into a conversation.
• Records a visitor creates: bookings, orders and requests, stored under the data model you defined and stamped with the visitor's identity where they were signed in.
• Remembered preferences: small facts a visitor asks the assistant to remember, capped at roughly two kilobytes per visitor.
• Personalization events: the questions and item clicks of a signed-in visitor, used to personalize what your assistant shows them.
• Conversation insights: an automated reading of a finished conversation, being how satisfied the visitor seemed, how it ended, and its topic.
• Proposed and completed actions: what the assistant offered to write on a visitor's behalf, the values it would have written, and what happened.

The purposes are these, and no others: to operate the assistant on your surfaces and answer your customers; to sign a visitor in and keep them signed in; to fulfil the requests a visitor makes and hand them to you; to prevent abuse of the service; and to give you your own analytics of the conversations on your site. We decide none of these purposes for ourselves.

Two honest notes. A conversation is free text, so a visitor can type anything into it, including data that would be classed as specially sensitive: nothing in the product asks for such data, and what your assistant invites is your decision. And the data model is yours, so what your entities collect is what we hold.

(ב) The systems your data sits in, and the ones we reach

Your data lives in managed services we run, all of them outside Israel. The principal ones, named as the register names them:

Google LLC (Google Cloud: Cloud Run, Cloud SQL, Memorystore, Cloud Storage, Cloud Logging) in region us-central1 holds the application database with your visitor accounts, conversations, preferences, events, insights and records, the media bucket with the images, and the application logs. Vercel Inc. (hosting and delivery) serves the pages and API calls of branderux.com, the embedded assistant and every published site. Vercel Inc. (AI Gateway) carries every hosted answer on its way to a model provider, and the model providers the register lists as enabled write the answer itself. Resend, Inc. sends a visitor's sign-in code and any escalation email to you.

The full register follows. It is the same list /legal/privacy renders and /api/legal/recipients serves as JSON, filtered here to the recipients a visitor's data actually reaches.

Our own access to those systems is by named individual accounts, granted for a named task at the smallest scope that accomplishes it, written into our authorisation register before the access is given, and reviewed quarterly. We keep no record of which of our personnel read which record, and we do not claim one: what stands in its place is the small number of authorised people, the undertakings in clause (ו), and the retention windows in clause (ד).

(ג) The processing we perform

On your instruction, and for the purposes in clause (א), we:

• Store the categories in clause (א) in the systems in clause (ב).
• Retrieve them to answer a visitor, to show you your own data, and to answer your questions about the conversations on your site.
• Transmit a conversation turn to the AI gateway and on to a model provider so the answer can be written, and deliver a sign-in code or an escalation email through our mail provider.
• Write on a visitor's behalf where you enabled it: create a record, and update an existing one only where you approved that separately.
• Delete on the schedule in clause (ד). It is a real deletion of the rows, not an archive flag.
• Export your data to you on request, in a structured machine-readable file.

We do not sell your data or your visitors' data, we share it with nobody outside the register, and we do not use it for our own marketing. The only processing we perform for purposes of our own is the processing named in the clause headed Processing for our own purposes, below.

(ד) How long we hold it, and what happens at the end

Each category has its own window, and each window is enforced by a job that runs whether or not anyone asks:

• Conversations and personalization events: deleted once they pass the window you choose for your site, 180 days by default and anywhere between 30 and 730 days if you change it. The insights and the quality evaluations belonging to a conversation are deleted with it, nightly.
• Ceilings that apply whatever the window says: at most the newest 2,000 conversation turns per project, and the newest 200 personalization events per visitor.
• Proposed and completed actions: 90 days.
• Visitor sign-in codes: deleted when the code is used or expires, and never longer than 15 minutes.
• A visitor's sign-in lasts 30 days. The identifier that groups one visit into a conversation lasts 30 minutes and is renewed on each message.
• Records a visitor creates, your data model, your agent configuration and your skills are kept for as long as your account and the project exist.
• Usage counters: daily token and request counts for 13 months, daily serving spend for 90 days. Both are counts, with no content in them.

This engagement runs for as long as we hold personal data for you.

At project deletion: deleting a project deletes the data under it, including the visitor conversations and the records held for that project.

At termination: we delete the project's data. There is no self-service delete button today, so write to contact@branderux.com and we delete the account and the projects under it. Export first. You can read your data through the product's own API at any time, and we will produce a file for you on written request before anything is deleted.

(ה) How we meet the Data Security Regulations

We keep the documents the Regulations require of us: a database definitions document, a written information security procedure covering access control, encryption, logging, incident handling and transfers abroad, and an authorisation register. They are reviewed at least once a year, and immediately after a material change or a security event. We will show you the current procedure on request, under confidentiality.

The measures themselves are the ones published under Security at /legal/privacy, and that list is the whole of it:

• Encrypted connections: every connection to the service uses HTTPS/TLS, and the application's connection to its database is encrypted as well.
• Encryption at rest by the platform: the managed Google Cloud services encrypt stored data at rest. That is a property of the platform rather than something our own code adds, so apart from the vault below, visitor emails, names and transcripts sit in ordinary database columns.
• API keys are never stored in the clear: we keep an HMAC-SHA256 digest computed with a server-side pepper, plus a short prefix. The server refuses to start without that pepper.
• The credential vault: your secrets, and your own model-provider key if you add one, are encrypted with AES-256-GCM under a 32-byte key held in our cloud secret manager, and are returned by no endpoint.
• Other secrets: visitor sign-in codes and agent authorization codes and refresh tokens are stored as SHA-256 hashes, never as the values themselves.
• Scoped access: project data is reachable only by the account that owns the project, and every project-scoped endpoint checks that before it answers. Agent tokens are short-lived and bound to the single resource they were issued for.
• No card data: no payment card details reach us at all.

The level we operate at. We operate at the BASIC security level under the Regulations, as a holder for controllers whose own databases are at basic level. That classification is conditional and we watch the conditions: no more than ten persons authorised to reach the database, no specially sensitive data by design, and no customer that is a public body. If your database is classified at medium level, or you are a public body, tell us. We reassess, and we confirm to you in writing what changes before we hold your data on that footing.

What we do not claim: we hold no security certification, we have not commissioned a third-party penetration test, and we keep no audit log of who read what. When any of that changes, this clause says so.

(ו) The people who can reach your data

Every person who can reach production systems or production data signs a written confidentiality undertaking BEFORE their first access, and the date is recorded in our authorisation register. A person with no date there does not get access.

The undertaking covers personal data, the free text of conversations, credentials and business information. It limits use to the person's own task, forbids reading visitor transcripts other than to investigate a specific fault or a specific request, forbids copying production data anywhere it is not already held, and forbids pasting it into any AI tool we have not approved for that purpose. It survives the end of their engagement with us.

Access is revoked on the day a person's need for it ends.

(ז) Sub-processors, and how you consent to them

By accepting this engagement you consent in writing to our engaging the recipients in our register: the list rendered at /legal/privacy and served, machine readable, at /api/legal/recipients. The register is the operative list, and the table in clause (ב) renders the part of it that a visitor's data reaches.

New sub-processors. We give you at least 30 days' notice, by email to the account holder, before a new recipient begins processing your data. If you object, you may terminate the affected project or your account before the change takes effect and we delete that project's data. That is the remedy this engagement gives you for an objection.

Their terms. We undertake to engage every sub-processor on written terms carrying the subjects of this engagement: purpose limitation, security, confidentiality, no onward transfer without written consent, notice of a breach and deletion at the end. The annex we offer them is published at /legal/vendor-annex. Where those terms are not yet in place with a recipient, the register says so in its transfer-basis field, and the clause headed Transfer out of Israel states our position today rather than an intention.

(ח) What we report to you

Three reports, and you never have to chase the second one:

• Annually: on your written request, and in any event within 12 months of the date you accept this engagement and every 12 months after that, a written statement of how we are meeting this engagement and the security duties the Regulations place on us as a holder.
• On a security event: notice without delay, and no later than 24 hours after we confirm an event affecting your data. It carries what we know at that point, being what happened, which of your data is affected as far as we can then tell, what we have done, and what we recommend you do. We do not wait for our investigation to finish before telling you, and we keep you updated as we learn more.
• On request: the current security procedure, the current list of sub-processors, and confirmation of the retention window in force for your site.

Reporting a breach of your database to the Privacy Protection Authority, and to the people affected where that is required, is yours to do as the database owner. We give you what you need for it, and we will not obstruct or delay it. Our address for every notice under this engagement is contact@branderux.com.

Who is who

For the personal data of your visitors you are the controller and the owner of the database (בעל מאגר), and we are a holder (מחזיק) processing on your instructions. We follow your instructions and this engagement, and we also carry, in our own name, the duties Israeli law places directly on a holder.

For your own account, being you as the account holder, your projects and your conversation with the Builder, we are the controller, and our privacy policy at /legal/privacy describes what we do with it.

This engagement forms part of the Terms of Service at /legal/terms for every account that accepts it. Where it and the Terms conflict about the personal data of your visitors, this engagement governs.

Where a visitor's request lands

A request from one of your visitors to see or correct their personal data is yours to answer: you are the controller and the request reaches you first.

Where such a request reaches us instead, we forward it to the account holder within 2 business days and act only on your instruction. We will not answer it for you, and we will not ignore it.

The one exception is written into section 14 of the Protection of Privacy Law: where you, the owner, are not a resident of Israel, a person may address a request to correct or delete their data to us as the holder. We then carry it out ourselves and tell you what we did.

The tools are in the product: a visitor signed in to a site we host can export the account, preferences, conversations, records and requests held for them there, and ask for that account to be deleted. Deletion removes their visitor account, their transcripts and their identity stamp; a record they created in your own data, such as an order or a booking, stays with you, and its contents commonly include what they typed into it.

What stays yours to do

Being the controller carries duties we cannot carry for you:

• Your own privacy notice: tell your visitors what your assistant collects, why, who receives it and how long you keep it. Our recipients are published and machine readable at /api/legal/recipients so you can name them in it.
• A lawful basis: collect only what you have a basis to collect, and obtain any consent your visitors' law requires.
• Marketing consent: contacts your assistant collects are not a marketing list. Sending them marketing is your decision and your legal risk, including the consent, unsubscribe and sender-identification rules of Israel's Communications Law (Amendment 40) and their equivalents elsewhere.
• Your own documents: where the Regulations require you to hold a database definitions document and a security procedure for your database, they are yours to write and to keep current.
• Your retention window: you choose how long conversations on your site are kept, within the range the product allows. A longer window is a decision about your visitors' data, not only a setting.
• Telling us what changes the picture: if your database moves to medium security level, if you become or acquire a public body, or if you start inviting specially sensitive data, tell us before it happens.

Processing for our own purposes

Two things we do with conversations are worth naming separately, because one of them serves us and not only you.

The first serves you: a session classifier reads a finished conversation and labels its topic and outcome, and an insights analyst reads stored conversations to answer the questions you ask about them. Both exist so you have analytics of your own site, and the analyst runs only when you ask it something.

The second is ours: quality reviews read stored conversations across BranderUX customers to score how well assistants answered. We will not run such a review over your data unless you have opted in, and it stays paused for your data until you do. These runs are triggered by a person on our side rather than automatically, which is what makes that promise one we can keep.

The opt-in will live in your project's Agent tab. Until that control ships, an account with no written opt-in is treated as paused, and you can opt in, or confirm that you have not, by writing to contact@branderux.com.

No training on your data

We do not use your data or your visitors' data to train, fine-tune or evaluate any model of our own, and we grant no one else the right to train on it. The purposes in clause (א) are the whole of what we do with it.

The model providers process a conversation turn under their own terms, which the register links per recipient. Where a provider's terms or settings offer stronger retention or training commitments than their defaults, that is a matter for our engagement with that provider, and clause (ז) is where we say whether such an engagement is in place.

Transfer out of Israel

Every system in clause (ב) is outside Israel, in the countries the register names for each recipient. By accepting this engagement you consent to that transfer for the purposes in clause (א), which is the consent the Privacy Protection (Transfer of Information to Databases Abroad) Regulations 5761-2001 contemplate at regulation 3.

We will not overstate what stands behind those transfers. The register carries a transfer-basis field per recipient and it states what is true today: a written undertaking where one has been signed, controller-directed where you chose the destination yourself, and none yet where we are still putting the undertaking in place. The table in clause (ב) renders that field per recipient, and it is the honest answer to the question rather than a summary of it.

Where the register says none yet, we are seeking the undertaking on the annex published at /legal/vendor-annex, and clause (ח) is how you find out where each one stands.

Liability

Our aggregate liability arising out of this engagement is limited to the fees you paid us in the 12 months before the claim. The limit does not apply to wilful misconduct.

Said plainly, because it matters more than the sentence above: the service is in beta and charges no fees, so that amount is currently zero.

Term

This engagement begins when the account holder accepts it and runs for as long as we hold personal data for you.

It ends when the account, or the last project holding your visitors' data, is deleted. Clause (ד) governs what happens to the data at that point, and the confidentiality and security duties in clauses (ה) and (ו) continue for as long as we hold any of it.

Governing law

This engagement is governed by the laws of Israel, without regard to conflict of law principles, and the competent courts in Israel have exclusive jurisdiction. That is the same law and forum as the Terms of Service at /legal/terms.

Acceptance, and this version

This is version 2026-09-11, in force from 11 September 2026. It is accepted online by the account holder, once, for the whole account and every project on it, and it replaces any earlier written arrangement between us on the same subject.

The acceptance is recorded against your account: the page at /legal/dpa/accept records the version and the date, and your account carries them from then on. An account that existed before this version took effect was not asked to accept it and is not blocked by it; it can accept from the same page at any time, and the engagement applies to it from the day it does.

A new version does not apply to you until it is accepted. If we change this engagement in substance we publish the new version, tell the account holder, and ask for acceptance of it.