What MIT found, and the recommendation worth acting on
MIT FutureTech and the MIT AI Risk Initiative have published a useful piece of work: Unmitigated: How the largest global companies are responding to AI risks, by Alexander Saeri, Jess Graham, Michael Noetel, Peter Slattery, Kun Zhao, Eunice Zhang, Erin Howard and Neil Thompson. The team read the public documents of 200 of the world’s largest companies, the 100 largest by market capitalization plus 100 drawn at random from the next 900, classified every passage about AI against the 24 risks in the MIT AI Risk Repository, and compared what they found with ratings from 272 AI risk experts.
Most of what they report is about public disclosure. 32% of the 100 largest companies did not publicly acknowledge any AI risks, and across the largest 1,000 the estimate is 62% (likely range 54% to 70%). What to disclose is a decision each company makes with its counsel.
The finding I found most practical for people who run AI governance day to day is a different one. In an exploratory analysis, 71 of the 100 largest companies reported at least one AI risk mitigation, but the mitigation was rarely linked to a specific risk. The authors recommend that reporting frameworks require that link, ideally against a specified set of controls and the risks each one addresses. It is a simple idea. It is also the difference between a list of good intentions and a record an outsider can rely on.
What a board actually reads
A board does not read a risk register. It reads a short list, worst first, with enough on each line to decide whether to ask a question. That is how the SanctumShield Executive Risk Report is built: five findings, ordered by severity, each with the evidence it rests on, the business impact if it is left alone, the clause it anchors to and a sentence on why it earned its severity.
Here are the five from our public sample, written for a fictional health company, Acme Health. The sample carries a sixth finding as well, because one of Acme’s answers triggered it; the five below are the ones a board would see first.
| # | Finding | Severity | Anchored to | Risk category (MIT AI Risk Repository) |
|---|---|---|---|---|
| F1 | Microsoft 365 Copilot uncovered on a tenant holding patient data | Critical | HIPAA §164.502(e), §164.404 | 2.1 Compromise of privacy by obtaining, leaking or correctly inferring sensitive information |
| F2 | Unmanaged Cursor agent use on engineering laptops | High | HIPAA §164.502(e), GDPR Article 28 | 2.2 AI system security vulnerabilities and attacks |
| F3 | No formal AI Acceptable Use Policy | High | SOC 2 CC5.3, EU AI Act Article 14 | None: no category fits exactly |
| F4 | No sub-processor disclosure for AI vendors | Medium | GDPR Article 28 | 2.1 Compromise of privacy … |
| F5 | Personal-device AI use invisible to device management | Medium | HIPAA §164.312 | 2.1 Compromise of privacy … |
Take the first line. Copilot is switched on in a Microsoft tenant that holds patient data, the AI policy on file does not mention it, and the agreement with Microsoft does not list Copilot as an in-scope service. The finding says so, cites the two HIPAA sections that apply, and explains the severity in one sentence: patient data is one configuration change away from a notification event. A director does not need to know what a tenant is to understand that sentence.
The severity comes first because attention is finite. Evidence comes next because a finding without evidence is an opinion. The clause is there because the board’s counsel will ask which obligation is at stake. And the rationale is there because the most common question in a board meeting is “why is this one red?”
The link: each action names the finding it closes
Findings are half of the record. The other half is the 90-day plan, and this is where the MIT recommendation lands. Every action in the plan now names the finding it closes.
| When | Action | Closes | Owner |
|---|---|---|---|
| Week 1 | Disable Copilot tenant-wide pending policy adoption and a Copilot-specific business associate agreement | F1 and TC1 | CISO |
| Week 2 | Adopt the AI Acceptable Use Policy and route it for signature | F3 | Legal |
| Week 4 | Publish the AI sub-processor disclosure and notify enterprise customers | F4 | Legal |
| Week 6 | Require a managed device for corporate sign-in across Google Workspace and Microsoft 365 | F5 | IT |
| Week 8 | Roll out safe-use training with acknowledgment tied to the new policy | F3 | HR |
TC1 is a compound finding: F1, F3 and F4 together describe patient data flowing through an AI service with no policy, no sub-processor disclosure and no review cycle. The first action closes F1 and takes the pressure off the compound at the same time, so it names both.
Then the plan checks its own coverage. At the foot of the plan, every finding is listed against the action that closes it, and any finding no action closes is named, with its owner, as an accepted risk or as open. In the sample, two findings are not closed by any of the five actions, the Cursor agents (F2) and the sixth finding, and the report says so in plain words. That is not a flaw in the plan. It is the plan telling the truth. A finding left open with a named owner is a decision; a finding that silently falls off the list is a gap nobody can see.
This is the control-to-risk linkage the MIT team recommends, in a form an underwriter can read in a minute. Each control points to the risk it answers, and each risk either has a control or a named person who owns the decision not to act yet. The same link appears in the Light and Standard reviews, where each next step sits beside the area it closes, and in the answers workbook, which carries a “Closes finding(s)” column on every action row. The Board Memo keeps to one page and says, in one sentence, that each action is tied to the finding it closes.
A shared vocabulary: the MIT AI Risk Repository
The last column of the findings table is new. Each finding can now carry a category from the MIT AI Risk Repository, named exactly as MIT publishes it: “Compromise of privacy by obtaining, leaking or correctly inferring sensitive information” for the Copilot finding, “AI system security vulnerabilities and attacks” for the unmanaged agents. A category appears only where MIT’s own definition fits the finding exactly, so the missing policy (F3) carries none: MIT’s “Governance failure” describes public regulation lagging behind AI, not one company’s policy.
Why bring in an outside taxonomy? Because the people who read these reports compare them. An auditor reviewing ten clients, or an underwriter pricing a book of renewals, needs the same risk to have the same name everywhere. Our own finding titles are written for the organization that owns them. The MIT category is written for everyone else. Used together, they let a reader see both what happened here and where it sits in the wider map of AI risk.
The tag is a reference point, not a compliance claim, and MIT does not review or endorse SanctumShield. The repository’s data is licensed under Creative Commons Attribution 4.0, and every report that carries a tag says so in its footer: “Risk categories reference the MIT AI Risk Repository (MIT FutureTech / MIT AI Risk Initiative), licensed CC BY 4.0. https://airisk.mit.edu”
Why it repeats
A risk report is true on the day it is written. The AI surface changes faster than that: a vendor switches on a feature inside software you already license, a team authorizes an agent, a model behind a service changes without notice. So the record is re-run on a cadence, and each run carries its date, its Verification URL and the list of what changed since the last one. The Missing Layer explains why the re-run is the artifact, and Five Records the Law Already Asks For sets out which records the instruments already expect.
Where to start
If you want to see where your own AI surface stands, the free Shadow AI Check takes a few minutes and needs no account. The free templates include the Board AI Register to fill in yourself. And the full Acme Health report, with its five actions, the coverage check and the MIT categories, is public on the sample outputs page, so you can read exactly what a board would read before you start your own.
Sources
- Saeri, A. K., Graham, J., Noetel, M., Slattery, P., Zhao, K., Zhang, E., Howard, E., and Thompson, N. (2026). Unmitigated: How the largest global companies are responding to AI risks. MIT FutureTech and MIT AI Risk Initiative. Paper (PDF). Data licensed CC BY 4.0.
- MIT AI Risk Repository, domain taxonomy of AI risks (7 domains, 24 subdomains). MIT FutureTech and MIT AI Risk Initiative. Licensed CC BY 4.0.
- SanctumShield sample outputs: the Acme Health Executive Risk Report (fictional company)
- The Missing Layer, SanctumShield, October 23, 2026
- Five Records the Law Already Asks For, SanctumShield
- Glossary: control-to-risk linkage, AI risk disclosure and MIT AI Risk Repository