AI GRC is the operating system that connects AI governance, risk management, and compliance. A useful program does not begin with a policy document or a new committee. It begins with a complete inventory, risk tiers, named decision owners, testable controls, evidence, an exception path, and a board cadence that ends in decisions. Ethical AI establishes what the organization should protect. Responsible AI assigns accountability. AI GRC makes both repeatable and auditable.

I work with C-level customers on AI and cybersecurity almost every business day. The most common failure is not a lack of concern. It is that concern is distributed across legal, security, technology, data, audit, procurement, and the business while authority is assigned to no one. Everyone owns a piece, so nobody can answer the board’s simplest question: who can approve, stop, or accept the risk of this system?

Why AI GRC programs stall

Many organizations start with principles: fairness, transparency, privacy, safety, accountability, and human oversight. Those principles are necessary and insufficient. They describe the destination without assigning the route.

The second common starting point is a framework crosswalk. A team maps NIST AI RMF, ISO/IEC 42001, the EU AI Act, sector requirements, and internal policies into a large control library. That work can be valuable, but it often produces hundreds of rows before the organization has answered which AI systems exist or who owns them.

The third failure is treating AI GRC as an approval gate at launch. AI systems change through new models, prompts, retrieval sources, tools, permissions, users, and data. A one-time review cannot govern a moving system. The EU AI Act’s risk-management requirements for high-risk systems describe a continuous, iterative lifecycle process. NIST’s AI RMF likewise frames AI risk management across design, development, use, and evaluation rather than as a single compliance event.

The six parts of a board-ready AI GRC operating model

1. Inventory the system, not just the model

The inventory record should identify the business purpose, owner, affected people, model and version, data sources, retrieval repositories, tools, integrations, agent harness, permissions, decision impact, geographic scope, vendors, and planned review date.

A model registry alone is too narrow. Two applications can use the same model and carry completely different risk because one drafts internal notes while the other changes a customer record or recommends a hiring decision.

2. Assign a risk tier based on impact and authority

Risk tiering should consider consequence, autonomy, reversibility, sensitivity, scale, vulnerable populations, and the ability of an affected person to understand or challenge the outcome. Those factors are more useful than novelty. A modest model used in a consequential workflow may deserve more oversight than a powerful model confined to a sandbox.

The tier should determine minimum requirements: review depth, testing, human approval, monitoring, documentation, reassessment cadence, incident reporting, and executive acceptance. If the tier does not change what the organization must do, it is only a label.

3. Name decision owners and authority limits

Each material system needs a business owner accountable for the outcome, a technical owner accountable for operation, a risk owner accountable for the accepted exposure, and a person with authority to pause or stop the system. Committees can advise those owners. A committee cannot absorb individual accountability.

Write the authority boundary in operational language. The system may draft but not send. It may recommend but not approve. It may approve below a defined threshold but must escalate above it. It may read a repository but not modify or delete. These statements become harness permissions, guardrails, approval gates, and tests.

4. Convert principles and obligations into controls

Every control should have five fields: the risk or obligation it addresses, the mechanism, the owner, the test, and the evidence. “Human oversight exists” is not a control. “A licensed reviewer must approve every denial recommendation before the customer receives a decision, and the approval record is retained for seven years” is closer to one.

Controls should cover data governance, model provenance, evaluation, transparency, privacy, security, bias and harm testing, output quality, agent identity, tool permissions, human intervention, logging, incident response, vendor change, and decommissioning. The right depth depends on the risk tier.

5. Build an evidence chain

Boards, auditors, regulators, customers, and incident responders need evidence, not reassurance. The evidence set may include inventory records, impact assessments, test results, red-team findings, data lineage, model documentation, approval records, tool logs, exception decisions, monitoring thresholds, incidents, remediation, and version history.

The strongest design produces evidence as a byproduct of normal operation. The harness records tool calls and approvals. The deployment pipeline retains evaluation results. The exception workflow captures the decision owner and expiration date. Manual screenshots assembled before an audit are a warning that the operating model is not yet durable.

6. Operate exceptions, incidents, and review

A mature AI GRC program expects exceptions. It requires a business justification, compensating control, decision owner, expiration date, and review. Permanent exceptions are usually undocumented changes to policy.

AI incidents should join the existing incident-response discipline while preserving AI-specific evidence: prompts, retrieved context, model and version, tool invocations, approvals, system actions, affected people, and the ability to reproduce or explain the event. The stop authority and communication path must be agreed before the system is in trouble.

How NIST AI RMF and the EU AI Act fit

NIST’s AI Risk Management Framework is intended for voluntary use and to help organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems. Its value is not as a badge. It is as a common language for governing, mapping, measuring, and managing risk.

The EU AI Act adds legal obligations that depend on role and risk classification. For high-risk systems, the consolidated text requires a documented and maintained risk-management system operating throughout the lifecycle, with testing against defined metrics and thresholds. The practical lesson is that evidence and lifecycle change control must be designed into the program.

OpenAI’s September 2026 policy statement also argued for independent assessments, AI-auditor accountability, monitoring, disclosure, and mandatory safeguards for the most capable systems. The direction of travel is clear even when jurisdictions differ: organizations will be expected to know what their systems can do, monitor them, preserve evidence, and act when controls fail.

The board dashboard should end in a decision

A useful quarterly AI GRC view fits on one page. It shows the number of material systems by risk tier; systems operating under exceptions; overdue reassessments; critical control failures; significant incidents and near misses; expansion of agent permissions; and decisions management needs from the board.

A dashboard that reports only training completion and policy publication is measuring activity. A board needs exposure, control effectiveness, change, and ownership. The central question is not “Do we have an AI policy?” It is “Which consequential AI authority changed this quarter, and what evidence says the organization can still control it?”

A 30-day starting plan

  1. Week one: identify the ten AI systems with the greatest combination of impact, autonomy, data sensitivity, and scale.
  2. Week two: assign business, technical, and risk owners; document what each system may recommend, approve, and execute.
  3. Week three: select the five controls whose failure would create the largest consequence, then define tests and evidence for each.
  4. Week four: run one executive review that ends with explicit decisions on exceptions, remediation, stop authority, and the next expansion of AI permissions.

This is intentionally smaller than an enterprise-wide framework rollout. It creates a working governance loop before the organization spends months building a taxonomy nobody has operated.

The frontline principle

The C-level conversations I have almost every business day reinforce one principle: AI governance becomes real only when it changes an operational decision. A policy that does not change permission, testing, evidence, escalation, or authority is communications material.

My forthcoming book, Think Bigger. Spend Once., makes the same argument from a broader business perspective. Durable architecture around the model matters more than a collection of short-lived fixes. In AI GRC, that durable architecture is the operating chassis of owners, controls, tests, records, decision rights, and human authority.

Primary sources and further reading

Need to turn AI principles into an executive operating model? Check Mark Lynd’s availability for an AI governance keynote, board briefing, or leadership session designed around the decisions your organization must make next.