Privacy Notice — Enhanced Fertility Ltd (EnhancedDx Platform)

Purpose. Enhanced Fertility Ltd's privacy notice for the EnhancedDx platform and the AI-enabled services we deliver on it (the "Services", defined in §1), explaining in plain language the two data-protection capacities we act in — processor for each Client whose Services we operate, and controller for our own limited platform data — and the information Articles 13–14 of the UK GDPR and, for EU deployments, the EU GDPR require. In this notice, "Data Protection Law" means the UK GDPR and the Data Protection Act 2018 and, where applicable to a deployment, the EU GDPR (Regulation (EU) 2016/679) and applicable EEA member-state law. This notice is published in our trust centre and is designed to be read alongside the privacy notice of the Client whose Services you are using. It describes Enhanced Fertility Ltd's standard platform positions and does not itself create contractual obligations; where an executed agreement with a Client states a different position, that agreement prevails between the parties.

Audience. End users of any deployment of the Services (patients, recipients, prospective donors, site visitors) in the UK and, for EU deployments, the EEA; our clients; counsel; regulators.

The essentials

We know a fertility journey is personal and often difficult, and that what you share with these Services can be among the most sensitive information there is. The full detail is below; these are the points that matter most:

• The clinic (or bank) you are dealing with is in charge of your data. We run the platform as its processor, on its instructions; its privacy notice is the primary notice for you (§2).
• Your data is never used to train AI. No conversation, registration, donor or preference data trains or fine-tunes any AI model — ours or anyone else's (§9; our contract with our cloud AI vendor bars it, and only AI providers bound by that restriction are used).
• Nobody routinely reads your chats. There is no routine human review of conversations; targeted, logged access happens only for security incidents, reports or complaints you raise, data-protection requests about your data, and audit (§3).
• The Services are designed so your data is processed and stored in the UK/EEA, mostly in London; limited US vendor support access can occur under approved safeguards (§7).
• You can chat without signing in — but then we usually cannot link the conversation to you afterwards (§3, §8).
• It's an information service, not medical advice — and it makes no automated decisions with legal or similarly significant effects about you (§9).
• No advertising and no selling of your data, ever. The limited browser storage and the one security script we use are described in full in §10.
• Your rights — access, erasure, objection and the rest — are set out in §8, with who to ask.

1. Who we are

This notice is issued by Enhanced Fertility Ltd ("we", "us"), a company registered in England and Wales.

Data Protection Officer. Enhanced Fertility Ltd has appointed a Data Protection Officer. You can contact our DPO at support@enhanceddx.com (mark your message "FAO: Data Protection Officer"). In line with regulatory guidance we publish the DPO's contact details rather than their name; the DPO's identity will be notified to the ICO in accordance with Article 37(7).

We build and operate EnhancedDx, an AI platform for fertility clinics, sperm and egg banks and other fertility-services organisations. In this notice, "the Services" means the EnhancedDx platform services specified in the applicable agreement or order form between us and the Client — the clinic, sperm or egg bank, or other fertility-services organisation named in that agreement or order form — which may include: conversational AI assistants embedded on the Client's website or other channels (such as a Concierge web chat and, where offered, voice interfaces); donor search and matching; end-user registration, lead capture and account management; appointment booking; staff portals and dashboards; the EnhancedDx FHIR Clinical Data Repository (FCDR); analytics and reporting; and such further AI-enabled services as the parties agree in writing.

The Concierge — a client-branded conversational AI assistant carrying the Client's own product name and branding — is the flagship example of the Services, not the limit of them. This notice applies to every deployment of the Services we operate.

EU representative (Article 27 EU GDPR). Where Article 3(2) of the EU GDPR applies to a deployment's processing and Article 27 requires it, Enhanced Fertility Ltd appoints an EU representative for the relevant processing. The position is assessed and recorded per deployment; where a representative is appointed, their details are added to the table above for that deployment.

2. The two capacities we act in

Because the Services are the Client's services running on our platform, we wear two hats — and your rights are routed differently depending on which hat covers the data in question.

The Client is the data controller for end-user personal data processed through the Services; Enhanced Fertility Ltd is its data processor. Enhanced Fertility Ltd acts as a controller only for its own platform telemetry, billing metadata and business contacts.

• As processor (most of your data). Everything you give the Services as a user — your registration details, your messages to a conversational assistant, your donor searches, your bookings, your feedback — is controlled by the Client and processed by us strictly on the Client's documented instructions under a data processing agreement (Article 28 of the UK GDPR or, for EU deployments, of the EU GDPR; see DPA.md). For that data, the Client's own privacy notice is the primary notice for you: it is published on the Client's website and linked from the Services' user interfaces (for example the Concierge chat widget), and it states the purposes, lawful bases and Article 9 conditions that apply. This notice explains Enhanced Fertility Ltd's role so you can see the whole picture in one place. If you send us a rights request about that data (including via the chat itself), we will pass it to the Client without undue delay and assist the Client in answering it — a processor cannot answer it in its own right. Relying on us to retrieve your data does not extend the Client's deadline to respond to you.
• As controller (a small, defined slice). We are the controller only for: (a) platform usage telemetry and billing metadata (§4 below — deliberately content-free); and (b) business contact details of clinic staff and commercial counterparties. Section 4 and this notice govern that slice; sections 3 and 5–7 describe the processor-side flows for transparency.

3. What we process as the Client's processor (plain-language summary)

A full Article 30-grade inventory is maintained internally and is available to the Client and to regulators. What we process depends on which of the Services the Client has enabled. In plain language, on the Client's instructions we process:

• Registration details — name, date of birth, email, optional phone, your chosen clinic and referral source, together with the consent records you give. What's required and what's optional: to register we need your name, date of birth and email (and your 18+ and terms confirmations); phone and referral source are optional, and any treatment-context fields the Client's flow includes are answered at your choice unless the flow marks them required — you can use the informational chat without registering at all. Any password captured at registration is stored write-only; day-to-day sign-in uses emailed one-time codes. Depending on the Client's registration flow, this can include — sensitively — treatment-context fields such as family type, intended treatment type and funding status. Those fields are health-related information; the Client, as controller, is responsible for establishing the Article 9 condition for them.
• Donor application details — name, date of birth, email, optional phone, and your over-18 and terms confirmations.
• Conversation content (where the deployment includes a conversational assistant — a web chat such as the Concierge and, where offered, a voice interface) — every message you send, including from anonymous sessions. The conversation is a free-text box, so you can type anything into it and we cannot prevent what you choose to share. In a fertility context, what you share may be special-category (sensitive) data — for example health conditions and history, fertility and reproductive-health details, pregnancy or pregnancy loss, medications and treatments, genetic or family-medical information, sex life or sexual orientation, or ethnicity and heritage (including as a donor-matching preference). Where you share it, it will be processed to answer you — and often it has to be, so that we can give you the right information, run the donor search you asked for, or point you to the right service. Please share only what you are comfortable sharing; the assistant is designed and instructed not to ask you for medical detail it does not need. If you use the chat without registering, you are choosing to use an informational AI service on that basis — and because you have not signed in or given us your identity, we usually cannot link an anonymous chat to you afterwards (see §8).
• Conversation transcripts — in-account download only. For conversational AI services, you can download the full text of your conversation from within your signed-in session; transcripts are never emailed, so conversation content — which may include health information — does not travel through any email provider.
• Donor search preferences and shortlists (where donor search and matching is enabled) — the search preferences you set and the donors you shortlist. Matching is deterministic and directed by you (§9); your shortlist is held in your browser session (§10). If you choose to save a search, the Services email your saved shortlist to the address you provide — a user-initiated email you request, sent through our EU-endpoint email vendor (§6); this is the one case where shortlist content travels by email, and it never includes your conversation content.
• Appointment bookings (where the Client has enabled the booking flow) — name, email, phone and slot time.
• Feedback — thumbs ratings (no direct identifiers — they are keyed to the conversation, so we treat them as pseudonymous personal data), and NPS scores and safety reports where you may optionally include your email so the Client can follow up. So a person can review it promptly, each safety report is also delivered as a minimised email notification — the category, the reason you typed and a conversation identifier, never any chat content — through our EU-endpoint email vendor (§6, §7) to our monitored operations mailbox, where it is deleted once follow-up closes. Please keep that in mind when writing your reason.
• Verification codes — your email (and phone, if SMS verification is used) and one-time codes, to confirm it is really you.

Safety signposting. The conversational assistant includes safety features intended to show crisis support contacts when a conversation suggests someone may be in distress. That works by the assistant responding to the content of your messages in the conversation itself; it is not a clinical assessment, no record flagging you is created, and no decision about you is taken (§9). The applicable Article 9 condition for this processing is the Client's, as controller, to establish alongside the conditions for the conversation content itself.

A copy of conversations is kept for quality and safety review. Conversation records are exported to an access-restricted analytics store, where automated checks support service-quality and safety monitoring and billing reconciliation. This copy is subject to the same confidentiality rules as the conversation itself (no routine human reading — see "Who can see what you write"), and it is retained for 365 days (12 months) (§5), separately from the live conversation and its de-identified archive.

Conversational AI services are clearly labelled. Every conversational assistant carries a persistent in-widget notice that it is an AI service for informational purposes only and that you should always consult your doctor before making medical decisions, together with a link to the Client's privacy notice. This transparency-by-design disclosure is designed to meet, for deployments targeted at the EEA, Article 50(1) of the EU AI Act (the limited-risk/transparency tier); UK-only deployments apply the same design voluntarily.

Who can see what you write. There is no routine human review of conversations — no one reads your chats to improve the service, train AI or check quality as a matter of course. Humans access conversation content only in targeted, logged cases: investigating a security incident; handling a report or complaint you raise (a person reviews every safety report); executing a data-protection request concerning your data (whether you send it to us or to the Client); and producing audit evidence the Client is entitled to. Authorised staff access to personal data through the staff portals is individually accounted for and recorded (see "Staff access" below).

Your data never trains AI. No conversation, registration, donor or preference data is used to train or fine-tune any machine-learning model — ours or a vendor's. The conversational model is a fixed foundation model; donor matching is deterministic; and our contract with our cloud AI vendor provides that customer data is not used to train its foundation models (§6, §9).

New special-category features are gated. As a platform rule, any feature that would process special-category inputs beyond those described here (for example photograph analysis) is separately DPIA-gated: it must not launch before its own data protection impact assessment is completed and signed off.

Marketing is optional and never bundled. Any marketing consent is asked for separately from the consents needed to use the Services, is entirely optional, and is never a condition of registering or using the Services. You can withdraw it at any time (§8).

Staff access to your contact details. Authorised Client staff and Enhanced Fertility Ltd staff can view registration and donor-application contact details (so the Client can follow up your enquiry) through secured staff portals. Access requires an individual staff account; every access to personal data through those portals is recorded in an audit trail (who viewed what, and when), which also serves as the provenance record for access through those portals if you ever ask who has accessed your data (§8; what we disclose about the individuals who accessed it follows the usual third-party balancing in our DSR procedure).

Where this data lives. By default, personal data processed through the Services is held at rest in the UK (a London cloud region) — registrations, consents and clinical-grade records in the EnhancedDx FHIR Clinical Data Repository (FCDR, our own UK-hosted infrastructure), and feedback, telemetry and audit data in UK datasets. For conversational AI services, live conversations sit in the EU multi-region (which includes London; the conversational platform offers no UK-only region). Section 7 sets out the full residency and transfers position.

For the purposes, lawful bases and Article 9 conditions applying to this data, see the Client's privacy notice; questions and rights requests about it go to the Client (§8).

4. What we process as controller (and why we are allowed to)

Our own controller-side processing is deliberately minimal and content-free:

• Usage metering (telemetry). For conversational AI services, for each chat turn we record: the turn's timestamp, conversation id, turn index, token counts by model, model and tool call counts, tool names, latency and duration, channel and source, and the length of your message in characters — the record being designed and operated to contain no message content. Where you have accepted the measurement identifier (§10), the record also carries two optional analytics dimensions: the pseudonymous identifier itself (used only to approximate unique-user counts) and the donor/recipient audience selection — neither is a billable unit, and both are pseudonymised data that we handle as personal data. Rows are pseudonymous — they carry a conversation id and, where you consented, the pseudonymous identifier, never your name, email or message content — and are stored in a dedicated billing dataset in London. (These rows and the activity events below also appear briefly in a short-lived operational log, deleted within 30 days — see RETENTION_DELETION_POLICY.md.)
• Activity telemetry (service-improvement events). We record deliberately minimal events about how the Services are used: an event type (for example "registration completed" or "chat error"), the audience (donor or recipient journey), the conversation id, a random first-party identifier (§10), a success/failure flag and a short non-personal detail field (a count, a channel name or an error cause). These events contain no names, no email addresses and no message content. They are pseudonymous — we hold no table mapping the random identifier to any person and we never use it to identify you; the rows do carry a conversation id, and where you signed in, a conversation can be linked to your account in the stores we hold as the Client's processor — which is why we treat these records as pseudonymous personal data, not anonymous, and retain and protect them accordingly. They are stored in London and retained for 365 days (12 months).
• Staff-access audit trail. When authorised staff use the staff portals (§3), we record who did what: the staff member's email and role, the action taken (including every view of personal data), the target, the result, the client IP address and a timestamp. The data subjects here are primarily staff; the trail also constitutes a record of access to end-user data. It is held in a dedicated, access-restricted dataset in London and retained for 6 years, because it is our security and accountability record.
• Billing rollups. Aggregated usage figures derived from the telemetry above, used to invoice the Client, retained for 6 years on a financial-records basis. Where payments are processed through the payment provider identified in our sub-processor register, the scope is payment card transactions for orders placed through your clinic's deployment, where your clinic has enabled payments (your card details go to the payment provider directly; we never store card numbers); no payments are taken through the conversational assistant.
• Business contacts. Names, work emails and phone numbers of clinic staff and commercial counterparties, used to run the contract and support the service. We obtain these from you directly, from your organisation, or from professional or public sources (for example your organisation's website or a professional profile); where we have not collected them from you, this notice — referenced in our first communication — provides the Article 14 information.

Lawful bases (Article 6 UK GDPR and, for EU deployments, Article 6 EU GDPR — the analysis is the same under both):

• Legitimate interests — Article 6(1)(f) — for usage metering and activity telemetry as such (the records described above, which exist whether or not you accept the measurement identifier, and carry no identifier unless you have), the staff-access audit trail, business-contact processing and service operation. Short legitimate-interests assessment: our purpose is operating, securing, metering, improving and billing services we are contractually obliged to run — including understanding approximately how many distinct users the Services serve (never who they are) — and keeping an accountable record of staff access to personal data. The processing is necessary because we cannot bill or monitor reliability without per-turn usage records, cannot improve or secure the Services without knowing which steps succeed or fail, and cannot evidence access control without an audit trail — and we have chosen the least-intrusive designs available: metadata only, message length not message content, pseudonymous conversation ids and a random first-party identifier, no names or content in activity events. On balance, the impact on individuals is minimal (no content, no profiling of individuals, no decisions about anyone, data resident in London) and within users' reasonable expectations of how an online service of this kind is run — and within staff members' reasonable expectations of a workplace audit control. You can object (§8).
• Consent — Article 6(1)(a) — for the identifier-keyed slice of the measurement. Where you have accepted the measurement identifier (§10), that consent — the same consent PECR requires before we store it — is our basis for storing the identifier and for the measurement keyed to it: its use in the activity events above and as an optional analytics dimension in the usage-metering records. You can withdraw it at any time (§10); withdrawal stops the identifier being used from that point and has no effect on the Services working.
• Contract — Article 6(1)(b) — for billing metadata and business-contact processing needed to perform our agreement with the Client and to take steps requested by counterparties.
• Legal obligation — Article 6(1)(c) — to the extent billing records and the audit trail must be kept to meet financial-records and accountability obligations; this also underpins their 6-year retention.

You are never under a statutory or contractual obligation to provide us personal data. For business contacts, work contact details are needed to administer the contract with your organisation — without them we cannot run the relationship; the measurement identifier (§10) is entirely optional and declining it has no effect on the Services; telemetry is generated by your use of the Services rather than provided by you. (What is required and what is optional when you register with a Client's deployment is stated in §3.)

5. How long we keep data

The full schedule, justifications and deletion mechanics are in RETENTION_DELETION_POLICY.md. Retention periods must be justified by purpose and reviewed; Data Protection Law sets no fixed periods. The table below states the platform defaults; for processor-side data the Client, as controller, may vary these in its agreement with us, and the Client's privacy notice states the periods that apply to your deployment.

Every period is a maximum: data no longer needed for its purpose is deleted early — the schedule is never a licence to keep data to period end.

Erasure requests are responded to within one calendar month (§8 — the extension and UK clock-pause described there can apply), and erasure is carried out except where a legal retention obligation or exemption applies (for example the 6-year billing and audit records above — Article 17(3)); for data we process for the Client, the decision is the Client's as controller. In-service deletion propagates to vendor systems within contractual maxima, and backups age out on the snapshot cycle described in RETENTION_DELETION_POLICY.md.

6. Who receives your data

• Our sub-processors. The canonical, always-current list of sub-processors we use to deliver the Services — with each vendor's role, region and transfer mechanism — is SUBPROCESSORS.md, which this notice incorporates by reference rather than duplicating. In headline terms they are: our cloud AI and hosting platform provider; our verification and transactional-email vendor; and — where the Client has enabled the relevant feature — a scheduling vendor (appointment booking) and a payment provider (payment card transactions for orders placed through your clinic's deployment, where your clinic has enabled payments (your card details go to the payment provider directly; we never store card numbers)) — each named, with role, region and transfer mechanism, in SUBPROCESSORS.md. The EnhancedDx FHIR Clinical Data Repository (FCDR) is our own infrastructure, not a vendor service. Our cloud AI vendor contractually does not use customer data to train its foundation models.
• The Client's own systems. On the Client's documented instruction, the Services can write into systems that belong to the Client — for example its website CMS, e-commerce platform, EMR or CRM — excluding any marketing export, which requires the further documented instruction below. These are the Client's own processor relationships, not our sub-processors; the Client's privacy notice covers them. In its standard configuration the platform performs no marketing export and the Services write to no third-party marketing platform. Any marketing export a Client requires activates only under the DPA's documented-instruction procedure (specified data elements and purpose, a UK/EEA-resident destination) — and because that would change what this notice describes, §13's duty to surface material changes before the new processing starts applies to it. Marketing consent, where you give it, is recorded in the FCDR; any marketing use is for the Client to carry out under its own notice.
• Others. Professional advisers, insurers and regulators where required; where a business customer's account is referred for debt recovery, the business-contact details needed for that recovery go to a debt-collection agency (end-user personal data is never shared for debt recovery); a purchaser in any restructuring, under confidentiality — any successor takes the data as operator of the Services, subject to this notice and the §13 change process; a restructuring transfer is not a sale of your data. We never sell personal data and never share it for advertising.

7. International transfers

Where your data lives: the UK and the EEA. All personal data processed through the Services at rest is UK/EEA-resident. The default is the UK (London); the exceptions are live conversations and the conversation-transcript export for conversational AI services, which sit in EU multi-regions that include London, because the conversational platform offers no UK-only region. The knowledge base a conversational assistant answers from contains only the Client's approved public content (its published website copy and confirmed published sources) — designed to contain no end-user personal data. Conversation transcripts are download-only from within your signed-in account and are never emailed, so transcript content stays within the UK/EEA conversation store and does not pass to any email provider. Email, SMS-verification and (where enabled) booking traffic is served from the vendors' EU processing endpoints. The full analysis is in DATA_HOSTING_AND_INTERNATIONAL_TRANSFERS.md.

The Services are designed so that personal data is processed and stored in the UK/EEA; day-to-day traffic is served from UK/EEA endpoints. The residual transfer surface — the reason transfer mechanisms appear below at all — is US-vendor contracting and access:

1. Residual US support and telemetry access (our cloud platform vendor). The platform's primary processing is UK/EEA-resident, but the cloud vendor's US parent retains the ability to access data in limited support scenarios. For UK deployments this rests on the UK Extension to the EU-US Data Privacy Framework (the vendor's certification includes the UK Extension), with SCCs/UK Addendum fallback built into the vendor's data processing addendum; for EU deployments, on the EU-US Data Privacy Framework, with EU SCCs fallback in the same addendum. The certified entity is named in SUBPROCESSORS.md.
2. Transactional email and verification codes (our communications vendor — EU endpoints, US-parented entity). One-time codes and transactional confirmations are processed at the vendor's EU endpoints; because the contracting entity is a US company, US access and jurisdiction remain part of the analysis. These flows rest on the vendor's Data Privacy Framework certification including the UK Extension. For the verification service, the vendor's Binding Corporate Rules and SCCs/UK IDTA-Addendum apply as fallback; for the transactional-email service — which the vendor group's Binding Corporate Rules do not cover — the fallback is the SCCs/UK Addendum under the vendor's data processing addendum. The certified entity is named in SUBPROCESSORS.md.
3. Appointment bookings (our scheduling vendor — where enabled). Bookings are processed through the scheduling vendor's EU-hosted endpoint, but the contracting entity (named in SUBPROCESSORS.md) is a US company that is not certified under the Data Privacy Framework. The safeguard relied on is therefore the UK Addendum to the EU SCCs (or the UK IDTA) for UK deployments — and, for EU deployments, the EU SCCs (2021/914) — in each case with a completed transfer risk assessment; executing that safeguard is a standing precondition of the booking flow going live on any deployment.

The dual-track position, stated for both regimes. For UK data subjects and UK deployments: the UK Extension to the EU-US DPF is a UK adequacy route, so no additional safeguard is required while a vendor's certification holds; the fallback mechanisms are the UK Addendum to the EU SCCs or the UK IDTA, with a completed transfer risk assessment. For EU data subjects and EEA deployments: the flow of EEA data into our UK-resident hosting rests on the EU→UK adequacy decisions (renewed 2025-12-19 and running to 2031-12-27) — the primary mechanism for the UK-resident hosting; residual US-vendor access rests on the EU-US Data Privacy Framework, with the EU SCCs (Commission Implementing Decision (EU) 2021/914), modules 2 and 3 according to the capacity in which we hold the data (processor-held data: module 3, processor-to-processor; our own controller-side telemetry: module 2, controller-to-processor) as fallback. As a backstop under both tracks: we monitor DPF certifications at least quarterly, and if a certification lapsed we would continue transfers only under the applicable fallback mechanism with a completed transfer risk assessment, or return/delete the data. The per-vendor position is maintained in SUBPROCESSORS.md and DATA_HOSTING_AND_INTERNATIONAL_TRANSFERS.md. To obtain a copy of the safeguards relied on, contact support@enhanceddx.com.

8. Your rights

You have all the rights Data Protection Law gives you — under the UK GDPR and, for EU deployments, the EU GDPR: access to your data, rectification, erasure, restriction, portability, objection (including to our legitimate-interests processing in §4 — we flag this right specifically), withdrawal of consent at any time where consent is the basis, and rights relating to automated decision-making (§9, where the UK and EU regimes now differ in form, though not — for the Services — in outcome).

Your right to object. Where we process your data on the basis of our legitimate interests (the telemetry, audit and business-contact processing in §4), you can object at any time by writing to support@enhanceddx.com. We will stop unless we can demonstrate compelling legitimate grounds that override your interests, rights and freedoms. If you object to direct marketing (which the Client, not us, would carry out), it stops — no balancing test, no exceptions.

• Who to ask. For anything you did as a user of the Services (registration, conversations, donor searches, bookings, feedback): the Client is the controller — use the contact route in the Client's privacy notice. If you send a request to us instead (including in the chat), we will forward it to the Client without undue delay — our standard is within 2 business days — and help the Client fulfil it; this routing does not extend the Client's deadline. For our controller-side data (§4) or business contacts: write to support@enhanceddx.com. Our full intake and routing procedure is in DSR_SAR_PROCEDURE.md.
• Timing. Requests are answered within one month, extendable by up to two further months for complex or numerous requests (you will be told, with reasons, within the first month). UK GDPR requests only — UK-specific reforms made by the Data (Use and Access) Act 2025 and now in force: if we or the Client reasonably need information to verify your identity or clarify your request, the response clock pauses from the day it is asked for until the day it is received (Article 12A), and searches are conducted on a reasonable and proportionate basis (Article 15(1A)). These UK reforms do not apply to requests under the EU GDPR, which follow the unmodified EU GDPR rules. Under either regime, we reuse existing verification (for example your OTP-verified email) rather than demanding documents by default — but because chat transcripts and registration records can contain health information, the level of checking scales with the harm of a wrong disclosure: where anything suggests the request or the mailbox may not be yours, or a third party asks on your behalf, we require more before any disclosure (the elevated checks in our DSR procedure). No fee applies except for manifestly unfounded or excessive requests.
• Anonymous sessions — an honest limitation. You can chat without signing in. Anonymous conversations are not reliably linkable to a person, so if you ask us to act on an anonymous session we may need additional information from you to locate it (Article 11 UK GDPR / EU GDPR), and a truly anonymous session may be beyond identification altogether.
• Complaints. You may complain to the controller. For UK deployments — a UK-specific duty (section 164A of the Data Protection Act 2018, inserted by the Data (Use and Access) Act 2025, in force since 2026-06-19) — controllers must facilitate data-protection complaints (including an electronic means of complaint), acknowledge within 30 days and respond without undue delay; complaints about the Services reaching us are routed to the Client the same way. You may also complain at any time to a supervisory authority. UK data subjects: the Information Commissioner's Office — online at ico.org.uk/make-a-complaint, by phone on 0303 123 1113, by email to casework@ico.org.uk, or by post to Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF. EEA data subjects: your local or otherwise competent supervisory authority — including in the EEA member state of your habitual residence, your place of work or the place of the alleged infringement.

9. Automated decision-making

The Services make no solely automated decisions that have legal or similarly significant effects on you. Because the UK and EU regimes now differ in form, we state the position under both:

• EU GDPR (EEA deployments). Article 22 of the EU GDPR remains in force. No decision producing legal effects concerning you, or similarly significantly affecting you, is based solely on automated processing through the Services, so Article 22 is not engaged.
• UK GDPR (UK deployments). Article 22 of the UK GDPR was substituted by Articles 22A–22D by the Data (Use and Access) Act 2025, with effect from 2026-02-05. We have re-validated the analysis under the substituted regime, against current ICO guidance, and reach the same conclusion: no significant decision within the meaning of Article 22A is based solely on automated processing, so the restrictions and safeguards in Articles 22A–22D are not engaged.

What the Services actually do: they provide information and a preference-based donor search that you direct — you set the preferences, the Services show you options, in the way a recommendation feature does; regulatory guidance treats such recommendations as typically not producing similarly significant effects. Donor matching is deterministic (preference filters plus text similarity — nothing learns from you), and the results are suggestions you choose among. The Services do not diagnose, triage, treat or predict outcomes; the conversational assistant's instructions prohibit individualised medical, genetic or legal advice; and every consequential decision — donor allocation, treatment, anything clinical — is made by you and the Client's clinical staff, with meaningful human involvement throughout. Rule-based identity checks (the one-time codes) simply apply a rule a human set in advance, which is not treated as a system "decision". Although the ADM provisions are not engaged under either regime, we provide the corresponding safeguards voluntarily: you can always reach a human (ask in the chat or contact the Client, and a person will engage with you), you can contest any output through the in-widget Report mechanism, and you can re-run any search with different preferences. Human oversight of the AI itself — runtime guardrails on every conversation turn, human review of every safety report, evaluation-gated releases with a named human approving every deployment — is described in AI_FUNCTIONALITY_QA.md.

10. Cookies, storage and similar technologies

The end-user-facing Services (the website chat, registration, donor search and booking interfaces) set no cookies and use no third-party analytics, advertising or cross-site tracking technologies (where a deployment enables bot protection, the security storage described at the end of this section is the one qualification). (Signed-in staff portals authenticate staff with a single strictly-necessary, first-party session cookie; that portal is a staff tool, not an end-user interface, and is the only part of the platform that uses a cookie.) For UK deployments, PECR Regulation 6 (as amended by the Data (Use and Access) Act 2025, in force 2026-02-05 — a UK-specific amendment) requires consent for storage/access technologies unless an exception applies; for EU deployments, the same requirement arises under the EEA member-state laws implementing Article 5(3) of the ePrivacy Directive (2002/58/EC). The design described below — strictly necessary session state, plus one consent-gated persistent identifier — is the platform standard on every deployment. What the Services store in your browser falls into two groups, and in line with regulatory transparency expectations we describe everything in full:

Group 1 — session state (strictly necessary). These items are needed for the Services to technically work from your perspective as the user, so they fall within the strictly necessary exception and require no consent:

The Group 1 items are used for no secondary purpose — no analytics, measurement or advertising — which is a condition of the exception.

Group 2 — one first-party measurement identifier (consent-gated). The page can store one persistent item: a random first-party identifier generated in your browser, used as the pseudonymous key for the activity telemetry described in §4 and, on conversational turns, carried as an optional analytics dimension in the usage-metering records described in §4 and §5 — in both cases metadata (which events succeeded or failed, and approximate unique-user counts; never names, emails or message content). It is first-party only: it is never shared with, or readable by, any third party, and we hold no direct mapping from it to you (§4 explains the indirect-linkage position: it is pseudonymous personal data, not anonymous). Because it is not strictly necessary, it is consent-gated (PECR Regulation 6 for UK deployments; the ePrivacy rules above for EU deployments): a short in-widget notice asks you to agree or decline before anything is stored, stating what the identifier is and that we treat it as personal data, with this notice linked, and where you accept, that consent is also our lawful basis for the identifier-keyed measurement (§4). Until you accept, no analytics identifier exists at all — nothing is stored on your device for measurement and no identifier accompanies your chat; if you decline, nothing is ever stored for measurement. Your choice — either way — is recorded in a small local-storage item so we do not ask again. You can withdraw your consent at any time: use the “Privacy choices” link in the widget footer — one click deletes the identifier and your recorded choice and shows the consent notice again so you can decline — or simply clear this site's stored data in your browser, which does the same. Withdrawal stops the identifier being used from that point (it does not affect the lawfulness of measurement already done); events already recorded age out on the §5 schedule (365 days (12 months)), and you can object or ask for erasure at any time (§8). The persistent identifier lasts only until you clear your browser storage; clearing it (or using private browsing, or declining) has no effect on the Services working.

Fonts are served first-party — no third-party font requests. The page's typefaces are self-hosted and served from the Services' own origin. The page makes no request to any third-party font service, so your IP address is not disclosed to a font provider on page load.

Bot protection (where enabled) — the one third-party script. Deployments may enable a third-party bot-protection service on abuse-sensitive actions. Where enabled, your browser loads the bot-protection script from that provider's domain when the page loads, and the provider processes interaction signals (such as your IP address and browser characteristics) to score abuse-sensitive requests — including each message sent to the chat and requests for verification and sign-in codes — to distinguish people from automated abuse: a security measure, used for no advertising or cross-site tracking purpose, operated by our cloud platform vendor (named, with its privacy terms, in our sub-processor register — §6, SUBPROCESSORS.md). We treat this storage and processing as strictly necessary to protect the service from automated abuse of the chat and verification endpoints — a security exemption assessment we record and keep under review. This is the only third-party script the end-user surface loads; the no-third-party statement at the top of this section is otherwise unqualified.

11. Age

The Services are for adults only and are not suitable for anyone under 18. Fertility treatment and donation enquiries are adult services; the Services are intended solely for people aged 18 or over and are not directed at, or suitable for, children. The Client's website and the AI interfaces (chat and any voice) make clear that the service is not for under-18s. We ask for your date of birth at registration and require confirmation that you are 18 or over before an account or a full donor search can be created; we do not knowingly process the data of anyone under 18, and we do not market to under-18s. The anonymous, unregistered chat has no technical age gate — we say so plainly; it is an informational service presented on the same adults-only basis, on an adult subject matter, with no marketing to under-18s; without registration, what is available is general information and preview-level donor search results drawn from the Client's published donor catalogue — accounts and full donor profiles sit behind registration and its date-of-birth check. Our assessment of the likelihood of under-18 access is recorded and kept under review. If you believe someone under 18 has used the Services, contact support@enhanceddx.com: we will investigate and, where the account or data is confirmed (or cannot reasonably be confirmed otherwise) to relate to someone under 18, delete it promptly, coordinating with the Client as controller.

12. How we protect your data — security and breaches

We protect personal data with technical and organisational measures proportionate to its sensitivity, described in full in INFOSEC_POLICY.md. In headline terms: encryption in transit (TLS) and at rest across the platform; UK/EEA data residency (§7); role-based, least-privilege access for staff with individually accountable accounts, passwordless two-factor sign-in to staff portals (subject to a documented enrolment-phase fallback and a documented break-glass exception, both recorded in INFOSEC_POLICY.md) and a complete audit trail of every staff access to personal data (§3, §4); network and application protections (including bot protection, prompt-security and content-safety screening on the conversational surfaces); automated de-identification of conversations after their live window (§5); daily backups with restricted access; and evaluation-gated, human-approved releases of the AI services.

If a personal-data breach occurs, we follow BREACH_RESPONSE_PROCEDURE.md: as processor we notify the affected Client without undue delay (our standard is within 72 hours of becoming aware, with a 48-hour operational target — 24 hours for high-severity incidents), so the Client can meet its own 72-hour duty to the ICO (or its EEA supervisory authority) and, where the breach is likely to result in a high risk to you, tell you directly; for our controller-side data (§4) we assess and, where required, notify the ICO within 72 hours and affected individuals without undue delay.

13. Changes to this notice

We review this notice at least annually and whenever the platform changes. Material changes — in particular any new purpose or new category of recipient — will be brought to your attention before the new processing starts (for example via the chat-entry notice), not merely published here. Earlier versions of this notice are available from support@enhanceddx.com.

Effective date: 12 July 2026