1. General provisions
1.3. Service: The national chatbot service Bürokratt as a common chatbot solution of the state that allows users to contact institutions that have joined Bürokratt and integrated it into their infrastructure, including allowed access to integrated services through a chat window, and to exchange messages, attachments, documents, notifications etc.
1.3.1. Bürokratt allows users to interact with institutions through an automated chatbot or directly with a customer service agent if the chatbot is unable to provide an adequate response to the user’s enquiry or if the chatbot service is unavailable.
1.3.2. Both the customer service agent and the chatbot can offer to the end-user the services of the institution through the chat window.
1.3.3. Bürokratt is a distributed ecosystem of technical applications where data flows between its different instances. The training model elements that are necessary for providing information to Bürokratt instances are shared to allow for the redirection of user queries to an instance of the institution capable of resolving it.
1.3.4. User data is shared between institutions only when the end-user consumes services where the resolution of the request requires the transfer of data, queries, requests, attachments etc to third parties (as described in Section 3).
1.4. Service user: End-user who uses the chatbot on the website of an institution that has joined Bürokratt or through the mobile application.
1.5. Developer and manager of Bürokratt: Information System Authority (RIA).
2. Use of the Bürokratt service
2.1. The chatbot service can be started when a user initiates a conversation with a chatbot or customer service agent of an institution that has joined the Bürokratt chatbot service and has been integrated into its production. The user consumes the service via the institution’s website, mobile application or another supported channel.
2.2. For institution-specific enquiries, the user will receive responses based on the pre-trained queries specific to the institution they are interacting with. Institution trainers can train the chatbot to provide competent answers to users based on previous queries, which Bürokratt will use in the future to identify the reason for the user’s request and user’s preference, and respond to the user according to the pre-trained scenario.
2.3. The Bürokratt chatbot can be configured to handle general knowledge queries (courtesy messages, general information about the country etc) on the basis of the shared knowledge base and database of the Bürokratt ecosystem.
2.4. If the user’s objective is to consume an e-service provided by the state:
2.4.1. the e-service Bürokratt will redirect the user to the e-service through the chat window if the service is integrated with Bürokratt or the service is offered directly through the chat window, depending on the technical interface of the service integrated with Bürokratt;
2.4.2. the user will be redirected to the website of the service if the service is not integrated with Bürokratt.
2.5. Integrated e-services can be used through Bürokratt’s chat window if Bürokratt accurately identifies the user’s intention based on machine learning technologies and pre-trained data.
2.6. If Bürokratt detects that the user’s enquiry falls under the competence of another institution, the user may be redirected to a Bürokratt instance of another institution in the same chat window, of which the user will be notified by a message. In such a case, the enquiry, along with the previous conversation, will be forwarded to the Bürokratt instance of the other institution.
2.7. If the content of the user’s enquiry and the use of the service do not require user identification, the enquiry may be sent to a third party without prior notification and the response will be displayed without warning.
3. Handling of data
3.1. Personal data is data that, if leaked as a standalone database, could identify the person who made the enquiry. Such databases contain, for example, the personal identification code, IP address and other parameter associated with the person who made the enquiry, which, according to the knowledge of the Information System Authority, can be used to directly identify the person.
3.1.1. Personal data does not include, for example, first and last names provided in free-text format, as there is no certainty that the user is who they claim to be. Additionally, the reference code of the enquiry, which could be used to identify the person who made enquiry if it was combined with another database, such as the authentication information database, is not considered personal data.
3.1.2. Each database and its contents are handled separately, not in conjunction with other databases.
3.1.3. Databases created for data analytics, machine learning and other such purposes do not contain personal data.
3.1.4. As a rule, databases that enable identification are databases necessary for the operation of the service (eg to keep track of active sessions).
3.1.5. Databases that enable identification are stored by the owners of each Bürokratt instance.
22.214.171.124. As the central administrator of the Bürokratt ecosystem, the Information System Authority does not have access to the personalised data (eg network traffic and application server logs) and databases (eg users, session information) of the ecosystem instances.
126.96.36.199. In line with the principles of distributed learning, the enquiries sent to different parties of the ecosystem do not contain any data that could identify the person who submitted the enquiry (end-user).
3.2. Non-personal data is data that, if leaked as a standalone database, could not directly identify the person who made the enquiry. The principles on the basis of which data are considered personal or non-personal are described in the section on databases enabling identification (3.1).
3.2.1. Databases that do not enable identification include those primarily used for machine learning and analytics.
3.2.2. Databases that do not enable identification are typically designed for long-term use. The databases used for machine learning and analytics can be stored on the servers of the Information System Authority or the cloud service provider, and they can also be made available in a public code repository (eg natural language processing base data).
3.2.3. Databases that do not enable identification are mostly, but not always, part of the databases that support the operation of the service. For example, databases used as buffers significantly enhance the speed, cost-effectiveness, and concurrent usability of the service for a wide range of users; however, the absence of these databases does not render the application code technically inoperable.
3.3. In the case of Bürokratt as an ecosystem, queries can be routed in the following ways:
3.3.1. only within the infrastructure of the instance owner; and/or
3.3.2. to a central application responsible for managing shared knowledge; and/or
3.3.3. to a central enquiry classification module; and/or
3.3.4. through central message rooms to the different (potentially all) instances of the Bürokratt ecosystem.
4. User identification
4.1. If a user wishes to consume a service that involves the transfer of personal data from a third-party service to the user or requires the user to transfer information regarded as personal data, the user is asked to identify themselves through the State Authentication Service TARA.
4.2. A user has the option to authenticate themselves at any time and the identification request can also be forwarded by a customer service agent or chatbot if the customer expresses a desire to use a service that requires identification and the customer service agent or chatbot detects the user’s desire to use the service.