askNiva Privacy Policy

> Notice to Consumers and Data Subjects (POPIA §18 / §55; CPA §49 where relevant). South African law (the Protection of Personal Information Act 4 of 2013, section 18) requires that you be informed, at the time your Personal Information is collected, of the information described in this Privacy Policy. This document is askNiva's §18 notification. Certain provisions are material to how your information is handled and must be specifically drawn to your attention before you provide Personal Information to askNiva. In particular, please read:

> - §6 — the categories of Personal Information askNiva collects and what askNiva does not collect.

> - §8 — the purposes and lawful bases on which askNiva processes Personal Information (POPIA §11 and GDPR Article 6).

> - §9 — the list of Sub-processors (Hetzner, Paystack, Google) and their processing locations.

> - §10 — cross-border transfers and the POPIA §72 / GDPR Chapter V basis for each flow.

> - §11 — retention periods, including the SA tax-law hold of up to five (5) years.

> - §12 — Data Subject rights, including the explicit asymmetry that POPIA does not include a formal data-portability right.

> - §14 — AI-Provider-specific disclosures, in particular the Google Gemini free-tier training warning: if you submit the Personal Information of South African or other non-EEA Data Subjects to your Instance while using a free-tier Gemini API key, Google will use those prompts, Outputs, and files to train its products, will subject them to human review, and will retain them indefinitely. This is almost certainly incompatible with your obligations as a Responsible Party under POPIA §11. Use paid-tier Gemini (AI Studio with billing, or Vertex AI) for any processing of Personal Information.

> - §15 — the Google OAuth Limited Use disclosures, which form part of this Privacy Policy by contract with Google.

> - §19 — askNiva's 72-hour Security Incident notification commitment.

> Your rights as a Data Subject under POPIA, and (where applicable) under the GDPR, the UK GDPR, the Swiss FADP, the CCPA/CPRA, and other privacy laws, cannot be waived by contract. Those rights, and how to exercise them, are set out in §12 and in the jurisdiction-specific addenda (§§23–26).

IMPORTANT — please read carefully. This Privacy Policy (the "Privacy Policy") describes how Mollo Innovations (Pty) Ltd, a company incorporated in the Republic of South Africa with registration number 2026/275132/07, trading as "askNiva" ("askNiva"), processes Personal Information in connection with the Service. The Privacy Policy forms part of the Agreement between you and askNiva — see §3 below for how the Privacy Policy relates to the Terms of Service (the "Terms" or "ToS"), the Acceptable Use Policy (the "AUP"), and the Data Processing Addendum (the "DPA"). By creating an Account, accessing any part of the Service, or submitting Personal Information to askNiva, you confirm that you have read, understood, and received notice of the content of this Privacy Policy.

A note on plain English: this Privacy Policy uses technical and legal language where precision is required, and plain-language "In plain English:" callouts where summarisation is helpful. In this Privacy Policy, "shall" and "will" denote an obligation; "may" denotes a discretion or permission; "must" denotes an absolute requirement; and "should" denotes a recommendation (consistent with RFC 2119 usage). For readability, askNiva uses "we", "us", and "our" interchangeably with "askNiva" only in explanatory passages and plain-English callouts; in operative provisions the defined term "askNiva" governs.

---

1. Who we are

1.1 Controller / Responsible Party. The Responsible Party under POPIA and, where applicable, the controller under the GDPR for Personal Information collected directly by askNiva in connection with the Service is:

Mollo Innovations (Pty) Ltd (trading as "askNiva")

Companies and Intellectual Property Commission (CIPC) registration number: 2026/275132/07

Registered office: Regus Business Centre, 1st Floor, Block B, North Park, Black River Park, 2 Fir Street, Observatory, Cape Town, Western Cape, South Africa, 7925

Principal place of business: same as registered office above

General enquiries: hello@askniva.com

Website: https://askniva.com

1.2 Information Officer (POPIA §55). askNiva's Information Officer, registered with the Information Regulator of South Africa in accordance with POPIA §55 and the Regulator's registration directives, may be contacted as follows:

Email: dpo@askniva.com

Privacy enquiries: privacy@askniva.com

Postal address: Regus Business Centre, 1st Floor, Block B, North Park, Black River Park, 2 Fir Street, Observatory, Cape Town, Western Cape, South Africa, 7925

1.3 EU representative (GDPR Article 27).

(a) Trigger. GDPR Article 27(1) requires a controller or processor not established in the European Union to designate in writing a representative in the Union where the processing is subject to the GDPR by reason of Article 3(2) — that is, where the processing relates to (i) the offering of goods or services (whether or not for payment) to Data Subjects in the Union, or (ii) the monitoring of the behaviour of Data Subjects in the Union, taking place in the Union. Article 27(2)(a) exempts processing which is occasional, does not include processing of special categories of data or criminal-conviction data on a large scale, and is unlikely to result in a risk to the rights and freedoms of natural persons.
(b) Current determination — non-targeting indicators (EDPB Guidelines 3/2018). askNiva is established in the Republic of South Africa. At the date of this Privacy Policy, askNiva does not consider its processing to engage GDPR Article 3(2) in a way that triggers Article 27(1). In support of that determination, and consistent with ToS §2.9, askNiva confirms that:

(i) askNiva offers the Service in English only (also an official language of South Africa) — not in any EU/EEA-Member-State language;
(ii) askNiva denominates Subscription pricing in South African Rand (ZAR) only — not in Euro or any EU/EEA-Member-State currency;
(iii) askNiva operates from the askniva.com domain only — askNiva does not operate any .eu country-code top-level domain or any EU-Member-State country-code top-level domain (.de, .fr, .ie, etc.);
(iv) askNiva does not run paid marketing, paid search, paid social, or other promotional campaigns geographically targeted at recipients located in the EEA;
(v) askNiva does not list any EEA country in any signup country picker, billing-address picker, or marketing form;
(vi) askNiva does not engage in behavioural monitoring (within the meaning of GDPR Article 3(2)(b)) of Data Subjects located in the EEA;
(vii) askNiva does not provide customer service or support in any EU/EEA-Member-State language other than English;
(viii) askNiva offers the Service to Users located in the Republic of South Africa (see ToS §2.9), and Users warrant under ToS §2.10 that they are not predominantly targeting EEA Data Subjects through their Instance.

If any EEA Data Subject interacts with the Service incidentally — for example, because a User has incidentally provided EEA-resident personnel data to its Instance — askNiva considers such processing to fall within the GDPR Article 27(2)(a) carve-out as occasional, low-risk processing that does not include large-scale processing of special-category or criminal-conviction data. askNiva's reliance on this position is documented in the launch-readiness register and is reviewed on each Privacy Policy update cycle.

(c) Commitment. Before askNiva markets the Service to EEA Data Subjects, onboards EEA-established Users on a non-occasional basis, or begins processing that constitutes monitoring of EEA Data Subjects' behaviour within the Union, askNiva will appoint a representative in the Union under Article 27 and will publish the representative's name, address, and contact details in this §1.3. Until that appointment is made, the slot below remains vacant.
(d) Representative details. No representative is currently designated. Pursuant to §1.3(c), upon the trigger event described in that paragraph askNiva will designate a representative in a Member State where EEA-origin Data Subjects whose Personal Information is being processed are located (GDPR Art. 27(3)) and will publish the representative's name, address, and email in this §1.3(d). Until that designation is made, this slot is intentionally reserved. Once designated, Data Subjects and supervisory authorities in the EEA may address the representative in addition to, or instead of, askNiva on all issues relating to processing for the purposes of ensuring compliance with the GDPR (Art. 27(4)).

1.4 UK representative (UK GDPR Article 27).

(a) Trigger. UK GDPR Article 27(1) requires a controller or processor not established in the United Kingdom to designate in writing a representative in the United Kingdom where the processing is subject to the UK GDPR by reason of Article 3(2) (offering of goods or services to Data Subjects in the UK; monitoring of behaviour of Data Subjects in the UK). Article 27(2)(a) applies the same occasional / low-risk carve-out.
(b) Current determination — non-targeting indicators. askNiva is established in the Republic of South Africa and does not consider its processing at the date of this Privacy Policy to trigger UK GDPR Article 27(1). The non-targeting indicators recited in §1.3(b)(i)–(viii) above apply equally to the United Kingdom. In particular: askNiva does not denominate Subscription pricing in Pound Sterling; askNiva does not operate a .uk or .co.uk country-code top-level domain (it operates from askniva.com); askNiva does not run paid marketing campaigns geographically targeted at UK recipients; askNiva does not list the United Kingdom in any signup country picker or billing-address picker; askNiva does not provide customer service in any UK-region-specific manner; and Users warrant under ToS §2.10 that they are not predominantly targeting UK Data Subjects through their Instance. Any incidental UK Data Subject interaction is treated as falling within the UK GDPR Article 27(2)(a) carve-out on the same basis as §1.3(b) above.
(c) Commitment. Before askNiva markets the Service to UK Data Subjects, onboards UK-established Users on a non-occasional basis, or begins processing that constitutes monitoring of UK Data Subjects' behaviour in the UK, askNiva will appoint a representative in the United Kingdom under Article 27 and will publish the representative's name, address, and contact details in this §1.4.
(d) Representative details. No representative is currently designated. Pursuant to §1.4(c), upon the trigger event described in that paragraph askNiva will designate a representative in the United Kingdom and will publish the representative's name, address, and email in this §1.4(d). Until that designation is made, this slot is intentionally reserved.

1.5 Data Protection Officer (GDPR Article 37).

(a) Legal test (Art. 37(1)). A Data Protection Officer must be designated where (i) the processing is carried out by a public authority or body; (ii) the core activities of the controller or processor require regular and systematic monitoring of Data Subjects on a large scale; or (iii) the core activities consist of processing on a large scale of special categories of personal data (Art. 9) or of personal data relating to criminal convictions and offences (Art. 10).
(b) askNiva's determination. askNiva is not a public authority. Its core activity is the provision of managed hosting for openClaw Instances; this activity does not involve regular and systematic monitoring of Data Subjects by askNiva on a large scale. Processing of special-category or criminal-conviction data at Responsible Party / controller level is not askNiva's core activity; where such data appears in Customer Data on a User's Instance, the User is the Responsible Party / controller for that processing (see DPA §§3.1, 3.5(h), 4.2). Accordingly, askNiva has determined that Article 37(1) is not triggered for the current scope of the Service, and has not designated a Data Protection Officer under Article 37(1). This determination is consistent with the Article 29 Working Party Guidelines on Data Protection Officers (WP243 rev.01, endorsed by the European Data Protection Board).
(c) Information Officer (POPIA §55). askNiva's Information Officer (§1.2 above), registered with the Information Regulator of South Africa, performs the data-protection point-of-contact function that an Art. 37 DPO would otherwise perform and is the designated contact for Data Subject enquiries, supervisory-authority communications, and privacy-complaint handling at dpo@askniva.com and privacy@askniva.com.
(d) Re-assessment triggers. askNiva will re-assess the Art. 37(1) determination on the occurrence of any of the following events and, where the re-assessment indicates the test is met, will appoint a Data Protection Officer:
(i) a material expansion of processing to include regular and systematic monitoring of Data Subjects (e.g., first-party profiling features, session analytics at volumes engaging "large scale");
(ii) a material expansion of processing to include, at the askNiva level, special-category or criminal-conviction data on a large scale;
(iii) EEA / UK / Swiss user base or processing scale increasing to the point that a supervisory authority or EDPB guidance would regard the Art. 37(1) test as met notwithstanding the BYOK architecture;
(iv) any change in EDPB / supervisory-authority guidance that would alter the "core activities" / "large scale" / "regular and systematic monitoring" analysis above.
(e) Voluntary designation. askNiva may voluntarily designate a DPO under Art. 37(4) at any time, in which case the full Art. 38 / 39 obligations will apply and the DPO's contact details will be published in this §1.5.

> In plain English: askNiva is the trading name of Mollo Innovations (Pty) Ltd, a South African company. If you have a question about how we handle your data, email privacy@askniva.com. For formal requests (data access, deletion, objection) or complaints, email dpo@askniva.com.

---

2. What this Privacy Policy covers

2.1 Scope. This Privacy Policy applies to the Personal Information that askNiva processes in connection with:

(a) the askNiva website (askniva.com and any successor domain);
(b) registration for, and use of, the Service and any Instance provisioned by askNiva;
(c) communications with askNiva (including support, abuse, legal, and privacy enquiries);
(d) payments to askNiva processed through Paystack;
(e) authentication to the Service through Google OAuth; and
(f) any other interaction with askNiva where Personal Information is processed.

2.2 What this Privacy Policy does not cover. This Privacy Policy does not cover:

(a) Personal Information contained in Customer Data on your Instance that is processed on your instructions as Responsible Party / controller — the DPA (and, at a higher level of abstraction, the Terms and the AUP) governs that processing;
(b) Personal Information collected directly by any AI Provider (Anthropic, OpenAI, Google Gemini, or any other provider whose API key you configure on your Instance) when your Instance routes prompts and data to that AI Provider — your direct relationship with each AI Provider is governed by that provider's own privacy policy (§14);
(c) Personal Information collected directly by Hetzner, Paystack, Google, or any other third party from you through an independent channel (for example, if you visit Hetzner's website separately, if you contact Paystack directly about a chargeback, or if you manage your Google account at myaccount.google.com);
(d) Personal Information collected by any third-party messaging platform, website, SaaS service, or other system with which your Instance or agent integrates; or
(e) the conduct of openClaw, which is third-party open-source software distributed under the MIT License by the openClaw project / openClaw Foundation (ToS §10.2).

> In plain English: This Privacy Policy covers what askNiva does with information about you as an askNiva customer — your login, your billing, your support messages, and your Instance configuration. It does not cover what you choose to do with your Instance once you have it, or what Anthropic / OpenAI / Google / Hetzner / Paystack do with your data under their own privacy policies. The DPA governs Personal Information on your Instance that askNiva processes for you.

---

3. How this Privacy Policy relates to the Terms, AUP, and DPA

3.1 Agreement structure. The Agreement between you and askNiva consists of:

Terms of Service (ToS) — the core commercial and legal terms.
Acceptable Use Policy (AUP) — what you may and may not do with the Service.
Data Processing Addendum (DPA) — askNiva's obligations as Operator (POPIA) / processor (GDPR) when processing Personal Information on your Instance on your instructions.
Privacy Policy (this document) — how askNiva processes Personal Information it collects directly from you (and from sources on your behalf).

3.2 Order of precedence. Where there is a conflict between this Privacy Policy and another part of the Agreement, the order of precedence in ToS §23.2 applies: (i) any signed order form; (ii) the DPA (to the extent it concerns data-protection matters); (iii) the ToS; (iv) the AUP; (v) this Privacy Policy; (vi) any other policy incorporated by reference. (ToS §23.2 as at the date of this Privacy Policy expressly includes this Privacy Policy at position (v); if the ToS is amended, the Privacy Policy's position may shift and askNiva shall update this §3.2 accordingly.) On data-protection matters, the DPA prevails over this Privacy Policy where the two address the same subject (for example, the Operator relationship and sub-processor flow-downs).

3.3 Cross-reference summary. The Privacy Policy works with the other parts of the Agreement as follows:

| Topic | Primary location | Secondary location |

|---|---|---|

| askNiva's role as Responsible Party / controller for account data | This Privacy Policy §5, §6 | ToS §1.3, §9.6 |

| askNiva's role as Operator / processor for Customer Data | DPA §§1–11 | This Privacy Policy §5; ToS §9.6 |

| Sub-processors | This Privacy Policy §9 | DPA §6 |

| Security measures | This Privacy Policy §13 | DPA §7 |

| Breach notification | This Privacy Policy §19 | DPA §9 |

| Cross-border transfers | This Privacy Policy §10 | DPA §12 |

| Data Subject rights | This Privacy Policy §12 | DPA §8 |

| AUP enforcement that may involve Personal Information | AUP §16, §16A | This Privacy Policy §8, §20 |

| Consumer protections | ToS Schedule A | This Privacy Policy §§23–26 |

---

4. Defined terms

4.1 Capitalised terms used but not defined in this Privacy Policy have the meaning given in the ToS §1 (which, to avoid repetition, is incorporated by reference). In this Privacy Policy the following capitalised words, in addition to those defined in the ToS, have the following meanings:

"Account Data" — Personal Information that identifies you or your Account, including your Google OAuth profile (email address, full name, profile picture, Google account identifier), Customer Type declaration, display name, language and locale preferences, consent and acknowledgement records, and the fact of your acceptance of the Agreement.
"Applicable Data Protection Law" — POPIA, the GDPR (where applicable to the processing), the UK GDPR, the Swiss FADP, the CCPA/CPRA (where applicable), and any other data-protection, privacy, or electronic-communications law that applies to the processing described in this Privacy Policy.
"Billing Data" — Personal Information relating to your payment for the Service, including Paystack tokens, transaction references, invoice numbers, amounts, currencies, VAT identifiers, billing address (where requested for invoicing), chargeback metadata, refund records, and tax-related records held for statutory retention. askNiva does not receive or store full card numbers, CVV codes, or full cardholder names in raw form (see §9.3 and §17).
"CCPA/CPRA" — the California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020, and its implementing regulations.
"Communications Data" — Personal Information in support tickets, abuse reports, legal and privacy enquiries, and any other correspondence you have with askNiva, including the content of the message, attachments you choose to include, and metadata (sender, recipient, timestamp, IP, threading).
"Cookies" — small text files or similar technologies that a website or application places on or reads from your device. The term includes local-storage and session-storage entries, pixels, tags, and similar tracking technologies.
"Customer Data" — as defined in the ToS: data that you or any user of your Instance submits to, stores on, or generates through your Instance, including prompts, inputs, Outputs, files, configuration, and any Personal Information of third parties. Personal Information contained in Customer Data is governed primarily by the DPA, not this Privacy Policy.
"Derived Data" — Personal Information askNiva infers or generates about you from other categories, including risk scores, aggregated usage patterns, abuse-detection signals, segmentation labels, and tier-eligibility indicators. askNiva does not use Derived Data for advertising, profiling for third-party marketing, or sale.
"FADP" — the Swiss Federal Act on Data Protection of 25 September 2020.
"GDPR" — Regulation (EU) 2016/679 (the General Data Protection Regulation).
"Google OAuth" — Google LLC's OAuth 2.0 identity-provider service, accessed via the API Services User Data Policy and the scopes openid, email, and profile.
"Information Regulator" — the Information Regulator (South Africa) established under POPIA §39.
"Operational Telemetry" — Personal Information askNiva generates through the operation of the Service and the provisioning and maintenance of your Instance, including access logs, authentication events, API calls to the askNiva control plane, error traces, performance metrics, security alerts, and abuse-detection signals. Operational Telemetry is distinguished from Customer Data (which sits on the Instance and is governed by the DPA) and from Service Logs (which are byproducts of technical operations — see below).
"Personal Information" — has the meaning given in POPIA §1 and, where the GDPR or UK GDPR applies, the meaning of "personal data" in GDPR Article 4(1). References to Personal Information include Personal Information relating to juristic persons where POPIA applies to such information.
"Privacy Centre" — the in-Account privacy dashboard described in §12.8, through which you may exercise certain Data Subject rights, manage cookie and direct-marketing preferences, view the Sub-processor list, revoke Google OAuth, and lodge privacy complaints.
"Security Incident" — any confirmed or reasonably suspected unauthorised access to, or unauthorised destruction, loss, alteration, or disclosure of, Personal Information processed by askNiva, including a "compromise of the integrity or confidentiality of personal information" under POPIA §22 and a "personal data breach" under GDPR Article 4(12).
"Sensitive Personal Information" — (a) in South Africa, Special Personal Information under POPIA §26 (religious or philosophical beliefs, race or ethnic origin, trade-union membership, political persuasion, health or sex life, biometric information, criminal behaviour of a Data Subject); (b) in the EU/UK/Switzerland, special categories of personal data under GDPR Article 9 and FADP Article 5(c); (c) in California, sensitive personal information under CCPA §1798.140(ae); and (d) any analogous category under other Applicable Data Protection Law.
"Service Logs" — technical byproducts of the operation of the Service that may incidentally contain Personal Information, including web-server access logs, audit logs of administrative actions, database query logs relating to askNiva control-plane operations, and log entries generated for security, compliance, or support purposes.
"Sub-processor" — any third party engaged by askNiva to process Personal Information in connection with the Service. The current Sub-processor list is at §9.
"Technical Data" — Personal Information generated by your interaction with the Service, including IP address, user-agent string, browser fingerprint-signal-equivalents limited to user-agent and accept-language headers, device type, operating system, timezone, screen resolution, referrer URL, session identifiers, CSRF tokens, rate-limit counters, login history, and the Hetzner region and data-centre identifier assigned to your Instance.

4.2 Controller / Responsible Party vocabulary. Consistent with the DPA §2:

| Role of party | POPIA term | GDPR term |

|---|---|---|

| You, for Customer Data on your Instance | Responsible Party | Controller |

| askNiva, for Account Data / Billing Data / Technical Data / Communications Data / Derived Data / Operational Telemetry / Service Logs collected directly by askNiva | Responsible Party | Controller |

| askNiva, for Customer Data processed on your instructions | Operator | Processor |

| Hetzner / Paystack / Google (as engaged by askNiva) | Sub-contracted Operator | Sub-processor |

4.3 The Interpretation rules of ToS §1.2 apply to this Privacy Policy.

---

5. askNiva's role — Responsible Party / Controller split

5.1 Two different roles. For clarity, askNiva plays two different data-protection roles in the Service:

(a) Responsible Party / controller for Personal Information that askNiva collects directly about you or the Account (Account Data, Billing Data, Technical Data, Communications Data, Operational Telemetry, Service Logs, and Derived Data). askNiva determines the purpose and means of processing that data. This Privacy Policy is the primary document describing that processing.
(b) Operator / processor for Personal Information in Customer Data on your Instance. Where you submit, store, or generate Personal Information in Customer Data, you determine the purpose and means, and you are the Responsible Party / controller. askNiva acts on your instructions (as documented in the Agreement and in your Instance configuration). The DPA is the primary document describing that processing.

5.2 Role-by-flow table. The tables and discussions in §§6–9 apply the above split to each flow askNiva operates.

|---|---|---|---|

5.3 Independent controller scenarios. Where askNiva determines the purpose and means of any processing for its own compliance purposes (for example, tax retention, FICA screening, fraud prevention, defence of legal claims, or security monitoring), askNiva acts as an independent Responsible Party / controller for that processing. The DPA does not apply; this Privacy Policy does.

> In plain English: Think of askNiva as wearing two hats. Hat 1: for your account, billing, support, and security — askNiva decides how to handle that data and this Privacy Policy explains it. Hat 2: for the prompts and files you run through your Instance — you decide what to do, and askNiva is your tool for processing it. The DPA explains Hat 2; this Privacy Policy explains Hat 1.

---

6. Categories of Personal Information askNiva collects

6.1 Summary table. The categories below are the universe of Personal Information askNiva collects about you. Each is expanded below the table.

|---|---|---|---|---|

6.2 Account Data. When you register using Google OAuth (ToS §4.1), Google sends askNiva the following attributes, tied to the openid, email, and profile scopes:

(a) Email address — used as your primary account identifier, to send service emails (billing, security, breach notices), and for password-equivalent identity verification.
(b) Full name — used to address you in the Service, in invoices, and in communications.
(c) Profile picture — displayed in the control panel as a non-functional visual cue.
(d) Google account identifier (sub) — an opaque, stable identifier Google uses to reference your account. askNiva stores it to re-associate subsequent logins.

In addition, askNiva collects:

(e) Customer Type declaration (Business User or Consumer) — you declare this at signup; askNiva relies on the declaration (ToS §2.3).
(f) Display name (if you change it from the Google-provided name).
(g) Language and locale preferences.
(h) Consent, acknowledgement, and agreement records — timestamps and versions of the ToS, AUP, DPA (where applicable), and this Privacy Policy you have accepted; your cookie-consent choices; your direct-marketing preferences.

What askNiva does NOT collect in Account Data: passwords (Google is the identity provider, so askNiva never sees or stores your Google password); your Google calendar, Gmail, Drive, contacts, or any other Google-user data beyond the three scopes above; biometric identifiers; government identifiers (passport, national ID, tax ID) except where you voluntarily provide them for VAT invoicing or as part of a FICA-triggered enhanced due-diligence request.

6.3 Billing Data. When you start a paid Subscription and make a payment via Paystack (ToS §8.2), askNiva collects:

(a) Paystack payment tokens (tok_xxxx or equivalent) — opaque references that Paystack generates for your payment method and that askNiva uses to trigger recurring charges without seeing the underlying card.
(b) Paystack transaction identifiers — for reconciliation and refunds.
(c) Invoice records — invoice number, line items, amounts, currency, VAT amount, VAT registration number (if applicable), date, status.
(d) Billing address — only if you provide one for VAT/invoicing purposes.
(e) Chargeback and refund metadata — dispute references, status, amounts, outcomes.
(f) Tax-retention records — the subset of invoice data that askNiva is required by the Income Tax Act §29 and the VAT Act §55 to retain for five (5) years after the tax return to which the record relates.

What askNiva does NOT collect in Billing Data: raw card numbers (PANs), full cardholder names in unredacted form, CVV codes, track data, card-issuer BIN ranges beyond what Paystack exposes in transaction metadata, or any other data categorised as "cardholder data" under PCI DSS. Paystack tokenises at its own checkout surface; askNiva receives only tokens (§17). askNiva's PCI DSS scope is accordingly SAQ-A at most.

6.4 Technical Data. askNiva collects the following Technical Data automatically when you interact with the Service:

(a) IP address — for rate limiting, abuse detection, geolocation for VAT/regional-rule determination, and security logging.
(b) User-agent string — for compatibility and security diagnostics.
(c) Accept-language header — for localisation.
(d) Timezone — for display and for scheduling service notifications.
(e) Device and browser identifiers — a limited set (user-agent, screen resolution where voluntarily exposed, browser type and major version) used for compatibility.
(f) Session tokens and CSRF tokens — for authenticated session management.
(g) Rate-limit counters — bucketed per-IP and per-Account counts of API or UI requests.
(h) Login history — successful and failed logins (time, IP, user-agent), used for security alerting.
(i) Hetzner region and data-centre identifier assigned to your Instance — the region you selected at signup (ToS §9.7) is recorded as part of the Instance configuration.

What askNiva does NOT collect in Technical Data: full device fingerprints beyond those fields, advertising identifiers (IDFA/GAID), precise geolocation (GPS), or Bluetooth / Wi-Fi MAC addresses.

6.5 Communications Data. When you contact askNiva (at hello@askniva.com, support@askniva.com, privacy@askniva.com, legal@askniva.com, abuse@askniva.com, security@askniva.com, dpo@askniva.com, or through any other channel askNiva publishes), askNiva collects:

(a) the content of the message, attachments, and any later messages in the thread;
(b) the sender and recipient addresses, timestamps, and thread identifiers;
(c) IP address of the submission where relevant to abuse triage; and
(d) any identifying information you voluntarily provide.

If you paste Personal Information of third parties into a support ticket, askNiva asks you not to — but askNiva cannot technically prevent it. askNiva staff are trained to minimise and, on receipt, to redact such Personal Information from the ticket record where feasible, and to handle any residual Personal Information under the confidentiality and security controls described in §13. This redaction discipline is a POPIA §14 / §19 measure: together with the two-year retention period set out in §11.2 row (e), it is designed to keep the processing of third-party Personal Information in support tickets no longer than is necessary for the support purpose (§8 Purpose 5).

6.6 Operational Telemetry. askNiva generates Operational Telemetry in the normal course of operating the Service. This includes:

(a) askNiva control-plane access logs — which Account accessed which control-plane endpoint, with what result, at what time;
(b) authentication events — login, logout, Google-OAuth token refresh, MFA challenge events if applicable;
(c) API call metadata to AI Providers — call counts, latency, error codes, token-budget utilisation, model identifier, and the fact that a call was made — but not prompt content or Output content (see §6.10 and §14.6);
(d) Instance lifecycle events — provisioning, reprovisioning, suspension, termination;
(e) security and abuse-detection signals — rate-limit hits, anomaly scores, abuse reports, cross-account correlation markers (where permitted by law);
(f) performance metrics — aggregate metrics used to operate and improve the Service.

6.7 Service Logs. askNiva maintains Service Logs as byproducts of technical operation, including:

(a) web-server access logs of askniva.com and of the control panel;
(b) audit logs of administrative actions taken by askNiva personnel on the control plane or against an Instance;
(c) database query logs for control-plane databases (not for the Instance database — that is Customer Data and lives inside the Instance);
(d) firewall and WAF logs; and
(e) logs held to satisfy askNiva's own accountability and compliance obligations.

6.8 Derived Data. askNiva derives limited insights about you from the above categories, including:

(a) risk and abuse scores (probabilistic indicators generated by rule-based or statistical logic; see §8.5 on automated decision-making);
(b) Subscription-tier eligibility and suggested-tier labels;
(c) aggregated usage patterns (sums, averages, percentiles) for capacity planning.

What askNiva does NOT do with Derived Data: askNiva does not sell Derived Data, does not share it with advertisers, does not use it to target third-party advertising, does not combine it with data brokers' datasets, and does not use it as input to any askNiva-owned AI or machine-learning model trained on User data (see also ToS §9.3).

6.9 Customer Data on the Instance. Customer Data — prompts, inputs, Outputs, files, configuration, and any Personal Information of third parties that you or a user of your Instance submits — sits on the Instance (Hetzner-hosted). askNiva acts as Operator / processor for Customer Data on your documented instructions; the DPA is the primary governing document. This Privacy Policy describes Customer Data only to the extent necessary for Data Subjects to understand the broader picture. The storage, encryption, access controls, retention, and deletion of Customer Data are described in DPA §§3, 7, and 10 and, at plain-language level, in §§11 and 13 of this Privacy Policy.

6.10 What askNiva does NOT collect — consolidated negative disclosure. For avoidance of doubt, askNiva does not:

(a) collect, process, or store any Special Personal Information (POPIA §26) or GDPR Article 9 special-category data directly from you except (i) where you voluntarily provide it (for example, if you mention a health condition in a support ticket), or (ii) in the narrow case of criminal-behaviour data incidentally generated by sanctions screening under §8.2 and POPIA §33;
(b) sell Personal Information to any third party, in any sense of "sell" (including the broad definition in CCPA §1798.140(ad));
(c) share Personal Information for cross-context behavioural advertising (within the meaning of CCPA §1798.140(ah));
(d) use Customer Data to train any AI or machine-learning model (ToS §9.3);
(e) use Google-derived Account Data for any purpose other than authentication, Account identification, and the communications purposes described in §8 (§15);
(f) access or view Customer-Data prompt content or Output content on your Instance except where necessary for security, abuse investigation, legal compliance, or a User-initiated support request, and then only under the role-based access controls described in §13;
(g) use or disclose the content of your support tickets for marketing or for any purpose unrelated to the ticket;
(h) profile you for third-party marketing or for any decision affecting you with legal or similarly significant effect in the absence of meaningful human involvement (see §8.5);
(i) engage in "dark patterns" within the meaning of CCPA §1798.140(l) in obtaining consent; or
(j) combine Personal Information you provide with data acquired from data brokers.

---

7. Sources of Personal Information

7.1 askNiva obtains Personal Information from the following sources:

(a) Directly from you — when you register, authenticate, configure your Instance, pay, contact askNiva, or respond to a security or abuse notice.
(b) Via Google OAuth — as described in §6.2 and §15, limited to the three scopes openid email profile.
(c) Via Paystack — Paystack returns the tokens and metadata described in §6.3 and §17 when it processes a payment.
(d) Via server telemetry — the Service itself generates Technical Data, Operational Telemetry, and Service Logs as a byproduct of your interaction with it.
(e) Via Hetzner control-plane metadata — Hetzner reports limited metadata about your Instance (status, region, resource utilisation markers, abuse signals). Hetzner does not share Customer Data with askNiva beyond what is technically necessary for infrastructure operation.
(f) Via third-party abuse reports — if a third party (a complainant, a platform, a regulator, a law-enforcement authority, or an AI Provider) reports conduct relating to your Instance, the report and any Personal Information it contains become Communications Data and Operational Telemetry.
(g) Via publicly available sources — askNiva may, on a targeted basis and only where lawful, check public sources (for example, sanctions lists under §8.2 and ToS §2.4, public company registries for Business User verification, or public abuse databases).

7.2 GDPR Article 14 / POPIA §18 "indirect" collection. Personal Information collected via sources (b), (c), (e), (f), and (g) is collected "indirectly" for GDPR Article 14 and POPIA §18 purposes. The Article 14 / §18 notice content is set out in this Privacy Policy, which is presented to you at first login (in summary form, with a link to the full text) and at any material change (§21).

---

8. Purposes and lawful bases

8.1 Purpose / basis matrix. askNiva processes Personal Information for the following purposes on the following lawful bases. The matrix provides both the POPIA §11 ground and the GDPR Article 6 ground to cover the primary jurisdictions.

|---|---|---|---|---|---|---|

| 6 | Enforcing the ToS and the AUP; investigating suspected abuse; security operations | All categories other than Customer Data content (with limited exceptions — see §13) | §11(1)(f) legitimate interests; §11(1)(c) legal obligation (for mandatory reports) | Art. 6(1)(f); Art. 6(1)(c) | §11.2(f); AUP §§16.8 and 16.9 evidence hold | Object (may be overridden by compelling legitimate interest) |

| 8 | Complying with FICA, the Cybercrimes Act, Films and Publications Act, POPIA, Electoral Act, CPA, tax law, and cooperating with law-enforcement or regulators | All relevant categories | §11(1)(c) legal obligation | Art. 6(1)(c) legal obligation; Art. 6(1)(f) (for defence of claims) | §11.2(h) | Limited during hold |

| 9 | Defending actual or threatened legal claims; asserting askNiva's legal rights; establishing, exercising, or defending rights under the Agreement | All relevant categories | §11(1)(f) legitimate interests | Art. 6(1)(f); Art. 6(1)(c) | Until disposal + statutory limitation period | Object (may be overridden) |

| 11 | Sending product-update and promotional emails ("Direct Marketing") | Account Data | §11(1)(a) consent; §69(3) "existing customer" exception in narrow cases (same or similar products, opportunity to object at each message) | Art. 6(1)(a) consent; Art. 6(1)(f) soft-opt-in where applicable (PECR Reg. 22) | §11.2(j) | Object / withdraw consent at any time |

| 12 | Acting on your instructions as Operator to process Customer Data on the Instance (routing to AI Provider, storing files, running agent tasks) | Customer Data | §20 processing on instructions (POPIA); Art. 28 processor (GDPR) | Art. 28 processor — User is controller | DPA §10 | Via Responsible Party / controller (you); see DPA §8 |

8.2 Sanctions and anti-corruption screening. askNiva screens you against applicable sanctions lists (UN, EU, UK, US OFAC, South African targeted-financial-sanctions lists) to satisfy its obligations under the sanctions and anti-corruption regimes referenced in ToS §§2.4–2.7 (sanctions, anti-corruption representations, source-of-funds) and under the Financial Intelligence Centre Act 38 of 2001 ("FICA") to the extent applicable. The lawful basis is POPIA §11(1)(c) legal obligation and GDPR Article 6(1)(c) / Article 10 (for criminal-offence data in sanctions contexts, where national law authorises the processing). Screening is triggered at signup, at material changes to Account Data, and on a rolling basis.

8.3 Marketing and POPIA §69. askNiva treats transactional emails (billing, security, breach notices, service outages, mandatory legal notices, AUP enforcement) as not constituting direct marketing and sends them regardless of your marketing preferences (you cannot fully opt out and retain an Account). askNiva treats product-update and promotional emails as direct marketing within the meaning of POPIA §69: askNiva will not send them to you except (a) with your express opt-in consent, or (b) to an existing customer in a narrow POPIA §69(3) context (same or similar products, reasonable opportunity to object at initial collection and at each message). You may withdraw marketing consent at any time via the Privacy Centre or the unsubscribe link in every marketing email.

8.4 Legitimate-interest balancing. Where askNiva relies on legitimate interests (POPIA §11(1)(f); GDPR Article 6(1)(f)), askNiva has carried out a balancing test for each purpose and concluded that the processing is necessary, proportionate, and not overridden by your interests, rights, or freedoms. On written request to dpo@askniva.com, askNiva shall provide a summary of the balancing test relevant to your enquiry.

8.5 Automated decision-making (POPIA §71; GDPR Article 22).

(a) askNiva's position. askNiva's position is that, as a general rule, askNiva does not subject Data Subjects to decisions based solely on automated processing (including profiling) that produce legal effects concerning them or similarly significantly affect them within the meaning of POPIA §71(1) or GDPR Article 22(1). Every materially adverse decision described in §§(c)(i)–(v) below is reviewed or reviewable by a qualified askNiva staff member before it becomes final. Where the statutory threshold is nonetheless arguably crossed (for example, because automated enforcement is time-critical and precedes human review), askNiva relies on the §71(2) / Article 22(2) gateways — processing necessary for entering into or performing a contract (POPIA §71(2)(a); Article 22(2)(a)), processing authorised by law with suitable safeguards (POPIA §71(2)(b); Article 22(2)(b)), or explicit consent (Article 22(2)(c)) — and provides the safeguards set out in §(d) below.

(b) "Legal or similarly significant effect" — threshold analysis. A decision has a "legal effect" if it affects a Data Subject's legal status, rights, or obligations under a contract or under law. A decision has a "similarly significant effect" if it materially affects the Data Subject's circumstances, behaviour, or choices in a comparable way — for example, denial of a service, significant pricing effects, or effective exclusion from a market. askNiva applies this threshold conservatively, treating borderline automated outcomes as falling within §71 / Article 22 wherever reasonable doubt exists.

(c) Automated processes askNiva operates and their classification. The table below identifies every automated process in the Service that might engage the POPIA §71 / GDPR Article 22 threshold, askNiva's classification of each, and the lawful basis or safeguard relied on.

|---|---|---|---|---|---|

| (i) | Sign-up / first-payment fraud screening (rule-based and statistical risk-scoring on Billing Data, Technical Data, and sanctions-list inputs under §8.2) | Registration submitted; first Paystack charge attempted | Registration or payment may be declined, flagged for manual review, or allowed | Not solely automated. A decline routes to a human-review queue on request under §(d); no automated final refusal without the right to request human re-review. Where a rejection is issued without prior human review, askNiva relies on Article 22(2)(a) (necessary to enter into a contract) and POPIA §71(2)(a). | Contract-performance necessity; §(d) safeguards |

| (ii) | Paystack-side fraud / chargeback scoring (operated by Paystack; askNiva receives only the outcome signal) | Transaction submitted to Paystack | Paystack may decline, flag, or accept the transaction | askNiva does not operate this processing; Paystack is an independent Responsible Party / controller for it. askNiva's downstream use of the outcome flag is reviewed by a human before any Account-level consequence | Legitimate interest (fraud prevention); Paystack's own safeguards |

| (iii) | Rate-limit enforcement (per-IP, per-Account request throttling) | Requests exceed bucketed thresholds | Specific API or UI requests are refused with a 429-class response; no Account suspension | Not within §71 / Article 22. A transient throttle is a technical quality-of-service measure, not a decision about the Data Subject of the kind contemplated by Article 22. No legal effect; no similarly significant effect | Legitimate interest (service availability) |

| (iv) | Account-security lockout (automatic lockout after repeated failed-login attempts, suspicious-device heuristics, or known-compromised-credential signals) | Failed-login threshold crossed; anomaly heuristic fires | Login is temporarily blocked; the Account-holder receives a security notice and a self-service unlock / recovery path | Not solely automated in effect. A lockout is reversible by the Data Subject through self-service verification (recovery email, re-authentication) or human-assisted recovery on request. Where self-service is unavailable (for example, compromise-driven hard lockout), human review is available on request under §(d) | Legitimate interest (Account security); §(d) safeguards |

| (v) | Abuse-detection auto-suspension of an Instance (rule-based triggers on AUP §5.1 CSAM hash-matches; egress anomaly scoring; automated Hetzner abuse-cascade under ToS §13) | Confirmed CSAM hash match; confirmed severe AUP breach; Hetzner null-route or abuse notice | Instance may be automatically suspended, throttled, or null-routed pending investigation | Arguably within §71 / Article 22 for the User (whose contract performance is materially affected). askNiva treats it as within the threshold and relies on §71(2)(b) / Article 22(2)(b) — processing authorised by law with suitable safeguards — for CSAM-driven suspension (mandatory reporting under the Films and Publications Act and international CSAM frameworks) and on §71(2)(a) / Article 22(2)(a) — contract-performance necessity — for other auto-suspensions. Human confirmation is obtained before any final termination decision (AUP §16) | Legal obligation (CSAM); contract-performance necessity (other cases); §(d) safeguards |

| (vi) | Spam / CSAM hash-matching (hash-compare against published CSAM and known-spam hash databases) | Content ingress / egress through a monitored vector | Match triggers preservation, access-restriction, and mandatory reporting under AUP §5.1 | Within §71 / Article 22 for the User to the extent auto-suspension follows; but the hash-matching itself is a detection mechanism, not a decision. The downstream suspension is classified under (v) above | Legal obligation (mandatory CSAM preservation and reporting); §(d) safeguards |

| (vii) | Risk and tier-eligibility scoring (Derived Data under §6.8) | Ongoing aggregation of Operational Telemetry | Internal signal used to route support tickets, suggest tiers, and flag accounts for human review | Not within §71 / Article 22. Scores are internal signals and do not produce any outward decision without human intervention | Legitimate interest (service operation) |

(d) Article 22(3) / §71(3) safeguards. Where a decision falls within §71 / Article 22 (cases (i) and (v) above, and any future process askNiva adds under this heading), askNiva implements the following safeguards:

(A) Right to obtain human intervention. You may request human review of any automated decision affecting you by writing to dpo@askniva.com with the subject line "Article 22 / §71 review". askNiva shall assign a qualified staff member who was not involved in the automated decision to re-review the matter on a fresh record. For CSAM-driven suspensions, human review is confined to whether the hash-match was correct and whether mandatory-reporting obligations were properly applied; a confirmed CSAM match is not reversible.
(B) Right to express your point of view. You may submit written representations — including contextual information, corrective evidence, or explanations of unusual behaviour — which askNiva shall take into account in the re-review.
(C) Right to contest. You may contest the decision by lodging a complaint with the Information Officer under §12.9, or with a supervisory authority under §12.9(a)–(f).
(D) Meaningful information about the logic. On written request, askNiva shall provide, at a general level of description, information about the logic involved in the automated process (the categories of input data, the nature of the rules or statistical model, and the significance and envisaged consequences of the processing for you), subject to protection of trade secrets and to preventing circumvention of anti-abuse controls.
(E) Minimisation and accuracy review. Inputs used in automated processes are periodically reviewed for accuracy and relevance; askNiva shall correct material inaccuracies in Account Data on which automated decisions have been based.

(e) No special-category-data-driven decisions. askNiva does not make any automated decision within §71 / Article 22 on the basis of Special Personal Information (POPIA §26) or Article 9 special-category data in the absence of the conditions in Article 22(4).

(f) No third-party profiling. askNiva does not share Derived Data or automated-decision outputs with any third party for the purpose of third-party profiling or targeted advertising (§6.10(b)–(c), §6.10(h)).

(g) Classification posture (borderline items). askNiva's current classifications of automated decisions that operate at the boundary of Art. 22(2) are: (i) the Hetzner abuse-cascade null-route (table row (v)) is treated as "contract-performance necessity" under Art. 22(2)(a) / POPIA §71(2)(a), because the null-route operates to discharge askNiva's upstream contractual obligations to Hetzner on which provision of the Service to you depends; and (ii) the sign-up fraud screen (row (i)) currently operates on a pull (on-request) human-review model under §8.5(d)(A). askNiva re-assesses both classifications on each Privacy Policy update cycle (§22); a push (positive-offer) human-review model for row (i) is a candidate change on the roadmap and will be reflected here when implemented.

---

9. Sub-processors

9.1 General authorisation. In accordance with DPA §6.1, you give askNiva general written authorisation to engage Sub-processors for the processing of Personal Information, subject to the notice and objection mechanism in DPA §6.3.

9.2 Current Sub-processor list. At the date of this Privacy Policy, askNiva uses the following Sub-processors. An up-to-date machine-maintained list is published at https://askniva.com/legal/sub-processors (or such other URL as askNiva may publish in §27).

|---|---|---|---|---|---|---|---|

| Hetzner Online GmbH | Hosting of your Instance, storage, networking; askNiva's own production infrastructure | Customer Data; Technical Data; Operational Telemetry; Service Logs | Germany (Nuremberg, Falkenstein) or Finland (Helsinki) by default; US (Ashburn, Hillsboro) or Singapore only if you opt in | Hetzner's own sub-processors (iDenfy LT, Computop DE, Google US, Matomo DE) per https://www.hetzner.com/AV/subunternehmer.pdf | §72(1)(b) contractual safeguards (Hetzner DPA, Article 28 obligations) | SCCs (Module 3) for non-EU regions; intra-EEA for DE/FI default | data-protection@hetzner.com |

| Paystack Payments Limited | Subscription-fee processing; tokenisation; chargeback management | Billing Data (tokens, transactions); minimal Account Data (name, email for invoicing) | Nigeria (headquarters and primary payment rails) | As directed by Paystack's card-network routing (typically Ireland / US for global card networks) | §72(1)(b) contractual safeguards (Paystack DPA; PCI DSS Level 1 Service Provider) | SCCs where applicable to EEA data; DPF-reliance only where Paystack's partner network is DPF-certified | dpo@paystack.com |

| Google LLC — OAuth / Identity | Identity provider (Google OAuth) for account authentication under the API Services User Data Policy | Account Data (email, name, picture, Google sub identifier) | United States | Google's global infrastructure | §72(1)(b) contractual safeguards (Google Cloud / Google API Services User Data Policy; EU-US Data Privacy Framework where applicable) | SCCs and/or EU-US Data Privacy Framework (Google LLC is DPF-certified) | https://support.google.com/accounts and https://policies.google.com |

9.3 Sub-processors that may be added. Additional operational Sub-processors may be engaged at or after launch (email delivery, monitoring, CDN, DNS, analytics, support tool, customer-communication platform). Before any such Sub-processor processes Personal Information on askNiva's behalf, it is added to §9.2 above with all eight columns populated; executed DPA and (where applicable) SCCs / UK Addendum / Swiss addendum are recorded in the Operator-Contract Register maintained under DPA §6.5; and askNiva issues the thirty (30) days' prior notice required by DPA §6.3. Rows are not added speculatively — no Sub-processor appears in §9.2 until the relevant contract is executed and processing is imminent.

9.4 Advance notice and objection (DPA §6.3). askNiva shall give you at least thirty (30) days' prior notice of any new Sub-processor or any change of Sub-processor, by email or in-product notification. You may object to the new Sub-processor on reasonable data-protection grounds by written notice to dpo@askniva.com within the notice period. If the parties cannot resolve the objection in good faith, you may terminate the affected Subscription for convenience under ToS §13.4.

9.5 Upstream services you contract directly with (NOT Sub-processors). The following third parties are not Sub-processors of askNiva, because you — not askNiva — contract directly with them:

| Third party | Role | Your direct contract |

|---|---|---|

| Anthropic PBC | AI Provider for Claude API | Anthropic Commercial Terms of Service; Usage Policy; Anthropic Privacy Policy; https://privacy.anthropic.com |

| OpenAI, OpenAI LLC, OpenAI Ireland Ltd (as applicable to your account) | AI Provider for OpenAI API | OpenAI Services Agreement; Service Terms; Usage Policies; OpenAI Privacy Policy; dsar@openai.com |

| Google LLC (AI Studio / Vertex AI / Gemini API) | AI Provider for Gemini models | Gemini API Additional Terms; Google APIs Terms of Service; Google Cloud Terms; Generative AI Prohibited Use Policy; Google Privacy Policy |

| Any other AI Provider you configure | AI inference | The provider's own terms and privacy policy |

When your Instance routes a prompt to an AI Provider, the prompt travels directly from the Instance's Hetzner IP address to the AI Provider's servers over TLS 1.2 or higher. askNiva does not act as reseller, sub-processor, or intermediary for inference traffic (see §14.6). askNiva cannot exercise any Data Subject right on your behalf against any AI Provider, and askNiva cannot warrant that an AI Provider will honour any request (§14).

9.6 Sub-sub-processors of Sub-processors. Each Sub-processor may engage its own sub-processors (sub-sub-processors of askNiva). Hetzner's sub-processors are published at https://www.hetzner.com/AV/subunternehmer.pdf (at the date of this Privacy Policy: iDenfy LT, Computop DE, Google US, Matomo DE). Paystack's and Google's sub-processor positions are published on their respective websites. askNiva is not the primary publisher of those lists; Data Subjects who wish to trace the full processing chain should consult each Sub-processor's list directly.

> In plain English: To run askNiva we need three outside companies — Hetzner (hosting in Germany/Finland by default), Paystack (payments), and Google (login). Your prompts and files go straight from your Instance to whichever AI company you chose (Anthropic, OpenAI, Google Gemini) — askNiva doesn't sit in the middle of that. That AI company is your provider, not ours, and you have to read their privacy policy.

---

10. Cross-border transfers

10.1 Why this section matters. Personal Information held by askNiva is, depending on the data flow, stored or processed in South Africa, Germany, Finland, Nigeria, Ireland, the United Kingdom, the United States, and — if you opt in — the United States (Ashburn/Hillsboro) or Singapore. Under POPIA §72 and GDPR Chapter V, each cross-border transfer must rest on a lawful basis.

10.2 POPIA §72. POPIA §72(1)(b) permits cross-border transfers where the Operator or Responsible Party in the third country is subject to a law, binding corporate rules, or contractual provisions that provide "a level of protection that effectively upholds principles for reasonable processing of the information that are substantially similar to the conditions for the lawful processing of personal information". askNiva relies on §72(1)(b) for every transfer of Personal Information out of South Africa, on the basis of the contractual safeguards described in each row of §9.2 and of the Hetzner / Paystack / Google DPAs.

10.3 GDPR Chapter V. Where the GDPR applies (for example, because a Data Subject is in the EEA at the time of processing, or because processing targets EEA Data Subjects), askNiva relies on the following transfer mechanisms:

(a) European Commission's Standard Contractual Clauses (SCCs) — Module 2 (controller-to-processor) and Module 3 (processor-to-sub-processor), incorporated by reference or signed as a schedule to the relevant DPA.
(b) EU-US Data Privacy Framework (DPF) — for transfers to DPF-certified US entities. At the date of this Privacy Policy, Google LLC is DPF-certified; askNiva's reliance on DPF for other US-based Sub-processors is contingent on their certification status at the time of transfer.
(c) Article 49 derogations — in rare cases (for example, transfer strictly necessary for the performance of your contract, or with your explicit consent after being informed of the risks), where SCCs or DPF are unavailable.

10.4 UK GDPR and Swiss FADP — conditional transfer mechanisms.

(a) UK. Where Personal Information is transferred from the United Kingdom in circumstances engaging UK GDPR Article 44, askNiva relies on the UK Addendum to the EU Standard Contractual Clauses published by the Information Commissioner's Office on 21 March 2022 (B.1.0, in force from 21 March 2022), incorporated into the DPA by reference under §12.3A of the DPA, or on the UK International Data Transfer Agreement (IDTA) where an EU SCC set is not in place with the Sub-processor.
(b) Switzerland. Where Personal Information is transferred from Switzerland in circumstances engaging the Swiss FADP, askNiva relies on the EU SCCs as incorporated under §12.3 of the DPA, with the Swiss amendments described in §12.3B of the DPA (FDPIC-accepted variant), or on the Swiss-US Data Privacy Framework where the transferee is a DPF-certified US entity.
(c) Execution status. The UK Addendum / IDTA and the Swiss amendments are incorporated by reference in the DPA and take effect on a per-Sub-processor basis as each Sub-processor contract is brought into compliance with those instruments. For any Sub-processor not yet under an executed UK Addendum / IDTA / Swiss addendum, askNiva will not process UK or Swiss Data Subject Personal Information through that Sub-processor until execution is complete. Execution status is recorded in the Operator-Contract Register (DPA §6.5).

10.5 Schrems II acknowledgment. askNiva acknowledges the Court of Justice of the European Union judgment in Schrems II (Case C-311/18). Where Personal Information is transferred to a third country, askNiva — together with the relevant Sub-processor — has considered the practical effectiveness of the transfer mechanism in the light of the third-country law (including US FISA §702 and Executive Order 12333 for US transfers), and has applied supplementary measures where appropriate (encryption in transit, encryption at rest, role-based access controls, contractual audit and objection rights). You may request a summary of the transfer-impact assessment for a specific Sub-processor by writing to dpo@askniva.com.

10.6 CLOUD Act and non-EU Hetzner regions. If you select Hetzner Ashburn / Hillsboro (US) or Singapore at signup, your Customer Data and the relevant Technical Data become subject to the US CLOUD Act (for US regions) or the Singapore Personal Data Protection Act and associated authorities (for Singapore). The deployment UI warns you at the point of selection; by selecting a non-EU region you acknowledge the additional risk. EU-default regions (Nuremberg / Falkenstein DE, Helsinki FI) are not subject to the CLOUD Act.

10.7 Hetzner transfer chain (data-protection angle). The Hetzner DPA is executed electronically through Hetzner's account portal and is not automatic (Hetzner T&C §6.2). askNiva shall execute the Hetzner Art. 28 GDPR AVV via Hetzner Robot before the Effective Date of this Privacy Policy and record the execution date in the Operator-Contract Register under DPA §6.5 (see the launch-readiness register for the pre-Effective-Date action list). Hetzner Online GmbH is bound by BDSG §7 written-confidentiality obligations on its personnel and by the 72-hour Article 33 cascade described in §19.

---

11. Retention

11.1 Principle. askNiva retains Personal Information only for as long as is necessary to fulfil the purposes for which it is processed (§8), subject to (a) mandatory retention periods imposed by law, (b) backup-cycle lag, and (c) evidence-preservation and legal-hold obligations (AUP §§16.8 and 16.9 and ToS §13.7). The per-category retention periods are set out in §11.2.

11.2 Retention schedule.

|---|---|---|---|

| (a) Account Data | Duration of Account | Thirty (30) days in deletion queue after termination; Hetzner backup-cycle propagation up to thirty (30) additional days | Records of acceptance of the Agreement (version + timestamp + Account ID) retained for up to five (5) years after termination for contract-enforcement defence |

| (b) Instance configuration (as part of Customer Data) | Duration of Subscription | Fourteen (14) days per ToS §13.5(c) (or shorter for for-cause termination); plus Hetzner backup cycle up to thirty (30) additional days | Overridden by legal hold under AUP §§16.8 and 16.9 / ToS §13.7 |

| (c) Customer Data (prompts, Outputs, files on Instance) | Controlled by you via the Instance | Fourteen (14) days grace per ToS §13.5(c); Hetzner backup cycle up to thirty (30) additional days | Overridden by legal hold; see DPA §10 |

| (d) Billing Data (invoices, tax-relevant records) | Duration of Account | — | Five (5) years after the end of the tax period to which the record relates (Income Tax Act §29; VAT Act §55); Hetzner may retain its own sub-processor records longer under German HGB §257 (fourteen (14) years) — askNiva cannot shorten that |

| (e) Communications Data (support tickets, abuse reports) | Two (2) years from closure of the ticket (POPIA §14(1)(b) — lawful purpose related to §8 Purpose 5 customer support and, for abuse reports, §8 Purpose 6 enforcement; staff minimise and redact third-party Personal Information on receipt under §6.5) | — | Overridden by legal hold (§11.3), AUP §§16.8 and 16.9 evidence preservation, or litigation preservation (§8 Purpose 9) |

| (f) Operational Telemetry; Service Logs | Ninety (90) days for most logs; up to twelve (12) months for security-relevant logs (login history, abuse signals, WAF) | Log retention continues on its own schedule independent of Account lifecycle | Overridden by legal hold |

| (i) Cookie-consent records | Two (2) years from collection or last update, whichever is later | — | — |

| (j) Marketing-consent and opt-out records | Until opt-out plus six (6) years (defence against future "you emailed me after I opted out" claim) | — | — |

11.3 Evidence preservation and legal hold. AUP §§16.8 (public-authority and askNiva-party limbs) and 16.9 (upstream-supplier limb), together with ToS §13.7, entitle askNiva to preserve logs, snapshots, agent traces, configuration, Customer Data, and metadata beyond the deletion deadlines in §11.2 for the purposes stated in those clauses. Preserved material is retained under the security and confidentiality controls of §13 and disclosed only as permitted or required by law. The preservation right is subject to POPIA §14 (purpose-limitation) and §15 (further processing compatibility) and to the GDPR storage-limitation principle; askNiva's assessment is that evidence preservation is compatible with the original purposes on the following bases: (a) for law-enforcement, regulatory, and court-process limbs, under POPIA §15(3)(c) (enforcement of a law / compliance with an obligation imposed by law); (b) for function-related defence and own-proceedings limbs, under the POPIA §15(2) compatibility balance read with §14(1)(b); (c) for upstream-supplier requests (AUP §16.9), under the same §15(2) compatibility balance read with §14(1)(b). GDPR Article 6(1)(c) and 6(1)(f) are the parallel bases where GDPR applies.

11.4 Deletion mechanics. On the expiry of the applicable retention period (subject to legal hold), askNiva deletes Personal Information, or renders it anonymous such that it can no longer be associated with any Data Subject, through a documented deletion procedure. Deletion from backups occurs on the routine backup rotation cycle (up to thirty (30) days). DPA §10 governs deletion of Customer Data.

11.5 Anonymisation as an alternative to deletion. For aggregated analytics (§8 purpose 10), askNiva retains data only in a form that cannot be associated with any identifiable individual. Aggregated anonymous data is not Personal Information and is not subject to the retention schedule.

---

12. Data Subject rights

12.1 Rights overview. Subject to the conditions of the relevant law, you — as a Data Subject — have the rights set out in this §12. The rights available to you depend on the law that applies to the processing. The jurisdiction-specific addenda (§§23–26) augment this §12 for POPIA, GDPR / UK GDPR / FADP, CCPA/CPRA, and other US state privacy laws.

12.2 Rights table.

|---|---|---|---|---|

| Access (know what askNiva holds) | §23(1)(a)–(b) | Art. 15 | §1798.100, §1798.110 | §12.5 |

| Correction / rectification | §24(1)(a) | Art. 16 | §1798.106 | §12.5 |

| Deletion / erasure | §24(1)(b) (where permitted) | Art. 17 | §1798.105 | §12.5 |

| Objection | §11(3) (general); §69(3)(c) (direct marketing) | Art. 21 | Closest CCPA analogues: §1798.120 opt-out of sale/share (no-op — askNiva does not sell or share) and §1798.121 limit use of sensitive PI (no-op — no qualifying use) | §12.5 |

| Portability | No formal portability right — askNiva offers courtesy export under §12.3 | Art. 20 | Right to receive specific pieces of PI in a readily useable format (§1798.130(a)(3)(B)(iii)) — satisfied by the courtesy export (§12.3) | §12.5 |

| Withdraw consent | §11(1)(a), §11(2)(b), §72(1)(c) | Art. 7(3) | Where consent is the basis | §12.5 |

| Not to be subject to automated decision-making with legal or similarly significant effect | §71 | Art. 22 | CPRA automated decision-making technology ("ADMT") regulations pending under §1798.185(a)(16) | §8.5 and §12.5 |

| Non-discrimination for exercising rights | Implicit | Art. 21(1) | §1798.125 | §12.10 |

12.3 Portability asymmetry (POPIA vs. GDPR). POPIA does not include a formal data-portability right equivalent to GDPR Article 20. As a courtesy, and independent of any statutory obligation, askNiva shall make available — on request through the Privacy Centre or to dpo@askniva.com — an export of Account Data, Billing Data (excluding tax-retention records still under mandatory hold), Communications Data, and Operational Telemetry in a structured, commonly used, machine-readable format (CSV and/or JSON). The courtesy export does not extend to Derived Data, Service Logs, or material on legal hold.

12.4 Rights in respect of Customer Data on the Instance. Data Subject rights against Customer Data on your Instance are exercised against you — the Responsible Party / controller for Customer Data — not against askNiva. DPA §8 describes askNiva's obligation to assist you with such requests. If a Data Subject contacts askNiva directly about Customer Data on your Instance, askNiva shall, where lawful, forward the request to you without undue delay and shall not act on the request except on your instruction or as required by law (DPA §8.2).

12.5 How to exercise rights. To exercise any right in §12.2 in respect of Personal Information for which askNiva is Responsible Party / controller:

(a) Preferred route — Privacy Centre. Log in to your Account and use the Privacy Centre (§12.8) to submit the request.
(b) Email. Write to dpo@askniva.com with the subject line "Data Subject Request" and the specific right you wish to exercise.
(c) Postal mail. Write to the Information Officer at the postal address published in §1.2 above.
(d) POPIA Form 2. You may use the Information Regulator's Form 2 for POPIA §23 access requests; it is available at https://inforegulator.org.za.

12.6 Identity verification. To protect your information and prevent unauthorised requests, askNiva shall verify your identity before acting on a request. The verification method depends on the nature of the request and the risk to you:

(a) for Account-holders, logging in via Google OAuth with the Account email is the primary verification method;
(b) for requests from a non-Account-holder, or a former Account-holder who has lost access, askNiva may require additional evidence (copy of an ID, linked email verification, or other reasonable means) proportionate to the sensitivity of the request;
(c) for CCPA/CPRA requests where the requester is a California resident, askNiva shall apply §1798.130 verification standards.

12.7 Response timelines and costs.

|---|---|---|---|

askNiva does not charge a fee for the first rights request in a calendar year. For manifestly unfounded or excessive requests, askNiva may either charge a reasonable fee (taking into account the administrative costs) or refuse to act on the request, on reasoned written notice to you (GDPR Art. 12(5); POPIA §23(3)(b)).

12.8 Privacy Centre. The Privacy Centre is accessible from within your Account. Through it you may:

(a) view a summary of the data categories askNiva holds about you;
(b) download an export of your Account Data, Communications Data (ticket summaries), Billing Data (excluding records under mandatory tax hold), and consent records in CSV or JSON;
(c) update Account Data (name, display name, locale);
(d) revoke your Google OAuth consent (link out to https://myaccount.google.com/permissions);
(e) manage cookie preferences (§18) and respect for the Global Privacy Control signal;
(f) manage direct-marketing consent (§8.3);
(g) view the current Sub-processor list (§9);
(h) lodge a privacy complaint;
(i) initiate an Account deletion request.

The Privacy Centre is in plain language and does not contain dark patterns within the meaning of CCPA §1798.140(l). Features are rolled out progressively; where a feature is not yet available, the email route in §12.5(b) is the fallback.

12.9 Right to complain. If you believe your rights have been infringed, you may lodge a complaint with:

(a) South Africa — Information Regulator. Website: https://inforegulator.org.za. Email: complaints.IR@inforegulator.org.za (general) / POPIAComplaints@inforegulator.org.za. Postal: JD House, 27 Stiemens Street, Braamfontein, Johannesburg, 2001.
(b) EU / EEA — the supervisory authority of the Member State of your habitual residence, place of work, or alleged infringement (GDPR Art. 77). A list is at https://edpb.europa.eu/about-edpb/board/members_en.
(c) United Kingdom — Information Commissioner's Office (ICO). https://ico.org.uk; tel. +44 303 123 1113.
(d) Switzerland — Federal Data Protection and Information Commissioner (FDPIC). https://www.edoeb.admin.ch.
(e) California — California Privacy Protection Agency. https://cppa.ca.gov.
(f) Other jurisdictions — your local data-protection or privacy regulator.

askNiva encourages Data Subjects to contact dpo@askniva.com first so askNiva can try to resolve the concern directly; doing so is not a precondition to lodging a complaint with a regulator.

12.10 Non-discrimination. askNiva shall not discriminate against you for exercising any right under this §12 or under Applicable Data Protection Law, including by denying you the Service, charging different prices, providing a different level or quality of service, or suggesting that you will receive any of the foregoing. Lawful financial incentives (for example, discounted rates tied to your marketing-opt-in) require separate disclosure and consent under §1798.125.

---

13. Security measures

13.1 Approach. askNiva implements appropriate technical and organisational measures to protect Personal Information against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access, taking into account the state of the art, the cost of implementation, and the nature, scope, context, and purposes of processing, as well as the risk to Data Subjects (POPIA §19; GDPR Art. 32; DPA §7).

13.2 In-transit encryption. askNiva uses TLS 1.2 or higher for all HTTPS traffic between your browser and the askNiva control plane, for management traffic to your Instance, and for inter-service traffic between the askNiva control plane and Sub-processors that support TLS. Legacy and insecure cipher suites are disabled.

13.3 At-rest encryption. Personal Information stored on askNiva control-plane databases is encrypted at rest using AES-256 or an equivalent industry-standard algorithm. Customer Data stored on your Instance is encrypted at rest at the Hetzner storage-layer level. Encryption keys are managed by askNiva through a key-management process with access controls and rotation.

13.4 API-key handling — differentiator. Your AI Provider API keys, when you submit them to your Instance, are:

(a) stored encrypted at rest using an envelope-encryption scheme with AES-256 (or stronger);
(b) never logged in plaintext;
(c) never displayed in full in the control panel, customer-support consoles, or askNiva staff tooling (a last-four-characters mask or similar is used where identification is needed);
(d) never shared with askNiva staff outside the encrypted key-management pipeline;
(e) decrypted only at the moment of routing a request to the AI Provider, and the decrypted value exists only in process memory for the duration of the request;
(f) destroyed — the encrypted key material is deleted — within twenty-four (24) hours after you rotate, remove, or instruct deletion of the key, or after the Instance is terminated (subject to backup-propagation lag and legal hold); and
(g) not recoverable by askNiva — if you lose your key, you must re-enter it. askNiva cannot "restore" a lost AI Provider API key.

13.5 Access controls. Access to Personal Information by askNiva personnel is:

(a) role-based — only personnel whose role requires access are granted it;
(b) principle-of-least-privilege — access is limited to the minimum Personal Information necessary for the task;
(c) authenticated via strong identity (MFA required for administrative access);
(d) logged — access events generate audit entries retained under §11.2(f);
(e) subject to confidentiality undertakings (DPA §5; BDSG §7 flow-down for personnel working with Hetzner-hosted data).

13.6 Customer Data access by askNiva staff. askNiva does not routinely access the content of Customer Data on your Instance. Staff access is limited to (a) User-initiated support requests in which you expressly authorise staff access to a specific scope, (b) security or abuse investigation under AUP §16.3, (c) legal compliance (§20), or (d) an emergency relating to the Service. Each access event is logged and subject to §13.5.

13.7 Shared-responsibility model. Security of the Service is a shared responsibility:

(a) askNiva's responsibilities — the controls described in §§13.2–13.6, the secure operation of the control plane, and the secure configuration of the Instance at provisioning time.
(b) Hetzner's responsibilities — the underlying physical, network, and virtualisation security of the infrastructure, published in Hetzner's security documentation. Hetzner holds an annual TÜV Rheinland audit (on which askNiva relies as external attestation of Hetzner's controls). A redacted summary of the Hetzner audit is available to Business Users under confidentiality on written request to dpo@askniva.com.
(c) Paystack's responsibilities — the security of the payment-card environment. Paystack holds PCI DSS Level 1 Service Provider status; Paystack is responsible for cardholder-data protection (askNiva receives only tokens; see §17).
(d) Google's responsibilities — the security of Google OAuth and the Google authentication stack, per Google's published security standards and DPF certification.
(e) Your responsibilities — keeping your Google account secure (MFA recommended), keeping your AI Provider API keys secret, configuring your Instance safely, avoiding public exposure of the management gateway, and promptly responding to security notices (AUP §12).

13.8 Personnel security. askNiva personnel are:

(a) bound to confidentiality in writing, for the duration of their engagement and after it ends (DPA §5.1; BDSG §7);
(b) trained on this Privacy Policy, the DPA, the AUP, and incident-response procedures;
(c) subject to background checks proportionate to their role, to the extent permitted by law; and
(d) required to use managed devices with full-disk encryption, MFA, and mobile-device-management for administrative access.

13.9 No guarantee of absolute security. No security control is absolute. Despite the measures in this §13, you acknowledge that (i) no system is immune from every attack, (ii) your own security practices materially affect the security of your data, and (iii) askNiva's ultimate security posture depends in part on Hetzner, Paystack, Google, and your chosen AI Providers (ToS §14.1(f); §5.5).

---

14. AI Provider disclosures (Anthropic, OpenAI, Google Gemini)

14.1 The structural point. You — not askNiva — are the direct customer of every AI Provider whose API key you configure on your Instance (ToS §6.2). askNiva is a downstream integration — not a reseller, sub-processor, partner, or intermediary. askNiva cannot warrant any AI Provider's availability, performance, privacy posture, or response to Data Subject requests. The subsections below summarise each AI Provider's posture as at the date of this Privacy Policy, based on public documentation; you must review each AI Provider's current terms and privacy policy directly before relying on them, and their posture may change without notice to askNiva.

14.2 Anthropic (Claude API).

(a) No training on API data by default. Under Anthropic's Commercial Terms (§B as at the date of this Privacy Policy), Anthropic "may not train models on Customer Content from Services". This commitment applies by default to all API traffic; opting in requires a separate agreement with Anthropic.
(b) Abuse monitoring and safety-flagged content. Content that is flagged by Anthropic's automated systems or reported for policy violation may be examined by Anthropic's Trust & Safety team — per Anthropic's Privacy Policy, "to improve our content detection, moderation, and safety models" — regardless of the no-training default. Flagged content may be retained beyond the default window for the duration of the review and investigation.
(c) Default back-end retention. Anthropic's Privacy Policy (effective January 12, 2026) states that "[d]eleted conversations are removed immediately from conversation history" but that "[b]ack-end retention may last up to thirty (30) days from deletion". askNiva reproduces this verbatim because the precise meaning is load-bearing: the thirty-(30)-day clock runs from the User's deletion action, not from original receipt, and it applies to back-end copies (logs, backups, processing pipelines), not the primary conversation record.
(d) Data Subject requests. Route through privacy@anthropic.com or through the Anthropic privacy portal. Anthropic's published DPO contact is dpo@anthropic.com.
(e) POPIA addendum. Anthropic does not publish a POPIA-specific addendum; you, as a Responsible Party, remain responsible for any POPIA compliance that depends on downstream-processor guarantees. Anthropic's Commercial Terms are governed by California law for non-EEA/UK/Swiss Customers, with Irish law for EEA/UK/Swiss Customers; neither option engages South African law directly.

14.3 OpenAI.

(a) No training on API data by default (March 2023 change). Under OpenAI's Services Agreement §4.2, "OpenAI will not use Customer Content to develop or improve the Services, unless Customer explicitly agrees to such use." This default has applied to the API since 1 March 2023 and is contractual, not merely a policy setting. Opt-in is rare and requires explicit customer agreement.
(b) Default abuse-monitoring retention — thirty (30) days. Independently of training, OpenAI retains API inputs, outputs, and associated metadata for up to thirty (30) days from generation for abuse-monitoring purposes, after which the content is automatically deleted unless OpenAI is legally required to retain it (for example, under a legal hold or subpoena). During that window, content flagged by automated systems may be reviewed by OpenAI Trust & Safety staff.
(c) Zero Data Retention ("ZDR") is an opt-in commitment, not the default. ZDR is an amendment to OpenAI's DPA under which API inputs and outputs are deleted immediately (typically within hours) after processing, with no thirty-(30)-day abuse-monitoring retention. ZDR requires: (i) eligibility (enterprise or high-volume agreement status), (ii) a signed amendment to the OpenAI DPA, (iii) acceptance of OpenAI's modified abuse-monitoring procedures, and (iv) formal approval by OpenAI's Trust & Safety team. A related middle-ground — "Modified Abuse Monitoring" ("MAM") — narrows the retention window or opts specific data categories out of monitoring. askNiva cannot obtain ZDR or MAM on your behalf; you must negotiate directly with OpenAI. Neither option is available through self-service API settings as at the date of this Privacy Policy.
(d) Enterprise privacy posture. OpenAI publishes SOC 2 Type 2, ISO 27001, ISO 27017, ISO 27018, and ISO 27701 certifications. Encryption is AES-256 at rest and TLS 1.2 or higher in transit. Enterprise-tier features (data residency in Europe, Enterprise Key Management, advanced audit rights) are available only to eligible high-volume customers and are not the API default.
(e) Governing law. OpenAI's Services Agreement is governed by California law for customers outside the EEA/UK/Switzerland (the contracting entity is OpenAI, LLC), and by Irish law for customers in those regions (contracting entity OpenAI Ireland Limited). Neither option engages South African law directly.
(f) Data Subject requests. Route through dsar@openai.com or the OpenAI privacy portal at https://privacy.openai.com. Trust & Safety appeals: trustandsafety@openai.com.
(g) Sub-processor list. https://openai.com/policies/sub-processor-list/. OpenAI gives at least thirty (30) days' notice of new sub-processors.

14.4 Google Gemini — the free-tier training split (critical warning).

Google Gemini treats free-tier and paid-tier API usage radically differently. This is the single most consequential AI-Provider disclosure in this Privacy Policy and is drawn directly from Google's Gemini API Additional Terms (https://ai.google.dev/gemini-api/terms).

(a) Free-tier (Google AI Studio without active Cloud billing). Gemini API Additional Terms state, verbatim: "Google uses the content you submit to the Services and any generated responses to provide, improve, and develop Google products and services." In addition: "human reviewers may read, annotate, and process your API input and output." The "Paid Service" definition limits the protective terms to access "through a Cloud Project associated with an active billing account", meaning: no billing account = no protection. Retention is effectively indefinite — reviewed content is retained for up to three (3) years (per the Gemini Apps Privacy Hub), and content absorbed into model weights cannot be selectively deleted. Google itself warns, verbatim: "Do not submit sensitive, confidential, or personal information to the Unpaid Services."
(b) Paid-tier (Google AI Studio with active Cloud billing, or Vertex AI). Gemini API Additional Terms state, verbatim: "Google doesn't use your prompts (including associated system instructions, cached content, and files such as images, videos, or documents) or responses to improve our products". Google logs prompts and responses "for a limited period of time, solely for detecting and preventing violations of the Prohibited Use Policy". The Google Cloud DPA applies; ISO 27001 and SOC 2 Type II certifications apply; Vertex AI customers may select data residency (for example, europe-west1). Deletion commitments under the Cloud DPA run to 180 days on customer instruction.
(c) EEA / UK / Swiss regional override. Per the Gemini API Additional Terms, if a User is in the EEA, Switzerland, or the UK, the paid-tier terms apply to all Services "even though they are offered free of charge" — Google forcibly applies paid-tier privacy to those Users because it lacks a GDPR / UK GDPR / FADP lawful basis to train on EEA/UK/Swiss personal data without explicit consent. South Africa is not in that list; an SA-based User on a free-tier key is subject to the free-tier training default and cannot rely on the regional override to cure a POPIA defect.

> IMPORTANT — Gemini free-tier warning for South African Users. If you submit Personal Information of South African or other non-EEA/UK/Swiss Data Subjects to your Instance while using a free-tier Gemini API key, Google will use those prompts, Outputs, and files to train its products, will subject them to human review, and will retain them indefinitely. This is almost certainly incompatible with your obligations under POPIA §11 (which requires a lawful basis for processing and imposes purpose-limitation, minimisation, and retention limits). askNiva strongly recommends that, if your Instance will process any Personal Information, you use a paid-tier Gemini API key (AI Studio with billing enabled, or Vertex AI). You remain responsible for your own POPIA §11 compliance regardless of which tier you choose.

(d) Data Subject requests. Route through https://support.google.com/policies/contact/general_privacy_form or your Google Cloud account team.
(e) Documentation. Gemini API Additional Terms (https://ai.google.dev/gemini-api/terms); Google APIs Terms of Service (https://developers.google.com/terms); Google Cloud Terms of Service (https://cloud.google.com/terms); Google Privacy Policy (https://policies.google.com/privacy).

14.5 Comparative summary.

|---|---|---|---|---|---|

14.6 askNiva's role in the AI-inference data flow. When your Instance makes an inference call, the prompt is marshalled by openClaw inside the Instance and sent directly from the Instance's Hetzner IP address to the AI Provider's API endpoint over TLS 1.2 or higher. askNiva's control plane does not sit in the data path for inference. askNiva does not log prompt content or Output content; askNiva's observability into inference traffic is limited to call counts, latency, HTTP/API error codes, model identifier, and token-budget utilisation (§6.6(c)). You may, however, configure your own logging on your Instance — that is Customer Data on your Instance, and the DPA applies.

14.7 No DSR-on-your-behalf. askNiva cannot exercise Data Subject rights on your behalf against any AI Provider, cannot force deletion of Personal Information held by an AI Provider, and cannot warrant any AI Provider's availability or response. You must route DSR requests directly to the AI Provider using the contacts in §§14.2(d), 14.3(e), and 14.4(d).

> In plain English: Each AI company has its own privacy rules. Anthropic and OpenAI do not train on your data by default. Google Gemini does train on your data on the free tier (and probably breaks POPIA if you use it for South African personal data). Always use Gemini's paid tier if you are processing personal information. Whatever the provider, they are your provider — you contact them directly, not through askNiva.

---

15. Google OAuth — API Services User Data Policy disclosures

15.1 Binding disclosures. askNiva's use of Google OAuth is governed by Google's API Services User Data Policy (https://developers.google.com/terms/api-services-user-data-policy), which imposes the following disclosures that askNiva is contractually bound to make in this Privacy Policy. Absence or materially inaccurate presentation of these disclosures is grounds for Google to disable askNiva's OAuth application.

15.2 Google is the identity provider. When you sign in to askNiva using "Sign in with Google", Google — not askNiva — authenticates you. askNiva does not receive, hold, or handle your Google password at any point.

15.3 Scopes and data received. askNiva requests the OAuth scopes openid, email, and profile. From Google, askNiva receives:

(a) your Google account sub identifier (an opaque, stable identifier);
(b) your email address;
(c) your full name; and
(d) your profile picture.

askNiva does not request, receive, or hold access to your Google Calendar, Gmail, Drive, Contacts, YouTube, Maps, Search, or any other Google-user data beyond the three scopes above. If askNiva adds any additional Google-user-data scope in the future, askNiva will (i) request your additional consent at the point of the scope grant, (ii) update this Privacy Policy, and (iii) present a Google-mandated scope-specific disclosure.

15.4 Limited Use — mandatory affirmations. askNiva's access to, use of, and transfer of Google User Data comply with the Google API Services User Data Policy, including the Limited Use requirements. Specifically, askNiva:

(a) uses Google User Data only to provide or improve user-facing features of the Service (namely, account authentication and identification);
(b) does not use Google User Data for serving advertisements, including retargeting, personalised, or interest-based advertising;
(c) does not sell, trade, or transfer Google User Data to any data broker, advertising service, or other third party outside the narrow allowances of the Limited Use policy;
(d) does not use or transfer Google User Data to determine credit-worthiness or for lending purposes;
(e) does not use or transfer Google User Data to develop, improve, or train any AI or machine-learning models, except as expressly permitted by the Google API Services User Data Policy (Limited Use) — for example, user-facing features with express user consent messaged at the point of collection; and
(f) permits humans to access Google User Data only (i) with your affirmative consent, (ii) for security purposes, (iii) to comply with applicable law, or (iv) where the data is aggregated and used for internal operations and in accordance with the Limited Use policy.

15.5 Right to revoke — immediate cessation on askNiva's side. You may revoke askNiva's access to your Google User Data at any time by visiting https://myaccount.google.com/permissions and removing "askNiva" from the list of connected applications. Revocation takes effect on Google's side immediately. On detection of revocation (including on receipt of invalid_grant from Google's OAuth endpoint), askNiva shall immediately cease all use of your Google-derived Account Data for any purpose other than (i) maintaining records of prior contract acceptance, or (ii) as required by law. askNiva detects the revocation asynchronously (typically within minutes). Revocation will prevent you from logging in to the Service until you re-consent. Account records may be retained for legal and accounting purposes (as described in §11) but will not be used for any purpose other than those for which retention is lawful.

15.6 Account deletion and Google data. Deleting your askNiva Account additionally causes deletion of Google-derived Account Data within thirty (30) days, subject to the retention exceptions in §11.2 (tax records, legal holds, consent-of-acceptance records).

15.7 Sub-processor status. Google LLC appears in the Sub-processor table in §9.2 in its capacity as OAuth / identity provider. Google LLC's processing of the Personal Information described in §15.3 on askNiva's behalf falls under the Google API Services User Data Policy and the applicable Google DPA / terms.

15.8 Merger, acquisition, or sale — prior user consent for Google-derived data. In the event of a merger, acquisition, or sale of askNiva's business, Google-derived Account Data (email, name, profile picture, Google sub identifier) will be transferred to the acquiring entity only after obtaining your affirmative prior consent, consistent with Google API Services User Data Policy §6. If you do not consent within thirty (30) days of notice, askNiva will delete your Google-derived data. This subsection operates in addition to (and as a specific carve-out from) the general assignment provision in ToS §23.3.

15.9 Annual security assessment for restricted scopes. If askNiva later requests any OAuth scope that Google classifies as "restricted" (for example, scopes accessing Gmail, Drive, Calendar, or Contacts), askNiva shall first complete Google's annual independent security assessment and obtain a valid Letter of Assessment from a Google-designated third-party assessor prior to enabling the scope in production. askNiva shall not enable any restricted scope without meeting this condition.

---

16. (reserved)

(This section number is intentionally reserved to preserve the stability of cross-references to §§17–27 across drafting iterations and future amendments. A substantive topic may be inserted here in a later version without disturbing numbering.)

---

17. Paystack — payment-data disclosure

17.1 Payment flow. askNiva uses Paystack Payments Limited ("Paystack") to process Subscription payments (ToS §8.2). When you enter card (or other payment-method) details, you do so on a Paystack-hosted form or SDK surface; the raw card data is transmitted to Paystack, not to askNiva.

17.2 Tokenisation. Paystack tokenises your payment method and returns to askNiva only:

(a) a token (e.g., tok_xxxx) representing the payment method, for use in recurring charges;
(b) transaction references, status, amount, currency, and timestamps;
(c) last-four digits of the card and card brand (for your own display in the control panel);
(d) chargeback and refund metadata as applicable.

askNiva does not receive, store, or transmit full card numbers, CVV codes, track data, PINs, or any other "cardholder data" within the meaning of PCI DSS in a form that would place askNiva into PCI DSS scope beyond SAQ-A. askNiva's PCI DSS scope is SAQ-A or less.

17.3 Paystack's certifications. Paystack holds PCI DSS Level 1 Service Provider status and is responsible for the security of the cardholder-data environment, including card-network connectivity, key management, and cardholder-data retention. askNiva relies on Paystack's PCI DSS Level 1 status and on Paystack's published privacy and security documentation.

17.4 Fraud detection. Paystack performs its own fraud detection on payment transactions, which may include IP-based risk signals, device fingerprinting, and velocity checks on the payment instrument. askNiva does not use the underlying fraud-detection data for any purpose other than the narrow inputs that Paystack returns to askNiva (e.g., a risk flag that triggers a chargeback review). The fraud-detection data itself is controlled by Paystack under Paystack's own privacy policy.

17.5 Data Subject requests. For matters relating to the payment-data environment (Paystack-held cardholder data, chargeback mechanics, fraud flags), address the Paystack Data Protection Officer: dpo@paystack.com. For the subset of Billing Data that askNiva itself holds (invoices, token references, tax-retention records), address dpo@askniva.com.

17.6 International transfers. Paystack is headquartered in Nigeria; payment-rail routing (card networks, acquiring banks) may transfer data to Ireland, the United States, and other jurisdictions as required for card-network operation. askNiva relies on §72(1)(b) contractual safeguards (Paystack DPA) for the POPIA basis and, for GDPR-scope data, on the EU SCCs (Module 2 for askNiva's merchant billing data; Module 3 for User card-holder data) as incorporated under DPA §12.3. The Paystack DPA and any POPIA addendum / SCC incorporation are recorded in the Operator-Contract Register (DPA §6.5) per the launch-readiness register.

---

18. Cookies and similar technologies

18.1 What askNiva uses. askNiva uses a minimal set of Cookies and similar technologies on askniva.com and within the control panel:

(a) Strictly necessary — session cookies (authentication, CSRF protection, load balancing), language preference, consent-record cookies. These are essential to provide the Service; disabling them will break the Service.
(b) Preferences — UI preferences, theme selection.
(c) Analytics — askNiva's analytics tooling and cookie set are specified in the Operator-Contract Register and in §9.2 once the analytics Sub-processor (if any) has been engaged per the launch-readiness register. No analytics cookies are set before that point.
(d) Marketing / advertising — askNiva does not use marketing or advertising cookies and does not engage in cross-context behavioural advertising.

18.2 Consent and opt-out. Where Cookies are not strictly necessary, askNiva obtains your opt-in consent before setting the Cookie, to the extent required by law (GDPR, UK PECR, German TTDSG §25, POPIA §69 for direct-marketing analogues). A banner on first visit allows you to accept or reject non-essential Cookies. You may change your choice at any time via the Privacy Centre (§12.8).

18.3 Global Privacy Control ("GPC"). askNiva respects the GPC signal (https://globalprivacycontrol.org). If your browser sends a GPC signal, askNiva treats it as (a) an opt-out of the sale or sharing of Personal Information for cross-context behavioural advertising under CCPA (§1798.135); and (b) an opt-out of non-essential analytics and marketing Cookies.

18.4 "Do Not Sell or Share My Personal Information" and "Limit the Use of My Sensitive Personal Information". A "Your Privacy Choices" link is available in the footer of askniva.com and in the Privacy Centre. Because askNiva does not sell or share Personal Information (§6.10(b)–(c)) and does not collect Sensitive Personal Information for use beyond what is reasonably necessary (§6.10(a)), these links are no-op confirmations rather than active opt-outs — but they are present as CCPA conformance signals.

18.5 Local storage, session storage, pixels. askNiva may use local storage and session storage for session-management and UI-state purposes (treated as strictly necessary), and may use server-side logging of page views (not a pixel or third-party tag) for analytics where you have consented.

---

19. Security Incidents and breach notification

19.1 Commitment — 72 hours outer bound for Data Subjects; 24 hours operator-to-controller under the DPA. askNiva shall notify you of a Security Incident affecting your Personal Information without undue delay after becoming aware of it, and in any event no later than seventy-two (72) hours after awareness. The seventy-two (72) hour figure is the outer-bound commitment that matches the GDPR Article 33(1) controller-to-supervisory-authority deadline and so gives every Data Subject a floor commitment aligned with the tightest directly-comparable statutory deadline. Where the DPA applies — that is, where askNiva acts as Operator / processor in respect of Customer Data on your Instance and you act as Responsible Party / controller — askNiva's operator-to-controller notification commitment in DPA §9.1 is tighter at twenty-four (24) hours after reasonable awareness, deliberately set inside the 72-hour outer bound so that you have sufficient runway to meet your own POPIA §22 / GDPR Article 33(1) / Article 34 deadlines to Data Subjects and supervisory authorities. The two clocks are not in conflict: the DPA §9.1 24-hour clock is the operative performance standard where it applies, and this Privacy Policy §19.1 72-hour clock is the outer bound published to Data Subjects so they understand askNiva's worst-case notification posture. The 72-hour figure is tighter than the "without undue delay" standard in GDPR Article 33(2) (processor-to-controller) and POPIA §22(1) ("as soon as reasonably possible"). askNiva's internal incident-response playbook defines "awareness" as the point at which a sufficiently senior askNiva responder concludes, on reasonable grounds, that a Security Incident has occurred — consistent with the POPIA §22(1) "reasonable grounds to believe" threshold for a compromise of the integrity or confidentiality of Personal Information.

19.2 Content of notification. The notification to you shall include, to the extent the information is available at the time of notification:

(a) a description of the nature of the Security Incident, including (where possible) the categories and approximate number of Data Subjects and records concerned;
(b) the name and contact details of askNiva's Information Officer / DPO;
(c) the likely consequences of the Security Incident;
(d) the measures taken or proposed to address the Security Incident and to mitigate its possible adverse effects; and
(e) any interim guidance to you (for example, rotating credentials, monitoring for unauthorised transactions).

19.3 Cascade from Hetzner. Hetzner is contractually bound to notify askNiva of a Personal Data Breach within seventy-two (72) hours of awareness under Hetzner's DPA / Article 33 flow-down. This cascade drives askNiva's own clock to you: if Hetzner notifies askNiva at hour 40, askNiva has 32 hours to notify you. The cascade is disclosed here so Data Subjects understand that askNiva's 72-hour clock is inherited from Hetzner, not solely voluntary.

19.4 POPIA §22 / GDPR Article 33 / Article 34 / FADP Art. 24. Where askNiva is the Responsible Party / controller in respect of affected Personal Information, askNiva shall additionally notify:

(a) the Information Regulator (South Africa) under POPIA §22 — "as soon as reasonably possible", subject to §22(3) law-enforcement delay, with §22(5) content;
(b) the competent supervisory authority in the EU/UK/Switzerland under GDPR Article 33, UK GDPR Article 33, or FADP Article 24;
(c) affected Data Subjects directly where a breach is likely to result in a high risk to their rights and freedoms (POPIA §22; GDPR Article 34; FADP Article 24); and
(d) any other authority or party legally required or contractually obliged to be notified (including, where applicable, CCPA-mandated reporting).

19.5 Your own clock. If you are Responsible Party / controller in respect of Customer Data affected by the Security Incident (see §5.1(b)), your own statutory clock (POPIA §22 / GDPR Article 33) runs from when you receive askNiva's notification. The DPA describes askNiva's assistance obligations.

19.6 Compromise threshold. askNiva's internal definition of a reportable "compromise" for POPIA §22 purposes is consistent with the Information Regulator's published guidance and with the EDPB's published thresholds for GDPR Article 33. The decision matrix lives in askNiva's incident-response playbook; this Privacy Policy commits to compliance with the statutory standards.

19.7 No preservation of privilege against disclosure. askNiva's preservation of legal privilege over internal incident communications does not displace its statutory notification obligations.

---

20. Cooperation with law enforcement and regulators

20.1 Permitted disclosures. askNiva may access, preserve, and disclose Personal Information as permitted by ToS §18 and by applicable law, including where required to comply with a lawful court order, subpoena, warrant, or regulatory request from an authority with jurisdiction (including, without limitation, the South African Police Service, the South African Revenue Service, the Information Regulator, the Financial Intelligence Centre, the National Director of Public Prosecutions, the Hawks, courts of the Republic of South Africa, foreign law-enforcement agencies acting through a mutual-legal-assistance process, the National Center for Missing and Exploited Children where CSAM is involved, the German federal authorities where German criminal law applies, and any other competent authority under applicable law). The POPIA lawful basis for these disclosures is POPIA §11(1)(b), (c), and (f) as expressly recited in ToS §18.1; the §18 notification is provided by this Privacy Policy and §20.3 below.

20.2 Mandatory reporting. In certain cases — notably suspected CSAM under AUP §5.1 — askNiva is required by law to preserve evidence and to report the matter to law-enforcement authorities without notice to you.

20.3 Notice where lawful. askNiva shall notify you of a lawful request before responding where (i) it is lawful to do so, (ii) it is reasonable, and (iii) it would not frustrate the purpose of the request or create a risk to any person (ToS §18.2).

20.4 Transparency. askNiva may publish periodic transparency reports aggregating (without identifying any User) the number and type of law-enforcement requests received and the response. Any decision to publish and the publication cadence remain at askNiva's discretion.

---

21. Children's data

21.1 Service is 18+. ToS §2.1 restricts the Service to individuals aged eighteen (18) or older. askNiva does not knowingly collect Personal Information from any person under 18. If askNiva discovers that it has collected Personal Information from a person under 18, askNiva shall delete the information without undue delay and may terminate the Account.

21.2 Your own processing of children's data. POPIA §34 prohibits processing of the Personal Information of a child unless one of the grounds in POPIA §35 applies (including consent of a competent person). If your use of the Service involves processing the Personal Information of a child (under 18 in South Africa; the age threshold may differ in other jurisdictions), you — as Responsible Party / controller for Customer Data — are solely responsible for:

(a) obtaining the consent of a competent person under POPIA §35(1)(a) (a parent, guardian, or other competent person);
(b) satisfying any other applicable children's-data law (for example, GDPR Article 8, the UK Age Appropriate Design Code, the US COPPA where 13+ with parental consent, or any jurisdiction-specific rule);
(c) implementing appropriate age-verification and consent-capture mechanics on your Instance; and
(d) refraining from any conduct prohibited by the AUP, including AUP §5.1 (child safety — zero tolerance).

21.3 COPPA. askNiva does not knowingly collect Personal Information from children under 13 within the meaning of the US Children's Online Privacy Protection Act. If a parent or guardian becomes aware that a child under 13 has provided Personal Information to askNiva, they may contact dpo@askniva.com; askNiva shall delete the information.

---

22. Changes to this Privacy Policy

22.1 Notice. askNiva may update this Privacy Policy from time to time. Where a change is material, askNiva shall notify you at least thirty (30) days before the change takes effect by email (to your Account email), by in-product notification, or by posting on askniva.com (or a combination). The notice mechanism aligns with ToS §23.11.

22.2 Non-material changes. Editorial, clarifying, or typographical corrections may be made without advance notice; the "Last Updated" date at the top of this document is the canonical change indicator.

22.3 Regulatory changes. Changes required by law, regulation, or supervisory-authority direction may take effect as required by law, which may be immediately.

22.4 Effective against you. Continued use of the Service after a change takes effect constitutes acknowledgement of the updated Privacy Policy. If you do not accept a material change, you may cancel your Subscription in accordance with ToS §8.6 before the change takes effect.

22.5 Version history. askNiva maintains a version history of this Privacy Policy at https://askniva.com/legal/privacy-changelog (or such other URL as askNiva may publish), listing prior versions and a summary of each material change. Publication of the changelog URL is a launch-readiness item (see the launch-readiness register).

---

23. South Africa addendum (POPIA)

23.1 Primary application. This Privacy Policy is a POPIA-first document. Every provision in §§1–22 is drafted primarily against POPIA; this §23 supplements and clarifies where POPIA-specific treatment is warranted.

23.2 Information Officer. askNiva's Information Officer, registered with the Information Regulator under POPIA §55, may be contacted at dpo@askniva.com.

23.3 §18 notification content. POPIA §18 requires the Responsible Party to notify the Data Subject of certain information at the time of collection. This Privacy Policy — read together with the first-login summary notice — is the §18 notification. Specifically:

| §18 element | Where in this Privacy Policy |

|---|---|

| §18(1)(a) — information being collected (and source, where not collected from the Data Subject) | §6 (categories); §7 (sources including Google OAuth, Paystack, Hetzner, third-party abuse reports) |

| §18(1)(b) — name and address of the Responsible Party | §1 |

| §18(1)(c) — purpose of collection | §8 (purpose/basis matrix) |

| §18(1)(d) — whether collection is voluntary or mandatory | §8 and this §23.3 (most collection is necessary for contract performance; marketing is voluntary; sanctions screening is mandatory under legal obligation) |

| §18(1)(e) — consequences of failure to provide | Failure to provide Account Data prevents account creation; failure to provide Billing Data prevents paid Subscription; failure to permit sanctions screening prevents Service provision |

| §18(1)(f) — any law authorising or requiring collection | §8 and §8.2 (Income Tax Act §29, VAT Act §55, FICA, POPIA §19 accountability, sanctions regimes) |

| §18(1)(g) — intended transfer to a third country and level of protection | §10 (cross-border transfers); §9.2 (Sub-processor table including each transfer mechanism) |

| §18(1)(h) — right of access (§23), right to correction (§24), right to object (§11(3)), right to lodge a complaint with the Information Regulator (§74, §99), and any other information necessary for fair processing | §12 (Data Subject rights); §12.9 (complaint route); §§1–22 in combination |

23.4 §§11, 13, 14, 15 conditions. askNiva processes Personal Information only to the extent permitted by POPIA §§11 (lawfulness), 13 (specific purpose), 14 (retention), and 15 (further processing). §8.1 maps each purpose to the corresponding §11 ground.

23.5 §§23–25 rights. Data Subjects in South Africa have the rights set out in POPIA §§23 (access), 24 (correction and deletion), and 11(3) (objection). §12 describes how to exercise them. POPIA does not include a formal data-portability right; askNiva offers a courtesy export (§12.3).

23.6 §26 and §§27–33 Special Personal Information. askNiva does not process Special Personal Information as a Responsible Party except to the limited extent necessary for §§27–33 exceptions (e.g., processing of criminal-behaviour data in sanctions screening under §33 — legal obligation). If you process Special Personal Information through your Instance, you are solely responsible for satisfying §§27–33.

23.7 §§34–35 children's Personal Information. §21 of this Privacy Policy describes the Service's 18+ age gate and the flow-down to your own processing under §35.

23.8 §69 direct marketing. askNiva obtains opt-in consent for direct marketing by electronic communication, subject to the narrow §69(3) existing-customer carve-out (§8.3).

23.9 §71 automated decision-making. §8.5 describes askNiva's approach to automated decisions with legal or similarly significant effects on Data Subjects.

23.10 §72 cross-border transfers. §10.2 sets out the §72(1)(b) contractual-safeguards basis for all outbound transfers.

23.11 §22 Security Incidents. §19 describes askNiva's breach-notification commitment; askNiva shall notify the Information Regulator and affected Data Subjects in accordance with §22.

23.12 §99 civil remedies. Nothing in this Privacy Policy limits a Data Subject's right to institute civil proceedings against a Responsible Party or Operator under POPIA §99 (see also DPA §13.2).

23.13 Information Regulator complaint route. §12.9(a) describes how to lodge a POPIA complaint.

---

24. EU / EEA / UK / Swiss addendum (GDPR, UK GDPR, FADP)

24.1 Application. This §24 applies where the GDPR (Regulation (EU) 2016/679), the UK GDPR, or the Swiss FADP applies to the processing of your Personal Information by askNiva. The GDPR applies extraterritorially under Article 3(2) to processing relating to the offering of goods or services to, or the monitoring of the behaviour of, Data Subjects in the EEA. The UK GDPR applies on parallel terms to UK Data Subjects. The FADP applies to Data Subjects in Switzerland.

24.2 Articles 13 and 14 notice. This Privacy Policy is askNiva's notice under GDPR Articles 13 (direct collection) and 14 (collection from sources other than the Data Subject — for example, Google OAuth and Paystack). The required content is distributed across §§1, 4, 6, 7, 8, 9, 10, 11, 12, 13, and 19.

24.3 Data Protection Officer and EU representative. §§1.3 and 1.5.

24.4 Article 28 processor arrangements. Where askNiva acts as processor on your instructions (Customer Data), the DPA §§4–11 implement Article 28(3) processor obligations.

24.5 Article 32 security measures. §13 of this Privacy Policy describes technical and organisational measures at plain-language level; Annexe 1 to the DPA (TOM Annexe) is the Article 32 vehicle.

24.6 Articles 33–34 breach notification. §19 describes the 72-hour commitment.

24.7 Articles 44–49 transfers. §10 describes the transfer mechanisms.

24.8 Articles 77–79 rights to complaint and remedy. §§12.9 and 12.10 describe how to complain to a supervisory authority and pursue a judicial remedy.

24.9 Member-state supervisory authorities. A Data Subject may complain to the supervisory authority of their habitual residence, place of work, or alleged infringement. A list of EEA supervisory authorities is published by the European Data Protection Board at https://edpb.europa.eu/about-edpb/board/members_en.

24.10 UK-specific. UK Data Subjects may complain to the Information Commissioner's Office (ICO) at https://ico.org.uk. UK IDTA / UK Addendum to SCCs applies to transfers from the UK.

24.11 Swiss-specific. Swiss Data Subjects may complain to the Federal Data Protection and Information Commissioner (FDPIC) at https://www.edoeb.admin.ch. FADP-recognised SCCs and the Swiss-US Data Privacy Framework apply to Swiss transfers.

24.12 German BDSG and TTDSG. Because Hetzner infrastructure is in Germany, BDSG §7 written-confidentiality obligations on personnel and TTDSG §25 consent requirements for non-essential device-storage access apply. §§13.8 and 18 implement these.

---

25. California addendum (CCPA/CPRA)

25.1 Application. This §25 applies to you if you are a California resident and the CCPA/CPRA applies to askNiva's processing of your Personal Information. CCPA/CPRA applicability to askNiva turns on the statutory thresholds for a "business" (including the revenue, consumer-record volume, and California-resident criteria in Cal. Civ. Code §1798.140(d)). askNiva re-assesses applicability annually against current operating metrics; any change in determination is recorded in the Operator-Contract Register and reflected in this §25 on the next update cycle.

25.2 CCPA §1798.140 categories collected. In the twelve (12) months preceding the Last Updated date of this Privacy Policy, askNiva has collected the following categories of Personal Information (mapped to CCPA §1798.140):

|---|---|---|---|

| (c) Protected classification characteristics | No | — | — |

| (e) Biometric information | No | — | — |

| (f) Internet or other electronic network activity (browsing, search history, interaction with website or ads) | Yes | Control-panel interactions; askniva.com page views | §8 purposes 2, 6, 10 |

| (g) Geolocation data (precise) | No | IP-derived approximate city-level only | — |

| (h) Audio, electronic, visual, thermal, olfactory, or similar information | No (unless you upload to an Instance, in which case Customer Data applies) | — | — |

| (j) Education information (FERPA) | No | — | — |

| (l) Sensitive personal information (§1798.140(ae)) | No | — | — |

25.3 "We do not sell and do not share Personal Information." askNiva does not sell Personal Information, and does not share Personal Information for cross-context behavioural advertising, within the meaning of CCPA §1798.140(ad) and §1798.140(ah).

25.4 Sensitive PI. askNiva does not collect Sensitive Personal Information within the meaning of §1798.140(ae) for use beyond that which is reasonably necessary under §1798.121. The CPRA "Limit the Use of My Sensitive Personal Information" link is present as a conformance signal (§18.4) but operates as a no-op because askNiva does not have qualifying sensitive-PI use to limit.

25.5 Sources and purposes. Sources are in §7; purposes are in §8.

25.6 Disclosures for business purposes. In the twelve (12) months preceding the Last Updated date, askNiva has disclosed each of the categories in §25.2 to the Sub-processors listed in §9 for the business purposes in §8. askNiva has not disclosed Personal Information for any purpose that would constitute a sale or a share under the CCPA.

25.7 Your CCPA/CPRA rights.

(a) Right to know (§§1798.100, 1798.110, 1798.115) — categories and specific pieces of Personal Information collected about you, categories of sources, business or commercial purpose, categories of third parties to whom Personal Information is disclosed.
(b) Right to delete (§1798.105) — subject to the statutory exceptions.
(c) Right to correct (§1798.106).
(d) Right to opt out of sale / share (§§1798.120–121) — no-op because askNiva does not sell or share.
(e) Right to limit use of sensitive PI (§1798.121) — no-op.
(f) Right to non-discrimination (§1798.125) — §12.10.
(g) Right to data portability (§1798.130(a)(3)(B)(iii)) — the courtesy export in §12.3 satisfies this.

25.8 Verifiable consumer request (§1798.130). askNiva verifies CCPA requests in accordance with §§999.323–999.326 of the implementing regulations: for Account-holders, Google OAuth login is sufficient identity evidence; for non-Account-holders or former Account-holders, askNiva may require two or three data points matched against internal records.

25.9 Authorised agent. You may designate an authorised agent to make a CCPA/CPRA request on your behalf in accordance with §1798.135(b)(1). Your agent must provide (i) written permission from you, and (ii) verification of your identity under §25.8.

25.10 Response timelines. §12.7 (CCPA row).

25.11 Complaints. California Privacy Protection Agency: https://cppa.ca.gov; California Office of the Attorney General: https://oag.ca.gov/privacy.

25.12 Notice at collection. §6 is askNiva's notice at collection required by §1798.100(b).

---

26. Other US state privacy laws (generic addendum)

26.1 Application. This §26 applies to residents of US states with comprehensive privacy laws (other than California), including as at the Last Updated date: Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), Iowa (ICDPA), Indiana (INCDPA), Tennessee (TIPA), Texas (TDPSA), Oregon (OCPA), Montana (MCDPA), Delaware (DPDPA), New Hampshire (NHPA), New Jersey (NJDPA), and any other US state comprehensive privacy law in force on the Last Updated date. askNiva reviews this enumeration on each Privacy Policy update cycle (§22).

26.2 Core rights. Residents of these states generally have the rights to (a) access, (b) delete, (c) correct, (d) port, and (e) opt out of targeted advertising, sale of personal data, and certain profiling activities. askNiva honours these rights by the routes in §12.5.

26.3 No sale; no targeted advertising. askNiva does not sell Personal Information and does not engage in targeted advertising based on the Personal Information of Data Subjects in these states.

26.4 Sensitive data. Where these laws define "sensitive data" and require opt-in consent, askNiva does not process sensitive data as Responsible Party except on the narrow bases in §6.10(a) and §8.2.

26.5 Appeal. Certain state laws (e.g., VCDPA §59.1-577, CPA §6-1-1306) grant a right to appeal a refused request. You may appeal in writing to dpo@askniva.com with the subject line "Privacy Appeal"; askNiva shall respond within the statutory period.

26.6 Complaints. Depending on the state, you may complain to the state Attorney General's office (Virginia, Connecticut, Texas, Utah, Iowa, Indiana, Tennessee, and others) or the designated state privacy regulator (Colorado — Attorney General; certain states are establishing dedicated agencies).

---

27. Contact and complaint escalation

Mollo Innovations (Pty) Ltd (trading as "askNiva")

Companies and Intellectual Property Commission (CIPC) registration number: 2026/275132/07

Registered office: Regus Business Centre, 1st Floor, Block B, North Park, Black River Park, 2 Fir Street, Observatory, Cape Town, Western Cape, South Africa, 7925

Principal place of business: same as registered office above

Website: https://askniva.com

General enquiries: hello@askniva.com

Customer support: support@askniva.com

Privacy team

Privacy / data-protection (POPIA): privacy@askniva.com

Data Protection Officer / Information Officer (POPIA §55): dpo@askniva.com

Other operational contacts

Legal notices: legal@askniva.com

Abuse reports: abuse@askniva.com

Security issues: security@askniva.com

EU Representative (GDPR Article 27). No representative currently designated; appointment is conditional on the trigger described in §1.3(c) above. Details will be published here upon designation.

UK Representative (UK GDPR Article 27). No representative currently designated; appointment is conditional on the trigger described in §1.4(c) above. Details will be published here upon designation.

Supervisory authorities (by jurisdiction)

South Africa — Information Regulator. https://inforegulator.org.za; complaints.IR@inforegulator.org.za; POPIAComplaints@inforegulator.org.za; JD House, 27 Stiemens Street, Braamfontein, Johannesburg, 2001.
EU / EEA. The supervisory authority of your habitual residence, place of work, or alleged infringement; list at https://edpb.europa.eu/about-edpb/board/members_en.
UK. Information Commissioner's Office, https://ico.org.uk, tel. +44 303 123 1113.
Switzerland. Federal Data Protection and Information Commissioner (FDPIC), https://www.edoeb.admin.ch.
California. California Privacy Protection Agency, https://cppa.ca.gov; California Office of the Attorney General, https://oag.ca.gov/privacy.
Other US states. Office of the Attorney General of the relevant state, or the designated state privacy regulator.

Sub-processor list (machine-maintained)

https://askniva.com/legal/sub-processors (publication of this page is a pre-Effective-Date launch-readiness item).

Privacy Policy version history

https://askniva.com/legal/privacy-changelog (publication of this page is a pre-Effective-Date launch-readiness item).

---

Acknowledgement

By creating an Account, accessing any part of the Service, or submitting Personal Information to askNiva, you acknowledge that you have read this Privacy Policy, that you understand it, that you have received notice of its content (POPIA §18; GDPR Article 13 / 14), and that askNiva may process your Personal Information in accordance with it and with the rest of the Agreement.

---

Schedule A — Glossary of defined terms (alphabetical index)

For the lawyer's convenience, the defined terms appearing in this Privacy Policy are listed alphabetically below, each with a reference to where it is defined. Terms defined in the ToS are incorporated by reference (§4.1) and are not repeated here.

| Term | Defined in |

|---|---|

| Account Data | §4.1 |

| Applicable Data Protection Law | §4.1 |

| Billing Data | §4.1 |

| CCPA/CPRA | §4.1 |

| Communications Data | §4.1 |

| Cookies | §4.1 |

| Customer Data | §4.1 (via ToS §1.1) |

| Derived Data | §4.1 |

| FADP | §4.1 |

| GDPR | §4.1 |

| Google OAuth | §4.1 |

| Information Regulator | §4.1 |

| Operational Telemetry | §4.1 |

| Personal Information | §4.1 (via POPIA §1) |

| Privacy Centre | §4.1 |

| Security Incident | §4.1 |

| Sensitive Personal Information | §4.1 |

| Service Logs | §4.1 |

| Sub-processor | §4.1 |

| Technical Data | §4.1 |

Terms such as "askNiva", "Account", "Agreement", "AI Provider", "AUP", "Business User", "Consumer", "CPA", "Customer Type", "Data Subject", "DPA", "ECTA", "FICA", "Hetzner", "Instance", "openClaw", "Operator", "Output", "Paystack", "POPIA", "Responsible Party", "Service", "Special Personal Information", "Subscription", and "User" / "you" / "your" take their meanings from ToS §1.1.