Privacy Policy

Plain-language summary

Summary in plain words — this box is a guide only. Clauses 1 to 37 are the policy.

We are Carnelian Technologies L.L.C-FZ, a Limited Liability Company licensed by Meydan Free Zone in Dubai, United Arab Emirates. We make ABS Twin — a booking and customer-communication system that beauty and wellness studios in the UAE run for their own customers, together with the management console the studio's own people use. People often call it an "AI receptionist", and so do we in conversation, because software handles the messages and calls instead of a person at a desk. It is not a general-purpose AI assistant and it is not a medical system. Clause 23.8 sets out what it is not.

There are two different situations, and which one you are in decides who is responsible for your data.

1. If you visited our website, joined our waitlist, applied for ABS Twin, hold a login to our Console or Staff App, contacted our support, or called our demonstration number — we decide how your data is used. We are the Controller. Read Part A. 2. If you are a customer of a salon, spa or clinic and you messaged or called that business and its AI assistant answered — the studio decides how your data is used. It is the Controller; we only run the software for it. We are the Processor. Read Part B, and send your privacy requests to the studio first. We will help the studio answer you.

What the assistant does with what you say. It books, moves and cancels appointments, answers questions about services and prices from the studio's own catalogue, and keeps a written record of the conversation. It also builds a short profile of your preferences so the studio can serve you better — and, only where you have agreed to it, a further set of commercial notes about how you respond to offers. Clause 18 describes both halves and says which is which. It always tells you it is an AI.

It is software, and software gets things wrong. The assistant is built and instructed to follow the rules in clause 17 — book only what the calendar really confirms, quote only the studio's own prices, never take instructions from a message. It is a probabilistic system and it can depart from those rules, which is why we run the daily check described in clause 17.8. Clause 23.7 applies to everything the assistant says.

Where your data goes. Honestly: mostly outside the UAE. Our software runs on services hosted principally in the United States and Europe, and the AI models we use run in the United States or globally. We name every one of them in our Sub-processor List — including the ones underneath our voice provider, which most vendors do not disclose.

Who else can receive it. Only five kinds of recipient, and clause 25 names them all: the technology providers that run the service on our instructions; a small number of those providers who, for defined categories, also act for themselves — for their own security, fraud-prevention and compliance purposes — where their own notice governs; a court, regulator or authority that lawfully compels us — we do not hand data over without that compulsion, we push back on demands that go too far, and we tell the studio unless we are legally forbidden to; our own lawyers, advisers and insurers, under confidentiality, and only as much as the matter needs; and a buyer of our business, who is bound by this policy or something no weaker. We do not sell personal data and we share it with nobody else.

What we never do. We do not sell personal data. We run no advertising networks, no data brokers and no cross-site tracking. We do not use a studio's data or its customers' data to train AI models, and we do not use one studio's data to build products, comparisons or sales material aimed at another. Our website analytics set no cookies, write nothing to your browser and build no profile of you, and an automated test prevents the analytics code from being loaded anywhere near studio data. Clause 6 states exactly what is settled about them and what is not.

What we cannot honestly promise yet. Automatic deletion after a set period is not built yet — clause 27 says so plainly rather than quoting a period we do not enforce. We hold no security certifications and claim none.

Your rights. Under UAE data protection law you can ask what we hold, get a copy, correct it, ask us to erase or restrict it, and object to direct marketing at any time and without giving a reason. You can also object to a decision made by automation — that one has limits the law itself sets, and clause 23.5.1 states them honestly instead of hiding them — and you can always ask for a human being to review an automated decision, which is a right the law does not limit at all. Clause 29 says how. Clause 30 says how to complain to us, with a reference you can track, and how to complain to the UAE Data Office.

Contact: a privacy question, request or complaint → privacy@contact.abstwin.com, which reaches our Data Protection Officer (he is also at dpo@contact.abstwin.com) · general and product enquiries → info@contact.abstwin.com · the company mailbox support@carnelian.tech also reaches us · +971 56 498 4007 · Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E.

Where to look

Contents

Clauses 1–5 — who we are and in which capacity 1. Structure · 2. About this policy · 3. Who we are and how to contact us · 4. Definitions · 5. Our two capacities — the role map

Part A — where Carnelian is the Controller 6. Website visitors · 7. Waitlist · 8. Studio applications · 9. Console and Staff App accounts · 10. Support · 11. Billing · 12. Demonstration studio and line · 13. Lawful bases · 14. Retention

Part B — where a Studio is the Controller 15. Who is responsible · 16. What is processed · 17. What the Assistant does · 18. The Digital Twin · 19. Voice calls and recording · 20. Messaging and consent · 21. Instagram identity · 22. Staff records

Part C — matters common to both 23. AI and automated processing · 24. Model training · 25. Recipients: sub-processors, authorities, advisers, successors · 26. International transfers · 27. Retention and deletion · 28. Security · 29. Your rights · 30. Complaints · 31. Children · 32. Restricted Data · 33. Cookies · 34. What we never do · 35. Changes · 36. Governing law and language · 37. Arabic version

1. Summary of this policy's structure

1.1 This policy has four sections: a preliminary section, followed by three Parts.

1.1.1 The preliminary section (clauses 1 to 5) identifies us, defines the terms used, and explains the two capacities in which we handle Personal Data.

1.1.2 Part A (clauses 6 to 14) covers Personal Data for which Carnelian is the Controller.

1.1.3 Part B (clauses 15 to 22) covers Personal Data for which a Studio is the Controller and Carnelian is a Processor.

1.1.4 Part C (clauses 23 to 37) covers matters that apply to both — artificial intelligence, model training, who receives Personal Data (sub-processors, public authorities, our advisers and a successor to our business), international transfers, retention, security, your rights, complaints, children, restricted and health-adjacent data, cookies, changes, governing law and language.

1.2 Where a clause applies to only one Part, it says so. Where it does not say so, it applies to both.

2. About this policy

2.1 Who this policy is for. It is written for two audiences at once: (a) people who deal with Carnelian directly — website visitors, prospective and current Studios, Authorised Users, applicants and correspondents; and (b) Guests of a Studio whose Personal Data passes through ABS Twin. Because the legal position of those two audiences is different, the policy is split rather than blended.

2.2 This policy is a notice, not a contract. It does not vary the Master Subscription Agreement, the Data Processing Agreement or any other agreement between Carnelian and a Studio. Where this policy and those agreements differ on any matter as between Carnelian and a Studio, the Master Subscription Agreement and the Data Processing Agreement prevail for that Studio, and the Data Processing Agreement prevails over the Master Subscription Agreement on a data-protection matter.

2.2.1 No reliance, no contractual right, and no third-party rights. This policy is a transparency notice. It is not incorporated into any agreement, it confers no contractual right on any person, and it is not a representation, warranty or condition inducing any contract. No person other than Carnelian and the reader to whom a statement is addressed acquires any right to enforce it. Nothing in this clause excludes liability for fraud or fraudulent misrepresentation, limits the disclosure duty applicable law imposes on us, or excludes any liability that cannot lawfully be excluded.

2.2.2 Where a Studio has a claim founded on this policy. Any claim by a Studio arising out of or in connection with this policy, however framed — in contract, in tort, for misrepresentation, in restitution or under statute — is subject to the liability provisions, exclusions, carve-outs and financial limits of the Master Subscription Agreement and the Data Processing Agreement, and to the governing law and forum those agreements select. This clause does not apply to an individual reader who is not a Studio; clause 36.2.2 states the position for that reader.

2.2.3 This protection extends to the people who run the service. Where this policy, read with clause 2.2.2, limits or excludes a liability of Carnelian, the same limit or exclusion applies for the benefit of Carnelian's affiliates, officers, employees, contractors and Sub-processors, to the extent applicable law permits.

2.3 Applicable data-protection law. Carnelian is licensed by Meydan Free Zone in Dubai, United Arab Emirates. Meydan Free Zone is a non-financial free zone and has no data-protection legislation of its own — the DIFC and the ADGM are the two UAE free zones that do — so Carnelian is subject without qualification to the UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021 (the "PDPL"), together with any Executive Regulations issued under it and any successor or amending instrument. That is the basis on which this policy is written, and everything downstream of this clause depends on it. Where a Studio is established in, or processes Personal Data in, the DIFC or ADGM, the DIFC Data Protection Law No. 5 of 2020 or the ADGM Data Protection Regulations 2021 may additionally apply to that Studio's processing; and where a Studio serves data subjects in another GCC state, that state's law may apply. We describe this collectively as Applicable Data Protection Law.

2.3.0 Where another GCC law applies to a Studio. There is no GCC-wide data-protection instrument. Where the law of another GCC state applies to a Studio's processing — including the extraterritorial reach and transfer regime of the Saudi Personal Data Protection Law, and the sensitive-data permit requirements in Oman and Qatar, which become live the moment a licensed clinic is accepted under clause 32.5 — that law is addressed by a country addendum to the Data Processing Agreement for that Studio, and not by this policy. Where a Studio is established in the DIFC, note also the position at clause 23.2.3.

2.3.1 What the PDPL does not reach, and why that matters here. The PDPL itself removes two categories of Personal Data from its own scope, and we say so rather than let this policy imply a protection the statute does not give:

2.3.1.1 Health personal data that is subject to the legislation regulating the use of information and communication technology in the health fields — UAE Federal Law No. 2 of 2019 and its implementing resolutions — is outside the PDPL and sits under that separate regime, which is stricter, not lighter. Among other things it prohibits the storage, processing, generation and transfer of health data outside the United Arab Emirates unless an exception has been granted by the competent health authority. The exceptions are narrow, are granted case by case, and none of the published categories covers software-as-a-service or customer-service processing.

The carve-out is conditional, and its condition is unverified. Whether a given item of health-related data is in fact subject to that separate regime, rather than to the PDPL, depends on facts that have not been established. We therefore do not treat the carve-out as operating automatically. For breach routing, our internal breach response procedure runs the PDPL Article 9 route as the default for health-related data unless and until it is established that the health regime displaces it, because silence is not the safe answer: a notification withheld on an unproven premise is a missed notification, whereas a notification made on the PDPL route that later proves to have been governed by another regime is a correctable over-notification. Three statements are held open until the position is established: that the data is health data within Federal Law No. 2 of 2019; where it was processed or stored; and any contact with a health authority.

2.3.1.2 Banking and credit data that is subject to its own UAE legislation and to the supervision of the competent financial authorities is likewise outside the PDPL.

2.3.1.3 ABS Twin is not supplied for the processing of either category. It is a booking and customer-communication system for beauty and wellness services. Studios are contractually prohibited from entering Restricted Data (clause 32), and we ask Guests not to send it. Where such data nevertheless appears — for example because a Guest volunteers it in a message — the legal regime governing that particular data may differ from the PDPL regime this policy otherwise describes, and the rights and routes described in clause 29 may operate differently for it. Clause 32 explains what we do when we find it.

2.3.2 Data subjects outside the United Arab Emirates. ABS Twin is built for UAE studios and their customers, and this policy is written to UAE law. We recognise that a Studio's Guests will often not be UAE residents — a visitor to Dubai booking a treatment is an ordinary case — and that abstwin.com is reachable from anywhere. Our position is that the processing described in this policy is carried out in the context of services provided in the United Arab Emirates, and that we do not offer goods or services to, or monitor the behaviour of, individuals by reason of their being located in any other particular country. We do not for that reason give anyone less than this policy promises: the rights in clause 29, the recipient disclosure in clause 25, the transfer position in clause 26 and the complaint routes in clause 30 are available to every reader of this policy, wherever they are. Where a law outside the UAE does apply to a given processing operation and gives a data subject more, that law applies to that processing (clause 29.1).

2.4 The Executive Regulations to the PDPL have not been issued as at the date of this version. Where this policy states a period, a timescale or a procedure that the law does not yet fix, we say so and identify it as our own commitment, not as a statutory figure. We will review this policy within six months of the Executive Regulations being issued, or sooner if they require it.

2.5 Honesty commitment. We state only what is true of the system as built. Where a control is planned but not yet enforced, this policy says that it is planned. Where we do not yet know a fact a reader would expect us to know, this policy marks the gap rather than states a plausible guess.

2.6 This policy is the notice we are required to give you before processing begins. UAE law requires a Controller, before it starts processing, to tell you the purposes of the processing, the sectors and establishments the data will be shared with inside and outside the UAE, and the safeguards applied to any transfer outside the UAE. This policy gives all three: purposes are stated per activity in Part A and Part B; recipients are described by category in clause 25 — every category, including public authorities, professional advisers and a successor to our business, and not only our technology providers — and named individually in the Sub-processor List; and the transfer safeguards are in clause 26. It is published before you engage with us, and it is reachable without logging in.

2.6.1 What "all three" means while destinations are still being confirmed. Several rows of the destination table at clause 26.2 are still open. Where a destination is not yet established in our own records, this policy says so in that row rather than state a region we have not verified. We say that here so that clause 2.6 is not read as a claim of completeness standing over an open row.

2.7 Consistency with app store declarations. The declarations Carnelian makes in the Apple App Store privacy labels and the Google Play Data safety form must agree with this policy. Two separate artefacts sit behind that: the Staff App Privacy Notice, which is published, and our internal store-disclosure mapping that reconciles the labels, the form and this policy line by line, which is not. Where any of them differs from this policy, this policy is the reference text and the other is corrected to match it.

2.8 Platform Providers, and the limits of what this policy can describe. ABS Twin depends on Platform Providers, as defined in clause 4.1. Their availability, approvals, rate limits, quality ratings, policy changes and enforcement actions are outside Carnelian's control. This policy describes what Carnelian does, not what a Platform Provider does: where a Platform Provider processes Personal Data for its own purposes, its own notice governs that processing (clause 5.3), and where a Platform Provider suspends, throttles, deprecates or refuses a service, the consequences as between Carnelian and a Studio are addressed in the Master Subscription Agreement and the Service Level & Support Policy. Nothing in this clause disclaims responsibility for our own selection and configuration of those providers, which is ours.

2.9 Only the published text speaks for us. Only the version of this policy published at https://abstwin.com/legal/privacy states our position. No employee, agent, reseller or introducer is authorised to give an assurance about our data practices that differs from it, and none should be relied on. The operative homes for that rule as between Carnelian and a Studio are the Master Subscription Agreement and our Sales Agent / Referral Agreement.

2.10 Timescales in this policy, and events outside our control. Where an event outside our reasonable control — including an act, outage, suspension, throttling, policy change or enforcement action of a Platform Provider or Sub-processor, a direction of a regulator or a court, or a failure of telecommunications or internet infrastructure — prevents us from meeting a timescale stated in this policy, we will tell you, explain why, and meet it as soon as we reasonably can. The same applies where the volume of requests received in a period is so far beyond the ordinary that meeting the stated timescale for each is not reasonably possible; in that case we prioritise by urgency and tell you where your request stands. This clause does not affect any obligation that applicable law imposes on us regardless, and it is not a claim that no hardship or change of circumstance can arise.

3. Who we are and how to contact us

3.1 Controller and Processor identity.

carnelian.tech is Carnelian's corporate website. Company-level enquiries are answered at support@carnelian.tech, which remains a valid route to us for anything in this policy. Enquiries about ABS Twin itself are answered at info@contact.abstwin.com, and a privacy question, request or complaint goes to privacy@contact.abstwin.com so that it is routed and recorded — see clause 3.2.

3.2 Data protection contact. Privacy questions, requests and complaints may be sent to privacy@contact.abstwin.com, which is the intake address for data-subject requests and reaches our Data Protection Officer; to the officer's own address dpo@contact.abstwin.com; to the company mailbox support@carnelian.tech, marked "for the attention of the Data Protection Officer"; or by post to the address in clause 3.1 marked for the attention of the Data Protection Officer.

3.2.1 The address for each route, and the mail-domain rule. Each route in this policy has its own address, and you may use whichever fits your message:

Delivery to every address above was verified by test on 21 August 2026: all six deliver — info@, privacy@, dpo@, legal@ and security@contact.abstwin.com, and support@carnelian.tech. An earlier check on the same day was made too soon and reported otherwise; it is superseded by the verified result. Publishing a route on a branded address is an arrangement about routing only: it does not narrow the right at clause 3.3.2 to communicate with the Data Protection Officer directly, and mail marked for the officer's attention reaches the officer whichever of these addresses it is sent to. The apex domain abstwin.com has no mailbox at all, so no bare @abstwin.com address is one of our contact routes.

3.3 Data Protection Officer. Syed Sharique Ali, Manager of Carnelian Technologies L.L.C-FZ, is the appointed Data Protection Officer, with effect from 21 August 2026. He is reached at dpo@contact.abstwin.com, at privacy@contact.abstwin.com for a request or complaint, at support@carnelian.tech marked "for the attention of the Data Protection Officer", or by post at the address in clause 3.1. The UAE Data Office has not yet published the channel through which a Controller notifies its officer's contact details; the notification will be made as soon as that channel is published, and this clause is the published statement of those details in the meantime.

3.3.1 Why an officer is appointed. Our assessment is that Carnelian is likely required to appoint a Data Protection Officer, and one is appointed (clause 3.3). The limb we rely on is that ABS Twin adopts new technologies which, together with the nature of the processing, present a high risk to the confidentiality and privacy of the data subject's Personal Data. We do not rest the conclusion on the separate statutory limb that turns on a systematic and comprehensive assessment of Sensitive Personal Data including Profiling and Automated Processing, because ABS Twin is not supplied for the processing of Sensitive Personal Data (clauses 16.3 and 32) — although the Digital Twin is Profiling and Automated Processing, and if that limb is engaged it points the same way. A Data Protection Officer may lawfully be employed or engaged, and may be located inside or outside the UAE.

3.3.2 You may communicate with our Data Protection Officer directly. You do not need to go through anyone else, and we will not filter or refuse that contact. The route is the address in clause 3.3, marked for the officer's attention.

3.4 Which name will be on your paperwork. Where you contract with us, the counterparty is Carnelian Technologies L.L.C-FZ. The Assistant that speaks to a Guest carries the Studio's own chosen name (for example "Rahima") and identifies the Studio as the business it is speaking for — not Carnelian.

4. Definitions

4.1 In this policy:

Applicable Data Protection Law has the meaning in clause 2.3.

Assistant means the AI receptionist operating under the Studio's configuration, in the Studio's name, on the Studio's data, named per Studio, on the channels identified on the Order Form and enabled for the Studio. This definition describes what the Assistant is; it does not state, and is not to be read as stating, that any particular channel is available. It is commonly described as the Studio's "AI receptionist"; that is a colloquial description of the same thing and does not widen what it does, which is fixed by clause 17 and limited by clause 23.8. Which channels are in fact operating today is stated at clause 20.7, and nowhere else in this policy. (This definition is taken from clause 1.1.5 of the Master Subscription Agreement, which governs, with the rider from the Mutual NDA.)

Authorised User means an individual whom a Studio permits to access the Console or the Staff App under that Studio's account — owner, reception, manager or staff — including through an invitation issued by Carnelian at the Studio's request.

Carnelian, we, us, our means Carnelian Technologies L.L.C-FZ as identified in clause 3.1.

Carnelian Data means Personal Data for which Carnelian determines the purposes and means: website visitor analytics, waitlist sign-ups, studio-application data, Prospect Data collected for us by a sales agent or referral partner (clause 8.6), Console and Staff App account, identity and audit data, support-ticket data, billing data, and data of people who contact our demonstration studio. Part A of this policy covers Carnelian Data.

Console means the web control panel at app.abstwin.com, comprising the owner, reception, manager and Carnelian administration surfaces. Staff App means the application at staff.abstwin.com, and the native applications built on it when they are released.

Customer Data means all data, content and materials a Studio or its Authorised Users submit to, or generate through, ABS Twin — including configuration, catalogue, pricing, policies, rosters and Guest Data.

Digital Twin means the short written profile of a Guest that an AI model composes and maintains from that Studio's own conversation record, described in full at clause 18. It has two parts, which clause 18 separates: a service profile used to run the Studio's reception, and a commercial profile that is written only where the Guest has consented.

Guest means an individual who contacts, books with, or receives services from a Studio and whose Personal Data is processed through ABS Twin — whether by WhatsApp, Instagram, voice call, the reception desk or a data import.

Guest Data means the subset of Customer Data that is Personal Data relating to a Guest — identity, bookings, payments, conversation content, voice transcripts and the Digital Twin profile. Part B of this policy covers Guest Data.

Personal Data, Processing, Controller, Processor, Sensitive Personal Data, Biometric Data, Automated Processing, Profiling, Cross-Border Processing, Consent, Pseudonymisation, Anonymisation and Data Breach each have the meaning given in the PDPL, and the meaning given in any other Applicable Data Protection Law to the extent that law applies. Sensitive Personal Data is defined by the PDPL, but note clause 2.3.1: health personal data governed by UAE Federal Law No. 2 of 2019, and banking and credit data governed by its own legislation, fall outside the PDPL altogether and are dealt with in clause 32, not merely as a sensitive sub-category of what this policy otherwise describes.

Platform Providers means Meta Platforms / WhatsApp, Twilio, telephony carriers and SIP providers, AI model providers, hosting providers, app stores and payment processors, on whose services ABS Twin depends and whose terms, availability, pricing, approvals, rate limits, quality ratings and enforcement actions Carnelian does not control. Clause 2.8 states what follows from that.

Restricted Data has the meaning given in clause 2.2 of the Restricted / Health Data Addendum, which governs. It is reproduced here for readability and not as a second definition: health data as defined by UAE Federal Law No. 2 of 2019 concerning the use of information and communication technology in the health fields and by any health authority; clinical, diagnostic or treatment records; biometric identifiers; full payment card numbers, card security codes, PINs and magnetic-stripe or chip data; government identification numbers and copies of identity documents; and special-category data — in each case except to the extent that the particular item of data is objectively necessary to book, schedule or deliver the specific service the Guest has requested, and is limited to what that purpose objectively requires. A Studio's own entity identifiers are not Restricted Data. Where this reproduction differs from clause 2.2 of that Addendum in wording or in effect, the Addendum governs.

Interpretive note. A truncated card identifier (the last four digits) and a payment-provider payment-method reference are not Restricted Data — see clauses 11.2 and 16.1 category 3 — but they remain cardholder data, and this policy does not make the wider claim that Carnelian does not store, process or transmit cardholder data. What Carnelian does not store, process or transmit is a full card number, a card security code, a PIN, or magnetic-stripe or chip data.

Studio (also Customer) means the licensed business entity that subscribes to ABS Twin, acting exclusively for the purposes of its business or trade.

Sub-processor means any third party engaged by Carnelian to process Personal Data on a Studio's behalf, as listed in the Sub-processor List, together with that party's own onward sub-processors.

4.2 Where this policy names an article of the PDPL, the reference is to that article as in force from time to time and to any successor provision.

4.3 How we cite a lawful basis, and why the words come first. Where this policy states a lawful basis it states the basis in words and names the article, but not the numbered sub-paragraph. That is deliberate. The widely circulated English rendering of PDPL Article 4 contains a duplication in its enumerated list, so the sub-paragraph numbers in the English may not correspond to the Arabic. A privacy notice that mis-cites the sub-paragraph of its own lawful basis is worse than one that states the basis in words, and the words are what the statute actually requires us to convey.

5. Our two capacities — the role map

5.1 The line we draw, and why. Data collected to run a Studio's reception belongs to that Studio and may not be repurposed as Carnelian's commercial intelligence. That is a purpose-limitation requirement under the PDPL and it is also our own settled position. Everything below follows from it.

5.2 The role map.

5.3 Where a Sub-processor acts for itself. Some Sub-processors process certain data as Controllers in their own right for their own purposes — trust and safety, abuse detection, fraud prevention, network security, service improvement and legal compliance. Twilio, Stripe, Vercel, Clerk, Resend, Anthropic, OpenAI and Cloudflare each take that position for defined categories of data. Where that is so, that provider's own privacy notice governs that processing, we identify the provider and the category in the Sub-processor List, and we can neither instruct nor delete what it holds on that footing — see clause 27.4, which states the consequence for deletion.

5.3.1 Why this is not a labelling question. A provider processing for its own purposes is a different kind of recipient, with different consequences for you, and it is disclosed as such at clause 25.0 row 2. It also matters between us and a Studio: where UAE law attaches joint liability to processing that involves more than one processor without a clear written allocation of roles, the allocation must be written down rather than assumed.

5.4 Why publishing this split matters to you. It tells you whom to ask. If you are a Guest, the Studio is your first point of contact and it decides. If you dealt with Carnelian directly, we decide, and you deal with us.

PART A — WHERE CARNELIAN IS THE CONTROLLER

Part A applies to visitors to abstwin.com, waitlist subscribers, studio applicants, Authorised Users of the Console and Staff App, people who contact our support, Studios in their billing relationship with us, and anyone who contacts our demonstration line.

6. Visitors to abstwin.com

6.1 What we collect. Anonymous product-analytics events describing how the site is used: page views, clicks on calls to action (with the channel, placement and label of the button), openings of frequently-asked-question items, section views, and web performance measurements.

6.2 How the analytics are configured. Our analytics are deliberately minimal:

6.2.1 no cookies are set by the analytics tool and nothing is written to your browser's local storage — persistence is in memory only, for the length of the page visit;

6.2.2 no person profiles are created — the tool is configured never to build a profile for an identified person;

6.2.3 the analytics client is configured to anonymise IP addresses. The corresponding setting on the analytics project itself is stated in the next published revision, once it has been read in the live project: this policy states the client configuration, which is evidenced in our own code, and does not state that your IP address is anonymised at the provider until the project setting has been read. The Cookie & Tracking Notice carries the same answer;

6.2.4 session recording and screen replay are switched off;

6.2.5 a browser "Do Not Track" signal is honoured; and

6.2.6 events are sent to the analytics provider's European Union ingestion host (eu.i.posthog.com) and are stored in the European Union — the project runs on that provider's EU Cloud. The ingestion host is the destination configured in our own code; the provider's EU Cloud is where the data it receives is held. The Cookie & Tracking Notice governs the analytics detail, and clause 26.2 states the same position.

6.3 The wall between our analytics and Studio data. Analytics run on the marketing site only. They are not loaded in the Console, the Staff App or any part of the product that touches Guest Data. As at the date of this version, that boundary is maintained as an engineering control rather than as a policy statement: the boundary is asserted by an automated test, so that where analytics code is referenced outside the marketing site the test suite fails and the change cannot be merged. The control is listed in clause 35.5 as an item re-verified at each review of this policy.

6.4 Lawful basis, stated exactly. The analytics described in clause 6.2 are configured so that no Personal Data is processed by them: no cookies, no browser storage, no person profiles, and a "Do Not Track" signal honoured — and, subject to the open item at clause 6.2.3, the IP-truncation setting. To the extent any residual data collected by them is nonetheless Personal Data, our position is that we do not treat your continued browsing as consent to it, and that we will obtain consent by a clear affirmative action, and log it, before anything requiring consent operates. If we introduce any tracking technology that requires consent, we will ask for it that way and not otherwise.

6.5 Cookies. See clause 33 and the Cookie & Tracking Notice.

7. Early-access waitlist

7.1 What we collect. Your email address, the studio name you give, the source or campaign you arrived from, the country inferred from your request, your browser user-agent string, and the date and time of sign-up.

7.2 Purpose. To tell you when ABS Twin becomes available, and to understand where interest is coming from.

7.3 Lawful basis. Your consent, given by submitting the form. You may withdraw it at any time by writing to the contact address in clause 3.2; withdrawal does not affect processing carried out before it.

7.4 Retention and honest limitation. A waitlist sign-up is retained for 12 months from sign-up, or until removal on request, whichever is earlier — the period set by our internal retention and deletion schedule, which governs and which clause 27.3 restates. There is currently no self-service unsubscribe or deletion control on the waitlist. Removal is by request to the contact address in clause 3.2 and is handled manually.

8. Studio applications

8.1 What we collect when a business applies for ABS Twin through the public application form: the requested organisation name, city or area, business category, branch address, reception telephone number and WhatsApp number; the legal registered name, trade licence number, licence country and issuing authority, tax registration number and registered address; the owner's full name, email address, telephone number and role; and, as evidence that the online agreement was accepted, the agreement version, the fact and time of acceptance, and the IP address from which it was accepted. That last set is the acceptance record the form captures today; clause 8.5 describes the fuller record that will be captured from the re-acceptance flow.

8.2 Purposes. To assess and process the application; to verify that the applicant is a licensed business; to provision an account if the application is accepted; to keep evidence of what was agreed and when; and to prevent abuse of the public form.

8.3 Lawful bases.

8.4 What protects the form. A hidden-field trap that silently discards automated submissions, a server-side bot challenge that fails closed, a per-IP rate limit, and a single database write through a locked, insert-only access scope. The application is written once, to a single table, through that insert-only scope; the only other systems that see it are the bot-check service and the email service that sends the acknowledgement, both of which are identified in the role map at clause 5.2.

8.5 The existing click-wrap, and how it is being closed. Our public application form records acceptance of an agreement identified as version "v1.0". We will identify the document that version refers to, run a re-acceptance flow against the published Master Subscription Agreement, and record each acceptance with the version and a content hash of the text accepted, a UTC timestamp, the accepting individual's identity and role, the IP address and user-agent, taken from an unticked checkbox affirmatively ticked, with a copy emailed to the accepting party and the record written to an append-only log.

8.6 Prospect data collected for us by a sales agent or referral partner. Carnelian may engage self-employed sales agents and referral partners under our Sales Agent / Referral Agreement. Where such a person collects the details of a prospective Studio and passes them to us, that data — "Prospect Data" — is Carnelian Data and Carnelian is the Controller of it. We set out the position here in full, because no other clause of this policy covered it.

8.6.1 What is collected. The business name, city or area and business category; a contact individual's name, role, business telephone number and business email address; the channel and date of the approach; the agent's own identifier or agent code; and any note the agent records of what was discussed.

8.6.2 Purposes. To contact the prospective Studio about ABS Twin; to assess whether it is a business we can serve; to attribute an introduction to the agent for commission or reward purposes; and to keep the record of consent and of the approach that UAE marketing and telecommunications rules require to be kept.

8.6.3 Lawful basis. Consent, given by the individual to the agent at the point of collection, for contact about ABS Twin; and, for the attribution and record-keeping limb, the necessity of the processing for the conclusion or performance of the contract between Carnelian and the agent, and compliance with a legal obligation to keep the record. An agent may not collect Prospect Data from a list, a scrape or a purchased dataset, and an approach made to a number on the national Do Not Contact Register is not permitted. Where consent was not validly given, the data is deleted rather than repaired.

8.6.4 Retention. Prospect Data is retained for 12 months from the decision or from the last contact, whichever is later, in line with our internal retention and deletion schedule for an application that does not proceed; where the prospect becomes a Studio, the data is retained as part of the Studio's own record. Clause 27.2 applies: deletion is a manual operation, not an enforced timer. Evidence of consent and of the approach is retained for the period stated in that schedule and is subject to the one-way floor there.

8.6.5 Your rights and the route. The rights in clause 29 apply to Prospect Data in full, and Carnelian is the party to ask — not the agent. Write to the address in clause 3.2. You may object to marketing contact at any time, unconditionally and without giving a reason, and we will suppress the record rather than delete-and-recollect it. If you were approached and do not know how the approacher obtained your details, ask us and we will tell you which agent recorded the approach and when.

8.6.6 The position today. No Prospect Data is held by Carnelian today. No Agent is engaged, no Agent Code activated and no outreach conducted until the conditions in our Sales Agent / Referral Agreement are met.

9. Console and Staff App accounts

9.1 Who this covers. Studio owners, reception staff, managers, therapists using the Staff App, and Carnelian's own administrators.

9.2 What we collect and generate.

9.2.1 Identity and authentication: name, email address, credentials held by our authentication provider, session and device records, and account metadata recording the organisation, the role and the linked staff record.

9.2.2 Audit records: for every write performed by an Authorised User in a role for which auditing is enabled — and for decisions taken by the Assistant — we record the actor's identifier, the actor's email address, the actor's IP address, the action, the target record, the result and supporting detail. The documented actor types are owner, reception and the Assistant; whether writes made from manager surfaces are recorded under an allowlisted actor type is not established, and this policy does not name "manager" as an audited actor until it is.

9.2.2.1 The audit record has two capacities, and we allocate them. The read view of a Studio's own Authorised Users' actions inside its own tenant is made available to that Studio and is processed on the Studio's behalf — the Studio is the Controller of that view. Carnelian's own accountability copy of the same underlying record is Carnelian Data for which Carnelian is the Controller, is not processed on the Studio's behalf, and is not subject to a Studio's erasure or return instruction (clauses 27.8 and 5.2). The Data Processing Agreement allocates the same split in the same terms, so that neither document resolves the point by accident.

9.3 Purposes. To authenticate you; to enforce which surfaces and which data you may reach; to keep an accountability record of who changed what and from where; to provide support; and to secure the service.

9.4 Lawful bases. Performance of the contract with the Studio under which you are given access, and steps taken at the Studio's request (PDPL Art 4); protection of the interests of the data subject — the account holder whose account the control protects (PDPL Art 4); and, for the audit record, the establishment, exercise or defence of legal claims (PDPL Art 4). Where a security control also protects Guests whose data an account can reach, the Controller of that Guest Data is the Studio and the basis is the Studio's, not ours.

9.5 Access is invitation-only. There is no open self-service registration for the Console. Accounts are created by invitation issued at a Studio's direction.

9.6 What we do not claim. Our administrative surface is protected by a password, the identity provider's enforced email one-time-code first factor, and an administrator claim. It is not protected by a second authentication factor, because true multi-factor authentication is not available on our current identity-provider plan. We say so rather than describe an MFA control we do not have.

9.7 Removing an account. A Studio's owner or manager may suspend, reactivate or remove an Authorised User's access at any time, which disables the login. The staff record and its history remain in the Studio's account, because they belong to the Studio as Controller. See clause 27.6; note that the public deletion page described there is not yet available (clause 27.7).

10. Support, correspondence and tickets

10.1 What we collect. Your name, email address, the subject and body of your message, and any information you choose to include; a category and severity we assign; a target response time; and, where used, a draft reply.

10.2 AI assistance in support. A Claude model from Anthropic may be used to draft a suggested reply and to triage the request. A support reply is only sent after a human at Carnelian has reviewed it, and we record whether the draft was edited before sending. No support reply is sent automatically.

10.2.1 Where support correspondence is processed. In addition to the providers named in the role map at clause 5.2, support correspondence and limited incident evidence may be processed on Carnelian-controlled equipment in the United Arab Emirates for triage and the preparation of a draft reply, under the same confidentiality and access controls that apply to our hosted systems. That equipment is ours, not a third party, so it does not add a recipient under clause 25.0 — but a person who writes to us should be told where their message is read.

10.3 Purposes. To answer you, to resolve incidents, to operate, secure, support and quality-assure the service, and to keep a record of what was asked and answered.

10.4 Lawful bases. Performance of a contract or steps taken at your request (PDPL Art 4); and, where you write to us about a legal matter or a claim, the establishment, exercise or defence of legal claims (PDPL Art 4).

10.5 Please do not send us Restricted Data. Do not include clinical records, payment card numbers or government identification documents in a support message. If you do, we will remove them where we reasonably can and ask you not to do it again.

10.6 Support hours and response commitment. Our support channels and the hours on which they are staffed are published on the Service Level & Support Policy, which governs them. No service-level agreement is offered or implied by this policy.

11. Billing

11.1 What we collect. The Studio's billing contact details, the subscription tier and term, the identifiers of the billing records held by our payment provider, and invoice history.

11.2 What we hold of a card, stated precisely. Card details are collected directly by Stripe — the contracting entity is Stripe Payments Europe, Limited — a PCI DSS Level 1 certified service provider, through Stripe's own hosted pages and portal. We do not store, process or transmit a full card number (primary account number), a card security code, a PIN, or magnetic-stripe or chip data. What may be held is a truncated card identifier — the last four digits — and a payment-provider payment-method reference, so that a payment method can be identified, an invoice reconciled and a refund returned to the method it came from. We say it that way rather than claim we touch no cardholder data at all, because a truncated card number is still cardholder data and the wider claim would not survive inspection of our own schema. Clause 11.3 draws the line between our billing of a Studio and a Studio's own takings; the truncated identifier at clause 16.1 category 3 belongs to the latter. The Refund & Cancellation Policy and the Billing & Tax Invoice Terms state the same position.

11.3 This is our billing of a Studio, not a Studio's billing of its Guests. Payments taken by a Studio from its own Guests are the Studio's own arrangements; Carnelian is not the merchant of record for them and does not process them.

11.4 Lawful bases. Performance of the contract (PDPL Art 4); and compliance with obligations imposed on us by UAE law (PDPL Art 4), including tax and commercial record-keeping.

11.5 Retention. Billing and tax records are kept for the period UAE tax and commercial record-keeping law requires, which we understand to be 5 years from the end of the relevant tax period, including any longer period applicable to e-invoicing records.

12. Our demonstration studio and demonstration line

12.1 This clause applies to anyone who contacts our own demonstration line or demonstration studio, rather than a Studio.

12.2 Carnelian operates a demonstration studio and a demonstration telephone number, +971 4 329 4347, so that prospective customers can experience the Assistant. The same number is also the WhatsApp sender for that demonstration.

12.3 If you call or message that number, you are dealing with Carnelian, not with a Studio. For that conversation, Carnelian is the Controller. Everything in Part B about what the Assistant does technically still describes what happens; but the decisions about it are ours, your requests come to us, and this Part A applies.

12.4 What we collect there: your telephone number or Instagram identifier, the content of the conversation, a transcript and summary of any voice call, the call's duration and how it ended, and any booking you make in the demonstration.

12.5 Purposes. To demonstrate the product, to answer your questions, and to follow up on your interest if you ask us to.

12.6 Lawful basis. Steps taken at your request before entering into a contract (PDPL Art 4); and, for any follow-up marketing, your consent (PDPL Arts 4 and 6), which you may withdraw at any time.

12.6.1 What we tell you about AI before you speak. Because this is a Part A conversation and we are the Controller of it, the permission for sharing what you say with the AI providers named at clause 23.2 is ours to obtain, and we obtain it here rather than leave it to anyone else. Before the conversation begins, the Assistant states that it is an AI assistant operated by Carnelian and that what you say is processed by third-party AI providers to produce its replies, and it points you to this policy. You may end the conversation at that point, or ask to speak to a person instead. On the demonstration telephone line that opening statement is made at the start of every call. On the demonstration messaging sender it is made from the Messaging Disclosure Commencement Date identified in clause 12.8, and until that date the position on that sender is the reactive one clause 12.8 describes — the Assistant never presents itself as a human being and confirms plainly that it is an AI whenever you ask — with the AI-provider limb given in this policy, which the sender points you to.

12.7 Do not put your own clients' data into a demonstration. A demonstration is a demonstration: whatever you type or say into it becomes data we hold, under this Part A, for a purpose neither of us has contracted for. Please do not enter, paste, upload, dictate or read out real client names, telephone numbers, appointment histories or client lists when you are trying the Assistant, the Console or any demonstration environment — use made-up details. If you have already done so, tell us at the address in clause 3.2 and we will delete what you identify. Nothing in this paragraph creates a right for us to keep such data: the position in clause 32 applies to a demonstration exactly as it applies elsewhere.

12.7.1 We may also delete it without waiting to be asked. Where we become aware that real client data belonging to other people has been entered into a demonstration, we may delete it on our own initiative and without further instruction, because we are the Controller of the demonstration (clause 12.3), we did not ask for that data and we have no lawful purpose for holding it. We are not obliged to look for it and we do not represent that we will find it.

12.7.2 And whoever entered it is responsible for having been entitled to. A person who enters another individual's Personal Data into a demonstration is responsible for having had a lawful basis to do so, and for any notice that individual was owed. That is not a burden we can carry for you, because we do not know who those people are or what you told them.

12.8 The Assistant will tell you it is an AI. On a voice call it says so at the start of the call, as a fixed behaviour of the product (clause 19.1). On messaging, the position today is narrower and we state it rather than blend the two: the Assistant answers plainly and truthfully that it is an AI when asked — the reactive limb — and the proactive opening disclosure on a messaging thread takes effect from the Messaging Disclosure Commencement Date, which is defined in clause 7.1.1B of the Acceptable Use Policy by reference to the version of that Policy published under its clause 16.4. Until that date this policy does not claim a proactive AI disclosure on messaging. The same position is stated in clause 3.7 of the Legal Notice, clause 8.3.2 of the Website Terms of Use, clause 4.1.2 of the AI & Communications Addendum and clause 7.1.1A of the Acceptable Use Policy. See clause 19 and clause 23.

13. Lawful bases for Part A — the complete list

13.1 We rely only on the bases the PDPL provides. There is no "legitimate interests" basis in UAE law and we do not rely on one. Where a GDPR-based policy would say "legitimate interests", we have either identified a different basis or stopped doing the processing.

13.2 The bases we use, and for what:

13.3 Withdrawing consent. Where we rely on consent, you may withdraw it at any time, easily, by writing to the address in clause 3.2 or by using any unsubscribe control we provide. Withdrawal does not affect the lawfulness of processing carried out before it, and we will tell you if withdrawal means we can no longer provide something.

13.4 Choosing which channel we may use. Where we market to a Studio, a prospect or a waitlist subscriber, you may accept or refuse each channel separately — telephone call, email, and messages through a social-media or messaging application — rather than being put to an all-or-nothing choice. Tell us at the address in clause 3.2 which channels you are content with. This is separate from a Guest's objection to a Studio's marketing, which is all-or-nothing in the Guest's favour (clause 20.5).

14. Retention for Part A

14.1 The retention position for all data — Part A and Part B — is set out honestly in clause 27, including what is and is not automated today. Please read clause 27 as part of this clause.

PART B — WHERE A STUDIO IS THE CONTROLLER AND CARNELIAN IS A PROCESSOR

Part B is for Guests: customers of a salon, spa, clinic or similar business that uses ABS Twin.

15. Who is responsible, and whom to contact

15.1 The Studio decides; we execute. When you message or call a business that uses ABS Twin, that business — the Studio — decides why your data is collected and what is done with it. It is the Controller. Carnelian runs the software on the Studio's documented instructions. We are a Processor.

15.2 Contact the Studio first. If you want to know what is held about you, to correct it, to have it erased or restricted, to object to marketing, to object to a decision taken by automation or to ask for a human to review one, send your request to the Studio. It holds the relationship with you and it makes the decision.

15.3 What we will do if you contact us instead. We will not ignore you. We will acknowledge your request, tell you which Studio appears to hold the data if we can identify it without disclosing more than we should, and pass the request to that Studio without undue delay. We will then assist the Studio to answer it. We will not act on your request against the Studio's instructions except where Applicable Data Protection Law requires us to.

15.4 What we do on our own account with Guest Data. Nothing beyond operating, securing, supporting and quality-assuring the service — which includes the daily automated review at clause 17.8, incident handling, and the metering record at clause 16.1 category 8. We do not use Guest Data to market to you, to market to anyone else, to build products for other Studios, to produce comparisons, or to train AI models. See clauses 24 and 34.

15.5 Why clause 15.4 is a legal duty and not only a promise. As Processor we are required by UAE law to take no action that would disclose Personal Data or the results of processing it, except where the law permits. That second limb is the one that matters here: it means the outputs derived from a Studio's data — aggregates, comparisons, model outputs, insight products, sales material — are as closed as the data itself. It is the reason clause 15.4 can be stated flatly, and it applies whether or not any Studio has ever asked us for it.

15.6 Cross-tenant comparison is not permitted today. We do not combine one Studio's data with another's to produce industry comparisons, and no Studio has agreed to it. If we ever build such a feature it will require: a contract term agreed before the data is collected; opt-in with an easy opt-out; a minimum group size sufficient to prevent re-identification; operational aggregates only; no identifiable output; and the comparison being returned to the participating Studios. None of those conditions exists today, and the feature does not exist.

16. What is processed through ABS Twin on a Studio's behalf

16.1 The categories, numbered as they are numbered in the Data Processing Agreement. Categories 1 to 15 below carry the same numbers and the same boundaries as the annex to that agreement, so that the two documents can be read side by side and a request answered against either. Category 16 — call audio — is stated here in addition, because UAE law names voice on the face of its definition of Personal Data and a category that exists only during a call is still a category.

16.2 What is not collected, and what is. ABS Twin collects no biometric data: it does not create voiceprints and does not identify anyone by their voice. What ABS Twin itself stores from a call is text (category 6). But your voice is processed while the call is happening, by the voice platform and its speech providers, and it leaves the United Arab Emirates to do so — that is category 16, and clause 26.2 gives its destination. We separate the two because "we store only text" is true and, on its own, misleading.

16.3 Sensitive Personal Data. ABS Twin is not designed to collect health or other sensitive data, and Studios are contractually prohibited from entering it. But a Guest may volunteer such information in a message or on a call — an allergy, a pregnancy, a skin condition — and that free text then reaches the conversation record. Clause 32 explains how we handle that, what we prohibit, what we ask you not to send, and what we do when we find it. Clause 2.3.1 explains why some of that information may not be governed by the PDPL at all.

16.4 Lawful basis in Part B — the Studio's decision, not ours. As Processor, Carnelian does not choose a lawful basis for Guest Data; the Studio does, and it must be able to show it. The Master Subscription Agreement and the Data Processing Agreement require each Studio to warrant that it has a basis under Article 4 of the PDPL for every purpose it uses ABS Twin for, and that it has given its Guests the pre-processing notice the law requires. The bases a Studio will ordinarily rely on are:

16.5 No "legitimate interests". Neither Carnelian nor a Studio may rely on a legitimate-interests basis through ABS Twin, because UAE law does not provide one. Every purpose in the table above therefore sits on a named basis or it is not carried out — which is why the Digital Twin is split in two rather than described as "personalisation" and left unplaced.

17. What the Assistant does with what you say

17.0 How to read this clause. Two different kinds of statement follow, and the difference matters. Some describe deterministic controls — things ordinary software does, which the AI model cannot override: a booking is written only by a tool call that returns a real result, and a discount is calculated by code against limits the Studio set. Others describe how the model is instructed to behave — what it should say, what it should refuse, what it should never treat as a command. The Assistant is a probabilistic system and it can depart from an instruction. That is not a hypothetical: it is why the daily review at clause 17.8 exists and why a severe departure is handled as an incident. Clause 23.7 applies to everything described in this clause 17.

17.1 It books. It creates, reschedules and cancels real appointments against the Studio's live calendar. Deterministic: a booking exists only where the booking system returned a real result — the Assistant cannot write one by saying so. Instructed: it is designed and instructed not to state availability without checking availability in that same conversation, and a claim of availability not backed by a live check is one of the things the daily review looks for.

17.2 It answers. It answers questions about services, durations, opening hours, location, parking, payment methods and policies, and — where the Studio's catalogue has a price — it will state that price. The Assistant is instructed to use the Studio's own catalogue price and no other, and not to state a price where none is recorded. A price stated in conversation is model output, not a deterministic lookup, so the daily review checks the previous day's replies for prices outside the catalogue; where one is found it is corrected with the Guest and, if severe, handled as an incident.

17.3 It answers the Studio's own written questions and answers, which the Studio authors. That text is treated by the system as content, never as an instruction to the model, and is checked at the point the Studio saves it.

17.4 It escalates complaints to a human. If it detects a complaint, it apologises, tells you a human will follow up, and raises the matter to the Studio's owner or manager by email, in the Console and by an internal staff alert. It does not judge or resolve a complaint itself. On a voice call it will ask you to send the complaint by WhatsApp so that it reaches the right person, and it will take a message marked urgent.

17.5 It understands voice notes. A voice note you send on WhatsApp is transcribed to text by OpenAI's Whisper service and processed as text.

17.6 It speaks your language — on messaging. In messaging, the Assistant answers natively in English, Gulf Arabic, Hindi, Urdu, Tagalog, Malayalam, Tamil, Russian, Chinese, French and mixed speech. Voice transcription is presently English-only, pending an Arabic pass. We state that flatly rather than leave it open: an Arabic call-opening is of no use, and is actively misleading, if the Assistant cannot understand the Arabic reply it invites. No part of this policy states that the Assistant handles Arabic telephone calls.

17.7 What it is designed and instructed not to do.

17.7.1 It is instructed not to give medical, diagnostic, therapeutic or suitability advice, and not to tell you whether a treatment is safe for you, but to refer you to the Studio's own qualified people. A message classified as medical forces a deferral reply.

17.7.2 It is instructed not to discuss competitors, not to role-play, and not to act on instructions embedded in a message: a message from a Guest is handled as data and not as a command to the system. Attempts to inject instructions are detected, logged as a security event and answered with a fixed safety line — and mishandled injected instructions are one of the four things the daily review at clause 17.8 exists to catch, because the instruction is a control and not a guarantee.

17.7.3 It is instructed not to improvise a cancellation policy or an offer. Where the Studio has not written one, the intended behaviour is that the Assistant says nothing rather than invent something.

17.7.4 Deterministic: any discount it offers is calculated by ordinary software against limits the Studio sets, not decided by the AI model. There is a hard floor the model cannot go below and an absolute platform ceiling; those are enforced in code.

17.8 Quality checking. Every day, an automated review reads the replies sent and checks mechanically for bookings that were claimed but not made, prices outside the catalogue, availability claims not backed by a live check, and mishandled injected instructions. Severe findings open an incident. That review quotes at most a 160-character excerpt of a conversation and stores references rather than transcripts.

18. The Digital Twin — a profile written about you by an AI

18.1 What it is. For each Guest of a Studio, ABS Twin maintains a short written profile — the Digital Twin. An AI model reads that Studio's own conversation record with you and writes it. It has two parts, and they are not on the same footing.

18.2 This is Profiling as UAE law defines it, and we say so plainly rather than describe it as "personalisation". Because UAE law provides no legitimate-interests basis (clause 16.5), each part must sit on a basis of its own — which is why the split below exists rather than being a presentational device.

18.3 The service profile — written for every Guest, as part of running the reception. This is: a narrative about you; how you like to be communicated with and in which language; the services and booking times you prefer; a summary of your last conversation; and concerns you have raised. Basis: necessary to perform the contract with you, or to take steps at your request before contracting (PDPL Art 4; clause 16.4). It is what a good receptionist who remembered you would know, and the Studio cannot run the reception function you are asking it to run without it.

18.4 The guardrail, stated exactly. The instruction given to the model is that it must write only what the customer volunteered or clearly demonstrated, and that it must never infer family, medical or financial details. That instruction is a control in the system, not a guarantee of the output — see clause 23.7. It does not prevent the model from summarising something you have chosen to say: if you tell the Studio you are pregnant, that may be summarised into a concerns field, and clause 32 governs what happens then.

18.5 What it is not used for. It is used to help that Studio serve you. It is not shared with another Studio, not sold, not used for advertising, and not used to train any AI model.

18.6 The commercial profile — written only where you have consented. These are the fields that are about selling to you rather than serving you: how price-sensitive you appear; how receptive you are to suggestions; the services you have shown interest in; and opportunities the Studio might follow up. Basis: your consent (PDPL Arts 4 and 6). You are asked for it at the same point, and in the same way, as the marketing consent at clause 20.3. Where you have not consented, or you withdraw consent, these fields are not written, and any that exist are cleared with the marketing suppression. Nothing in the service profile at clause 18.3 depends on that answer.

18.6.1 Why the line falls there. A commercial score is not something the Studio needs in order to honour the booking you asked for, so it cannot ride on the contract basis; and there is no third basis in UAE law that would carry it. The same split is what allows us to say honestly, on the messaging channels, that we do not profile platform users beyond what running that Studio's reception requires (clause 34.1.7), and it is what a messaging platform's own terms require of an application that builds a profile of its users.

18.7 Your rights over it. You may ask the Studio for a copy of your Digital Twin, ask for it to be corrected, ask for it to be erased, object to it, and — because it is Automated Processing — object to any decision based on it and require that a human being reviews that decision. See clause 29.

18.7.1 How correction and erasure actually happen today. Two different things are described here and they must not be read as contradicting each other. What the Console can do, as clause 12.3.1 of the Data Processing Agreement states: a Studio can search and view a Guest's record and its conversation and call history, correct the record's fields, suppress marketing, record an objection, and escalate a decision to a human — with conversation and voice transcripts read-only. What the Console cannot do is the narrower point this clause makes: there is no control in the Console that edits, overrides or deletes a field of the Digital Twin profile itself, and there is no Console rights-request view, no restriction indicator and no self-service Guest-deletion function. For the Digital Twin, correction, override and erasure are performed manually by Carnelian, on the Studio's documented instruction, and both the instruction and the action are recorded in the audit log. We say that rather than describe a control we have not built.

18.8 Voice calls do not get the deepest personalisation. See clause 19.6.

19. Voice calls, transcripts and recording

19.1 You are talking to an AI, and it says so. The Assistant opens a call by naming the Studio and stating that it is the Studio's AI assistant. It will confirm plainly if you ask. It is instructed never to claim to be a human being. This announcement is a fixed behaviour of the product and a Studio cannot disable it — a point that protects the Studio as much as you, because UAE electronic-transactions law makes what the other party knew decisive for the enforceability of commitments made through an automated system.

19.2 No fake office noise. The voice platform's default is to play artificial background office sounds, which would make an automated call sound like a person at a desk. We switch that off on every assistant.

19.3 What is processed during a call, and what is kept afterwards. During the call, your voice is streamed to the voice platform and the speech providers beneath it so that speech can be turned into text and text into speech — that is clause 16.1 category 16, and clause 26.2 states where it goes. The AI notice is given in the opening words of the call, before anything you say is processed. After the call, what is written to the Studio's records is: the caller's number; the start and end time; the duration; how the call ended; the full text transcript; and an AI-written summary. No audio is kept — see clause 19.4.

19.4 Audio recording — there is none. Calls handled by the Assistant are not audio-recorded. No audio of your call is captured for storage, none is retained by us, and none is written to a Studio's records. What is kept instead is the written transcript described at clause 19.3 — the text of what you and the Assistant said to each other, retained as the record of what was communicated so that it can be evidenced afterwards, and readable by the Studio whose line you called and by Carnelian as the operator of the system.

19.4.1 Why the position is drawn this way. The UAE treats recording a conversation without the consent of the parties as a criminal matter, not merely a privacy matter, and being a participant in a call does not by itself entitle anyone to record it. Rather than operate a consent flow around an audio recording the service does not need, the product does not capture audio for storage at all.

19.4.2 What you are told at the start of a call, and what you can ask for. The Assistant states in its opening words that it is an AI assistant answering for the Studio; that announcement is a fixed behaviour of the product and a Studio cannot switch it off. The Assistant does not today say that a written transcript is kept — this policy and the AI & Recording Disclosure are where that is disclosed. A caller who would rather not speak to an automated assistant may say so, ask for a person, or end the call.

19.4.3 Who controls the record. The Studio is the Controller of the call record, including the transcript and the summary, and Carnelian holds it as Processor on that Studio's instructions. If audio recording is ever enabled for a Studio it will be enabled only on that Studio's documented instruction, and on that Studio's warranty to us that it has a lawful basis to record — and this policy, the notice a caller hears and the AI & Recording Disclosure will be updated before the first such call.

19.5 The AI notice will exist in Arabic as well as English. The English wording is drafted; the Arabic is drafted for review and has not been legally reviewed, and no Arabic runtime notice is spoken, sent or printed until that review is complete. The exact wording for each channel, and the review gate, are in the AI & Recording Disclosure. This is the same discipline this policy applies to its own Arabic text at clauses 36.4.1 and 37.

19.6 Caller ID is not trusted. Because a caller's number can be spoofed, what the Assistant will say to a caller is deliberately tiered: if the number is withheld, nothing personal is used; if the number is recognised, only tone and a general preference such as a usual appointment slot; anything drawing on your history requires you to confirm a detail an impostor would not know; and the deepest profile content is never used on a voice call at all.

20. Messaging, consent and stopping messages

20.1 Who is sending. Messages are sent in the Studio's name, from the Studio's own messaging sender. The Studio is responsible for the lawfulness of what it sends. Carnelian provides the technical means and the guardrails.

20.2 Two kinds of message.

20.2.1 Utility messages relate to a specific appointment — a confirmation, a reminder, aftercare guidance, a request for feedback. They contain no promotional content.

20.2.2 Marketing messages promote something — an offer, a campaign, a win-back, a birthday greeting with an offer attached. A reminder that also promotes something is a marketing message.

20.3 How consent is asked for. After a booking is confirmed, and only where no marketing preference has been recorded for you, the Assistant asks once, warmly, whether you would like to hear about offers. The fact that you were asked is recorded, so you are not asked again — including if you simply do not answer. If you decline, marketing is suppressed for you.

20.3.1 Silence is not consent. If you do not answer, no consent is recorded, no marketing is sent to you, and the commercial half of the Digital Twin (clause 18.6) is not written. UAE law requires consent to be provable, and an unanswered question proves nothing. The same answer governs both, so you are asked once and not twice.

20.4 An imported list is not consent. When a Studio imports its existing client list into ABS Twin, the import never sets a marketing preference for anyone. Consent has to be given, not inherited from a spreadsheet.

20.5 Stopping messages. You may object to direct marketing at any time and without giving a reason, and the objection takes effect for all marketing. Tell the Assistant, tell the Studio, or use any opt-out instruction in the message. A suppression is carried forward if your records are ever merged; it is never overwritten by a merge.

20.6 Guardrails configured in the software, not left to policy. The sending controls are designed and configured so that: marketing goes only to Guests who have opted in; there is at most one marketing message per Guest per 14 days; marketing is sent only between 10:00 and 18:00 Gulf Standard Time, which is the stricter overlap of the 09:00–18:00 window UAE telemarketing rules permit for marketing messages (including those sent through messaging and social-media applications) and the sending layer's own 10:00 opening; and guest-facing messages of any kind are held until 09:00 Gulf Standard Time, because a utility message is not a licence to wake someone. A failed send releases the frequency reservation so you are not silently skipped. These are configured controls that we keep under review; clause 20.7 states which of them are actually operating today.

20.7 What is live today. Conversational handling on WhatsApp is live. Reminder and campaign messaging is built but is not operating, because the message templates that platform rules require for messages sent outside a live conversation are not yet approved — so the frequency cap, the send window and the opt-in gate at clause 20.6 describe how the campaign path is configured and not a service running today. Instagram Direct handling is built, is gated behind a feature flag, and is NOT enabled in production. It is not live, not available and not operating, and it must not be described as any of those things in this policy, in any tier sheet, deck, store listing or sales conversation, until the flag is on for the Studio concerned. It is in testing, and it will be announced when it becomes available. We would rather say this than describe features that are dark.

20.8 Whose compliance obligation the sending is. The Studio sends; Carnelian supplies the means and the guardrails (clause 20.1). Compliance with UAE marketing and telecommunications rules is the Studio's responsibility as Controller — including any Do Not Contact Register screening obligation, any approval or registration required from the competent authority, sending only from a sender identity registered to the Studio's own licence, identifying the sender and the purpose in the message, observing frequency limits and the permitted hours, honouring opt-outs, and keeping the records those rules require. The Master Subscription Agreement, the AI Communications Addendum and the Acceptable Use Policy set out that responsibility and the warranties the Studio gives us. Nothing in clause 20.6 is a representation by Carnelian that a particular Studio's sending is lawful.

21. Instagram and how you are identified

Instagram Direct is in testing and is not available in production (clause 20.7). This clause describes how you are identified on that channel, and it becomes operative for you only if and when the channel is announced as available.

21.1 Meta does not give us your telephone number. When you message a Studio on Instagram, we receive your Instagram identifier and username. We do not receive your phone number.

21.2 So we do not identify you by telephone number. An Instagram Guest is held as a record keyed on the Instagram identifier with no phone number at all. If a booking needs a contactable number, the Assistant asks for one; if you later give a number that matches an existing record, the records may be merged.

21.3 Merging is protective, not destructive. When two records are merged, blocking status and marketing suppression are carried forward from both sides, never dropped.

21.4 Consequence for your rights requests. If you contact a Studio or us about Instagram-only data, we cannot verify you by telephone number. Verification will be through the same Instagram thread, or through a code sent in that thread. We will not ask you to prove your identity by supplying more sensitive information than the request itself needs.

22. Staff records held inside a Studio's account

22.1 A Studio may hold employment records about its own staff in the Console: name, contact details, role and job title, nationality, hire date, status, visa expiry date, health-authority certification expiry, branch assignment and booking limits; a restricted payroll block containing salary, commission, bank name, a bank-account field and a wage-protection employee number; and app-access fields recording invitation, activation and status.

22.2 The Studio is the Controller of those records. Carnelian is a Processor. Questions about them go to the employer.

22.3 What the software enforces. Payroll and other restricted fields are excluded server-side from manager surfaces — they are never returned to those surfaces and never writable from them. The Staff App is given only the fields a therapist needs; the response is assembled field by field on the server so that restricted fields never enter the app's memory, every response is marked private and not to be stored by caches, and access is limited to the staff origins.

22.4 Certification is a control, not advice. As at the date of this version, where a service is flagged as medical, the assignment check is configured to fail closed: a staff member whose health-authority certification is missing, unreadable or expired is not assignable to that service. It is a control we operate and keep under review, described rather than warranted as an outcome; clause 28.9 applies.

22.5 Bank account field. Whether the staff bank-account field is encrypted at rest, and by what mechanism, is stated in the next published revision. The field name implies encryption; this policy does not state it as fact until it has been verified.

PART C — MATTERS COMMON TO PARTS A AND B

23. Artificial intelligence and automated processing

23.1 What the technology is. ABS Twin uses large language models to classify what a Guest wants and to draft a reply, a speech-to-text service to transcribe voice notes, and a voice-agent platform to conduct telephone conversations. The models are supplied by third parties; we do not build or train models.

23.2 Which models, where.

23.2.1 Sharing with AI providers is disclosed, and permission is the Studio's to obtain. Conversation content, voice transcripts and profile text are shared with the AI providers named above so that the Assistant can work. Where a Guest's permission is required for that sharing, it is obtained by the Studio as Controller, not by Carnelian; the Master Subscription Agreement requires each Studio to obtain it, and the Data Processing Agreement records the AI sub-processing. In Part A cases — including our demonstration line — the permission is ours to obtain, and clause 12.6.1 describes exactly what we say and when.

23.2.2 Purposes are defined by people, not by the model. What the Assistant may do is fixed by the Studio's configuration and by the tools we give the model. The model chooses words; it does not choose purposes, does not choose which systems to call, and cannot grant itself new capabilities.

23.2.3 Codes and certifications, and one regime that may bind us directly. We do not claim adherence to any AI certification scheme, standard or code of conduct, because we hold none. We have shaped the disclosure in this clause on the DIFC's regulation of autonomous and semi-autonomous systems, which is the most developed regional template for what an AI disclosure should contain, and on the UAE's published AI ethics principles. Neither instrument binds Carnelian by reason of its own establishment, and we do not represent that they do — but where a Studio is established in the DIFC, that regulation may apply to that Studio's use of ABS Twin with the Studio as Deployer and Carnelian as Operator, which carries obligations on us directly, including the content of this notice, the maintenance of a system register, design principles, and — for high-risk processing — certification and an Autonomous Systems Officer. Whether any DIFC-established Studio is accepted, and, if so, the Operator obligations to be met before that Studio is onboarded, are settled before the first such Studio is onboarded and stated in the next published revision. The country-addendum route at clause 2.3.0 is where the analysis lands.

23.3 Are decisions made solely by automation? Some are, and we do not pretend otherwise:

23.3.1 the Assistant confirms, reschedules and cancels appointments autonomously during a conversation;

23.3.2 it applies discounts within limits the Studio has set, where the calculation itself is ordinary software;

23.3.3 it writes and updates the Digital Twin;

23.3.4 it classifies a message as a complaint and escalates it; and

23.3.5 it may end a call that becomes abusive, after one attempt to de-escalate.

23.3.5A What blocking a Guest does, and what it does not do. Where a Studio marks a Guest as blocked in the Console, that Guest is marked blacklisted and further bookings are refused. It does not stop the Assistant replying: the Assistant's silence gate reads a different field, and nothing in the Console writes it. Blocking a Guest in the Console is therefore not an automated decision that silences the Assistant, and we do not describe it as one. Where a Guest is to be suppressed from the Assistant altogether, that is done manually by Carnelian on request, using reasonable endeavours within one Business Day, via the abuse route at security@contact.abstwin.com, marked "Attn: Abuse" (the route the Acceptable Use Policy establishes; delivery verified 21 August 2026).

23.4 Where a human is involved, stated precisely. Complaints are resolved by a person, never by the Assistant. Support replies from Carnelian are sent only after a person approves them. The decision to refuse service, to block a Guest or to charge a fee is the Studio's, taken by a person in the Console — but the enforcement of the booking refusal that follows a block, and the ending of an abusive call, are automated, within the Studio's own configuration. We separate the decision from its enforcement because only the first has a person in it, and clause 23.3.5A states the limit of what that enforcement reaches.

23.5 Objecting to an automated decision. If a decision reached by automated processing has legal consequences for you or seriously affects you, you may object to it. Ask the Studio (or, in the cases in Part A, ask us).

23.5.1 The limits UAE law puts on that objection right. The right to object does not arise where the automated processing is included in the terms of the contract between you and the Controller, where the automated processing is necessary under other UAE legislation, or where you gave your prior consent to it meeting the law's consent standard. A Studio that uses ABS Twin is expected to describe the Assistant's automated handling in its own customer-facing terms, and where it has done so that first limb may be engaged for that Studio's Guests, depending on that Studio's own terms. We will not treat an objection as excluded on that ground without first confirming the position with the Studio. We state the limits because they are the law, not to discourage you from asking: even where the objection right does not arise, the Controller must still apply appropriate procedures and measures to protect the privacy and confidentiality of your data, without prejudice to your other rights.

23.5.2 Your right to a human review is not subject to those limits. Whatever the position on objection, UAE law entitles you to require that a human being reviews a decision taken by automated processing, and that right is unqualified. Ask the Studio (or, in Part A cases, ask us), and a person will review it. How that is done today: a Studio can read the automated outcome and the record behind it in the Console; bookings, blocks and messages can be changed there by a person; and for the Digital Twin, where no edit control exists yet, correction and override are performed manually by Carnelian on the Studio's documented instruction, with the instruction and the action recorded in the audit log (clause 18.7.1). The right does not depend on a control existing — it depends on a person reviewing the decision, and that is what we and the Studio undertake to do.

23.5.3 Who owes you that review, and what our part is. Where a Studio is the Controller, the Studio owns the human-review obligation — it is the decision-maker and the decision is its own. Carnelian's role is to supply the instrument: the escalation route, the review and override controls in the Console, the audit trail that records what a person did, and our assistance to the Studio in answering you. We do not take, reverse or refuse a Studio's decision on your instruction alone, for the reason given in clause 29.7. In Part A cases — including our demonstration line — the obligation is ours and we perform it ourselves.

23.6 Design safeguards we operate. Prices come only from the Studio's catalogue; availability is never asserted without a live check; medical and suitability questions are refused and referred to the Studio's qualified people; a Guest's message is data and never an instruction to the system; attempts to inject instructions are detected, logged as a security event and answered with a fixed safety line; text a Studio writes is checked at the point of saving; and a daily automated review checks the previous day's replies against those rules.

23.7 AI output is not guaranteed to be correct. Model output is produced by a probabilistic system. It can be wrong, incomplete or out of date. It should not be relied on without verification where it matters. A Studio is responsible for reviewing and configuring the Assistant, for the accuracy of the catalogue, prices, hours, policies and rosters it enters, and for supervising outcomes. Nothing in this clause limits any liability which cannot lawfully be limited.

23.8 What ABS Twin is not. It is a booking and customer-communication system for a Studio's own customers. It is not a general-purpose AI assistant, not a medical, diagnostic or clinical system, not a system of record for health information, not a payment processor, and not a source of legal, medical or financial advice. It does not make a Studio compliant with any law, and nothing in it should be taken as a representation that a Studio's own processing is lawful. Nothing in this clause excludes or limits liability that cannot lawfully be excluded or limited.

23.9 Where else this notice appears. The same disclosure exists at the point of use — the Assistant states that it is an AI at the start of every conversation and every call, and that behaviour is fixed and cannot be disabled by a Studio (clause 19.1) — in the Website Terms of Use, in the AI & Recording Disclosure, and in the Master Subscription Agreement with each Studio.

23.10 We assess the impact of this processing before we do it. UAE law requires a Controller to assess the impact of processing that uses modern technologies posing a high risk to privacy and confidentiality, and requires it specifically where processing involves a systematic and comprehensive assessment of personal aspects based on automated processing including profiling. The Digital Twin, the Assistant's automated handling, the voice channel and our cross-border processing are exactly that. We will prepare, hold and maintain a written impact assessment covering those four, and we state it in the future tense because it does not yet exist. It will explain the processing and its purpose, test whether the processing is necessary and suitable for that purpose, identify the risks and record the measures taken to reduce them; it will be prepared in coordination with our Data Protection Officer; and it will be reviewed periodically and after any material change. We also intend to make a pre-completed version available to each Studio, because the Studio is the Controller of Guest Data and the assessment obligation for that processing is the Studio's own. The date, reference and review cycle of the completed assessment are published in this policy once it exists.

24. Training of AI models

24.1 We state this in layers, because a single sentence would not be true.

24.1.1 Carnelian does not use Customer Data or Guest Data to train AI models, and does not train any model across tenants.

24.1.2 Anthropic's published commercial terms state that it does not train on business API content. We report what those published terms say; we do not state that we have completed the contractual verification behind them, because we have not, and an unexecuted agreement cannot be the source of a contractual bar. The carve-outs are stated every time this layer is stated: standard use of a non-covered model is not retained; a Covered Model carries a mandatory 30-day retention, with zero retention unavailable; stateful features are not zero-retention-eligible; and the workspace geography is United States only and is fixed at creation. An unqualified "nothing is retained" is not available at this layer.

24.1.3 OpenAI does not train on data submitted through its API absent an explicit opt-in by the customer. Whether the training and model-improvement setting on Carnelian's own OpenAI organisation is on or off is a fact about our own account, and it is stated in the next published revision once it has been read. Until then, this policy does not state that Carnelian has not opted in.

24.1.4 The voice layer — the voice-agent platform, the speech-to-text and text-to-speech providers underneath it, and the model that runs the in-call conversation — is the layer where we will not make an absolute statement. The providers are named: Soniox converts speech to text, ElevenLabs converts text to speech, and OpenAI's gpt-4.1 runs the conversation, each verified against the live voice configuration on 23 August 2026 and each processing in the United States. Carnelian configures the retention and training controls each provider makes available, and contracts to restrict such use where the provider offers that option; for the two speech providers that arrangement is not yet evidenced, which is why no absolute statement is made. The full position, provider by provider, is in the Sub-processor List.

24.1.5 Messaging platform data. Data received through the WhatsApp Business Platform is not used to create, develop, train or improve AI systems. We state this as our own commitment.

24.1.6 We never sell Personal Data.

24.1.7 Separately, Studios are not permitted to use ABS Twin's outputs, prompts or voices to build a competing model or dataset.

25. Who receives Personal Data — sub-processors and other recipients

25.0 The complete list of recipient categories. UAE law requires us to tell you, before processing begins, the sectors and establishments your data is shared with inside and outside the UAE. There are five categories and no others. They are, in full:

We do not share Personal Data with anyone outside those five categories. We do not sell it, licence it, rent it or trade it (clause 34), and we do not disclose it to advertisers, data brokers or list vendors, because we use none.

25.1 We publish the full list. The current list, with each provider's legal entity, its role in ABS Twin, the categories of Personal Data it touches, its processing locations and a dated record of additions and removals, is in the Sub-processor List.

25.2 We publish two tiers. Tier 1 is the providers we contract with directly. Tier 2 is the providers underneath them whose services your data actually reaches — in particular the speech and infrastructure providers beneath the voice platform. We publish both tiers, because a Guest's voice really does reach the second one and a list that stopped at the first would not tell you where your data goes.

25.3 Categories of Sub-processor and what each does (the named entities are in the Sub-processor List):

25.4 What we require of them. Each Tier 1 Sub-processor is engaged under a written agreement requiring it to process Personal Data only for the purposes we specify, to apply appropriate technical and organisational security measures, and to restrict onward disclosure. Where we contract on a provider's non-negotiable standard terms — which is the position with several of them — we record which written instrument governs that provider, we assess that instrument before engagement, and we do not represent more protection than it actually gives (clause 26.4). The Sub-processor List identifies the governing instrument for each provider, so you can see for yourself which is which. We state it that way rather than promise that every provider affords protection equivalent to this policy, because for the click-through tier that promise would not be true and could not be made true.

25.5 Changes. We may change Sub-processors. Where the relevant provider gives us equivalent advance notice, we give Studios at least 30 days' notice before a new Sub-processor begins processing; otherwise we give notice as soon as reasonably practicable and in any event before processing begins. Notice is given by email to the Studio's subscribed notice address and in the Console. A Studio's rights to object are set out in the Data Processing Agreement. We do not offer that mechanism to Guests, because a Guest's Controller is the Studio.

25.6 Retired providers. Two automation platforms previously used by the wider ABS Twin system have been retired and hold no live role. Until deletion of the historical data in each retired account is confirmed, each remains a current processor and is treated as one — a retired role is not a deleted dataset (clause 12 of the Sub-processor List). Whether historical data in those retired accounts has been deleted, and on what date, is stated in the next published revision.

25.7 Disclosure required by law

25.7.1 Who can require it. Personal Data we hold may have to be disclosed to a public authority. The authorities that can require it are:

25.7.2 On what legal footing. Disclosure of this kind is made because it is necessary to fulfil an obligation imposed on us by UAE law, or because it is necessary to establish, exercise or defend a legal claim or is connected with judicial or security procedures. It is not made on consent and we do not ask you to consent to it, because it would not be a real choice.

25.7.3 What we commit to, and it is a commitment against ourselves.

25.7.3.1 We do not disclose Personal Data to any authority in the absence of lawful compulsion. A request that is not backed by a legal instrument that binds us — a court order, a judicial decision, a statutory demand, or an equivalent lawful process — is refused. An informal request, an approach without process, or a request to "co-operate voluntarily" is not compulsion and does not get data.

25.7.3.1a The UAE Data Office is different, and we say so. The Data Office is the authority that supervises us and that would assess any complaint about us, and the PDPL owes it duties we do not qualify: we provide the UAE Data Office with the compliance evidence and the cooperation the PDPL requires of us, including the means of proving compliance at the request of a Controller or of the Office, processing in accordance with the Office's instructions where the law so provides, and dealing with the Office directly where it verifies a complaint. Clause 25.7.3.1 is not applied to the Office as though it were a foreign police force.

25.7.3.2 We challenge demands that go further than the law allows. Where a demand is overbroad, vague, made without jurisdiction, or seeks more data than the stated purpose needs, we take reasonable steps to narrow or resist it, including seeking legal advice and making representations to the authority or the court. Where we must disclose, we disclose the minimum the instrument actually compels, never the account, the database or the conversation history as a whole because that was easier to produce.

25.7.3.3 We tell the Studio, unless we are legally prohibited from telling it. Where the data belongs to a Studio's Guests or to a Studio's own records, we notify that Studio of the demand — before disclosure where the timetable allows, and otherwise as soon as we lawfully can — so that the Studio, as Controller, can take its own steps. Where a gag provision, a court order or a statutory prohibition forbids us from telling the Studio, we do not tell it, and we ask the authority to lift or narrow that prohibition. Where notice to the Studio is prohibited, we keep a record of the demand and of the prohibition so that it can be disclosed later, if and when the prohibition ends.

25.7.3.4 We keep a record. Every disclosure to an authority is recorded — what was demanded, by whom, under what instrument, what we disclosed, what we withheld and what we challenged.

25.7.4 Nothing in this clause is a promise we can break the law. If a binding instrument compels disclosure, we comply with it. We will not pretend otherwise, and we do not offer a Studio or a Guest a guarantee of non-disclosure that no company can honestly give. What we offer is the standard above, applied consistently. The detailed transfer and foreign-access analysis is held in our internal cross-border transfer assessment.

25.8 Our professional advisers, auditors and insurers

25.8.1 Personal Data may be disclosed to our own lawyers, accountants and tax advisers, auditors, and our insurers and insurance brokers — for example where a claim is threatened or made, where a dispute or regulatory matter is live, where a statutory audit or tax filing requires it, or where we must notify a claim under an insurance policy. Clause 27.5 anticipates exactly these situations as grounds on which data is retained; this clause is the matching disclosure of who sees it when they arise. Carnelian holds no insurance of any kind at present, so no disclosure to an insurer or an insurance broker arises today; the category is stated because it applies if and when cover is taken out.

25.8.2 The limits. Each such adviser is engaged under a duty of confidentiality, whether professional or contractual. Each receives only what the matter actually requires and not the surrounding record. Where a Studio is the Controller of the data in question, we notify that Studio on the same basis as clause 25.7.3.3, unless doing so would prejudice a claim between us and that Studio.

25.9 A change in our ownership

25.9.1 If Carnelian is merged, acquired, reorganised or restructured, if it raises investment, or if all or part of its business or assets is sold or transferred, Personal Data held in connection with the transferred business may pass to the acquirer, investor or successor entity — and, before that, to that party and its advisers as part of a due-diligence review.

25.9.2 What is guaranteed in that event.

25.9.2.1 The data goes with the promise. A successor takes the Personal Data subject to this policy, or to a policy no less protective of you. A change of ownership is not an opportunity to widen the purposes, and it does not create a licence to use Guest Data for anything clause 15.4 forbids.

25.9.2.2 Due diligence sees the minimum. Before any transaction completes, disclosure to a prospective party and its advisers is under a written confidentiality undertaking, limited to what the transaction genuinely requires, and made in aggregated or pseudonymised form wherever that is sufficient.

25.9.2.3 Studios are told. A Studio is notified of the change under clause 35 as a material change, and a Guest is told by its Studio, which remains its Controller throughout. Where a Studio's own agreement with us gives it rights on a change of control, those rights are unaffected — see the Master Subscription Agreement and the Data Processing Agreement.

25.9.2.4 The mirror case. Where a Studio is sold, that Studio's transfer of its own Guest records to its buyer is a transfer of Personal Data for which the Studio is responsible as Controller. We are not a party to it and we do not authorise it on the Studio's behalf; the Master Subscription Agreement and the Data Processing Agreement set out what the Studio must do.

25.10 Links to other people's websites

25.10.1 Our website and our documents link to third parties — a Sub-processor's own privacy notice, a payment provider's hosted page, an app store, a regulator. Those destinations are not ours, this policy does not govern them, and following a link takes you into someone else's terms and someone else's data practices. The full statement is in the Website Terms of Use.

26. International transfers

26.1 Lead with the truth. Most of the services that run ABS Twin are hosted outside the United Arab Emirates, principally in the United States. Part of the stack is genuinely in Europe, and we say which part rather than leaving it vague: the conversation database — where the messages themselves are stored — is in Ireland (eu-west-1), our outbound and inbound email run in Ireland, our website analytics are ingested and stored in the European Union, and our payment provider's contracting entity is Irish. What remains in the United States is the operational database, the AI providers, the whole voice chain, the hosting, the file storage, the encrypted backups and the login system. We do not claim UAE data residency, and we do not claim EU data residency for the stack as a whole, because neither would be true.

26.2 What goes where (the entity-by-entity detail is in the Sub-processor List). The rows below are set out against the sixteen data categories in clause 16.1 so that the two tables can be read together; the right-hand column gives the category number each row carries. Where a destination is not established in our own records, the row says so — clause 2.6.1 explains why we would rather leave it open than state a region we have not verified.

26.2.1 How to check this table. If a category in clause 16.1 does not appear in a row above, that is a defect in this policy and we want to know: write to the address in clause 3.2. The same movement data is recorded, provider by provider, in the Sub-processor List and in our internal record of processing activities, and the reasoning is in our internal cross-border transfer assessment. The three must agree; where they do not, the Sub-processor List and the record of processing activities are the operational records and this table is corrected to match them.

26.3 On what basis we transfer. The UAE Data Office has not published a list of countries recognised as providing an adequate level of protection, so we do not rely on adequacy and no document in this set describes any country as adequate. The structure is one set of safeguards applied to every transfer, and then the transfer condition relied on:

26.3.1 The safeguards — contractual measures, applied to every transfer without exception. Every recipient is bound by written terms requiring it to apply the protections, measures, controls and requirements the PDPL requires, and naming, for each recipient jurisdiction, the supervisory or judicial route by which those obligations can be enforced against that recipient there. That is the standard PDPL Art 23(1)(a) sets for transfers to a country with no personal-data protection legislation; we apply it to every destination whether or not it has such legislation, because it is the protection that actually travels with the data. We do not cite Art 23(1)(a) as the gateway for the destinations at clause 26.1 — Ireland and Germany plainly have data-protection legislation and the United States has sectoral and state legislation, so that gateway is not drawn for them.

26.3.2 The transfer condition we rely on for the service itself: transfer necessary to perform a contract with, or in the interest of, the data subject (PDPL Art 23(1)(d)). The Studio's Guest is contracting for an appointment, and delivering it through ABS Twin involves the transfers described above.

26.3.3 Where a Studio obtains it: the express consent of the data subject to the transfer (PDPL Art 23(1)(b)). This is additional to, not a substitute for, clause 26.3.1.

26.3.4 What this clause does not say. It is not a representation that a Studio's own transfers are lawful. A Studio is the Controller of Guest Data and must satisfy itself of its own transfer position; our analysis, and the limits of it, are held in our internal cross-border transfer assessment.

26.4 What that contractual measure actually contains. There are no UAE-issued standard contractual clauses. We therefore use our own cross-border transfer terms, which name — for each recipient jurisdiction — the supervisory or judicial route by which obligations can be enforced against the recipient there. Where a provider's own terms are non-negotiable, we record which written instrument governs that provider and we do not represent more protection than that instrument gives. See the Data Processing Agreement and its transfer annex.

26.5 What we do not do. We do not construct your consent to a transfer from the fact that you kept using the service.

27. Retention and deletion

27.1 The honest position first. UAE law requires that Personal Data is not kept after the purpose for which it was collected has been fulfilled, except in a form where the individual can no longer be identified, or where another law requires it to be kept.

27.2 Automatic deletion is not yet enforced in ABS Twin. Today, no operational record class is deleted automatically after a fixed period; deletion happens on request and by manual operation. (Short-lived technical state is the exception and it is not an operational record class: it expires by design in seconds to 30 minutes — clause 16.1 category 15.) We state this rather than publish a retention table we do not enforce, because publishing a period we do not apply would be a misrepresentation.

27.2.1 What we do about that in the meantime. An admission is not a plan, so here is the plan. Deletion on request is honoured today, by whichever route clause 27.6 gives you. No new class of data is added to the system without a retention decision recorded for it in our internal retention and deletion schedule. And the enforcement jobs that will apply the periods in clause 27.3 are a dated commitment in that schedule rather than an open intention. UAE law is stricter than some regimes here — data may not be kept once its purpose is fulfilled except in a form where you can no longer be identified — and we would rather show the remediation than let the admission stand alone.

27.3 The periods we intend to adopt, and the work behind them:

27.3.1 No backup is taken of the conversation database, and the two databases must not be confused. The nightly encrypted snapshot described at clauses 16.1 category 13, 28.2.2 and 28.4 covers the operational database — the store described at clause 25.3 that holds customers, bookings, staff, payments, settings, audit records, voice transcripts and Digital Twins — and nothing else. No backup at all is taken of the conversation database, the separate store that holds message content, per-turn records, AI usage and cost records, and operations and support records (clause 16.1 categories 4, 5, 8 and 11). We say so because it cuts both ways and a reader is entitled to both halves: it means there is no backup tail for that data — a deletion is not silently undone by a restore of a copy that does not exist — and it means the recovery position for that data is correspondingly worse, and depends entirely on the provider's own cycle. Our internal retention and deletion schedule is the operative record of this, and the Master Subscription Agreement, Annex 2 to the Data Processing Agreement and the Service Level & Support Policy state the same fact in the same two directions. Whether a backup of that database is introduced, and on what rotation, is stated in the next revision of this policy.

27.4 Deletion is not instantaneous and is not always complete. When data is deleted from ABS Twin, residual copies can persist for a period in encrypted backups and in our providers' own systems. Our providers keep their own tails — typically between 30 and 90 days after termination, and longer for records they must keep for compliance or trust-and-safety purposes. We do not promise deletion "within 30 days" across the whole chain, because the chain would break that promise.

27.4.1 One tail we cannot reach at all, and you should know about it. Where a provider retains content on its own footing as an independent controller (clause 5.3), that retention is not on our instructions and we can neither shorten nor delete it. The clearest example is the AI model provider: content flagged by its own trust-and-safety processes may be retained by it for up to approximately two years, for its own purpose, after we have deleted our copy. A Guest's message and Digital Twin text both pass to that provider (clause 23.2.1). We say this here rather than let clause 27.4's general reference to "providers' own tails" carry it, because a general reference does not tell you that a specific message of yours may outlive our deletion of it.

27.5 Grounds on which we retain data after a deletion request. We may retain Personal Data where it is needed for security or fraud prevention, to comply with a legal or regulatory obligation, to establish, exercise or defend a legal claim, or during a live dispute or a regulatory hold. We tell you when we do this and why, and we restrict the data to that purpose. Where one of those grounds is engaged, the recipients who may see the retained data are those named in clauses 25.7 and 25.8 and no others.

27.6 How deletion works in practice, by relationship.

27.6.1 Guests: ask the Studio. The Studio is your Controller, it decides, and we act on its instruction. Note that some identity records are deliberately kept in a marked, inactive state rather than removed outright, because removing them would corrupt the record of past appointments and could cause the same person to be recreated as a new record. Where that applies, the record is suppressed and no longer used, and we explain what remains.

27.6.1.1 You can also come straight to us, and we would rather you did than get stuck. A Guest — including a Guest who reached the Studio through Instagram — may send a deletion request in the same Instagram or WhatsApp thread, or to the address in clause 3.2, or (once it is available — clause 27.7) at /legal/delete-account. We will acknowledge it, identify the Studio that holds the data where we can do so without disclosing more than we should, and pass it on under clause 15.3, and we will action directly anything held in our own systems. Telling you to go and find a third party is not a route, and a messaging platform is entitled to expect the operator of the application — which is us — to give you one. This is what clause 15.3 already promises; it is stated here because this is where a reader, and a platform reviewer, looks for it.

27.6.2 Authorised Users: ask your employer, who can remove your access immediately. Your login is deleted with the account. Your employment record belongs to your employer.

27.6.3 Everyone else (waitlist, applicants, correspondents, demonstration-line callers): write to the address in clause 3.2. A public deletion page is being built and is not yet available — clause 27.7.

27.7 A public deletion page is being built, and does not exist today. We will publish a page at /legal/delete-account which explains, without any login and without installing anything, how to request deletion of an account and its data, what is deleted, what is retained and why, and which receives and tracks a request rather than describing one. Until it is published, the routes that operate are the ones in clause 27.6: ask your Studio, write to the address in clause 3.2, or send the request in the same messaging thread (clause 27.6.1.1). The Staff App Privacy Notice states the same position for the Staff App.

27.8 What happens to Guest Data when a Studio's subscription ends. This is the question a Guest most often has no way of answering, so we answer it here.

27.8.1 The rule is delete or return, and it is statutory. UAE law requires a Processor, at the end of the period for which it was engaged to process, either to erase the Personal Data or to hand it back to the Controller. That is not a commercial concession we grant a Studio and it is not something a Studio can waive by inaction. When a Studio's subscription ends, its data is not ours to keep, to reuse or to fold into anything else.

27.8.2 How we run it. At the end of a Studio's term, the Studio elects — within a defined window set out in the Master Subscription Agreement and the Data Processing Agreement — whether to take an export of its Customer Data and Guest Data or to have it deleted. Where the window passes without an election, we delete the data. Deletion is performed as a manual operation within 30 days of the window closing, and is subject to clause 27.2 (automatic deletion is not yet enforced, so this is a person running a job, not a timer), to clauses 27.4 and 27.4.1 (residual copies in encrypted backups and in providers' own systems, including a tail we cannot reach), and to the retention grounds in clause 27.5. Where a litigation hold or a regulatory hold is in place over some of the data, that part is preserved and the rest is deleted, and we tell the Studio which is which. Personal data is never held back, and never made conditional, because an invoice is unpaid (clause 29.5). Carnelian's own accountability copy of the audit record is not part of the Studio's data for this purpose (clause 9.2.2.1).

27.8.3 What that means for you as a Guest. Your Controller is the Studio. If it stops using ABS Twin, your data either goes back to it — where it remains subject to the Studio's own obligations to you — or is deleted from our systems. Either way we do not retain it to run anything of our own, and clause 15.4 continues to apply to it while we hold it. If you want to know which route your Studio chose, ask the Studio; if you cannot reach it, write to us at the address in clause 3.2 and we will tell you what we did with the data we held.

27.8.4 The mechanics, the election window, the export format and the deletion evidence are set out in our internal retention and deletion schedule and in the Data Processing Agreement.

28. Security

28.1 How the measures map to what the law requires. UAE law requires measures appropriate to the risk, in line with the best international standards and practices, and names four things in particular. We describe ours against those four.

28.2 Encryption and pseudonymisation.

28.2.1 All traffic to and from our services runs over HTTPS. The public site sets strict transport security and content-type and framing protections on every response.

28.2.2 Nightly database backups are encrypted with AES-256-GCM before they are uploaded, because the storage service they are written to serves objects from unguessable URLs and that is not by itself adequate protection for a UAE customer database. The backup job refuses to run at all if the encryption key is absent.

28.2.3 Our providers apply encryption at rest as standard.

28.2.4 Minimisation is used as a form of pseudonymisation in practice: see clause 28.6.

28.3 Confidentiality, integrity, availability and resilience.

28.3.1 Tenant isolation is enforced architecturally, not procedurally. As at the date of this version: a single adapter is the only route to the operational database; scoping to one organisation is mandatory, and a call that cannot resolve an organisation is configured to fail with an error rather than return unscoped data; after the database has filtered by organisation, a second ownership check in our own code discards any record belonging to another organisation; and the organisation is always taken from the authenticated session and never from anything the browser sends.

28.3.2 The conversation database is closed by default. As at the date of this version, row-level security is enabled on every table in it with no permissive policies, so the public interface can read nothing, and that rule lives in the schema file itself so that a new table is closed in the same change that creates it. This control exists because it once failed, and the failure was fixed and then re-hardened after it recurred — we publish that because a reader is entitled to know it, and because it is the reason the measures in this clause are described rather than warranted as an outcome.

28.3.2.1 How clause 28.3 is to be read. These are the measures we operate and keep under review. They are described, not warranted as an outcome; clause 28.9 applies to all of them, and where a Studio founds a claim on this clause, clause 2.2.2 routes it to the security annex of the Data Processing Agreement and the liability provisions of the Master Subscription Agreement.

28.3.3 Access classes are enforced in three places — at the network edge, in the page layer and in the data layer — never only in the interface. Four classes exist: owner, reception, manager and Carnelian administrator.

28.3.4 Inbound traffic is authenticated. Messaging webhooks are signature-verified and fail closed; scheduling callbacks are verified by signed token and body hash; identity webhooks are verified by HMAC with a short replay window; the Instagram interface verifies Meta's signature. One exception is disclosed: the voice platform offers no request signing, so its callbacks are authenticated by a bearer secret bound per Studio, and every destructive action re-proves ownership on the server before it executes.

28.3.5 Uploads are checked by content, not by filename. As at the date of this version, file type is determined from the file's own bytes rather than its name, so a renamed executable is rejected; only images and, for brochures, PDFs are accepted, with size caps; filenames are sanitised; files are namespaced per organisation with a random suffix; the previous file is deleted on replacement; and every upload and removal is recorded in the audit log.

28.3.5.1 How objects in the file store are protected, stated plainly. Objects in that store are served from unguessable URLs. That is why the nightly database backup is encrypted with AES-256-GCM before upload (clause 28.2.2) — an unguessable URL was judged not to be adequate protection for a UAE customer database. Uploaded files — logos, brochures and imported client lists — are namespaced per organisation with a random suffix but are not additionally encrypted, so their protection is the unguessability of the URL and nothing more. An imported client list can contain a whole client book (clause 16.1 category 12). We say this rather than let clause 28.3.5's list of controls imply a private store.

28.4 Timely retrieval after a failure. A full snapshot of the operational database is taken nightly and stored encrypted. That snapshot covers the operational database and nothing else: no backup is taken of the conversation database at all — which shortens the deletion tail for the data in it and worsens the recovery position for that same data, and clause 27.3.1 states both halves. A separate daily read-only check exercises the booking engine end to end and fails loudly if it cannot produce a bookable appointment. We have not documented a tested restore, and we do not claim one.

28.5 Testing and evaluation. Every change to the system is checked before it is merged by a person with no involvement in building it, against a fixed checklist covering security, correctness against the live data schema, error handling and test coverage; the verdict is recorded against the exact version merged. Production incidents are handled under a written runbook with defined severity classes, an escalation path and a rule that an incident without a new regression test is not closed. No independent penetration test has been commissioned, and no periodic control review is scheduled. We state the negative rather than leave the question open, because a reader is entitled to know what has not been done.

28.6 Data minimisation as a security control. These are specific and verifiable:

28.6.1 push notifications to staff devices carry a first name only, never a full name and never a telephone number;

28.6.2 the Staff App receives only the fields a therapist needs, assembled field by field on the server so restricted fields never enter the application's memory; responses are marked private and not cacheable; and access is restricted to the staff origins;

28.6.3 a Studio owner's daily briefing carries counts and money only, and no Guest personal data;

28.6.4 operational alerts carry a correlation identifier only, never the conversation lane, because a lane embeds a telephone number;

28.6.5 automated quality findings quote at most a 160-character excerpt and store references rather than transcripts; and

28.6.6 manager surfaces exclude payroll and restricted personal fields server-side — those fields are never returned and never writable there.

28.7 Accountability. Every write performed by an Authorised User in a role for which auditing is enabled (clause 9.2.2) is recorded with the actor, the actor's email address, the actor's IP address, the action, the target, the result and supporting detail. Decisions taken by the Assistant are recorded the same way and marked as agent actions. Audit writing is fail-safe: a failure to write an audit record never silently blocks the underlying action, and the failure is itself surfaced.

28.8 What we do not claim. We hold no SOC 2 report, no ISO 27001 certification, and no other security certification, and we do not describe ourselves as "bank-grade" or equivalent. We publish no certification badge we have not earned. We offer no uptime commitment through this policy.

28.9 The honest qualifier. No system, and no method of transmitting or storing data, can be guaranteed to be completely secure. We take the measures described above and keep them under review, but we cannot and do not warrant absolute security. Nothing in this clause excludes or limits any liability which cannot lawfully be excluded or limited.

28.10 If something goes wrong. Where a personal-data breach occurs, we act as follows.

28.10.1 Where Carnelian is the Controller, we investigate, report to the UAE Data Office in accordance with the PDPL and, where the breach would prejudice the privacy, confidentiality or security of your data, we notify you and tell you what we have done.

28.10.2 Where a Studio is the Controller, we notify that Studio without undue delay and in any event within 24 hours of becoming aware, and we assist it. The Studio makes the report and notifies its Guests. This 24-hour period is our own commitment, not a statutory deadline: the PDPL requires a Processor to notify "immediately" and leaves the period to Executive Regulations that have not been issued (clause 2.4).

28.10.2.1 What the 24 hours runs from, and what it contains. Three things make that promise capable of being kept:

28.10.2.1.1 "Becoming aware" means knowledge, on the part of any director, employee, contractor or freelance agent of Carnelian, of facts indicating that a personal-data breach affecting that Studio's data has occurred. Awareness is not deferred to initial triage, to a manager's review, or to office hours. This is the definition in our internal breach response procedure, which governs, and the Data Processing Agreement states it in the same words. A Personal Data Breach includes an event that Carnelian cannot rule out having occurred, and excludes an unsuccessful attempt against a control that held.

28.10.2.1.2 The first notification may be incomplete. We give what we have within the 24 hours and supplement it as the investigation proceeds, including the further information the law requires the Studio to report. A holding notice sent on time is better for the Studio than a complete notice sent late, and this clause is drafted so we are not forced to choose.

28.10.2.1.3 Where we first learn of a breach from a Platform Provider or a Sub-processor, the period runs from our awareness, not from the moment the incident occurred upstream. Most of our providers owe us only "without undue delay", and we cannot promise a Studio a clock we do not control.

28.10.2.2 The Data Processing Agreement states this in the same words, so that neither document can be read as the tighter one.

28.10.3 A notification is not an admission of fault or liability.

29. Your rights and how to exercise them

29.1 The rights. Under the PDPL you have the following rights. Where another Applicable Data Protection Law gives you more, that law applies to that processing. Where Personal Data falls outside the PDPL under clause 2.3.1 — health personal data governed by UAE Federal Law No. 2 of 2019, or banking and credit data governed by its own legislation — the rights below are not the applicable ones for that data, and the rights and routes given by that other regime apply instead; write to us at the address in clause 3.2 and we will tell you which regime we consider applies and why. Whichever regime applies, we will in any event handle your request under this clause 29 unless the law requires us to do otherwise — you should not be worse off for having mentioned an allergy in a message than for not having mentioned it. That is already what we do in substance under clause 32.4.

29.2 How to exercise them.

29.2.1 If a Studio is the Controller (Part B) — contact the Studio. If you cannot reach it, write to us at the address in clause 3.2 and we will pass your request on and assist.

29.2.2 If Carnelian is the Controller (Part A) — write to the address in clause 3.2. A public deletion page at /legal/delete-account will be published and is not yet available (clause 27.7).

29.2.3 How you get a copy, in practice. The right to a copy in a structured, machine-readable format is only real if there is a way to obtain one, so we say plainly how it works today. There is no self-service export control for a Guest. A copy is obtained by making the request through the route in clause 29.2.1 or 29.2.2, and it is produced as a machine-readable file — the data you provided, plus the records generated about you, including your Digital Twin (clause 18.7) — within the timescale in clause 29.4. The copy is produced manually, by a named person at Carnelian, on the Studio's instruction where the Studio is the Controller. There is no export control in the Console today, for a Studio or for a Guest — the Console has an import wizard and no matching export, and a Studio therefore cannot produce an export for its own Guest from the Console. (The client-import report is exportable; it is not a full export.)

29.3 Verifying who you are. We will verify your identity before acting, proportionately to the sensitivity of the request, and we will not ask for more information than the request requires. Because Instagram does not give us telephone numbers, an Instagram-only request is verified inside the same Instagram thread rather than by telephone (clause 21.4).

29.4 Our response commitment. We will acknowledge a request within 5 business days and respond substantively within 30 calendar days of verifying your identity, extending only where a request is complex and telling you if we do. This is our own commitment. UAE law does not currently fix a response period; the Executive Regulations may. Clause 2.10 applies to these periods as it applies to every other timescale in this policy.

29.5 Charges. Exercising your rights is free. We will not charge you, and we will never make access to your own Personal Data conditional on a Studio's account being paid up.

29.6 When we may refuse or limit a response to a request for information. These are the grounds the law gives for refusing or limiting a request for information about processing — they are not the grounds on which erasure may be refused, which are separate, narrower and set out in the erasure row of clause 29.1. On this ground we may refuse a request that is not related to the information the law entitles you to, that is excessively repetitive, that conflicts with judicial procedures or an investigation, that would adversely affect our information-security work, or that would affect the privacy of another person. If we refuse, we will say so and say why.

29.7 Rights we cannot exercise for you. Where a Studio is the Controller, we will not erase, correct or export its records on your instruction alone, because we are not entitled to act against the Controller's instructions. This is exactly why clause 5 tells you who your Controller is.

30. Complaints

30.1 Come to us first. Write to the address in clause 3.2, or use the business contact route in clause 3.1. If your Controller is a Studio, tell the Studio too. We would rather fix it.

30.1.1 You get a reference, and you can track it. UAE law requires a published complaints channel with a way of following what happens to a complaint, and a complaint that vanishes into a mailbox is not that. So: every complaint is logged and acknowledged with a unique reference number within 2 business days. Quoting that reference to us — by reply, or at the contact route in clause 3.1 — gets you the current status, who holds it and what happens next, at any time and without charge. We tell you the outcome and the reasons for it in writing. If we cannot resolve it within 30 calendar days we tell you why and give you a revised date.

30.1.2 Complaining does not cost you anything, and it does not cost you your other routes. A complaint to us is free, it does not require you to use any particular form, and it does not suspend, delay or replace anything in clause 30.2, 30.3 or 30.4.

30.2 The regulator. You may complain to the UAE Data Office, the federal authority established to supervise the PDPL. Its complaint route and contact details are the ones that Office publishes, and we reproduce them here once it publishes a standing channel.

30.3 Free-zone regulators. If your Controller is established in the DIFC, you may complain to the DIFC Commissioner of Data Protection. If it is established in ADGM, you may complain to the ADGM Office of Data Protection.

30.4 We do not require you to complain to us first as a condition of going to a regulator.

31. Children

31.1 ABS Twin is not directed to children, and neither abstwin.com nor the Console is intended for use by children.

31.2 A Studio must not use ABS Twin to collect Personal Data directly from a child. Where a Studio holds data about a minor — for example a parent booking a child's appointment — that data is expected to be provided by the accompanying adult.

31.3 Some services in a Studio's catalogue carry a minimum age, which is recorded on the service as a catalogue attribute. It is a record, not a control: the product does not today check a Guest's age against it, and clause 31.4 carries the decision about whether it should. Contrast the health-authority certification check at clause 22.4, which is a control that fails closed — that is what an enforced control looks like in this product, and the age attribute is not one.

31.4 The minimum age is 18. ABS Twin is not offered to, and a Guest record is not to be created for, a person under 18 years of age; the same figure is stated in the Website Terms of Use, clause 1.8 of the Cookie & Tracking Notice and the Staff App Privacy Notice, and one figure is used across the set. Honest limitation: no age gate exists in the product today. The Service does not verify age, and the Assistant does not attempt to determine whether it is speaking to an adult; where the catalogue records a minimum age for a service, enforcing it is the Studio's responsibility (clause 31.3).

31.5 If you believe a child's Personal Data has been provided to a Studio through ABS Twin without the appropriate adult's involvement, tell the Studio and tell us at the address in clause 3.2, and we will assist the Studio to deal with it.

32. Restricted Data, and health-adjacent information

32.1 The rule. ABS Twin is supplied for appointment booking and customer communication for beauty and wellness services. It is not a clinical, diagnostic or medical-records system, and it is not intended for the processing of health data as defined by UAE Federal Law No. 2 of 2019. Studios are contractually prohibited from entering Restricted Data.

32.1.1 And the law behind that rule is not the PDPL. As clause 2.3.1 explains, health personal data subject to Federal Law No. 2 of 2019 is carved out of the PDPL and governed by that separate regime, which prohibits storing, processing, generating or transferring health data outside the United Arab Emirates unless an exception has been granted by the competent health authority — and the published exception categories are narrow, granted case by case, and do not cover software-as-a-service or customer-service processing. The ABS Twin stack is predominantly hosted outside the United Arab Emirates (clause 26). That is why this clause is a prohibition with an enforcement path rather than a disclaimer: for this category of data, a contract term alone does not answer the question, and we do not pretend it does. The open question is at clause 32.5.

32.2 Please do not send it to the Assistant. Do not send clinical records, diagnoses, prescriptions, payment card numbers, or copies of passports or identity documents through a chat or a call. If you send it anyway, it reaches the conversation record, which is not where it belongs — and clause 32.4.5 sets out what we then do about it. We would rather remove it than keep it.

32.3 Where health-adjacent information nonetheless appears. We identify it honestly rather than pretend it does not exist:

32.3.1 clinical flags on a service in the catalogue — whether a service is medical, whether it needs a patch test, its minimum age, and its aftercare notes — which are set by Carnelian and are read-only to a Studio;

32.3.2 a therapist's free-text notes about a visit, and a link to a colour or chemical formula record;

32.3.3 conversation content, where a Guest volunteers an allergy, a pregnancy, a skin or hair condition — this is the largest surface and it is unstructured by nature;

32.3.4 a Digital Twin summary that restates something a Guest volunteered; and

32.3.5 staff health-authority certification data (clause 22), which is health-adjacent because the certification is issued by a health regulator. Staff immigration data — nationality and visa expiry — is also held under clause 22 and is also sensitive, but it is not health-adjacent and we do not describe it as though it were.

32.4 The guardrails, and what we do when they are crossed.

32.4.1 Prevention. The Assistant refuses medical and suitability questions and defers to the Studio's qualified people; a message classified as medical forces a deferral reply; the Digital Twin instruction forbids inferring medical details; and a safety filter layer applies at the settings level.

32.4.2 A prohibition on its own is not enough, and we do not treat it as enough. Clause 10.5 already gives us the right to remove Restricted Data from a support message. The surface described in clause 32.3 is far larger than a support inbox, and the same response belongs here. Clauses 32.4.2A to 32.4.7 state it.

32.4.2A Where the authority to act comes from, because it is not this policy. A privacy notice cannot confer a right, and a Processor may not act against its Controller's instructions — clause 29.7 says exactly that, and it remains true. Each Studio therefore instructs us, in the Master Subscription Agreement and the Restricted / Health Data Addendum, to take the steps in clause 32.4 on discovery of Restricted Data. Those steps are accordingly taken on the Studio's own documented instruction, and not against it. This clause describes that instruction; it does not create it.

32.4.3 What we do on discovery, in order. Where we become aware — whether from a Studio, from a Guest, from an automated check or in the course of supporting the service — that Restricted Data has been entered into or sent through ABS Twin, we take the least intrusive step that answers the risk, and we escalate only if it does not:

32.4.3.1 quarantine before we destroy. The default step is to move the affected content to a restricted store reachable only by the incident team, and to preserve it there — not to delete it. Deletion is the step only where the applicable health-data regime positively requires destruction, or the Studio instructs it. We preserve by default because the content is the Studio's own record and may be its own evidence in a complaint;

32.4.3.2 redact or suppress the affected element in place — a message, a therapist's free-text note, a call transcript or an extract of one, or a Digital Twin field that restates it — where that answers the risk without removing the surrounding record;

32.4.3.3 stop it propagating — excluding the affected text from the Digital Twin, from summaries, from staff alerts and from any onward processing; and

32.4.3.4 decline to process it further, including declining to send it to an AI model or across a border.

32.4.3.5 Preservation overrides all of it. Where we are on notice of a claim, a dispute, an investigation or a regulatory hold touching that content, it is preserved and not destroyed, whatever else in clause 32.4 would otherwise apply.

32.4.4 What we do with a repeated or systemic problem, and what the Studio gets. Where Restricted Data is entered repeatedly, or where the way a Studio has configured or is using ABS Twin causes it to be collected as a matter of course rather than by accident, the steps are graduated: redact or suppress → quarantine → restrict the feature → disable the channel → suspend the affected processing under the Master Subscription Agreement and the Restricted / Health Data Addendum. We give notice and a period to put it right before restricting a feature or disabling a channel, and we take an immediate step only where continuing to process creates a present legal risk — in which case clause 32.4.6 applies as soon as practicable afterwards rather than before. Where we disable a channel or restrict a feature for more than a short period, the fee for that channel or feature is credited pro rata for the period it is unavailable. We do this reluctantly and proportionately, and we do it because continuing to process regulated health data offshore once we know it is there is the thing the law will not forgive — but a restriction with a remedy is a bargain, and one without a remedy is not.

32.4.4.1 Where these rights are actually agreed. The operative rights and their consequences live in the Master Subscription Agreement and the Restricted / Health Data Addendum, which is where a Studio accepts them. This policy describes them so that a Guest can see what happens to something they said; it does not itself grant them.

32.4.5 The same commitment on the voice and transcript path. Voice is not exempt because it is spoken. A call transcript is text the moment it is written, and the removal, suppression and non-propagation steps in clause 32.4.3 apply to a transcript, to its AI-written summary and to anything derived from either, in the same way as to a message.

32.4.6 What we tell the Studio, and when. Where a Studio is the Controller, we tell it before we act, unless continuing to process creates a present legal risk that will not wait — in which case we tell it as soon as practicable afterwards. We tell it: what category of Restricted Data was found and where, when we became aware, what we did or propose to do about it, what remains and where, and what the Studio must do next — including any notification the Studio may owe its Guest or a regulator, which is the Studio's decision to make as Controller. We do not tell it more of the content than it needs to act. Where Carnelian is the Controller (Part A, including the demonstration line), there is no Studio and we simply act.

32.4.7 What this is not. Nothing in clause 32.4 makes Carnelian responsible for detecting Restricted Data, obliges us to inspect conversation content looking for it, or turns the removal right into a promise of removal. Free-text conversation is unstructured by nature and detection is imperfect; we say so at clause 32.3.3. What we commit to is that we do not simply carry on when we know.

32.5 Licensed clinics and medi-spas. Whether a licensed clinic or medi-spa is within the definition of an accepted customer is stated in the next revision of this policy; none is accepted until it is. UAE health-data legislation prohibits storing, processing, generating or transferring health data outside the United Arab Emirates unless an exception has been granted by the competent health authority (clauses 2.3.1.1 and 32.1.1), and the ABS Twin stack is predominantly offshore. If clinics are accepted, a Restricted / Health Data Addendum, a lawful-basis analysis and an architecture answer are all required; a contract clause alone does not solve it.

32.6 A separate medical environment exists elsewhere in the wider ABS ecosystem. ABS Twin never accesses it, never reads from it and never writes to it.

33. Cookies and similar technologies

33.1 abstwin.com sets no cookies. The analytics described in clause 6 use no cookies and no browser storage; persistence is in memory for the duration of the page visit only.

33.2 The Console and the Staff App use session cookies to keep you signed in and to protect your session. Without them you cannot log in. The lawful basis is performance of the contract under which the Authorised User is given access (PDPL Art 4; clause 9.4) — we state a basis rather than rest on the phrase "strictly necessary", which is a category from another regime with no UAE analogue and which does not by itself supply one.

33.3 No advertising or cross-site tracking cookies are used anywhere.

33.4 We do not treat continued browsing as consent to anything that requires consent. Where consent is needed we will ask by a clear affirmative action, log it, and let you withdraw it as easily as you gave it.

33.5 Full detail is in the Cookie & Tracking Notice.

34. What we never do

34.1 Each of the following is true of the system as at the date of this version, and any change to one of them is a material change under clause 35 — which means we tell you before it takes effect rather than quietly editing the list.

34.1.1 We do not sell Personal Data, and we do not license it, rent it or trade it.

34.1.2 We run no advertising networks, use no data brokers and do no cross-site tracking.

34.1.3 We do not use one Studio's data to market or sell to another Studio, and we do not use Guest Data to build products, industry comparisons or sales material. This does not prevent us from operating, securing, supporting and quality-assuring the service, including the daily automated review at clause 17.8, incident handling, and the metering record at clause 16.1 category 8 — which is what clause 15.4 means by "running the service".

34.1.4 We do not enrich a Guest's profile from sources outside the Studio's own records and its own conversations with you — no social media lookups, no purchased datasets, no scraped directories, no data brokers. A Studio's own imported client records (clause 16.1 categories 1 and 12) and a platform-supplied handle such as an Instagram username (clause 21.2) are not external enrichment: the first is the Studio's own client book and the second is how the message reached it.

34.1.5 We do not re-identify data we have anonymised.

34.1.6 We do not use Customer Data or Guest Data to train AI models (clause 24).

34.1.7 We do not combine messaging-platform data across Studios, and we do not use data received through a messaging platform for any purpose beyond running that Studio's own reception — which includes the Digital Twin described at clause 18, on the two bases stated there. We state it that way rather than as a bare denial of profiling, because clause 18 discloses a profile and a negative commitment a reader can falsify from another clause of the same document is worse than no commitment at all.

34.1.8 We publish no certification we do not hold.

34.1.9 We disclose Personal Data to no one outside the five recipient categories in clause 25.0, and we do not hand it to any authority in the absence of lawful compulsion (clause 25.7.3.1), subject to the cooperation the PDPL requires of us with the UAE Data Office (clause 25.7.3.1a).

35. Changes to this policy

35.1 We will keep this policy current. When we change it we will update the version and effective date, publish the new version at the URL above, and keep the previous versions accessible with their effective dates.

35.2 For a material change — one that materially affects how Personal Data is processed or your rights over it — we will give notice before it takes effect: to Studios by email to the registered notice address and in the Console, at least 30 days in advance; and to Guests through the Studio, or through the channel you use to reach the Assistant, where a direct notice is appropriate.

35.3 We will not treat your continued use of the service as acceptance of a material change. Where a change requires consent, we will ask for it afresh.

35.4 We will not silently edit a published version. Every change is recorded in the published version history that accompanies this policy.

35.5 We will review this policy at least annually, and in any event within six months of the issuance of the PDPL Executive Regulations. The engineering controls stated in this policy as being true "as at the date of this version" are re-verified at each review — in particular the analytics build check (clause 6.3), the tenant-scoping and row-level-security controls (clauses 28.3.1 and 28.3.2), the upload checks (clause 28.3.5) and the certification check (clause 22.4).

35.6 Which text is the authoritative one. The version published at https://abstwin.com/legal/privacy, identified by its version number, its effective date and the content hash printed in the footer, is the authoritative text of this policy. Superseded versions remain accessible with their own effective dates. Where a question arises about what this policy said on a particular date, that record answers it.

36. Governing law, forum and language

36.1 Data-protection regime. The UAE Personal Data Protection Law governs the protection of Personal Data described in this policy, together with any other Applicable Data Protection Law that applies to a given processing operation — save for the categories that the PDPL itself places outside its scope, which are identified in clause 2.3.1 and governed by their own legislation. This is stated separately from clause 36.2 on purpose: the choice of a court does not change which data-protection law applies.

36.2 Governing law and forum. This clause has two limbs, because this policy has two audiences.

36.2.1 For a Studio. Any claim by a Studio arising out of or in connection with this policy — however framed, including a non-contractual claim — is governed by, and subject to the forum selected in, the Master Subscription Agreement and the Data Processing Agreement, and to the liability provisions of those agreements (clause 2.2.2). The Master Subscription Agreement selects DIFC law and the DIFC Courts — a selection adopted on 21 August 2026 for the whole studio contract stack. It is made in the specific, clear and express terms Dubai law now requires for such an election, and it extends expressly to non-contractual claims. It does not affect clause 36.2.2, and it does not affect any mandatory right or forum available to an individual who is not a Studio. Nothing in this policy varies that selection or creates a second route around it.

36.2.2 For an individual reader who is not a Studio. This policy is governed by the federal laws of the United Arab Emirates as applied in the Emirate of Dubai, and the courts of Dubai have non-exclusive jurisdiction. This is without prejudice to any mandatory right you have, or any forum available to you, under the law applicable to you — including any right to complain to a data-protection regulator under clause 30.

36.3 Nothing in this policy limits liability that cannot lawfully be limited. No statement in this policy excludes or restricts any liability, right or remedy to the extent that doing so would be contrary to any applicable law.

36.4 Language — the commitment, and the position until it is met. This policy will be published in English and Arabic. UAE consumer protection law requires consumer-facing information to be given in Arabic, the Arabic text is the version most readers in the UAE will rely on, and we treat producing it as an obligation on us rather than an optional courtesy.

36.4.1 Publication precondition. This policy is published in Arabic and English together, and it is not published at all until a legally reviewed Arabic text exists. We do not publish an Arabic version that has not been reviewed by UAE-qualified lawyers, and we do not give precedence to a text that does not exist — so the answer is to prepare the Arabic, not to publish English alone. It reflects that UAE consumer and e-commerce law requires a supplier registered in the State to give consumer-facing information and e-commerce particulars in Arabic, in addition to the original language, with penalties attached — and that information a UAE data subject cannot read has not been given to them for the purposes of the pre-processing notice at clause 2.6.

37. Arabic version

37.1 An Arabic translation of this policy will be prepared, legally reviewed by UAE-qualified lawyers, and published alongside the English text at the same URL. Its publication date will be recorded in the published version history.

37.2 Precedence, once the Arabic exists. From the date on which a legally reviewed Arabic text is published at that URL, and in respect of the period from that date, any conflict or inconsistency between the English and the Arabic texts is resolved in favour of the Arabic text, to the fullest extent permitted by applicable law. Before that date this clause has no operation, because there is no Arabic text — and, as clause 36.4.1 states, before that date this policy is not published either. This differs from the position taken in the Studio contract stack, and the difference is deliberate: the audience for this policy is onshore and partly consists of individuals, the forum in clause 36.2 is an onshore court that works from Arabic, and UAE consumer protection law requires consumer-facing information to be in Arabic.

37.3 The review precondition. An Arabic translation that has not been legally reviewed is never published, and is never published alongside a clause stating that it prevails. This policy is published in neither language until the reviewed Arabic text exists; clause 36.4.1 states the same precondition.

37.4 Guest-facing runtime notices — the AI disclosure the Assistant speaks or sends, and any recording notice if recording is ever enabled — will exist separately in English and Arabic and are set out in the AI & Recording Disclosure. The Arabic runtime notices are drafted for review and have not been legally reviewed; until that review is complete no Arabic runtime notice is spoken, sent, printed on a notice card or published, and that document carries the same gate. Clause 19.5 states the same position.

Privacy Policy · Version 0.9 · Effective date: on publication · Supersedes: version 0.8 Languages: English and Arabic. From the date the reviewed Arabic text is published, the Arabic prevails to the fullest extent applicable law permits (clause 37.2). Publisher: Carnelian Technologies L.L.C-FZ, a Limited Liability Company licensed by Meydan Free Zone — trade licence 2415615.01 — Meydan Grandstand, 6th floor, Meydan Road, Nad Al Sheba, Dubai, U.A.E. Contact: info@contact.abstwin.com (general) · Privacy and data-subject requests: privacy@contact.abstwin.com · Legal notices: legal@contact.abstwin.com · Security: security@contact.abstwin.com Company mailbox, and an alternative route to any of the above: support@carnelian.tech Data Protection Officer: Syed Sharique Ali, Manager of Carnelian Technologies L.L.C-FZ — dpo@contact.abstwin.com Content hash: recorded with each published version, so that the text in force on a given date can be proved.