AI Isn't Coming For GRC Jobs. It's Coming For The Manual Review Part Of Every GRC Job

 

What second line experts each need to build before their function gets automated out from under them

Here's the uncomfortable part nobody says out loud in a GRC conference room. AI is not replacing risk managers, compliance officers, auditors, cyber teams, controllers, or sustainability experts. It's replacing the manual review work that used to justify half of those job descriptions. What's left after that work disappears is judgment, and judgment is either your biggest career asset right now or the skill you never actually built because the manual work always came first.

Every one of these six professions is being pulled through the same transformation at the same time, just wearing different clothes. Risk teams are using AI to process larger volumes of exposure data faster than any analyst could by hand. Audit is automating the routine testing that used to eat most of fieldwork season. Cyber teams are automating alert triage and first-line response. Compliance is watching AI surface policy conflicts across thousands of documents in the time it used to take to review one contract. Controllers are automating reconciliations and close procedures. Sustainability teams are automating ESG data extraction and disclosure drafting.

None of that is a headcount story on its own. It becomes one for the people who don't adapt, because the professionals who can validate AI outputs, challenge exceptions, and decide where a human still has to sign off are becoming the only ones a board actually needs in the room.

Manual Review Jobs Are Becoming Judgment and Governance Jobs

Guidance on responsible AI and audit puts this plainly: building strong governance, inventories, and validation practices now means an organization can answer the hard questions with confidence when auditors ask them, with a clear account of how AI is actually being used across the enterprise. That's not a compliance platitude. It's a description of what the job becomes once the underlying manual task gets automated: you stop being the person who does the review, and you become the person who can prove the review was done correctly.

The same shift shows up in new studies on audit committees, which stresses that internal auditors still need to bring human judgment into evaluating AI outcomes for fairness, accuracy, reliability, and consistency. The AI does the first pass. The professional's value moves entirely into catching what the first pass got wrong, and knowing when to trust it versus when to escalate.

The riskiest moment in any AI-enabled function isn't when the AI makes a mistake. It's the meeting where everyone assumes someone else already checked the output.

This pattern holds across every one of the six roles, and it's worth naming what "judgment and governance" actually means in practice, because it's not a soft skill. It's validating outputs against known failure modes, challenging exceptions instead of rubber-stamping them, and deciding, explicitly and in writing, where a human still has to own the final call. Professionals who can do all three become harder to automate than the task they used to perform, because the task was never the actual value. The check was.

Redesign The Workflow, Don't Just Bolt on a Tool

The biggest mistake organizations make right now is layering an AI tool onto an unchanged process and calling it transformation. It isn't. Research on operational risk modernization is direct about this: an AI-driven framework is only as good as the data foundation underneath it, and the real opportunity is rethinking the framework itself, not just automating today's manual steps inside the old one.

That distinction matters for your career, not just your organization's efficiency numbers. If you only learn to operate a new tool inside an old workflow, you've picked up a skill that gets replaced the next time a better tool ships. If you learn to redesign the workflow itself, meaning new decision points, new escalation paths, and new control ownership, you've picked up a skill that survives every tool upgrade after this one.

Process design and control mapping are not adjacent skills to model literacy anymore. They're the load-bearing skill. Anyone can learn to prompt a tool. Far fewer people can look at a redesigned workflow and correctly identify where the old control broke, where a new one needs to exist, and who now owns it. That's the professional a board actually wants advising them, and it's a skill you build by practicing control mapping deliberately, not by waiting for it to show up as a side effect of using AI tools daily.

Every GRC Function Now Needs Its Own AI-Specific Controls

Generic "AI governance" is not a control. It's a slogan. Each of the six functions needs controls tuned to its own specific failure modes, because the way AI breaks a compliance workflow is not the way it breaks a cybersecurity workflow.

Compliance officers need to track policy and regulatory drift as a distinct, monitored risk category, not a once-a-year policy refresh. Governance Intelligence's roundup of 2026 GRC predictions captures why this matters: Diligent's governance lead expects the pace of AI regulation to stay unpredictable and increasingly demanding through the year, which means a compliance program built around annual policy review cycles is already structurally too slow for how fast the underlying regulatory landscape is moving.

Auditors need to test AI-enabled controls and the reliability of AI-generated evidence directly, not just the outputs those controls used to produce manually. Internal audit guidance frames this as a genuine fork in the road: internal audit can either lead on AI governance or scramble to catch up after a model failure, compliance breach, or public misstep has already happened. Testing evidence quality now means asking how a model was developed, deployed, validated, and monitored, not just whether the final number tied out.

Cybersecurity experts need controls built for AI-accelerated attacks and AI-driven defense at the same time, because both sides of that fight are now running on the same underlying technology. New cybersecurity surveys name this directly as a defining contradiction facing security leaders: AI is accelerating the threat landscape while simultaneously becoming a core defense capability, which creates pressure to govern adoption tightly without slowing the business down. Establishing a formal AI security and governance program with real human-in-the-loop controls for critical decisions isn't optional anymore. 

Financial controllers need to watch specifically for automation errors bleeding into reporting and approval chains, a risk made sharper by the fact that no binding regulatory standard currently governs AI use in financial reporting audits. Coverage of the 2026 compliance landscape for CFOs and audit committees is blunt about this gap: there's no PCAOB or SEC standard governing AI in audits as of mid-2026, which means the burden falls entirely on the controller's own internal governance to answer questions regulators haven't formally asked yet, questions like which reporting processes use AI, how those outputs get validated, and who signed off on the tools in the first place.

Sustainability experts need to treat AI's effect on ESG data quality and reporting integrity as a governance risk in its own right, not a side benefit of faster reporting. Legal and sustainability coverage of 2026 ESG trends notes that leading teams are already adopting agentic AI to manage compliance work and automate structured data tagging for digital filings, which introduces new governance risk that needs board-level oversight, particularly around whether AI-calculated figures such as carbon footprints or supplier risk scores can actually withstand a regulatory audit. Academic research on ESG disclosure adds a sharper warning underneath that: AI can genuinely improve consistency and scale in sustainability reporting, but it can just as easily formalize and speed up existing greenwashing and disclosure inconsistency if nobody is checking the outputs against source data. An ESG report drafted faster by AI is not automatically a more accurate ESG report. Speed and accuracy are different axes, and AI only reliably improves one of them without deliberate human validation on the other.

Data Quality And Governance Are Now Foundational Career Skills

Every one of these functions runs into the same wall eventually: AI performance is entirely dependent on the data underneath it, and weak data governance creates downstream risk across risk management, compliance, and control functions alike. Research on AI-enabled risk management states this almost as a warning label: without good data, AI is just artificial noise, and clear data governance is the foundation of any effective AI-enabled risk program.

That's not an abstract point. Researchers broader work on rebuilding data governance for the AI era describes a real structural problem showing up across organizations right now: legacy governance models built for structured, static data are struggling under the weight of unstructured inputs, AI-generated outputs, and metadata that shifts constantly, which slows adoption and quietly erodes trust in the outputs everyone's relying on.

The career implication is straightforward, even if it's not the sexy part of the AI story. Professionals who can actually improve data lineage, define clear ownership, and set real monitoring standards are becoming more valuable than professionals who only consume AI outputs and take them at face value. Data stewardship used to be a back-office function nobody wanted. It's becoming a leadership qualification, because nobody can trust an AI-generated risk score, audit finding, or ESG figure without someone accountable for the data quality underneath it.

The Career Premium Goes To Domain Experts Who Can Also Supervise AI

Here's where this gets specific and useful, rather than another generic "upskill in AI" pep talk. The premium isn't going to AI generalists. It's going to domain experts, meaning people who already understand risk, compliance, audit, cyber, financial controls, or sustainability deeply, who then add AI oversight capability on top of that existing expertise.

In cybersecurity, this shift already has names attached to it. Coverage of how agentic AI is reshaping security teams describes the classic Level 1 SOC analyst role turning into an AI supervisor role, where the human reviews agent output, tunes agent guardrails, and focuses on the nuanced investigations the agent stack can't handle on its own. Specialized roles like AI governance specialists, focused on regulatory compliance and internal audit of the AI systems themselves, and AI red teamers, focused on finding flaws through adversarial testing, are becoming distinct career tracks rather than side responsibilities bolted onto an existing security job.

Audit and compliance are moving in the same direction, just with different labels. The routine testing and checklist work is what gets automated first. What's left, and what's growing in value, is higher-order advisory and assurance work: helping the organization decide what AI governance should actually look like, not just confirming a checklist got completed.

Role-Specific Lens: What Each Function Should Actually Prioritize

Risk managers should focus on predictive risk models, response control agents, emerging exposures, faster scenario detection, and real-time monitoring rather than static, backward-looking risk registers. The shift from periodic review to continuous, risk-based monitoring is exactly what model risk research describes as the direction traditional frameworks need to move, since AI systems drift constantly rather than occasionally.

Compliance officers should focus on regulatory mapping, policy drift detection, and exception governance, treating regulatory change as a continuous input rather than an annual refresh cycle. Given how unpredictable AI-specific regulation is expected to stay, a compliance function that only reviews policy once a year is already behind by definition.

Auditors should focus on AI-enabled control testing, evidence reliability, and moving up into higher-value assurance work rather than routine transaction testing. The chief audit executive conversation happening right now, according to new audit committee guidance, is explicitly about how the internal audit function's talent strategy and skill sets need to evolve alongside the technology itself.

Cybersecurity experts should focus on AI-assisted defense, automated triage, and building resilient human oversight into every critical decision point, rather than trying to out-manual an attack surface that's now partly automated on the attacker's side too. Guidance on security management is explicit that human-in-the-loop controls for critical decisions are not optional in a mature AI security program.

Financial controllers should focus on automated close accuracy, reporting integrity, and approval chain controls, given that no binding standard yet tells them exactly how to govern this. That absence of a formal rulebook is not permission to wait. It's the reason controllers need to build their own internal governance now, ahead of whatever standard eventually arrives.

Sustainability experts should focus on data quality, ESG process integrity, and AI governance specifically inside reporting workflows, since the value of faster ESG reporting evaporates the moment a regulator or auditor finds a figure that can't be traced back to a reliable source.

Moves That Actually Build Career Resilience Across GRC Roles

Redesign roles around judgment, not task completion. 

AI will keep absorbing routine review work. The durable skill is deciding what still needs a human, not doing every task yourself.

Build AI fluency by function, not generically. 

A generic AI training session teaches nobody anything they can use Monday morning. Risk managers, auditors, controllers, and sustainability teams each need role-specific use cases, controls, and prompts tied to their actual daily workflow.

Make control mapping a core, practiced skill. 

Every AI use case should map to a specific control, approval, piece of evidence, and named owner before it scales past a pilot. Professionals who can translate an AI use case into control language directly reduce operational and regulatory risk, which makes them structurally harder to replace.

Treat data quality as career capital, not a back-office chore. 

The people who can improve lineage, completeness, and governance are becoming the ones organizations can't function without, precisely because AI performance depends entirely on the data feeding it.

Learn to manage mixed human-AI workflows deliberately. 

The future isn't full automation. It's people validating, overriding, and coaching AI systems continuously. Knowing when to trust an output, when to challenge it, and how to document that decision is a skill you have to practice, not one that shows up automatically from using a tool daily.

Build a real specialization moat. 

Broad generalists are easier to automate than specialists who combine deep domain expertise with genuine AI oversight capability. Niches like AI risk, AI audit, AI governance, cyber AI defense, and AI-enabled ESG assurance are where the strongest career positions are opening up right now.

Track task-level exposure, not just headcount. 

If a role is losing routine tasks faster than it's gaining higher-value ones, that's a leading indicator, and leaders need to redeploy people into analysis, control, or advisory work before displacement turns into layoffs nobody saw coming.

Become the translator between the business and the AI. 

The professionals who can explain AI risk, AI value, and AI's actual limits in language executives and regulators understand are the ones who become genuinely difficult to replace, because that translation work connects a technology decision directly to accountability.

Push for internal AI champions inside every function. 

A local champion who tests tools, shares lessons, and surfaces risks quickly helps a team adopt AI safely, and gives individual employees a real path to grow into new responsibilities instead of getting overtaken by change decided somewhere else.

Tie AI adoption directly to workforce strategy. 

AI should never be treated as a separate technology program running alongside the workforce plan. Linking AI investment to reskilling, career paths, and role redesign from the start is what lets a workforce evolve with the tools instead of getting overtaken by them.

What This Actually Means for Your Next Twelve Months

None of this requires you to become a data scientist. It requires you to get specific about the same five questions in every AI-touched process you own: what is the metric, what is the threshold, who owns it, how often is it tested, and what happens when it's breached. If you can't answer all five for a control you claim to have, you don't have a control yet. You have a policy statement waiting to fail its first real test.

Start with one workflow you already own. Map where AI has entered it, name the control that used to catch problems there, and check whether that control actually survived the redesign or quietly disappeared along with the manual task it used to sit inside. That single exercise, repeated across a career instead of done once for a compliance checkbox, is the actual difference between a GRC professional AI displaces and one it makes indispensable.

If you're working through this shift in your own function and want to compare notes on what a real AI-specific control catalog looks like for your specific role, that's exactly the conversation worth having now, before the next audit cycle forces it. Subscribe below for the next piece in this series, where we build out the control catalog for each of these six functions line by line.

SR 26-2 Is Here: The 2026 Model Risk Guidance That Finally Gives Validators Teeth

Article by Prof. Hernan Huwyler, MBA, CPA, CAIO
AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor

Top 10 Responsible AI and Risk Management by Thinkers360

On April 17, 2026, the Federal Reserve, the FDIC, and the OCC (collectively, "the agencies") issued SR Letter 26-2, which replaces prior model risk management guidance, the SR 11-7 issued in 2011. This update refines supervisory expectations regarding how banking organizations should calibrate their model risk management frameworks. The guidance is most directly applicable to institutions with total assets exceeding $30 billion, though smaller institutions with complex modeling activities are advised to consider its principles.

Scope and Applicability

The guidance formally excludes simple arithmetic calculations, deterministic rule-based processes, and notably, generative artificial intelligence and agentic artificial intelligence models from the definition of a model. However, the agencies explicitly state that traditional statistical, quantitative, and non-generative artificial intelligence models remain within scope. The primary audience is organizations with over $30 billion in assets, reflecting a tailored supervisory approach that recognizes the lower inherent risk profiles of most community banking institutions.

What Is Covered and What Is Not

SR 26-2 draws a clean line between two categories of artificial intelligence. On one side, traditional statistical models and non-generative, non-agentic AI models are fully within scope. This includes logistic regression for credit scoring, random forests for fraud detection, gradient boosting for loss forecasting, and any probabilistic model that applies statistical, economic, or financial theories to produce quantitative estimates. On the other side, generative AI such as ChatGPT-style models and agentic AI that makes autonomous decisions are explicitly excluded from the guidance. 

The agencies state these technologies are novel and rapidly evolving, so they are not covered here. Simple spreadsheet arithmetic and deterministic rule-based processes with no statistical underpinning are also excluded. For practitioners, this means the bank existing credit risk, market risk, and stress testing models remain subject to the full model risk management framework, while the internal productivity chatbots do not.

How to Treat Probabilistic and AI Models in Practice

For probabilistic models and non-generative AI, the guidance applies the same materiality-based framework as any other quantitative model. U.S. banks under scope must assess each model using two dimensions: exposure (portfolio size and financial impact) and purpose (regulatory significance or critical risk decisions). A machine learning fraud detection model affecting $50 million in transactions may require less rigor than a smaller logistic regression model used for regulatory capital calculations, if the latter serves a more critical purpose. The key operational change is that validators of AI models must now have organizational standing to effect change, not just technical expertise. 

For probabilistic models with inherent uncertainty, banks must document assumptions explicitly and monitor performance drift continuously, not annually. Vendor-supplied AI models receive no lighter treatment; proprietary black-box constraints do not excuse banks from validating conceptual soundness. If a vendor will not provide transparency into model design, development data, or assumptions, banks must either conduct independent back-testing using the internal own data or limit the model to immaterial use cases.

Main Changes and Technical Nuances

The most significant departure from prior guidance is the formal introduction of a materiality-driven framework. Rather than applying uniform rigor to all models, the agencies now require banking organizations to evaluate model risk through two distinct lenses:

1. Model Exposure: The quantitative significance of a model's output to business decisions, typically measured by portfolio size or financial impact.

2. Model Purpose: A qualitative assessment of whether the model supports regulatory requirements or manages critical financial risk exposures.

The interaction of exposure and purpose determines model materiality, which then dictates the depth of validation, monitoring, and governance required. Immaterial models require only identification and periodic monitoring for changes in conditions that could elevate their status. Conversely, higher materiality models warrant comprehensive and rigorous oversight throughout the lifecycle.

The guidance also introduces a more explicit expectation regarding aggregate model risk. Institutions must assess risk not only at the individual model level but also across portfolios of models. This includes evaluating dependencies, common assumptions, shared data sources, and correlated methodologies that could cause simultaneous failures. A single point of weakness in a shared data pipeline, for example, could manifest as aggregate risk across multiple high-stakes models.

Effective Challenge and Independence

The agencies reinforce the concept of effective challenge as a non-negotiable component of sound governance. Effective challenge is defined as critical analysis performed by objective experts who possess the technical competence to evaluate model risk, sufficient independence to maintain objectivity, and the organizational standing to compel changes. This elevates the requirement beyond mere peer review to a governance mechanism with teeth. Validation functions must be structured to avoid conflicts of interest, particularly misalignment of incentives between model development and validation reporting lines.

Vendor and Third-Party Products

A critical clarification addresses vendor and third-party models. The guidance states that the use of proprietary products, including those where underlying code or methodology is inaccessible, does not diminish the banking organization's risk management responsibilities. Validation of vendor models must include an assessment of conceptual soundness, design, development data, and ongoing performance. Customizations made to vendor models for specific business needs must be documented, justified, and evaluated as part of validation. The inability to inspect proprietary elements is not an acceptable basis for reducing validation rigor.

Model Development, Validation, and Monitoring

The guidance formalizes three components of validation:

• Conceptual Soundness: Assessing model design, assumptions, qualitative judgments, and data selection.

• Outcomes Analysis: Comparing model outputs to real-world results, including back-testing and outlier analysis.

• Ongoing Monitoring: Evaluating performance against changing products, exposures, data relevance, and market conditions.

Notably, the guidance permits limited circumstances where a model may be used prior to completion of validation, such as an urgent business need. In such cases, the institution must apply heightened attention to model limitations, inform relevant stakeholders, and implement compensating controls including usage limits and closer performance monitoring.

Governance and Documentation

The agencies expect a comprehensive model inventory that supports risk management at both individual and aggregate levels. Documentation must be adequate to ensure continuity of operations, track recommendations and exceptions, and support remediation efforts. Internal audit functions are expected to evaluate the effectiveness of model risk management practices rather than duplicate validation activities.

Enforceability Context

While the guidance explicitly states that non-compliance will not result in supervisory criticism standing alone, the agencies preserve their authority to take action for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk. Practically, this means the guidance defines the supervisory baseline. Deviations from its principles will be cited as evidence of inadequate risk management in the event of a model failure or material loss.

Implications for GRC Professionals

The 2026 guidance signals a maturation of model risk management from a technical validation exercise to an integrated governance discipline. GRC professionals should prioritize three actions: first, implementing a tiered inventory that clearly distinguishes material from immaterial models; second, assessing aggregate risk across model portfolios, particularly where shared assumptions or data sources exist; and third, reviewing vendor management agreements to ensure that contractual terms do not impede the validation and ongoing monitoring required by the agencies. The exclusion of generative and agentic artificial intelligence is temporary; the principles articulated in this guidance will likely inform future supervisory expectations as those technologies evolve.

Critical Implications of the Revised Model Risk Management Guidance (SR 26-2)

Four Critical Changes for Risk Managers

1. Redesign Model Tiering Using Dual-Axis Materiality Assessment

Risk managers must now classify all AI predictive models using both exposure (quantitative portfolio impact) and purpose (qualitative regulatory or risk significance), replacing single-dimension risk ratings. This materiality-based framework means a fraud detection AI model affecting $50M in transactions may warrant less rigor than a $10M credit decisioning model if the latter supports regulatory capital calculations. Organizations must rebuild model inventories to document both dimensions, as immaterial models by exposure may still be material by purpose. The tiering directly determines validation depth, monitoring frequency, and governance escalation pathways for each AI risk model.

2. Establish Effective Challenge with Organizational Authority

Validators of AI predictive models must now possess not only technical expertise but demonstrable organizational standing and influence to effect change, moving beyond advisory roles. Risk managers must restructure validation teams to ensure challengers can delay model deployment, escalate concerns to executive committees, and mandate remediation with teeth. This represents a fundamental shift from validation as documentation exercise to validation as governance gate, particularly critical for complex AI models where technical reviewers previously lacked business authority. Second-line model risk functions must now be empowered to override first-line deployment timelines when AI model risks are inadequately addressed.

3. Implement Rigorous Vendor Risk Model Governance

Third-party AI models for credit scoring, fraud detection, or risk forecasting no longer receive lighter treatment despite proprietary limitations, requiring the same conceptual soundness validation as internal models. Risk managers must negotiate with vendors for sufficient transparency into model design, development data, assumptions, and performance metrics to conduct meaningful validation, even when source code is unavailable. Ongoing monitoring and outcomes analysis are now explicitly required for vendor AI models, including documentation of any overlays or adjustments made to customize outputs. Where vendors cannot provide adequate validation evidence, risk managers must either conduct independent testing using the bank's own data or limit the model's application to lower-materiality use cases.

4. Deploy Continuous Model Monitoring Infrastructure

Ongoing monitoring is elevated from periodic review to continuous evaluation, requiring risk managers to implement real-time performance tracking for material AI predictive models across changing data distributions and market conditions. Monitoring frameworks must now explicitly assess whether AI models remain fit-for-purpose as products, client bases, or economic environments shift, with predefined thresholds triggering recalibration or redevelopment. Risk managers must establish outcomes analysis comparing AI model predictions to actual results (back-testing) as a standard validation component, not an optional add-on, particularly for models relying on expert judgment or alternative data. The guidance mandates documentation of model deterioration triggers and response procedures, forcing proactive governance rather than reactive remediation when AI risk models fail.

Priority Actions for SR 26-2 Compliance

1. Materiality Triage

Large U.S. banks should redesign model inventories around purpose and exposure, not a single generic risk score. The guidance is explicit that model materiality depends on the business importance of the use case and the significance of the output to decisions, including regulatory and financial risk use. For predictive AI models, credit loss, fraud, liquidity, and capital-related use cases should be tiered above internal analytics or convenience models. Common practice still overweights model complexity and underweights business consequence; that should be corrected.

2. Challenge Authority

Banks should formalize effective challenge as a control with authority, not as a review function. The guidance requires challengers to have sufficient expertise, independence, organizational standing, and influence to effect change throughout the model lifecycle. That means validation functions need documented rights to delay launch, require remediation, and escalate unresolved issues to executive governance forums. Common advice tends to treat validation as commentary; that is not defensible under this guidance.

3. Continuous Monitoring

Scoped banks should move material predictive AI models to ongoing monitoring with explicit deterioration triggers. The guidance requires monitoring for changes in products, exposures, activities, clients, data relevance, and market conditions, and it states that material deterioration may warrant overlays, adjustment, or redevelopment. Monitoring should therefore include pre-defined thresholds for drift, performance decay, and segmentation instability, not just periodic reporting. Common practice often relies on quarterly review cycles; that is too slow for models embedded in live decisioning flows.

4. Third-Party Validation

Banks should validate vendor and other third-party predictive models to the same conceptual standard applied to internally developed models. The guidance states that proprietary constraints do not remove the need to understand design, development data, assumptions, and performance. Where source code is unavailable, banks need compensating controls such as benchmarking, documented customization review, independent testing, and ongoing outcomes analysis. Common advice often treats SOC reports or vendor attestations as sufficient coverage; they are not.

5. Use Expansion Gate

Banks should treat any extension of model use as a new risk event requiring formal review. The guidance states that using a model beyond its intended purpose introduces additional uncertainty and requires additional analysis of limitations and controls. That means a predictive model approved for one portfolio, channel, or decision layer should not be repurposed without re-validation and governance sign-off. Common practice often extends models through informal business requests; that is a control weakness, not agility.

6. Aggregate Risk Map

The banks under scope should maintain a live inventory that maps individual and aggregate model risk, including shared data, assumptions, and dependencies. The guidance specifically calls out aggregate risk arising from interactions among models and from common methodologies or inputs that can fail simultaneously. For predictive AI models, that inventory should also identify upstream data feeds, shared calibration logic, and correlated override points. Common advice tends to validate models in isolation; that misses the concentration risk the guidance now makes explicit.

---

About the Author:

Hernan Huwyler is a risk and compliance executive who advises financial institutions on model risk management, AI governance, and control frameworks. He has led validation functions for global banks and regularly writes on the intersection of quantitative risk and regulatory compliance.

#ModelRiskManagement, #SR262, #SR117, #ModelValidation, #EffectiveChallenge, #AIModels, #RiskGovernance, #ModelRisk, #VendorRiskManagement, #FinancialRegulation, #FederalReserve, #FDIC, #OCC, #GRC, #Compliance, #RiskManagement, #AIGovernance, #ModelMateriality, #SecondLineOfDefense, #BankingRegulation

How to Stop Producing Risk Registers Nobody Uses

Article by Prof. Hernan Huwyler, MBA, CPA, CAIO
AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor

Top 10 Responsible AI and Risk Management by Thinkers360

The Painful Gap Between Risk Reporting and Risk-Informed Decisions

Most Enterprise Risk Management programs fail in the same quiet way. They produce polished registers, colorful heat maps, and quarterly reports that look impressive in board packs. Then the organization makes its next major capital allocation, acquisition, or vendor choice using a single-page summary with one projected number and zero reference to the risk framework that consumed thousands of hours to build.

I've watched this pattern destroy the credibility of risk functions across industries. The risk team works hard. Stakeholders get interviewed. Likelihood and impact get scored. And none of it touches the actual decisions that determine whether the organization wins or loses. The gap between risk reporting quality and decision quality is where ERM programs go to die.

This article addresses that gap directly. It provides a stage-by-stage implementation approach for building an ERM program that changes how your organization decides, plans, and allocates resources. Every recommendation comes from field-tested practice, not theory. If your ERM program currently produces documents that live in SharePoint between annual reviews, this post shows you how to fix that.

Core Framework: The Three Pillars of Decision-Driven ERM

Effective ERM that actually changes decisions rests on three pillars. Each one addresses a different failure mode I've seen repeatedly in organizations that mistake activity for impact.

Pillar 1: Risk-Informed Performance Management

ERM must live inside the performance management system, not alongside it. This means every major risk links to at least one strategic objective and KPI. When risk shows up in performance reviews and operating rhythms, people pay attention. When it lives in a separate portal, they don't.

The most common failure here is creating the linkage on paper but not in practice. I worked with one organization that mapped all 35 risks to strategic objectives in their GRC platform. Beautiful mapping. But the quarterly business reviews still used a completely separate slide deck with no risk content. The fix was simple but politically difficult: we added a mandatory "risk and assumption" section to the existing QBR template and made the business unit head (not the risk team) responsible for completing it. Adoption jumped from near zero to 80% within two quarters because the accountability sat with the person who owned the performance conversation.

Pillar 2: Risk Analysis Embedded in Decision Workflows

Every significant decision, from capital expenditure approvals to vendor selections to product launches, must include explicit risk reasoning. Not a generic "risk section" pasted at the end of a business case. A structured analysis of key assumptions, downside scenarios, and alignment with risk appetite.

o not try to retrofit risk analysis into existing decision workflows by adding a new form or approval gate. That creates resentment and checkbox behavior. Instead, redesign the decision paper template itself. Add three mandatory questions directly into the body of the document: "What are the top three assumptions this recommendation depends on?" "What happens if each assumption is wrong?" "How does this fit within our stated risk appetite?" When these questions sit inside the template that decision-makers already complete, risk thinking becomes part of the work rather than extra work.

Pillar 3: Distributions Replace Point Estimates

Organizations addicted to single "best guess" numbers make systematically overconfident decisions. Fighting this addiction requires replacing point estimates with ranges, scenarios, and probability distributions for all material assumptions.

Do not try to convert every number in your organization to a distribution. Start by identifying "high-leverage assumptions," the five or six variables that most affect NPV, margin, schedule, or safety in your biggest decisions. Convert those to three-point estimates (minimum, most likely, maximum) first. I made the mistake early in my career of trying to build full stochastic models for everything. The result was analysis paralysis and skepticism from leadership. Starting with just the high-leverage variables keeps the effort manageable and produces results that are visually obvious to executives who have never seen a tornado chart before.

Stage 1: Reframe ERM and Align It to the Business Cycle

The first implementation stage kills the annual risk assessment ritual and replaces it with a rolling cadence tied to how the business actually operates.

Map your organization's existing planning calendar: budgeting cycle, strategy refresh, product roadmap reviews, capital planning windows. Then attach risk input as a standard step in each of those existing processes. Risk analysis during budgeting means budget assumptions get challenged. Risk analysis during strategy refresh means strategic bets get stress-tested. Risk analysis during product roadmap reviews means launch decisions include downside scenarios.

The responsible party for each touchpoint is the business owner, not the risk function. The risk function sets the method, provides tools, and samples for quality. But the business leader presents the risk view alongside the performance view. This matters because risk ownership that sits with a central function creates a dynamic where business leaders treat risk as "someone else's job."

What to do: Collapse your risk inventory from whatever unwieldy number it has grown to (I've seen 200+) down to 10 to 20 enterprise-level risks with clear aggregation logic. Local risks roll up into enterprise themes. The board sees 15 risks, not 150. Business units manage their local registers, but reporting flows upward through defined aggregation rules.

The hardest part of this stage is getting the CEO and CFO to agree that risk content belongs in existing performance forums rather than in separate risk committee meetings. I've found the most effective argument is financial: show them a past decision where a single-point estimate led to a materially different outcome than what a range-based analysis would have predicted. One concrete example of a budget miss or project overrun that was foreseeable with basic scenario analysis does more to shift executive behavior than any amount of framework documentation. Find that example in your own organization's recent history. It exists. I guarantee it.

Stage 2: Build Risk Analysis Into Decision Templates and Workflows

This stage addresses the specific mechanics of getting risk reasoning into the documents and approval processes that govern major decisions.

Start by mapping every "decision point" where risk analysis should be mandatory. Board approvals. Capital investments above a defined threshold. Acquisitions. Large contracts. Major technology choices. Key product or market entry decisions. For each type, define a minimum level of analysis. Small decisions get a short qualitative checklist. Large, irreversible, or high-uncertainty bets get full quantitative modeling.

For every significant contract, investment, or vendor choice, attach a one to two page mini risk assessment. The template should cover: objectives, key assumptions, top five risks with likelihood and impact ratings, existing controls, residual risk rating, and proposed mitigations. This format works because it's short enough to complete in an hour but structured enough to surface real issues.

Standardize quick techniques for smaller assessments: what-if questions, simple decision trees, bow-tie diagrams, or 5x5 matrices. Reserve deeper tools like FMEA, HAZOP, or fault-tree analysis for complex technical or safety-critical decisions. Set clear thresholds (contract value, strategic impact, irreversibility, public or ESG exposure) that trigger the more advanced assessment. This way your organization runs dozens of mini-assessments per month with sensible prioritization, not bureaucratic uniformity.

Require that any recommendation comparing Option A to Option B includes risk-adjusted reasoning. Not just base-case numbers. The proposal must show what happens to each option under stress. Which option breaks first? Which option has a wider range of possible outcomes? This single requirement forces genuine analytical thinking and prevents the common dysfunction where the "highest NPV" option wins by default even when its returns depend on a single fragile assumption.

Watch out for "fake risk-based" methods. I've audited vendor and contract risk methodologies across multiple organizations and found that many rely on uncalibrated scoring, arbitrary matrices, or vague checklists that produce a number but do not actually improve the decision. The test is simple: can you show me a specific instance where this risk methodology changed the selection of a vendor, the structure of a contract, or the design of a project? If the answer requires more than 30 seconds of thought, the methodology is theater. Replace it with structured identification, explicit assumptions, harmonized scales, and wherever possible, quantification tied to financial or operational impacts.

Stage 3: Replace Point Estimates With Ranges and Simulations

This is where decision-driven ERM gets quantitatively serious. Most organizations plan using single numbers for exchange rates, commodity prices, demand volumes, system uptime, and dozens of other variables. Every experienced professional knows these numbers are wrong. But the organization plans as if they're certain, then acts surprised when reality differs.

For key drivers, require ranges or probability distributions instead of single numbers. Start with three-point estimates (minimum, most likely, maximum) because they're intuitive and fit into existing spreadsheet workflows. Show P10, P50, and P90 outcomes next to the traditional single case. Standardize a small set of "risk views" for every major item: base case, conservative (P80 to P90), aggressive (P20), and stress case. Make approval documents reference which profile management is accepting.

For large projects, site selections, portfolio decisions, and annual budgets, run Monte Carlo simulations on the combined distributions of key assumptions. Report results in terms executives can act on: probability of loss, probability of meeting budget or schedule, value at specific percentiles, and which variables contribute most to variance. Tornado charts that show "FX drives 40% of your outcome variance" focus mitigation efforts far better than a color-coded heat map ever could.

Build simple internal libraries of typical distributions for recurring drivers. FX volatility ranges. Load factor distributions. Failure rate curves. Price curve bands. When teams can reuse validated assumptions instead of inventing numbers from scratch, the quality of analysis goes up and the time required goes down. I spent months building these libraries at one organization and it cut the time to produce a quantified risk view from two weeks to three days.

The cultural shift matters more than the technical one. I watched a capital allocation committee change their decision after seeing simulation output for the first time. The "highest NPV" option had a 35% probability of delivering negative returns once you modeled realistic input ranges. The second-ranked option had lower expected returns but only a 12% probability of loss. They chose robustness over optimism. That single moment did more to establish the credibility of quantitative risk analysis than two years of framework presentations. Find your version of that moment. Run the simulation on a decision that's already been made and show leadership what they would have seen if they'd had this view at the time. The reaction will tell you whether your organization is ready.

Stage 4: Governance, Ownership, and Culture Infrastructure

Without accountability structures, everything in the previous three stages degrades within 12 months. I've seen it happen. An organization builds beautiful decision templates, runs impressive simulations, and then slowly reverts to old habits because nobody's performance goals include risk-adjusted outcomes.

Define risk ownership at the level of specific "risk objects": products, processes, portfolios, or business units. Each risk object gets a named owner. That owner's performance goals explicitly include risk-adjusted outcomes. Not just revenue. Not just volume. This connects risk management to compensation and career progression, which is the only reliable driver of sustained behavior change.

Run short monthly "risk clinics" with each business unit. These replace the annual committee meeting that tries to cover everything and covers nothing well. In a 60-minute clinic, review changes in the unit's risk profile, challenge key assumptions, and adjust plans. The risk function facilitates. The business unit leads. Keep the format consistent: what changed since last month, what are the top three risks to this quarter's objectives, what decisions are coming up that need risk input.

Build an explicit expectation that major decisions (capex approvals, acquisitions, product launches, outsourcing) must reference key risks and mitigations from the ERM system. Treat the absence of this reference as a process failure. Not a documentation gap. A process failure that gets flagged in the same way a missing financial approval would get flagged. This is a governance design choice that signals organizational seriousness.

The single most common dysfunction I see in ERM governance is the "risk owner in name only" pattern. Someone's name appears next to a risk on the register, but their actual performance review, bonus criteria, and promotion case make zero reference to how they managed that risk. The fix requires executive sponsorship from the CEO or CFO to mandate that risk-adjusted KPIs appear in performance scorecards for anyone who owns a top-20 enterprise risk. Without this, risk ownership is decorative. I failed to get this done at one organization because I tried to push it through the risk committee instead of the compensation committee. The lesson: risk ownership is a people and incentives problem, not a risk framework problem.

 Implementation Tips

These four tips apply across all stages and address the patterns that most commonly cause decision-driven ERM programs to stall or revert.

Tip 1: Maintain Method Integrity Over Time

Original implementation tip: ERM methods degrade naturally. Templates get shortened. Simulation steps get skipped when deadlines are tight. Scoring scales drift as new people join and interpret criteria differently. Schedule a semi-annual "method health check" where the risk function reviews a sample of recent decision papers, mini-assessments, and simulation outputs against the defined standards. Flag deviations. Retrain where needed. Publish a short "quality scorecard" that shows which business units are maintaining standards and which are slipping. Transparency creates peer pressure that formal compliance never matches.

Tip 2: Handle the "Risk Champion" Role Carefully

Original implementation tip: Many organizations appoint "risk champions" in each business unit to act as liaisons with the central risk function. This works when champions have genuine credibility and seniority in their unit. It fails when the role gets assigned to the most junior person available or treated as administrative overhead. Require that risk champions hold a position at least one level below the unit head. Give them explicit time allocation (minimum 10% of their role). Include champion effectiveness as a factor in their performance review. I've seen champion networks transform ERM adoption when they're staffed with respected operators. I've seen them become an excuse for everyone else to ignore risk when they're staffed with interns.

Tip 3: Document Decision Rationale, Not Just Decision Outcomes

Original implementation tip: Create a simple "decision record" template that captures: the options considered, the risk analysis for each option, the trade-offs discussed, the risk appetite alignment, and the rationale for the final choice. Store these records in a searchable repository. Review a sample annually to check whether risk information was captured, how it influenced the choice, and how outcomes compared to expectations. This feedback loop is where organizational learning happens. Most organizations skip it entirely. The ones that do it consistently develop a pattern-recognition capability that makes future decisions measurably better. One organization I worked with found that 60% of project overruns in a three-year sample traced back to the same two assumption categories that were consistently treated as deterministic when they should have been modeled as ranges.

Tip 4: Be Skeptical of Dashboard-First GRC Platforms

Original implementation tip: Before committing to any ERM or GRC platform, ask the vendor one question: "Show me three examples where your platform's output changed an actual decision at a client organization." If they can only show you dashboards, taxonomies, and workflow automations, proceed with extreme caution. The best platforms provide centralized risk repositories, standardized taxonomies, automated data feeds from incidents and audit findings, scenario analytics, and integration with the BI tools and project portfolio systems your leaders already use daily. The worst platforms produce beautiful screens that no decision-maker ever opens. Run a pilot focused on one specific decision type before scaling. Measure whether the pilot improves option selection or outcome quality, not just reporting speed.

Key References

The following standards and frameworks provide authoritative guidance for building decision-driven ERM programs:

ISO 31000:2018, Risk Management Guidelines, provides the foundational principles and process for integrating risk management into organizational governance and decision-making

COSO ERM Framework (2017), Enterprise Risk Management: Integrating with Strategy and Performance, directly addresses the linkage between risk management and strategic planning

IEC 31010:2019, Risk Assessment Techniques, catalogs and guides the selection of specific risk assessment methods (Monte Carlo, FMEA, bow-tie, fault tree, and others) matched to decision context

ISO 31022:2020, Guidelines for the Management of Legal Risk, extends risk management principles to legal and contractual decision-making

NIST Risk Management Framework (SP 800-37), while focused on information systems, provides a strong model for embedding risk analysis into system acquisition and authorization decisions

The Orange Book (HM Treasury, UK), Managing Public Money risk guidance, offers practical templates for integrating risk analysis into investment and spending decisions

IIA Three Lines Model (2020), provides the governance structure for separating risk ownership, risk oversight, and independent assurance

Closing

When ERM stays a compliance artifact, it consumes budget, absorbs staff time, and produces documents that create an illusion of control. Decisions continue to rely on single-point estimates, gut feel, and the loudest voice in the room. The risk register gets updated annually, presented quarterly, and referenced never. The organization pays the full cost of risk management and receives almost none of the benefit.

When ERM operates as a living decision system, every major choice carries an explicit view of uncertainty, a structured comparison of options under stress, and a clear statement of which risks leadership is consciously accepting. The risk register becomes a hub connected to controls, incidents, KPIs, and projects. Simulations replace single guesses. Performance conversations shift from "you missed the number" to "where did we land in the distribution, and what did we learn?" The difference between these two states determines whether your organization manages risk or merely documents it.

What's one major decision your organization made in the last year that would look completely different if someone had modeled the downside honestly?

Skills for Compliance Officers, Risk Managers, and Auditors

7 Career Capabilities That Will Separate Compliance Officers Who Thrive in 2026 From Those Who Get Replaced by Algorithms

ING just announced 1,250 job cuts in its compliance operations. ABN Amro plans to replace 35% of its AML division with AI. The Dutch audit office published a report questioning whether the €1.4 billion the banking sector spends annually on anti-money laundering checks actually produces effective outcomes.

Read that last sentence again. The government auditor is asking whether the entire manual compliance model works.

This is not a future scenario. This is happening now, across multiple banks, in one of Europe's most regulated markets. And it raises a question that every compliance officer, risk manager, and internal auditor should be asking themselves today: if my primary value comes from executing manual processes that AI can do faster and more consistently, what exactly is my professional future?

The answer depends entirely on skills. Not certifications. Not years of experience. Skills.

I have spent the last fifteen years working with compliance functions across financial services, industrials, and technology companies. The pattern I see repeating is consistent: the professionals who can quantify risk, challenge AI outputs, and translate regulatory complexity into financial terms the business can act on are becoming more valuable every quarter. The ones who built careers around checklist execution, manual alert processing, and qualitative risk scoring are watching their roles disappear. Sometimes gradually. Sometimes overnight.

This post identifies the seven skills that will define professional survival and advancement in compliance, risk, and audit roles through 2026 and beyond. Each one is grounded in what I see organizations actually hiring for, paying premiums for, and struggling to find.

 

Quantification: The Skill That Changes Everything

Here is the dividing line. A compliance officer who says "this risk is high" is offering an opinion. A compliance officer who says "the expected annual loss from this obligation failure is €2.3 million, with a severe but plausible exposure of €9.6 million at the 95th percentile" is offering a decision.

Boards act on the second one. They file the first one.

Quantification means expressing compliance exposure in currency. Expected annual loss. Value at Risk. Conditional Value at Risk. Return on compliance investment. Loss exceedance curves. These are not exotic financial instruments. They are the basic vocabulary of every other risk function in the organization. Credit risk quantifies. Market risk quantifies. Operational risk quantifies. Compliance still shows up with colors.

The Dutch audit office report captures the consequence of this gap perfectly. The Netherlands spends €1.4 billion per year on AML compliance. Nobody can demonstrate whether it works. That is what happens when a function operates for decades without measuring its own effectiveness in terms that finance and strategy teams can use.

Original implementation tip: Start with your five most material compliance obligations. For each one, estimate a frequency (how often could this go wrong, expressed as events per year) and a severity range (what would it cost when it does, expressed as a currency interval with a confidence level). Feed those into a compound Poisson-Lognormal Monte Carlo simulation. You can do this in a free Google Colab notebook with code available on GitHub. No statistics degree required. The output is a loss distribution that tells you more about your compliance exposure in one afternoon than your entire qualitative risk register has told the board in the last five years.

Judgment: The One Thing AI Cannot Automate

AI can process 10,000 transaction alerts in the time it takes a human analyst to review three. It can scan contracts for misaligned clauses, monitor sanctions lists in real time, and flag anomalous expense patterns across the entire organization.

What it cannot do is decide.

An AI model that flags a suspicious transaction has produced a signal. Whether that signal warrants investigation, escalation, a suspicious activity report, or closure with documented rationale requires judgment. Judgment about regulatory expectations in that specific jurisdiction. Judgment about the customer relationship and its commercial context. Judgment about whether the pattern represents genuine risk or a false positive that, if escalated, would waste investigative resources and potentially harm a legitimate customer.

The Dutch audit office report noted that the current system of strict AML controls "does not always lead to useful investigations" and can have "serious consequences for ordinary people." That is a judgment failure, not a technology failure. The controls generated activity. Nobody ensured the activity produced outcomes.

When ING reduces 1,250 FTEs and shifts to AI-driven processing, the compliance professionals who remain need better judgment than the ones who left. They are handling the cases that the algorithm could not resolve. They are calibrating the thresholds that determine what the algorithm escalates. They are explaining to the regulator why a particular decision was made. Every one of those tasks requires experience, context, and the ability to exercise discretion under uncertainty.

Original implementation tip: When you review an AI-generated alert or risk flag, document not just your decision but your reasoning. Write two sentences explaining why you escalated or closed the case. After twelve months, review those documented rationales. You will find patterns in your own judgment that improve future decisions and create an auditable record that regulators value far more than a closed-case count.

AI Fluency: Working With the Machine, Not Around It

AI fluency for compliance professionals has nothing to do with writing code. It has everything to do with understanding what the model is doing well enough to trust it where it is reliable and challenge it where it is not.

This means knowing how to ask the right questions. What data was the model trained on? What assumptions drive the alert thresholds? Where are the known blind spots? What is the false positive rate, and what is the cost of each false positive in analyst time? What happens when the input data quality degrades?

I worked with a financial institution that deployed an AI-powered transaction monitoring system. The compliance team treated it as a black box. Alerts came in, analysts processed them, case counts went into the quarterly report. Nobody asked whether the model was actually catching the right things. When an external review tested the system against known typologies, the detection rate for a specific category of trade-based money laundering was below 12%. The model was generating thousands of alerts for low-risk patterns while missing the high-risk ones entirely.

The compliance team did not lack intelligence or dedication. They lacked the fluency to interrogate the tool they were using every day.

Original implementation tip: Ask your technology team to show you the model's confusion matrix for the last quarter. It will tell you how many true positives, false positives, true negatives, and false negatives the system produced. If nobody can produce this information, you have a tool, but you do not have a control. A control you cannot measure is a control you cannot defend.

Regulatory Mapping: Conflicts, Overlaps, and the Before-the-Fact Discipline

Regulatory fluency in 2026 is not about memorizing rules. It is about mapping obligations across jurisdictions, identifying conflicts before they create exposure, and translating regulatory expectations into operational requirements that the business can actually execute.

The complexity is real and accelerating. The EU AI Act imposes requirements on high-risk AI systems that may conflict with data minimization principles under GDPR. Cross-border data localization requirements in one jurisdiction clash with centralized processing mandates in another. Anti-corruption reporting thresholds differ between the FCPA, the UK Bribery Act, and local legislation in every market where the organization operates.

A compliance officer who can identify these conflicts, quantify the exposure on each side, and recommend a documented compliance path with a defensible rationale is providing strategic value. One who simply flags the conflict and asks the business to "seek legal advice" is adding a step to the process without reducing risk.

The most important application of regulatory fluency happens before the organization accepts the obligation. Before signing the contract. Before announcing the ESG commitment. Before entering the new market. Before launching the AI-powered product. At that point, terms can be changed, commitments narrowed, controls built first, and deal structures adjusted. Once the promise is made, the options get slower and more expensive.

Original implementation tip: For every new market entry, major contract, or public commitment, create a one-page obligation conflict map. List the top five obligations the decision creates. For each, identify whether any conflict exists with obligations in other jurisdictions where the organization operates. Where conflicts exist, quantify the exposure for each compliance path and document the chosen approach with its rationale. This single artifact will be the most valuable document in your file if a regulator ever asks why you chose one path over another.

Making Your Decisions Defensible

A compliance decision that cannot be reconstructed and explained six months later is not a decision. It is a liability.

Evidencing is the discipline of documenting risk assessments, treatment decisions, control design rationale, and residual risk acceptance in a way that creates a defensible record. Not for the sake of documentation, but because regulators, auditors, and courts evaluate compliance programs based on what can be demonstrated, not what was intended.

ISO 37301 explicitly links a robust compliance management system to evidence of due diligence that can mitigate corporate liability. In jurisdictions that recognize effective compliance programs as a mitigating or exonerating factor (Spain, France, Brazil, the UK, and increasingly the US through DOJ guidance), the quality of your evidence directly affects the severity of your sanctions.

I have seen organizations with excellent compliance programs receive harsh regulatory treatment because they could not produce the documentation to prove what they had done. And I have seen organizations with modest programs receive favorable treatment because they could demonstrate a clear, documented chain of risk assessment, decision, control, and monitoring.

The difference was not the quality of the compliance work. It was the quality of the evidence.

Original implementation tip: For every risk that exceeds your stated tolerance, create a treatment decision record with five elements: the quantified exposure before treatment, the treatment option selected with its cost, the expected reduction in exposure, the residual risk explicitly accepted, and the name and level of the person who approved the acceptance. This record takes ten minutes to create and can save millions in regulatory proceedings.

Spending Where It Matters

Compliance budgets are finite. The obligation universe is not. Every organization faces more compliance requirements than it can address with maximum intensity simultaneously. The skill that separates effective compliance leaders from overwhelmed ones is the ability to allocate resources where the expected loss reduction justifies the cost.

This sounds obvious. Watch how many organizations skip it.

The standard approach is to apply roughly uniform compliance intensity across all obligation domains, driven by checklist coverage rather than risk-weighted exposure. The result is predictable: the organization spends heavily on low-risk obligations where the expected loss is modest and underinvests in high-risk obligations where the expected loss is material. The qualitative risk register cannot reveal this misallocation because it does not express exposure in comparable units.

The return on compliance investment formula is simple. Take the reduction in expected annual loss attributable to a control, subtract the annual cost of the control, divide by the annual cost of the control. If a new automated monitoring system costs €400,000 per year and reduces expected annual AML-related compliance losses from €2.8 million to €1.5 million, the ROCI is 225%. That is a compelling business case expressed in language that finance teams understand and approve.

Every compliance budget request should be framed this way. "This €200,000 investment reduces our expected annual loss by €750,000" works. "We need this because the regulation requires it" does not.

Original implementation tip: Rank your top ten compliance obligations by expected annual loss. Then rank them by current compliance spending. Compare the two lists. In my experience, the correlation is disturbingly low. The mismatch between where you spend and where your exposure actually sits is the single highest-value finding your quantitative risk assessment will produce.

Speaking the Language of the Business

Every skill described above becomes useless if the compliance officer cannot communicate findings in terms that decision-makers act on. Translation is the ability to convert regulatory complexity, risk quantification, and control recommendations into the financial and operational language that executives, boards, and business unit leaders use to make decisions.

Decision-makers act on euros. They do not act on risk ratings. They do not act on colors. They do not act on compliance jargon.

A compliance officer who tells the board "we have 47 high risks" has produced information that prompts no specific action. A compliance officer who tells the board "our expected annual compliance loss is €4.2 million, with a P80 exposure of €8.1 million and a tail at P99 of €95 million, and our current reserves cover only to the 55th percentile" has produced a statement that triggers a budget discussion, an insurance review, and a strategic conversation about which obligations create the most exposure.

The difference between these two presentations is not sophistication. It is professional utility. The first produces documentation. The second produces decisions.

Original implementation tip: Before every board or committee presentation, test your key message against this question: "Can a CFO act on this statement without asking for additional information?" If the answer is no, rewrite it until the answer is yes. Replace "high risk" with a currency range. Replace "significant exposure" with a percentile from your simulation. Replace "we recommend enhanced controls" with "this €300,000 investment reduces our P80 exposure from €8 million to €3.5 million." The reaction in the room will change immediately.

Understanding the 2026 skills model for GRC roles

The mistake many firms make is treating future skills as a training catalogue problem.

It is not.

This is a control model problem, a governance design problem, and a workforce economics problem. Once AI and automation take over repetitive tasks, the remaining human work changes shape. That means the required skills also change shape. Fast.

A useful way to think about this is through three buckets.

Transferred skills

These are the capabilities that still anchor professional credibility.

Regulatory judgment still matters. Ethical judgment still matters. Clear documentation still matters. Institutional memory still matters. If you cannot explain why a decision was made, or what a regulator is likely to focus on, no analytics tool will save you.

Original implementation tip: do not treat legacy expertise as “old knowledge.” Extract it systematically. Build decision logs from experienced staff before attrition or restructuring removes your best practical judgment.

Sharpened skills

These are existing skills that now need a higher level of precision.

Communication is the best example. In 2026, compliance, risk, and audit professionals must explain complex risks to business leaders who are moving faster, using more technology, and tolerating less ambiguity. The old style, long memos, defensive language, generic caveats, gets ignored.

Risk prioritization also sits here. You now need to distinguish quickly between a control issue, a design issue, a model issue, and a real exposure issue.

Original implementation tip: if your team still writes findings that cannot be converted into a business decision within five minutes, your communication model is already outdated.

New skills

This is where the real shift sits.

Data literacy. AI oversight. Workflow design. Model skepticism. Cross-border digital regulatory fluency. These were once specialist capabilities. They are becoming baseline skills for high-value governance roles.

This does not mean every compliance officer must code, every auditor must become a data scientist, or every risk manager must build models. It means they must understand enough to challenge outputs, spot weak assumptions, and defend positions under scrutiny.

Original implementation tip: stop designing training around job families alone. Design it around decisions your team must make in the next 12 months.

[Suggested visual: a simple three-column diagram titled “Transferred, Sharpened, New Skills for 2026 GRC Roles”]

Stage 1: Build data literacy before you talk about AI

Start here.

Most teams want to jump straight into AI training because it sounds urgent and visible. In practice, the bigger failure point is much more basic. People cannot interpret dashboards, exception reports, alert quality metrics, model performance summaries, or data lineage issues with enough confidence to challenge what they see.

That weakness creates a quiet professional risk. A compliance officer who cannot interrogate data becomes dependent on whoever built the dashboard. A risk manager who cannot question assumptions behind thresholds becomes a consumer of outputs, not an owner of risk judgment. An auditor who cannot test data reliability properly ends up auditing process theatre.

What to implement:

• Basic data fluency training for all GRC roles
• A standard review method for dashboard quality
• A simple model of data quality checks for governance teams
• Case exercises on false positives, false negatives, and threshold design
• Role-specific training on how data feeds decisions

The responsible parties should be shared. Compliance leadership defines use cases. Data teams explain structures and limitations. Internal audit helps design challenge routines. Risk functions connect metrics to exposure.

One detail matters a lot here. Use your own data examples. Not vendor demos. Not generic training screenshots. Real internal dashboards, real alert patterns, real escalation logs. Teams learn faster when the examples are familiar and slightly uncomfortable.

I learned this the hard way. Years ago, I helped run analytics training using polished external case studies. People liked the sessions. Nothing changed. When we switched to the organization’s own ugly, inconsistent reports, participation dropped for a week, then quality of challenge went up sharply. That is when the training started working.

Original implementation tip: teach governance teams to ask four questions every time they see a dashboard. What is missing, what changed, what is the threshold logic, and what decision should this support.

Stage 2: Move from AI enthusiasm to AI oversight

This is where many teams get exposed.

There is a big difference between using AI and governing AI. Most organizations are still much better at the first than the second. They can buy the tool, run the pilot, automate the workflow, and announce efficiency gains. They are far less prepared to answer harder questions about explainability, control effectiveness, model drift, fairness, escalation logic, and accountability.

That gap is now a live governance issue.

For compliance officers, the skill is not coding. It is understanding what the tool is doing, where it can fail, how decisions are documented, and when human review must override automation. For risk managers, the skill is understanding model assumptions and residual exposure. For auditors, the skill is testing whether the governance around the tool is real or decorative.

What to implement:

• AI use case inventory with clear ownership
• Minimum control requirements for AI-enabled decisions
• Challenge sessions for model outputs and thresholds
• Documentation standards for explainability and overrides
• Audit steps tailored to automated workflows

Responsible parties should be explicit. The first line owns operational use. Risk sets challenge and model governance expectations. Compliance tests legal and regulatory implications. Audit reviews design and operating effectiveness.

One common failure deserves attention. Firms often reduce headcount before they upgrade capability. That creates the worst possible sequence. Work is automated, people leave, and the remaining staff have not yet learned to govern the new environment. The operation becomes cheaper. The exposure becomes harder to see.

Original implementation tip: never approve an AI-related staff reduction unless the governance capability map has been signed off first. Efficiency without oversight maturity creates hidden regulatory debt.

Stage 3: Strengthen regulatory fluency for digital and cross-border change

Regulatory fluency in 2026 means more than knowing the rulebook.

You need to understand how fast-moving digital regulation, privacy regimes, AI laws, outsourcing standards, conduct expectations, and cross-border obligations interact. That interaction is where real mistakes happen. A team can know each rule in isolation and still fail badly when obligations collide across products, jurisdictions, and data flows.

This is now a daily problem. AI systems cross borders. Customer data moves through vendors. Marketing claims create exposure in one jurisdiction and trigger evidence duties in another. Outsourcing arrangements carry regulatory, contractual, and operational obligations at the same time. Governance teams that cannot work across these layers become bottlenecks, or worse, false comfort providers.

What to implement:

• Cross-border obligation maps for material products
• Regulatory horizon scanning tied to business decisions
• Decision templates for conflicting obligations
• Joint reviews between legal, compliance, risk, and technology
• Escalation rules for unresolved jurisdictional conflicts

The critical artifact here is not a long legal memo. It is a decision-ready summary that tells management what changed, why it matters, where the exposure sits, and what options exist.

There is also a capability tradeoff. Small firms cannot build deep expertise in every jurisdiction. Large firms often drown in fragmented expertise. Both need a clearer model of when to centralize interpretation and when to localize execution.

Original implementation tip: when a new digital or cross-border rule appears, do not ask first “what does the rule say?” Ask “which current decisions, products, or claims become harder to defend because of this?”

Stage 4: Replace checklist execution with risk-based prioritization

A lot of compliance, risk, and audit work still suffers from equal treatment of unequal problems.

That made some sense when workflows were mostly manual and teams needed visible consistency. It makes far less sense now. In a world of automated monitoring, large-scale data, and constrained headcount, the real differentiator is prioritization quality.

This skill is becoming central across all three functions.

Compliance officers must know where to intensify monitoring and where a control can be simplified. Risk managers must know which exposures deserve scenario work and which do not. Auditors must know where testing depth should increase and where assurance effort is no longer worth the cost. This is no longer just a planning issue. It is a professional judgment issue.

What to implement:

• Risk-based planning linked to expected loss or materiality
• Segmentation of issues by decision impact
• Dynamic review cycles for emerging risk indicators
• Monitoring plans tied to control value, not legacy frequency
• Documentation of why low-value work was reduced

Here is where many teams hesitate. They fear that reducing low-value work will look careless. In reality, supervisors and boards increasingly expect the opposite. They want to know that scarce governance resources are being directed where they matter most.

I have seen teams spend months polishing low-risk control evidence while material third-party and data governance exposures sat under-reviewed. Nobody intended that outcome. It came from inherited planning habits that were never seriously challenged.

Original implementation tip: each year, require every governance team to identify 15 percent of recurring work that no longer justifies its cost. If nobody can name it, the planning process is too passive.

[Suggested visual: sample matrix comparing “effort spent” versus “risk value created”]

Stage 5: Turn judgment into a visible professional skill

Judgment used to hide behind experience.

That is no longer enough. As automated systems handle more routine work, human contribution must become more explicit. This means professionals need to show how they interpret ambiguity, challenge outputs, weigh tradeoffs, and defend decisions.

This is especially important because supervisors, boards, and executives now expect more than procedural compliance. They expect reasoning. They want to know why a case was escalated, why a model output was overruled, why a business request was delayed, or why a regulatory interpretation was considered proportionate.

Judgment also has to be teachable. This is where many organizations struggle. Senior people often have excellent instinct but poor transfer discipline. They know when something feels wrong, but they do not articulate the reasoning path clearly enough for others to learn from it.

What to implement:

• Decision logs for difficult cases
• Review sessions on borderline escalations
• Written rationale requirements for overrides
• Judgment-based case discussions in team meetings
• Mentoring focused on reasoning, not just outcomes

The responsible parties here are mostly leaders. Team heads must create space for reasoning, not just throughput. Senior reviewers need to model their thought process in real cases. Audit leaders should document why a finding matters, not only what failed.

One vulnerable truth. Many experienced professionals are less prepared for this shift than they think. Deep experience with manual processes does not automatically translate into strong explicit judgment. I have seen very senior people struggle when asked to explain why they trusted one control output and challenged another. Experience gave them confidence. It had not given them a repeatable method.

Original implementation tip: after any material review or escalation, ask the decision-maker to write five lines explaining the reasoning. Over time, this becomes one of the best judgment training tools in the function.

Stage 6: Build influence across the first, second, and third lines

Governance functions lose value when they arrive late.

This is true in contract review, product change, AI deployment, customer segmentation, vendor onboarding, and issue remediation. If compliance, risk, and audit only appear once the decision is mostly made, they do not shape outcomes. They document concerns around decisions already moving forward.

The skill behind early influence is not authority. It is relevance.

Compliance officers need to explain business implications in terms leaders care about. Risk managers need to connect exposure to choices, timing, and tradeoffs. Auditors need to shift part of their credibility from post-event review to pre-event insight, while preserving independence.

What to implement:

• Early-stage governance gates for key business changes
• Short decision memos, not only long reports
• Financial framing of major compliance exposures
• Joint workshops with business, legal, data, and operations
• Clear escalation routes when tradeoffs remain unresolved

A good practical test is simple. Can your team explain, in three minutes, why a proposed control change matters to revenue, cost, risk, or supervisory defensibility? If not, the technical analysis may be fine, but the influence skill is weak.

This is where careers widen or narrow. The professionals who can connect risk to business reality become trusted participants in decision-making. The ones who stay in narrow technical phrasing become background reviewers.

Original implementation tip: teach teams to present every material issue with three elements only. Exposure, decision options, and recommendation. Everything else can sit in the appendix.

Cross-cutting implementation tips for 2026 GRC skills

Skills do not hold unless the operating model supports them.

That is where many development programs break down. They train people in isolation while leaving workflows, incentives, reporting lines, and documentation unchanged. The result is temporary awareness with no durable capability.

Here are four cross-cutting practices that make the shift stick.

1. Tie skills to real decisions

Training works when it connects directly to live work.

Use current alerts, current controls, current dashboards, current regulatory changes. Build training around decisions the function must make this quarter, not abstract capability aspirations.

Original implementation tip: before approving any skills program, ask which three live decisions it will improve within 90 days. If nobody knows, the program is too generic.

2. Protect documentation quality during automation

As automation rises, documentation often gets weaker.

People assume the system record is enough. It usually is not. You still need rationale, evidence of challenge, override logic, and clear ownership of decisions. This matters in supervisory review, audit defense, and internal accountability.

Original implementation tip: for every automated control or AI-supported workflow, define what the system records automatically and what human rationale must still be documented manually.

3. Design for capability transfer, not heroics

Too many GRC functions still depend on a few very experienced people.

That model breaks under restructuring, attrition, or rapid technology change. Capability must sit in methods, playbooks, decision logs, review routines, and mentoring structures. Not only in memory.

Original implementation tip: if a critical governance task can only be defended by one person in the team, you do not have a skill. You have a dependency.

4. Measure whether the skill shift changes outcomes

This is the test that matters.

Did alert review quality improve. Did time to escalation fall. Did issue prioritization become sharper. Did audit findings become more decision-useful. Did management decisions change earlier in the process. If none of these move, your skills program may be producing awareness, not value.

Original implementation tip: define three operational metrics before the training starts and compare them after 90 and 180 days. Skill development without outcome measurement becomes corporate theatre.

Key references for 2026 compliance skills, risk management skills, and audit skills

The following standards, guidance sources, and institutional references are especially relevant for building 2026-ready skills in compliance, risk, and audit functions:

• ISO 37301, Compliance management systems
• ISO 31000, Risk management guidelines
• IIA Global Internal Audit Standards
• NIST AI Risk Management Framework
• EU AI Act
• GDPR and related EDPB guidance
• Basel Committee guidance on operational risk and governance
• FATF guidance on digital transformation, AML, and risk-based controls
• EBA guidelines on internal governance, outsourcing, and ICT risk
• DOJ guidance on evaluation of corporate compliance programs
• ECB supervisory expectations for governance and risk control functions
• Industry reports from PwC, KPMG, Deloitte, and major banking supervisory bodies on AI, compliance, and governance capability trends

Use these as anchors. But do not stop at reading them. Convert them into capability design, workflow changes, and role-specific expectations.

The capabilities that now matter most

If you need a simple shortlist, this is it.

Analytics

• Turn alerts into quantified, decision-ready risk signals
• Data literacy now matters more than checklist experience

Automation

• Automate routine KYC, redeploy humans to complex judgment
• Efficiency without capability shift increases regulatory exposure

Governance

• AI needs oversight, not blind operational dependence
• Model decisions must remain explainable to supervisors

Judgment

• Compliance value shifts from processing to defensible decisions
• AI flags risk, humans must interpret and escalate

Regulation

• Cross-border compliance now requires multi-jurisdictional legal fluency
• Digital rules expand faster than legacy compliance models

Prioritization

• Risk-based planning beats uniform compliance effort allocation
• Focus resources where expected loss is materially concentrated

Treat these skills as a soft HR topic and you will get a well-designed learning calendar with very little impact on control quality.

Treat them as part of your governance operating model and they become something else entirely. Better judgment. Faster escalation. Stronger supervisory defensibility. Clearer decisions. That is where the real value sits.

The professionals who stay valuable in 2026 will not be the ones who process the most checklists. They will be the ones who can explain, challenge, and defend risk in a system where more of the first pass is done by machines.

The Real Test: Does Your Work Change Decisions?

All seven skills point to a single criterion. Does the compliance risk process demonstrably change organizational decisions?

Does it alter contract terms before signature? Does it delay a market entry until controls are in place? Does it narrow a public commitment to what the organization can actually substantiate? Does it redirect compliance investment from low-exposure obligations to high-exposure ones? Does it produce reserve levels and insurance coverage calibrated to a loss distribution rather than to last year's budget plus 5%?

If the answer to all of these is no, the process is producing documentation, not decisions. And documentation without decision impact is precisely the kind of compliance work that AI will replace.

The professionals who build these seven skills will find themselves more valuable in 2026 than they are today. The compliance function needs fewer people who can process alerts and more people who can interpret signals, calibrate models, quantify exposure, challenge AI outputs, map regulatory conflicts, evidence decisions, and translate risk into financial terms.

One question worth asking yourself this week: which of these seven skills would you be most uncomfortable being tested on in front of your board or your regulator? Start there.