2. Information We Collect and Use
We follow the principles of lawfulness, fairness, necessity, and good faith. We process information only as needed to provide product features, perform our contract with you, protect security, respond to your requests, or comply with applicable laws and regulations. Unless the law allows otherwise or the information is necessary for a core feature, you may refuse to provide certain information or disable permissions, but the related feature may not work.
2.1 Chat Recognition and Reply Assistance
SayPilot is a user-triggered chat reply assistant. When you tap the floating assistant, generate reply suggestions, view draft suggestions, or ask SayPilot to review earlier context on a supported chat conversation screen, we may process:
- Currently visible chat text, conversation title, group title, message direction, sender display name, message-type placeholders, and timing or ordering cues.
- Input draft text, reply style, reply intent, banned words, relationship labels you enter for the other person and yourself, group reply targets, and whether an @ mention is needed.
- UI node text, control positions, page state, and basic screen structure, used to decide whether the current page is a supported chat conversation.
- Additional visible messages if you actively trigger history backfill or ask SayPilot to review more context. In that case, the App may briefly scroll the current chat page.
We use this information to understand the current conversation, generate candidate replies, evaluate whether a draft is appropriate, provide conversation summaries, help infer relationship or identity context, improve candidate ranking, and reduce repeated setup.
SayPilot does not send chat messages for you, does not tap a third-party chat app's send button, and does not write generated content into a third-party chat input box on its own.
SayPilot does not obtain chat records by reading third-party chat app databases, private directories, encryption keys, non-public interfaces, hooks, injection, cracking, or protocol emulation. It does not bulk export, sell, or collect chat records for purposes unrelated to reply suggestions.
2.2 Cloud Generation and AI Processing
When you use cloud generation, SayPilot sends the minimum context needed for reply generation to the SayPilot cloud service at https://www.getsaypilot.com over HTTPS. This may include:
- Request ID, request time, app version, request status, context source, and necessary model request metadata.
- Currently visible chat messages, conversation title, input draft, reply settings, group reply target, and local conversation or contact profile summaries you allow for the request.
- Screenshots or screenshot recognition results you allow for that request.
- Generated results, including candidate replies, draft evaluation, conversation summaries, model suggestions, relationship/identity hints, and profile review results.
Before a reply-generation request is sent, SayPilot shows a Pre-send Check that summarizes the selected chat context and reply settings. You can review the selected transcript, confirm generation, or cancel. The confirmation applies only to the current request; it does not enable background chat collection or automatic message sending.
Before building a cloud generation request, SayPilot locally redacts structured text where possible. The redaction replaces high-risk items such as phone numbers, email addresses, verification codes, passwords or passphrases, government ID numbers, passport numbers, bank card numbers, API keys or tokens, payment or transfer account identifiers, and precise address fragments. Redaction does not hide ordinary nicknames, names, relationship terms, or regular chat meaning by default, and it does not change the backend request schema.
The SayPilot backend may call AI model providers enabled in the current cloud routing configuration, or other necessary service providers, to generate reply suggestions, draft evaluations, conversation summaries, and profile review results. Specific provider names, purposes, data types, and regions are described in Appendix 3 of this Policy and the public website version. Model provider secrets should not be embedded in the client app package.
Please note that redaction is not the same as anonymization, and it may not detect or replace every sensitive item. We recommend that you do not intentionally submit passwords, payment verification codes, government ID numbers, bank card numbers, precise locations, contact lists, medical records, children's sensitive information, trade secrets, or other sensitive information unrelated to reply suggestions in chats, drafts, screenshots, or feedback. If you submit another person's personal information, you must make sure you have a lawful basis or authorization to do so.
2.3 Screenshot Recognition and OCR
When you actively trigger screenshot recognition, screenshot fallback, or manual screenshot mode and approve the Android system prompt, SayPilot may process the current screenshot, OCR result, screenshot area, screenshot time, and recognition status. A screenshot may include visible chat content, draft text, or other information shown on the screen.
Screenshot recognition is mainly used when the accessibility service is unavailable, disconnected, or unable to reliably read the current chat page. SayPilot does not continuously record the screen in the background. You may refuse screen capture permission; if you do, accessibility-based text recognition and existing local context may still be available.
If you choose cloud generation and allow screenshots to be included, the original screenshot or screenshot data may be sent to SayPilot cloud services and model providers for the current request, so they can understand the chat content and generate reply suggestions.
The first version does not blur or mask the screenshot image itself. The original screenshot may be used for the current cloud screenshot recognition or multimodal understanding request. Chat text, OCR output, or structured screenshot results returned from cloud recognition are locally redacted where possible before they are used for generation, long-term local memory, or feedback diagnostic export.
2.4 Local Settings, Conversation Memory, and Contact Profiles
To reduce repeated setup and make suggestions more relevant, SayPilot may store the following information on your device:
- Global reply preferences and default switches, plus long-term relationship, reply style, reply language, banned-word, and memory settings for eligible named direct conversations.
- Contact notes, the other person's identity, your identity, conversation summaries, and recent chat summaries for eligible named direct conversations.
- Long-term profile signals, preferences and taboos, interaction profiles, profile evidence, update time, confidence, and similar local profile information for eligible named direct conversations.
- On-device generation history created after you actively trigger generation, including candidate replies from direct or group chats and related context needed to display and review that result.
- Records showing that you acknowledged prominent permission disclosures, screenshot permission disclosures, app cache, temporary screenshot previews, and feedback export caches.
Before conversation memory, AI reply history, profile summaries, profile evidence, draft previews, and conversation previews are saved, the client locally redacts high-risk sensitive fragments where possible.
Reply intent, group reply targets, group reply scope, and whether an @ mention is needed are used only for the current runtime state or generation request. They are not stored as long-term group conversation memory or group contact profiles. Group chats do not create long-term conversation memory or contact profiles. However, group-chat candidate replies and the related context needed to review that result may be stored as separate on-device generation history until you clear local assistant data, newer history replaces the record, or you clear app data or uninstall the App. Generation history is not used as a long-term group profile.
This information is mainly stored in the App's private directory, SharedPreferences, database, or cache. You can clear local assistant data from "Management Center - Help and Feedback - Privacy and Local Data". After clearing, local profiles, conversation memory, default settings, permission confirmation records, and temporary caches will be reset.
Clearing local data does not automatically delete records that have already been sent to the cloud backend, model providers, or feedback handling systems.
2.5 Accounts, Sign-In, and Entitlements
Some cloud generation, quota sync, entitlement records, purchase records, feedback tracking, or cross-device features may require an account. Depending on server-side configuration, SayPilot may support email verification codes, phone verification codes, Google sign-in, Passkeys, or other sign-in methods. The methods actually available are those shown in the App.
When you use account features, we may process account ID, email address, phone number, verification-code request and verification status, necessary identifiers returned by Google sign-in, Passkey registration or sign-in challenges and verification results, login tokens, session status, account creation and login time, registration and sign-in IP addresses, authentication method, entitlement quota, subscription status, and risk-control status.
When an account is first created and during later sign-in or authentication requests, the server may record the public egress IP address it observes and associate the registration IP or recent sign-in IP with the account. We use this information to detect unusual registrations or sign-ins, prevent abuse, protect account security, and perform necessary security audits. The address may be affected by carrier networks, shared networks, VPNs, or proxies and does not represent a precise physical location.
We do not ask you to provide bank card passwords, payment verification codes, or third-party account passwords inside the SayPilot client. Please protect your email, phone number, Google account, Passkey, device unlock method, and other credentials.
2.6 Payments, Memberships, and Purchases
As of the last updated date of this Policy, SayPilot offers Google Play Billing one-time credit packs in the public Android release. The App may show the credits_30, credits_100, and credits_300 product IDs, prices supplied by Google Play, purchase status, and restore-purchase status. Subscriptions, external payment methods, simulated payments, and test payment features are not offered to ordinary release users in this release.
When you buy, restore, receive a refund for, or otherwise manage a Google Play credit pack, we may process product IDs, order numbers, purchase tokens, payment status, credit amounts, refund status, voided-purchase status, purchase restoration results, and payment verification results. Sensitive payment credentials such as payment card numbers are normally handled directly by Google Play or the relevant payment provider, and should not be collected directly inside the SayPilot client.
2.7 Feedback, Support, and Diagnostics
When you submit feedback, export diagnostic files, attach screenshots, or contact us, we may process the issue description, contact details, device model, system version, app version, permission status, request status, error logs, request IDs, conversation summaries, screenshots, diagnostic files, and communication records you provide.
We use this information to investigate issues, respond to you, improve the product, handle complaints, verify account or data deletion requests, and maintain service security. You may choose not to submit feedback materials, but this may limit our ability to diagnose or resolve the issue.
When you export a feedback diagnostic package or copy diagnostic information, chat text in recognition details, request log summaries, and user notes is locally redacted where possible. Contact details you actively enter are kept so we can reach you. If you choose to attach a recent screenshot, the original screenshot may still contain unredacted screen content; please review it before submission.
2.8 Device, App, and Security Logs
To keep the software and services running securely, troubleshoot issues, measure service quality, and prevent abuse, we may process app version, system version, device model, network request status, cloud API status, crash information, error logs, request latency, request success or failure status, IP address, account login status, quota usage status, and necessary security or risk-control information.
Cloud requests may also carry a randomly generated installation client identifier, a one-way hash of Android ID, and a device fingerprint derived from that hash. The raw Android ID is not sent. These pseudonymous identifiers are used to bind login-verification requests, provide anonymous trials, detect multiple accounts or repeated claims on the same device, perform security and abuse prevention, associate necessary diagnostics, and measure product usage. They may be associated with a SayPilot account after sign-in.
SayPilot does not read contacts, SMS, call logs, precise location, photo library files, passwords, payment verification codes, or content unrelated to reply suggestions for the purpose of generating replies.
SayPilot also does not read third-party chat app local databases, private directories, encryption keys, or non-public interfaces for reply suggestions, and does not use hooks, injection, cracking, or protocol emulation to bypass the normal permission and security boundaries of third-party apps.
2.9 Product Analytics and Pseudonymous Identifiers
When the configured SayPilot cloud service is available, the Android App automatically reports a limited set of product analytics events. These include first open and app launch events; permission guide, settings-opened, permission-granted, and required-permissions-ready events; and Google Play credit-pack funnel events such as membership-page views, product and price availability, product selection, purchase clicks, purchase-sheet opening, cancellation, errors, and verification status. This reporting happens when the App starts or when you use the relevant permission or purchase flow; it does not require a separate submission action for every event.
Each event may contain the randomly generated installation client identifier described above, sent as anonymous_id, together with the event name, platform, app version and version code, channel or source, and limited event metadata. Depending on the event, metadata may include permission type and readiness, product ID and type, base plan ID, credit amount, whether a price was available, Google Play response code, error class, or a shortened error message. The backend hashes the identifier again before storing the analytics event. The identifier is pseudonymous rather than anonymous because it remains stable in the App's private storage and is also used for some account-verification and security functions; while you are signed in, the login session may also associate the event with your SayPilot account ID.
We use these events to measure installation and feature adoption, understand permission setup and purchase funnels, assess release quality and service reliability, troubleshoot failures, and prevent abuse. First-party SayPilot analytics events are not intended to contain chat text, screenshots, contact names, advertising IDs, or precise location, and we do not sell this information.
2.10 Updates and Notifications
SayPilot may connect to cloud services to check the app version, update status, official update address, and forced update flags. Notification permission is used when needed to keep the floating assistant, screenshot recognition, or background tasks visibly running, or to show service-related notices.
You can disable notifications in system settings. If you do, some foreground service notices, error messages, or background task status notices may not appear.
2.11 Cases Where Separate Consent May Not Be Required
Where permitted by applicable law, we may process your personal information without separate additional consent in the following situations:
- The processing is necessary to enter into or perform a contract with you.
- The processing is necessary for us to perform legal duties or obligations.
- The processing is necessary to respond to a public health emergency, or to protect an individual's life, health, or property in an emergency.
- The processing is carried out within a reasonable scope for public-interest news reporting, public opinion supervision, or similar activities.
- The processing concerns personal information you have made public yourself, or information that has otherwise been lawfully made public, within a reasonable scope.
- Other situations provided by laws and regulations.
