Corporate Management Support System with Prior Consent Verification Mechanism

Abstract

This invention provides a corporate management support system, method, and pre-consent record structure with a pre-consent verification mechanism that uses multiple AI agents to generate proposals regarding a corporation's business or decision-making, determines whether the proposal content conforms to pre-registered consent conditions, appropriately controls whether or not automated execution is possible, and ensures auditability and explainability. [Solution] The corporate management support system, which has a proposal layer, an aggregation layer, and a final decision layer, includes a consent registry, a consent matching engine, a decision integration engine, a human intervention module, and an audit trail / explainability module. The consent matching engine matches the proposed content with the prior consent record, the decision integration engine decides on approval, conditional approval, withholding, or rejection based on the matching results, the human intervention module requests additional approval as needed, and the audit trail / explainability module records the basis for the decision. The system can also handle the renewal or cancellation of consent.

Description

Technical Field

[0001] The present invention belongs to the field of artificial intelligence (AI) technology, and particularly relates to the implementation of a pre-consent verification mechanism in a multi-agent system using multiple large language models (LLMs).

Background Art

[0002] This application is a composite priority application based on Japanese Patent Application No. 2026-00552 and Japanese Patent Application No. 2026-00933.

[0003] Patent Document 1 (Japanese Patent Application No. 2026-005527) discloses an AI-assisted corporate operation system. This document realizes the automation of corporate operation, including an AI execution engine, an audit node, an execution entity, and an information sharing infrastructure. However, the system described in Patent Document 1 does not disclose the application to the Mixture-of-Agents (MoA) framework and the integration of a pre-consent verification mechanism.

[0004] Patent Document 2 (Japanese Patent Application No. 2026-009336) discloses an AI-assisted corporate operation system including a smart articles of incorporation and an approval policy. However, the system described in Patent Document 2 also does not disclose the combination with the MoA framework and the integration into a multi-layer architecture.

[0005] Patent Document 3 (US20250252293A1) discloses a system that uses a large language model (LLM) as an orchestrator to control and integrate multiple task-specialized machine learning (ML) agents.

[0006] ​​This document includes dynamic context injection using a context engine, agent control using a model orchestration LLM, and automated verification and correction functions using a compliance agent.

[0007] However, the compliance agent described in the document adversarially verifies whether the generated responses comply with regulations and guidelines, and automatically repeats revisions until they pass; it does not include a prior consent verification mechanism that matches them against a pre-registered consent registry.

[0008] Furthermore, the document does not disclose how the Mixture-of-Agents (MoA) framework can be integrated into multi-layer architectures (such as the Proposer layer and Aggregator layer).

[0009] Patent document 4 (US12475151B1) discloses a technology that achieves fault tolerance and processing optimization in a multi-agent system using a large-scale language model (LLM) by combining shadow agents, checkpointing, and dynamic task assignment by an AI broker.

[0010] This document describes a fault-tolerant multi-agent system that includes a fault detection algorithm that monitors heartbeat signals, an agent replacement mechanism, and a response to software and hardware failures.

[0011] However, the system described in that document is specialized for agent failure response and does not include a Consent Matching Engine that matches pre-registered consent conditions with agent output.

[0012] Furthermore, the document does not disclose the integration of the Mixture-of-Agents (MoA) framework into multi-tier architectures.

[0013] Non-patent document 1 (Wang et al., 2024) discloses a Mixture-of-Agents (MoA) method that leverages the collective expertise of multiple large-scale language models. This method employs a hierarchical architecture consisting of a Proposer layer and an Aggregator layer.

[0014] However, the document concerns the cooperation mechanism between LLM agents and does not disclose its application to consent matching mechanisms or corporate governance.

[0015] Non-patent document 2 (ISO / IEC TS 27560:2023) is a privacy technology. This standard provides an international standard for consent record information structure. While it defines data structures such as the scope of consent, validity period, and signature metadata, it does not disclose its application to large-scale language model agents or integration into multi-layer architectures (Mixture-of-Agents frameworks). [Prior art documents] [Patent Documents]

[0016] [Patent Document 1] Japanese Patent Application No. 2026-005527 [Patent Document 2] Japanese Patent Application No. 2026-009336 [Patent Document 3] US20250252293A1 [Patent Document 4] US12475151B1 [Non-patent literature]

[0017] [Non-Patent Document 1] Wang, J., et al. "Mixture-of-Agents Enhances Large Language Model Capabilities." arXiv preprint arXiv:2406.04692 (2024). [Non-Patent Document 2] ISO / IEC TS 27560:2023 "Consent Records and Receipts" (2023). [Summary of the Invention] [Problems to be Solved by the Invention]

[0018] In recent years, techniques have been proposed that use large language models (LLMs) or multiple machine learning agents including LLMs to respond to natural language instructions and cross-cuttingly control multiple data sources or processing modules.

[0019] Also, in systems using multiple AI agents or LLMs, techniques have been proposed that combine log acquisition, explanation generation, guardrails, shared message pools, brokers, etc. to improve the reliability, auditability, and maintainability of the system.

[0020] However, each of the above techniques does not comprehensively solve the problems of automatic execution based on prior human consent, automatic branching of human intervention, and retroactive correction processing caused by human intervention.

[0021] An object of the present application is to comprehensively solve the problems of enabling automatic execution based on prior consent and branching of human intervention even when performing cross-cutting control using multiple AI agents, and performing retroactive correction processing caused by human intervention. [Means for Solving the Problems]

[0022] A corporate management support system with a prior consent verification mechanism according to one aspect of the present application comprises a configuration in which a consent verification engine located in the proposed layer performs a preliminary verification based on the consent subject, consenting entity, purpose of use, terms of use, consent version, validity period, cancellation flag, and other verification items included in the prior consent record, and supplies the verification results to the decision integration engine.

[0023] Furthermore, if a predetermined timeout or uncertainty is detected during the matching process, the system is configured to perform re-matching at predetermined intervals, and if the predetermined number of re-matches is exceeded, it will forcibly switch to a human intervention module.

[0024] In addition, the audit trail / explainability module is configured to generate audit records including matching items, mismatching items, weighting coefficients, evidence references, and reasoning for decisions, and to record them on an information sharing platform or blockchain.

[0025] Furthermore, the information sharing platform includes encrypted storage, a log aggregation platform, a database or distributed database, a consortium-type blockchain, and an HSM, and is configured to maintain records of the aforementioned audit records and consent-related information.

[0026] This invention enables the realization of a corporate management support system with a pre-consent verification mechanism that can perform the machine processing of consent verification results, the transition to human judgment, the recording of the basis for the decision, and the preservation of those records as an integrated process. [Effects of the Invention]

[0027] According to this application, by combining a preliminary provisional matching by the consent matching engine in the proposed layer, re-matching in response to timeouts or uncertainties, and forced branching to a human intervention module, output of matching items, mismatching items, weighting coefficients, document references, and decision reasons by the audit trail / explainability module, and record preservation using encrypted storage, blockchain, and HSM in the information sharing platform, the system of this application can ensure a high level of consent compliance, auditability, and explainability in supporting corporate operations.

[0028] Furthermore, even if the terms of agreement are updated or revoked, corrective actions such as notification, suspension, remand, compensation, or requests for additional approval can be retroactively implemented or initiated for the affected cases, thus ensuring the possibility of subsequent correction.

[0029] Therefore, according to this application, it is possible to maintain the processing efficiency of AI while simultaneously achieving the legal and operational controls and accountability required for supporting corporate operations. [Brief explanation of the drawing]

[0030] [Figure 1] Figure 1 is a block diagram showing the overall configuration of a corporate management support system with a pre-consent verification mechanism according to one embodiment of the present invention.

[0031] [Figure 2] Figure 2 is a flowchart showing the matching process flow from receiving the proposed output to calculating the degree of match and branching to automatic execution or human approval request.

[0032] [Figure 3] Figure 3 shows a data model of the pre-consent record structure stored in a consent registry configured on an information sharing platform.

[0033] [Figure 4]Figure 4 shows the sequence of REST APIs used to create, retrieve, update, cancel, search, and retrieve history of consent registries.

[0034] [Figure 5] Figure 5 shows the internal configuration of a decision integration engine that weights and integrates the outputs of multiple AI agents to calculate an integrated confidence score, and then combines this with the consent matching results to generate a decision of approval, conditional approval, hold, or rejection based on the degree of agreement and the integrated confidence score.

[0035] [Figure 6] Figure 6 shows Example 1, in which the consent matching engine is placed after the final decision layer.

[0036] [Figure 7] Figure 7 shows an example 2 in which the consent matching engine is placed in the aggregation layer.

[0037] [Figure 8] Figure 8 shows Example 3, in which the consent matching engine is placed in the proposed layer.

[0038] [Figure 9] Figure 9 shows the retroactive processing sequence in the event of a consent cancellation or renewal.

[0039] [Figure 10] Figure 10 shows an extended configuration including audit trails, security, external collaborations, and multi-corporate collaborations. [Modes for carrying out the invention]

[0040] The embodiments of the present invention will be described below with reference to the drawings. The embodiments described below are examples of the present invention, and the present invention is not limited to these embodiments.

[0041] The present invention relates to a corporate management support system, method, and data structure that uses multiple AI agents to generate proposals regarding a corporation's business or decision-making, checks whether the proposals fall within the scope of pre-agreed consent, and then generates a decision result indicating whether to implement, suspend, or require additional approval.

[0042] In this specification, "information sharing platform" refers to a platform for storing, sharing, synchronizing, auditing, managing evidence trails, and external linking data within a corporate operations support system, and may consist of, or be implemented in combination with, a network, cloud, storage devices such as HDDs or SSDs, a log aggregation platform, secure storage, a database, a distributed database, a blockchain, or an API linking partner.

[0043] Furthermore, in this specification, "consent registry" refers to a component that is logically or functionally configured on the information sharing platform and that holds, updates, cancels, manages the history of, and makes accessible prior consent records.

[0044] In the present invention, a configuration in which multiple AI agents are arranged in layers to generate or integrate proposals can be used. However, the main focus of the present invention is not on the known multi-layer AI integration configuration itself, but rather on the collaborative addition of a consent registry, consent matching engine, decision integration engine, human intervention module, and audit trail / explainability module on an information sharing platform to that configuration.

[0045] According to the present invention, the AI's proposed content can be compared with pre-consent records managed for each entity, and the possibility of automatic execution can be controlled based on the comparison results, thus enabling both the use of AI and corporate control.

[0046] Figure 1 is a block diagram showing the overall configuration of a corporate management support system 100 with a pre-consent matching mechanism according to one embodiment of the present invention. As shown in Figure 1, the system 100 comprises an agent layer including a proposal layer 110, an aggregation layer 120, and a final decision layer 130; an information sharing platform 200A; a consent registry 140 configured on the information sharing platform 200A; a consent matching engine 150; a decision integration engine 160; a human intervention module 170; an audit trail / explainability module 180; an execution engine 190; and an external collaboration group 200.

[0047] The proposal layer 110 is a layer in which multiple AI agents individually generate candidate proposals for the same or similar input problem, and their outputs are sent to the aggregation layer 120. Each AI agent may generate proposals using different models, different parameters, different instruction templates, or different reference data.

[0048] The aggregation layer 120 is a layer that summarizes, compares, integrates, ranks, or reorganizes the multiple candidate proposals obtained from the proposal layer 110. The final decision layer 130 is a layer that selects a final candidate or a small group of final candidates from the candidates received from the aggregation layer 120 and hands over the final candidate or group of final candidates to the decision integration engine 160. The location of the agreement matching engine 150 varies depending on the embodiment and may be located after the decision integration engine 160, in the aggregation layer 120, or in the proposal layer 110.

[0049] The consent registry 140 is logically or functionally configured on the information sharing platform 200A. It functions as an independent data management platform that stores pre-consent records for each subject, and holds consent identifiers, subject identifiers, permitted actions, permitted conditions, validity period, revocation status, signature metadata, version control information, update history, access control information, and storage history information.

[0050] The Consent Matching Engine 150 extracts the content of actions, conditions, scope, counterparty information, regional information, time information, document reference information, and other attributes included in the proposed candidate, aggregated candidate, or final candidate, depending on its location, and calculates the degree of match by comparing them with the corresponding pre-consent record in the consent registry 140. The matching result is used in subsequent aggregation processing, final decision processing, or decision integration processing, depending on its location.

[0051] The decision integration engine 160 takes the final candidate or a small group of final candidates received from the final decision layer 130 as input, integrates the outputs of multiple AI agents with weights to calculate integrated confidence, and, depending on the embodiment, generates a decision of approval, conditional approval, hold, or rejection by combining it with the consent matching result or based on the candidates that have been consent-matched in the previous stage.

[0052] Depending on the embodiment, the human intervention module 170 may receive an additional approval request from the consent matching engine 150 and return an approval or rejection to the consent matching engine 150 based on confirmation by an approver, auditor, or designated authorized person. For example, the additional approval request may be sent when the degree of agreement is below a predetermined threshold, when the cancellation flag is true, or when additional judgment is required to confirm consistency with the consent conditions.

[0053] The audit trail / explainability module 180 generates an audit record that includes matching fields, extraction results, degree of match, weight coefficient, integrated confidence score, decision result, time information, signature hash, hash of the previous record, and optionally explanatory information for the reason for the decision, and records it in the information sharing platform 200A, or records it in an external chain platform via the information sharing platform 200A. Here, the explanatory information for the reason for the decision may be generated or output in at least one of natural language format and machine-readable format.

[0054] The execution engine 190 executes specified corporate business, application, notification, contract processing, payment processing, approval processing, and other target actions only when it is granted automatic execution permission by the decision integration engine 160. The external linkage group 200 may include corporate registration / organization information linkage 210, KYC / IAM linkage 220, legal / internal regulations / contract terms database 230, monitoring agent 270, and multi-corporate linkage gateway 280, etc. Here, KYC means Know Your Customer, and IAM means Identity and Access Management.

[0055] Figure 2 is a flowchart showing the matching process flow from receiving the proposal output to generating a decision result indicating whether to execute, stop, or require additional approval, and to recording an audit record. As shown in Figure 2, first in step S201, the system 100 receives proposal outputs from multiple AI agents. Next, in step S202, the system 100 obtains the corresponding pre-consent record from the consent registry 140 on the information sharing platform 200A.

[0056] In step S203, system 100 normalizes the action details, conditions, scope, counterparty attributes, amount, region, time, document references, and other matching information included in the proposal output. Normalization may include terminology standardization, unit conversion, category conversion, period formatting, and reference identifier resolution.

[0057] In step S204, the consent matching engine 150 compares the normalized proposal information with the prior consent record and calculates at least the behavioral matching degree A, the range overlap degree R, and the time effectiveness index T.

[0058] The action matching score A may be calculated based on whether the proposed action is included in allowed_actions or is allowed as a nearby category. The range overlap score R may be calculated based on the degree of overlap with acceptable conditions such as monetary limits, scope, counterparty attributes, geographical scope, deadline conditions, or documentation conditions. The time effectiveness score T may be calculated based on whether the proposed time or planned execution time falls within the range of effective_from and effective_to.

[0059] In step S205, the consent matching engine 150 calculates the degree of agreement S by, for example, the following formula. (Math. 1) S = α·A + β·R + γ·T Here, α, β, and γ are weighting coefficients, (Math 2) α + β + γ = 1 That is also acceptable.

[0060] In step S206, the decision integration engine 160 calculates the integrated confidence level C based on the output confidence levels c_i and weight coefficients w_i of the multiple AI agents, for example, using the following formula. (Math 3) C = Σ(w_i·c_i) / Σ(w_i)

[0061] In step S207, the decision integration engine 160 comprehensively evaluates the degree of agreement S, the integrated confidence level C, the cancellation flag, the regulation consistency information, the risk score, and the external constraints. For example, if the degree of agreement S is 0.8 or higher, the integrated confidence level C is above a predetermined threshold, the cancellation flag is false, and no significant inconsistencies or high-risk events are detected, automatic execution permission may be granted.

[0062] In step S207, the decision integration engine 160 comprehensively evaluates the degree of agreement S, the integration confidence C, the cancellation flag, the regulations consistency information, the risk score, and the external constraints, and may generate a decision result for the action to be performed that can be expressed as approval, conditional approval, suspension, or rejection, i.e., a decision result indicating whether to perform, suspend, or require additional approval. Here, "perform" includes permission for automatic execution, and "suspend" includes a decision not to perform automatic execution, and such suspension may include suspension, rejection, withholding execution when conditions are not met, or postponing execution until the prescribed requirements are met.

[0063] Furthermore, the "decision result indicating whether additional approval is required" is a concept that includes whether or not an approval request should be generated by the human intervention module 170 to the approver, auditor, or designated authority, and may generate a decision result indicating that additional approval is required if the degree of agreement S is below a predetermined threshold, the integrated confidence C is below a predetermined threshold, the cancellation flag is true, or a timeout or inconsistency detection occurs. The said decision result may be stored as an audit record by the audit trail / explainability module 180 along with the matching result.

[0064] On the other hand, if the degree of match S is less than 0.8, if the integrated confidence score C is below a predetermined threshold, if the cancellation flag is true, or if a timeout or inconsistency detection occurs, the process can branch to the human intervention module 170 to generate a human approval request. Finally, the audit trail / explainability module 180 stores the matched fields, degree of match S, integrated confidence score C, decision result, template identifier used, weight coefficients, time information, and signature hash as an audit record.

[0065] Figure 3 shows the data model of the pre-consent record structure 300 stored in the consent registry 140 configured on the information sharing platform 200A. As shown in Figure 3, the pre-consent record structure 300 includes consent_id 301, principal_id 302, allowed_actions 303, allowed_conditions 304, effective_from 305, effective_to 306, revocation_flag 307, signature_meta 308, consent_version 309, update_history 310, access_control 311, storage_provenance 312, and schema_version 313.

[0066] consent_id 301 is an identifier that uniquely identifies each consent record, and principal_id 302 is an identifier that identifies the entity that gave consent. Note that while policy_id in the prior application can identify approval policy units and function as an identifier for policy or regulation units, consent_id 301 is an identifier that uniquely identifies individual prior consent records, and the two have different roles. allowed_actions 303 is a string array or identifier array indicating the types of actions that are permitted. allowed_conditions 304 may include monetary limits, counterparty attributes, scope of business, geographical scope, deadline conditions, identifiers of referenced laws or internal regulations, or document references.

[0067] `effective_from` 305 and `effective_to` 306 are time information representing the validity period of the consent, and `effective_to` 306 may be a null value if there is no time limit. `revocation_flag` 307 is a boolean value indicating whether the consent has been revoked. `consent_version` 309 is an integer value indicating the update generation, and `update_history` 310 may be implemented as an array or chain structure containing the updater, update time, reason for change, difference information, or previous version reference, etc.

[0068] The signature_meta 308 includes at least the signer identifier signer_id, the signing time signed_at, the signing algorithm signature_algo, and the signature hash signature_hash. The access_control 311 may include information defining read and update permissions based on RBAC or ABAC, where RBAC means Role-Based Access Control and ABAC means Attribute-Based Access Control. The storage_provenance 312 may include the storage location identifier, the registration node identifier, the registration time, the anchor hash, the chain write status, and the encryption method identifier.

[0069] Figure 4 shows the sequence of REST API requests to the consent registry 140. Client 401 sends a request to API gateway 402 that includes Authorization, Content-Type, X-Signature, X-Timestamp, and X-Request-Id. API gateway 402 performs authentication, authorization, signature verification, timestamp verification, and duplicate request prevention, and then delegates processing to consent management service 403.

[0070] The consent management service 403 can create consent records using POST / consents, retrieve them using GET / consents / {consent_id}, update them using PUT / consents / {consent_id}, revoke them using POST / consents / {consent_id} / revoke, search them using POST / consents / query, and retrieve history using GET / consents / {consent_id} / history. The processing results are stored in the consent data store 404 or linked to the audit chain 405 via the information sharing platform 200A.

[0071] In signature verification, the received request body may be normalized, a hash value of the normalized data may be calculated, and the integrity of the signature may be verified using a public key or shared key. Furthermore, duplicate execution of the same request can be prevented by determining whether the value of X-Timestamp is within a predetermined tolerance and whether X-Request-Id does not overlap with past processing history.

[0072] If verification fails, the consent management service 403 may return an error code corresponding to, for example, a missing required field, a time consistency error, authentication failure, insufficient permissions, undiscovered consent, version conflict, signature verification failure, unknown key, or chain write delay.

[0073] Figure 5 shows the internal configuration of the decision integration engine 160. The decision integration engine 160 may include a candidate receiving unit 161, an output evaluation unit 162, a weighting unit 163, an integrated reliability calculation unit 164, a specification consistency evaluation unit 165, a risk evaluation unit 166, and a decision result output unit 167.

[0074] The decision result output unit 167 generates a decision result that can be expressed as approval, conditional approval, deferral, or rejection, i.e., whether to proceed, suspend, or require additional approval, based on the degree of agreement S, integrated confidence C, regulation consistency evaluation, and risk score. [Examples]

[0075] Figure 6 shows an example 1 in which the consent matching engine 150 is placed after the final decision layer 130. Because the matching target can be limited to the final candidate, it is easier to perform highly accurate consent determination while reducing matching costs. For example, α=0.45, β=0.35, γ=0.20, S_th=0.8, C_th=0.75, timeout time of 3 seconds, and re-matching interval of 60 seconds may be set. [Examples]

[0076] Figure 7 shows an example 2 in which the consent matching engine 150 is placed in the aggregation layer 120. The degree of agreement is calculated for each aggregation candidate, and candidate groups with low consent consistency can be excluded or lowered in rank before being sent to the final decision layer 130. For example, α=0.40, β=0.40, γ=0.20, S_th=0.8, C_th=0.75, the timeout period may be 2 seconds, and the re-matching interval may be 30 seconds. [Examples]

[0077] Figure 8 shows Embodiment 3, in which the consent matching engine 150 is placed in the proposal layer 110. For each proposal output generated by the AI ​​agent, an initial matching is performed before sending it to the next stage to exclude candidates below the threshold early, or to regenerate them with correction instructions. For example, the initial provisional threshold may be 0.65, the final threshold in the next stage may be 0.8, α=0.60, β=0.20, γ=0.20, the timeout period may be 1 second, and the re-matching interval may be 15 seconds.

[0078] The embodiments shown in Figures 6 to 8 are examples in which the consent matching engine 150 is positioned differently, but the present invention is not limited to these, and multiple arrangements may be combined. For example, preliminary matching in the proposal layer 110 and final matching in the final decision layer 130 may be used in combination.

[0079] Figure 9 shows the retroactive processing sequence when consent is revoked or renewed. When a user or administrator 901 sends a revocation request or renewal request to the consent management service 403, the consent management service 403 sends a consent version update request to the consent registry 140 and receives the update result.

[0080] Furthermore, the consent management service 403 may send updated audit records to the audit trail / explainability module 180 and send a retrospective job initiation request to the retrospective job 260.

[0081] The retrospective processing job 260 may send a request for impact case extraction and evaluation to the impact assessment unit 261 and send the retrospective processing audit record to the audit trail / explainability module 180.

[0082] The impact assessment unit 261 returns the impact assessment results to the retrospective processing job 260 and registers corrective actions such as notification, suspension, rollback, compensation, additional approval request, and other corrective actions in the corrective action queue 262, which may then send the corrective action registration record to the audit trail / explainability module 180.

[0083] If necessary, the retrospective processing job 260 may send an additional approval request to the consent management service 403, and the consent management service 403 may send an additional approval request to the user or managing entity 901, and after receiving the approval response, send the additional approval response back to the retrospective processing job 260.

[0084] Furthermore, the retrospective processing job 260 may send a correction action completion registration to the correction action queue 262 and a retrospective processing result record to the audit trail / explainability module 180, and the correction action queue 262 may send a correction action completion registration record to the audit trail / explainability module 180.

[0085] The exchange of additional approval requests and approval responses between the consent management service 403 and the user or management entity 901 in Figure 9 may be understood as a specific embodiment or external interface of the manual approval function by the human intervention module 170 shown in Figure 1, etc.

[0086] Figure 10 shows an extended configuration including audit trails, security, external collaboration, and multi-corporate collaboration. The information sharing platform 200A is shown as a configuration that internally includes a multi-corporate collaboration gateway 280, an access control gateway 281, a consent registry 140, a consortium-type blockchain 240, encrypted cloud storage 250, and an HSM 245, while the external collaboration group 200, monitoring agent 270, and audit trail / explainability module 180 may be located outside the information sharing platform 200A.

[0087] Here, the HSM245 may be a hardware security module that protects and performs the generation, storage, use, and disposal of cryptographic keys used for encryption or signature verification in the information sharing infrastructure 200A within tamper-resistant hardware.

[0088] The access control gateway 281 may control access and update permissions for each entity, person in charge, auditor, corporate group, or external contractor based on RBAC and ABAC, and may also perform access control coordination with the multi-corporate linkage gateway 280.

[0089] Furthermore, the access control gateway 281 may perform access monitoring cooperation with a monitoring agent 270 located outside the information sharing infrastructure 200A.

[0090] The monitoring agent 270 may perform periodic audit jobs to detect expired consents, unreflected updates, signature inconsistencies, abnormal access, chain write delays, or audit gaps, and may perform monitoring and audit coordination with the audit trail / explainability module 180.

[0091] The multi-corporate integration gateway 280 may perform external integration with the external integration group 200, and in cases spanning multiple corporations or multiple organizational units, it may select matching records according to consistency rules, while taking into account the different consent_version, schema_version, or access_control for each corporation.

[0092] The consent registry 140 may store consent information in the encrypted cloud storage 250, and the HSM245 may manage encryption keys with the encrypted cloud storage 250 and manage signature verification keys with the consortium-type blockchain 240.

[0093] Furthermore, the consortium-type blockchain 240 may also share audit records with the audit trail / explainability module 180.

[0094] As described above, according to the present invention, in a corporate management support system using multiple AI agents, by providing a consent registry on an information sharing platform and a quantitative consent verification mechanism, the acceptance or rejection of AI proposals can be controlled within the scope of prior consent.

[0095] Furthermore, by incorporating version control, signature metadata, update history, and provenance into consent records, the entire lifecycle, including consent creation, updating, revocation, and retroactive processing, can be managed.

[0096] Furthermore, according to the present invention, by storing the matching target items, degree of agreement, integrated confidence level, decision result, and signature hash as audit records in an information sharing platform, or by recording them to the chain platform via the information sharing platform, explainability and auditability when using AI can be improved.

[0097] It should be noted that the present invention is not limited to the embodiments described above, and components can be added, deleted, replaced, rearranged, or various parameters modified without departing from the spirit of the invention. [Industrial applicability]

[0098] The present invention can be applied to an information processing system, cloud service, or program that implements these, which uses multiple AI agents to generate proposals regarding a corporation's business or decision-making, compares the proposals with pre-consent records, and generates a decision result including approval, conditional approval, deferral, rejection, or additional approval request. In particular, it can be used for application processing, contract processing, payment processing, notification processing, approval processing, internal control, and audit response in corporations, financial institutions, insurance companies, medical corporations, educational institutions, public interest corporations, government agencies, and other organizations.

[0099] Furthermore, the present invention can be implemented in information sharing platforms, consent management platforms, audit trail preservation platforms, or AI governance platforms spanning multiple corporations or organizational units, and can be used in combination with encrypted storage, databases or distributed databases, blockchains, HSMs, access control gateways, or external APIs. Therefore, the present invention can be widely used in industrial fields that require consent compliance management, explainability assurance, audit trail preservation, and post-corrective processing associated with consent renewal or cancellation when using AI. [Explanation of symbols]

[0100] 100 Corporate Management Support System with Prior Consent Verification Mechanism 110 Proposal layer 120 Aggregation Layer 130 Final Decision Layer 140 Consent Registry 150 Consent Matching Engine 160 Decision Integration Engine 161 Candidate receiving unit 162 Output Evaluation Unit 163 Weighting section 164 Integrated Reliability Calculation Unit 165 Regulations Consistency Evaluation Department 166 Risk Assessment Department 167 Decision Result Output Unit 170 Human Intervention Modules 180 Audit Trails / Explainability Module 190 Execution Engines 200 External Collaboration Groups 200A Information sharing platform 210 Corporate Registration and Organizational Information Sharing 220 KYC / IAM Integration (Identity Verification / Customer Verification and Identification / Access Management Integration) 230 Database of Laws, Regulations, and Contract Terms 240 Consortium-type blockchains 245 Hardware Security Module (HSM) 250 Encrypted Cloud Storage 260 retrospective processing jobs 261 Impact Assessment Department 262 Corrective Action Queue 270 Surveillance Agents 280 Multiple Corporate Collaboration Gateway 281 Access Control Gateway 300 Pre-consent record structure 301 Consent identifier (consent_id) 302 Principal identifier (principal_id) 303 List of permitted actions 304 Allowed conditions 305 Effective start time (effective_from) 306 Effective end time (effective_to) 307 Revocation flag (revocation_flag) 308 Signature metadata (signature_meta) 309 Consent version number (consent_version) 310 Update History 311 Access control information (access_control) 312 Storage history information (storage_provenance) 313 Schema version 401 Client 402 API Gateway 403 Consent Management Service 404 Consent Data Store 405 Audit Chain 901 User or Administrator

Claims

1. The system comprises an agent layer that generates multiple proposal outputs by multiple AI agents for actions related to the business or decision-making of a corporation; a consent registry configured on an information sharing platform that stores pre-consent records; a consent matching engine that calculates the degree of agreement by comparing the action content, condition content, and execution time information included in the proposal output with the pre-consent records stored in the consent registry; a decision integration engine that integrates the outputs of multiple AI agents and generates a decision of approval, conditional approval, deferral, or rejection based on the degree of agreement and integrated confidence; a human intervention module that generates a human approval request when the degree of agreement is below a predetermined threshold, when cancellation or expiration is recorded in the pre-consent record, or when a contradiction is detected between the outputs of the multiple AI agents; and an audit trail / explainability module that sequentially records the matching target field, calculated degree of agreement, integrated confidence, decision result, time information, and signature hash as an audit record, and the information sharing platform comprises a network, cloud, storage devices such as HDDs or SSDs, a log aggregation platform, secure storage, and a database. A corporate management support system with a pre-consent verification mechanism, comprising a network, distributed database, blockchain, or API integration partner, or which can be implemented in combination thereof, wherein the pre-consent record stored in the consent registry includes at least a consent identifier (consent_id), principal identifier (principal_id), allowed actions list (allowed_actions), allowed conditions (allowed_conditions), effective start time (effective_from), effective end time (effective_to), revocation flag (revocation_flag), signature metadata (signature_meta), consent version (consent_version), update history (update_history), access control information (access_control), storage history information (storage_provenance), and schema version (schema_version), and is characterized in that the system automatically executes the target action if the degree of agreement and the integrated trust level meet predetermined conditions, and branches to a human approval request if the predetermined conditions are not met.

2. A computer-based method for verifying prior consent regarding the business or decision-making of a corporation, comprising the steps of: receiving multiple proposal outputs regarding an action to be performed from multiple AI agents; obtaining a prior consent record linked to a subject identifier corresponding to the action to be performed from a consent registry configured on an information sharing platform; calculating a degree of agreement by comparing the action content, condition content, and execution time information of the proposal outputs with the list of permissible actions, permissible conditions, and validity period of the prior consent record; calculating an integrated confidence score by integrating the multiple proposal outputs; generating a decision result indicating whether to perform, suspend, or require additional approval for the action to be performed based on the degree of agreement and the integrated confidence score; performing a re-verification or retrospective processing for targets that have already been determined or performed when an update or cancellation of the prior consent record occurs; and recording the verification results and decision results as an audit trail.

3. A pre-consent record structure configured on an information sharing platform and referenced by a computer, comprising: consent identifier, subject identifier, list of permitted actions, permitted conditions, effective start time, effective end time or null value, cancellation flag, signature metadata, consent version, update history, access control information, stored history information and schema version, wherein the signature metadata comprises at least: signer identifier (signer_id), signing time (signed_at), signature algorithm (signature_algo) and signature hash (signature_hash), and the pre-consent record structure is referenced in the corporate management support system with pre-consent matching mechanism described in claim 1 or the pre-consent matching method described in claim 2 for calculating the degree of match and determining whether automatic execution is possible.

4. A system or method according to claim 1 or claim 2, wherein the consent matching engine calculates the degree of agreement based on at least the degree of behavioral agreement, the degree of range overlap, and the time effectiveness index.

5. A system or method according to claim 4, characterized in that execution is permitted when the degree of match is equal to or greater than a first threshold, the cancellation flag is false, and the integrated confidence level is equal to or greater than a second threshold, and the system or method branches to an additional approval request when the degree of match is less than the first threshold or the integrated confidence level is less than the second threshold.

6. A system or method according to claim 1 or claim 2, wherein the decision integration engine calculates an integrated confidence score based on the output confidence score and weight coefficient of each AI agent.

7. The system according to claim 1, wherein the consent matching engine is placed after the outputs of the plurality of AI agents are input to the final decision layer, and calculates the degree of agreement for the final candidate.

8. The system according to claim 1, wherein the consent matching engine is located in an aggregation layer that aggregates the outputs of the plurality of AI agents, and calculates the degree of agreement for each aggregation candidate.

9. The system according to claim 1, wherein the consent matching engine is located in the proposal layer that generates each of the proposal outputs of the plurality of AI agents, and before the subsequent aggregation process, the system is characterized in that it excludes, ranks, or corrects the proposal outputs based on the degree of agreement.

10. The system or pre-consent record structure according to claim 1 or claim 3, wherein the permissible conditions include at least a monetary limit, counterparty attributes, scope of business, geographical scope, deadline conditions, identifiers of referenced laws or internal regulations, or at least a portion of the evidence references.

11. A system or method according to claim 1 or claim 2, characterized in that when an update or cancellation of the prior consent record occurs, a retroactive processing job is initiated, a determined or executed case affected is identified, and at least one of notification, suspension, rollback, compensation, or additional approval request is registered in the corrective action queue.

12. A system or method according to claim 1 or claim 2, wherein the audit trail / explainability module generates an audit record including at least request_id, actor_id, consent_id, prompt_template_id, matched_fields, match score S, decision result, timestamp, signature_hash, and a hash of the most recent audit record, and records the audit record on the information sharing platform, or records it in hash chain format or to a blockchain via the information sharing platform.

13. The system or method according to claim 1 or claim 2, wherein the consent registry comprises a REST API for creating, retrieving, updating, canceling, searching and retrieving the history of consent records, and the REST API accepts at least the headers Authorization, Content-Type, X-Signature, X-Timestamp and X-Request-Id.

14. The system or method according to claim 13, wherein the REST API normalizes the received request body, calculates a hash value, performs signature verification using a public key or shared key, and further performs a determination to prevent duplicate execution of the same request based on the timestamp difference and request identifier.

15. A system or method according to claim 1 or claim 2, wherein the information sharing infrastructure includes at least one of encrypted secure storage, a log aggregation infrastructure, a database, a distributed database, or a consortium-type blockchain, and the cryptographic keys used for encryption or signature verification in the information sharing infrastructure are managed by a hardware security module (HSM).

16. A system or method according to claim 1 or claim 2, characterized in that if the consent matching engine or the decision integration engine cannot complete the determination within a predetermined timeout period, or if uncertainty within a predetermined range is detected, it performs re-matching at each re-matching interval, and if the predetermined number of re-matchings is exceeded, it forcibly branches to a human intervention module.

17. A system or method according to claim 1 or claim 2, wherein the audit trail / explainability module generates and outputs for audit or post-verification information matching agreement items, disagreement items, adopted weighting coefficients, referenced evidence references, and explanations of the reasons for the decisions.

18. The pre-consent record structure according to claim 3, wherein the stored history information includes at least a storage location identifier, a registration node identifier, a registration time, an anchor hash, a chain write status, and an encryption method identifier, wherein the storage location identifier indicates a storage location within the information sharing infrastructure or a storage location accessible via the information sharing infrastructure.

Images