Personal Data Processing Policy
Version 2026-10-28 · Edition for the Russian region
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. General provisions
1.1. This Personal Data Processing Policy (the Policy) is issued under Article 18.1(2) of Federal Law No. 152-FZ of 27 July 2006 "On Personal Data" (the PD Law) and sets out the purposes, legal grounds, procedures and conditions of personal data processing and the measures taken to protect personal data.
1.2. Personal data operator: Individual Entrepreneur Yulia Vitalyevna Orlova, INN 781438442029, OGRNIP 318784700117489, address: 20 Kustodieva Street, building 1, flat 67, Saint Petersburg, 194352, Russia (the Operator, "we"). Registration number in the register of personal data operators: 78-25-182670.
1.3. The Policy applies to personal data processing when the Aitechestvo service is used in the Russian region (the Service): the website https://aitechestvo.com (also reachable at https://айтечество.рф and https://aitech-ru.instatoggle.com), the management console (the Console), the web chat and the software gateway https://gw.aitechestvo.com (also reachable at https://aitech-ru-gw.instatoggle.com; the Gateway).
1.4. The Service is used by organisations (the Customers) that connect their employees and information systems to it. The Operator acts in different roles for different data:
- as an operator for account data, billing data, website enquiries and the other data listed in Section 4;
- as a person processing personal data on behalf of the Customer (Article 6(3) of the PD Law) for the content of requests to language models and the metadata of those requests. The Customer is the operator of such data; the terms of the instruction are set out in the "Personal Data Processing Instruction" (/en/legal/dpa). Section 9 describes this processing for reference.
1.5. The international region of the Service, if it is opened, will be run by another person as an independent operator acting under its own policy. Data of Russian-region users is not transferred to the international region; the regions share no databases.
1.6. The Operator organises personal data processing herself: the person responsible for organising personal data processing (Article 22.1 of the PD Law) is the individual entrepreneur Yulia Vitalyevna Orlova. Email for personal data enquiries: ceo.orlova@yandex.ru; phone: +7 911 715-58-67.
2. Key terms
- Personal data (PD) — any information relating directly or indirectly to an identified or identifiable natural person (the data subject).
- User — a natural person registered in the Console or invited to a Customer's organisation.
- Request — a call to the Gateway (via the API, the web chat, the playground or the masking API) containing text and other data addressed to a language model.
- Masking — automatic replacement of values detected in a Request with placeholders (for example
[PERSON_1]), generalised values, or blocking of the Request before it is sent to the model provider, with the original values restored in the response. Masking (pseudonymisation) is not depersonalisation within the meaning of the PD Law: masked data in context remain personal data. - Other terms have the meanings given in the PD Law.
3. Processing principles
The Operator processes PD lawfully and fairly; limits processing to specific, predefined and lawful purposes; does not merge databases processed for incompatible purposes; processes only PD that serve the purposes and are not excessive; ensures the accuracy of PD; and keeps PD no longer than the purposes or the law require, after which they are destroyed or depersonalised (Article 5 of the PD Law).
The key architectural rule of the Service is no content at rest: Request texts, model responses and pseudonym mapping tables exist only in the memory of the Gateway and its auxiliary services for the duration of one Request and are never written to databases, logs, metrics or error reports (exceptions are described in Section 9).
4. Purposes, data subjects, data, legal grounds and retention
| No. | Purpose | Data subjects | Personal data | Legal ground | Retention |
|---|---|---|---|---|---|
| 4.1 | Registration and account management, access to the Console and web chat, organisation membership | Users (representatives and employees of Customers, invited persons) | email address; name as entered by the user; password hash (argon2id; the password itself is not stored); interface language; organisations and roles; two-factor authentication status, encrypted TOTP secret and hashes of recovery codes; date of last login | the User's consent (Article 6(1)(1) of the PD Law), given at registration, including registration by invitation; for a Customer that is a sole proprietor, also performance of the contract to which they are a party (Article 6(1)(5)) | until the account is deleted; deletion on request within 30 days (Section 8) |
| 4.2 | Inviting users to a Customer's organisation | invited persons | email address, role, details of the inviting user | legitimate interests of the Customer and the Operator (Article 6(1)(7)) | the invitation link is valid for 7 days; the record is kept until the organisation is deleted or on the data subject's request |
| 4.3 | Service security, account protection, incident investigation | Users; website visitors and persons accessing the Gateway | sessions (token hash, IP address, browser details (user agent), creation and last-activity time); Console audit log (action, object, IP address, user agent, time); failed-login counters and rate limits per IP address, email address or account (in an in-memory store: per IP address and email address for no more than two hours, per account for no more than two days); web server log (IP address, time, website or Gateway host, request method, response status and size, processing time; no request path, query parameters, headers or content) | legitimate interests of the Operator (Article 6(1)(7)); duty to secure PD (Article 19) | a session lasts up to 30 days after the last activity; IP address and user agent are erased after 12 months; audit log — 1,095 days (3 years); web server log — until older entries are deleted automatically (the log is limited in size) |
| 4.4 | Preventing abuse of the trial period | organisation owners; Customers that are sole proprietors | keyed hash (HMAC-SHA256) of the owner's normalised email address and of the organisation's INN; readable values are not stored | legitimate interests of the Operator (Article 6(1)(7)) | 365 days after the record is created, including after the account and organisation are deleted |
| 4.5 | Concluding and performing the contract with the Customer, payments, invoices, fiscal receipts | Customer representatives, payers; Customers that are sole proprietors | organisation details (for sole proprietors: name, INN, OGRNIP, address); email for invoices and receipts; payment, invoice, refund and balance records; saved payment method data (payment provider identifier, card scheme, last 4 digits and expiry of the card); evidence of consent to recurring payments is kept with the evidence of consents (item 4.8) | performance of a contract (Article 6(1)(5)); legal obligations (Article 6(1)(2); Federal Law No. 54-FZ of 22 May 2003, the Tax Code of the Russian Federation, Federal Law No. 402-FZ of 6 December 2011) | 5 years after the end of the year of the last payment, invoice or refund, including after the organisation is deleted |
| 4.6 | Service notifications (email confirmation, password reset, invitations, security and billing notices, alerts configured by the Customer) | Users | email address, name, organisation name, details needed for the notice (never Request content) | the User's consent (Article 6(1)(1)); legitimate interests of the Operator (Article 6(1)(7)); for a Customer that is a sole proprietor, also performance of the contract to which they are a party (Article 6(1)(5)) | the email queue is kept for 30 days; message parameters are erased right after sending |
| 4.7 | Handling enquiries sent through the website contact form | persons who sent an enquiry | name, email address, phone (optional), company (optional), message, enquiry type, language, IP address | consent (Article 6(1)(1)) | 12 months after the enquiry is handled (if never handled, after it was received) |
| 4.8 | Evidence of consents; handling data subject requests | Users; persons who sent enquiries | consent type (consent to recurring payments included), document version, time, IP address, user agent, SHA-256 hash of the email address; data subject requests (type, status, deadlines) | legal obligations (Article 6(1)(2); Articles 9(3), 14, 20 of the PD Law) | consents — 3 years after the consent is withdrawn or the account is deleted (IP address and user agent erased after 12 months); requests — 3 years after completion, the email address being replaced by its hash on completion |
| 4.9 | Masking demonstration on the website | website visitors | text typed into the demo field (may contain PD at the visitor's choice); IP address (for rate limiting) | legitimate interests of the Operator (Article 6(1)(7)): demonstrating the Service at the visitor's request and protecting the website against abuse | the text is processed in memory only for the response and is not stored (except for the name-recognition service entries described in item 9.2; memory pages holding this text may be paged out to the swap area, as stated in item 9.2) or sent to any language model; per-IP counters last no more than a few minutes |
The Operator does not process special categories of PD or biometric PD for the Operator's own purposes. Such data may appear in the content of Customers' Requests; that processing is governed by Section 9 and the Personal Data Processing Instruction. The Operator does not process PD to promote goods, works or services on the market and sends no advertising messages.
5. Processing procedures and conditions
5.1. Operations: collection, recording, systematisation, accumulation, storage, clarification (updating, changing), retrieval, use, transfer (provision, access), blocking, deletion, destruction. Processing is automated and involves transmission over the Internet.
5.2. Localisation. Recording, systematisation, accumulation, storage, clarification (updating, changing) and retrieval of PD of citizens of the Russian Federation are performed only using databases located in the Russian Federation; no databases located outside the Russian Federation are used for these operations (Article 18(5) of the PD Law). The databases, cache and object storage of the Russian region are hosted on a Timeweb Cloud virtual server (TIMEWEB.CLOUD LLC) in a data centre in Moscow, and the database backups are kept in encrypted form in Timeweb Cloud object storage in Saint Petersburg.
5.3. Cross-border transfer. The Operator does not transfer PD processed in the Russian region across borders. Russian-region email is sent through a Russian provider (Unisender Go); the user's browser makes no requests to resources outside the region (fonts are self-hosted; no third-party counters or widgets are used). If a Customer connects a language-model endpoint located abroad to the Gateway, the transfer is made by the Customer as the operator (Section 9).
5.4. The Operator does not take decisions that produce legal effects for a data subject or otherwise affect their rights and legitimate interests solely on the basis of automated processing (Article 16 of the PD Law). The Gateway blocks Requests automatically under rules set by the Customer, and such blocking only determines which data are sent to the model provider. Automated protective measures (rate limiting, temporary login lockout after failed attempts, refusal of a repeated trial period) are applied to keep the Service secure and to prevent abuse; the Operator considers objections to them as described in Section 8.
5.5. The Operator does not disseminate PD (disclose it to an indefinite group of persons) and does not sell PD.
6. Transfer to third parties and processors
The Operator transfers PD or instructs others to process PD only as listed in the table and only to the extent necessary for the stated purposes. The table also names the supplier of the computing infrastructure on whose equipment the Service is hosted.
| Party | Role and purpose | Data |
|---|---|---|
| TIMEWEB.CLOUD LLC (Timeweb Cloud) | supplier of computing infrastructure: provides the Operator with a virtual server in Moscow, on which the Operator hosts the Service's databases, cache and object storage, and with object storage in Saint Petersburg for the encrypted database backups. Under its contract with the Operator, Timeweb Cloud is not a person processing PD on the Operator's instruction and does not process the PD the Operator hosts; the PD processing on this infrastructure is performed by the Operator herself | the Service's data are hosted on Timeweb Cloud equipment; backups only in encrypted form, the decryption key being held by the Operator and never given to Timeweb Cloud |
| Unisender Smart LLC (Unisender Go service) | delivery of the Service's email — processing on the Operator's instruction | recipient addresses, names and message texts |
| YANDEX LLC (ООО «ЯНДЕКС», Yandex Mail) | the mail service hosting the Operator's mailbox ceo.orlova@yandex.ru: receipt and storage of messages sent to the Operator and of contact-form enquiry notices | senders' addresses and names, message texts and attachments, enquiry details |
| NCO YooMoney LLC (ООО НКО «ЮМани», YooKassa service) | payment acceptance, saving payment methods for recurring payments, fiscal receipts | payment details, receipt email, buyer details (name, INN) where available. Card data are entered on the YooKassa page and are not passed to the Operator |
| Deyta Kyu LLC (ООО «Дейта Кью», DaData service) | retrieving organisation details by INN at the User's request | INN (personal data for sole proprietors) |
| Platform model providers: Yandex.Cloud LLC (YandexGPT), SaluteDevices LLC (ООО «СалютДевайсы», GigaChat API; the rights holder of the service is Sberbank PJSC) | processing Requests of Customers that chose platform models — under the Customer's instruction (Section 9); the providers' terms and the restrictions on the data that may be sent to them are set out in Annex 2 to the Personal Data Processing Instruction (/en/legal/dpa) | Request content after masking |
| Public authorities | on the grounds and in the manner established by law | as requested |
7. Cookies
The website and the Console use only strictly necessary cookies (session, selected language) and browser local storage (theme, web chat history). No analytics or advertising cookies, third-party counters or widgets are used. See the "Cookie Policy" (/en/legal/cookies).
8. Data subject rights
8.1. A data subject may:
- obtain information about the processing of their PD (Article 14(7) of the PD Law);
- demand clarification, blocking or destruction of PD that are incomplete, outdated, inaccurate, unlawfully obtained or not necessary for the stated purpose;
- withdraw consent to PD processing;
- demand that processing stops (Article 21(5.1) of the PD Law);
- appeal against the Operator's actions or omissions to the Federal Service for Supervision of Communications, Information Technology and Mass Media (Roskomnadzor) or to a court.
8.2. How to exercise the rights. In the Console (Settings → Account) a User can export their data and request deletion of the account; signing in to the account confirms the requester's identity. A request may also be sent to ceo.orlova@yandex.ru or by post to 20 Kustodieva Street, building 1, flat 67, Saint Petersburg, 194352, Russia. A request sent by email from the address given in the account or in a contact-form enquiry is fulfilled once the requester has confirmed control of that address (by replying to the Operator's verification email). Other requests must contain the details required by Article 14(3) of the PD Law: the number of the main identity document of the data subject or their representative, its date of issue and the issuing authority; details confirming the data subject's relationship with the Operator (for example the account's email address or an invoice number) or otherwise confirming that the Operator processes their PD; and the signature of the data subject or their representative. A request in the form of an electronic document is signed with an electronic signature under the laws of the Russian Federation; a representative attaches a document confirming their authority.
8.3. Deadlines. The Operator answers a request within 10 working days of receipt; the period may be extended by no more than 5 working days with a reasoned notice (Articles 14 and 20 of the PD Law). A data export is prepared within this period and can be downloaded in the Console for 24 hours after it is ready. If consent is withdrawn, the Operator stops processing and destroys the PD within no more than 30 days (Article 21(5)) unless the law or a contract provides otherwise; a demand to stop processing is fulfilled within 10 working days (Article 21(5.1)).
8.4. Account deletion. On deletion: the User's API keys are revoked; organisations of which the User is the sole owner are deleted (if such an organisation has an active paid subscription, the owner and administrators are notified and given 25 days to transfer ownership); in the Request log the User identifiers, IP address and user agent are erased; emails, invitations and other records containing the email address are deleted. After deletion we keep only data that the law, the security of the Service or the protection of the Operator's rights requires: payment documents (item 4.5), audit log entries (item 4.3), consent evidence and records of data subject requests (with the email hash instead of the address, item 4.8), keyed hashes used to prevent abuse (item 4.4), and, for 30 days, the record of the email confirming the account deletion (item 4.6).
8.5. Withdrawing the consent referred to in item 4.1 makes it impossible to use the Service, because the Console cannot be accessed without an account.
9. Processing on behalf of Customers
9.1. The Customer is the operator of Request content and Request metadata. The Operator processes these data on the Customer's instruction and according to the Customer's settings. Data subject requests concerning such data are forwarded to the Customer (Personal Data Processing Instruction, /en/legal/dpa).
9.2. Request content (texts, attachments, model responses) and the pseudonym mapping table are processed only in the memory of the Gateway and of its auxiliary name-recognition and document-text-extraction services running on the same server, for the duration of one Request, and are not kept after it ends. Exceptions:
- results of recognising names of persons, organisations and places (the fragments of text found, their positions, normal and grammatical forms) are kept in the Gateway's memory separately for each organisation and reused for no longer than 10 minutes after recognition, to speed up repeated processing of texts of the same organisation; expired entries are not used and are removed from memory when looked up, when displaced by newer entries or when the Gateway restarts;
- text extracted from attached documents for masking is kept in the Gateway's memory in its original (unmasked) form, separately for each organisation, and reused for no longer than 10 minutes after extraction, so that the same document sent again (for example in the next message of a web chat conversation) is not extracted again; it is removed from memory no later than 30 seconds after that period ends; only the masked text is sent to the model provider, never the original file;
- 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, a User or a Request; these entries have no fixed retention period: they are displaced by newer entries and removed when the service restarts;
- the masking API returns an encrypted restore token containing the mapping table to the Customer; the Customer keeps the token, the Operator does not store it; the token is valid for 24 hours;
- web chat history is stored only in the User's browser.
The entries described in the first three items exist only in the memory of the Service's processes: the Service never writes them to files, databases, logs or error reports and does not disclose them 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.
9.3. Request metadata (who sent the Request and when, with which key, the model, the decision, the number of detected values per category, token counts, cost, latencies, the client IP address and user agent) are kept for the period set by the Customer within its plan (from 7 days to 3 years). If the Customer has enabled fingerprint storage, the Service stores keyed hashes (HMAC) of detected values computed with the organisation's key, never the values themselves.
9.4. Masking is performed by the Gateway on the Service's server in the Russian Federation; after masking, the Request is sent to the model provider chosen by the Customer. Values of categories for which the Customer set the action "allow" or "warn", attachments for which the action "allow" is set, and values the detectors did not find are sent to the provider unchanged. Masking reduces, but does not eliminate, the risk of PD reaching the provider; the limitations are listed in the Offer (/en/legal/terms) and on the website's Security page.
10. Security measures
10.1. The Operator takes the legal, organisational and technical measures provided for in Articles 18.1 and 19 of the PD Law, including:
- organisation of PD processing by the Operator herself as the person responsible for it (item 1.6); issuing this Policy and internal acts on PD processing and protection; briefing the persons admitted to PD processing on the PD legislation and these documents; assessing the harm that may be caused to data subjects; internal control of compliance of PD processing with the PD Law;
- role-based access control; two-factor authentication (mandatory for platform administrators); passwords stored only as argon2id hashes;
- encrypted connections (TLS 1.2 or later); encryption of provider connection credentials and secrets in the database (AES-256-GCM);
- no storage of Request content; logs and metrics contain no request bodies, authorisation headers or URL query strings;
- network segmentation (the database, the cache and object storage are not reachable from the internet), application components running as unprivileged users with read-only file systems, regular vulnerability scanning of images;
- audit logging of Console actions; daily database backups, each encrypted before it is uploaded to storage, with the decryption key kept separately from the Service;
- an incident response procedure, including notification of Roskomnadzor and interaction with GosSOPKA (Section 11).
10.2. The level of PD protection in the information system has been determined by the Operator, based on her own assessment, under Government Resolution No. 1119 of 1 November 2012 as protection level 4 (УЗ-4). The Operator does not claim to hold a certificate of conformity of the information system with information security requirements or FSTEC or FSB certificates, or to use certified information security tools.
11. Incidents
If an unlawful or accidental transfer (provision, dissemination, access) of PD that violates data subjects' rights is detected, the Operator notifies Roskomnadzor of the incident within 24 hours and of the results of the internal investigation within 72 hours (Article 21(3.1) of the PD Law), and informs GosSOPKA in the established manner. If the incident affects data processed on behalf of Customers, the Operator notifies each affected Customer no later than 12 hours after detection.
12. Retention and destruction
12.1. Retention periods are given in Section 4. When the purposes are achieved, the period expires or consent is withdrawn, PD are destroyed or depersonalised unless the law requires their retention. Destruction of PD is documented as required by the Requirements for confirming the destruction of personal data approved by Roskomnadzor Order No. 179 of 28 October 2022 (for automated processing: a PD destruction certificate and an extract from the event log of the information system).
12.2. Deleted data may remain in encrypted database backups. A backup is made daily and kept in object storage for 14 days: copies older than that are deleted after each successful backup; the Service's server keeps the last two copies. Deleted data therefore remain in backups for no more than 15 days or, if backups fail, until the first successful backup after they resume, and are then destroyed. Backups are used only to restore the Service.
12.3. A deleted organisation is kept for 30 days, after which its operational data are deleted; payment documents are kept for the period given in item 4.5.
13. Minors
The Service is intended for organisations and not for persons under 18. The Operator does not knowingly process PD of minors.
14. Changes to the Policy
The Operator may change the Policy. A new version with a new version identifier is published at /en/legal/privacy and takes effect on publication unless it states otherwise. Users are notified of material changes by email. The Operator keeps previous versions and provides them on request.
15. Contacts
Individual Entrepreneur Yulia Vitalyevna Orlova, 20 Kustodieva Street, building 1, flat 67, Saint Petersburg, 194352, Russia. Email (personal data questions and support): ceo.orlova@yandex.ru. Phone: +7 911 715-58-67.