Privacy Policy

This policy explains what Kinsei Lab does with personal data. It covers our own websites, the accounts and billing relationships we hold with customers, and the corporate relationships we hold with partners, suppliers and applicants.

It is written to be read rather than survived. Where a section carries a legal consequence — who answers a request, how long we keep something, where data physically sits — it says so plainly instead of gesturing at it.

Terms used here follow the UAE Personal Data Protection Law: a Data Subject is the person the data is about, a Controller decides why and how data is processed, and a Processor handles data on a Controller's instructions.

Kinsei Lab is an independent product studio. We build and operate our own software products rather than delivering client projects, and each product is run by the same company under a shared operational and security model.

Products currently operated under this policy: Everbird.ai. New products are added to section 5 when they launch, and this policy applies to them from the day they do.

Kinsei Lab is the trading name of Kinsei Lab LLC, a company registered in Sharjah, United Arab Emirates with Sharjah Media City under commercial licence number 2645921.01.

Any reference in this policy to “we”, “us” or “our” means that entity, unless a section names a different one.

This is the umbrella policy. Kinsei Lab LLC is the Controller of account data, billing data and corporate-relationship data across every product we operate — the identity you sign up with, the payment records, the support history, the contract. That does not change when you move between our products, and it does not change when a product publishes its own notice.

Each product also publishes a product-level privacy notice. That notice governs the data processed inside the product itself: the content you create, the files and records you upload, the messages the product sends on your behalf, and anything the product's own integrations pull in. It describes the mechanics of that product, and it can be more specific than this document because it is describing one system rather than all of them.

The division is deliberate and it decides who answers a request. A request about your account, your billing history, your marketing preferences or our corporate records is answered here, by us, under this policy. A request about the contents of a specific product workspace is answered under that product's notice — but it still reaches the same privacy contact in section 7, and we route it internally rather than sending you elsewhere.

Where the two documents genuinely conflict on a point about account, billing or corporate data, this policy governs. Where they conflict on a point about how a product internally handles the content inside it, the product notice governs. If you find a conflict we have not anticipated, tell us — that is a defect in the documents, not something you should have to resolve.

This policy applies to:

It does not apply to third-party sites we link to, to a customer's own end users where that customer is the Controller and we are only processing on their instructions, or to anything you send us through a channel we do not operate.

We are both, on different data, and the distinction changes who you go to.

If you are an individual whose data was put into one of our products by a business that uses us, that business is the Controller. Your rights request goes to them first, and we support them in answering it. If you contact us directly we will tell you who the Controller is and, where we are permitted to, pass the request on rather than leaving it with you.

The same processing can move between the two roles. Security logs generated while running a customer's workspace, for example, are processed under our own responsibility as Controller because we — not the customer — decide that the platform needs them.

Privacy questions, rights requests and complaints all go through one route — the contact form below — and it is read by a person rather than a queue that discards what it cannot classify.

Please say which product or account the request concerns if you can. It is not required, and we will not refuse a request for leaving it out, but it shortens the identity check in section 42.

We have not appointed a formal Data Protection Officer.

The UAE Personal Data Protection Law requires one only where processing meets specific thresholds — high-risk processing arising from new technologies and the volume of data, large-scale processing of sensitive personal data, or systematic and comprehensive evaluation of it. The EU and UK GDPR set out equivalent thresholds. Our processing does not meet them: we do not collect sensitive personal data (section 16), and we do not profile you or make automated decisions with legal effect (section 26).

Saying so plainly is the point of this section. Privacy matters are handled directly by Kinsei Lab, and every request reaches a person through the contact route in section 7 — there is no unattended inbox and no requirement to address a request to a named officer for it to be valid.

If our processing changes such that an appointment becomes mandatory, we will appoint a Data Protection Officer, name them here, and record the change in the version history in section 53.

You can read our sites without telling us who you are. We do not require an account to browse, and we do not gate content behind a form.

Form submissions are stored so we can reply and so we have a record of what was asked. They are not used to build a profile of you, and we do not enrich them against third-party data brokers.

Content data is the category where we are usually the Processor rather than the Controller — see section 6. We do not read it to learn about you, and we do not mine it for marketing.

We collect what is needed to charge you correctly and to keep books that survive an audit: billing name, billing address, the country you are taxed in, any tax registration number you give us, the plan you are on, invoice history, payment status, refunds and chargebacks.

We do not collect or store full payment card numbers. Card details are entered directly into our payment provider's hosted fields and never reach our systems. What we receive back is a token, the card's brand, its last four digits and its expiry — enough to show you which card is on file and to take the next payment, and not enough to make a payment anywhere else.

Billing data sits with the parent entity rather than at product level, because the payment account is held there. Section 23 explains what that means for who you are contracting with.

If you work for a supplier, partner, reseller or prospective customer, we hold your business contact details, your role, the correspondence between us, and the commercial records of the relationship — contracts, statements of work, purchase orders and invoices.

Where a relationship requires it we also collect the compliance data needed to enter into it: company registration details, beneficial-ownership information, tax and VAT registration, and bank details for payment.

If you apply to work with us we collect your CV, the contact details and work history in it, anything you write in a covering note, your responses in interviews, and any work you send as part of an assessment.

We collect references only with your knowledge and only at the point where an offer is realistic. We do not contact a current employer without asking you first.

Retention for unsuccessful applications is in section 20. If you would rather we did not keep your details on file at all, say so and we will delete them at the end of the process instead.

This data is the operational floor of running a service that is available, secure and debuggable. It is retained on short cycles — see section 20 — and it is not combined with content data to profile you.

We do not buy personal data from list brokers, and we do not enrich our records against commercial data-appending services.

We do not seek sensitive personal data — data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic or biometric data, health data, or data concerning a person's sex life or sexual orientation — and none of our products require it to work.

We ask you not to put sensitive data into free-text fields, support tickets or product content where it is not needed. Where a business customer chooses to process sensitive data inside a product, they do so as Controller and are responsible for having a lawful basis for it; our processing of it stays limited to what is needed to run the service for them.

If sensitive data reaches us unsolicited, we delete it unless we are legally required to keep it.

We do not use personal data to make decisions about you that produce legal or similarly significant effects without a human involved — see section 26.

Under the UAE PDPL, processing is lawful where the data subject consents or where one of the specified exceptions applies. Under the GDPR and the UK GDPR, where those apply to us, one of the Article 6 bases must apply. We rely on the following, mapped to purpose:

Where we rely on legitimate interests we have considered whether the processing is necessary, whether a less intrusive route exists, and whether it would override your rights and expectations. You can ask us for the reasoning behind any specific balancing test.

Where we rely on consent, it is a positive action you take — ticking a box, clicking accept, subscribing. Silence, a pre-ticked box or continued use of a page is not consent, and we do not treat it as such.

Withdrawing consent is as easy as giving it, is free, and does not affect the lawfulness of what we processed before you withdrew. It also does not switch off processing that rests on a different basis — we will still bill you, still keep the statutory records, and still send the service messages you cannot opt out of while you hold an account.

Retention is where most privacy policies stop being specific, and it is the area most commonly left undefined in UAE PDPL implementation — organisations document what they collect and never document when it goes. Ours is set out below as concrete periods.

Two things are kept deliberately separate. Statutory bookkeeping retention for a UAE entity is fixed by law and cannot be shortened by a deletion request. Product and account data is ours to define, and is set to the shortest period that still lets us run the service, resolve disputes and defend claims. Collapsing the two into one blanket line would either over-retain the product data or misstate the statutory obligation.

At the end of a period, data is deleted or irreversibly anonymised. Anonymised data — aggregate usage counts with no identifiers — may be kept indefinitely, because it is no longer personal data and cannot be turned back into it.

Marketing email goes only to people who asked for it, or to existing business customers about products related to what they already use. Every message carries a one-click unsubscribe that works without signing in and without a reason.

Service messages are different and cannot be opted out of while you hold an account: outages, security notices, billing failures, changes to terms. They are sent because you have a contract with us, not because you were marketed to, and they contain no promotion.

We do not sell or rent our mailing list, and we do not share it with anyone other than the provider that delivers the mail for us.

Kinsei Lab LLC operates every product under this policy. There is no separate operating company per product, which means the identity you register with is a single account across the studio rather than a fresh relationship each time.

We may tell you about another of our products — in-app, or by email if you are an existing customer and have not opted out. This is disclosed here rather than added later on purpose: retrofitting a cross-product marketing disclosure after the fact would require going back and obtaining fresh consent, which is worse for everyone. If you do not want it, the opt-out in section 21 covers it and takes effect across every product.

If we ever restructure — spinning a product into its own entity, or bringing another company in — section 32 governs what happens to your data, and we will tell you before it takes effect rather than after.

The payment account is held by Kinsei Lab LLC, not by any individual product. That entity is the merchant of record: it is who you are contracting with for the purchase, whose name appears on your card statement, who issues the invoice, and who is answerable for a refund or a chargeback.

This matters for two practical reasons. First, if you dispute a charge, the dispute runs against the parent entity and is resolved there — you do not have to work out which product to raise it with. Second, the billing records that result from that dispute are held at the parent, under this policy, rather than in a product's own systems under its notice.

Card details go directly to our payment provider and never reach our servers. We receive a token, the card brand, its last four digits and its expiry. The provider is an independent Controller for its own fraud-prevention and regulatory-compliance processing, and its own privacy policy governs that — we cannot vary it and do not attempt to describe it here.

Where local tax rules require it, the invoice will show the tax registration and the tax charged. Tax data we collect for that purpose is used for it and for nothing else.

As a UAE-registered entity we are required to maintain accounting records, invoices and supporting documents for periods fixed by law. Those periods are in the retention table in section 20 and are stated separately from product retention because they are not ours to shorten.

Records held for this purpose are removed from operational use and kept for the statutory purpose alone. They are not used for marketing, analytics or product decisions, and access to them is limited to the people who need it for accounting, audit or a regulator's request.

When you contact support we hold the correspondence, the account it relates to and any diagnostic detail you send us. Support staff can see account and billing data. Access to the content inside your workspace is restricted, logged, and used only where it is necessary to resolve the specific issue you raised.

We may quote a support exchange internally to fix the underlying problem. We do not publish it, and we do not use it in marketing without asking you first.

Some of our products use automated processing, including AI models, to do work inside your own workspace — drafting a message, summarising a thread, spotting that something has stalled and suggesting a follow-up. This is disclosed rather than buried because it is a core mechanic of what we build, not an incidental feature.

Where we operate automated checks on our own account — fraud and abuse detection, for example — a positive signal is reviewed by a person before an account is suspended, and you can contest the outcome by contacting the privacy contact in section 7.

We do not share personal data with anyone outside these categories, and we do not disclose it to advertisers or data brokers in any form.

Every provider that handles personal data on our behalf does so under a written contract that binds them to process only on our instructions, to keep it confidential, to apply appropriate security measures, to engage sub-processors only with our permission, to help us answer rights requests, and to delete or return the data when the engagement ends.

We assess a provider's security and privacy posture before engaging them and reassess it while the engagement runs. Where a provider processes data outside the UAE, sections 35 and 36 govern the transfer.

Our payment provider processes card and transaction data. For the parts of that processing it performs on our instructions it acts as our Processor. For its own fraud prevention, anti-money-laundering and regulatory compliance it acts as an independent Controller under its own privacy policy, which we cannot vary.

We receive from it only what we need to run billing: whether a payment succeeded, the token and last four digits of the card, and the details of any refund or dispute.

Lawyers, accountants, auditors, tax advisers and insurers see personal data where a specific matter requires it — a filing, an audit, a claim, a transaction. They are bound by professional confidentiality obligations as well as by contract, and they receive only the data the matter needs.

We disclose personal data to a court, regulator or law enforcement body where we are legally required to, or where it is necessary to establish, exercise or defend a legal claim.

If we are acquired, merge, restructure, or sell part of the business, personal data may transfer to the acquiring or successor entity as part of the assets. Data shared during due diligence is limited, minimised, and covered by confidentiality obligations.

Any successor is bound by this policy in respect of the data it receives until it lawfully gives you notice of a different one. We will tell you before a transfer takes effect, not after, and where the change would materially affect how your data is handled you will be able to close your account and have it deleted first.

We do not sell personal data. We do not rent, trade or otherwise disclose it to a third party for that party's own commercial purposes.

We also do not “share” personal data for cross-context behavioural advertising, in the specific sense that term carries under United States state privacy laws. We do not run advertising networks or advertising pixels on our sites, and there is no advertising identifier to sell.

This is a statement of practice, not of intent. If it ever changes, it changes here first, with notice, and with a working opt-out before any such disclosure begins.

We are established in Sharjah, United Arab Emirates. Our infrastructure and several of our providers are not, so personal data is processed outside the UAE as a matter of ordinary operation rather than as an exception.

Personal data we hold is transferred out of the UAE. This is a live disclosure, not a theoretical one: our hosting and our payment processing both sit outside the country, which means essentially every record described in this policy crosses a border at some point in its life.

The UAE PDPL permits a cross-border transfer where the destination provides an adequate level of protection — because it is recognised as adequate, or because it is bound by a bilateral or multilateral agreement the UAE is party to. Where no such adequacy exists, a transfer is still permitted where appropriate contractual safeguards are in place, where you have given explicit consent, where the transfer is necessary to perform a contract with you or one made in your interest, where it is necessary for a legal claim, or where it is necessary to protect a vital interest.

Our transfers rest on two of those routes. Transfers necessary to deliver the service you have contracted for — hosting your workspace, taking your payment, sending your mail — are made on the contractual-necessity basis, because the service cannot be provided without them. Every other transfer is made under the contractual safeguards described in section 36.

We do not treat consent as the primary route for infrastructure transfers. Consent that you cannot realistically refuse without losing the service is not meaningful consent, and building the architecture on it would be a worse protection than the contractual one.

Where a destination is later recognised as adequate by the UAE Data Office, we rely on that recognition and the contractual safeguards remain in place alongside it. Where an adequacy recognition or transfer mechanism we rely on is invalidated, we reassess the transfer and either move the processing or suspend it — we do not continue on a mechanism that no longer stands.

You can ask us for a description of the safeguards applying to a specific transfer, and we will provide it.

The UAE PDPL reaches beyond the UAE's borders: it applies to a controller or processor outside the country that processes the personal data of people inside it. The same logic runs the other way at us, and we treat it as applying rather than arguing about it.

A Sharjah-registered entity selling to customers in the European Union, the United Kingdom and the United States inherits obligations under each of those regimes regardless of where it is registered, because those laws attach to who we target and whose data we process rather than to where our licence was issued.

Sections 39 and 40 set out the additional rights those regimes give you. Where two regimes apply to the same processing we apply the higher standard rather than the more convenient one.

Exercising a right is free. We will not charge you, and we will not degrade your service because you used one.

Where the GDPR or UK GDPR applies to our processing, you hold the rights in section 38 under those regimes as well, together with:

We have no establishment in the EEA or the UK. Where an Article 27 representative is required for our processing, we will appoint one and name them here.

Where a United States state privacy law applies to our processing of your data, you have the right to know what we collect and why, to access and obtain a copy of it, to correct it, to delete it, and not to be discriminated against for exercising any of those rights.

You also have the right to opt out of the sale of personal information and of sharing it for cross-context behavioural advertising. As stated in section 33 we do neither, so there is nothing to opt out of — but if that ever changes we will provide the mechanism before any such disclosure begins.

We do not use or disclose sensitive personal information for purposes beyond those permitted without a limitation right, because we do not collect it in the first place (section 16).

You may use an authorised agent to make a request on your behalf. We will ask for proof of authorisation and, where the law permits, for you to confirm the agent's authority directly.

There is no template you have to follow and no legal wording you have to get right. If a request is unclear we will ask, and the clock in section 43 pauses only for as long as it takes you to answer.

If the data is inside a workspace belonging to a business customer, we are the Processor and they are the Controller (section 6). We will tell you who they are and, where permitted, forward the request rather than closing it.

We verify identity before acting on a request, because disclosing or deleting someone's data on an impostor's say-so is itself a breach.

Normally this means replying from the email address on the account, or confirming a detail only the account holder would know. We ask for identity documents only where the request is high-risk and no other route works, and we delete any document sent for this purpose as soon as verification is complete.

If we genuinely cannot verify who you are, we will say so and explain what would satisfy us, rather than ignoring the request.

We may refuse a request that is manifestly unfounded or excessive, particularly if it repeats one we have already answered. If we do, we will say why, and tell you how to complain to the supervisory authority.

Complain to us first, through the contact route in section 7. It is the fastest way to resolve it, and most complaints are about something we can simply fix.

If you are not satisfied with our response, or we fail to respond within the period in section 43, you can file a complaint with the UAE Data Office, the supervisory authority established under UAE federal law to oversee the Personal Data Protection Law.

Complaining to us is not a precondition of complaining to the Data Office, and you can go to them directly. If you are in the EEA or the UK you can also complain to your local supervisory authority; if you are in a United States state with its own privacy law, to that state's Attorney General or privacy agency.

Local storage and similar technologies are treated as cookies for the purposes of this section — what matters is that something is stored on your device, not the API used to store it.

We use analytics to see which pages are read and where people give up, so we can fix the second. It is configured to minimise what it collects: IP addresses are truncated or not stored, no cross-site identifier is set, and no data is used for advertising.

Analytics runs on consent. Declining it costs you nothing — the site behaves identically — and we would rather have a smaller, honest picture than a complete one obtained by not asking.

Blocking strictly necessary cookies will break sign-in — there is no way for us to keep you authenticated without them.

No system is perfectly secure, and a policy that claimed otherwise would be lying. What we commit to is that these measures are real, that they are reviewed, and that a failure of them is disclosed under section 49 rather than absorbed quietly.

We maintain an incident process covering detection, containment, assessment, notification and remediation. Every incident is recorded whether or not it turns out to be notifiable.

A notification will describe what happened, what data was involved, what we assess the likely consequences to be, what we have done about it, and what you may want to do. It will not be written to minimise.

Our products are business tools. They are not directed at children, and we do not knowingly collect personal data from anyone under 18.

If we learn that we hold data from a child without appropriate consent from a holder of parental responsibility, we delete it. If you believe a child has given us data, contact the privacy contact in section 7 and we will act on it.

Our sites and products link out to third-party websites, and some products connect to third-party services at your instruction. Those services are operated by other organisations under their own privacy policies, and this policy does not govern them.

Connecting an integration authorises a flow of data between that service and ours within the scopes you approve. You can revoke it at any time, from our side or theirs. We are responsible for what we do with the data we receive; we are not responsible for what that service does with the data it holds.

We update this policy when our processing changes, when we add a product, when a provider handling personal data changes, or when the law does.

Material changes — a new purpose, a new category of recipient, a new transfer, a longer retention period — are notified by email to account holders and posted on this page before they take effect. Non-material changes such as clarified wording are made with the version and date updated, and recorded in section 53.

Where a change requires your consent, we will ask for it. We will not treat continued use of the service as consent to something we did not tell you about.

This policy is effective from 7 August 2026. It is published in English; where it is translated, the English text governs in the event of a discrepancy.