skills/magnus919_agent-skills
1
0
Fork 0
mirror of https://github.com/magnus919/agent-skills.git synced 2026-09-20 07:59:15 +03:00
Code Issues Packages Projects Releases Wiki Activity

feat(ai-governance): add governance charter and use-case intake templates

Browse Source 
Add fillable governance-charter.md (council terms of reference) and
use-case-intake-form.md (intake/registry entry with risk classification)
templates, each with an H1 title, purpose statement, guided fields with
placeholders, and completion instructions, aligned with the operating-model
and risk/lifecycle references.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
This commit is contained in:
Magnus Hedemark
2026-08-14 20:17:30 -04:00
co-authored by factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
parent 8520ce1b77
commit 452c061a7e
2 changed files with 199 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ai-governance/templates/governance-charter.md
+108
View File
@@ -0,0 +1,108 @@
# AI Governance Council Charter
> **Confidentiality:** A completed charter names accountable executives, decision rights, and escalation paths. Store it with access controls appropriate to governance and board-oversight information. This template instantiates the council terms of reference described in `references/governance-operating-model.md`.
## When To Use
Use this charter to stand up (or refresh) any AI governance body — an AI ethics council, an AI risk council, an enterprise AI committee, or a board-level technology committee. The operating model reference explains the tiered council structure; this template turns the council's purpose, membership, responsibilities, decision rights, cadence, and reporting lines into a written terms of reference. Complete it when the council is created and review it at least annually or whenever the operating model or risk profile changes.
## When Not To Use
Do not use this template as a substitute for an individual role's job description, and do not use it to assign operational work that belongs to stewards and functional owners. A charter governs how a body deliberates and decides; it is not a RACI for every task. Use `model-risk-assessment.md` for single-model reviews and `use-case-intake-form.md` for routing individual use cases.
## Charter Meta
| Field | Value |
|---|---|
| Council name | `<name, e.g. Enterprise AI Risk Council>` |
| Charter version | `<version, e.g. 1.0>` |
| Effective date | `<YYYY-MM-DD>` |
| Next review date | `<YYYY-MM-DD>` |
| Sponsor / accountable executive | `<name and role>` |
| Status | `<draft / ratified / amended>` |
## Purpose
State, in one to three sentences, why the council exists and what outcomes it is accountable for. Anchor it to a mission statement so every decision can be traced back to it.
- Council purpose: `<one-to-three-sentence statement of the mandate and the outcomes it owns>`
- What the council is accountable for: `<list the decisions, standards, and risk approvals it must own>`
- What the council must NOT decide alone: `<identify matters that require executive sign-off or board approval>`
## Membership
List the representative roles and named individuals. A cross-functional council should bring together legal, risk, compliance, privacy, security, data, product, and engineering. Note alternates so the body is never blocked by a single person's absence.
| Role | Representative | Alternates | Term / rotation |
|---|---|---|---|
| <council chair> | <name> | <name> | <term> |
| <legal / compliance> | <name> | <name> | <term> |
| <risk management> | <name> | <name> | <term> |
| <privacy / data protection> | <name> | <name> | <term> |
| <security> | <name> | <name> | <term> |
| <data / product / engineering> | <name> | <name> | <term> |
| <business unit / domain steward> | <name> | <name> | <term> |
- Quorum: `<minimum number or roles required for a valid meeting>`
- Decision method: `<consensus / majority / by chair with recorded dissent>`
## Responsibilities
List the standing duties of the council. Tie each duty to the stage of the AI life cycle or the risk framework where it bites.
- Set and maintain AI policy, standards, and principles: <duty details>
- Review and approve higher-risk AI use cases and their residual risk: <duty details>
- Own the risk register and ensure entries above threshold are escalated: <duty details>
- Review monitoring, incident, and drift signals and direct responses: <duty details>
- Oversee third-party and procured AI diligence: <duty details>
- Prepare aggregate risk reporting for the executive team and board: <duty details>
## Decision Rights And Escalation
Make explicit who the council can decide, who it must consult, who it must inform, and how disputes are raised. Reference the operating model's RACI so one person is accountable for each outcome.
| Matter | Decision right | Consulted | Informed | Escalation path |
|---|---|---|---|---|
| Approve low-risk use case | <who decides> | <roles> | <roles> | <path> |
| Approve medium-risk use case | <who decides> | <roles> | <roles> | <path> |
| Approve high-risk use case | <who decides> | <roles> | <roles> | <path> |
| Approve residual-risk exception | <who decides> | <roles> | <roles> | <path> |
| Declare material incident | <who decides> | <roles> | <roles> | <path> |
- Escalation trigger and path: <describe when a matter must be raised to the executive sponsor, CEO, or board>
- Dispute resolution: <describe how a deadlock or contested decision is resolved and recorded>
## Meeting Cadence And Operation
Define how often the council meets, what it reviews, and how members prepare. The operating model reference notes that councils need a regular cadence and ground rules for psychological safety so that honest discussion, including disagreement, is possible.
- Meeting frequency: <e.g. every other week, monthly, quarterly>
- Session length: <e.g. 60–90 minutes>
- Standing agenda items: <list recurring items, e.g. new use cases, risk register, incidents, metrics>
- Pre-read expectations: <describe what members review before the meeting>
- Ground rules for discussion: <state expectations for candid disagreement and psychological safety>
- Record keeping: <state where decisions, minutes, and dissents are recorded and retained>
## Reporting And Oversight
Describe how the council reports up (to the executive sponsor and board) and down (to stewards and operating owners), consistent with the board tier's "noses in, fingers out" oversight posture.
- Reports to: <executive sponsor, CEO, board committee — name them>
- Report cadence and contents: <what is reported, how often, and to whom>
- Material-incident briefing path: <how the board is briefed promptly on material incidents>
- Interactions with stewards and operating owners: <how decisions are communicated and enforced downstream>
## Effectiveness Review
Define how the council evaluates its own performance so the charter stays a living instrument, not a filed artifact.
- Review trigger: <annual / on operating-model change / on material incident>
- Effectiveness criteria: <list measurable criteria, e.g. decisions within SLA, incidents caught early, documented dissent>
- Success measures: <list the metrics the council watches and reports>
- Amendment process: <who can change the charter and how it is ratified>
## Completion
To complete and ratify this charter: fill every labeled field, confirm each named member and alternate, obtain sign-off from the accountable executive (and board sponsor where applicable), record the ratification date and version, and store the ratified copy in the shared governance location referenced by the operating model. Schedule the next review date before circulating the final version.
> **Synthesized from** `research-org-board-governance.md` and the ideas of *Designing Data Governance from the Ground Up* and the *Data Governance Handbook* (see `references/governance-operating-model.md`). Fillable artifact of the `ai-governance` skill.
ai-governance/templates/use-case-intake-form.md
+91
View File
@@ -0,0 +1,91 @@
# AI Use-Case Intake Form
> **Confidentiality:** A completed intake form describes data, decisions, and risk. Store it with access controls appropriate to the sensitivity of the use case. This template turns the earliest lifecycle gate and the risk-register entry described in `references/risk-management-and-frameworks.md` and `references/ai-lifecycle-governance.md` into a fillable form.
## When To Use
Use this form to open a governed lifecycle for any proposed or newly discovered AI use case — whether built in-house, procured from a vendor, or embedded in an inherited system. Completing it routes the use case into the risk register and to the correct depth of review before significant investment, model training, or deployment. Submit it at the intake stage; revisit it when the use case, data, or context changes materially.
## When Not To Use
Do not use this form as a substitute for a full single-model risk assessment. If the use case already exists and you are evaluating an individual model's residual risk, use `model-risk-assessment.md`. This form captures intent and initial classification; it does not replace monitoring, drift detection, or incident response after deployment.
## Use-Case Identity
| Field | Entry |
|---|---|
| Use-case name | <short descriptive name> |
| Use-case ID | <registry ID, e.g. UC-2026-014> |
| Submitted by | <name and role> |
| Submitted date | <YYYY-MM-DD> |
| Business unit / domain | <unit> |
| Status | <new / triaged / in review / approved / rejected / live / retired> |
## Purpose And Context
Describe what the use case does, who it serves, and why it is being built or adopted.
- Problem statement: <what problem the AI system addresses and for whom>
- Intended function: <what the system does, e.g. recommend, classify, generate, automate, decide>
- Users and affected parties: <who operates it and who is affected by its output>
- Expected benefit: <what value is expected, with a rough scale or metric>
- Alternatives considered: <non-AI or lower-risk alternatives and why they were set aside>
## Data And Inputs
Describe the data that trains and feeds the system. Sensitive, high-volume, or personal data raises the inherent risk and the controls required.
- Primary data sources: <data sets, systems, or vendors supplying data>
- Data sensitivity: <public / internal / confidential / personal / sensitive personal / regulated>
- Contains personal or special-category data: <yes/no — if yes, list the types>
- Data lineage and provenance: <where data comes from and how it is governed>
- Data quality and known limitations: <describe quality issues, gaps, or biases you are aware of>
- Retention and minimization: <how long data is kept and what is minimized>
## Autonomy And Decision Impact
Classify how much the system decides and how consequential its output is. This drives the tier.
- Level of autonomy: <human-in-the-loop / human-on-the-loop / fully automated>
- Decision type: <advisory / recommendation / direct action / automated decision>
- Decision impact: <informational / operational / financial / life- or liberty-affecting>
- Scale of exposure: <approximate users, transactions, or decisions affected per year>
- Opportunity for human override: <how and when a person can review or reverse the outcome>
## Initial Risk Classification
Record the inherent risk (with no controls applied) and any immediate risk considerations, aligned with the tiering discipline in `references/risk-management-and-frameworks.md`.
- Inherent risk tier: <low / medium / high — justify>
- Primary risk drivers: <list factors such as sensitive data, autonomy, decision impact, volume>
- Known biases or fairness concerns: <describe any identified bias or disparate-impact risk>
- Known security or integrity concerns: <prompt injection, data exposure, misuse, tooling, supply chain>
- Suggested review depth: <standard / enhanced / full assessment + tiering>
- Proposed controls to reach acceptable residual risk: <list candidate mitigations>
## Review Routing
Route the use case to the right level of review based on its tier, and record the decision.
| Routing field | Entry |
|---|---|
| Assigned reviewer / assessor | <name and role> |
| Review path | <steward only / AI council / board committee> |
| Required approvals | <who must sign off before development or deployment> |
| Escalation trigger | <what bumps the use case to a higher review tier> |
| Linked risk-register entry | <registry reference, if created> |
## Decisions And Next Steps
Record the outcome and the follow-up actions so the intake is closed out.
- Decision: <approved / approved with conditions / deferred / rejected / referred>
- Conditions or mitigations required: <list any conditions attached to approval>
- Next steps and owners: <describe the next actions, owners, and due dates>
- Re-review trigger: <what change would require the intake to be reopened>
## Completion
To complete this intake: fill every labeled field, confirm the submitted-by and business owner, perform the initial risk classification honestly (inherent risk first), route the form to the assigned reviewer through the path your operating model defines, record the decision and any conditions, and file the completed entry in the risk register as the source-of-record. Revisit the form whenever the use case, data, context, or risk tier changes materially.
> **Synthesized from** `research-standards.md` and `research-technical-controls.md` and the ideas of *Responsible AI in the Enterprise* and *Platform and Model Design for Responsible AI* (see `references/risk-management-and-frameworks.md` and `references/ai-lifecycle-governance.md`). Fillable artifact of the `ai-governance` skill.