Privacy Policy

This policy applies to InnKite’s guest chat service, owner dashboard, knowledge ingestion, and any related API. It does not apply to third-party services you may reach by following a link from a property’s QR code. Those services are governed by their own privacy notices.

The responsible party is the operator of InnKite. For South African properties, the responsible party is InnKite, a sole proprietorship operated by Darren Chapman, whose Information Officer is contactable at the address in section 15. For data of EU residents processed in connection with the service, InnKite acts as a processor on behalf of the property owner, who is the controller.

For guests, we process the contents of chat messages, technical metadata (browser locale, device class, IP-derived coarse location), and a per-conversation identifier. We do not require guests to register or provide their name, email address, or phone number to use the chat.

For owners, we process account credentials, billing details, the property and room records you create, the knowledge documents you upload, and your acknowledgement of this policy.

We process personal information only on the grounds permitted by section 11 of POPIA, including performance of a contract (hosting your dashboard and properties), your consent (the acknowledgement you give in section 13), and our legitimate interest in operating, securing, and improving a multi-tenant SaaS.

Section 72 of POPIA (Chapter 11) prohibits the transfer of personal information about a data subject to a third party in a foreign country unless certain conditions are met, including that the recipient country has binding corporate rules, an agreement with the data subject, or a law or binding instrument that provides an adequate level of protection.

InnKite uses third-party infrastructure and model providers that may process personal information outside the Republic of South Africa. We rely on the following Chapter 11 grounds for every such international transfer:

• Application hosting and email: our edge application runs on Cloudflare Workers, and transactional email is sent through Cloudflare Email Service. Cloudflare operates a global edge network, so request handling may occur outside South Africa. See section 7.
• Database: all persistent personal information is stored in a managed PostgreSQL database (Neon) hosted in South Africa (Cape Town, af-south-1). Neon is operated by Databricks. See section 7.
• Rate limiting: short-lived counters (IP and room identifiers, hashed) are stored in Upstash Redis. These counters hold no message content and expire within minutes to hours.
• Large language model (LLM) and embedding providers: our chat, guardrail, intent-classification, prompt-injection, and translation models are served by Mistral AI (Mistral Small and Ministral), and message embeddings are generated by Mistral Embed. Mistral AI is based in France and runs inference in the European Union. See section 6.
• Service providers and subprocessors: only vendors that have signed a written data-processing agreement that imposes POPIA-equivalent obligations are permitted to receive personal information.
• Consent: by acknowledging this policy under section 13, owners consent to the international transfers described here. Guests consent by submitting a message through the chat widget.

Sub-processors

We use the following sub-processors. Each receives only the personal information needed for its function and is bound by a written data-processing agreement where one is required.

• Cloudflare: application hosting (Workers) and, where configured, transactional email delivery (Cloudflare Email Service). Cloudflare processes on a global edge network, so handling may occur outside South Africa.
• Neon, operated by Databricks: managed PostgreSQL database holding all persistent personal information, hosted in South Africa (AWS Cape Town, af-south-1).
• Upstash: short-lived rate-limit counters, keyed by hashed IP and room identifiers. No message content is stored, and counters expire within minutes to hours.
• Mistral AI: inference for the chat, guardrail, intent-classification, prompt-injection, and translation models (Mistral Small and Ministral) and the Mistral Embed embedding model (section 6). Mistral AI is based in France and runs inference in the European Union.
• Resend: fallback transactional email provider, used only when email is not sent through Cloudflare Email Service. Resend is a United States provider and receives the owner’s email address and the message body.
• Telegram: delivery of emergency alerts to the property owner (section 10). Telegram is situated outside South Africa and receives the guest’s full, unscrubbed message when an emergency is detected.

This list is current as of the effective date. We will update it before adding a new sub-processor that processes personal information.

The South African Information Regulator has not, as of the effective date, designated any country as having an adequate level of protection for the purposes of section 72. We nevertheless assess each transfer on a case-by-case basis against the criteria in POPIA and our data-processing agreements.

Every guest message is embedded and then sent to a third-party large language model for the purposes of retrieval-augmented answering, outbound guardrail evaluation, and intent classification. The embedding and language models are served by Mistral AI, which is based in France and runs inference in the European Union. Messages that trigger the deterministic emergency bypass skip model calls entirely and are forwarded to the owner instead (section 10). This constitutes an international transfer under POPIA Chapter 11.

Before any message leaves our infrastructure we run it through a best-effort PII scrubber (see section 8). The scrubber reduces, but does not eliminate, the risk that a name, phone number, email address, or vehicle registration flows to the LLM provider. We disclose this limitation in plain language because POPIA Chapter 11 obliges us to be candid about the residual risk.

All persistent personal information, including tenant records, properties, source documents, embeddings, conversation history, and audit logs, is stored in a managed PostgreSQL database (Neon, operated by Databricks) hosted in South Africa, in the AWS Cape Town (af-south-1) region. Our vector embeddings are stored in that same database.

The application itself runs on Cloudflare’s global edge network, and transactional email is sent through Cloudflare Email Service where configured, falling back to Resend when it is not. This means a request may be handled, and email may be relayed, by infrastructure outside South Africa, and that handling is an international transfer under POPIA Chapter 11 (section 5). Short-lived rate-limit counters are held in Upstash Redis (no message content). Persistent data is not replicated to any other region.

Ephemeral model calls to the LLM and embedding providers described in section 6 are the other exception, and the scrubber described in section 8 runs before those calls.

The PII scrubber we apply to guest messages is a best-effort, regex-based filter. It is designed to catch common South African mobile numbers, email addresses, vehicle registration plates, and self-introduced names (“my name is…”). It is not a guarantee.

The scrubber will not catch:

• Names introduced without a trigger phrase (for example, “booked under [Name]” or “credit card [Name]”).
• Account numbers, ID numbers, passport numbers, or other government identifiers.
• Free-form personal context (allergies, relationships, employer, hotel room number, children’s ages).
• Variants that include unusual punctuation, line breaks, emoji, or transliteration.

We do not advertise the scrubber as a guarantee of confidentiality. Owners and guests should treat every message as if it will reach the LLM provider in unredacted form, and avoid typing personal information that they would not be comfortable sharing with a third-party processor.

The scrubber is currently tuned for English and the most common South African personal-information formats. Coverage of other languages is limited.

• The name-introduction trigger phrases are English-only. In Afrikaans, isiXhosa, isiZulu, Sesotho, Setswana, German, or other languages, the scrubber will not detect a self-introduced name. For example, “igama lam ngu…”, “my naam is…”, or “ich heisse…” will not be redacted by the name layer.
• Non-Latin scripts (Arabic, Mandarin, Hindi, Tamil) are not matched by the name pattern. Names in those scripts will pass through to the LLM provider untouched.
• Phone-number patterns are tuned for South African numbers. International numbers in other formats (E.164 variants, short codes, numbers written with words in between digits) are not reliably detected.
• Email and vehicle-plate regexes are ASCII-only and will not match any non-Latin-character variant.

Owners should warn guests in non-English languages to avoid typing their name, phone, email, or plate into the chat, and should provide a manual contact channel for those conversations.

When a guest message indicates an emergency (for example a break-in, a fire, or a medical crisis), the service bypasses the AI pipeline and immediately alerts the property owner through our Telegram bot. That alert contains the guest’s full message text exactly as typed, including any name, phone number, location, or other personal details it contains.

We deliberately do not run the PII scrubber on emergency alerts. Redaction could remove the very details an owner or emergency contact needs to respond, such as a callback number or where on the property the incident is happening. Emergency alerts are the one place where message content leaves our infrastructure unredacted.

Telegram is a third-party processor situated outside South Africa, so emergency forwarding is an international transfer under POPIA Chapter 11. We rely on the same grounds listed in section 5. The notice shown in the chat widget states that by using the chat you agree to this policy, and it links here.

If you are a guest in an emergency and prefer not to share personal details in the chat, call the emergency numbers displayed in the conversation instead.

Conversation messages are retained on a plan-tiered schedule and then redacted: 30 days on Starter and Starter + Languages, 90 days on Pro, and 365 days on Scale. The free trial uses a 7-day window. Guardrail logs are retained for 7 days as text and 30 days as aggregates. DSR records are retained for 30 days after resolution, with the audit hash preserved for compliance.

To enforce our one-free-trial-per-email rule we keep a one-way cryptographic hash of the email address that started a trial. It is not linked to your account and is not removed when an account is deleted, because its only purpose is to stop a repeat trial. It is kept for as long as the free trial is offered.

The property owner is the controller of personal information collected from their own guests. InnKite is a processor of that information on the owner’s behalf. This means:

• The owner is responsible for telling their guests, in plain language, that they are interacting with an AI assistant backed by a third-party large language model.
• The owner is responsible for honouring a guest’s request to delete or export their conversation, including the request endpoint described in section 14.
• The owner is responsible for the accuracy and lawfulness of any knowledge document they upload to the assistant.
• The owner is responsible for any QR code or short URL they print or display, and for ensuring that the URL does not include any non-public information they do not want disclosed.
• The owner must not use the service to process personal information of children under 18 without taking their own POPIA-compliant consent flow.

InnKite provides the tooling to honour these obligations (DSR request endpoint, data export, redaction CRONs) but the legal duty sits with the owner. InnKite is not liable for an owner’s failure to obtain consent or to honour a guest’s rights.

Before a property can go live, the owner must explicitly acknowledge this policy. The acknowledgement checkbox on the Go Live page is the single point at which this consent is captured. Acknowledgement is recorded as a dated, audit-logged event tied to the owner’s tenant and property. Go live is blocked until acknowledgement is on file.

By acknowledging, the owner confirms that they have read and understood the following:

• Guest messages are logged and transferred to third-party large language model providers as described in sections 5 and 6. The current provider is Mistral AI (EU inference).
• By enabling the bot, the owner authorises InnKite and its AI sub-processors, including Mistral AI, to process guest messages on the owner’s behalf to answer guests, and confirms they may give that instruction as controller.
• The PII scrubber is best-effort and is not a guarantee (section 8).
• The scrubber’s multilingual coverage is limited (section 9).
• All persistent data is stored in South Africa (Neon PostgreSQL, AWS Cape Town) (section 7).
• Emergency alerts forward the guest’s full, unscrubbed message to the owner via Telegram (section 10).
• The owner is the controller of their guests’ personal information and bears the responsibility set out in section 12.

An owner may withdraw acknowledgement by cancelling the subscription, which disables the public chat widget and schedules the tenant for deletion under the retention schedule in section 11. If this policy changes materially, the version number above is increased and a fresh acknowledgement is required before the property can go live again.

Guests have the right to ask what personal information we hold about them, to correct it, to delete it, and to object to its processing. Deletion and export requests can be submitted through the link provided in the chat footer; requests are forwarded to the property owner for action.

EU residents additionally have the right to lodge a complaint with their supervisory authority. South African residents may lodge a complaint with the Information Regulator.

Questions about this policy, requests from data subjects, or notifications from supervisory authorities should be sent to the Information Officer at privacy@innkite.com. The Information Officer’s postal address is TBC. We respond within 30 days.

We will update this policy when our data-processing practices change. The effective date at the top of the page reflects the current version. Material changes are also announced to owners by email at least 14 days before they take effect.