Kay-X Privacy Policy

1.The short version

This section is a summary. The rest of the document is the detail. If the two ever disagree, the detail governs — but we have tried hard to make sure they do not.

• We record and keep voice data. When someone speaks to a service built on Kay-X, we store the audio, the transcript, and the values we pulled out of it — an amount, a phone number, a medicine name, whatever the business asked for.
• We use that data to train and improve our models. Krio has almost no language technology. Our models get better because real Krio speech flows through them. We state this plainly because it is central to the service, not incidental to it.
• Real people listen to some recordings. Trained reviewers, paid for their work, listen to audio and read the values extracted from it in order to correct mistakes. This is how we produce accurate training labels.
• We do not sell it, and we do not advertise. We do not sell or rent personal data, we run no advertising, we build no advertising profiles, and we do not use this data to make decisions about individual callers.
• We do not try to identify anyone by their voice. We build no voiceprint and run no speaker identification.
• Three different people are involved and they are not the same. Kay-X, the business that holds the API key, and the person whose voice is processed. Section 3 explains who is responsible for what. In short: the business decides what to collect and must obtain the caller's consent; we process it and improve our models with it.
• We are honest about what we have not built yet. Where this policy promises something we are still building — a training opt-out is the main one — it says so.

2.What we collect, and everything that happens to it

This is the whole picture in one place. Every row is something the system actually does today — not something it might do.

3.Three parties, and who is responsible for what

Almost every misunderstanding about a platform like this comes from collapsing three different people into one. They are distinct, and so are their obligations.

We have no direct relationship with the end user. We do not know who they are, we have no way to contact them, and we cannot obtain their consent ourselves. That is why the obligation to obtain it sits with the business customer, and why it is written into the Terms & Conditions as a binding warranty rather than left as an expectation.

4.How we use your data to train and improve our models

This is the section most people are looking for, so it is near the top rather than buried at the end.

We use the audio, transcripts, extracted values and corrections that pass through Kay-X to train and improve our models. Not 'may from time to time'. We do, as a matter of course, on production traffic.

Why the service works this way

Krio is spoken by most of Sierra Leone and supported by almost no software. There is no large licensed corpus of Krio speech to buy, no off-the-shelf Krio recogniser, and no vendor to switch to. The only way a Krio speech system gets good is for real Krio speech — real accents, real background noise, real phone lines, real ways of saying a number — to flow through it and for its mistakes to be corrected.

So the exchange is a straightforward one, and we would rather state it as a deal than dress it up. You send us Krio speech. We use it to make the models better. The better models are what you are paying for, and every customer gets the benefit of the aggregate — a pharmacy in Bo improves the recogniser that a logistics company in Freetown depends on. A customer joining next year inherits everything learned this year.

What, specifically, we do with it

• Train and fine-tune our Krio speech recognition models.
• Train and improve our Krio speech synthesis models, so that read-backs sound natural.
• Improve how we interpret a request and extract values from it — how Krio speakers actually say amounts, phone numbers, dates and quantities.
• Measure quality, find failure modes, and build the evaluation sets we test against.
• Curate Krio language resources, through our review platform KACCP.

Human review

Trained reviewers, who are paid for their work, listen to recordings and read the values extracted from them. This is not an edge case or an occasional audit — it is the core of how accurate training labels are produced. A reviewer may hear a caller say an amount, a phone number or a name, and will see those values alongside the audio in order to judge whether the transcript is right.

Reviewers work under confidentiality obligations and role-based access controls, and see only what they need in order to correct a transcript. We call this out prominently because it is the disclosure most easily missed, and because a person saying their phone number out loud deserves to know that another person may hear it.

Curated Krio language resources

We curate Krio speech corpora in order to build language technology for a language that has none. Our review platform holds two separate streams: recordings made by contributors who registered and consented to that use, and audio captured from production traffic. The two are tracked separately by origin, and corpus exports exclude production audio by default.

Protections that apply to training use

The following are binding commitments, not aspirations:

1. 1Purpose limitation. Data described in this section is used only to develop, train, evaluate and improve language and speech models and the services built on them. It is not used for any other purpose.
2. 2No sale. We do not sell, rent, licence or otherwise make available personal data to any third party for that third party's own purposes. We do not supply data to data brokers.
3. 3No advertising. We run no advertising business. We do not use this data to target, select or measure advertising, and we do not build advertising profiles.
4. 4No profiling of end users. We do not construct profiles of individual callers, do not score them, and do not make or support automated decisions that produce legal or similarly significant effects about them.
5. 5No biometric identification. We do not build voiceprints, we do not perform speaker identification or verification, and we will not use voice data to recognise a specific individual across interactions.
6. 6De-identification and aggregation. Before data is used to train a model we will remove or replace direct identifiers, separate data from the account that produced it, and work with it in aggregate. Where a value that identifies a person is intrinsic to the utterance itself — a phone number spoken aloud is part of the audio — we will substitute or mask it in derived training material rather than propagate it. Parts of this are commitments we are still implementing; see section 9 and the honesty note below.
7. 7Confidentiality of human review. Everyone with access to recordings is bound by confidentiality obligations and access is limited by role.
8. 8No re-identification. We will not attempt to re-identify any individual from de-identified or aggregated data, and we will not permit others to do so.

5.What we never do

Stated separately from section 4 so that it is quotable on its own. We do not:

• Sell, rent or trade personal data.
• Use voice data, transcripts or extracted values for advertising, or share them with advertisers.
• Build advertising or behavioural profiles of end users.
• Build voiceprints or perform speaker identification.
• Use the contents of a caller's request to make decisions about that caller.
• Disclose one business customer's data to another business customer.
• Use a business customer's data to compete with that customer.
• Attempt to re-identify individuals from de-identified data.

6.Legal bases for processing

Sierra Leone does not currently have a general data protection statute in force, so there is no domestic statutory list of lawful bases to map onto. We nevertheless set out our bases in the internationally recognised form, because the Bill now before Government is aligned to those standards and because many of our customers will have obligations of their own.

7.Who we share data with

We share data with the subprocessors below, and with nobody else except where we are legally compelled to, or where we must in order to establish or defend a legal claim.

If we ever sell the business or merge, personal data may transfer as part of it. If that happens, this policy continues to apply to data collected under it until it is replaced with notice.

8.Sending data outside Sierra Leone

We must be direct about this. Recordings and transcripts do not stay in Sierra Leone. They are stored and processed on infrastructure operated principally in the United States — Google Cloud Storage, OpenAI, Stripe and Vercel — and our own speech models run on a distributed GPU network whose node locations are not fixed.

Sierra Leone has no data protection statute in force and therefore no statutory cross-border transfer regime, no adequacy mechanism and no supervisory authority to authorise a transfer. Rather than treat the absence of a rule as permission, we commit to the following:

1. 1We will impose contractual data protection obligations on each subprocessor that receives personal data, at a standard no lower than this policy.
2. 2We will not transfer personal data to a subprocessor that has not accepted those obligations.
3. 3We will keep and, on request from a business customer, disclose an up-to-date list of subprocessors and the categories of data each receives.
4. 4When Sierra Leone brings a data protection Act into force, we will bring our transfer arrangements into line with it and give notice of any resulting change.

9.How long we keep things

The periods below are the commitments we intend to adopt, and each needs a number confirmed before this policy takes effect:

A model already trained cannot be untrained. If data has been incorporated into a trained model, deleting the source record does not remove its influence from the model. We can delete the record, stop using it in future training, and exclude it from future corpora. We cannot reverse training that has already happened, and we will not claim to.

10.Security

• Passwords are stored as bcrypt hashes. We never store a password in plain text and cannot recover one.
• API key secrets are stored as salted SHA-256 hashes. We cannot show you a key again after it is created.
• API access is authenticated on every request, with per-key rate limits and quotas.
• Access to recordings is role-based, and everyone with access is under confidentiality obligations.
• Data in transit is protected by TLS.
• Dashboard sessions use a single strictly-necessary, HTTP-only cookie.

No system is perfectly secure. If a breach affects your data we will notify you within [BREACH_NOTIFICATION_WINDOW] of becoming aware of it, with what we know and what we are doing. If you find a vulnerability, report it to [PRIVACY_CONTACT_EMAIL]; we will not pursue good-faith security research.

11.Rights, and how to exercise them

If you are a business customer

Contact [PRIVACY_CONTACT_EMAIL] to access, correct, export or delete your account data, to ask for the current subprocessor list, or to request exclusion from model training.

If you are an end user whose voice was processed

You almost certainly reached a Kay-X-powered service by calling or messaging a business, not by visiting this website. We hold your recording but we do not know who you are and have no way to reach you.

Contact the business you were speaking to. They know who you are, they decided what to collect, and they can identify your session to us. When a business customer passes us a request on your behalf, we will act on it and respond within [DATA_SUBJECT_REQUEST_SLA]. You can also write to us directly at [PRIVACY_CONTACT_EMAIL], but we will usually need the business's help to locate your data.

Subject to what the law requires and to the limitation about trained models in section 9, we will support requests to access the data we hold about an interaction, correct it, delete it, or stop using it for training.

12.Obligations of business customers

These are conditions of using Kay-X and they are repeated as binding warranties in the Terms & Conditions. If you hold an API key, you must:

1. 1Have a lawful basis for collecting the caller's voice and sending it to us, and be able to evidence it.
2. 2Tell callers, before you record them, that they are being recorded; that the recording and what they say will be used to improve Krio language models; and that trained reviewers may listen to it. Section 13 gives you a script.
3. 3Obtain consent where consent is the applicable basis, and give callers a way to refuse that does not simply deny them the service where that would be unlawful.
4. 4Not send us data you have no right to send, and not send special-category data unless you have a valid basis and have told us.
5. 5Comply with the rules of your own sector. If you operate in health, financial services, payments or government, those rules are yours to meet; using Kay-X does not displace them and we do not advise on them.
6. 6Pass on to us, promptly, any data subject request that concerns data you sent us, and help us identify the relevant session.
7. 7Not use Kay-X to identify or authenticate a person by their voice.
8. 8Keep your API key secret, and tell us promptly if it is exposed.

13.For callers: this policy in Krio

Most people whose voices are processed by Kay-X are Krio speakers in Sierra Leone, speaking into a phone. Many will never see an English-language web page, and adult literacy in Sierra Leone is low enough that a written English policy on its own protects nobody. A privacy notice that cannot be understood by the person it concerns is not a privacy notice.

So here is the substance of this policy in Krio, in the same plain register the Kay-X system itself speaks. It is a summary, not a translation of the whole document, and the English text above governs.

14.A consent script you can play to callers

Section 12 requires you to tell callers what is happening before you record them. For a caller on a feature phone, a link to a web page does not do that. A few seconds of spoken Krio at the start of the call does.

You are free to use, adapt and record the script below. You can synthesise it with the Kay-X speech endpoint, or record a person reading it. Keep whatever record of the caller's answer your own legal advice requires.

15.Children

Kay-X is sold to businesses, and an account holder must be at least [MINIMUM_AGE]. We do not knowingly collect data from children through our dashboard.

We cannot tell how old a caller is from their voice, and we will not try to infer it. Business customers must not direct a Kay-X-powered service at children, and must not send us recordings of children, without a valid basis under whatever law applies to them. If you become aware that you have, tell us and we will delete the recordings.

16.The legal framework this policy is written against

We set this out openly because the position in Sierra Leone is unusual and our customers deserve to understand it rather than be handed a policy that quietly implies a regime that does not exist.

• Sierra Leone has no general data protection statute in force. There is no data protection authority and none has been appointed, and 'personal data' is not defined anywhere in Sierra Leonean law. The Data Protection and Right to Access Information Bill was validated nationally in November 2025, and on 21 April 2026 Cabinet approved a national data protection policy, approved the repeal of the Right to Access Information Commission Act, and directed that the Bill be finalised and tabled in Parliament. As at the date of this document it has not been passed or assented to.
• The Constitution of Sierra Leone, 1991, section 22(1) provides that "Except with his own consent, no person shall be subjected to the search of his person or his property or the entry by others on his premises, or interference with his correspondence, telephone conversations and telegraphic and electronic communications." Section 22(2) sets out the limitations. This is the strongest privacy protection currently in force in Sierra Leone, and it is expressly framed around the individual's consent.
• The Cyber Security and Crime Act, 2021 (Act No. 7 of 2021, assented 25 November 2021) is in force. It is not a data protection statute. It creates offences including unauthorised data interception and unauthorised data interference, and it grants investigative powers including production orders, expedited preservation of traffic data, real-time collection of traffic data and interception of content data, subject to judicial oversight and to principles of necessity and proportionality.
• Sierra Leone has signed the ECOWAS Supplementary Act on Personal Data Protection and the African Union's Malabo Convention. [UNVERIFIED: whether either has been domestically ratified or given effect by implementing legislation. Secondary sources record signature only.]
• The Telecommunications Act, 2006 provides some protection for personal data processed by telecommunications network operators. Kay-X is not a network operator, but a business customer delivering a service over a telecom channel may be affected.

In the absence of a statute in force, this policy is written to internationally recognised data protection principles — purpose limitation, data minimisation, storage limitation, transparency, security and accountability. Those are the standards the Bill is drafted against, so aligning now should mean little change when it commences. Where a business customer is itself subject to a data protection law of another country, we will work with them to meet it.

17.Changes, and how to contact us

If we make a material change to this policy — particularly to how we use data for training — we will notify business customers by email at least [NOTICE_PERIOD_TERMS_CHANGE] before it takes effect, and update the date at the top of this page.

There is no data protection supervisory authority in Sierra Leone with which to lodge a complaint at present. If one is established, we will update this section with its details.