The consequence map doesn't classify a system by what it touches. It classifies a system by what the business loses when that system fails or gets compromised, and whether that loss is recoverable. A system connected to everything can still land as low-impact if the failure there is cheap and quick to fix. A system nobody thinks about can land as existential if its data can't be reconstructed and losing it ends the business. What a system touches feeds into the answer, but the answer itself comes down to cost and recovery, existential, high-recoverable, or low-impact.

Run an AI system through that same question and the answer depends entirely on what's on the other side of the failure, not on the fact that it's an AI system at all. An agent with permission to move money or push code carries the same worst case as any other service account with that access, credentials extracted, actions taken under the business's name, a pivot into whatever else those credentials reach. That worst case is existential for the same reason a compromised deployment pipeline is existential. Being AI doesn't change the answer.

Recovery is where AI systems put more pressure on the map's own questions. The map already asks what recovery looks like today and marks the answer tested with a date, untested, or unknown, and for most traditional systems the owner can point to a backup and a known restore point even when the answer is untested. A model fine-tuned on data that turns out corrupted or poisoned has no equivalent clean point. Nobody can say exactly when the bad data entered or how much of the model's current behavior traces back to it, so "retrain the model" isn't a restore procedure the way "restore from backup" is. Recording the recovery status as unknown here is often the accurate answer, not a gap in the process, and it should push the classification toward existential rather than get smoothed over as a formality.

The exfiltration question runs into the same wall. Losing a database means losing a known set of records. Losing a vector store built from embedded documents is harder to bound, since the exposure includes whatever sensitive material got embedded, and most teams can't say offhand what that includes without going back and checking. The map asks who could be impersonated and what obligations get triggered if the data leaves undetected. For a system built on embeddings, answering that well usually takes real digging, more than it takes for a database with a known schema, and how long that digging takes is itself useful information about how well the system is actually understood.

The eight questions still work for AI systems without any separate row or separate set of rules, but getting real answers to them takes more digging than it does for a system with a known schema and a tested backup. Run the questions the same way you would for anything else on the list. When the team hesitates or answers "unknown" more than once, treat that as a signal the system belongs higher on the list than the first pass suggested.