Automated response method and system for data subject rights requests

Abstract

This application relates to the field of large language model technology, and provides a method and system for automated response to data subject rights requests. The method includes: normalizing rights request text expressions in different languages ​​into standardized rights operation intent templates based on a target large language model; retrieving storage location information corresponding to the data subject's identity identifier based on a pre-built cross-system data directory; mapping the rights operation intent templates to atomic operation tasks targeting one or more target heterogeneous data storage systems according to the rights action type and storage location information; sequentially scheduling and executing the atomic operation tasks in a predetermined order; and generating a compliance response log for the rights request text based on the operation execution evidence of each atomic operation task. This application achieves end-to-end automated response to multilingual rights requests, ensuring consistency in cross-system data operations.

Description

Technical Field

[0001] This application relates to the field of large language model technology, and in particular to a method and system for automatically responding to data subject rights claims. Background Technology

[0002] In related technologies, companies expanding overseas are required to respond to user requests for rights in order to comply with privacy regulations such as the EU's General Data Protection Regulation (GDPR). Requests submitted by users in multiple languages, including French and German, such as those requesting the deletion of their data or the provision of data copies, are often freely expressed and colloquial. Traditional keyword-based ticketing systems cannot accurately understand the intent and scope of these requests, relying on manual analysis of each request. Furthermore, user data is distributed across heterogeneous data storage systems such as cloud data warehouses, object storage, log systems, and third-party software-as-a-service platforms. The data formats and operational interfaces differ between these systems, requiring manual execution of queries and deletions across each system, resulting in long response times and a high risk of omissions.

[0003] When faced with rights requests submitted by users in multiple languages, the colloquial expressions vary across languages, and the same intent to claim a right is expressed significantly differently in languages ​​such as French and German. Human interpretation of unstructured request text in different languages ​​cannot guarantee consistency in intent recognition. Furthermore, multiple heterogeneous data storage systems each have independent operating interfaces and data formats. Manually translating the identified intent to claim a right into specific operational instructions for each storage system is neither feasible in ensuring that the operational steps cover all storage systems nor can a standardized, automated conversion path be established between request understanding and system operation. This makes end-to-end automated responses to multilingual rights requests impossible. Summary of the Invention

[0004] Therefore, it is necessary to provide a method and system for automating data subject rights requests, addressing the technical problem that existing technologies cannot achieve end-to-end automated responses to multilingual rights requests.

[0005] Firstly, a method for automating responses to data subject rights requests is provided, comprising: based on a target large language model, performing intent recognition and entity extraction on multilingual rights request texts; normalizing the expressions of rights request texts in different languages ​​into a standardized rights operation intent template, wherein the rights operation intent template includes a rights action type and a data subject identity identifier; retrieving storage location information corresponding to the data subject identity identifier based on a pre-built cross-system data directory; mapping the rights operation intent template to atomic operation tasks for one or more target heterogeneous data storage systems according to the rights action type and the storage location information; sequentially scheduling and executing the atomic operation tasks in a predetermined order, and recording the operation execution evidence generated during the execution of each atomic operation task; and generating a compliance response log for the rights request text based on the operation execution evidence of each atomic operation task.

[0006] Secondly, an automated response system for data subject rights claims based on a large language model is provided. The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the aforementioned automated response method for data subject rights claims.

[0007] Thirdly, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the aforementioned automated response method for data subject rights claims.

[0008] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described automated response method for data subject rights claims.

[0009] The automated response method for data subject rights requests provided in this application uses a target large language model to perform intent recognition and entity extraction on multilingual rights request texts. It normalizes request expressions in different languages ​​into standardized rights operation intent templates, enabling colloquial requests in languages ​​such as French and German to be uniformly parsed into structured templates containing rights action types and data subject identity identifiers. This establishes an automatic conversion path from multilingual unstructured requests to standardized intents. By retrieving storage location information corresponding to data subject identity identifiers from a pre-built cross-system data directory, it associates the rights action types in the standardized templates with the data subject's storage locations in various heterogeneous data storage systems, allowing abstract rights intents to correspond to specific data storage locations. By mapping the rights operation intent templates to atomic operation tasks for each target heterogeneous data storage system based on the rights action type and storage location information, and sequentially scheduling and recording operation execution evidence according to a predetermined order, the operation execution process across multiple heterogeneous data storage systems can be chained into a traceable atomic task sequence. By generating compliant response logs for the text of a rights request based on the execution evidence of each atomic operation task, the technical problem of the inability to achieve end-to-end automated response to multilingual rights requests is solved. The consistency of cross-system data operations is guaranteed, and the response cycle and human resources required for rights requests are reduced. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] in: Figure 1 This is a flowchart of the automated response method for data subject rights requests in the embodiments of this application; Figure 2 This is a structural block diagram of the computer device in the embodiments of this application; Figure 3 This is a structural block diagram of the computer device in the embodiments of this application. Detailed Implementation

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

[0013] Please see Figure 1 As shown, Figure 1 A flowchart illustrating the automated response method for data subject rights claims provided in this application embodiment includes the following steps: Step 01: Based on the target large language model, perform intent recognition and entity extraction on multilingual rights request texts, and normalize the expression of rights request texts in different languages ​​into standardized rights operation intent templates. The rights operation intent templates include the type of rights action and the identity identifier of the data subject. Step 02: Based on the pre-built cross-system data catalog, retrieve the storage location information corresponding to the data subject's identity identifier; Step 03: Based on the type of right action and storage location information, map the right operation intent template to atomic operation tasks targeting one or more heterogeneous data storage systems; Step 04: Schedule and execute atomic operation tasks sequentially according to a predetermined order, and record the operation execution evidence generated during the execution of each atomic operation task; Step 05: Generate a compliance response log for the rights request text based on the operation execution evidence for each atomic operation task.

[0014] Specifically, in step 01, the target large language model is a pre-trained neural network model capable of understanding and processing multiple natural language texts. Its internal parameters are obtained through training on a large-scale multilingual corpus, and it has the ability to map everyday spoken expressions in different languages ​​to a unified semantic representation. The target large language model refers to a deep learning model with natural language understanding and generation capabilities, obtained through pre-training on a large-scale multilingual corpus. It can receive multilingual natural language text input and output structured semantic representations.

[0015] Multilingual rights request texts are unstructured requests for exercising rights submitted by users in their respective native languages, such as "supprimer mes données" (French user) or "meine Daten löschen" (German user). The syntactic structure and vocabulary of these texts vary depending on the language, but they all point to the same intention: to delete personal data. Intent identification refers to determining the type of action the user wishes to perform from the request text; for example, identifying both "supprimer" and "löschen" as deletion actions. Entity extraction refers to extracting the identifier of the subject to which the action is directed from the request text; for example, obtaining the data subject's identity from user account information, the identity token attached to the request, or identifiers explicitly mentioned in the text.

[0016] The rights operation intent template is a predefined data format template used to uniformly represent semantic information extracted from multilingual rights claim texts, including at least a rights action type field and a data subject identity identifier field.

[0017] Normalization refers to filling the operation category obtained from intent recognition and the subject identifier obtained from entity extraction into the standard rights operation intent template according to the predefined structured field format to form a unified expression that is independent of language.

[0018] After receiving multilingual rights request texts, the target large language model does not rely on keyword matching or rule templates, but rather understands the true meaning of the request based on the context. The target large language model determines the type of action the user wants to perform from the rights request text and outputs the rights action type. The target large language model extracts the identity identifiers of the data subjects involved from the rights request text and the associated session context.

[0019] Based on pre-training with a general multilingual corpus, the target large language model is further fine-tuned using parallel corpora in the field of privacy regulations (including GDPR-related rights claim templates and their French, German, and other multilingual translation pairs) to improve its accuracy in recognizing privacy regulation terms.

[0020] The target large language model fills the corresponding fields of the standard rights operation intent template with the rights action type and data subject identity identifier, completing the normalization mapping from unstructured multilingual text to structured templates. For multiple rights request texts expressing the same intent in different languages, the rights operation intent template generated by the target large language model has the same rights action type and corresponding data subject identity identifier, thereby eliminating the formal inconsistency caused by language differences.

[0021] In step 02, the cross-system data directory can be implemented using a relational database or a distributed key-value store, with the data subject's identity identifier as the primary key, recording the storage location, data type, and data format of the data subject in each target heterogeneous data storage system. The cross-system data directory maintains consistency with the actual data status of each system by periodically scanning the metadata tables of each target heterogeneous data storage system or subscribing to the data change logs of each system.

[0022] Cross-system data catalogs can maintain data consistency with each target heterogeneous data storage system in the following ways: (1) periodically (e.g., hourly) scan the metadata tables of each system and update the index; (2) subscribe to data change event notifications of each system to achieve near real-time updates.

[0023] A cross-system data catalog can be implemented using a relational database or a distributed key-value store, with the data subject's identity identifier as the primary key, recording the data subject's storage location, data type, and data format in each target heterogeneous data storage system. The cross-system data catalog maintains consistency with the actual data state of each system by periodically scanning the metadata tables of each target heterogeneous data storage system or subscribing to the data change logs of each system.

[0024] The cross-system data catalog uses the data subject's identity identifier as the query condition and retrieves all storage locations associated with that data subject's identity identifier from a pre-built mapping relationship. The cross-system data catalog outputs the retrieved storage location information, which indicates the specific storage location of the data subject's identity identifier in each target heterogeneous data storage system.

[0025] In step 03, the right action type is the operation category identified in the standard right operation intent template, representing the specific right operation requested by the user. Storage location information refers to the storage location of the data subject output from the cross-system data catalog retrieval in each target heterogeneous data storage system. Target heterogeneous data storage systems are various types of data storage services used to store user data; each target heterogeneous data storage system has its own independent data storage structure and operation interface. An atomic operation task refers to the smallest indivisible schedulable execution unit generated for a single target heterogeneous data storage system. Each atomic operation task includes a target system identifier, operation interface, operation parameters, and operation object path.

[0026] For each target heterogeneous data storage system requiring operation, the operation content to be performed in that system is determined based on the type of right action, the data object targeted by the operation is determined based on the storage location in that system, and an atomic operation task is generated for that target heterogeneous data storage system. When the storage location information indicates that the data subject identity is associated with multiple target heterogeneous data storage systems, a corresponding atomic operation task is generated for each target heterogeneous data storage system.

[0027] The distributed task scheduler determines the execution order based on the data dependencies between atomic operation tasks: atomic operation tasks with dependencies are executed serially in sequence, while atomic operation tasks without dependencies can be distributed to various target heterogeneous data storage systems for execution in parallel.

[0028] In step 04, the predetermined order refers to the execution order pre-determined based on the dependencies between atomic operation tasks or the type of the target heterogeneous data storage system. Scheduled execution refers to distributing atomic operation tasks to the corresponding target heterogeneous data storage systems for actual execution according to the predetermined order. An atomic operation task is an operation unit targeting a single heterogeneous data storage system. Operation execution evidence refers to traceable records generated during the execution of atomic operation tasks in the target heterogeneous data storage system, used to prove that the operation has been executed as expected, including but not limited to information such as operation time, operation object, operation result, and return status.

[0029] After sorting the atomic operation tasks according to a predetermined order, each atomic operation task is sequentially distributed to the corresponding target heterogeneous data storage system for execution. During the execution of each atomic operation task, the execution status of that atomic operation task is recorded, forming operation execution evidence. The operation execution evidence includes the execution result and execution status of the atomic operation task in the target heterogeneous data storage system.

[0030] In step 05, the operation execution evidence is the execution status and details recorded after each atomic operation task is executed in the corresponding target heterogeneous data storage system. The compliance response log is a formal response file generated from the original rights request text, recording the entire operation process and results.

[0031] The execution evidence collected from various heterogeneous data storage systems is aggregated, and a compliance response log is generated based on the execution evidence of all atomic operation tasks, targeting the original rights request text. The compliance response log records the operation details and completion status of each atomic operation task, corresponding to the rights operation intent template for that rights request text.

[0032] By generating compliance response logs based on the operational execution evidence of each atomic operation task, the operational execution status scattered across multiple heterogeneous data storage systems is aggregated into a unified response file. This enables the response process for a rights request to form a complete record chain from request understanding to cross-system operational execution, providing traceable response credentials for compliance audits.

[0033] Based on the execution evidence of each atomic operation task, a compliance response log is generated, aggregating the execution status of operations scattered across various storage systems into a unified response file. This enables an end-to-end automated closed loop for rights requests, from understanding multilingual request texts to cross-system operation execution and compliance log generation. Therefore, the response process for multilingual rights requests no longer relies on manual understanding of request texts in different languages, nor on manual execution of operations in each storage system. The technical problem of achieving end-to-end automated response for multilingual rights requests is thus solved.

[0034] In some embodiments, step 01 above includes: Based on the target large language model, the language type of the rights claim text is identified; Based on the semantic parsing rules corresponding to the language type, the right type, data subject identity identifier, data scope description, and time constraint entity are extracted from the right claim text; Based on the target large language model, the privacy law knowledge base corresponding to the language is invoked to map the rights type, data subject identity identifier, data scope description and time constraint entity into a unified standard rights operation intent template across languages.

[0035] Specifically, multilingual rights request texts can be received via email, web forms, or Application Programming Interfaces (APIs). Upon receiving the rights request text, the target language model first identifies its language. For example, when a user submits "supprimer mes données," the target language model identifies the rights request text as French; when a user submits "meine Daten löschen," the target language model identifies the rights request text as German. Identifying the language type is a prerequisite for subsequently selecting the corresponding semantic parsing rules and privacy law knowledge base.

[0036] Different languages ​​have different grammatical structures and colloquial expressions. The target large language model loads corresponding semantic parsing rules for different languages ​​such as French and German, extracting four entities from unstructured colloquial text. Among them, the right type refers to the type of operation requested by the user, the data subject identity identifier refers to the user identifier to which the operation is directed, the data scope description refers to the data scope of the user's requested operation, and the time constraint refers to the user's limitation on the time scope of the operation.

[0037] The target language model invokes a privacy law knowledge base corresponding to each language, mapping the extracted right types, data subject identification, data scope description, and time constraint entities to a unified standard right operation intent template across languages. The target language model internally or externally hosts privacy law knowledge bases corresponding to each language, storing the mapping relationship between colloquial right request expressions and standardized right operations in each language. For example, the target language model normalizes the colloquial French expression "supprimer mes données" into a standard right operation intent template for "deletion: data subject identification is X, data scope is all personal data".

[0038] The right types extracted from the target large language model are mapped to the right action type field of the template, the data subject identity identifier is mapped to the data subject identity identifier field of the template, the data scope description is mapped to the data scope field of the template, and the time constraint entity is mapped to the time scope field of the template. Thus, the same right intent in different languages ​​is mapped to a standard right operation intent template with the same format.

[0039] In some embodiments, step 01 above further includes: When extracting entities from multilingual rights claim texts based on the target large language model, output the confidence score of entity extraction; When the confidence score corresponding to the data range description is lower than the preset threshold, it is determined that the data range description is ambiguous. Based on the target large language model, multiple rounds of dialogue and follow-up questions are conducted in the identified language to determine the clarified data range description; Based on the clarified data scope description, the rights request text is transformed into a structured rights operation intent vector, which includes the type of rights action, the identity of the data subject, the data scope, and the confidence level.

[0040] Specifically, when users submit rights requests in a colloquial manner, the expression is often incomplete or the scope is vague. For example, if a user submits a request in French, "supprimez certaines de mes données," the target large language model can identify the rights type as deletion and the data subject as the current user. However, "certaines de mes données" only means "some of my data," and the target large language model cannot determine from this colloquial expression which specific data the user wants to delete.

[0041] When extracting entities, the target large language model generates confidence scores for the extraction results of rights types, data subject identity identifiers, data scope descriptions, and time-constrained entities in its output layer. The confidence scores reflect the model's certainty regarding the extraction results for each entity. When the user's expression is clear, such as "supprimer toutes mesdonnées personnelles," the target large language model extracts data scope descriptions of "all personal data," resulting in a high confidence score. When the user's expression is vague, such as "supprimez certaines de mes données," the target large language model can only extract "partial data," and the confidence score is below a preset threshold.

[0042] The target large language model initiates multi-turn follow-up questions in the identified language. For example, the target large language model asks the user in French, "What specific types of data do you want to delete? Is it account information, order records, or all personal data?" After the user replies in French, the target large language model performs entity extraction on the reply and generates a new confidence score. If the new confidence score is still below a preset threshold, the target large language model continues to ask follow-up questions, such as "Are you referring to order records from 2023 or order records from all years?", until the confidence score corresponding to the data range description reaches or exceeds the preset threshold.

[0043] Through multiple rounds of follow-up questions, the user's initially vague "certain data" was gradually clarified into a specific data range, such as "order records from January 1, 2023 to December 31, 2023". The data range was then replaced with the clarified "order records for the entire year of 2023", and the confidence level was replaced with a value that reached or exceeded the preset threshold after clarification.

[0044] The rights operation intent vector fully and clearly carries the user's true intent in a structured form, eliminating the ambiguity of colloquial expressions. It provides a precise data range input for subsequent cross-system data catalog retrieval and atomic operation task mapping, avoiding operation omissions or misoperations due to unclear data ranges.

[0045] In some embodiments, step 02 above includes: Construct a cross-system data catalog and maintain a global data subject index in the cross-system data catalog. The global data subject index is used to record the storage location, data type and data format of each data subject in each target heterogeneous data storage system. Input the data subject identity identifier in the rights operation intent template into the global data subject index for querying; Retrieve the storage location of the data subject identity identifier in each target heterogeneous data storage system from the global data subject index.

[0046] Specifically, the global data subject index uses the data subject identity as the index key, recording the mapping relationship between each data subject identity and its storage location, data type, and data format in each target heterogeneous data storage system. For example, the global data subject index stores the following mapping records: the data subject identity "user_12345" is stored as the "user_id" field in the "user_accounts" table of the Snowflake (a cloud data warehouse platform) data warehouse, with a data type of structured table data; it is stored under the "bucket-user-files / user_12345 / " path in the Amazon S3 (Amazon Simple Storage Service) object storage, with a data type of object file; and it is stored in the "access-log-2023" index of the Elasticsearch (a distributed search and analytics engine) log system, with a data type of log document. The global data subject index is kept up-to-date by periodically scanning the metadata of each target heterogeneous data storage system or by accessing data change notifications from each target heterogeneous data storage system.

[0047] The cross-system data catalog reads the value of the data subject identity field from the template. For example, the value of the data subject identity field in the standard rights operation intent template is "user_12345". The cross-system data catalog uses "user_12345" as a query condition and inputs it into the global data subject index for retrieval. Based on the pre-established mapping records, the global data subject index searches for all mapping entries with the key value "user_12345", returning the storage location, data type, and data format of this data subject identity in target heterogeneous data storage systems such as data warehouses, Amazon S3 (Amazon Simple Storage Service), log systems, and third-party platforms.

[0048] The cross-system data catalog organizes the retrieved results into a list of storage location information. The list lists the system name of each target heterogeneous data storage system, the specific storage path or data table name of the main data in the system, the data type, and the data format.

[0049] In some embodiments, step 03 above includes: Based on the determined type of right action, the right operation corresponding to the right action type is decomposed into parallel or sequential operation steps, with different operation steps corresponding to different types of right actions; Based on the storage location information, determine the system type of each target heterogeneous data storage system, and call the preset operation converter corresponding to the system type of each target heterogeneous data storage system; By using a pre-configured operation converter, operation steps are converted into atomic operation tasks that can be executed by various target heterogeneous data storage systems.

[0050] Specifically, when the right action type is access, the operation steps are broken down into a data query step and a data export step. The two steps are executed in sequence. The data query step determines the data object to be exported, and the data export step organizes the query results into a data copy.

[0051] When the right action type is deletion, the operation steps are broken down into a data location step and a data deletion step. The two steps are executed in sequence. The data location step determines the specific location of the data to be deleted in each target heterogeneous data storage system, and the data deletion step performs the actual deletion.

[0052] When the right action type is restricted processing, the operation steps are broken down into a data marking step and an access control modification step. The two steps can be executed simultaneously. The data marking step adds a processing restriction identifier to the data, and the access control modification step adjusts the read and write permissions of the data.

[0053] The system type indicates whether the target heterogeneous data storage system belongs to a cloud data warehouse, object storage service, log search engine, or software-as-a-service platform. Pre-built operation converters are conversion components pre-built for each system type, encapsulating the corresponding system's operation command templates and interface call methods. For example, the pre-built operation converter for data warehouses encapsulates Structured Query Language (SQL) templates, the pre-built operation converter for Amazon S3 (Amazon Simple Storage Service) object storage encapsulates object operation interfaces, and the pre-built operation converter for log systems encapsulates index operation interfaces and anonymization command templates.

[0054] The pre-built operation converter extracts the operation type and data object parameters from the operation steps and populates them into the corresponding system's operation command template. For example, when the action type is delete and the target system is Amazon S3 object storage, the pre-built operation converter converts the data deletion step into an atomic operation task that deletes all objects under the storage path "bucket-user-files / user_12345 / ". When the target system is an Elasticsearch log system, the pre-built operation converter converts the data deletion step into a time-window anonymized atomic operation task, specifying the index name, user identifier field, and time range. Each atomic operation task includes the target system identifier, operation interface, operation parameters, and operation object path, and can be directly issued and executed by the scheduling execution stage.

[0055] In some embodiments, step 03 above further includes: When generating atomic operation tasks, the scope of the atomic operation tasks is limited to the records corresponding to the data subject's identity identifier; Perform compliance verification on atomic operation tasks after limiting the scope of operation to confirm data conflict between the type of right action and the record corresponding to the data subject identity in the target heterogeneous data storage system; After the verification is passed, the atomic operation task is determined to be an executable atomic operation task.

[0056] Specifically, when atomic operation tasks are generated, the system automatically adds data filtering conditions to limit the operation scope to records corresponding to the data subject's identity. For example, the SQL query atomic operation task in a data warehouse can have the filter condition "WHERE user_id = 'user_12345'" appended, and the object deletion atomic operation task in Amazon S3 object storage can specify object paths prefixed with "user_12345 / ". This ensures that the operation boundary of each atomic operation task strictly corresponds to the data subject's identity and does not affect the data of other data subjects in the same heterogeneous data storage system.

[0057] After defining the scope of operations, the system performs compliance checks on atomic operations to identify data conflict situations. For example, when the action type is deletion, the system checks whether the data subject in the target heterogeneous data storage system contains financial transaction records or ongoing dispute resolution records that are legally required to be retained. If the check results show that the data subject's data contains records that are legally required to be retained, a data conflict is determined, and the atomic operation task fails the verification. If the check results show that the data subject's data does not involve legally retained records, the verification passes.

[0058] Compliance verification can be achieved by invoking a pre-configured compliance rule engine. This engine stores compliance constraint rules for data subject rights claims under various jurisdictions (such as GDPR, CCPA, etc.), including data retention period rules and statutory retention exception rules. The rule engine receives the right action type of the atomic operation task, the target system type, and the data subject identity as input, and outputs a result indicating whether the verification passes or fails.

[0059] In some implementations, converting operation steps into atomic operation tasks executable by each target heterogeneous data storage system via a pre-defined operation converter includes: When the rights action type is access, the preset operation converter will convert the data export operation into a structured query language query task for the data warehouse; When the rights action type is deletion, the preset operation converter converts the data deletion operation into an object deletion task for object storage, or into a time window anonymization task for the log system.

[0060] Specifically, when the rights action type is access, the pre-built operation converter transforms the data export operation into a Structured Query Language (SQL) query task for the data warehouse. The SQL query task embeds the data subject identity as a query filter condition, and the query result is returned as a copy of the data requested by the user.

[0061] When the action type is deletion, the preset operation converter executes different conversion branches based on the system type of the target heterogeneous data storage system. If the target heterogeneous data storage system is object storage, the preset operation converter converts the data deletion operation into an object deletion task, which specifies the storage path of the object to be deleted, and this storage path corresponds to the data subject's identity identifier.

[0062] If the target heterogeneous data storage system is a log system, the pre-built operation converter will convert the data deletion operation into a time window anonymization task. The time window anonymization task specifies the log index name, the data subject identity field, and the time range for anonymization processing. Data anonymization is performed on the log records within the time range instead of physical deletion to maintain the data integrity constraints of the log system.

[0063] In some implementations, step 04 above includes: According to the predetermined order of the distributed task scheduler, the interfaces of the target heterogeneous data storage system corresponding to each atomic operation task in the execution queue are called sequentially for execution; Record the start time, end time, operation object, number of rows affected, and return status of each atomic operation task; The start time, end time, operation object, number of affected rows, and return status are stored in an immutable manner as evidence of operation execution.

[0064] Specifically, the distributed task scheduler retrieves atomic operation tasks from the execution queue in a predetermined order and sequentially calls the operation interface of the target heterogeneous data storage system corresponding to each atomic operation task for execution. The predetermined order is determined by the dependencies between atomic operation tasks; atomic operation tasks with dependencies are executed serially in sequence, while atomic operation tasks without dependencies are issued and executed in parallel.

[0065] When each atomic operation task is executed, the system records the start time, end time, operation object, number of rows affected, and return status of the atomic operation task. The start time marks the moment when the atomic operation task is sent to the target heterogeneous data storage system interface, the end time marks the moment when the atomic operation task returns the execution result, the operation object records the specific data table name or object path operated by the atomic operation task, the number of rows affected records the number of data records or objects involved in the operation, and the return status records the success or failure flag returned by the target heterogeneous data storage system interface.

[0066] The distributed task scheduler supports a compensation mechanism for atomic operation tasks: when any atomic operation task fails, the scheduler records the failed task and its reason, and triggers rollback or compensation operations for related tasks that have been successfully executed, ensuring the consistency of data operations across systems. The specific strategy for the compensation operation is determined according to the type of right action. For example, for a deletion operation, a failure is not rolled back but recorded for manual handling.

[0067] The system records the start time, end time, operation object, number of affected rows, and return status of each atomic operation task, storing them as operation execution evidence in an immutable manner. This immutability can be achieved by appending to a write-once log storage medium, or by generating a hash verification value for the operation execution evidence and writing it to a blockchain-based evidence storage platform, ensuring that the operation execution evidence cannot be modified or deleted after being written. Each piece of operation execution evidence is associated with its corresponding atomic operation task identifier and rights request identifier, forming a traceable chain of operation records.

[0068] In some implementations, step 05 above includes: Based on the target large language model, operation details are extracted from the operation execution evidence of each atomic operation task. The operation details include the operation time, operation type and operation result of each target heterogeneous data storage system. Based on the extracted operation details, a multilingual compliance response log is generated, including timestamps and full-chain operation details.

[0069] Specifically, the target large language model generates a natural language description of the operation details in the language of the original rights request text, and appends the structured operation data to it to form a multilingual compliance response log.

[0070] Operation time refers to the start and end times of the atomic operation task; operation type refers to the specific action category performed by the atomic operation task; and operation result is an indicator of whether the atomic operation task was successfully or unsuccessfully executed. The target large language model organizes the extracted operation details into a structured list according to the target heterogeneous data storage system and the order of operation time.

[0071] Based on the extracted operation details, the target large language model generates multilingual compliance response logs containing timestamps and end-to-end operation details. The timestamps are the system time at the log generation point, and the end-to-end operation details record the operation type, time, and result of each atomic operation task in each target heterogeneous data storage system in list form. For example, when a user submits a rights request in French, the target large language model generates a French version of the compliance response log; when a user submits a rights request in German, the target large language model generates a German version of the compliance response log. The compliance response logs also include end-to-end operation details in structured data format, which can be directly used as compliance operation records submitted to regulatory agencies.

[0072] In some implementations, after all atomic operation tasks are completed, the mapping engine automatically updates the cross-system data directory based on the execution results of each atomic operation task. When an atomic operation task targeting a specific heterogeneous data storage system executes successfully, the mapping engine updates the mapping relationship between the data subject's identity and the storage location in the target heterogeneous data storage system within the cross-system data directory to an "operated" state. When an atomic operation task fails, the mapping engine retains the storage location mapping relationship in the cross-system data directory and adds a failure flag. After the update, the cross-system data directory maintains consistency with the actual data state in each target heterogeneous data storage system.

[0073] In this way, the rights request, from receiving and parsing, cross-system data directory retrieval, atomic operation task mapping, atomic operation task scheduling and execution, compliance response log generation, to cross-system data directory update, forms a closed loop of "request - mapping - execution - log - update".

[0074] This application provides an automated response system for data subject rights claims based on a large language model. The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the aforementioned automated response method for data subject rights claims.

[0075] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 2As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a server-side method for automatically responding to data subject rights requests.

[0076] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 3 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of an automated response method for data subject rights claims.

[0077] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0078] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0080] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for automatically responding to data subject rights requests, characterized in that, Includes the following steps: Based on the target large language model, intent recognition and entity extraction are performed on multilingual rights claim texts. The expressions of rights claim texts in different languages ​​are normalized into standardized rights operation intent templates, which include rights action types and data subject identity identifiers. Based on a pre-built cross-system data catalog, retrieve the storage location information corresponding to the data subject's identity identifier; Based on the determined type of right action, the right operation corresponding to the right action type is decomposed into parallel or serial operation steps, with different operation steps corresponding to different types of right actions; Based on the storage location information, determine the system type of each target heterogeneous data storage system, and call the preset operation converter corresponding to the system type of each target heterogeneous data storage system; The operation steps are converted into atomic operation tasks that can be executed by each target heterogeneous data storage system through the preset operation converter. Based on the right action type and the storage location information, the right operation intent template is mapped to an atomic operation task targeting one or more heterogeneous data storage systems; The atomic operation tasks are scheduled and executed sequentially according to a predetermined order, and the operation execution evidence generated during the execution of each atomic operation task is recorded. Based on the operational execution evidence for each of the atomic operation tasks, a compliance response log is generated for the claim text.

2. The automated response method for data subject rights requests according to claim 1, characterized in that, The process of performing intent recognition and entity extraction on multilingual rights claim texts based on a target large language model, and normalizing the expressions of rights claim texts in different languages ​​into standardized rights operation intent templates, includes: Based on the target large language model, the language type of the rights claim text is identified; Based on the semantic parsing rules corresponding to the language type, extract the right type, data subject identity identifier, data scope description, and time constraint entity from the right request text; Based on the target large language model, the privacy law knowledge base corresponding to the language is invoked to map the right type, data subject identity identifier, data scope description and time constraint entity into a cross-language unified standard right operation intent template.

3. The automated response method for data subject rights requests according to claim 2, characterized in that, The process of performing intent recognition and entity extraction on multilingual rights claim texts based on a target large language model, and normalizing the expressions of rights claim texts in different languages ​​into standardized rights operation intent templates, also includes: When extracting entities from multilingual rights claim texts based on the target large language model, the confidence score of the entity extraction is output. When the confidence score corresponding to the data range description is lower than a preset threshold, it is determined that the data range description is ambiguous. Based on the target large language model, multiple rounds of dialogue and follow-up questions are conducted in the identified language to determine the clarified data range description; Based on the clarified data scope description, the rights request text is transformed into a structured rights operation intent vector, which includes the rights action type, data subject identity identifier, data scope, and confidence level.

4. The automated response method for data subject rights requests according to claim 1, characterized in that, The process of retrieving storage location information corresponding to the data subject's identity identifier based on a pre-built cross-system data directory includes: Construct a cross-system data catalog, and maintain a global data subject index in the cross-system data catalog. The global data subject index is used to record the storage location, data type and data format of each data subject in each target heterogeneous data storage system. Input the data subject identity identifier in the rights operation intent template into the global data subject index for querying; The storage location of the data subject identity identifier in each target heterogeneous data storage system is obtained from the global data subject index.

5. The automated response method for data subject rights requests according to claim 1, characterized in that, The step of mapping the right operation intent template to atomic operation tasks targeting one or more target heterogeneous data storage systems further includes: When the atomic operation task is generated, the scope of the atomic operation task is limited to the record corresponding to the data subject identity identifier; The atomic operation tasks after the operation scope is limited are subject to compliance verification to confirm the data conflict between the right action type and the record corresponding to the data subject identity identifier in the target heterogeneous data storage system; After the verification is passed, the atomic operation task is determined to be an executable atomic operation task.

6. The automated response method for data subject rights requests according to claim 1, characterized in that, The step of converting the operation steps into atomic operation tasks executable by each target heterogeneous data storage system through the preset operation converter includes: When the right action type is access, the preset operation converter will convert the data export operation into a structured query language query task for the data warehouse; When the right action type is deletion, the preset operation converter converts the data deletion operation into an object deletion task for object storage, or into a time window anonymization task for the log system.

7. The automated response method for data subject rights requests according to claim 1, characterized in that, The step of scheduling and executing the atomic operation tasks sequentially according to a predetermined order, and recording the operation execution evidence generated during the execution of each atomic operation task, includes: According to the predetermined order of the distributed task scheduler, the interfaces of the target heterogeneous data storage system corresponding to each atomic operation task in the execution queue are called sequentially for execution; Record the start time, end time, operation object, number of rows affected, and return status of each atomic operation task; The recorded start time, end time, operation object, number of affected rows, and return status are stored in an immutable manner as evidence of operation execution.

8. The automated response method for data subject rights requests according to claim 1, characterized in that, The step of generating a compliance response log for the claim text based on the operation execution evidence of each atomic operation task includes: Based on the target large language model, operation details are extracted from the operation execution evidence of each atomic operation task. The operation details include the operation time, operation type, and operation result of each target heterogeneous data storage system. Based on the extracted operation details, a multilingual compliance response log is generated, including timestamps and full-chain operation details.

9. An automated response system for data subject rights claims based on a large language model, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the data subject rights claim automated response method as described in any one of claims 1 to 8.

Images