Skip to content

Personal Data Processing Policy

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 whole 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. 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: {{RU_OPERATOR_NAME}}, INN {{RU_OPERATOR_INN}}, OGRN {{RU_OPERATOR_OGRN}}, address: {{RU_OPERATOR_ADDRESS}} (the Operator, "we"). Registration number in the register of personal data operators: {{RU_RKN_REGISTRY_NUMBER}}.

1.3. The Policy applies to personal data processing when the Aitechestvo service is used in the Russian region (the Service): the website {{RU_SITE_URL}}, the management console (the Console), the web chat and the software gateway {{RU_GATEWAY_URL}} (the Gateway). [TECH-CHECK: as of this version the stand addresses are, for the website and the Console, https://aitechestvo.com (also https://айтечество.рф and the technical address https://aitech-ru.instatoggle.com) and, for the Gateway, https://gw.aitechestvo.com (technical address https://aitech-ru-gw.instatoggle.com); update when the domains change.]

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 is run by a different, non-Russian legal entity, which is 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. Person responsible for organising personal data processing (Article 22.1 of the PD Law): {{RU_DPO_NAME}}; email for personal data enquiries: {{RU_PRIVACY_EMAIL}}.

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. [LAWYER-REVIEW: confirm the wording on pseudonymisation versus depersonalisation.]
  • 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 Gateway's memory 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.PurposeData subjectsPersonal dataLegal groundRetention
4.1Registration and account management, access to the Console and web chat, organisation membershipUsers (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 loginconsent (Article 6(1)(1) of the PD Law); the contract with the Customer whom the data subject represents [LAWYER-REVIEW: confirm the grounds for Customer employees]until the account is deleted; deletion on request within 30 days (Section 8)
4.2Inviting users to a Customer's organisationinvited personsemail address, role, details of the inviting userlegitimate interests of the Customer and the Operator (Article 6(1)(7)) [LAWYER-REVIEW]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.3Service security, account protection, incident investigationUserssessions (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 per-IP rate limits (in an in-memory store, for no more than a few minutes)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)
4.4Preventing abuse of the trial periodorganisation owners; Customers that are sole proprietorskeyed hash (HMAC-SHA256) of the owner's normalised email address and of the organisation's INN; readable values are not storedlegitimate interests of the Operator (Article 6(1)(7)) [LAWYER-REVIEW]365 days after the record is created, including after the account and organisation are deleted
4.5Concluding and performing the contract with the Customer, payments, invoices, fiscal receiptsCustomer representatives, payers; Customers that are sole proprietorsorganisation 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 (email hash, IP address, user agent, time, document version)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.6Service notifications (email confirmation, password reset, invitations, security and billing notices, alerts configured by the Customer)Usersemail address, name, organisation name, details needed for the notice (never Request content)performance of the contract with the Customer; legitimate interests of the Operator (Article 6(1)(5), (7))the email queue is kept for 30 days; message parameters are erased right after sending
4.7Handling enquiries sent through the website contact formpersons who sent an enquiryname, email address, phone (optional), company (optional), message, enquiry type, language, IP addressconsent (Article 6(1)(1))12 months after the enquiry is handled (if never handled, after it was received)
4.8Sending advertising and informational messages about the Servicepersons who gave a separate consentemail address, name, languageseparate consent (Article 15(1) of the PD Law; Article 18(1) of Federal Law No. 38-FZ of 13 March 2006 "On Advertising")until consent is withdrawn
4.9Evidence of consents; handling data subject requestsUsers; persons who sent enquiriesconsent type, 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 [LAWYER-REVIEW: confirm the retention period for consent evidence]
4.10Masking demonstration on the websitewebsite visitorstext typed into the demo field (may contain PD at the visitor's choice); IP address (for rate limiting)the visitor's request for the demonstration [LAWYER-REVIEW: legal ground]the text is processed in memory only for the response and is not stored 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 its 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.

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 and retrieval of PD of citizens of the Russian Federation are performed using databases located in the Russian Federation (Article 18(5) of the PD Law): the databases 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 the Russian Federation. [LAWYER-REVIEW: check against the current wording of Article 18(5) (amendments effective from 1 July 2025); TECH-CHECK: obtain from Timeweb Cloud the address of the server's data centre and the location of the backup bucket (the provider also has locations abroad); update if the provider or the location changes.]

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). [TECH-CHECK: this holds only while neither users' traffic to the Service nor Requests sent to model providers (including after masking) pass through any node outside the Russian Federation (SPEC §0.1 item 4, §12.11). If such a node is introduced (e.g. a proxy server at DigitalOcean), that is a cross-border transfer of PD: before it starts, file the Article 12 notice and rewrite this clause, Section 6, the Consent to PD processing and the PD processing instruction. Owner decision 2026-10-15: such a node — 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, docs/runbooks/open-risks.md). Sending email through Resend is likewise allowed only on staging with synthetic data (R-57); in production email goes through Unisender Go.]

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. [LAWYER-REVIEW]

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 below and only to the extent necessary for the stated purposes [LAWYER-REVIEW: check names and roles against the contracts concluded]:

PartyRole and purposeData
TIMEWEB.CLOUD LLC (Timeweb Cloud)compute and storage for hosting the Service infrastructure: a virtual server in Moscow (databases, cache, object storage) and object storage for the encrypted database backups [LAWYER-REVIEW: the Timeweb Cloud offer (version of 6 February 2026, clause 9.4) states that the contract is not an instruction to process PD and that the provider does not process the customer's PD; decide whether to list it as a party instructed to process PD or as an infrastructure supplier, and whether a separate contract is needed]all data stored in the Service (backups in encrypted form)
Unisender Smart LLC (Unisender Go service)delivery of the Service's email — processing on the Operator's instruction [LAWYER-REVIEW: PD processing terms under the Unisender Go Terms of Use (version of 23 September 2026) and whether a separate instruction is needed]recipient addresses, names and message texts
NCO YooMoney LLC (YooKassa)payment acceptance, saving payment methods for recurring payments, fiscal receiptspayment details, receipt email, buyer details (name, INN) where available. Card data are entered on the YooKassa page and are not passed to the Operator
Dadata LLC [LAWYER-REVIEW: legal name]retrieving organisation details by INN at the User's requestINN (personal data for sole proprietors)
Platform model providers: Yandex.Cloud LLC (YandexGPT), Sberbank PJSC (GigaChat) [LAWYER-REVIEW: GigaChat API counterparty]processing Requests of Customers that chose platform models — under the Customer's instruction (Section 9)Request content after masking
Public authoritieson the grounds and in the manner established by lawas 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 and consent to receive advertising;
  • 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. A request may also be sent to {{RU_PRIVACY_EMAIL}} or by post to {{RU_OPERATOR_POSTAL_ADDRESS}}. The request must allow the data subject to be identified and confirm their relationship with the Operator (Article 14(3) of the PD Law); an electronic request sent outside the Console must be signed with an electronic signature. [LAWYER-REVIEW: identification procedure for requesters not using the Console.]

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 or the protection of the Operator's rights requires: payment documents (item 4.5), consent evidence (email hash, item 4.9) and keyed hashes used to prevent abuse (item 4.4).

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. Opting out of advertising does not affect use of the Service.

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 Gateway's memory for the duration of one Request and are not kept after it ends. Exceptions:

  • results of name and organisation recognition (positions and normal forms) may be kept in the Gateway's memory for up to 10 minutes to speed up repeated processing of texts of the same organisation; they are never written to disk or to databases;
  • 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.

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", 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:

  • appointing the person responsible for organising PD processing, issuing internal policies, briefing staff and internal control [LAWYER-REVIEW: list the policies actually issued];
  • 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 under Government Resolution No. 1119 of 1 November 2012 as {{RU_PROTECTION_LEVEL}}. [LAWYER-REVIEW: state the level resulting from the Operator's own assessment. The Operator does not claim to hold an information system certificate of conformity, FSTEC or FSB certificates, or certified information security tools; do not add such statements until the documents have actually been obtained.]

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 its 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 is documented in the manner established by Roskomnadzor. [LAWYER-REVIEW: procedure for documenting destruction.]

12.2. Deleted data may remain in encrypted database backups for no more than 15 days (each daily backup is kept for 14 days) and are destroyed when this period expires. Backups are used only to restore the Service. [TECH-CHECK: the period matches the backup retention setting (14 days) as of this version, with versioning of the backup bucket off; update it if that changes.]

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

{{RU_OPERATOR_NAME}}, {{RU_OPERATOR_ADDRESS}}. Personal data questions: {{RU_PRIVACY_EMAIL}}. Support: {{RU_SUPPORT_EMAIL}}.