Adjacent Councils
Lessons from data governance, security champions, architecture review boards, and design governance.
The AI Council is not the first governance body organizations have had to stand up. Mature patterns from adjacent domains offer practical lessons.
Data Governance Councils
NCUA Charter Model
NCUA's data governance council charter defines purpose, guiding principles, responsibilities, membership, quarterly meetings, quorum, consensus, advisory roles, and chair responsibilities in clear, reusable language.
What to borrow:
- Charter structure and language
- Quorum and consensus rules
- Role definitions (chair, members, advisory)
Collibra's Role Stack
Collibra's data governance guidance defines a practical role stack: executive champion, convener, council members, and data stewards.
What to borrow:
- The "steward" pattern maps directly to AI champions
- Executive champion as a named, accountable sponsor
- Clear separation between convening and decision-making
Security Champions (OWASP)
OWASP Security Champions Guide
OWASP's guide is intentionally modular and recommends assigning a security champion in each development team with dedicated time, training, and periodic briefings.
OWASP SAMM
OWASP's Software Assurance Maturity Model recommends champions as liaison between central security and delivery teams.
What to borrow:
- Champion selection criteria and recruitment approach
- Dedicated time commitment (not just a side responsibility)
- Training and briefing cadence
- Community of practice model
Architecture Review Boards
AWS ARB Model
AWS argues that effective architecture review boards need:
- Executive sponsorship
- Cross-functional representation (security, architecture, development, infrastructure, operations)
- A single source of truth for guidance and policies
- A review-process shepherd embedded in delivery
Pennsylvania ARB
Pennsylvania's Architecture Review Board publishes templates, checklists, and forms alongside the board itself: not just principles, but the operational artifacts teams actually need.
What to borrow:
- The "shepherd" role, someone who guides teams through the review process (maps to the AI champion)
- Publishing artifacts alongside the board (the toolkit approach)
- Cross-functional representation as a requirement, not a nice-to-have
Design and UX Governance
US Web Design System (USWDS)
USWDS states that product decisions should start with real user needs and maintains a recurring usability research practice.
EU Communities of Practice Playbook
The EU playbook adds guidance on stakeholder mapping, co-created governance, and creating a risk-free environment that supports learning and innovation.
What to borrow:
- Start with affected people, not just compliance requirements
- Create psychological safety for teams to surface concerns early
- Governance should enable good outcomes, not just prevent bad ones
- Research and feedback loops keep governance grounded in reality
The Common Thread
Across all these adjacent domains, the pattern is the same:
- Central body sets policy and handles escalations
- Embedded champions connect governance to delivery
- Published artifacts (not just principles) make governance operational
- Tiered review prevents bottlenecks
- Continuous improvement keeps governance relevant