Introduction

AI governance connects an organization’s decisions about AI with the people accountable for them, the controls used to manage risk, and the records that show what happened. It applies to systems an organization develops and to systems it buys, configures or uses through a supplier.

The aim is not to collect policies for their own sake. It is to make a practical decision explainable: what the system is intended to do, where it may fail, who may be affected, which requirements apply, and who can approve, change or stop its use.

How this edition is different

The September edition replaces the May edition’s provisional or superseded descriptions where newer primary sources establish the position. In particular:

• The EU AI Act chapter distinguishes the adopted 2026 amendment, its substantive changes and separate transition dates. A delayed high-risk provision does not postpone every AI-related duty.
• The US state chapter replaces the former Colorado framework and includes New York RAISE. It separates ordinary AI use from duties that apply only to particular developers, deployments or decisions.
• The federal chapter distinguishes statutes, executive direction, agency procurement/use rules and voluntary NIST guidance. An executive order is not a blanket repeal of state law.

• The ISO chapter distinguishes management-system requirements, risk guidance, impact-assessment guidance and requirements for certification bodies. Certification is not proof that every system is safe or lawful.
• Copyright & IP separates the specific issues decided in selected cases from broader questions that remain fact-dependent or unresolved.

These are selected corrections and updates, not a claim that this publication covers every development. The source guide and each chapter’s citations are part of the reading, not optional supporting decoration.

Five questions to answer first

1. What is the actual system and use? Record its intended purpose, users, affected people, data, outputs and decision process. A vendor’s generic product description is not enough.
2. What role does the organization perform? Developer, provider, deployer, employer, service provider and public authority are not interchangeable categories. Legal definitions differ.
3. Where does the activity occur or have relevant effects? Consider the provision’s territorial and subject-matter scope instead of assuming a single headquarters address settles applicability.
4. What evidence is available? Separate a claim, a contract promise, a test result and an operating record. Document material limitations and unanswered questions.
5. Who owns the decision? Name the person who can approve, restrict, escalate or stop the use. Set a review trigger when the system, purpose, data or legal position changes.

How to use the chapters

For a specific question, use the chapter map rather than reading every page first. Start with the relevant legal scope, then connect it to data/security controls and technical evaluation. The role guide turns those topics into responsibilities.

For program planning, use the six maturity frameworks as discussion prompts. They are illustrative, author-created descriptions—not a validated score, an industry benchmark, or a route to a guaranteed certification. Evidence can be uneven across dimensions, and a higher numbered stage is not necessarily the right next investment for every organization.

For a deeper employment or board question, follow the related Techné AI briefings. The handbook explains the landscape; the paid libraries offer separate working-document collections. Reading or downloading this free publication does not grant access to those libraries.

Keep different kinds of statements separate

Law: identify the provision, covered role, operative date, exceptions and enforcement context. Guidance: identify who issued it and whether it is voluntary or incorporated into a particular obligation. A recommended practice: identify the problem it is intended to address and test whether it works in the actual setting. An example or forecast: do not present it as a requirement or a measured result.

A useful governance record makes these distinctions visible. It also records uncertainty rather than silently turning an unanswered question into a favorable conclusion.

Looking forward

Build a process that can absorb change: maintain a system inventory, keep a source and decision log, name review owners, and define escalation and re-evaluation triggers. Revisit material changes in models, data, suppliers, users and law.

Those practices support better decisions; they do not eliminate risk or establish compliance by themselves. The practical test is whether people can use the record to understand, challenge and revise an actual AI decision.