Personal agent execution and audit method with adaptive generation of execution plans and auxiliary verification functions

Abstract

A personal agent execution and auditing method equipped with adaptive generation and auxiliary verification functions of an execution plan may include: an operation of generating an execution plan including the name and execution order of a target task corresponding to the user request using a first artificial intelligence model when a user request is received from a user terminal; an operation of inputting the user request, the execution plan, and device status information received from the user terminal into a second artificial intelligence model that is distinct from the first artificial intelligence model and learned based on a preset policy rule, thereby generating a verification result for the execution plan; an operation of determining whether to execute the target task based on the execution plan based on the verification result; and, when the target task is executed according to the determination of whether to execute, an operation of generating and storing audit information for the execution result and updating at least one model parameter of the first artificial intelligence model and the second artificial intelligence model using at least a portion of the audit information.

Description

Technology Field

[0001] The present invention relates to a personal agent execution and auditing method equipped with adaptive generation of execution plans and auxiliary verification functions. Background Technology

[0002] With the recent advancement of artificial intelligence technology, natural language processing-based agent systems are being utilized in various industrial fields. In particular, personal agents based on large language models can understand user requests and automatically perform various tasks based on them, thereby significantly improving user convenience.

[0003] However, these AI-based agents have limitations in terms of the accuracy or reliability of the generated results. In particular, there may be cases where the execution plans or responses generated by the model do not match the actual user's intent, or where actions are performed based on incorrect information.

[0004] Furthermore, existing AI systems often execute without sufficient consideration of user permissions, device status, or security environments, which can lead to issues such as security vulnerabilities or data leaks. These problems are particularly severe in environments that handle personal information or sensitive data.

[0005] Meanwhile, when AI agents perform tasks such as executing actual system commands, transmitting external data, or controlling devices, pre-verification and post-auditing are essential to ensure the safety of such execution. However, existing systems do not have these verification and auditing functions sufficiently integrated.

[0006] Furthermore, while the method of transmitting user data to an external server during the training and improvement process of artificial intelligence models is commonly used, this has limitations in terms of personal information protection and can also pose issues regarding data security and regulatory compliance. In this regard, documents such as Published Patent Application No. 10-2025-0160818 and Published Patent Application No. 10-2022-0085561 have been disclosed. The problem to be solved

[0007] The problem that the present invention aims to solve is to prevent errors and abnormal behavior that may occur during the execution of an artificial intelligence-based personal agent and to improve the reliability of the execution.

[0008] The problem that the present invention aims to solve is to provide a technology capable of determining the risk level of a target task by comprehensively considering various factors such as user authority, device status, and network environment, and deciding whether to execute the task based thereon.

[0009] The problem that the present invention aims to solve is to enable more stable system operation by providing a dual verification structure that performs verification of an execution plan generated by an artificial intelligence model in advance and confirms the suitability of the results even after execution.

[0010] The problem that the present invention aims to solve is to enable post-audit and tracking by systematically recording events occurring during the execution process of an artificial intelligence agent and storing them in a form that prevents tampering.

[0011] The problem that the present invention aims to solve is to simultaneously achieve privacy protection and model performance improvement by providing a learning structure that can continuously improve the performance of an artificial intelligence model while minimizing the external transmission of user data.

[0012] The technical problems of the present invention are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below. means of solving the problem

[0013] A method for executing and auditing a personal agent using multiple artificial intelligence models in a local priority and on-device environment, performed by an electronic device including a processor according to an embodiment of the present invention, may include: an operation in which the processor, upon receiving a user request from a user terminal, generates an execution plan for a target task corresponding to the user request using a first artificial intelligence model on the on-device; an operation in which the processor generates a verification result based on a policy rule or a predefined criterion for the execution plan using a second artificial intelligence model distinguished from the first artificial intelligence model; an operation in which the processor determines whether to execute the target task based on the execution plan based on the verification result; and an operation in which, if the target task is executed according to the determination of whether to execute, the processor generates and stores audit information regarding the execution result and updates at least one model parameter of the first artificial intelligence model and the second artificial intelligence model using at least a portion of the audit information. Effects of the invention

[0014] The effects of the personal agent execution and auditing method according to embodiments of the present invention are described as follows.

[0015] According to the present invention, by performing a separate verification process on an execution plan generated by an artificial intelligence model, incorrect execution can be prevented in advance and the reliability of the entire system can be improved.

[0016] According to the present invention, by determining the risk level of a target task based on user authorization information and device status information, appropriate execution control suitable for the situation is possible, and security incidents can be prevented.

[0017] According to the present invention, by including not only pre-execution verification but also a post-execution audit function for the results, an integrated verification system can be provided throughout the entire execution process.

[0018] According to the present invention, data integrity can be ensured by recording events occurring during the execution process in a hash chain structure, thereby providing a reliable audit log.

[0019] According to the present invention, user data is not directly transmitted externally but is processed within the device and shared only in the form of parameters, thereby enhancing personal information protection while simultaneously achieving continuous learning and performance improvement of the artificial intelligence model.

[0020] In addition, various effects that can be identified directly or indirectly through this document may be provided. Brief explanation of the drawing

[0021] FIG. 1 is a block diagram showing the components of an electronic device according to one embodiment of the present invention. FIG. 2 is a block diagram showing the components of a personal agent execution and auditing system according to one embodiment of the present invention. FIG. 3 is a block diagram conceptually illustrating the overall operation flow and components of a personal agent execution and auditing system according to one embodiment of the present invention. FIG. 4 is a block diagram conceptually illustrating the overall operation flow and components of a personal agent execution and auditing system according to one embodiment of the present invention. FIG. 5 is a block diagram conceptually illustrating the overall operation flow and components of a personal agent execution and auditing system according to one embodiment of the present invention. FIG. 6 is a flowchart of the operation of a personal agent execution and auditing method according to one embodiment of the present invention. In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Specific details for implementing the invention

[0022] Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that in assigning reference numerals to the components of each drawing, the same components are given the same reference numeral whenever possible, even if they are shown in different drawings. Furthermore, in describing the embodiments of the present invention, if it is determined that a detailed description of related known components or functions would hinder understanding of the embodiments of the present invention, such detailed description is omitted.

[0023] In describing the components of the embodiments of the present invention, terms such as first, second, A, B, (a), (b), etc., may be used. These terms are intended merely to distinguish the components from other components, and the essence, order, or sequence of the components is not limited by the terms. Furthermore, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application.

[0024] Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 1 to 3.

[0026] FIG. 1 is a block diagram showing the components of an electronic device according to one embodiment of the present invention.

[0027] According to one embodiment, the electronic device (100) may include a memory (110), a processor (120), a communication interface (130), and / or a display device (140). The configuration of the electronic device (100) illustrated in FIG. 1 is exemplary and the embodiments of the present invention are not limited thereto. For example, the electronic device (100) may further include components not illustrated in FIG. 1 (e.g., a user interface, an input device, a notification unit, a sensor unit, or at least one of any combination thereof).

[0028] According to one embodiment, the memory (110) may store instructions or data. For example, the memory (110) may store one or more instructions that cause the electronic device (100) to perform various operations when executed by the processor (120).

[0029] For example, the memory (110) may be implemented as a single chipset with the processor (120). The processor (120) may include at least one of a communication processor or a modem.

[0030] For example, the memory (110) can store various information related to the electronic device (100). For example, the memory (110) can store information regarding the operation history of the processor (120). For example, the memory (110) can store input data acquired by the electronic device (100), output data output by the electronic device (100), data acquired from an external server, a wearable device, a plurality of cameras and / or user terminals, etc.

[0031] For example, the memory (110) may include multiple storage devices of different types. For example, the memory (110) may include volatile and / or non-volatile storage media. For example, the memory (110) may include at least one of RAM (random-access memory), ROM (read only memory), eMMC (Embedded Multi-Media Card), or any combination thereof.

[0032] The steps of the method or algorithm described in connection with the embodiments disclosed in this specification may be directly implemented in hardware, software modules, or a combination of both, executed by the processor (120). The software modules may reside in a storage medium (i.e., memory (110)) such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, or a CD-ROM.

[0033] For example, the memory (110) is coupled to a processor (120), and the processor (120) can read information from a storage medium and write information to a storage medium. Alternatively, the memory (110) may be integrated with the processor (120). The memory (110) and the processor (120) may reside within an application-specific integrated circuit (ASIC). The ASIC may reside within a user terminal. Alternatively, the memory (110) and the processor (120) may reside as separate components within the user terminal.

[0034] According to one embodiment, the processor (120) may be operatively connected to the memory (110), the communication interface (130), and / or the display device (140). For example, the processor (120) may control the operation of the memory (110), the communication interface (130), and / or the display device (140).

[0035] According to one embodiment, the communication interface (130) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between an electronic device (100) and an external device (e.g., user terminal (210) of FIG. 2, external server (220), etc.), and the performance of communication through the established communication channel. The communication interface (130) may include one or more communication processors that operate independently of the processor (120) (e.g., application processor) and support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication interface (130) may include a wireless communication module (e.g., cellular communication module, short-range wireless communication module, or GNSS (global navigation satellite system) communication module) or a wired communication module (e.g., LAN (local area network) communication module, or power line communication module). The corresponding communication module among these communication modules can communicate with an external electronic device through a first network (e.g., a short-range communication network such as Bluetooth, WiFi (wireless fidelity) direct, or IrDA (infrared data association)) or a second network (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a long-range communication network such as a computer network (e.g., LAN or WAN). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module can identify or authenticate the electronic device (100) within a communication network, such as the first network or the second network, using subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in a subscriber identification module.

[0036] According to one embodiment, the display device (140) may include at least one output device that provides various information and a user interface to the user.

[0037] For example, the display device (140) may include a display device, an audio output device, a virtual reality output device, etc.

[0038] For example, the display device (140) can provide the user with various types of user interfaces described in the present disclosure visually and / or audibly.

[0039] The components of the electronic device (100) illustrated in FIG. 1 are exemplary, and the embodiments of the present disclosure are not limited thereto.

[0040] At least some of the embodiments of the present disclosure may be implemented as artificial intelligence (AI) through a processor (120) and memory (110) of an electronic device (100). The processor (120) may be composed of one or more processors, and the one or more processors may be general-purpose processors such as a CPU, AP, DSP (digital signal processor), etc., graphics-dedicated processors such as a GPU, VPU (vision processing unit), or artificial intelligence-dedicated processors such as an NPU. The one or more processors may be controlled to process input data according to predefined operation rules or artificial intelligence models stored in memory (110). Alternatively, if the one or more processors are artificial intelligence-dedicated processors, the artificial intelligence-dedicated processors may be designed with a hardware structure specialized for processing a specific artificial intelligence model.

[0041] The predefined operation rules or artificial intelligence models are characterized by being created through learning. Here, being created through learning means that a predefined operation rules or artificial intelligence models configured to perform a desired characteristic (or purpose) are created by a basic artificial intelligence model being trained using a number of learning data by a learning algorithm. Such learning may be performed within the electronic device (100) itself where the artificial intelligence according to the present disclosure is performed, or it may be performed through a separate server and / or system. Examples of learning algorithms include supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but are not limited to the examples described above.

[0042] An artificial intelligence model may be composed of multiple neural network layers. Each of the multiple neural network layers has multiple weight values ​​and can perform neural network operations through operations between the results of previous layers and the multiple weights. The multiple weights possessed by the multiple neural network layers can be optimized based on the learning results of the artificial intelligence model. For example, the multiple weights can be updated so that the loss value or cost value obtained from the artificial intelligence model during the learning process is reduced or minimized. Artificial neural networks may include, but are not limited to, deep neural networks (DNN), convolutional neural networks (CNN), recurrent neural networks (RNN), restricted Boltzmann machines (RBM), deep belief networks (DBN), bidirectional recurrent deep neural networks (BRDNN), or deep Q-networks.

[0043] The electronic device (100) can receive a user request in the form of natural language from a user terminal (210). The electronic device (100) can take the user request as input, analyze the user's intent through a first artificial intelligence model, and generate an execution plan for a target task to perform the request.

[0044] At this time, the first artificial intelligence model performs context analysis, intent classification, and workflow generation functions, and can generate a structured execution plan including multiple work steps and an execution sequence corresponding to each step.

[0045] The electronic device (100) can perform verification on an execution plan generated by a first artificial intelligence model using a second artificial intelligence model. The second artificial intelligence model can determine the suitability, safety, and policy compliance of the execution plan based on policy rules, device status information, and external or internal data. Through this, the electronic device (100) can prevent errors that may occur before execution and reduce the possibility of policy violations.

[0046] The electronic device (100) can collect device status information during the process of handling user requests. The device status information may include the network status of the user terminal (210), the location of the device, power status, temperature status, and security status, etc.

[0047] The electronic device (100) can calculate the execution risk of a target task through an artificial intelligence model or a rule-based algorithm using device state information as input, and determine whether to execute the target task according to the risk.

[0048] After the execution of the target task is completed, the electronic device (100) can verify the execution result using a second artificial intelligence model. At this time, the electronic device (100) can determine whether there is a match by comparing the execution plan with the actual execution result, and can detect if an abnormal execution has occurred. In addition, the electronic device (100) can perform follow-up actions or provide a notification to the user based on the verification result.

[0049] The electronic device (100) can store events and results that occurred during the execution of a target task in the form of an audit log. The audit log may include execution order, commands executed, execution results, and device status information.

[0050] The electronic device (100) can generate training data for improving the performance of an artificial intelligence model based on an audit log and update model parameters through this.

[0051] The electronic device (100) can process raw data internally without transmitting it to an external server (220) in order to minimize the external transmission of user data. The electronic device (100) transmits only update parameters generated in the local environment to the external server, and the external server (220) can update the artificial intelligence model by aggregating parameters collected from multiple electronic devices including the electronic device (100). In this process, the electronic device (100) or the external server (220) can improve the level of personal information protection by applying differential privacy techniques.

[0052] The electronic device (100) can select the execution location of the artificial intelligence model by considering the characteristics of the user request, the computational resources of the device, the network status and the response delay requirements.

[0053] For example, the electronic device (100) can run an artificial intelligence model on-device for simple requests and call an artificial intelligence model located on an external server to process complex requests.

[0055] FIG. 2 is a block diagram showing the components of a personal agent execution and auditing system according to one embodiment of the present invention.

[0056] According to one embodiment, the personal agent execution and auditing system may include an electronic device (100), a user terminal (210), and an external server (220).

[0057] According to one embodiment, the electronic device (100) is a core processing unit for processing user requests and performing various functions based on artificial intelligence, and can be implemented in various forms such as a smartphone, tablet, server device, wearable device, in-vehicle control device, or Internet of Things (IoT) device. This electronic device (100) serves as a central node that interacts directly with the user and plays a role in controlling the overall operation of the system.

[0058] The electronic device (100) may include computational resources for receiving and interpreting user input, and may internally execute an artificial intelligence model to generate a processing result for a user request. In this process, the electronic device (100) may analyze the user's intent and configure an appropriate processing flow to perform the request.

[0059] The electronic device (100) can collect device status information of the user terminal (210) and adjust its operation based on this information. The device status information may include network connection status, power status, location information, and security status, and this information can be used as an important judgment criterion to ensure the stability and safety of the system.

[0060] The electronic device (100) can store data and log information generated during the execution process, including an internal storage, and can perform additional computational processing or data exchange by linking with an external server (220) as needed. At this time, the storage and transmission of data can be carried out while considering personal information protection and security requirements during the data processing process.

[0061] The electronic device (100) can record various events that occur during the execution process and improve the operation of the system based on this. For example, by analyzing errors or abnormal behavior that occur repeatedly, the system can be optimized to enable a more appropriate response in similar situations in the future.

[0062] According to one embodiment, the user terminal (210) is an interface device for a user to interact with the system and may include a smartphone, a personal computer, a tablet, or other input device. The user terminal (210) receives various forms of input from the user and performs the role of transmitting them to the electronic device (100).

[0063] The user terminal (210) can support various input methods such as keyboard input, voice input, and touch input, and through this, the user can transmit commands to the system based on natural language. Such inputs may include not only simple commands but also complex task requests.

[0064] The user terminal (210) can provide the user with processing results in a visual or auditory form. For example, it can output execution results in the form of text, images, notification messages, or voice guidance, and may include various user interfaces to enhance the user experience.

[0065] The user terminal (210) may include user authentication and authorization management functions, thereby enabling the system to perform appropriate access control for each user. For example, user account information, login status, and authentication tokens may be managed through the user terminal (210).

[0066] The user terminal (210) can store user settings and preferences and reflect them in system operations. For example, information regarding usage restrictions for specific functions, notification settings, or the provision of personalized services may be stored in the user terminal (210).

[0067] According to one embodiment, the external server (220) is a system that communicates with the electronic device (100) to perform additional computational processing and data management, and can be implemented as a cloud server, a data center, or a remote computing environment. The external server (220) can contribute to reducing the processing burden of the electronic device (100) and ensuring scalability.

[0068] The external server (220) can utilize large-scale computing resources to execute complex artificial intelligence models or perform tasks that are difficult to process on behalf of the electronic device (100). For example, high-volume data analysis or high-performance model inference tasks can be performed on the external server (220).

[0069] The external server (220) can collect data from a plurality of electronic devices including the electronic device (100) and perform statistical analysis or model learning based thereon. This can improve the performance of the entire system and provide more sophisticated services.

[0070] The external server (220) may support the secure storage and transmission of data by including security and access control functions. For example, data may be transmitted through an encrypted communication channel, or access to data may be restricted according to user rights.

[0071] The external server (220) can perform central management functions for system updates, policy management, and service operation. This allows for maintaining consistency throughout the system and efficiently reflecting the addition of new features or changes to policies.

[0073] FIG. 3 is a block diagram conceptually illustrating the overall operation flow and components of a personal agent execution and auditing system according to one embodiment of the present invention.

[0074] FIG. 3 illustrates an overall conceptual diagram (300) of a personal agent execution and auditing system using a local priority and on-device-based multiple artificial intelligence model according to one embodiment of the present invention.

[0075] The system illustrated in FIG. 3 can be configured to receive user requests or device events from multiple input environments, such as a desktop or web environment, a mobile application, a wearable or vehicle interface, firmware, or an IoT device, and to process them centered around a local agent runtime.

[0076] The local agent runtime is not limited to a configuration that simply converts user requests into text responses, but can function as an intermediate processing layer to analyze user intent and determine the feasibility of target tasks.

[0077] For example, the local agent runtime can request the Main AI, the first artificial intelligence model, to generate an execution plan after checking the task type, execution target, required permissions, relevant device status, and whether a policy applies to the user request.

[0078] The Main AI can be implemented as a local or cloud-based large-scale language model and can generate execution plans, tool call information, device control commands, or structured responses corresponding to user requests. In this case, the Main AI is executed preferentially in an on-device environment whenever possible, and may optionally be integrated with an external cloud LLM depending on the complexity of the request, the device's computational resources, network conditions, or the acceptable response delay.

[0079] Audit AI is a second artificial intelligence model distinct from Main AI, capable of verifying whether execution plans or tool call information generated by Main AI conform to policy rules, security standards, device status, user rights, or ground data. Audit AI can be implemented as a relatively lightweight SLM or sLLM and, by running on-device, can minimize the transmission of sensitive user data externally.

[0080] The Policy Engine is a component responsible for execution control within the system and can be used to determine whether to execute target tasks by referencing user permissions, organizational policies, personal settings, device policies, risk criteria, and the like. For example, if a target task involves external data transmission, system command execution, or device control, the Policy Engine may classify the task as a high-risk task and require user or administrator approval.

[0081] The Private RAG / Evidence configuration can function as an internal knowledge layer for the Audit AI and Policy Engine to secure grounds for verification. By searching policy documents, device manuals, historical audit logs, user history, failure history, operational guides, or the enterprise's internal knowledge base, this configuration can provide the basis for judgment regarding pre- or post-audits of execution plans.

[0082] Enterprise Policy / KB can be implemented as a knowledge repository storing organizational-level policies, compliance standards, lists of prohibited behaviors, licensing policies, or tenant-specific operational rules. Private RAG / Evidence can be integrated with Enterprise Policy / KB to generate verification results utilizing document-based evidence rather than simple model inference.

[0083] The Action Executor, Tool Router, and Device Control are the layers that perform actual execution based on verification results. These layers can perform specific actions such as file system access, external API calls, message transmission, document editing, operating system command execution, IoT device control, or vehicle interface control. However, such executions can only be performed if permitted by the Audit AI and Policy Engine.

[0084] Additionally, the Action Executor can generate audit information from events occurring during execution. For example, the audit information may include executed commands, invoked tools, execution timestamps, user approval status, device status, execution results, and error information. The audit information can be stored in a hash chain structure or a tamper-proof log structure and can be utilized for subsequent post-audits or model updates.

[0085] The Integrated Management Server is a component that performs integrated management of the entire system and can provide model registry, policy bundling, telemetry, tenant control, and remote update capabilities. Through this, artificial intelligence models, policy rules, and audit criteria used by multiple electronic devices can be managed centrally, and different policy or model versions can be deployed based on the status of each device.

[0086] The Integrated Management Server can receive update parameters from multiple electronic devices and aggregate them to improve model parameters. In this case, raw data is not transmitted outside the electronic device (100), and only update parameters or delta values ​​generated in the local environment can be transmitted to the server. Additionally, the possibility of re-identifying personal information can be reduced by applying differential privacy-based noise.

[0087] According to the configuration of Fig. 3, unlike existing structures where a single artificial intelligence model is responsible for interpreting user requests, generating execution plans, calling tools, and determining execution, the present invention can be configured by separating the Main AI responsible for execution and the Audit AI responsible for verification. Through this, generation quality and execution reliability can be simultaneously secured, and the possibility of policy violations, execution beyond privilege, incorrect device control, or leakage of sensitive information can be reduced.

[0088] In addition, since the system of Fig. 3 is based on a local-first structure, it can provide a certain level of agent functionality even in environments where network connectivity is limited or the external transmission of sensitive data is restricted. In particular, it can be flexibly applied in environments where device resources and security requirements differ, such as mobile, wearable, vehicle, firmware, and IoT environments.

[0089] Consequently, the conceptual diagram (300) of FIG. 3 shows a structure in which user request reception, execution plan generation, policy-based verification, evidence search, execution control, post-audit, log storage, and model update are connected as one integrated flow.

[0090] This structure provides a policy-based AI execution platform that can clearly control the scope of execution and security responsibilities while maintaining the autonomy of personal agents.

[0092] FIG. 4 is a block diagram conceptually illustrating the overall operation flow and components of a personal agent execution and auditing system according to one embodiment of the present invention.

[0093] FIG. 4 shows a conceptual diagram (400) illustrating the overall processing flow including the generation of an execution plan, policy-based verification, and auditing of a personal agent according to one embodiment of the present invention.

[0094] Referring to FIG. 4, a user request entered by a user can be provided as the initial input of the system. The user request can be entered in the form of natural language, voice, or structured commands, and can define a target task to be performed by the personal agent.

[0095] In this case, user requests can be combined with global prompt rules. Global prompt rules may include default policies applied commonly across the system, definitions of prohibited behaviors, response format restrictions, or security requirements, and serve to set the default behavioral direction of the artificial intelligence model.

[0096] In addition, user requests can be processed with Personal / Tenant / Device Rules, which include rules based on personal settings, tenant policies, and device characteristics. This allows different execution conditions to be applied depending on the user environment, even for the same request.

[0097] Information reflecting global rules and user-specific rules can be structured through Context Builder, which can generate prompts provided as input to Main AI, the first artificial intelligence model.

[0098] The Main AI can generate an execution plan corresponding to a user request based on the above prompt, and the execution plan may include the sequence of tasks to be performed, necessary tool calls, data access methods, and device control commands.

[0099] In addition, Main AI is not limited to generating simple text responses but can generate actual executable structured output (e.g., execution plans in JSON format or API call information).

[0100] The execution plan generated by the Main AI can be combined with the Audit Policy Prompt and Risk Profile and passed to the second AI model, the Audit AI.

[0101] The Audit Policy Prompt may include policy rules, security criteria, user permissions, device status, and risk assessment criteria, and the Risk Profile may define risk criteria or acceptance conditions based on specific task types.

[0102] Based on the above input, Audit AI determines whether the execution plan complies with the policy and can modify or block the execution plan as necessary. For example, if the execution plan involves access to sensitive data, Audit AI may determine to restrict it or require additional authentication.

[0103] As illustrated in FIG. 4, the system (or electronic device (100)) can retrieve evidence data such as policy documents, device manuals, past audit logs, or user history through the Evidence Retrieval component.

[0104] The retrieved evidence data can be utilized in the Risk Score calculation and Hallucination Check processes, which allows for determining whether the Main AI's output is based on facts.

[0105] The Risk Score can be calculated by reflecting user permissions, device status, network environment, and data sensitivity, and the Hallucination Check can verify whether the content generated by the AI ​​model was created without actual grounds.

[0106] Based on the Audit AI verification results and Risk Score, the system can determine the final execution policy.

[0107] For example, the system can select the following results:

[0108] Allow: Execute immediately

[0109] Revise: Re-verify after changing the execution plan

[0110] Top Report (Escalate): Request Administrator Approval

[0111] Block: Prohibit execution

[0112] These decisions may be made based on criteria defined by the Policy Engine or policy rules, and user approval requests may also be made through the user interface.

[0113] When the execution is finally performed, the system can generate audit information along with the execution results.

[0114] For example, audit information may include executed commands, execution time, user approval status, device status, execution results, and error information, and may be stored in the form of an integrity log including a hash chain structure.

[0115] These audit logs can be utilized for post-audits, security analysis, policy improvement, and artificial intelligence model training.

[0117] FIG. 5 is a block diagram conceptually illustrating the overall operation flow and components of a personal agent execution and auditing system according to one embodiment of the present invention.

[0118] FIG. 5 illustrates a conceptual diagram (500) showing a process of improving an artificial intelligence model (e.g., updating model parameters of an artificial intelligence model) based on update information generated from a plurality of electronic devices according to one embodiment of the present invention, and safely distributing the same.

[0119] The system of the present invention may be configured to collect learning-related information generated in a local environment from a plurality of client devices (Client A, Client B, Client C, etc.) and to improve the overall artificial intelligence model or policy structure based thereon.

[0120] Each client device can generate update parameters for an artificial intelligence model in a local environment based on execution results, audit logs, or policy evaluation results generated during the user request processing process. In this case, the client device does not transmit raw data externally, but can generate only information in the form of parameters, such as adapter updates or critic updates, corresponding to the results processed locally.

[0121] The update parameters generated in this way can be passed to the Secure Aggregation stage. Secure Aggregation is a process of aggregating update information received from multiple clients while protecting it so that it cannot be individually identified; it can be designed to maintain the data contribution of each client without exposing individual user information.

[0122] Update parameters aggregated through Secure Aggregation can be passed to a stage where differential privacy techniques are applied. In this stage, noise is added according to a predefined privacy budget, making it difficult to trace back individual user information from the aggregated data.

[0123] The aggregated results with such privacy protection applied can be converted into a Global Adapter or a Policy Critic Bundle. Here, the Global Adapter may refer to parameter updates to enhance the performance of the overall AI model, while the Policy Critic Bundle may contain information to improve the judgment criteria of the model performing policy verification or risk assessment.

[0124] The generated Global Adapter or Policy Critic Bundle can be gradually deployed through Canary Rollout or Rollback mechanisms. Canary Rollout is a method to verify stability by applying updates to a select number of users or devices first, and if issues arise, the system can be restored to a previous state via Rollback.

[0125] In addition, updates can be distributed via the Signed Distribution method. That is, the distributed model or policy data is electronically signed to guarantee integrity, thereby preventing malicious tampering or the application of unauthorized updates.

[0126] According to the structure illustrated in FIG. 5, the present invention can continuously improve the performance of the entire system based on learning information collected from a plurality of devices while maintaining a local priority learning structure in which user data is not directly transmitted externally.

[0127] In addition, by combining Secure Aggregation and differential privacy techniques, it is possible to provide a learning structure that utilizes only collective knowledge without exposing individual user information. This satisfies personal information protection requirements while simultaneously improving the generalization performance of artificial intelligence models.

[0128] Furthermore, through Canary Rollout and a signature-based deployment structure, the stability and reliability of model updates can be ensured, and errors or performance degradation that may occur during system operation can be minimized.

[0129] Consequently, the conceptual diagram (500) of FIG. 5 represents an integrated artificial intelligence operational structure including local learning, secure aggregation, privacy protection, policy and model improvement, and stable deployment, which can function as a key component that enables the personal agent system of the present invention to continuously evolve while maintaining security and reliability.

[0131] Meanwhile, the electronic device (100) of the present disclosure can perform dual model-based operations including a first artificial intelligence model and a second artificial intelligence model distinct therefrom.

[0132] According to one embodiment, the first artificial intelligence model is a model for interpreting user requests and generating corresponding execution plans, and can perform the role of converting user intent into a structured workflow. This first artificial intelligence model can be trained using various forms of input and output data during the training process.

[0133] The training input data of the first artificial intelligence model may include user requests, contextual information included in the user requests, parts of device status information, user history information, and previous execution cases. Here, the user requests may be in the form of natural language text, data converted from voice input into text, or structured commands. Additionally, the contextual information may include the user's previous conversation content, current working environment, time information, or user preferences.

[0134] The training output data of the first artificial intelligence model may include an execution plan corresponding to the input data. The execution plan may be structured data including the name of the target task, the sequence of execution steps, tool call information to be performed at each step, input data, and expected output results. For example, the execution plan may be expressed in the form of a JSON structure, a command list, or an internal execution schema.

[0135] The correlation between the input and output data of the first artificial intelligence model can be defined as a transformation relationship of “user intent → executable workflow.” In other words, the model can perform learning by interpreting the meaning of an input user request and breaking it down into step-by-step tasks that can be performed in the actual system.

[0136] For example, if the user request is “summarize the meeting minutes and share them on the team channel,” the output data of the first AI model may include the following execution plan:

[0137] Search meeting minutes files

[0138] Document Content Summary

[0139] “Check for inclusion of sensitive information”

[0140] Create shared message

[0141] Send to Team Channel

[0142] As another example, if a request such as “Check the current temperature and turn on the air conditioner” is input, the output data may consist of steps such as “retrieving sensor data,” “comparing based on temperature,” and “generating and executing air conditioner control commands.”

[0143] In this way, the first artificial intelligence model can convert various forms of user requests into actual executable workflows by learning the correspondence between input user requests and output execution plans. This learning structure can function as a key element that enables a personal agent system to support actual task execution beyond simple question-answering.

[0144] According to one embodiment, the second artificial intelligence model may operate as an audit model to determine the suitability, safety, and policy compliance of an execution plan generated by the first artificial intelligence model. To perform verification of the execution plan, the second artificial intelligence model may be trained based on training data that reflects policy rules and supporting data.

[0145] The training input data for the second artificial intelligence model may include user requests, execution plans, policy rule information, device status information, user authorization information, and supporting data (e.g., RAG-based search results). Here, the execution plan refers to a workflow generated by the first artificial intelligence model, and the policy rules may include allow / disallow criteria, security policies, authorization criteria, etc. Additionally, the device status information may include network status, security status, location information, etc.

[0146] The training output data of the second artificial intelligence model may include verification results for the execution plan. The verification results may include status information, such as allow, correction, top-level reporting, or block, and may additionally include the reason for verification, risk level, or correction suggestion information.

[0147] The correlation between the input and output data of the second artificial intelligence model can be defined as the relationship of “execution plan and environmental conditions → determination of feasibility.” In other words, the model can perform learning to determine the suitability of an execution by considering not only the execution plan itself but also the environmental and policy conditions under which the execution will be performed.

[0148] For example, if a user request is “send the customer list to an external email” and the execution plan includes the “file access → external transmission” step, and the policy rule includes a rule prohibiting the external transmission of personal information, the output data of the second AI model may include a verification result such as “block” or “modification (transmission after masking).”

[0149] As another example, even with the same execution plan, if the user authority is administrator and the network is an internal network, an “allow” result may be generated, and if the user is a general user and the network environment is a public network, a “report to higher level” or “block” result may be generated.

[0150] In addition, the second AI model can determine whether there is a discrepancy between the execution plan and the user request. For example, if the execution plan includes an external transmission even though the user request is a simple query, the output data may be generated as “modified” or “blocked.”

[0151] In this way, the second artificial intelligence model can learn relationships that generate verification results by comprehensively considering execution plans, policy rules, and environment information included in the input data, and thereby improve the execution stability and policy compliance of the personal agent system.

[0152] In one embodiment, the first artificial intelligence model and the second artificial intelligence model are not limited to models that are simply functionally defined, but can be implemented as mutually distinct models with differently defined input data structures, output data structures, and processing purposes.

[0153] For example, as described above, the first artificial intelligence model is a model for generating an execution plan for a target task based on a user request, and may include at least one of a user request, user context information, and device status information as input data. Here, the user request may include natural language commands, voice input, or structured command forms, and the user context information may include user history, preferences, previous execution records, or session information, etc. Additionally, the device status information may include network status, battery status, location information, or device performance status.

[0154] The output data of the first artificial intelligence model may include an execution plan for a target task, and the execution plan may include a step structure composed of multiple sub-tasks. Specifically, the execution plan may be generated in the form of structured data including at least one of the name of the target task, the execution order of each step, the actions performed at each step, the required permission information, the tool call information, the input data, and the expected output result. For example, the execution plan may be expressed in JSON, a list, or a tree structure, and each step may be defined in the form of a function call or an instruction.

[0155] In addition, the first artificial intelligence model can be trained through supervised learning, reinforcement learning, or user feedback-based learning. For example, the performance of generating execution plans can be improved by using pairs of past user requests and corresponding appropriate execution plans as training data, or by using the success or failure of execution results and user satisfaction as reward signals.

[0156] For example, as described above, the second artificial intelligence model is a model for auditing and verification purposes distinct from the first artificial intelligence model, and may include at least one of user requests, execution plans, policy rules, device status information, and RAG-based evidence data as input data. Here, the execution plan refers to the result generated by the first artificial intelligence model, and the policy rules may include security policies, authorization rules, data processing rules, or organizational policies.

[0157] The output data of the second artificial intelligence model may include the result of determining the suitability of the execution plan, and the output may be expressed as a verification result including at least one of allow, modification, upline reporting, or blocking. Additionally, the output data may further include explanatory information (explainable output) including not only simple status information but also the reason for verification, applied policy rules, risk assessment results, and a summary of supporting data.

[0158] The second artificial intelligence model can be trained through policy rule-based learning, anomaly detection learning, or historical audit log-based learning. For example, it can be trained to predict the likelihood of policy violations using historical execution plans and their allowance or blocking results as training data, and the anomaly detection model may be configured to distinguish between normal and abnormal execution patterns.

[0159] In addition, the second artificial intelligence model is not limited to being implemented as a single model, but can be implemented as a hybrid structure combining rule-based filters, classification models, and generative models. For example, it is possible to detect obvious policy violations primarily through rule-based filters and secondarily evaluate context-based risk using an artificial intelligence model.

[0160] In this way, the first AI model is configured to function as a generative model that generates execution plans, and the second AI model is configured to function as an audit-oriented model that verifies the suitability of the generated execution plans; thereby, execution stability and policy compliance can be improved through a dual structure in which generation and verification are separated.

[0161] Meanwhile, the ground data based on Retrieval-Augmented Generation (RAG) according to the present disclosure can be generated not through simple data retrieval, but through a structure that includes multiple search methods and similarity evaluation.

[0162] Specifically, the electronic device (100) can perform at least one of keyword-based search and embedding-based search on an internal database containing policy documents, device manuals, past audit logs and user history information.

[0163] Keyword-based search can be performed by searching for documents or logs within a database using core keywords extracted from the execution plan or user request. For example, an electronic device (100) can extract core tokens such as nouns, verbs, or named entities using natural language processing techniques, and search for related data by performing an inverted index or string matching based thereon.

[0164] Additionally, embedding-based search can be performed by converting an execution plan or user request into a vector form and then comparing it with a vector representation of a document or log stored in an internal database to search for similar data. At this time, the electronic device (100) can convert text data into a high-dimensional vector space using a pre-trained sentence embedding model or language model.

[0165] Similarity calculation can be performed by calculating the similarity between a query vector generated from an execution plan or user request and a document vector stored in a database, and can be performed using at least one of cosine similarity, dot product, or Euclidean distance. The processor can select data or the top k data whose similarity value is greater than or equal to a preset threshold and utilize them as search results.

[0166] Additionally, the electronic device (100) can generate a final search result by combining keyword-based search results and embedding-based search results. For example, the electronic device (100) can prioritize data that is commonly selected in both search methods, or calculate an integrated score by assigning weights to the results of each search method, and select top data accordingly.

[0167] Subsequently, the electronic device (100) may generate a basis for verification of the execution plan based on the retrieved data, and the basis for verification may include natural language descriptions, policy rule citations, summaries of past cases, or grounds for judgment regarding whether there is a violation of regulations. The basis for verification may be provided as input to a second artificial intelligence model and used to determine the suitability of the execution plan.

[0168] According to this structure, the electronic device (100) can go beyond simple rule-based verification and generate explainable verification results based on actual documents and logs, thereby improving the reliability and reproducibility of the verification.

[0170] FIG. 6 is a flowchart of the operation of a personal agent execution and auditing method according to one embodiment of the present invention.

[0171] According to one embodiment, the components of a personal agent execution and auditing system may perform the operations disclosed in FIG. 6. For example, at least some of the components included in the electronic device (100) among the components of the personal agent execution and auditing system (e.g., memory (110), processor (120), communication interface (130), and display device (140) of FIG. 1) may be configured to perform the operations of FIG. 6.

[0172] In the following embodiments, the operations of S610 to S640 may be performed sequentially, but are not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel. Additionally, content corresponding to or overlapping with the above description in relation to FIG. 6 may be briefly explained or omitted.

[0173] According to one embodiment, when the processor (120) receives a user request from a user terminal, it can generate an execution plan for a target task corresponding to the user request using a first artificial intelligence model on the device (S610).

[0174] The electronic device (100) can receive a user request from a user terminal (210). Here, the user request may include a command entered by the user in natural language, a voice command, a touch input, a selection menu input, a request generated by a system event, or a task request transmitted from another application.

[0175] For example, the user can input requests such as “summarize this document and send it to an external partner,” “extract only the tasks from the meeting minutes and register them in the calendar,” or “change the operating mode of the currently connected IoT device” through the user terminal (210). The electronic device (100) may not treat these requests as simple question-and-answer targets, but may use them as inputs to interpret them as actual target tasks that can be performed.

[0176] At this time, the user terminal (210) may be a smartphone, tablet, laptop, desktop computer, vehicle interface, wearable device, or IoT control terminal. The electronic device (100) may be implemented as the same device as the user terminal (210), or as a separate local device capable of communicating with the user terminal.

[0177] For example, the smartphone itself may operate as an electronic device (100), or the user's laptop may operate as an electronic device and receive requests from the smartphone. This configuration allows user data to be processed in a local environment first, rather than being immediately transmitted to an external server in an on-device environment.

[0178] When the electronic device (100) receives a user request, it can generate an execution plan for a target task corresponding to the user request using a first artificial intelligence model on the device.

[0179] Here, the first AI model may be a model that interprets the meaning of a user request and constructs a workflow corresponding to the user's intent. The first AI model can be implemented as a large-scale language model, a lightweight language model, a multimodal model, or an agent model specialized in generating task plans. The important point is that the first AI model does not merely generate a simple response, but rather generates an execution plan that includes actual actionable steps.

[0180] A target task may refer to a unit of work that must be performed in response to a user request. Target tasks may include document summarization, document creation, email composition, file search, API calls, system command execution, device control, data conversion, report generation, schedule registration, notification creation, or external transmission operations.

[0181] For example, the target task of the request “Summarize the meeting minutes and share them on the team channel” can consist of multiple sub-tasks, such as identifying the meeting minutes file, summarizing the content, verifying sensitive information, drafting a sharing message, and sending it to the team channel.

[0182] An execution plan may include one or more steps to perform a target task, the order of each step, tools to be used, input data, expected output, required permissions, execution conditions, or whether user approval is required.

[0183] For example, an execution plan for a request to transfer a document externally may include sequential steps such as “identifying document location,” “summarizing document content,” “checking for the inclusion of personal information,” “identifying the destination,” “creating a transfer message,” “requesting user approval,” and “performing the transfer.” This execution plan may be in natural language form or in a structured form such as a tabular format, JSON, a list of commands, or an internal execution schema.

[0184] The first artificial intelligence model can analyze the intent of user requests, classify task types, select necessary tools, determine the execution order, and generate structured responses.

[0185] For example, if a user requests, “Organize last week’s sales table and create a report,” the first AI model determines that the request corresponds to a document processing and report generation task, and can generate an execution plan that includes searching for necessary data files, organizing table data, generating summary sentences, and generating a report file.

[0186] In this way, the first artificial intelligence model functions as a central component that converts user requests into an actually executable form.

[0187] Generating an execution plan on-device may mean that user requests and related data are processed first within the electronic device (100). This is advantageous for reducing the direct transmission of personal information, business documents, device status information, or sensitive user context to an external server.

[0188] For example, in the case of a request containing a user's personal schedule, internal documents, location information, or device control information, the electronic device can generate an execution plan through a local artificial intelligence model without transmitting such information externally.

[0189] Additionally, the electronic device (100) may execute the first artificial intelligence model differently depending on the complexity of the user request or the state of the device resources.

[0190] For example, requests for short document summaries or simple configuration changes can be handled using only on-device models, while requests requiring analysis of very long documents or large-scale searches can generate a basic plan locally and then utilize an external server model as a supplementary tool to the necessary extent.

[0191] Since this execution plan generation step becomes the input for the subsequent verification step, it is desirable for the electronic device (100) to configure the execution plan in a verifiable form.

[0192] For example, an execution plan may include the target file, API to be called, required permissions, destination, expected output, device control commands, and risk tags.

[0193] When an execution plan is structured in this way, it can be easier for a second artificial intelligence model or policy rule to determine the feasibility of execution based on each item in subsequent stages.

[0194] According to one embodiment, the processor (120) can generate a verification result based on policy rules or predefined criteria for an execution plan using a second artificial intelligence model that is distinct from the first artificial intelligence model (S620).

[0195] The electronic device (100) can generate a verification result for an execution plan generated by a first artificial intelligence model using a second artificial intelligence model that is distinct from the first artificial intelligence model.

[0196] Here, the second artificial intelligence model may be an audit model for determining the suitability, safety, policy compliance, or risk of the execution plan. If the first artificial intelligence model performs the role of generating the execution plan, the second artificial intelligence model performs the role of verification to determine whether the execution plan can actually be executed.

[0197] The second AI model may not be the same model instance as the first AI model, but may be implemented as a separate model distinguished in terms of role, training data, input prompts, policy criteria, or execution environment.

[0198] For example, the first AI model may be one that creatively and flexibly interprets user requests to generate action plans, while the second AI model may be one that is trained or configured to strictly apply security policies, privacy standards, organizational rules, device status, and risk criteria. Accordingly, the possibility of error propagation can be reduced compared to a case where a single model performs both generation and verification.

[0199] The execution plan subject to verification may include not only the execution order of the target task, but also tool call information, file access paths, external transmission targets, API call arguments, device control commands, and output results or intermediate deliverables to be provided to the user.

[0200] For example, if the first AI model generates an execution plan to “summarize a customer list file and send it to an external email address,” the second AI model can review whether the plan includes personal information or internal data, whether external transmission is permitted, whether user permissions are sufficient, whether additional approval is required, etc.

[0201] Policy rules may include execution restriction criteria, organizational policies, user-specific settings, device-specific restrictions, or service operation criteria stored on electronic devices or local storage.

[0202] For example, policy rules may include criteria such as “documents containing personal information must be masked before external transmission,” “administrator authority commands cannot be executed without user approval,” “device control operations are restricted when the battery level is below a certain level,” and “internal documents are not transmitted externally on unauthorized networks.” Additionally, or generally, policy rules may further include an authority level value mapping table in which authority level values ​​corresponding to the authority level of the user terminal (210) are mapped.

[0203] The predefined criteria are not necessarily limited to policies in the form of documents and may include thresholds, risk criteria, approval criteria, device status criteria, execution time limits, network trust criteria, or data sensitivity criteria that are pre-set in the electronic device (100).

[0204] For example, file deletion commands, system setting change commands, external API calls, or IoT device control commands may be defined as having a higher risk than plain text responses. The second artificial intelligence model can use these criteria to determine whether the execution plan is within an acceptable range.

[0205] The verification result may be information indicating the status of the execution plan. For example, the verification result may include a status of execution allowed, execution blocked, execution plan modification request, user approval request, administrator approval request, or further review required.

[0206] For example, if the execution plan corresponds to a simple document summary and does not contain sensitive information, the verification result may be generated as "Allowed." On the other hand, if the execution plan involves external transmission and personal information is detected, the verification result may be generated as "Modified" or "Blocked."

[0207] The second artificial intelligence model is not limited to a method of mechanically comparing only policy rules, but can determine actual risk by interpreting the context of the execution plan.

[0208] For example, if a user requests, “Send this material to a partner,” the second AI model can comprehensively determine whether the material is an internal document, whether the partner is an allowed recipient, whether the material contains secret information, and whether masking is required before transmission. In this way, the second AI model can consider both structured rules and unstructured context.

[0209] In addition, the second artificial intelligence model can determine whether a command or tool call included in the execution plan exceeds the scope of the user's original request.

[0210] For example, if a user requests "find a file" but the execution plan includes steps for "delete file" or "upload to external server," the second AI model can determine that the execution plan is outside the scope of the user request. This verification is useful for preventing AI models from being deceived or exercising excessive privileges.

[0211] The operation of generating verification results can take the nature of a pre-audit performed prior to execution. Since a pre-audit is a procedure that identifies risks before the target task is actually executed, it can prevent incorrect tool calls, leakage of sensitive information, execution beyond privilege, or device malfunction.

[0212] For example, if an execution plan to change the operating mode of an IoT device is generated, the second artificial intelligence model can verify the safety of the corresponding control command based on the device manual, current temperature, network status, and user permissions.

[0213] The electronic device (100) can store the verification results of the second artificial intelligence model for use in the subsequent execution decision step, or manage them in a form connected with the execution plan.

[0214] For example, the execution plan identifier, verification time, policy rules used for verification, verification results, reasons for verification, and related supporting data can be stored as a single verification record. This configuration is advantageous for explaining the grounds on which an execution was permitted or blocked in the event of an audit or dispute after execution.

[0215] According to one embodiment, the processor (120) can determine whether to execute a target task based on an execution plan based on a verification result (S630).

[0216] The electronic device (100) can determine whether to execute a target task based on an execution plan based on a verification result generated by a second artificial intelligence model.

[0217] Here, the decision regarding execution is not limited to a simple dichotomous judgment of execution or non-execution, but may include multiple execution control states such as immediate execution, execution plan modification, user approval request, administrator approval request, conditional execution, or execution blocking.

[0218] The execution decision step can be understood as a control layer performed before the output of an artificial intelligence model leads to actual system operation. While conventional agent systems may execute plans generated by the model immediately or without separate user verification, the present invention undergoes a separate execution decision process based on verification results. This reduces the likelihood of plans incorrectly generated by the AI ​​model or plans with a potential for policy violations being executed in the actual environment.

[0219] For example, if the verification result of the second artificial intelligence model is "allowed," the electronic device (100) may determine that the target task included in the execution plan is executable. Conversely, if the verification result is "blocked," the electronic device (100) may decide not to execute the target task and may provide the user terminal (210) with a reason for blocking. If the verification result is "modified," the electronic device (100) may change some steps of the execution plan or mask sensitive information and then perform re-verification. If the verification result is "upper report," the electronic device (100) may request user approval or administrator approval from the user terminal (210) (and / or external server (220)).

[0220] The decision on whether to execute can be made by considering policy rules, verification results, user rights, device status, the type of target task, and risk information together.

[0221] For example, even for the same “document transmission” task, if the document is public material and the recipient is an internal user, it can be executed immediately, but if the document is an internal secret document and the recipient is an external email address, user approval or administrator approval may be required. In this way, the electronic device (100) can determine whether to execute by taking into account the context of the request and environmental conditions together.

[0222] If the target task includes external data transmission, system command execution, or device control, the electronic device (100) may classify the task as a high-risk task. External data transmission carries the risk of leakage of personal information or internal documents, system command execution may entail risks such as file deletion, permission changes, or setting changes, and device control may affect the actual physical environment. Therefore, a higher level of control may be applied to these tasks than to simple information retrieval or summarization.

[0223] If classified as a high-risk task, the electronic device (100) may transmit a user approval request through the user terminal (210). The approval request may include the content of the task to be executed, expected results, reasons for risk, relevant policies, recipients, access target data, or device control details.

[0224] For example, an approval message such as “This operation involves sending an external email and contains phone numbers within the document. Would you like to mask them before sending?” may be provided. The user can confirm this and provide input to approve or reject.

[0225] The electronic device (100) may decide to execute the target task only when an approval input is received from the user, only when the verification result is a top report and / or when the target task is classified as a high-risk task. Conversely, execution may be blocked if no approval input is received, if an explicit rejection input is received, or if the approval time expires. Since this method includes a human verification process for high-risk tasks, it can provide a balance between the autonomy of the artificial intelligence agent and user control.

[0226] In the execution decision step, the risk level of the target task may also be utilized. The electronic device (100) can determine the risk level based on authorization information included in the policy rule and device status information received from the user terminal (210).

[0227] For example, if the user's privilege level is low, the user terminal is connected to a public network, and the device location is outside the allowed zone, the same task may be determined to have a higher risk.

[0228] If the risk level falls within a set stable range, the electronic device (100) may determine that the target task is executable based on a verification result including permission. Here, the stable range may be a risk level range predefined by policy rules or administrator settings. For example, the range may be defined such as automatic execution when the risk score is 0 or higher and 0.3 or lower, a user approval request when it is greater than 0.3 and 0.7 or lower, and administrator approval or blocking when it is greater than 0.7.

[0229] The decision regarding execution is also important in terms of user experience. Requiring approval for all tasks may reduce usability, while automatically executing all tasks may increase security risks. Therefore, the electronic device (100) can decide to perform the approval procedure only when necessary and to automatically perform safe tasks based on the task type, risk level, device status, and policy rules. This structure is an execution control method that considers both security and convenience.

[0230] Furthermore, the results of execution decisions can be stored as audit information. For example, information such as which execution plans were permitted, which were blocked, which user approval procedures were performed, what the risk values ​​were, and which policy rules were applied can be recorded. This information can be utilized for post-audits, model improvement, policy improvement, and responding to user disputes.

[0231] According to one embodiment, when a target task is executed based on a decision on whether to execute, the processor (120) can generate and store audit information regarding the execution result and update at least one of the first artificial intelligence model and the second artificial intelligence model's model parameters using at least a portion of the audit information (S640).

[0232] The electronic device (100) can generate and store audit information regarding the execution result when a target task is executed according to a decision on whether to execute. Here, the audit information may refer to record information indicating how the target task was executed, what inputs and conditions were used for execution, whether the execution result matched the execution plan, and whether there was a possibility of errors or policy violations during execution. The audit information is not limited to simple logs and can be generated as structured data capable of explaining the basis and results of the execution.

[0233] Audit information may include user requests, execution plans, verification results, execution decision results, user approval status, applied policy rules, risk level of target tasks, execution time, invoked tools, accessed files, external API call history, device control commands, execution results, error codes, device status, and post-audit results.

[0234] For example, when a document transmission task is performed, the audit information may include the transmission destination, the transmitted document identifier, whether sensitive information is masked, the time of user approval, the applied policy rules, and whether the transmission was successful.

[0235] After the execution of the target task is performed, the electronic device (100) can verify whether there is a match between the execution result and the execution plan using a second artificial intelligence model. In the present disclosure, this may be defined as "post-audit."

[0236] For example, if the execution plan included a step of “masking personal information in the document and sharing it on an internal channel,” but the actual execution result was sent to an external email or the masking was omitted, the electronic device (100) may determine that the execution result is inconsistent with the execution plan.

[0237] Post-execution auditing is useful for detecting potential problems that may occur after execution is completed. Even if verification is performed before execution, external API errors, device state changes, network failures, changes in user input, or tool execution failures may occur during the actual execution process. The electronic device can check these post-execution states and increase the reliability of the execution by comparing the planned results with the actual results. For example, if the actual sensor value or device state differs from the expected state after a mode change request from an IoT device is executed, the electronic device (100) can record it as an abnormal execution.

[0238] Audit information may be stored in a database, local storage, secure storage, or an audit storage on an external server. In an on-device structure, sensitive audit information may be stored locally first, and if necessary, only summary information, anonymized information, or update parameters may be transmitted to an external server (220). This method can simultaneously ensure user data protection and auditability.

[0239] The electronic device (100) can generate an audit log of a chain structure containing a hash value corresponding to at least one event that occurred during the execution process. For example, the first event may be the reception of a user request, the second event may be the generation of an execution plan, the third event may be the generation of a verification result, the fourth event may be user approval, the fifth event may be actual execution, and the sixth event may be a post-audit result. Each event log may be configured to include the hash value of a previous event, so that if an intermediate event changes, the subsequent hash value changes, thereby allowing verification of whether tampering has occurred.

[0240] An audit log of a chain structure is advantageous for ensuring the integrity of the execution flow. For example, if a user attempts to delete execution approval records after the fact or change external transmission history, the change in the log can be detected through the hash chain structure. Thus, the electronic device (100) can store important events occurring during the execution process of the personal agent in a traceable and verifiable form.

[0241] Audit information can be used not only for simple storage purposes but also to update at least one of the model parameters of the first artificial intelligence model or the second artificial intelligence model.

[0242] For example, if the first AI model repeatedly generates execution plans with a high probability of policy violations, the audit information can be used to improve the first AI model so that it generates safer execution plans in the future. Additionally, if the second AI model fails to sufficiently block specific risky tasks, the audit information can be used to strengthen the verification criteria for the second AI model.

[0243] Model parameter updates can be performed within the electronic device (100). For example, the electronic device (100) may generate learnable feature information, such as whether execution was successful, the type of verification error, the result of a risk assessment, whether approval was granted, or the type of policy violation, rather than extracting raw user data from audit information and transmitting it externally. This feature information may be used to update some parameters, adapters, or evaluation criteria of the model in a local environment.

[0244] Additionally, the electronic device (100) can perform model updates using audit information accumulated from multiple execution cases. For example, if an external transmission request is repeatedly blocked in a specific user's environment, the electronic device can learn the first artificial intelligence model to generate an execution plan that includes a masking step or an approval step for similar future requests. Conversely, if it is confirmed that a specific type of device control command is executed reliably, the electronic device can simplify the approval process in similar low-risk situations.

[0245] Audit information-based updates can be applied to the first and second AI models in different ways. For the first AI model, they can be used to improve the quality of execution plans, the appropriateness of step configurations, the degree of user intent reflection, and the accuracy of tool selection. For the second AI model, they can be used to improve the accuracy of policy violation detection, personal information leakage detection, risk assessment, and blocking reason generation.

[0246] This structure for generating audit information and updating the model provides a closed-loop structure in which the personal agent goes beyond simply processing user requests on a one-time basis and is progressively improved through execution experiences. In other words, a cyclic structure is formed in which an execution plan is generated from a user request, executed after verification, the execution results are stored as audit information, and then reflected back into model improvement. This structure can contribute to simultaneously achieving system reliability, explainability, and continuous performance improvement.

[0247] Additionally, the electronic device (100) can provide information regarding the execution process and execution results to the user terminal (210) after the execution of the target task is completed.

[0248] Information regarding the execution process here may include information indicating which stages the target task was performed in, which tools or functions were used in each stage, whether user approval or policy verification was performed, and whether errors or constraints occurred during execution. Information regarding the execution results may include whether the target task was completed, the generated deliverables, whether transmission was successful, the results of device control, the cause of failure, or whether follow-up action is required.

[0249] For example, if a user requests, “Summarize the meeting minutes and share them on the team channel,” the electronic device (100) can provide step-by-step execution statuses to the user terminal (210) after the execution of the target task is completed, such as “Meeting minutes file verification complete,” “Summary creation complete,” “Sensitive information verification complete,” and “Team channel transmission complete.” Additionally, the electronic device (100) can provide the final generated summary, the transmitted channel name, the transmission time, and the policy verification results together.

[0250] As another example, if a user requests a change in the operating mode of an IoT device, the electronic device (100) may provide the user terminal (210) with information on whether a device control command was executed, the device status before execution, the device status after execution, changes in sensor values, and post-audit results. If execution is restricted due to device status information such as device temperature or network status, the electronic device (100) may provide guidance on follow-up actions the user can take, along with the reason for the restriction.

[0251] Additionally, the electronic device (100) may provide the verification results or post-audit results generated by the second artificial intelligence model to the user terminal (210) in a summary form. For example, if the execution plan is modified or some steps are blocked, the electronic device (100) may provide explanatory information such as “The external transmission step was blocked according to policy rules, and only the local storage step was performed.” This explanatory information helps the user understand the basis of the system’s judgment and can improve the execution transparency of the artificial intelligence agent.

[0252] The electronic device (100) may provide information regarding the execution process and execution results through the screen, notification message, voice output, conversational interface, or task history screen of the user terminal (210). For example, in a mobile terminal, the execution result may be displayed as a notification card or conversational chat interface, in a desktop environment, it may be displayed as a task completion report or log summary window, and in a wearable device, it may be provided in the form of a short summary notification.

[0253] At this time, the electronic device (100) can adjust the level of detail of the information provided according to the screen size, input method, network status, or usage environment of the user terminal (210). For example, for a user driving a vehicle, brief voice guidance such as “Task completed,” “Approval required,” or “Execution blocked” may be provided instead of a long text execution log, and for a desktop user, detailed logs of each execution step and the basis for verification may be provided together.

[0254] When the electronic device (100) provides execution results, it may summarize or mask some information to protect sensitive information. For example, an email address to be sent externally, a document name containing personal information, an authentication key, or an internal system identifier may not be fully displayed, but only partially displayed. This allows the user to receive execution results at a level necessary for the user, while reducing the possibility of information leakage due to screen exposure or notification exposure on the user terminal (210).

[0255] Additionally, the electronic device (100) may receive user feedback regarding the execution results provided to the user terminal (210). For example, the user may input feedback such as “results are appropriate,” “summary is inaccurate,” “reason for blocking is inappropriate,” “re-execute,” or “report to administrator.” The electronic device (100) may store this feedback along with audit information and utilize it for future updates of the first artificial intelligence model or the second artificial intelligence model.

[0256] According to this embodiment, even after the execution of the target task is completed, the electronic device (100) does not merely store internal logs, but provides the execution process and execution results to the user terminal (210), thereby enabling the user to verify and understand the operation of the artificial intelligence agent. Therefore, the present invention can provide the convenience of execution automation while simultaneously providing the user with execution transparency, the ability to verify results, and the ability to control the results afterward.

[0258] Additionally or generally, in one embodiment, when the electronic device (100) generates an execution plan corresponding to a user request, it may configure the execution plan in a form that explicitly includes the name and execution order of the target task.

[0259] Here, the name of the target task may be information for identifying the type or purpose of the work to be performed according to the user's request, and the execution order may be information indicating the order in which multiple sub-actions required to perform the target task are executed.

[0260] For example, if a user requests document transmission, the execution plan may include task names and sequences such as “document search,” “document summary,” “sensitive information review,” “transmission target verification,” “user approval request,” and “message transmission.”

[0261] Additionally, the electronic device (100) may not execute the execution plan generated by the first artificial intelligence model as is, but may verify the suitability of the execution plan using a second artificial intelligence model. In this case, the second artificial intelligence model is a model distinct from the first artificial intelligence model and may be an auditing artificial intelligence model trained or adjusted based on pre-set policy rules. Therefore, the second artificial intelligence model may be configured not merely to evaluate the naturalness of the sentence or the quality of the response, but to determine whether the execution plan conforms to policy rules, security standards, user rights, or device status.

[0262] In one embodiment, the electronic device (100) may input a user request, an execution plan, and device status information together into a second artificial intelligence model. The user request represents the user's original intention, the execution plan represents an execution procedure generated by the first artificial intelligence model, and the device status information represents the environmental conditions under which the execution will be performed. Accordingly, the second artificial intelligence model may not only review the execution plan alone, but also determine whether the user's original request and the execution plan correspond to each other, and whether the execution plan can be safely executed in the current device environment.

[0263] For example, if the execution plan includes a step of sending an external email even though the user has requested to “summarize the meeting minutes,” the second AI model can detect a discrepancy between the user request and the execution plan. Additionally, even if the user has requested device control, if the user terminal’s battery level is low, the network status is unstable, or the device security status does not meet trust criteria, the second AI model can determine that the execution plan should be modified or blocked.

[0264] Device status information may include the user terminal's network status, battery status, temperature status, location information, security status, certificate status, signature verification status, or other execution environment information. Such device status information can be used to determine risks that may occur when the execution plan is performed in a real-world environment. For example, external data transmission tasks may carry a higher risk when connected to a public network, and device control tasks may be restricted due to sensor malfunctions or high temperatures.

[0265] According to this configuration, the electronic device (100) can verify the execution plan generated by the first artificial intelligence model together with the context of the user request, policy rules, and device status information, thereby identifying dangerous executions or executions inconsistent with the user's intent with higher accuracy than simply reviewing the execution plan itself. In particular, since the second artificial intelligence model is trained based on policy rules, it can generate verification results that reflect organization-specific policies, user-specific restrictions, device-specific restrictions, or service operation standards.

[0266] Additionally, the electronic device (100) can determine whether to execute the target task based on the verification result of the second artificial intelligence model. If the verification result corresponds to permission, the target task may be executed, and if the verification result corresponds to modification or blocking, some steps of the execution plan may be changed or execution may be restricted. If the verification result requires additional verification, the electronic device (100) may request user approval or administrator approval through the user terminal (210).

[0267] This embodiment may particularly focus on the “input context-based verification” of an execution plan rather than the “generation” of the execution plan. That is, the second AI model uses user requests, execution plans, and device state information as a single verification input set to determine whether the execution plan of the first AI model aligns with the user’s original intent, does not violate policy rules, and is feasible in the current device environment. This structure can contribute to enhancing pre-execution safety in environments where AI agents perform tasks autonomously.

[0269] Additionally or generally, in one embodiment, the electronic device (100) may first receive device status information of the user terminal (210) and use it to determine whether the target task is executable before generating an execution plan corresponding to a user request.

[0270] This preliminary judgment is significant in that, unlike the method where the AI ​​model reviews risks only after generating an execution plan, it verifies the security reliability of the device at a stage prior to the execution plan generation.

[0271] For example, if the user terminal (210) is rooted, if the signature verification of the app or policy bundle has failed, or if the certificate has expired, the electronic device (100) may restrict or stop the generation of the execution plan for the user request itself.

[0272] Here, device status information may include the operating system status, security setting status, network connection status, authentication status, app integrity status, or device identification information of the user terminal (210). The electronic device (100) may generate or verify device reliability information using at least some of these device status information.

[0273] Device reliability information is information indicating whether the user terminal (210) is in a trustworthy state to perform the current target task, and may include whether it is rooted, whether it is jailbroken, the status of signature verification of an execution module or policy bundle, certificate validity, whether access to a secure storage is possible, whether debugging mode is enabled, or the result of an integrity check.

[0274] The electronic device (100) can determine whether a target task is executable based on device reliability information.

[0275] For example, if the target task is a low-risk operation such as simple question-and-answer or local notification generation, the device reliability standard may be set relatively low, but if the target task includes external data transmission, file deletion, system setting change, device control, or access to authentication information, a higher device reliability standard may be applied. Accordingly, the electronic device (100) may determine differently whether to execute the same user request depending on the security status of the device.

[0276] For example, if a user requests, “Summarize internal documents and send them to an external partner,” the electronic device (100) can first check the security status of the user terminal (210). At this time, if it is determined that the user terminal (210) possesses a valid certificate, the signature of the execution application is valid, and it is not rooted or jailbroken, the electronic device (100) can proceed to the execution plan generation step. Conversely, if a rooted state is detected or the certificate validation fails, the electronic device (100) may restrict the generation of the execution plan or notify the user of an abnormal security status, considering that the request may involve external transmission.

[0277] As another example, when a user terminal (210) is connected to an IoT device or a vehicle control interface, the device reliability information may be directly related to the control safety of the actual physical device. For example, if a user requests a change in the operation mode of a vehicle or IoT device, the electronic device (100) may check the validity of the user terminal's certificate, the signature status of the control app, and the device security status before generating an execution plan through the first artificial intelligence model. If the device reliability information does not meet the criteria, the electronic device (100) may reduce the possibility of unauthorized control or malfunction by restricting the generation or execution of physical device control commands.

[0278] In this embodiment, the determination based on device reliability can be performed before the execution plan generation of the first artificial intelligence model. This has the effect of reducing the transmission of requests generated from untrusted terminals to the plan generation stage of the artificial intelligence model. In particular, since the artificial intelligence model can generate complex tool calls or device control plans based on input user requests, screening untrusted devices at the input stage is advantageous for enhancing the safety of the entire system.

[0279] Additionally, the electronic device (100) may limit not only the feasibility of execution but also the scope of execution based on device reliability information. For example, if the device reliability information satisfies some criteria but not all criteria, the electronic device (100) may allow only low-risk steps among target tasks, such as local information lookup or summarization, and restrict high-risk steps, such as external transmission, execution of administrator commands, or device control. This method allows the scope of execution for each step to be adjusted according to the device security status without blocking all requests at once.

[0280] The electronic device (100) may generate an execution plan corresponding to a user request using a first artificial intelligence model on-device only when it is determined that the execution of a target task is possible. Accordingly, the first artificial intelligence model generates an execution plan only for requests that have passed through a security gate, and the execution plan may include the name of the target task, the execution order, necessary tools, data to be accessed, device control commands, or steps requiring approval. This structure can be understood as a combination of the plan generation function of the artificial intelligence model and a security check based on device trustworthiness.

[0281] Subsequently, the electronic device (100) can perform verification using a second artificial intelligence model on an execution plan generated by a first artificial intelligence model. That is, in this embodiment, a prior security judgment based on device reliability and an execution plan verification using a second artificial intelligence model can be performed sequentially. The former functions as a security gate prior to the generation of the execution plan, and the latter functions as a policy-based audit of the generated execution plan.

[0282] By combining different stages of verification in this way, the electronic device (100) can reduce both the risk of request processing in untrusted devices and the risk of policy violation in the execution plan itself.

[0283] The second artificial intelligence model can determine whether the execution plan meets policy rules or predefined criteria. For example, even if a user request has passed the device reliability check, the execution plan generated by the first artificial intelligence model may exceed user authority, transmit sensitive information externally, or include control commands that do not match the device state. Therefore, the electronic device (100) may not allow execution based solely on the device reliability check, but may generate a separate verification result through the second artificial intelligence model.

[0284] Based on the verification result, the electronic device (100) can determine whether to execute a target task based on an execution plan. For example, if the device reliability criteria are satisfied and the verification result of the second artificial intelligence model is allowed, the target task may be executed. Conversely, if the device reliability criteria are satisfied but the verification result is blocked, the target task may not be executed. Additionally, if the verification result corresponds to a modification or a higher-level report, the execution plan may be changed or user or administrator approval may be requested.

[0285] When a target task is executed, the electronic device (100) may generate and store audit information regarding the execution result. This audit information may include the result of determining the device's reliability, whether an execution plan was generated, the result of verifying the second artificial intelligence model, the result of determining whether to execute, the content of the executed task, the time of execution, whether user approval was obtained, the device status, and the execution result. In particular, by including the result of determining the device's reliability in the audit information, it is possible to verify whether the execution was performed in a reliable device state during a subsequent post-audit.

[0286] Additionally, the electronic device (100) may update at least one model parameter of the first artificial intelligence model or the second artificial intelligence model using at least a portion of the audit information. For example, if repeated execution failures occur under specific device reliability conditions, or if an execution plan with a high probability of policy violation is generated under a specific security state, the electronic device (100) may use this audit information to improve the model to generate a more conservative execution plan under similar conditions in the future or to generate a more stringent verification result.

[0287] According to the present embodiment, the electronic device (100) can first determine whether a target task is executable using device reliability information immediately after receiving a user request, and perform an artificial intelligence model-based execution plan generation and audit procedure only if the determination is passed. Therefore, it is possible to prevent an artificial intelligence agent from generating a sensitive tool call or device control plan in advance under security vulnerable conditions such as rooting, signature verification failure, or certificate expiration.

[0288] This configuration is particularly useful in enterprise environments, vehicle control environments, IoT control environments, and mobile business environments. For example, it is desirable that operations such as accessing internal corporate documents, calling external APIs, controlling firmware, or controlling vehicle interfaces be permitted only when the security status of the terminal is trusted. Through a prior judgment based on device trustworthiness, this embodiment can also consider terminal security risks that are difficult to sufficiently control with user permissions alone.

[0289] Consequently, the present embodiment enhances the security of the AI ​​agent execution environment by placing a determination of execution feasibility using device trust information prior to the AI ​​model execution plan generation and verification structure. This provides a multi-layered security structure that, in addition to retrospectively verifying the execution plan generated by the AI ​​model, suppresses the processing of dangerous requests from untrusted devices at a stage prior to execution plan generation.

[0291] According to one embodiment, the operation of generating a verification result may further include using a second artificial intelligence model to perform a pre-audit of the execution plan based on locally stored policy rules and search augmentation generation (RAG)-based evidence data, and generating a verification result including any one of allow, revise, escalate, or block.

[0292] The electronic device (100) can perform a pre-audit on an execution plan generated by a first artificial intelligence model using a second artificial intelligence model and generate a verification result based on the result. Here, the pre-audit may refer to a procedure for determining the suitability, safety, and policy compliance of an execution plan at a stage prior to the actual execution of a target task.

[0293] The second AI model may operate not as a simple response generation model, but as an audit model that evaluates the feasibility of an execution plan based on policy rules and supporting data. In particular, the second AI model may be configured to operate in a local environment or to reference locally stored policy rules and supporting data, thereby allowing sensitive information included in user requests and execution plans to be verified internally without being transmitted externally.

[0294] The electronic device (100) may utilize locally stored policy rules to perform a pre-audit. The policy rules may include execution restrictions, security requirements, user permission criteria, data processing criteria, and device control conditions, and

[0295] For example, rules such as “documents containing personal information must be masked before external transmission,” “system commands requiring administrator privileges cannot be executed without user approval,” and “external data transmission is prohibited in unauthorized network environments” may be included.

[0296] Additionally, the electronic device (100) can improve the accuracy of verification of execution plans by utilizing retrieval-augmented generation (RAG)-based evidence data. RAG-based evidence data may include information retrieved from policy documents, device manuals, historical audit logs, user history, failure history, or internal organizational knowledge databases. This evidence data enables actual document-based judgment rather than simple rule matching.

[0297] For example, if a user requests control of a specific device, the electronic device (100) can search for the permission conditions of the corresponding command in the device manual and determine whether the execution plan is safe based on this. Additionally, if there is a history in past audit logs where similar executions failed or were blocked, the second artificial intelligence model can make a more conservative judgment regarding the execution plan.

[0298] The second AI model analyzes the execution plan by comprehensively considering policy rules and RAG-based evidence data, and can determine whether each step of the execution plan complies with the policy.

[0299] For example, the possibility of policy violations can be reviewed for each of the file access paths, external transfer destinations, API call information, device control commands, or data processing steps included in the execution plan.

[0300] The verification result generated as a result of a preliminary audit may include status information for determining whether to execute the target task, and may include at least one of allow, revise, escalate, and block.

[0301] "Allowed" may refer to a state where the execution plan aligns with policy rules and supporting data, and is executable without additional restrictions. For example, an allowed status may be generated in cases with low risk and no potential for policy violations, such as simple document summarization or internal data retrieval.

[0302] Modification may refer to a state where part of an execution plan does not fully comply with policy rules but can be executed through some changes. For example, if personal information is detected in an execution plan that includes external transmission, the electronic device may modify the execution plan to mask the data.

[0303] Higher-level reporting may refer to a state requiring user or administrator approval when the execution plan demands policy-critical judgments. For example, tasks with a wide scope of impact, such as executing system commands requiring administrator privileges, transmitting data to external organizations, or controlling devices, can be classified as high-level reporting.

[0304] Blocking may refer to a state where execution is not permitted, such as when an execution plan clearly violates policy rules or involves a high risk. For example, data transmission to an unauthenticated external server, unauthorized file deletion commands, or device control requests in a security vulnerable state may be determined to be blocked.

[0305] The second AI model can make judgments by comprehensively considering the context of the user request, the structure of the execution plan, and the underlying data when generating these verification results, rather than relying on simple rule matching. For example, even for the same external transmission request, different verification results may be generated depending on whether the recipient is an internal user, a partner, or an unclear external address.

[0306] Furthermore, the second AI model can assess complex risks by considering the relationships between the steps of the execution plan. For example, if the steps “file search → file summary → external transfer” are combined, there may be a risk of sensitive information leakage in the overall flow, even if there is no issue with a single step alone. The second AI model can generate verification results by taking this entire flow into account.

[0307] The electronic device (100) can utilize the generated verification results in a subsequent decision-making step regarding execution, and can store the basis information for the judgment (e.g., applied policy rules, referenced documents, reasons for risk assessment, etc.) along with the verification results. This can subsequently be used for user explanation, audit analysis, or model improvement.

[0308] According to the present embodiment, since a preliminary audit using policy rules and RAG-based evidence data is performed before the execution plan is actually executed, security issues, data leakage, or device malfunction caused by an incorrect execution plan of an artificial intelligence model can be effectively prevented.

[0309] In particular, by verifying execution plans through the combination of AI models and supporting data rather than simple rule-based filtering, more flexible and sophisticated execution control is possible. This offers the advantage of simultaneously considering various user environments, device states, and organizational policies.

[0310] As a result, the configuration according to the present embodiment provides a structure that performs multi-layered verification in the pre-execution stage after the execution plan is generated, thereby improving the reliability, safety, and policy compliance of the personal agent system.

[0312] According to one embodiment, the operation of determining whether to execute the target task based on a verification result may further include: classifying the target task as a high-risk task based on the policy rule when the target task includes external data transmission, system command execution, or device control; transmitting a user approval request through the user terminal and receiving an approval input from the user when the target task is classified as the high-risk task; and executing the target task only when the approval input is received from the user, and blocking the execution of the target task when the approval input is not received.

[0313] The electronic device (100) can determine whether to execute a target task based on a verification result generated by a second artificial intelligence model. At this time, the electronic device (100) can go beyond simply reflecting the verification result and specifically determine an execution control method by considering the type and risk level of the target task.

[0314] In particular, the electronic device (100) can classify a target task as a high-risk task based on policy rules when the target task includes external data transmission, system command execution, or device control.

[0315] Here, external data transmission may include sending emails, sending messages, uploading to the cloud, calling external APIs, or transferring data to third-party systems, and system command execution may include operating system-level commands such as deleting files, changing permissions, modifying settings, or controlling processes. Additionally, device control may include control commands that change the state of IoT devices, vehicle systems, wearable devices, or other connected devices.

[0316] Unlike general information retrieval or document creation tasks, such tasks may cause user data leakage, system malfunction, or physical hazards, so the electronic device (100) may classify them as high-risk tasks according to policy rules. For example, tasks such as sending internal documents to external emails, changing system settings requiring administrator privileges, or commands to change the driving mode of a vehicle may be determined as high-risk tasks.

[0317] The electronic device (100) may transmit a user approval request through the user terminal (210) when the target task is classified as a high-risk task. The user approval request may include the execution details of the target task, expected results, reasons for risk, applied policy rules, target data, or information on the controlled device. For example, an approval message such as “This operation involves external transmission and contains personal information in the document. Would you like to proceed?” may be displayed on the user terminal (210).

[0318] The user may provide an approval or rejection input through the user terminal (210). The approval input may be entered via a button click, voice command, biometric authentication, or other user authentication methods, and the electronic device (100) may determine whether to execute the target task based on such input. Additionally, if an approval input is not received within a certain period of time, the electronic device (100) may be configured to automatically block execution.

[0319] The electronic device (100) can execute the target task only when an approval input is received from the user. That is, in the case of high-risk tasks, it can be controlled so that they are not automatically executed without user approval. Conversely, if an approval input is not received from the user or a rejection input is received, the electronic device (100) can block the execution of the target task.

[0320] Such user approval-based execution control can provide users with control over critical execution decisions while maintaining the autonomy of AI agents. For example, automatic execution may occur when a user performs a simple information lookup request, but tasks such as external transmission or system modification can be configured to require user confirmation.

[0321] Additionally, the electronic device (100) can apply various execution control scenarios depending on the verification result. For example, if the verification result is allowed, it can be executed immediately, and if it is modified, it can be executed after re-verification following changes to part of the execution plan. In the case of a higher-level report, an additional request for administrator approval may be made, and if it is blocked, execution is not performed and the reason for the blocking may be provided to the user.

[0322] The electronic device (100) may consider user authorization information, device status information, and policy rules together in the process of determining whether to execute a target task. For example, for the same external transmission task, immediate execution may be allowed for an administrator, while user approval or administrator approval may be required for a general user. Additionally, if the device is connected to a public network, the same task may be blocked or require additional authentication.

[0323] The results of execution decisions can be recorded as audit information. For example, information such as which tasks were classified as high-risk, whether user approval requests were made, the approval status, and the final execution status can be stored. This information can subsequently be utilized for post-audits, policy improvements, or AI model training.

[0324] According to the present embodiment, the electronic device (100) does not execute the execution plan generated by the artificial intelligence model as is, but can control whether to execute it by considering the risk level of the target task and policy rules. In particular, by introducing a user approval procedure for high-risk tasks, risks such as data leakage, abuse of authority, or device malfunction can be effectively reduced.

[0325] Furthermore, a user approval-based execution control structure can contribute to enhancing user trust in the behavior of AI agents. Users can trust the system more because important tasks are not performed automatically but are executed after their confirmation.

[0326] As a result, the configuration according to the present embodiment can improve the safety and reliability of the personal agent system by controlling whether to execute a target task based on verification results and providing an execution control mechanism that includes a user approval procedure for high-risk tasks.

[0328] According to one embodiment, the operation of determining whether to execute the target task based on a verification result may include: determining the risk level of the target task based on authorization information included in a policy rule and device status information received from the user terminal; generating the verification result including permission when the risk level of the target task is included in a set stable range; performing a post-audit to verify whether the execution result and the execution plan match using the second artificial intelligence model after the execution of the target task is performed; and generating an audit log of a chain structure including at least one hash value corresponding to at least one event that occurred during the execution process of the target task, storing it in a database, and updating at least one of the first artificial intelligence model or the second artificial intelligence model based on the audit log.

[0329] The electronic device (100) can determine the risk level of a target task by using authorization information included in policy rules and device status information received from a user terminal (210) when determining whether to execute a target task based on a verification result generated by a second artificial intelligence model.

[0330] Here, risk may be an indicator that quantitatively or semi-quantitatively represents the likelihood that the execution of the target task will exceed the scope of system security, data protection, device stability, or user privileges.

[0331] The electronic device (100) can determine the suitability between the level of authority required by the target task and the user authority set on the user terminal (210) through the authority information included in the policy rule.

[0332] For example, if the execution of a specific system command or the transmission of external data requires administrator privileges, the risk level of the task may be calculated as high on a user terminal (210) with general user privileges.

[0333] Additionally, the electronic device (100) can evaluate the stability and reliability of the execution environment based on device status information received from the user terminal (210). The device status information may include network connection status, battery level, device temperature, location information, security status, or authentication status, and, for example, in a public network environment or a low-power state, the same task may be judged to have a higher risk.

[0334] The electronic device (100) can calculate the risk level of a target task by comprehensively considering the authorization information and device status information, and can generate or maintain a verification result including permission if the risk level falls within a preset stable range. Here, the stable range is a risk level range defined according to policy rules or administrator settings, and can be used as a criterion for allowing automatic execution for tasks having a risk level below a certain level.

[0335] For example, tasks with low sensitivity and low permission requirements, such as simple document summarization or internal data retrieval, fall within the safe zone and can be executed automatically without separate approval. Conversely, high-risk tasks, such as external transmission or device control, fall outside the safe zone, so additional approval or blocking may be required.

[0336] After the execution of the target task is performed, the electronic device (100) may perform a post-audit using a second artificial intelligence model to verify whether the execution result matches the execution plan. Unlike pre-execution verification, the post-audit is performed based on the actual execution result and can be used to detect errors, modifications, or policy violations that may occur during the execution process.

[0337] For example, if the execution plan included only the step of “saving the document to an internal system,” but in the actual execution result data was transmitted to an external server (220), the electronic device (100) may determine that the execution result is inconsistent with the execution plan. Additionally, if the planned data masking step is not executed, it may be detected as an abnormal execution in a post-audit.

[0338] The electronic device (100) can generate and store in a database an audit log of a chain structure containing a hash value corresponding to at least one event that occurred during the execution process of a target task. Here, the events may include receiving a user request, generating an execution plan, generating a verification result, user approval, actual execution, post-audit result, etc., and each event may be linked in a manner that includes the hash value of the previous event.

[0339] Such a hash chain structure can be used to ensure the integrity of an audit log. For example, if a specific execution record is changed or deleted, the connection of the hash chain is broken, making it easy to detect whether tampering has occurred. Thus, the electronic device (100) can maintain a reliable audit log, which can be utilized for security audits, regulatory compliance, or dispute response.

[0340] Additionally, the electronic device (100) may update at least one of the first artificial intelligence model or the second artificial intelligence model based on the audit log. For example, if repeated execution failures occur in a specific type of task or if an execution plan with a high probability of policy violation is generated, the electronic device (100) may analyze the audit log and improve the first artificial intelligence model so that a safer execution plan is generated in similar situations in the future.

[0341] Additionally, in the case of the second artificial intelligence model, verification criteria can be strengthened based on instances where specific risk situations were not sufficiently detected. For example, if instances where risk tasks are allowed in a specific device state occur repeatedly, the electronic device (100) can update the second artificial intelligence model to generate stricter verification results under those conditions.

[0342] The electronic device (100) may also utilize information required for audit logs or model updates by linking with an external server (220). For example, some of the locally generated audit information may be anonymized or summarized and transmitted to the external server (220), and the external server (220) may aggregate and update the model based on information collected from multiple electronic devices. Even in this case, sensitive raw data is not transmitted externally, and only the minimum necessary information may be utilized.

[0343] According to the present embodiment, the electronic device (100) can perform risk-based judgment before execution, post-execution audit, and audit log-based model update as a single continuous flow. This structure enables the configuration of a closed-loop system that goes beyond simple execution control and continuously reflects execution results into learning.

[0344] As a result, the configuration according to the present embodiment can simultaneously achieve reliability, stability, and continuous performance improvement of the personal agent system by providing a structure that determines whether to execute based on the risk level of the target task, verifies the execution results through post-execution audits and integrity logs after execution, and utilizes this to improve the artificial intelligence model.

[0346] According to one embodiment, the operation of determining the risk level of a target task may include: using the authorization information and the device status information to identify an authorization level value set corresponding to the user authorization level of the user terminal and an authorization non-possession count indicating the number of authorization items for which the user terminal does not possess authorization among the authorization items required for the execution of the target task; using the device status information to identify the network reliability of the user terminal based on whether the user terminal is connected to an unauthorized network and the packet loss rate over a predetermined period; using the device status information to identify a location-based risk value based on the result of a comparison between the location of the user terminal and a preset zone table; using the device status information to identify an operational state risk value based on the temperature and remaining battery level of the user terminal; and using the device status information to calculate the risk level of the target task based on at least one of the authorization level value, the authorization non-possession count, the network reliability, the location-based risk value, and the operational state risk value.

[0347] The electronic device (100) can identify multiple risk-related parameters based on authorization information included in policy rules and device status information received from a user terminal (210) in order to more precisely determine the risk level of a target task, and can calculate the risk level of a target task using the same.

[0348] The electronic device (100) can first identify an authority level value set corresponding to the user authority level of the user terminal (210) based on authority information. Here, the authority level value is a numerical value representing the user authority level; for example, administrator authority can be set to a high value, general user authority to a medium value, and restricted user authority to a low value. This authority level value can be used to calculate the risk level by comparing it with the authority level required by the target task. The authority level value can be used to calculate the risk level described later, and can be implemented in a form where the risk level is calculated to be lower as the authority level 'K' value increases.

[0349] Additionally, the electronic device (100) can identify the number of non-permissioned items, which indicates the number of permission items that the user terminal (210) does not possess, by comparing the permission items required for the execution of the target task with the permission items actually possessed by the user terminal (210). For example, if the target task requires permission for file access, network transmission, and system setting change, and the user terminal (210) does not possess some of these permissions, the number of such insufficient permissions may be reflected as a risk factor.

[0350] The electronic device (100) can identify network reliability based on device status information. Network reliability can be calculated based on whether the user terminal (210) is connected to an unauthorized network, or based on packet loss rate, latency, or connection stability measured over a specified period. For example, network reliability may be evaluated as low in a public Wi-Fi environment or a network environment with a high packet loss rate, which may be reflected as a risk increase factor.

[0351] Additionally, the electronic device (100) can identify a location-based risk value using location information of the user terminal (210). The location-based risk value can be calculated based on the result of a comparison between the current location of the user terminal (210) and a pre-set allowed zone or risk zone table. For example, a low risk value may be set in a location within an office where access to the corporate internal system is permitted, but a high risk value may be set in an overseas or unauthorized area.

[0352] The electronic device (100) can also identify a risk value based on the operating state of the device. The operating state risk value can be calculated based on the temperature, battery level, or device performance status of the user terminal (210). For example, if the battery level is very low or the device temperature is excessively high, the risk value may be set high because the probability of an error occurring during execution increases.

[0353] The electronic device (100) can calculate the risk of a target task based on at least one of the authority level value, the number of non-authorized items, network reliability, location-based risk value, and operational status risk value. At this time, the risk can be calculated by applying weights to each parameter and summing them, by using an average value, or by calculating it in stages according to specific conditions.

[0354] For example, the risk level can be configured to increase as the degree of privilege deficiency increases, as network reliability decreases, as the location is closer to a risk zone, and as the device status becomes unstable.

[0355] By combining these multiple elements, it becomes possible to make a more precise risk assessment without relying on a single criterion.

[0356] Additionally, the electronic device (100) may apply different weights to each parameter depending on the type of target task. For example, in the case of an external data transmission task, the weights of network reliability and location-based risk values ​​may be set high, and in the case of a device control task, the weight of the operational status risk value may be set high. Through this, it is possible to calculate a risk optimized for the characteristics of the task.

[0357] The electronic device (100) can determine whether to execute a target task based on the calculated risk level, or perform controls such as automatic execution, requesting user approval, or blocking execution by comparing with a stable period.

[0358] Additionally, the electronic device (100) can include each parameter value used in the risk calculation process in the audit information. This allows for identifying which factors influenced the risk assessment during subsequent post-audit or analysis processes, and can be utilized for improving policy rules or training artificial intelligence models.

[0359] According to the present embodiment, the electronic device (100) calculates a quantitative risk level based on user authority information and device status information, thereby enabling more sophisticated and flexible execution control than simple rule-based judgment. In particular, by simultaneously considering various environmental variables and user authority, it is possible to perform execution judgments suitable for the actual usage environment.

[0360] As a result, the configuration according to the present embodiment provides a specific mechanism for calculating the risk level of a target task based on numerical values, thereby improving the accuracy of execution judgment and security of the personal agent system.

[0362] Meanwhile, according to one embodiment, the electronic device (100) can process user requests and related data preferentially in a local environment based on a local-first structure. Here, the local-first structure does not necessarily mean that all operations are performed only in an on-device environment, and may include a structure that selectively combines a local environment and an external cloud environment by considering the sensitivity of user data, the state of device computation resources, network conditions, the acceptable response delay range, or the complexity of the target task.

[0363] For example, tasks related to personal information or device control can be processed first on the device, and external cloud-based artificial intelligence models can be utilized secondarily when large-scale document analysis or high-performance inference is required.

[0364] Accordingly, the present invention is not limited to a simple on-device structure and may include a hybrid artificial intelligence execution structure that flexibly links a local environment and a cloud environment based on a local priority processing policy.

[0366] Furthermore, as used in this disclosure, “first artificial intelligence model” and “second artificial intelligence model” may each refer to mutually distinct artificial intelligence models having different roles, input data structures, output data structures, or policy application criteria.

[0367] Additionally, expressions such as “AI model,” “language model,” “audit model,” and “verification model” used in this specification may be used to refer to the first artificial intelligence model or the second artificial intelligence model depending on the context, and may be interpreted to include the same or corresponding technical concepts unless specifically limited.

[0369] Additionally, the “learning algorithm” as used in this disclosure may refer to an algorithmic processing structure for generating, adjusting, or optimizing parameters of an artificial intelligence model, and may include at least one of supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, feedback-based learning, or search augmentation generative (RAG)-based adaptive learning.

[0370] Additionally, expressions such as “learning method,” “learning method,” or “model learning” used in this disclosure may be interpreted as concepts including a process of model improvement or parameter update based on the learning algorithm, unless otherwise specifically limited.

[0372] Additionally or generally, the electronic device (100) may perform a security processing structure to ensure the confidentiality and integrity of audit information during the process of storing audit information or transmitting and receiving it with an external server (220). For example, the electronic device (100) may store audit logs or execution event information using an AES (Advanced Encryption Standard) based symmetric key encryption method, and may use a TLS (Transport Layer Security) based encryption channel during communication with the external server (220).

[0373] Additionally, the electronic device (100) can generate a hash value by combining at least one of user identification information, a token generation time (timestamp), a nonce value, a device identifier, or an execution plan identifier, and verify whether the audit information has been tampered with based thereon. For example, the audit log may be stored in a hash chain structure containing the hash value of a previous log or in an electronic signature-based integrity verification structure, thereby detecting unauthorized modification or attempts to tamper with the log. Additionally, the audit information may be stored in a Trusted Execution Environment (TEE) or a secure storage area.

[0375] According to one embodiment, the electronic device (100) can perform a federated learning structure based on learning results generated in a local priority and on-device environment.

[0376] For example, the electronic device (100) can generate model parameter or weight update values ​​in a local environment based on execution results, audit logs, policy verification results, or user feedback generated during the user request processing process.

[0377] Afterwards, the electronic device (100) may not transmit raw data to the external server (220), but only transmit the weight update value or parameter delta to the external server (220).

[0378] The external server (220) can aggregate update values ​​received from multiple electronic devices and update the global model through multiple learning rounds. Additionally, the external server (220) can adjust the update reflection rate based on device reliability, data quality, or policy compliance, and can reduce the possibility of exposure of individual user data by applying Secure Aggregation or differential privacy techniques. The updated global model can be redistributed to multiple electronic devices through a signature-based verification procedure.

[0380] The above risk level can be calculated based on the following [Mathematical Formula 1], and

[0381]

[0382] Risk corresponds to the risk level of the target task, P_V corresponds to the authority level value, N_M corresponds to the number of non-authorized items, T_N corresponds to the network reliability of the user terminal, R_L corresponds to the location-based risk value, R_O corresponds to the operational state risk value, and a, b, and c correspond to the first weight constant, the second weight constant, and the third weight constant, respectively, which are pre-set for importance adjustment.

[0383] Here, the risk level may be a value indicating the likelihood that the target task will cause a security breach, exceeding privileges, data leakage, device malfunction, or execution failure when executed.

[0384] The risk level can be normalized to a value between 0 and 1, and the lower the risk level, the higher the likelihood that the target task will execute stably, and the higher the risk level, the higher the likelihood that user approval, administrator approval, or execution blocking will be required.

[0385] For example, the electronic device (100) can identify a target section containing a target task among a plurality of preset sections based on the magnitude of the risk, and generate a verification result based on a preset value corresponding to the target section.

[0386] The authority level value may be a numerical value representing the level of authority granted to a user of the user terminal (210). The electronic device (100) can identify the user authority level based on user identification information, account information, authentication token, role information, or access authority information received from the user terminal (210), and can identify the authority level value by referring to an authority level value mapping table included in the policy rule. For example, different authority level values ​​may be set for each authority level, such as an administrator, an authorized user, a general user, and an external user.

[0387] The number of non-authorized items may refer to the number of authorization items that the user of the user terminal (210) does not possess among the authorization items required for the execution of the target task. The electronic device (100) can calculate the number of non-authorized items by identifying the required authorizations for each sub-operation included in the execution plan, such as file access, external transmission, API call, system command execution, or device control, and comparing this with the list of authorizations granted to the user of the user terminal (210). For example, if the target task requires 5 authorization items and the user possesses only 3 of them, the number of non-authorized items may be calculated as 2.

[0388] Network reliability may be a value indicating whether the communication environment of the user terminal (210) is suitable for safely performing the target task. The electronic device (100) may calculate network reliability using at least one of the identifier of the network connected to the user terminal (210), whether it is an authorized network, encryption method, packet loss rate, latency, connection stability, or frequency of network change. For example, if the user terminal (210) is connected to a pre-registered internal network and the packet loss rate is low, network reliability may be calculated as high, and if it is connected to a public network or an unauthorized network, network reliability may be calculated as low.

[0389] A location-based risk value may be a value indicating whether the current location of the user terminal (210) is a suitable location for the execution of a target task. The electronic device (100) may receive GPS information, network-based location information, base station information, internal access point information, or geofence information from the user terminal (210) and identify a location-based risk value by comparing it with a preset zone table. For example, a low risk value may be set in an allowed zone, and a relatively high risk value may be set in a caution zone, an unauthorized zone, or a prohibited zone.

[0390] The operating state risk value may be a value indicating whether the actual operating environment of the user terminal (210) is suitable for stably performing the target task. The electronic device (100) may calculate the operating state risk value using at least one of the temperature, battery level, CPU usage rate, memory usage rate, storage space, power connection status, or sensor status of the user terminal (210). For example, if the temperature of the user terminal (210) exceeds a reference temperature or the battery level is below a reference value, the operating state risk value may increase because the possibility of failure or device malfunction during execution increases.

[0391] The first weighting constant may be a value for controlling the influence of network reliability on the risk level. The second weighting constant may be a value for controlling the influence of location-based risk values ​​on the risk level, and the third weighting constant may be a value for controlling the influence of operational state risk values ​​on the risk level. These weighting constants may be pre-set according to policy rules, task types, organizational policies, or user settings; for example, in external data transmission tasks, the influence of network reliability and location-based risk values ​​may be set significantly, and in device control tasks, the influence of operational state risk values ​​may be set significantly.

[0392] Mathematical Equation 1 can be configured to reflect different patterns of increase depending on the characteristics of each element, rather than simply summing the privilege shortage factor, network instability factor, location risk factor, and device operation risk factor. For example, since the number of unprivileged elements is reflected through a logarithmic function, the risk increases as the privilege shortage increases, but the rate of increase may become gradual beyond a certain level. Additionally, since network reliability is reflected as a squared term, the risk may increase non-linearly as network reliability decreases.

[0393] In addition, Equation 1 can limit the final risk level to a certain range using an exponential function. Accordingly, even when multiple risk factors exist simultaneously, the risk level increases rapidly, yet the final risk level can be calculated within a stable range without excessive divergence. This structure is advantageous for setting stable, approval, and blocking ranges in actual systems.

[0394] For example, if user authority is sufficient, network reliability is high, the user terminal (210) is located in an allowed zone, and the temperature and battery condition are normal, the electronic device (100) can calculate a low risk. Conversely, if the user does not possess some of the necessary authority, the user terminal (210) is connected to an unauthorized network, is located in a prohibited zone, and the battery level is low, the electronic device (100) can calculate a high risk.

[0395] The electronic device (100) can determine whether to execute a target task by comparing the risk level calculated by mathematical formula 1 with a preset stable range. For example, if the risk level is included in the stable range, the target task can be automatically executed; if the risk level is included in the caution range, a user approval request can be transmitted through the user terminal (210); and if the risk level is included in the blocking range, the execution of the target task can be blocked.

[0396] The risk calculation method according to mathematical formula 1 has technical significance in that, unlike methods that simply check only user authority or only device status, it comprehensively reflects insufficient authority, network environment, location conditions, and device operation status. Accordingly, the electronic device (100) can make different execution decisions depending on the execution environment even for the same user request, and can more precisely evaluate complex risk situations that are difficult to judge with fixed rules alone.

[0397] In addition, Equation 1 can adjust weight constants according to the type of target task, so it can be adaptively applied to various service environments. For example, the document summarization task can relatively significantly reflect the influence of the number of unauthorized items, the external data transmission task can significantly reflect the influence of network reliability and location-based risk values, and the IoT device control task can significantly reflect the influence of the operational status risk value.

[0398] Consequently, according to the present embodiment, the electronic device (100) can calculate the risk level of a target task by quantifying various elements included in policy rules and device status information, thereby more accurately determining whether an execution plan generated by an artificial intelligence model can be safely executed in an actual execution environment. In particular, since Equation 1 non-linearly reflects multiple risk factors, it enables more flexible and precise execution control than a single condition-based blocking method.

[0399] According to one embodiment, the electronic device (100) can calculate the risk of a target task using mathematical formula 1 and perform a series of scenarios to determine whether to execute based on the calculated risk.

[0400] For example, a situation can be assumed in which a user inputs a request through a user terminal (210) such as “summarize the internal report and send it to an external partner’s email.” After receiving the user request, the electronic device (100) can generate an execution plan including “document search → document summary → sensitive information review → external email transmission” using a first artificial intelligence model.

[0401] Afterward, the electronic device (100) can identify each parameter included in Equation 1 to calculate the risk level of the target task based on the execution plan.

[0402] First, if the user authority of the user terminal (210) is at the general user level, the electronic device (100) can set an intermediate level authority value by referring to the authority level value mapping table included in the policy rule. Additionally, if some of the external transmission and file access permissions included in the execution plan are not granted to the user, the electronic device (100) can calculate the number of non-authorized permissions as 1 or more.

[0403] Next, if the user terminal (210) is connected to a public Wi-Fi and the packet loss rate is measured to be high for a certain period of time, the electronic device (100) can calculate the network reliability as a low value. In this case, since the network reliability in Equation 1 is reflected as a squared term, the risk may increase non-linearly as the reliability decreases.

[0404] Additionally, if the location of the user terminal (210) is identified as an external area rather than an internal allowed area, the electronic device (100) may set the location-based risk value to a relatively high value. Furthermore, if the battery level of the user terminal (210) is low and the CPU usage is high, the operating state risk value may also be reflected as an increased value.

[0405] The electronic device (100) can calculate the final risk level by substituting each parameter calculated as above into Equation 1. At this time, the number of non-authorized items is reflected in the form of a logarithmic function, so that if there is a lack of authorization, the risk level increases but is controlled so as not to diverge excessively, and network reliability is reflected through a squared term so that the risk level can increase rapidly in an unstable network environment. In addition, the location-based risk value and the operational status risk value can linearly affect the total risk level according to a weighting constant.

[0406] For example, when the above conditions are combined, the electronic device (100) can calculate the risk level to be 0.7 or higher, which may correspond to a preset blocking interval. Accordingly, the electronic device (100) does not automatically execute the target task and can block execution by providing a guidance message such as “External transmission is restricted under current network and location conditions” through the user terminal (210).

[0407] Conversely, a case may be considered where the same user request is performed in an internal corporate network environment, the user has sufficient authority, the location of the user terminal (210) is within an allowed area, and the device state is stable. In this case, the electronic device (100) can calculate the number of unauthorized items as 0, set the network reliability to a high value, and reflect the location-based risk value and the operational status risk value as low values.

[0408] Under these conditions, the risk level calculated by mathematical formula 1 may be included in a stable range of 0.2 or less, and the electronic device (100) can automatically execute the target task without a separate approval procedure. For example, document summarization and internal sharing steps are performed immediately, and external transmission can also be performed automatically if policy conditions are satisfied.

[0409] In another scenario, when the risk level is at an intermediate level (e.g., 0.4 or higher and 0.7 or lower), the electronic device (100) may transmit a user approval request through the user terminal (210). At this time, the user terminal (210) may display a message such as, “There is an external transmission task involved, and the current network status is not fully trusted. Do you wish to proceed?” The target task may be executed only if the user provides an approval input.

[0410] In this way, the electronic device (100) can calculate a risk level reflecting various environmental conditions based on mathematical formula 1, and perform different execution control operations such as automatic execution, user approval request, or execution blocking depending on the range to which the risk level belongs.

[0411] In particular, this embodiment calculates different risk levels depending on the authorization status, network environment, location conditions, and device status even for the same user request, and allows the execution result to vary accordingly. This has technical significance in that, unlike fixed rule-based control methods, it enables dynamic and adaptive execution control that reflects the actual execution environment.

[0412] In addition, since mathematical formula 1 reflects each risk factor non-linearly, it can be designed so that the overall risk level increases rapidly when a specific risk factor exceeds a threshold level. Accordingly, the electronic device (100) can effectively identify complex risk situations that are difficult to detect with single-factor-based judgment.

[0413] Consequently, the scenario according to the present embodiment can provide a specific application example that enables a personal agent system to go beyond simply performing user requests and to make safe and reliable execution decisions by comprehensively considering the execution environment.

[0415] The operation of generating the above verification result is,

[0416] The above processor performs the operation of retrieving at least one data from an internal database including policy documents, device manuals, historical audit logs, and user history information; and

[0417] The processor includes an operation of generating search augmentation generation (RAG)-based basis data that constitutes a basis for verification of the execution plan based on at least one searched data.

[0418] According to one embodiment, in order to improve the reliability of the verification result using the second artificial intelligence model, the electronic device (100) is not limited to using only the execution plan itself as input, but can generate verification grounds by utilizing various ground information stored in an internal database together. To this end, the electronic device (100) can retrieve at least one data from an internal database including policy documents, device manuals, past audit logs, and user history information.

[0419] Here, the internal database may be implemented as a data store located in an internal storage of an electronic device (100) or a local network environment, and may be configured as a cache synchronized with data stored on an external server (220). The policy document may include a document defining actions allowed or prohibited by the system, authorization criteria, data processing criteria, and security requirements. For example, rules such as “personal information masking required when transmitting externally,” “administrator authority commands require approval,” and “specific API calls allowed only on the internal network” may be included in the policy document.

[0420] A device manual may include information defining how to use a specific device or system function, limitations, safety standards, and operating conditions. For example, in the case of a task related to IoT device control, the device manual may include temperature ranges, conditions for changing operating modes, safety cutoff conditions, etc., and the electronic device (100) may determine the suitability of an execution plan based on this information.

[0421] Past audit logs may include the execution history, verification results, user approval status, error history, or policy violation cases of previously performed target tasks. The electronic device (100) may search for past cases similar to the current execution plan to refer to how the execution was handled in the past. For example, if a similar external transmission task has a history of being blocked in the past, the electronic device (100) may generate a more conservative verification result for the execution plan.

[0422] User history information may include previous usage patterns, approval history, permission change history, or task preferences of a specific user or user terminal (210). For example, if a specific user has repeatedly approved a specific type of task, the electronic device (100) may refer to the pattern to adjust the risk of the execution plan or generate a verification result.

[0423] The electronic device (100) may generate a search query based on the contents of an execution plan, the type of target task, included tool call information, data access target, or device control command to search for at least one of the various data as described above. For example, if the execution plan includes “external API call,” the electronic device (100) may search for related API policy documents, past call history, and security criteria.

[0424] The data retrieved in this manner is not used merely as reference information, but can be composed of evidence data based on Retrieval-Augmented Generation (RAG). The electronic device (100) can structure or summarize the retrieved documents, logs, or historical data and convert them into a form that can be input into a second artificial intelligence model. For example, relevant provisions of policy documents, summaries of past audit logs, and safety conditions of device manuals can be composed of a single set of evidence data.

[0425] The second AI model receives the aforementioned supporting data along with the execution plan and can determine whether the execution plan conforms to policy rules, device conditions, and past cases. In other words, the second AI model can generate verification results by referencing actual document-based evidence, rather than simply relying on learned parameters. For example, if a specific data transmission included in the execution plan is specified as a prohibited item in a policy document, the second AI model can generate a blocking or modification verification result based on that evidence.

[0426] Additionally, the electronic device (100) can manage source information of the basis (e.g., policy document identifier, log ID, manual item number, etc.) together with the basis data. This can contribute to improving the explainability of the verification results. For example, when providing verification results to a user terminal (210), an explanation such as “external transmission is restricted pursuant to Article 3 of the policy document” can be provided.

[0427] Such a RAG-based verification structure can provide higher accuracy and reliability compared to simple rule-based filtering or model-based judgments. In particular, system flexibility can be enhanced because verification is performed based on the latest documents or logs, even when policy changes or device environment shifts occur.

[0428] Additionally, the electronic device (100) can store the retrieved evidence data and verification results together as audit information. This allows tracking of the grounds on which a specific execution was allowed or blocked in subsequent post-audit or dispute situations.

[0429] Consequently, according to the present embodiment, the electronic device (100) can provide the effect of supplementing the judgment of the artificial intelligence model and improving policy compliance and explainability by utilizing various evidence data retrieved from an internal database during the verification process of the execution plan. This can function as an important component that simultaneously improves the reliability, security, and auditability of the personal agent system.

[0431] The operation of generating the above execution plan is,

[0432] The above processor performs the operation of determining the computational resources required for the execution of the target task, the allowable response delay range, and the network status based on the user request; and

[0433] The processor includes an operation of determining whether to generate the execution plan using the first artificial intelligence model on-device or to generate the execution plan based on an artificial intelligence model deployed on an external server, depending on the result of the determination.

[0434] According to one embodiment, the electronic device (100) may dynamically determine the location and method of generating the execution plan by comprehensively considering the current system environment and execution conditions, rather than always calling the artificial intelligence model in the same way when generating an execution plan corresponding to a user request. To this end, after receiving a user request, the electronic device (100) may determine the computational resources required for the execution of the target task, the allowable response delay range, and the network status.

[0435] First, the electronic device (100) can determine the computational resources required to perform the target task. Here, the computational resources may include CPU performance, GPU or NPU acceleration resources, memory capacity, storage space, and current resource utilization required to execute the first artificial intelligence model. The electronic device (100) can monitor the current resource status of the device to determine whether the execution plan generation process can be performed on-device. For example, if large-scale document analysis or complex multi-step plan generation is required, and on-device resources are insufficient, it may be more appropriate to utilize the computational resources of an external server (220).

[0436] Additionally, the electronic device (100) can determine an acceptable response delay range for user requests. The acceptable response delay range may be a criterion indicating how quickly a task requested by a user should be processed. For example, very short response times may be required in cases such as command processing in a real-time voice interface or vehicle control, in which case the electronic device (100) may prioritize on-device-based execution to minimize network delay. On the other hand, for tasks that do not require an immediate response, such as large-scale data analysis or report generation, a certain level of delay may be allowed and an external server (220) may be utilized.

[0437] The electronic device (100) can also determine the network status of the user terminal (210). The network status may include connection status, bandwidth, latency, packet loss rate, and connection stability. For example, if the network connection is unstable or offline, the electronic device (100) may decide to generate an execution plan on-device without relying on an external server (220). Conversely, if a high-speed network environment is available, a more sophisticated execution plan may be generated by utilizing the high-performance model of the external server (220).

[0438] The electronic device (100) can determine the method for generating an execution plan by comprehensively considering the computational resources, response delay tolerance range, and network conditions determined as above. For example, if computational resources are sufficient, response delay requirements are low, and network conditions are unstable, on-device-based execution plan generation may be selected. On the other hand, if computational resources are insufficient, high-quality plan generation is required, and network conditions are good, an artificial intelligence model deployed on an external server (220) may be utilized.

[0439] At this time, on-device based execution plan generation means that the first artificial intelligence model is executed directly inside the electronic device (100), and has the advantage that user requests and related data can be processed in a local environment without being transmitted externally. This is advantageous in terms of privacy protection and security, and can reduce dependency on the network.

[0440] On the other hand, when utilizing an artificial intelligence model deployed on an external server (220), the electronic device (100) transmits minimal input data for user requests and execution plan generation to the external server (220), and the external server (220) generates an execution plan based on this and returns it to the electronic device (100). Since the external server (220) can provide relatively high computational performance, it is advantageous when more complex inference or large-scale data processing is required.

[0441] Additionally, the electronic device (100) may also apply a hybrid method of using a combination of an on-device model and a model from an external server (220). For example, the electronic device (100) may generate the framework of a basic execution plan on-device and then use a model from an external server (220) to supplement the detailed plan for specific steps. Alternatively, the execution plan generated from the external server (220) may be re-verified or partially modified on-device.

[0442] The electronic device (100) can include the results of the decision on the execution plan generation method in the audit information, thereby allowing tracking of how the execution plan was generated in which environment thereafter. For example, if a specific task is repeatedly processed through an external server (220), the electronic device (100) can learn the pattern and apply a more efficient resource allocation strategy in similar situations in the future.

[0443] According to the present embodiment, the electronic device (100) can dynamically select the location for generating an execution plan by considering the execution environment, rather than simply calling an artificial intelligence model, thereby achieving a balance of performance, responsiveness, security, and resource efficiency. In particular, by providing a flexible structure that can utilize the computational resources of an external server (220) when necessary while maintaining a local priority structure, it can respond to various device environments and service requirements.

[0444] As a result, the configuration according to the present embodiment can provide technical effects that improve resource optimization and execution efficiency in the process of generating an execution plan for an AI-based personal agent, while simultaneously ensuring personal information protection and system stability.

[0446] The operation of executing the above target task is,

[0447] The above processor includes an operation of performing at least one of file system access, external API call, or device control command based on tool call information included in the execution plan.

[0448] According to one embodiment, the electronic device (100) can actually perform a target task based on tool call information included in an execution plan generated by a first artificial intelligence model. Here, the tool call information may be structured information defining the target function to be performed at each step included in the execution plan, the target interface to be called, input parameters, execution order, and expected result.

[0449] The electronic device (100) can interpret tool call information included in an execution plan and perform at least one of file system access, external API call, or device control command. In this case, the tool call information may be expressed, for example, in the form of a function call, a command list, a JSON structure, or an internal execution schema, and each tool call may be defined as an executable unit task.

[0450] File system access may include the electronic device (100) accessing a local storage or a connected storage device to read, write, modify, delete, or search for files. For example, in the case of a task to “summarize a meeting minutes file,” the electronic device (100) may perform a tool call to search for the relevant document in the file system and read its contents.

[0451] External API calls may include actions in which the electronic device (100) communicates with an external server (220) or a third-party system to request data or perform tasks. For example, tasks such as “looking up weather information” or “transmitting data to an external partner system” can be performed through external API calls. In this case, the electronic device (100) can appropriately process authentication tokens, request parameters, and response data.

[0452] A device control command may include an action that changes the state of a device or system to which the electronic device (100) is connected. For example, this may include power control of an IoT device, mode change of a vehicle interface, change of settings of a wearable device, or adjustment of system settings. The electronic device (100) may generate and execute the device control command based on tool call information.

[0453] The electronic device (100) can execute tool calls included in the execution plan sequentially or in parallel, and can use the execution result of each step as the input for the next step. Additionally, results, errors, or state changes occurring during the execution of each tool call can be recorded as audit information.

[0454] Additionally, the electronic device (100) may perform execution only within the scope permitted by the second artificial intelligence model or policy rules prior to performing the tool call. For example, high-risk tool calls, such as external API calls or device control, may be executed only after passing user approval or policy verification.

[0455] According to this tool call-based execution structure, execution plans generated by artificial intelligence models can be safely connected to actual system operations, and personal agent functions capable of performing actual tasks beyond simple text responses can be implemented.

[0457] The above policy rule is,

[0458] It includes global rules applicable to all users, personal rules based on user-specific settings, tenant rules set at the organizational level, and device rules based on device characteristics.

[0459] According to one embodiment, an electronic device (100) may refer to policy rules defined in various ranges to determine whether to execute a target task or to generate a verification result. The policy rules may include global rules that apply commonly to all users, personal rules based on user-specific settings, tenant rules set at the organizational level, and device rules based on device characteristics.

[0460] Global rules are fundamental policies applied universally across the entire system and may include service operation standards, security policies, definitions of prohibited acts, or basic restrictions. For example, rules such as "prohibition of malicious code execution," "prohibition of unauthorized data access," and "restriction on external transmission of personal information" may be included in global rules. Global rules can be applied equally to all users and all devices.

[0461] Personal rules may refer to policies set individually for specific users. These may include user preferences, access permissions, usage restrictions, or personalized security settings. For example, if a specific user has configured the external data transmission function to be restricted, related tasks may be blocked according to that user's personal rules.

[0462] Tenant rules may refer to policies defined at the organizational or group level. For example, in an enterprise environment, departmental access rights, data sharing policies, standards for data exchange with external partners, or compliance requirements may be set as tenant rules. The electronic device (100) may apply the tenant rules based on the organizational information to which the user terminal (210) belongs.

[0463] Device rules may refer to policies applied according to the characteristics of a user terminal (210) or an electronic device (100). These may be defined based on the device's operating system, security status, location, network environment, or hardware characteristics. For example, certain functions may be restricted on public devices, or device control commands may be prohibited in certain locations.

[0464] The electronic device (100) may apply the global rule, private rule, tenant rule, and device rule hierarchically or based on priority. For example, the global rule may always be applied first, followed by the tenant rule, private rule, and device rule. Alternatively, in certain situations, the device rule may be applied first.

[0465] Additionally, the electronic device (100) can determine the final applicable rule based on a predefined priority or policy interpretation criteria when a conflict occurs between multiple policy rules. For example, if an action allowed in a personal rule is prohibited in a tenant rule, the tenant rule can be applied first to block the action.

[0466] The electronic device (100) can utilize policy rules throughout the execution plan generation phase, verification phase, and execution phase. For example, policy rules can be reflected during execution plan generation to ensure that dangerous phases are not included, policy violations can be determined during the verification phase, and actual tool calls can be restricted during the execution phase.

[0467] According to such a multi-layered policy rule structure, the electronic device (100) can flexibly control operation according to the user, organization, and device environment, and can produce different execution results depending on various conditions even for the same user request. This can provide the effect of simultaneously improving the security, flexibility, and policy compliance of the personal agent system.

[0469] The operation of updating at least one model parameter among the first artificial intelligence model and the second artificial intelligence model is,

[0470] The operation of the above processor generating update parameters within the electronic device without transmitting raw data included in the audit information externally;

[0471] The above processor performs the operation of transmitting the update parameters to an external server; and

[0472] The above processor includes an operation of aggregating cumulative update parameters received from a plurality of devices over a predetermined period and the generated update parameters, and applying differential privacy-based noise to update at least one model parameter of the first artificial intelligence model or the second artificial intelligence model.

[0473] According to one embodiment, the electronic device (100) can update model parameters using audit information generated during the execution of a target task in order to improve the performance of the first artificial intelligence model and the second artificial intelligence model. In this case, considering personal information protection and data security, the electronic device (100) can generate update parameters internally within the electronic device (100) without transmitting the raw data included in the audit information to the outside.

[0474] Here, raw data may include the original text of a user request, document content, voice data, location information, or personally identifiable information, and there may be a risk of personal information leakage if such data is transmitted externally. Therefore, instead of directly utilizing the raw data, the electronic device (100) can extract update parameters, such as feature information, gradient values, error information, or parameter change amounts, from the data that are necessary for model updates.

[0475] For example, if an execution plan generated by a first artificial intelligence model is repeatedly determined to have a high probability of policy violation, the electronic device (100) can generate update parameters by converting a pattern such as “specific type of request → specific execution plan generation → verification result blocking” from the case into a learnable form. Additionally, if the verification result of a second artificial intelligence model is inconsistent with the actual execution result, update parameters can be generated to correct the judgment criteria of the verification model based on the error information.

[0476] The electronic device (100) can transmit the generated update parameters to an external server (220). The information transmitted at this time may be limited to the minimum information required for model updates rather than raw data, thereby preventing the exposure of personal information.

[0477] The external server (220) can aggregate cumulative update parameters received from multiple electronic devices over a predetermined period. In this process, a Secure Aggregation method may be applied, and the update contribution of individual devices can be maintained while protecting the data of individual devices from being identifiable.

[0478] Additionally, the external server (220) may apply differential privacy-based noise to the aggregated update parameters. Here, differential privacy is a technique to limit the influence of data from a specific user or specific device on the result, and can reduce the possibility of re-identifying individual data by adding a certain level of probabilistic noise.

[0479] For example, to prevent update parameters generated from a specific user terminal from being excessively reflected in the overall model update, an external server (220) may add Gaussian noise or Laplace noise. In this case, the magnitude of the noise may be adjusted according to a predefined privacy budget.

[0480] Based on the aggregated results with differential privacy applied, the external server (220) can update at least one model parameter of the first artificial intelligence model or the second artificial intelligence model. The updated model can then be distributed to the electronic device (100), thereby gradually improving the performance of the entire system.

[0481] According to the present embodiment, the electronic device (100) can improve model performance by collecting collective knowledge from multiple devices while maintaining a local-first learning structure that does not transmit raw data externally. In particular, by applying differential privacy, it can provide the effect of improving the generalization performance of the artificial intelligence model while satisfying personal information protection requirements.

[0483] The operation of generating the above verification result or determining whether to execute the above is,

[0484] The above processor determines whether the target task is executable based on device trust information including at least one of rooting status, signature verification status, and certificate validity, which indicates the security status of the device; and

[0485] The above processor further includes the operation of, when executing the target task, generating tool call information included in the execution plan in an electronically signed form and recording events occurring during the execution process of the target task in the form of a sequentially connected hash chain.

[0486] According to one embodiment, the electronic device (100) can determine whether a target task can be executed or generate a verification result based on device reliability information indicating the security status of the user terminal (210).

[0487] Here, the device trust information may include whether the user terminal (210) is rooted, the signature verification status of the application or execution module, the validity of the certificate, and other security status information. The electronic device (100) can identify the device trust information by receiving the information from the user terminal (210) or by directly verifying it through a security module.

[0488] For example, if the user terminal (210) is rooted or jailbroken, the system security may be compromised, so the electronic device (100) may restrict the execution of high-risk tasks requested on the terminal. Additionally, if the application's signature verification fails or the certificate expires, the electronic device (100) may negatively determine whether the target task can be executed.

[0489] The electronic device (100) can determine in advance whether a target task is executable based on device reliability information, and can generate an execution plan or restrict the execution itself according to the result of the determination. For example, if the device reliability is low, high-risk tasks such as external data transmission, system command execution, or device control can be blocked.

[0490] Additionally, the electronic device (100) can generate tool call information included in the execution plan in an electronically signed form when executing a target task. Here, the electronic signature can be generated using a security key or certificate of the electronic device (100) as a means to guarantee the integrity and source of the tool call information.

[0491] For example, commands included in the execution plan, such as “file deletion” or “external transfer,” are generated in an electronically signed form and can only be executed if the corresponding signature is verified during actual execution. This prevents tool call information from being tampered with during the execution process.

[0492] Additionally, the electronic device (100) can record events occurring during the execution of a target task in the form of a sequentially connected hash chain. Each event can be configured to include the hash value of the previous event, thereby ensuring the integrity of the entire execution flow.

[0493] For example, events such as “receipt of user request → generation of execution plan → generation of validation result → user approval → execution execution → post-audit” are recorded sequentially, and each event can form a chain structure by including the hash value of the previous event.

[0494] According to this hash chain structure, if an intermediate event is changed or deleted, the subsequent hash value becomes inconsistent, so it is easy to detect whether the log has been tampered with. Therefore, the electronic device (100) can maintain a reliable audit log.

[0495] According to the present embodiment, the electronic device (100) can multi-layeredly enhance the security of the personal agent system by combining a determination of execution feasibility based on device reliability, an guarantee of execution integrity based on electronic signatures, and a hash chain-based audit log record. In particular, it can provide the effect of improving the overall reliability of the system by restricting execution on untrusted terminals, preventing tampering with the execution process, and maintaining the execution history in a verifiable form.

[0497] The above description is merely an illustrative explanation of the technical concept of the present invention, and those skilled in the art to which the present invention pertains will be able to make various modifications and variations within the scope of the essential characteristics of the present invention.

[0498] Accordingly, the embodiments disclosed in this invention are intended to illustrate, not limit, the technical concept of the invention, and the scope of the technical concept of the invention is not limited by these embodiments. The scope of protection of this invention shall be interpreted by the claims below, and all technical concepts within an equivalent scope shall be interpreted as being included within the scope of rights of this invention.

Claims

Claim 1 A personal agent execution and auditing method having adaptive generation of an execution plan and auxiliary verification functions, performed by an electronic device including a processor, wherein the processor, upon receiving a user request from a user terminal, generates an execution plan including the name and execution order of a target task corresponding to the user request using a first artificial intelligence model; wherein the processor inputs the user request, the execution plan, and device status information received from the user terminal into a second artificial intelligence model that is distinguished from the first artificial intelligence model and learned based on a preset policy rule, thereby generating a verification result for the execution plan; wherein the processor determines whether to execute the target task based on the execution plan based on the verification result; and wherein, when the target task is executed according to the determination of whether to execute, the processor generates and stores audit information regarding the execution result and updates at least one model parameter of the first artificial intelligence model and the second artificial intelligence model using at least a portion of the audit information, wherein the operation of generating the execution plan comprises: the processor determining, based on the user request, the computational resources required for the execution of the target task, the allowable response delay range, and the network status. A personal agent execution and auditing method comprising the operation of the processor determining, based on a judgment result, whether to generate the execution plan using the first artificial intelligence model on the device or to generate the execution plan based on an artificial intelligence model deployed on an external server. Claim 2 delete Claim 3 A personal agent execution and auditing method according to claim 1, wherein the operation of generating the verification result further comprises the operation of the processor using the second artificial intelligence model to perform a pre-audit of the execution plan based on locally stored policy rules and search augmentation generative (RAG)-based evidence data, and generating a verification result including any one of allow, revise, escalate, or block. Claim 4 In claim 3, the operation of determining whether to execute the target task based on the verification result comprises: the operation of the processor determining the risk level of the target task based on authorization information included in the policy rule and device status information received from the user terminal when the verification result is not generated through the second artificial intelligence model; the operation of the processor determining to execute the target task by generating an auxiliary verification result including the permission when the risk level of the target task is included in a set stable range; the operation of the processor performing a post-audit to verify whether the execution result and the execution plan match using the second artificial intelligence model after the execution of the target task is performed; and the operation of the processor generating an audit log of a chain structure including at least one hash value corresponding to at least one event that occurred during the execution process of the target task, storing it in a database, and updating at least one of the first artificial intelligence model or the second artificial intelligence model based on the audit log. Claim 5 In claim 4, the operation of determining the risk level of the target task comprises: the operation of the processor using the authorization information and the device status information to identify an authorization level value set corresponding to the user authorization level of the user terminal and a number of non-authorized items indicating the number of authorization items required for the execution of the target task for which the user terminal does not possess authorization; the operation of the processor using the device status information to identify the network reliability of the user terminal based on whether the user terminal is connected to an unauthorized network and the packet loss rate over a predetermined period; the operation of the processor using the device status information to identify a location-based risk value based on the result of a comparison between the location of the user terminal and a preset zone table; the operation of the processor using the device status information to identify an operational state risk value based on the temperature and remaining battery level of the user terminal; and the operation of the processor to calculate the risk level of the target task based on at least one of the authorization level value, the number of non-authorized items, the network reliability, the location-based risk value, and the operational state risk value.

Images