A semantic-preserving desensitization and restoration method and system for large model applications
Patent Information
- Application Number
- CN202611054139.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-15
- Publication Date
- 2026-09-04
AI Technical Summary
缺陷一,采用纯占位方式脱敏,即把每一个敏感值替换为一个无意义的占位符
效果一,由区别特征一与区别特征二的机制必然性,脱敏后的数据在隐去真实值的同时保留了数值的大小顺序、分位水位与文化合规语义,故外部引擎在只见脱敏骨架的情况下仍能正确完成数值比较与语义推理,例如仍能判断成交价是否低于成本、仍能据泛化后的文化标签生成合规文案;相较纯占位脱敏使外部引擎推理能力丧失的方案,本方案使脱敏与可用性得以兼得。
Smart Images

Figure CN122693031A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of artificial intelligence and data security technology, specifically to a method and system for semantically desensitizing data carrying sensitive fields before a business system calls an external engine for processing, and for restoring the output of the external engine to the true value after the external engine returns. The external engine includes a Large Language Model (LLM) inference engine and a skill execution engine. Background Technology
[0002] When providing intelligent services to users, business systems typically need to submit data containing user confidentiality to external engines for processing. For example, data containing sensitive fields such as break-even prices, costs, inventory depth, compliance red-line words, and cultural tags may be written into prompts and sent to a large language model inference engine to generate solutions or copy, or sent to a skill execution engine to execute predetermined processing logic. Once these sensitive fields are sent to the external engine in plaintext, user confidentiality leaves the controllable domain, posing a risk of leakage if retained by the external engine, absorbed during training, or obtained by a third party. For compliance scenarios that require data to remain within the controllable domain, this risk of leakage is a fundamental obstacle to contract signing and compliance.
[0003] To protect sensitive fields while utilizing external engine capabilities, current practices often involve de-identifying sensitive fields at the data outgoing point. However, these existing technologies have the following specific drawbacks: The first drawback is the use of a pure placeholder approach for anonymization, which replaces each sensitive value with a meaningless placeholder. While this method hides the actual value, it also erases the comparability and semantic features between values. This prevents large language model inference engines from performing numerical comparisons and semantic reasoning based on the anonymized data. For example, it cannot determine whether a transaction price is lower than cost, or generate compliant copy based on a cultural tag. After anonymization, the external engine's reasoning ability is lost, and anonymization and usability are mutually exclusive.
[0004] The second flaw is that data masking is only performed once at the data outgoing entry point, failing to cover secondary calls within the engine initiated by the external engine to another external engine during its execution. For example, during the execution of a skill execution engine, the processed intermediate skeleton may be rewritten into the prompt words to call the large language model inference engine. If this secondary call within the engine is not masked again, sensitive fields will still be leaked at the secondary call point. Masking only once at the entry point is insufficient to achieve full-path coverage of confidentiality.
[0005] The third flaw is the improper handling of the mapping relationship used for restoration after anonymization. Some solutions transmit the correspondence between anonymized values and real values to external engines along with the anonymized data, or store them locally but do not encrypt them or isolate the keys of different users, making the restoration mapping itself an entry point for leaking the real value, rendering the anonymization ineffective.
[0006] Fourthly, the de-identification process lacks a safety baseline of rejection upon failure. When failures occur in rule loading, de-identification calculation, or the retrieval of the benchmark for order preservation, some solutions degenerate into allowing plaintext or outputting it without order preservation, resulting in sensitive fields being exposed outside the domain in failure scenarios. In addition, such solutions usually lack privacy protection when refining aggregated multi-user data, and the refined results in small samples can be extrapolated back to a single user.
[0007] Therefore, the industry urgently needs a method and system that can preserve the comparability and semantics necessary for external engine inference while concealing the true value, cover secondary calls within the engine, and safeguard confidential information throughout the entire process with a security baseline of locally encrypted and non-transmitted restoration mapping and rejection upon failure. Summary of the Invention
[0008] (a) The technical problem to be solved by the present invention The technical problem this invention aims to solve is: how to conceal the true value to prevent confidentiality leakage when a business system calls an external engine to process data carrying sensitive fields, while preserving the numerical comparability and semantic features necessary for the external engine's inference, covering secondary calls within the external engine, supporting correct restoration after the call return with locally encrypted and non-externalized restoration mapping, and refusing to allow any data to pass if any link in the de-identification link fails. This overcomes the shortcomings of existing pure placeholder de-identification methods that lose usability, de-identify only at the entry point and miss internal secondary calls, transmit or not encrypt restoration mappings, and lack a failure-based rejection security baseline. Essentially, the above technical problem is a data security processing problem for computer systems to perform deterministic de-identification, placeholder preservation, reversible restoration, and failure-based rejection on data transmitted across trust domains. This invention solves this problem with a unified de-identification mapping, locally encrypted restoration mapping, and end-to-end failure rejection. The resulting technical effects at the data security level include sensitive data not leaving the domain, reversible and semantically comparable de-identification, and no de-identification missed even in internal secondary calls, rather than simply improving business management.
[0009] (II) Complete Technical Solution To address the aforementioned technical problems, the first aspect of this invention provides a semantic-preserving desensitization and restoration method for large-scale model applications, comprising the following steps: S1, receive the original data containing sensitive fields, as well as the tenant identifier and call mode submitted by the caller before initiating a call to the external engine. The external engine includes a large language model inference engine and a skill execution engine. S2, load the sensitive field rules of the tenant according to the tenant identifier, hit the sensitive fields in the original data and determine a desensitization method for each hit field. The desensitization method is determined from four options: order-preserving desensitization, position-based desensitization, semantic generalization desensitization, and placeholder desensitization. If the tenant has no corresponding rules, it will fall back to the platform's default rules. S3, perform desensitization on each hit field according to its desensitization method to obtain a desensitized representation that hides the real value, and accumulate and register the correspondence between each desensitized representation and its real value as a restoration mapping. After each desensitized representation replaces the corresponding real value in the original data, a desensitized skeleton is formed. S4, generate a mapping token referencing the restoration mapping, determine the lifespan of the restoration mapping according to the calling mode, encrypt the restoration mapping and store it locally only and never transmit it with the de-identified skeleton, and only send the de-identified skeleton to the external engine. S5, Receive the engine output returned by the external engine after processing based on the desensitized skeleton; S6, retrieve the restoration map using the mapping token, recursively traverse the engine output, replace the desensitized representation that matches the restoration map with the corresponding real value to obtain the restoration result, and clear the mapping token after restoration is completed; if any step S2 to S4 fails, the call is rejected and no data is output to the external engine.
[0010] The second aspect of the present invention provides a semantic-preserving desensitization and restoration system for large model applications, including a rule parsing module (10), a desensitization execution module (20), a baseline management module (30), a mapping storage module (40), a restoration execution module (50), and an auditing module (60), for executing the above-mentioned methods; the system can also be implemented as an electronic device including a processor (501), a memory (502), a bus (503), and a communication interface (504), as well as a computer-readable storage medium storing a corresponding computer program.
[0011] (iii) Technical features that distinguish it from existing technologies The technical features that distinguish this invention from the prior art are the combination of the following items, and each item can be found in the specific embodiments of this specification: The first distinguishing feature is that the desensitization method selects one of four methods based on the semantics of the hit field: order-preserving desensitization, positional desensitization, semantic generalization desensitization, and placeholder desensitization. It preserves the order of the values to be compared, the positional values of the values requiring high and low watermark semantics, and the semantic features of cultural compliance brand semantics. In this way, it preserves the comparability and semantics necessary for external engine inference while hiding the true values. In contrast, existing technologies use pure placeholder desensitization, which results in the loss of comparability and semantics after desensitization.
[0012] The second distinguishing feature is that multiple numeric fields of the same type within the same call are calculated using the same ascending-order baseline snapshot to ensure that the desensitized representation strictly maintains the same size order as the real value, and is rejected when the baseline is missing rather than degraded in a non-order-preserving manner; in contrast, existing technologies do not guarantee order-preserving consistency, or degrade the output when the baseline is missing.
[0013] The third distinguishing feature is that the desensitization coverage not only includes calls to external engines, but also internal secondary calls initiated by the skill execution engine to the large language model inference engine during its execution process, achieving full-path coverage of confidentiality. In contrast, existing technologies only desensitize data once at the data outgoing entry point and then allow it to pass, missing internal secondary calls.
[0014] The fourth distinguishing feature is that the restoration mapping uses a field token with a type prefix as the key, is encrypted by the tenant key, and is stored locally only, with each tenant key isolated from the others. It is never transmitted outside the desensitized skeleton. During restoration, the engine output is recursively traversed and the mapping token is cleared after restoration. In contrast, existing technologies may transmit the mapping outside, store it locally in plaintext, or not isolate the user key.
[0015] The fifth distinguishing feature is that the de-identification link is constrained to a state machine where failure means rejection. Only when the de-identification is completed is the de-identification skeleton allowed to be sent to the external engine. If any of the following steps fails, such as rule loading, de-identification, or benchmark retrieval, the system will enter the rejection state as the final security state, and no data will be allowed to pass through, and an audit alarm will be written. In contrast, existing technologies lack the security bottom line of rejection upon failure, and data will be exposed in plaintext when the system fails.
[0016] The sixth distinguishing feature is that before aggregating multi-tenant data to extract cross-tenant results, it first undergoes dual gatekeeping with a minimum number of tenants and an anonymity threshold, and optional differential noise is injected to prevent small samples from back-inferring a single tenant; in contrast, existing technologies lack group-level privacy protection for cross-tenant extraction.
[0017] (iv) Technical effects that are not available in the prior art resulting from the above distinguishing features. The combination of the above-mentioned distinguishing technical features produces the following technical effects that are not present in the prior art: Effect 1: Due to the inherent mechanism of distinguishing features 1 and 2, the anonymized data retains the numerical order, percentile, and cultural compliance semantics while concealing the true value. Therefore, external engines can still correctly perform numerical comparisons and semantic reasoning even when only the anonymized skeleton is visible. For example, they can still determine whether the transaction price is lower than the cost and generate compliant copy based on the generalized cultural tags. Compared to pure placeholder anonymization that causes external engines to lose their reasoning ability, this solution achieves both anonymization and usability.
[0018] Secondly, due to the inherent mechanism of the distinguishing feature three, the secondary calls initiated by the skill execution engine to the large language model inference engine during its execution process are also desensitized first. Therefore, sensitive fields will not be leaked at the secondary call. Confidential information will not leave the domain as real values in all call paths, achieving full path coverage, rather than just one entry point.
[0019] Effect 3: Due to the inherent mechanism of the distinguishing feature 4, the restoration mapping is neither transmitted externally nor encrypted locally and is isolated by tenant key. Therefore, the external engine cannot access the real value at all, and the restoration mapping itself does not become a leakage entry point. Recursive restoration ensures that the desensitized representations embedded in the engine output structure and even in the text are correctly replaced with the real value. The use and disposal method prevents the mapping from being stuck for a long time.
[0020] Fourthly, due to the inherent mechanism of the fifth distinguishing feature, failure in any link of the desensitization link will result in rejection, so sensitive fields will not be exposed outside the domain in the event of failure, achieving the security bottom line of "it is better to fail this business than to leak confidential information"; sixthly, cross-tenant extraction is rejected or protected by differential protection in small samples, and the confidentiality of a single tenant is not reversed.
[0021] In summary, the present invention employs technical means to solve technical problems and achieve measurable technical effects. The combination of the distinguishing technical features produces technical effects that are unpredictable by existing technologies, which both conceal the truth value and ensure availability, and provide full path coverage with a safety baseline of rejection upon failure.
[0022] Furthermore, this invention is not simply a combination of the aforementioned single-point technologies: four methods—semantic-preserving desensitization—preserve comparability and semantics for the external engine; order-preserving benchmark snapshots ensure correct comparisons within the same call; second-level call coverage within the engine blocks the entire path; local encrypted and non-transmitted restoration mapping and recursive restoration support correct backfilling; a failure-based rejection state machine safeguards the bottom line of security; and cross-tenant gatekeeping prevents group-level backtracking. These six methods support each other, forming a closed loop of desensitization-processing-restoration. The absence of any one of these elements will result in leakage or unavailability at the corresponding stage. In particular, this invention places semantic-preserving desensitization under the premise of concealing the true value, while simultaneously preserving the comparability of numerical values and culturally compliant semantics. This overcomes the long-standing technical bias in the field that "desensitization inevitably sacrifices semantic usability, and the two are mutually exclusive"—the conventional practice in the field is to exchange security for pure placeholder space at the expense of usability. However, this invention proves that the comparability and semantics required for external engine inference can be preserved without exposing the true value. This is the concentrated embodiment of the inventiveness of this invention. Attached Figure Description
[0023] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments are briefly introduced below.
[0024] Figure 1 This is a schematic diagram of the overall process of the semantic-preserving desensitization and restoration method described in an embodiment of the present invention; Figure 2 This is a schematic diagram of the semantic-preserving desensitization and restoration system described in an embodiment of the present invention; Figure 3 This is a timing diagram illustrating a complete desensitization-processing-restoration call of the system described in this embodiment of the invention; Figure 4 This is a schematic diagram illustrating the data flow between the steps of the method described in the embodiments of the present invention; Figure 5 This is a schematic diagram of the structure of the electronic device described in an embodiment of the present invention.
[0025] Figure 2 The attached diagrams are labeled as follows: 10-Rule parsing module, 20-De-identification execution module, 30-Baseline management module, 40-Mapping storage module, 50-Restore execution module, 60-Audit module; Figure 5 The reference numerals in the figures are: 501-processor, 502-memory, 503-bus, 504-communication interface. Detailed Implementation
[0026] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Those skilled in the art, after reading this specification, can make equivalent substitutions, combinations, or improvements to the following embodiments based on the principles of the present invention, all of which fall within the protection scope of the present invention. To ensure sufficient disclosure, the following provides feasible processing logic, data structures, general symbolic forms of computational formulas, exception and boundary handling, alternative implementation methods, and numerical examples for each step; where specific values are involved, they are demonstrative values for ease of understanding, not actual production configurations, and do not constitute a limitation of the present invention. The collection and processing of data involved in this invention are all carried out under the premise of obtaining explicit authorization from the relevant subject. Sensitive fields are used after irreversible desensitization to remove personal identification identifiers, complying with the relevant provisions of the "Data Security Law of the People's Republic of China" and the "Personal Information Protection Law of the People's Republic of China."
[0027] I. System Overall Architecture and Responsibilities of Each Module See Figure 2 The system in this embodiment of the invention serves as an independent data security layer bridging the business module and the external engine, acting as the necessary gateway for the business module to initiate calls to any external engine. Logically, the system is divided into a rule parsing module (10), a de-identification execution module (20), a baseline management module (30), a mapping storage module (40), a restoration execution module (50), and an auditing module (60). Each module can be mapped as an independent functional unit, or it can be merged or split according to deployment needs. Data is sequentially transmitted, with the structured output of the previous module serving as the input of the next module. The system can be implemented in two integrated forms: an in-process software development kit (SDK) and an independent remote service. The former is used for latency-sensitive real-time channels, while the latter is used for standard channels; both forms have consistent external contracts.
[0028] The rule parsing module (10) is responsible for loading the sensitive field rules of the tenant according to the tenant identifier, hitting the sensitive fields in the original data, and determining the de-identification method to be used for each hit field; if the tenant has no corresponding rules, it will fall back to the platform's default rules. The de-identification execution module (20) is responsible for performing de-identification on each hit field according to its de-identification method, obtaining the de-identified representation, and accumulating and registering the correspondence between the de-identified representation and the real value as a restoration map. The baseline management module (30) is responsible for providing the ascending baseline snapshot of the same type of value for the tenant for order-preserving de-identification and position-based de-identification, and ensuring that the same type of value maintains its size relationship after de-identification within the same call. The mapping storage module (40) is responsible for generating mapping tokens, determining the lifespan according to the call mode, encrypting the restoration map and storing it only locally. The restoration execution module (50) is responsible for retrieving the restoration map with the mapping token and recursively outputting the restoration engine, and clearing the mapping token after restoration. The audit module (60) is responsible for recording each de-identification, restoration and rejection, and writing an audit and issuing an alarm when rejection occurs.
[0029] The modules mentioned above are connected to structured intermediate results through controlled interfaces, and the interface calls are implemented using a request-response method or a message channel method. The system can be implemented in software, hardware or a combination of software and hardware, and can be distributed and deployed in a private cloud or server cluster; the system can also be implemented as an electronic device including a processor (501), a memory (502), a bus (503) and a communication interface (504).
[0030] One unchanging boundary of responsibility in this system is: the real value exists only at the input of the desensitization execution module (20) and the output of the restoration execution module (50), and all intermediate links are represented by desensitization; the restoration mapping is only read and written encrypted by the mapping storage module (40), and no module may persist the real value in plaintext; if any field fails to desensitize, the desensitization execution module (20) will directly throw an error to trigger rejection, and skipping the field is prohibited. These three boundaries of responsibility are internal invariants that must be maintained during the implementation of subsequent stages, and are the structural guarantee of the security of this system.
[0031] (a) Internal processing stage and data flow From an internal processing perspective, a complete call sequentially goes through stages such as rule parsing, field-by-field desensitization, benchmark retrieval, mapping encryption storage, auditing, external engine processing, and recursive restoration. The encryption can use an authentication encryption algorithm (such as AES-GCM), and the key is managed in isolation by tenant. In the rule parsing stage, the rule parsing module (10) loads the tenant rules and marks the desensitization method for each hit field in the original data. In the field-by-field desensitization stage, the desensitization execution module (20) desensitizes the hit fields according to the method. Among them, the order-preserving desensitization and the positional desensitization are calculated by the benchmark management module (30) taking the tenant's similar distribution to calculate the order-preserving position or positional, the semantic generalization desensitization looks up the generalization dictionary, and the placeholder desensitization generates placeholders. Each field accumulates the correspondence between the desensitized representation and the real value into the restoration mapping. If any field fails to desensitize, an error is thrown and the call is transferred to the rejection state without returning the desensitized skeleton. Subsequently, the mapping storage module (40) generates a mapping token, selects the survival time according to the call mode, and writes the restored mapping encrypted locally. The auditing module (60) records this desensitization. At this point, the desensitized skeleton is returned and sent to the external engine. After the external engine finishes processing and returns the engine output, the restore execution module (50) retrieves the restore mapping based on the mapping token. If it cannot retrieve the mapping, it returns a restore failure; if it does retrieve the mapping, it recursively restores the mapping and clears the mapping token. The audit module (60) records this restore. The above stages are both a dynamic unfolding of the module's responsibilities and a process of... Figure 3 The timing and Figure 4 The internal basis for the data flow shown.
[0032] (ii) Desensitization-free state and possible concurrent states The de-identification execution and rule parsing are pure processing without side effects, and can be horizontally scaled for concurrent execution; the distributed data of the baseline management module (30) is carried by a cache, with more reads than writes, and does not constitute a bottleneck. Multiple calls do not share variable states with each other, but only share read-only rules and baseline caches, so that under high concurrency, the de-identification results of each call can still be guaranteed to be independent of each other, and the ordering consistency within the same call is not affected by other calls.
[0033] II. Checkpoint Positioning and Coverage Boundaries This system is positioned as the crucial gateway for all outbound calls from business modules or external engines, with the following coverage boundaries: Calls from business modules to the skill execution engine must pass through this system; calls from business modules to the large language model inference engine must pass through this system, as this is the most vulnerable point for leakage when the hint word contains confidentiality; secondary calls within the engine of the skill execution engine to the large language model inference engine must pass through this system, providing depth of defense; calls from business modules to any third-party engine must pass through this system. Conversely, reads and writes from business modules to their own storage within the domain do not require desensitization by this system, as this data is already within a controllable domain and has not left the domain. Therefore, this system converges all possible outbound paths of confidential information through the same gateway, ensuring that all outbound requests are desensitized and all inbound requests are restored, thus architecturally guaranteeing that confidential information does not leave the domain with its true value.
[0034] The objects protected by this system are tenant confidential fields, such as break-even price, cost structure, inventory depth, compliance red line words that have triggered penalties in the past, religious and cultural labels of specific target areas, etc. These fields vary from industry to industry and tenant to tenant, so they are carried by sensitive field rules that can be configured by the tenant, rather than hard-coded.
[0035] III. Data Access and Rule Parsing Phase (Steps S1 and S2) (a) Access and Packaging of Calls Before initiating a call to any external engine, the business module submits the original data carrying sensitive fields, the tenant identifier, and the call mode to this system. This system then wraps the call in a unified manner: first, desensitizes the data; then, it calls the external engine; and finally, it restores the data. The external engines include a large language model inference engine and a skill execution engine. The original data is a key-value structure, and its values can be any nested scalar, dictionary, or list. The call mode includes synchronous and asynchronous modes, used to determine the lifespan of the restored mapping. The business module itself does not directly send data carrying the actual values to the external engine; all data is wrapped by this system, thus converging the only path for confidential data to leave the domain to this system within the architecture.
[0036] (ii) Loading and hitting of sensitive field rules The rule parsing module (10) loads the sensitive field rules for the tenant based on the tenant identifier. Each rule contains at least three items: field name matching pattern, field value type, and desensitization method. The field name matching pattern matches the field name in the original data using a wildcard method. The field value type is used for baseline bucketing and audit classification. The desensitization method specifies which of the four desensitization methods should be used for the field. The rule can also carry the generalization dictionary identifier referenced by the semantic generalization desensitization. The rule is loaded as a read-only immutable object to avoid tampering during runtime. After loading, it is cached locally to reduce the overhead of repeated loading. When there is no corresponding rule for the tenant, it falls back to the platform's default rule. When the rule loading fails, it enters a rejection state and does not allow any data to pass.
[0037] The system matches each field of the original data against the tenant's rules. Matched fields are labeled with their value types and desensitization methods; fields not matched are retained as is. Wildcard matching is used for field names, allowing synonymous fields to be covered by the same rule. When a field matches multiple rules, the rule is selected based on its priority to avoid ambiguity. Rules support hot configuration and hot deactivation, allowing rules to be added, modified, or disabled without restarting the system, adapting to the varying sets of sensitive items for different tenants across industries.
[0038] IV. Determination and Implementation of Four Desensitization Methods (Step S3) The desensitization execution module (20) performs desensitization on each hit field according to its desensitization method. The four desensitization methods are selected according to the semantics of the hit field. The determination and execution are as follows.
[0039] (a) Order-preserving desensitization Order-preserving desensitization is suitable for numerical fields that require comparison, such as break-even price, cost, and budget. It works by taking an ascending snapshot of the field type for the tenant, mapping the actual value to its rank within that ascending snapshot, with the rank monotonically decreasing as the actual value increases. For example, the ascending snapshot can be a set of historical values of the same type arranged from smallest to largest, and the actual value can be mapped to the rightmost position it would be inserted into that snapshot. In cases of equality, it is placed after existing elements to ensure monotonicity. Thus, after desensitization, only the relative rank of the value within the same category is exposed, not the actual amount. External engines can still correctly compare the two values, for example, determining whether the rank of a transaction price is lower than the rank of the cost. The rank becomes more granular as the number of snapshot samples increases, but it always reflects only the relative order, not the actual amount. To ensure the ranking has statistical significance, the minimum sample size of the same type of snapshot for this field type is 20 (the following values are only demonstration values for ease of understanding and are not actual production configurations, and do not constitute a limitation); if the sample size of the benchmark is less than this minimum value, it will be rejected as a missing benchmark as described below.
[0040] (ii) Segregation desensitization Quantity-based anonymization is suitable for numeric fields requiring "high and low water level" semantics, such as price water level and inventory depth. It works by taking an ascending baseline snapshot of the tenant's field type and mapping the true value to its quantile or discretized tier within the distribution. For example, the quantile is the ratio of the true value's rank to the baseline sample size, mapped to an integer range of 0 to 100. The tier is created by discretizing the quantile into 5 tiers based on quantile breakpoints, with the upper bounds of the 5 tiers being 20, 40, 60, 80, and 100 respectively (these values are for illustrative purposes only and are not actual production configurations, nor do they constitute limitations). Thus, the external engine can determine from the anonymized representation whether the value is at a low, middle, or high water level in the historical distribution, and infer from this, without knowing the actual amount. The number of quantile tiers and the upper bounds of each tier are configurable. The difference between positional masking and order-preserving masking is that order-preserving masking retains the comparable order of any two values, while positional masking retains the semantic meaning of the water level relative to the historical distribution of a single value; the two can be selected according to the semantic meaning required by the field.
[0041] (III) Semantic generalization desensitization Semantic generalization desensitization is applicable to semantic fields such as culture, compliance, and brand. Its execution is as follows: according to the generalization dictionary configured for the tenant, the real value is mapped to a generalized expression that retains its semantic features. For example, a specific religious culture label is mapped to a generalized expression that "must comply with the requirements of the corresponding religious rules", a specific brand name is mapped to a generalized expression that "a first-tier brand of a certain category", and a specific compliance red line word is mapped to a generalized expression that "is a highly sensitive violation word and needs to be rewritten with a synonym to avoid it". Thus, the external engine can still perform compliance reasoning and copy generation based on its pre-trained knowledge according to the semantic features carried by the generalized expression, without touching the real specific identifier. When a semantic field cannot find a corresponding generalized item in the generalization dictionary, the desensitization execution module (20) throws an error and triggers rejection, and will never allow it to pass in its original form, so as to prevent semantic confidentiality from running naked out of the domain when there is no generalized item.
[0042] (iv) Desensitization of space Placeholder masking is suitable for fields where external engines do not need to perform any inference and only require placeholders for restoration, such as contact names and order numbers. It works by mapping the actual value to a placeholder that only carries the field type identifier, without preserving comparability or semantics. Placeholder masking is only used for such fields where external engines do not need to perform inference, avoiding misuse of placeholder masking for fields that require inference and resulting in a loss of usability; that is, among the four methods, placeholder masking has the weakest usability and should only be used when inference is truly unnecessary. This contrasts with existing pure placeholder masking, which uses placeholders for all fields.
[0043] (v) A safety net for method selection When a field fails to match a specific desensitization method, it is handled by a preset fallback method. The fallback method defaults to placeholder desensitization to prioritize security over usability when uncertain. The fallback method is a configurable option. If any field desensitization fails, the desensitization execution module (20) throws an error and triggers rejection, without returning the semi-finished desensitization skeleton.
[0044] V. Structured organization and field tokens for de-identified representation (a) Structured desensitization representation Each masked representation of a hit field is organized into a structured object carrying a field token, method identifier, and method-specific information. For order-preserving masking, the representation carries its position; for positional masking, it carries its position or grade; for semantic generalization masking, it carries its generalized expression; and for placeholder masking, it only carries the type identifier. This structured organization serves two purposes: first, the field token serves as the key for that item in the restoration mapping, allowing for reverse lookup of the true value during restoration; second, the method-specific information, such as position, position, and generalized expression, is readable by external engines, enabling them to infer information without accessing the true value. The masking skeleton is formed by replacing hit fields in the original data with this structured masked representation, while retaining the unhit fields as they are.
[0045] (II) Generation and Properties of Field Tokens Field tokens are prefixed with the field's type identifier and consist of a random segment. The type prefix allows auditors and troubleshooters to immediately identify whether the data has been anonymized (e.g., price, inventory, or other types). The random segment ensures that tokens for multiple fields of the same type are distinct within the same call, requiring only uniqueness within the lifecycle of a single restore map, not across calls. Field tokens serve as both the key to the restore map and the embedded anonymized representation, allowing the true value to be retrieved from the token in the anonymized representation during restoration.
[0046] (III) Generation and Properties of Mapping Tokens Unlike field tokens, mapping tokens are used to reference the entire restore map and are globally unique and unpredictable identifiers. Their unpredictability is crucial: the mapping token is the sole key to retrieving the restore map. If it could be guessed or enumerated, attackers could steal it. Therefore, mapping tokens are generated with sufficient randomness to prevent enumeration. The mapping token is returned to the caller along with the de-identification result, but it never enters the de-identification skeleton sent to the external engine. Thus, the external engine has neither the restore map nor the key to reference it.
[0047] VI. Maintaining consistency between tenant baseline snapshot and concurrent call sequence (Step S3) Both order-preserving desensitization and position-based desensitization rely on the benchmark of similar values for the tenant. The benchmark management module (30) maintains and provides the benchmark, which is the ascending distribution of recent similar values of a certain field type for the tenant. It is cached by tenant identifier and field type, with more reads than writes.
[0048] (i) The same baseline snapshot is retrieved in the same call. To ensure that multiple numeric fields of the same type within the same call strictly maintain their original size relationship after de-identification, this stage takes an ascending-order baseline snapshot of each field type at the beginning of each call. All numeric fields of the same type within that call use the same snapshot to calculate their rank or percentile. Since the rank under the same ascending baseline monotonically does not decrease with the actual value, if two actual values satisfy the condition that the former is less than the latter, then their de-identified rank will also satisfy that the former is not greater than the latter, thus maintaining the size relationship—a prerequisite for the external engine to correctly perform conditional comparisons. If different fields use baselines at different times, the consistency of order preservation may be disrupted because the baseline is refreshed between two fetches; therefore, sharing the same snapshot within the same call is necessary.
[0049] (ii) Reading snapshot semantics and background refresh The baseline snapshot adopts read snapshot semantics: once the baseline is retrieved, the snapshot is fixed, and the baseline management module (30) refreshes the distribution in the background at a preset period without affecting any ongoing calls. Thus, the update of the baseline is isolated from the ongoing de-identified calls, ensuring both order consistency and allowing the baseline to be smoothly updated with new data. The refresh period is a configurable item and can be set according to the type. For example, it is set to 5 minutes (the following values are only demonstration values for easy understanding and are not actual production configurations, and do not constitute a limitation).
[0050] (iii) Rejection due to missing benchmark If the reference for the field type of the tenant cannot be obtained through order-preserving or position-based masking (e.g., the reference is empty), this stage rejects the call and does not output in plaintext or without order preservation. This constraint ensures that the correctness of order preservation is not sacrificed due to the lack of a reference; it is better to fail the call than to output a masked representation that may mislead the external engine for comparison.
[0051] VII. Restore the encrypted storage, lifespan, and local non-transmission of the mapping (Step S4) (a) Mapping Tokens and Lifetime The mapping storage module (40) generates a mapping token for this call, which is used to reference the restore mapping during subsequent restore. The lifespan of the restore mapping is determined according to the call mode: In synchronous mode, the request and response are completed within a short period of time, so a shorter lifespan is used (exemplarily 5 minutes (the following values are only demonstration values for easy understanding and are not actual production configurations, and do not constitute a limitation)); In asynchronous mode, the task is queued through the message channel and executed asynchronously, so a longer lifespan is used, which is not less than the sum of the waiting time, execution time and maximum retry time of the task in the queue, so as to avoid the asynchronous long task from expiring before the restore (exemplarily 60 minutes (the following values are only demonstration values for easy understanding and are not actual production configurations, and do not constitute a limitation)). The lifespan tiers are configurable items.
[0052] (ii) Local encryption and tenant key isolation The restore map, encrypted with the tenant key, is stored locally only and is never transmitted to external engines along with the de-identified skeleton. Encryption employs an authentication-based encryption method that balances confidentiality and integrity, ensuring that any tampering with the restore map will result in an error during decryption. Encryption keys are derived per tenant, and each tenant's key is isolated from others; leakage of a single tenant's key will not affect other tenants. Therefore, even if local storage is accessed, the restore map remains encrypted; even if accessed by an external engine, it will never receive the restore map. The encryption master key can be obtained from the local protected environment or injected by an external key management service.
[0053] (iii) Disposable after use Once the restoration is complete, the restoration map is cleared, and the mapping token becomes invalid, ensuring that it is used and discarded immediately to prevent the mapping from remaining for a long time and expanding the exposure surface. Even if it is not actively cleared, the restoration map will expire after its lifespan, thus limiting its exposure window in time.
[0054] 8. External Engine Processing and Recursive Restoration (Steps S5 and S6) (a) External engine only shows desensitized skeleton This system only sends the anonymized skeleton to an external engine; the external engine processes the anonymized skeleton and returns its output, without ever accessing the actual value. For the large language model inference engine, it performs numerical comparison and semantic reasoning based on the position, quantile, and generalized semantics retained in the anonymized skeleton; for the skill execution engine, it executes predetermined processing logic based on the anonymized skeleton. Wherever the anonymized field is referenced in the engine output, it still appears with the corresponding anonymized representation.
[0055] (ii) Recursive Restoration The restoration execution module (50) retrieves the restoration map using the mapping token and recursively traverses the engine output: it traverses the dictionary, list, and text in the engine output layer by layer. For dictionary nodes, if they have a token and the token matches the restoration map, the entire node is replaced with the corresponding real value; otherwise, each value is recursively processed. For list nodes, each element is recursively processed. For text nodes, the part embedded in the form of a field token is replaced with the corresponding real value. The recursive traversal ensures that the de-identified representation is correctly restored regardless of which layer of the engine output structure it appears in, or even if it is embedded in a text string. After restoration is complete, the mapping token is cleared, the restoration result falls within the domain, and the real value is displayed to the user.
[0056] (III) Restored Map Expiration and Replay When the mapping token is retrieved and the restoration mapping has expired, the restoration execution module (50) returns a restoration failure with a replayable flag. For asynchronous long tasks, the lifespan is normally extended in asynchronous mode to prevent expiration; if it still expires, the caller decides whether to re-execute the de-identification and external engine call in the original context based on the replayable flag. This system does not automatically rerun the external engine call. When the mapping token is inconsistent with the tenant identifier at the time of submission, it is judged as a non-replayable security issue and restoration is refused. Restoration is never performed across tenants. When the caller re-executes in the original context based on the replayable flag, the number of retries is limited by an upper limit. For example, the upper limit of retries is 3 times, and the backoff interval of each retry is 1 second, 2 seconds and 4 seconds respectively (the following values are only demonstration values for easy understanding and are not actual production configurations, and do not constitute a limitation); if the retry limit is reached and the task still fails, it is judged as a failure of this business, and this system will not retry.
[0057] 9. Failure-based rejection state machine (compliance and security baseline) This system constrains each call as a state machine that rejects upon failure. Its core principle is: any uncertainty will result in rejection, and confidential information will never be exposed outside the domain.
[0058] (a) Legal Status and Migration The valid states of the state machine include: rule loading state, field-by-field de-identification state, de-identification completed state, engine invoked state, restoration in progress state, restoration completed state, restoration failed state, and rejection state. The transitions are as follows: When in the rule loading state, if the rule is successfully loaded (either a tenant rule exists or it reverts to the platform's default rule), it enters the field-by-field de-identification state; if the rule loading fails, it transitions to the rejection state. When in the field-by-field de-identification state, if all fields are successfully de-identified and the restoration mapping is encrypted and stored, it enters the de-identification completed state; if any field fails to be de-identified or the baseline cannot be obtained, it transitions to the rejection state. When in the de-identification completed state, the de-identified skeleton is allowed to be sent to the external engine, thus entering the engine invoked state. When in the engine invoked state and the engine returns and the mapping has not expired, it enters the restoration in progress state. When in the restoration in progress state, if restoration is successful, it enters the restoration completed state; if the mapping has expired, it enters the restoration failed state.
[0059] (ii) The rejection state is the safe final state. The rejection state is a safety final state, meaning that even if the current business fails, no data will be allowed to pass. When rule loading fails, any field desensitization fails, or the baseline for order preservation and quantile desensitization cannot be obtained, the system will transition to the rejection state without degrading to plaintext or out-of-order data. When the caller's business activity is in a critical or rollback-like abnormal state, the system will also reject all inbound and outbound traffic. An audit record is written and an alarm is issued upon transitioning to the rejection state. If the same tenant continuously enters the rejection state a set number of times, the tenant's calls to the external engine will be blocked. The set number of times is a configurable threshold (exemplarily set to 5 times; the following values are only demonstrative values for ease of understanding and are not actual production configurations, and do not constitute a limitation)
[0060] (iii) State machine invariants The state machine satisfies the following invariants: First, data is only allowed to be sent to the external engine when the data masking process is complete; data will never be allowed to pass through during the rule loading and rejection states. Second, the rejection state is a secure final state; once entered, no more data will be output. Third, entering the rejection state requires auditing and triggering an alarm. These invariants collectively ensure that sensitive fields are not exposed outside the domain if any link in the data masking chain fails. This system itself only guarantees no leakage and is not responsible for business degradation; when this system returns a rejection or error, the caller will handle subsequent business according to its respective fallback strategy.
[0061] 10. Defense depth coverage for secondary calls within the engine The system covers not only calls initiated by business modules to external engines, but also intra-engine secondary calls initiated by the skill execution engine to the large language model inference engine during its execution process. During execution, the skill execution engine rewrites the processed intermediate skeleton into prompt words to call the large language model inference engine. If this secondary call is not desensitized, sensitive fields will still be leaked. Therefore, before initiating, this intra-engine secondary call undergoes a complete chain of execution rule parsing, desensitization, mapping, encrypted storage, external engine processing, and recursive restoration, achieving full-path coverage of confidentiality in depth, rather than simply desensitizing once at the entry point from the business module to the external engine. To prevent resource exhaustion due to infinite nesting of call chains, the desensitization coverage level of intra-engine secondary calls is constrained by an upper limit, exemplarily set to a maximum of 3 levels (the following values are only demonstrative values for ease of understanding, not actual production configurations, and do not constitute a limitation). Calls exceeding this upper limit are rejected upon failure. Thus, regardless of whether sensitive fields flow through primary calls or intra-engine secondary calls, they will not leave the domain with their true values. This depth of defense contrasts with the existing practice of only anonymizing data once at the data outgoing entry point: the latter leaves a leak at the secondary call point within the engine, while the former blocks that leak by passing through a checkpoint on every outgoing data transfer.
[0062] XI. Multi-tenant isolation and cross-tenant gatekeeping (a) Tenant segregation This system uses tenant identifiers for complete isolation: sensitive field rules, baseline snapshots, restore mappings, encryption keys, and audit logs are all differentiated by tenant identifier. During restoration, the mapping token is verified to match the tenant identifier submitted; if they do not match, the restoration is rejected, preventing the misuse of confidential information caused by cross-tenant restorations. Encryption keys are derived by tenant, achieving tenant key isolation, thus ensuring that a single tenant's key leak does not affect other tenants.
[0063] (ii) Cross-tenant gatekeeping For scenarios involving aggregating and refining data from multiple tenants into cross-tenant results, this system employs a group-level privacy gatekeeper on top of field-level anonymization: Before refinement, the system verifies that the number of tenants participating in the refinement is not less than a minimum tenant threshold (exemplarily set at 5; these values are for illustrative purposes only and do not constitute a limitation in actual production configurations) and that the size of the indistinguishable groups corresponding to the refined result is not less than a set anonymity threshold (exemplarily set at 5; these values are for illustrative purposes only and do not constitute a limitation in actual production configurations)). Refinement is rejected if either condition is not met, preventing cross-tenant results from being backed up to a single tenant in small sample sizes. Furthermore, when differential protection is enabled, noise satisfying differential privacy is injected into the aggregation statistics of cross-tenant results, ensuring that the addition or removal of a single tenant does not significantly alter the cross-tenant results. Whether differential protection is enabled and its privacy budget are configurable; highly sensitive tenants can enable it by default. Field-level anonymization and group-level gatekeepers are not interchangeable: passing field-level anonymization does not mean the aggregation result cannot be backed up; therefore, group-level gatekeepers must be applied to cross-tenant refinement.
[0064] XII. Audit and Compliance Tracing The audit module (60) records an audit log for each de-identification, restoration, rejection, and cross-tenant extraction gatekeeping operation, enabling retrospective tracking of "whose data was de-identified or restored at what time, and why it was rejected." The audit log includes at least the tenant identifier, caller, target engine, operation type, number of de-identified fields, and a tracking identifier throughout the entire process. This tracking identifier is consistent on both sides of the de-identification and restoration process within a single call, allowing for pairwise association of de-identification and restoration within the same call. The audit log only records metadata such as the number and type classification of de-identified fields, not the actual values themselves, thus preventing the audit from becoming another entry point for leaking the actual values.
[0065] When a call enters a rejected state, an alert is issued in addition to write auditing. If the same tenant enters a rejected state a set number of times consecutively, the tenant's calls to external engines are blocked until manual intervention resolves the issue. This promptly cuts off the tenant's outbound communication channels when encountering abnormal rules, abnormal data, or malicious constructs that lead to repeated rejections, preventing repeated outbound attempts during the period of anomaly. Auditing and alerting provide a verifiable chain of evidence for compliance reviews and a counting basis for circuit breaker decisions.
[0066] XIII. Safety Invariants and Constraints The following invariants must be preserved during the implementation of this system, and they together constitute the security guarantee of this system: First, confidentiality is not allowed: any data sent to the external engine must be desensitized, and the real value only exists at the input end of the desensitization execution module (20) and the output end of the restoration execution module (50). All intermediate links are desensitized.
[0067] Secondly, failure is the priority of rejection: if any link in the desensitization process is uncertain or fails, it will switch to a rejection state and plaintext will never be allowed.
[0068] Third, maintain order correctness: After anonymizing similar values within the same call, strictly maintain their size relationship, and reject rather than disorder when the baseline is missing.
[0069] Fourth, semantics are not lost: numerical values are ordered or quantified, and semantics are generalized, rather than being meaningless placeholders, thus preserving the comparison and reasoning capabilities of the external engine.
[0070] Fifth, the mapping is not disclosed externally: the restoration mapping is only encrypted and stored on the platform side, discarded after use, and will never leave the domain with the desensitized skeleton.
[0071] Sixth, full coverage of secondary paths: not only calls from business modules to external engines, but also internal secondary calls from the skill execution engine to the large language model inference engine must pass through this system.
[0072] Seventh, cross-tenant back-inference is not allowed: cross-tenant extraction satisfies the minimum number of tenants and the anonymity threshold, and optional differential protection can be added to prevent back-inference of a single tenant from a small sample.
[0073] Eighth, the entire process is auditable: every desensitization, restoration, and cross-tenant extraction process is audited, and the tracking identifier runs through the entire chain.
[0074] The eight invariants mentioned above are not independent or isolated requirements, but rather mutually supportive: failure means refusal to keep secrets out of the domain; mapping means not being leaked; the mapping itself means not becoming a leak point; full coverage of secondary paths means that keeping secrets out of the domain is true across all paths; and cross-tenant non-reverse inference means that keeping secrets out of the domain at the aggregation level is not allowed. If any one of these invariants is violated, the overall goal of keeping secrets out of the domain fails at the corresponding stage.
[0075] XIV. Data Structures and Processes This chapter describes the data objects and their flow at each stage using general techniques, without involving any specific class names, table names, or field identifiers. See also Figure 4 Each step uses the output of the previous step as the input of the next step and passes structured intermediate results sequentially between steps, thus connecting to form a complete processing chain.
[0076] (a) Original data objects The raw data object is the input during the access phase. It is a key-value structure, and its values can be any nested scalar, dictionary, or list. Some fields are sensitive fields. The raw data object is accompanied by a tenant identifier and invocation mode.
[0077] (ii) Desensitized skeleton objects The de-identified skeleton object is the output of the de-identification stage. It is isomorphic to the original data object, but the sensitive fields that are detected have been replaced with structured de-identified representations, while the fields that are not detected are retained as is. The de-identified skeleton object is the only data object sent to the external engine, and it does not contain any real values, nor does it contain any restore maps or mapping tokens.
[0078] (iii) Restore the mapped object The restored mapping object is a collection with the field token as the key and the corresponding real value as the value. It is held and stored encrypted only on the platform side and will never be disclosed. After encryption, it is stored locally along with the mapping token, tenant identifier, call mode, and lifespan.
[0079] (iv) Engine output object and restoration result object The engine output object is the structure returned by the external engine after processing based on the de-identified skeleton. It can be any nested dictionary, list, or text, where references to de-identified fields still appear in their de-identified form. The restored result object is the result of recursively restoring the engine output object, where the de-identified values have been replaced with their true values and fall within the specified domain.
[0080] (v) Audit Record Objects The audit log records each instance of de-identification, restoration, rejection, and cross-tenant gatekeeping, including at least the tenant identifier, caller, target engine, operation type, number of de-identified fields, and a tracking identifier throughout the entire process, for compliance traceability.
[0081] 15. Exception and Boundary Handling (a) Rule loading failed When the tenant's rules fail to load and the platform's default rules are also unavailable, the system switches to a denial state, preventing any data from being passed and writing an audit alert.
[0082] (ii) Lack of benchmarks When the reference cannot be obtained for order preservation or positional desensitization, the system switches to a rejection state instead of degenerating into plaintext or out-of-order output, ensuring that the correctness of order preservation is not sacrificed.
[0083] (iii) Field desensitization failed When any field fails to be desensitized, the desensitization execution module (20) immediately throws an error, does not return the semi-finished desensitization skeleton, prohibits skipping the field and continues, and enters the rejection state. Semantic fields that cannot be found in the generalization dictionary also fall into this category of failure, and are also rejected instead of being allowed in the original text.
[0084] (iv) Expired restoration mapping If the mapping has expired during restoration, the restoration fails and a replayable flag is returned; asynchronous long-lived tasks have had their lifespan extended in asynchronous mode to avoid normal expiration, and those that have still expired are replayed by the caller based on the replayable flag; if the mapping token does not match the tenant identifier, it is judged as non-replayable and rejected.
[0085] (v) Any objection under abnormal conditions will be rejected. When the business activity of the caller is in a critical or rollback state, this system will refuse all inbound and outbound traffic until the abnormality is resolved, thus preventing the flow of confidential information under abnormal conditions.
[0086] XVI. Alternative Implementation Methods To enhance the sufficiency of disclosure and appropriately expand the scope of protection, alternative implementations are given below, all of which do not depart from the principles of this invention.
[0087] (a) Substitution of integrated forms This system can be implemented as a software development kit embedded in the caller's process to reduce latency, or as an independent remote service for centralized management and auditing. Both have consistent external contracts, and can be chosen or coexisted depending on the channel's sensitivity to latency.
[0088] (II) Alternatives to order-preserving and quantile algorithms In addition to using the insertion position of the true value in the ascending order benchmark, the order rank can also be replaced by the bucket number after equal-width or equal-frequency bucketing; in addition to using the ratio of rank to sample size, the quantile can also be replaced by the quantile obtained from empirical distribution function or kernel density estimation; the number of quantiles can be increased or decreased as needed, in addition to 5 quantiles. All the above substitutions are based on "maintaining the order of values of the same type" or "preserving the semantics of high and low water levels" and do not depart from the principle of this invention.
[0089] (III) Alternatives to Encryption and Key Derivation In addition to authentication encryption, the encryption of the restoration mapping can also be replaced by other methods that combine confidentiality and integrity protection; in addition to being derived by tenant identifier, the derivation of tenant keys can also be replaced by independent keys injected by the key management service per tenant; the source of the master key can be either the local protected environment or an external key management service.
[0090] (iv) Substitution of storage and lifespan The local storage for restoring the mapping can be either a memory cache or persistent storage with expiration capability; in addition to synchronous and asynchronous tiers, the lifespan tiers can also be subdivided into multiple tiers according to task type, but the asynchronous long task tier must cover the sum of queue waiting, execution, and maximum retries.
[0091] (v) Replacement of generalized dictionaries In addition to using a pre-built generalization dictionary, the semantic generalization mapping can also dynamically identify and generalize semantic fields instead of using named entity recognition and other methods. The generalization dictionary can be hot-configured by tenant, and different tenants can be configured with different generalization calibers.
[0092] XVII. Examples This chapter provides two complete demonstration examples, from raw data, rule parsing, four-method de-identification, mapping and encrypted storage, external engine processing, to recursive restoration. All data below are illustrative and intended to explain, not limit, this invention.
[0093] Example 1 (including scheme generation scenarios for order preservation and quantile preservation) Raw data (Step S1): Before calling the large language model inference engine to generate a business plan, a tenant submits raw data including the break-even price, cost, and inventory depth; along with the tenant's identifier and synchronous call mode. The break-even price and cost are the values to be compared, and the inventory depth is the value requiring high and low water level semantics.
[0094] Rule parsing (step S2): The rule parsing module (10) loads rules according to the tenant identifier, hits the break-even price and cost fields and determines that their desensitization method is order-based desensitization, hits the inventory depth field and determines that its desensitization method is position-based desensitization.
[0095] Desensitization (Step S3): The baseline management module (30) takes an ascending baseline snapshot for both the price category and the inventory category; the desensitization execution module (20) uses the same snapshot of the price category to calculate the position of the break-even price and the cost, so that the positions of the two after desensitization are consistent with the size order of the real value (that is, when the real price is lower than the cost, its position is not greater than the position of the cost); the inventory category snapshot is used to calculate the percentile of the inventory depth, and it is found to be in the low water level. For example, the ascending baseline snapshot of the price category contains 20 historical values of the same type. The break-even price is mapped to the position 8, and the cost is mapped to the position 12. The positions of the two are consistent with the size order of the real value; the inventory depth is mapped to the position 15, falling into the first of the 5 levels (low water level) (the following values are only demonstration values for easy understanding, not actual production configuration, and do not constitute a limitation). Each desensitization representation is accumulated and registered as a restoration mapping using the field token with the type prefix as the key.
[0096] Mapping Encryption Storage (Step S4): The mapping storage module (40) generates a mapping token, takes the shorter lifespan according to the synchronization mode, and stores the restored mapping locally after encrypting it with the tenant key; only the desensitized skeleton is sent to the large language model inference engine, and the restored mapping and mapping token do not enter the desensitized skeleton.
[0097] External engine processing and restoration (steps S5 and S6): The large language model inference engine judges the position of the bottom price to be lower than the cost and the inventory to be at a low level based on the position and quantile retained in the desensitized skeleton. Based on this, it generates the corresponding business plan and returns it to the engine output. The actual amount is not touched throughout the process. The restoration execution module (50) recursively restores the desensitized representation in the engine output as the real value based on the mapping token. After restoration, the mapping token is cleared and the result falls within the domain.
[0098] The technical effects of this example are as follows: First, the external engine can still correctly compare the base price and cost and perceive the inventory level even when it only sees the de-identified skeleton, thus preserving usability; Second, the real amount never leaves the domain, and the restoration mapping is locally encrypted and not transmitted externally; Third, each link in the de-identification link is under the constraint of a state machine, and any failure results in rejection.
[0099] Example 2 (including semantic generalization and placeholder scenarios, and second-level calls within the engine) Raw data (step S1): Before calling the skill execution engine to process compliance documents for a specific target area, a tenant submits raw data containing a specific religious culture tag, a specific compliance red line word, and a contact person's name; along with the tenant's identifier and asynchronous call mode.
[0100] Rule parsing and desensitization (steps S2 and S3): Religious cultural tags and compliance red-line words are identified, and their desensitization method is determined to be semantic generalization desensitization. Based on the generalization dictionary, these are mapped to "must comply with the relevant religious regulations" and "is a highly sensitive violation word, requiring synonymous rewriting to avoid detection." Contact person names are identified, and their desensitization method is determined to be placeholder desensitization, mapped to a placeholder carrying only the type identifier. All corresponding relationships are registered as restoration mappings.
[0101] Mapping Encryption Storage (Step S4): Take a longer lifespan in asynchronous mode (exemplarily 60 minutes (the following values are only demonstration values for easy understanding and are not actual production configurations and do not constitute a limitation)) to cover the sum of waiting, execution and maximum retries of tasks in the queue, so as to avoid asynchronous long tasks from expiring before restoration; after restoring the mapping, it is encrypted with the tenant key and stored only locally.
[0102] Secondary call within the engine (defense depth): During the execution of the skill execution engine, the intermediate skeleton obtained from the processing is rewritten into the prompt words to call the large language model inference engine. Before the secondary call within the engine is initiated, it is also desensitized by this system to prevent the sensitive semantics in the intermediate skeleton from being leaked at the secondary call point; after the secondary call returns, it is also recursively restored.
[0103] External engine processing and restoration (steps S5 and S6): The external engine generates compliant text based on the semantics carried by the generalized expression without touching the real specific identifier; the restoration execution module (50) recursively traverses the engine output, replaces the placeholders embedded in the text with the field tokens corresponding to the generalized expression with the real values, and clears the mapping tokens after restoration.
[0104] The technical effects of this example are as follows: First, semantic generalization enables the external engine to generate compliant text based on culturally compliant semantics, and placeholder desensitization ensures that names that do not require reasoning are restored by simply placing a placeholder; Second, secondary calls within the engine are also covered, and confidential information is not leaked at the secondary call level, achieving full path coverage; Third, asynchronous long tasks do not expire normally because their lifespan is amplified according to the asynchronous mode.
[0105] XVIII. System Implementation Examples and Electronic Device and Storage Media Implementation Examples Example 3 (System) Based on the same inventive concept as the above method, this embodiment provides a semantic-preserving desensitization and restoration system for large model applications, including: a rule parsing module (10), a desensitization execution module (20), a baseline management module (30), a mapping storage module (40), a restoration execution module (50), and an auditing module (60), used to execute the above method. Figure 2 As shown, each module corresponds to a specific step in the above method, with the structured output of the previous module serving as the input for the next module, and the modules are sequentially linked. The system can be implemented as either an in-process software development kit or a standalone remote service, while maintaining a consistent external contract.
[0106] Example 4 (Electronic Devices and Storage Media) like Figure 5 As shown, the present invention also provides an electronic device for implementing the above-described methods, including a memory (502), a processor (501), a bus (503), and a communication interface (504). The memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the methods described in any of the above embodiments. The present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the methods described in any of the above embodiments.
[0107] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention; any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A semantic-preserving desensitization and restoration method for large-scale model applications, characterized in that, Includes the following steps: S1. Receive the original data containing sensitive fields, along with the tenant identifier and call mode, submitted by the caller before initiating a call to an external engine. The external engine includes a large language model inference engine and a skill execution engine. S2. Load the sensitive field rules for the tenant according to the tenant identifier, match the sensitive fields in the original data, and determine a desensitization method for each matched field. The desensitization method is determined from four options: order-preserving desensitization, positional desensitization, semantic generalization desensitization, and placeholder desensitization. If the tenant has no corresponding rule, the system will fall back to the platform's default rule. S3. Perform desensitization on each matched field according to its desensitization method to obtain a desensitized representation that hides the real value. Accumulate and register the correspondence between each desensitized representation and its real value as a restoration map. Replace the corresponding real value in the original data with the desensitized representation of each matched field to form a desensitized skeleton. S4. Generate a mapping token referencing the restoration map. Determine the lifespan of the restoration map according to the call mode. Encrypt the restoration map and store it locally, never transmitting it with the desensitized skeleton. Only send the desensitized skeleton to the external engine. S5, Receive the engine output returned by the external engine after processing based on the de-identified skeleton; S6, Retrieve the restoration map using the mapping token, recursively traverse the engine output, replace the de-identified representation that matches the restoration map with the corresponding real value to obtain the restoration result, and clear the mapping token after restoration is completed; and if any step S2 to S4 fails, the call is rejected and no data is output to the external engine; and the external engine call also includes the intra-engine secondary call initiated by the skill execution engine to the large language model inference engine during its execution process. The intra-engine secondary call also performs the de-identification before initiation and performs the restoration upon return, so as to cover the entire call path.
2. The method according to claim 1, characterized in that, The four desensitization methods described in S2 are determined according to the semantics of the hit field: for numerical fields that need to be compared, the method is to determine the order-preserving desensitization, which maps the real value to the ordinal number that maintains the order of size among the same type of value; Numerical fields requiring high and low water level semantics are identified as quantile-based desensitization, mapping the real value to its quantile or rank in the historical distribution of similar values; cultural, compliance, or brand semantic fields are identified as semantic generalization-based desensitization, mapping the real value to a generalized expression that retains semantic features according to the generalization dictionary; fields for which the external engine does not need to perform any reasoning are identified as placeholder-based desensitization, mapping the real value to a placeholder that only carries type identifiers.
3. The method according to claim 1, characterized in that, In S3, for numeric fields identified as requiring order-preserving or quantile-preserving desensitization, an ascending-order baseline snapshot of the recent distribution of similar values for that field type is taken from the tenant. The real value is then mapped to its position or quantile in the ascending-order baseline snapshot. Multiple numeric fields of the same type within the same call are calculated using the same baseline snapshot, ensuring that the desensitized representation maintains the same size order as the real value. Once the baseline snapshot is taken, it is fixed, and its background refresh does not affect ongoing calls. Furthermore, if the baseline cannot be obtained, the call is rejected, and the output is not degraded in plaintext or without order preservation.
4. The method according to claim 1, characterized in that, The de-identification representation in S3 is a structured object carrying a field token and a method identifier. The field token is prefixed with a field type identifier. The field token serves as both the key for the item in the restoration mapping and is embedded in the de-identification representation. The restoration map described in S4 is encrypted with the tenant key and stored locally only. Each tenant key is isolated from the others, and the restoration map is not sent to the external engine along with the de-identified skeleton.
5. The method according to claim 1, characterized in that, This call is constrained to a state machine, and the valid states of the state machine include rule loading, field-by-field desensitization, desensitization completed, engine called, restoration in progress, restoration completed, and rejection. The de-identified skeleton is only allowed to be sent to the external engine when it is in the de-identification completed state; when the rule loading fails, any field de-identification fails, or the baseline cannot be obtained, it enters the rejection state. The rejection state is a safe final state and an audit is written and an alarm is issued when entering the rejection state; when the same tenant enters the rejection state continuously for a set number of times, the tenant's call to the external engine is blocked.
6. The method according to claim 1, characterized in that, The recursive traversal described in S6 iterates through the dictionary, list, and text in the engine output layer by layer. Whenever a desensitized representation that matches the restoration mapping is encountered, it is replaced with the corresponding real value, including the field token embedded in the text. If the restored mapping is expired when the restored mapping is retrieved with the mapping token, a restoration failure is returned with a replayable flag. The caller decides whether to re-execute S3 to S5 in the original context based on the replayable flag. If the mapping token is inconsistent with the tenant identifier at the time of submission, it is determined to be non-replayable.
7. The method according to claim 1, characterized in that, It also includes a cross-tenant extraction gatekeeping step: before aggregating and extracting data from multiple tenants into a cross-tenant result, it verifies that the number of tenants participating in the extraction is not less than the minimum number of tenants threshold, and that the size of the indistinguishable group corresponding to the extracted result is not less than the set anonymity threshold. If either of these conditions is not met, the extraction is rejected. Furthermore, when differential protection is enabled, noise is injected into the aggregate statistics of the cross-tenant results, so that the addition or departure of a single tenant does not significantly change the cross-tenant results.
8. A semantic-preserving desensitization and restoration system for large-scale model applications, characterized in that, include: The system includes a rule parsing module, a desensitization execution module, a baseline management module, a mapping storage module, a restoration execution module, and an auditing module. The rule parsing module is used to load sensitive field rules according to tenant identifiers and determine the desensitization method for the matched fields. The desensitization execution module is used to perform desensitization on the hit fields according to their desensitization methods, accumulate registration and restore mapping, and form a desensitization skeleton; the benchmark management module is used to provide ascending benchmark snapshots of the same value for order-preserving desensitization and position-based desensitization and ensure that the order is consistent within the same call. The mapping storage module is used to determine the lifespan according to the calling mode, encrypt the restored mapping and store it only locally, and generate a mapping token. The restoration execution module is used to recursively restore the output of the mapping token and clear the mapping token after restoration; the audit module is used to record desensitization, restoration and rejection and to issue an alarm when rejected; each module is used to execute the corresponding step of the method according to any one of claims 1 to 7.
9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 1 to 7.