User management system and method based on intelligent data set

Abstract

The invention provides a user management system and method based on an intelligent data set, relates to the technical field of Internet data processing, and aims to predict user intentions according to user operation behaviors and recommend compliance paths in advance to perform compliance guidance. Real-time rule matching is carried out on the operation request and the legal requirement knowledge graph through the risk reasoning agent, whether the operation request conflicts with legal data, user data and contract data or not is judged, compliance decision making is carried out according to the conflict type, compliance risk prediction is carried out according to the execution result of compliance decision making, and decision making suggestions are generated; according to the method, compliance check is seamlessly embedded into each key node of a business process, so that beforehand guidance, in-event real-time blocking and intelligent correction and post-event risk prediction and decision suggestion of violation operation are realized, the occurrence probability of violation events is greatly reduced, an administrator is liberated from heavy post-event auditing work, and the working efficiency is improved. The method focuses on strategic risk early warning and decision.

Description

Technical Field

[0001] This invention relates to the field of Internet data processing technology, specifically to a user management system and method based on intelligent datasets. Background Technology

[0002] Currently, existing management systems for user management and data processing involving contracts generally adopt role-based access control models. These models define system permissions by pre-assigning static roles to users, such as legal specialists and project managers. Furthermore, compliance reviews of contracts and legal documents often rely on post-event batch checks or manual audits. Relevant compliance rules exist in a discrete, hard-coded strategy format, which presents two problems in practical use. First, static permission models cannot respond to the dynamic risk changes of data objects with varying levels of sensitivity. For example, the dynamic risk changes during transactions between ordinary administrative agreements and core trade secret contracts lead to permission settings that are either too broad, introducing security risks, or too strict, impacting business efficiency. Second, the delayed, manual compliance review cannot intervene in real-time when users perform specific operations, such as sending or sharing files. The system lacks a deep understanding of the operational context and legal semantics, leaving management in a passive response state, failing to meet the real-time, intelligent risk control needs of modern enterprises. In summary, existing user data management for legal contract categories has the following problems: Problem 1: User permission allocation is preset and fixed, and cannot be adaptively adjusted according to the legal risks of the user's current operation object, operating environment, etc. This results in a fixed range of user permissions when handling highly sensitive legal contracts and ordinary documents, making it impossible to control permissions accurately in real time. It requires layers of manual approval, which seriously reduces business efficiency. The second problem is the lack of digital understanding of legal provisions and contract terms. When conducting compliance checks, the system often uses post-event triggering or simple keyword triggering, which leads to untimely monitoring and a high risk of misjudgment. The system is unable to proactively assess and provide real-time guidance and blocking throughout the entire process of initiating, conducting, and ending operations, resulting in a lack of risk control in user operation management, low security, and an inability to provide pre-event warnings and in-event blocking of risks. Summary of the Invention

[0003] To achieve the above objectives, the present invention provides the following technical solution: a user management system and method based on intelligent datasets, the method comprising: The process involves acquiring and parsing multi-source heterogeneous data, and constructing a legal elements knowledge graph based on this data. The multi-source heterogeneous data includes legal data, contract data, and user data. Intercept operation requests and calculate dynamic compliance identity for the user who made the operation request based on a legal requirement knowledge graph; Based on dynamic compliance identity and legal requirements knowledge graph, compliance guidance and real-time risk reasoning are used to generate compliance decisions for operation requests, and execution of compliance decisions generates execution results. The execution results are obtained, displayed, and analyzed to generate compliance risk predictions and decision-making recommendations.

[0004] Furthermore, the acquisition and parsing of multi-source heterogeneous data, and the construction of a legal elements knowledge graph based on the multi-source heterogeneous data, includes: Establish a predefined legal ontology, which includes M core concepts, conceptual attributes, and hierarchical relationships; Acquire user data and parse it into standardized data; acquire contract data to extract contract structure information, clause information and contracting party information; acquire legal data to mark legal entities, rights and obligations and constraints; and generate processing results based on the processing of user data, contract data and legal data. The corresponding positions of each item in the processing result are identified in the predefined legal ontology, a mapping alignment result is generated, and a legal element knowledge graph is constructed based on the mapping alignment result.

[0005] Furthermore, the calculation of dynamic compliance identity for the user submitting the operation request based on the legal requirements knowledge graph includes: Acquire and parse user operation requests, and identify the target data object and user identity of the operation requests; Query the legal requirements knowledge graph to obtain N legal sensitivity tags associated with the target data object; Collect current environmental risk values, including network environment trustworthiness, access time, and login device type; A temporary permission set is generated based on user identity, legal sensitivity tags, and environmental risk values. The temporary permission set, user identity, legal sensitivity tags, and environmental risk values ​​are then integrated to generate a dynamic compliance identity.

[0006] Furthermore, the process of guiding operational requests based on dynamic compliance identity and legal requirements knowledge graphs, generating compliance decisions through real-time risk reasoning, and executing compliance decisions to generate execution results includes: A risk reasoning intelligent agent is constructed based on dynamic compliance identity. The risk reasoning intelligent agent is matched with the legal elements knowledge graph to determine whether there is a conflict between the operation request and legal data, user data and contract data, and generates a judgment result. Based on the judgment result, a compliance decision is generated. If the judgment result indicates a conflict, the compliance decision is to block the operation request and generate a warning message; If the judgment result is no conflict, the compliance decision is to allow the operation request and record the operation behavior generated based on the operation request; If it is determined that permissions need to be restricted, the compliance decision is to adjust the permissions.

[0007] Furthermore, if the judgment result indicates a conflict, the compliance decision is to block the operation request and generate a warning message, including: Based on the analysis of legal elements knowledge graph, legal data and contract data of operational behavior violations are generated, and P correction suggestions are matched from a predefined strategy library; The data on violated laws and contracts is integrated with P corrective suggestions to generate a warning message.

[0008] Furthermore, if it is determined that permission needs to be restricted, the compliance decision is to adjust the permissions, including: Analyze the risk level and remaining session duration of the operation request; When the risk level is greater than or equal to the first threshold and the remaining session duration exceeds the preset duration, session-level permission adjustment will be performed. When the risk level is greater than or equal to the second threshold, perform an operational-level permission adjustment. When the risk level is greater than or equal to the third threshold, system-level permission adjustments will be performed.

[0009] Furthermore, the compliance guidance for operation requests includes: Predict the user's potential action intent based on the action request; Based on the user's operational intent, the system retrieves and generates alternative operational paths that conform to the rules of the legal requirements knowledge graph from a predefined compliant operational path library and sends them to the user.

[0010] Furthermore, the process of obtaining, displaying, and analyzing the execution results to generate compliance risk prediction results and decision-making suggestions includes: Analyze abnormal operational patterns to obtain compliance decisions and execution results; Predict the development trend of abnormal operation patterns and generate compliance risk prediction results; Decision recommendations are generated based on compliance risk prediction results and legal requirement knowledge graphs.

[0011] A user management system based on intelligent datasets, the system comprising: The data acquisition and graph construction module is used to acquire and parse multi-source heterogeneous data, and construct a legal element knowledge graph based on the multi-source heterogeneous data. The multi-source heterogeneous data includes legal data, contract data, and user data. The dynamic identity calculation module is used to intercept operation requests and calculate a dynamic compliance identity for the user who makes the operation request based on a legal requirement knowledge graph. The reasoning and execution module, based on a dynamic compliance identity and legal requirements knowledge graph, provides compliance guidance and real-time risk reasoning for operation requests to generate compliance decisions, and executes compliance decisions to generate execution results. The monitoring and decision-making module is used to acquire, display, and analyze execution results, and generate compliance risk prediction results and decision-making suggestions.

[0012] This invention provides a user management system and method based on intelligent datasets. It has the following beneficial effects: 1. This invention adaptively and dynamically adjusts user permissions by calculating the user's dynamic compliance identity. It intercepts user operation requests in real time and calculates a temporary and precise set of temporary permissions by comprehensively considering the user's basic role, the legal sensitivity of the target data object marked in the legal elements knowledge graph, and real-time environmental risk values. The system calculates the dynamic compliance identity and adjusts user permissions accordingly, tightly binding user permissions to their current specific legal risk context. This ensures that the same user enjoys standard permissions when processing ordinary public information, but their permissions are dynamically and temporarily tightened when accessing highly sensitive M&A agreements. This achieves refined and contextualized permission management, reducing the risk of excessive data exposure due to rigid permissions while ensuring business smoothness. The dynamic adaptation of user operations to user permissions avoids the low business efficiency caused by manual permission approval, achieving a precise balance between security and efficiency.

[0013] 2. This invention employs the construction of a legal element knowledge graph and real-time risk reasoning and compliance guidance. It utilizes this knowledge graph to perform deep semantic understanding of legal and contractual data, transforming unstructured legal provisions into calculable and reasonable digital rules. When a user's operation request is intercepted, the system predicts the user's intention based on their behavior and pre-recommends compliant paths. A risk reasoning agent performs real-time rule matching between the operation request and the legal element knowledge graph, determining whether the request conflicts with legal, user, and contractual data. Based on the conflict type, compliance decisions are made, decisively blocking high-risk operations. Furthermore, it proactively generates warning messages containing specific explanations of violations and feasible correction suggestions, directly guiding users to take compliant actions. Finally, it predicts compliance risks and generates decision recommendations based on the execution results of compliance decisions. This seamlessly embeds compliance checks into every key node of the business process, achieving pre-emptive guidance, real-time blocking and intelligent correction of violations, and post-event risk prediction and decision recommendations. This significantly reduces the probability of violations, enables rapid response and intervention to risky behaviors, reduces manual intervention and costs, and improves the security and intelligence of user management. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating the steps of a user management method based on an intelligent dataset according to the present invention. Figure 2 This is a flowchart of a user management method based on an intelligent dataset according to the present invention; Figure 3 This is an architecture diagram of a user management system based on intelligent datasets according to the present invention. Detailed Implementation

[0015] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] like Figures 1 to 2 As shown, a user management method based on intelligent datasets includes: Step S100: Obtain and analyze multi-source heterogeneous data, and construct a legal element knowledge graph based on the multi-source heterogeneous data. The multi-source heterogeneous data includes legal data, contract data, and user data. Legal data originates from the plain text or structured text of publicly released laws, administrative regulations, departmental rules, and other normative documents from people's congresses and governments at all levels, providing universal and mandatory legal rules and definitions to provide the foundational rules for the legal element knowledge graph. Contract data originates from various contract documents stored in enterprise business systems, such as contract management systems and document management systems, including but not limited to procurement contracts, service agreements, and confidentiality agreements. The same data is used to provide personalized rights and obligations relationships agreed upon in the specific operation of the enterprise, transforming abstract legal clauses into enforceable contractual constraints, and connecting legal clauses with specific application scenarios; user data comes from the enterprise's internal human resources system and includes users' basic identity information (such as user ID, appearance, etc.), job role information (such as department, job role, etc.) and affiliation (such as reporting relationship, jurisdiction, etc.). User data is used to clarify the actors in legal data and contractual data, so that permission calculation and compliance judgment can be accurate to specific actors, forming a three-dimensional multi-source heterogeneous data of rules, agreements and actors.

[0017] Step S101: Establish a predefined legal ontology. The predefined legal ontology contains M core concepts (M is an integer), conceptual attributes, and hierarchical relationships. The predefined legal ontology is a structured framework and vocabulary used to describe core concepts, conceptual attributes, and hierarchical relationships. It serves as the foundation for constructing a legal elements knowledge graph and is established through the integration of expert knowledge and data-driven iteration. First, domain experts, such as legal experts and compliance officers, compile a list of core concepts based on the target business domain (such as labor law, data security law, and contract law). Second, by analyzing a large number of legal provisions and standard contract templates, the key attributes of the core concepts are extracted and defined. Then, based on legal logic and taxonomy, the hierarchical relationships between the core concepts are established to form a preliminary ontology framework. Finally, this preliminary ontology framework is applied to some data, such as historical contracts, for verification and iterative correction to ensure that it can effectively cover and describe the legal elements in the actual data. After iteration and correction, the predefined legal ontology is formed. The core concepts are basic semantic units with clear legal or business definitions, serving as node types in the legal elements knowledge graph. Core concepts, such as natural persons, legal persons, contracts, confidentiality obligations, and personal information, have clearly defined conceptual content. Concept attributes are used to describe and refine core concepts, providing detailed information dimensions that graph nodes can carry, such as the "sensitivity level" and "belonging entity" of "personal information." For the concept of "contract," attributes such as "contract name," "effective date," "expiration date," "contracting parties," and "main subject matter" are defined. Hierarchical relationships represent the relationship structure between core concepts and within the core concepts themselves, such as an employment contract being a type of contract and an employee being a type of natural person.

[0018] Step S102: Obtain user data and parse it into standardized data, mapping the fields in the user data to the core concepts of a predefined legal ontology; obtain contract data for structural analysis and extraction, extracting contract structure information, clause information, and contracting party information; obtain legal data for in-depth natural language processing, labeling legal entities, rights and obligations, and constraints; and generate processing results based on the processing of user data, contract data, and legal data, wherein: When parsing user data, firstly, user data containing fields such as user name, employee ID, department code, job title, and supervisor is extracted from the API interface or database of the human resources system or active directory. Then, a standardized mapping template is established to map the fields of user data to the core concepts, conceptual attributes, and hierarchical relationships of a predefined legal ontology. For example, "name" and "employee ID" are mapped to the "identifier" and "name" attributes of the "natural person" concept; "department" and "job title" are mapped to instances of the "role" concept, and the relationship that the "natural person" instance "belongs to" a certain "department role" or "holds" a certain "job title" is established. Finally, standardized data containing user entities and relationships is output. The parsing and extraction of contract data employs a combination of structural parsing and semantic extraction. First, document parsing technologies, such as PDF parsers based on layout analysis, are used to identify the chapter structure of various contract documents within the contract data, such as "Chapter 1 General Provisions" and "Article 5 Confidentiality Clause." Then, combining natural language processing and rule matching, contract structure information, clause information, and signatory information are extracted from each chapter, identifying the type, subject, object, and conditions of the clauses. Contract structure information includes the contract title and chapter titles; clause information, especially clauses defining legal obligations such as confidentiality obligations and data provision obligations; and signatory information includes company name, the name and position of the signing representative. The extracted content is ultimately transformed into structured objects, such as "Contract Examples," "Clause Examples," and "Signatory Examples." When legal data undergoes deep natural language processing, firstly, named entity recognition technology based on legal terminology dictionaries and pattern matching is used to identify legal entities, such as personal information processors, data subjects, and regulatory authorities, from the plain text or structured text of the legal data. Secondly, through dependency parsing and rule-based relation extraction templates, the rights and obligations relationships are identified, and the triple information of subject, relation, and object is extracted. For example, in the sentence "personal information processors shall take technical measures," the subject is "personal information processors," the relation is "shall," and the object is "take technical measures." Then, the constraints are identified and labeled, such as unless otherwise stipulated by laws and regulations, or with the consent of the personal information subject. These constraints will be recorded as additional constraints on the relations or attributes. The processing results specifically include standardized data parsed from user data, contract structure information, clause information, and contracting party information extracted from contract data, and legal entities, rights and obligations triples, and constraints extracted from legal data. The processing results transform the original unstructured or semi-structured data into structured information with clear semantic labels that can be directly logically associated and calculated by computers. The original multi-source heterogeneous data is unprocessed raw material, such as PDF contracts, legal texts, and database user records, while the processing results are structured intermediate products generated after parsing, extraction, and annotation, and have been initially aligned to the legal semantic framework. They are the direct data for constructing knowledge graphs.

[0019] Step S103 involves identifying the corresponding positions of each item in the processing results within the predefined legal ontology, performing entity alignment and attribute mapping, traversing all objects and legal entities identified in the processing results, and performing semantic search and matching within the core concepts of the predefined legal ontology. For example, for an object extracted from the clause information whose content is "Party B shall keep Party A's technical information confidential," its core semantic "confidentiality" will be matched with the core concepts in the predefined legal ontology, ultimately aligning it to the core concept node of "confidentiality obligation." Next, attribute mapping is performed: the "obligation subject" attribute value ("Party B") of the clause object is mapped... The process involves mapping the "obligated party" attribute slot under the "confidentiality obligation" concept; mapping the "confidential object" attribute value ("Party A's technical data") to the "confidential content" attribute slot; and finally, establishing relationship connections: based on the mapping results, creating a "bearing" relationship edge between "Party B" (an instance of a "natural person" or "legal person") and the "confidentiality obligation" instance in the legal elements knowledge graph; simultaneously, establishing a "source" relationship edge between the "confidentiality obligation" instance and the source "contract" instance, thus mapping and aligning specific data instances to the abstract legal concept framework; and generating mapping and alignment results by mapping and aligning all identified objects and legal entities one by one. Step S104: Based on the mapping alignment results, a legal element knowledge graph is constructed, using legal entities and core concepts as graph nodes and rights and obligations relationships and hierarchical relationships as graph edges. This construction connects discrete information into a network of knowledge. The legal element knowledge graph is automatically and dynamically updated when new laws are promulgated, contracts are signed, or user information is updated. The legal element knowledge graph is based on multi-source heterogeneous data for adding, deleting, and modifying graph nodes and edges, where: The graph nodes are directly derived from the entity instances mapped and aligned in step S103 and the core concepts in the predefined legal ontology. For example, a specific user "Zhang San" is mapped to the "natural person" graph node, an "XX Data Service Contract" is mapped to the "contract" graph node, and "confidentiality obligation" as a legal concept is also a graph node. The graph edges are defined based on the relationship types determined by mapping and alignment. Hierarchical relationships between core concepts form one type of edge, "belonging" relationships between specific instances and concepts form another type of edge, and relationships based on rights, obligations, and legal facts constitute the richest edge types, such as the "signing" relationship between contracting parties, the "serving" relationship between individuals and roles, and the "bound by" relationship between user behavior and obligation clauses. When constructing a legal element knowledge graph, graph nodes and graph edges are persistently stored in the form of a graph data model. The updating of the legal elements knowledge graph is event-driven and rule-driven, requiring no complex prediction algorithms. It relies on the parsing of multi-source heterogeneous data in step S102. When events such as the promulgation of new laws, the signing of new contracts, or changes in user information are detected, the update process of the corresponding data source is automatically triggered. For example, when a new contract is added to the database, steps S102 and S103 are executed immediately to parse, extract, and map the new contract, generating new "contract" graph nodes, "clause" graph nodes, and related "constraint" relationship graph edges. These are then merged into the existing legal elements knowledge graph as incremental updates. For legal revisions, version comparison is used to identify the changed clauses, and the corresponding rule nodes and relationships in the legal elements knowledge graph are reprocessed and updated. The criteria for adding, deleting, and modifying graph nodes and edges are directly derived from changes in the processing results of multi-source heterogeneous data and the mapping alignment results. When a completely new entity or relationship not present in the legal element knowledge graph appears in the processing results, such as a new employee, a new contract, or a new legal obligation, an addition operation is performed. When data in multi-source heterogeneous data is marked as invalid, such as contract expiration, employee departure, or repeal of laws and regulations, and the legal effect associated with it is confirmed to have terminated according to business rules, the corresponding node and edge are marked as "historical" or moved to an independent area, or deleted after ensuring there are no current references. When the attributes of data in multi-source heterogeneous data change, such as user job changes or contract amount corrections, and it is found after mapping alignment that the change affects the attributes of graph nodes, the attribute values ​​of the corresponding nodes are updated. In addition, if a revision of a legal provision causes a change in the specific content of an obligation relationship, the attributes of the corresponding "rights and obligations relationship" edge or the target node it points to are modified. The entire process is based on data-driven events and predefined business rule logic.

[0020] Step S200: Intercept operation requests and calculate dynamic compliance identity for the user making the operation request based on a legal element knowledge graph. An operation request refers to a specific instruction stream generated when a user initiates any data interaction or function call in the business system. Technically, an operation request is usually represented as a structured data packet, including operation type, target data object, and user identity. Operation types include reading, downloading, modifying, and sharing; target data objects include files, videos, tables, and links; and user identities include user ID and job role. By setting up a dedicated interface to intercept operation requests in real time, the operation requests first enter a compliance review channel based on a legal element knowledge graph before reaching the execution of the operation. Before each operation request occurs, a step based on real-time legal scenario calculation and decision-making is set up to realize the transformation from a static pre-allocated role and permission system to a dynamic and precise permission control based on specific operation context and real-time risk environment. Step S201: Obtain and parse the user's operation request, identify the target data object and user identity of the operation request, and encapsulate the identified target data object and user identity into a standardized operation request context object; Step S202: Input the target data object and query the legal elements knowledge graph. Use the unique identifier of the target data object to check if there is a graph node named with that identifier. If it exists, start the query directly from that graph node. If the target data object is an underlying file connected to the graph node, such as an attachment to a contract, search for the parent object of the target data object in the legal elements knowledge graph, such as the graph node corresponding to the main contract, and associate it. Then, perform a traversal query, starting from the graph node, along various relationship edges such as "contains", "associates", "bound by", and "involves", to find all connected "..." The system generates a graph node for "legal obligations," a graph node for "legal concepts," and related graph nodes for "contract terms." Finally, it extracts all legal constraint information directly or indirectly related to the target data object from these associated graph nodes and their attributes. Then, based on predefined classification rules, it categorizes and prioritizes the associated graph nodes, generating N legal sensitivity labels associated with the target data object, where N is an integer. Each legal sensitivity label is a category-level relationship pair, for example, [(data category, personal information), (sensitivity level, high), (source of constraint, Article 9 of GDPR)]. Step S203: Collect the current environmental risk values, which include network environment trustworthiness, access time, and login device type. Environmental risk values ​​are a set of real-time variables describing the security status of the technical environment when a user initiates an operation request. Environmental risk values ​​are actively collected through the system environment interface: network environment trustworthiness is obtained by analyzing the request source IP address, detecting VPN channels, and network proxy status; network environment trustworthiness includes internal office networks, external public Wi-Fi, and VPN connections. Access time is directly obtained from the server system time and associated with the work calendar; access time includes working hours on weekdays, non-working hours, and holidays. Login device type is determined by parsing the user agent string, checking device certificates, or interacting with the mobile device management system; login device types include company-issued registered secure computers, personal mobile devices, and unknown devices. Among them, network environment trustworthiness is a comprehensive evaluation value used to characterize the security of the current network connection. During the evaluation, firstly, it is determined whether the IP address of the request source belongs to the enterprise's internal network IP address range. If so, a high basic trustworthiness is assigned. Secondly, it is checked whether the connection channel is established through an enterprise-authorized VPN gateway using strong encryption. If so, a trustworthiness similar to that of the internal network is assigned. Then, it is detected whether there are abnormal network proxies or redirects. Finally, combined with real-time network threat intelligence, such as whether the IP range has been reported to have attack activities, the basic trustworthiness is fine-tuned, and finally a discrete network environment trustworthiness score with high, medium and low levels and corresponding continuous scores is generated. The specific details of the access time include the standard calendar date and the specific time of day, which are used to identify whether the operation occurred during regular business hours. In compliance logic, abnormal access outside of working hours, such as downloading a large number of sensitive contracts late at night, indicates a higher internal risk or the possibility of misoperation, and therefore may require stricter permission verification. The determination of login device type includes distinguishing between company-hosted devices, trusted personal devices, and unknown / unmanaged devices. This is used to assess the security baseline of the operating terminal. Company-hosted devices usually have complete security protection, such as disk encryption and antivirus software, and are therefore considered a more secure operating environment. Unknown devices, on the other hand, may introduce the risk of data leakage, thereby triggering more conservative permission policies.

[0021] Step S204: A temporary permission set is calculated and generated based on user identity, legal sensitivity label, and environmental risk value. The temporary permission set, user identity, legal sensitivity label, and environmental risk value are integrated to generate a dynamic compliance identity. The dynamic compliance identity contains all information related to the operation behavior and is used to integrate the data calculated in steps S201 to S204 into a complete context of the operation behavior. It binds in real time "who (Who) in what environment (Where / When) wants to do what (How) with the data (What)", which facilitates subsequent compliance guidance and real-time risk reasoning for the operation behavior. For example, it allows the same legal manager to view a confidential contract on the company computer, but prohibits them from downloading the same contract on their personal computer at home. A temporary permission set is a set of specific operations that are allowed or prohibited based on all input parameters for the current operation request. It is a temporary and minimal list of instructions. During the calculation, a built-in permission calculation engine is used. The permission calculation engine encapsulates a decision logic rule library predefined by compliance experts. All inputs are matched with the decision logic rule library, and the final output is a list of operation permissions that only applies to the current scenario, such as {"Allow":["Read","Preview"],"Prohibit":["Download","Share"]}. For example, a rule in the decision logic rule library is: "IF (user identity contains 'project member') AND (legal sensitivity label contains 'project confidential') AND (network environment trustworthiness is 'high') THEN temporary permission set = {'View', 'Online preview'}; ELSEIF (device type is 'personal device') THEN temporary permission set = {'View'}."

[0022] Step S300, based on the dynamic compliance identity and legal requirements knowledge graph, provides compliance guidance and real-time risk reasoning to generate compliance decisions for operation requests, and executes the compliance decisions to generate execution results. The operation request processing is divided into two logically parallel branches that are executed in sequence: one is compliance guidance, which proactively provides users with compliant operation suggestions before risks occur; the other is real-time risk reasoning, which conducts mandatory security reviews on operation requests that users insist on, generates a definite compliance decision and executes it, transforming abstract legal rules into specific, executable instructions, and realizing real-time regulation and guidance of operation behavior. In actual execution, the compliance guidance in step S301 is executed first by default, proactively providing users with compliant alternative operation paths. Regardless of whether the user chooses to execute the alternative operation path, they will enter the real-time risk reasoning step in step S302 for security review. Step S301, providing compliance guidance for the operation request, includes: Predicting a user's potential operational intent based on their operation requests; a user's potential operational intent is a prediction of the business goals or subsequent actions that the user may want to achieve behind their current operation request. For example, if a user requests to "download a customer contract," their potential intent may include "archiving it locally," "sending it to an external lawyer for review via email," or "printing it and sending it offline." By analyzing the context of the current operation request, combined with the user's historical behavior patterns (for example, if a salesperson has downloaded a contract in the past, there is a 70% probability that they will send it out via the company email), and referring to the common operation sequences of users with similar roles, the most likely subsequent intent can be predicted. The prediction is based on a combination of operation log analysis, role behavior profiling, and common business process knowledge. Based on the user's operational intent, an alternative operational path that conforms to the legal requirements knowledge graph rules is retrieved and generated from a predefined compliant operational path library and sent to the user. If the user chooses to execute the alternative operational path, a new operational request is generated based on the alternative operational path. This new operational request is intercepted, triggering the complete processing flow from step S200. The process then proceeds to step S300 for real-time risk reasoning, and finally, in step S302, it is determined to be conflict-free, generating a permission request, recording the compliance decision of the operational behavior, and generating an execution result. If the user does not choose an alternative operational path, the process proceeds to step S302 for real-time risk reasoning based on the original operational request, where: The predefined compliance operation path library is a knowledge base that stores standard security operation procedures that have undergone compliance review. The compliance operation paths are jointly set by the compliance team and business departments, and the data comes from the company's best practices, security audit requirements, and security constraints derived from the legal requirements knowledge graph. Alternative operation paths are one or more safer and more compliant operation guidelines proactively recommended to users when their current operation path is predicted to pose a compliance risk. An alternative operation path is not merely a binary "allow / prohibit" instruction, but a series of specific operational steps suggested. For example, if the user's intention in downloading a contract is predicted to be "external distribution," the alternative path might be: "We have detected that you may need to externally distribute contract 'XXX.' To comply with the confidentiality agreement, we recommend using the 'Secure External Distribution' function. The system will generate an encrypted link for you and record an audit log." Alternative operation paths are based on matching the user's potential intent with a predefined library of compliant operation paths. The predicted intent keywords are matched with the trigger conditions of compliant operation paths in the predefined library to retrieve all applicable compliant operation paths and transform them into actionable user-facing guidelines, such as: "To fulfill your confidentiality obligations to 'XX Company,' we recommend: 1. Click the 'Secure Sharing' button; 2. Enter the recipient's company email address; 3. Set the link validity period to 7 days."

[0023] Compliance guidance refers to proactively providing users with compliant operational suggestions before a risky operation actually occurs, based on predictions of user intent and compliance knowledge. This is done by determining compliance based on rules within a legal requirements knowledge graph. The key actions in the suggested alternative operational paths are logically matched with the applicable obligations clauses for the current data object and the user within the legal requirements knowledge graph. Only when all key steps in the alternative operational path are permitted or supported by the rules in the legal requirements knowledge graph and do not violate any prohibitions will the alternative operational path be deemed compliant and recommended to the user. Step S302: Construct a risk reasoning agent based on the dynamic compliance identity. The risk reasoning agent includes the dynamic compliance identity, the operation type of the operation request, and the attributes of the target data object. The attributes of the target data object are a set of metadata derived from the legal elements knowledge graph, describing the characteristics of the target data object under the legal and contractual framework. These attributes include inherent attributes, such as data name, type, and creator; legal association attributes, such as a list of bound legal sensitivity tags and a set of directly applicable legal provisions; contract association attributes, such as a list of effective contracts involving the data and a summary of relevant obligation clauses in the contracts; and relationship attributes, such as which natural persons, roles, obligations, and other graph nodes in the legal elements knowledge graph are connected to the data object. The risk reasoning agent is matched with a legal element knowledge graph to determine if there are any conflicts between the operation request and legal data, user data, and contract data, and to generate a judgment result. Based on the judgment result, a compliance decision is generated. The compliance decision is the final instruction produced by the rule matching process regarding how to handle the current operation request, and its form is usually a structured instruction. Rule matching is the process of logically comparing the set of scenarios of the operation behavior carried by the risk reasoning agent with the abstract legal rules formally expressed in the legal element knowledge graph to determine whether the scenario meets or violates the rule conditions. Rule matching includes condition evaluation and conclusion triggering. First, the set of scenarios for matching is extracted from the risk reasoning agent, such as {User identity: "Project Manager", Operation type: "Download", Legal sensitivity:} "High", environment credibility: "Medium"}; Second, traverse the graph nodes in the legal elements knowledge graph. Graph nodes are usually stored in an "IF-THEN" structure, such as "IF(operation type == 'download') AND (legal sensitivity label contains 'high') AND (user identity NOTIN['authorized executive']) THEN decision = 'block'"; Next, substitute the extracted context into the conditions of each rule for logical evaluation. If all conditions of a rule are met, the rule is activated, and the conclusions corresponding to its conditions, such as blocking, allowing, warning, etc., are added to the candidate decision set. Finally, if multiple rules are activated, the final matching result is obtained according to the preset conflict resolution strategy, such as "prohibitory rules take precedence over permissive rules" and "special rules take precedence over general rules". If the judgment result indicates a conflict, the compliance decision is to block the operation request and generate a warning message. When generating the warning message, based on legal requirement knowledge graph analysis, legal and contractual data regarding the violation of the operation are generated. P corrective suggestions are matched from a predefined strategy library, where P is an integer. The violated legal and contractual data are integrated with the P corrective suggestions to generate the warning message, for example: "Operation has been blocked. Reason: The document you attempted to send involves the 'Client Technology List,' which violates Article 5.2 of the 'XX Project Confidentiality Agreement' regarding the confidentiality of technical information. We suggest you: 1. Contact the project manager for written approval; 2. Use the 'Secure Document Sending' function (this function will automatically encrypt and log)."

[0024] The P corrective suggestions are a set of actionable standard solutions pre-configured by compliance administrators in a predefined policy library for specific violation scenarios. Each corrective suggestion includes a description of specific operational steps, corresponding security control measures, and the expected compliance goals. They are generated based on historical best practices for handling violation types and compliance paths derived from a legal requirement knowledge graph. According to the violation rules, one or more violation classification tags are determined. All suggestion entries matching these tags are searched in the predefined policy library and sorted according to predefined priority or applicability scores. The top P suggestions (e.g., P=2) are selected, and their content is converted from structured instructions into user-friendly guiding statements. Finally, these suggestions are combined with explanatory text of the violation clauses using a standard message template (usually "Violation Reason: {Reason}. Corrective Suggestions: 1. {Suggestion 1} 2. {Suggestion 2}") to generate the final warning message. If the judgment result is no conflict, the compliance decision is to allow the operation request and record the operation behavior generated based on the operation request; If it is determined that permission needs to be restricted, the compliance decision is to adjust the permission. If the determination result does not fully meet the conditions for direct blocking, but the risk level has exceeded the normal allowable range, it is determined that permission needs to be restricted. That is, a restrictive permission intermediate state is set between the permission request and the blocking request for more refined risk control, including: Analyze the risk level and remaining session duration of the operation request; When the risk level is greater than or equal to the first threshold and the remaining session duration exceeds the preset duration, session-level permission adjustment is performed. Session-level permission adjustment refers to reducing the user's global permission level for the remaining time of the current login session. The actions include: generally disabling high-risk operation functions, such as prohibiting all file download, printing, and sharing functions for the session; or restricting its data access scope to non-sensitive areas. When the risk level is greater than or equal to the second threshold, an operation-level permission adjustment is performed. Operation-level permission adjustment means restricting only the specific operation that the user is currently trying to perform, without affecting other operations within the session. The content of the operation includes prohibiting only the specific operation on the specific target data object in this session. For example, allowing the user to view the file list, but prohibiting the user from downloading a specific file named "XX technical solution.pdf", while the user can still download other unrestricted files. When the risk level is greater than or equal to the third threshold, system-level permission adjustment will be implemented. System-level permission adjustment is the most severe measure, which means immediately suspending the user's current session and temporarily freezing the general access permissions of the account. The execution includes forcibly logging out the user, invalidating all active session tokens; requiring the user to re-authenticate with strong identity, such as combining password and dynamic token; and suspending the account's access permissions in all relevant systems until the re-authentication is successful. In determining whether an operation request conflicts with legal data, user data, and contract data, the criteria and basis for judgment vary depending on the data source. For legal data, the criterion is whether the operation request violates any prohibitive obligations or mandatory requirements derived from legal provisions. This is based on the rules of the graph nodes derived from legal data in the legal elements knowledge graph. For example, a rule in the graph node derived from the Personal Information Protection Law may stipulate that "the processing of sensitive personal information shall obtain the individual's separate consent." If the operation request involves the processing of sensitive personal information without consent, it is determined to conflict with legal data. For user data, the criterion is whether the initiator of the operation request has the necessary qualifications to perform the operation. Legal roles or qualifications are determined by the attributes and hierarchical relationships of user graph nodes formed after user data is mapped to a legal elements knowledge graph. For example, a contract may stipulate that "only the project manager has the right to approve the final payment." If a user who is not the project manager initiates an approval operation, it is considered a conflict with the user data (mapped role permissions). For contract data, the criterion is whether the operation request violates the specific rights and obligations agreed upon by both parties to the contract. This is based on the obligation nodes extracted and instantiated from the contract terms in the legal elements knowledge graph. For example, a confidentiality agreement may stipulate that "the recipient shall not copy the technical data in any form." If a user attempts to download (a form of copying) the data, it is considered a conflict with the contract data. Risk level is a quantitative score that integrates multiple risk indicators to determine the severity of permission adjustments. Risk levels are typically divided into four levels: low, medium, high, and severe, corresponding to a numerical range of 0-100. This classification is based on a weighted combination of various elements within the risk reasoning agent, including inherent operational risk (e.g., "delete" is riskier than "view"), legal sensitivity, environmental risk value (network, time, device), and user behavior credibility (based on historical operational behavior analysis). First, a base score and weight are assigned to each risk factor in the risk reasoning agent. For example, the base score for the operation type "download" is 40, for legal sensitivity "high" it is 50, for environmental risk value "low-credible network" it is 30, and for user behavior "first anomaly" it is 20. Second, a comprehensive risk score is calculated according to a preset weighted summation formula. Then, the score is mapped to a preset risk level range; for example, 0-30 is low risk, 31-60 is medium risk, 61-85 is high risk, and 86-100 is severe risk. Finally, a discrete risk level label is output. The remaining session duration refers to the length of time remaining from the current moment until the user's current login session automatically expires due to timeout. By maintaining the user session state and recording the session start timestamp and preset session timeout duration, when permission adjustment judgment is required, the current time is subtracted from the session start time to obtain the elapsed duration, and then the preset timeout duration is subtracted from the elapsed duration to obtain the remaining session duration. For example, if the preset session duration is 8 hours (28800 seconds) and the user has been logged in for 2 hours (7200 seconds), then the remaining duration is 6 hours (21600 seconds). The preset duration of the session is set based on a balance between enterprise information security strategy, industry compliance standards (such as the financial industry requiring frequent re-authentication) and user experience. Common considerations include the need for business continuity (longer sessions facilitate work), the risk of account theft (shorter sessions are more secure), and differences in user identity (administrator session duration is usually shorter than that of ordinary employees). For example, ordinary employees may be set to 8 hours, the financial system may be set to 4 hours, while sessions accessing the core production system may be set to only 2 hours. The first, second, and third thresholds are risk level thresholds used to trigger the aforementioned three permission adjustment levels. They are set based on historical security event analysis, compliance risk tolerance, and business operation impact assessment. Generally, there are no fixed values, but they follow an increasing relationship: first threshold < second threshold < third threshold. For example, in a risk scoring system of 0-100 points, the first threshold is set at 65 points. When the risk reaches this level, it indicates that the user's operational context is abnormal, such as accessing sensitive data from an external network outside of working hours, requiring preventative control at the entire session level. The second threshold is set at 80 points. When the risk reaches this level, it indicates that the current specific operation is highly risky, such as attempting to download a file marked "top secret," but the user's overall session behavior is acceptable, so only targeted blocking is needed. The third threshold is set at 90 points. This is based on the fact that when the risk reaches this level, it indicates serious security threat signs, such as multiple attempts to access a large number of sensitive files within a very short period. The session must be immediately interrupted and an emergency verification process initiated to prevent account theft. The specific values ​​of the risk level thresholds need to be determined during system deployment by analyzing simulated attack scenarios and normal operating modes.

[0025] Step S400: Obtain execution results for display and analysis, generate compliance risk prediction results and decision suggestions, and continuously collect all execution results from step S300. Execution results include, but are not limited to, the type of each compliance decision, data related to operation requests, triggered rules, timestamps of compliance decision generation, specific performance of compliance decision execution, generated warning information, permission change records, risk level, environmental risk value, etc.; data associated with operation requests, such as user identity, operation type, target data object, etc.; specific performance of compliance decision execution, such as "file download channel is closed", "warning information has popped up in the user interface", "user session permissions have been adjusted to view-only", etc. After the compliance decision execution is completed, the compliance decision itself, the final execution status (success / failure), and all relevant context data collected from the entire chain starting from S300 are packaged into an immutable execution result and sent to the log and analysis system in real time for persistent storage, providing raw data for the analysis in step S401. Step S401: Obtain compliance decisions and execution results for analysis, and analyze abnormal operation patterns based on user identity and target data object attributes; wherein: The analysis of execution results includes frequency analysis, sequence pattern analysis, association clustering analysis, and trend analysis. Frequency analysis includes the number of times a specific user or role triggers a "blocking" decision within a unit of time; sequence pattern analysis includes whether a user, after being "warned," immediately attempts other similar operations that might circumvent control; association clustering analysis includes whether there is a temporal and pattern-related correlation between multiple users' abnormal access to the same sensitive data object; and trend analysis includes the change in the incidence rate of a certain type of violation over time. Analysis is performed by periodically extracting all execution result records within a certain time window from storage, such as hourly. First, data cleaning and field standardization are conducted. Then, aggregation and statistics are performed according to preset analysis dimensions, such as analysis by user, by data type, and by violation type. Next, rule-based or lightweight machine learning models, such as isolated forests, are applied to detect outliers and identify statistical patterns that exceed the normal baseline. For example, the blocking rate of a user's "download" operation may suddenly be much higher than the historical average for their role. When identifying abnormal behavior patterns, a baseline of normal behavior is first established. For example, for the role of "R&D engineer", the typical pattern of accessing "source code" objects is "high-frequency viewing, medium-frequency downloading (limited to internal build servers), and extremely low-frequency external transmission". When analyzing new execution results, the user identity and target data object attributes in the records are extracted. Then, the frequency, time, environment and other characteristics of this operation are compared with the normal behavior baseline established for this user identity. If the characteristics deviate from the baseline, the operation is marked as an anomaly. Continuous or related anomalies constitute an abnormal operation pattern. Abnormal operation patterns refer to a series of regular characteristics exhibited by operations that do not conform to the user's normal responsibilities, business logic, or security baseline. These include time-abnormal patterns (such as concentrated access to sensitive data during non-working hours), frequency-abnormal patterns (such as tentative "viewing" or "downloading" attempts on a large number of unrelated files in a short period of time), sequence-abnormal patterns (such as the routine operation of "viewing contract A" followed by an unconventional attempt to "download all historical versions of contract A"), and associated diffusion patterns (such as multiple accounts accessing the same batch of highly sensitive files in a similar manner, which may indicate collaborative probing or information gathering).

[0026] Step S402: Predict the development trend of abnormal operation modes, generate compliance risk prediction results, and generate decision suggestions based on compliance risk prediction results and legal requirements knowledge graph.

[0027] Predicting the development trend of abnormal operation patterns involves conducting time series and correlation analysis on historical abnormal patterns to infer their potential future direction and intensity. The predictions include the evolution trend of risk types, the trend of risk impact scope, and the trends of risk frequency and severity. For example, the evolution trend of risk types might be from simple "unauthorized access attempts" to more complex "data aggregation and leakage" patterns. The trend of risk impact scope might be, for example, the spread of abnormal operations from a single department to multiple departments. The trend of risk frequency and severity might be, for example, the monthly occurrence rate of a specific violation is expected to increase by 20% in the next quarter. Identified historical abnormal operation patterns are arranged chronologically, and key characteristic indicators (such as the number of occurrences, the number of users involved, and the average trigger risk level) are extracted. Then, time series analysis models, such as Prophet or autoregressive models, are used to fit and extrapolate the key characteristic indicators to predict the indicator values ​​for a future period, such as the following week or month. Simultaneously, the sequential occurrence or symbiotic relationship between different patterns is analyzed, and association rule learning is used to predict whether the occurrence of one pattern may accompany or trigger another. The compliance risk forecast results are the conclusive output of the above-mentioned development trend predictions. It is a structured risk assessment report, including a description of the predicted high-risk scenarios, the potential risk impact level, and the relevant potential legal or contractual terms. It is used to shift the management perspective from passively responding to historical events to proactively addressing future threats, providing administrators with forward-looking decision-making basis so that targeted reinforcement measures can be taken before a large-scale risk outbreak. When generating decision recommendations, the system dynamically combines compliance risk predictions with the latest legal element knowledge graph. First, based on predicted high-risk scenarios, relevant legal obligation nodes and contractual constraint nodes are located in the legal element knowledge graph to confirm their current validity. Then, based on the logical relationships in the legal element knowledge graph, potential control points are deduced. These are then selected from a predefined management measures library, similar to the predefined strategy library used to generate correction recommendations, but with the difference that the predefined management measures library is designed to match administrators with applicable control actions. For example, regarding the prediction of "increased risk of non-compliant downloading of expired contracts by the sales department," the generated decision recommendations are: "Recommendation 1: Add a 'read-only after archiving' attribute tag to the 'expired customer contracts' data class in the knowledge graph and automatically trigger stricter download approval rules. Recommendation 2: Conduct a compliance awareness enhancement training on 'Data Lifecycle Management' for all members of the sales department. Recommendation 3: Review and tighten the batch export permissions of historical data for the 'Sales Director' role." These decision recommendations aim to directly and actionably mitigate the predicted risks.

[0028] In this embodiment, user permissions are adaptively and dynamically adjusted by calculating the user's dynamic compliance identity. By intercepting user operation requests in real time and combining the user's basic role, the legal sensitivity of the target data object marked in the legal elements knowledge graph, and the real-time environmental risk value, a temporary and accurate temporary permission set is generated. The dynamic compliance identity is calculated, and the user's permissions are adjusted according to the dynamic compliance identity. This achieves a close binding between user permissions and the specific legal risk situation they are in. The same user enjoys standard permissions when processing ordinary public information, but when accessing highly sensitive merger and acquisition agreements, their permissions are dynamically and temporarily tightened by the system. This achieves refined and contextualized permission management. While ensuring business smoothness, it reduces the risk of excessive data exposure caused by rigid permissions. It enables dynamic adaptation between user operation behavior and user permissions, avoids the problem of low business efficiency caused by manual permission approval, and achieves a precise balance between security and efficiency. By constructing a legal element knowledge graph and performing real-time risk reasoning and compliance guidance, this system leverages the legal element knowledge graph to perform deep semantic understanding of legal and contractual data. Unstructured legal provisions are transformed into computable and reasonable digital rules. When a user's operation request is intercepted, the system predicts the user's intention based on their behavior and pre-recommends compliant paths. A risk reasoning agent performs real-time rule matching between the operation request and the legal element knowledge graph, determining whether the request conflicts with legal, user, and contractual data. Compliance decisions are made based on the conflict type, enabling decisive blocking of high-risk operations. Furthermore, it proactively generates warning messages containing specific explanations of violations and feasible correction suggestions, directly guiding users to take compliant actions. Finally, compliance risk prediction and decision recommendations are generated based on the execution results of compliance decisions. This seamlessly embeds compliance checks into every key node of the business process, achieving pre-emptive guidance, real-time blocking and intelligent correction of violations, and post-event risk prediction and decision recommendations. This significantly reduces the probability of violations, enables rapid response and intervention to risky behaviors, reduces manual intervention and costs, and improves the security and intelligence of user management.

[0029] like Figure 3 As shown, a user management system based on intelligent datasets includes: The data acquisition and graph construction module is used to acquire and analyze multi-source heterogeneous data, and to construct a legal element knowledge graph based on the multi-source heterogeneous data, which includes legal data, contract data and user data. The dynamic identity calculation module is used to intercept operation requests and calculate a dynamic compliance identity for the user who makes the operation request based on a legal requirement knowledge graph. The reasoning and execution module, based on a dynamic compliance identity and legal requirements knowledge graph, provides compliance guidance and real-time risk reasoning for operation requests to generate compliance decisions, and executes compliance decisions to generate execution results. The monitoring and decision-making module is used to acquire, display, and analyze execution results, and generate compliance risk prediction results and decision-making suggestions.

[0030] This application also provides an electronic device. The electronic device may include one or more processors and one or more memories. The memories store computer-readable code, which, when executed by the one or more processors, can perform the user management system and method based on an intelligent dataset as described above.

[0031] The system and method according to the embodiments of this application can also be implemented using the architecture of the electronic device shown in this application. The electronic device may include a bus, one or more CPUs, ROM, RAM, a communication port connected to a network, input / output, a hard disk, etc. The storage device in the electronic device, such as ROM or hard disk, may store a user management system and method based on an intelligent dataset provided in this application. Furthermore, the electronic device may also include a user interface. Of course, the architecture shown in this application is merely exemplary; when implementing different devices, one or more components in the electronic device shown in this application may be omitted according to actual needs.

[0032] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a reference structure" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0033] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A user management method based on intelligent datasets, characterized in that, The method includes: The process involves acquiring and parsing multi-source heterogeneous data, and constructing a legal elements knowledge graph based on this data. The multi-source heterogeneous data includes legal data, contract data, and user data. Intercept operation requests and calculate dynamic compliance identity for the user who made the operation request based on a legal requirement knowledge graph; Based on dynamic compliance identity and legal requirements knowledge graph, compliance guidance and real-time risk reasoning are used to generate compliance decisions for operation requests, and execution of compliance decisions generates execution results. The execution results are obtained, displayed, and analyzed to generate compliance risk predictions and decision-making recommendations.

2. The user management method based on intelligent datasets according to claim 1, characterized in that, The process of acquiring and parsing multi-source heterogeneous data, and constructing a legal elements knowledge graph based on the multi-source heterogeneous data, includes: Establish a predefined legal ontology, which includes M core concepts, conceptual attributes, and hierarchical relationships; Acquire user data and parse it into standardized data; acquire contract data to extract contract structure information, clause information and contracting party information; acquire legal data to mark legal entities, rights and obligations and constraints; and generate processing results based on the processing of user data, contract data and legal data. The corresponding positions of each item in the processing result are identified in the predefined legal ontology, a mapping alignment result is generated, and a legal element knowledge graph is constructed based on the mapping alignment result.

3. The user management method based on intelligent datasets according to claim 1, characterized in that, The calculation of dynamic compliance identity for users submitting operation requests based on legal element knowledge graphs includes: Acquire and parse user operation requests, and identify the target data object and user identity of the operation requests; Query the legal requirements knowledge graph to obtain N legal sensitivity tags associated with the target data object; Collect current environmental risk values, including network environment trustworthiness, access time, and login device type; A temporary permission set is generated based on user identity, legal sensitivity tags, and environmental risk values. The temporary permission set, user identity, legal sensitivity tags, and environmental risk values ​​are then integrated to generate a dynamic compliance identity.

4. The user management method based on intelligent datasets according to claim 1, characterized in that, The system, based on a dynamic compliance identity and legal requirement knowledge graph, provides compliance guidance and real-time risk reasoning for operation requests, generates compliance decisions, and executes these decisions to generate execution results, including: A risk reasoning intelligent agent is constructed based on dynamic compliance identity. The risk reasoning intelligent agent is matched with the legal elements knowledge graph to determine whether there is a conflict between the operation request and legal data, user data and contract data, and generates a judgment result. Based on the judgment result, a compliance decision is generated. If the judgment result indicates a conflict, the compliance decision is to block the operation request and generate a warning message; If the judgment result is no conflict, the compliance decision is to allow the operation request and record the operation behavior generated based on the operation request; If it is determined that permissions need to be restricted, the compliance decision is to adjust the permissions.

5. The user management method based on intelligent datasets according to claim 4, characterized in that, If the judgment result indicates a conflict, the compliance decision is to block the operation request and generate a warning message, including: Based on the analysis of legal elements knowledge graph, legal data and contract data of operational behavior violations are generated, and P correction suggestions are matched from a predefined strategy library; The data on violated laws and contracts is integrated with P corrective suggestions to generate a warning message.

6. The user management method based on intelligent datasets according to claim 5, characterized in that, If it is determined that permission needs to be restricted, the compliance decision is to adjust the permissions, including: Analyze the risk level and remaining session duration of the operation request; When the risk level is greater than or equal to the first threshold and the remaining session duration exceeds the preset duration, session-level permission adjustment will be performed. When the risk level is greater than or equal to the second threshold, perform an operational-level permission adjustment. When the risk level is greater than or equal to the third threshold, system-level permission adjustments will be performed.

7. The user management method based on intelligent datasets according to claim 4, characterized in that, The compliance guidance for operation requests includes: Predict the user's potential action intent based on the action request; Based on the user's operational intent, the system retrieves and generates alternative operational paths that conform to the rules of the legal requirements knowledge graph from a predefined compliant operational path library and sends them to the user.

8. The user management method based on intelligent datasets according to claim 1, characterized in that, The process of obtaining, displaying, and analyzing execution results to generate compliance risk predictions and decision-making recommendations includes: Analyze abnormal operational patterns to obtain compliance decisions and execution results; Predict the development trend of abnormal operation patterns and generate compliance risk prediction results; Decision recommendations are generated based on compliance risk prediction results and legal requirement knowledge graphs.

9. A user management system based on intelligent datasets, characterized in that, The system includes: The data acquisition and graph construction module is used to acquire and parse multi-source heterogeneous data, and construct a legal element knowledge graph based on the multi-source heterogeneous data. The multi-source heterogeneous data includes legal data, contract data, and user data. The dynamic identity calculation module is used to intercept operation requests and calculate a dynamic compliance identity for the user who makes the operation request based on a legal requirement knowledge graph. The reasoning and execution module, based on a dynamic compliance identity and legal requirements knowledge graph, provides compliance guidance and real-time risk reasoning for operation requests to generate compliance decisions, and executes compliance decisions to generate execution results. The monitoring and decision-making module is used to acquire, display, and analyze execution results, and generate compliance risk prediction results and decision-making suggestions.

Images