Enterprise AI Architecture · Part II · AI Governance

Chapter 7 — AI Policies

By Anjaneyullu Tamma

An analyst pastes a customer list into a public chatbot to summarize it.

No rule said she couldn't.

No control stopped her.

The policy existed — a wiki page, updated last year, that no one had read.

The breach report, months later, is very specific about what left the building.

Names. Account numbers. A support ticket queue's worth of complaints, verbatim.

Nothing was wrong with the chatbot. It did exactly what a public chatbot does.

A policy that isn't enforced is a suggestion. A policy that isn't written is a guess.

Purpose

Chapter 4 established who decides what AI output can be trusted; Chapters 5 and 6 built the runtime controls — guardrails and human approval — that enforce those decisions in flight. This chapter defines the rules those controls are enforcing. A policy, in the sense this book uses the word, is not a document filed away for an audit — it is a written rule with a named owner, a version history, and a compiled runtime control, across five domains: acceptable use, model selection, prompt, data usage, and audit. A policy that lives only as a document is aspiration. The discipline of this chapter is turning each rule into something a machine can enforce and an auditor can verify.

Executive Summary

Policy is the source of every AI control in this book; the job of this chapter is to make policy specific enough to enforce and enforced firmly enough to trust.

• Policy is the source of every control — a guardrail with no policy is a hardcoded opinion; a policy with no guardrail is a wish.
• Shadow AI is the default in a policy vacuum — most knowledge workers already bring their own AI tools to work, and sensitive data leaks through whichever one is fastest.
• Five domains cover the surface — acceptable use, model selection, prompt, data usage, and audit — and each maps to a concrete runtime control.
• Policy-as-code is the enforcement mechanism — written rules compile into OPA/Rego authorization plus gateway guardrails, applied on both input and output.
• Standards give you the skeleton — NIST GOVERN, ISO/IEC 42001, and the EU AI Act — so you write the policy once and satisfy all of them at once.

Running Examples

Two programs at Northwind Holdings — the fictional insurance and financial-services group introduced in Chapter 5 — anchor this chapter.

The first is Northwind Holdings' AI Readiness Assessment, which moved the company from ad hoc pilots to governed scale. The engagement produced a model inventory, a risk-tiering framework, standardized intake and risk assessment for every new use case, approval gates before anything reached production, documented governance policies, and named, accountable owners for each. It is the policy chapter made concrete at portfolio scale, and we return to it for model selection, the audit trail, and the link back to the governance framework in Chapter 4.

The second is Northwind Holdings' customer-facing AI assistant, built for trusted policyholder self-service. It runs explicit refusal boundaries that decline out-of-scope requests, PII redaction and prompt-injection defenses on every interaction, responses grounded in approved sources with citations, and automatic escalation for sensitive cases. It is acceptable-use, prompt, and data policy made runtime — enforced at the gateway on every single exchange, not asserted in a document somewhere upstream. We return to it for acceptable use, prompt policy, and data-usage enforcement.

What a Policy Is Here — and Isn't

A policy, for the purposes of this book, is an enforceable rule with a named owner and an audit trail. It is not a wiki page, a slide in a governance deck, or a paragraph in an employee handbook that nobody has opened since onboarding. Two failure modes bookend the discipline, and both are common. Documentation without enforcement is aspiration — a rule that exists in language but nowhere in the request path, which means it competes with the fastest path to getting work done and loses. Enforcement without documentation is worse in a different way: a gateway rule with no policy behind it has no organizational basis, no owner to explain it to a regulator, and no defensible reason it exists at all. You need both, and they need to be the same artifact viewed two ways — the document that a human reads and approves, and the machine-readable rule compiled from it.

Key Principles

Four principles separate a policy that actually governs behavior from one that merely describes an intention.

Policy is the source of controls. Every guardrail, every approval gate, every redaction rule in Chapters 5 and 6 should trace back to a written policy — and every written policy should compile forward into a control. A guardrail with no policy behind it is a hardcoded opinion someone made up under deadline pressure; a policy with no guardrail enforcing it is a wish written down and filed. The relationship runs in both directions, and an architecture review should be able to walk it either way: point at any runtime check and name the policy it enforces, or point at any policy clause and name the control that enforces it.

Write once, enforce as code, map to standards. A single, well-structured policy set, expressed declaratively, can satisfy NIST's GOVERN function, ISO/IEC 42001's Annex A.2, and the EU AI Act's governance obligations at the same time — because all three are asking variations of the same question: who decided this was acceptable, and can you prove it. Writing the policy once and mapping it to each framework is far cheaper than maintaining three parallel compliance efforts that happen to describe the same rules in different vocabularies.

Least privilege is a policy, not a setting. Which models a use case may call, which data classes it may touch, which tools it may invoke — all of this should be denied by default and explicitly granted, the same discipline applied to network access or database permissions for decades. Treating model and data access as a policy decision, rather than a configuration a developer sets once and forgets, is what keeps the surface area from growing invisibly as new use cases launch.

Policies are versioned and owned, like code. A policy that cannot be diffed cannot be reviewed, and a policy no one owns cannot be updated when the world changes — new regulation, a new model release, a new attack technique. Every policy in this chapter's five domains needs an owner who can be named in an audit, a version history that shows what changed and when, and a review cadence that keeps it from going stale the way the wiki page in this chapter's cold open did.

The Five Policy Domains

Five domains cover the policy surface an enterprise AI program needs to govern. Each maps to a concrete runtime control and a standard an auditor will recognize.

Acceptable Use

An enterprise acceptable-use policy (AUP) for AI is not a generic IT policy with "AI" inserted. It needs to name the approved tools and the path for vetting a new one; state prohibited uses explicitly rather than relying on common sense; specify how each data classification may and may not be handled by AI; and assert human accountability in plain language — the person using the tool owns the output and must verify it before it goes anywhere consequential. It should require disclosure when content is AI-generated, wherever a customer or a colleague would reasonably want to know. And it needs to name shadow AI as a prohibited practice explicitly, paired with a sanctioned alternative fast enough that people do not feel forced around it. Harvard's HUIT AI guidelines and the SANS AI Toolkit's AUP template are useful exemplars of this shape — specific, tool-aware, and written for the person actually doing the pasting, not just for legal review.

Technical enforcement is what turns the document into a control: endpoint blocking of unapproved AI domains, data-loss-prevention rules tuned to catch the patterns in the AUP's prohibited list, and runtime monitoring that flags unusual volumes of data leaving toward an AI endpoint. The customer-facing assistant from the running examples is acceptable-use policy made runtime in the other direction — its refusal boundaries are the AUP's prohibited-use list, compiled into the assistant's own behavior rather than left for a human to remember.

Artifact — the acceptable-use one-pager:

ACCEPTABLE USE OF AI — ONE-PAGE SUMMARY

Approved tools:      [enterprise chat assistant] · [enterprise coding assistant]
                      New tool? Route through the AI intake process before first use.

Prohibited uses:      - Pasting Confidential or Restricted data into any
                        non-approved AI tool ("shadow AI")
                      - Using AI output as final legal, medical, or financial
                        advice without qualified human review
                      - Impersonating a person, generating deceptive content,
                        or bypassing disclosure requirements

Data handling:        Public / Internal  -> approved tools, standard controls
                      Confidential       -> enterprise no-training tier only
                      Restricted / PHI   -> self-hosted or zero-data-retention
                                             tier, with redaction, only

Human accountability: You own and must verify any AI output before you act on
                      it, publish it, or send it externally.

Disclosure:           Say so when content is AI-generated, wherever a
                      reasonable person would want to know.

Shadow AI:            Prohibited. Report an unmet need to [AI platform team] --
                      a sanctioned tool or exception path exists for it.

Enforcement:          Endpoint blocking - DLP rules - runtime monitoring.
                      Violations are logged and reviewed like any other
                      policy exception.

Model Selection

Model selection is a policy decision before it is a technical one, and it should be filtered in a fixed order. Hard filters come first — data residency, deployment mode, context window, latency, and cost eliminate most candidates before a single benchmark is run. Task-tier capability benchmarking narrows what survives the hard filters to what is actually good enough for the job. Multi-model routing is the last step, sending different requests to different approved models by task rather than betting the whole use case on one.

The hard filters need to include a trap that is easy to miss: open-weight does not mean open source. The OSI's Open Source AI Definition sets a real bar — training data disclosure, freedom to use, study, modify, and share — and most "open" model releases do not clear it. The Llama Community License is the clearest example: it imposes a 700-million-monthly-active-user threshold above which a separate commercial license is required, restricts use in certain competitive contexts, and prohibits using Llama outputs to train competing models. None of that makes Llama models bad choices — it makes the license a governed variable, not a footnote, and it belongs in the same hard-filter pass as data residency.

Every approved model needs a model card or system card on file — the practice Mitchell et al. formalized in 2018 and that providers like Anthropic now publish as system cards for frontier releases — documenting intended use, known limitations, and evaluation results. And every approved model belongs in a registry adapted from the Federal Reserve's SR 11-7 model risk management guidance: an inventory entry, an independent validation performed at least annually, a risk tier, a named owner, and a validation record an examiner could ask to see.

Artifact — model-selection policy table (representative row shape):

Northwind Holdings' AI Readiness Assessment is this section at portfolio scale: the model inventory and risk-tiering framework it produced is exactly the registry described above, applied across every use case the company runs rather than one system at a time.

Prompt Policies

Prompts are code, and they should be governed like code. A production system prompt belongs in a central prompt registry with immutable version history and diffs, subject to pull-request-style review before it changes, gated by an evaluation suite before promotion, staged from development to production rather than edited live, protected by role-based access control, and rollback-capable — with a full audit trail of who changed what and where it deployed. Tooling such as LangSmith, Langfuse, and the MLflow Prompt Registry exists specifically to make this discipline practical rather than aspirational.

Injection defense is itself a policy question, not only a guardrail question. OWASP ranks prompt injection as LLM01 — the single most common risk category in the field — and is explicit that no fool-proof prevention exists, only defense in depth. LLM08:2026, Hidden Context Exposure (the 2026 broadening of what was System Prompt Leakage, LLM07:2025 — see Chapter 5), is the mirror-image risk: a system prompt is not a secret-storage mechanism, and anything in it should be written as if it could someday be read back to the user, because it can be.

The discipline above is the same shape as Figure 7.1's compile pipeline, applied specifically to prompts: draft, PR review, evaluation gate, staged deployment, rollback — a prompt is never one edit away from production.

Data Usage Policies

Data usage policy is where acceptable use meets model selection meets the data itself. Classify data into four classes — Public, Internal, Confidential, and Restricted/Regulated (which includes PHI) — and map each class to the deployment tiers it may reach: a public API endpoint, an enterprise no-training tier, a zero-data-retention (ZDR) endpoint, or a fully self-hosted model. The mapping is enforced at the point of data access — before a document is indexed into a RAG store, before a request is routed to a model — not after the fact.

Provider retention terms matter here and they move. As of this writing, OpenAI's enterprise terms describe no training on business or API data by default, API data retained up to 30 days, and zero-data-retention available for eligible endpoints; Anthropic's terms describe no training without explicit permission, roughly a 30-day default deletion window, zero-data-retention available through a sales agreement, and data residency controls via an inference-geo setting. Treat every specific number in this paragraph as time-sensitive — verify the current terms against the provider's published policy before you rely on them in a contract or an audit response.

Data protection agreements and business-associate agreements (for HIPAA-covered data), residency commitments, and RAG source governance round out this domain. RAG source governance means the model surfaces only content the requesting user is actually entitled to see — permissions enforced at retrieval time, not assumed because the document happened to be indexed — with provenance and lineage tracked back to the source. The customer-facing assistant's grounding-with-citations behavior is this policy enforced on every response: nothing reaches the customer that cannot be traced to an approved, permissioned source.

Artifact — the matrix as an OPA-enforceable routing spec (excerpt):

data_class: confidential
allowed_tiers: [enterprise_no_training, zero_data_retention, self_hosted]
denied_tiers:  [public_api]
required_controls:
  redaction: true
  human_review: conditional   # required above a defined sensitivity threshold
  residency: must_match_data_residency_policy

Audit Requirements

The audit trail is what lets an organization reconstruct any AI-influenced decision after the fact — and it mirrors, deliberately, the log structure Chapter 6 relies on for human approvals. It needs to capture the model and its version, the prompt-template version in effect, the provenance of any retrieved context and the access decision made about it, the data classification of the input, the identity of any human verifier, and timestamps throughout.

Retention periods are a place this citation is easy to get wrong, and it is worth stating precisely: the EU AI Act's logging capability requirement lives in Article 12, but the retention period — providers and deployers of high-risk systems must retain logs for at least six months — is set by Article 19 and Article 26(6), not Article 12. Sectoral rules run much longer and were not written with AI in mind, which is exactly why they still bind it: SEC Rule 17a-4 requires six years of records (a 2022 amendment allows either WORM storage or an audit-trail alternative that meets equivalent guarantees), FINRA Rule 4511 requires six years, and HIPAA's administrative requirements at 45 CFR 164.316 require six years for the relevant documentation.

Immutability is a real design choice, not a default: the SEC's 2022 amendment to Rule 17a-4 codified that a firm may satisfy the requirement with WORM (write-once-read-many) storage or with an audit-trail system that reconstructs records with equivalent integrity guarantees — either is acceptable, but "we didn't configure either" is not. The AI Readiness Assessment's documented governance policies and named owners are, in this domain, the organizational half of what the immutable log is the technical half of — a decision record that names who is accountable and a log that proves what actually happened.

Policy-as-Code

Policy-as-code is the mechanism that turns everything above from a document into a runtime decision. Open Policy Agent (OPA), a CNCF-graduated project, is the reference implementation of the pattern: it decouples the policy decision from the point of enforcement — software queries OPA with a JSON input describing the request, and OPA returns an allow or deny decision evaluated against a declarative Rego policy. It is the natural authorization layer for which tools and which data an agent may touch — the least-privilege control that OWASP's LLM03:2026 (Excessive Agency) exists to motivate.

AI gateways are where policy-as-code meets the model traffic itself, compiling written rules into deterministic input and output controls on every request: AWS Bedrock Guardrails (content filters, denied topics, PII filters, prompt-attack detection, contextual grounding checks), Azure AI Content Safety and Foundry Guardrails, Google's Apigee combined with Model Armor, and Kong's AI Gateway all implement the same underlying pattern described in Chapter 5 — a proxy every request passes through, enforcing rules the prompt cannot see or override.

Artifact — OPA/Rego prompt-and-data policy snippet:

package ai_policy.authorization

default allow := false

# The request is allowed only if every one of these holds:
#  1. the requested model is in the approved registry for the caller's data class
#  2. the prompt template in use is an approved, versioned template
#  3. a PII-handling action is explicitly configured for this request

allow if {
    input.model in data.approved_models[input.caller.data_classification]
    input.prompt_template.version in data.approved_prompt_versions[input.prompt_template.name]
    input.pii_action in {"redact", "tokenize", "block"}
}

# Restricted and regulated data may never reach a public API tier,
# regardless of any other allow rule above.
deny if {
    input.caller.data_classification == "restricted"
    input.model_tier == "public_api"
}

Notice the shape: the highest-stakes rule — restricted data can never reach a public endpoint — is a flat deny that ignores everything else, the same pattern Chapter 5 used for payout authorization. It is deliberately not AI checking AI; it is a rule a machine evaluates the same way every time.

The Standards Crosswalk

None of the standards referenced in this chapter are competing homework assignments — they are different views of the same policy layer, and mapping your five domains to each of them once is far cheaper than maintaining separate compliance narratives.

NIST's GOVERN function is the accountability and policy layer that policy-as-code is compiled from — it asks who owns risk and how policy is set, which is this chapter in NIST's own vocabulary. ISO/IEC 42001's Annex A.2, "Policies related to AI," is the management-system equivalent. The EU AI Act's obligations touch acceptable use (transparency), model selection and data usage (Article 10's data-governance requirements for high-risk systems), and audit (Articles 12, 19, and 26(6)). OWASP's LLM Top 10 supplies the threat model behind prompt policy and policy-as-code alike.

Design Tradeoffs

Every policy choice trades something for something else. The point of writing the tradeoff down is to make the trade on purpose rather than by default.

Best Practices

• Write every policy as an enforceable rule with a named owner, not a document filed for an audit.
• Maintain a single policy set and map it to NIST GOVERN, ISO/IEC 42001, and the EU AI Act rather than writing three parallel compliance narratives.
• Default to deny for model, data, and tool access, and grant explicitly per use case.
• Vet every "open" model's license for MAU thresholds, competitive-use restrictions, and training restrictions before approval, not after deployment.
• Keep a model card or system card, a risk tier, and a validation record on file for every approved model.
• Govern prompts like code: version history, PR review, an evaluation gate, and staged promotion to production.
• Enforce the data-classification-to-model matrix at the point of data access, before indexing or routing, not after.
• Log everything the audit trail needs to reconstruct a decision, and set retention against the longest applicable regulatory floor, not the provider's default.
• Compile policy into OPA/Rego and gateway guardrails so enforcement does not depend on individual memory or compliance.
• Give shadow AI a fast, sanctioned alternative — a memo alone will always lose to the fastest path to getting work done.

Anti-Patterns

• A policy that isn't enforced is a suggestion. A wiki page, a slide, a paragraph in a handbook — none of it is a control until it compiles into something the gateway checks on every request.
• A policy that isn't written is a guess. Enforcing a rule no one documented has no organizational basis and nothing to show an auditor when asked why.
• Shadow AI treated as a discipline problem. Banning a tool without offering a sanctioned, comparably fast alternative just moves the leak somewhere less visible.
• Trusting the provider's default retention as your audit trail. A 30-day default is not a substitute for the regulatory retention floor your sector actually requires.
• Citing Article 12 for the EU AI Act's six-month retention period. Article 12 is the logging capability; Articles 19 and 26(6) set the retention duration — cite the right one.
• Model selection as a one-time technical decision. Choosing a model once and never re-validating it, while its license terms, safety behavior, and provider retention policy all continue to change underneath it.
• Policy owned by no one. A rule with no named owner cannot be updated when the regulation, the model, or the attack technique changes, and it quietly goes stale.

Maturity Model

Implementation Checklist

• Every policy has a named owner, a version history, and a compiled runtime control.
• An acceptable-use policy names approved tools, prohibited uses, data-handling rules, and a shadow-AI reporting path with a sanctioned alternative.
• Model selection runs hard filters (residency, deployment mode, license, context, latency, cost) before capability benchmarking.
• Every approved model has a model card or system card, a risk tier, and an SR-11-7-style validation record on file.
• Prompts are versioned, reviewed, evaluation-gated, and staged to production like application code.
• A data-classification-to-model matrix is enforced at the point of data access, before indexing or routing.
• Audit logs capture model, prompt version, context provenance, data classification, and human-verifier identity.
• Retention periods meet the longest applicable regulatory floor, not the AI provider's default retention window.
• Policy is compiled into OPA/Rego and gateway guardrails, not left to individual compliance.
• Each of the five domains is mapped to NIST GOVERN, ISO/IEC 42001, and the EU AI Act.

Standards and Further Reading

NIST AI RMF (AI 100-1) and its Generative AI Profile (AI 600-1), particularly the GOVERN function; ISO/IEC 42001:2023, particularly Annex A.2, "Policies related to AI"; the EU AI Act, Articles 10, 12, 19, 26, and 50 — read alongside the 2025-26 Digital Omnibus deferrals, which are not final at the time of writing; the OWASP Top 10 for LLM Applications, especially LLM01 (Prompt Injection), LLM03:2026 (Excessive Agency), and LLM08:2026 (Hidden Context Exposure, the 2026 broadening of System Prompt Leakage — OWASP re-ranks this list as incident data accumulates, so treat the category, not the number, as load-bearing; see Chapter 5); the Federal Reserve's SR 11-7 for the model-inventory and validation precedent; the OSI Open Source AI Definition 1.0; and the Harvard HUIT and SANS AI Toolkit acceptable-use policy exemplars.

Chapter Summary

• Policy is the source of every AI control; the discipline is making each rule executable, owned, and audited — not a document.
• Five domains — acceptable use, model selection, prompt, data usage, and audit — each map to a concrete runtime control.
• Shadow AI is what fills a policy vacuum; the fix is a sanctioned alternative plus technical enforcement, not a stronger memo.
• Policy-as-code (OPA plus AI gateways) compiles written rules into deterministic input and output controls; the data-class-to-model matrix is the durable artifact.
• Write the policy once and map it to NIST GOVERN, ISO 42001, and the EU AI Act — and verify time-sensitive provider terms and regulatory dates at publication.

Looking Ahead

Policy says what data may go where. The next part makes that physically true. Chapter 8, Data Protection, opens Part III with the mechanisms that turn a data-usage policy from a rule into a guarantee — encryption, tokenization, masking, secure pipelines, and residency enforced in the data layer itself, not only at the gateway.

Human Approval (Ch 6) → AI Policies (Ch 7) → Data Protection (Ch 8): the rule, then the mechanism that enforces it in the data layer.