Writing an AI governance charter that survives an audit

• System name, vendor, purpose
• Data inputs (does it touch personal data, benefits eligibility, criminal records?)
• Decision impact: informational only, or does it affect a person's access to a service, benefit, or enforcement action?
• Risk tier: low (internal drafting aid), medium (decision supportdecision supportTechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → with human review), high (materially affects eligibility, benefits, policing, or hiring)

This mirrors the tiering logic in the EU AI Act (Regulation (EU) 2024/1689, entered into force August 2024), which bans certain uses outright and classifies systems used in law enforcement, migration, employment, and essential public services as "high-risk," triggering mandatory conformity assessments before deployment. US agencies increasingly use similar tiering voluntarily, referencing the White House Office of Management and Budget's OMB Memo M-24-10 (2024), which requires federal agencies to designate a Chief AI Officer and complete risk assessments for "safety-impacting" and "rights-impacting" AI use cases.

Charter clause language:

> "No AI system may move from pilot to production status without an entry in the AI System Inventory and an assigned risk tier, reviewed at minimum annually or upon material model update."

Core clause 2: named roles, not departments

The single most common audit finding is a responsibility vacuum. Fix it with named roles, not "the IT department":

• AI Accountable Official: signs off before deployment; personally answerable in an audit. In federal agencies this is often the Chief AI Officer role required under OMB M-24-10.
• Model Risk Reviewer: independent from the team that built or procured the system; checks for bias, data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.Voir la définition complète →, and drift (a model's accuracy degrading as real-world conditions change from its training data).
• Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Voir la définition complète →: confirms what data trained or feeds the system, and whether it includes protected categories requiring extra scrutiny under laws like the Fair Housing Act or Title VII, if the system touches housing or employment decisions.
• Public Records Officer: ensures documentation (see Clause 4) is retained per state and municipal public records law, since AI decision logs are increasingly deemed subject to public records requests (as several state courts have held regarding predictive policing tools).

Core clause 3: escalation path before and after deployment

Before deployment, define a mandatory hold point: any system scoring "medium" or "high" risk cannot go live without written sign-off from the Model Risk Reviewer and Accountable Official.

After deployment, define the incident ladder:

1. Frontline staff or citizen flags an anomaly (wrong benefit denial, biased flagging).

2. Logged within 48 hours to the Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Voir la définition complète →.

3. Model Risk Reviewer assesses within 5 business days: is this a one-off error or a systemic pattern?

4. If systemic, Accountable Official decides: suspend, patch, or retrain, with the decision documented and dated.

5. Any suspension affecting public-facing service triggers notice to the oversight body (city council committee, state legislature AI task force, or IG office, depending on jurisdiction).

This ladder is what an IG audit actually tests: not "did you have a policy" but "did you follow your own escalation path the last time something broke."

Core clause 4: documentation standards that hold up

Auditors want artifacts, not narratives. Minimum documentation per system:

Retention period should match your jurisdiction's public records law, typically the same schedule applied to the underlying government function (benefits records, procurement records, personnel records). This is not optional archiving; several city and state IG reports have specifically cited missing retention schedules as an audit failure, since incomplete records prevent reconstruction of how a contested decision was made.

Guardrails to run before any deployment

Before a system clears Clause 1's hold point, run these checks:

1. Bias and disparate impact test: compare outcomes across demographic groups where data allows, using established fairness metrics (e.g., demographic parity, equalized odds).

2. Data provenance check: confirm training and input data sources are lawfully obtained and appropriately scoped (no unauthorized personal data).

3. Human-in-the-loop confirmation: for any high-risk tier, a human must be able to review and override before the decision takes effect on a person, not after.

4. Vendor transparency check: does the contract give the agency audit rights over the model's logic and update history? Many procurement failures trace back to vendor contracts that block this.

5. Public notice check: does the jurisdiction require public disclosure of automated decision system use (as NYC's Local Law 144 requires for automated employment decision tools)?

What this looks like in practice

Picture a mid-size city deploying an AI tool to triage 311 service requests (non-emergency citizen complaints) by urgency. Under the charter: it enters the inventory as medium risk (it affects service order but not eligibility or rights). The Model Risk Reviewer tests it for neighborhood-level bias, since urgency scoring could systematically deprioritize lower-income areas. The Accountable Official signs off with a human dispatcher retaining override authority. Three months in, a council member's office flags a pattern: complaints from one district are consistently deprioritized. The incident ladder triggers, the pattern is confirmed, and the model is retrained with logged justification. When the city comptroller's office later audits the program, every step has a timestamp and a name attached.

🎬 [VIDEO: "How Government Agencies Are Regulating AI" - youtube.com - search for GAO or Brookings Institution explainers on federal AI oversight frameworks and agency accountability structures]

Key Takeaways

• A governance charter assigns named accountability and documented decision points; a policy statement of principles will not survive an audit.
• Tier every AI system by risk (low, medium, high) using a framework consistent with OMB M-24-10 (US federal) or the EU AI Act's risk categories (for jurisdictions referencing EU practice).
• Build a two-part escalation path: a pre-deployment hold point requiring sign-off, and a post-deployment incident ladder with fixed response timelines.
• Documentation must be artifact-based (logs, sign-offs, dated reviews) and retained per public records law, since these records are increasingly subject to open records requests and IG review.
• Test for bias, data provenancedata provenanceData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Voir la définition complète →, human override capability, and vendor audit rights before any system goes live, not after a complaint forces the question.