The Spreadsheet Trap
Most mid-market teams that want to get AI governance off the ground start with a risk spreadsheet. They list their AI tools, score them on a rough likelihood-and-impact scale, and call it a framework. It feels like progress. The problem is that the scores are guesses — because they haven’t been logging what’s actually going wrong.
An AI incident log isn’t the glamorous part of governance. It doesn’t produce a policy document you can show an auditor or a risk score you can present to leadership. What it produces is evidence: a timestamped, factual record of the AI-related events your organization has already experienced. That record is what turns a risk spreadsheet from informed fiction into something defensible.
If you’re building AI governance from scratch — or trying to make what you have credible — the incident log belongs at the front of the line.
What Counts as an AI Incident
The term “incident” carries baggage from IT security, where it usually means a breach or an outage. AI incidents are broader and often quieter. You should be logging any event where an AI tool produced a result that was wrong, harmful, unauthorized, or policy-adjacent — whether or not it caused visible damage.
In practice, that covers four categories:
- Output failures: A model generates factually incorrect content that gets used in a client-facing document, a contract summary with a material error, a code suggestion that introduces a vulnerability.
- Policy violations: An employee uses a generative AI tool to process data that your acceptable-use policy doesn’t permit — customer PII, confidential financials, health information — regardless of whether the data was retained by the vendor.
- Vendor and service issues: A third-party AI provider has an outage, changes its data retention terms mid-contract, or discloses a security incident affecting model training data.
- Near-misses: An employee catches a bad output before it ships, or flags a use case that probably shouldn’t have reached an AI tool in the first place.
That last category is the one teams skip most often, and it’s the most valuable. Near-misses are your leading indicators. By the time you’re counting confirmed failures, you’re already behind.
What to Actually Capture in Each Entry
A useful AI incident log entry doesn’t need to be long, but it needs to be consistent. The fields that matter are:
Date and time — obvious, but worth stating: log the date the incident occurred or was discovered, not just the date you got around to writing it up.
AI tool or system involved — the specific product, not just the vendor category. “ChatGPT” tells you more than “generative AI.”
Incident type — use a controlled vocabulary from the start. Freeform descriptions make pattern analysis impossible. A simple taxonomy like output failure, policy violation, vendor issue, and near-miss is enough to start.
Description — a factual, two-to-four sentence account of what happened. Resist the urge to characterize severity here; that goes in a separate field. Stick to what happened.
Data involved — was any sensitive data processed or exposed? If yes, what classification? This field is critical when a later privacy inquiry or regulatory question requires you to reconstruct what was at risk.
Business impact — what did this actually cost, delay, or affect? Even a rough estimate is better than nothing. “Draft went to client with incorrect clause; caught in review, no contract signed” is a legitimate entry.
Reporter and owner — who logged it, and who is responsible for any follow-up or remediation? These can be the same person in a small team, but they need to be named.
Status and resolution — open, under review, resolved, or accepted risk. Close the loop on every entry, even if the resolution is “acknowledged, no action required.”
The format matters less than the consistency. A shared spreadsheet with these eight fields, maintained by one person, beats an elaborate tool nobody fills out.
Who Owns the Log
In a mid-market company without a dedicated compliance team, the AI incident log typically lands with the IT manager or the person who owns security policy. That’s the right call — not because AI incidents are purely technical problems, but because that role already has the cross-functional visibility to hear about issues from legal, operations, HR, and finance before they disappear into departmental silos.
Ownership means two things: maintaining the log itself, and creating the conditions where employees actually report to it. The second part is the harder job. People don’t report AI incidents for the same reasons they don’t report security near-misses — they’re not sure what counts, they don’t want to look like they misused a tool, and there’s no obvious place to send the information.
Solve the process problem before you solve the tool problem. A one-paragraph explanation in your acceptable-use policy of what constitutes a reportable AI event, and a clear instruction on how to report it, will generate more entries than any software you deploy. Pair it with a standing agenda item in a monthly IT or security review meeting where recent incidents get briefly discussed, and you’ve created accountability without bureaucracy.
How Incident Data Feeds Risk Assessment
Here’s where the sequencing argument becomes concrete. When you eventually build or formalize a risk assessment for your AI tools — scoring vendors, evaluating use cases, deciding what controls to put around different applications — the incident log is your empirical baseline.
Without it, a risk assessment is a structured guess. You’re estimating likelihood based on general knowledge of a tool category, not on your organization’s actual experience with that tool in your environment, used by your employees, processing your data.
With even three to six months of incident data, the assessment becomes grounded. You’ll see which tools generate the most output failures in practice, which departments are most likely to push against acceptable-use limits, and which vendor relationships carry operational risk you didn’t anticipate at procurement. That’s not theory — that’s pattern recognition from your own operations.
The EU AI Act’s conformity assessment requirements, for instance, are built around documented evidence of how a system performs and what risks have been identified and addressed. If you have EU exposure and you’re using AI tools that touch personal data or decision-making processes, “we have a log of what’s happened and how we responded” is a materially stronger position than “we assessed the risk before deployment and haven’t tracked it since.” The Act’s obligations vary by risk tier and operator role, but the evidentiary logic is consistent across the EU AI Act text: documented monitoring is not optional for systems above minimal risk.
The NIST AI Risk Management Framework makes a similar point from the other direction. The NIST AI RMF treats “GOVERN,” “MAP,” “MEASURE,” and “MANAGE” as a cycle, not a one-time exercise. Measurement, including incident tracking, is what keeps the cycle honest. You can’t govern what you’re not measuring.
The Practical Takeaway: Do This Week
You don’t need a governance platform to start. This week, open a shared document or spreadsheet, add the eight fields listed above, and send a two-paragraph email to your team that says: here’s what an AI incident is, here’s where to report it, and here’s why we’re tracking it. Then log the last three AI-related issues you personally know about — the output someone complained about, the tool someone used in a way that made you uncomfortable, the vendor notification you filed and forgot. That’s your baseline.
Do that before you spend another hour refining your risk scoring methodology. The incidents will tell you where to focus the methodology.
If you want a purpose-built home for that register rather than a spreadsheet you’ll eventually outgrow, InfoDefenders’ AI Incident Log gives you an append-only incident register at the STARTER tier — no enterprise GRC overhead, no implementation project.
Why “React First” Is a Framework, Not Just Advice
The RAGP sequence — React, Assess, Govern, Prove — is deliberately ordered. React comes first because you can’t accurately assess risk you haven’t observed, govern behavior you haven’t documented, or prove a governance posture you haven’t built from evidence up.
Teams that skip React and start with Assess produce risk frameworks that look rigorous and aren’t. They score hypothetical threats while real incidents go unlogged. When a regulator, a customer, or a board member asks “what AI-related issues have you had, and how did you handle them,” a risk score doesn’t answer the question. A log does.
Starting with the incident log also produces something equally valuable: organizational muscle memory. The act of logging incidents — deciding what counts, naming an owner, tracking resolution — trains your team to think about AI use as something that requires accountability. That mindset shift is worth more than any framework document you could hand them.
Get the log running first. The rest of governance gets easier once you have something real to govern from.
