A subcontractor on one of the firm's hospital jobs used an AI tool to draft a delay-claim narrative, pulled the contemporaneous records the model assembled, and the package went to the owner under the firm's letterhead. It cited a daily report that did not exist and a weather event off by two days, the owner's counsel caught both, and the claim's credibility was gone before the merits were ever argued. When the principal asked who had approved using AI on a live claim package, the answer was nobody: no one had said yes, and no one had said no, so a project engineer made the call alone at 6pm on a deadline. That is the expensive moment governance exists to prevent. Not a policy violation, because there was no policy, but a decision that nobody owned, made under pressure, on a deliverable with real contractual consequence. This lesson builds the firm's AI governance structure: the committee, the decision rights that say who approves which use cases, the standing agenda that keeps the structure alive between incidents, the sign-off authority, and the relationship to the safety and risk committees the firm already runs, ending in the named artifact you will produce, the firm's AI governance committee charter.

Governance Is Decision Rights, Not a Document

The instinct when a firm gets serious about AI is to write a policy, a long document that lists the rules, gets circulated, acknowledged, and filed. The policy matters, but it is not governance. Governance answers a simpler and harder question: when a project engineer wants to use AI on a deliverable nobody anticipated, who decides whether that is allowed, and who signs off on the output before it leaves the firm. The hospital claim went wrong not because a rule was broken but because no one held the decision right. Governance is the assignment of decision rights, the explicit, named answer to who approves what, and a document that does not assign decision rights is a wish list.

Think of governance the way the firm already thinks about its signature authority matrix. The firm does not let any project engineer sign a $400K change order; there is a schedule that says a PM can authorize up to a threshold, a VP above that, an officer above that, and certain instruments require two signatures. Nobody experiences that matrix as bureaucracy, because everyone understands that a binding commitment to an owner needs an owner inside the firm. AI governance is the same idea applied to a new class of decision: which AI use cases are pre-approved, which require committee review, which are prohibited, and who signs off on AI-touched output at each tier. The controlling analogy for this lesson is the signature authority matrix, a schedule of who can commit the firm to what, extended to cover the firm's use of AI.

Decision rights matter more than rules because the rules cannot anticipate every case, and the cases that hurt are the ones the rules did not name. The claim narrative was on no one's list of approved or prohibited uses because no one had imagined it. Governance needs not a complete list of every permitted use, which is impossible, but a clear answer to who decides when a new use appears, so the answer is never nobody. The structure exists to make sure that for any AI use, someone with the authority to say yes or no has actually said it, and that the output about to be sent carries a sign-off from a person accountable for it.

Who Approves Which Use Cases: The Tiered Approval Model

The core of the charter is the tiered approval model, the schedule that maps classes of AI use to the level of approval they require. A flat rule, all AI use must be approved by the committee, is unworkable because it would route a project engineer's request to summarize a meeting transcript through the same gate as a decision to let AI route medical-gas mains, and the committee would either drown or be ignored. The tiers sort uses by consequence, the same way the signature matrix sorts commitments by dollar amount, so that low-consequence uses are pre-approved and high-consequence uses get real scrutiny.

A workable model has three tiers. Tier 1, pre-approved uses, covers low-consequence internal work where AI assists and a human reviews before anything leaves the firm: drafting internal meeting notes, summarizing a document the user already has rights to, first-pass formatting. These need no case-by-case approval; the policy approves the class, and the user verifies the output. Tier 2, use-with-verification-gate, covers the work that touches a deliverable or a contractual instrument and rides on one of the program's five verification gates: AI-drafted RFIs and ASIs (contract authority gate), AI-assisted takeoffs and CORs (dollars gate), AI-drafted code narratives (code gate, with the licensed professional owning the interpretation), AI-generated pre-task plans (life-safety gate). These are approved as classes but only under a named verification gate and a named human owner who signs off. Tier 3, committee-review-required, covers the uses that change the firm's risk posture: any AI use on a stamped or sealed deliverable, AI that touches owner-confidential or NDA-protected data, AI on a live claim or dispute package, AI in subcontractor selection where bias is a documented exposure, and any new tool not on the approved list. These do not happen until the committee has reviewed and authorized them.

The tier that would have caught the hospital claim is Tier 3: a live claim package is exactly the kind of high-consequence, dispute-adjacent use that should never have proceeded without committee review. The point of the model is not to slow the firm down but to make the routing automatic, so a project engineer facing a novel use does not have to guess. The tier tells them: this is pre-approved, go; this needs a verification gate and a sign-off, use it; this needs the committee, stop and route it. The model turns the impossible question of every possible AI use into a tractable one of which of three boxes it falls into, defined by consequence, the same logic the firm already trusts in its signature authority.

Sign-Off Authority: Who Stamps the AI-Touched Deliverable

Approval and sign-off are two different decisions, and the charter must separate them. Approval is the committee's act, deciding a class of AI use is allowed. Sign-off is the act of the named person who verifies a specific output and takes accountability for it before it leaves the firm. The committee approves the category; an individual signs the instance. Conflating the two is how the hospital claim happened: the project engineer believed that if AI was generally permitted, any specific output was implicitly blessed, and no one had told them the output still needed a named owner to sign it.

Sign-off authority follows the existing professional structure, because the firm cannot invent a parallel accountability hierarchy for AI. On a stamped sheet, the licensed professional is the only sign-off, full stop; AI does not change who holds the seal, and the program's cardinal rule, verify before it touches a stamp, is the sign-off rule made concrete. On an RFI or a notice, the sign-off is the PM or PE who owns the contractual instrument under the prime contract. On a COR, the sign-off is the estimator who owns the priced claim. On a pre-task plan, the sign-off is the competent person under OSHA 1926. The governance charter does not create new signers; it names, for each tier and each deliverable type, who the existing accountable person is and requires their explicit sign-off on the AI-touched output, recorded in the firm's AI-touched-deliverable register that the L1 and L2 lessons established.

The register is what makes sign-off real rather than aspirational. A sign-off that lives only in someone's memory is no sign-off, because when the owner's counsel asks who verified the claim narrative, the answer has to be a name and a date in a record, not a shrug. The charter requires every Tier 2 and Tier 3 AI-touched deliverable to carry an entry: the tool used, the human who verified it, the gate applied, and the date. This is the documentation discipline of responsible charge, the same standard the EOR has always met, extended to AI, and it protects the firm when a deliverable is challenged, because it turns who approved this from an unanswerable question into a record.

The Standing Agenda: Keeping Governance Alive Between Incidents

A governance committee that meets once, writes a charter, and disbands has not built governance; it has built a binder. Governance is a living function, and what keeps it alive is a standing agenda on a fixed cadence, because the risks and the tools both move faster than an annual review can track. A committee that meets monthly with a predictable agenda catches the drift, the new tool a team quietly adopted, the use case creeping from Tier 1 to Tier 3 without anyone noticing, the incident that needs review before it becomes a claim.

A durable standing agenda has five recurring items. First, incident review: any AI-related near-miss or failure since the last meeting, what happened, what gate failed, what changes. The hospital claim, in a firm with this agenda, becomes an incident-review item that produces a tier reclassification, not a one-off disaster that everyone forgets. Second, use-case requests: the Tier 3 requests queued since the last meeting, reviewed and approved, conditioned, or denied, so that the committee is the named decider and the queue does not stall the work. Third, tool and vendor changes: new tools requested, version changes with new capabilities, vendor terms that shifted, tying to the diligence work of the vendor-selection lessons. Fourth, register and metrics review: a look at the AI-touched-deliverable register and the adoption and verification metrics, so the committee governs by evidence rather than anecdote. Fifth, policy and risk-register update: changes to the tiered model and to the firm's AI risk register, the prior lesson's artifact, which this committee owns and updates.

The cadence matters as much as the agenda. Monthly is the right rhythm for most firms, frequent enough to catch drift before it becomes exposure, infrequent enough that the committee is not a standing meeting nobody respects. The standing agenda converts governance from an event into a function, and the function is the difference between a firm that learns from the hospital claim and one that repeats it, because the agenda guarantees that incidents are reviewed, requests decided, tools tracked, and the policy kept current, on a rhythm that does not depend on a crisis to convene.

Governance is the firm's signature authority matrix extended to AI: a named committee holds the decision rights, a tiered model routes each use by consequence, and a named accountable person signs off on every AI-touched deliverable, all kept alive by a standing monthly agenda rather than a binder that was written once.

The Relationship to Safety and Risk: Do Not Build a Parallel Silo

The most common and most expensive governance mistake is standing up the AI committee as a freestanding body with no connection to the committees the firm already runs. Every established firm already has a risk committee and a safety committee, and AI risk is not a separate species that needs its own kingdom; it is a new vector inside the risks those committees already own. AI on a pay app is a financial and contractual risk the risk committee already governs. AI on a pre-task plan is a life-safety matter the safety committee already owns. A parallel AI silo creates two failures: it duplicates existing governance with worse expertise, and it lets AI risk fall between the committees because each assumes the other has it.

The charter therefore defines the AI committee as a coordinating body that reports into and feeds the existing committees, not a replacement for them. The AI committee owns the AI-specific decisions, the tiered model, the tool approvals, the AI-touched-deliverable register, but routes the consequences into the standing committees through named liaison seats. AI-related safety matters, the verification of AI-generated pre-task plans, the life-safety gate, flow to the safety committee through a shared member. AI-related contractual, financial, and insurance matters flow to the risk committee, which already owns the firm's professional liability, indemnity posture, and the claims exposure the next lesson on insurance and AI disclosure develops. The AI committee's risk register is a feed into the enterprise risk register, not a competing document.

The membership reflects this integration. The committee is not an IT committee and not a panel of enthusiasts; it is cross-functional by design, with a named executive sponsor who can commit the firm, an operations leader who owns the deliverable workflows, a licensed professional (the AOR or EOR voice on stamp and seal accountability), a risk or legal seat tied to the risk committee, a safety seat tied to the safety committee, and an IT or data seat for the tooling and security diligence. The point is that every decision right the committee holds has, in the room, the person who would own its consequence elsewhere in the firm, which keeps the AI committee from becoming a silo. Governance integrates; it does not duplicate.

Operationalizing the Risk Register and the Verification Gates

This committee does not invent the firm's risk thinking; it operationalizes the work the prior lessons produced. The previous lesson built the firm's AI risk register, the catalog of where AI can hurt the firm: stamped work, contract authority, IP and data, bias, vendor failure, hallucination, cybersecurity, OSHA implications. A register written and shelved is as dead as a policy nobody enforces. The governance committee owns the register, keeps it current on the standing agenda, and turns each named risk into a tier rule, a sign-off requirement, or a prohibited use. The register names the danger; the committee converts it into a decision rule and an owner.

The same is true of the program's five verification gates, the design-intent, code, contract-authority, dollars, and life-safety gates that have run through the entire program. The gates are the practitioner's discipline, what a PE or an estimator applies at their desk. Governance makes them firm policy rather than personal habit by writing into the charter that Tier 2 uses are permitted only under their named gate with a named sign-off, so the gate stops being something a conscientious individual happens to do and becomes something the firm requires and records. The committee operationalizes the risk register into the tiered model and the gates into firm policy, the bridge from the individual discipline the program taught to the institutional governance the firm now needs.

This is also where governance becomes the G of the readiness audit made real. The readiness-audit lesson scored the firm across five dimensions, data, tooling, workflow, people, and governance, and governance asked whether anyone owned the AI decisions. The charter this lesson produces moves the firm from a low governance score to a high one: not a claim that the firm is responsible, but the named committee, the decision rights, the sign-off discipline, and the standing agenda that prove it. Governance was the audit's weakest dimension for most firms because it cannot be bought as a tool; it has to be built as a structure, and the charter is that structure written down.

The Applied Problem: Design the Firm's AI Governance Committee Charter

Here is the exercise. Draft the firm's AI governance committee charter, the single document that assigns the decision rights and brings the governance structure to life, in five parts, each tracing to a section of this lesson. First, the membership: name the seats, executive sponsor, operations leader, licensed professional, risk or legal seat, safety seat, IT or data seat, and for each the consequence they own elsewhere in the firm, so the membership is integration by design rather than a panel of enthusiasts. Second, the decision rights and tiered approval model: define Tier 1 pre-approved, Tier 2 use-with-verification-gate, and Tier 3 committee-review-required, and place at least three real uses from your firm in each tier, including the one novel use that nobody currently owns.

Third, the sign-off authority: for each deliverable type your firm produces, name the existing accountable person who signs the AI-touched output, confirming that stamped work keeps the licensed professional as the only sign-off, and tie the sign-off to an entry in the AI-touched-deliverable register. Fourth, the standing agenda and cadence: write the five recurring items, incident review, use-case requests, tool and vendor changes, register and metrics review, policy and risk-register update, and set the meeting rhythm, monthly for most firms. Fifth, the relationship to the safety and risk committees: define the liaison seats and the reporting lines that route AI safety matters to the safety committee and AI contractual, financial, and insurance matters to the risk committee, and state explicitly that the AI risk register feeds the enterprise risk register rather than competing with it.

The deliverable is the AI governance committee charter, and the test of whether it works is the hospital claim: walk that scenario through your charter and confirm that a live claim package lands in Tier 3, routes to the committee, and cannot proceed without review, and that any AI output that did proceed would carry a named sign-off and a register entry. A charter that would have caught the claim governs; one that would have let it through is a binder. The lasting product is a governance structure that answers, for any AI use the firm encounters, the question the hospital claim left unanswered: who approved this, and who signed it, with the answer always a name and a date rather than nobody, because governance is the firm's signature authority extended to AI and the named committee that holds it.

Key Takeaways

• Governance is decision rights, not a document. The expensive failures happen not because a rule was broken but because no one held the decision right, so a deliverable went out that nobody had approved or signed; the charter's job is to make the answer to who decides never be nobody.
• The controlling analogy is the signature authority matrix. The firm already trusts a schedule of who can commit it to what by dollar amount; AI governance is that same schedule extended to a new class of decision, which is why it reads as discipline rather than bureaucracy.
• The tiered approval model routes uses by consequence. Tier 1 pre-approved (low-consequence internal work), Tier 2 use-with-verification-gate (deliverables under a named gate and sign-off), and Tier 3 committee-review-required (stamped work, confidential data, live claims, bias-exposed selection, new tools); the tier tells a practitioner facing a novel use whether to go, gate-and-sign, or stop and route.
• Approval and sign-off are different decisions. The committee approves a class of use; a named accountable person signs the specific output and records it in the AI-touched-deliverable register. Stamped work keeps the licensed professional as the only sign-off, because AI never changes who holds the seal.
• The standing agenda keeps governance alive. Five recurring monthly items, incident review, use-case requests, tool and vendor changes, register and metrics review, and policy and risk-register update, convert governance from a one-time event into a living function that catches drift before it becomes exposure.
• Do not build a parallel silo. AI risk is a new vector inside the risks the firm's safety and risk committees already own, so the AI committee coordinates and feeds those bodies through liaison seats rather than replacing them; its risk register is a feed into the enterprise risk register, not a competitor.
• The committee operationalizes the prior lessons. It owns the AI risk register and converts each named risk into a tier rule and an owner, and it makes the program's five verification gates firm policy rather than personal habit, which is governance becoming the G of the readiness audit made real.