Method and System for Automatically Parsing Unstructured Policy Documents and Dynamically Generating Compliance Profiles for AI Agent Execution Environments

Abstract

When policy documents held by the organization (laws, policies of higher-level organizations, internal security policies, standards, etc.) are uploaded, a document classifier identifies types and domains, and a rule extraction pipeline normalizes them into Intermediate Rule Representations (IRR). Subsequently, a Rule Compiler automatically generates Policy Objects for each PEP stage (Ingress / Retrieval / Tool / Egress). A conflict resolution module deterministically resolves conflicts between multiple documents based on priority hierarchy and assembles them into a single Compliance Profile (JSON), while a Dynamic Binding Module immediately applies this to the running AI agent's PEP pipeline through atomic switching based on request boundaries.

Description

Technology Field

[0001] The present invention relates to compliance management of an AI agent execution environment, and specifically, to a method and system in which policy documents (laws, policies of higher-level organizations, internal security policies, standards, etc.) held by an organization are parsed by a rule extraction pipeline to generate an Intermediate Rule Representation (IRR), a Rule Compiler converts this into a Policy Object for each PEP stage, a conflict resolution module generates a single Compliance Profile, and a Dynamic Binding Module atomically applies it to the PEP pipeline of an AI agent currently in execution. Background Technology

[0002] As AI agent services are rapidly adopted in regulated industries such as finance, healthcare, public sector, and manufacturing, organizations are facing the need to incorporate their own policy documents into AI systems. However, conventional AI governance systems have the following structural problems.

[0003] Problem 1) Dependence on manual policy coding: OPA (Rego) and XACML require professional developers to write rules directly as the policy language. There is a structural constraint that prevents the direct use of natural language policy documents as input.

[0004] Problem 2) Delay in policy updates: Since policy codes must be rewritten and redistributed upon amendment of laws, immediate compliance implementation is structurally impossible.

[0005] Problem 3) Non-standardization of policies by organization: Since the format, language, and structure of policy documents vary from organization to organization, it is difficult to extract rules of consistent quality using a single parser.

[0006] Problem 4) Unresolved conflicts between multiple policy documents: The existing system cannot automatically resolve conflicts between GDPR and internal data usage policies in a deterministic manner, and administrators must handle them manually.

[0007] Problem 5) Separation from AI agent pipeline stages: The existing policy engine is not directly integrated with control points specialized for the AI ​​agent's Ingress / Retrieval / Tool / Egress execution stages. Prior art literature

[0009] US Patent (US 10341410): Security tokens for a multi-tenant identity and data security management cloud service The problem to be solved

[0010] The present invention aims to provide a method and system that parses policy documents to generate an IRR, a Rule Compiler automatically generates a Policy Object for each PEP stage, a Conflict Resolution Module deterministically assembles a single Compliance Profile, and a Dynamic Binding Module immediately applies it to an executing PEP pipeline through atomic switching of the request boundary. means of solving the problem

[0011] The present invention comprises: a document classification module that receives policy documents (laws, policies of higher-level agencies, internal policies, standards), classifies document types and domains, and selects extraction strategies by type; a rule extraction pipeline that generates an intermediate representation (IRR) from the classified documents that includes subject, action, object, condition, and source clause identifiers and records an applicable PEP stage candidate (inferred_stage); a Stage Assignment Engine that analyzes the subject, action, object, and condition fields of the IRR according to priority rules to determine the applicable PEP stage among Ingress, Retrieval, Tool, and Egress; a Rule Compiler that compiles the IRR into an executable Policy Object containing CEL condition expressions, judgments, and priorities; a conflict resolution module that detects conflicts between multiple Policy Objects and resolves them deterministically according to a predetermined priority hierarchy; and a Compliance Profile generator that assembles the conflict-resolved Policy Objects into a single Compliance Profile together with original clause trace information (Policy Lineage). The present invention provides a system for dynamic generation of a Compliance Profile and binding of an AI agent execution environment, comprising a dynamic binding module that binds the Compliance Profile to the AI ​​agent's PEP pipeline using request boundary-based atomic pointer replacement (CAS).

[0012] In addition, the present invention provides a method for automatically generating a Compliance Profile based on policy documents, comprising the steps of: receiving policy documents (laws, higher-level agency policies, internal policies, standards), classifying document types and domains, and selecting a type-specific extraction strategy; generating an IRR from the classified documents that includes subject, action, object, condition, source clause identifiers, and PEP stage candidates (inferred_stage); a Stage Assignment step that analyzes the IRR fields according to priority rules to determine the applicable PEP stage; compiling the IRR into a Policy Object that includes CEL condition expressions, judgments, and priorities; detecting conflicts between Policy Objects and resolving them deterministically according to a priority hierarchy; assembling and sealing the conflict-resolved Policy Objects into a Compliance Profile together with Policy Lineage metadata; and binding the Compliance Profile to the PEP pipeline using an atomic pointer replacement (CAS) at the time of receiving a new request.

[0013] In addition, the present invention comprises a rule normalization module that normalizes a policy rule extracted from a policy document into an intermediate representation (IRR) including six required fields—subject, action, object, condition, source_clause_id, and effect—and system-generated fields—inferred_stage and irr_valid, and immediately transmits it to a HITL queue by setting irr_valid=false if any of the six required fields are missing or blank; The present invention provides an IRR-based automatic PEP stage assignment system comprising a Stage Assignment Engine that determines the corresponding PEP stage by processing the subject, action, and object fields of the above IRR according to a 6-stage decision tree of SA-1 (verify irr_valid) → SA-2 (calculate candidates in order of priority for Ingress, Retrieval, Tool, and Egress) → SA-3 (branch single / multiple) → SA-4 (check action identity among multiple candidates) → SA-5 (set hitl_required=true and send to HITL queue if actions conflict) → SA-6 (final record of inferred_stage), wherein in SA-4, if the actions of multiple stage candidates are identical, the inferred_stage is set to "multi", and in SA-5, if the actions conflict, hitl_required=true is set and sent to the HITL queue. Effects of the invention

[0014] Based on the structure described above, the present invention enables the effect of automatically generating Policy Objects at each PEP stage (Ingress / Retrieval / Tool / Egress) when policy documents (laws, policies of higher-level organizations, internal security policies, standards, etc.) held by an organization are uploaded, a document classifier identifies the type and domain, a rule extraction pipeline normalizes them into an Intermediate Rule Representation (IRR), and then a Rule Compiler automatically generates Policy Objects. Brief explanation of the drawing

[0015] FIG. 1 is an overall system block diagram of the present invention, and FIG. 2 is a flowchart of the entire processing S100~S800 according to the present invention, and FIG. 3 is a document classification decision tree and extraction strategy selection according to the present invention, and Figure 4 is a transformation diagram of IRR → Stage Assignment → Policy Object in the present invention, and FIG. 5 is a collision resolution algorithm (CR-1 ~ CR-5) of the present invention, and FIG. 6 is the Compliance Profile data structure and Policy Lineage of the present invention, and Figure 7 is the Hot-reload binding sequence (HR-1 to HR-4) of the present invention. Specific details for implementing the invention

[0016] The objects, specific advantages, and novel features of the present invention will become more apparent from the following detailed description and preferred embodiments in conjunction with the accompanying drawings. Additionally, the terms used are defined with respect to their functions in the present invention, which may vary according to the user's intent or practice. Therefore, the definitions of these terms should be based on the content throughout this specification.

[0017] In addition, when describing the components of the present invention, different reference numerals may be assigned to components with the same name depending on the drawing, and the same reference numeral may be assigned even if they are different drawings. However, even in such cases, this does not mean that the components have different functions depending on the embodiment, or that they have the same function in different embodiments, and the function of each component should be determined based on the description of each component in the corresponding embodiment.

[0018] Figure 1 is an overall system block diagram of the present invention, showing the data flow and external interface (HITL queue, binding registry, Patent① connection) between 6 modules + Stage Assignment Engine.

[0019] FIG. 2 is a flowchart of the entire processing flow from S100 to S800 according to the present invention, and is a stage from document upload to pre-PEP pipeline binding (including Stage Assignment S350, HITL branch, and escalation).

[0020] FIG. 3 is a document classification decision tree and extraction strategy selection according to the present invention, and

[0021] Type (Laws / Regulations / Internal Policies / Standards) × Domain (Security / Privacy / Finance / Medical) Classification · Shows the Classification - First Architecture.

[0022] Figure 4 is a diagram of the IRR → Stage Assignment → Policy Object transformation in the present invention, and is the result of the IRR 10 fields (6 required, 2 optional, 2 system output) → RC-1 to RC-5 → Policy Object PEP stage placement.

[0023] Figure 5 shows the collision resolution algorithm (CR-1 to CR-5) of the present invention, which is a priority hierarchy-based deterministic resolution, DFS circular collision detection, loss lineage preservation, and escalation path.

[0024] Figure 6 shows the Compliance Profile data structure and Policy Lineage of the present invention, and is a JSON structure · source_clauses[] multiple sources · conflict_resolution_log · Evidence Package connection key (policy_id).

[0025] Figure 7 is the Hot-reload binding sequence (HR-1 to HR-4) of the present invention, HR-1 Pending registration · HR-2 CAS atomic pointer replacement (request boundary basis) · HR-3 rollback · HR-4 audit log.

[0027] Hereinafter, the components and operation method of the present invention will be described.

[0028] [Components of the present invention]

[0029] Component 1: Document Ingestion & Classifier Module

[0030] 1) Technical role of Component 1

[0031] It receives uploaded policy documents and automatically classifies document types (laws, higher-level agency policies, internal policies, standards, contracts) and domains (security, personal information, finance, medical, general business). The classification results are used to select type-specific optimized extraction strategies in the subsequent rule extraction step.

[0032] 2) The functions performed by Component 1 are as follows.

[0033] ① Document format detection and text extraction (PDF, DOCX, HWP, TXT) / ② Type Classifier: Automatic identification of document types such as laws, regulations, internal policies, standards, and contracts / ③ Domain Classifier: Automatic identification of security, personal information, finance, medical, and general business domains / ④ Structure and deliver classification results as metadata (document_type, domain, language, confidence_score)

[0034] 3) Characteristics of Component 1

[0035] A Classification-First Architecture that dynamically selects an optimized extraction strategy based on type and domain combinations, rather than a single parser. This ensures consistent IRR generation quality for policy documents with different languages ​​and formats.

[0037] Component 2: Rule Extraction Pipeline

[0038] 1) Technical role of Component 2

[0039] Rule Seeds are extracted from classified documents and normalized into Intermediate Rule Representations (IRRs). The IRR is an intermediate representation layer unique to this invention, serving as a language and format-independent standard structure between natural language rules and executable Policy Objects.

[0040] 2) An example of the IRR field structure (distinguishing between mandatory and optional) is as follows.

[0041]

[0042] 3) The processing rules for IRR generation verification are as follows.

[0043]

[0045] Component 2 - Attachment: Stage Assignment Engine (PEP Stage Automatic Assignment Engine)

[0046] 1) Component 2 - Technical Role of the Attachment

[0047] It analyzes the subject, action, object, and condition fields of the IRR generated by the rule extraction pipeline to automatically determine the PEP stage (Ingress / Retrieval / Tool / Egress) to which the corresponding rule will be applied and records it in the inferred_stage field.

[0048] 2) The PEP phase placement criteria (priority rules) are as follows.

[0049]

[0050]

[0051] 3) The order of processing for Stage Assignment decisions (SA-1~SA-6) is as follows.

[0052]

[0054] 4) Characteristics of this component

[0055] By implementing PEP stage placement conditions using a rule-based decision tree (IRR keyword-pattern matching), natural language rules are automatically placed in the appropriate stage among Ingress, Retrieval, Tool, and Egress without administrator intervention. This is fundamentally different from the method used in existing policy engines (OPA and XACML) where humans manually specify stages.

[0057] Component 3: Rule Compiler

[0058] 1) Technical role of Component 3

[0059] The AI ​​Guardrails PEP pipeline compiles the IRR into an executable Policy Object. The Rule Compiler is not a simple format converter, but an execution policy generator that creates condition expressions, determines actions, assigns priorities, and verifies executable feasibility.

[0060] 2) The internal processing procedure of the Rule Compiler is as follows.

[0061]

[0062]

[0064] 3) The output structure of the Policy Object is as follows.

[0065] { policy_id, stage: "ingress|retrieval|tool|egress", priority: int, condition_expression: CEL, action: "allow|warn|block|error", source_irr_id, source_clause_id, paragraph_offset, compiled_at, hitl_flagged: bool}

[0066] 4) The feature of this component is a three-stage transformation system (RC-1 / RC-2 / RC-3) that automatically compiles condition_expression into CEL (Cloud Expression Language), deterministically calculates action from natural language intensity expressions, and automatically assigns priority from the document type hierarchy, and this is the core technical means.

[0068] Component 4: Conflict Resolution Module

[0069] 1) Technical role of Component 4

[0070] It automatically detects logical conflicts between Policy Objects compiled from multiple policy documents and resolves them using a deterministic priority algorithm to generate a single set of Policy Objects.

[0071] 2) The collision resolution deterministic algorithm is as follows.

[0072]

[0073] 3) The core of component 4 is a CR-1 to CR-5 5-step algorithm that incorporates a fixed priority hierarchy of statutes > superior organizations > internal policies > service-specific settings, and resolves conflicts within the same hierarchy deterministically in the order of clauses (section numbers), and this is the differentiating means of the present invention.

[0075] Component 5: Compliance Profile Generator

[0076] 1) Technical role of Component 5

[0077] The conflict-resolved Policy Objects are assembled into a single Compliance Profile (JSON), and the final Compliance Profile is generated by adding Policy Lineage trace metadata and a SHA-256 hash seal.

[0078] 2) The Policy Lineage tracing structure is as follows.

[0079] Each Policy Object can be traced one-to-one with the source document via its source_clause_id and paragraph_offset. If a single Policy Object is derived from multiple clauses: the multiple origins are recorded as an array of source_clauses[{ clause_id, paragraph_offset, doc_id}]. History is preserved in the conflict_resolution_log both before and after conflict resolution. Linkage key with the Evidence Package: policy_id — use the same value as the applied_policy_id field of the Evidence Package.

[0080] 3) The Compliance Profile data structure is as follows.

[0081] { profile_id, tenant_id, source_documents[{ doc_id, doc_type, domain, version}], policies[{ policy_id, stage, priority, condition_expression, action, source_clauses[{ clause_id, paragraph_offset, doc_id}]}], conflict_resolution_log, created_at, version, profile_hash(SHA-256), digital_signature}

[0082] 4) The core of this component is that the Policy Lineage tracing structure at the clause_id·paragraph_offset level is the key component that distinguishes this invention from a simple policy repository. It can automatically present the legal basis clauses of each policy rule during regulatory audits.

[0084] Component 6: Dynamic Binding Module

[0085] 1) Technical role of Component 6

[0086] Atomically binds the generated Compliance Profile to the AI ​​Guardrails PEP pipeline. Immediately applies the new Profile via request boundary-based Compare-And-Swap (CAS) switching without service restart.

[0087] 2) Hot-reload version switching control is as shown in [Table 6] below.

[0088]

[0089] 3) The core of Component 6 is that the mechanism (HR-1 to HR-4) which prohibits profile switching during request processing and performs atomic pointer replacement via CAS operations at the time of receiving a new request structurally prevents the occurrence of an inconsistent state during policy changes.

[0091] [Operation method of the present invention]

[0092] The overall operation method of the present invention is as shown in [Table 7] below.

[0093]

[0095] The policy update scenario (Hot-reload flow) according to the present invention is as follows.

[0096] - Administrator uploads new / revised policy documents → Re-execute S100~S600 pipeline → New Compliance Profile (pending) is created

[0097] - Dynamic Binding Module (HR-1): Registers a new profile in the binding registry in a pending state.

[0098] - When a new request is received (HR-2): Perform CAS atomic_swap (active ↔ pending) — No service restart

[0099] - Previous requests finalized with the old version Profile / New Profile applied starting from new requests ― No discrepancies

[0100] - Record all update events (HR-4) in the audit log: from_profile_id, to_profile_id, swap_latency_ms

[0102] Embodiments of the present invention include a computer-readable medium comprising program instructions for performing operations implemented by various computers. This medium records a program for executing the method described above. This medium may include program instructions, data files, data structures, etc., either alone or in combination. Examples of such media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CDs and DVDs; floptical disks and magneto-optical media; and hardware devices configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

[0103] Although preferred embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements by those skilled in the art using the basic concept of the present invention as defined in the following claims also fall within the scope of the present invention.

Claims

Claim 1 A system comprising one or more processors and memory connected to said processors, wherein the system includes: a document classification module implemented by said processors, which receives policy documents (laws, higher-level agency policies, internal policies, standards), classifies document types and domains, and selects extraction strategies by type; a rule extraction pipeline that generates an intermediate representation (IRR) from classified documents containing subject, action, object, condition, and source clause identifiers and recording an applicable PEP stage candidate (inferred_stage), wherein said IRR includes six required fields of subject, action, object, condition, source_clause_id, and effect, and if any of said six required fields are missing or blank, sets irr_valid to false and transmits to a HITL (Human-in-the-Loop) queue; and a Stage Assignment Engine that analyzes the subject, action, object, and condition fields of said IRR according to priority rules to determine the applicable PEP stage among Ingress, Retrieval, Tool, and Egress. A Rule Compiler that compiles the above IRR into an executable Policy Object containing CEL condition expressions, judgments, and priorities; a conflict resolution module that detects conflicts between multiple Policy Objects and resolves them deterministically according to a predetermined priority hierarchy; and a Compliance Profile Generator that assembles the conflict-resolved Policy Objects into a single Compliance Profile together with original clause trace information (Policy Lineage).A system for dynamic generation of Compliance Profile and binding to an AI agent execution environment, comprising: a dynamic binding module that defines the Compliance Profile as the request completion point when the Egress PEP’s Evidence Package sealing is completed, and thereafter, when a new request is received, performs a single pointer replacement using a CAS(active_profile_id, old_value, pending_profile_id) operation to bind the Compliance Profile to the AI ​​agent’s PEP pipeline, wherein in the event of a pointer replacement failure, performs an exponential backoff retry up to three times, releases the swap_lock and notifies the administrator, and traverses the same CAS path even during a rollback. Claim 2 A system for dynamic generation of a Compliance Profile and binding of an AI agent execution environment according to claim 1, wherein the Rule Compiler sequentially performs an RC-1 step (failure type: TERM_MAPPING_FAILURE·INCOMPLETE_STRUCTURE·AMBIGUOUS_SCOPE·PARTIAL_COMPILE) that compiles the condition field of an IRR into a CEL expression, an RC-2 step that determines allow·warn·block·error in a natural language strength expression and selects a more restrictive action when multiple criteria apply simultaneously, and an RC-3 step that automatically assigns priority using a document type hierarchy and a two-step tie-breaker for section number and paragraph offset. Claim 3 A system for dynamic generation of Compliance Profile and binding of an AI agent execution environment according to claim 1, characterized in that, upon RC-4 verification failure of the Rule Compiler, MISSING_FIELD·INVALID_STAGE·SCHEMA_VIOLATION discards the Policy Object and transmits it to the HITL queue, and INVALID_EXPRESSION temporarily stores the Policy Object in a quarantine pool and allows recompilation after administrator modification. Claim 4 A system for dynamic generation of Compliance Profile and binding of AI agent execution environment according to claim 1, wherein the collision resolution module excludes the loser Policy Object from the Compliance Profile after collision resolution and preserves it as loser_policy_id in the conflict_resolution_log, converts the Policy Objects into a directed graph to detect cyclic collisions (A>B>C>A) and performs DFS cycle detection, and switches to HITL if the CEL equivalence incomparable collision fails after attempting to resolve the priority rule part. Claim 5 A system for dynamic generation of Compliance Profile and binding of an AI agent execution environment according to claim 1, wherein the Compliance Profile generator records a Policy Lineage including source_clause_id and paragraph_offset for each Policy Object, and if a single Policy Object is derived from multiple clauses, records multiple sources in a source_clauses[] array and records the source_clause_id of the conflict resolution loser in the superseded_policies[] field of the winner. Claim 6 delete Claim 7 A system for dynamic generation of a Compliance Profile and binding of an AI agent execution environment according to claim 1, characterized in that the source_clause_id and paragraph_offset included in each Policy Object of the Compliance Profile can be traced back to a specific clause of the original policy document through the applied_policy_id in the Evidence Package of the PEP to which the Policy Object was applied, and the connection key between the Policy Lineage and the Evidence Package is unified and managed as a policy_id. Claim 8 A method for automatically generating a Compliance Profile based on policy documents performed by a system comprising one or more processors, wherein the processor receives policy documents (laws, higher-level agency policies, internal policies, standards), classifies document types and domains, and selects an extraction strategy for each type; generates an IRR from the classified documents that includes six required fields (subject, action, object, condition, source_clause_id, and effect) and a candidate for the applicable PEP stage (inferred_stage), wherein if any of the six required fields are missing or blank, irr_valid is set to false and transmitted to a HITL queue; a Stage Assignment step in which the subject, action, object, and condition fields of the IRR are analyzed according to priority rules to determine the applicable PEP stage; a step of compiling the IRR into an executable Policy Object containing CEL condition expressions, judgments, and priorities; a step of detecting conflicts between Policy Objects and resolving them deterministically according to a priority hierarchy; and a step of assembling the conflict-resolved Policy Objects into a Compliance Profile together with Policy Lineage metadata and sealing them. A method for automatically generating a policy document-based Compliance Profile, comprising the steps of: defining the Compliance Profile as the request completion point when the Egress PEP’s Evidence Package sealing is completed, and thereafter, when a new request is received, performing a single pointer replacement using a CAS(active_profile_id, old_value, pending_profile_id) operation to bind it to the PEP pipeline, wherein in the event of a pointer replacement failure, performing a swap_lock release and administrator notification after retrying exponential backoff up to 3 times, and traversing the same CAS path even during rollback. Claim 9 A system comprising one or more processors and memory connected to said processors, wherein a rule normalization module is implemented by said processors and normalizes a policy rule extracted from a policy document into an intermediate representation (IRR) including six required fields—subject, action, object, condition, source_clause_id, and effect—and system-generated fields—inferred_stage and irr_valid, and immediately transmits to a HITL queue by setting irr_valid=false if any of the six required fields are missing or blank; An IRR-based automatic PEP stage assignment system comprising: a Stage Assignment Engine that determines the corresponding PEP stage by processing the subject, action, and object fields of the above IRR according to a 6-stage decision tree of SA-1 (verify irr_valid) → SA-2 (calculate candidates in order of priority for Ingress, Retrieval, Tool, and Egress) → SA-3 (branch single / multiple) → SA-4 (check action identity among multiple candidates) → SA-5 (set hitl_required=true and send to HITL queue if actions conflict) → SA-6 (final record of inferred_stage), wherein in SA-4, if the actions of multiple stage candidates are identical, the inferred_stage is set to "i", and in SA-5, if the actions conflict, hitl_required=true is set and sent to the HITL queue.

Images