A regional design-build firm discovered its largest AI exposure the way most firms do: in a deposition. A junior project architect had pasted a confidential hospital owner's program brief, including the as-yet-unannounced bed count and the site, into a public chatbot to draft an OPR summary, and a competitor referenced that bed count in a pursuit four months later. Nobody at the firm had ever named "owner-confidential data pasted into a public model" as a risk, so nobody owned it, nobody had a mitigation, and nobody could say who was supposed to have stopped it. The firm had AI tools, AI enthusiasm, and AI-generated deliverables flowing into stamped sets and pay apps. What it did not have was a single sheet that listed each AI risk, rated how likely it was and how badly it would hurt, named the person responsible for it, and stated what the firm was doing to keep it from happening. This lesson builds that sheet: the firm's AI risk register, the governance instrument that names every AI risk the program has taught you to fear, rates likelihood and impact, assigns an owner and a mitigation, and turns the program's verification gates into something the firm can audit at the firm level rather than hope happens deliverable by deliverable.

What a Risk Register Is and Why AI Needs Its Own

Construction firms already run risk registers. A project risk register names each risk to a job (a long-lead switchgear slip, a differing site condition, a key-trade default), rates its likelihood and impact, assigns an owner accountable for watching it, and states the mitigation that reduces the likelihood or impact. It is not a memo or a policy statement; it is a living table a risk committee reviews on a cadence, giving each named risk a person and a plan and making the firm's exposure visible and auditable rather than diffuse and deniable. The discipline that makes a project register work is exactly what an AI register needs: a risk is not managed until it is named, rated, owned, and mitigated.

AI needs its own register, separate from the general project register, for a specific reason: the AI risks are new, they cut across every project and department, and they do not map cleanly onto the categories the firm's superintendents and PMs already watch. A differing-site-condition risk lives on one job with one owner. The risk that an AI tool hallucinates a spec section, that a vendor goes insolvent and takes the firm's prompt library and project data with it, or that a safety-vision model under-detects on workers with darker skin in low light is a firm-wide exposure no single PM owns and no existing register captures. Folded into the general register, the AI risks are diluted; pulled into their own, each gets a named owner, a rating, and a mitigation, and the firm can see its whole AI exposure on one sheet.

The controlling analogy is the register itself, carried straight from the project-controls world the reader already lives in. Everything that follows is the columns of that table applied to AI: the category (the named risk), the likelihood and impact (the rating), the owner (the accountable person), and the mitigation (what reduces it). The work of the lesson is to fill those columns candidly for each of the nine AI risk categories, because a register with vague categories, unrated rows, unnamed owners, or aspirational mitigations is theater, not governance.

The Nine AI Risk Categories for an AEC Firm

The register's rows are the named AI risks, and for an AEC firm there are nine that recur and that the register should at minimum cover. Each maps to a lesson earlier in this program, which is the point: the register is not a new body of knowledge but the consolidation of the program's hazards into one auditable instrument. The nine are stamped work, contract authority, intellectual property, data and confidentiality, bias and fairness, vendor failure, hallucination, cybersecurity, and OSHA and life-safety implications.

Stamped work is the risk that AI-generated output flows into a sealed, stamped deliverable, a sheet, a calculation, a code narrative, that the licensed professional did not verify, because the stamp is binary: it is either the professional's own verified work or it is not, and there is no partial seal. Contract authority is the risk that an AI-drafted notice, RFI, ASI response, or change document misstates a notice window or a claim clause and prejudices the firm's contractual position, the A201 §3.2.4 / §15.1.3.1 / §3.7.4 confusion the program has flagged repeatedly. Intellectual property is the risk around BIM model rights under AIA E203 and G202, point-cloud ownership, and who owns AI-generated geometry and the prompts that produced it. Data and confidentiality is the risk that owner-confidential program data, NDA-protected scopes, bid documents, or federal DBE/MWBE lists are pasted into a tool that trains on them or exposes them, the exact failure that opened this lesson.

Bias and fairness is the risk that AI bid-leveling systematically deprioritizes MWBE and DBE subs, or that a safety-vision model under-detects on certain workers, producing a discriminatory or unsafe outcome the firm cannot defend to an owner's DEI auditor. Vendor failure is the risk that an AI vendor is acquired, sunset, breached, or goes insolvent, and the firm loses the tool, the data, or the workflow that depends on it. Hallucination is the risk that the AI confidently fabricates a spec section, an AIA clause, an ASTM citation, a UL listing, or an NEC article, and it reaches a deliverable unverified. Cybersecurity is the risk that the AI tool is the attack surface: prompt injection, data exfiltration through the model, or a compromised vendor pipeline. OSHA and life-safety implications is the risk that an AI-generated pre-task plan, toolbox talk, or safety analysis is wrong on a life-safety point, conflates OSHA 1910 (general industry) with 1926 (construction), or lulls a crew into trusting a vision system that missed a hazard.

How Each Category Maps to a Lesson

The register's power for a firm strategist is that it is auditable against the program: every category traces to a lesson, so the firm can point to where the risk was taught and which deliverable it governs. Stamped work traces to the cardinal-rule and responsible-charge lessons: the stamp is binary, so the mitigation is the verification gate before any AI-touched output reaches a sealed sheet. Contract authority traces to the AIA A201 and contract-notice verification lessons: the mitigation is the notice-clause check on every AI-drafted contract document. Intellectual property and data and confidentiality trace to the IP, Drawings, and Confidentiality lesson and the firm AI-use policy it produced: the mitigation is the policy that says what may and may not be pasted into which class of tool.

Bias and fairness traces to the Bias and Fairness lesson on estimating, sub selection, and safety analytics: the mitigation is the documented AI-assisted decision trail and the detection-rate parity audit. Hallucination traces to the hallucinations lesson and every verification lesson: the mitigation is citation-back-to-source and the "I could not find" requirement on AI output. Vendor failure traces to the vendor-selection and security-and-contract-diligence lessons: the mitigation is the diligence checklist, the data-export and exit terms, and the SOC 2 / data-residency requirements in the enterprise agreement. Cybersecurity traces to the same diligence lesson plus the firm's broader security posture and NIST AI RMF alignment. OSHA and life-safety implications traces to the OSHA pre-task-plan and safety-observation lessons and the life-safety gate: the mitigation is that the competent person owns the PTP and the safety analysis, never the model.

This mapping is what makes the register the program's capstone governance artifact rather than a generic IT risk list: it is grounded in the AEC-specific failure modes the program has spent four levels teaching, and each row carries the verification discipline the relevant lesson established. The strategist who builds it is not inventing controls; they are consolidating the controls the program already taught into one instrument the firm's risk committee can govern from.

Rating Likelihood and Impact

A register that names risks but does not rate them cannot prioritize, and prioritization is the whole point: a firm cannot mitigate everything at once, so it must address the risks that are both likely and severe first. Each row gets a likelihood rating (how probable in the next period, given the firm's current tools and practices) and an impact rating (how badly it hurts if it happens), each on a simple low / medium / high scale, with the product giving a priority that orders the register. The scale need not be quantitative; it needs to be honest and consistently applied, so a high-likelihood, high-impact risk visibly outranks a low-likelihood, low-impact one.

The ratings should reflect the firm's actual posture, not a generic industry baseline. Data and confidentiality is high-likelihood at a firm with no AI-use policy and junior staff using public chatbots, lower at a firm with an enterprise tool, training opt-out, and a clear policy, so the rating mirrors the firm's current controls. Hallucination is high-likelihood everywhere, because models fabricate by nature, but its impact depends on whether the verification gates are real: high where AI output flows unverified into stamped sets, lower where the discipline holds. Stamped work and OSHA and life-safety are the highest-impact categories by definition, because the consequence is a revoked stamp, a lawsuit, or a hurt worker, so even at moderate likelihood they sort to the top.

A risk register is the governance instrument that makes the program's verification gates auditable at the firm level: it names each AI risk, rates its likelihood and impact, assigns an owner and a mitigation, and turns "we verify before we stamp" from a hope into a row someone is accountable for.

Assigning the Owner and the Mitigation

The two columns that turn a list into governance are the owner and the mitigation, and they are the two most often left blank. An owner is a single named, accountable person, not a committee and not "the firm," because a risk owned by everyone is owned by no one, which is how the opening firm got blindsided. The owner watches the risk, reports on it to the AI committee, and is accountable if the mitigation lapses. The natural owners follow the categories: the risk or legal lead owns contract authority and IP; the data or IT lead owns data, confidentiality, and cybersecurity; the chief estimator or precon lead owns bias in bid-leveling; the safety director owns OSHA and life-safety; the relevant licensed professional, the AOR or EOR, owns stamped work, because the stamp is theirs and cannot be delegated to a committee.

A mitigation is what the firm actually does to reduce the likelihood or the impact, stated specifically enough to be checked. "Be careful with confidential data" is not a mitigation; "deploy the enterprise tool with training opt-out, publish the AI-use policy naming what may not be pasted into public tools, and train all staff quarterly" is. The mitigation should name the artifact or control, because most are deliverables the program has already produced: the AI-use policy mitigates data and IP, the verification gate and AI-touched-deliverable register mitigate stamped work and hallucination, the diligence checklist and exit terms mitigate vendor failure, the decision-trail and parity audit mitigate bias, the competent-person ownership mitigates OSHA. The register's job is to connect each named, rated risk to the specific control that addresses it and the person accountable for that control holding.

Two mitigation pitfalls sink registers. The first is the aspirational mitigation, a control the firm intends to build but has not, listed as though it exists, which leaves the firm rated as protected when it is exposed; the register should distinguish in-place controls from planned ones and rate the residual risk accordingly. The second is the orphaned mitigation, a control with no owner, which decays because no one is accountable. A mitigation without an owner and an owner without a mitigation are both register theater, and the AI committee's standing job is to check, on a cadence, that every high-priority row still has both and that the in-place mitigations are actually in place.

The Register as the Firm's Governance Instrument

The register is not a one-time deliverable; it is the firm's standing AI governance instrument, the table the AI committee governs from. It makes the program's verification gates auditable: a gate that lives only in a PM's habit is invisible to ownership and to an auditor, while a rated, owned, mitigated row is something the firm can show it manages. When an owner, insurer, board, or plaintiff's attorney asks "how does your firm manage the risk that AI fabricates a code citation in a stamped narrative," the register is the answer: here is the named risk, its rating, the accountable owner, the verification mitigation, and the AI-touched-deliverable register that records it held.

The register also sets the agenda for the firm's AI committee, the subject of the next lesson. A standing committee with no instrument drifts into opinion and anecdote; a committee that reviews the register on a cadence has a concrete agenda: the high-priority rows, the rows whose ratings have changed because the firm's tools or practices changed, the mitigations that have lapsed, and the new risks a new tool or project type introduced. The register is the bridge between the deliverable-level verification discipline the program taught and the firm-level governance ownership and insurers require.

Finally, the register connects to the firm's insurance and indemnity posture, the subject of a later lesson, and to its subcontractor AI flow-down. An insurer renewing the firm's professional-liability or cyber policy in 2026, when AI exclusions are appearing in renewals, will want to see that the firm names and manages its AI risks; the register is that evidence. The register that names vendor failure and data exposure is also the basis for the flow-down clause requiring subs to manage the same risks on the firm's projects. The register is the hub from which the firm's whole AI governance, the committee, the policies, the insurance, the flow-down, radiates.

The Applied Problem: Produce the Firm's AI Risk Register

Here is the exercise. Produce your firm's AI risk register as a table with one row per AI risk and the columns category, description, likelihood, impact, priority (the product of likelihood and impact), owner, and mitigation, with a final column distinguishing in-place mitigations from planned ones so the residual risk is honest. Cover at minimum the nine categories: stamped work, contract authority, intellectual property, data and confidentiality, bias and fairness, vendor failure, hallucination, cybersecurity, and OSHA and life-safety implications, and add any risk specific to your firm's tools or project types.

For each row, do the real work the columns demand. Write the description so it names the AEC-specific failure: for hallucination, the fabricated spec section reaching a stamped narrative, not "the AI might be wrong." Rate likelihood and impact against your firm's actual posture, so the ratings mirror your current controls rather than an industry baseline, and let the product sort the register so the high-likelihood, high-impact rows surface at the top. Assign a single named, accountable owner to each row: the licensed professional on stamped work, the safety director on OSHA, the risk or legal lead on contract authority and IP, the data or IT lead on data, confidentiality, and cybersecurity. State a specific, checkable mitigation for each, naming the control or artifact (the AI-use policy, the verification gate and AI-touched-deliverable register, the diligence checklist and exit terms, the decision-trail and parity audit, the competent-person ownership) that addresses it, and mark whether that control is in place today.

The deliverable is the firm's AI risk register, and the lasting product is the governance instrument the AI committee will govern from on a standing cadence, the evidence the firm shows an owner, insurer, or board that its AI risks are named, rated, owned, and mitigated rather than diffuse and deniable. The strategist who builds it has done for AI what the firm long ago did for project risk: turned a set of frightening, unowned exposures into a managed, prioritized, accountable table, the only state in which a firm can responsibly run AI across its stamped, contracted, and life-safety-critical work, because the alternative is discovering the risk no one named in a deposition.

Key Takeaways

• A risk register names each risk, rates its likelihood and impact, assigns a single accountable owner, and states a specific mitigation; the firm needs an AI-specific register because AI risks are new, firm-wide, and cross-project, and would be diluted if folded into the general project register.
• The nine AI risk categories for an AEC firm are stamped work, contract authority, intellectual property, data and confidentiality, bias and fairness, vendor failure, hallucination, cybersecurity, and OSHA and life-safety implications; each maps to a specific lesson earlier in the program, which is what makes the register auditable against the program rather than a generic IT risk list.
• Likelihood and impact need not be quantitative but must be honest and consistently applied; the ratings should mirror the firm's actual posture (data exposure is high-likelihood at a firm with no AI-use policy, lower at one with an enterprise tool and training opt-out), and the product orders the register so high-likelihood, high-impact rows surface first.
• Stamped work and OSHA and life-safety are the highest-impact categories by definition, because the consequence is a revoked stamp, a lawsuit, or a hurt worker, so they sort to the top even at moderate likelihood; the stamp is binary and the competent person owns the safety plan, neither can be delegated to a committee or a model.
• An owner is a single named, accountable person, not a committee and not "the firm," because a risk owned by everyone is owned by no one; the natural owners follow the categories, with the licensed professional owning stamped work, the safety director owning OSHA, the risk or legal lead owning contract authority and IP, and the data or IT lead owning data, confidentiality, and cybersecurity.
• A mitigation must be specific and checkable and should name the control or artifact the program already produced (the AI-use policy, the verification gate and AI-touched-deliverable register, the diligence checklist and exit terms, the decision-trail and parity audit, the competent-person ownership); the two pitfalls are the aspirational mitigation (listed as in place when it is planned) and the orphaned mitigation (a control with no owner).
• The register is the firm's standing governance instrument: it makes the program's per-deliverable verification gates auditable at the firm level, sets the AI committee's standing agenda, and is the evidence the firm shows an owner, an insurer renewing under 2026 AI exclusions, or a board that its AI risks are managed rather than diffuse and deniable.
• The register is the hub of the firm's AI governance, connecting to the AI committee charter, the firm policies, the insurance and indemnity posture, and the subcontractor AI flow-down; building it turns a set of unowned exposures into a managed, prioritized, accountable table, the only state in which a firm can responsibly run AI across stamped, contracted, and life-safety-critical work.