The gap

A bank’s board approves an AI policy. The policy is a slide deck. It says things like “AI systems must be fair,” “high-risk decisions must have human oversight,” “we will retain data only as long as necessary.”

The risk team takes the slides and tries to operationalise them. They produce a 200-page policy document. Engineering reads it once, files it, and goes back to shipping code. The code is what actually decides what the AI system does in production.

The gap between the slide deck and the code is the gap regulators worry about. It’s also where most “AI governance” programs live.

What closing the gap looks like

The board’s policy needs to be the configuration. Not a translation of the configuration. The actual configuration.

In Genie, this is config/ai-policy.example.yaml:

version: 2.0
board_approved_on: 2026-04-15
owner: Chief Risk Officer

sutras:
  - id: sutra-1
    name: Customer Centricity
    description: |
      AI is a tool to serve the customer, not the bank.
      ...

consumer:
  ai_disclosure_banner: |
    AI may participate in answering your questions. Decisions about
    your money are reviewed by humans. ...

risk_thresholds:
  high_risk_message_types:
    - payment_request
    - kyc_decide
    - loan_underwrite
  hitl_required_above_inr: 200000

rules:
  - id: kyc-edd-trigger
    when: classification == "high" AND amount > 500000
    decision: deny_with_review
    reason: enhanced due diligence required

The risk team edits this YAML. Engineering doesn’t translate it; the code reads it directly. A board approval is a YAML change with a board_approved_on: <date> annotation.

What this changes about audit

Auditor’s question: “How does your system enforce the EDD trigger?”

Old answer: “It’s in the requirements document; engineering implemented it in code we’ll show you.”

New answer: “Here’s the rule: config/ai-policy.example.yaml line 47. Here’s the test that verifies the system honours it: pkg/policy/dsl/rules_test.go::TestEDDTriggerFires. Here’s the audit log entry every time the rule fires: query Postgres audit_log where action='policy.deny' AND details.rule='kyc-edd-trigger'.”

Three steps; all verifiable; all reproducible.

What this changes about board approval

The board approves a YAML PR. The PR’s diff is the change. The board’s approval is recorded as the merge.

Risk team workflow:

1. Risk team drafts a rule (YAML edit).
2. PR opened, automated tests run (verify the rule parses, doesn’t conflict with existing).
3. Compliance reviews; engineering reviews; board reviews.
4. Merged with board_approved_on annotation.
5. Deployed; the system enforces from the next restart.

Versioning, history, accountability — all in git.

The pushback

“Boards don’t review YAML.”

True. Boards review a summary of the YAML. The summary is generated from the YAML automatically — what’s changed, what rules now apply, what thresholds moved. The board’s signature is on the summary; the YAML is the artefact the summary describes.

For Genie’s pattern, the summary tool is cmd/policy-summary — runs against the YAML, produces a human-readable diff document, signed and timestamped. Board sees the document; the document references the YAML; both ship together.

What this rules out

The “the policy exists in PowerPoint and we’ll get to it” mode. If the policy isn’t operational (configurable, verifiable, version-controlled), it isn’t policy — it’s intent.

For regulated AI specifically, this matters because the regulator’s question is always “show me.” A slide deck is hard to show. A YAML file plus a test suite plus an audit log is easy.

The board’s policy is the configuration. If they’re not the same file, you haven’t closed the gap.