AI Governance and Security Policy: Enterprise Framework 2026

AI governance security is the discipline of deciding which AI systems your organization may build, buy and run, and then proving, with technical controls rather than slideware, that they behave within those limits. Most enterprises have one half of this. Compliance teams write principles that engineers never see, while security teams harden individual models without any shared definition of what is allowed. This framework joins the two: an operating model, an inventory-driven risk process, a policy you can adopt, a control baseline mapped to real attack classes, and a 90-day plan to put it in place.

Governance answers what is permitted and who is accountable. Security answers whether the permitted behavior is actually enforced and can be evidenced. When they are run separately, two failure modes appear. A governance-only program produces approved-use-case lists that nothing enforces, so employees paste customer data into whichever chatbot is fastest. A security-only program hardens the systems it happens to know about and misses the unsanctioned ones, and it has no authority to say a risky use case should not exist.

The practical test is simple: for every governance question a regulator, customer or board member can ask, there should be a named control that produces the answer on demand.

Enterprises do not need to implement every framework separately. They need one control backbone that can be mapped to each. The instruments below are the ones that most commonly drive enterprise AI programs in 2026.

• NIST AI RMF as the control backbone. Its Govern, Map, Measure and Manage functions map cleanly to the operating model, inventory, testing and incident processes in this article.
• ISO/IEC 42001 as the auditable wrapper. If customers or regulators ask for certification, the management-system structure is already what you are building.
• EU AI Act as the risk-tier driver. Even for non-EU organizations, its categories are a useful starting taxonomy for your internal tiers (Section 4), and EU-facing products need them anyway.
• OWASP and ATLAS as the test plan. Controls are credible only if you can show which named attacks they stop.

Governance fails most often because nobody can say who decides. The operating model below uses the familiar three-lines structure so it fits existing risk and audit processes instead of creating a parallel bureaucracy.

You cannot govern what you cannot list. The inventory is the single most valuable artifact in the program: it drives risk tiering, review depth, vendor scrutiny, incident scoping and regulatory reporting. Treat it as a system of record, not a spreadsheet someone updates once a year.

# ai_inventory/payments-support-assistant.yaml
system_id: AI-0142
name: Payments Support Assistant
owner: jane.doe@example.com          # a named, accountable person
business_purpose: Draft replies to customer payment queries for agent review
lifecycle: production                 # proposed | pilot | production | retired
sourcing: third_party_api             # built | fine_tuned | open_weights | third_party_api | embedded_saas
model: vendor-model-x (version pinned: 2026-08-01)
data_classes: [customer_pii, payment_metadata]
data_leaves_org: true                 # sent to an external provider?
retrieval_sources: [kb_payments_v3]   # RAG corpora, with their own owners
tools_and_actions: [read_ticket, draft_reply]   # no send, no refund
human_in_loop: required_before_send
affects_individuals: true             # influences decisions about people?
risk_tier: 2                          # computed, then confirmed by a reviewer
last_review: 2026-09-12
next_review: 2027-03-12

Tiering should be a repeatable function of facts in the record, then confirmed by a human reviewer. This version is intentionally conservative: any one high-impact trait pushes a system up a tier.

# risk_tier.py: compute a starting tier from inventory facts (1 = highest scrutiny)
PROHIBITED_PURPOSES = {"social_scoring", "emotion_inference_workplace", "untargeted_face_scraping"}
CONSEQUENTIAL_DOMAINS = {"employment", "credit", "insurance", "education",
                         "housing", "healthcare", "essential_services", "law_enforcement"}
SENSITIVE = {"special_category", "payment_card", "credentials", "health"}

def starting_tier(s: dict) -> int:
    if s.get("purpose_category") in PROHIBITED_PURPOSES:
        return 0                      # 0 = blocked; no exception path without board approval

    score = 0
    if s.get("domain") in CONSEQUENTIAL_DOMAINS and s.get("affects_individuals"):
        score += 3                  # consequential decisions about people
    if set(s.get("data_classes", [])) & SENSITIVE:
        score += 2
    if s.get("data_leaves_org"):
        score += 1
    if s.get("external_facing"):
        score += 1
    if s.get("autonomous_actions") and not s.get("human_in_loop"):
        score += 3                  # can act with side effects and no approval
    if s.get("sourcing") == "open_weights" and not s.get("model_scanned"):
        score += 1

    if score >= 5: return 1
    if score >= 3: return 2
    if score >= 1: return 3
    return 4

A usable policy is short, testable and tied to controls. The clauses below form a core you can adapt. Each uses "must" language that an auditor can check, and each names the control from Section 6 that enforces it.

This is the minimum control set behind the policy. Each control addresses a named attack class, and most map to deeper guidance elsewhere in this series.

Two areas outrun most governance programs: AI that nobody told you about, and AI that can act. Both need controls that work without waiting for a human to notice.

Employees adopt AI tools because they are useful, so a ban without an approved alternative mostly drives usage out of sight. Start with discovery, then offer a sanctioned option for the common cases. The sources that find the most are:

• Egress, proxy and DNS logs for traffic to AI provider domains
• OAuth and SaaS grants where an AI app has been given access to mail, files or chat
• Browser extensions that read page content and send it to AI services
• Source repositories and CI secrets containing AI provider API keys
• Expense and procurement data showing AI subscriptions

# shadow_ai_scan.py: summarize proxy-log traffic to known AI provider domains
import csv, collections

AI_DOMAINS = {
    "api.openai.com", "chatgpt.com", "api.anthropic.com", "claude.ai",
    "generativelanguage.googleapis.com", "gemini.google.com",
    "api.mistral.ai", "api.cohere.com", "huggingface.co",
}
SANCTIONED = {"api.anthropic.com"}      # replace with your approved, contracted services

def scan(log_csv: str):
    # expected columns: user, dest_host, bytes_out
    by_host = collections.defaultdict(lambda: {"users": set(), "bytes": 0})
    with open(log_csv, newline="") as f:
        for row in csv.DictReader(f):
            host = row["dest_host"].lower()
            if host in AI_DOMAINS:
                by_host[host]["users"].add(row["user"])
                by_host[host]["bytes"] += int(row["bytes_out"])
    for host, d in sorted(by_host.items(), key=lambda kv: -kv[1]["bytes"]):
        status = "sanctioned" if host in SANCTIONED else "REVIEW"
        print(f"{status:10} {host:40} users={len(d['users']):4} MB_out={d['bytes']/1e6:8.1f}")

# Feed REVIEW rows into the inventory intake: register, replace with a sanctioned tool, or block.

An agent that can call tools is a new kind of principal. Authorization should be decided outside the model, in code the model cannot rewrite, and every decision should be logged.

# agent_policy.py: deny-by-default authorization for agent tool calls
from dataclasses import dataclass
import json, time

READ, WRITE, IRREVERSIBLE = "read", "write", "irreversible"

@dataclass
class ToolPolicy:
    impact: str                  # read | write | irreversible
    needs_approval: bool
    max_calls_per_task: int

# Per-agent allowlist. Anything not listed is denied.
POLICIES = {
    "support-assistant": {
        "read_ticket":  ToolPolicy(READ,  False, 20),
        "draft_reply":  ToolPolicy(WRITE, False, 5),
        "send_reply":   ToolPolicy(IRREVERSIBLE, True, 1),
    }
}

def authorize(agent: str, tool: str, call_count: int, approved_by: str | None) -> bool:
    policy = POLICIES.get(agent, {}).get(tool)
    allowed, reason = False, "not_in_allowlist"
    if policy:
        if call_count >= policy.max_calls_per_task:
            reason = "rate_limit"
        elif policy.needs_approval and not approved_by:
            reason = "approval_required"
        else:
            allowed, reason = True, "ok"

    # Audit every decision, allowed or denied
    print(json.dumps({"ts": int(time.time()), "agent": agent, "tool": tool,
                      "allowed": allowed, "reason": reason, "approved_by": approved_by}))
    return allowed

# Note: approved_by must come from your approval system, never from model output.

Most enterprise AI exposure arrives through vendors: AI features added to existing SaaS, API model providers, and agencies using AI on your behalf. Standard security questionnaires miss the AI-specific questions below.

A governance program is credible when it can show numbers that move. Choose a small set that reflect control operation, not activity, and make each one reproducible from system data.

• The current inventory export and the discovery report it was reconciled against
• Risk assessments and approvals for a sample of tier 1 and tier 2 systems
• Registry records with hashes, scan results and approvers for models in production
• Red-team or adversarial test reports and the remediation tickets they created
• Agent approval logs and denied-call logs for a chosen period
• Incident records, post-incident reviews and the latest rollback drill
• The exception register with owners and expiry dates

Do not try to launch everything at once. The sequence below delivers visibility first, then enforcement, then assurance.