Your AI Governance Policy Is a PDF. Your Prompt Has Never Read It.

Every organization running AI now has a governance framework it must answer to — and almost none of them are machine-readable. I'm proposing a jurisdiction-selectable AI governance policy layer for Drupal, and I'd like the design torn apart before I write the code.

By Joshua Fernandes — Axelerant

Ask a Drupal team how their AI features comply with the EU AI Act, and you will usually get one of three answers. The confident one: "Legal signed off on the policy." The honest one: "We put a line in the system prompt." The most common one: "…which framework?" All three describe the same gap. Governance frameworks live as PDFs, wiki pages, and legal memos. AI features live as prompts and API calls. Between the two, there is a human who is supposed to remember, at prompt-writing time, what the policy said — and a compliance review, months later, that has no evidence of whether they did. I maintain AI Empathy Evaluation, a Drupal module that benchmarks how AI systems handle high-stakes, ethically loaded decisions. It has the same gap, and worse: the sector-specific regulatory scoring in it today is a set of hardcoded PHP enums. Want to evaluate against India's guidance instead of a US healthcare framework? Write PHP. Want to add a framework that was published last quarter? Write PHP, and wait for a release. That is the wrong shape for something that changes as fast as AI regulation does. So I've opened a design proposal to fix it — issue #3608922 — and I'm publishing it before building it, because a data model is cheap to argue about and expensive to migrate. 

The observation that makes this tractable

Read enough AI governance frameworks side by side — the EU AI Act, the OECD AI Principles, the UNESCO Recommendation on the Ethics of Artificial Intelligence, the UN's work on AI, India's responsible-AI guidance, Singapore's Model AI Governance Framework, the UK's pro-innovation principles — and something becomes obvious. They disagree about enforcement. They disagree about scope, definitions, penalties, and who counts as a deployer. But they converge, remarkably tightly, on what they are asking you to care about:

human oversight · transparency · explainability · accountability · fairness and bias mitigation · privacy and data governance · security and robustness · risk management · auditability · human rights · sustainability · public trust · incident reporting · continuous monitoring

Fourteen themes. Nearly every framework is some weighting of those, expressed in that jurisdiction's language, with that jurisdiction's teeth. That convergence is the design opening. If the themes are shared and only the text and force differ, then a governance framework is data, not code. And data belongs in config entities, exportable YAML, and an admin UI — not in a PHP enum behind a release cycle. 

What I'm proposing

A jurisdiction-selectable governance policy layer, built on the pieces the Drupal AI ecosystem already has. 

1. A policy catalog you can edit

A new ai_empathy_governance_policy config entity. Each policy carries:

Defaults ship in config/install So a fresh install is useful immediately. But every policy is editable in the UI, exportable like any other config, and shippable as a policy pack — the same pattern the module already uses for domain scenario packs. A Canadian public-sector team can install the catalog, disable what doesn't apply, and add what does, without touching PHP. Note the type column. A treaty, a binding regulation, and a voluntary recommendation are not the same obligation, and a tool that flattens them into "policies" is lying to you. The catalog keeps the distinction visible.

2. Selection at two levels

A site-wide default — "we are an EU deployer, these apply to everything" — with per-scenario overrides stored as third-party settings. Because the healthcare triage scenario and the marketing copy scenario are not subject to the same obligations, even within the same organization.

3. Two activation paths, and you choose

This is the part I most want reviewed. (a) Via the Context Control Center. The ai_context module already exists to be the governed library of "rules and standards your AI actually reads," with scoping so the right context reaches the right interaction. AI Empathy already bridges to it for brand voice. So: a service formulates each active policy into a CCC context item under a new governance_policy scope, and it flows into prompts through infrastructure that is already governed, already scoped, already auditable. (b) Direct prompt injection. For sites that don't run CCC, append the selected guidance straight into the evaluation and scoring prompts. A site setting picks (a), (b), or both. Path (a) is the architecturally correct one. Path (b) is the one that gets adopted on a Tuesday afternoon. I'd rather ship both than be pure and unused.

4. A policy-alignment score

A PolicyAlignmentScorer service producing a policy_alignment metric (0–100) on every result, with a configurable threshold, surfaced on result pages and the dashboard alongside the existing metrics — decision accuracy, empathy alignment, explanation quality, consistency, and the trust and accountability dimensions the governance submodule adds. So the question stops being "did someone remember the policy?" and becomes "here is the score, per scenario, per model, over time, against a cited framework version." 

The thing I want to say out loud before anyone else does

This is not a compliance certification, and it must never be sold as one. An LLM scoring a response against policy text is a signal. It is a useful, repeatable, trendable signal that catches drift and gives your risk team something better than vibes. It is not a legal opinion, it is not an audit, and a green dashboard is not a defense. I think the labeling around this matters more than the scorer itself, and I'd genuinely welcome help getting the wording right. A governance tool that quietly encourages false confidence is worse than no tool — it does the one thing governance is supposed to prevent. 

Where I need the community

The issue is a Plan issue on purpose. Nothing is built. Everything is arguable. Specifically:

1. Is the catalog in the right module? I've scoped it to AI Empathy because that's where the hardcoded enums are, and that's what I maintain. But a governance policy catalog is obviously useful to any AI feature on a Drupal site, not just evaluation. Should this live upstream — in ai, in ai_context, or as its own ai_governance contrib module — with AI Empathy as one consumer? If you maintain something that would be used, say so on the issue. That single fact changes the architecture.
2. Is a 0–100 score honest? Or does policy_alignment need to be per-theme, so "strong on transparency, weak on human oversight" is visible instead of averaged into a comfortable 78?
3. Who keeps the catalog current? Frameworks move. The as_of field records when a policy text was true, but somebody has to update it. Is that a maintainer burden, a community-contributed pack per jurisdiction, or something we deliberately keep thin and defer to the site owner?
4. What jurisdictions and frameworks am I missing? The starting list reflects what I know. It is certainly incomplete, and the gaps are probably in exactly the regions least represented in this kind of tooling. If you work under a framework that isn't on the list, that comment is the single most valuable thing you can leave on the issue. Framework name, jurisdiction, source URL — that's enough. I'll do the rest.
5. Does the field model survive your real use case? If you have taken a Drupal site through an actual AI governance review, you know something the design doesn't. Tell me what it failed to capture.

Why open, and why now

This module exists because of three pieces of published research evaluating empathetic and accountable AI decision-making (IJFMR 2025, IJISRT 2026, IJSR 2026) — and each one improved because someone pushed back on it. The last major feature in this module, the Context Control Center integration, followed exactly that loop: build it in the open, share it, get told what was wrong, and end up filing two improvement issues against the platform it was built on. The integration is better for it, and so is ai_context. I'd like to run that loop again, one step earlier this time — at the data model, before the migration path exists. The issue is here: #3608922 — AI governance policy layer. Follow it, or better, disagree with it. 

Joshua Fernandes maintains AI Empathy Evaluation and works on AI systems on Drupal at Axelerant. Find him in the Drupal Slack #ai channel or at drupal.org/u/joshua1234511.