Collaborative AI control system with consent-constrained weight correction and human control

Abstract

When integrating proposals from multiple AIs, this system links consistency with prior consent conditions, confidence scores, weight correction with consent constraints, automatic execution feasibility, and human approval requirements, providing a consent-constrained weight correction collaborative AI control system that allows corporations to maintain human control responsibility. [Solution] The system comprises an information sharing platform, a consent registry, a pre-consent matching engine, a confidence calculation unit, a weight correction unit, a decision integration engine, a human intervention control unit, and an audit trail generation unit. The pre-consent matching engine determines the consent status (accepted / conditionally accepted / unconfirmed / prohibited / expired / withdrawn) for each piece of proposed information, the weight correction unit calculates correction weights according to the consent status, the human intervention control unit controls an automatic execution flag or a human approval request flag based on the consent status, correction weights, and anomaly detection results, and the audit trail generation unit stores audit records including candidate_id, entity_id, reason_code, timestamp, and hash_value in a chain.

Description

Technical Field

[0001] The present invention relates to an information processing technology for integrating proposal information, judgment results, or execution candidates output from a plurality of AI agents or AI modules to control decisions regarding the business actions of a corporation or organization. In particular, when introducing AI into corporate operations, instead of directly automating the execution of AI judgments, the present invention incorporates a human-controllable mechanism into the system structure, and integrally controls by linking pre-agreement conditions, consent status, reliability scores, partial reliability, weighted correction with consent constraints, automatic execution feasibility, and the necessity of human approval. The present invention also relates to a cooperative AI control system that can track `reason_code`, `timestamp`, and `score_breakdown` corresponding to each judgment or control event.

Background Art

[0002] In recent years, in corporate operations, there has been a growing trend to introduce AI into business areas such as contract review, payment instructions, internal approval, personal data handling, external notifications, and regulatory compliance confirmation, and to obtain proposals from a plurality of AI agents or a plurality of judgment modules to enhance business judgment.

[0003] However, when introducing AI into corporate business, simply ranking AI outputs based on prediction accuracy, adoption rate, correct answer rate, or past performance is not sufficient. What a corporation actually demands is not the improvement of AI capabilities itself, but an operating structure in which humans can still fulfill control responsibilities even when using AI.

[0004] That is, in actual corporate operations, even if a certain proposal has a high performance evaluation, it is necessary to simultaneously satisfy control conditions such as whether there is prior consent for the actions targeted by the proposal, whether the consent is still valid, whether it has deviated from the scope of conditional consent, whether revocation or invalidation has occurred, and whether it is not a situation that requires additional approval. Furthermore, the AI's decisions regarding proposal acceptance, automated execution, rejection, postponement, or return must be auditable, allowing humans to verify the rationale behind these decisions at a later date. In this case, relying solely on natural language descriptions can easily lead to problems with subsequent comparison, reproduction, and anomaly detection. Therefore, it is desirable to structure and store at least `reason_code` representing the reason for the judgment, `timestamp` representing the time of the judgment, and `score_breakdown` representing the breakdown of confidence or correction weights.

[0005] Many conventional weighted integration techniques focus on updating weights according to the performance differences of each AI, or on improving the accuracy of integrating multiple outputs. Therefore, it is insufficient in that it incorporates the control structure essential for corporate management—"who can use AI judgment, under what conditions, to what extent, and at what point in time"—into the core of the decision-making flow.

[0006] Furthermore, in configurations where the breakdown of the weight calculation process, the reason code for switching to rejection or postponement, or the time of such switching are not recorded, accountability and audit responses tend to become reactive and fabricated.

[0007] As a result, even if AI's judgments are highly accurate, there are challenges in putting them into practical use from the perspective of legal, internal control, and audit compliance. [Prior art documents] [Patent Documents]

[0008] [Patent Document 1] Japanese Patent Application No. 2026-005527 "AI-assisted corporate management support system"

[0009] This document discloses the overall architecture of a corporate management system equipped with machine-readable articles of incorporation, an AI execution engine, audit nodes, and an information sharing platform. While it provides a basic structure for introducing AI into corporate management, it does not disclose a configuration that integrates a pre-consent verification engine, a confidence calculation unit, a consent-constrained weight correction unit, a human intervention control unit, and an audit trail generation unit, and links the consent status with the confidence score to achieve human control.

[0010] [Patent Document 2] Japanese Patent Application No. 2026-007023 "AI-assisted corporate management support system"

[0011] This document discloses technologies related to the definition of data items such as AI_registry_id, policy_version, proposal_id, and effective_at, version control of approval policies, task generation, and audit trail recording. While it provides a framework for AI execution management within a single legal entity, it does not disclose the configuration that weights proposals from multiple AIs based on confidence scores and consent constraints, allows automation to the extent that human control is possible, or the audit trail generation unit that structures and maintains reason_code, timestamp, and score_breakdown.

[0012] [Patent Document 3] Japanese Patent Application No. 2026-047022 "Corporate Management Support System with Prior Consent Verification Mechanism"

[0013] This document discloses a consent management system equipped with features for verifying prior consent conditions, confirming the integrity of supporting documents, and audit support. While it provides a basic mechanism for acquiring, verifying, and recording consent status, it does not disclose features for calculating the confidence level of multiple AI proposals, weighting adjustments linked to consent constraints, switching between automatic execution, rejection, and postponement by a human intervention control unit, or generating structured audit trails.

[0014] [Patent Document 4] U.S. Patent No. 11615331 (US11615331B2)

[0015] "Explainable AI technique"

[0016] A patent related to explainable AI technology. It discloses a technology for visualizing the decision-making process of AI, but does not disclose the configuration for linking the prior consent conditions, changes in the consent status, weight correction conditions, and human control in corporate operations.

[0017] [Patent Document 5] U.S. Patent No. 11281232 (US11281232B2)

[0018] "Methods and systems for multi-agent system control"

[0019] A patent related to a multi-agent control system. It discloses the cooperative control of multiple AI agents, but does not describe the weight correction based on consent constraints, the linked control of the human approval request flag, and the structured maintenance of the audit trail. [Non-Patent Document]

[0020] [Non-Patent Document 1] B.J. Evans, A. Bihorac, "Co-creating Consent for Data Use - AI-Powered Ethics", NIH PMC, 2024

[0021] https: / / pmc.ncbi.nlm.nih.gov / articles / PMC12412891 /

[0022] Ethical considerations regarding consent management using AI. It discusses the co-creation of consent in data use, but does not describe the control responsibilities in corporate operations, the weight correction conditions, and the linkage of the executability of automation.

[0023] [Non-Patent Document 2] E. Papagiannidis et al., "Responsible artificial intelligence governance: A review", ScienceDirect, 2025

[0024] https: / / www.sciencedirect.com / science / article / pii / S0963868724000672

[0025] This is a review paper on responsible AI governance. While it comprehensively discusses the framework of AI governance, it does not address the linkage between consent constraints and confidence scores, or the automatic switching of remands and hold-offs by human intervention control units.

[0026] [Non-Patent Document 3] V. Conitzer et al., "Consent as a Foundation for Responsible Autonomy", AAAI-22, 2022

[0027] https: / / ojs.aaai.org / index.php / AAAI / article / view / 21501

[0028] This paper discusses responsible autonomy based on consent. While it provides a theoretical framework for ethical autonomy, it does not show the implementation configuration of the pre-consent verification engine, weighting adjustment unit, and audit trail generation unit in corporate operations. [Overview of the project] [Problems that the invention aims to solve]

[0029] The problem that this invention aims to solve is to embed a structure into the system components that allows a corporation to utilize the judgment capabilities of AI while retaining ultimate control responsibility when introducing AI into its business operations. More specifically, it aims to provide a technology that does not simply mechanically integrate proposals obtained from multiple AI agents or AI modules based on performance history, but rather links pre-consent conditions, changes in consent status, time validity, weight correction conditions, automatic execution feasibility, and human approval requirements for each target action, allowing automation only within a controllable scope, and appropriately switching to human confirmation, approval, rejection, or postponement otherwise.

[0030] Furthermore, an objective of this invention is to enable, through audit records, the reasons why a proposal was adopted, why automated execution was permitted, or why it was switched to human approval, rejection, or postponement after a corporation has implemented AI. This aims to simultaneously improve performance, explainability, controllability, auditability, and clarification of responsibility boundaries in business operations after AI implementation. In particular, by recording `reason_code`, `timestamp`, and `score_breakdown` for each event, the aim is to enable subsequent anomaly analysis, recalculation, rejection decisions, and responsibility tracking using a consistent data structure. [Means for solving the problem]

[0031] The collaborative AI control system according to the present invention comprises at least an information sharing platform, a consent registry, a pre-consent verification engine, a confidence calculation unit, a weight correction unit, a decision integration engine, a human intervention control unit, and an audit trail generation unit.

[0032] The information sharing platform acquires proposal information, reasoning information, trust-related information, target action type, target data type, and related metadata from multiple AI agents or AI modules regarding the target action, and stores them in a shareable format. At this time, each proposal information or integration candidate is assigned a `candidate_id`, the proposing or decision-making entity is associated with an `entity_id`, the proposal or acquisition time is assigned a `timestamp`, and a `reason_code` indicating the reason for the proposal or control can be stored.

[0033] The consent registry records the target action, target entity, target data, target party, acceptance conditions, conditional acceptance conditions, expiration date, withdrawal history, grounds for revocation, reference rules, and auxiliary information necessary for determination. In this case, the applied version of the consent conditions, weight adjustment conditions, or approval conditions is recorded as `policy_version`, the time when the consent status is determined or a state transition occurs is stored as `timestamp`, and the basis for the determination can be recorded as `reason_code`.

[0034] The pre-consent matching engine, for each piece of proposal information, refers to the consent registry to determine which of the following consent states it belongs to: accepted, conditionally accepted, unconfirmed, prohibited, expired, or withdrawn. When making this determination, the engine can output the `entity_id` corresponding to the entity being determined, the `policy_version` of the applied consent determination conditions, the `timestamp` at the time of determination, and the `reason_code` representing the basis for the determination.

[0035] The reliability calculation unit calculates a reliability score for each AI agent or AI module based on past case acceptance rates, agreement rates, output consistency rates, and other evaluation factors, and can further calculate partial reliability for each type of action or processing type. Not only the overall reliability score or partial reliability, but also its components, contribution rates, attenuation reflection results, or pre- and post-correction comparisons can be stored as `score_breakdown`, and the calculation or update time can be attached as `timestamp`.

[0036] The weight correction unit applies at least one of the following to the weights based on the confidence score or partial confidence score: an upper limit, a lower limit, a decay rate, an exclusion condition, or a weight correction condition, according to the consent status, time validity, or reference rule specified by `policy_version` determined by the pre-consent matching engine, and calculates the corrected weights. At this time, the breakdown before and after correction, the reason for correction, and the details of exception handling can be stored as `score_breakdown` and `reason_code`, and the time of application can be managed as `timestamp`.

[0037] The decision integration engine integrates multiple proposal information based on the correction weights and determines whether to accept, rank, or execute the target action. The decision integration engine can refer to the `candidate_id` assigned to each proposal information or integration candidate, maintain the evaluation breakdown of the integration target as `score_breakdown`, record the reason for branching to acceptance, rejection, return, postponement, or re-examination as `reason_code`, and output the time of the decision as `timestamp`.

[0038] The human intervention control unit controls whether automated execution is permitted or whether human approval is required, based on the consent status, correction weights, anomaly detection results, `reason_code`, `timestamp`, or predetermined control conditions, and switches to rollback, postponement, or re-examination as necessary. For example, the reason for setting the human approval request flag, the reason for rollback, the reason for postponement, or the reason for additional approval is managed as `reason_code`, and the time when such a switch occurs is recorded as `timestamp`.

[0039] The audit trail generation unit generates audit records that associate proposed information, `candidate_id`, `entity_id`, agreement status, confidence score, `score_breakdown`, adjustment weights, decision result, `reason_code`, `timestamp`, `policy_version`, and human control details, and stores them in a time-series and tamper-detectable format. Each audit record or candidate record is assigned a `hash_value`, and can be linked and stored in a chain as needed, associated with the corresponding `hash_value` of the preceding and succeeding audit records. [Effects of the Invention]

[0040] According to the present invention, when a corporation introduces AI into its business operations, it can implement a control structure as a system that not only ranks proposals from multiple AIs based on mere performance indicators, but also links pre-consent conditions, consent status, time effectiveness, weight correction, automatic execution feasibility, and human approval requirements.

[0041] This allows, firstly, humans to retain control responsibility even after AI implementation. Secondly, automation can be advanced only to cases that meet control conditions. Thirdly, cases that do not meet control conditions can be appropriately switched to human approval, return, or postponement. Fourthly, each decision process is stored in an auditable, cascaded manner, making post-mortem verification, accountability, and internal control compliance easier. Furthermore, by structuring and storing `reason_code`, `timestamp`, and `score_breakdown`, the reason for each decision, the time of the decision, and the score breakdown can be recorded in a comparable manner, allowing for more precise anomaly investigations, re-evaluations, and audit reports in the future. [Brief explanation of the drawing]

[0042] [Figure 1] Figure 1 is a block diagram showing the overall configuration of a weight-corrected collaborative AI control system with consent constraints according to an embodiment of the present invention.

[0043] [Figure 2] Figure 2 is a flowchart showing the integrated processing flow of suggestion information from multiple AIs in the same embodiment.

[0044] [Figure 3] Figure 3 is a class diagram showing the data structure of the audit record in the same embodiment.

[0045] [Figure 4] Figure 4 is a flowchart showing the detailed flow of the agreement status determination and weight correction process in the same embodiment. [Modes for carrying out the invention]

[0046] 1. Overall structure (see Figure 1)

[0047] As shown in Figure 1, the collaborative AI control system of the present invention comprises an information sharing platform for aggregating proposals from multiple AIs, a consent registry for holding prior consent conditions, a prior consent matching engine for determining consistency with said consent conditions, a confidence calculation unit for calculating a confidence score based on the history of each AI, a weight correction unit for constraining weights according to the consent status, a decision integration engine for integrating proposals based on the corrected weights, a human intervention control unit for controlling whether a case is subject to automatic execution or human approval, and an audit trail generation unit for storing a series of judgment results.

[0048] This configuration allows the present invention to treat the following as a single control flow, rather than simply adopting the AI ​​output: "Does it conform to the agreement?", "How much weight should be assigned?", "Should automated execution be allowed?", "Should it be forwarded to human approval?", and "Should it be returned or put on hold in case of an anomaly?". Furthermore, each control flow maintains at least the reason for the decision as `reason_code`, the time of the decision as `timestamp`, and the breakdown of the weight or confidence level as `score_breakdown`, thereby enabling post-verification.

[0049] 2. Confidence score and partial confidence level

[0050] The confidence calculation unit (see Figure 1) can calculate a confidence score for each AI agent or AI module based on at least two of the following: acceptance rate, match rate, and output consistency rate from past cases. Furthermore, when updating the confidence score, time decay, exponential moving average, or a combination thereof can be applied to gradually reduce the contribution of older performance data. At this time, each contributing element before and after the update, the decay coefficient, exception correction, and the percentage of reflection in the final score are saved as `score_breakdown`, and the update date is managed as `timestamp`.

[0051] Furthermore, the confidence calculation unit can calculate partial confidence for each type of action or processing included in the target action. Partial confidence is calculated based on at least one of the following: past adoption history, judgment consistency history, output consistency history, agreement status, time validity, or reference rule corresponding to the type of action or processing. The primary factor used in the calculation is stored as `score_breakdown`, and branching factors such as below the threshold, insufficient history, waiting for re-verification, etc., can be indicated by `reason_code`.

[0052] If a single target action falls under multiple action or processing categories, the partial confidence level corresponding to the most stringent action or processing category is prioritized, or multiple partial confidence levels can be integrated according to a predetermined merging rule. This allows the legal entity to switch the contribution of AI proposals according to the required level of control for each target action. The composition ratio of partial confidence levels in this integration process can be tracked using `score_breakdown`.

[0053] 3. Consent status and weight adjustment with consent constraints (see Figure 4)

[0054] As shown in Figure 4, the pre-consent matching engine is configured to determine at least one of the following consent statuses for each proposed piece of information: acceptable, conditionally acceptable, unconfirmed, prohibited, expired, and withdrawn. Each determination is associated with the subject being determined, the applicable rule version, the basis for the determination, and the time of determination, with at least the basis for the determination being structured as `reason_code` and the time of determination as `timestamp`.

[0055] The weight correction unit maintains different weight upper limits, weight lower limits, attenuation rates, exclusion conditions, or weight correction conditions for each agreement state. In the acceptable state, weights are allowed within the range of automatic execution; in the conditionally acceptable state, the weight upper limit is restricted; in the unconfirmed, expired, or withdrawn state, weights are corrected in a way that suppresses automatic execution; and in the prohibited state, candidates can be excluded from integration. At this time, the conditions, the extent, and which candidates were corrected are recorded as `score_breakdown`, the reason for the correction is saved as `reason_code`, and the time of correction is saved as `timestamp`.

[0056] 4. Applying the changes to multiple control points (see Figure 2)

[0057] In the integrated processing flow shown in Figure 2, the corrected weights or weight correction conditions by the weight correction unit are reflected in at least two of the following control points: proposal acceptance / rejection judgment, proposal ranking, integrated confidence calculation, threshold judgment, automatic execution feasibility judgment, and human approval request judgment.

[0058] Therefore, the weight correction in this invention is not merely an auxiliary calculation for updating the internal score, but has a controlling effect that changes the final course of business processing itself. For example, even for the same proposal, if it is in a conditionally permissible state, it can not only be lowered in rank, but automatic execution can be disabled and human approval can be made mandatory. In this case, the breakdown of the rank reduction, the content of the threshold failure, and the reason for making approval mandatory are recorded in `score_breakdown` and `reason_code`, and the application time at each control point is recorded as `timestamp`.

[0059] 5. Expiration date, recalculation, and automatic execution stop.

[0060] The confidence score, adjusted weights, or weight adjustment conditions are subject to recalculation or reconfirmation in response to the passage of a specified period, renewal or cancellation of the consent status, failure to satisfy the time validity requirement, or the occurrence of a request for re-verification.

[0061] Until the recalculation or reconfirmation is completed, the human intervention control unit will set the automatic execution flag for the case in a stopped state and enable the human approval request flag as needed. This prevents past confidence levels or weight correction results from being directly carried over to automatic processing when significant changes in corporate operational conditions occur. The reason for starting the recalculation, the reason for waiting for reconfirmation, and the reason for allowing resumption are stored as `reason_code`, the start and completion times are managed as `timestamp`, and the updated breakdown is saved as `score_breakdown`.

[0062] 6. Audit trail, anomaly detection, and failover control (see Figure 3)

[0063] In the audit record data structure shown in Figure 3, the audit trail generation unit can generate an audit record that includes a `candidate_id` indicating a proposal or merger candidate, an `entity_id` indicating the entity involved in the proposal or merger candidate, the agreement status, applied weighting conditions, confidence score, `score_breakdown`, decision result, human control information, `reason_code`, and `timestamp`, and can store it in association with preceding and succeeding audit records. Each audit record is assigned a `hash_value`, and a chain structure can be formed that references the `hash_value` corresponding to the preceding audit record as needed.

[0064] Furthermore, the audit trail generation unit or anomaly detection unit adds integrity verification information or signature information to the audit record and generates warning information if a chain inconsistency in `hash_value`, a subsequent change in the consent status, a change in the applied weight correction conditions, an inconsistency with the consent registry, or a predetermined anomaly judgment condition is detected. At this time, the type of anomaly, the trigger for detection, the scope of impact, and the necessary measures are stored as `reason_code`, the detection time is recorded as `timestamp`, and the evaluation breakdown that led to the anomaly judgment can be saved as `score_breakdown`.

[0065] The human intervention control unit can, in response to the warning information, disable the automatic execution flag for the case, and switch to a return, postponement, or additional approval request. This allows the audit trail to function not merely as a record for post-incident explanation, but as an active control mechanism that pulls processing back to human control in the event of an anomaly. The reason for the halt is recorded in `reason_code`, preventing accidental "stopping for no apparent reason" incidents.

[0066] 7. Examples [Examples]

[0067] Integration of proposed contract amendments (see Figures 1 and 2)

[0068] In the system configuration shown in Figure 1, when multiple AI agents propose contract amendments, the information sharing platform receives the content of each proposal and its associated metadata, and assigns a `candidate_id` to each proposal. According to the integrated processing flow shown in Figure 2, the pre-consent verification engine refers to the consent registry for the target business partner and the target contract, and determines that Proposal A is acceptable, Proposal B is conditionally acceptable, and Proposal C is unconfirmed. This judgment result is associated with a `timestamp` indicating the time of the judgment and a `reason_code` indicating the basis for the judgment. The weight correction unit maintains the normal weight for proposal A, applies the upper weight limit for proposal B, sets the automatic execution flag to no for proposal C, and records the correction breakdown as `score_breakdown`. The decision integration engine calculates the integrated confidence score for proposals A and B, sets the human approval request flag due to the existence of proposal C, and outputs conditional approval. At this time, the reason for the conditional approval is stored as `reason_code`, and the decision date is recorded as `timestamp`. [Examples]

[0069] Partial confidence levels by type of transaction in payment orders (see Figure 1)

[0070] In the confidence calculation unit shown in Figure 1, for payment orders, a partial confidence score limited to payment operations is used for each AI agent. Even if an AI has received a high rating in past contract reviews, if the agreement rate in payment orders is low, a low raw weight will be calculated. Furthermore, if it is determined to be conditionally acceptable or unconfirmed in light of the payment amount, counterparty attributes, agreement conditions, or time validity, the weight correction unit can suppress automatic execution and activate the human approval request flag. In this case, the calculation elements and correction results for the partial confidence score are stored as `score_breakdown`, the reason for the approval request is stored as `reason_code`, and the request time is stored as `timestamp`. [Examples]

[0071] Decision on providing personal data to a third party (see Figure 4)

[0072] In the consent status determination flow shown in Figure 4, if the consent previously granted for a proposal regarding the provision of personal data to a third party has been revoked in the consent registry, the proposal is determined to be in a revoked state. The weight correction unit sets the automatic execution flag for the proposal to "no," and excludes it from integration or reduces its contribution as necessary. The human intervention control unit presents the person in charge with the withdrawal history, proposal summary, and anticipated impact, and requests a manual decision. At this time, the basis for the withdrawal status determination, the reason for exclusion, and the reason for the manual decision request are stored as `reason_code`, each processing point is recorded as `timestamp`, and the contribution comparison before and after exclusion can be tracked using `score_breakdown`. [Examples]

[0073] Recalculation upon expiration (see Figures 1 and 2)

[0074] In the system shown in Figure 1, if an expiration date is set for the confidence score or correction weight of a certain AI agent, the confidence calculation unit or weight correction unit will recalculate or re-verify the value once the expiration date has been exceeded. In the integrated processing flow shown in Figure 2, during this time, automatic execution is stopped for the target case, and a flag requesting human approval is set. Automatic execution can be allowed again only if the agreement status and trust level meet the predetermined conditions after reconfirmation. The reason for suspension due to exceeding the deadline, the reason for completion of reconfirmation, and the reason for allowing resumption are managed as `reason_code`, each point in time is recorded as `timestamp`, and the values ​​before and after recalculation are stored as `score_breakdown`. [Examples]

[0075] Processing when an audit anomaly is detected (see Figure 3)

[0076] In the audit record data structure shown in Figure 3, if the audit trail generation unit or anomaly detection unit detects an inconsistency in the `hash_value` chain with past audit records, a retroactive change in the agreement status, or an unauthorized change in the weight correction conditions, it immediately switches the automatic execution flag for the relevant case to no and sets the human approval request flag. The person in charge will refer to the consent matching results, applicable weighting conditions, anomaly detection results, and `score_breakdown` on the audit trail, and, if necessary, roll back, withhold, re-examine, or grant additional approval to the decision. In this case, the type of anomaly and the reason for the action taken are saved as `reason_code`, and the time of anomaly detection and the time of action taken are recorded as `timestamp`. (Definition of terms)

[0077] Consent Status: A status assigned as a result of matching by the pre-consent matching engine, including at least: Accepted, Conditionally Accepted, Unconfirmed, Prohibited, Expired, and Withdrawn.

[0078] Partial confidence level: This refers to the confidence level calculated for a specific type of action or processing.

[0079] Consent-constrained weighting: This refers to a weighting process that applies upper limits, lower limits, attenuation, exclusion, or switching conditions to weights based on confidence scores or partial confidence levels, depending on the consent status, time validity, or reference rules.

[0080] Automatic execution flag: This flag indicates whether or not the target project can be executed automatically without human intervention.

[0081] Human Approval Request Flag: This flag indicates that confirmation or approval by a person in charge is required when there are unconfirmed, expired, withdrawn, incomplete re-verification, anomaly detection, or other control conditions.

[0082] Human control: This refers to ensuring, both institutionally and systemically, that a human being, as the responsible entity of the corporation, can approve, reject, withhold, prohibit, or re-examine AI proposals or automated execution candidates.

[0083] `reason_code`: A structured code representing the reason for a decision, rejection, exclusion, hold, re-examination, anomaly detection, or approval request. It may be presented alongside the natural language reason, but it is preferable that it be maintained as at least a comparable code value.

[0084] `timestamp`: This refers to time information indicating the point in time when a judgment, update, correction, switch, anomaly detection, or audit record generation occurred. It is preferable that it be stored in UTC or with an explicit time zone.

[0085] `score_breakdown` refers to structured data representing the breakdown of confidence scores, partial confidence scores, adjusted weights, or integrated assessments. It is desirable to retain not only the overall score but also the main components, contribution rates, attenuation reflections, or pre- and post-adjustment comparisons. [Industrial applicability]

[0086] The collaborative AI control system with consent-constrained weight correction and human control according to the present invention is widely applicable in the fields of collaborative AI control and corporate management support.

[0087] Specifically, the following industrial applications are envisioned: (1) Decision control regarding business activities such as contract review, payment instructions, internal approval, and handling of personal data within corporations. (2) Integration of suggestion information from multiple AI agents or AI modules (3) Control of automated execution and human approval based on prior consent conditions and confidence scores (4) Corporate management AI system with auditability

[0088] Thus, the present invention contributes to the practical application of AI technology in corporate management and has industrial value from the standpoint of improving operational efficiency, enhancing transparency, and strengthening compliance. [Explanation of symbols]

[0089] 10. Entire System 11 Information sharing infrastructure 12 Consent Registry 21. Pre-consent verification engine 22. Confidence Calculation Unit 23 Weight Correction Unit 24 Decision Integration Engine 25 Human Intervention Control Unit 26. Audit Trail Generation Unit 31 Proposal Acquisition Process 32 Consent Verification Process 33. Confidence Calculation Process 34. Weight Correction Process 35. Integration Judgment Process 36. Human intervention determination process 37 Audit Record Generation Process 41. Entire audit record 42 Entity ID 43 Timestamp 44 hash values 45 Policy Versions 46 Candidate IDs 47 Selection candidate ID 48 Score breakdown 49 Reason Code 51. Confirmation of Agreement Step 52 Steps to obtain confidence 53 Correction Weight Calculation Step 54. Integrated Weight Update Step 55. Step to determine whether automatic execution is possible. 56 Audit Record Output Step

Claims

1. An information sharing platform that acquires suggested information regarding target actions from multiple AI agents or AI modules, A consent registry records the prior consent conditions corresponding to the aforementioned target action, associated with at least an `entity_id` indicating the entity to which the prior consent conditions apply, a `policy_version` indicating the applied version of the prior consent conditions, weighting adjustment conditions, or approval conditions, an expiration date, withdrawal history, and reference conditions. For each of the aforementioned proposal information, a pre-consent matching engine determines the consent status by referring to the consent registry, A reliability calculation unit calculates a reliability score based on the past adoption or compatibility record for each AI agent or AI module, and stores the breakdown of the reliability score as `score_breakdown`. A weight correction unit calculates corrected weights by applying at least one of an upper limit, lower limit, attenuation rate, or exclusion condition to the weights derived from the confidence score, according to the agreement status. A decision integration engine assigns a `candidate_id` to each of the proposed information or the integration candidates generated from said proposed information, integrates the proposed information based on the correction weight, and determines whether to accept, rank, or execute the target action. A human intervention control unit controls whether automatic execution is possible or whether human approval is required, according to the agreement status, the correction weight, the anomaly detection result, the `policy_version`, or predetermined control conditions. An audit trail generation unit associates the proposed information, the `candidate_id`, the `entity_id`, the agreement status, the confidence score, the `score_breakdown`, the correction weight, the decision result, the `reason_code`, the `timestamp`, the `policy_version`, and the content of the human control, and further assigns a `hash_value` corresponding to each audit record or candidate record, and saves them as audit records. A collaborative AI control system characterized by having the following features.

2. The collaborative AI control system according to claim 1, wherein the reliability calculation unit calculates a reliability score for each AI agent or AI module based on at least two of the following: acceptance rate, agreement rate, and output consistency rate in past cases, manages the calculation results for each `entity_id` corresponding to the AI ​​agent or AI module, and maintains the breakdown of the reliability score as `score_breakdown`.

3. The cooperative AI control system according to claim 2, wherein the reliability calculation unit, when updating the reliability score, applies time decay, exponential moving average, or a combination thereof to change the contribution of past performance over time, and maintains a `timestamp` indicating the update time, a `policy_version` of the applied update condition, and a `score_breakdown` indicating the breakdown after the update.

4. The confidence calculation unit calculates a partial confidence level for at least one of the following: past adoption history, judgment consistency history, output consistency history, agreement status, time validity, or reference rule specified by the `policy_version`, for each type of action or processing type. The weight correction unit switches the corrected weights or weight correction conditions according to the partial confidence level and stores the breakdown as `score_breakdown`. If a single target action falls under multiple action types or processing types, the partial confidence level corresponding to the most stringent action type or processing type is prioritized, or multiple partial confidence levels are integrated according to a predetermined merging rule, for each integration target or candidate. A collaborative AI control system according to any one of claims 1 to 3, which associates a `candidate_id`. The confidence calculation unit can calculate a partial confidence score for each type of action or processing included in the target action. Partial confidence is calculated based on at least one of the following: past adoption history, judgment consistency history, output consistency history, consent status, time validity, or reference rule corresponding to the type of action in question. For cases that fall under multiple types of actions, the partial confidence corresponding to the most stringent type of action is prioritized, or they can be combined according to the prescribed blending rules. This allows corporations to adjust the degree of AI-driven contribution to each specific action, while ensuring that stricter conditions for human control are not overlooked and reflected in their decision-making processes.

5. The aforementioned pre-consent verification engine is configured to determine at least the following states as the consent status: permitted, conditionally permitted, unconfirmed, prohibited, expired, and revoked. The collaborative AI control system according to any one of claims 1 to 4, wherein the audit trail generation unit includes in the audit record a `reason_code` indicating the basis for determining the consent state, a record identifier, a `timestamp` indicating the time of determination, the cause of the state transition, a `policy_version` applied to the determination, and an `entity_id` indicating the subject of the determination.

6. The weight correction unit maintains different weight upper limits, weight lower limits, attenuation rates, or exclusion conditions for each agreement state, and manages these conditions in association with the `policy_version`. For acceptable states, weights are allowed within the range of automatic execution; for conditionally acceptable states, the aforementioned weight limit is restricted; for unconfirmed, expired, or withdrawn states, the weights are adjusted in a direction that suppresses automatic execution; and for prohibited states, they are excluded from the integration target corresponding to the `candidate_id`. A collaborative AI control system according to any one of claims 1 to 5, wherein the breakdown of the correction result or exclusion result is stored as `score_breakdown`.

7. The human intervention control unit sets an automatic execution flag or a human approval request flag based on the consent status and the correction weight. If the aforementioned consent status is unconfirmed, expired, or withdrawn, or if the prescribed re-verification or abnormality check has not been completed, the human approval request flag is set, and if the aforementioned consent status is prohibited, the automatic execution flag is disabled. A collaborative AI control system according to any one of claims 1 to 6, which outputs a `reason_code` indicating the reason for the setting or disabling, a `timestamp` indicating the time of setting, and a `candidate_id` indicating the target candidate to the audit record.

8. The corrected weights or weight correction conditions from the weight correction unit are reflected in at least two control points among the proposal acceptance / rejection judgment, proposal ranking, integrated confidence calculation, threshold judgment, automatic execution feasibility judgment, and human approval request judgment. The target candidate at each control point is identified by `candidate_id`, the version applied to that control point is identified by `policy_version`, and the breakdown of the judgment for each control point is stored as `score_breakdown`. A collaborative AI control system according to any one of claims 1 to 7, used for controlling the switching from automated execution to human approval in accordance with the consent status or predetermined control conditions. The corrected weights or weight correction conditions applied by the weight correction unit are reflected in at least two of the following control points: proposal acceptance / rejection judgment, proposal ranking, integrated confidence calculation, threshold judgment, automatic execution feasibility judgment, and human approval request judgment. Therefore, weight adjustments are not limited to internal ranking adjustments, but also control the control pathway itself—whether to proceed with automated execution or switch to human approval for a case.

9. The confidence calculation unit or the weight correction unit shall recalculate or reconfirm the confidence score, the corrected weight, or the weight correction conditions in accordance with at least one of the following: the passage of a predetermined period, the renewal or cancellation of the consent status, the failure to satisfy the time validity requirement, or the occurrence of a request for re-verification. Until the recalculation or reconfirmation is complete, the automated execution will be stopped, or the human approval request flag will be enabled. A collaborative AI control system according to any one of claims 1 to 8, which holds a `reason_code` indicating the reason for initiating the recalculation or reconfirmation, a `timestamp` indicating the start and completion times, a `policy_version` of the applied reconfirmation conditions, and a `score_breakdown` indicating the updated breakdown. The confidence score, adjusted weights, or weight adjustment conditions are subject to recalculation or reconfirmation in response to the passage of a specified period, renewal or cancellation of the consent status, failure to satisfy the time validity requirement, or the occurrence of a request for re-verification. Until recalculation or reconfirmation is complete, the case will be excluded from automated execution, and the human approval request flag will be activated. This prevents changes in corporate operational conditions from directly impacting AI-driven automated processing, and allows for human intervention as needed.

10. The audit trail generation unit generates a record for each audit record that includes at least a `candidate_id` indicating a proposed or merged candidate, an `entity_id` indicating an entity involved in the proposed or merged candidate, the agreement status, the weighting conditions applied, the confidence score, the `score_breakdown`, the decision result, the `reason_code`, the `timestamp`, the `policy_version`, and human control information. A collaborative AI control system according to any one of claims 1 to 9, which stores the `hash_value` corresponding to the record in question in association with the `hash_value` corresponding to the preceding and succeeding audit records.

11. The audit trail generation unit or anomaly detection unit assigns a `hash_value`, integrity verification information, or signature information corresponding to the audit record. At a minimum, if any of the following occurs: a chain inconsistency in the `hash_value`, a post-facto change in the consent status, a change in the applied weight correction conditions, an inconsistency with the consent registry, or the detection of a predetermined abnormality determination condition, a warning information is generated, the human intervention control unit disables the automatic execution flag for the case, and switches to a rollback, hold, or additional approval request. The collaborative AI control system according to claim 10, wherein the `reason_code` indicating the type of anomaly, the `timestamp` indicating the time of anomaly detection, the `policy_version` applied to the anomaly determination, the `candidate_id` indicating the target candidate, the `entity_id` indicating the target entity, and the anomaly detection result are stored in a chain as the audit record. The audit trail generation unit or anomaly detection unit adds integrity verification information or signature information to the audit record and generates warning information if it detects an inconsistency in the hash chain, a post-mortem change in the consent status, a change in the weight correction conditions, an inconsistency with the consent registry, or a predetermined anomaly judgment condition. Furthermore, the human intervention control unit disables the automatic execution flag for the case and switches to rollback, hold, or additional approval request. In this way, the audit trail functions not merely as a record for post-mortem verification, but as an active control mechanism to bring processing back to human control in the event of anomalies.

Images