Which category on the risk map does AI risk belong to? What should the CRO set up first?
- Inventory first: the AI system inventory covers AI that is built in-house, bought, and used by staff on their own, recording purpose, data, owner and risk tier.
- Use existing categories: Article 18 of the TWSE and TPEx Risk Management Best Practice Principles for Listed Companies lists strategic, operational, financial, information, compliance, integrity and other emerging risks. AI governance usually sits under other emerging risks, with individual uses mapped by impact to information, compliance or operational risk.
- Method: ISO/IEC 23894 or the US NIST AI Risk Management Framework (Govern, Map, Measure, Manage) can serve as references.
- Not only company losses: assess the impact on individuals and groups as well, for example pricing or eligibility screening that disadvantages a customer group over time.
The principles are for listed companies to refer to; companies that are not public companies are not covered and can use them voluntarily.
How do we choose the first AI use case without exceeding risk appetite?
A good starting point usually has a clear goal, usable data and a tolerable cost of failure, such as quality inspection or predictive equipment maintenance. Rank by data availability, business benefit and risk controllability, not by how new the technology is.
| Model | Risks to clarify first |
|---|---|
| Buy a mature AI solution | Where data is stored, whether the vendor may use your data, whether you can exit later |
| Co-develop with a technology vendor | Ownership of models and data, acceptance criteria, who runs it after go-live |
| Build internal capability | Training, data foundations and governance processes |
If the AI will affect decisions about customers or employees, process personal data, or go into a product for the EU market, formal governance and risk assessment are needed. Set KPI baselines before deployment so the benefits can be tracked.
After AI goes live, which KRIs should the CRO track?
These are KRI directions that can be built on the ISO/IEC 42001 monitoring requirements; thresholds are set by the company according to its risk appetite:
- Model performance: whether accuracy and drift exceed thresholds; performance by group, so errors in small groups are not hidden by the overall average
- Human oversight: whether there is a human checkpoint before high-impact operations; the share of outputs corrected or overridden by people (model degradation is often masked by manual fixes while official metrics still show targets met)
- Change: when a bought model is updated, whether you know the version in use, run the same regression tests, and have an alternative if you cannot roll back
- Incidents: number of AI incidents and whether each investigation has an owner, so R&D, sales and security do not pass it around
Feed these results into management review and risk reporting, not just the IT department.
If we buy a model or outsource development, can the risk and responsibility be transferred to the vendor?
Not entirely. When you build a third-party foundation model into your own product, you remain responsible for retrieval data, prompt design, tool integration and go-live approval; with outsourced development, data, acceptance, go-live decisions and incident handling remain the commissioning party's responsibility; staff using personal accounts for company work is also AI use the organisation must govern.
If you use a high-risk AI system in EU business (as a deployer), Article 26 of the EU AI Act requires you to use it according to the instructions, assign human oversight to people with the necessary competence, training and authority, monitor operation and inform the provider where relevant, and keep the logs under your control for at least six months. Rebranding, substantially modifying or re-purposing a system so that it becomes high-risk makes you a provider under Article 25(1).
Vendor contracts should cover information provision, data use and exit arrangements.
How should the regulatory and liability exposure of AI transformation go into the impact assessment?
| Source | Exposure |
|---|---|
| EU AI Act Article 99 | Breaching prohibitions: up to EUR 35 million or 7% of worldwide annual turnover; other obligations: up to EUR 15 million or 3% (whichever is higher) |
| Damages | The EU AI Act itself has no civil damages rules; the Commission has withdrawn the AI Liability Directive proposal; AI damage is handled mainly under the new Product Liability Directive (EU) 2024/2853 (covering software and AI, for products placed on the market from 9 December 2026) and national tort law |
| Taiwan | The AI Basic Act was promulgated and took effect on 14 January 2026; requirements for companies come mainly through risk-based rules set by sector regulators; the Ministry of Digital Affairs has published version 1.0 of an AI risk classification framework |
Specific liability and applicability should be assessed case by case by legal counsel.
How should AI transformation risk be reported to the board or risk management committee?
Fold AI into the existing reporting cycle instead of opening a separate line:
| Article of the principles | How AI transformation fits in |
|---|---|
| Article 13: the board approves the risk management policy | Extend the policy scope to the use and development of AI systems |
| Article 14: the risk management committee approves risk appetite | Set AI tolerance, for example which decisions may not be fully automated |
| Article 15: report at least once a year | AI inventory and risk tiers, KRIs, incidents, investment benefit against baselines |
ESG evaluation indicator G-18 requires a board-level functional committee to oversee risk management and report to the board at least once a year; it is an AA item, and scoring it adds one point to the total. The principles and the ESG evaluation apply to listed companies; companies that are not public companies are not covered and can use them voluntarily.
How does Winners Consulting help a CRO govern the risks of AI transformation?
- Governance first: before AI systems are deployed, build an ISO 42001 AI management framework covering AI ethics principles, AI system inventory management, security requirements for AI development and procurement, and an algorithm review process
- Four steps: identify AI opportunities and assess risk, build the AI governance framework, implement and integrate AI systems, monitoring and optimisation with EU AI Act compliance
- Trackable results: KPI baselines set before deployment
- Timeline (as listed on the service page): depending on AI maturity and scope, usually 7 to 12 months or more
- Who leads: VP- and director-level consultants lead the work end to end, never outsourced; the first assessment is free
More: AI transformation advisory, Choosing an AI transformation consultant, ISO 42001, CRO role page
How other roles see this service
Other services for this role
- ERM for CROs: how do you build the risk map, KRIs and board reporting?
- ISO 22301 for CROs: how do scenarios, RTOs and exercises enter the risk report?
- ISO 37001 for CROs: how do you manage bribery scenarios and overseas exposure?
- Trade secrets for CROs: how do you set leak scenarios, reasonable measures and KRIs?
- ISO 27001 for CROs: how do information and enterprise risk share one scale?
- AI risk for CROs: what to decide first on ISO 42001 and the EU AI Act?
- GDPR for CROs: how to assess fines, intra-group transfers and breach scenarios?
- NIS2 for CROs: how to assess scope, fines and management body duties?
- EU CRA for CROs: how to handle market access risk, reporting and oversight?
- CRO and DORA: where do ICT third-party and operational resilience risks go on the risk map?