Personal Data Processing Policy
Version of:
This is a translation. The Russian version at
/legal/privacyis the one in force; where the two differ, the Russian text prevails.
1. Operator
| Legal name | Limited liability company «ITERNA RESHENIYA» |
|---|---|
| OGRN (state registration number) | 1267400015409 |
| INN (taxpayer number) | 7453369705 |
| KPP | 745301001 |
| Address | 6 Ternopolskaya St., office 158, workplace 31, Chelyabinsk, Chelyabinsk Region, 454080, Russia |
| Email for questions about the service | support@iterna.ai |
| Email for personal-data requests | privacy@iterna.ai |
Requests from data subjects are accepted at the personal-data email address listed above. An answer is sent within ten working days of receipt; that term may be extended by no more than five working days with a reasoned notice (art. 20(1) of 152-FZ).
2. Definitions
Operator — the party whose details are given in section 1. Capitalised, the word “Operator” denotes only that party throughout this Policy. Lower-case, “operator” denotes the role of an operator of personal data under 152-FZ; in respect of Correspondents’ data that role belongs to the User (section 3).
Service — the Iterna software and the access to its functionality provided through
iterna.ai and app.iterna.ai.
User — a person who has registered an account in the Service.
Scenario — a configuration for handling messages and data, created by a User.
Correspondent — a person who addresses a User’s scenario through a chat page, an embedded widget, a messenger or another connected channel.
Model provider — an organisation providing access to a language or other model that the User selected in their scenario.
3. Two categories of subject, processed differently
This is the central section: which of the two categories a person falls into determines who sets the purposes of processing, who obtains consent, and where a request should be sent.
(a) Users of the Service. In respect of their data the Operator is the operator of personal data: it determines the purposes and the scope itself. This Policy is the primary document for this category.
(b) Correspondents of scenarios. Their messages, files and other data enter the Service because a User’s scenario was built that way. In respect of this data the User is the operator, and the Operator processes it on the User’s instruction (art. 6(3) of 152-FZ) in the scope the scenario defines. The Operator does not set the purposes of such processing, does not verify the lawfulness of the User’s acquisition of that data, and has no direct relationship with Correspondents.
The practical consequence: if you wrote to a company’s chat that runs on Iterna and want to know what is held about you, address that company. It identifies itself in its own policy; on such a request the Operator can only forward it to the User.
4. What data is processed
4.1 Users of the Service
| Data | Source |
|---|---|
| Email address | given at registration or passed by Yandex ID on sign-in through it |
| Name (optional) | given at registration or in the profile, or passed by Yandex ID |
| Yandex ID account identifier | passed by Yandex ID on sign-in through it; used only for signing in |
| Password as an irreversible hash | created at registration; the original password is not stored |
| Interface language | the user’s choice |
| IP address, date, time and outcome of actions: sign-in, registration, password change, permission changes, operations on secrets and connections | recorded automatically in the security log |
| State of interface hints | recorded automatically while using the interface |
| Plan, balance of accounting units, spending history | produced by use of the Service |
| Address and delivery status of Service emails | produced when emails are sent |
| Payment attributes: identifier, amount, currency, date and status of a payment, the label and masked number of a saved payment method | received from the payment provider at payment; card details are neither passed to nor stored by the Operator |
A separate category is a person invited by a User to a workspace. The Operator receives their email address from the User and processes it in order to send the invitation, on the basis of the agreement with the User. Once the invitation is accepted, that address becomes an account address and is processed on the general terms.
The Operator does not request identity-document data, health data, biometric data or any other special category of personal data for the operation of the Service.
4.2 Data processed on the User’s instruction
The scope of this data is determined by the User’s scenario. Technically the Service is capable of storing:
- chat message texts, including Correspondents’ messages and the scenario’s answers;
- files attached to messages or uploaded to the workspace store;
- the contents of documents uploaded to knowledge bases and the vector representations derived from them;
- message history in connected messengers: platform id, chat id, participant id and name, message text, timestamp;
- the contents of document-store tables and of agent memory;
- the run log of scenarios: the input and output of every step.
5. Purposes and legal grounds
| Purpose | Ground |
|---|---|
| Providing access to the Service, identifying the User | contract (art. 6(1)(5) of 152-FZ), the offer |
| Sending service emails: address confirmation, password recovery, invitations, low-balance notices | contract |
| Settlements for use of the Service, issuing documents | contract, accounting legislation |
| Security: sign-in and action logs, incident investigation | legitimate interest (art. 6(1)(7)), art. 19 of 152-FZ |
| Improving the Service from anonymised visit statistics | legitimate interest (art. 6(1)(7)); how to refuse is set out in the Cookie Policy |
| Processing Correspondents’ data | the User’s instruction (art. 6(3)) |
Consent to the processing of a User’s personal data is given at registration by a separate action. The text is Consent to Personal Data Processing.
6. Retention
Account data is kept for as long as the account exists and is destroyed within thirty days of withdrawal of consent or of the purpose being achieved (art. 21(4)–(5) of 152-FZ), unless a different term is set by law.
Deleting an account. A User deletes their account in the Service’s interface. From the moment of the request, access to the account is closed, published scenarios stop answering and automatic plan renewal is switched off. The request can be cancelled in the Service’s interface within seven days; cancelling does not restore automatic renewal. After seven days the entire contents of the User’s workspaces, including scenarios, files and knowledge bases, are destroyed irreversibly, and the email address and the name in the account are replaced with anonymised values. Records of charges and payments are kept, without personal data, for the terms set by accounting legislation: they evidence settlements, not identity.
The retention of the run log depends on the plan. The values in force are in the plan limits table, which is generated from the Service’s configuration and therefore cannot disagree with actual behaviour. The numbers are deliberately not repeated in this text.
Other terms:
- chat and messenger history is kept until the User deletes it, or until the messenger-history term set by the plan expires;
- files, knowledge bases and tables are kept until the User deletes them;
- data required for accounting and tax purposes is kept for the terms set by law.
7. Where data is processed
Accounts, scenarios, files, knowledge bases, message history and logs are stored on servers located in the Russian Federation. The recording, systematisation, accumulation, storage, amendment and retrieval of personal data of citizens of the Russian Federation is carried out using databases located in the Russian Federation (art. 18(5) of 152-FZ).
8. Disclosure to third parties
The Operator does not sell personal data and does not disclose it for third-party marketing. Disclosure happens only to the extent needed for the Service to work, to the following categories of recipient:
| Category | What is passed | When |
|---|---|---|
| Model providers | the request text the scenario composed and the files attached to it; the text of a request to the built-in assistant | on every model call — see section 9 |
| Platforms of connected channels (e.g. messengers) | the messages the scenario sends to a Correspondent | when the scenario is published to that channel |
| External services a scenario calls | whatever the scenario sends them | per the scenario’s configuration; the recipient is chosen by the User |
| Programs to which the User has issued a workspace access key | workspace data within the permissions the User set when issuing the key | while the key is valid; the User issues and revokes it |
| Email delivery provider | recipient address and the text of a service email | when Service emails are sent |
| Payment provider (YooKassa) | order identifier and amount, currency, the payer’s email address | at payment and at automatic renewal |
| Web analytics provider | anonymised information about the site visit | from the start of the visit; how to refuse — see the Cookie Policy |
| Infrastructure provider (server hosting and object storage) | data resides on the provided hardware | continuously |
The list of model providers available in the Service as at today’s date is in section 9. The Operator may change the set of recipients; a change to the list of model providers is published on this page no later than ten days before it takes effect.
9. Model providers
The Service does not build models. It passes the request composed by a scenario to the model provider chosen by the User, and returns the answer.
Where the request is processed. The request a scenario composes is processed on the side of the provider of the model the User selected. The Operator engages model providers to process data on its instructions and may change which ones; a User may also connect a key of their own and work with the model of a provider they choose.
Who determines the contents of the request. The data in a request is determined by the User as the author of the scenario. The Service adds none of the User’s own data to a request — the account, payment details and logs are never sent to a model — and does not alter its contents.
Calls the Service itself makes. Besides the requests a scenario composes, the Service calls
a model provider in its own name in two cases. The built-in assistant in the editor receives the
text of the task the User typed and information about the scenario they are working on; the
anonymisation facilities described below do not apply to those calls. The chat helper on
iterna.ai is an ordinary scenario published on the site: anonymisation applies to it exactly
as it does to any scenario in an embedded chat.
Your own key. If a User connects their own model-provider key, requests run under the User’s agreement with that provider. Such requests are not charged by the Service.
Training. The Operator does not use the contents of requests and answers to train models. A model provider’s terms may differ and are set out in that provider’s documents; reading them before selecting a model is the User’s responsibility.
Anonymisation facilities. The Service provides facilities for automatically anonymising recognised identifiers before a request is sent to a model provider. Completeness of recognition depends on the format of the data and is not guaranteed. The mapping between anonymised and original values is restored on the Service’s side and is not passed to the model provider. Consequences of sending data with anonymisation switched off rest with the User.
Anonymisation applies to the request text. It does not apply to attachments — photographs, scans, voice messages — nor to the contents of documents uploaded to knowledge bases, to web-search queries, or to a scenario’s own HTTP calls to external services.
Limits on subject matter. The Service is not intended for sending third parties’ personal data, or information constituting a legally protected secret, to models.
10. Rights of the data subject
A subject may obtain information about the processing of their data, require its amendment, blocking or destruction, withdraw consent, and appeal the Operator’s actions to Roskomnadzor or in court.
How to make a request: an email to the personal-data address given in section 1, stating the subject’s name, information confirming their relationship with the Operator (for example the account email address), and the substance of the request.
Terms: ten working days to provide information (art. 20(1)), ten working days to remedy unlawful processing (art. 21(3)), thirty days to destroy data on withdrawal of consent or achievement of the purpose (art. 21(4)–(5)).
If the request concerns messages sent to a company’s chat running on Iterna, it is addressed to that company — see section 3.
11. Protective measures
The Operator takes the legal, organisational and technical measures required by arts. 18.1 and 19 of 152-FZ. The technical measures are described in the documentation under Data and security; in particular:
- access separation by workspace, enforced in storage rather than in the interface;
- encryption of keys and secrets held on the User’s behalf;
- restriction of the Service’s outbound network calls;
- execution of user code in an isolated environment with no access to the database or secrets;
- a log of security-relevant actions.
On establishing an unlawful transfer of personal data the Operator notifies Roskomnadzor within 24 hours and submits the results of its internal investigation within 72 hours (art. 21(3.1)).
12. Cookies
The cookies used, their purposes and how to refuse them are set out in the Cookie Policy.
13. Changes to this Policy
The Operator may amend this Policy. The version in force is always available at
/legal/privacy; the redaction date is shown at the top of the document. Material changes
are published no later than ten days before they take effect.