Personal Data Processing Instruction

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

Version: 2026-10-28. Effective date: 28 October 2026.

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 Individual Entrepreneur Yulia Vitalyevna Orlova (INN 781438442029, 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:

1. 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;
2. performing masking and unmasking API calls;
3. recording Requests and providing the Customer with the Request log, analytics, alerts and notifications (including via the Customer's webhooks) and exports;
4. fingerprint search investigations, if the Customer has enabled fingerprint storage;
5. 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: collection (receipt from the Customer), use (automated analysis to detect data, including extracting text from attached documents), modification (replacing values with placeholders or generalised values, restoring the original values in the response), storage in memory in the cases and within the periods set out in item 5.1, transfer (provision) to the model provider designated by the Customer, transfer of the response to the Customer, deletion.

4.2. With metadata and fingerprints: recording, systematisation, accumulation, storage, retrieval, use, transfer (provision, access) to the Customer via the Console, API, exports and the Customer's webhooks, deletion, destruction. When a User is deleted, their identifiers, IP address and user agent are deleted from the metadata of their Requests (Section 9).

4.3. Processing is performed by automated means and involves transmission over the Internet information and telecommunications network; no processing is performed without automated means.

5. Conditions for processing Request content

5.1. Request content (texts, attachments, model responses) and the pseudonym mapping table are processed only in the memory of the Gateway and its auxiliary name recognition and document text extraction services, which run on the same server, while one Request is processed (the text extraction service keeps a document in a temporary directory in memory only while it is being processed; the Service's edge, where TLS connections terminate, passes Requests to the Gateway and responses to the Customer without storing or logging their content), and are never written by the Service to databases, logs, metrics, error reports or disk. Exceptions:

• results of recognising personal names, organisation names and place names (the text fragments found, their positions, normal and grammatical forms) are kept in the Gateway's memory separately for each Organisation and reused for no more than 10 minutes after recognition; expired entries are never used and are removed from memory when looked up, when displaced by new entries or when the Gateway restarts; these results are never used for the website demo;
• text extracted from attached documents for masking is kept in the Gateway's memory in its original (unmasked) form separately for each Organisation and used for no more than 10 minutes after extraction, after which it is removed from memory within 30 seconds, so that the same document sent again is not extracted again; only the masked text is sent to the model provider, never the original file; this text is never used for the website demo;
• the name recognition service keeps in memory a limited number of entries: results of morphological and dictionary analysis of individual words, and the personal names found (including full names: surname, first name and patronymic) and place names, in their normal form together with their grammatical forms — without the rest of the Request text and without any link to an Organisation, User or Request; these entries have no fixed retention period: they are displaced by new entries and removed when the service restarts;
• 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.

The entries listed in the first three items exist only in memory, are never written by the Service to disk, databases, logs or error reports, and are never disclosed to other Organisations. The server has a swap area enabled: the operating system may page memory out to it, on the same server's disk, including memory that holds Request content and these entries.

5.2. Values of categories for which the Customer's Masking Policy sets the action "allow" or "warn", attachments for which the Customer's Masking Policy sets the action "allow", and values the detectors do not find 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, the Processor does not use them to train models and does not sell them.

6. Processor obligations

The Processor shall:

1. keep the personal data confidential (Article 7 of the PD Law) and ensure their security during processing;
2. 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;
3. apply the personal data protection measures under Article 19 of the PD Law set out in Annex 1;
4. 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;
5. 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;
6. 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);
7. 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:

1. ensures legal grounds for processing, informs data subjects and obtains their consents where required, including written consents in the cases established by law;
2. determines the Masking Policy, the model providers and the Request log retention period;
3. 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);
4. keeps a current security notification address in the Console;
5. 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 consents to the Processor engaging the parties listed as sub-processors in Annex 2 to process the entrusted data, and instructs the Processor to transfer data to them to the extent necessary to provide the services. Sub-processors process the data under their own contracts with the Processor; the processing terms, including retention on their side and restrictions on the data that may be sent to them, are set out in Annex 2. The Processor is liable to the Customer for the sub-processors' actions as for its own, within the limits set by the Offer. The infrastructure provider listed in Annex 2 provides the Processor with computing capacity and storage, does not process the entrusted data on the Processor's instruction and is not a sub-processor.

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. The providers' terms restrict the data that may be sent to their models (Annex 2); the Customer takes these terms into account when choosing Platform models and setting its Masking Policy.

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 or changing the infrastructure provider. If the Customer objects, it may withdraw from the Agreement before the new sub-processor is engaged or the infrastructure provider is changed.

9. Processing and retention periods

Data	Period
Request content and pseudonym tables	only while the Request is processed (memory)
Name recognition results in the Gateway's memory	reused for no more than 10 minutes; then removed when looked up, when displaced by new entries or when the Gateway restarts
Text extracted from attached documents, in the Gateway's memory	used for no more than 10 minutes after extraction; removed no later than 30 seconds after that period ends
Word analysis results, and personal names and place names with their grammatical forms, in the name recognition service's memory	no fixed period: until displaced by new entries or until the service restarts
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 in the backup storage for 14 days (older backups are deleted after each successful backup run), and the two most recent backups are also kept on the Service's server; deleted data remain in backups for no more than 15 days or, if backups fail, until the first successful backup after they resume
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 virtual server in Moscow, which also performs data detection and masking, and the Timeweb Cloud backup storage in Saint Petersburg) 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. The Processor may start a cross-border transfer of the entrusted data only after complying with Article 12 of the PD Law, amending this Instruction and notifying the Customer under item 8.4.

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. If that information is not sufficient, the Customer may, no more than once a year, audit compliance with this Instruction — itself or through an independent specialist bound by a confidentiality obligation — with at least 30 days' prior notice, at its own expense, at a time and in a manner agreed with the Processor, and without access to other customers' data. Physical access to the infrastructure provider's equipment (Annex 2) is not provided during an audit.

14. Processor contacts

Individual Entrepreneur Yulia Vitalyevna Orlova, INN 781438442029, OGRNIP 318784700117489, address (also for written requests): 20 Kustodieva Street, building 1, flat 67, Saint Petersburg, 194352, Russia. Email for notices, requests and documents under this Instruction: ceo.orlova@yandex.ru. Phone: +7 911 715-58-67.

Annex 1. Security measures

This list reflects the measures actually in place at the date of this version. The Processor does not claim to hold an information system certificate of conformity, FSTEC or FSB certificates, or certified information security tools. The level of protection of personal data processed in the Service's information system under Government Resolution No. 1119 of 1 November 2012 is level 4 (УЗ-4); the Processor determined it itself. The Customer, as the operator, assesses on its own whether these measures are sufficient for the data it processes, including special categories of personal data (item 3.4).

1. No content at rest. Request content is not stored, except for storage in memory in the cases and within the periods set out in item 5.1; 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.
2. 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.
3. 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.
4. Isolation. Each Organisation's data are separated at the database query level; the caches of name recognition results and of text extracted from documents are separated per Organisation; the Russian and international regions are independent deployments with no shared databases or network paths.
5. 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.
6. 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.
7. Network and runtime. The database, the cache, object storage, the recognition service and the document text extraction service are attached only to the Service's internal networks, which have 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 and text extraction services, 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.
8. Logging and monitoring. Console audit log; service logs are kept on the server in a bounded volume and without Request content (item 1); every update of the Service automatically checks that its dependencies are available. Application metrics and automatic alerts on masking failures are not used on the Russian-region stand.
9. Backups. A daily database backup, encrypted before upload (the decryption key is kept separately from the Service), in private Timeweb Cloud object storage in Saint Petersburg with an access key limited to that storage; kept for 14 days; the two most recent backups, also encrypted, are kept on the Service's server; a monthly restore test. A restore may lose up to 24 hours of data.
10. Secure development. Dependencies pinned by version and checksum; images scanned for vulnerabilities; changes pass automated checks.
11. Incident response. A response procedure, including notifying Customers within 12 hours.

Annex 2. Sub-processors and infrastructure provider

The information is given from the Processor's contracts with these parties and the providers' published terms at the date of this version.

Party	Purpose	Location	Data	Retention at the party
TIMEWEB.CLOUD LLC (Timeweb Cloud) — infrastructure provider	compute and storage for hosting the Service infrastructure: a virtual server (database, cache, object storage, the Gateway and its auxiliary services) and storage for the encrypted backups. Under the Timeweb Cloud offer (version of 6 February 2026, clause 9.4) the contract with it is not an instruction to process personal data; the Processor itself performs the processing on the rented capacity, and Timeweb Cloud is not a sub-processor (item 8.1)	Russian Federation (server: Moscow; backup storage: Saint Petersburg)	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)
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; in that case, under the provider's terms, request content is not stored on its servers, except for short-term storage objectively necessary to process the request, and is not used for debugging or model training. Terms: the Yandex AI Studio Terms of Use (https://yandex.ru/legal/cloud_terms_yandex_ai_studio), which contain an instruction to the provider to process the personal data in requests, and the Yandex Cloud data processing agreement (https://yandex.ru/legal/cloud_dpa). The provider's terms do not allow requests to contain information constituting a secret protected by law, special categories of personal data or biometric personal data: by choosing these models, the Customer ensures that Requests to them contain no such information after masking
SaluteDevices LLC (ООО «СалютДевайсы»; GigaChat API; right holder of the GigaChat program: Sberbank PJSC)	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: the Agreement on the Use of the GigaChat API Service on a Postpaid Basis for Corporate Users (https://developers.sber.ru/docs/ru/policies/gigachat-agreement/corporate-clients-beta). The provider and the right holder use request content to process requests and generate responses and do not use it for purposes unrelated to providing the service; the agreement sets no retention period. The agreement contains no instruction to process personal data and assumes that no personal data are sent to the service: by choosing these models, the Customer ensures that Requests to them contain no personal data after masking