Information processing device, information processing method, and information processing program

Abstract

Evaluate the consistency with the rules during the agent specification stage before implementation. [Solution] The information processing device according to the present invention is characterized by comprising: an acquisition unit that acquires agent specifications defining the requirements of an AI agent that performs a predetermined process; an evaluation unit that evaluates the consistency of the agent specifications with predetermined rules relating to the predetermined process; a deliverable management unit that saves the evaluation content as deliverables; and an output unit that outputs deliverables. The evaluation unit mechanically checks the agent specifications in three stages: business rules, technical implementation, and execution results.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, and an information processing program.

Background Art

[0002] A technique for identifying the cause location of software errors has been disclosed (see Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the above prior art, it only analyzes the logs from the start of server startup to the occurrence of an error and identifies the cause location of the error based on the output content to the logs at the time of error occurrence. Therefore, in the prior art, it is impossible to evaluate the consistency with rules for an AI agent before introduction at the agent specification stage.

[0005] The present application has been made in view of the above, and an object thereof is to evaluate the consistency with rules before introduction at the agent specification stage.

Means for Solving the Problems

[0006] The information processing apparatus according to the present application includes an acquisition unit that acquires an agent specification defining requirements for an AI agent that executes predetermined Business processing, an evaluation unit that evaluates the but consistency regarding the predetermined Business processing, an artifact management unit that stores the evaluation content as an artifact, and an output unit that outputs the artifact, and is characterized by this. ​​

[0007] Furthermore, some or all of the above-mentioned solutions may be implemented using various technologies and methods related to artificial intelligence (including, but not limited to, the use of various generative AI models realized using machine learning, deep learning, large-scale language models, etc.). [Effects of the Invention]

[0008] According to one embodiment, the consistency with the rules can be evaluated before deployment at the agent specification stage. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is an explanatory diagram showing an overview of the information processing system according to the embodiment. [Figure 2] Figure 2 is an explanatory diagram showing an overview of the processing flow of the dynamic wiring agent infrastructure according to the embodiment. [Figure 3] Figure 3 is an explanatory diagram showing an overview of the architectural configuration of the DSL static verification platform according to the embodiment. [Figure 4] Figure 4 is an explanatory diagram showing an overview of the processing flow of the DSL static verification platform according to the embodiment. [Figure 5] Figure 5 is an explanatory diagram showing an overview of the architectural configuration of the guardrail automatic insertion base according to the embodiment. [Figure 6] Figure 6 is an explanatory diagram showing an overview of the processing flow of the automatic guardrail insertion platform according to the embodiment. [Figure 7] Figure 7 shows an example of the configuration of a server device according to this embodiment. [Figure 8] Figure 8 is a flowchart showing the processing procedure of the DSL static verification platform according to the embodiment. [Figure 9] Figure 9 is a flowchart showing the processing procedure of the automatic guardrail insertion base according to the embodiment. [Figure 10] Figure 10 shows an example of a hardware configuration. [Modes for carrying out the invention]

[0010] The following describes in detail, with reference to the drawings, embodiments for implementing the information processing device, information processing method, and information processing program according to the present application (hereinafter referred to as "embodiments"). Note that these embodiments do not limit the information processing device, information processing method, and information processing program according to the present application. Furthermore, the same parts are denoted by the same reference numerals in the following embodiments, and redundant descriptions are omitted.

[0011] [1. Overview of the Information Processing System] First, with reference to Figure 1, an overview of the information processing system according to the embodiment will be described. Figure 1 is an explanatory diagram showing an overview of the information processing system according to the embodiment. As shown in Figure 1, the information processing system 1 according to the embodiment includes a terminal device 10 and a server device 100. The terminal device 10 and the server device 100 are connected to each other via a network N, either by wired or wireless means, enabling communication between them. This allows the terminal device 10 to cooperate with the server device 100. The network N is, for example, a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet.

[0012] Terminal device 10 is an information processing device used by user U (user). For example, terminal device 10 is a computer such as a desktop PC (Personal Computer) or a notebook (laptop) PC. Alternatively, terminal device 10 may be a smart device such as a smartphone or tablet, or a wearable device such as a head-mounted display (HMD) or smart glasses.

[0013] The server device 100 is an information processing device that audits AI (Artificial Intelligence) agents. Also, the server device 100 manages an OSS (Open Source Software) infrastructure that serves as a foundation for constructing and operating an IT infrastructure. For example, the server device 100 is composed of a PC, a cloud server, an on-premises edge server, a blade server, a rack-mounted server, a tower-type server, a workstation, or a mainframe, etc.

[0014] In this embodiment, the server device 100 manages LangGraph as an example of the OSS infrastructure. LangGraph models a workflow as a graph structure and supports the automation of complex tasks and the state management of the system. In LangGraph, the graph structure of the workflow is composed of two components, "nodes" and "edges", and the boxes called nodes are connected by arrows called edges to construct the overall flow. Regarding which to prioritize, the connection (wiring) of the boxes or the content inside the boxes (information processing), first ensure that the content inside the boxes (the roles of individual members / AI) is in a working state, and then organize the boxes (connection of the flow).

[0015] Also, the server device 100 may cooperate with the terminal device 10 of the user U and provide an API (Application Programming Interface) service for a predetermined application (hereinafter referred to as an app) and data used by the app to the terminal device 10 of the user U.

[0016] Also, the number of each device included in the information processing system 1 shown in FIG. Ⅰ is not limited to what is shown. For example, in FIG. Ⅰ, only one terminal device 10 is shown for simplicity of illustration, but this is merely an example and not limiting, and there may be two or more.

[0017] Furthermore, the server device 100 may implement the mechanism of this embodiment, as described below, using AI. For example, the AI ​​model (machine learning model) may be a large language model (LLM) such as GPT (registered trademark), a diffusion model such as "Stable Diffusion", a multimodal model, or a generative adversarial network (GAN). GPT (registered trademark) is a generative pre-trained transformer, a type of generative AI, and a language model capable of generating text using natural language processing. When using AI, the server device 100 implements each process by inputting the data to be processed and a prompt (instruction text) to instruct the processing into the AI.

[0018] In the following explanation, the server device 100 will be described as the one performing the processing (the server device 100 being the main operator). However, in practice, the user U's terminal device 10, which is connected to the server device 100 via the network N, may perform the processing (the user U's terminal device 10 being the main operator). Furthermore, the processing performed by the server device 100 described below may be carried out by AI. That is, the AI ​​may operate on either the user U's terminal device 10 (terminal side) or the server device 100 (server side). In addition, federated learning may be performed between the user U's terminal device 10 (terminal side) and the server device 100 (server side).

[0019] [2. Audit Rule-Driven Dynamic Cabling Agent Infrastructure] This embodiment describes the concept of a platform that automatically switches AI agent workflows (AI workflows) based on audit rules, the reduction of operational costs by reducing manual corrections by engineers, and the importance of logging to ensure accountability.

[0020] The audit rule-driven dynamic wiring agent platform according to this embodiment is a platform in which, in the auditing of AI agents, the AI ​​workflow route is automatically rearranged simply by rewriting the audit rules, and the "reason for the route change" is recorded as machine-readable evidence. This platform aims to reduce the effort required for engineers to manually modify programs when business decisions or rule changes occur on-site, thereby lowering operational costs. It also logs the reasons for flow changes, enabling accountability and historical tracking in the event of an incident.

[0021] Existing AI agent implementations do not support dynamic workflow changes or audit modeling. Furthermore, the current problem lies in the black box nature of decision-making. For example, even if rules are taught to an AI agent and assigned to perform specific tasks, rule changes can occur frequently due to legal revisions or changes in the business environment. In these cases, engineers manually implement the rule changes, making the relationship between business decisions and implementation modifications unclear. In other words, because engineers manually modify the flow when rules change, the intentions and impacts are not recorded. Moreover, the lack of records makes it difficult to explain, for example, "why the change was made in that way."

[0022] Therefore, in this embodiment, automatic wiring is achieved using a rule DSL (Domain-Specific Language). A rule DSL refers to a DSL file that defines rules. For example, the audit rule DSL is evaluated and the AI ​​workflow is automatically restructured. In addition, the changes and their rationale are recorded in JSONL (JSON Lines) to make them reproducible later. JSONL is a format in which independent JSON (Java Script Object Notation) data is arranged line by line (1 line = 1 data).

[0023] In this way, when rules are changed, the AI ​​workflow is automatically reconfigured to comply with the changed rules, and this process can be reproduced as a log. This prevents the decision-making process from becoming a black box, and allows for the recording of the intent behind the changes and business decisions. It also improves accountability and response speed. For example, it enables immediate compliance with regulatory and rule revisions (without requiring code modifications). Furthermore, it speeds up the investigation of the root cause of incidents. Details are explained below.

[0024] [2-1. Architectural Configuration of the Dynamic Wiring Agent Platform] Referring to Figure 1, the architectural configuration of the audit rule-driven dynamic routing agent infrastructure according to this embodiment will be described.

[0025] The audit rule-driven dynamic wiring agent infrastructure according to this embodiment includes an audit rule engine 101, a topology manager 102, an AI workflow 103, an auditor 104, a trace logger 105, an object storage 106, and an operation UI (User Interface) 107.

[0026] The audit rule engine 101 functions as the "brain" that reads DSLs (Domain-Specific Languages) designed specifically for performing particular tasks or solving problems, and outputs the wiring policies to be applied. In this embodiment, when the audit rule engine 101 receives an audit rule DSL as input from the field, it reads the audit rule DSL, updates the wiring policy of the AI ​​workflow, and outputs the updated wiring policy as an instruction to the topology manager 102. The audit rule DSL is a rule that defines "how the AI ​​agent should behave," and it precisely defines the scope of the AI ​​agent's actions in the work, for example, "handling personal information is prohibited" or "handling certain confidential data is not allowed." The audit rule engine 101 also includes data such as the AI ​​agent's identification information (ID), operating conditions (Condition), priority (Priority), and scope of action as internal rules.

[0027] The topology manager 102 reads the initial flow of the AI ​​workflow 103 (initial connection and initial wiring of each node) and dynamically updates the connections (wiring) of each node in the AI ​​workflow 103 according to the instructions (wiring policy) from the audit rule engine 101. In this embodiment, the topology manager 102 adds, deletes, and changes the priority of nodes and edges in the LangGraph topology according to the wiring policy from the audit rule engine 101. The topology manager 102 can output, for example, as a flow in data format (code or data).

[0028] The AI ​​workflow 103 is a workflow executed by an AI agent. In this embodiment, the AI ​​workflow 103 is represented by a graph structure in LangGraph. The AI ​​workflow 103 includes five types of nodes: Planner 103a, Router 103b, Executor 103c, Synthesizer 103d, and Evaluator 103e. Each node, Planner 103a, Router 103b, Executor 103c, Synthesizer 103d, and Evaluator 103e, consists of one or more nodes. Each node is connected to a target node by an edge.

[0029] Auditor 104 audits (evaluates) the execution results, context, external scores, etc., of the AI ​​workflow 103. For example, auditor 104 audits the execution results of each of the AI ​​workflow 103's planning agent 103a, route determination agent 103b, execution agent 103c, integration agent 103d, and evaluation agent 103e. At this time, auditor 104 may receive evaluation results from the AI ​​workflow 103's evaluation agent 103e. Also, based on the audit results, auditor 104 instructs rewiring and re-execution when it detects an anomaly in the AI ​​agent (infinite loop, increased cost, etc.). Furthermore, if the anomaly is not resolved and a minor doubt arises, auditor 104 instructs to stop, and if a serious doubt arises, it instructs to redo the process via a different route instead of rewiring. In this embodiment, auditor 104 forms an autonomous loop control logic that repeats "anomaly detection → rewiring → re-execution" a predetermined number of times up to a threshold, for the purpose of audit compliance.

[0030] Trace Logger 105 records the workflow change action itself—"this change action was performed at this time"—rather than the rule itself before and after the change. The appropriate timing for creating the log is after the AI ​​workflow processing is complete and all information is available, regardless of the success or failure of the AI ​​workflow execution, as it records all information related to decisions and actions. The log includes both a rule explanation in human-understandable language, such as "data use is now OK," and the actual changes (change timeline) of "where and how the agent reconnected," and these are mapped together as a dictionary. Currently, it is envisioned to record only the difference (added content), but it may be possible to make the log better by keeping both the before and after information. The extent to which the trial-and-error process of rewiring and re-execution is logged will be a trade-off with cost. Also, even if the AI ​​workflow does not change despite a rule change, the decision "not to change" itself is an important asset and should be logged. Cases where logging is not taken are limited to cases where the trial-and-error process of unsuccessful attempts is to be omitted.

[0031] Furthermore, the trace logger 105 centrally records the flow differences of the AI ​​workflow and the audit evaluation results in JSONL format. For example, as an audit trail with differences, the trace logger 105 generates a routing difference record at each routing reconfiguration, which includes the rule ID, audit evaluation result, before and after topology, timestamp, and trace ID (trace_id), and stores it in the audit trail store in JSONL format. In this embodiment, the trace logger 105 extracts "node / edge difference data" at each reconfiguration step and persists it in JSONL format along with the rule ID, audit evaluation result, and timestamp (automatically recording logs persistently / permanently).

[0032] The object storage 106 is a storage device that handles data on an object basis. It receives flow differences, rule evaluations, step input / output, etc., stored in JSONL format from the trace logger 105 to the audit trail store, stores them on an object basis, and builds a search infrastructure. In practice, other search infrastructures may be used instead of the object storage 106.

[0033] The operation UI 107 is, for example, an audit view, which is displayed on the operator's terminal device 10. In response to the operator's actions, it accesses the object storage 106 and displays items such as "Trace ID Search," "Applied Rule List," "Wiring Change Timeline," and "Final Result Summary" on the screen. For example, the operation UI 107 displays selection buttons for items such as "Trace ID Search," "Applied Rule List," "Wiring Change Timeline," and "Final Result Summary" on the screen, and displays the screen for the selected item in response to the operator's selection operation (button press).

[0034] This information can be used, for example, in workflows such as KYC (Know Your Customer), credit screening and management, and internal audits for payment applications. Furthermore, the case-based accountability for such workflows can be explained on a single screen. The AI ​​agent can be used in any job, and the invention according to this embodiment is applicable not only to business-related audits such as those for payment applications, but also to "AI audits" in general. [2-2. Overview of the processing flow of the dynamic wiring agent infrastructure] Referring to Figure 2, an overview of the processing flow of the audit rule-driven dynamic routing agent infrastructure according to the embodiment will be described. Figure 2 is an explanatory diagram showing an overview of the processing flow of the dynamic routing agent infrastructure according to the embodiment.

[0035] For example, as shown in Figure 2, the topology manager 102 of the server device 100 receives a request and constructs the initial topology (step S1).

[0036] Next, the Planner 103a of the AI ​​workflow 103 of the server device 100 plans and breaks down tasks based on the initial topology. The routing manager 103b notifies the topology manager 102 of the broken-down tasks (step S2).

[0037] Next, the audit rule engine 101 of the server device 100 reads the audit rule DSL, performs a DSL evaluation, and determines the wiring policy (step S3).

[0038] Next, the topology manager 102 of the server device 100 dynamically updates the connections (wiring) of each node in the AI ​​workflow 103 according to the wiring policy. The trace logger 105 extracts the wiring differences and sends (outputs) the log to the object storage 106 (step S4).

[0039] Next, the executor 103c of the AI ​​workflow 103 on the server device 100 executes each task. The integrator 103d integrates the executed tasks (step S5).

[0040] Next, the evaluator 103e of the AI ​​workflow 103 of the server device 100 evaluates the integrated task (step S6).

[0041] Next, the auditor 104 of the server device 100 audits the execution results, context, external scores, etc., of the AI ​​workflow 103, and based on the audit results, if an anomaly is detected, it instructs the topology manager 102 to rewire and re-execute, thereby realizing an automated loop (step S7).

[0042] Finally, if the trace logger 105 of the server device 100 finds no problems (abnormalities) in the audit results, it confirms the audit trail and saves it in JSONL format to the audit trail store, completing the processing flow (step S8).

[0043] [3. Multilayer Schema & DSL Static Validation Pipeline] In this embodiment, the server device 100 mechanically checks the LLM generation specification (JSON / YAML) that defines the AI ​​agent specifications (agent specifications) in multiple stages. The LLM generation specification is, for example, similar to a requirements definition document (design document). In this embodiment, as an example, a case in which the LLM generation specification is checked in three stages: "business rules," "technical implementation," and "execution results" (3-tier schema & DSL static verification pipeline).

[0044] Conventional technologies frequently encountered issues in LLM generation, such as missing fields, type errors, and non-existent API calls (LLM uncertainty). Furthermore, DSL analysis was limited, primarily relying on syntax checks using a single schema (e.g., JSON Schema), and did not consider business constraints (limitations of simple checks). Even with correct syntax, structural flaws such as circularities and unreachable nodes were easily overlooked, and failures in tool call order or dependencies could not be detected (limitations of analysis capabilities). Additionally, in sectors like finance, where "running and failing" is unacceptable, execution verification was difficult (difficulty in verification). Moreover, it relied on manual testing and lacked automated correction capabilities (manual verification).

[0045] In this embodiment, a two-stage verification process is performed, consisting of a business layer (Layer 1) that verifies business rules and an implementation layer (Layer 2) that verifies implementation rules (implementation specifications), thereby verifying business rules and implementation rules separately. In other words, multi-layer verification is performed to detect "violations of business rules" and "implementation errors" separately (multi-layer verification). Furthermore, "structural failures" are detected before execution. For example, unreachable locations, infinite loops, and undefined tools are mathematically detected (static analysis). In addition, the sandbox execution results and specifications are compared and automatically corrected. For example, through "execution comparison + automatic recovery loop," a patch is generated from the difference between the sandbox execution trace (execution results / execution log in the sandbox environment) and the expected specifications (expected agent specifications), and the correction is performed automatically (automatic recovery). Furthermore, highly reliable flows in payments and transactions, such as KYC (Know Your Customer), AML (Anti-Money Laundering), and CFT (Countering the Financing of Terrorism), are screened "before execution" to minimize rework and risk (risk reduction).

[0046] For example, regarding the workflow of an AI agent created with LangGraph, the server device 100 first determines whether it satisfies business rules and implementation rules during the requirements definition phase, and then confirms that the AI ​​agent is appropriate for business execution by verifying its structural and dynamic behavior through static and dynamic analysis. The server device 100 evaluates the requirements definition document (design document) and determines whether the business rules are likely to be followed, taking the context into consideration.

[0047] The three main functions in this embodiment are as follows. Further details will be provided later.

[0048] (1) Multilayer schema verification The server device 100 sequentially verifies the AI ​​agent's specifications (agent specifications) at the business layer (operational consistency) and the implementation layer (technical consistency) to determine any constraint violations.

[0049] (2) DSL static analysis The server device 100 generates a DSL from the verified agent specifications and performs static analysis of the DSL using an analysis procedure that detects unreachable nodes, circularity, undefined tools, type inconsistencies, inconsistent conditional branches, missing conditional branches, etc., using a static analyzer.

[0050] (3) Automatic recovery loop The server device 100 has an autonomous repair function that compares the sandbox execution trace with the expected specifications and performs regeneration (re-prompting) or partial patching (application of partial patches) using LLM depending on the difference or error between the sandbox execution trace and the expected specifications.

[0051] [3-1. Architectural Configuration of the DSL Static Verification Platform] Referring to Figure 3, the architectural configuration of the DSL static verification platform according to this embodiment will be described. Figure 3 is an explanatory diagram showing an overview of the architectural configuration of the DSL static verification platform according to this embodiment.

[0052] The architectural configuration of the DSL static verification platform according to the embodiment is basically the same as the architectural configuration of the audit rule-driven dynamic routing agent platform shown in Figure 1. However, the audit rule-driven dynamic routing agent platform is merely an example. In practice, the DSL static verification platform according to the embodiment may be an independent platform separate from the audit rule-driven dynamic routing agent platform, or it may be part of another platform (it may be included in and applied to the architectural configuration of another platform). Furthermore, the DSL static verification platform according to the embodiment may be a platform preceding or following the audit rule-driven dynamic routing agent platform.

[0053] As shown in Figure 3, the DSL static verification platform according to the embodiment includes an audit rule engine 101. The topology manager 102, AI workflow 103, auditor 104, trace logger 105, object storage 106, and operation UI 107 shown in Figure 1 are not shown or described here. In practice, the DSL static verification platform according to the embodiment may be a combination of the audit rule engine 101, topology manager 102, AI workflow 103, auditor 104, trace logger 105, object storage 106, and operation UI 107.

[0054] The audit rule engine 101 includes a specification management layer 101a, a rule verification layer 101b, a static analysis layer 101c, a verification and correction layer 101d, and an artifact store 101e.

[0055] The specification management layer 101a functions as an input / output interface for LLM generation specifications (JSON / YAML) that define the AI ​​agent specifications (agent specifications). The specification management layer 101a accepts LLM generation specifications as input, manages them, and outputs LLM generation specifications to the subsequent rule verification layer 101b. For example, the specification management layer 101a receives and manages the version of the rule DSL in which the agent specifications are defined.

[0056] The rule validation layer 101b functions as a schema validator. A validator is a function (tool or software) that validates the accuracy, consistency, validity, and effectiveness of data. A schema validator, for example, verifies whether JSON data conforms to the JSON schema. Validation with a schema validator takes place before looking at the program, that is, at the stage of evaluating whether the requirements definition and its rules match. The rule validation layer 101b includes a business layer (Layer 1) that performs business NG checks and validates business rules based on the LLM generation specification, and an implementation layer (Layer 2) that performs implementation mischecks and validates implementation rules. Business rules include required steps, permission constraints, etc. Implementation rules include DSL structure, types, field constraints, etc. For example, the rule validation layer 101b performs two-stage validation in Layer 1 and Layer 2, validating business rules in Layer 1 and implementation rules in Layer 2. Furthermore, if the rule validation layer 101b finds a problem as a result of the validation (NG), it performs regeneration (re-prompting) or partial patching using LLM. Thus, the rule validation layer 101b uses a multi-layer schema of the business layer and implementation layer to realize a pipeline configuration and sequence for step-by-step validation of the agent specification. Note that two-stage validation is just one example. In practice, three or more stages of validation may be performed.

[0057] The static analysis layer 101c functions as a "DSL compiler" + "static analyzer". The static analysis layer 101c generates the LangGraph DSL and performs topology consistency checks (circularity, unreferenced elements, etc.). The LangGraph DSL is the DSL file for the AI ​​agent's workflow. For example, the static analysis layer 101c performs a static analysis on the LangGraph DSL to check the topology consistency, detecting unreachable nodes, circularity, unreferenced elements, undefined tools, type mismatches, inconsistent conditional branches, missing conditional branches, etc., and verifies the structure. Furthermore, if problems are found as a result of the analysis and verification (if NG), the static analysis layer 101c performs regeneration (re-prompting) or partial patching using LLM.

[0058] The verification and correction layer 101d functions as a "test executor" + "recovery loop engine". The verification and correction layer 101d compares the execution results of the test run in the sandbox environment with the expected specifications, and automatically corrects any differences or errors found in the comparison. The sandbox environment is a secure virtual environment completely isolated from the server device 100 and network N. For example, the verification and correction layer 101d compares the sandbox execution trace (execution results in the sandbox environment) with the expected specifications and performs an automatic recovery loop that prompts / applies patches to the LLM depending on the differences or errors between the sandbox execution trace and the expected specifications. In other words, if there is a problem (NG) as a result of the comparison, the verification and correction layer 101d performs regeneration (re-prompting) or partial patching by the LLM.

[0059] Artifact store 101e stores "trusted templates" that have passed all validations. For example, artifact store 101e stores LLM generation specifications and traces that have passed all validations as artifacts. In this way, artifact store 101e stores validation and recovery results as metadata and implements a learning build method (learning reuse) that prioritizes the reuse of successful patterns during subsequent generation.

[0060] Furthermore, the three NG routes in the DSL static verification platform architecture shown in Figure 3 are cases that deviate from the system's requirements and require entirely manual intervention (engineer intervention). When an NG occurs, server device 100 provides the human with the context of the error or issue. Important information to provide to the human when an NG occurs includes the branching rule, the reasoning behind the NG, and proposed improvements. Moreover, at this NG stage, the focus shifts from fixing the implementation to proposing changes to how the "rules" themselves, such as business rules and implementation rules, are created.

[0061] [3-2. Overview of the processing flow of the DSL static verification platform] Referring to Figure 4, an overview of the processing flow of the DSL static verification platform according to the embodiment will be described. Figure 4 is an explanatory diagram showing an overview of the processing flow of the DSL static verification platform according to the embodiment.

[0062] For example, as shown in Figure 4, the specification management layer 101a of the server device 100 accepts the input of the LLM generation specification (JSON / YAML) (step S11).

[0063] Next, the rule verification layer 101b of the server device 100 verifies the business rules at layer 1 (step S12).

[0064] Next, the rule verification layer 101b of the server device 100 verifies the implemented rules at layer 2 (step S13).

[0065] Next, the static analysis layer 101c of the server device 100 generates a LangGraph DSL and performs a static analysis on the LangGraph DSL to check the topology consistency, detecting unreachable nodes, circularities, unreferenced elements, undefined tools, inconsistent conditional branches, missing conditional branches, etc., and confirms the structure (step S14).

[0066] Next, the verification and correction layer 101d of the server device 100 performs a test execution in a sandbox environment (step S15).

[0067] Next, the verification and correction layer 101d of the server device 100 compares the sandbox execution trace with the expected specifications (step S16).

[0068] Next, the verification and correction layer 101d of the server device 100 performs an automatic recovery loop that prompts / applies patches to the LLM again depending on the difference or error between the sandbox execution trace and the expected specifications, and automatically corrects the issue (step S17).

[0069] Next, the artifact store 101e of the server device 100 saves the LLM generation specification and trace that have passed all verifications as artifacts (step S18).

[0070] [3-3. Tasks and PoCs that differentiate from existing technologies] The following describes the differences between the DSL static verification platform according to the embodiment and existing technologies, as well as the Proof of Concept (PoC).

[0071] (1) Phase 1: Design and Foundation Regarding the detailed design of the multi-layer schema, we will define the distinction between business constraints (operational rules) and implementation constraints (implementation rules). Regarding the DSL static analysis engine, we will implement a circularity / unreachability detection function based on graph theory.

[0072] (2) Phase 2: Implementation and Operation Regarding sandbox matching, we will prepare the execution environment and implement the trace comparison logic. Regarding recovery strategies, we will prepare re-prompt templates for each error type. Regarding operational flows, we will integrate with the artifact store and formulate production application criteria.

[0073] [4. Automatic Guardrail Insertion Based on Policy Ledger] In this embodiment, the server device 100 aggregates PII (Personally Identifiable Information), regulations, and internal rules into a "policy ledger" and automatically inserts safety check nodes as "guardrails" into the AI ​​agent's (hereinafter referred to as "agent") processing flow (for example, LangGraph DSL). In other words, the safety check nodes function as guardrails that restrict / correct the agent's processing flow to prevent it from violating policies (PII, regulations, and internal rules).

[0074] Conventional technologies involve frequent and distributed updates, and while PII regulations change frequently, the reflection of these changes to each agent is manual, resulting in a high risk of update omissions. In other words, in the application mechanism, developers manually add prompts and hooks, and there is no automatic synchronization with the ledger. Therefore, in this embodiment, the ledger is centrally managed, and "targets" and "rules" are automatically determined from the JSON / YAML ledger. In this embodiment, automatic guardrail injection is performed, the ledger is interpreted, and nodes / edges are automatically inserted into the DSL. For example, automatic DSL insertion is performed, and masking and AML nodes are directly injected into the topology.

[0075] Furthermore, in conventional technologies, pre-execution verification is limited to inserting template statements, making topology-level conformance verification difficult. Therefore, in this embodiment, build pipeline integration is achieved to verify structural conformance after DSL update before execution.

[0076] Furthermore, with conventional technologies, the history of agents and policies is not linked in version control, making it difficult to grasp the scope of impact. In other words, version control is impossible, and it is not possible to track "which policy was applied at what point in the past." Also, there are management limits, and as the number of agents increases, individually implemented guardrails become unmanageable. Therefore, in this embodiment, complete traceability is achieved, and automatic rebuilding and ID audit trail saving are performed when the ledger is updated. In other words, audit trails are realized, a complete record of "when and with which policy ID it was built" is made, and audit response is expedited.

[0077] Server device 100 automatically converts business requirements and internal rules into AI agents and automatically adds and generates guardrail AI agents that make decisions about the entire system. This reduces the effort and risk of missing updates when it comes to frequently changing rules such as internal regulations and the handling of personal information, which would otherwise require manual reflection.

[0078] Server device 100 automatically determines agent-specific rules from internal regulations created by humans and automatically inserts the necessary nodes (agents) and edges to update the processing flow. Server device 100 then verifies whether the updated processing flow operates as expected and leaves logs useful for version control. For example, server device 100 determines agent specifications from internal regulations (in YAML format or documents convertible to LLM such as PDF), writes and implements programs for guardrail nodes and edges, operates them, and leaves logs. This realizes an architecture that automatically implements security through the automatic insertion of guardrail nodes and edges, automatic pipeline building, verification, and log retention. Furthermore, security can be maintained by automatically inserting guardrails such as personal information masking nodes (PII masking nodes).

[0079] Furthermore, as the number of agents increases, it has become difficult to track which policies are applied and to manually configure implementation guardrails. This problem will be solved by creating a system that automatically determines agent-specific rules from internal regulations and automatically creates and inserts "protective implementations" such as masking. This system will automate only the addition of nodes and their associated edges (arrows), while utilizing existing human-created elements for the rest, thus ensuring ease of recording change history.

[0080] The three main functions in this embodiment are as follows. Further details will be provided later.

[0081] (1) Ledger interpretation engine The server device 100 extracts applicable rules (target agent, required guardrail type) from the JSON / YAML policy ledger and determines the application strategy.

[0082] (2) Automatic injection The server device 100 automatically inserts guardrails as nodes / edges on the LangGraph DSL based on the determined application strategy, updating the processing flow while maintaining dependencies.

[0083] (3) Conformity verification + evidence The server device 100 verifies the presence or absence of required nodes and prohibited paths in the injected DSL, saves the verification results and version ID as evidence, and persists them.

[0084] [4-1. Architectural Configuration of the Automatic Guardrail Insertion Base] Referring to Figure 5, the architectural configuration of the guardrail automatic insertion base according to the embodiment will be described. Figure 5 is an explanatory diagram showing an overview of the architectural configuration of the guardrail automatic insertion base according to the embodiment.

[0085] The architectural configuration of the guardrail automatic insertion base according to the embodiment is basically the same as the architectural configuration of the audit rule-driven dynamic wiring agent base shown in Figure 1. However, the audit rule-driven dynamic wiring agent base is merely an example. In practice, the guardrail automatic insertion base according to the embodiment may be an independent base separate from the audit rule-driven dynamic wiring agent base, or it may be part of another base (it may be included in and applied to the architectural configuration of another base). Furthermore, the guardrail automatic insertion base according to the embodiment may be a base preceding or following the audit rule-driven dynamic wiring agent base.

[0086] As shown in Figure 5, the automatic guardrail insertion platform according to the embodiment includes a topology manager 102. The audit rule engine 101, AI workflow 103, auditor 104, trace logger 105, object storage 106, and operation UI 107 shown in Figure 1 are not shown or described here. In practice, the automatic guardrail insertion platform according to the embodiment may be a combination of the topology manager 102 and the AI ​​workflow 103, or a combination of the topology manager 102, AI workflow 103, auditor 104, trace logger 105, object storage 106, and operation UI 107.

[0087] The topology manager 102 includes a policy loading layer 102a, an apply rule generation layer 102b, a guardrail insertion layer 102c, a workflow validation layer 102d, and an audit trail store 102e.

[0088] The policy loading layer 102a functions as a policy loader. It reads a policy ledger (JSON / YAML) containing one or more policies related to personal information, regulations, and internal rules, and converts it into a machine-readable internal model. Furthermore, the policy loading layer 102a has the function of receiving, collecting, or accessing input of one or more policies related to personal information, regulations, and internal rules via the network N, sequentially reading one or more policies, and aggregating them into a policy ledger (JSON / YAML). The policy loading layer 102a can also read an aggregated (existing) policy ledger (JSON / YAML) and convert it into a machine-readable internal model. Additionally, the policy loading layer 102a may be configured to automatically read the updated policy ledger when it is updated.

[0089] The application rule generation layer 102b functions as a rule interpreter. The application rule generation layer 102b receives the specifications of the AI ​​agent (agent specifications), matches the agent specifications with the policies in the policy ledger, and generates (or determines and extracts) application rules (such as PII mandatory). For example, the application rule generation layer 102b receives the specifications of the AI ​​agent for guardrails and automatically generates guardrail application rules for the agent specifications from the policy ledger.

[0090] The guardrail insertion layer 102c functions as a guardrail injector. The guardrail insertion layer 102c receives the LangGraph DSL and inserts filter / inspection nodes as guardrails into the LangGraph DSL, performing rewiring. For example, the guardrail insertion layer 102c automatically and physically injects guardrails as nodes / edges into the LangGraph DSL from the policy ledger.

[0091] The workflow validation layer 102d functions as a LangGraph generator and validator. It generates the final LangGraph DSL and checks for policy compliance (whether it conforms to the policy). For example, the workflow validation layer 102d validates the policy compliance of the injected DSL based on the required nodes and prohibited paths defined in the policy ledger, and automatically fails the build if it does not comply.

[0092] The trail store 102e stores the applied policy ID and DSL hash as evidence. For example, the trail store 102e stores check results, applied policy IDs, DSL versions, etc., for later review. The trail store 102e also visualizes the application status, exports policy application results as metadata, and makes it possible to display "which agent is protected by which policy" on an operational dashboard displayed on an external display or operator terminal device 10.

[0093] [4-2. Overview of the processing flow of the automatic guardrail insertion base] Referring to Figure 6, an overview of the processing flow of the automatic guardrail insertion platform according to the embodiment will be described. Figure 6 is an explanatory diagram showing an overview of the processing flow of the automatic guardrail insertion platform according to the embodiment.

[0094] For example, as shown in Figure 6, the policy reading layer 102a of the server device 100 reads a policy ledger (JSON / YAML) that aggregates one or more policies concerning personal information, regulations, and internal rules, and converts it into an internal model with a machine-readable structure (step S21).

[0095] Next, the application rule generation layer 102b of the server device 100 receives the AI ​​agent specifications (agent specifications) (step S22).

[0096] Next, the application rule generation layer 102b of the server device 100 matches the AI ​​agent specifications (agent specifications) with the policy and generates application rules (step S23).

[0097] Next, the guardrail insertion layer 102c of the server device 100 receives the LangGraph DSL, inserts filter / inspection nodes as guardrails into the LangGraph DSL, and performs rewiring (step S24).

[0098] Next, the workflow validation layer 102d of the server device 100 generates the final LangGraph DSL (final DSL) and validates its policy compliance (step S25).

[0099] Next, the workflow verification layer 102d of the server device 100 automatically fails the build and issues a warning (alert) if the policy compliance is not met (violation) (step S26).

[0100] Next, the workflow verification layer 102d of the server device 100, if it finds that the policy compliance is met, stores the applied policy ID and DSL hash as evidence in the evidence store 102e and persists them (step S27).

[0101] [4-3. Tasks and PoCs that differentiate from existing technologies] The following describes the differences between the guardrail automatic insertion base according to the embodiment and existing technologies, as well as the proof of concept (PoC).

[0102] (1) Design and implementation phase Task 1 involves designing the policy ledger schema. For example, defining the structure for application conditions, required nodes, and prohibited paths. Task 2 involves implementing the guardrail injector. For example, developing logic to rewrite the topology without side effects. Task 3 involves implementing compliance checks. For example, designing build failure conditions and error recovery flows.

[0103] (2) Operation and Verification Phase Task 4 involves operating an automated rebuild pipeline. For example, this includes implementing CI / CD integration based on ledger update detection. Task 5 involves conducting an internal Proof of Concept (PoC) and review. For example, this involves collaborating with the audit and security departments to refine the rule set to be robust enough for actual operation.

[0104] [5. Example of Server Device Configuration] Next, the configuration of the server device 100 according to the embodiment will be described using Figure 7. Figure 7 is a diagram showing an example of the configuration of the server device 100 according to the embodiment. As shown in Figure 7, the server device 100 includes a communication unit 110, a storage unit 120, and a control unit 130.

[0105] (Communications Department 110) The communication unit 110 is implemented, for example, by a NIC (Network Interface Card). The communication unit 110 is also connected to the network N by wired or wireless connection.

[0106] (Storage unit 120) The storage unit 120 is implemented by, for example, semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or storage devices such as HDDs, SSDs, and optical discs. For example, the storage unit 120 stores information transmitted and received via the communication unit 110, and information processed by the control unit 130. The storage unit 120 may also store user U's attribute information and history information (log data) along with identification information (user ID, etc.) indicating user U.

[0107] (Control unit 130) The control unit 130 is a controller, and is realized by executing various programs (corresponding to an example of an information processing program) stored in the internal storage device of the server device 100 using a storage area such as RAM as a working area, for example, by a CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), NPU (Neural network Processing Unit), ASIC (Application Specific Integrated Circuit), or FPGA (Field Programmable Gate Array).

[0108] In the example shown in Figure 7, the control unit 130 includes an acquisition unit 131, an evaluation unit 132, an output management unit 133, an aggregation unit 134, a generation unit 135, an insertion unit 136, a verification unit 137, and an output unit 138. Each block constituting the control unit 130 (acquisition unit 131, evaluation unit 132, output management unit 133, aggregation unit 134, generation unit 135, insertion unit 136, verification unit 137, output unit 138) is a functional block that represents the function of the control unit 130. These functional blocks may be software blocks or hardware blocks. For example, each functional block may be a single software module implemented in software (including microprograms), or a single circuit block on a semiconductor chip (die). Of course, each functional block may also be a single processor or a single integrated circuit. The control unit 130 may be composed of functional units different from the above-mentioned functional blocks. In other words, the configuration method of the functional blocks is arbitrary.

[0109] (Acquisition part 131) The acquisition unit 131 acquires the workflow rules (audit rule DSL) of the AI ​​agent entered by a user U (user), such as an operator. For example, the acquisition unit 131 acquires the audit rule DSL created by the user U from the user U's terminal device 10 via the communication unit 110. In practice, the acquisition unit 131 may acquire the audit rule DSL not only from the user U's terminal device 10, but also from other server devices 100, online storage, or the cloud via the communication unit 110. The acquisition unit 131 then stores the audit rule DSL in the storage unit 120.

[0110] Furthermore, the acquisition unit 131 may acquire user information about user U via the communication unit 110. For example, the acquisition unit 131 acquires identification information (such as user ID), location information of user U, attribute information of user U, etc., from user U's terminal device 10. The acquisition unit 131 then stores the user information in the storage unit 120.

[0111] Furthermore, the acquisition unit 131 may acquire AI agents from other server devices 100 or the cloud via the communication unit 110. For example, the acquisition unit 131 may acquire machine learning models from other server devices 100 or the cloud via the communication unit 110.

[0112] Furthermore, the acquisition unit 131 acquires an agent specification (LLM generation specification) that defines the requirements for an AI agent to perform a predetermined process, via the communication unit 110. In this case, the acquisition unit 131 corresponds to the specification management layer 101a. That is, the acquisition unit 131 may be one of the functions of the audit rule engine 101 or a part of the audit rule engine 101. Alternatively, the acquisition unit 131 corresponds to the application rule generation layer 102b. That is, the acquisition unit 131 may be one of the functions of the topology manager 102 or a part of the topology manager 102.

[0113] Furthermore, the acquisition unit 131 acquires one or more policies concerning personal information, regulations, and internal rules via the communication unit 110. In this case, the acquisition unit 131 corresponds to the policy reading layer 102a. That is, the acquisition unit 131 may be one of the functions of the topology manager 102 or a part of the topology manager 102.

[0114] (Evaluation Section 132) The evaluation unit 132 evaluates the consistency of the agent specification with respect to predetermined rules regarding predetermined processing. The evaluation unit 132 corresponds to the rule verification layer 101b, the static analysis layer 101c, and the confirmation and correction layer 101d. In other words, the evaluation unit 132 may be one of the functions of the audit rule engine 101 or a part of the audit rule engine 101.

[0115] For example, the evaluation unit 132 uses a multi-layer schema of business layer and implementation layer to progressively verify the business consistency and technical consistency of the agent specification and determine constraint violations. In this process, the evaluation unit 132 first verifies the business rules at the business layer and then verifies the implementation rules at the implementation layer. In other words, the evaluation unit 132 mechanically checks the agent specification in three stages: business rules, technical implementation, and execution results.

[0116] Furthermore, the evaluation unit 132 generates a DSL from the verified agent specifications, performs static analysis of the DSL using a static analyzer, and detects unreachable nodes, cycles, undefined tools, and inconsistencies. The evaluation unit 132 also has an autonomous repair function that compares the execution results in the sandbox environment with the expected agent specifications and performs regeneration or partial patching using LLM depending on the differences or errors.

[0117] (Delivery Management Department 133) The deliverable management unit 133 saves the evaluation content as a deliverable. The deliverable management unit 133 corresponds to the deliverable store 101e. In other words, the evaluation unit 132 may be one of the functions of the audit rule engine 101 or a part of the audit rule engine 101.

[0118] For example, the deliverable management unit 133 saves the agent specification that has passed all verifications and the execution trace in the sandbox environment as deliverables. In addition, the deliverable management unit 133 saves the verification and recovery results as metadata and implements a learning build method that prioritizes the reuse of successful patterns in subsequent generation.

[0119] (Aggregation section 134) The aggregation unit 134 aggregates one or more acquired policies into a policy ledger. The aggregation unit 134 also manages the aggregated policy ledger. Furthermore, when a new policy is added (acquired), the aggregation unit 134 may add / insert it into the existing (aggregated) policy ledger and store it. The aggregation unit 134 corresponds to the policy reading layer 102a. In other words, the aggregation unit 134 may be one of the functions of the topology manager 102 or a part of the topology manager 102.

[0120] (Generation unit 135) The generation unit 135 generates application rules from a policy ledger that aggregates policies for using predetermined information. For example, the generation unit 135 generates application rules from a policy ledger that aggregates one or more policies regarding personal information, regulations, and internal company rules. At this time, the generation unit 135 automatically generates guardrail application rules for agent specifications from the policy ledger. The generation unit 135 also generates application rules by matching agent specifications with the policy ledger. Furthermore, the generation unit 135 extracts target agents and required guardrail types as application rules from the JSON / YAML policy ledger to determine the application strategy. The generation unit 135 corresponds to the application rule generation layer 102b. That is, the generation unit 135 may be one of the functions of the topology manager 102 or a part of the topology manager 102.

[0121] (Insertion section 136) The insertion unit 136 automatically inserts inspection filters or nodes as guardrails into the AI ​​agent's workflow based on application rules. For example, the insertion unit 136 automatically inserts nodes and edges into the AI ​​agent's workflow based on guardrail application rules. The insertion unit 136 also automatically inserts masking nodes or safety check nodes as guardrails into the AI ​​agent's workflow based on a determined application strategy. Furthermore, the insertion unit 136 automatically inserts guardrails as nodes and edges on the LangGraph DSL based on a determined application strategy, updating the AI ​​agent's workflow while maintaining dependencies. The insertion unit 136 corresponds to the guardrail insertion layer 102c. That is, the insertion unit 136 may be one of the functions of the topology manager 102 or a part of the topology manager 102.

[0122] (Verification Section 137) The verification unit 137 performs conformity verification on the workflow with the guardrail inserted (the AI ​​agent's workflow after the guardrail insertion) and saves the verification results as evidence. Furthermore, when the policy ledger is updated, the verification unit 137 automatically verifies the policy conformity of the workflow with the guardrail inserted based on the required nodes and prohibited paths defined in the policy ledger. If it conforms, it automatically rebuilds the workflow, saves the verification results and version ID as evidence, and persists them. The verification unit 137 also verifies the structural conformity of the workflow with the guardrail inserted before execution. The verification unit 137 corresponds to the workflow verification layer 102d. That is, the verification unit 137 may be one of the functions of the topology manager 102 or a part of the topology manager 102.

[0123] (Output section 138) The output unit 138 outputs the deliverables. In this case, the output unit 138 corresponds to the deliverable store 101e. That is, the output unit 138 may be one of the functions of the audit rule engine 101 or a part of the audit rule engine 101. For example, the output unit 138 outputs a wiring policy based on the deliverables.

[0124] Furthermore, the output unit 138 outputs the evidence. In this case, the output unit 138 corresponds to the evidence store 102e. That is, the output unit 138 may be one of the functions of the topology manager 102 or a part of the topology manager 102.

[0125] [6. Processing Procedure] Next, the processing procedure by the server device 100 according to the embodiment will be described using Figures 8 and 9. Figure 8 is a flowchart showing the processing procedure of the DSL static verification platform according to the embodiment. Figure 9 is a flowchart showing the processing procedure of the guardrail automatic insertion platform according to the embodiment. The processing procedure shown below is repeatedly executed by the control unit 130 of the server device 100.

[0126] [6-1. Processing Procedure for the DSL Static Verification Platform] For example, as shown in Figure 8, the acquisition unit 131 of the server device 100 accepts input of an LLM generation specification (JSON / YAML) that defines the AI ​​agent specifications (agent specifications), stores it in the storage unit 120, and performs version control (step S101).

[0127] Next, the evaluation unit 132 of the server device 100 divides the process into a business layer (Layer 1) that performs business NG checks and verifies business rules, and an implementation layer (Layer 2) that performs implementation error checks and verifies implementation rules. A two-stage verification is performed using Layer 1 and Layer 2, where business rules are verified in Layer 1 and implementation rules are verified in Layer 2 (Step S102).

[0128] Next, the evaluation unit 132 of the server device 100 determines, based on the verification results, whether or not there were any violations in either Layer 1 or Layer 2 (step S103).

[0129] If no violations are found (Step S103: Yes), the evaluation unit 132 of the server device 100 generates a LangGraph DSL and performs a topology consistency check. The LangGraph DSL is subjected to a static analysis to check the topology consistency, detecting unreachable nodes, circularities, unreferenced elements, undefined tools, type mismatches, inconsistent conditional branches, missing conditional branches, etc., and the structure is confirmed (Step S104).

[0130] Next, the evaluation unit 132 of the server device 100 determines whether or not there were any violations based on the results of the analysis and verification (step S105).

[0131] If no violations are found (Step S105: Yes), the evaluation unit 132 of the server device 100 compares the results of the test execution in the sandbox environment (sandbox execution trace) with the expected specifications (Step S106).

[0132] Next, the evaluation unit 132 of the server device 100 determines whether or not there are any differences or errors as a result of the comparison (step S107).

[0133] If there are no differences or errors (Step S107: Yes), the evaluation unit 132 of the server device 100 saves the LLM generation specification and trace that have passed all verifications as deliverables to the deliverable management unit 133 (Step S108). At this time, the output unit 138 of the server device 100 may output the deliverables.

[0134] If there are violations, differences, or errors (step S103: No, step S105: No, or step S107: No), the evaluation unit 132 of the server device 100 automatically corrects (recovers) the error by regenerating (re-prompting) or partially patching using LLM and then re-executes (step S109).

[0135] [6-2. Processing Procedure for Automatic Guardrail Insertion Base] For example, as shown in Figure 9, the aggregation unit 134 of the server device 100 aggregates one or more policies concerning personal information, regulations, and internal rules into a policy ledger (JSON / YAML) (step S201). The aggregation unit 134 may also aggregate policies into the policy ledger when it receives policy input from an external source.

[0136] Next, the aggregation unit 134 of the server device 100 determines whether or not the policy ledger has been updated (step S202). Note that if the aggregation unit 134 generates the policy ledger for the first time, it determines that the policy ledger has been updated because no policy ledger existed before that. The aggregation unit 134 may also manage the policy ledger and detect updates when the policy ledger is updated, or it may periodically check for updates to the policy ledger. If the policy ledger has not been updated (step S202: No), the aggregation unit 134 maintains the current state and waits for the policy ledger to be updated (returns to step S201).

[0137] If the policy ledger is updated (Step S202: Yes), the generation unit 135 of the server device 100 receives the AI ​​agent specifications (agent specifications), matches the agent specifications with the policies in the policy ledger, and automatically generates guardrail application rules (Step S203).

[0138] Next, the insertion unit 136 of the server device 100 receives the LangGraph DSL, which is the DSL file of the AI ​​agent's workflow, and, in accordance with the guardrail application rules, automatically inserts masking nodes or safety check nodes / edges as guardrails into the LangGraph DSL, performs rewiring, and updates the AI ​​agent's workflow while maintaining dependencies (step S204).

[0139] Next, the verification unit 137 of the server device 100 generates a final LangGraph DSL (final DSL) that shows the workflow with the guardrails inserted, and before execution, performs a compliance verification regarding policy compliance (whether it conforms to the policy) based on the required nodes and prohibited paths defined in the policy ledger (step S205).

[0140] If the verification results in a non-conformity (step S205: No), the verification unit 137 of the server device 100 automatically fails the build (step S206). At this time, the verification unit 137 may record the automatic build failure as a log.

[0141] Next, the output unit 138 of the server device 100 outputs a warning (alert) regarding the automatic build failure to a terminal device 10 for a developer or operator, or to an external display / storage (step S207).

[0142] If the verification is successful (Step S205: Yes), the verification unit 137 of the server device 100 automatically performs a build and saves the applicable policy ID and DSL hash as evidence in the evidence store 102e so that they can be checked later (Step S208).

[0143] Next, the output unit 138 of the server device 100 outputs evidence to the terminal device 10 of the developer or operator, or to an external display / storage, in response to a request from the terminal device 10 of the developer or operator, or automatically according to the settings, etc. (step S209).

[0144] [7. Variations] The terminal device 10 and server device 100 described above may be implemented in various other forms besides those of the embodiment described above. Therefore, the following describes modifications of the embodiment.

[0145] In the above embodiment, some or all of the processing performed by the server device 100 may actually be performed by the terminal device 10 (or an application running on the terminal device 10). For example, the terminal device 10 may perform all processing in a standalone or on-device manner. In this case, the terminal device 10 is assumed to have the same functionality as the server device 100 in the above embodiment. Furthermore, in the above embodiment, since the terminal device 10 is in cooperation with the server device 100, from the perspective of user U, it appears as if the processing of the server device 100 is also being performed by the terminal device 10. In other words, from another perspective, the terminal device 10 can be said to have the server device 100.

[0146] Furthermore, in the above embodiment, the server device 100 may be a container server that constructs an execution environment (container) for virtually running applications on a host computer. For example, the server device 100 may construct a container for executing various functions of user U's terminal device 10.

[0147] Furthermore, in the above embodiment, if the terminal device 10 can perform the role of a server device 100 due to its enhanced performance and functionality, the terminal device 10 may be used as a server device 100. In this case, the terminal device 10 may acquire the functionality of a server device 100 by coordinating with an actual server device 100. This allows one user's terminal device 10 to function as a server device 100 for another user's terminal device 10.

[0148] Furthermore, in the above embodiment, the user U's terminal device 10 may build (generate, update) the model through on-device learning, or it may build the model through federated learning in cooperation with other terminal devices 10 or server devices 100.

[0149] Furthermore, in the above embodiment, the AI ​​agent may operate on the device (terminal side) of each user U's terminal device 10. The server device 100 may then audit the workflow (AI workflow) of the AI ​​agent operating on the device (terminal side) of each user U's terminal device 10.

[0150] Furthermore, in the above embodiment, the server device 100 aggregates PII, regulations, and internal rules into a policy ledger, but PII, regulations, and internal rules are merely examples and are not limited to these. In practice, the server device 100 may also aggregate policies other than "PII, regulations, and internal rules" into the policy ledger. In addition, the server device 100 may also aggregate wiring policies output from the audit rule engine 101 into the policy ledger.

[0151] Furthermore, in the above embodiment, if the contents of the policies aggregated in the policy ledger are contradictory (conflicting), the server device 100 may set a priority for each policy and adopt and apply the policy with the higher priority if there is a contradiction. Alternatively, the server device 100 may compare and evaluate the contents of all policies aggregated in the policy ledger, determine an appropriate and valid policy, and align the policies.

[0152] [8. Effects] [8-1. Effects of the Multilayer Schema & DSL Static Validation Pipeline] As described above, the information processing device (terminal device 10 and / or server device 100) according to the present invention is characterized by comprising: an acquisition unit 131 that acquires agent specifications defining the requirements of an AI agent that performs a predetermined process; an evaluation unit 132 that evaluates the consistency of the agent specifications with predetermined rules relating to the predetermined process; an output management unit 133 that stores the evaluation content as an output; and an output unit 138 that outputs the output.

[0153] The evaluation unit 132 uses a multi-layer schema of the business layer and implementation layer to progressively verify the business consistency and technical consistency of the agent specification and determine any constraint violations.

[0154] The evaluation unit 132 first verifies the business rules at the business layer and then the implementation rules at the implementation layer against the agent specifications.

[0155] The evaluation unit 132 mechanically checks the agent specifications in three stages: business rules, technical implementation, and execution results.

[0156] The evaluation unit 132 generates a DSL from the verified agent specifications, performs a static analysis of the DSL using a static analyzer, and detects unreachable nodes, circularity, undefined tools, and inconsistencies.

[0157] The evaluation unit 132 has an autonomous repair function that compares the execution results in the sandbox environment with the expected agent specifications and performs regeneration or partial patching using LLM depending on the differences or errors.

[0158] The deliverable management unit 133 saves the agent specifications that have passed all verifications and the execution trace in the sandbox environment as deliverables.

[0159] The deliverable management unit 133 saves verification and recovery results as metadata and implements a learning-based build method that prioritizes the reuse of successful patterns during subsequent generation.

[0160] Through any or a combination of the above-described processes, the information processing device according to the present invention can evaluate the consistency with the rules before implementation at the agent specification stage.

[0161] [8-2. Effects of Automatic Guardrail Insertion Based on Policy Ledger Application] As described above, the information processing device (terminal device 10 and / or server device 100) according to the present invention is characterized by comprising: a generation unit 135 that generates application rules from a policy ledger that aggregates policies for using predetermined information; an insertion unit 136 that automatically inserts inspection filters or nodes as guardrails into the workflow of the AI ​​agent based on the application rules; a verification unit 137 that performs conformity verification on the workflow into which the guardrails have been inserted and saves the verification results as evidence; and an output unit 138 that outputs the evidence.

[0162] The generation unit 135 generates applicable rules from a policy ledger that aggregates one or more policies concerning personal information, regulations, and internal company rules.

[0163] Furthermore, the information processing device according to the present application further comprises an acquisition unit 131 that acquires one or more policies relating to personal information, regulations, and internal company rules, and an aggregation unit 134 that aggregates the acquired one or more policies into a policy ledger.

[0164] Furthermore, the information processing device according to the present invention further includes an acquisition unit 131 that acquires agent specifications defining the requirements for an AI agent to perform a predetermined process. The generation unit 135 automatically generates guardrail application rules for the agent specifications from a policy ledger and automatically inserts nodes and edges into the AI ​​agent's workflow based on the guardrail application rules.

[0165] The acquisition unit 131 acquires agent specifications that define the requirements for an AI agent to perform a predetermined process. The generation unit 135 matches the agent specifications with the policy ledger to generate application rules.

[0166] The verification unit 137 verifies policy compliance for the workflow with the guardrail inserted based on the required nodes and prohibited paths defined in the policy ledger, and automatically fails the build if it does not comply.

[0167] The verification unit 137 verifies the presence or absence of required nodes and prohibited paths defined in the policy ledger for the workflow into which the guardrail has been inserted, and saves and persists the verification results and version ID as evidence.

[0168] The generation unit 135 extracts target agents and required guardrail types as application rules from the JSON / YAML policy ledger and determines the application strategy. The insertion unit 136 automatically inserts masking nodes or safety check nodes as guardrails into the AI ​​agent's workflow based on the determined application strategy.

[0169] The insertion unit 136 automatically inserts guardrails as nodes and edges on the LangGraph DSL based on the determined application strategy, updating the AI ​​agent's workflow while maintaining dependencies.

[0170] The verification unit 137 verifies the structural compatibility of the workflow with the guardrail inserted before execution.

[0171] When the policy ledger is updated, the verification unit 137 verifies the policy compliance of the workflow, which has automatically inserted guardrails, based on the required nodes and prohibited paths defined in the policy ledger, performs an automatic rebuild, and saves and persists the verification results and version ID as evidence.

[0172] By any or a combination of the above-described processes, the information processing device according to the present invention can automatically generate an AI agent for guardrails.

[0173] [9. Hardware Configuration] Furthermore, the terminal device 10 and server device 100 according to the above-described embodiment are realized by a computer 1000 having a configuration such as that shown in Figure 10. The following explanation will use the server device 100 as an example. Figure 10 shows an example of the hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and has a configuration in which an arithmetic unit 1030, a primary storage device 1040, a secondary storage device 1050, an output interface 1060, an input interface 1070, and a network interface 1080 are connected by a bus 1090.

[0174] The arithmetic unit 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, as well as programs read from the input device 1020, and performs various processes. The arithmetic unit 1030 can be implemented using, for example, a CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), NPU (Neural Network Processing Unit), ASIC (Application Specific Integrated Circuit), or FPGA (Field Programmable Gate Array).

[0175] The primary storage device 1040 is a memory device, such as RAM (Random Access Memory), that temporarily stores data used by the arithmetic unit 1030 for various calculations. The secondary storage device 1050 is a storage device where data used by the arithmetic unit 1030 for various calculations and various databases are registered, and can be implemented using ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc. The secondary storage device 1050 may be internal storage or external storage. The secondary storage device 1050 may also be a removable storage medium such as USB (Universal Serial Bus) memory or SD (Secure Digital) memory card. The secondary storage device 1050 may also be cloud storage (online storage), NAS (Network Attached Storage), file server, etc.

[0176] The output I / F 1060 is an interface for transmitting information to be output to output devices 1010, such as displays, projectors, and printers, and is implemented using connectors of standards such as USB (Universal Serial Bus), DVI (Digital Visual Interface), and HDMI (High Definition Multimedia Interface). The input I / F 1070 is an interface for receiving information from various input devices 1020, such as mice, keyboards, keypads, buttons, and scanners, and is implemented using, for example, USB.

[0177] Furthermore, the output interface 1060 and input interface 1070 may be wirelessly connected to the output device 1010 and input device 1020, respectively. In other words, the output device 1010 and input device 1020 may be wireless devices.

[0178] Furthermore, the output device 1010 and the input device 1020 may be integrated as a touch panel. In this case, the output I / F 1060 and the input I / F 1070 may also be integrated as an input / output I / F.

[0179] The input device 1020 may also be a device that reads information from, for example, an optical recording medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0180] The network interface 1080 receives data from other devices via network N and sends it to the computing unit 1030, and also transmits data generated by the computing unit 1030 to other devices via network N.

[0181] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output interface 1060 and the input interface 1070. For example, the arithmetic unit 1030 loads a program from the input device 1020 or the secondary storage device 1050 onto the primary storage device 1040 and executes the loaded program.

[0182] For example, when computer 1000 functions as a server device 100, the arithmetic unit 1030 of computer 1000 realizes the functions of the control unit 130 by executing a program loaded onto the primary storage device 1040. Alternatively, the arithmetic unit 1030 of computer 1000 may load a program obtained from another device via the network interface 1080 onto the primary storage device 1040 and execute the loaded program. Furthermore, the arithmetic unit 1030 of computer 1000 may cooperate with other devices via the network interface 1080 and call and use program functions, data, etc., from other programs on other devices.

[0183] [10. Other] Although embodiments of the present invention have been described above, the present invention is not limited by the content of these embodiments. Furthermore, the aforementioned components include those that can be easily conceived by those skilled in the art, those that are substantially the same, and those that fall within the so-called equivalent range. Moreover, the aforementioned components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the embodiments described above.

[0184] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, specific names, and information including various data and parameters shown in the above document and drawings can be arbitrarily changed unless otherwise specified. For example, the various information shown in each figure is not limited to the information shown.

[0185] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0186] For example, the server device 100 described above may be implemented using multiple server computers, and the configuration can be flexibly changed, such as by calling external platforms via APIs (Application Programming Interfaces) or network computing depending on the function.

[0187] Furthermore, the embodiments and modifications described above can be combined as appropriate, provided that the processing content is not inconsistent.

[0188] Furthermore, the terms "section, module, unit" mentioned above can be replaced with "means" or "circuit," etc. For example, the acquisition unit can be replaced with acquisition means or acquisition circuit.

[0189] The functions of the elements disclosed herein may be implemented using circuits or processing circuits that include general-purpose processors, special-purpose processors, integrated circuits, ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays), conventional circuits, and / or combinations thereof, which are programmed using one or more programs stored in one or more memories, or otherwise configured to perform the disclosed functions. A processor is considered a processing circuit or circuit because it includes transistors and other circuits. A processor may be a programmed processor that executes programs stored in memory. In this disclosure, a circuit, unit, or means is hardware that performs the enumerated functions, or hardware programmed to perform the enumerated functions. Hardware may be any hardware disclosed herein that is programmed or configured to perform the enumerated functions. [Explanation of Symbols]

[0190] 1. Information Processing System 10 Terminal devices 100 Server Devices 101 Audit Rule Engine 101a Specification Management Layer 101b Rule Validation Layer 101c static analysis layer 101d Confirmation correction layer 101e Deliverable Store 102 Topology Manager 102a Policy reading layer 102b Application Rule Generation Layer 102c Guardrail Insertion Layer 102d Workflow Validation Layer 102e Evidence Store 103 AI Workflow 104 Auditors 105 Trace Logger 106 Object Storage 107 Operation UI 110 Communications Department 120 Storage section 130 Control Unit 131 Acquisition Department 132 Evaluation Department 133 Deliverables Management Department 134 Aggregation Section 135 Generation part 136 Insertion part 137 Verification Department 138 Output section

Claims

1. An acquisition unit that acquires agent specifications that define the requirements for an AI agent to perform a predetermined task, An evaluation unit that evaluates whether the agent specifications are consistent with the business rules and technical rules related to the processing of the predetermined tasks, The deliverables management department saves the evaluation results as deliverables, Output unit that outputs deliverables An information processing device characterized by comprising:

2. The evaluation unit uses a multi-layer schema of business layer and implementation layer to progressively verify business consistency and technical consistency against the agent specifications and determine constraint violations. The information processing apparatus according to feature 1.

3. The evaluation unit first verifies the business rules at the business layer and then verifies the implementation rules at the implementation layer for the agent specifications. The information processing apparatus according to feature 2.

4. The aforementioned evaluation unit mechanically checks the agent specifications in three stages: business rules, technical implementation, and execution results. The information processing apparatus according to feature 1.

5. The evaluation unit generates a DSL from the verified agent specifications, performs a static analysis of the DSL using a static analyzer, and detects unreachable nodes, circularities, undefined tools, and inconsistencies. The information processing apparatus according to feature 1.

6. The evaluation unit has an autonomous repair function that compares the execution results in the sandbox environment with the expected agent specifications and performs regeneration or partial patching using LLM depending on the differences or errors. The information processing apparatus according to feature 1.

7. The aforementioned deliverable management unit saves, as deliverables, the agent specifications that have passed all verifications and the traces of execution in the sandbox environment. The information processing apparatus according to feature 1.

8. The aforementioned deliverable management unit stores verification and recovery results as metadata and implements a learning build method that prioritizes the reuse of successful patterns during subsequent generation. The information processing apparatus according to feature 1.

9. An information processing method performed by an information processing device, The acquisition process involves obtaining agent specifications that define the requirements for an AI agent to perform a predetermined task, and An evaluation step to assess whether the agent specifications are consistent with the business rules and technical rules related to the processing of the predetermined tasks, The deliverable management process involves saving the evaluation results as deliverables, Output process for producing deliverables An information processing method characterized by including

10. A procedure for obtaining agent specifications that define the requirements for an AI agent to perform a predetermined task, An evaluation procedure for assessing whether the agent specifications are consistent with the business rules and technical rules related to the processing of the aforementioned specified tasks, A deliverable management procedure for saving evaluation results as deliverables, Output procedure for producing deliverables An information processing program characterized by causing a computer to execute it.

Images