1. General provisions
1.3. Service: Bürokrat's national chatbot service as the country's unified chatbot solution, which users can contact institutions that have joined Bürokrat and integrated into their own infrastructure, including enabling access to integrated services through the chat window, and transmitting messages, attachments, documents, notifications, etc. from both sides.
1.3.1. Bureaukrat allows the user to communicate with institutions both through an automated chatbot and directly with a customer service representative in the event that the chatbot cannot provide a competent answer to the user's request or if the chatbot's service is not active.
1.3.2. In addition, both the customer service representative and the chatbot can offer the end user the services of the institution through the chat window.
1.3.3.Bureaucrat is a distributed ecosystem of technical applications in which data flows between its various instances. The elements of the training models are shared, which are necessary to provide information to the Bureaucrat's instances, in order to enable the user's appeal to be directed to the institution's instance, whose competence is to solve it.
1.3.4. User data is shared between institutions only if the end user consumes services, in which case the resolution of the appeal requires the transfer of data, requests, requests, attachments, etc. to third parties (described in point 3).
1.4 Service user: end user who uses the chatbot when chatting on the website of the institution that has joined Bürokrat or through the mobile application.
1.5 Bureaucrat developer and administrator: State Information System Agency (RIA).
2. Using the service of a bureaucrat
2.1. The chatbot service can be started when the user starts a conversation with the chatbot or customer service representative of the institution that has joined the Bürokrat chatbot service and is integrated into the production. The user consumes the service through the institution's website, mobile application or other supported channel.
2.2. In the case of institution-specific appeals, the user is given answers based on pre-trained appeals of the institution with which the end user communicates. Trainers of institutions can train the chatbot to answer the user with a competent answer, based on previous appeals, based on which Bürokratt will identify the reason for the end user's appeal and the user's desire in the future, and respond to the user based on a pre-trained scenario.
2.3. The Bureaucrat chatbot can be configured to serve queries at the level of general knowledge (polite statements, general information about the country, etc.) at the level of a common knowledge/database that is part of the Bureaucrat ecosystem.
2.4. If the user's goal is to consume some e-service provided by the state,
2.4.1. the user is directed to the e-service Bürokrat, if the service is interfaced with Bürokrat, to the e-service through the chat window or the service is offered directly through the chat window depending on the technical level of the integrated interface of the specific service with Bürokrat;
2.4.2. the user is redirected to the service page if the service is not integrated with Bürokrat.
2.5. Interfaced e-services can be used through Bürokratt's chat window if Bürokratt identifies the user's desire with sufficient confidence using machine learning technologies and pre-trained data.
2.6. The user may be directed to another institution's Bureaucrat instance within the same chat window, informing the user of this with the message ..... , in the event that the Bureaucrat determines that the end user's question falls within the competence of another institution. In such a case, the appeal will be forwarded to the Bürokrat instance of another institution together with the previous interview.
2.7. The user's request may be sent to a third party without warning, and a response will be displayed, without a corresponding warning, if the content of the request and the use of the service do not require identification of the user's identity
3. Data handling
3.1. Data enabling identification of a person are data which, if leaked, can be used as a separate database to identify the person who made the request. Such databases contain, for example, the identity code, IP or other parameters of the person who made the request, with the help of which, as far as RIA is aware, it is possible to directly identify the person.
3.1.1. The data enabling personalization does not include, for example, the first and last name entered in free text form, because there is no certainty that the user is actually who he claims to be. Also, the reference code of the request, which when combined with another, e.g. with the database of authentication information, it would be possible to identify the person who made the request.
3.1.2. Each database and its contents are treated separately, not in interaction with other databases.
3.1.3. Databases created for data analysis, machine learning, etc. do not contain data enabling personalization
3.1.4. As a rule, databases that enable personalization belong to the databases necessary for the operation of the service (e.g. to keep track of active usage sessions).
3.1.5. Databases enabling identification of a person are kept with the owner of each Bürokrat instance.
_cc781905-5cde-3194- bb3b-136bad5cf58d_ 126.96.36.199. RIA, as the central administrator of the Bürokrat ecosystem, does not have access to personalized data (e.g. logs of network traffic and application servers) and databases (e.g. users, session information) of ecosystem instances.
_cc781905-5cde-3194- bb3b-136bad5cf58d_ 188.8.131.52. Based on the principles of distributed learning, requests made to different parties of the ecosystem do not contain data enabling the personalization of the requester (end customer).
3.2. Data that do not allow personalization are data that, if leaked as a separate database, it is not possible to directly identify the person who made the request. The principles on the basis of which data are considered to enable personalization or not are described in section (3.1) on databases enabling personalization.
3.2.1. Databases that do not allow personalization mainly include databases used for machine learning and analytics.
3.2.2. Databases that do not allow personalization are generally long-lived. Databases used for machine learning and analytics can be located on the servers of both the RIA and the cloud service provider, and can also be published in a public code repository (e.g. basic data of language technology).
3.2.3. Databases that do not allow personalization are, as a rule, but not always, among databases that support the operation of the service. For example, databases used as buffers make the service significantly faster, cheaper and simultaneously usable by a wide range of consumers, but in their absence the application code does not become unusable in a technical sense.
3.3. With Bureaucrat as an ecosystem, queries can move
3.3.1. only within the infrastructure of the instance owner; and/or in addition
3.3.2. to the central application managing shared knowledge; and/or in addition
3.3.3. to the central request classification module; and/or in addition
3.3.4. through central message rooms to different (potentially all) instances of the Bureaucrat ecosystem.
4. User identification
4.1. In the event that the user wishes to consume a service, as a result of which personal data is transferred to the user from a third-party service or the user has to transfer information that is treated as personal data, the user is asked to identify himself through the state authentication service TARA.
4.2. The user can identify himself at any time, and the identification request can also be forwarded by a customer service agent or a chatbot if the customer expresses a desire to use a service that requires identification and the chatbot or customer service agent detects the user's desire to use the service.