[EAAPL-GOV004] AI Policy Enforcement

Category: Governance / Runtime Control Sub-category: Policy Decision & Enforcement Version: 1.2 Maturity: Proven Tags: PDP, PEP, OPA, policy-enforcement, runtime-governance, guardrails, acceptable-use, data-handling Regulatory Relevance: APRA CPS234 §15–§17, EU AI Act Article 9, Privacy Act 1988 APP 3/APP 6, NIST AI RMF MANAGE 2.4

1. Executive Summary

The AI Policy Enforcement pattern implements runtime governance controls that ensure AI systems comply with organisational policies and regulatory requirements at the point of inference—not just at deployment time. Using the Policy Decision Point / Policy Enforcement Point (PDP/PEP) architectural pattern, it intercepts every AI request and response, evaluates applicable policies, and enforces decisions in real time.

This pattern addresses the critical governance gap that exists between pre-deployment approval and ongoing operational compliance. An AI system approved today will face different regulatory requirements, different data classifications, and different acceptable-use boundaries next year. Without runtime enforcement, policy changes require re-deployment to take effect—creating a window of non-compliance that regulators will not accept.

The pattern implements Open Policy Agent (OPA) as the policy decision engine, enabling policies to be expressed as code (Rego language), version-controlled alongside application code, tested independently, and updated without application redeployment. This "policy-as-code" approach is the enterprise standard for achieving both agility and auditability in runtime governance.

For CIOs and CTOs, the strategic outcome is clear: organisational AI policies become enforceable in real time, with auditable evidence of every policy evaluation. This transforms AI governance from a paper exercise into an operational control.

2. Problem Statement

Business Problem

AI policies (acceptable use, data handling, geographic restrictions, financial advice disclaimers) exist as documents but are not enforced at runtime. Business units implement interpretations inconsistently. Policy changes require application redeployment cycles of weeks. Compliance teams cannot prove policies are enforced.

Technical Problem

AI requests flow through application code with policy logic embedded inline as conditionals. Policy changes require code changes, testing, and deployment. There is no central visibility of policy decisions across AI systems. Different teams implement the same policy differently, creating inconsistency.

Symptoms

• Same AI policy producing different outcomes in different business unit implementations
• Policy violation discovered post-incident without runtime evidence of enforcement attempt
• Average time from policy change to enforced implementation measured in weeks due to deployment cycles
• Compliance teams relying on manual spot-checks because automated enforcement evidence does not exist
• Geographic data residency violations because routing logic in application code not updated with new regulatory requirements

Cost of Inaction

• Regulatory: Privacy Act APP 6 violations (purpose limitation breach by AI system); APRA CPS234 information security breach
• Legal: Unauthorised processing of personal information for AI purposes
• Operational: Policy inconsistency creating unpredictable AI behaviour affecting customer experience and liability
• Financial: Geographic restriction violations creating cross-border data transfer liability

3. Context

When to Apply

• Any AI system making decisions that are subject to policy constraints (acceptable use, data handling, geographic restriction)
• Organisations operating in multiple regulatory jurisdictions with different AI requirements
• Enterprises requiring real-time auditability of policy enforcement
• Organisations adopting "policy-as-code" practices for AI governance
• When policy change frequency requires decoupling policy from application deployment cycle

When NOT to Apply

• Simple, single-jurisdiction AI systems with static policies unlikely to change
• Proof-of-concept environments (overhead not justified)
• AI systems where the enforcement latency overhead (typically 5–20ms) is incompatible with real-time requirements (e.g., high-frequency trading — separate design required)

Prerequisites

• AI Policy framework documented and approved (AI Use Policy, Data Handling Policy)
• OPA or equivalent policy engine available in infrastructure
• API gateway or service mesh available as enforcement insertion point
• Policy authorship team with Rego or equivalent policy language competency

Industry Applicability

4. Architecture Overview

The AI Policy Enforcement pattern implements the classic Policy Decision Point / Policy Enforcement Point architectural separation, adapted specifically for AI workloads. This separation is not merely organisational—it is a fundamental architectural principle that enables policy agility without application change.

The PDP/PEP Separation. The Policy Decision Point (PDP) is responsible for evaluating policies against context and returning a decision (allow/deny/allow-with-modification). The Policy Enforcement Point (PEP) is responsible for intercepting requests, assembling context for the PDP, and enforcing the PDP decision. They are deployed as separate components, enabling the PDP to be updated (new policies, policy changes) without touching the PEP, and enabling the same PEP to enforce policies from different PDPs.

Open Policy Agent as the PDP. OPA provides a general-purpose policy engine with Rego as its policy language. For AI governance, OPA is configured with a set of AI-specific policy bundles: acceptable use policies, data handling policies, geographic restriction policies, financial services-specific policies, and model-specific policy overrides. Policies are stored as Rego files in version control, peer-reviewed before deployment to OPA, and tested with automated Rego unit tests. Policy deployment to OPA is decoupled from application deployment—a policy change can be live within minutes of approval.

Enforcement Topology. The PEP operates at three insertion points: (1) API Gateway level for coarse-grained enforcement (request blocking before reaching AI infrastructure), (2) AI Middleware Proxy for fine-grained enforcement (request transformation, response filtering, output guardrails), and (3) Application-level SDK for deep context enforcement (user-specific policies, feature-level controls). This layered topology provides defence in depth: a request must pass all three layers, and a policy that cannot be enforced at the API Gateway level will be caught at the middleware level.

Policy Bundle Architecture. Policies are organised into bundles by domain: acceptable_use (what users can ask), data_handling (what data can flow), geographic_restriction (what data can be processed where), output_guardrails (what responses can be returned), and financial_advice (disclaimers and prohibited recommendations). Bundles are versioned and can be independently updated and rolled back. Each bundle references external data (policy data, user attributes, geographic lookup) via OPA's external data mechanism.

Context Assembly for AI. AI policy evaluation requires richer context than typical API policies. The PEP assembles a context payload for each PDP call that includes: user identity and roles, tenant/organisation context, request content metadata (not full content at PDP layer — privacy-preserving), data classification tags, geographic context (user location, data location), model MRID and risk tier, and session history metadata. This context enables policies to make nuanced decisions: the same prompt may be allowed for a verified professional user and blocked for an anonymous user.

Response Transformation. Beyond allow/deny, the PDP can return transformation directives: append a financial advice disclaimer to the response, redact named individuals from model output, route to a higher-oversight model, or require human review before response delivery. This "allow-with-modification" capability transforms the PEP from a binary gate into an active governance participant.

Policy Change Governance. Policy-as-code integrates with the AI approval workflow (GOV003). Material policy changes (not cosmetic) require approval before deployment to the production OPA bundle. A lightweight policy change workflow with Security and Compliance review (30-minute turnaround for urgent changes) is defined alongside the full model approval workflow. This prevents policy governance becoming a bottleneck while maintaining integrity for significant changes.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Policy Enforcement Flow

Error Flow

8. Security Considerations

OPA Security Hardening

• OPA management API (bundle upload, query API) accessible only from policy CI/CD system via mTLS
• OPA query API accessible from PEP services only; no general access
• Rego policies peer-reviewed before merge; automated policy test coverage enforced (>80% statement coverage)
• Policy bundle integrity verified via signature on bundle pull

Context Data Protection

• User attributes in OPA context do not include personal information (use opaque user ID + role set)
• Full request content does not reach OPA; only derived metadata (content classification, entity detection results)
• OPA decision logs do not include full request content; include only context keys and decision

OWASP LLM Top 10 Mapping

9. Governance Considerations

Policy-as-Code Governance

All policies are in version-controlled Git repositories, peer-reviewed, and CI/CD-tested before deployment. Policy history is fully reconstructable. Any policy active at any point in time can be retrieved from the version control system.

Policy Change Control

Material policy changes require lightweight approval (Security + Compliance sign-off within 4 hours for urgent; standard 2-day process for planned). Policy change log is maintained as a GOV001 model register reference.

Governance Artefacts

10. Operational Considerations

SLOs

Monitoring

Disaster Recovery

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Option Comparison

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

APRA CPS234

• §15: Information classification and handling. Policy bundles enforce data handling policies aligned to information classification scheme.
• §17: Information security controls must be implemented. Runtime policy enforcement is a documented information security control.

EU AI Act

• Article 9: AI risk management system must include measures to address identified risks. Policy enforcement implements risk controls at runtime.
• Article 13: Transparency — AI systems must be designed to allow operators to understand system operation. Policy decision logs provide this transparency.

Privacy Act 1988 / APPs

• APP 3.3: Personal information must not be collected unless reasonably necessary. Input policy enforces data minimisation at collection point.
• APP 6: Personal information must not be used or disclosed for a purpose other than the primary purpose of collection. Purpose limitation policy bundle enforces this at runtime.

NIST AI RMF

• MANAGE 2.4: AI risk responses include monitoring, testing, and adjustment. Policy enforcement with real-time decision logging implements this continuously.

15. Reference Implementations

AWS

Azure

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven (Level 3)

18. Revision History