Compliance-Driven Logging: What Regulators Actually Need

"We log everything for compliance."

I hear this constantly. It's almost always wrong.

Logging everything doesn't satisfy compliance requirements. It creates new compliance problems while missing the actual requirements.

The Compliance Paradox

More logging often means worse compliance:

Regulators don't want your logs. They want specific answers to specific questions.

What Regulators Actually Ask

EU AI Act

The EU AI Act requires that high-risk AI systems maintain logs sufficient to:

1. Trace decisions to inputs - Given an output, can you show what inputs led to it?
2. Verify human oversight - Can you prove humans were in the loop when required?
3. Demonstrate testing - Can you show the system was tested appropriately?
4. Enable auditing - Can an external party verify the system's behavior?

Notice what's NOT required:

• Every API call
• Every state change
• Every internal operation
• Debug-level traces

SOC 2

SOC 2 focuses on:

1. Access controls - Who accessed what, when
2. Change management - What changed, who approved it
3. Incident response - What happened, how was it handled
4. Data integrity - Can you verify data wasn't corrupted

Again, not "log everything." Log evidence of controls.

Industry-Specific (HIPAA, PCI, etc.)

Each regulation has specific requirements:

• HIPAA: Access to PHI, disclosures, amendments
• PCI: Cardholder data access, security events
• GDPR: Processing activities, consent, access requests

The pattern: specific evidence for specific controls.

The Compliance Logging Framework

Step 1: Map Requirements to Questions

Step 2: Define Required Evidence

For "Why did the AI do X?":

{
  "decision_id": "dec_xyz",
  "timestamp": "2025-02-26T10:15:00Z",
  "agent": "approval-agent",
  "input_summary": "Loan application for $50,000",
  "decision": "approved",
  "reasoning": "Credit score 780, DTI ratio 28%, employment stable",
  "confidence": 0.94,
  "model_version": "v2.3.1"
}

For "Was a human involved?":

{
  "decision_id": "dec_xyz",
  "human_review": {
    "required": true,
    "completed": true,
    "reviewer": "agent_john",
    "timestamp": "2025-02-26T10:17:00Z",
    "action": "approved_as_recommended"
  }
}

Step 3: Log Only Required Evidence

You don't need:

• The 47 API calls made during processing
• The internal state machine transitions
• The cache hits and misses
• The retry attempts that succeeded

You need the decision, the reasoning, and the human involvement.

Minimum Viable Compliance Logging

For EU AI Act High-Risk Systems

def compliant_log(decision):
    empress.log({
        # Traceability
        "decision_id": decision.id,
        "timestamp": decision.timestamp,
        "input_hash": hash(decision.inputs),  # For reproducibility
        "input_summary": summarize(decision.inputs),  # Human-readable

        # Decision details
        "agent": decision.agent_id,
        "agent_version": decision.agent_version,
        "decision": decision.choice,
        "confidence": decision.confidence,
        "reasoning": decision.reasoning,

        # Human oversight
        "human_required": decision.requires_human,
        "human_review": decision.human_review if decision.requires_human else None,

        # Audit support
        "model_version": decision.model_version,
        "policy_version": decision.policy_version
    })

That's it. That's the minimum for EU AI Act compliance.

For SOC 2

def soc2_log(event):
    empress.log({
        # Access control evidence
        "actor": event.user_id,
        "action": event.action,
        "resource": event.resource,
        "timestamp": event.timestamp,
        "ip_address": event.ip,

        # Authorization evidence
        "authorized": event.authorized,
        "authorization_method": event.auth_method,

        # Change evidence (if applicable)
        "change_type": event.change_type,
        "previous_value_hash": event.prev_hash,
        "new_value_hash": event.new_hash,
        "approver": event.approver
    })

What NOT to Log for Compliance

Ironically, some logging hurts compliance:

PII You Don't Need

// DON'T log this
{
  "customer_name": "John Smith",
  "email": "john@example.com",
  "ssn": "123-45-6789",  // DEFINITELY not this
  "decision": "approved"
}

// DO log this
{
  "customer_id": "cust_xyz",  // Reference, not PII
  "decision": "approved"
}

Data That Creates Retention Burden

Every piece of logged data must be:

• Retained for the required period
• Deleted after the retention period
• Searchable for access requests
• Protected against unauthorized access

More data = more burden.

Sensitive Internal Details

// DON'T log this
{
  "decision": "deny",
  "internal_fraud_score": 0.97,
  "fraud_signals": ["velocity_spike", "new_device", "location_mismatch"]
}

// DO log this
{
  "decision": "deny",
  "reason_category": "risk_assessment",
  "review_required": true
}

Detailed fraud signals could help bad actors game your system if exposed.

The Empress Compliance Framework

Empress provides compliance-specific logging helpers:

// EU AI Act compliant decision logging
empress.compliantDecision({
  regulation: "eu_ai_act",
  decision: decision,
  humanOversight: humanReview
});

// SOC 2 compliant access logging
empress.compliantAccess({
  regulation: "soc2",
  actor: user.id,
  resource: resource.path,
  action: "read"
});

// Auto-generates required fields
// Auto-excludes unnecessary fields
// Auto-applies retention policies

The Audit Test

Before any compliance audit, run this test:

1. Pick 10 random AI decisions from the past year
2. For each, answer: "Why did the AI do this?"
3. If you can't answer from your logs, you're not compliant

If you can answer clearly and quickly, you're probably logging the right things—and nothing more.

That's compliance-driven logging.