KameleonAI: Data Processing Addendum

Effective Date: the date the Merchant installs the KameleonAI application.

This Data Processing Addendum ("DPA") forms part of the KameleonAI Terms of Service between Joseph Abdo, Angelo Ayranji and Ramy Sobhieh, trading together as KameleonAI, an unincorporated business based in Beirut, Lebanon, contactable at privacy@kameleonai.com ("Processor", "we"), and the merchant that installs the KameleonAI application ("Controller", "you"). Where they conflict, this DPA prevails on the subject of personal data processing.

When we incorporate, this DPA transfers to the new company under §13. We keep a versioned record of every acceptance, and we will ask you to accept again once the company exists.

---

1. Definitions

"Data Protection Law" means all laws applicable to the processing under this DPA, including the EU General Data Protection Regulation 2016/679 ("GDPR"), the UK GDPR and Data Protection Act 2018, the ePrivacy Directive 2002/58/EC and its national implementations, the California Consumer Privacy Act as amended ("CCPA"), and comparable US state, Canadian, Brazilian and other privacy laws.

"Personal Data" means personal data, personal information or equivalent under Data Protection Law that we process on your behalf under the Terms.

"Data Subject" means a store visitor or other individual to whom Personal Data relates.

"Sub-processor" means a third party engaged by us to process Personal Data on your behalf.

Terms such as controller, processor, processing, personal data breach, service provider, sale and share have the meanings given in Data Protection Law.

2. Roles

You are the controller (and, under CCPA, the business) for Personal Data relating to your store's visitors. We are the processor (and, under CCPA, a service provider) for that data and process it only on your documented instructions.

We are an independent controller for your own account, billing, support and app-usage data. That processing is governed by our Privacy Policy, not this DPA.

As a CCPA service provider, we certify that we: do not sell or share Personal Data; do not retain, use or disclose it for any purpose other than performing the services specified in the Terms, or as otherwise permitted by CCPA; do not combine it with personal information received from another source, except as CCPA permits; and will notify you if we determine we can no longer meet these obligations.

3. Scope of processing (GDPR Art. 28(3), Art. 30)

4. Our obligations

We will:

(a) Process on documented instructions. Process Personal Data only on your documented instructions, including on international transfers, unless required otherwise by law, in which case we will inform you first unless the law forbids it. The Terms, this DPA and your configuration of the app constitute your complete documented instructions. We will tell you if, in our opinion, an instruction infringes Data Protection Law.

(b) Ensure confidentiality. Ensure personnel authorised to process Personal Data are bound by confidentiality obligations and receive appropriate data protection training.

(c) Implement security measures. Implement the technical and organisational measures in Annex B, appropriate to the risk, as required by GDPR Art. 32.

(d) Manage sub-processors. Engage sub-processors only under §5.

(e) Assist with Data Subject rights. Taking account of the nature of the processing, assist you by appropriate technical and organisational measures in fulfilling your obligation to respond to requests to exercise Data Subject rights under Chapter III GDPR. If a Data Subject contacts us directly, we will not respond substantively other than to direct them to you, unless you instruct otherwise or law requires it; except that we will act on Shopify's mandatory customer data-request and redaction webhooks as described in §9.

(f) Assist with compliance obligations. Assist you in complying with GDPR Arts. 32–36 (security, breach notification, data protection impact assessments and prior consultation), taking account of the nature of processing and the information available to us. We will also provide the information you need for any risk assessment required of you under US state privacy regulations.

(g) Delete or return. At your choice, delete or return all Personal Data at the end of the provision of services, and delete existing copies unless law requires storage. Our default is deletion within 30 days of uninstallation.

(h) Demonstrate compliance. Make available all information necessary to demonstrate compliance with Art. 28, and allow for and contribute to audits under §11.

5. Sub-processors

You give general written authorisation for us to engage sub-processors. The current list is at Annex A.

We will give you at least 30 days' notice before adding or replacing a sub-processor. You may object on reasonable data protection grounds within that period. We will work in good faith to address the objection; if we cannot, you may terminate the affected service and receive a pro-rata refund of prepaid fees, as your sole remedy.

We impose on our sub-processors, by written contract, data protection obligations no less protective than those in this DPA, including the prohibition in §6. The contracts with Hetzner and Coolify Cloud are still being completed. We remain fully liable to you for our sub-processors' performance.

6. AI providers and the training prohibition

We use third-party AI providers to generate the assistant's responses. In respect of Personal Data and any of your data:

• We do not, and we contractually prohibit our providers from, using it to create, develop, train, fine-tune or improve any machine learning or artificial intelligence model (including large language models), and this prohibition extends to anonymised, aggregated and derived forms, including embeddings.
• Providers are contractually limited to processing the data solely to provide their service to us, and not for their own or any other purpose.
• We contract for zero or minimal retention with each AI provider and will confirm the applicable retention on request.
• We do not permit providers to use the data for their own analytics, benchmarking or product development.

We do not use your data for competitive benchmarking, and we do not disclose or make available to another merchant any insight, statistic or content specific to your store, your catalogue, your pricing or your shoppers.

6.1 Evaluation of the assistant

Training a model and testing our own product are different things, and we separate them. The prohibition above is about model development and it is absolute. This section describes the one thing we do with real conversations, so that it is disclosed rather than implied.

Before we release a change to the assistant (a revised instruction, a different model, a new feature), we replay real conversations through the candidate and compare the result against the current version. Without this we would be shipping changes to a shopper-facing assistant on the strength of synthetic examples, and the quality of what your shoppers experience would be worse for it.

To be precise about what this is and is not:

• No model is created, trained, fine-tuned or otherwise altered by it. No weights change, nothing is learned or retained by any model, and no data is sent to a provider for any purpose other than returning the response being evaluated, under the same purpose limitation as live traffic. The instructions we write are our own work product, not a model.
• It is evaluation of the service we provide, not development of a separate product. The assistant is a single service and its instructions are shared across merchants. A change validated against conversations from one store therefore improves the assistant every merchant receives (including yours, from every other merchant's conversations).
• Nothing specific to your store crosses to another merchant. Not your catalogue, your pricing, your conversion data, your shoppers or their conversations, and no insight, statistic or benchmark drawn from them. What is shared is our own instruction text and the general quality it produces.
• Past replays in our source repository. A small number of past replays remain in our source repository and are being removed.

7. International transfers

Personal Data is hosted on infrastructure in the European Union (Stockholm and Helsinki), in Switzerland (Zurich), which has an EU adequacy decision, and in the United States. It leaves the EEA and Switzerland in two ways, both of which we disclose:

1. Sub-processors in the United States: the analytics database, the merchant admin application, AI providers, monitoring and network services (Annex A).
2. Our own personnel in Lebanon: our engineering and support staff access production systems from Lebanon for support, maintenance and incident response. Lebanon has no EU adequacy decision, so this remote access is a restricted transfer under GDPR Chapter V even though the data itself is not stored in Lebanon.

Where we transfer Personal Data from the EEA, UK or Switzerland to a country without an adequacy decision, we rely on:

• the EU-US Data Privacy Framework (and its UK Extension and Swiss-US framework) where the recipient entity is certified for the relevant data type; and/or
• the European Commission's Standard Contractual Clauses (Decision 2021/914), Module Two (controller-to-processor) between you and us, and Module Three (processor-to-processor) between us and our sub-processors, together with the UK International Data Transfer Addendum for UK data.

Where the SCCs apply, they are incorporated into this DPA and take precedence over conflicting terms. For the purposes of the SCCs: the data exporter is you; the data importer is us; Annex I is populated by §3 and Annex A; Annex II is Annex B; the optional docking clause applies; the governing law and forum are those of Ireland; and the audit and sub-processor provisions of this DPA satisfy Clauses 8.9 and 9 respectively (Option 2, general written authorisation, 30 days' notice).

8. Personal data breach

We will notify you without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting Personal Data processed under this DPA. The notification will describe the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point.

We will assist you in meeting your own notification obligations to supervisory authorities and Data Subjects. We will not notify any supervisory authority or Data Subject on your behalf without your prior written instruction, except where law requires it of us directly.

We separately notify Shopify of any actual or suspected breach of Merchant Data within 24 hours, as Shopify's API terms require.

9. Retention and deletion

Three of these deserve an explanation, because the reason is the safeguard.

Chat conversations are kept for exactly as long as the identifier that can reach them lasts, which is why there are two periods. Once a visitor's identifier expires there is no key to that conversation from anywhere, so keeping the content longer would serve no purpose, and we delete it. The conversation and the only means of retrieving it expire together.

Where the visitor consented, that identifier lasts six months, and the assistant remembers them as a returning visitor within that window, which is why the period is not shorter. Where the visitor did not consent, we never set a lasting identifier at all: the conversation is held against a session reference that expires after 30 minutes of inactivity, and once it does, nobody can retrieve the conversation, including us and including the visitor. We therefore delete those conversations after 7 days. Seven rather than one because a small number of legitimate processes still read a conversation shortly after the visit ends (matching an order placed later that day, reconciling a cart, generating the merchant's summary), and all of them complete inside a week.

AI request traces are kept to debug and monitor the assistant, and are bounded by the conversation. Our AI tracing sub-processor records the inputs and outputs of each model request, which necessarily includes what the shopper wrote. These are deleted after 60 days, and, because a trace must never outlive the conversation it describes, traces belonging to a visitor who did not consent are deleted on the same seven-day schedule as that conversation.

Deletion completes within the stated period, not at the instant it is requested. When a conversation or trace reaches the end of its period, or when an erasure request is acted on, the record is removed from every system that serves it: it can no longer be retrieved, searched, or read by us, by your staff, or by our sub-processors. Our storage is versioned so that an operational mistake can be undone, so a residual copy remains briefly in that versioned layer and is then permanently removed. That final step completes within 7 days. We state this rather than claim instantaneous deletion, because the latter would not be true and the difference is the sort of thing an auditor tests.

Analytics reports are written by a language model from the conversation, and we mask direct identifiers before storing them. Reports are processed through automated detection and masking designed to mask Direct Identifiers before storage. "Direct Identifiers" means name, email address, postal address, telephone number and payment card number.

Automated detection is not exhaustive and may not identify every Direct Identifier. It relies on statistical models, and detection performance varies with text formatting, with language, and with the origin of a name. We therefore treat every report as Personal Data for the whole of its life: reports are subject to the technical and organisational measures in §12, including role-based access control, and are retained for the period stated in the table above. Masking reduces what a report contains. It does not make a report anonymous, and we do not claim that it does.

The same masking runs on error reports before they leave our systems. Our error-monitoring sub-processor is there to tell us when the service breaks, and its records are diagnostic: error type, stack trace, technical context and store identifiers. Provider error messages can quote the content that caused the failure, so they are passed through the same automated masking before transmission, subject to the same limitation stated above. Masking targets Direct Identifiers, so an error record can occasionally also carry a pseudonymous identifier; we design error messages not to include one, but we do not claim that none ever will. Error records are retained for 30 days. That period is set by our current plan with that sub-processor and is applied when each record is created; if we move to a plan with a longer period we will update the table in this section.

We would rather state this plainly than let you infer a guarantee we cannot keep. Every vendor we are aware of that offers automated identifier detection states the same limitation, and a commitment we can actually evidence is worth more to you than one we cannot.

Reports also keep a pseudonymous conversation reference, and keep it deliberately. A report retains the internal reference to the conversation it summarises, because that reference is what an erasure request follows in order to find and delete the report. Removing it would make these reports permanently unerasable, which we regard as the worse outcome.

We process Shopify's mandatory compliance webhooks as follows: we acknowledge receipt immediately and complete the requested action within 30 days.

• customers/data_request: we compile and deliver to you a machine-readable export of the Personal Data we hold relating to the identified individual.
• customers/redact: we delete the Personal Data we hold relating to the identified individual across all our systems, including conversation content, behavioural signals and derived profiles. The record becomes irretrievable immediately and is permanently removed from versioned storage within 7 days, as described above.
• shop/redact: we delete all data relating to your store that we process under this DPA. Your account and billing records, which we hold as a controller (§2), are kept only as long as accounting and tax law requires, as our Privacy Policy states; they contain no conversation content or shopper profiles.

A pseudonymous session reference can remain in our tracing system's index after the traces it points to are deleted; it carries no conversation content.

We identify records for export or deletion by Shopify customer identifier and order identifiers. Each compliance action is logged.

A limit you should know about, because we would rather state it than have you discover it. Our records of a storefront visit are keyed to a pseudonymous identifier we set in the visitor's browser, not to a Shopify customer account. The two are linked when that visitor places an order, because the order carries both. Until then there is no link. This has two consequences:

• A visitor who used the chat assistant but never completed an order cannot be located from a customers/redact or customers/data_request webhook, because those requests identify a person by Shopify customer identifier and no such identifier exists for them. Shopify does not hold a customer record for that visitor either, so in practice it does not send us a request about one.
• Where a request for erasure or access reaches you directly rather than through Shopify (a visitor who emails you saying they used the chat assistant), we can act on it if the visitor still holds our identifier in their browser. The chat interface provides a control by which a visitor can delete their own conversation data without needing to identify themselves to either of us.

Data belonging to visitors who never ordered is not retained indefinitely as a result. It is deleted on the schedule in the table above and on uninstallation, whichever comes first. That schedule is enforced by automated deletion jobs, and each run is recorded so that a failure to delete is visible to us rather than silent.

Where law requires us to retain data (for example, tax records) we will retain only what is required, for no longer than required, and will tell you.

9A. Consent provenance: both directions

You warrant that you maintain a privacy notice covering the processing described in this DPA and, where required in a visitor's jurisdiction, a lawful consent mechanism, and that consent signals surfaced through Shopify's Customer Privacy API reflect the visitor's actual choice.

We warrant that our storefront components will not write a non-essential identifier, read platform identifiers, capture behavioural signals, or build a profile until a valid consent signal is received where consent is required; that we fail closed when consent state cannot be determined; that we re-evaluate on consent change including withdrawal; and that we honour a Global Privacy Control signal as an opt-out from profiling and targeted messaging.

We will not condition the availability of the chat assistant on a visitor consenting to profiling.

9B. Prohibited configurations

You will not configure, and we will not enable, the service to:

(a) Tie the derived profile to commercial outcomes. The purchase-intent score, engagement level and shopping-style category may influence what the assistant says and when it says it. They must never determine price, discount eligibility, promotion access, or product availability. We enforce this as a product constraint.

This restriction does legal work for both of us. It is what keeps the processing outside automated-decision-making rules in the EU, outside the "legal or similarly significant effects" profiling opt-outs under US state law, and outside the automated-review right in Brazilian law, which expressly covers consumer profiling with no significance threshold. It is also the difference between personalised service and differential pricing by inferred psychology.

(b) Target minors. The service is not directed at children and must not be configured to identify or target them.

(c) Solicit special category data. You will not instruct the assistant to ask for, or steer conversations toward, health, biometric, political, religious, sexual-orientation, trade-union or similar information.

(d) Contact visitors outside the storefront using data obtained through the service, unless separately agreed in writing.

10. Data Subject rights

We provide functionality allowing you to access, export, correct and delete Personal Data relating to an identified Data Subject. Where a request cannot be satisfied through the app, we will assist you at no additional charge for a reasonable volume of requests.

Requests arriving through Shopify's compliance webhooks are handled as described in §9. Requests reaching you directly are subject to the identifier limit described there: where the Data Subject is an identified customer we can act on your instruction, and where they are an unidentified visitor the in-chat self-service control is the reliable route. Tell us and we will help either way.

We provide store visitors with a direct, in-widget means of opting out of behavioural profiling and proactive outreach, and we honour consent signals communicated through Shopify's Customer Privacy API, including the Global Privacy Control.

11. Audit

We will make available to you all information reasonably necessary to demonstrate compliance with this DPA and will contribute to audits, including inspections, conducted by you or an auditor you mandate.

In the first instance we will respond to a reasonable written information request or provide a completed security questionnaire, and any third-party audit report or certification we hold, no more than once in any 12-month period unless a personal data breach or a supervisory authority requires otherwise. Where that does not satisfy your obligations, we will cooperate on an on-site or remote audit, on at least 30 days' notice, during business hours, subject to confidentiality, at your cost, and conducted so as not to disrupt our operations or any other customer's data.

12. Liability

Each party's liability under this DPA is subject to the limitations and exclusions in the Terms, except where Data Protection Law does not permit that limitation.

13. Term and general

This DPA takes effect on installation and continues while we process Personal Data on your behalf. Obligations that by their nature should survive termination do so.

If a provision is invalid, the rest stands. Amendments must be in writing, save that we may update Annex A under §5 and may update this DPA where required by a change in Data Protection Law, on notice to you.

When we incorporate, this DPA transfers to the new company, which becomes the Processor. We will notify you when that happens.

Where you require a countersigned copy, contact legal@kameleonai.com.

---

Annex A: Sub-processors

Current as of 24 September 2026. The list in this Annex is the authoritative one; the same list appears in our Privacy Policy.

Annex B: Technical and organisational measures (GDPR Art. 32)

Encryption

• TLS for all external connections; data encrypted in transit between our services and our data stores, with certificate verification enforced on every connection to our cache
• Encryption at rest, stated per system rather than as a single claim, because it is not uniform:
  • Databases (conversations, messages, analytics events and reports, platform sessions): encrypted at rest by our managed database providers.
  • Cache: encrypted at rest (AWS ElastiCache, at-rest encryption enabled).
  • Object storage: encrypted at rest with server-side encryption (AWS S3).
  • AI request traces: our self-hosted tracing system stores traces on a single provider-hosted virtual machine whose disk is not encrypted at rest. The trace content is subject to the same masking, access restriction and 60-day retention as described in §9 and §12, and is bounded by the conversation it traces, but we do not claim disk-level encryption for it
• Application-layer encryption of platform access tokens using AES-256-GCM, with the encryption key held in our hosting providers' encrypted secret stores and never in source code or the database

Access control

• Cryptographically verified, store-scoped authentication on every request; a request authenticated for one store cannot reach another store's data
• Cryptographic verification of platform webhook authenticity before processing
• Role-based access to production systems, limited to personnel who require it
• Recording of internal administrative access to merchant and Data Subject data through the application: the staff member, the store accessed, the time, and the request route. Direct database and hosting-console access by engineering staff is restricted to those who require it and bound by §2(b), but is not covered by this record
• Multi-factor authentication and strong password requirements on administrative accounts of every service with access to production systems or customer data

Data minimisation and integrity

• Field-level minimisation: we do not request the protected customer fields, and Shopify redacts them before delivery
• Automated detection and masking designed to remove email addresses, telephone numbers and card-shaped numbers from chat content before storage and before transmission to our AI providers, except where the Data Subject gives the identifier as their own (for example, a call-back number), which is kept because it is needed to act on their request. AI request traces and analytics reports mask these identifiers in every case. This is automated and not exhaustive (see §9)
• Separation of test and production environments. Production data is not used to build or populate test environments. Real conversations are replayed against candidate versions of the assistant to evaluate a change before it is released, under §6.1, and never to train a model. A small number of past replays remain in our source repository and are being removed

Resilience and recovery

• Managed database backups by our database providers (Supabase, Timescale)

Governance

• Confidentiality obligations and data protection training for personnel with access
• Written data protection agreements with our sub-processors; those with Hetzner and Coolify Cloud are still being completed
• Periodic review of this Annex against the deployed system