Personal Data Processing and Privacy Policy

01General provisions

This Policy defines the procedure for processing personal data ("PD") and the measures ensuring its security, and is developed in accordance with Federal Law No. 152-FZ of 27.07.2006 "On Personal Data". This is the Operator's primary document on PD processing.

02Personal data operator

The personal data operator and the rights holder of the AiHummer software is Limited Liability Company "AI HUMMER", a company incorporated in the Russian Federation. The developer of the AiHummer mobile applications is Leon Sokirkin. The operator's full and short legal name, INN, OGRN, registered address and director are listed in the «Operator details» card at the end of this document and in the Requisites section. Contact for PD matters: info@aihummer.ru.

03Terms & definitions

• Personal data — any information relating to a directly or indirectly identified individual.
• Processing — any operation with PD: collection, recording, storage, use, transfer, deletion, etc.
• Data subject — the individual to whom the PD relates.

04Data subjects & data composition

Subjects are website visitors, account-portal users, representatives of customers and counterparties, and job applicants. PD composition: full name, email address, contact phone, organization name and position, account data, the content of requests, date of birth and gender — only when voluntarily provided by the user in the account portal (used to personalize communication; kept until account deletion or consent withdrawal), and technical data (see §9).

05Processing purposes

• processing applications, demo requests and feedback;
• registration and maintenance of the account portal, providing product access;
• conclusion and performance of contracts, payments and issuing closing documents;
• providing technical support and informing about updates;
• ensuring security, keeping logs and preventing abuse;
• reviewing job applications.

06Legal basis

Processing is carried out on the basis of the data subject's consent, concluded contracts (or the intention to conclude them), and in cases provided for by the legislation of the Russian Federation.

07List of actions with PD

Processing includes collection, recording, systematization, accumulation, storage, rectification, use, transfer (in cases established by law), anonymization, blocking, deletion and destruction of PD, with and without automation.

08Principles & conditions

Processing is lawful and fair, limited to the stated purposes, not excessive in scope, and ceases once the purposes are achieved or consent is withdrawn.

09Cookies, web analytics & logging

The website uses cookies and Yandex.Metrica with Webvisor enabled: analytics includes session replay based on DOM state, navigation, clicks and scrolling; editable field values are not sent in that recording. The website also keeps technical access logs (IP address, device and browser type). See the Cookie Policy for details.

10Special categories & biometrics

The Operator does not process special categories of personal data (on race, ethnicity, political views, health, etc.) or biometric personal data, unless expressly provided by a specific project configuration and formalized by a separate consent and legal basis.

11Self-hosted processing model

The Platform is deployed on the User's infrastructure. PD processed within an Instance is stored on the User's side; the Platform Operator has no access to it and is not a processor unless separately agreed.

12Engaged processors & transfer

For certain purposes the Operator may engage vetted contractors (hosting, payment and communication services) under confidentiality terms and to the extent necessary. PD is not shared with third parties except as required by law or with the subject's consent. The Operator performs no cross-border transfer unless expressly stated.

13Retention & deletion

PD is retained no longer than the processing purposes require and is destroyed upon their achievement or consent withdrawal, unless a different period is set by law or contract.

14Data subject rights

The subject may obtain information about processing, request rectification, blocking or deletion of PD, withdraw consent and appeal the Operator's actions. To exercise these rights, send a request to info@aihummer.ru.

15Protection measures

Organizational and technical measures are applied: an encrypted credentials vault, role-based access control (RBAC), row-level security, audit, IP allowlist, approval gates on risky operations, and an air-gapped mode.

16AI-generated content

AiHummer is an AI-employee platform, and its primary purpose is generating text with large language models. A user sees AI-generated text in the following places: the AI employee’s replies in the AiHummer mobile app chat, in the web chat and in connected channels (messengers, email, corporate systems); automatically composed conversation titles and summaries; facts extracted from messages by the memory system; sentiment and topic assessments of a conversation; and the replies of voice mode. When the instance owner enables the corresponding tools, the AI also produces images and synthesized speech.

How a user recognizes such content. In the AiHummer app and in the web chat the counterpart is an AI employee — that is the product’s explicit purpose; its messages are displayed separately from a human’s and are labelled with the AI employee’s name. On messengers the AI employee operates through that platform’s bot account, so the platform’s own «bot» marking applies to its messages. The AI employee’s default system description states that it is an AI assistant.

What the product does not do. AiHummer does not watermark the content it produces, does not attach machine-readable markers of its origin, and does not append an automatic disclaimer to every reply. The AI employee’s name, appearance and system description are configured by the instance owner, so a given installation may present the AI employee differently from the default. In a self-hosted deployment, the duty to inform end users that they are talking to an AI and to comply with the disclosure requirements applicable to its own operations rests with the instance owner.

Data processing during generation. To produce a reply, the conversation content is sent to the selected language model. The model provider is chosen by the instance owner: it can be an external service or a local model running inside the owner’s own perimeter with no data leaving it. A model’s reply is not a legally significant decision, does not automatically create legal consequences for the user, and may contain inaccuracies; verifying a reply before acting on it remains a human responsibility.

Human control. Selected high-risk actions of the AI employee (calls to external tools) can be put behind a human approval gate; it is off by default and is enabled by the instance owner. The product does not perform a human pre-send review of every text reply.

17The AiHummer mobile and desktop app

This section describes the processing of data by the AiHummer app for Android, iOS, macOS, Windows and Linux. The app connects to an Instance chosen by the user via a one-time code (QR) and keeps conversation data on the device itself: the access token and a random install identifier in the operating system’s secure storage (Keychain on Apple platforms, Keystore on Android); the chat list, messages, the queue of unsent messages and the attachment cache in the app’s local database; and drafts in the system settings store. The local cache and drafts are erased by the «Clear» action in the app settings.

Android permissions and what they are for. The app requests: internet access and network state — to reach the Instance; the camera — to scan the pairing QR code and to take a photo or video to send in chat; the microphone — to record voice messages; notification display — to deliver push notifications; and external storage write — only on Android 6–9 and only to save a picture from a chat into the gallery when the user asks for it. The camera is declared optional, so the app installs on devices without one. Permissions inherited from third-party libraries for reading external storage and the media library, as well as the advertising-identifier permission, are deliberately removed from the build. The app requests no location, contacts, call-log or SMS permissions on Android at all.

iOS and macOS permissions. The purpose strings the system shows correspond to these purposes: photos — picking an image to send in chat and reading photo details when the «Photos» source is on; add to photo library — saving a picture from a chat; camera and microphone — capture and voice messages; Health, Calendar and Reminders, Home (HomeKit) and location while using the app — the device-data bridge (see the next paragraph). In Health the app only reads and never writes: the write permission is listed because iOS asks for it together with read access, and declining it changes nothing. The macOS build runs sandboxed; of the sensitive entitlements it holds only the microphone, the Downloads folder and user-selected files.

The device-data bridge and its default state. The app can answer Instance queries about data that exists only on the device: Health (steps, heart rate, sleep, workouts), Photos, Home, Find My (this device’s location) and Calendar (events and reminders). The bridge is implemented for iOS; on other platforms a source answers «unsupported». Every source is off by default: the set of enabled sources starts out empty and only the user turns them on in the app settings. The check runs on every request — when a source is off the app returns a refusal and does not touch the system data at all. Data is read only in response to a specific query; there is no background or continuous collection. The app announces the list of enabled sources to the Instance on connect so that it knows what it may ask about; that list is held only in the Instance server’s memory for the lifetime of the connection.

What the app sends to the Instance server. Over the secure connection the app transmits: conversation content (messages, attachments, voice recordings); the push notification token together with the platform label (ios, android, macos, windows, linux) and the delivery service; presence information (whether the app is in the foreground, which chat is open, the install identifier and the platform); appearance settings and the chosen interface language; and the app’s diagnostic log lines. During QR pairing the app sends a random install identifier that it generates itself; it is not derived from any hardware identifier of the device. The app version, the device model and OS version, the mobile carrier and advertising identifiers are not transmitted to the server.

What is stored on the Instance server. The server that serves the app is a component of the Instance deployed on the User’s own infrastructure (see the «Self-hosted processing model» section). It stores: conversations and their text content, voice message transcripts, attachment metadata and the attachment files themselves, profile images, user settings including the chosen language, a delivery event journal, and the push notification token with its platform label, delivery service and last-use timestamp. A device session is kept as a hash of the access token and lives for 90 days; the token itself is not stored on the server, and the one-time pairing code is likewise stored only as a hash. The IP address of a connecting device appears in the server’s technical log but is not stored in the app’s database.

Push notification delivery and the third parties involved. The app ships in several builds, each with its own delivery service: Firebase Cloud Messaging (Google) on iOS, macOS and the Google Play build (on Apple devices delivery goes through FCM into Apple’s APNs); Huawei Push Kit in the AppGallery build; RuStore Push (VK’s push notification service) in the RuStore build. Windows and Linux have no store delivery service: notifications arrive over the same connection to the Instance and are shown by the operating system, and the web version has no device delivery at all. Materially: the Instance server puts the chat name and a preview of the message text — up to 100 characters — into the notification, along with the chat and message identifiers. This means that a fragment of conversation content is transmitted to the infrastructure of the selected delivery service. The current version offers no switch to hide the preview inside a notification; notifications as a whole are turned off through the operating system and the app’s notification settings. The delivery services’ credentials are configured on the Instance side by its owner; when they are absent no token is issued and no notifications are sent.

Voice message transcription. A voice recording is uploaded to the Instance server and may be converted into text. By default this uses a speech recognition service running inside the Instance’s own perimeter, and the recording does not leave it. A cloud recognition service is engaged only by a separate decision of the Instance owner; when no service is configured, no transcription is performed.

App telemetry. The Android and iOS builds run Yandex AppMetrica. It activates at app start and reports: app open, screen transitions (the screen name), the progress of QR pairing, the fact that a message was sent or received together with its kind only (text, media, voice), the start and end of a voice recording, the fact that files were attached (their number and source), the name of a changed setting without its value, notification receipt and opening, and technical errors. Conversation content, message texts and attachments are not sent to telemetry. Advertising-identifier collection and location tracking are switched off in the AppMetrica configuration, and the corresponding permission is additionally removed from the Android build. A session is associated not with the device or pairing identifier itself but with its one-way hash, so the original value never leaves the device. AppMetrica does not run on macOS, Windows, Linux or in the web version. The current version of the app has no separate switch to turn telemetry off.

Crash reports. Unhandled errors and crashes are sent to the developer’s own server (Bugsink, a Sentry-protocol-compatible product) — not to a third-party cloud service. Before sending, sensitive URL parameters are redacted from the report: access tokens, refresh tokens and media access tokens. Crash reports are also collected by AppMetrica. In a self-built app the report endpoint is replaced with the builder’s own or cleared — in the latter case no reports are sent anywhere.

What the app does not do. The app shows no advertising and contains no ad networks, collects no advertising identifiers, does not read contacts, the call log or SMS, does not determine location on Android, does not collect the device model or operating system version, and does not fetch fonts from third-party content delivery networks at runtime — every font is bundled into the build.

Backups, uninstalling the app and deleting data. App data is fully excluded from Android cloud backup and from device-to-device transfer — the exclusion is declared separately for both modes. When the app is uninstalled, the operating system removes everything it kept on the device: the local conversation database, the attachment cache, the drafts, the access token and the install identifier in secure storage; after that the device is no longer connected to the Instance. Uninstalling the app does not by itself delete the data held on the Instance side: conversations, attachments and event journal records remain; deleting a chat or a message in the app marks it as deleted rather than erasing it physically; the push token record is removed only once the delivery service reports that the token is no longer valid; and the device session record simply stops being valid after 90 days. The app has no separate «delete my account» function. Because the Instance belongs to the User and runs on the User’s infrastructure, final deletion of the data is performed on the Instance by its owner; a request to delete data processed by the Operator is sent to the contact address given at the end of this document.

18Final provisions

The Operator may amend this Policy. The current version is published on the website with its date and version. Related documents: Cookie Policy.