Governance by design: Turning AI policy into executable controls

Governance by design is the practice of encoding policy into build and runtime controls that enforce access, constrain actions, capture evidence, and measure drift. Here’s how to implement it for AI. Governance determines whether a generative AI program remains a set of pilots or becomes a durable capability. I treat governance as engineering work. The goal stays simple. The system should behave within policy, every day, under change. I define governance by design as the practice of encoding policy into build and runtime controls that enforce access, constrain actions, capture evidence, and measure drift. Policies become executable rules. Evidence becomes a byproduct of normal operation. Teams ship faster when governance runs as part of delivery. Enterprises already understand this pattern. Payment systems embed controls for fraud and chargebacks. Customer data platforms embed consent and retention. Generative AI needs the same approach because it touches data boundaries, produces content, and increasingly takes actions through tools. Adnan Masood Start with a threat model that reflects real usage A threat model is a short description of what can go wrong, who gets harmed, and where controls belong. I keep it concrete. I focus on the failures that appear in production. Data exposure through prompts, logs, or model outputs. Sensitive data can move across trust boundaries quickly. Prompt injection and indirect instruction. A user message or retrieved document can steer the system toward unsafe actions. Source integrity risk. Retrieval can surface outdated, incorrect, or tampered documents that look authoritative. Tool misuse. Agents and assistants can write to systems of record through APIs and workflow tools. Model and prompt drift. A system changes through model updates, prompt edits, and data refresh cycles. This threat model drives control placement. I avoid controls that live only in process steps. Runtime and CI controls reduce reliance on memory and manual review. Define governance primitives Governance primitives are the smallest pieces you can implement and reuse across use cases. I standardize them so teams do not reinvent controls. Identity context: Who asked, under which role, with which scopes. Data boundaries: Which sources the system can read, and which destinations it can write. Policy evaluation: Checks that run before retrieval, before tool calls, and before output. Lineage: Versions for prompts, models, indexes, and policies, plus trace IDs per request. Audit evidence: Structured logs that capture policy decisions, retrieved sources, and write actions. Teams can implement these primitives once in a platform layer. Product teams consume them through a simple interface. This approach scales across assistants, copilots, and agentic workflows. Adnan Masood Treat policy as code Policy as code means policies are expressed in a machine-readable format and executed automatically. Teams version policies, review them through pull requests, and deploy them through the same pipeline as application code. The runtime enforces the current policy version on each request. I ask for three categories of policy rules. Access rules for retrieval and tool calls. These rules bind requests to identity and scopes. Content rules for output. These rules cover restricted data, citations, and refusal behaviors. Action rules for tools. These rules constrain which tools run, which records can be changed, and which approvals apply. A policy module also needs observability. It should emit a decision record that includes the policy version, the rule triggered, and the effect on the request. Put governance into CI Continuous integration provides leverage. It catches regressions before users see them. I treat evaluation and policy checks as release gates for generative AI changes. The CI pipeline should run a small suite on every change to prompts, retrieval configuration, model routing, and policy rules. The suite includes unit checks, scenario tests, and safety checks. It produces a report that teams can act on. A simplified gate looks like this: stages: - eval - security - deploy eval: script: - run_retrieval_regression --suite core - run_answer_quality_eval --suite core artifacts: - eval_report.json rules: - fail_if: quality_score < 0.82 security: script: - run_prompt_injection_tests --suite redteam-lite - run_pii_leakage_checks --threshold 0 rules: - fail_if: any_violation Teams can start with lightweight gates and raise standards over time. The important point is ownership. Someone owns the suite. Someone owns the thresholds. Someone owns the remediation path. Enforce controls at runtime Runtime enforcement handles the conditions CI cannot simulate. It also supports audit and incident response. I look for four runtime controls in every production deployment. Request mediation that attaches identity and scopes to the request context, with redaction for logs. Retrieval filtering that enforces access control, source allowlists, and freshness constraints. Tool mediation that validates schemas, enforces allowlists, and writes audit events for actions. Output checks that enforce citation rules, restricted data rules, and safe rendering in the user interface. For agentic systems, tool mediation carries most of the weight. A tool call should pass through a router that enforces permissions, limits targets, and binds idempotency keys to prevent duplicate writes. Capture evidence as part of normal operation Audit evidence matters for security, compliance, and internal governance. I aim for evidence that arrives automatically. The system should generate an audit record on each request that includes policy version, model version, prompt version, index version, retrieved sources, tool calls, and final output metadata. I store this evidence in a system designed for restricted access and retention. It supports incident review and supports periodic reporting. It also supports evaluation work because a team can replay high-impact requests. Operate governance with feedback loops Governance improves through feedback. Teams learn from incidents, near misses, and evaluation regressions. I use a short cadence to review policy decisions and to adjust controls. Weekly review of policy blocks and high-severity tool call failures. Monthly review of evaluation drift and retrieval quality metrics. Quarterly red-team exercises on high-impact workflows, with tracked remediation. This cadence keeps policy grounded in how the system behaves, not in hypothetical risk lists. Minimum viable governance checklist I use this checklist when a team moves a generative AI system into broader production. Threat model written for the actual workflow and the data sources in scope. Policy module in source control with versioning, review, and deployment process. Evaluation gates in CI for quality regressions, injection tests, and restricted data checks. Runtime enforcement for identity, retrieval access control, tool mediation, and output checks. Lineage for model, prompt, policy, and index versions, tied to request traces. Audit evidence stored with controlled access and defined retention. Incident runbooks with disable switches for tools and a rollback plan for model and prompt changes. A responsible approach Governance-by-design works when it lives inside the delivery system. Teams benefit from the same outcomes that other mature services depend on: measurable controls, clear ownership, and repeatable release practices. This approach supports responsible operation and steady iteration at enterprise scale. — New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.