You can describe AI risk in general terms. What you cannot yet do is say which of your systems carries the most of it, on what basis, and whether that changed this quarter — because each assessment was done differently, by different people, at different times.
That makes AI the one exposure in the business you cannot put on the same page as everything else, which is precisely when a board starts asking harder questions.
Every system scored from the same evidence, so ranking them is meaningful rather than a matter of who wrote the assessment.
Classification against EU AI Act categories per system, so the risk language matches the one your regulators and customers use.
Risks link to the systems they arise from and the incidents that realise them, so a pattern across three systems is visible as a pattern.
Escalation paths and four-tier severity logic, so what reaches you is what should, and the rest is handled where it sits.
Whether the board's picture of AI risk survives contact with reality. A quantified position that turns out to be wrong is recoverable; discovering there was no position at all when an incident lands is not.
CXO Ready is an aid, not an assurance. It helps you structure your thinking, record what you have done and see where the gaps are. It does not make you compliant, and nothing it produces is legal advice or a regulatory opinion. Scores are indicative. Responsibility for compliance stays with your organisation, and decisions with legal consequences should be taken with a qualified adviser.
Before you start
By scoring what is documented rather than what is felt. Legal basis, DPIA, human oversight, bias and drift controls, kill-switch and security posture are either evidenced or they are not. The score measures the strength of the controls actually in place, which is defensible in a way that a subjective 1-to-5 rating is not.
No, it feeds it. CXO Ready produces AI risk in a form your existing framework can consume, with the per-system detail underneath. Most risk functions keep their taxonomy and use this for the layer beneath it that general GRC tools do not reach.
It changes after deployment without anyone shipping code. Model drift, changing input distributions and vendor updates all move the risk position of a system that looks untouched, which is why point-in-time assessment fails for AI and continuous scoring does not.
It is recorded as a system like any other, with the vendor named and the dependency mapped. You often cannot inspect the model, but you can evidence what you asked, what they answered and what controls you put around it — which is what a regulator will actually want to see.
More in the full FAQ, or ask us directly.
Other roles