Privacy Policy

1. Overview, and who this is about

1.1. This Policy explains how to be confirmed ("we") handles personal data in connection with KeepSayBot (the "Service"), a platform that helps a business answer the people who message it on Instagram and WhatsApp.

1.2. Two different groups of people appear in this Policy, and we stand in a different relationship to each.

(a) Our customers and their members — the businesses that subscribe, and the people who sign in and use the Service. For them we decide what is processed and why. We are the controller.

(b) The people who message our customers — their customers, who wrote to a business on Instagram or WhatsApp and have never visited us. For them our customer decides what happens, and we act on that customer's instructions. We are a processor, and our customer is the controller.

1.3. If you messaged a business and want to know what it holds about you, or want it erased, the business is who to ask. We cannot make that decision for them, and we will not act on it without their instruction. Clause 14.4 says what we will do.

2. Who is the controller, and when we are a processor

2.1. The controller for the processing described in clause 2.3 is:

to be confirmed, registered in to be confirmed under to be confirmed, to be confirmed.

Privacy contact: to be confirmed. Data protection officer or representative, where appointed: to be confirmed.

2.2. Where we act as a processor, the processing is governed by the Data Processing Agreement with the customer concerned, which sets out the instructions we act on, confidentiality, security, the use of subprocessors, assistance with requests, breach notification and what happens when the agreement ends.

2.3. We are the controller for: account and sign-in data; workspace and member records; subscription, billing and payment records; records of consent to our legal documents; security, audit and diagnostic records; and our correspondence with you.

2.4. We are a processor for: the content of conversations between our customer and the people who message them, the media and recordings in those conversations, transcripts of them, and anything the Service derives from them.

2.5. The split is a legal characterisation of what the Service does, and it is the position taken in these drafts. It is one of the items marked for legal confirmation.

3. What we process

3.1. Account and identity data. Name and e-mail address; sign-in method; the identifier a sign-in provider gives us where you sign in with one; session records; interface language.

3.2. Workspace data. Workspace and Business Profile records, members and their roles, settings, and the knowledge and writing-style material a customer configures.

3.3. Channel authorizations. The authorization a customer grants for an Instagram or WhatsApp account, its scope and expiry, and the account's own identifiers on the platform. The credential itself is a secret and is handled under clause 15.

3.4. Conversation content. What a person wrote; media and voice notes they sent; what the Service prepared and what was sent; who decided to send it; delivery and read state; and timestamps.

3.5. Transcripts. Where transcription is enabled, the words of a voice note as a transcription provider reads them. A transcript is a reading of a recording and can be wrong. Where a person typed a caption on the same message, their own words take precedence over the machine's reading of their voice.

3.6. Derived data. Conversation summaries, facts and preferences the Service records about a person, writing-style examples, lead stage, and the numerical search representations of any of it. Derived data is personal data about the same person. A product that deleted the correspondence and kept the summary has not forgotten anybody, and this Policy does not pretend otherwise.

3.7. Billing data. Plan, interval, currency, amounts, subscription state, payment and refund state, and the identifiers a payment provider gives us. We never receive or store full card numbers.

3.8. Operational data. Queue jobs, outbound delivery records, duplicate-suppression ledgers and audit events. These carry identifiers, outcomes and counts — never message bodies.

3.9. Technical data. IP address, request metadata and error diagnostics, for security and for finding faults.

3.10. We do not ask for special categories of personal data. A person writing to a business may nonetheless disclose something sensitive in a message, because people do. Our customer decides what to do about that; we process what their conversations contain.

4. Where it comes from

4.1. From you, when you create an account, configure a Workspace, write to support or buy a subscription.

4.2. From the messaging platform. The largest category of personal data we process does not reach us from the person it concerns: it arrives from Instagram or WhatsApp, as a notification that somebody has messaged a business that authorized us. That person gave their information to the platform and to the business, not to us.

4.3. From a sign-in provider, where you choose one, which tells us the e-mail address and an account identifier.

4.4. From a payment provider, which tells us the state of a payment.

4.5. Generated by the Service: transcripts, summaries, drafts, search representations, decisions and audit records.

5. Why we process it

5.1. To provide the Service: receiving messages, assembling the context for a reply, preparing a reply, applying safety rules, queuing and delivering what is sent, and keeping the record.

5.2. To transcribe voice notes, where that is enabled and an allowance remains.

5.3. To retrieve relevant knowledge and style material, which requires computing and comparing search representations of text.

5.4. To operate accounts, subscriptions, capacity, allowances, invoicing, refunds and disputes.

5.5. To keep a record of who decided what: which person approved or edited a reply, what was sent, and on whose authority. This exists so that a disputed message can be accounted for.

5.6. To keep the Service secure and to prevent abuse, including duplicate-suppression, rate limiting and investigating faults.

5.7. To communicate with you about your account — most importantly to send a sign-in link when you ask for one. There is no marketing mail in the Service.

5.8. To meet legal obligations, including accounting and tax record-keeping, and to establish or defend legal claims.

6. Legal bases

6.1. Where we are the controller:

6.2. Where we are a processor, the legal basis for processing conversation content is the customer's, not ours. Our customer is responsible for having one, for the consent it may require, and for telling the people concerned. Our basis for acting is the contract with that customer.

6.3. Where we rely on legitimate interests, we have considered the interests and rights of the people concerned, and you may object — see clause 14.

7. Automated assistance and AI providers

7.1. The Service prepares replies using third-party models. To do so it sends the model what it needs for that one reply: a bounded part of the conversation, the knowledge and style material retrieved for it, and a transcript where one exists.

7.2. What is sent is bounded and deliberate. The model is given a structured set of labelled pieces rather than one assembled block of text. Content that did not come from the customer's own configuration is treated as untrusted: it is cleaned, limited in length, and marked so the model treats it as material to read rather than as instructions to follow. The history window is bounded and retrieval results are capped. Nothing reaches a model that was not read for that reply, and a credential never reaches a model at all.

7.3. The categories of provider involved are: a provider that prepares text; a provider that transcribes audio, where transcription is enabled; and a provider that computes search representations, where that is enabled. The Service is built so that a provider can be replaced, and the current list is maintained with the subprocessor arrangements rather than written into this Policy, so that a change is a notified change rather than a silent edit to a web page.

7.4. A note on model training. This Policy does not state that content sent to a provider is excluded from training that provider's models, because that depends on each provider's terms and on how the account is configured, and we will not claim it until it is verified for each provider. See `../OWNER_DECISIONS.md`, D-14.

7.5. Automated decisions. The Service does not use personal data to make automated decisions with legal or similarly significant effects. It drafts and sends messages. Where a case falls into a category the Service treats as high-risk — payment disputes, legal questions, high-risk advice, security matters, serious complaints, unusual commitments, or a missing material fact — it holds the reply for a person instead of sending it.

8. Human review and takeover

8.1. A person can take over any conversation at any time, and when they do, automated sending for that conversation stops until it is resumed.

8.2. When a person edits a prepared reply before approving it, the Service may keep their final wording as an example of the customer's writing style. It is kept as a style example and not as a business fact.

8.3. Each decision a person makes — approve, edit and send, dismiss, claim — is recorded with the decision, the person, the wording and the authority they granted, as one record. This is why a disputed message can be traced to a decision rather than to a system.

9. Recipients and sharing

9.1. We share personal data with: the messaging platform concerned, because it is the channel; the providers in clause 7, for the purposes stated there; a payment provider, for billing; an e-mail delivery provider, for sign-in links; and our hosting and infrastructure providers.

9.2. We may disclose data where the law requires it, to establish or defend a legal claim, or to a successor in a reorganisation or sale, in which case this Policy continues to apply until replaced.

9.3. We do not sell personal data, and we do not share it for advertising.

10. International transfers

10.1. Several of the providers in clause 9 are established outside the European Economic Area, principally in the United States.

10.2. Where personal data is transferred outside the EEA, an appropriate transfer safeguard is required. The specific instrument relied on for each provider is being confirmed and is not stated in this draft. A privacy notice that names a mechanism nobody has verified is worse than one that says the assessment is pending. See `../SUBPROCESSORS.md` and D-5.

10.3. The location of our own hosting and database is to be confirmed.

11. Retention

11.1. to be confirmed for account and Workspace data after a Workspace is closed.

11.2. to be confirmed for conversation content and what is derived from it, unless deleted earlier on request.

11.3. to be confirmed for billing and invoice records, which is ordinarily set by the accounting law applying to the seller.

11.4. to be confirmed for records of consent to our legal documents. These records cannot be altered. They are append-only by design, because evidence of what somebody agreed to is worthless if it can be edited afterwards. Clause 12.5 explains what that means for a deletion request.

11.5. What is deleted on a clock today, rather than on request:

(a) part-completed channel authorization states expire and are cleared hourly;

(b) the platform keeps its own copy of a recording and applies its own expiry to it. A deployment may instead be configured to ask the platform to delete that copy as soon as a transcript is stored, which is irreversible and is therefore not the default;

(c) a withdrawn channel credential leaves its record in place with the secret replaced by a marker, so that the history of the connection stays interpretable;

(d) a recorded fact about a person that has reached its expiry is not used, and is removed when a deletion removes it.

Unresolved. Every period in 11.1–11.4 is a decision, not an omission. See `../OWNER_DECISIONS.md`, D-11.

12. Deletion

12.1. Deletion is requested in one of four scopes, chosen when the request is made and never widened afterwards:

12.2. A deletion runs as a durable process and finishes in one of two states: completed, or partially failed. A partial failure is final rather than retried on a schedule, because a deletion that removed some things and not others must not be reported as done.

12.3. The platform's copy goes first. A media identifier is the only handle we have on a recording held by the messaging platform, so the request to delete it is made before the record naming it is removed. If that request cannot be made, the deletion is recorded as a partial failure — a deletion reported as completed while a voice note remained on somebody else's servers would be untrue.

12.4. An objection to contact is kept, and it is not a deletion. You cannot both erase somebody and remember never to message them. Where a person has asked not to be contacted, the record of that objection and the platform's own identifier for them are kept, while their names, contact details, correspondence and derived data are removed. That is the least that honours the request they actually made.

12.5. What a deletion cannot remove. Records of consent to our legal documents, and the billing and accounting records the law requires us to keep, are not removed by a deletion request. Where a right to erasure applies, it is limited by the legal obligation that requires the record — and that limit is stated here rather than discovered later.

13. Export and requests

13.1. One person's data can be exported at a time. The action is reserved to a Workspace's owner or administrators, is limited in size, and is recorded as part of the same operation that reads the data.

13.2. The record of an export holds counts, not content. A log that quoted an export would be a second copy of it, sitting where every administrator could read it indefinitely.

13.3. A request about a person in a Business Profile the requester cannot see is answered exactly as a request about a person who does not exist. Confirming that somebody exists is itself disclosing something about them.

14. Your rights

14.1. Where we are the controller, and subject to the conditions the applicable law attaches to each, you may ask for access to your personal data, correction, erasure, restriction, portability, and may object to processing based on legitimate interests.

14.2. Write to to be confirmed. We will respond within the period the applicable law allows.

14.3. You may complain to a supervisory authority. The authority for our establishment is to be confirmed; you may also complain to the authority where you live or work.

14.4. If you messaged a business that uses the Service, we are the processor and not the controller. Ask that business. If you reach us instead, we will tell you so, and we will pass your request to the customer concerned rather than act on it ourselves — acting on it would mean overriding the instructions of the controller who is responsible for you.

15. Security

15.1. Channel credentials are encrypted at rest with the Workspace, the credential's identity and its purpose bound into the encryption, so that a record cannot be decrypted in the wrong context. The plaintext exists only in memory, between being read and being used.

15.2. Nothing logs a secret. Error reporting passes through an allow-list of fields and deliberately avoids the place where HTTP clients expose request configuration, which is where a token would otherwise appear. A sign-in link is treated the same way: it is a credential for one click, and it is never written to a log.

15.3. Authorization is checked on every request against the member's current role and the Business Profiles they may see, and is not cached in a session — so a revoked role takes effect at once. Scope alone is not permission: reading a conversation and taking the whole of somebody's history out of the Service are different capabilities.

15.4. Taking the whole of a person's history out, erasing it, or erasing what the Service has learned about them are reserved to a Workspace's owner or administrators.

16. Cookies

16.1. The Service sets only what it needs to sign you in and keep you signed in safely, and one cookie recording the language chosen on the public sign-in page so that the page and the sign-in link are in the same language.

16.2. There is no advertising or analytics cookie in the Service. The Cookie Notice describes each cookie and its purpose.

17. Communications

17.1. We write to you about your account: a sign-in link when you ask for one, and notices about security, billing, service changes and legal documents.

17.2. There is no marketing mail, and therefore nothing to unsubscribe from. If that changes, this Policy and the consent position change with it.

18. Children's data

18.1. The Service is sold to businesses and is not directed at children. An account holder must be at least to be confirmed.

18.2. A person who messages one of our customers may be a child, which is a matter for that customer's own obligations. If you believe we hold a child's data without a proper basis, write to to be confirmed.

19. What we do not do

Stated plainly, because a notice that only lists what is processed leaves the reader to guess at the rest.

19.1. We do not sell personal data.

19.2. We do not share personal data for advertising, and there is no advertising or analytics tracking in the Service.

19.3. We do not use the content of our customers' conversations to improve anything outside the Workspace it belongs to. Knowledge and style material learned in one Workspace is used for that Workspace.

19.4. We do not read a Workspace's conversations as a matter of course. Access by our staff happens for support, security or a legal obligation, and is recorded.

19.5. We claim nothing about a provider's own model training. See clause 7.4.

20. Changes to this Policy

20.1. A change is published as a new version with its own effective date. A version already in force is not edited, because the question "what was this person told?" has to stay answerable.

20.2. Material changes are notified in the Service or by e-mail before they take effect, where practicable. Where acceptance is required, you will be asked for it and the acceptance recorded against the new version.

21. Contact

to be confirmed to be confirmed to be confirmed

Privacy: to be confirmed · Support: to be confirmed · Legal: to be confirmed Data protection officer or representative, where appointed: to be confirmed