Privacy policy automatic generation system and method

Abstract

The invention provides a privacy policy automatic generation system and method, and relates to the technical field of data processing, and the method comprises the steps: 1, collecting business information of an internet application, including data processing behaviors of the application and a third-party SDK, and converting the business information into a standardized privacy policy data input protocol format; 2, based on the privacy policy data input protocol format, laws and regulations and normative files are matched from a preset laws and regulations knowledge base, and a structured laws and regulations rule set is generated. According to the method, the privacy policy text which meets the requirements of laws and regulations and has formality and readability is finally generated by automatically collecting the service information, matching the laws and regulations and dynamically allocating the clause priorities, and the problem of manually maintaining the compliance and transparency of the privacy policy is solved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a system and method for automatically generating a privacy policy. Background Art

[0002] As internet application data processing scenarios become increasingly complex, the compliance generation of privacy policies faces significant challenges. The current mainstream manual maintenance model has three core problems: It is difficult to fully cover the data processing behaviors of the app itself and third-party SDKs manually, and it is easy to overlook dynamic runtime data (such as background permission calls and cross-border data transmission paths), resulting in incomplete disclosure of privacy information; Regulatory requirements for detailed disclosure of functional-level information (such as data types and third-party sharing details) are becoming increasingly refined. Manual interpretation can easily lead to disconnects between clauses and regulatory logic, impacting compliance. It is difficult to manually link the "function-data-permission" chain in a systematic manner, resulting in fragmentation of privacy policy content and an inability to meet users' needs for transparency.

[0003] Although existing automation solutions improve efficiency, they lack standardized data protocols and controllable processes. Unstructured data input can easily lead to semantic ambiguity. Purely automated generation does not introduce manual review at key nodes (such as clause priority and multilingual adaptation), and it is difficult to balance regulatory coverage, language formality and logical coherence. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a privacy policy automatic generation system and method thereof, which realizes efficient and compliant generation of privacy policies through standardized protocols and automated analysis.

[0005] In order to solve the above technical problems, the technical solutions of the present invention are as follows: In a first aspect, a method for automatically generating a privacy policy is provided, the method comprising: Step 1: Collect business information of internet applications, including data processing behaviors of the application itself and third-party SDKs, and convert the business information into a standardized privacy policy data input protocol format; Step 2: Based on the privacy policy data input protocol format, match laws, regulations, and normative documents from the preset regulatory knowledge base to generate a structured regulatory rule set; Step 3: Map the structured regulatory rule set to the triangle area formed by the three reference points. Based on the distance between the mapped data points and the center of gravity of the triangle, dynamically assign clause priorities and generate a clause requirement table containing functional-level disclosure clauses and third-party disclosure information. Step 4: Generate a privacy policy intermediate agreement based on the clause requirement table. The privacy policy intermediate agreement includes structured clause content, natural language descriptions, and manual review status marks in chapters. Step 5: Review the terms of the Privacy Policy Intermediate Agreement item by item, accept manual confirmation, modification, or rejection operations, and generate a revised Privacy Policy Intermediate Agreement after review; Step 6: Based on the revised privacy policy intermediate agreement, optimize the language and structure the terms to generate a privacy policy text that meets the formality and readability requirements.

[0006] Furthermore, the privacy policy data input protocol format includes data source, data type, operation type, purpose of use, functional module, third-party provider information and data transmission destination.

[0007] Furthermore, based on the privacy policy data input protocol format, the system matches laws, regulations, and normative documents from the pre-set regulatory knowledge base to generate a structured regulatory rule set, including: Parse the text content of laws, regulations and normative documents in the regulatory knowledge base, extract functional-level information disclosure requirements, and form structured rule entries that include disclosure content, data type, operation type and usage purpose; Semantically match the functional modules, data types, and usage purposes in the privacy policy data input protocol with the structured rule entries. Based on the correlation between the functional module's operating scenarios and regulatory provisions, a rule set containing the legal basis is generated. Based on the data source and operation type in the privacy policy data input protocol, the corresponding information disclosure requirements in the rule entries are dynamically matched, and the scope of application of the rules is adjusted based on the sensitivity level of the data type. Standardize and verify the field format of the rule set, verify the mapping relationship between the rule logic and the business information in the privacy policy data input protocol, and output an executable structured regulatory rule set.

[0008] Furthermore, the structured regulatory rule set is mapped to a triangle area formed by three reference points. Based on the distance between the mapped data points and the center of gravity of the triangle, the clause priority is dynamically assigned to generate a clause requirement table containing functional-level disclosure clauses and third-party disclosure information, including: Based on the functional-level disclosure requirements in the regulatory rule set, each clause is assigned a data sensitivity weight value and a regulatory constraint strength weight value. The weight value is dynamically adjusted based on historical compliance data and the weight ratio is modified based on the data type sensitivity level in the privacy policy data input agreement; The weight value is weighted and integrated with the functional modules and operation types in the privacy policy data input protocol to calculate the comprehensive priority score of the clause; Based on the comprehensive priority score, compliance risk analysis is conducted on clauses involving third-party SDK data transmission or sensitive data operations. Confidence tags associated with the comprehensive priority score are generated. Clauses with confidence levels below the preset threshold trigger a manual review process. Based on the comprehensive priority score and confidence mark, a clause requirement table is generated by sorting the comprehensive priority score from high to low.

[0009] Furthermore, based on the clause requirement table, a privacy policy intermediate agreement is generated. The privacy policy intermediate agreement contains structured clause content, natural language descriptions, and manual review status marks in different chapters, including: Build a natural language generation model based on the legal text specifications in the regulatory knowledge base; Convert the functional modules, data types, operation types, and regulatory basis in the terms and conditions table into structured terms and conditions according to the privacy policy section template. Use a natural language generation model to semantically optimize the structured terms and conditions, generate user-readable descriptions, and adjust the level of detail based on the overall priority score in the terms and conditions table. Add an initial status mark to each structured clause content and associate it with the corresponding functional module and data type; verify the integrity of the privacy policy intermediate agreement chapters and the standardization of the fields, and output an auditable privacy policy intermediate agreement.

[0010] Furthermore, the terms of the privacy policy intermediate agreement are reviewed item by item, and manual confirmation, modification or rejection operations are accepted. A revised privacy policy intermediate agreement is generated after the review, including: A visual interface displays the agreement clauses in a structured manner by chapter, categorizes them by review status, and dynamically associates the comprehensive priority scores and confidence levels in the clause requirements table. Receive manual confirmation, modification, or rejection of the terms and conditions, update the review status based on the manual operation, record the modification content, operator, and timestamp, and generate a revised intermediate agreement; For the rejected clauses in the revised intermediary agreement, the comprehensive priority score and confidence mark in the clause requirement table are updated based on the manual modification opinions, triggering the regeneration of the intermediary agreement process until a revised privacy policy intermediary agreement is generated after review and approval.

[0011] Furthermore, based on the revised privacy policy intermediate agreement, the terms and conditions were optimized and structured to generate a privacy policy text that meets formality and readability requirements, including: Based on the language requirements of the target region, we extract legal terms and sentence structure specifications of the corresponding language from the regulatory knowledge base and build a multilingual translation model; Use a multilingual translation model to standardize terminology and adjust sentence structure in the natural language descriptions in the revised privacy policy intermediate agreement to generate a formalized description that complies with legal text specifications. Based on the target region's language configuration, the formalized description is converted into the corresponding language version of the privacy policy chapters through a multilingual translation model; Verify the logical coherence of each chapter and splice them together in order to generate the complete privacy policy text; Based on the regulatory knowledge base, the key fields in the full text of the privacy policy, including third-party disclosure information and data operation types, are secondary verified to output the final privacy policy text.

[0012] Second, a privacy policy automatic generation system includes: The business information collection module is used to collect business information of Internet applications, including the data processing behavior of the application itself and third-party SDKs, and convert the business information into a standardized privacy policy data input protocol format; The regulatory rules mapping module is used to match laws, regulations, and normative documents from a pre-set regulatory knowledge base based on the privacy policy data input protocol format to generate a structured regulatory rules set; A priority allocation module is used to map a structured regulatory rule set to a triangular area formed by three reference points. Based on the distance between the mapped data points and the center of gravity of the triangle, it dynamically assigns clause priorities and generates a clause requirement table containing functional-level disclosure clauses and third-party disclosure information. An intermediate agreement module is used to generate a privacy policy intermediate agreement based on the terms requirement table. The privacy policy intermediate agreement includes structured terms content, natural language descriptions, and manual review status marks in different chapters. The manual review module is used to review the terms of the privacy policy intermediate agreement item by item, accept manual confirmation, modification or rejection operations, and generate a revised version of the privacy policy intermediate agreement after approval; The text optimization module is used to optimize the language and structure the clause content based on the revised privacy policy intermediate agreement, and generate a privacy policy text that meets the formality and readability requirements.

[0013] According to a third aspect, a computing device includes: one or more processors; The storage device is used to store one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement the method.

[0014] In a fourth aspect, a computer-readable storage medium stores a program, which implements the method when executed by a processor.

[0015] The above solution of the present invention includes at least the following beneficial effects: Through technical means such as code scanning and runtime monitoring, we systematically collect data processing behaviors within the application itself and third-party SDKs to prevent manual omission of sensitive data (such as location information and device ID) or hidden operations (such as backend permission calls). We convert unstructured information into a unified protocol format (PPDIP) to eliminate semantic ambiguity (for example, standardizing the term "device ID"). We extract function-level disclosure rules (such as "collection of sensitive data requires clear purpose") from the regulatory knowledge base to ensure that generated clauses are precisely aligned with regulatory requirements, reducing compliance risks caused by human interpretation bias. We dynamically match regulatory rules based on data source (such as third-party SDKs) and operation type (such as cross-border transfers) to enhance the relevance of clauses to business scenarios.

[0016] We prioritize clauses (e.g., highly sensitive data clauses are prioritized) by weighting factors like data sensitivity and regulatory constraints, ensuring that clauses for high-risk scenarios (such as third-party data sharing) are prioritized for generation and review. We assign confidence levels to clauses for complex scenarios (such as cross-border transfers), with clauses below the threshold triggering manual review, balancing automation efficiency and accuracy.

[0017] Present the clauses in a structured manner according to the sections of the privacy policy (such as "Data Collection" and "Third-Party Sharing"), with clear logic to facilitate subsequent review and user reading. Use large models to generate user-readable descriptive text (such as "Collecting location information for personalized recommendations") to improve policy transparency. Centrally display clauses through a visual interface, support batch confirmation of high-confidence clauses and focused review of low-confidence clauses, reducing the workload of manual review. Rejected clauses automatically trigger the regeneration process to ensure that all clauses ultimately comply with regulatory requirements and business practices. Optimize text expression based on regulatory terminology specifications (such as optimizing "transmitting device ID" to "transmitting your device identifier to a third party"), while avoiding lengthy expressions to improve user understanding. Organize content in a logical order according to chapters to ensure that the policy text is coherent and conflict-free, meeting regulatory requirements for clause integrity. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a flowchart of a method for automatically generating a privacy policy provided by an embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram of a privacy policy automatic generation system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0021] like Figure 1 As shown, an embodiment of the present invention provides a method for automatically generating a privacy policy, the method comprising the following steps: Step 1: Collect business information of internet applications, including data processing behaviors of the application itself and third-party SDKs, and convert the business information into a standardized privacy policy data input protocol format; Step 2: Based on the privacy policy data input protocol format, match laws, regulations, and normative documents from the preset regulatory knowledge base to generate a structured regulatory rule set; Step 3: Map the structured regulatory rule set to the triangle area formed by the three reference points. Based on the distance between the mapped data points and the center of gravity of the triangle, dynamically assign clause priorities and generate a clause requirement table containing functional-level disclosure clauses and third-party disclosure information. Step 4: Generate a privacy policy intermediate agreement based on the clause requirement table. The privacy policy intermediate agreement includes structured clause content, natural language descriptions, and manual review status marks in chapters. Step 5: Review the terms of the Privacy Policy Intermediate Agreement item by item, accept manual confirmation, modification, or rejection operations, and generate a revised Privacy Policy Intermediate Agreement after review; Step 6: Based on the revised privacy policy intermediate agreement, optimize the language and structure the terms to generate a privacy policy text that meets the formality and readability requirements.

[0022] In an embodiment of the present invention, data processing information (such as data types, operation types, and functional modules) from the application itself and third-party SDKs is collected through automated means such as code scanning and runtime monitoring, preventing manual omission of sensitive data or hidden operations (such as backend permission calls) and improving the integrity of privacy information disclosure. The scope of application of rules is dynamically adjusted based on the data source (such as third-party SDK) and operation type (such as cross-border transmission), improving the relevance of clauses to actual business operations. For example, the "disclosure of third-party provider information" rule is automatically matched for third-party data sharing scenarios. A comprehensive priority is calculated using weighting factors such as data sensitivity and the strength of regulatory constraints to ensure that clauses for high-risk scenarios (such as sensitive data processing and third-party SDK transmission) are generated and reviewed first, improving compliance efficiency (such as prioritizing core clauses involving user privacy). Confidence tags are generated for clauses, and a manual review process is triggered for low-confidence clauses, balancing automation efficiency and accuracy.

[0023] The terms requirement table is structured into chapters according to the privacy policy section template (such as "data collection" and "third-party sharing") to make the content logic clear. Add an initial review status mark (such as "pending review") to the terms, and associate functional modules and data types to facilitate reviewers to quickly locate problematic terms and achieve process traceability. Display the priority, confidence level and review status of the terms through a visual interface, support manual confirmation, modification or rejection operations, and make up for the shortcomings of automated algorithms in complex scenarios (such as regulatory ambiguity and special business needs) (such as manually supplementing special disclosure content for personalized business scenarios). Automatically update the priority and confidence level of rejected terms, triggering a regeneration process until the review is passed, forming a closed loop of "generation-review-correction" to ensure the accuracy and compliance of the final terms.

[0024] In a preferred embodiment of the present invention, the above step 1 collects business information of the Internet application, including data processing behaviors of the application itself and third-party SDKs, and converts the business information into a standardized privacy policy data input protocol format. The privacy policy data input protocol format includes data source, data type, operation type, usage purpose, functional module, third-party provider information, and data transmission destination, and may include: In this embodiment of the present invention, application data includes: analyzing application source code using code scanning tools to identify sensitive data types (e.g., location information, device ID), processing actions (e.g., collection, transmission), and associated functional modules (e.g., user registration, payment). Monitoring application runtime behavior to capture permission calls (e.g., camera, microphone) and local data storage operations. Analyzing server logs to track data transmission paths and destination addresses. The R&D team supplements special scenarios not identified by automated tools (e.g., test environment data processing).

[0025] Third-party SDK data includes: Extract data types, usage purposes, and transfer destinations from the SDK provider's privacy policy document, and require suppliers to actively submit data processing descriptions, including provider information, contact information, and compliance statements, through standardized interfaces.

[0026] Data cleaning and standardization: Standardize data type naming (e.g., standardize "device identification code" to "device_id"); standardize operation type descriptions (e.g., use only pre-defined verbs such as "collect" and "transmit"); filter duplicate records based on the combination of "data type + function module + operation type"; and supplement records missing key information (e.g., records with no intended use) through secondary scanning or manual confirmation.

[0027] Map the collected information to standard protocol fields, such as: The data source corresponds to the "source" field (such as "code_scan" or "third_party_sdk"); Function modules correspond to the "function" field (such as "user_login"); Fill in the "provider_name" and related fields with third-party information.

[0028] Generate standardized protocol documents with clear hierarchies, distinguish between application data and third-party SDK data, and add metadata tags (such as collection time and processing status) to each record.

[0029] In a preferred embodiment of the present invention, the above step 2, based on the privacy policy data input protocol format, matches laws, regulations and normative documents from a preset regulatory knowledge base to generate a structured regulatory rule set, may include: Step 200: Parse the text content of laws, regulations, and normative documents in the regulatory knowledge base, extract functional-level information disclosure requirements, and form structured rule entries containing disclosure content, data type, operation type, and usage purpose; Step 201: Semantically match the functional modules, data types, and usage purposes in the privacy policy data input protocol with the structured rule entries. Based on the correlation between the functional module's operation scenarios and regulatory provisions, a rule set containing the legal basis is generated. Based on the data source and operation type in the privacy policy data input protocol, the corresponding information disclosure requirements in the rule entries are dynamically matched, and the scope of application of the rules is adjusted based on the sensitivity level of the data type. Step 202 : Standardize and verify the field format of the rule set, verify the mapping relationship between the rule logic and the business information in the privacy policy data input protocol, and output an executable structured regulatory rule set.

[0030] In this embodiment of the present invention, the regulatory text is segmented and tagged with parts of speech to identify key entities (such as "personal information" and "sensitive personal information") and action descriptions (such as "explicitly stating the purpose of collection" and "obtaining user consent") in the legal clauses. Named entity recognition (NER) technology is used to extract the data types (such as "biometric information" and "location information"), operation types (such as "sharing" and "cross-border transmission"), and usage purposes (such as "personalized recommendations") in the clauses. The conditional expressions in the clauses are parsed, for example: "If sensitive personal information is collected, the user's written consent must be obtained separately" → converted into rule entries: Trigger conditions: The data type is sensitive personal information and the operation type is collection; Disclosure content: Method of obtaining separate written consent and notification of processing risks; Establish a mapping relationship between rule entries and regulatory clauses, and mark the clause number and effective time.

[0031] Organize the extracted rule entries into a hierarchical structure, for example: First-level classification: by data type (general personal information / sensitive personal information); Secondary classification: by operation type (collection / storage / sharing); Three-level classification: by purpose of use (identity authentication / marketing push); Each rule entry includes: description of disclosure content, triggering conditions, legal basis, and compliance level (such as "must comply" or "recommended compliance").

[0032] Step 201: Semantically match the functional modules (e.g., "User Registration") in the Privacy Policy Data Input Protocol (PPDIP) with the disclosure requirements in the regulatory knowledge base. Distinguish between proprietary data and third-party SDK data. For example, if the data source is a third-party SDK (e.g., Google Analytics), the "Require Disclosure of Third-Party Identity and Data Sharing Scope" rule will be automatically matched. Disclosure requirements will be adjusted based on the operation type. Rule constraints will be gradually strengthened based on the sensitivity level of the data type (e.g., general information → sensitive information → core sensitive information). For example: General information (such as user name): only the purpose of collection needs to be disclosed; Sensitive information (such as location information): Additional explanation of usage scenarios and user exit mechanisms is required; Core sensitive information (such as biometric information): requires separate consent and provides deletion methods.

[0033] When multiple rules apply to the same business scenario, they are processed according to the following priority: Legally mandatory clauses take precedence over recommended clauses; More specific terms take precedence over more general terms (e.g., a "Location Information" term takes precedence over a general "Personal Information" term); The terms with the latest effective date shall take precedence.

[0034] Step 202: Verify the completeness of the rule set fields to ensure that each rule includes trigger conditions, disclosure content, legal basis, and compliance level. Check that fields such as data type and operation type conform to pre-defined enumeration values ​​(e.g., only "collect" and "transmit" are allowed as operation types).

[0035] Check whether the mapping between rules and PPDIP business information is reasonable. For example, if a PPDIP functional module does not involve "cross-border transfer" operations, but the rule set contains cross-border transfer-related clauses, it will be marked as an anomaly and trigger manual review. Rule dependencies are constructed using a graph database to detect circular dependencies or logical contradictions (for example, a clause requiring "no user consent" conflicts with another clause requiring "consent").

[0036] Convert the rules into an executable decision tree structure, add execution priority and risk level labels to each rule, and execute high-risk rules (such as those involving sensitive data) first.

[0037] Through semantic matching and dynamic rule adaptation, the generated privacy policy clauses are ensured to be precisely aligned with regulatory requirements, avoiding compliance risks caused by deviations in manual interpretation. Systematically sort out the functional-level disclosure requirements in regulations, automatically associate business functions with legal clauses, and prevent violations caused by omitting specific scenarios (such as third-party SDK data sharing). Support real-time updates of the regulatory knowledge base. When new regulations come into effect or existing clauses are revised, the rule set can be quickly adjusted to ensure continuous policy compliance. By adjusting the rule priority and sensitivity level, the compliance risks of different business scenarios are quantified, helping companies focus on high-risk areas for key management and control. Each rule entry retains the original legal basis and matching process records, which can quickly prove the compliance path of policy generation during regulatory audits.

[0038] In a preferred embodiment of the present invention, step 3 above maps the structured regulatory rule set to a triangular area formed by three reference points, dynamically assigns clause priorities based on the distance between the mapped data points and the center of gravity of the triangle, and generates a clause requirement table containing functional-level disclosure clauses and third-party disclosure information, which may include: Step 300: Assign a data sensitivity weight and a regulatory constraint strength weight to each clause based on the functional level disclosure requirements in the regulatory rule set. The weights are dynamically adjusted based on historical compliance data and the weight ratio is modified based on the data type sensitivity level in the privacy policy data input protocol. Step 301: Calculate the comprehensive priority score of the clause by combining the weight value with the function module and operation type in the privacy policy data input protocol; Step 302: Based on the comprehensive priority score, conduct a compliance risk analysis on clauses involving third-party SDK data transmission or sensitive data operations, generate a confidence level associated with the comprehensive priority score, and trigger a manual review process for clauses with a confidence level below a preset threshold. Step 303 : Based on the comprehensive priority scores and confidence marks, generate a clause requirement table by sorting the clauses from high to low according to the comprehensive priority scores.

[0039] In the embodiment of the present invention, the base value is set according to the sensitivity of the data type (such as general personal information, sensitive personal information, core sensitive information). For example: General information (such as username) is weighted 10-30 points; Sensitive information (such as location information and medical and health information) is weighted between 40 and 60 points; The weight of core sensitive information (such as biometric information and financial account information) is 70-100 points.

[0040] Analyze regulatory constraints based on their degree of mandatory nature. For example, user consent clauses mandated by law are weighted 90-100 points; recommendations in regulatory documents are weighted 10-50 points. Analyze historical compliance records and calculate the frequency of violations across different data types and regulatory clauses. For example, if a certain type of sensitive data has a high violation rate in recent years, its data sensitivity weight will automatically increase by 20 points. If a regulatory clause has been the focus of multiple audits, its constraint strength weight will increase by 30 points.

[0041] Real-time correction of sensitivity level: Temporarily adjust the weighting ratio based on the real-time sensitivity level of the data type in the Privacy Policy Data Input Protocol (PPDIP). For example, if the PPDIP contains "facial recognition data," the data sensitivity weighting of the corresponding clause will be increased by 50% from the base value (e.g., a base value of 70 points will be adjusted to 105 points, and any points exceeding 100 points will be counted as 100 points).

[0042] Step 301: Cross-weight the data sensitivity weight, regulatory constraint strength weight, and business scenario parameters (functional module, operation type). For example, if the functional module "User Financial Transactions" involves high-risk operations, the corresponding clause's comprehensive priority score will be (data sensitivity weight × 40%) + (regulatory constraint strength weight × 50%) + (operation type risk factor × 10%). The risk factor for the operation type "Cross-border Transfer" is increased by 30 points by default. The comprehensive priority score is adjusted based on the functional module's business impact. For example, the comprehensive priority score of clauses for core functions (such as payment settlement) is automatically increased by 20 points, while the comprehensive priority score of clauses for marginal functions (such as user feedback) is decreased by 10 points by default.

[0043] Step 302, Third-Party SDK Data Transfer: If the terms involve a third-party SDK (such as the AutoNavi Map SDK), a risk premium is automatically triggered. For example, if the terms do not clearly disclose the third-party provider's information, the confidence level will be reduced by 30%. If the terms involve cross-border data transfer to high-risk areas, the confidence level will be directly marked as "low" (<60%).

[0044] For "sharing" and "deleting" sensitive data, a verification step is added to the confidence calculation. For example, sharing sensitive data requires both "user consent" and "security assessment." If either condition is not verified, the confidence level is reduced to below 50%.

[0045] The default threshold is assumed to be 70%: Clauses with a comprehensive priority score of 80 or higher and no risk premium are marked as having a confidence level of 'high' (90%-100%); Clauses with an overall priority score of 60-79 or involving low-risk scenarios are marked with a confidence level of 'medium' (70%-89%); Clauses with an overall priority score less than 60 points or involving high-risk scenarios are marked with a confidence level of 'low' (less than 70%), triggering manual review.

[0046] In step 303, a clause requirement table is generated according to the following rules: comprehensive priority score (from high to low) to ensure that clauses with high risk and high compliance requirements are processed first; confidence level (from high to low) to ensure that clauses with the same comprehensive priority score and high confidence level are processed first. The clause requirement table contains the following core fields: Clause ID: unique identifier (e.g. R-20250527-001); Functional modules: such as "user registration" and "third-party login"; Data type: such as "mobile phone number" and "IMEI"; Legal basis: such as Article × of the ×× Law; Comprehensive priority score; Confidence level: such as "medium (82%)"; Processing status: such as "pending review" and "manual review required".

[0047] Through quantitative analysis of data sensitivity and the strength of regulatory constraints, high-risk clauses (such as cross-border transmission of sensitive data) are prioritized to avoid compliance loopholes. Dynamically adjust weights based on historical compliance data and real-time business information to adapt to scenarios such as the release of new regulations and changes in business functions, and maintain the timeliness of priority allocation. Automatically filter high-confidence clauses to reduce the workload of manual review; only trigger review for low-confidence clauses to focus on high-risk scenarios. Specialized risk analysis for third-party SDKs and sensitive data operations can identify potential compliance gaps (such as undisclosed SDK data sharing) in advance and reduce supply chain compliance risks. Structured clause requirement tables provide clear input for subsequent policy generation and review, ensure the integrity of function-level disclosure and third-party information disclosure, and improve the user readability and regulatory compliance of privacy policies.

[0048] In a preferred embodiment of the present invention, in step 4, a privacy policy intermediate agreement is generated based on the clause requirement table. The privacy policy intermediate agreement includes structured clause content, natural language descriptions, and manual review status marks in each chapter, and may include: Step 400: construct a natural language generation model based on the legal text specifications in the legal knowledge base; Step 401: Convert the functional modules, data types, operation types, and regulatory basis in the clause requirement table into structured clause content in sections according to the privacy policy section template. Use a natural language generation model to semantically optimize the structured clause content and generate user-readable description text. The level of detail in the description is adjusted based on the comprehensive priority score in the clause requirement table. Step 402: Add an initial status mark to each structured clause content and associate it with the corresponding functional module and data type; verify the integrity of the privacy policy intermediate agreement chapters and the standardization of the fields, and output an auditable privacy policy intermediate agreement.

[0049] In this embodiment of the present invention, the normative texts in the legal knowledge base (such as the provisions of the XX Law and the official privacy policy template) are analyzed to extract legal language features: Terminology standards: Identify professional terms (such as "personal information processor" and "minimum necessary principle") and their standard expressions; Sentence structure: Summarize common sentence structures in legal documents (e.g., "Under [scenario], [subject] will [operate] [data type], use it for [purpose], and comply with [legal basis]"); Logical hierarchy: Sort out the logical relationships between clauses (such as the conditional relationship "if...then...", the parallel relationship "including but not limited to...").

[0050] Using natural language processing (NLP) technology, a semantic vector space is constructed to transform legal terminology and sentence structures into feature vectors that the model can understand. Fine-tuning is performed based on pre-trained language models (such as BERT and GPT), which are fed with a corpus of legal text to output natural language descriptions that comply with regulatory standards. Model parameters are optimized for privacy policy scenarios, for example: enhancing the ability to generate semantic information for combinations of "data type + operation type + purpose"; and setting a threshold for formality in generated text (e.g., disabling colloquial expressions).

[0051] Step 401: Match the preset privacy policy section template according to the functional modules in the terms requirement table: Data collection: corresponding to functions such as "user registration" and "location services"; Third-party sharing: corresponds to the terms related to SDK; User rights: corresponding to operations such as "delete data" and "correct information".

[0052] For example, the function module "User Registration" + data type "Mobile Number" → is classified into the "Data Collection" section with the title "Registration Information Collection".

[0053] Fill the template placeholders with the fields (data type, operation type, and regulatory basis) from the terms requirement table to form the basic terms framework. For example: During the [Functional Module] process, [Operation Type] [Data Type] is used for [Purpose] in accordance with [Regulatory Basis]. Use a natural language generation model to polish the basic framework to improve text fluency and compliance. For example: Optimize "Collecting mobile phone number" to "Collecting your mobile phone number to complete identity verification" and add a supplementary note: "We only collect this information with your consent and only for registration purposes." Adjust the description details based on the overall priority score: High-priority clauses (comprehensive priority score ≥ 80 points): Add risk warnings (e.g., "This information is sensitive personal information and we will adopt encrypted storage measures"); Low priority clauses (comprehensive priority score ≤ 40 points): Simplified statement: "We will handle relevant information in accordance with industry practices."

[0054] Step 402: Add a review status tag to each clause, with the initial value being "pending review", and associate the function module and data type. For example: Article ID: PPIP-20250528-001; Status: Pending review; Related information: Function module "User Registration", data type "Mobile Number".

[0055] Check whether the preset chapters cover all business scenarios. If there are unclassified clauses (such as those involving "Data Deletion"), automatically create a "Data Deletion" chapter. Verify the logical order of the chapters (for example, "Data Collection" should come before "Data Use").

[0056] Check that the natural language description includes all required fields, including the data type, operation type, purpose, and regulatory basis. Also check that the third-party terms include the provider's name and contact information. If the terms involve a third-party SDK, the description must include "sharing data with [provider name], whose contact information is [contact_info]." Summarize all sections and terms to generate an indexed intermediate agreement document for the manual review module to access.

[0057] A legal text generation model ensures that clause wording complies with regulatory standards, avoiding compliance risks caused by ambiguous wording (such as accurately using "obtain consent" instead of "obtain permission"). Dynamic mapping of section templates and functional modules ensures that privacy policies cover all data processing activities, including edge cases (such as temporary data caching), to avoid disclosure omissions. Structured clauses and status markers enable reviewers to quickly identify high-priority issues (such as sensitive data clauses). Combined with the ability to adjust details, this reduces the time spent reviewing low-risk content. A natural language generation model automatically optimizes text fluency, and detailed descriptions of high-priority clauses enhance user understanding of key information (such as risk warnings for sensitive data processing). Section templates and generation models can be quickly adjusted to accommodate new business functions or regulatory updates (such as the addition of a "Data Outbound Transfer" section to address new cross-border data transfer regulations), maintaining the agility of policy generation.

[0058] In a preferred embodiment of the present invention, step 5, reviewing each clause of the privacy policy intermediate agreement, accepting manual confirmation, modification, or rejection, and generating a revised privacy policy intermediate agreement after review, may include: Step 500: Display the agreement clauses in a structured manner by chapter through a visual interface, categorize them by review status, and dynamically associate the comprehensive priority scores and confidence marks in the clause requirement table; Step 501: Receive manual confirmation, modification, or rejection of the clause content, update the review status mark based on the manual operation, record the modification content, operator, and timestamp, and generate a revised intermediate agreement; Step 502: For the rejected clauses in the revised intermediate agreement, the comprehensive priority score and confidence mark in the clause requirement table are updated based on the manual modification opinions, triggering the regeneration of the intermediate agreement process until a revised privacy policy intermediate agreement is generated after review and approval.

[0059] In the embodiment of the present invention, a hierarchical tree structure is used to display the intermediate agreement sections of the privacy policy, and each section lists the terms and conditions, which include: Basic information: clause ID, functional module, data type, and regulatory basis; Status label: pending review / confirmed / rejected / under review; Related indicators: comprehensive priority score, confidence mark.

[0060] Filter by review status (such as creating a "pending" view or a "high-risk" view), supporting keyword search and batch selection.

[0061] The interface pulls the comprehensive priority scores and confidence marks from the clause requirement table in real time, highlighting high-risk clauses through color coding: Comprehensive priority score greater than or equal to 80 points: highlighted in red (high priority); Confidence level less than 70%: Yellow exclamation mark (needs attention).

[0062] In step 501, after clicking "Confirm," the clause status changes to "Confirmed," the operator and time (e.g., "Auditor A, 2025-05-28 14:30") are recorded, and the clause content is locked to prevent accidental changes. Text editing and field adjustments (e.g., adding third-party contact information) are supported. A version diff comparison is generated after the changes are made. Select a rejection reason (e.g., "Unclear regulatory basis"), and the clause status changes to "Rejected." Review comments (e.g., "Additional citation of Article X of the XX Law" is required) are automatically attached.

[0063] An audit log is generated for each operation, including: clause ID, operation type, modification content summary; operator account, IP address, operation timestamp; associated historical version number (such as modification from V1.0 to V1.1).

[0064] Based on the results of manual operations, the modified content is automatically merged to generate a new version of the intermediate agreement. For example, if a clause is modified three times and passes the review, the final version will display all historical modification records for review.

[0065] In step 502, when a clause is manually rejected, the relevant weights are automatically adjusted based on the revisions. For example, if the original clause was rejected due to "low data sensitivity weight," the data type sensitivity level is revised from "Normal" to "Sensitive," and the weight is increased by 30%. The comprehensive priority score is recalculated; for example, the original comprehensive priority score of 55 is adjusted to 82 (due to the weight revision). A second compliance risk analysis is conducted on the revised clause. If new regulatory basis is added (e.g., the supplementary Article XX of the XX Law), the confidence level is increased from 60% to 85%, eliminating the manual review threshold. If the requirements are still not met (e.g., the confidence level is less than 70%), the clause remains marked as "Requires Review" until manual approval is obtained. Information on the adjustments to the rejected clause is fed back to the clause requirements table, triggering the regeneration of the intermediate agreement. For example: reject the clause → update the requirements table comprehensive priority score → remap the regulatory rule set → generate a new intermediate agreement version → reenter the review queue. This cycle continues until all clauses have reached "Confirmed" or "Rejected without Modification" (e.g., if a feature is abandoned due to business needs).

[0066] A visual interface centrally displays key information, allowing auditors to quickly identify high-priority, low-confidence clauses and reducing ineffective review time. Color coding and dynamic tagging intuitively highlight high-risk clauses (such as third-party sharing and sensitive data manipulation), preventing compliance vulnerabilities caused by oversight. Standardized action types (confirm / modify / reject) and logging rules ensure consistent standards across different auditors, improving the repeatability and fairness of audit results. Blockchain logs and version difference comparison capabilities accurately trace the responsible parties and reasons for each modification, meeting regulatory requirements for transparency in compliance processes. An automatic revision and regeneration mechanism for rejected clauses creates a closed-loop "review-feedback-optimization" process, ensuring that all clauses ultimately comply with regulatory requirements and business practices, reducing back-and-forth communication costs. The system supports rapid initiation of the review process for new or modified business features (such as new SDKs), dynamically adjusting weights and automatically regenerating clauses to accommodate frequent business iterations. Optimized clauses are more accurate and detailed (for example, by adding third-party contact information), enhancing user trust in privacy policies and reducing user complaints due to ambiguous disclosures.

[0067] In a preferred embodiment of the present invention, step 6 above, based on the revised privacy policy intermediate agreement, optimizes the language and structures the clauses to generate a privacy policy text that meets formality and readability requirements, which may include: Step 600: Based on the language requirements of the target region, extract the legal terms and sentence structure specifications of the corresponding language from the legal knowledge base to build a multilingual translation model; Step 601: Using a multilingual translation model, standardize the terminology and adjust the sentence structure of the natural language description in the revised privacy policy intermediate agreement to generate a formalized description that complies with legal text specifications. Step 602 , based on the target region language configuration, convert the formalized description into the privacy policy chapters in the corresponding language version using a multilingual translation model; Step 603: Verify the logical coherence of the chapters and combine them in order to generate the complete privacy policy. Step 604 : Based on the regulatory knowledge base, a secondary verification is performed on the key fields in the complete privacy policy text, including third-party disclosure information and data operation types, and the final privacy policy text is output.

[0068] In this embodiment of the present invention, localized legal terms are extracted from the regulatory knowledge base for the target region, and a cross-language term mapping table is established to ensure terminology consistency (for example, "sensitive personal information" is uniformly mapped to the English "sensitivepersonaldata"). The sentence structure of the legal text in the target region is analyzed, for example: Chinese: Use the active sentence structure of "Under [scenario], [subject] should [behave] with [purpose]"; English: Follow the legal English standard of "Where [condition], [entity] shall [action] for [purpose]".

[0069] Build a sentence template library containing mandatory sentences (such as "must" and "shall") and permissive sentences (such as "can" and "may"). Use a neural machine translation (NMT) model (such as the Transformer) with bilingual legal text corpus (such as the Chinese-English bilingual version of the "XX Law") to train the model and generate translations that conform to local regulatory conventions. Fine-tune the model for privacy policy scenarios, enhancing translation accuracy for the "data type + operation + regulatory basis" combination.

[0070] Step 601: Scan the Chinese description of the revised intermediate agreement for terminology and replace it with standard terminology in the target language. For complex terms (such as "de-identification"), prioritize using the official translation defined in the regulations or add footnotes. Convert colloquial expressions to formal legal terms. Adjust sentence order to ensure the logical subject is clear.

[0071] Step 602: Translate the privacy policy chapter by chapter (e.g., "Data Collection" and "Third-Party Sharing"), ensuring that the chapter logic is consistent with the original text. For example: "Data Collection" in Chinese → "Data Collection" in English, "Collected de Données" in French. Address the hierarchical relationships between clauses within the chapter (e.g., clauses 1.1 and 1.2), maintaining the same numbering system. Adjust the wording to suit the cultural customs of the target region. For example: The EU version emphasizes "data subject rights" and must detail the rights of access, correction, and deletion. The US version emphasizes "transparency" and requires clear disclosure of data storage periods. Avoid using potentially ambiguous terms (e.g., retain the Chinese word "cookies" in English or translate it into "Cookie technology" with a commentary).

[0072] Step 603: Check whether cross-section references are consistent. For example: The third-party SDKs mentioned in the "Data Collection" section must be described in the "Third-Party Sharing" section; In the English version, the storage period in the "DataRetention" section must be consistent with the storage period in the "DataCollection" section. Verify that the order of clauses aligns with cognitive logic (e.g., "Collect," "Use," and "Share"). Combine the subsections in order to generate a complete document. Standardize formatting (e.g., heading hierarchy, bullet points, and punctuation) to ensure that the PDF / HTML output is aesthetically pleasing and easy to read.

[0073] Step 604: Scan the final translation for third-party disclosure information (e.g., provider name, contact information) to verify consistency with the PPDIP records. Verify that data operation types (e.g., "transmit" and "store") comply with the regulatory constraints of the target region. For sensitive data operation clauses (e.g., biometric information processing), confirm whether additional compliance statements are included (e.g., "separate consent" requirement in the Chinese version, "lawful basis for processing" in the English version). Low-confidence clauses (e.g., confidence level less than 75%) trigger manual review to ensure that the translation does not distort the original meaning.

[0074] Cross-section logical verification avoids content conflicts, ensures policy text consistency, and reduces user questions and regulatory inquiries caused by conflicting wording. Secondary verification of key fields focuses on high-risk scenarios (such as third-party sharing and cross-border transfers). Combined with a manual review mechanism, this minimizes compliance risks caused by translation errors. Standardized multilingual policies demonstrate corporate compliance capabilities. Traceable records from intermediate agreements to final text facilitate proof of compliance and consistency across multiple language versions during regulatory review.

[0075] When applied, code scanning tools (such as SonarQube) are used to scan the application code and extract data types (such as location information and device ID), operation types (such as collection and transmission), and functional modules (such as user registration and personalized recommendations). Instrumentation technology is used to monitor app runtime behavior (such as permission calls and local data storage). Server-side network logs are also analyzed to capture data transmission paths and destination addresses.

[0076] Third-party information acquisition: Parse the privacy policy document of the third-party SDK, extract the SDK name, data processing type (such as device identity transmission), and supplier information (such as contact information and privacy policy link), and allow third-party technology suppliers to actively report data usage descriptions through standard interfaces.

[0077] Manual supplementation: R&D personnel and business personnel submit edge scenario data not covered by the code (such as data processing logic for temporary test functions) through templates.

[0078] Collected data is deduplicated, formatted uniformly (e.g., standardizing "device ID" to device_id), and labeled with sources (e.g., code scanning, third-party SDKs). Structured data is generated according to the **Privacy Policy Data Input Protocol (PPDIP)** format, including fields such as data source, data type, operation type, functional module, and third-party provider information. For example: Source: Code Scan; Data type: location; Operation type: collect; Function module: personalized_recommendation.

[0079] Extract function-level disclosure requirements (such as "collection of sensitive data requires clear purpose") from the regulatory knowledge base, generate a structured rule set (such as "function = personalized recommendation requires disclosure of data type and purpose"), and associate it with the logical basis of regulatory clauses. Assign weights to clauses based on data sensitivity (normal / sensitive / core sensitive) and regulatory constraint strength (mandatory requirements / recommended practices). For example, core sensitive data (such as biometric information) has a higher weight than normal data. Calculate a comprehensive priority score based on functional modules and operation types. Give priority to clauses for high-risk scenarios (such as cross-border transmission of third-party SDKs). Conduct confidence assessments on clauses for complex scenarios (such as cross-border data transmission). Clauses below a threshold (such as 70%) trigger a manual review process. Generate a list of clauses containing function-level disclosure content by priority, clarifying the chapter to which each clause belongs (such as "data collection" or "third-party sharing"), regulatory basis, third-party information, and confidence level. For example: Chapter: Data Collection; Data type: location; Functional module: personalized_recommendation; Legal basis: User consent is required; Confidence level: 0.92.

[0080] Based on the terms and conditions table, a structured intermediate agreement is generated using section templates (e.g., "Data Collection" and "Third-Party Sharing"), including natural language descriptions (e.g., "Collecting location information for personalized recommendations") and review status markers (e.g., pending review). A large model is used to optimize language expression, simplify professional terminology, and ensure user readability. For example: Chapter: Data Collection; Terms description: We collect your location information for personalized recommendation functions. The type of data involved is location information and the purpose is personalization.

[0081] The clauses are displayed through a visual interface and arranged in descending order of confidence. Auditors can confirm, modify or reject the clauses one by one (such as adding third-party contact information). The modification content, operator and time are automatically recorded to generate a revised intermediate agreement; the rejection of a clause triggers the regeneration process until the status of all clauses is "approved". Based on the intermediate agreement that has passed the review, the chapters and clause descriptions are extracted and spliced ​​into a complete text in a logical order. The language expression is optimized using a large model, for example, "transmitting device ID" is optimized to "transmitting your device identifier to a third party", and multi-language adaptation is supported (such as Chinese and English). Compare the text with the regulatory rule set to verify the functional level disclosure completeness (such as whether the instructions for sensitive data operations are omitted) and semantic consistency (such as whether "user consent" accurately reflects regulatory requirements), generate a verification report, mark high-risk clauses, and output the final version after passing, for example: Verification results: Functional-level disclosure is complete, third-party information is accurate, and meets compliance requirements.

[0082] Distinguish between development versions (drafts), pre-release versions (pending review), and released versions (officially launched), record version metadata (such as version number, generation time, and change description), encrypt and store version data, and support retrieval by time or type, for example: Version number: v1.0.1; Generated time: 2025-04-15T12:00:00Z; Change description: Added location information collection terms.

[0083] Automatically compare the current version with historical versions, highlighting newly added, modified, or deleted clauses (such as "New Third-Party SDK Sharing Clauses") and providing text highlighting or structured difference reports. Users can select any two versions through the web interface to view detailed changes at the chapter or clause level, facilitating internal audits and regulatory reviews. Automated processes are implemented at each stage through standardized protocols (PPDIP / PPIP) and large-scale modeling technology. Manual review is introduced at key nodes (such as low-confidence clauses and complex business scenarios), forming a closed-loop process of "data collection → regulatory matching → clause generation → manual verification → text release → version management," ensuring the efficiency, compliance, and transparency of privacy policy generation.

[0084] like Figure 2 As shown, an embodiment of the present invention further provides a privacy policy automatic generation system, including: The business information collection module is used to collect business information of Internet applications, including the data processing behavior of the application itself and third-party SDKs, and convert the business information into a standardized privacy policy data input protocol format; The regulatory rules mapping module is used to match laws, regulations, and normative documents from a pre-set regulatory knowledge base based on the privacy policy data input protocol format to generate a structured regulatory rules set; A priority allocation module is used to map a structured regulatory rule set to a triangular area formed by three reference points. Based on the distance between the mapped data points and the center of gravity of the triangle, it dynamically assigns clause priorities and generates a clause requirement table containing functional-level disclosure clauses and third-party disclosure information. An intermediate agreement module is used to generate a privacy policy intermediate agreement based on the terms requirement table. The privacy policy intermediate agreement includes structured terms content, natural language descriptions, and manual review status marks in different chapters. The manual review module is used to review the terms of the privacy policy intermediate agreement item by item, accept manual confirmation, modification or rejection operations, and generate a revised version of the privacy policy intermediate agreement after approval; The text optimization module is used to optimize the language and structure the clause content based on the revised privacy policy intermediate agreement, and generate a privacy policy text that meets the formality and readability requirements.

[0085] It should be noted that this system is a system corresponding to the above method, and all implementation methods in the above method embodiment are applicable to this embodiment and can achieve the same technical effects.

[0086] An embodiment of the present invention further provides a computing device comprising: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the above-described method. All implementations in the above-described method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0087] The embodiment of the present invention further provides a computer-readable storage medium storing instructions, which, when executed on a computer, causes the computer to execute the above-described method. All implementations in the above-described method embodiment are applicable to this embodiment and can achieve the same technical effects.

[0088] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A method for automatically generating a privacy policy, characterized in that: The method comprises: Step 1: Collect business information of internet applications, including data processing behaviors of the application itself and third-party SDKs, and convert the business information into a standardized privacy policy data input protocol format; Step 2: Based on the privacy policy data input protocol format, match laws, regulations, and normative documents from the preset regulatory knowledge base to generate a structured regulatory rule set; Step 3: Map the structured regulatory rule set to the triangle area formed by the three reference points. Based on the distance between the mapped data points and the center of gravity of the triangle, dynamically assign clause priorities and generate a clause requirement table containing functional-level disclosure clauses and third-party disclosure information. Step 4: Generate a privacy policy intermediate agreement based on the clause requirement table. The privacy policy intermediate agreement includes structured clause content, natural language descriptions, and manual review status marks in chapters. Step 5: Review the terms of the Privacy Policy Intermediate Agreement item by item, accept manual confirmation, modification, or rejection operations, and generate a revised Privacy Policy Intermediate Agreement after review; Step 6: Based on the revised privacy policy intermediate agreement, optimize the language and structure the terms to generate a privacy policy text that meets the formality and readability requirements.

2. The method for automatically generating a privacy policy according to claim 1, characterized in that: The privacy policy data input protocol format includes data source, data type, operation type, purpose of use, functional module, third-party provider information and data transmission destination.

3. The method for automatically generating a privacy policy according to claim 2, characterized in that: Based on the privacy policy data input protocol format, the system matches laws, regulations, and normative documents from the pre-set regulatory knowledge base to generate a structured regulatory rule set, including: Parse the text content of laws, regulations and normative documents in the regulatory knowledge base, extract functional-level information disclosure requirements, and form structured rule entries that include disclosure content, data type, operation type and usage purpose; Semantically match the functional modules, data types, and usage purposes in the privacy policy data input protocol with the structured rule entries. Based on the correlation between the functional module's operating scenarios and regulatory provisions, a rule set containing the legal basis is generated. Based on the data source and operation type in the privacy policy data input protocol, the corresponding information disclosure requirements in the rule entries are dynamically matched, and the scope of application of the rules is adjusted based on the sensitivity level of the data type. Standardize and verify the field format of the rule set, verify the mapping relationship between the rule logic and the business information in the privacy policy data input protocol, and output an executable structured regulatory rule set.

4. The method for automatically generating a privacy policy according to claim 3, characterized in that: Map the structured regulatory rule set to a triangle formed by three reference points. Based on the distance between the mapped data point and the triangle's centroid, dynamically assign clause priorities and generate a clause requirement table containing functional-level disclosure clauses and third-party disclosure information, including: Based on the functional-level disclosure requirements in the regulatory rule set, each clause is assigned a data sensitivity weight value and a regulatory constraint strength weight value. The weight value is dynamically adjusted based on historical compliance data and the weight ratio is modified based on the data type sensitivity level in the privacy policy data input agreement; The weight value is weighted and integrated with the functional modules and operation types in the privacy policy data input protocol to calculate the comprehensive priority score of the clause; Based on the comprehensive priority score, compliance risk analysis is conducted on clauses involving third-party SDK data transmission or sensitive data operations. Confidence tags associated with the comprehensive priority score are generated. Clauses with confidence levels below the preset threshold trigger a manual review process. Based on the comprehensive priority score and confidence mark, a clause requirement table is generated by sorting the comprehensive priority score from high to low.

5. The method for automatically generating a privacy policy according to claim 4, characterized in that: Based on the clause requirement table, a privacy policy intermediate agreement is generated. The privacy policy intermediate agreement contains structured clause content, natural language descriptions, and manual review status marks by chapter, including: Build a natural language generation model based on the legal text specifications in the regulatory knowledge base; Convert the functional modules, data types, operation types, and regulatory basis in the terms and conditions table into structured terms and conditions according to the privacy policy section template. Use a natural language generation model to semantically optimize the structured terms and conditions, generate user-readable descriptions, and adjust the level of detail based on the overall priority score in the terms and conditions table. Add an initial status mark to each structured clause content and associate it with the corresponding functional module and data type; verify the integrity of the privacy policy intermediate agreement chapters and the standardization of the fields, and output an auditable privacy policy intermediate agreement.

6. The method for automatically generating a privacy policy according to claim 5, characterized in that: Review the terms of the privacy policy intermediary agreement item by item, accept manual confirmation, modification or rejection operations, and generate a revised privacy policy intermediary agreement after review, including: A visual interface displays the agreement terms in a structured manner by chapter, categorizes them by review status, and dynamically associates them with the comprehensive priority scores and confidence levels in the terms requirements table. Receive manual confirmation, modification, or rejection of the terms and conditions, update the review status based on the manual operation, record the modification content, operator, and timestamp, and generate a revised intermediate agreement; For the rejected clauses in the revised intermediary agreement, the comprehensive priority score and confidence mark in the clause requirement table are updated based on the manual modification opinions, triggering the regeneration of the intermediary agreement process until a revised privacy policy intermediary agreement is generated after review and approval.

7. The method for automatically generating a privacy policy according to claim 6, characterized in that: Based on the revised privacy policy intermediate agreement, the terms and conditions were optimized and structured to generate a privacy policy text that meets formality and readability requirements, including: Based on the language requirements of the target region, we extract legal terms and sentence structure specifications of the corresponding language from the regulatory knowledge base and build a multilingual translation model; Use a multilingual translation model to standardize terminology and adjust sentence structure in the natural language descriptions in the revised privacy policy intermediate agreement to generate a formalized description that complies with legal text specifications. Based on the target region's language configuration, the formalized description is converted into the corresponding language version of the privacy policy chapters through a multilingual translation model; Verify the logical coherence of each chapter and splice them together in order to generate the complete privacy policy text; Based on the regulatory knowledge base, the key fields in the full text of the privacy policy, including third-party disclosure information and data operation types, are secondary verified to output the final privacy policy text.

8. A privacy policy automatic generation system, which implements the method according to any one of claims 1 to 7, characterized in that: include: The business information collection module is used to collect business information of Internet applications, including the data processing behavior of the application itself and third-party SDKs, and convert the business information into a standardized privacy policy data input protocol format; The regulatory rules mapping module is used to match laws, regulations, and normative documents from a pre-set regulatory knowledge base based on the privacy policy data input protocol format to generate a structured regulatory rules set; A priority allocation module is used to map a structured regulatory rule set to a triangular area formed by three reference points. Based on the distance between the mapped data points and the center of gravity of the triangle, it dynamically assigns clause priorities and generates a clause requirement table containing functional-level disclosure clauses and third-party disclosure information. An intermediate agreement module is used to generate a privacy policy intermediate agreement based on the terms requirement table. The privacy policy intermediate agreement includes structured terms content, natural language descriptions, and manual review status marks in different chapters. The manual review module is used to review the terms of the privacy policy intermediate agreement item by item, accept manual confirmation, modification or rejection operations, and generate a revised version of the privacy policy intermediate agreement after approval; The text optimization module is used to optimize the language and structure the clause content based on the revised privacy policy intermediate agreement, and generate a privacy policy text that meets the formality and readability requirements.

9. A computing device, characterized in that include: one or more processors; A storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program, which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images