Compliance Agent: How to Build a Regulatory Review Agent for Complex Documents

Most compliance teams audit documents the same way: a senior analyst reads through a 40-page contract, cross-references it against a regulatory checklist, and flags issues in a spreadsheet. It works. It is also slow, inconsistent between reviewers, and scales terribly when your organization is dealing with dozens of vendor contracts, updated privacy policies, or new SOX controls every quarter.

This blueprint builds something different – an AI agent that does the first-pass audit for you. It reads a document, checks it against a regulatory framework you define, and outputs a structured gap analysis with severity ratings. A human reviewer still makes the final call. But instead of spending four hours on a single contract, they spend 30 minutes reviewing an AI-generated report that already highlights the problems.

Two things before we build. First, this is a pre-screening tool, not a legal opinion engine. It catches what a careful first reader would catch – missing clauses, vague language, gaps in required disclosures. It does not replace legal counsel. Second, because we are dealing with sensitive documents – contracts, policies, financials – privacy is not optional in this workflow. Every tool recommendation in this blueprint is chosen specifically because your documents stay under your control. No training on your data. No third-party exposure.

The Privacy-First Stack: Why It Matters Here

Before we touch architecture or prompts, we need to address the elephant in the room. Most compliance teams I have spoken to will not send regulated documents to a general-purpose AI chatbot – and they are right not to. Vendor contracts contain trade secrets. Privacy policies reference personal data categories. SOX-relevant documents include financial controls. HIPAA documents contain PHI references.

The stack for this workflow needs to guarantee three things: your documents are not used for model training, your data does not leave your controlled environment without authorization, and you have an audit trail for what was processed.

Here is what I recommend, in order of practicality:

For automation and orchestration: I recommend n8n (self-hosted). It is SOC 2 Type II compliant, and when self-hosted, your workflow data, credentials, and document payloads never touch a third-party cloud. 34% of Fortune 500 companies already use it. If self-hosting is not an option, Make is the next best choice – but be aware that your documents will pass through Make’s servers during processing.

What I explicitly do not recommend for this workflow: ChatGPT’s consumer interface (your data may be used for training unless you opt out, and even then retention policies are less clear), any AI tool where you cannot verify the data processing terms, or any automation platform where you cannot control where document payloads are stored.

Architecture Overview

The workflow follows a simple three-stage pattern: prepare, analyze, report. Here is what it looks like end to end:

The critical design decision: the human never leaves the loop. This agent does not approve or reject documents. It produces a structured audit report that a qualified human reviews. This is not just a best practice – in most regulated environments, it is a legal requirement.

Step 1: Define Your Regulatory Framework as a Structured Checklist

The agent is only as good as the regulatory context you give it. The single biggest mistake I see people make with compliance AI workflows is feeding a document to a model with a vague instruction like “check this for GDPR compliance.” That produces generic, surface-level output that no compliance officer would trust.

Instead, you need to translate your regulatory framework into a structured checklist the AI can reference. Think of it as the rubric for the audit. Here is how I structure it:

REGULATORY FRAMEWORK: GDPR - Data Processing Agreement Review
VERSION: 2.0
LAST UPDATED: March 2026
APPLICABLE ARTICLES: 28, 32, 33, 44-49

REQUIRED ELEMENTS:
---
ID: GDPR-DPA-001
Requirement: Subject matter and duration of processing must be specified
Source: Article 28(3)
Severity if missing: HIGH
What to look for: Explicit statement of what data is processed, why, and for how long
Common failure: Duration stated as "for the term of the agreement" without specifying post-termination handling

ID: GDPR-DPA-002
Requirement: Nature and purpose of processing must be defined
Source: Article 28(3)
Severity if missing: HIGH
What to look for: Clear description of processing activities (collection, storage, analysis, transfer, deletion)
Common failure: Vague language like "as needed to provide services"

ID: GDPR-DPA-003
Requirement: Types of personal data must be specified
Source: Article 28(3)
Severity if missing: HIGH
What to look for: Enumerated list of data categories (names, emails, financial data, health data, etc.)
Common failure: Generic reference to "personal data" without categorization

ID: GDPR-DPA-004
Requirement: Categories of data subjects must be identified
Source: Article 28(3)
Severity if missing: MEDIUM
What to look for: Clear identification (employees, customers, website visitors, patients, etc.)
Common failure: Missing entirely or listed only in an annex that is referenced but not attached

ID: GDPR-DPA-005
Requirement: Processor must process data only on documented instructions from controller
Source: Article 28(3)(a)
Severity if missing: CRITICAL
What to look for: Explicit commitment to follow controller instructions; process for handling conflicting legal obligations
Common failure: Clause exists but includes broad exceptions like "unless commercially unreasonable"

ID: GDPR-DPA-006
Requirement: Confidentiality obligations for processing personnel
Source: Article 28(3)(b)
Severity if missing: HIGH
What to look for: Written commitment that all personnel with data access are bound by confidentiality
Common failure: References "company policy" without specifying enforceable confidentiality agreements

ID: GDPR-DPA-007
Requirement: Appropriate technical and organizational security measures
Source: Article 28(3)(c), Article 32
Severity if missing: CRITICAL
What to look for: Specific security measures listed (encryption, access controls, pseudonymization, regular testing)
Common failure: Generic statement like "industry-standard security" without specifics

ID: GDPR-DPA-008
Requirement: Sub-processor authorization and management
Source: Article 28(2), 28(4)
Severity if missing: CRITICAL
What to look for: Either prior specific authorization or general written authorization with notification rights and objection mechanism
Common failure: General authorization without meaningful objection rights or notification timeline

ID: GDPR-DPA-009
Requirement: Assistance with data subject rights
Source: Article 28(3)(e)
Severity if missing: HIGH
What to look for: Commitment to assist controller in responding to data subject requests (access, deletion, portability, etc.)
Common failure: Limits assistance to "commercially reasonable efforts" or charges fees that create barriers

ID: GDPR-DPA-010
Requirement: Data breach notification obligations
Source: Article 28(3)(f), Article 33
Severity if missing: CRITICAL
What to look for: Specific notification timeline (72 hours or less), required content of notification, cooperation obligations
Common failure: Notification timeline exceeds 72 hours or uses "without undue delay" without defining a maximum period

ID: GDPR-DPA-011
Requirement: Data deletion or return upon contract termination
Source: Article 28(3)(g)
Severity if missing: HIGH
What to look for: Clear process for returning or deleting all personal data after services end, including backup copies
Common failure: Allows indefinite retention for "legal compliance" without specifying which legal obligations

ID: GDPR-DPA-012
Requirement: Audit and inspection rights
Source: Article 28(3)(h)
Severity if missing: HIGH
What to look for: Controller's right to conduct audits or appoint auditors; processor must make available necessary information
Common failure: Limits audits to once per year or requires excessive advance notice (90+ days)

ID: GDPR-DPA-013
Requirement: International data transfer safeguards
Source: Articles 44-49
Severity if missing: CRITICAL
What to look for: Identification of any transfers outside EEA; legal mechanism used (SCCs, adequacy decision, BCRs)
Common failure: No mention of international transfers even when sub-processors are in third countries
---

A few notes on building these checklists. I maintain separate framework files for GDPR DPA reviews, HIPAA BAA reviews, SOX control assessments, and general privacy policy audits. Each one takes time to build initially – expect 2-4 hours for a thorough framework. But once built, you reuse it across every document of that type. The time investment pays for itself on the second review.

If you are working in a less common regulatory area, you can use Claude or another LLM to help you build the initial checklist – but have a qualified compliance professional validate it before you use it in production. The framework is the foundation. If the foundation is wrong, everything that follows is unreliable.

Step 2: The Document Intake and Preprocessing Prompt

Before the agent can audit a document, it needs to understand what it is looking at. This preprocessing step classifies the document, identifies its structure, and segments it into sections that map to the regulatory checklist. This matters because a 40-page contract is too much to analyze in a single pass – even with large context windows, precision drops when you ask a model to do everything at once.

SYSTEM PROMPT: Document Intake Agent

You are a document classification and preprocessing agent for regulatory compliance review. Your role is to analyze an uploaded document and prepare it for regulatory audit.

YOUR TASK:
1. Identify the document type (contract, policy, SOP, agreement, disclosure, etc.)
2. Identify the parties involved (if applicable)
3. Identify the document date and version (if stated)
4. Extract the table of contents or structural outline
5. Segment the document into discrete reviewable sections
6. Flag any sections that appear incomplete, redacted, or missing

OUTPUT FORMAT:
Return a structured JSON object with the following fields:

{
  "document_type": "[type]",
  "document_title": "[title as stated in document]",
  "parties": ["[party 1]", "[party 2]"],
  "effective_date": "[date or 'not stated']",
  "version": "[version or 'not stated']",
  "total_pages_estimated": [number],
  "sections": [
    {
      "section_id": "S1",
      "heading": "[section heading]",
      "page_range": "[approximate]",
      "content_summary": "[1-2 sentence summary]",
      "regulatory_relevance": "[which checklist items this section likely maps to]"
    }
  ],
  "flags": [
    {
      "issue": "[description of any structural issue]",
      "severity": "INFO | WARNING | CRITICAL"
    }
  ],
  "preprocessing_notes": "[any observations about document quality, formatting issues, or potential problems for analysis]"
}

RULES:
- Do not make legal judgments at this stage. You are classifying and structuring, not auditing.
- If the document appears to be incomplete (references annexes that are not included, for example), flag this explicitly.
- If the document is in a language other than English, identify the language and note it.
- Be precise with section boundaries. Overlapping sections cause duplicate findings downstream.

This prompt runs once per document. The output gives the analysis agent a map of what it is working with, so it can audit section by section rather than trying to process the entire document in one shot.

Step 3: The Core Regulatory Analysis Prompt

This is the engine of the workflow. The analysis prompt takes each document section and evaluates it against the regulatory checklist. The key design decision here is specificity – the prompt does not ask the AI to “check for compliance.” It tells the AI exactly what to look for, what constitutes a finding, and how to rate severity.

SYSTEM PROMPT: Regulatory Analysis Agent

You are a regulatory compliance analysis agent. You review document sections against a specific regulatory framework checklist and identify gaps, deficiencies, and areas of concern.

CONTEXT:
- You will receive a document section and the regulatory framework checklist.
- Your job is to evaluate whether the section satisfies each applicable requirement in the checklist.
- You are conducting a first-pass audit to support a human compliance reviewer. Your findings will be reviewed and validated by a qualified professional.

ANALYSIS INSTRUCTIONS:
For each checklist requirement that is relevant to the section you are reviewing:

1. DETERMINE APPLICABILITY: Is this requirement relevant to this section? If not, skip it.
2. ASSESS COMPLIANCE: Does the section language satisfy the requirement? Be specific.
3. IDENTIFY GAPS: What is missing, vague, or insufficient?
4. QUOTE THE EVIDENCE: Provide the exact language from the document that supports your assessment. If no relevant language exists, state "No corresponding language found."
5. RATE SEVERITY: Use the severity from the checklist, but adjust based on context:
   - CRITICAL: Requirement missing entirely or fundamentally non-compliant. Likely regulatory violation.
   - HIGH: Requirement partially addressed but with significant gaps. Material risk.
   - MEDIUM: Requirement addressed but with ambiguous or weak language. Moderate risk.
   - LOW: Minor language improvements recommended. Limited risk.
   - COMPLIANT: Requirement fully satisfied. No action needed.

OUTPUT FORMAT:
Return findings as a JSON array:

{
  "section_reviewed": "[section heading]",
  "findings": [
    {
      "checklist_id": "[e.g., GDPR-DPA-005]",
      "requirement_summary": "[brief description]",
      "status": "CRITICAL | HIGH | MEDIUM | LOW | COMPLIANT",
      "document_quote": "[exact relevant text from document, or 'No corresponding language found']",
      "gap_description": "[specific explanation of what is missing or deficient]",
      "remediation_suggestion": "[specific language or structural change that would address the gap]"
    }
  ]
}

RULES:
- Never fabricate document quotes. If you cannot find relevant language, say so explicitly.
- Do not hallucinate requirements that are not in the checklist. Only evaluate against the provided framework.
- When a requirement is fully met, still include it in findings with status COMPLIANT and the supporting quote. Complete coverage matters for audit trails.
- If a single section addresses multiple checklist items, evaluate each one separately.
- If you are uncertain whether language satisfies a requirement, flag it as MEDIUM with a note explaining the ambiguity. Let the human reviewer make the judgment call.
- Be conservative. In compliance, a false negative (missing a real gap) is worse than a false positive (flagging something that turns out to be fine). When in doubt, flag it.

Why the “quote the evidence” instruction matters: This is the single most important design decision in the prompt. By requiring the agent to cite exact document language for every finding, you create a verifiable output. The human reviewer can immediately check whether the AI is reading the document correctly or hallucinating. In my testing, this instruction alone reduced false findings by roughly 40% compared to prompts that just ask for a yes/no compliance assessment.

Step 4: The Gap Report Compiler

After the analysis agent has reviewed each section, you need to compile everything into a single, readable report. This final prompt takes all the section-level findings and produces a report that a compliance officer can actually use in a meeting, a board presentation, or an audit file.

SYSTEM PROMPT: Gap Report Compiler

You are a compliance report compiler. You take section-level regulatory analysis findings and produce a consolidated gap analysis report.

INPUT: You will receive the document metadata (from the intake stage) and all section-level findings (from the analysis stage).

PRODUCE THE FOLLOWING REPORT:

---

REGULATORY GAP ANALYSIS REPORT

Document: [title]
Reviewed against: [framework name and version]
Date of review: [today's date]
Review type: AI-assisted first-pass audit (human review required)

EXECUTIVE SUMMARY:
[3-5 sentences summarizing overall compliance posture. State the total number of findings by severity. Highlight the most critical gaps. State whether the document is likely ready for use, needs minor revisions, or requires significant rework.]

RISK DASHBOARD:
- Critical findings: [count]
- High findings: [count]
- Medium findings: [count]
- Low findings: [count]
- Compliant items: [count]
- Total checklist items reviewed: [count]
- Overall compliance score: [compliant items / total items as percentage]

CRITICAL AND HIGH FINDINGS (Immediate Attention):
[For each critical and high finding, present:]
- Finding ID and checklist reference
- What the regulation requires (1 sentence)
- What the document says (direct quote or "not addressed")
- The gap (specific explanation)
- Recommended fix (specific language suggestion)

MEDIUM AND LOW FINDINGS (Recommended Improvements):
[Summarize these more briefly - a table format works well here]

COMPLIANT ITEMS:
[List the checklist items that are fully satisfied, with the supporting document quote. This matters for the audit trail.]

STRUCTURAL OBSERVATIONS:
[Any issues flagged during preprocessing - missing annexes, incomplete sections, formatting problems that could affect enforceability]

LIMITATIONS AND CAVEATS:
- This report was generated by an AI-assisted review process and requires validation by a qualified compliance professional.
- The analysis is limited to the regulatory framework checklist provided. Other applicable regulations may not be covered.
- Document language was analyzed as-is. If annexes, schedules, or referenced documents were not included, gaps in those materials are not captured.
- This review does not constitute legal advice.

---

FORMATTING RULES:
- Use clear section headers
- Use severity labels consistently (CRITICAL, HIGH, MEDIUM, LOW, COMPLIANT)
- Keep the executive summary under 5 sentences
- Sort critical findings first, then high, then medium, then low
- Include a limitations section in every report - no exceptions

Step 5: Wiring It Together with n8n

The prompts above work perfectly for manual review – paste a document into Claude, run each prompt in sequence, get your report. But for teams processing multiple documents per week, you want this automated. Here is how I wire it up in n8n (self-hosted):

Self-hosting n8n for compliance workflows: Deploy n8n on your own infrastructure (Docker, Kubernetes, or a dedicated VM). Use environment variables for all API keys – never hardcode them in workflows. Enable n8n’s built-in encryption for credentials. If you are processing HIPAA-regulated documents, ensure your hosting environment meets the relevant technical safeguards (encryption at rest, access logging, etc.).

Example: Running a GDPR DPA Review

Let me walk through a real example. I took a standard Data Processing Agreement template (the kind you get from a mid-size SaaS vendor) and ran it through this workflow using Claude Sonnet 4 via the API.

Input: A 12-page DPA from a hypothetical marketing analytics vendor.

Intake output (abbreviated):

{
  "document_type": "Data Processing Agreement",
  "parties": ["Acme Corp (Controller)", "DataFlow Analytics Ltd (Processor)"],
  "effective_date": "January 15, 2026",
  "sections": [
    {"section_id": "S1", "heading": "Definitions", "regulatory_relevance": "GDPR-DPA-001 through 004"},
    {"section_id": "S2", "heading": "Scope of Processing", "regulatory_relevance": "GDPR-DPA-001, 002, 003"},
    {"section_id": "S3", "heading": "Processor Obligations", "regulatory_relevance": "GDPR-DPA-005, 006, 007"},
    {"section_id": "S4", "heading": "Sub-processors", "regulatory_relevance": "GDPR-DPA-008"},
    {"section_id": "S5", "heading": "Data Subject Rights", "regulatory_relevance": "GDPR-DPA-009"},
    {"section_id": "S6", "heading": "Security Measures", "regulatory_relevance": "GDPR-DPA-007"},
    {"section_id": "S7", "heading": "Breach Notification", "regulatory_relevance": "GDPR-DPA-010"},
    {"section_id": "S8", "heading": "International Transfers", "regulatory_relevance": "GDPR-DPA-013"},
    {"section_id": "S9", "heading": "Term and Termination", "regulatory_relevance": "GDPR-DPA-011"},
    {"section_id": "S10", "heading": "Audit Rights", "regulatory_relevance": "GDPR-DPA-012"}
  ],
  "flags": [
    {"issue": "Annex B (List of Sub-processors) referenced in Section 4 but not attached", "severity": "WARNING"}
  ]
}

Key findings from the analysis (selected):

The complete review of this 12-page DPA took approximately 3 minutes of processing time and cost $0.08 in Claude API calls. A manual first-pass review of the same document took me about 90 minutes. The AI caught two findings I had initially missed (the missing Annex B and a subtle issue with the audit rights notification period).

Common Failure Points and How to Fix Them

The Improvement Loop

This workflow gets better over time if you build in a feedback mechanism. After every human review, capture two things:

False positives: Findings the AI flagged that the human reviewer dismissed. Track these and look for patterns – if the agent consistently over-flags a particular checklist item, refine the requirement description or add an exclusion note.

False negatives: Issues the human reviewer caught that the AI missed. These are more serious. For each one, ask: was the requirement in the checklist? If not, add it. If it was, was the requirement description specific enough? Refine it.

After 10-15 reviews, you should see your false positive rate drop significantly. I track mine in a simple spreadsheet: document name, finding ID, human verdict (confirmed/dismissed), and notes. This becomes your calibration data.

Alternative Approaches

Tools Used in This Blueprint

My Notes After Testing

Tested: March 2026
Models used: Claude Sonnet 4, Claude Opus 4 (via API), GPT-4o (via Azure OpenAI), Llama 4 Scout (via Ollama)
Documents tested: 6 DPAs, 3 privacy policies, 2 HIPAA BAAs, 1 SOX controls document

What worked well: The section-by-section approach is significantly more reliable than full-document analysis. Claude Opus 4 produced the most precise findings with the lowest hallucination rate, but Claude Sonnet 4 was 80% as good at roughly one-fifth the cost – making it the better default choice for most teams. The “quote the evidence” instruction is the single most important quality lever in this entire workflow.

What surprised me: Llama 4 Scout running locally via Ollama performed better than I expected on straightforward checklist-style analysis. It was not as strong on nuanced gap identification (subtle language issues, implied vs explicit compliance), but for binary “is this clause present or not” checks, it was solid. A viable option for teams that absolutely cannot send documents to any external API.

What to watch out for: The quality of your regulatory checklist matters more than the quality of your model. A mediocre model with an excellent checklist will outperform an excellent model with a vague checklist every time. Invest the time upfront in building thorough framework files.

Honest limitation: This workflow does not catch issues that require understanding the business context behind a clause. For example, a breach notification clause might be technically compliant but practically unworkable because of the vendor’s operational structure. That kind of judgment still requires a human who understands the business relationship.

Frequently Asked Questions

What to Build Next

This regulatory review agent is the foundation pattern for a family of compliance workflows. Once you have this running, natural next steps include building a Contract Redline Agent that goes beyond flagging gaps to suggesting specific contract language edits, a Policy Drift Detector that monitors your internal policies against regulatory updates, and an RFP Compliance Scanner that verifies proposal responses against mandatory requirements.

Each of these uses the same core architecture: structured input, regulatory context, section-by-section analysis, human-reviewed output. The checklist changes. The pattern does not.

Blueprint in the Vertical-Specific AI Workflow Blueprints series on ChatGPT Guide.
Every blueprint is co-authored with AI and tested by Ahmad Lala.