The European Union Artificial Intelligence Act is, in regulatory terms, a sprawling instrument. It runs to more than a hundred articles and twelve annexes. Most institutional reading of it has fallen into one of two failure modes. The first is to treat it as a compliance project, the property of the legal function, to be discharged by a checklist. The second is to treat it as a far-off problem, the property of a strategy team, to be deferred until enforcement matures.
Neither reading serves a Chief Risk Officer. The Act is not a compliance instrument. It is a risk-management instrument, and three of its provisions, Articles 9, 15, and 17, place obligations on the risk function that cannot be discharged elsewhere.
Article 9: the risk-management system
Article 9 requires that providers of high-risk AI systems establish, implement, document, and maintain a risk-management system. The language is familiar. The substance, in our reading, is not.
A risk-management system under Article 9 is not a register of known risks. It is a continuous process that identifies foreseeable harms, evaluates the residual risk after mitigation, and revisits the analysis as the system, the data, or the deployment context changes. Crucially, the analysis must address not only the institution's own risks but the risks to natural persons exposed to the system, a population over which a conventional enterprise-risk register has no view.
The practical implication for a CRO is that the existing risk-management apparatus, designed around shareholder and enterprise harm, must be extended to capture a different class of harm with a different evidentiary basis. This is not a technical question. It is an institutional one.
Article 15: accuracy, robustness, and cybersecurity
Article 15 imposes obligations on the accuracy, robustness, and cybersecurity of high-risk AI systems. The most consequential phrase is the requirement that systems perform consistently throughout their lifecycle.
For an institution that has purchased a model from a vendor and deployed it without modification, this introduces an unfamiliar evidentiary burden. The vendor will provide performance evidence as of the date of release. The institution must produce evidence of consistent performance as of any later date a regulator may inquire. The mechanism by which this evidence is produced (continuous evaluation, drift monitoring, periodic re-validation) is rarely present in the institution's existing model risk framework.
The Article 15 burden is not the model. It is the institutional capacity to attest, on demand, that the model continues to perform.
Risk functions that have historically operated on the strength of pre-deployment validation now require an operating cadence built around post-deployment monitoring. The committee structures, the evidence pipelines, and the second-line attestations that this cadence requires are, in most institutions, partial at best.
Article 17: the quality-management system
Article 17 requires a quality-management system. In substance, it requires that the institution document, in advance, how it will design, develop, test, deploy, monitor, and retire AI systems. The document is not a marketing artifact. It is the basis on which regulators will assess whether the institution's actual practice conforms to its stated procedure.
The Article 17 obligation does not, in itself, require new practices. It requires that whatever practices the institution operates be specified, governed, and auditable. For most risk functions, the gap is not in capability. It is in the formality of the capability's expression.
What existing artifacts already cover
The institutional response to the Act has been, in many cases, to commission a parallel apparatus: an AI governance committee, an AI policy, an AI inventory, an AI risk register. Some of this is necessary. Much of it duplicates instruments the institution already operates.
A model risk management framework, if one exists, addresses much of the Article 9 obligation. An information security program, if one exists, addresses much of the Article 15 cybersecurity requirement. A third-party risk program, if it has been extended to vendor AI services, addresses a large fraction of the supplier-facing obligations the Act creates. The question for the CRO is not whether new artifacts are required. The question is which existing artifacts can be extended and which require to be supplemented.
Where the genuine gaps sit
In our experience across institutions presently working through the Act, the genuine gaps cluster in three areas.
The first is post-deployment monitoring. The institutional muscle for continuous evaluation of model performance, particularly for vendor models the institution does not train, is rarely developed. The platforms exist. The operating cadence does not.
The second is human-oversight procedure. Article 14 requires that high-risk AI systems be effectively overseen by natural persons. The institutional translation of this, what an overseer does, when, with what evidence, and what action she is empowered to take, is rarely specified. In most institutions, the human-oversight obligation is satisfied on paper by the existence of a committee whose actual decision-making protocol is undefined.
The third is the AI inventory itself. Article 12 logging and Article 17 documentation depend on a reliable accounting of which AI systems the institution operates, including the vendor systems whose AI components are embedded rather than declared. Most institutional inventories are partial, lagging, and reliant on self-attestation by the business units that have integrated the systems.
A note for the Chief Risk Officer
The EU AI Act is not, ultimately, a regulation that the legal or compliance function can absorb on the institution's behalf. The obligations it imposes are operating obligations. The evidence it requires is operating evidence. The committee that will be required to attest to compliance is, in practice, a risk committee.
The window in which to construct this apparatus is not long. Enforcement is staggered, but the institutional time required to build a defensible AI governance posture is twelve to eighteen months for an organization starting from a partial baseline. The institutions that begin in 2026 will be operating from confidence in 2027. The institutions that begin in 2027 will be operating from urgency in 2028.