Building a Compliance Review Assistant with Multi-Agent AI on AWS 🛡️

A multi-agent AI system on AWS that automates compliance reviews—scoring risk, detecting policy violations, recommending AWS-native remediations, and producing executive-ready reports

sweta jha

Published Jun 24, 2026

Last modified Jun 24, 2026

Building a Compliance Review Assistant with Multi-Agent AI on AWS 🛡️

By Sweta Jha | Senior Data Scientist & AWS Community Builder (AI/ML)

Tags: #AWSCommunityBuilders #AmazonBedrock #StrandsSDK #AgentCore #GenAI #MultiAgent #Compliance #HIPAA #GDPR

Introduction

Every enterprise — whether in healthcare, banking, or insurance — lives under the shadow of regulatory compliance. Teams spend thousands of hours manually reviewing policy documents, checking for HIPAA violations, GDPR gaps, AML deficiencies, and SOC2 failures. A single oversight can mean million-dollar fines.

What if a team of specialised AI agents could do the heavy lifting in seconds?

In this post, I'll walk you through how I built a Compliance Review Assistant — a fully agentic, multi-agent AI system on AWS that takes a document and a compliance domain, and returns a structured risk assessment, violation report, remediation plan, and executive summary. All automated. All grounded in real regulatory frameworks.

This system uses:

Amazon Bedrock (Nova Pro) for LLM inference
Strands Agents SDK for agent orchestration
AgentCore Runtime for serverless deployment
Amazon S3 for report storage
FastAPI as the REST layer

Why Multi-Agent for Compliance?

A single LLM prompt is too blunt an instrument for compliance review. Here's the problem: compliance is multidimensional. You need to:

Assess risk — How severe is the exposure?
Check specific rules — Which exact clauses are violated?
Recommend remediation — What do you do about it?
Communicate findings — How do you explain this to a CXO?

Each of these tasks requires different reasoning depth, different system instructions, and different output formats. A multi-agent system lets each agent specialise, and the orchestrator coordinate — exactly how a real compliance team operates.

System Architecture

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
User / API Request
        │
        ▼
┌─────────────────────────────────────┐
│         Orchestrator Agent          │
│   (Strands SDK + Amazon Nova Pro)   │
│  Routes → Coordinates → Aggregates  │
└────────┬────────────────────────────┘
         │
    ┌────┴───────────────────────────────────┐
    │                                        │
    ▼                                        ▼
┌──────────────────┐              ┌─────────────────────┐
│  Risk Classifier │              │   Policy Checker    │
│      Agent       │              │       Agent         │
│ Scores LOW→CRIT  │              │  HIPAA/GDPR/AML/    │
│ Detects PII/PHI  │              │  SOC2 rule engine   │
└──────────────────┘              └──────────┬──────────┘
                                             │
                                  ┌──────────▼──────────┐
                                  │   Remediation Agent │
                                  │  AWS-native fixes   │
                                  │  Priority + effort  │
                                  └──────────┬──────────┘
                                             │
                                  ┌──────────▼──────────┐
                                  │  Report Writer Agent│
                                  │  Executive summary  │
                                  │  Compliance status  │
                                  └─────────────────────┘
         │
    ┌────┴────────────────────┐
    │     Memory Store        │  ← Review history, risk trends
    │     Amazon S3           │  ← Persistent report storage
    └─────────────────────────┘

Each agent is a discrete Strands Agent instance with its own system prompt, tool, and reasoning scope. The Orchestrator Agent calls them in sequence and assembles the final report.

The Agents — Deep Dive

1. 🔍 Risk Classifier Agent

The first agent to receive the document. It analyses the raw text and assigns a risk level: LOW, MEDIUM, HIGH, or CRITICAL, along with a numeric risk score (0–100) and detected sensitive entity types (PII, PHI, PCI, etc.).

System prompt design principle: Temperature = 0.0. Risk classification must be deterministic and reproducible.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
RISK_SYSTEM_PROMPT = """You are a Risk Classification Agent specialised in regulatory compliance.

Given a document and a compliance domain, classify the overall risk level as one of:
  - LOW      : Minor issues, no sensitive data exposure
  - MEDIUM   : Some policy gaps, limited exposure
  - HIGH     : Significant gaps, potential for data/financial harm
  - CRITICAL : Severe violations, immediate regulatory action likely

Respond ONLY with a JSON object in this exact format (no markdown, no preamble):
{
  "risk_level": "HIGH",
  "risk_score": 78,
  "risk_factors": ["factor1", "factor2"],
  "sensitive_entities_detected": ["PII", "PHI"],
  "summary": "One-sentence summary."
}"""

Key design decision: We use temperature=0.0 for risk and policy agents to ensure consistent, reproducible outputs. The Remediation and Report Writer agents use slightly higher temperatures (0.2–0.3) to produce more natural, varied language.

2. 📋 Policy Checker Agent

The Policy Checker is the heart of the system. It maintains a built-in rule database for four compliance domains and checks each rule against the document.

Supported domains and sample rules:

Domain	Sample Rules
HIPAA	PHI encrypted at rest/transit; Role-based access; 6-year audit log retention
GDPR	Lawful basis documented; 72-hour breach notification; DPO appointment
AML	CDD for all customers; SAR filing timelines; 5-year record retention
SOC2	Annual security policy review; Change management; Incident response testing

1
2
3
4
5
6
7
8
9
10
POLICY_RULES = {
    "HIPAA": [
        "PHI must be encrypted at rest and in transit",
        "Access controls must be role-based and documented",
        "Audit logs for all PHI access must be maintained for 6 years",
        "Business Associate Agreements must be in place for third parties",
        "Minimum necessary standard must be applied to PHI disclosures",
    ],
    # ... GDPR, AML, SOC2
}

Each violation comes with a severity (LOW/MEDIUM/HIGH/CRITICAL), a violation_detail grounded in the document text, and a clause_reference pointing to the exact regulation (e.g., 45 CFR § 164.312(a)(2)(iv)).

3. 🔧 Remediation Agent

Once violations are identified, the Remediation Agent generates an AWS-native remediation plan. It assigns each violation a priority (IMMEDIATE, SHORT_TERM, MEDIUM_TERM, LONG_TERM), an effort level, specific action steps, and the AWS services that address the gap.

1
2
3
4
5
6
7
8
9
10
11
12
13
# Example output for "PHI stored unencrypted"
{
  "violation_rule": "PHI must be encrypted at rest and in transit",
  "priority": "IMMEDIATE",
  "effort": "HIGH",
  "steps": [
    "Enable S3 Server-Side Encryption with AWS KMS",
    "Enforce TLS 1.2+ on all API endpoints handling PHI",
    "Migrate USB data to encrypted S3 buckets immediately"
  ],
  "aws_services": ["AWS KMS", "Amazon S3 SSE", "AWS Certificate Manager"],
  "estimated_days": 14
}

The agent also returns quick_wins — zero-cost, low-effort actions that can be taken immediately (like enabling MFA or revoking shared credentials).

4. 📝 Report Writer Agent

The final agent synthesises everything into a professional compliance report with:

Executive Summary (2–3 sentences for non-technical stakeholders)
Key Findings (bulleted)
Compliance Status (COMPLIANT, PARTIALLY_COMPLIANT, NON_COMPLIANT)
Narrative (3–4 paragraphs suitable for a Chief Compliance Officer)
Next Review Date

This is where temperature=0.3 pays off — the narrative reads professionally rather than robotically.

5. 🎯 Orchestrator Agent

The Orchestrator is a Strands Agent with a single tool: orchestrate_compliance_review. This tool calls each specialist agent in sequence, passing outputs forward as context.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
@tool
def orchestrate_compliance_review(document_text: str, document_id: str, domain: str) -> str:
    # Step 1 — Risk Classification
    risk_result = classify_risk(document_text=document_text, domain=domain)

    # Step 2 — Policy Check (risk level informs depth)
    policy_result = check_policy(
        document_text=document_text,
        domain=domain,
        risk_level=risk_data.get("risk_level"),
    )

    # Step 3 — Remediation (only if violations exist)
    if policy_data.get("violations"):
        remediation_result = suggest_remediation(
            violations=json.dumps(policy_data["violations"]),
            domain=domain,
        )

    # Step 4 — Write Report
    report_result = write_report(...)

    # Step 5 — Persist to memory
    memory_store.save_review(document_id=document_id, report=report_data)

    # Step 6 — Upload to S3
    s3_uri = upload_report_to_s3(document_id=document_id, report=report_data)

    return json.dumps(report_data)

Conditional branching: The Remediation Agent is skipped entirely if there are no violations. This saves tokens and latency for clean documents.

Memory: Tracking Compliance Over Time

One of the most powerful features of this system is its memory layer. Every review is saved to a ComplianceMemoryStore, which tracks:

Risk level over time
Compliance score trajectory
Number of violations per review

The store computes a risk trend — IMPROVING, STABLE, or DEGRADING — by comparing compliance scores across sequential reviews. This lets compliance officers track whether their remediation efforts are actually working.

1
2
3
4
5
6
def get_risk_trend(self, document_id: str) -> str:
    scores = [h.get("compliance_score") for h in history]
    delta = scores[-1] - scores[-2]
    if delta > 5: return "IMPROVING"
    elif delta < -5: return "DEGRADING"
    return "STABLE"

FastAPI Layer

The system is exposed via three REST endpoints:

Method	Endpoint	Description
`GET`	`/health`	Health check
`POST`	`/review`	Run full compliance review
`GET`	`/history/{document_id}`	View review history + trend
`GET`	`/domains`	List supported domains + rules

1
2
3
4
5
6
7
8
# Example: Review a document for HIPAA compliance
curl -X POST http://localhost:8000/review \
  -H "Content-Type: application/json" \
  -d '{
    "document_text": "Our hospital stores patient records...",
    "domain": "HIPAA",
    "document_id": "hospital-policy-v2"
  }'

AgentCore Runtime Deployment

For production, the orchestrator wraps into a Lambda-compatible handler for Amazon Bedrock AgentCore Runtime deployment:

1
2
3
4
5
6
7
8
9
10
11
def handler(event: dict, context=None) -> dict:
    document_text = event.get("document_text", "")
    document_id = event.get("document_id", "auto")
    domain = event.get("domain", "SOC2")

    report = run_compliance_review(
        document_text=document_text,
        document_id=document_id,
        domain=domain,
    )
    return {"statusCode": 200, "body": json.dumps(report)}

AgentCore handles auto-scaling, IAM permissions, and Bedrock model routing automatically — no infrastructure management needed.

Testing Strategy

The test suite covers four layers:

Unit tests per agent — Mocks the Bedrock model, tests JSON parsing and fallback logic
Policy rule coverage — Verifies all four domains have rules defined
Memory store tests — Save/retrieve cycles and trend calculation
API endpoint tests — Health check, domain listing via FastAPI TestClient

1
2
3
4
5
6
7
8
9
pytest tests/ -v

# Expected output:
# PASSED tests/test_compliance_agents.py::TestRiskClassifierAgent::test_classify_risk_returns_valid_json
# PASSED tests/test_compliance_agents.py::TestPolicyCheckerAgent::test_check_policy_returns_violations
# PASSED tests/test_compliance_agents.py::TestRemediationAgent::test_suggest_remediation_returns_steps
# PASSED tests/test_compliance_agents.py::TestReportWriterAgent::test_write_report_produces_full_report
# PASSED tests/test_compliance_agents.py::TestMemoryStore::test_save_and_retrieve
# PASSED tests/test_compliance_agents.py::TestAPIEndpoints::test_health_check

Sample Output

Here's what the system returns for a document with HIPAA violations:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
  "document_id": "hospital-policy-v1",
  "domain": "HIPAA",
  "reviewed_at": "2025-06-15T10:30:00Z",
  "risk_level": "HIGH",
  "risk_score": 82,
  "sensitive_entities": ["PHI", "PII"],
  "violations_count": 3,
  "compliance_score": 40,
  "compliance_status": "NON_COMPLIANT",
  "executive_summary": "This document reveals critical HIPAA non-compliance in three areas: data encryption, access control, and third-party agreements. Immediate action is required to avoid regulatory penalties.",
  "violations": [
    {
      "rule": "PHI must be encrypted at rest and in transit",
      "violation_detail": "Patient data stored on unencrypted USB drives and shared via email",
      "severity": "CRITICAL",
      "clause_reference": "45 CFR § 164.312(a)(2)(iv)"
    }
  ],
  "quick_wins": [
    "Enable MFA on all staff accounts today",
    "Revoke shared credentials immediately"
  ],
  "total_remediation_days": 45,
  "s3_uri": "s3://compliance-reports-dev/reports/hospital-policy-v1/compliance_report.json"
}

Key Design Patterns

✅ Structured JSON-only outputs

Every agent is instructed to return only valid JSON with no markdown fencing. Each agent also has a fallback parser that catches malformed responses and returns a safe default structure. This makes the pipeline robust even when the LLM adds unexpected commentary.

✅ Temperature tuning per agent role

0.0 for Risk Classifier and Policy Checker — determinism matters for legal defensibility
0.2 for Remediation — slightly creative for generating varied fix suggestions
0.3 for Report Writer — natural, professional prose

✅ Conditional orchestration

The Remediation Agent is only invoked when violations exist. This is a simple but effective token- and cost-saving pattern.

✅ Domain-specific rule injection

Rather than relying entirely on the LLM's knowledge of HIPAA or GDPR, we inject the exact policy rules into the prompt at runtime. This grounds the output in real regulatory text and makes it auditable.

AWS Services Used

Service	Role
Amazon Bedrock (Nova Pro)	LLM inference for all 5 agents
Strands Agents SDK	Agent construction and tool binding
AgentCore Runtime	Serverless agent deployment
Amazon S3	Compliance report persistent storage
AWS KMS	Referenced in remediation for encryption
AWS Certificate Manager	Referenced in remediation for TLS
AWS IAM	Access control for Bedrock and S3

What's Next

This system is extensible in several directions I'm actively exploring:

Document ingestion via S3 trigger — upload a PDF, trigger a Lambda, get a compliance report automatically
Multi-LOB pipeline — run the same document through HIPAA and GDPR simultaneously using parallel agent invocations
Slack/Teams integration — push critical violations to a compliance channel in real time
OpenSearch indexing — store all violations in a searchable knowledge base for trend analysis across the document corpus
Human-in-the-loop approval — add a HumanApprovalTool step before the report is finalised, consistent with my HR Onboarding Assistant pattern

Conclusion

Building a multi-agent compliance system reinforced for me why the agent-per-concern architecture works so well for enterprise use cases. Each agent is independently testable, independently improvable, and independently replaceable. If the GDPR ruleset changes, you update the Policy Checker Agent's rule dictionary — the rest of the pipeline is untouched.

The Strands SDK made this surprisingly ergonomic. The @tool decorator pattern is clean, the BedrockModel abstraction handles all the AWS credential plumbing, and AgentCore Runtime means I'm not managing Lambda layers or container registries.

Healthcare, banking, insurance — the use case adapts by swapping the domain. The architecture stays the same.

Resources

# agentic-ai # aws-builders # aws-community-builders # amazon-bedrock-agentcore # strands-agents

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Building a Compliance Review Assistant with Multi-Agent AI on AWS 🛡️

sweta jha

Building a Compliance Review Assistant with Multi-Agent AI on AWS 🛡️

Introduction

Why Multi-Agent for Compliance?

System Architecture

The Agents — Deep Dive

1. 🔍 Risk Classifier Agent

2. 📋 Policy Checker Agent

3. 🔧 Remediation Agent

4. 📝 Report Writer Agent

5. 🎯 Orchestrator Agent

Memory: Tracking Compliance Over Time

FastAPI Layer

AgentCore Runtime Deployment

Testing Strategy

Sample Output

Key Design Patterns

✅ Structured JSON-only outputs

✅ Temperature tuning per agent role

✅ Conditional orchestration

✅ Domain-specific rule injection

AWS Services Used

What's Next

Conclusion

Resources