Personal Data Processing Instruction

Version 2026-10-14 · Edition for the Russian region

LAWYER-REVIEW — draft. This text was prepared by the engineering team from the actual design of the Service and is not legal advice. Before it is published in production, a lawyer must review the document and confirm every place marked LAWYER-REVIEW, engineers must confirm every place marked TECH-CHECK, and every {{…}} value must be filled in. While this notice is present, the document is not an effective version.

This English text is a convenience translation of the Russian original. In case of any discrepancy, the Russian version prevails.

Version: 2026-10-14. Effective date: {{EFFECTIVE_DATE}}.

1. Parties, roles and conclusion

1.1. This Personal Data Processing Instruction (the Instruction) forms part of the Public Offer for the Right to Use the Aitechestvo Service (/en/legal/terms, the Offer) and is accepted by the Customer together with it. Terms have the meanings given in the Offer.

1.2. The Customer, as the personal data operator, instructs {{RU_OPERATOR_NAME}} (INN {{RU_OPERATOR_INN}}, the Processor) to process the personal data contained in Requests and their metadata, in accordance with Article 6(3) of Federal Law No. 152-FZ of 27 July 2006 "On Personal Data" (the PD Law).

1.3. The Instruction does not cover User account data, billing data or website enquiries: the Processor processes those as an independent operator (/en/legal/privacy).

1.4. Data subjects' consent to processing by the Processor is not required (Article 6(4) of the PD Law); the Customer ensures consents and other legal grounds for processing.

2. Subject and purposes

The Processor processes personal data for the following purposes:

detecting and masking data in Requests according to the Customer's Masking Policy, sending masked Requests to the model provider chosen by the Customer and restoring the original values in responses;
performing masking and unmasking API calls;
recording Requests and providing the Customer with the Request log, analytics, alerts and notifications (including via the Customer's webhooks) and exports;
fingerprint search investigations, if the Customer has enabled fingerprint storage;
calculating the cost of Platform model usage and tracking limits.

3. Personal data and data subjects

3.1. Request content — any personal data that the Customer's Users and information systems include in the texts, structured fields and attachments of Requests, and that model responses contain. The Customer determines the scope; it may include, in particular: names; dates of birth; identity document details (passport, SNILS, compulsory medical insurance policy, driving licence); phone numbers, email addresses, postal addresses, IP addresses; bank account and card numbers, IBANs, BICs, amounts; INN, OGRN(IP), KPP; coordinates and place names; vehicle registration numbers; diagnoses and ICD codes (health data — a special category); credentials (passwords, tokens, keys). Data subjects — any persons whose data appear in Requests (the Customer's employees, clients, counterparties and others).

3.2. Request metadata — identifiers of the User, the Organisation member and the API key; time; source (API, chat, playground, masking API); provider and model; decision and block/warn reason codes (categories, never values); counts of detected values per category and the actions applied; token counts and cost; latencies; IP address and client application details (user agent). Data subjects — the Customer's Users.

3.3. Fingerprints (if the Customer has enabled fingerprint storage) — keyed HMAC-SHA256 hashes of normalised values computed with the Organisation's secret key, with the category and the Request. Original values are not stored.

3.4. The Customer decides whether special categories of personal data and biometric personal data may be sent through the Service, ensures legal grounds for processing them (Articles 10 and 11 of the PD Law) and configures blocking or pseudonymisation for the corresponding categories. The Service is not intended for processing biometric personal data.

4. Operations and methods

4.1. With Request content: receipt from the Customer, use (automated analysis to detect data), modification (replacing values with placeholders or generalised values), transfer (provision) to the model provider designated by the Customer, restoring the original values in the response, transfer of the response to the Customer, removal from memory when the Request ends.

4.2. With metadata and fingerprints: recording, systematisation, accumulation, storage, retrieval, use, transfer (provision) to the Customer via the Console, API, exports and the Customer's webhooks, depersonalisation by removing identifiers, deletion, destruction.

4.3. Processing is automated and involves transmission over the Internet. [LAWYER-REVIEW: check the list of operations against the terminology of Article 3 of the PD Law.]

5. Conditions for processing Request content

5.1. Request content and the pseudonym mapping table exist only in the Gateway's memory while one Request is processed and are never written to databases, logs, metrics, error reports or disk. Exceptions:

results of name and organisation recognition (positions and normal forms) are kept in the memory of a Gateway instance for no more than 10 minutes, separately for each Organisation, never written to disk or shared between Organisations, and never used for the website demo;
on request, the masking API returns to the Customer an encrypted restore token (AES-256-GCM) containing the mapping table; the Customer keeps the token, which is valid for 24 hours;
web chat history is stored only in the User's browser.

5.2. Values of categories for which the Customer's Masking Policy sets the action "allow" or "warn", values the detectors do not find, and attachments passed without masking are sent to the provider unchanged. The masking limitations are listed in Section 11 of the Offer; the Customer confirms that it has read them.

5.3. The Masking Policy, the choice of providers and the Organisation settings are the Customer's documented instructions. The Processor does not process the entrusted data for any other purpose; in particular, it does not use them to train models and does not sell them.

6. Processor obligations

The Processor shall:

keep the personal data confidential (Article 7 of the PD Law) and ensure their security during processing;
comply with the principles and rules of processing set by the PD Law, the requirements of Article 18(5) (recording, systematisation, accumulation, storage, clarification and retrieval using databases located in the Russian Federation) and Article 18.1;
apply the personal data protection measures under Article 19 of the PD Law set out in Annex 1;
at the Customer's request during the term of the Instruction, including before processing starts, provide documents and other information confirming the measures taken and compliance with the requirements of Article 6 of the PD Law — within 10 working days of the request;
notify the Customer of any detected unlawful or accidental transfer (provision, dissemination, access) of personal data that violated data subjects' rights (Article 21(3.1) of the PD Law) without undue delay and no later than 12 hours after detection — to the Organisation's security notification address (or, if none is set, to the owner) — stating what is known about the nature of the incident, its presumed causes, the data affected, the measures taken and a contact person; and provide further information the Customer needs to notify Roskomnadzor within 72 hours as it becomes available;
forward to the Customer, within 3 working days, any data subject requests the Processor receives concerning the entrusted data, and assist the Customer in fulfilling them within the Service's functionality (Request log, exports, deletion);
at the Customer's demand, stop processing and destroy the entrusted data within the Service's functionality and the periods of Section 9.

7. Customer obligations

The Customer:

ensures legal grounds for processing, informs data subjects and obtains their consents where required, including written consents in the cases established by law;
determines the Masking Policy, the model providers and the Request log retention period;
when sending Requests through Own connections, is responsible for the lawfulness of transferring data to the provider, including notifying Roskomnadzor of any cross-border transfer (Article 12 of the PD Law);
keeps a current security notification address in the Console;
notifies Roskomnadzor of incidents involving data of which it is the operator (Article 21(3.1) of the PD Law), using the information received from the Processor.

8. Engaging third parties (sub-processors)

8.1. The Customer instructs and authorises the Processor to engage the parties listed in Annex 2 to the extent necessary to provide the services. The Processor ensures that such parties are bound by confidentiality and personal data protection obligations no less strict than those of this Instruction. [LAWYER-REVIEW: whether and how a processor may engage third parties (sub-delegation of the instruction) under the PD Law; if necessary, a direct instruction from the Customer to the sub-processors.]

8.2. Platform model providers are engaged only for Organisations whose owner or administrator has confirmed the Platform models notice in the Console, and only for Requests to those models.

8.3. Providers the Customer reaches through Own connections are not the Processor's sub-processors: the Processor transfers data to them on the Customer's instruction; the relationship with them is governed by the Customer's contract with the provider.

8.4. The Processor notifies the Customer by email at least 30 days before engaging a new sub-processor. If the Customer objects, it may withdraw from the Agreement before the engagement.

9. Processing and retention periods

Data	Period
Request content and pseudonym tables	only while the Request is processed (memory)
Name recognition results in memory	no more than 10 minutes
Restore tokens	not stored by the Processor; valid for 24 hours
Request metadata and fingerprints	the period set by the Customer in the Console: from 7 days up to the plan maximum (30, 90, 365 or 1,095 days); after a reduction, the previous period still applies for 7 days
Per-User aggregated usage statistics	within the same period
Console audit log (no Request content)	1,095 days
Database backups (encrypted)	each daily backup is kept for 14 days; deleted data remain in backups for no more than 15 days
After the Organisation is deleted	operational data are deleted after 30 days

When a User is deleted, the identifiers, IP address and user agent in the metadata of their Requests are erased.

10. End of processing

When the Agreement ends (the Organisation is deleted), there is no Request content to return because it is not stored. Before deletion the Customer can export the Request log as CSV or JSONL. Metadata and fingerprints are destroyed within the periods of Section 9. The Processor keeps billing records as an operator for the period required by law.

11. Cross-border transfer and localisation

The Processor does not transfer the entrusted data across borders: the Russian-region infrastructure (the Timeweb Cloud server in Moscow, which also performs data detection and masking, and the backup storage) and the Platform model providers are located in the Russian Federation. The Processor blocks known addresses of foreign providers that do not serve the Russian Federation; when connecting an arbitrary endpoint, the Customer confirms its responsibility for the lawfulness of the transfer. [TECH-CHECK: this holds only while Russian-region Requests, including after masking, and traffic to the Service do not pass through any node outside the Russian Federation (SPEC §0.1 item 4, §12.11). A node abroad (e.g. a proxy server at DigitalOcean) means a cross-border transfer of the entrusted data: rewrite this Section and Annex 2 and notify Customers under item 8.4 before the transfer starts. Owner decision 2026-10-15: the operator egress relay at DigitalOcean to OpenAI/Anthropic (SPEC §12.11 (f)) is allowed only for testing on the staging stand with synthetic data; in Russian-region production it is blocked until R-56 is closed (EGRESS_RELAY_PROD_ACK).]

12. Liability

The Customer is liable to the data subject for the Processor's actions; the Processor is liable to the Customer (Article 6(5) of the PD Law) within the limits set by the Offer.

13. Audits

At the Customer's request, the Processor provides a completed security questionnaire and the documents listed in item 6.4. An on-site audit is possible no more than once a year, with at least 30 days' notice, at the Customer's expense and without access to other customers' data. [LAWYER-REVIEW]

Annex 1. Security measures

This list reflects the measures actually in place at the date of this version. [LAWYER-REVIEW: the Processor does not claim to hold an information system certificate of conformity, FSTEC or FSB certificates, or certified information security tools; the protection level under Government Resolution No. 1119 of 1 November 2012 is {{RU_PROTECTION_LEVEL}} according to the Processor's own assessment.]

No content at rest. Request content is not stored; logs contain the method, the path (without the query string), the status, latencies and identifiers; request bodies, authorisation headers and values are never logged. Error reports contain no request data.
Fail closed. If masking cannot be completed (a detector failure under a blocking setting, a format violation, an unclassified content type, etc.), the Request is rejected and never sent to the provider.
Single egress point. Connections to model providers are opened by one Gateway module only, and only for Requests whose masking has completed; Customer-supplied provider addresses are checked against forbidden (internal, service) addresses on every connection.
Isolation. Each Organisation's data are separated at the database query level; the recognition cache is separated per Organisation; the Russian and international regions are independent deployments with no shared databases or network paths.
Encryption. TLS 1.2 or later at the edge; provider connection credentials, the Organisation fingerprint key, TOTP secrets and webhook secrets are encrypted with AES-256-GCM; keys are kept outside the database and rotated according to a procedure; database backups are encrypted before upload.
Access control. Role model (owner, administrator, security officer, auditor, member); passwords stored as argon2id hashes; two-factor authentication, mandatory for platform administrators; login rate limiting; API keys stored as keyed hashes.
Network and runtime. The database, the cache, object storage and the recognition service are attached only to the Service's internal network, which has no internet access; all services run on one server, and traffic between them does not leave it. From the internet only the edge (ports 80 and 443) and key-authenticated SSH administration are reachable; all other inbound connections are blocked by a firewall. The application components (the Gateway, the recognition service, the management API, background workers, the web interface and the backup job) run as unprivileged users, with read-only file systems and without Linux kernel capabilities; every service, including the database, the cache and object storage, has a memory limit.
Logging and monitoring. Console audit log; metrics and alert rules for masking failures and anomalies. [TECH-CHECK: the Russian-region stand has no metrics or alert rules deployed (SPEC §13.3: server monitoring in the Timeweb Cloud panel and external availability and certificate checks); deploy them before launch or adjust the wording.]
Backups. A daily database backup, encrypted before upload (the decryption key is kept separately from the Service), in private Timeweb Cloud object storage in the Russian Federation with an access key limited to that storage; kept for 14 days; a monthly restore test. A restore may lose up to 24 hours of data.
Secure development. Dependencies pinned by version and checksum; images scanned for vulnerabilities; changes pass automated checks.
Incident response. A response procedure, including notifying Customers within 12 hours.

Annex 2. Sub-processors

[LAWYER-REVIEW: check names, roles and retention terms against the contracts and the providers' current documentation.]

Party	Purpose	Location	Data	Retention at the party
TIMEWEB.CLOUD LLC (Timeweb Cloud)	compute and storage for hosting the Service infrastructure: a virtual server (database, cache, object storage, Gateway) and storage for the encrypted backups [LAWYER-REVIEW: under the Timeweb Cloud offer (version of 6 February 2026, clause 9.4) the contract is not an instruction to process PD; decide whether the provider is a sub-processor and whether a separate contract is needed]	Russian Federation (server: Moscow) [TECH-CHECK: location of the backup bucket]	all data processed by the Service (backups in encrypted form)	within the periods of Section 9
Unisender Smart LLC (Unisender Go)	delivery of the Service's email, including alerts configured by the Customer	Russian Federation	recipient addresses and message texts; Request content is never included in messages	under the provider's terms (Unisender Go Terms of Use, version of 23 September 2026) [LAWYER-REVIEW: retention of messages and delivery logs on the provider's side]
Yandex.Cloud LLC (YandexGPT, Yandex AI Studio)	Platform models — only after the Platform models notice is confirmed	Russian Federation	content of Requests to these models after masking	Requests are sent with a header disabling request-data logging, per the provider's documentation; otherwise under the provider's terms {{YANDEX_AI_TERMS_URL}}
Sberbank PJSC (GigaChat)	Platform models — only after the Platform models notice is confirmed	Russian Federation	content of Requests to these models after masking	under the provider's terms {{GIGACHAT_TERMS_URL}}