Information processing device, information processing method, and program

JP7926815B1Active Publication Date: 2026-09-30SPECIAL MEDICO CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2026079329
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2026-05-11
Publication Date
2026-09-30
Estimated Expiration
2046-05-11

Smart Images

  • Figure 0007926815000001_ABST
    Figure 0007926815000001_ABST
Patent Text Reader

Abstract

This invention provides an information processing device, information processing method, and program that govern data on the backend system side, suppress unnecessary requests to the generating AI, and significantly reduce processing load and token charges. [Solution] An information processing device (200) configured to access a storage unit (300) that stores target data includes an event monitoring unit (210) that monitors whether a predefined specific event has occurred with respect to the target data and fires an event when the specific event occurs, and an AI execution control unit (220) that, on the condition that an event has been fired, extracts the target data that was the target of the firing, and calls the API of the generated AI model to send an analysis request.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to an information processing apparatus, an information processing method, and a program. [Background Art]

[0002] In recent years, information processing systems that monitor data accumulated in SaaS platforms and in-house business systems and support business progress management and anomaly detection have been widely used. In such systems, batch processing that periodically checks the state in a database and a monitoring mechanism using polling are generally used.

[0003] In addition, in recent years, generative AI technology capable of executing advanced inference tasks such as natural language processing has been developing rapidly. Along with this, attempts have been made to incorporate APIs of external generative AI models into business systems and cause AI to perform state monitoring, self-repair of errors, and the like.

[0004] For example, Patent Document 1 discloses a technology for monitoring a system to detect an error during execution of robotic process automation (RPA), providing information for dealing with the error to a cognitive AI layer, and attempting self-repair.

[0005] Here, when generative AI is used to perform data monitoring and analysis in a conventional system, it has been common that all data in the system, or all recently updated logs and all data, are collectively transmitted to the API of the generative AI through periodic batch processing or the like, and the generative AI is caused to evaluate state determination and the presence or absence of an anomaly. [Prior Art Document] [Patent Document]

[0006] [Patent Document 1] Japanese Unexamined Patent Publication No. 2025-97251 [Summary of Invention] [Problem to be Solved by Invention]

[0007] However, when using generational AI for continuous monitoring and automated processing in conventional system architectures such as Patent Document 1, there were significant challenges, including the waste of computing resources due to continuous polling monitoring and unconditional bulk transmission, as well as increased communication costs (token charges).

[0008] External generative AI model APIs generally use a pay-as-you-go system based on the amount of input and output data (number of tokens), and often have a limit on the number of requests per unit of time (rate limit). In conventional methods, where the system does not strictly control the state and instead periodically sends all or a large amount of data to the AI ​​to determine the presence or absence of anomalies and the current situation, repeated API requests are generated even for data whose state has not changed or for data that does not immediately require human intervention.

[0009] As a result, problems arose such as enormous API communication load and server resource consumption, unrealistically high business operating costs (token billing), and the easy reaching of API rate limits, causing the entire system to malfunction.

[0010] In view of the above circumstances, at least some embodiments of the present invention aim to provide an information processing device, an information processing method, and a program that can govern data on the backend system side to suppress unnecessary requests to the generating AI, thereby significantly reducing processing load and token charges. [Means for solving the problem]

[0011] Information processing devices according to at least some embodiments of the present invention are An information processing device configured to allow access to a storage unit that stores target data, An event monitoring unit monitors whether a predefined specific event has occurred with respect to the aforementioned target data, and triggers an event when such specific event occurs. The AI ​​execution control unit, which, upon the occurrence of the aforementioned event, extracts the target data that was the subject of the event, and calls the API of the generated AI model to send an analysis request, It is equipped with. [Effects of the Invention]

[0012] According to at least some embodiments of the present invention, the API of the generating AI is called only when a specific event occurs with respect to the target data and triggers an event. Compared to continuous polling for full data monitoring, this method can suppress unnecessary AI requests and significantly reduce the processing load and token charges of the information processing device. [Brief explanation of the drawing]

[0013] [Figure 1] A network configuration diagram showing an example of the overall configuration of an information processing system according to one embodiment. [Figure 2A] This is a block diagram showing the functional configuration of an information processing device according to one embodiment. [Figure 2B] This is a hardware configuration diagram of an information processing device according to one embodiment. [Figure 3] This is an Entity-Relationship (ER) diagram showing an example of the structure of a storage unit (database) according to one embodiment. [Figure 4] This is a conceptual diagram showing the data structure of the cache and differential recording layer within the storage unit, which are managed by the cache management unit according to one embodiment of this model. [Figure 5] This is a flowchart of the event monitoring and data extraction process by the event monitoring unit according to one embodiment. [Figure 6] This flowchart shows an example of job management processing by the AI ​​execution control unit according to one embodiment. [Figure 7] This flowchart shows the procedure for generating structured data (analysis requests) by an AI execution control unit according to one embodiment. [Figure 8]It is a flowchart illustrating the procedure of dynamic destination model sorting processing by a model routing unit according to an embodiment. [Figure 9] It is a flowchart illustrating the procedure of generating an analysis request using differential recalculation by an AI execution control unit according to an embodiment. [Figure 10] It is a diagram (ladder diagram) illustrating an authentication, authorization and response generation sequence between an information processing apparatus and a client apparatus according to an embodiment. [Figure 11] It is a fail-closed sequence diagram (ladder diagram) for an abnormal situation of a generative AI model according to an embodiment. [Figure 12] It is a diagram illustrating a specific example of role-by-role response data (in JSON format) generated by a response control unit according to an embodiment. [Figure 13] It is a conceptual diagram of screen control performed based on UI state information received from an information processing apparatus in a client apparatus according to an embodiment. [Figure 14] It is a diagram illustrating a specific example of the data structure of structured data (analysis request) generated by an AI execution control unit according to an embodiment. [Figure 15] It is a mapping diagram illustrating the correspondence between an instruction identifier (action_request) included in structured data according to an embodiment and specific instruction content (prompt template) selected based on the instruction identifier. DETAILED DESCRIPTION OF EMBODIMENTS

[0014] Hereinafter, several embodiments of the present invention will be described in detail with reference to the drawings. The same constituent elements are denoted by the same reference numerals, and overlapping descriptions are omitted. In addition, the blocks and sequences shown in each drawing do not necessarily limit the physical arrangement or strict processing order, and integration, distribution, or reordering can be appropriately performed without departing from the spirit of the present invention.

[0015] (Overall System Configuration) Figure 1 is a network configuration diagram showing an example of the overall configuration of an information processing system according to one embodiment.

[0016] In some embodiments, as shown in Figure 1, the information processing system includes an information processing device 200 configured to access a storage unit 300 that stores target data. The information processing system includes a client device 100 for viewing or manipulating the target case, an information processing device 200 (server) that controls the system, a storage unit 300 (database) for persisting the actual target data, and APIs (generating AI model group 400) of multiple generating AI models that provide advanced inference processing or have different processing loads. These are connected to each other via a network 500 so that they can communicate with one another.

[0017] In one embodiment, the information processing device 200 is configured as a backend server running on, for example, an asynchronous event-driven execution environment (e.g., Node.js®), and uses a relational database such as MySQL® or a non-relational database such as MongoDB® as the storage unit 300. The information processing device 200 receives requests from the client device 100 via the network 500 and performs event monitoring and AI execution control on the target data in the storage unit 300, as described later.

[0018] In some embodiments, the "target data" stored in the memory unit 300 may be structured around a "case" that includes medical and labor data such as interview records, stress check results, and follow-up status in this industrial physician system. The target data may also be health checkup result data received from external health checkup institutions, etc. Specifically, the target data may include numerical items of biodata (biometric measurement data) such as blood pressure, weight, BMI, liver function values ​​(AST, ALT, etc.), and lipids (LDL cholesterol, etc.), as well as text items such as findings. It may also be data that includes the format or content of "3 documents 6 information" (medical information provision form, discharge summary, health checkup result report, etc.) as defined by the Ministry of Health, Labour and Welfare. However, the specific content of the "target data" is not limited to this example. In other embodiments, the target data may be equipment operation logs or sensor data in a manufacturing plant, inventory and order data in e-commerce, or monitoring logs in financial transactions, etc.

[0019] In some embodiments, the information processing device 200 functions as a "governance platform" for safely and efficiently integrating generative AI models, which are expensive in terms of computing resources and communication costs, into business processes, regardless of the type of data. For example, this system can be fully utilized in the area of ​​standardizing health checkup data (e.g., format conversion and data matching).

[0020] The AI ​​model group 400 performs tasks such as summarizing text, classifying data, assessing risks, and generating next actions in response to analysis requests from the information processing device 200. In the embodiment shown in Figure 1, the generative AI model group 400 is composed of multiple models that differ in their capabilities and characteristics from one another. The multiple models that make up the generative AI model group 400 include, for example, a first generative AI model 410 that assumes a high degree of accountability and a second generative AI model 420 that is suitable for routine classification. As a concrete implementation example, the first generative AI model 410 is a high-performance model provided by platform A, and the second generative AI model 420 is a lightweight model provided by platform B, which is other than platform A. In this way, the cost-effectiveness of the entire system may be optimized by integrating and governing APIs from different platforms.

[0021] In other embodiments not shown, the generated AI model group 400 does not necessarily have to be an external cloud service. For example, the information processing device 200 may be a self-hosted (on-premises) local LLM operating within the same private network. In this case, the information processing device 200 is extremely effective in avoiding contention for limited computing resources (such as GPU memory) within the company's own server and in reducing power consumption.

[0022] Network 500 may be the internet, an intranet, a dedicated line, or a combination thereof. Communication between the information processing device 200 and the client device 100 may be protected by stateless authentication using the HTTPS protocol and JWT (JSON Web Token), as described later, and by adopting a configuration that does not maintain sessions on the server side, robust governance may be possible even for large-scale simultaneous access.

[0023] (Functional configuration of information processing equipment) Figure 2A is a block diagram showing the functional configuration of an information processing device 200 according to one embodiment. The information processing device 200 governs the entire lifecycle of target data, from "monitoring" to "analysis execution" and "responding to the client." In some embodiments, as shown in Figure 2A, the information processing device 200 includes an event monitoring unit 210, an AI execution control unit 220 (including a model routing unit 230 and a cache management unit 240), a response control unit 250, and a communication and authentication control unit 260.

[0024] In some embodiments, the event monitoring unit 210 monitors whether a predefined specific event has occurred with respect to the target data, and triggers an event if the specific event occurs.

[0025] In the embodiment shown in Figure 2A, the event monitoring unit 210 may be implemented as a periodic batch process executed in a backend environment such as Node.js, or as server-side processing during status updates. Specifically, the event monitoring unit 210 may query the business table in the storage unit 300 to detect specific events such as exceeding deadlines, continuing unconfirmed notifications, or exceeding thresholds for stress assessments. This allows for the precise identification of critical timings when AI resources are needed, enabling subsequent processing.

[0026] In some embodiments, the AI ​​execution control unit 220 extracts target data and sends an analysis request by calling the API of the generated AI model (generated AI model group 400) when an event is triggered.

[0027] The AI ​​execution control unit 220 not only relays data, but also controls the "density" and "content" of requests. For example, in the event of multiple events occurring simultaneously, it has a "job management function" that temporarily holds the extracted cases as jobs and sends requests sequentially or in small batches to avoid exceeding the rate limits of external APIs. Furthermore, as will be described later, it also handles the conversion of raw data into structured metadata rather than sending it as is.

[0028] In some embodiments, the AI ​​execution control unit 220 includes a model routing unit 230 for dynamically selecting the destination of an analysis request from among the APIs of multiple generating AI models (a group of generating AI models 400) based on the type of event or the importance of the target data. Specifically, the model routing unit 230 routes requests to select a low-cost, lightweight model for simple classification tasks and a high-performance model for tasks such as audit summaries that require a high level of accountability. This optimizes the overall system operating cost while maintaining accuracy.

[0029] In some embodiments, the AI ​​execution control unit 220 includes a cache management unit 240 to assist in the process of storing past analysis results and extracting only the difference items that have been changed by comparison with the current data. This enables "differential recalculation," which avoids the regeneration of the entire text and dramatically reduces token consumption.

[0030] In some embodiments, the response control unit 250 generates response data containing only permitted data fields based on the status of the target data and the user's authorization role, and returns it with UI status information that defines whether or not the operation is permitted on the client side. This is based on the design philosophy of "APITruth" and "ui_state," which determine the exposure of information and the activation status of operations on the backend side, without relying on display control on the frontend side. In addition, the response control unit 250 also plays a role in incorporating a fail-closed instruction, including a reason code, into the response data if a failure occurs in the AI ​​API.

[0031] In other embodiments not shown, these functional units do not necessarily need to reside within a single server. For example, it is possible to adopt configurations such as making the event monitoring unit 210 an independent microservice, or using a distributed in-memory database for the cache management unit 240.

[0032] (Hardware configuration of information processing equipment) Figure 2B is a hardware configuration diagram of an information processing device 200 according to one embodiment. The information processing device 200 is configured as a physical computer that realizes each of the above-described functional units (Figure 2A) through the cooperation of software and hardware.

[0033] In some embodiments, as shown in Figure 2B, the information processing device 200 includes a processor 201, RAM 202, ROM 203, communication IF 204, and storage device 205, which are connected to each other via a bus 206 so as to be able to communicate with each other.

[0034] Processor 201 is the central hardware that performs calculations, such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), MPU (Micro Processing Unit), or DSP (Digital Signal Processor). The processor 201 loads programs stored in the memory device 205, etc., into the RAM 202 and executes them, thereby realizing each function of the information processing device 200 shown in Figure 2A (for example, the functions of the event monitoring unit 210 and the AI ​​execution control unit 220). In particular, the sophisticated logic processing involved in generating requests to the generative AI models (Generative AI Model Group 400) and determining differences is ensured by the computing power of processor 201.

[0035] RAM202 is volatile memory that functions as a workspace for the processor 201 when it performs processing. In some embodiments, RAM 202 is used as a high-speed data storage area for job queues of target data extracted by the AI ​​execution control unit 220, generation of temporary structured metadata (such as JSON), and parsing of responses from the AI.

[0036] ROM203 is a non-volatile memory that holds the basic programs and other data necessary for system startup.

[0037] Communication IF204 is an interface for communicating with external devices via network 500, such as a network card (NIC), wireless modem, or serial communication port. In some embodiments, the communication IF204 is responsible for receiving access requests from the client device 100, and for sending API requests to and receiving responses from external generated AI models (a group of generated AI models 400) (such as a cloud-based AI platform).

[0038] The storage device 205 is an auxiliary storage device that permanently holds programs and data, such as an HDD (Hard Disk Drive) or SSD (Solid State Drive). In some embodiments, the storage device 205 stores case management tables, cache data, audit logs, etc., as the actual storage unit 300 (database) shown in Figure 1.

[0039] Note that the configuration shown in Figure 2B is merely an example, and in other embodiments not shown, the information processing device 200 may include input / output devices such as a display, keyboard, and mouse. In other embodiments not shown, the information processing device 200 may be configured not as a single physical enclosure, but as a distributed computing environment in which multiple servers cooperate, or as a virtual machine on a cloud platform. Furthermore, the hardware configuration may include dedicated application-specific integrated circuits (ASICs) or FPGAs (Field Programmable Gate Arrays) to accelerate specific computational processes (e.g., encryption of sensitive data or advanced inference).

[0040] (Data structure of the memory unit) Figure 3 is an Entity-Relationship (ER) diagram showing an example of the structure of a storage unit 300 (database) according to one embodiment. In some embodiments, as shown in Figure 3, the storage unit 300 includes a case management table 310 (case_master) which is the core of the overall system governance, and has a structure in which related tables that define various states and permissions are linked to it.

[0041] In the embodiment shown in Figure 3, the case management table 310 holds a unique identifier (case_id) for the target data as its primary key, and also manages attributes such as severity (severity_level), the overall progress status of the case (workflow_state), and the applicable role boundaries (role_scope). This system employs a backend structure that uses the "case" as the subject, rather than a specific user session or chat room, to manage its operations and data.

[0042] In some embodiments, data defining the "specific events" to be monitored by the event monitoring unit 210 is stored, for example, in a notification history table 340 or a record table 350.

[0043] The notification history table 340 (notification_outbox) holds multiple notification sending and resending histories for each case, and manages the latest notification type, sending status (send_status), notification sending time, etc. The record table 350 (follow_up_record, etc.) manages the follow-up deadline (due_at) and implementation status. The case management table 310 and the notification history table 340 or record table 350 have a "1:N" relationship. The event monitoring unit 210 triggers an event by comparing the "due_at" column in these tables with the current time to detect when the deadline has been exceeded, or by referring to the "send_status" column to detect when the status remains unconfirmed.

[0044] In some embodiments, the storage unit 300 includes a permission management table 320 (role_scope_permission) and a UI state table 330 (ui_state) to support the forced control of information exposure (APITruth) by the response control unit 250. The authorization management table 320 defines the permitted operations (allowed_action) and the permitted range of data fields (allowed_field_range) for each user role and scope (CompanyView / MedicalView, etc.). The authorization management table 320 and the case management table 310 have a "1:N" relationship, meaning that a single defined authorization rule can be applied to multiple cases. This forms the logical basis for the role side in the "severity x role" matrix output control in the information processing device 200. The UI status table 330 stores information such as the activation conditions (enabled_flags) for buttons on the screen and the reason code (reason_code) for when they cannot be operated, for each case, and these are linked "1:1" to the case management table 310.

[0045] Furthermore, in some embodiments, the storage unit 300 includes an audit log table 360 ​​(audit_log) to ensure transparency and traceability of the entire system. The audit log table 360 ​​maintains the operation history related to a case and records which user received what data and in what format (response_shape), using a consistent processing identifier (request_id), described later, as the key. This ensures that the uncertainty of AI is covered by robust system governance and enables ex-post proof as needed. The case management table 310 and the audit log table 360 ​​have a "1:N" relationship.

[0046] In other embodiments not shown, the storage unit 300 is not limited to a single relational database. For example, a polyglot persistence configuration could be used, where structured data such as project management is handled using MySQL®, while a NoSQL database (such as DynamoDB® or MongoDB®) is used for vast amounts of time-series data such as audit logs. Furthermore, in other embodiments not shown, in order to further enhance data integrity, it is also possible to adopt a configuration in which a portion of the audit log is recorded using distributed ledger technology such as blockchain and retained as an immutable evidence.

[0047] (Data structure for cache management) Figure 4 is a conceptual diagram showing the data structure of the cache and differential recording layer within the storage unit 300, which is managed by the cache management unit 240 according to one embodiment. In some embodiments, the information processing device 200 includes a cache management unit 240 that stores analysis results from past generation AI models (generation AI model group 400) on target data, as described above with reference to Figure 2A. When a specific event occurs, the AI ​​execution control unit 220 compares the past analysis results stored in the cache management unit 240 with the current target data, extracts the changed difference items, and sends an analysis request to the generation AI model (generation AI model group 400) to update the analysis results to reflect only those difference items.

[0048] In the embodiment shown in Figure 4, the cache management unit 240 stores past analysis results 370 in a first management layer (summary_cache) and differential records 380 (history of changes) in a second management layer (diff_record) 380 within the storage unit 300.

[0049] The past analysis results 370, for example, use the case identifier (case_id) as the primary key and store fields such as the version number of the generated result (summary_version), the generation date and time (generated_at), the model class used (model_class), and the actual summary text (summary_text). On the other hand, the differential record 380 stores, for example, the items that have been changed since the last update (changed_fields), the date and time of the change (changed_at), and the type of event that triggered the change (trigger_event), all associated with the case identifier (case_id). The past analysis results 370 and the difference records 380 are configured to be matchable using the case identifier (case_id) as a common key, and the information processing device 200 allows the AI ​​execution control unit 220, implemented with Node.js (registered trademark), to refer to these records, enabling it to precisely identify "what has changed" since the previous analysis.

[0050] According to the configuration shown in Figure 4, the AI ​​execution control unit 220 combines the extracted changed items (changed_fields) with the latest values ​​and dynamically generates structured data 390 (analysis request) including differential update prompts. For example, if only the follow-up deadline is changed, the AI ​​execution control unit 220 does not resend the entire previous summary, but instead sends a lightweight request that includes instructions such as, "Only the deadline field has been changed to a specific date and time, so update the summary to reflect only that change to the previous summary (version 3)." This eliminates the need to regenerate the entire text from scratch each time, dramatically reducing the computational load and token consumption of the generative AI model (Generative AI Model Group 400), while also enabling updates without compromising the consistency (continuity) of the analysis results.

[0051] In other embodiments not shown, the data held by the cache management unit 240 is not necessarily limited to summary results in text format. For example, intermediate vector data (embedding) generated during the analysis process, as well as information on specific inference paths, can be stored as a cache and reused in subsequent analyses to simultaneously improve the accuracy and speed of inference. Furthermore, in other embodiments not shown, to enhance data confidentiality, it is possible to encrypt the cache data stored in the memory unit 300 with a unique key for each case, and dynamically decrypt and process it only when the AI ​​is running. This achieves a higher level of security while simultaneously enabling both data non-retention and reusability.

[0052] (Event monitoring and extraction processing) Figure 5 is a flowchart of the event monitoring and data extraction process performed by the event monitoring unit 210 according to one embodiment. Furthermore, the process shown in this flowchart does not involve constantly making requests to the generated AI model (Generated AI Model Group 400), but rather aims to suppress the number of requests by triggering proactive events in the backend (e.g., the Node.js environment).

[0053] First, in step S501, the event monitoring unit 210 of the information processing device 200 starts the periodic monitoring process. This process is executed at regular intervals (e.g., nightly batch) by, for example, a server-side cron job. In step S502, the event monitoring unit 210 accesses the storage unit 300 and queries for the relevant business data (e.g., notification history and follow-up records).

[0054] In some embodiments, the event monitoring unit 210 monitors whether a specific event, which is defined in advance, has occurred with respect to the target data. Specific events include, for example, exceeding the deadline for the target data, continuing to have the status unconfirmed, or exceeding a threshold for a particular score.

[0055] A specific event may be an event in which the input target data is detected not to conform to the standardization rules (standard format) such as the "Ministry of Health, Labour and Welfare Standard Specifications" established by the Ministry of Health, Labour and Welfare, etc. Specifically, the system can be configured to trigger an event when receiving health checkup result data, etc., if it detects unmapped items, mismatches in units, mismatches in judgment categories (for example, a formal difference such as "requires follow-up observation" from institution A and "requires re-examination" from institution B), or inconsistencies with standard codes (for example, JLAC11 or LOINC).

[0056] The event monitoring unit 210 detects any of these specific events and triggers an event. Specifically, in step S503, the event monitoring unit 210 determines whether a specific event has occurred based on the queried data. For example, it evaluates conditional expressions such as whether the follow-up deadline (due_at) has exceeded the current time, whether a sent notification has remained "unread (unconfirmed)" for a certain period of time, or whether the stress check score has exceeded a set threshold and been determined to be "high stress".

[0057] If it is determined that no specific event has occurred (S503: NO), the process terminates. On the other hand, if it is determined that any of the events has occurred (S503: YES), the process proceeds to step S504.

[0058] In step S504, the event monitoring unit 210 extracts the relevant data that matches the conditions and triggers an event within the system. In the subsequent step S505, the extracted data is temporarily stored in memory or elsewhere as a "processing unit (job)" for processing by the subsequent AI execution control unit 220.

[0059] According to the embodiment shown in Figure 5, the system is designed to accurately capture only critical moments when a system or human intervention is necessary, such as when deadlines are exceeded or unconfirmed issues persist, and prepare to activate the AI ​​at those specific times. This prevents oversights and reliably eliminates unnecessary AI calls.

[0060] In other embodiments, instead of the periodic batch processing shown in Figure 5, a configuration is also possible in which data updates are triggered in real time. In other embodiments not shown, the system may be configured to immediately execute the data extraction and event firing in step S504 by utilizing a database trigger function or an ORM (Object-Relational Mapping) tool's lifecycle hook the moment a record in the storage unit 300 is updated by a user operation from the client device 100 (e.g., form submission or status change). Alternatively, the system may be configured to fire an event directly when data is received from an external human resources system or health checkup system (e.g., when a webhook is received), immediately initiating AI analysis processing. This enables more real-time monitoring and faster execution of AI analysis.

[0061] (AI execution job management process) Figure 6 is a flowchart showing an example of job management processing by the AI ​​execution control unit 220 according to one embodiment. The event monitoring process described above (see Figure 5) anticipates that multiple specific events (for example, multiple deadlines being exceeded at the end of the month) may occur simultaneously. In such cases, if the information processing device 200 simultaneously sends all the relevant data to an external generating AI model (generating AI model group 400), it may exceed the API rate limit (limit on the number of requests per unit of time) or deplete the network resources of the server itself. This process is control logic designed to prevent these problems.

[0062] In step S601, the AI ​​execution control unit 220 acquires the unprocessed processing units (jobs) held in step S505 in Figure 5. In step S602, the AI ​​execution control unit 220 determines whether the current number of concurrently running processes in the information processing device 200, or the current frequency of calls to the external API, has reached a preset limit (threshold). If the limit is reached (S602: YES), the AI ​​execution control unit 220 either waits (sleeps) for a certain period of time, or temporarily suspends processing of the job and returns it to the queue, and retries processing from step S601. This prevents excessive load concentration on the system. If the limit has not been reached (S602: NO), the process proceeds to step S603, and the AI ​​execution control unit 220 generates structured data (analysis request) through the processing described later. In the following step S604, the generated structured data is sent (called) to the API of the generating AI model (Generating AI Model Group 400), and the processing of this job is completed.

[0063] In some embodiments, when multiple specific events occur simultaneously, the AI ​​execution control unit 220 temporarily holds the extracted target data as a processing unit, and calls the API of the generated AI model (generated AI model group 400) while controlling the processing unit sequentially or in predetermined units.

[0064] The control logic shown in Figure 6 can be implemented, for example, in an asynchronous execution environment such as Node.js® by managing arrays in the backend server's own memory or by controlling the number of concurrent executions using Promises (Concurrency Control). This allows for sequential or incremental control of API calls, even when multiple events occur simultaneously, without complicating the infrastructure configuration, thus robustly ensuring the stable operation of the system.

[0065] In other embodiments not shown, a simple "job management table" may be provided in the storage unit 300 (MySQL®, etc.), and multiple worker threads may read records waiting to be processed from this table one by one (or in batches) and sequentially call the AI ​​API. This makes it possible to safely and reliably avoid rate limits even in a redundant environment (scale-out configuration) consisting of multiple information processing units 200.

[0066] (Process for generating structured data) Figure 7 is a flowchart showing the procedure for generating structured data (analysis request) by the AI ​​execution control unit 220 according to one embodiment. In this flowchart, the data sent to the generated AI model (Generated AI Model Group 400) does not include the lengthy raw text (for example, medical diagnosis results or free-form descriptions from interviews) stored within the business system. The AI ​​execution control unit 220 extracts only the necessary metadata and generates and sends structured data in a format such as JSON (JavaScript® Object Notation).

[0067] In step S701, the AI ​​execution control unit 220 acquires the type of event (for example, "deadline exceeded," "unconfirmed and continuing," "high stress threshold exceeded," etc.) that was triggered by the event monitoring unit 210. In step S702, the AI ​​execution control unit 220 extracts "common items" from the target data that are independent of the event type. Common items include, for example, the case identifier (case_id), the case severity level (severity_level), the authorization role (role_scope), and the current work state (workflow_state). This allows the generated AI model (generated AI model group 400) to always provide the overall context and constraints of the target case in a consistent format.

[0068] In some embodiments, the AI ​​execution control unit 220 does not send the raw target data as an analysis request, but instead generates structured data that includes common items independent of the event and optional items corresponding to the type of event that was triggered, and sends this structured data to the generating AI model (group of generating AI models 400). Therefore, in step S703, the AI ​​execution control unit 220 dynamically extracts "optional items" according to the event type acquired in step S701, with the aim of incorporating them into structured data along with "common items". For example, if the triggered event is "overdue," the optional fields extracted will be "due_at" and "overdue_days." On the other hand, if the event is "unconfirmed," the optional fields extracted will be "notification_sent_at" and "notification_resend_count."

[0069] In step S704, the AI ​​execution control unit 220 combines the extracted common items and optional items, and further incorporates the "instruction prompt" described later to generate the final structured data. This processing flow is completed, and the generated structured data is passed on to the next transmission process (step S604 in Figure 6, etc.).

[0070] In this way, by generating structured data consisting of common and optional items according to the event type and sending it to the generating AI model (Generating AI Model Group 400), the amount of data sent to the API (number of input tokens) can be minimized compared to sending raw long text every time. At the same time, it structurally prevents the excessive transmission of sensitive information outside of authorized permissions (for example, details of medical texts that are not disclosed with CompanyView permissions) to external AI engines, thus ensuring secure system operation.

[0071] In other embodiments not shown, the format of the structured data is not limited to JSON, but may be XML or a binary format (Protocol Buffers, MessagePack, etc.). Furthermore, the rules for extracting optional items are defined by an external rule engine or configuration file, making it possible to dynamically add new event types and optional items without restarting the system during operation.

[0072] Furthermore, when generating structured data, external knowledge such as internal company regulations (employment rules, etc.) and criteria for judging similar past cases may be dynamically extracted from the database using vector searches or similar methods, and the extracted external knowledge may be incorporated into common items as "prerequisite information (context)" that the generating AI model should refer to. Here, "background information (context)" includes, for example, rule text such as "According to our regulations, if an employee is absent for more than 3 consecutive days, an industrial physician consultation is required within 5 business days," relevant sections of practical manuals such as "If the high stress assessment score is 80 points or higher and the employee's request for a consultation flag is ON, classify it as 'Urgency: High (L3)'," past knowledge such as "In a similar past case (Case-X), we prioritized interviewing the immediate supervisor before contacting the employee," or description specifications based on medical information exchange standards such as "HL7FHIR (registered trademark)" (e.g., HS037: Health checkup result report HL7FHIR description specification, etc.) or code mapping rules such as clinical laboratory master (HS014). By adopting this so-called RAG (Retrieval-Augmented Generation) architecture, it becomes possible to suppress hallucination (plausible lies) in the generated AI model and obtain highly accurate analysis results that comply with the company's own rules.

[0073] (Model routing processing) Figure 8 is a flowchart showing the procedure for the dynamic distribution process of destination models by the model routing unit 230 according to one embodiment. This flowchart is based on the design philosophy of "model hierarchy separation," which uses the most suitable model according to the characteristics of the request, rather than processing all analysis requests with a uniform AI engine.

[0074] In step S801, the model routing unit 230 of the information processing device 200 evaluates the complexity and importance of the analysis request based on the content of the analysis request generated by the AI ​​execution control unit 220. This evaluation may be carried out by comprehensively determining, for example, the type of event that was triggered (event_type), the severity level of the issue (severity_level), the number of changed differential items (amount of changed_fields), and whether human accountability is required.

[0075] In some embodiments, the information processing device 200 is configured to communicate with APIs of multiple generating AI models (a group of generating AI models 400) that have different providers or processing loads, and the AI ​​execution control unit 220 dynamically selects the destination for sending the analysis request from among the APIs of the multiple generating AI models (a group of generating AI models 400) based on at least one of the type of event or the importance of the target data. In this case, the model routing unit 230 determines in step S802 whether a high level of accountability or complex analysis is required based on the evaluation results. For example, if an event relates to "assisting with medical explanations for high-stress cases" or "audit explanations / explanations of historical discrepancies," it will be judged as requiring "a high level of accountability (high importance)" because contextual understanding and high traceability are necessary.

[0076] If it is determined that a high level of accountability or complex analysis is not required (S802:NO), the process proceeds to step S803, where the model routing unit 230 sets the lightweight and low-cost second-generation AI model 420 (lightweight model) as the destination. For example, tasks such as "simple classification and unverified count organization" or "prioritizing candidates for overdue items" are standardized judgments that can be processed using only structured input, and therefore can be adequately achieved with lightweight models that have a low processing load.

[0077] On the other hand, if it is determined that a high level of accountability or complex analysis is required (S802: YES), the process proceeds to step S804, where the model routing unit 230 sets the first generated AI model 410 (high-performance model), which is capable of high-precision inference, as the destination.

[0078] Thus, the dynamic distribution process of the destination model shown in Figure 8 allows for the dynamic use (routing) of lightweight and high-performance models according to the event type and data importance, eliminating the waste of processing everything with the high-cost high-performance model and optimizing the cost-effectiveness of the entire system.

[0079] In other embodiments not shown, the routing decision criteria may include not only cost and accountability but also "real-time performance (required latency level)." For example, for interactive operation assistance events that require an immediate response from client device 100, even if they are of high importance, the system may be configured to temporarily route them as a fallback to a lightweight model with a faster response speed (or a dedicated API endpoint for high-speed inference). Furthermore, it may include a load balancing function that monitors the current API rate limit consumption of each generating AI model (400 generating AI models) and automatically redirects requests to the other API when one API limit approaches its upper limit. Furthermore, it is possible to adopt a hybrid configuration in which the information processing device 200 determines whether the target data contains specific sensitive information (for example, specific disease names or information that is highly personally identifiable), and if the information is highly sensitive, it avoids the external cloud API (first generation AI model 410) and forcibly routes it to a self-hosted model (second generation AI model 420) that operates on the company's closed network.

[0080] (Process for generating analysis requests through differential recalculation) Figure 9 is a flowchart showing the procedure for generating an analysis request using differential recalculation by the AI ​​execution control unit 220 according to one embodiment. This flowchart employs a "delta update" algorithm that processes only the "difference" from the previous generation result, rather than resending the entire text to the AI ​​and generating summaries from scratch every time the target data is updated.

[0081] In some embodiments, the information processing device 200 includes a cache management unit 240 that stores the analysis results of past generation AI models (generation AI model group 400) on the target data. In step S901, the AI ​​execution control unit 220 retrieves "past analysis results (cache)" stored in the memory unit 300 via the cache management unit 240. Specifically, summary text (summary_text) and the latest version number (summary_version) associated with the case identifier (case_id) shown in Figure 4 are read out.

[0082] In some embodiments, when a specific event occurs, the AI ​​execution control unit 220 compares past analysis results with the current target data, extracts the changed difference items, and sends an analysis request to the generating AI model (group of generating AI models 400) to update the analysis results to reflect only those difference items. In step S902, the AI ​​execution control unit 220 compares the data values ​​that formed the basis of the acquired past analysis results with the latest target data on the current memory unit 300 (current business status, deadline, notification status, etc.) and extracts the fields that have changed as difference items (changed_fields). In step S903, it is determined whether difference items have been extracted (i.e., whether there are differences). If there are no differences (S903; NO), the AI ​​call is omitted and the process ends. On the other hand, if there are differences (S903; YES), an analysis request is generated (S904) to update the previous analysis results (incremental update) by reflecting only the extracted difference items, and this analysis request is sent to the generating AI model (generating AI model group 400) (S905). This analysis request includes the previous version number, the changed field name, and the new value of the field.

[0083] In this way, by extracting the differences between past analysis results and current data and sending analysis requests that reflect only the differences, it becomes unnecessary to regenerate the entire text from scratch each time, dramatically reducing the processing load on the AI ​​model and the consumption of communication tokens. Furthermore, updating based on differences suppresses discontinuous changes in the analysis content (such as drastic changes in summaries due to hallucination), ensuring consistent accountability (explainability).

[0084] In other embodiments not shown, difference extraction is not limited to simple field comparison. For example, the system could be configured to calculate the semantic similarity of text data and skip the AI ​​request if there is no substantial change in meaning.

[0085] Alternatively, the system could be configured to calculate an "impact score" for each changed item on the backend side, and if the score is below a predetermined threshold (for example, a simple correction of a typographical error or the addition of a memo that does not affect business operations), it could skip sending an analysis request to the generating AI model, thereby further reducing the system load. Here, the logic for calculating the impact score could be, for example, one that pre-defines importance weights for each field of the target data (for example, "Due Date and Time" and "Medical Assessment" fields have high weights, while the "Free Memo" field has a low weight), and then uses the sum of the weights of the fields where changes are detected as the score, or one that calculates the edit distance (Levenshtein distance, etc.) between the strings before and after the change in a text field and converts that into a score.

[0086] Furthermore, in other embodiments not shown, it is also possible to adopt a configuration that dynamically switches between a differential recalculation mode (delta_update) and a "forced full-text regeneration (full_rebuild)" mode, which is executed when there is concern about information loss after several generations of updates, depending on specific conditions (for example, when the number of updates exceeds a threshold).

[0087] (Authentication, authorization, and response generation sequences) Figure 10 is a ladder diagram showing the authentication, authorization, and response generation sequence between an information processing device 200 and a client device 100 according to one embodiment. This sequence is based on the "APITruth" design philosophy, which completely excludes unauthorized information at the information processing device 200 (backend) stage, rather than hiding (masking) the data on the screen after sending it to the client side (frontend).

[0088] In some embodiments, the information processing device 200 includes a response control unit 250 that, in response to a request from a client device 100, generates response data that includes only the data fields permitted to the user, based on the status of the target data and the user's authority. The response control unit 250 adds UI state information that defines the rendering state or operability of the screen on the client device 100 to the response data and returns it.

[0089] In the embodiment shown in Figure 10, the sequence begins with an access request from the client device 100 ("1. Access Request"). This request includes an authentication token, such as a JWT (JSON Web Token), in the URL or HTTP header. The communication and authentication control unit 260 of the information processing device 200 verifies the signature and expiration date of the received JWT and obtains user identification information and role information ("2. JWT Verification and Role Acquisition").

[0090] Next, the information processing device 200 accesses the storage unit 300 to obtain the status (severity_level, workflow_state, etc.) of the target case (case_id), and also refers to the authorization management table 320 (role_scope_permission) to query the operations (allowed_action) and the range of permitted data fields (allowed_field_range) for the user's role (see "3. Case Status and Authorization Inquiry" and "4. Allowed Field Range Return").

[0091] Next, the response control unit 250 performs a filtering process based on the query results to completely exclude fields outside of its authority (for example, medical text or raw URLs for the Head Office Human Resources role) during the payload generation stage ("5. Excluding Data Outside of Authority"). Furthermore, the response control unit 250 generates UI state information (ui_state) that defines the enabled / disabled status of buttons on the screen of the client device 100 (enabled_flags), the display range (visibility_scope), the current state label (state_label), etc. ("6. UI State Information Generation"), and adds this to the response data (JSON, etc.) and returns it to the client device 100 ("7. Response Data Return").

[0092] The client device 100 interprets the returned UI state information as positive and performs screen rendering and function control completely subservient to the server's instructions without independently inferring state or permissions ("8. Screen Rendering Control").

[0093] In this way, by excluding unauthorized data on the backend side and returning it to the client along with UI state instructions, information leaks (fail-open) due to the frontend's own inferences can be completely prevented, and robust data governance can be achieved.

[0094] In other embodiments not shown, the authentication method is not limited to stateless authentication using JWT, but may also be federated authentication using OAuth 2.0 or SAML, or a session management method using secure cookies.

[0095] Furthermore, the client device 100 is not limited to a Single Page Application (SPA) that runs on a web browser. In other embodiments not shown, the client device 100 may be a native application for smartphones or other devices, or client software specifically for desktops. In any case, a configuration is applied in which the screen rendering state and button activation state are determined in accordance with the UI state information generated by the response control unit 250.

[0096] (Fail-closed sequence in case of anomaly) Figure 11 is a fail-closed sequence diagram (ladder diagram) of a generation AI model (generation AI model group 400) according to one embodiment in the event of an abnormality. Due to its nature of utilizing external cloud APIs, requests to the generated AI models (Generated AI Model Group 400) are always subject to "uncertainty" such as network failures, service provider failures (HTTP 500-series errors), or timeouts due to reaching API rate limits. Therefore, this sequence is based on a design philosophy that, when an abnormal response occurs from such a generating AI model, does not leave the decision to the client side and allow the system to continue (fail-open), but rather the backend takes the lead in prioritizing safety and closing the function (fail-close).

[0097] In some embodiments, if the response from the API of the generated AI model (group of generated AI models 400) is abnormal, the response control unit 250 generates UI status information including a reason code indicating a limitation or suspension of the function and returns it to the client device 100.

[0098] In the embodiment shown in Figure 11, after the AI ​​execution control unit 220 sends an analysis request to the generated AI model (generated AI model group 400) ("1. Analysis Request"), if a normal response is not received within a certain period of time (timeout) or if an error response is received, the AI ​​execution control unit 220 detects an abnormal state ("2. Timeout / Error"). At this time, the AI ​​execution control unit 220 maintains the original state of the target data (such as the status of the case) without unnecessarily updating it, and records the type of abnormality that occurred and the error message in the system's internal audit log (audit_log) ("3. Recording Abnormal State") to ensure traceability after the fact.

[0099] Next, the AI ​​execution control unit 220 notifies the response control unit 250 of the detected abnormal state ("4. Notification of Abnormal State"). Then, the response control unit 250, upon receiving notification of an anomaly detection from the AI ​​execution control unit 220, sets a reason code indicating the reason for the anomaly (reason_code: "AI_UNAVAILABLE" etc.) and an instruction to deactivate the function (enabled_flags: { "edit": false} etc.) in the UI state information (ui_state) to be returned to the client device 100 (see "5. Setting reason_code etc."). When the client device 100 receives response data containing this UI state information ("6. Response return including reason code"), it explicitly displays a reason statement on the screen based on the reason code, such as "This operation has been stopped because AI collaboration is unavailable," and deactivates (closes functions) related save buttons, etc. ("7. Display of reason statement and function closure (fail-closed)").

[0100] In this way, when an AI execution error occurs, instead of allowing screen operations to continue with an incomplete data state, the server forces UI state information to safely stop the function along with a reason code. This prevents user errors and data inconsistencies, and establishes high reliability and governance as a business system while incorporating the uncertain element of AI.

[0101] In other embodiments not shown, the handling of an anomaly is not limited to a single fail-close. For example, if an error is returned from the API of the first generated AI model 410 (high-performance model), the AI ​​execution control unit 220 does not immediately proceed to fail-close processing. Instead, it can adopt a process that temporarily falls back to rerouting the request to the second generated AI model 420 (lightweight model), and only executes fail-close processing if an error still occurs.

[0102] In other embodiments not shown, the information processing device 200 may also have a function to automatically send an alert about the failure to administrators and the operation and maintenance team via an external chat tool (such as Slack®) or email, at the same time as the system is shut down according to the reason code.

[0103] (Specific examples of response data by role) Figure 12 shows a specific example of role-specific response data (in JSON format) generated by the response control unit 250 according to one embodiment. This response data is based on the "APITruth" design philosophy, which ensures that the data sent from the backend (information processing device 200) itself does not contain unauthorized information, rather than the frontend (client device 100) receiving the data and then using CSS, JavaScript, etc. to hide (mask) unauthorized information.

[0104] Figure 12(A) shows an example of response data for "CompanyView" permissions granted to company personnel such as HR and general affairs staff, and (B) shows an example of response data for "MedicalView" permissions granted to medical professionals such as industrial physicians. These are responses to requests for the same target data ("case_id": "CASE-001"), but the content changes dynamically depending on the permissions.

[0105] In some embodiments, the response control unit 250 generates response data that includes only the data fields permitted to the user, based on the state of the target data and the user's authority, and adds UI state information that defines the rendering state or operation availability of the screen on the client device 100 to the response data.

[0106] In the CompanyView data shown in Figure 12(A), the "visibility_scope" within the UI state information ("ui_state") is set to "company," and while viewing ("view") is permitted (true) in the permission flags ("enabled_flags"), editing ("edit") is forcibly disabled (false). Furthermore, it is noteworthy that medical summary information ("medical_summary", etc.), which should originally be present in the target data, has been completely excluded from the JSON payload fields themselves. On the other hand, in the MedicalView data shown in Figure 12(B), editing ("edit": true) is permitted in the UI status information, and the medical summary ("medical_summary": "Medical consultation required, progress check...") is included as a field in the interview information ("interview") object and returned.

[0107] In this way, by generating response data on the backend side that includes only the data fields permitted according to the user's permissions and is accompanied by UI state information (ui_state), the risk of sensitive information being leaked outside of the user's permissions can be structurally reduced to zero, even if a malicious user intercepts and analyzes the communication content (network tab) using browser developer tools, etc.

[0108] In other embodiments not shown, the format of the data being communicated is not limited to JSON (JavaScript Object Notation). For example, GraPHQL could be used for frontend-backend communication, and directives based on schema definitions (such as @auth) could be used to automatically return null or an error on the backend side for queries on fields without authorization. Alternatively, binary communication using gRPC and Protocol Buffers could also be used, and in any of these communication protocols, the effect of "the backend determining the truth and not sending unauthorized data over the network" is equally achieved.

[0109] (Screen control based on UI state information) Figure 13 is a conceptual diagram of screen control performed in a client device 100 according to one embodiment, based on UI state information received from an information processing device 200. This screen control system employs an architecture in which the client device 100 (frontend) does not independently infer the user's permissions or data status to render the screen, but rather is completely dependent on the "UI state information (ui_state)" provided by the information processing device 200 (backend).

[0110] In some embodiments, as shown in Figure 13, the client device 100 receives UI state information that defines the screen rendering state or whether it is operable, which is attached to the response data returned from the information processing device 200. In the embodiment shown in Figure 13, the response data (JSON) sent from the information processing device 200 includes a "ui_state" object. In this example, the UI state information includes a flag ("enabled_flags": { "edit": false}) indicating a function closure due to an API anomaly (see Figure 11) in the generated AI model (generated AI model group 400), and a reason code ("reason_code": "AI_UNAVAILABLE") indicating the reason.

[0111] The client device 100 parses this response data and controls the screen rendering in accordance with the UI state information. Specifically, on the client screen shown on the right side of Figure 13, based on the fact that "reason_code" is "AI_UNAVAILABLE", a warning message (alert box) stating "This operation has been stopped because AI integration is unavailable" is explicitly displayed at the top of the screen. At the same time, in accordance with the mandatory instruction "edit": false, the normally clickable "Save" button is grayed out and disabled.

[0112] In some embodiments, if the response from the API of the generated AI model (group of generated AI models 400) is abnormal, the response control unit 250 does not change the state of the target data, but generates UI state information including a reason code indicating a limitation or suspension of the function, and returns it to the client device 100. Figure 13 visually illustrates how this UI state information with a reason code is interpreted on the client side, resulting in a safe fail-closed state (failure to function) without the system failing open (continuing processing in an uncertain state). In this way, by configuring the client screen to be completely subordinate to the UI state information determined in the backend, it is possible to prevent unauthorized data updates due to implementation omissions or tampering in the frontend, and to ensure robust system governance.

[0113] In other embodiments not shown, the control by UI state information is not limited to deactivating buttons or displaying text. For example, it may include controlling an entire field (e.g., an input form) to be read-only, or removing a specific tab or menu item from the DOM (Document Object Model) tree to completely hide it. Furthermore, in other embodiments not shown, the client device 100 can locally store the correspondence between reason codes and on-screen display messages, and the backend can send only short reason codes. The client can then expand and display appropriate translated messages (e.g., Japanese, English, etc.) according to the user's language settings. This allows for user-friendly governance control while keeping the response data payload size small.

[0114] (Structured data (analysis request) data structure) Figure 14 shows a specific example of the data structure of structured data 390 (analysis request) generated by the AI ​​execution control unit 220 according to one embodiment. This data structure is based on the design philosophy of sending JSON (JavaScript Object Notation)-based structured metadata that has been extracted and formatted by the system, rather than directly embedding "raw long texts" such as interview records and comments stored in the memory unit 300 into the prompt when making a request to the generative AI model (generative AI model group 400).

[0115] In some embodiments, as described above with reference to Figure 7, the AI ​​execution control unit 220 does not send the raw target data as an analysis request, but instead generates structured data that includes common items independent of events and optional items corresponding to the type of event that was triggered, and sends this structured data to the generating AI model (generating AI model group 400).

[0116] In the embodiment shown in Figure 14, the structured data 390 is broadly composed of two blocks: "common items 391" and "optional items 392".

[0117] Common item 391 is a set of information that is always necessary as the basic context of a case, regardless of the type of event (e.g., whether it is overdue or unconfirmed). Specifically, it includes the identifier of the target data ("case_id": "CASE-2026-0001"), the severity level of the case ("severity_level": "L3"), the applied role ("role_scope": "CompanyView"), and the current work progress status ("workflow_state": "FOLLOW_UP_REQUIRED"). Common item 391 allows the generative AI model (Generative AI Model Group 400) to reliably recognize the preconditions, such as "What situation is the case currently being processed?"

[0118] On the other hand, option item 392 is a set of information that is dynamically extracted and replaced by server-side processing such as Node.js, depending on the type of event that was triggered. The example in Figure 14 shows the data structure when an "overdue event" occurs. In the example shown in Figure 14, the event type ("event_type": "FOLLOW_UP_OVERDUE") is set, and the due date and time ("due_at") and the number of days overdue ("overdue_days"), which are essential for evaluating the event, are extracted and incorporated. Furthermore, as will be described later, an instruction identifier ("action_request": "summarize_risk_and_next_action") is assigned to instruct the generative AI model (generative AI model group 400) to perform a specific task.

[0119] In this way, instead of sending the raw target data as is, structured data 390 including common items 391 and optional items 392 is generated. This structurally prevents excessive external transmission of sensitive information outside of authorized permissions (e.g., detailed medical text), ensuring API Truth, while simultaneously minimizing the amount of data input to the API (number of input tokens), thereby improving processing speed and reducing token charges.

[0120] In other embodiments not shown, the format of the generated structured data is not limited to JSON, but may be YAML, XML, or a proprietary key-value format optimized for the API specification.

[0121] Furthermore, in other embodiments not shown, for example, if the target data is IoT (Internet of Things) sensor data of factory equipment, it is also possible to adopt a configuration in which common items 391 such as "equipment ID" and "operating mode" are set, and unique parameters such as "peak frequency when an abnormal vibration event occurs" and "time elapsed since the most recent maintenance" are dynamically incorporated as optional items 392 according to the event type. As a result, the structured data generation framework disclosed herein can be broadly deployed (applied) not only to the fields of industrial medicine and labor management, but also to anomaly detection and automated analysis systems in a wide range of industrial sectors.

[0122] (Dynamic selection processing of instruction prompts) Figure 15 is a mapping diagram showing the correspondence between an instruction identifier (action_request) included in structured data according to one embodiment and the specific instruction content (prompt template) selected based on it. The information processing device 200 does not send uniform, general-purpose instructions (for example, "Summarize the following data") to the generating AI models (the group of generating AI models 400), but rather has an architecture that dynamically assigns specialized tasks that are most appropriate to the context of the triggered event, as shown in Figure 15.

[0123] In some embodiments, the AI ​​execution control unit 220 dynamically switches the content of the instruction prompts to the generating AI models (generating AI model group 400) to be included in the structured data, depending on the type of event that has been triggered.

[0124] In the embodiment shown in Figure 15, the AI ​​execution control unit 220 (for example, server-side logic on Node.js) selects a template for the corresponding instruction prompt based on the value of "action_request" determined from the event type. For example, if action_request is "summarize_risk_and_next_action", a template aimed at risk assessment and guiding to the next step will be selected, such as "Evaluate the risks associated with exceeding the deadline and summarize the specific actions to be taken next." Also, if action_request is "summarize_medical_attention_points", a more advanced template to assist professional judgment will be selected, such as "Extract the medical points to consider when determining high stress levels and list the items that industrial physicians should check in bullet points."

[0125] In some embodiments, the analysis request is a request to cause a generating AI model (a group of generating AI models 400) to perform at least one of the following processes on the target data: determining priority, suggesting the next action, summarizing the state, or explaining the differences in history. The analysis request may also include requests to generate proposed mappings between different data standards (for example, between a healthcare institution's proprietary house code and a Ministry of Health, Labour and Welfare standard code) and to perform structural transformations (schema transformations) into public standard formats.

[0126] As shown in the example in Figure 15, prompts based on "summarize_confirmation_gap" prompt to organize dwell times and perform a "priority determination" regarding the need for retransmission. The aforementioned "summarize_risk_and_next_action" prompts to "present the next action." "summarize_medical_attention_points" prompts to "summarize the state" from lengthy records. Furthermore, prompts based on "summarize_audit_diff" prompt to compare the differences with the previous analysis results and perform a "historical difference explanation" that explains the background of the changes for audit purposes. In this way, by dynamically optimizing the tasks requested from the AI ​​in response to system conditions (events), it is possible to reliably fit (govern) the AI's general-purpose reasoning capabilities, from routine classification to advanced audit explanations, into the clear "roles" required by the business system.

[0127] In other embodiments not shown, these prompt templates are not limited to being hardcoded within the backend source code. For example, they may be managed in a dedicated table (such as prompt_template_master) within the storage unit 300 or by an external CMS (Content Management System), allowing operators to dynamically fine-tune the prompts (prompt engineering) without requiring system redeployment by engineers. Furthermore, in other horizontal deployment embodiments not shown, if the system is applied to maintenance management in manufacturing, the "action_request" may be set to "predict_time_to_failure," and a prompt such as "predict the remaining time to failure from the abnormal vibration pattern of the sensor and present a list of maintenance parts that need to be replaced" may be dynamically selected. This makes the "backend-based AI governance platform" of this disclosure broadly applicable to any condition-monitoring business process, regardless of the specific industry.

[0128] The characteristic configurations of the information processing device 200, information processing method, and program according to some of the embodiments described above can be summarized as follows.

[0129] [1] An information processing apparatus (200) according to at least some embodiments of the present invention is An information processing device (200) configured to be able to access a storage unit (300) that stores target data, An event monitoring unit (210) monitors whether a predefined specific event has occurred with respect to the aforementioned target data, and triggers an event when such specific event occurs. Based on the condition that the aforementioned event has been triggered, an AI execution control unit (220) extracts the target data that was the subject of the trigger, and calls the API of the generated AI model to send an analysis request, It is equipped with.

[0130] According to the configuration described in [1] above, the generation AI API is called only when a specific event occurs with respect to the target data and triggers an event. Compared to continuous polling for full monitoring, this reduces unnecessary AI requests and significantly lowers the processing load on the information processing device and token charges.

[0131] [2] In some embodiments, in the configuration of [1] above, The event monitoring unit (210) is configured to trigger an event when it detects, as a specific event, any of the following: an expiration of the deadline for the business data as the target data, continued unconfirmed status, or exceeding a threshold for a specific score.

[0132] According to the configuration described in [2] above, the AI ​​is activated only at critical times when business intervention is necessary, such as when deadlines are exceeded or unconfirmed items remain. This prevents oversights while reliably eliminating unnecessary AI calls.

[0133] [3] In some embodiments, in the configuration of [1] or [2] above, The AI ​​execution control unit (220) is configured to, when multiple of the specified events occur simultaneously, temporarily hold the extracted target data as processing units, and call the API of the generated AI model while controlling the processing units sequentially or in predetermined units.

[0134] According to the configuration described in [3] above, even if multiple events occur simultaneously, the generation AI's API calls are controlled sequentially or in small batches, thereby avoiding infringement of the rate limits (transmission limits) of external APIs and ensuring the stable operation of the system.

[0135] [4] In some embodiments, in any of the configurations described in [1] to [3] above, The AI ​​execution control unit (220) is configured not to send the raw target data as an analysis request, but to generate structured data (390) that includes event-independent common items (391) and optional items (392) corresponding to the type of event that was triggered, and to send the structured data (390) to the generated AI model.

[0136] According to the configuration described in [4] above, structured data including common items independent of events and optional items corresponding to the event type is generated and sent to the AI. This minimizes the amount of data sent to the API (number of input tokens) and prevents excessive external transmission of sensitive information.

[0137] [5] In some embodiments, in the configuration of [4] above, The AI ​​execution control unit (220) is configured to dynamically switch the content of the instruction prompts to be included in the structured data (390) for the generated AI model, depending on the type of event that has been triggered.

[0138] According to the configuration described in [5] above, instructions to the generating AI are dynamically optimized according to the type of event that is triggered, so that highly accurate analysis results appropriate to the situation can be obtained efficiently.

[0139] [6] In some embodiments, in any of the configurations [1] to [5] above, The aforementioned analysis request is a request to cause the generating AI model to perform at least one of the following processes on the target data: determining priority, suggesting the next action, summarizing the state, or explaining the differences in history.

[0140] According to the configuration described in [6] above, instead of leaving the final decision to the generating AI, it is made to perform decision-making support processes such as summarization and prioritization, thereby reducing the hallucination risk of the AI ​​while safely improving user efficiency.

[0141] [7] In some embodiments, in any of the configurations [1] to [6] above, The AI ​​execution control unit (220) includes a cache management unit (240) that holds past analysis results (370) of the target data by the generated AI model, The AI ​​execution control unit (220) is configured to, when the specific event occurs, compare past analysis results (370) held in the cache management unit (240) with the current target data, extract the changed difference items, and send an analysis request to the generating AI model to update the analysis results (370) to reflect only those difference items.

[0142] According to the configuration described in [7] above, the differences between past analysis results and current data are extracted, and analysis requests that reflect only the differences are sent. This eliminates the need to regenerate the entire text from scratch each time, dramatically reducing the API processing load and token consumption.

[0143] [8] In some embodiments, in any of the configurations described in [1] to [7] above, It is configured to communicate with APIs of multiple generative AI models that have different providers or processing loads. The AI ​​execution control unit (220) is configured to dynamically select the destination of the analysis request from among the APIs of the plurality of generating AI models based on at least one of the type of event or the importance of the target data.

[0144] According to the configuration described in [8] above, lightweight and high-performance models are dynamically used depending on the event type and the importance of the data, thus eliminating the waste of processing everything with the high-cost high-performance model and optimizing the cost-effectiveness of the entire system.

[0145] [9] In some embodiments, in any of the configurations [1] to [8] above, The system includes a response control unit (250) that, in response to a request from a client device (100), generates response data that includes only the data fields permitted to the user, based on the status of the target data and the user's authority. The response control unit (250) is configured to return the response data with UI state information that defines the rendering state or operability of the screen on the client device (100).

[0146] According to the configuration described in [9] above, the information processing device, which is the backend, excludes unauthorized data and returns it to the client along with the UI state instructions. This completely prevents information leakage (fail-open) due to the frontend's own inferences and enables robust data governance.

[0147]

[10] In some embodiments, in the configuration of [9] above, When the AI ​​execution control unit (220) receives an abnormal response from the generated AI model, the response control unit (250) is configured to record the abnormal response and return it to the client device (100) with a reason code indicating the reason for the abnormality included in the UI state information within the response data.

[0148] According to the configuration described in

[10] above, even if a failure occurs on the generating AI side, the backend will take the lead in safely closing (fail-closing) the client-side functions without concealing the error, thus preventing the entire system from being operated in an unstable state.

[0149]

[11] Information processing methods according to at least some embodiments of the present invention are An information processing method executed by a computer configured to access a storage unit (300) that stores target data, The process includes monitoring whether a predefined specific event has occurred with respect to the target data, and triggering an event if such a specific event occurs (for example, S503-S504), The steps include: 1) Based on the condition that the aforementioned event has been triggered, 2) extracting the target data that was the subject of the trigger, and 3) calling the API of the generated AI model to send an analysis request (for example, S603-S604); Includes.

[0150] According to the method described in

[11] above, the generation AI API is called only when a specific event occurs with respect to the target data and triggers an event. Compared to continuous polling for all records, this method can suppress unnecessary AI requests and significantly reduce the processing load on the information processing device and token charges.

[0151]

[12] Programs according to at least some embodiments of the present invention are A computer configured to be able to access the storage unit (300) that stores the target data, An event monitoring unit (210) monitors whether a predefined specific event has occurred with respect to the aforementioned target data, and triggers an event when such specific event occurs, and The AI ​​execution control unit (220) extracts the target data that was the subject of the event, and calls the API of the generated AI model to send an analysis request, based on the condition that the event has been triggered. This is a program designed to function as such.

[0152] According to the program described in

[12] above, the generation AI API is called only when a specific event occurs with respect to the target data and triggers an event. Compared to continuous polling for all records, this reduces unnecessary AI requests and significantly lowers the processing load on the information processing device and token charges. [Explanation of Symbols]

[0153] 100: Client device 200: Information Processing Device 210: Event Monitoring Department 220: AI Execution Control Unit 230: Model Routing Section 240: Cash Management Department 250: Response Control Unit 260: Authentication Control Unit 300: Storage section 310: Project Management Table 320: Permission Management Table 330: UI state table 340: Notification history table 350: Record Table 360: Audit log table 370:Analysis results 380: Differential Record 390: Structured data 391: Common items 392: Optional item 400: Generative AI Models 410: First Generative AI Model 420: Second Generation AI Model

Claims

1. An information processing device that functions as a backend server configured to be able to access a storage unit that stores target data, An event monitoring unit autonomously monitors whether a predefined specific event has occurred with respect to the aforementioned target data, either as a periodic batch process or as a server-side process triggered in real time by the update or receipt of the aforementioned target data, and fires an event when the aforementioned specific event occurs. Based on the condition that the aforementioned event has been triggered, an AI execution control unit extracts the target data that was the cause of the trigger, calls the API of the generated AI model, and sends an analysis request. Equipped with, The aforementioned target data includes any of the following: medical and labor data, health checkup results data, medical information reports, discharge summaries, health checkup result reports, inventory and order data in e-commerce, or monitoring logs in financial transactions. The event monitoring unit is configured to trigger the event when it detects, as a specific event, any of the following: an expiration of the deadline for the business data, a continued unconfirmed status, or an exceedance of a specific score threshold in the target data. Information processing device.

2. The AI ​​execution control unit is configured to dynamically extract external knowledge related to the target data from a database, generate structured data incorporating the extracted external knowledge as prerequisite information that the generating AI model should refer to, and transmit the structured data to the generating AI model. The information processing apparatus according to claim 1.

3. The AI ​​execution control unit is configured to, when multiple of the specified events occur simultaneously, temporarily hold the extracted target data as processing units, and call the API of the generated AI model while controlling these processing units sequentially or in predetermined units. The information processing apparatus according to claim 1 or 2.

4. An information processing device configured to be able to access a storage unit that stores target data, An event monitoring unit monitors whether a predefined specific event has occurred with respect to the aforementioned target data, and triggers an event when such specific event occurs. Based on the condition that the aforementioned event has been triggered, an AI execution control unit extracts the target data that was the cause of the trigger, calls the API of the generated AI model, and sends an analysis request. Equipped with, The AI ​​execution control unit is configured not to send the raw target data as an analysis request, but to generate structured data that includes common items independent of the event and optional items corresponding to the type of event that was triggered, and to send the structured data to the generated AI model. Information processing device.

5. The AI ​​execution control unit is configured to dynamically switch the content of the instruction prompts to be included in the structured data for the generated AI model, depending on the type of event that was triggered. The information processing apparatus according to claim 4.

6. The aforementioned analysis request is a request to cause the generating AI model to perform at least one of the following processes on the target data: determining priority, suggesting the next action, summarizing the state, or explaining the difference in history. The information processing apparatus according to claim 1 or 2.

7. The AI ​​execution control unit includes a cache management unit that stores past analysis results from the generated AI model for the target data. The AI ​​execution control unit is configured to, when the specific event occurs, compare past analysis results held in the cache management unit with the current target data, extract the changed difference items, and send an analysis request to the generating AI model to update the analysis results to reflect only those difference items. The information processing apparatus according to claim 1 or 2.

8. It is configured to communicate with APIs for multiple generated AI models that have different providers or processing loads. The AI ​​execution control unit is configured to dynamically select the destination of the analysis request from among the APIs of the plurality of generating AI models based on at least one of the type of event or the importance of the target data. The information processing apparatus according to claim 1 or 2.

9. An information processing device configured to be able to access a storage unit that stores target data, An event monitoring unit monitors whether a predefined specific event has occurred with respect to the aforementioned target data, and triggers an event when such specific event occurs. Based on the condition that the aforementioned event has been triggered, an AI execution control unit extracts the target data that was the cause of the trigger, calls the API of the generated AI model, and sends an analysis request. Equipped with, The system includes a response control unit that, in response to a request from a client device, generates response data that includes only the data fields permitted to the user, based on the status of the target data and the user's authority. The response control unit is configured to return the response data with UI state information that defines the rendering state or operability of the screen on the client device. Information processing device.

10. When the AI ​​execution control unit receives an abnormal response from the generated AI model, the response control unit is configured to record the abnormal response and return it to the client device, including a reason code indicating the reason for the abnormality in the UI state information within the response data. The information processing apparatus according to claim 9.

11. An information processing method executed by a computer that functions as a backend server configured to have access to a storage unit that stores target data, The process includes autonomously monitoring whether a predefined specific event has occurred with respect to the target data, either as a periodic batch process or as a server-side process triggered in real time by the update or receipt of the target data, and firing an event when the specific event occurs. The steps include: 1) Based on the condition that the aforementioned event has been triggered, extract the target data that was the subject of the trigger, and call the API of the generated AI model to send an analysis request; Includes, The aforementioned target data includes business data such as medical and labor data, health checkup result data, medical information provision documents, discharge summaries, health checkup result reports, inventory and order data in e-commerce, or monitoring logs in financial transactions. The step of triggering the event involves detecting one of the following as a specific event: an expiration of the deadline in the business data, continued unconfirmed status, or exceeding a threshold for a specific score, thereby triggering the event. Information processing methods.

12. A computer that functions as a backend server and is configured to have access to the storage unit that stores the target data, An event monitoring unit autonomously monitors whether a predefined specific event has occurred with respect to the target data, either as a periodic batch process or as a server-side process triggered in real time by the update or receipt of the target data, and fires an event when the specific event occurs, and The AI ​​execution control unit, upon confirmation that the aforementioned event has been triggered, extracts the target data that was the subject of the trigger, and calls the API of the generated AI model to send an analysis request. It is a program designed to function as such. The aforementioned target data includes business data such as medical and labor data, health checkup result data, medical information provision documents, discharge summaries, health checkup result reports, inventory and order data in e-commerce, or monitoring logs in financial transactions. The event monitoring unit is configured to trigger the event when it detects one of the following as a specific event: an expiration of the deadline in the business data, continued unconfirmed status, or exceeding a threshold for a specific score. program.

13. An information processing method performed by a computer configured to access a storage unit that stores target data, The steps include monitoring whether a predefined specific event has occurred with respect to the aforementioned target data, and triggering an event if such a specific event occurs, The steps include: 1) Based on the condition that the aforementioned event has been triggered, extract the target data that was the subject of the trigger, and call the API of the generated AI model to send an analysis request; Includes, The step of sending the analysis request involves not sending the raw target data as is, but generating structured data that includes common items independent of the event and optional items corresponding to the type of event that was triggered, and then sending the structured data to the generated AI model. Information processing methods.

14. A computer configured to have access to the memory unit that stores the target data, An event monitoring unit monitors whether a predefined specific event has occurred with respect to the aforementioned target data, and triggers an event when such a specific event occurs, and The AI ​​execution control unit, upon confirmation that the aforementioned event has been triggered, extracts the target data that was the subject of the trigger, and calls the API of the generated AI model to send an analysis request. It is a program designed to function as such. The AI ​​execution control unit is configured not to send the raw target data as an analysis request, but to generate structured data including common items independent of the event and optional items corresponding to the type of event that was triggered, and to send the structured data to the generated AI model. program.

15. An information processing method performed by a computer configured to access a storage unit that stores target data, The steps include monitoring whether a predefined specific event has occurred with respect to the aforementioned target data, and triggering an event if such a specific event occurs, The steps include: 1) Based on the condition that the aforementioned event has been triggered, extract the target data that was the subject of the trigger, and call the API of the generated AI model to send an analysis request; The steps include: generating response data that includes only the data fields permitted to the user, based on the status of the target data and the user's permissions, in response to a request from the client device; Includes, The step of generating the response data includes adding UI state information that defines the rendering state or operability of the screen on the client device to the response data and returning it. Information processing methods.

16. A computer configured to have access to the memory unit that stores the target data, An event monitoring unit monitors whether a predefined specific event has occurred with respect to the aforementioned target data, and triggers an event if such a specific event occurs. The AI ​​execution control unit, which, upon the occurrence of the aforementioned event, extracts the target data that was the subject of the event, calls the API of the generated AI model, and sends an analysis request, and A response control unit generates response data that includes only the data fields permitted for the user, based on the status of the target data and the user's permissions, in response to a request from the client device. It is a program designed to function as such. The response control unit is configured to return the response data with UI state information that defines the rendering state or operability of the screen on the client device. program.

Citation Information

Patent Citations

  • Design time smart analyzer and runtime smart handler for robotic process automation

    JP2025097251A

  • System and method for providing event-related information

    WO2025213264A1