Building an AI governance framework: from policy to guardrails to audit

An insurance company had a 40-page AI governance framework. The deck was thorough: clear taxonomy, proper citations to international standards. But last week, one of their representatives pasted a customer's complete medical history into a public chatbot. The framework didn't catch it. Which policy in those 40 pages would have stopped it?

It wasn't governance. It was documentation.

Companies commonly treat AI governance as a writing exercise: compliance writes the policy, files it, and then the work continues unchanged. A functioning governance framework is different. It has three parts working together: policy that defines what should and shouldn't happen, guardrails that enforce those rules as they execute, and audit that reconstructs what happened. Leave out any one of these and you have documentation, not governance.

Policy: what should and shouldn't happen

Policy forms the foundation, but most policies fail at one point: they're too vague. 'Employees should use AI carefully and protect company secrets' doesn't tell you what to do. It won't work.

A workable policy takes shape this way. Start by classifying data: public, internal, confidential, regulated (PII, health records, financial transactions). Assign each tier rules about which models it can reach. Then classify uses: internal draft assistance, customer-facing communication, decisions involving money or health. As the risk rises, require more human review. Finally, bind each rule to something observable and testable. Example: regulated data cannot go to external models without a signed DPA. An engineer can code that into a block. Audit can verify it.

There's a tradeoff. Detail makes policy safer, but length means fewer people read it. Keep the core rules to one page. Move detailed mechanics to the guardrails layer, where they're enforced anyway. Don't bury them in 50 pages that everyone signs and ignores.

Guardrails: how to enforce

Guardrails enforce policy through technical systems. They're the layer most often skipped because they require engineering work. When policy says confidential data shouldn't leak, guardrails mean the system detects and blocks regulated data the moment someone pastes it into a field. It doesn't wait months to appear in an audit report.

Guardrails sit at several points. Input detection masks PII and blocks DLP violations. Model routing, informed by data classification, directs sensitive data to private deployments. Output filtering removes sensitive content and flags hallucinations. Permissions layer keeps role boundaries strict: customer service operates within its scope, interns don't touch production systems.

For the insurance company, the solution wasn't to rewrite the 40-page deck. Input masking and external model blocking went into the customer service workflow. Within two weeks, the system had blocked eleven instances of PII that would have gone completely unnoticed. Guardrails prevent the problem. Audit documents it.

Audit: how to trace decisions

When a regulator or customer asks why your AI recommended something specific, you need to reconstruct the reasoning. Audit creates that traceability.

Keep logs of who used it, when, which model, inputs and outputs, and which guardrails fired. These must be immutable with retention matching your regulations. Logging is necessary but not sufficient. Review high-risk decisions monthly, replay them, check each block and bypass attempt. The point isn't finding fault. It's collecting real data to improve policy and guardrails. Governance is a continuous process.

Three layers at a glance

Rolling it out

A common approach is attempting to govern all AI systems at once. This leads to months of planning meetings.

Start with your highest-risk workflow currently in use (usually customer service or a knowledge system). Build all three layers for it, but narrow the scope: policy covers only this scenario's core rules, guardrails block only the biggest risks here, audit logs only this scenario. Run for a month. Use the actual block data to improve policy. Then add the next workflow. Governance systems grow through practice, not planning.

Tenten's approach to building FDE systems puts engineers directly in customer environments. They wire all three layers into production code rather than handing over a standalone framework. Demos generate agreement, but whether governance actually blocks violations in production is only visible to people doing the work on-site.