Abstract

Governance, Risk and Compliance (GRC) is undergoing a fundamental transformation as artificial intelligence (AI), generative AI and agentic systems alter the way organisations identify risk, interpret regulatory requirements, execute controls and make decisions under uncertainty. Traditional GRC operating models remain predominantly periodic, process-centric and retrospective, relying on fragmented information, manual assessment, point-in-time assurance and organisational boundaries that increasingly fail to reflect the speed and interconnectedness of contemporary risk environments. This paper argues that the emergence of AI should therefore be understood not as an opportunity to automate existing GRC activities, but as a catalyst for redesigning GRC as an integrated organisational capability.

Drawing on the evolution of digital GRC, AI governance, data infrastructure, agentic AI, cybersecurity, continuous assurance, workforce transformation and ecosystem risk, the paper develops a target operating model and architectural framework for decision-intelligent GRC. The proposed model integrates six mutually reinforcing layers: business and decision processes; risk and regulatory intelligence; AI and decision intelligence; governed agentic execution; control and assurance; and organisational learning. Within this architecture, intelligence, authority and execution are deliberately separated, while remaining connected through explicit identity, permissions, policy enforcement, human approval, monitoring, evidence and verification mechanisms.

The paper identifies ten strategic transformation pillars: establishing an AI-ready GRC data foundation; re-engineering workflows; introducing governed agentic GRC; moving from AI governance towards organisational control; establishing continuous AI assurance; designing GRC for failure and resilience; integrating cybersecurity and identity-centric controls; redesigning the GRC workforce; transforming third-party and ecosystem governance; and extending GRC beyond organisational boundaries. These pillars are supported by a transformation roadmap based on capability maturity rather than technology deployment, progressing from foundational integration through AI augmentation and governed autonomy towards decision intelligence.

The paper further proposes that transformation should be measured through organisational outcomes rather than AI adoption alone. Five dimensions—risk intelligence, operational efficiency, control effectiveness, decision quality, and trust and resilience—provide a balanced basis for assessing progress from reactive to preventive, predictive, adaptive and ultimately decision-intelligent GRC.

The central contribution of the paper is therefore a shift in the conceptualisation of GRC: from a periodic compliance and assurance function towards a continuously sensing, decision-supporting, control-executing and organisationally learning system. AI becomes strategically valuable not when it replaces GRC professionals or maximises automation, but when it strengthens the organisation's ability to understand uncertainty, exercise accountable judgement, control machine action, respond to failure and make better decisions.

Keywords: Governance, Risk and Compliance; artificial intelligence; generative AI; agentic AI; AI governance; continuous assurance; organisational control; decision intelligence; cybersecurity; ecosystem risk; GRC transformation.

1. Introduction

Governance, Risk and Compliance (GRC) has become an established component of organisational governance, providing the structures through which firms articulate risk appetite, translate regulatory requirements into controls, monitor exposure, demonstrate accountability and provide assurance to boards, regulators and other stakeholders. Its institutional architecture has traditionally been built around relatively stable representations of organisational risk: policies, risk registers, control libraries, risk assessments, heat maps, compliance attestations, audit evidence and periodic management reporting. These mechanisms remain necessary because they provide standardisation, traceability and formal accountability. The problem, however, is not that such artefacts have become obsolete; rather, it is that they increasingly constitute an insufficient representation of the environments that organisations are required to govern.

The central weakness is temporal and epistemic. Conventional GRC tends to represent risk as something that can be periodically identified, assessed, documented and controlled. This logic is increasingly difficult to sustain in environments characterised by continuous technological change, regulatory volatility, geopolitical disruption, cyber threats, complex third-party dependencies and highly interconnected financial and operational systems. The contemporary risk environment is better understood as dynamic and emergent: risks interact across organisational boundaries, propagate through networks and can develop materially between formal assessment cycles.

The GRC literature increasingly points towards a transition from fragmented, compliance-oriented risk management towards integrated, AI-augmented decision intelligence, in which continuous risk sensing, contextual analysis and extended-enterprise governance become central capabilities (Bromiley et al., 2015; Autio et al., 2023). This diagnosis is consistent with the broader enterprise risk literature, which has long identified the tendency of conventional enterprise risk management to fragment risk into functional silos and thereby obscure interdependencies between risks and organisational decisions (Bromiley et al., 2015).

This critique is important because the proliferation of GRC artefacts can create an illusion of control. Risk registers, control matrices and compliance dashboards can demonstrate that governance activity has occurred without necessarily demonstrating that the organisation has improved its capacity to anticipate, interpret or respond to uncertainty. Power (2021), for example, characterises aspects of contemporary risk management as becoming ritualised around assurance and procedural demonstration. The implication for GRC transformation is therefore not that documentation, controls or assurance should be abandoned, but that their purpose must be reconsidered. They should function as components of an organisational decision system rather than as ends in themselves. The strategic question becomes whether GRC improves the quality, speed, robustness and accountability of decisions made under uncertainty.

The concept of decision advantage provides a useful basis for this reorientation. Rather than treating risk management primarily as the production of an inventory of exposures, decision-oriented GRC seeks to improve organisational judgement by integrating risk information into strategy and decision-making, making uncertainty, assumptions, dependencies, options and potential consequences more visible at the point where decisions are taken (COSO, 2017, Spetzler 2016). This perspective resonates with contemporary risk-analysis scholarship, which emphasises that risk analysis should support decisions under uncertainty rather than merely generate deterministic probability-impact estimates (Aven, 2020). GRC therefore needs to move closer to the operational and strategic decisions that it is intended to inform. Its value should increasingly be judged not by how many assessments have been completed, or how many controls have been documented, but by whether it enables the organisation to recognise emerging conditions earlier, understand their implications more effectively and act within clearly defined governance boundaries.

This shift is also necessitated by the changing character of risk itself. Contemporary organisations operate as components of complex socio-technical and economic networks in which disruptions can propagate across domains and organisational boundaries. Cyber incidents can become operational failures; supplier disruption can become liquidity or customer risk; geopolitical developments can affect technology availability and regulatory exposure; and regulatory change can alter the economics of an entire business model. Systems research has demonstrated that such environments cannot be adequately understood through the independent analysis of their constituent parts because interactions and feedback mechanisms can generate emergent outcomes (Helbing, 2013). This perspective supports a move from static risk registers towards integrated, relationship-aware representations of risk capable of making dependencies, interdependencies and systemic exposure more visible (Bromiley et al., 2015; COSO, 2017; Hogan et al., 2021). The significance of this proposition extends beyond risk analytics: it implies that the architecture of GRC itself must become relational, dynamic and capable of representing the organisational context in which risk materialises.

The temporal dimension is equally consequential. Third-party risk provides a particularly clear illustration. Traditional third-party risk management frequently relies upon questionnaires, attestations and periodic reviews. Yet a supplier's risk profile may change materially between assessment cycles because of cyber incidents, ownership changes, financial deterioration, geopolitical events, subcontractor dependencies or changes in the technology on which the supplier relies. Research on resilient supply chains similarly emphasises the importance of end-to-end visibility and adaptive response rather than static preparedness (Ivanov, 2021; Ivanov and Dolgui, 2021). The GRC Advisory work on extended-enterprise governance therefore reframes third-party risk as a continuous intelligence problem in which suppliers, subcontractors and technology providers are treated as interconnected components of the enterprise risk environment rather than as periodically assessed external entities (Bromiley et al., 2015; NIST, 2023; Hogan et al., 2021). This logic extends naturally to cloud providers, AI model providers, data suppliers and other digital dependencies.

Artificial intelligence creates both the opportunity and the imperative for this transformation. Generative AI can significantly increase the capacity of GRC functions to analyse unstructured information, interpret regulatory texts, identify relationships, summarise evidence and support professional judgement. Agentic AI extends this possibility further by connecting reasoning to tools, enterprise data and workflow execution. The distinction is strategically important. Generative AI principally produces information, whereas agentic systems can interpret objectives, decompose goals into action plans, retrieve information, invoke actions in external environments, observe outcomes and adapt their subsequent actions through iterative reasoning and acting (Yao et al., 2023). In this sense, agentic AI should be understood not as an enhanced chatbot but as a new enterprise automation architecture.

However, the mere deployment of AI does not constitute GRC transformation. AI creates organisational value only when it is integrated into business processes, organisational structures and decision-making rather than layered onto existing activities as a standalone technological capability. The distinction between an AI-enabled interface and an AI-enabled operating model is therefore fundamental (Bharadwaj, El Sawy and Pavlou, 2013; Raisch and Krakowski, 2021). If a language model merely summarises an existing risk register, the organisation may obtain productivity benefits without changing how risk is understood or governed. A genuinely transformative architecture instead connects AI to enterprise data, regulatory knowledge, controls, workflows and decision rights, thereby changing how GRC intelligence is produced and consumed. This is consistent with the wider digital-transformation literature, which suggests that technology creates greater organisational value when it is integrated with processes, complementary capabilities and organisational redesign rather than implemented as a discrete technological layer (Bharadwaj et al., 2013).

The same principle applies to agentic AI. Its strategic potential derives less from unrestricted autonomy than from the orchestration of reasoning, enterprise knowledge, deterministic systems and controlled action. A useful architectural principle is to separate interpretive intelligence from transactional execution: AI agents can interpret requirements, retrieve evidence and formulate recommendations, while deterministic enterprise systems and established control mechanisms execute transactions requiring precision, consistency and auditability (Yao et al., 2023; Raisch and Krakowski, 2021). Agentic AI should therefore complement rather than indiscriminately replace workflow engines, business rules, robotic process automation and systems of record. Its value lies in providing an adaptive intelligence and orchestration layer across these existing capabilities.

This architecture simultaneously creates a new governance problem. The moment an AI system moves from generating information to taking authorised action, its risk profile changes materially. A hallucinating model may produce an incorrect answer; an agent with access to enterprise systems can convert the same epistemic error into an unauthorised transaction, incorrect regulatory action, inappropriate customer treatment or disclosure of sensitive information. The governance challenge therefore changes when AI systems move from generating information to taking actions on behalf of an organisation. Such systems require explicit limits on authority, human oversight, evaluation and mechanisms for accountability (NIST, 2023; Novelli, Taddeo and Floridi, 2024). This reinforces the importance of separating AI reasoning from execution, with actions mediated through explicit controls that determine what an AI system is authorised to undertake (Yao et al., 2023; NIST, 2023).

This issue also exposes an important limitation in conventional approaches to AI governance. Governance committees, policies, principles and model inventories are necessary, but they do not in themselves constitute effective organisational control. The transition from AI governance to organisational control requires governance to become operational: decision rights, accountability, defined responsibilities, monitoring and evidence must be translated into policies, processes and control mechanisms embedded within the architecture and workflows through which AI systems operate (NIST, 2023; ISO/IEC, 2023). This is consistent with the direction of contemporary AI governance frameworks, including the NIST AI Risk Management Framework and ISO/IEC 42001, both of which emphasise accountability, risk management, lifecycle governance and organisational controls rather than purely technical model evaluation (NIST, 2023; ISO/IEC, 2023).

The requirement for organisational control becomes more significant as AI systems become increasingly autonomous. Agentic AI introduces a spectrum of autonomy rather than a binary distinction between automated and human-controlled processes. At one end are deterministic workflows supported by AI classification or extraction; further along the spectrum are assistants capable of retrieval and restricted tool use; beyond these are agents capable of planning and executing multi-step tasks; and at the most autonomous end are systems capable of pursuing relatively open-ended objectives with limited human intervention. This spectrum reflects a progression from AI-enabled task support towards increasingly autonomous reasoning and action, with corresponding implications for the balance between human augmentation and automation and for the governance of AI systems as their capacity to act increases (Raisch and Krakowski, 2021; Yao et al., 2023; NIST, 2023). The strategic question for GRC is therefore not whether an organisation should "adopt agentic AI", but how much autonomy should be permitted for a particular process, under what conditions, with which authorities and subject to which controls.

This requires a reconsideration of the human role. The transformation of GRC should not be interpreted as a linear progression from human work to autonomous machines. Research on the automation–augmentation paradox suggests that AI can simultaneously substitute for some activities and complement others, with organisational value depending significantly on how work is redesigned around the interaction between people and intelligent systems (Raisch and Krakowski, 2021). Human judgement remains an enduring component of AI-enabled governance, particularly where decisions involve ambiguity, competing considerations, contextual interpretation or potentially significant consequences. AI systems may support decision-makers by providing additional analysis or recommendations, but organisations must clearly define the respective roles and responsibilities of humans and AI within the decision-making process, including where human oversight or intervention is required (NIST, 2023; ISO/IEC, 2023). The objective should therefore be meaningful human control, rather than nominal human involvement. A human approver who cannot understand, challenge or override an AI recommendation does not provide effective governance merely by being placed at the end of a workflow.

The epistemic risks of AI make this distinction especially important. Large language models generate probabilistic outputs and can produce plausible but incorrect or insufficiently grounded information. In GRC contexts, such hallucinations are not simply quality defects. They can undermine regulatory interpretation, control assessments, audit evidence, financial-crime investigations and management decisions. Research on hallucination in natural-language generation demonstrates that the problem is structural rather than merely incidental (Ji et al., 2023). The appropriate response is therefore not to assume that increasingly capable models will eliminate the problem, but to engineer systems in which important outputs are grounded in authoritative data, supported by provenance, subject to validation and accompanied by appropriate escalation mechanisms. Retrieval-augmented generation provides one mechanism for grounding models in external knowledge, while agent architectures can combine retrieval with reasoning, tool use and subsequent actions in an iterative decision process. This creates a need for the information retrieved, actions undertaken and resulting outcomes to remain subject to appropriate governance and control mechanisms (Lewis et al., 2020; Yao et al., 2023).

Consequently, AI readiness should be understood principally as an organisational and infrastructural capability, rather than as a model-selection exercise. AI value depends not only on model capability but also on the quality, accessibility, interoperability and governance of the underlying data environment. AI-ready data platforms therefore represent an organisational capability that connects data infrastructure, business processes and AI systems, while requiring appropriate governance and risk management across the AI lifecycle (Bharadwaj et al., 2013; NIST, 2023). This is particularly significant for GRC because the relevant information is inherently distributed. Regulatory obligations reside in external legal and supervisory sources; organisational policies reside in document repositories; controls reside in GRC systems; operational evidence resides in enterprise applications; incidents may reside in security platforms; supplier information resides in procurement systems; and business outcomes reside in operational and financial systems. Without a coherent data and knowledge architecture, AI merely accelerates the fragmentation already present in conventional GRC.

The desired architecture should therefore connect regulation, obligation, policy, risk, control, process, system, third party, evidence, decision and outcome. Such relationships are more important than any individual data element. Knowledge-graph and semantic approaches are consequently relevant because they allow GRC systems to represent relationships and dependencies rather than merely storing isolated records. This provides the foundation for network-aware and causally informed risk models, drawing on established research into Bayesian networks, causal inference and complex networks (Fenton and Neil, 2019; Pearl, 2009; Barabási and Pósfai, 2016).

The transformation also requires GRC to become more closely integrated with cybersecurity and operational resilience. As AI systems acquire access to enterprise information and tools, identity, access control, data security, API security and monitoring become integral elements of GRC rather than adjacent technology concerns. Cybersecurity should therefore be treated as an integral property of intelligent systems and their operating environments rather than solely as a downstream control. Effective cybersecurity and resilience increasingly depend upon continuous understanding of system conditions, identities, dependencies, threats and vulnerabilities, supported by governance, monitoring and adaptive risk management across the system lifecycle (NIST, 2023; NIST, 2024; ISO/IEC, 2023). GRC transformation must therefore converge with cybersecurity architecture rather than preserve rigid functional boundaries.

The same argument applies to organisational resilience more broadly. If instability is treated as a persistent characteristic of the operating environment rather than an exceptional event, GRC must be designed to operate under degraded conditions. Research on resilient information systems emphasises architectures designed to withstand disruption, maintain essential capabilities under adverse conditions and recover effectively when failures occur, rather than assuming that systems can be made permanently failure-free (NIST, 2023). For AI-enabled GRC, this means incorporating fallbacks, transaction limits, confidence thresholds, checkpoints, rollback mechanisms, escalation paths and alternative operating modes. Resilience becomes a governance property: the organisation must know not only whether an AI system is functioning, but also what happens when it is wrong, unavailable, manipulated or operating outside its validated conditions.

This becomes particularly significant in financial services, where AI-enabled processes intersect with regulatory obligations, financial infrastructure and systemic risk. The GRC Advisory research on AI in banking, AI-enabled finance, financial-sector stability and agentic AI in financial infrastructure illustrates that the consequences of AI deployment cannot be isolated at the application level. AI may influence multiple functions across the financial system, including financial intermediation, payments, risk management, customer-facing activities and financial-market operations, while also creating dependencies that can propagate risk across institutions and markets (Aldasoro et al., 2024). Consequently, the appropriate unit of governance is increasingly the socio-technical system in which AI models interact with data, people, organisational processes, technologies and external dependencies, rather than the individual AI model in isolation (NIST, 2023; Autio et al., 2024).

Regulatory and geopolitical developments reinforce this conclusion. The GRC environment is becoming increasingly fragmented across jurisdictions while technological dependencies are becoming increasingly concentrated around global cloud, AI and digital-infrastructure providers. The increasing adoption of AI and cloud technologies in financial services creates a strategic tension between innovation and competitiveness on the one hand, and digital sovereignty, resilience, regulatory control and dependency management on the other. In Swiss banking, these tensions are particularly relevant because cloud adoption can support technological innovation while simultaneously creating regulatory, data-sovereignty, security and concentration risks that must be actively governed (NIST, 2023; ISO/IEC, 2023). GRC can no longer treat regulatory compliance as a purely legal interpretation exercise. It must also understand technological dependency, jurisdictional exposure, concentration risk and strategic optionality. This expands the role of GRC from compliance assurance towards strategic risk intelligence.

Financial crime compliance provides another illustration of the required transition. The movement from point-in-time customer due diligence towards more continuous and risk-sensitive approaches demonstrates how compliance is increasingly becoming an information-integration and intelligence problem. Similar dynamics are visible across the broader financial-crime landscape, where digitalisation, regulatory complexity and increasingly sophisticated forms of financial crime require organisations to integrate data, contextual and behavioural signals, and investigative workflows rather than rely exclusively upon static rules and periodic reviews (FATF, 2017; Bromiley et al., 2015; NIST, 2023). AI therefore creates an opportunity to transform compliance from retrospective evidence collection towards more continuous detection, investigation and intervention.

However, technology alone cannot deliver this transition. Research on digital business transformation and the organisational implications of AI demonstrates that legacy systems, organisational structures, business processes and professional roles can constrain AI-enabled transformation even where technical capability is available (Bharadwaj, El Sawy and Pavlou, 2013; Raisch and Krakowski, 2021). This is consistent with the broader finding that digital transformation is fundamentally socio-technical. Organisations do not simply implement technologies; they reconfigure routines, responsibilities, expertise, incentives and decision structures around them. GRC transformation therefore requires the redesign of professional roles and organisational capabilities alongside technology. The future GRC professional will increasingly operate as an interpreter of risk, designer of controls, supervisor of intelligent systems and adviser on decisions under uncertainty rather than primarily as an administrator of compliance artefacts.

This also changes the economics of GRC transformation. AI use cases should not be selected because they are technologically impressive. AI use cases should therefore be identified and evaluated according to their strategic relevance, process characteristics, data availability, integration requirements, expected value, human–AI roles and governance implications. Such an assessment recognises that the value and feasibility of an AI application depend not only on technical capability but also on its fit with business strategy and processes, the allocation of tasks between humans and AI, and the governance requirements associated with its deployment (Bharadwaj, El Sawy and Pavlou, 2013; Raisch and Krakowski, 2021; NIST, 2023).

The resulting transformation can be conceptualised as a movement through several interrelated states. Traditional GRC is primarily artefact-centric: it produces policies, registers, assessments and evidence. Digitised GRC becomes workflow-centric, improving the speed and consistency with which those artefacts are produced. AI-enabled GRC becomes intelligence-centric, using data and models to interpret information and identify emerging conditions. Agentic GRC becomes action-centric, allowing governed AI systems to initiate and coordinate responses. The mature state is decision-centric GRC, in which intelligence, control and execution are integrated into the organisation's critical decision processes. This progression aligns with the broader shift from compliance-oriented risk management towards an integrated governance architecture in which risk information supports strategic decision-making, organisational performance and the management of uncertainty (COSO, 2017; NIST, 2023).

Accordingly, the strategic challenge is not simply how GRC can "use AI". The deeper question concerns how the GRC operating model should be redesigned when intelligence becomes abundant, machine action becomes increasingly feasible and organisational risk becomes more interconnected. This requires simultaneous transformation across data, architecture, processes, controls, decision rights, workforce capabilities and assurance mechanisms. Research on digital business strategy and the organisational implications of artificial intelligence reinforces this point by positioning intelligent enterprise transformation as an organisational and architectural challenge in which technology, operating models, business processes and organisational capabilities must evolve together (Bharadwaj, El Sawy and Pavlou, 2013; Raisch and Krakowski, 2021). GRC cannot remain a peripheral control layer attached to this transformation; it must become part of the architecture through which the intelligent enterprise governs itself.

The central proposition of this chapter is therefore that the future of GRC lies in its transformation from a predominantly compliance-centric assurance function into an adaptive organisational decision system. Such a system would continuously sense internal and external signals; integrate regulatory, operational, technological and ecosystem data; represent relationships and dependencies; use AI to generate contextual intelligence; deploy agents where autonomy is justified; constrain execution through explicit organisational controls; retain meaningful human accountability; and continuously verify outcomes and learn from failure. In this conception, governance is not an ex-post assessment of whether organisational activity complied with predetermined rules. It becomes an embedded capability for navigating uncertainty while preserving accountability.

The distinction is fundamental. AI-enabled GRC adds artificial intelligence to existing GRC processes. AI-native GRC redesigns those processes around continuous sensing, contextual intelligence, governed action and evidence-producing controls. The former can deliver incremental productivity; the latter has the potential to alter the strategic role of GRC itself.

The transformation should therefore be understood not as the automation of compliance, but as the engineering of organisational intelligence under conditions of uncertainty. Its objective is neither to eliminate human judgement nor to maximise machine autonomy. Rather, it is to establish an architecture in which data creates context, AI creates analytical capacity, agents execute bounded actions, controls constrain those actions, humans retain accountable judgement, assurance verifies outcomes and organisational learning continuously improves the system. Such an architecture would reposition GRC from a largely retrospective mechanism for demonstrating control towards a strategic capability for anticipating risk, enabling informed risk-taking and creating decision advantage.

The research question that follows from this proposition is consequently:

How should GRC operating models, architectures and control mechanisms be transformed to exploit AI and agentic capabilities while preserving accountability, resilience and decision quality in increasingly complex and interconnected organisational environments?

Answering this question requires moving beyond the question of whether AI can automate individual GRC tasks. It requires examination of the deeper relationship between risk intelligence, organisational control, enterprise architecture, human judgement and technological agency. The subsequent analysis therefore treats GRC transformation as a socio-technical and architectural problem rather than a technology-adoption exercise.

2. The Strategic Case for Transforming GRC

The case for transforming Governance, Risk and Compliance (GRC) is not principally technological. It arises from a growing structural misalignment between the operating logic of conventional GRC and the environments in which organisations now make decisions. Traditional GRC was largely designed for comparatively stable regulatory conditions, identifiable organisational boundaries, periodic management cycles and risks that could be represented through discrete categories and control assertions. Contemporary organisations operate under very different conditions. Digital dependencies are increasingly interconnected, third parties form extended enterprise networks, regulatory obligations are proliferating across jurisdictions, cyber threats evolve continuously, and artificial intelligence is introducing new forms of operational autonomy and decision-making.

The GRC literature therefore frames transformation as a movement from compliance-centric administration towards continuous organisational intelligence and decision advantage (COSO, 2017; NIST, 2023). This does not imply that policies, controls, risk registers, audits or regulatory reporting have become obsolete. Rather, their role must be repositioned within a broader architecture in which evidence is generated continuously, risks are interpreted dynamically, decisions are supported contextually, and control effectiveness can be evaluated as conditions change. Compliance consequently becomes less an endpoint of organisational activity and more an embedded organisational capability through which the organisation continuously senses, interprets, governs and responds to uncertainty (COSO, 2017; NIST, 2023).

The strategic case for transformation can therefore be understood through several interconnected shifts: from periodic assurance to continuous sensing; from risk quantification to decision intelligence; from isolated controls to interconnected control architectures; from process automation to process reinvention; from human-only analysis to human–AI complementarity; and from static governance to adaptive organisational control. Taken together, these shifts suggest that the future of GRC lies not in digitising the existing compliance model, but in redesigning the organisational system through which risk, regulation, technology and managerial judgement interact.

2.1 From Periodic Assurance to Continuous Sensing

Traditional GRC is heavily dependent upon periodicity. Risk assessments are commonly conducted annually or semi-annually; management information is reported according to quarterly or monthly cycles; controls are tested according to predetermined schedules; internal audits operate through defined review programmes; and compliance assessments are often triggered by regulatory or organisational milestones. These mechanisms remain necessary for accountability and assurance, but they introduce a fundamental temporal constraint: they create the possibility that the organisation's understanding of risk becomes outdated before the next formal assessment occurs.

The problem is not simply that periodic processes are slow. More fundamentally, periodicity assumes that risk can be meaningfully represented at discrete points in time. This assumption becomes increasingly problematic in complex and interconnected environments in which risk emerges through interactions between changing technologies, markets, counterparties, regulations and organisational behaviours. Research on enterprise risk management highlights the limitations of fragmented approaches to risk and the importance of integrating risk information across organisational activities, while COSO (2017) emphasises the integration of risk with strategy and performance (Bromiley et al., 2015; COSO, 2017). From this perspective, the challenge is not to produce more frequent versions of the same artefacts, but to reconsider the underlying information architecture of risk management so that risk information can be integrated, contextualised and used to support decisions as organisational conditions change.

This is consistent with the broader enterprise risk management literature. Bromiley et al. (2015) conceptualise risk management as an organisational capability rather than merely a collection of discrete risk activities, while COSO (2017) positions enterprise risk management within strategy, performance and decision-making. The implication is important: if risk management is an organisational capability, its effectiveness depends upon the organisation's capacity to acquire, interpret and act upon relevant information as circumstances evolve.

Continuous sensing provides such a capability. It involves the systematic acquisition and contextualisation of signals from internal operations and the external environment, followed by ongoing evaluation of whether those signals alter the organisation's risk profile. Relevant signals may include changes in customer behaviour, transaction patterns, cyber threat intelligence, supplier performance, financial indicators, regulatory developments, geopolitical events, technology dependencies, control exceptions and changes in organisational processes. The objective is not simply to increase the volume of monitoring. It is to improve the organisation's ability to distinguish meaningful changes from operational noise.

This distinction becomes particularly important in systemic risk. Material risks frequently emerge not from individual control failures alone but from relationships and interdependencies between entities, technologies and organisational systems. Research on enterprise risk management highlights the importance of understanding risk as an integrated organisational phenomenon rather than as a collection of isolated exposures, while research on knowledge graphs demonstrates how relationships between entities and concepts can be represented explicitly within interconnected information structures (Bromiley et al., 2015; Hogan et al., 2021). COSO (2017) similarly emphasises the integration of risk with strategy and performance across the organisation. For GRC, this means that the question “Is this control operating?” may be insufficient if the organisation cannot also determine how changes or disruptions elsewhere in the organisational and technological environment could alter the effectiveness, relevance or exposure addressed by that control.

Continuous sensing therefore changes the temporal logic of GRC. Instead of treating risk assessment as an event, it becomes a continuous organisational process:

Sense → contextualise → assess → decide → act → verify → learn.

This sequence is particularly compatible with AI-enabled architectures. Research on agentic language-model systems describes a comparable operational loop in which systems reason over contextual information, interact with external sources or environments, take actions through available tools, observe the resulting feedback and use that information to update subsequent actions (Yao et al., 2023). Importantly, this does not mean that GRC decisions should simply be delegated to autonomous agents. Rather, the architectural pattern demonstrates how agentic capabilities can support a transition from static reporting towards continuous feedback, monitoring and control, while decision rights and authority remain explicitly governed.

The resulting strategic advantage is therefore not merely faster compliance. It is earlier organisational awareness. A GRC function capable of identifying changes in risk conditions before they crystallise into incidents can influence decisions upstream rather than merely documenting consequences downstream. This represents a shift from retrospective assurance towards anticipatory governance.

2.2 From Compliance Evidence to Decision Intelligence

Continuous sensing alone does not create effective GRC. An organisation can collect enormous volumes of information and still make poor decisions. The strategic problem consequently extends beyond risk visibility to the conversion of information into decision-relevant intelligence.

Risk quantification remains important because it provides a means of comparing exposures, modelling scenarios and allocating resources. Yet quantitative precision can create a false sense of certainty when assumptions, data quality and model limitations are not adequately understood. Aven (2016; 2020) emphasises the importance of uncertainty, knowledge quality and the robustness of assumptions in risk analysis. Similarly, Fenton and Neil (2019) demonstrate the value of probabilistic reasoning for representing uncertainty rather than concealing it behind deterministic classifications.

The concept of decision intelligence builds on this logic by repositioning GRC around the quality and consequences of organisational decisions rather than the production of risk information alone (COSO, 2017). The distinction is strategically significant. A risk function can produce accurate assessments while failing to influence the decisions that determine how the organisation responds to uncertainty and maintains resilience. Conversely, decision intelligence requires risk information to be connected to organisational objectives, decision rights, available interventions, potential consequences and accountability. In this sense, the value of GRC lies not only in identifying and communicating risk, but in ensuring that relevant risk intelligence is available and actionable at the points where organisational decisions are made.

The principal output of GRC should therefore not be a dashboard indicating that an exposure is "red", "amber" or "green". Such classifications can be useful communication devices, but they compress complex uncertainty into simplified categories. A decision-intelligent GRC system should instead establish a chain of reasoning that enables management to understand what has changed, why it matters, what may happen next and what can legitimately be done about it.

The relevant questions become: What has changed? Why has it changed? Which business processes, customers, assets or counterparties are affected? Which regulatory obligations are implicated? Which controls are relevant and how effective are they under the changed conditions? What plausible scenarios should management consider? What response options are available? What are the expected consequences, costs and residual risks of each option? Who has the authority to decide? What assumptions underpin the recommendation? What evidence supports it? And how will the organisation determine whether the intervention has worked?

This is a fundamental shift from reporting risk to governing uncertainty.

The distinction also strengthens the relationship between GRC and organisational strategy. Davenport and Harris (2007) argue that analytical capability can become a source of competitive advantage when organisations systematically integrate information and decision-making. Research on digital business strategy similarly emphasises the integration of digital technologies with organisational processes and capabilities, while research on artificial intelligence highlights the importance of balancing automation and human augmentation when designing AI-enabled work (Bharadwaj et al., 2013; Raisch and Krakowski, 2021). GRC should therefore be understood not merely as a protective function but as an organisational intelligence capability capable of improving strategic, operational and regulatory decisions.

This perspective also changes how AI should be evaluated within GRC. An AI system that summarises regulations, produces dashboards or drafts compliance reports may create efficiency without materially improving decision quality. Conversely, a system that identifies a previously undetected dependency, models alternative responses, identifies affected obligations and presents an evidence-backed recommendation to an authorised decision-maker may generate substantially greater organisational value. AI use cases should therefore be evaluated not only according to their automation potential, but also according to their strategic relevance, integration with organisational processes, data requirements, allocation of tasks between humans and AI, expected value and associated governance risks (Bharadwaj et al., 2013; Raisch and Krakowski, 2021; NIST, 2023).

The strategic objective is consequently decision advantage: the ability to make better-informed, more timely and more defensible decisions under conditions of uncertainty. GRC becomes valuable not because it produces more information, but because it improves the organisation's capacity to interpret uncertainty and act responsibly.

2.3 From Isolated Controls to an Interconnected Control Architecture

The traditional GRC model often represents controls as discrete objects. A control has an owner, a frequency, an objective, an evidence requirement and a testing procedure. This structure is essential for accountability, but it can encourage a fragmented understanding of organisational risk. Modern organisations do not experience risk in discrete categories. Operational resilience, cybersecurity, financial crime, third-party risk, data governance, regulatory compliance and strategic risk increasingly intersect.

The GRC literature consequently supports understanding compliance as an integrated organisational architecture connecting business objectives, governance arrangements, data, technology, processes and control mechanisms (COSO, 2017; ISO/IEC, 2023). Under this model, controls are not simply items within a library. They become components within an interconnected system of prevention, detection, decision-making, intervention and assurance, embedded within the processes through which the organisation manages risk and pursues its objectives.

This has particular relevance to customer due diligence and financial crime compliance. The FATF's risk-based approach to customer due diligence emphasises the importance of understanding and managing customer risk through appropriate identification, verification and ongoing monitoring, while its guidance on risk-based supervision emphasises the need for financial institutions and supervisors to maintain an evolving understanding of risk (FATF, 2017; FATF, 2021). The strategic implication is that information collected for one compliance purpose can become relevant to multiple risk domains, provided that its use remains lawful, proportionate, governed and traceable.

The same principle applies to cybersecurity. AI-enabled threat intelligence can enrich organisational understanding by identifying relevant entities, relationships, patterns and emerging threats. Identity, access rights, data provenance and system permissions consequently become common control dependencies between cybersecurity, AI governance and GRC, requiring appropriate governance and monitoring across the AI and information-system lifecycle (NIST, 2023). Identity and access controls are therefore not merely technical security mechanisms but important components of the broader control environment through which organisations govern access to data, systems and AI-enabled capabilities.

This architectural perspective becomes even more important as organisations increasingly depend on external providers and interconnected ecosystems. Enterprise risk management research highlights the importance of understanding risk across organisational boundaries and recognising the interdependencies through which exposures can arise and affect organisational performance (Bromiley et al., 2015). Third-party governance can therefore no longer be reduced to onboarding questionnaires and periodic supplier reviews. It increasingly requires an understanding of dependencies, information flows, technology relationships and changing risk conditions across the extended enterprise (Bromiley et al., 2015; NIST, 2023).

The strategic case for transformation is consequently based on control interdependence. A control should be understood not only by asking whether it exists, but also by asking what data it depends upon, which systems execute it, which external parties influence it, which decisions it supports, and what happens when its assumptions no longer hold. This shifts GRC from assessing controls as isolated artefacts towards understanding them as interconnected components of an organisational control system.

2.4 From Process Automation to Process Reinvention

A further reason to transform GRC is that digitising existing processes does not necessarily produce meaningful transformation. Organisations can automate inefficient approval chains, digitise paper-based evidence, deploy AI-generated summaries and introduce workflow platforms while preserving the underlying assumptions that made the original processes inefficient.

Research on digital business strategy and the organisational implications of artificial intelligence suggests that established processes, organisational structures and professional roles can constrain transformation even where technical capability is available (Bharadwaj et al., 2013; Raisch and Krakowski, 2021). This creates an important distinction between automation and reinvention. Automation makes an existing process faster or cheaper; reinvention questions whether the process should exist in its current form at all.

The distinction is particularly important for GRC because many compliance processes have accumulated layers of historical requirements, duplicated controls, manual reconciliations and institution-specific practices. AI can make such processes more efficient, but efficiency alone may preserve structural complexity. A high-performing GRC function should instead ask whether regulatory obligations, risk decisions, evidence production and assurance activities can be redesigned around a common information and control architecture.

The same principle emerges from the broader literature on digital business strategy and artificial intelligence. AI deployment does not automatically create organisational value; value depends upon the integration of technology with business processes, organisational capabilities and the operating model through which work is performed (Bharadwaj et al., 2013; Raisch and Krakowski, 2021). This is consistent with the broader literature on automation and augmentation. Raisch and Krakowski (2021) demonstrate that organisations face an automation–augmentation paradox: technologies can substitute for human activity while simultaneously creating opportunities to augment human capabilities.

For GRC, the appropriate objective is therefore neither wholesale automation nor preservation of human-centric processes. It is intelligent redistribution of work. Machines should undertake activities for which scale, consistency and computational capacity provide an advantage; humans should concentrate on activities requiring contextual interpretation, normative judgement, accountability, negotiation and responsibility for consequential decisions.

2.5 From Human-Only Analysis to Human–AI Complementarity

The emergence of generative and agentic AI intensifies this strategic argument. Generative AI can summarise complex information, extract regulatory obligations, classify documents, identify relationships and generate analytical outputs. Agentic AI extends these capabilities by enabling systems to reason over contextual information, retrieve external information, use tools, observe outcomes and execute sequences of actions (Yao et al., 2023).

However, greater technical capability does not eliminate the need for organisational control. Indeed, it increases it. An AI agent that can act across enterprise systems introduces fundamentally different governance considerations from an AI system that merely generates text. Tool permissions, identity, authorisation, escalation, verification, auditability and accountability therefore become integral to the architecture. These requirements are consistent with the need for clearly defined responsibilities, human oversight, monitoring and accountability across the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

Genuine agentic GRC therefore requires more than conversational interfaces or workflow automation. It requires systems in which contextual intelligence, authorised action and institutional accountability are deliberately integrated. Agentic capability should consequently be understood as a spectrum of autonomy, authority and adaptability rather than as a binary property. The appropriate degree of autonomy depends upon task structure, regulatory risk, explainability requirements, the potential consequences of error and organisational governance maturity (Raisch and Krakowski, 2021; NIST, 2023).

This distinction is critical for GRC. A low-risk administrative task may legitimately be highly automated. A complex regulatory interpretation or decision affecting a customer's legal rights may require substantially greater human involvement. The objective should therefore be meaningful human control, not symbolic human approval. Human roles, responsibilities and intervention points should be explicitly defined according to the risks and consequences associated with the relevant AI-enabled activity (NIST, 2023; ISO/IEC, 2023).

Enterprise agentic systems also require separation between intelligence and execution, with trusted data, provenance, identity, permissions, policy controls, observability, verification and escalation mechanisms surrounding the reasoning component. This separation prevents the AI model from becoming an uncontrolled source of transactional authority. The agent may recommend, orchestrate or initiate actions, while authoritative systems and governance mechanisms determine what it is permitted to execute (Yao et al., 2023; NIST, 2023).

Such architecture also addresses a central weakness of simplistic AI transformation strategies: the assumption that improved model performance automatically produces trustworthy organisational outcomes. AI systems can hallucinate, misinterpret context, rely on inappropriate information or be manipulated through adversarial inputs. Consequently, trustworthy deployment requires verification, accountability, continuous evaluation and controlled execution rather than reliance on model performance alone (NIST, 2023; ISO/IEC, 2023). Lewis et al.'s (2020) work on retrieval-augmented generation is also relevant because it demonstrates how generated outputs can be grounded in retrieved information. However, retrieval alone does not establish governance, provenance or decision accountability.

The strategic implication is therefore that GRC must become capable of governing AI as an organisational actor rather than merely governing AI as software.

2.6 From Static AI Governance to Continuous Organisational Control

This leads to a deeper transformation in the meaning of governance itself. Conventional AI governance frequently takes the form of principles, policies, risk assessments and approval procedures established before deployment. These remain necessary, but they can be inadequate for systems whose behaviour, data environments and use cases evolve continuously.

This corresponds with a broader movement from AI governance towards organisational control. Governance should be understood as an operational architecture containing policies, decision rights, accountable ownership, intervention mechanisms and evidence-producing processes rather than as a static compliance checklist (NIST, 2023; ISO/IEC, 2023). This is closely aligned with ISO/IEC 42001:2023 and the EU AI Act's emphasis on organisational responsibilities, risk management and demonstrable controls (ISO/IEC, 2023; European Union, 2024).

This corresponds with a broader movement from AI governance towards organisational control. Governance should be understood not simply as a set of policies or compliance statements, but as an operational arrangement comprising decision rights, accountable ownership, intervention mechanisms, monitoring and evidence-producing processes. This interpretation is consistent with ISO/IEC 42001:2023, which frames AI governance through a management-system approach involving defined responsibilities, documented processes, risk management, monitoring and continual improvement (ISO/IEC, 2023).

The strategic distinction is between having governance rules and possessing the capability to exercise control. An organisation may have an AI policy while lacking visibility of where AI is actually being used. It may have an approval process without continuous monitoring. It may require explainability without maintaining the information needed to reconstruct how an AI-supported decision was produced. Governance becomes substantive only when it can influence system behaviour and produce credible evidence of that influence.

For GRC, this means that policy, architecture and assurance must become tightly coupled. Governance requirements should be translated into technical and operational controls; controls should generate evidence; evidence should inform monitoring; monitoring should trigger intervention; and intervention should feed organisational learning.

The resulting model is closer to a control system than a policy repository.

2.7 From Digital GRC to an AI-Ready Organisational Infrastructure

None of these transformations can succeed without an appropriate data and technology foundation. AI does not remove the need for enterprise architecture; it makes the quality of that architecture more consequential. Research on digital business strategy emphasises that technological value depends upon the integration of digital capabilities with organisational processes, structures and resources rather than on technology deployment alone (Bharadwaj et al., 2013). Similarly, the AI Risk Management Framework highlights the importance of data quality, governance, documentation, monitoring and risk management across the AI lifecycle (NIST, 2023). The movement from data governance towards operational data infrastructure is therefore significant because governance principles must ultimately be translated into the characteristics, processes and controls of the data environment rather than remain separate policy statements.

For GRC, this implies the development of a trusted information substrate linking obligations, risks, controls, processes, assets, identities, customers, suppliers, incidents, transactions and evidence. Such an architecture requires data provenance, semantic consistency, access controls and appropriate lineage. It must also distinguish authoritative enterprise records from generated or inferred information. Knowledge-graph research is relevant to this requirement because it demonstrates how entities, concepts and relationships can be represented within interconnected information structures (Hogan et al., 2021).

The agentic architecture literature reinforces this point. Retrieval-augmented generation provides one mechanism for grounding model outputs in retrieved information, while agentic systems can combine reasoning, external information retrieval, tool use and feedback from observed outcomes (Lewis et al., 2020; Yao et al., 2023). However, simply connecting a large language model to a collection of documents does not create a trustworthy organisational intelligence system. Reliable interfaces, controlled access, appropriate permissions, provenance, monitoring and explicit governance remain necessary to ensure that retrieved information and subsequent actions are used appropriately (NIST, 2023; ISO/IEC, 2023). The deeper architectural challenge is therefore to make organisational knowledge both machine-actionable and institutionally trustworthy.

This also explains why modernisation matters strategically. Research on digital business strategy and the organisational implications of artificial intelligence positions transformation as a challenge involving technology, operating models, business processes and organisational capabilities rather than technology alone (Bharadwaj et al., 2013; Raisch and Krakowski, 2021). GRC becomes one of the critical domains through which this intelligence must be engineered because it provides the organisation's mechanisms for defining acceptable behaviour, detecting deviations and governing consequential decisions.

2.8 From Risk Management to Organisational Resilience

The strategic case for GRC transformation ultimately extends beyond compliance and efficiency to resilience. Organisations increasingly operate within environments characterised by cyber threats, geopolitical fragmentation, supply-chain dependencies, technological disruption, regulatory divergence and financial-system transformation. Preventing every disruption is neither realistic nor necessarily optimal. The more meaningful objective is the capacity to absorb disruption, adapt, recover and learn.

Resilience should be understood as the capacity to adapt to changing conditions, withstand adverse events and recover when disruption occurs rather than merely as the prevention of failure (NIST, 2023). This principle has direct implications for GRC. A mature control environment should not assume that controls will always operate as designed. It should identify potential failure modes, establish escalation mechanisms, maintain alternative pathways and learn from control breakdowns. Resilience therefore requires GRC to move beyond assessing whether controls operate under expected conditions towards understanding how the control environment performs when assumptions, systems or operating conditions change.

The same logic is visible in cybersecurity, where resilience depends upon the organisation's ability to govern, identify, protect, detect, respond to and recover from cybersecurity risks across changing technological and operational conditions (NIST, 2024). Threat intelligence can contribute to this capability by providing information that supports the identification and assessment of changing threats, but its value depends upon its integration with organisational risk management, decision-making and response processes. Cybersecurity should therefore be treated as an integral component of organisational resilience rather than as a separate technical control domain.

The principle also extends to emerging technologies such as quantum computing. Organisations must consider not only current technology risks but also how future technological developments could affect the resilience of cryptographic systems, data protection mechanisms and critical financial and digital infrastructure. This reinforces the broader GRC requirement to consider both current exposures and plausible changes in the technological environment when designing controls and resilience capabilities.

This resilience perspective changes the purpose of assurance. Assurance should not merely demonstrate that controls worked under historical conditions. It should provide evidence that the organisation is capable of maintaining acceptable outcomes when assumptions change.

GRC consequently becomes part of the organisation's adaptive capacity.

2.9 From Organisational Boundaries to Extended-Enterprise Governance

Another strategic driver is the erosion of organisational boundaries. Critical processes increasingly depend on cloud providers, software vendors, data utilities, fintechs, outsourcing arrangements, open-banking interfaces, payment infrastructures and other ecosystem participants. Consequently, an organisation's risk profile cannot be understood solely through its internally controlled assets. Enterprise risk management research emphasises the need to consider risk across organisational activities and interdependencies, while contemporary AI risk management also recognises that AI systems may depend upon external data, software, infrastructure and third-party components (Bromiley et al., 2015; NIST, 2023).

This becomes particularly important where AI systems depend upon external foundation models, cloud infrastructure, specialised data or third-party services. The governance challenge extends beyond evaluating the capabilities of an individual technology provider to understanding how external dependencies affect organisational objectives, control effectiveness, resilience and accountability. As AI-enabled processes become more interconnected, relationships between organisations, technologies, data sources and systems become increasingly important components of the risk environment (NIST, 2023; Hogan et al., 2021).

The same principle applies to digitally interconnected financial ecosystems. Technological capabilities increasingly span organisational boundaries, creating dependencies between financial institutions, technology providers, infrastructure operators and other ecosystem participants. These relationships can create both opportunities and new concentrations of risk, reinforcing the importance of understanding how interconnected components contribute to organisational outcomes (Bromiley et al., 2015; NIST, 2023).

GRC must therefore develop extended-enterprise visibility. Third-party risk should evolve from periodic due diligence towards more continuous intelligence concerning dependencies, control effectiveness, concentration risk, cyber posture and operational resilience. This does not mean attempting to control the entire ecosystem. It means understanding the dependencies upon which organisational objectives and regulatory obligations ultimately rest.

2.10 From Compliance Function to Strategic Organisational Capability

Taken together, these shifts establish a broader strategic proposition. GRC transformation is justified not simply because compliance processes are inefficient, but because the underlying risk, technological and organisational environment has become more dynamic and interconnected than the institutional architectures traditionally designed to govern it (Bromiley et al., 2015; COSO, 2017).

The organisation of the future requires a GRC capability that can continuously sense its environment, connect signals across risk domains, interpret uncertainty, support consequential decisions, orchestrate authorised interventions and produce credible evidence of control. It must operate across organisational boundaries, integrate with cybersecurity and financial crime capabilities, support AI-enabled processes and remain resilient when assumptions fail (NIST, 2023; ISO/IEC, 2023).

This is also why the transformation cannot be reduced to the implementation of a new GRC platform. Digital business strategy research emphasises that technological value depends upon the integration of digital capabilities with business processes, organisational structures and broader organisational capabilities rather than on technology deployment alone (Bharadwaj et al., 2013). Procurement and technology decisions must therefore be considered in relation to architectural integration, organisational capability and institutional control rather than software functionality alone.

Nor should transformation be equated with maximum automation. The appropriate objective is the optimisation of the human–machine–control system. Humans provide judgement, accountability and normative authority; AI provides scalable sensing, synthesis, prediction and reasoning; deterministic systems provide reliable execution; and the GRC control architecture ensures that each component operates within defined authority. This reflects the automation–augmentation paradox identified by Raisch and Krakowski (2021), while NIST (2023) emphasises the importance of clearly defined roles, responsibilities and human oversight in AI-enabled systems.

This synthesis is particularly important in regulated financial services. AI can affect multiple organisational and financial functions simultaneously, creating interactions between innovation, operational resilience, regulatory responsibility, cybersecurity, financial crime controls and organisational governance. Consequently, these concerns should not be treated as separate agendas but as interconnected dimensions of the broader organisational control architecture (NIST, 2023; ISO/IEC, 2023).

The strategic case for transforming GRC can therefore be expressed as a movement across four levels. At the first level, GRC must become continuous rather than periodic, ensuring that material changes in the risk environment can be detected before formal review cycles occur. At the second, it must become decision-oriented rather than evidence-oriented, ensuring that risk information improves the quality and defensibility of organisational action. At the third, it must become architectural rather than functional, integrating data, processes, technology, controls and organisational responsibilities. At the fourth, it must become adaptive rather than static, allowing governance mechanisms themselves to respond as technologies, risks, regulations and organisational conditions evolve (COSO, 2017; NIST, 2023; ISO/IEC, 2023).

The objective is therefore not an automated compliance department. It is an organisation in which governance and risk intelligence are embedded into the infrastructure of decision-making.

In this sense, the transformation of GRC is closely connected to the wider movement from digital enterprise towards increasingly intelligent organisational capabilities. Agentic AI, advanced analytics, modern data infrastructure and continuous monitoring provide new technical capabilities, but their strategic value depends upon the organisational architecture within which they operate (Bharadwaj et al., 2013; Raisch and Krakowski, 2021). Without governance, AI can accelerate uncontrolled decisions; without reliable data, it can industrialise poor information; without process reinvention, it can automate structural inefficiency; without human accountability, it can create responsibility gaps; and without resilience, it can amplify systemic vulnerabilities (NIST, 2023; ISO/IEC, 2023).

The strategic proposition is therefore deliberately broader than "AI-enabled GRC". AI-enabled GRC improves existing processes through intelligent technologies. The more consequential ambition is AI-native, decision-intelligent GRC: a continuously sensing, evidence-producing and adaptive organisational capability in which intelligence, authority, execution and accountability are deliberately engineered together.

GRC transformation should consequently be understood not as the automation of compliance, but as the engineering of organisational intelligence and control under conditions of uncertainty, interdependence and continuous technological change.

3. A Target Operating Model for AI-Enabled GRC

The strategic case for GRC transformation establishes the need to move from periodic assurance towards continuous sensing, from risk reporting towards decision intelligence, and from fragmented controls towards an adaptive organisational architecture. The next question is therefore organisational: what operating model is required to make these capabilities work together?

An AI-enabled GRC operating model should not be conceived as a conventional GRC function with artificial intelligence added to existing workflows. Such an approach risks reproducing the limitations of the legacy model while increasing the speed at which existing processes operate. The target state should instead be understood as an integrated organisational system in which business decisions, risk and regulatory intelligence, AI reasoning, authorised execution, control mechanisms and organisational learning operate as a continuous feedback loop. This reflects the broader requirement to integrate AI governance into organisational processes, responsibilities and controls rather than treating governance as a separate activity (NIST, 2023; ISO/IEC, 2023).

The proposed operating model therefore comprises six mutually reinforcing layers: business and decision; risk and regulatory intelligence; AI and decision intelligence; governed agentic execution; control and assurance; and organisational learning. These layers should not be interpreted as a linear technology stack. They constitute an organisational control system in which information flows upwards into interpretation and decision-making, authorised decisions flow downwards into execution, and evidence from outcomes continuously feeds back into the system.

The central design principle is that intelligence should be separated from authority, and authority should be separated from execution. AI may identify, interpret, recommend and orchestrate, but the organisation must retain explicit control over who or what is authorised to make consequential decisions and execute consequential actions. This principle is consistent with the need for clearly defined human and AI roles, responsibilities, oversight and accountability as AI systems become capable of taking actions through external tools and environments (NIST, 2023; Yao et al., 2023). It also reflects the broader distinction between automation and augmentation, in which organisations must deliberately determine how responsibilities and tasks are allocated between humans and AI (Raisch and Krakowski, 2021).

3.1 Layer 1: Business and Decision

The operating model should begin not with technology but with the decisions the organisation needs to make. This is a critical departure from technology-led transformation because the value of GRC ultimately lies in improving decisions under conditions of uncertainty rather than maximising automation.

The first layer should therefore establish a structured representation of the organisation's critical decisions, strategic objectives, risk appetite, regulatory obligations, material processes and decision rights. Examples include approving a high-risk customer, entering a new jurisdiction, onboarding a critical supplier, approving an AI system, changing a material business process, responding to a cyber incident, determining capital or liquidity actions, or approving a high-risk transaction.

This decision-centric orientation reflects a shift from risk quantification towards decision intelligence, in which risk information and analytical evidence are connected to organisational objectives, governance responsibilities and managerial judgement. It also aligns with the broader principle that risk management should be integrated with strategy and performance so that risk information contributes directly to organisational decision-making rather than being treated as a separate reporting activity (COSO, 2017). More broadly, research on digital business strategy suggests that analytical and technological capabilities create organisational value when they are integrated with business processes and organisational capabilities rather than developed as standalone technical resources (Bharadwaj et al., 2013).

The implication is that GRC should not ask simply whether a risk has increased. It should establish what that change means for a decision. A change in a supplier's cyber posture, for example, may be relatively unimportant in isolation but strategically significant if the supplier supports a critical process with no viable substitute. Similarly, a change in a customer's transaction behaviour becomes materially different when considered alongside beneficial ownership, sanctions exposure, jurisdictional risk and the customer's broader relationship with the institution.

The first layer therefore provides the decision context within which subsequent intelligence is interpreted.

Its principal output is not a risk report but trusted intelligence at the point of decision.

This establishes a critical principle for AI use-case selection. AI should be deployed where it improves strategically important decisions or materially strengthens the control environment, rather than simply where a task happens to be automatable. The value of an AI initiative depends on how effectively its capabilities are integrated with business processes, organisational responsibilities and complementary resources, not merely on whether the underlying task can be technically automated (Bharadwaj et al., 2013). Similarly, the organisational consequences of AI depend upon how tasks and responsibilities are allocated between humans and machines, including where human judgement, oversight and accountability remain necessary (Raisch and Krakowski, 2021).

The use-case selection approach proposed in this paper therefore evaluates strategic relevance, process integration, data availability, human–AI roles, economic value and governance risk as interconnected dimensions of use-case viability. These dimensions are intended to prevent organisations from prioritising initiatives solely on the basis of technical feasibility or anticipated productivity gains. A use case should also be assessed according to whether it addresses a meaningful organisational need, can be supported by reliable data, fits within existing or redesigned workflows, has clearly defined human and machine responsibilities, creates sufficient value and can be governed proportionately to its potential risks.

This approach is consistent with risk-based AI governance, which requires consideration of intended use, potential impacts, data and system dependencies, human oversight and the controls necessary to manage AI-related risks (NIST, 2023). It also reinforces the distinction between automation potential and organisational suitability. A task may be technically automatable but strategically unimportant, poorly integrated, unsupported by reliable data or too consequential to execute without substantial human oversight.

The resulting principle is that AI use-case selection should be treated as an operating-model and control-design decision, not simply as a search for tasks that can be automated. The most valuable use cases are those in which AI capability, organisational purpose, process design, decision rights and governance requirements reinforce one another.

The operating model consequently starts with a deceptively simple question:

Which organisational decisions matter most, and what intelligence is required to make them well?

3.2 Layer 2: Risk and Regulatory Intelligence

Once critical decisions have been identified, the second layer provides the continuously updated information required to support them. This layer should be understood as a GRC intelligence fabric rather than a conventional data warehouse or document repository.

It should integrate relevant internal and external signals, including regulations, supervisory communications, internal policies, risk indicators, incidents, audit findings, control performance, customer and transaction information, third-party intelligence, cyber threat intelligence, financial and operational data, geopolitical developments and other material environmental signals. The purpose is to create a connected information environment in which relevant risk and regulatory information can be accessed, interpreted and related to the decisions and controls it informs (COSO, 2017; NIST, 2023).

The significance of this architecture lies not simply in aggregation but in contextualisation and relationships. A regulation should be connected to the processes, products, controls and jurisdictions to which it applies. A control should be connected to the risks and obligations it mitigates. A supplier should be connected to the processes and services dependent upon it. An incident should be connected to the affected assets, controls, processes and regulatory obligations. Such relationships transform disconnected information into organisational knowledge. This relationship-oriented approach is consistent with research on knowledge graphs, which demonstrates how relationships between entities can be represented explicitly to support more connected forms of information retrieval and reasoning (Hogan et al., 2021).

The architecture therefore supports a move away from isolated risk registers and information repositories towards more integrated representations of organisational risk. Enterprise risk management research emphasises the importance of understanding risk in relation to organisational objectives and the interactions between different sources of exposure, while the NIST AI Risk Management Framework emphasises the importance of appropriate data, context, documentation and ongoing monitoring across the AI lifecycle (Bromiley et al., 2015; NIST, 2023). The proposed GRC intelligence fabric extends these principles by connecting risk, regulatory, control and operational information within a common organisational context.

The transformation of KYC provides a particularly useful illustration. Risk-based approaches to customer due diligence emphasise the importance of understanding customer risk and applying appropriate identification, verification and ongoing monitoring measures. FATF guidance also emphasises the need for financial institutions and supervisors to maintain an evolving understanding of risk rather than relying on static assessments (FATF, 2017; FATF, 2021). The same lifecycle principle can be extended across GRC. Rather than asking whether a customer, supplier, process or control was compliant when it was last assessed, the organisation should continuously evaluate whether relevant circumstances have changed.

This layer should therefore support continuous risk sensing. The objective is not to create an indiscriminate stream of alerts. It is to establish mechanisms for distinguishing significant changes in risk from normal operational variation and for directing material signals towards the appropriate decision, control or escalation process (NIST, 2023).

AI-ready data architecture is fundamental to this capability. Effective AI deployment depends not only on model capability but also on the quality, accessibility, interoperability and governance of the underlying data environment. Digital business strategy research similarly demonstrates that technological capabilities create organisational value when they are integrated with business processes and organisational capabilities rather than developed as standalone technical resources (Bharadwaj et al., 2013; NIST, 2023). The data architecture supporting GRC must therefore provide appropriate governance, traceability, access controls and contextual consistency while remaining sufficiently interoperable to support analytics and AI-enabled decision processes.

The second layer therefore acts as the organisational memory and sensing infrastructure of GRC: connecting heterogeneous information, preserving relationships between risks and organisational objects, detecting material changes and providing the contextual foundation upon which AI-supported analysis and decision-making can operate.

3.3 Layer 3: AI and Decision Intelligence

The third layer transforms information into analytical and decision-relevant intelligence. This is where machine learning, generative AI, probabilistic models, knowledge graphs, retrieval-augmented generation, anomaly detection, scenario analysis and other analytical techniques can be deployed according to the characteristics of the use case. The choice of technique should reflect the nature of the task, the available data, the level of uncertainty and the consequences associated with error rather than being driven by technological novelty alone (NIST, 2023; Raisch and Krakowski, 2021).

The output may include classifications, predictions, scenarios, correlations, summaries, explanations, risk signals, recommendations or proposed control responses. However, the architectural principle must remain clear: probabilistic intelligence does not constitute organisational authority.

This distinction is essential because the outputs of AI systems are inherently subject to uncertainty. Even highly capable models can produce erroneous, incomplete or contextually inappropriate outputs. Research on generative AI demonstrates that such systems can substantially improve productivity while still requiring appropriate judgement concerning the quality, applicability and limitations of their outputs (Noy and Zhang, 2023; Brynjolfsson, Li and Raymond, 2025). The objective of the AI layer should therefore not be to create an artificial source of certainty, but to improve the organisation's capacity to interpret complex information while making relevant uncertainty and limitations visible (NIST, 2023).

Decision intelligence should consequently expose, where material, the assumptions, evidence and limitations underlying an analytical output rather than hide them behind apparently precise scores. Explainability should also not be treated simply as a technical requirement to produce a model explanation. In a GRC context, meaningful explainability concerns whether an authorised decision-maker can understand the evidence, reasoning and limitations of an AI-supported recommendation sufficiently to exercise responsible judgement. This places explainability within a broader governance framework concerned with accountability, transparency and the appropriate allocation of responsibility (NIST, 2023; Novelli, Taddeo and Floridi, 2024).

This is where human–AI complementarity becomes important. Research on the automation–augmentation paradox demonstrates that AI can simultaneously substitute for some forms of human work while increasing the value of other forms of human expertise (Raisch and Krakowski, 2021). The implication for GRC is that AI should be deployed selectively according to the characteristics and consequences of the task, with human expertise retained where contextual interpretation, judgement or accountability is material. The value of the AI layer therefore arises not simply from automating individual activities, but from combining machine capabilities with organisational knowledge, appropriate processes and human judgement.

The appropriate operating model is therefore not “AI decides”. It is AI informs, humans govern, systems execute within authority.

Different decision types will require different degrees of machine involvement. Low-risk classification or information-retrieval tasks may be highly automated. Higher-risk decisions may require human review, challenge or approval. Decisions involving legal interpretation, significant customer impact, regulatory judgement or material financial consequences should generally be subject to more demanding governance arrangements, including clearly defined responsibilities, oversight mechanisms and escalation thresholds (NIST, 2023; ISO/IEC, 2023).

The appropriate level of AI involvement should therefore be determined by factors including task characteristics, potential impact, uncertainty, the need for human judgement, explainability requirements and the organisation's governance capabilities. This reflects the broader principle that the allocation of work between humans and AI should be deliberately designed rather than determined solely by technical feasibility (Raisch and Krakowski, 2021; NIST, 2023).

The AI layer should therefore produce not merely an answer but an evidence-backed decision context containing, where appropriate, the relevant sources, confidence or uncertainty, assumptions, affected obligations, alternative scenarios and recommended actions. Retrieval-augmented generation can support this objective by connecting generative models to external knowledge sources, while agentic approaches can combine reasoning with information retrieval, action and observation (Lewis et al., 2020; Yao et al., 2023). Within GRC, however, these capabilities should operate within defined governance boundaries so that analytical intelligence strengthens decision-making without becoming an uncontrolled source of organisational authority.

3.4 Layer 4: Governed Agentic Execution

The fourth layer represents the most significant architectural extension beyond conventional AI-enabled GRC. Agentic AI can move from interpreting information towards planning and executing multi-step activities through authorised enterprise tools. Research on agentic approaches demonstrates how language models can combine reasoning with external actions, observations and iterative planning, creating capabilities that extend beyond the generation of static outputs (Yao et al., 2023).

The distinction between generative and agentic AI is therefore consequential. A generative system may produce a recommendation or draft a compliance assessment, whereas an agentic system can potentially retrieve evidence, determine the next procedural step, invoke enterprise applications, create remediation tasks, request approvals, update records and verify whether an action produced the intended result (Yao et al., 2023). The movement from information generation towards action changes the nature of the GRC control problem because governance must extend beyond the quality of an AI output to the authority under which the system is permitted to act.

Once an AI system can interact with external tools and organisational systems, its governance must address not only model performance but also the allocation of responsibility, human oversight, access to relevant resources, monitoring and the conditions under which actions are permitted (NIST, 2023; ISO/IEC, 2023). The agent should consequently interact with enterprise systems through explicitly defined and authorised interfaces rather than possessing unrestricted access. This establishes a separation between the agent's capacity to reason and the organisational authority required to execute consequential actions.

The resulting execution loop can be represented as:

Goal → Observe → Reason → Act → Verify → Repeat → Complete/Escalate.

The significance of the final two stages should not be underestimated. An agent should not be considered successful merely because it performed an action. It should establish whether the action achieved the intended outcome and whether the result remains within the organisation's control boundaries. Where uncertainty, failure or policy conflict arises, the system should escalate rather than continue autonomously. This emphasis on monitoring, evaluation and defined human oversight is consistent with the lifecycle-oriented governance principles of the NIST AI Risk Management Framework (NIST, 2023).

A GRC agent might therefore be authorised to retrieve an applicable policy, identify a regulatory obligation, assess available evidence, create a remediation task, initiate an appropriate review, request human approval, escalate a risk or prepare an audit package. It should not automatically acquire unrestricted authority to alter material records, approve high-risk decisions or execute consequential transactions. The precise allocation of authority should reflect the potential impact of the action, the level of uncertainty involved and the organisation's governance arrangements (NIST, 2023; ISO/IEC, 2023).

This creates a controlled action surface: a deliberately constrained set of tools, permissions, policies and escalation mechanisms through which an AI agent can interact with the organisation. The concept is consistent with the broader principle that AI governance must be translated into operational processes, responsibilities and controls rather than remaining at the level of high-level policy statements (NIST, 2023; ISO/IEC, 2023).

The distinction also preserves the role of deterministic automation. Not every GRC activity requires adaptive agentic reasoning. Where processes are predictable, rules are well defined and execution requirements are highly repeatable, conventional workflow automation and deterministic enterprise systems may remain preferable. Agentic AI is more valuable where activities require interpretation, information retrieval, sequencing, orchestration or adaptation to changing circumstances. The target architecture should therefore not replace deterministic systems with agents indiscriminately. Instead, agents can operate as an interpretive and orchestration layer above authoritative enterprise systems, with consequential transactions remaining subject to established controls and permissions.

This distinction is particularly important in regulated environments, where AI-enabled systems may interact with customer information, compliance processes, financial infrastructure and other consequential organisational capabilities. As AI systems become more capable of acting through external tools, questions of accountability, human oversight and control become increasingly important because errors can propagate from an analytical output into an organisational action (NIST, 2023; Novelli, Taddeo and Floridi, 2024).

The strategic objective is therefore bounded autonomy: sufficient autonomy to generate meaningful operational value, but bounded by explicit identity, authority, policy, monitoring, verification and escalation mechanisms. In this model, autonomy is not treated as an end in itself. It is a controlled organisational capability whose permissible scope is determined by risk, consequence, accountability and governance maturity.

3.5 Layer 5: Control and Assurance

The fifth layer provides the mechanisms through which the organisation exercises control over the entire operating model. This layer should not be treated as an after-the-fact assurance function. Controls should be embedded throughout the architecture and operate alongside intelligence and execution, so that governance requirements are translated into operational mechanisms rather than applied only through retrospective review (NIST, 2023; ISO/IEC, 2023).

Core mechanisms should include identity, authentication, authorisation, segregation of duties, policy enforcement, approval thresholds, logging, provenance, model evaluation, exception management, monitoring, rollback and auditability. The precise combination of mechanisms should reflect the nature and consequences of the activities being governed, with stronger controls applied where AI systems can affect material organisational decisions, sensitive information or consequential transactions (NIST, 2023).

Identity is particularly important because agentic systems introduce the possibility of machine identities interacting across multiple enterprise systems. The organisation must therefore be able to establish which actor or agent performed an action, under whose authority, using which permissions, against which information and with what outcome. Identity, access management and clearly defined responsibilities consequently form important connections between cybersecurity, AI governance and GRC (NIST, 2023).

Provenance is equally important. AI-generated conclusions should be traceable, where practicable, to the information and processes upon which they were based. Retrieval-augmented approaches can help connect generative models to external knowledge sources, but retrieval itself does not guarantee correctness, completeness or appropriate governance of the retrieved information (Lewis et al., 2020). GRC therefore requires provenance across relevant stages of the decision and control process, including sources, transformations, model versions, instructions where material, decisions, actions and approvals.

The control layer should also accommodate adversarial and operational risks associated with AI-enabled systems. As AI systems become integrated with external tools, data sources and enterprise applications, the potential consequences of erroneous or manipulated outputs extend beyond the model itself. Effective governance therefore requires ongoing risk identification, testing, monitoring, evaluation and mechanisms for responding to unexpected behaviour (NIST, 2023; Autio et al., 2024). Consequently, the security architecture of AI-enabled GRC cannot be treated as entirely separate from its governance and control architecture.

This supports a broader transition from AI governance as a set of principles towards organisational control. Effective governance requires clearly defined roles and responsibilities, accountability mechanisms, operational controls, human oversight and processes capable of demonstrating how AI systems are governed throughout their lifecycle (NIST, 2023; ISO/IEC, 2023). Accountability is particularly important because responsibility for an AI-supported decision cannot simply be transferred to the system that generated the recommendation or performed the action (Novelli, Taddeo and Floridi, 2024).

The control layer should therefore answer five fundamental questions:

Who is authorised to act? What are they authorised to do? Under which policy? What evidence demonstrates that the action was appropriate? What happens when the system behaves outside its authorised boundaries?

These questions apply equally to humans, software and AI agents.

Assurance consequently becomes continuous rather than purely retrospective. AI systems and their operating environments can change as models, data, regulations, vendors, processes and use cases evolve. The NIST AI Risk Management Framework therefore emphasises ongoing monitoring, measurement and management of AI risks across the system lifecycle rather than treating risk assessment as a one-time deployment activity (NIST, 2023). ISO/IEC 42001 similarly establishes a management-system approach in which AI governance is subject to defined processes, monitoring and continual improvement (ISO/IEC, 2023).

The fifth layer therefore establishes continuous demonstrable control, rather than one-time compliance. Its purpose is not merely to demonstrate after the fact that governance requirements existed, but to provide ongoing evidence that authority was appropriately allocated, controls operated as intended, exceptions were identified and managed, and AI-enabled activities remained within defined organisational boundaries.

3.6 Layer 6: Organisational Learning

The sixth layer closes the operating loop. Without organisational learning, continuous monitoring simply produces continuous information; without feedback, automation can reproduce errors at scale.

GRC should therefore systematically learn from incidents, control failures, audit observations, false positives, regulatory findings, management overrides, customer complaints, model performance, agent failures and operational outcomes. These events should not be treated merely as evidence of individual breakdowns. They should be analysed for what they reveal about the assumptions, controls, processes and decision structures of the wider system. This reflects the broader principle of enterprise risk management that risk management should support organisational performance and adapt to changes in the organisation and its operating environment (COSO, 2017).

This learning perspective is also consistent with the lifecycle orientation of contemporary AI governance. The NIST AI Risk Management Framework emphasises ongoing measurement, monitoring, risk management and the identification of changes that may affect the performance or trustworthiness of AI systems, while ISO/IEC 42001 establishes a management-system approach based on monitoring and continual improvement (NIST, 2023; ISO/IEC, 2023). The implication for GRC is that control effectiveness and AI-system performance should be treated as evolving properties rather than fixed characteristics established at deployment.

For example, a false-positive sanctions alert may indicate a model calibration problem, poor data quality or an overly conservative policy. A repeated control override may indicate that the formal process does not reflect operational reality. An agent repeatedly escalating the same type of exception may reveal an ambiguity in policy rather than a failure of the agent itself. A regulatory finding may indicate a structural weakness in the relationship between policy, process, data and system implementation. These examples illustrate why learning should examine relationships between technology, processes, controls and human decisions rather than attributing every failure to an individual component.

Organisational learning therefore requires GRC to analyse not merely what failed, but why the system produced the failure and what should change as a consequence.

This creates a feedback loop between operational experience and governance design. Lessons from incidents can modify policies; policy changes can alter controls; control changes can modify agent permissions; new evidence can change models; model changes can alter decision thresholds; and changes in organisational conditions can trigger reassessment of the overall control architecture. Such feedback is consistent with the continual-improvement orientation of ISO/IEC 42001 and with the NIST emphasis on continuous monitoring and risk management across the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

The learning layer should also recognise that not every intervention should be automated. Some lessons can be incorporated through automated recalibration, rule updates or workflow adjustments, while material changes to policies, decision rights, control thresholds or AI system behaviour may require formal governance review and human approval. The organisation must therefore distinguish between learning from experience and authorising change: evidence can inform adaptation, but adaptation should remain subject to appropriate governance.

The learning layer therefore transforms GRC from an assurance mechanism into an adaptive capability. Its purpose is not simply to record what happened, but to convert operational experience into changes in policies, controls, models, processes and decision structures, thereby enabling the overall GRC system to become progressively more effective as its environment and its own behaviour evolve.

3.7 The Operating Model as a Closed-Loop Control System

The six layers should ultimately operate as a single closed-loop system rather than as six independent GRC capabilities. Their value arises from the interaction between decision-making, risk intelligence, AI-supported analysis, authorised execution, control and assurance, and organisational learning.

The business and decision layer establishes what matters. The risk and regulatory intelligence layer establishes what is changing. The AI and decision-intelligence layer evaluates what those changes mean. The governed agentic layer determines what authorised actions can be taken. The control and assurance layer establishes whether those actions remain within organisational authority and policy. The organisational learning layer determines what should change as a result of experience. This integrated logic reflects the broader principle that risk management should be connected to organisational objectives, decision-making, performance and continual improvement rather than operating as a collection of isolated control activities (COSO, 2017; NIST, 2023; ISO/IEC, 2023).

This produces a fundamentally different operating logic from the conventional GRC cycle. Rather than:

Assess → document → report → test → remediate → repeat

the target model operates as:

Sense → contextualise → interpret → decide → authorise → execute → verify → learn → adapt.

The distinction is not semantic. It changes the role of the GRC function itself.

Under the conventional model, GRC primarily provides oversight of activities undertaken elsewhere in the organisation. Under the target model, GRC becomes an embedded intelligence and control capability that participates in the information flows surrounding consequential decisions while retaining appropriate independence and challenge. This does not imply that GRC assumes operational responsibility for every decision or control. Rather, it means that risk intelligence, governance requirements and control mechanisms become more closely integrated with the processes through which consequential organisational activities are undertaken.

This does not mean that the second line of defence should disappear or that GRC should become indistinguishable from business operations. On the contrary, independent challenge, accountability and clearly defined responsibilities remain essential. NIST emphasises the importance of clearly defined roles, responsibilities and human oversight in AI-enabled systems, while COSO positions risk management as an organisational capability that should operate in conjunction with governance, strategy and performance (NIST, 2023; COSO, 2017). The transformation therefore concerns the mechanisms through which these responsibilities are exercised. Instead of relying predominantly on periodic reviews and manually assembled evidence, the second line can increasingly operate through continuous intelligence, automated control monitoring, exception-based intervention and reconstructable evidence.

The result is a model in which assurance becomes increasingly exception-driven rather than population-driven. Where controls operate predictably within defined tolerances, automated monitoring can provide continuous evidence of performance. Human attention can then be concentrated on material exceptions, ambiguous cases, emerging risks and situations in which underlying assumptions have changed. This approach is consistent with the lifecycle orientation of AI governance, in which monitoring, measurement and risk management continue after deployment rather than being confined to initial assessment (NIST, 2023; ISO/IEC, 2023).

The resulting operating model can therefore be understood as a continuous organisational control loop: the organisation senses change, contextualises its significance, interprets its implications, makes and authorises decisions, executes within defined boundaries, verifies outcomes, learns from experience and adapts its controls and decision structures accordingly. The six layers are consequently not separate components of a technology stack but mutually reinforcing elements of a decision-intelligent GRC capability.

3.8 Governance of the Operating Model Itself

A final implication is that the operating model must itself be governed. Introducing AI into GRC creates the possibility of a paradox in which the function responsible for organisational control becomes dependent upon opaque or insufficiently governed technologies. The governance of the GRC architecture must therefore extend to the technologies and capabilities through which GRC itself operates.

The target operating model requires explicit ownership of AI systems, agents, models, data assets, policies and decision rights. The organisation should maintain visibility over where AI is deployed, what decisions it influences, what authority it possesses, what data it can access and what controls constrain its behaviour. Clearly defined roles, responsibilities, accountability and oversight are fundamental to effective AI governance, particularly where AI systems operate across organisational processes and interact with external tools or information sources (NIST, 2023; ISO/IEC, 2023).

This requirement also extends to the organisation's technology dependencies. As AI-enabled GRC increasingly relies upon external cloud services, foundation models, data providers and specialised compliance technologies, governance must consider not only the performance of individual components but also the dependencies and concentration risks created by the wider technology architecture. Enterprise risk management research emphasises the importance of understanding interdependencies and the ways in which exposures can affect organisational performance across organisational boundaries (Bromiley et al., 2015).

Consequently, architectural optionality becomes a governance capability. Modular interfaces, interoperable data structures, clear ownership, documented dependencies and replaceable components can reduce technology concentration and lock-in risks while preserving the organisation's ability to evolve the architecture. This principle also supports resilience by reducing dependence on individual technological components and making it easier to modify, replace or isolate components when their performance, risk profile or strategic suitability changes.

This consideration is particularly relevant to organisations operating across multiple jurisdictions and relying upon external digital infrastructures. The governance of AI-enabled GRC must therefore account not only for internal control but also for technology concentration, third-party dependencies, data governance, jurisdictional exposure and the organisational consequences of changes to critical technology providers (NIST, 2023; ISO/IEC, 2023).

The operating model should therefore govern both the use of AI and the architecture through which AI is used. This requires the organisation to maintain visibility over its AI dependencies, preserve appropriate control over critical decision rights and ensure that the technology supporting GRC remains sufficiently transparent, governable and adaptable. In this sense, architectural resilience and governance become mutually reinforcing capabilities: the organisation is better able to govern its AI-enabled GRC system when it retains the ability to understand, constrain, modify and, where necessary, replace the components on which that system depends.

3.9 The Resulting Target State

The target operating model can therefore be understood as a decision-centred, continuously sensing, AI-augmented and agentically orchestrated control system. Its defining characteristic is not the presence of AI, but the integration of intelligence with authority, execution, assurance and organisational learning.

At the front of the model, critical business decisions establish the purpose of GRC. Beneath this, a continuously updated intelligence fabric provides the evidence and context required for decision-making. AI converts that information into patterns, predictions, scenarios and recommendations, while governed agents can orchestrate authorised actions. A pervasive control architecture constrains identity, permissions, policy, execution and evidence. Finally, organisational learning feeds operational outcomes back into the system so that models, controls, policies and processes can evolve. This integrated approach reflects the broader principle that risk management, AI governance and organisational performance should be connected rather than managed as separate activities (COSO, 2017; NIST, 2023; ISO/IEC, 2023).

This architecture also provides a principled answer to the question of where autonomy should reside. AI should have sufficient autonomy to reduce cognitive and operational burden, but insufficient authority to bypass institutional governance. The more consequential the decision, the stronger the requirements for explainability, verification, human judgement and explicit authorisation should become. This reflects the need to establish clearly defined human and AI roles, responsibilities and oversight arrangements, particularly where AI systems can influence or execute consequential actions (NIST, 2023; ISO/IEC, 2023).

The target state is consequently neither a fully autonomous GRC function nor a traditional GRC function with AI tools attached. It is a human–AI organisational control system in which different forms of intelligence and automation are deliberately allocated according to risk, decision significance, task characteristics and organisational capability. This reflects the automation–augmentation paradox: AI can substitute for some forms of human activity while simultaneously increasing the importance of human expertise, judgement and oversight in other areas (Raisch and Krakowski, 2021).

This distinction is fundamental to achieving sustainable value. Research on digital business strategy indicates that technological capabilities generate organisational value when they are integrated with business processes, organisational structures and complementary capabilities rather than deployed as isolated technical resources (Bharadwaj et al., 2013). Similarly, research on AI and work demonstrates that the productivity effects of generative AI depend upon how the technology is incorporated into existing tasks and workflows rather than simply on the availability of the technology itself (Noy and Zhang, 2023; Brynjolfsson, Li and Raymond, 2025). The implication for GRC is that AI capability must be embedded within appropriate data foundations, processes, governance mechanisms and organisational responsibilities.

The target operating model should therefore be judged against four outcomes.

First, it should provide better decision intelligence by connecting risk, regulatory and operational information to consequential organisational choices.

Second, it should provide stronger control by making authority, permissions, accountability and evidence explicit across human and machine actors.

Third, it should provide greater operational efficiency by automating appropriate high-volume sensing and execution while concentrating human expertise on judgement, exceptions and accountability.

Fourth, it should provide greater adaptability and resilience by continuously learning from changing conditions, control failures, incidents and emerging risks. These outcomes are consistent with the broader objectives of integrating risk management with organisational performance and establishing continuous monitoring and improvement across AI-enabled systems (COSO, 2017; NIST, 2023; ISO/IEC, 2023).

The strategic ambition is consequently greater than implementing an AI-enabled GRC platform. It is to construct an organisational architecture in which governance becomes continuous, intelligence becomes actionable, execution becomes bounded, assurance becomes evidence-based and learning becomes systemic.

In this target state, GRC ceases to function primarily as a periodic reviewer of organisational activity. It becomes part of the organisation's decision infrastructure: continuously sensing its environment, interpreting uncertainty, supporting judgement, controlling authorised action and learning from outcomes. This represents the organisational foundation for a transition from conventional GRC towards a genuinely decision-intelligent and adaptive GRC system.

4. Strategic Pillar 1: Build an AI-Ready GRC Data Foundation

The first priority in transforming GRC should not be the deployment of a large language model or an agentic application. It should be the construction of the information infrastructure upon which trustworthy, explainable and operationally valuable AI depends. Without reliable data, coherent relationships, appropriate access controls and traceable evidence, AI may increase the speed and scale of analysis while reproducing or amplifying existing weaknesses in the control environment. Effective AI risk management therefore requires appropriate attention to data quality, governance, context and lifecycle management rather than focusing exclusively on model capability (NIST, 2023).

The development of this foundation is consistent with the wider information systems literature, which demonstrates that information technology capabilities create organisational value through their interaction with organisational resources, complementary capabilities and business processes (Bharadwaj, 2000; Bharadwaj et al., 2013). In the context of GRC, the strategic challenge is therefore not simply to make GRC data available to AI systems, but to make it sufficiently reliable, contextualised, interoperable and governed to support consequential organisational decisions. AI readiness should consequently be understood as an organisational capability involving data, technology, processes and governance rather than as a property of the AI model alone (Bharadwaj et al., 2013; NIST, 2023).

The required foundation should be understood as a GRC data fabric: an interconnected information architecture linking the organisation's regulatory environment to its internal decision-making and control processes. Its conceptual chain can be represented as:

Regulation → policy → obligation → risk → control → process → system → evidence → decision → outcome.

This chain is important because GRC information is fundamentally relational. A regulatory obligation does not exist in isolation. It may be implemented through a policy, operationalised through one or more controls, embedded in a business process, dependent upon a particular system and evidenced through records generated by employees, technologies or third parties. A risk may affect several processes, depend upon a common data source and require coordinated controls across multiple business units. An incident may simultaneously create operational, regulatory, cyber, financial crime, third-party and reputational implications. Enterprise risk management therefore requires risk to be considered in relation to organisational objectives and the wider system of activities through which those objectives are pursued (COSO, 2017; Bromiley et al., 2015).

A data foundation that stores these objects separately without representing their relationships will remain limited for advanced GRC. The objective should instead be to establish a machine-interpretable representation of how obligations, risks, controls, processes, systems, actors and outcomes relate to one another. Research on knowledge graphs demonstrates the value of representing entities and their relationships explicitly, providing a basis for more connected information retrieval, integration and reasoning (Hogan et al., 2021).

Such a foundation also creates the basis for traceability. AI-supported analysis should be capable, where appropriate, of connecting a recommendation or risk signal back to the underlying evidence, relevant obligations, affected controls and originating data. This makes the data architecture not merely an information repository but part of the GRC control environment itself. The resulting capability provides the contextual foundation required for subsequent AI-enabled analysis, decision support, governed execution and continuous assurance (NIST, 2023).

The strategic priority is therefore to establish trusted, connected and governable GRC information before attempting to maximise AI autonomy. In the proposed operating model, the quality of the data fabric determines the quality of the intelligence that can be produced from it, while the relationships represented within that fabric determine the organisation's ability to understand how changes in regulation, risk, controls, processes and systems affect consequential decisions.

4.1 From Document Repositories to Organisational Knowledge Infrastructure

Conventional GRC environments are often organised around documents and records: policies, risk registers, control descriptions, assessment forms, audit reports, issue logs and evidence repositories. These artefacts remain important, but their value is limited when they are disconnected from the operational context in which they are created and used.

The strategic objective should therefore be to transform GRC from a collection of documents into an organisational knowledge system. This requires information to be represented in ways that support both human interpretation and machine reasoning. A policy should be linked to the obligations it addresses, the controls through which it is implemented, the processes in which those controls operate and the evidence required to demonstrate effectiveness.

This approach is consistent with the broader principle that governance requirements must be translated into operational processes, responsibilities and controls rather than remaining solely as documented policies. NIST emphasises the importance of governance, documentation, accountability, data management and ongoing monitoring throughout the AI lifecycle, while ISO/IEC 42001 establishes a management-system approach for governing AI-related processes and responsibilities (NIST, 2023; ISO/IEC, 2023). Similarly, research on digital business strategy demonstrates that the value of technological capabilities depends upon their integration with organisational processes and complementary capabilities (Bharadwaj et al., 2013).

The transformation is therefore not achieved simply by digitising paper records. It requires the organisation to define the semantic structure of GRC information and make that structure consistently usable across functions, systems and decision contexts. This includes establishing common definitions, relationships, ownership, access requirements and traceability so that GRC information can be interpreted consistently by both people and AI-enabled systems.

The transformation is therefore not achieved simply by digitising paper records. It requires the organisation to define the semantic structure of GRC information and make that structure consistently usable across functions, systems and decision contexts.

4.2 Establishing Common Definitions and Authoritative Sources

The first practical requirement is the establishment of common data definitions. Terms such as risk, control, obligation, incident, issue, asset, process, customer, supplier and materiality are often interpreted differently across business units. Such inconsistency creates duplication, weakens reporting and makes reliable AI reasoning difficult.

A common GRC data model should therefore define:

• the core objects used across the GRC lifecycle;

• the attributes associated with each object;

• the relationships between objects;

• the ownership and accountability of each object;

• the authoritative source for each data element;

• the permitted uses of the information;

• the frequency at which it should be updated;

• the evidence required to validate its quality.

This does not require every function to use identical tools or processes. It requires the organisation to establish a common semantic foundation through which different systems can exchange information without losing meaning.

Authoritative systems of record are equally important. AI systems should not be allowed to treat every available document or data source as equally reliable. The architecture should distinguish between authoritative regulatory sources, approved internal policies, operational records, analyst interpretations, generated summaries and unverified external information.

This distinction is central to trustworthy AI. Effective AI governance requires organisations to understand the data and information on which AI systems depend, including its provenance, quality, governance arrangements and appropriate conditions of use. NIST emphasises the importance of data management, documentation, transparency and ongoing risk management across the AI lifecycle, while ISO/IEC 42001 establishes organisational requirements for governing AI-related information, responsibilities and processes (NIST, 2023; ISO/IEC, 2023). Retrieval-augmented generation can also connect AI systems to external knowledge sources, but retrieval alone does not establish that the underlying information is authoritative, current or appropriate for a particular use case (Lewis et al., 2020).

Without authoritative source management, an AI system may produce a plausible answer based on an outdated policy, superseded regulation or inappropriate interpretation. The data foundation should therefore make it possible to determine not only what information says, but also where it came from, whether it is current, who owns it and whether it is authorised for use. These attributes are essential for establishing the traceability and governance required when AI-generated outputs contribute to consequential organisational decisions (NIST, 2023).

The objective is consequently not simply to provide AI systems with more information, but to provide them with trusted, contextualised and governable information. In the proposed GRC architecture, provenance, currency, ownership, access rights and authoritative status should therefore be treated as properties of the information itself and incorporated into the mechanisms through which GRC data is retrieved, interpreted and used.

4.3 Connecting Regulation, Policy and Control

A central objective of the GRC data fabric should be to connect regulatory requirements to their operational implementation. Regulatory intelligence should not remain in a repository accessible only to compliance specialists. It should be linked to the policies, controls, processes and systems through which obligations are enacted.

For example, a new regulatory requirement should be capable of being associated with:

• the relevant legal or supervisory source;

• the affected jurisdictions;

• the applicable business entities;

• the products or services within scope;

• the impacted processes;

• the relevant policies;

• the controls that address the requirement;

• the evidence needed to demonstrate compliance;

• the accountable owners;

• the implementation status;

• the residual risk created by any gap.

This architecture would enable regulatory change to become operationally actionable. Instead of merely notifying stakeholders that a new rule has been published, the system could identify the processes and controls likely to be affected, assess implementation dependencies, propose remediation activities and identify decisions requiring management attention.

Forward-looking AI compliance requires governance mechanisms that can respond as AI systems, use cases, data, processes and regulatory expectations evolve over time. Static governance mechanisms are therefore increasingly inadequate for environments in which AI-related risks and operating conditions can change throughout the system lifecycle. The NIST AI Risk Management Framework emphasises ongoing measurement, monitoring and management of AI risks, while ISO/IEC 42001 establishes a management-system approach based on defined processes, monitoring and continual improvement (NIST, 2023; ISO/IEC, 2023). A connected GRC data foundation is necessary to identify where material change has occurred and assess what consequences that change may have for the control environment.

The result is a shift from regulatory awareness to regulatory operationalisation: from knowing what regulatory requirements exist to embedding their implications into policies, controls, processes, decision-making and ongoing assurance.

4.4 Representing GRC Relationships Through Knowledge Graphs

Knowledge graphs are particularly relevant because GRC is fundamentally relational. A regulatory obligation may apply to a policy, which governs a control, which operates within a process, which depends upon a system, which is supported by a third party. A customer may be connected to beneficial owners, accounts, transactions, jurisdictions, sanctions indicators and adverse-media events. A cyber incident may be connected to an asset, vulnerability, supplier, control deficiency and regulatory reporting obligation.

Hogan et al. (2021) identify knowledge graphs as a means of representing entities and relationships in a machine-readable form. Applied to GRC, this approach can make the structure of organisational obligations and dependencies more visible to both analysts and AI systems.

A knowledge graph could, for example, support questions such as:

• Which controls address this regulatory obligation?

• Which business processes depend upon this critical supplier?

• Which customers are connected to a high-risk jurisdiction?

• Which systems support processes affected by a cyber incident?

• Which controls rely upon data that has recently failed quality checks?

• Which regulatory obligations may be affected by a proposed process change?

• Which risks are connected through a common technology, vendor or business process?

This relational capability is particularly important for interdependent and extended-enterprise risk. Risks can emerge through interactions among suppliers, technologies, jurisdictions, counterparties, processes and regulatory obligations rather than through isolated control failures. Enterprise risk management research highlights the importance of understanding how different sources of risk interact and how exposures can affect organisational performance across interconnected activities and organisational boundaries (Bromiley et al., 2015). A knowledge graph can help make these relationships explicit by representing connections between entities and supporting more integrated forms of information retrieval and reasoning (Hogan et al., 2021).

The implication for GRC is that risk should increasingly be understood not only as a collection of individual exposures, but as a network of relationships and dependencies. This provides a stronger foundation for identifying how changes in one part of the organisational or extended-enterprise environment may affect risks, controls, processes and decisions elsewhere.

However, knowledge graphs should not be treated as a substitute for sound data governance. Their value depends upon the quality, currency, provenance and completeness of the relationships they contain. An inaccurate graph can create a false appearance of systemic understanding. The graph must therefore preserve uncertainty, source references, ownership and update history.

4.5 Data Provenance, Lineage and Explainability

AI-enabled GRC requires more than data availability. It requires the ability to reconstruct how information was obtained, transformed and used. This makes provenance and lineage central design requirements.

Data provenance should establish the origin of a data element, the system or source from which it was obtained, the transformations applied to it and the date on which it was last validated. Lineage should make it possible to trace how information moves from source systems into analytical models, dashboards, decisions and control actions.

These capabilities are essential for several reasons. First, they support auditability by allowing the organisation to reconstruct the evidence underlying a decision. Second, they support regulatory defensibility by demonstrating that information was obtained and used appropriately. Third, they support model evaluation by identifying whether an erroneous output resulted from poor data, an inappropriate transformation, an analytical limitation or an execution error. Fourth, they support remediation by allowing the organisation to identify other decisions or processes affected by the same defective information.

The requirement is especially important where AI systems generate summaries, classifications or recommendations. An AI-generated conclusion should not be treated as self-authenticating. It should be possible to identify the sources supporting the conclusion, distinguish retrieved evidence from model-generated inference and understand any relevant uncertainty or limitation.

Trustworthy AI depends not only on the quality of model outputs but also on the ability of organisations to understand, govern and account for how those outputs are produced and used. Effective AI governance therefore requires appropriate transparency, accountability, human oversight and mechanisms for documenting and evaluating AI systems throughout their lifecycle (NIST, 2023; Novelli, Taddeo and Floridi, 2024). The same principle applies to GRC: explainability is not simply the ability to describe a model's internal reasoning; it is the ability to reconstruct the evidential and governance chain through which a decision was produced.

In this context, meaningful explainability should enable an authorised reviewer to establish, where appropriate, what information informed the decision, which policies or obligations were relevant, what analytical process was applied, which human or machine actors participated, what approvals or interventions occurred, and why the resulting action was considered authorised. Explainability therefore becomes a property of the wider decision and control process, rather than solely of the underlying AI model.

4.6 Identity, Access and Data Rights

An AI-ready GRC data foundation must also incorporate identity and access controls from the outset. Data cannot be made universally available merely because it may be useful to an AI system. Access must remain aligned with legal and regulatory requirements, confidentiality obligations, segregation of duties, purpose limitations and organisational authority. Effective AI governance therefore requires organisations to establish appropriate controls over data access, responsibilities and the use of information throughout the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

This is particularly important for agentic AI. An agent that can retrieve information, initiate workflows or update records must operate within a clearly defined identity and permission model. It should access only the information and capabilities required for its authorised task, with controls preventing inappropriate combinations of data, permissions or actions across organisational domains. The underlying principle is that an AI system should not acquire broader authority merely because it possesses greater technical capacity to retrieve or process information.

The proposed architecture therefore treats least-privilege access, controlled tool use, policy enforcement and separation between intelligence and execution as design requirements for agentic GRC. These controls should be embedded within the data and application architecture rather than added retrospectively as technical safeguards. This is consistent with the broader governance principle that AI systems require clearly defined responsibilities, oversight, access arrangements and controls appropriate to their intended use and potential impact (NIST, 2023; ISO/IEC, 2023).

The GRC data fabric should therefore support:

• role-based and attribute-based access;

• purpose-specific data permissions;

• distinct human and machine identities;

• segregation of duties;

• access logging and traceability;

• consent and privacy constraints where applicable;

• restrictions on data export and secondary use, including model training where relevant;

• controls over cross-domain data linkage;

• timely revocation or modification of access when roles, responsibilities or authorities change.

These mechanisms establish a direct relationship between identity, authority and accountability. Identity is consequently not merely a cybersecurity concern; it is a foundational component of GRC because the organisation must be able to establish who or what accessed information, under whose authority, for what purpose and with what consequences. In an agentic environment, this principle extends naturally to machine actors: every consequential action should be attributable to an identifiable actor operating within explicitly defined authority.

4.7 Event Streams and Continuous Risk Sensing

A static repository is insufficient for continuous GRC. The data foundation must also support event-driven information flows through which material changes can be detected and routed into appropriate analytical or control processes. Changes in customer behaviour, supplier performance, regulatory requirements, control effectiveness, cyber threats, financial indicators or operational conditions should be capable of generating signals that trigger reassessment, analysis or intervention. This reflects the lifecycle orientation of AI risk management, in which organisations are expected to monitor changing conditions and manage risks as systems and their operating environments evolve (NIST, 2023).

Event streams can provide the basis for continuous sensing by allowing the GRC architecture to respond to relevant changes as they occur rather than waiting for scheduled reporting cycles. For example, a significant change in a supplier's ownership, a new sanctions designation, a material control failure, a cyber threat affecting a critical technology or a change in regulatory expectations could trigger reassessment of the relevant risk and control relationships. The underlying principle is consistent with risk-based approaches to customer due diligence and supervision, which emphasise the importance of maintaining an evolving understanding of risk as new information becomes available (FATF, 2017; FATF, 2021). The same lifecycle logic can be extended, within appropriate governance boundaries, to suppliers, systems, processes, AI models and controls.

However, event-driven architecture must be designed carefully. Not every event should create an alert, and not every alert should require human intervention. The organisation must establish thresholds, prioritisation rules and escalation pathways so that continuous sensing does not create continuous overload. Signals should therefore be assessed according to their materiality, relevance, uncertainty and potential consequences before triggering automated action or human review (NIST, 2023).

The strategic objective is therefore continuous, risk-based responsiveness rather than indiscriminate monitoring. The value of event-driven GRC lies not in generating more alerts, but in identifying material changes, connecting them to the relevant risk and control context, and directing them towards proportionate analysis, decision-making or intervention.

4.8 APIs and Interoperability

The GRC data fabric should be connected to operational systems through APIs and other interoperable interfaces. GRC cannot become an intelligent organisational capability if it remains dependent upon manually exported spreadsheets, duplicated records and disconnected applications.

Relevant connections may include:

• core banking and transaction systems;

• customer relationship management platforms;

• procurement and supplier-management systems;

• identity and access-management systems;

• security information and event-management platforms;

• case-management tools;

• financial and liquidity systems;

• human resources systems;

• enterprise architecture repositories;

• audit and issue-management platforms;

• AI model inventories;

• document and knowledge-management systems.

Interoperability is strategically important for both efficiency and resilience. It can reduce duplication, support greater consistency of information and enable information to flow across the organisational processes through which risks, controls and decisions are managed. It can also reduce dependence on individual technology components by allowing elements of the architecture to be modified, replaced or isolated without requiring wholesale redesign. This is particularly relevant where GRC depends upon multiple interconnected technologies, data sources and external providers, because enterprise risk can arise from dependencies that extend beyond individual systems or organisational boundaries (Bromiley et al., 2015; NIST, 2023).

The target architecture should therefore avoid creating a new form of GRC technology lock-in. APIs, common data models and clearly defined interfaces should allow analytical, orchestration and assurance components to evolve independently while preserving institutional control over critical information and decision processes. Modularity and interoperability should consequently be treated not simply as technical design preferences, but as architectural capabilities that support adaptability, resilience and continued organisational control as the GRC technology environment evolves.

The objective is therefore not to create a single monolithic GRC technology stack, but a connected and governable ecosystem in which information can move reliably between authoritative systems while individual analytical and automation components can evolve without undermining the integrity of the wider control architecture.

4.9 Data Quality as a Control Responsibility

Data quality should be treated as a formal control responsibility rather than as a technical housekeeping activity. AI systems can produce highly convincing outputs from incomplete, outdated or biased information. Consequently, data quality failures can become control failures when they influence risk assessments, customer decisions, regulatory reporting or agentic actions.

The organisation should establish data-quality controls covering:

• completeness;

• accuracy;

• consistency;

• timeliness;

• validity;

• uniqueness;

• relevance;

• lineage;

• ownership;

• fitness for intended use.

Data-quality thresholds should be linked to decision criticality. Information used for a low-risk administrative summary may tolerate different limitations from information used to approve a high-risk customer, determine a regulatory filing or authorise a material transaction.

Where data quality is insufficient, the system should not silently proceed. It should expose the limitation, reduce confidence, request additional evidence or escalate to a human decision-maker. This is an important component of meaningful human control because humans cannot exercise responsible judgement if the quality of the information presented to them is concealed.

4.10 From Data Foundation to Machine-Interpretable GRC

The strategic objective of the first pillar is therefore not simply to create a larger GRC database. It is to establish a machine-interpretable organisational knowledge and control system.

Such a system should allow the organisation to:

• identify the obligations relevant to a decision;

• trace obligations to policies and controls;

• understand the processes and systems affected by a risk;

• identify dependencies across suppliers and jurisdictions;

• retrieve authoritative evidence;

• monitor changes in risk and regulatory conditions;

• support AI analysis with contextual and permission-aware information;

• constrain agentic actions through identity and authority;

• reconstruct the evidence and reasoning behind decisions;

• learn from incidents, failures and outcomes.

This foundation is a precondition for every subsequent strategic pillar. Without it, AI-enabled GRC will remain fragmented, dependent upon manual interpretation and vulnerable to inconsistent information. With it, the organisation can begin to develop continuous risk sensing, decision intelligence, governed agentic execution and adaptive assurance.

The central proposition is therefore that AI readiness is fundamentally a GRC architecture problem before it is an AI model problem. The organisation must first make its obligations, risks, controls, processes, systems, evidence and decisions sufficiently connected, governed and interpretable for AI to operate safely and usefully.

The transformation of GRC should consequently begin by building the information infrastructure through which organisational intelligence can be trusted, acted upon and audited.

5. Strategic pillar 2: Re-engineer GRC workflows rather than merely automate them

The second strategic priority is to redesign GRC workflows as integrated decision and control systems rather than simply adding artificial intelligence to existing processes. The central distinction is between automation, which accelerates established activities, and process reinvention, which changes how work is structured, governed and executed. Research on digital business strategy indicates that technological capabilities generate organisational value when they are integrated with business processes and complementary organisational capabilities rather than deployed as standalone technical resources (Bharadwaj et al., 2013). Similarly, research on AI and management highlights the importance of deliberately determining how tasks and responsibilities are allocated between humans and AI rather than assuming that technological capability will automatically translate into organisational value (Raisch and Krakowski, 2021).

This distinction has significant implications for GRC transformation. An AI assistant that summarises risk reports, drafts policies or answers questions may produce local productivity gains, but it does not necessarily alter the underlying operating model. If the surrounding process remains fragmented, periodic, manually coordinated and dependent on spreadsheets, the organisation may simply perform the same work more quickly while retaining the same structural weaknesses. AI deployment should therefore be evaluated not only according to immediate productivity gains, but also according to whether it improves the underlying processes, decision structures and control mechanisms through which organisational work is performed (Bharadwaj et al., 2013; Raisch and Krakowski, 2021).

The objective should therefore be to treat the workflow itself as an object of strategic redesign. This requires organisations to examine the full sequence through which information is collected, interpreted, assessed, approved, acted upon and monitored. It also requires attention to the institutional conditions that shape how work is performed, including legacy systems, professional roles, governance structures, accountability arrangements and established assumptions about where judgement should reside. AI transformation is unlikely to deliver its full potential where these organisational conditions remain unchanged because the allocation of activities between humans and AI, and the resulting organisational outcomes, depend upon how technology is embedded within the wider work system (Raisch and Krakowski, 2021).

The implication is that GRC transformation should move beyond AI-enabled task acceleration towards AI-enabled process reinvention. The question is not simply where AI can be inserted into an existing workflow, but how the workflow itself should be redesigned when continuous sensing, machine-supported analysis, automated execution and human judgement become available. This reframes AI adoption as an operating-model decision: organisations must determine which activities should be automated, which should be augmented, where human judgement remains necessary, and how governance and control mechanisms should operate across the resulting process (Bharadwaj et al., 2013; Raisch and Krakowski, 2021).

5.1 From periodic processes to continuous control loops

Traditional GRC processes are commonly organised around periodic review cycles. A third-party risk assessment, for example, may follow a sequence such as:

Questionnaire → analyst review → spreadsheet consolidation → risk rating → approval → annual reassessment.

This model is administratively recognisable, but it is poorly aligned with the dynamic nature of modern risk. Supplier ownership, financial condition, cyber exposure, sanctions status, geopolitical circumstances and service dependencies can change substantially between formal assessment points. A process that treats the annual questionnaire as the principal source of truth therefore creates a structural gap between the organisation's evolving risk profile and the information used to govern it. Enterprise risk management research highlights the importance of understanding risk in relation to organisational objectives and the interdependencies through which exposures can arise across organisational boundaries (Bromiley et al., 2015).

A redesigned workflow would instead operate as a continuous control loop:

Continuous supplier intelligence → automated evidence collection → risk-signal detection → contextual assessment → agent-generated recommendation → human approval where required → control execution → continuous monitoring → automatic reassessment.

The difference is not simply that individual steps have been automated. The process has been reconceived around continuous sensing, contextual interpretation, governed action and feedback. The workflow no longer begins with a scheduled request for information; it begins with an ongoing view of the supplier relationship and the signals that may indicate a material change in exposure. It no longer ends with an approved rating; it ends with a monitored control state that can be reassessed when new evidence becomes available.

This model is consistent with the lifecycle orientation of contemporary risk and AI governance. NIST emphasises ongoing measurement, monitoring and management of AI risks as systems and their operating environments evolve, while ISO/IEC 42001 establishes a management-system approach based on monitoring, evaluation and continual improvement (NIST, 2023; ISO/IEC, 2023). Applied to GRC, this means that assurance should increasingly operate as a lifecycle capability embedded within operational activity rather than as a discrete event performed only after the fact.

The resulting process is more responsive because it can distinguish between stable conditions, emerging concerns and events requiring intervention. Importantly, continuous monitoring should not imply continuous human review. Signals should be assessed according to their materiality and potential consequences, with automated responses used where appropriate and human intervention triggered when defined thresholds, uncertainties or governance requirements are reached (NIST, 2023). The objective is therefore not to eliminate periodic assessment altogether, but to place periodic reviews within a broader system of continuous, risk-based sensing and reassessment.

5.2 Redesigning the end-to-end process architecture

Effective workflow reinvention begins by mapping the complete process rather than selecting isolated tasks for automation. Organisations should identify the sources of information, decision points, control objectives, hand-offs, exceptions, approval thresholds and evidence requirements that shape the existing workflow. This exposes where value is lost through duplication, delay, inconsistent interpretation or unclear accountability, while also revealing the dependencies that must be addressed before automation or AI can be introduced effectively.

Several common weaknesses are likely to emerge. Information may be requested repeatedly because systems cannot exchange data. Analysts may manually reconcile conflicting records because there is no authoritative source. Risk ratings may be produced through inconsistent judgement because assessment criteria are not semantically standardised. Approvals may be delayed because decision rights are unclear. Evidence may be stored separately from the action it supports, making later assurance expensive and uncertain. These are not merely efficiency problems. They indicate that the process architecture itself may be preventing GRC from functioning as an integrated control system. Digital business strategy research similarly suggests that technology creates organisational value when it is integrated with business processes and complementary organisational capabilities rather than deployed as an isolated technical resource (Bharadwaj et al., 2013).

Workflow redesign should therefore address the sequence as a whole. Data collection, analysis, decision-making, execution and assurance should be connected through explicit interfaces and shared control logic. Where a process depends on a recurring judgement, the organisation should determine whether that judgement can be supported by structured rules, probabilistic analysis, retrieval-augmented reasoning or human review. Where an action carries material consequences, the workflow should define the required authorisation, evidence and escalation conditions before the action is delegated to an AI-enabled system. This ensures that automation is introduced within an already-defined governance structure rather than becoming a substitute for one.

This approach also requires a distinction between activities that should be automated deterministically and activities that require contextual reasoning. Deterministic tasks, such as checking whether required fields are complete, matching records, applying thresholds or routing cases, may be suitable for conventional automation. More ambiguous tasks, such as interpreting regulatory change, assessing unusual behaviour or evaluating the significance of interconnected risk signals, may benefit from AI-supported analysis. The purpose is not to maximise the use of AI but to allocate each activity to the most appropriate combination of rules, software, models and human judgement. This reflects the automation–augmentation paradox identified by Raisch and Krakowski (2021), in which AI can both automate elements of work and increase the importance of human expertise in other parts of the process.

The resulting design principle is therefore process first, technology second. Organisations should first determine what the process is intended to achieve, where decisions and controls occur, what evidence is required and where accountability resides. Only then should they determine which activities should be automated, augmented or retained as human responsibilities. This creates a stronger basis for AI-enabled GRC because technology is deployed to improve the control system as a whole rather than simply to accelerate individual tasks.

5.3 Embedding intelligence into operational workflows

AI becomes strategically valuable when it is connected to the systems in which GRC work actually occurs. A model that produces a recommendation in a separate chat interface leaves the user responsible for transferring the result into a case-management system, updating a risk record, initiating a control or documenting the rationale. This creates additional hand-offs and weakens the connection between intelligence, decision-making and execution. Digital business strategy research similarly indicates that technological capabilities generate greater organisational value when they are integrated with business processes and complementary organisational capabilities rather than operated as standalone resources (Bharadwaj et al., 2013).

An embedded workflow, by contrast, allows intelligence to be generated in the context of a specific case, decision or control. A supplier-risk workflow could retrieve relevant contracts, ownership information, prior assessments, adverse events, sanctions results, cyber indicators and service criticality. It could then compare the new evidence with the supplier's existing risk profile, identify material changes, explain the basis of a recommendation and route the case according to predefined authority thresholds.

The value arises from this integration of context, action and accountability. AI is not merely producing text; it is helping the organisation move from evidence towards a governed decision. This is particularly important in GRC because the usefulness and reliability of an AI-supported output depend not only on the model's analytical capability but also on the information available to it, the organisational context in which the output is interpreted and the governance arrangements under which it is used (NIST, 2023).

Retrieval-augmented generation can improve access to relevant documents and regulatory materials by connecting generative models to external knowledge sources, but retrieval alone does not establish a trustworthy workflow (Lewis et al., 2020). The organisation must also govern source authority, document currency, provenance, access permissions, conflicting interpretations and the relationship between retrieved information and the decision being made. NIST emphasises the importance of appropriate data management, documentation, transparency and ongoing risk management across the AI lifecycle (NIST, 2023). The workflow should therefore make clear, where material, which sources were consulted, what evidence was relied upon, how that evidence was interpreted and how the resulting recommendation was validated.

The strategic implication is that AI should be embedded where decisions and controls occur, not positioned alongside them as a separate conversational interface. This reduces unnecessary hand-offs, strengthens traceability and creates a more direct connection between organisational intelligence and authorised action.

5.4 Reallocating human judgement rather than removing it

Process reinvention should not be equated with the wholesale removal of human involvement. In GRC, the more appropriate objective is to reposition human judgement at the points where it adds the greatest value. AI can reduce the burden of searching, comparing, classifying, drafting and monitoring, allowing professionals to focus on interpretation, challenge, accountability and decisions involving material uncertainty. This reflects the automation–augmentation paradox identified by Raisch and Krakowski (2021), whereby AI can automate some activities while simultaneously increasing the importance of human expertise in others.

This requires explicit decision-rights design. The workflow should specify which actions an AI system may perform automatically, which require review, which require approval by a designated role and which are prohibited. Low-risk, reversible and well-defined actions may be executed within tightly bounded parameters. Actions affecting regulatory reporting, customer access, supplier termination, legal interpretation or material risk acceptance should generally be subject to appropriate human authorisation, with the precise requirements determined by the organisation's risk appetite, governance arrangements and the consequences of error (NIST, 2023; ISO/IEC, 2023).

Such arrangements are consistent with the principle that increasing AI capability should not automatically result in increasing organisational authority. A system may be permitted to detect a risk signal, assemble evidence and recommend an action without being authorised to execute the action independently. Least-privilege access, policy constraints, checkpoints, verification and escalation mechanisms should therefore be treated as core components of workflow governance. NIST emphasises the importance of clearly defined roles, responsibilities, human oversight and risk management for AI-enabled systems, while ISO/IEC 42001 provides a management-system framework for establishing and governing AI-related responsibilities and controls (NIST, 2023; ISO/IEC, 2023).

The result should be a more effective allocation of professional expertise. Analysts are not displaced simply because AI can perform parts of their former work. Rather, their roles can evolve from manual information processing towards exception management, evidence and model challenge, contextual interpretation and accountable decision-making. This reflects the broader finding that the organisational consequences of AI depend upon how tasks and responsibilities are redesigned around human–AI collaboration rather than simply on the technical capability of the technology (Raisch and Krakowski, 2021).

This transition should also be managed as an organisational change rather than treated solely as a technology implementation. Changes in roles, decision rights, accountability and established ownership boundaries can affect how professionals understand their responsibilities and how work is coordinated across functions. The target state should therefore preserve clear accountability while deliberately reallocating routine cognitive and administrative activities to AI, enabling human expertise to be concentrated where judgement, challenge and responsibility remain most consequential.

5.5 Designing for exceptions, uncertainty and escalation

A mature GRC workflow cannot be designed only around the normal case. Risk and compliance processes are characterised by incomplete information, conflicting evidence, ambiguous requirements and situations that do not fit predefined categories. AI-enabled workflows must therefore treat uncertainty and exception handling as first-class design requirements rather than as residual conditions to be addressed after automation has been implemented.

The workflow should distinguish between confidence in the evidence, confidence in the interpretation and confidence in the proposed action. A recommendation may be well supported by reliable data but still involve substantial uncertainty because the consequences are difficult to predict. Conversely, a model may express high confidence despite weak or incomplete evidence. These conditions should therefore lead to different forms of escalation and review. Probabilistic reasoning and decision analysis provide relevant foundations for representing uncertainty and supporting decisions under conditions where available information is incomplete or uncertain (Fenton and Neil, 2019). The NIST AI Risk Management Framework similarly emphasises the importance of identifying, assessing and managing uncertainty and potential impacts throughout the AI lifecycle (NIST, 2023).

Escalation should be triggered by more than model confidence alone. Other relevant conditions include the materiality of the decision, reversibility of the action, sensitivity of the information, novelty of the situation, presence of conflicting sources and potential consequences for affected stakeholders. A workflow that automatically routes uncertain or high-impact cases to an accountable human decision-maker is therefore more defensible than one that treats every model output as equally actionable. The appropriate level of human involvement should reflect the characteristics and consequences of the decision rather than being determined solely by the model's stated confidence (NIST, 2023; Raisch and Krakowski, 2021).

This also reinforces the importance of observability and traceability. Organisations should be able to determine, where appropriate, which information entered the workflow, which rules or models were used, what recommendation was produced, what human intervention occurred and what outcome followed. Such documentation supports accountability, evaluation, incident investigation and ongoing improvement, while enabling the organisation to understand how AI-supported decisions and actions were produced and governed (NIST, 2023; ISO/IEC, 2023).

The resulting principle is that uncertainty should become an input to governance rather than an error condition. Instead of attempting to eliminate uncertainty through increasingly confident automated outputs, the GRC workflow should make uncertainty visible, assess its significance and route it towards proportionate analysis, human judgement or escalation. This creates a more resilient decision process in which the system can distinguish between situations that can be handled automatically and those in which organisational judgement and authority must become more prominent.

5.6 Connecting workflow redesign to control execution

GRC transformation is incomplete if improved analysis does not lead to improved control execution. A workflow should therefore be designed to connect risk assessments to the operational controls that mitigate the identified exposure. For example, a change in supplier risk may need to trigger a revised access review, additional monitoring, a contract amendment, a business-continuity test or a reassessment of concentration risk. This reflects the broader principle that enterprise risk management should be integrated with strategy and performance rather than treated as a separate reporting activity (COSO, 2017).

This connection is essential because risk information has limited value when it remains trapped in reports and registers. The purpose of GRC is not simply to describe exposure but to inform decisions and support controlled organisational responses. Effective AI governance similarly requires governance principles to be translated into operational processes, responsibilities, controls and monitoring rather than remaining at the level of policy statements (NIST, 2023; ISO/IEC, 2023). Compliance use cases should therefore be understood within the wider organisational processes through which data, decisions, controls, human oversight and technology interact.

The same principle applies beyond third-party risk. In regulatory change management, a new obligation should be translated into affected policies, controls, processes, systems and accountable owners. In cybersecurity, a detected identity or access anomaly should connect to appropriate investigation, containment, remediation and evidence-capture processes. In financial crime compliance, changes in beneficial ownership, sanctions exposure or customer behaviour should inform ongoing risk assessment and customer due diligence rather than remain isolated alerts. Risk-based approaches to customer due diligence emphasise the importance of understanding customer risk and applying appropriate measures, while risk-based supervision requires an evolving understanding of risk as circumstances change (FATF, 2017; FATF, 2021).

The strategic measure of success is therefore not the number of tasks automated or the number of AI assistants deployed. It is whether the redesigned workflow improves the timeliness, consistency, traceability and effectiveness of organisational control. A mature GRC workflow should consequently establish a demonstrable chain from signal → assessment → decision → authorised action → verification → evidence, ensuring that intelligence is converted into controlled organisational outcomes rather than remaining isolated within analytical or reporting systems.

5.7 Overcoming legacy constraints and organisational fragmentation

Workflow reinvention is difficult because GRC processes are often distributed across business units, technologies and professional communities. Different functions may use incompatible taxonomies, maintain separate records and apply different thresholds to similar risks. Legacy platforms may lack APIs or event-driven capabilities. Procurement decisions may also create a fragmented technology environment in which data and workflows cannot move easily across products. Organisational incentives may further reward local optimisation rather than end-to-end performance. These challenges reflect the broader difficulty of integrating digital capabilities across organisational processes, structures and complementary resources (Bharadwaj et al., 2013).

These constraints mean that process redesign must be accompanied by architectural and governance change. Interoperability, shared data definitions, modular services and appropriate technology optionality can allow organisations to redesign workflows without becoming excessively dependent on a single platform or monolithic implementation. This is particularly important where GRC activities depend upon interconnected systems and organisational capabilities, because weaknesses or dependencies in one part of the environment can affect other areas of organisational risk and performance (Bromiley et al., 2015). The GRC ecosystem should therefore be treated as a distributed operating environment in which foundational data capabilities, domain-specific intelligence, workflow services and assurance mechanisms can work together through governed interfaces.

Architectural modularity also supports organisational adaptability. Where components have clearly defined interfaces and responsibilities, individual technologies or services can be modified, replaced or extended without requiring wholesale redesign of the wider GRC environment. This reduces technological dependency and supports the ability of the organisation to evolve its architecture as regulatory requirements, risk conditions and AI capabilities change. The objective is therefore not to eliminate technology dependencies, but to ensure that those dependencies remain visible, governable and replaceable where appropriate.

Leadership must also establish end-to-end process ownership across functional boundaries. A workflow that crosses procurement, information security, legal, compliance, finance and business operations cannot be transformed effectively if each function controls only its own segment. End-to-end accountability is required for the quality and effectiveness of the process as experienced by the organisation, not merely for the performance of individual departments. This requires clear decision rights, shared objectives and explicit responsibilities across the functions contributing to the workflow (Bharadwaj et al., 2013; NIST, 2023).

The implication is that workflow reinvention is simultaneously a process, architecture and organisational-design challenge. Technology can enable new ways of working, but sustainable transformation requires the organisation to align data structures, system interfaces, governance arrangements, incentives and accountability around the end-to-end outcome that the GRC process is intended to achieve.

5.8 From automation projects to adaptive GRC capabilities

The long-term objective is to create GRC workflows that can sense change, interpret its significance, initiate proportionate action and learn from outcomes. Such workflows should be continuously evaluated against control objectives, decision quality, false-positive rates, escalation patterns, user behaviour and realised risk outcomes. Evaluation should not be limited to model accuracy; it should examine whether the complete workflow produces reliable, effective and defensible organisational results. This broader perspective is consistent with AI risk-management approaches that emphasise ongoing measurement, monitoring and management across the system lifecycle rather than evaluation of model performance in isolation (NIST, 2023). It also reflects the management-system orientation of ISO/IEC 42001, which emphasises defined responsibilities, monitoring and continual improvement of organisational AI governance (ISO/IEC, 2023).

This provides the foundation for what this paper terms adaptive GRC. The concept aligns with enterprise risk management's emphasis on understanding relationships among risks and their potential effects on organisational objectives and performance (Bromiley et al., 2015; COSO, 2017). In an increasingly interconnected operating environment, risks may arise from dependencies across processes, technologies, suppliers and organisational activities rather than from isolated control failures. The implication is that GRC workflows should be capable of incorporating changes in one part of the environment into the assessment of related risks, controls and decisions elsewhere.

It also supports the view of compliance as an organisational architecture of information, decisions, controls and feedback rather than as a collection of isolated regulatory activities. COSO (2017) emphasises the integration of risk management with strategy and performance, while NIST (2023) and ISO/IEC 42001 (2023) emphasise governance, defined responsibilities, monitoring and continual improvement in the management of AI-related risks. Building on these principles, this paper proposes that compliance and control capabilities should be designed as connected organisational mechanisms that can adapt as the organisation, its technologies and its external environment change.

The strategic implication is clear. Organisations should not ask only where AI can be inserted into an existing GRC process. They should ask whether the process itself remains appropriate for a continuously changing, data-intensive and interconnected operating environment. Where the answer is no, the priority should be process reinvention: redesigning the workflow around trusted context, explicit authority, integrated control execution, continuous monitoring and accountable human judgement.

AI should therefore be understood as an enabler of a new GRC operating logic, not simply as an additional productivity layer. The most valuable transformation occurs when organisations move from fragmented, periodic and document-centred processes towards continuous, context-aware and control-connected workflows. This requires the integration of technological capabilities with business processes, organisational responsibilities and human expertise rather than treating AI as a standalone technical capability (Bharadwaj et al., 2013; Raisch and Krakowski, 2021).

At this point, GRC begins to function not merely as an assurance activity, but as an adaptive organisational capability: one that continuously senses relevant change, connects that change to risk and control context, supports proportionate decisions, enables authorised action and incorporates outcomes into subsequent monitoring and improvement. The specific concept of adaptive GRC, and the proposed workflow logic through which it operates, therefore represent a central conceptual contribution of this paper.

6. Strategic pillar 3: Establish governed agentic GRC

The third strategic priority is to introduce agentic artificial intelligence into GRC through bounded autonomy, explicit authority and continuous assurance. The objective should not be to maximise the number of autonomous agents deployed, but to determine where agentic capabilities can safely improve the speed, consistency and responsiveness of GRC while preserving accountability for consequential decisions.

This distinction is important because agentic AI differs materially from conventional analytical AI. A traditional model may classify information, generate a prediction or produce a recommendation. An agentic system can additionally combine reasoning with actions such as retrieving information, interacting with tools and initiating activities within an operational environment (Yao et al., 2023). The governance challenge therefore extends beyond the quality of the model's output to include the permissions, oversight, controls and consequences associated with the system's actions (NIST, 2023; ISO/IEC, 2023).

The appropriate question is consequently not simply “Can an agent perform this task?” but “Under what conditions should an agent be authorised to perform this task?” This reframes agentic GRC as an organisational control problem involving task characteristics, regulatory exposure, decision rights, explainability, reversibility, monitoring and governance maturity.

6.1 A risk-based framework for agentic deployment

The framework proposed in this paper identifies four criteria for determining the suitability of agentic AI within GRC processes: task structure, regulatory risk, explainability requirements and organisational governance maturity. These criteria provide a practical basis for differentiating between processes where autonomous execution may be appropriate and those where AI should remain primarily advisory. The underlying approach is consistent with risk-based AI governance, which requires organisations to consider intended use, potential impacts, human oversight and the controls necessary to manage AI-related risks (NIST, 2023; ISO/IEC, 2023).

Task structure concerns the degree to which the activity can be specified and bounded. Highly structured processes with clear inputs, predictable decision logic and defined outputs are generally more amenable to automation than ambiguous tasks requiring extensive contextual interpretation. This reflects the broader distinction between automation and augmentation: the suitability of AI depends not only on technical capability but also on how tasks and responsibilities are designed within the wider work system (Raisch and Krakowski, 2021).

Regulatory risk concerns the potential consequences of an incorrect or unauthorised action. A process that affects regulatory reporting, customer rights, material financial exposure or legal obligations requires substantially stronger safeguards than an internal evidence-retrieval task. AI governance should therefore be proportionate to the potential impact of the system and the context in which it is deployed (NIST, 2023).

Explainability requirements concern the organisation's ability to understand and defend how a decision or action was produced. In GRC, an outcome may need to be explained not only to an internal user but also to auditors, regulators, customers or other affected stakeholders. The higher the requirement for demonstrable reasoning, evidence and accountability, the stronger the case for retaining appropriate human oversight (NIST, 2023; Novelli, Taddeo and Floridi, 2024).

Finally, organisational governance maturity determines whether the organisation possesses the infrastructure necessary to control an agent effectively. Agentic systems require more than model governance. They require appropriate identity and access arrangements, permissions, tool controls, monitoring, logging, evaluation, escalation, incident management and clearly defined accountability. An organisation that lacks these capabilities may be technically capable of deploying agents but organisationally unprepared to govern them (NIST, 2023; ISO/IEC, 2023).

These criteria imply that agentic adoption should proceed according to risk-adjusted autonomy, rather than a technology-first deployment model.

6.2 High-suitability use cases: bounded and observable autonomy

The strongest initial candidates for agentic GRC are processes that are repetitive, information-intensive, rules-constrained, reversible and highly observable, with low-to-moderate consequences if an error occurs. These characteristics create an environment in which agents can generate meaningful productivity and responsiveness gains while remaining subject to strong controls.

Regulatory horizon scanning is one such example. An agent can monitor designated regulatory sources, identify potentially relevant developments, compare new requirements with existing obligations and route material changes to the appropriate owner. Regulatory obligation extraction can similarly use AI to identify obligations from complex documents and structure them for subsequent human validation.

Other suitable applications include policy comparison, evidence collection, control-evidence mapping, audit preparation and remediation tracking. In each case, the agent's role can be tightly defined and its actions readily inspected. The agent may gather evidence, identify inconsistencies or prepare a work product without possessing authority to make the final consequential decision.

Sanctions and adverse-media investigation support is another potential application. An agent can assemble relevant information, identify potentially material signals and prepare an investigative context for an analyst. However, the agent should not be treated as the ultimate adjudicator of whether a customer, supplier or other party is subject to a consequential restriction. The distinction between investigative assistance and authoritative determination is fundamental.

The common characteristic of these use cases is not simply that they are easy. Rather, they allow the organisation to establish a controlled relationship between agent perception, agent reasoning, human validation and authorised action.

6.3 Conditional autonomy: recommendation before execution

A second category comprises processes where agents can provide substantial decision support but should initially operate within a human-authorised execution model. These cases may involve greater ambiguity, higher regulatory exposure or more consequential outcomes.

Examples include customer risk reassessment, third-party risk escalation, control-exception prioritisation and regulatory-change impact assessment. An agent can collect relevant evidence, analyse patterns, compare the case against established criteria and generate a recommendation. It can also identify the rationale for the recommendation and highlight contradictory evidence or unresolved uncertainty.

The final decision, however, remains with an appropriately authorised human decision-maker.

This model creates an important intermediate state between manual GRC and full autonomy. Rather than treating human involvement as a temporary obstacle to automation, the organisation deliberately positions humans at points where judgement, accountability or contextual interpretation is required. Over time, evidence from system performance can be used to determine whether particular decisions are suitable for greater automation. This reflects the principle that AI implementation should involve deliberate allocation of tasks between humans and machines rather than an assumption that greater automation is inherently preferable (Raisch and Krakowski, 2021).

The progression should therefore be:

Assist → recommend → approve → execute within bounds → learn and reassess.

This creates a pathway towards increasing autonomy without assuming that every process should ultimately become autonomous.

6.4 Low-suitability activities: preserving human authority

Some decisions should remain outside autonomous agentic execution, particularly where actions are irreversible, highly consequential or difficult to remediate. Initial deployment should generally avoid granting autonomous authority over regulatory reporting, termination of critical relationships, material financial commitments, high-impact customer decisions, disciplinary actions, legal determinations and strategic risk acceptance.

The issue is not that AI is incapable of contributing to these activities. On the contrary, AI may substantially improve the quality and speed of analysis supporting them. The critical distinction is between decision support and decision substitution.

An agent could assemble the evidence required for a regulatory filing, identify inconsistencies and draft proposed disclosures, while an accountable professional retains responsibility for submission. It could analyse the implications of terminating a critical supplier relationship without possessing authority to terminate the relationship. It could identify evidence relevant to a disciplinary case without making the final employment determination.

This approach recognises that accountability cannot simply be transferred to a machine. Where the organisation retains legal, regulatory or fiduciary responsibility for an outcome, the governance architecture must preserve an accountable authority capable of reviewing, challenging and, where necessary, rejecting the agent's recommendation. This is consistent with AI accountability principles that emphasise the allocation of responsibility across the actors and organisational arrangements involved in the development and use of AI systems (Novelli, Taddeo and Floridi, 2024).

6.5 Separating intelligence from authority and execution

The central architectural principle of governed agentic GRC is the separation of intelligence, authority and execution. An agent may be highly capable of analysing information without being authorised to act upon that analysis. Conversely, an action may be technically executable by a system without being organisationally authorised.

This distinction should be implemented architecturally rather than relying solely on procedural instructions. Agents should interact with enterprise systems through controlled tools and interfaces, with explicit permissions governing what they can read, modify or execute. Least-privilege access should ensure that an agent receives only the permissions necessary for its defined role. High-impact actions should require additional authorisation, confirmation or checkpointing. These arrangements are consistent with the broader AI governance requirements for defined responsibilities, human oversight, risk management and appropriate controls (NIST, 2023; ISO/IEC, 2023).

This creates a hierarchy of authority. An agent might be permitted to retrieve information, analyse evidence and draft a recommendation. A separate control layer may determine whether the proposed action is within policy. A human decision-maker may then approve a material action. Only after these conditions are satisfied should the relevant enterprise system execute the action.

Such separation reduces the risk that a model's ability to generate a plausible output is mistakenly interpreted as authority to act. It also creates clearer accountability when something goes wrong.

6.6 Identity and permissions as foundational agent controls

Agentic systems require an identity architecture capable of distinguishing between the agent, the human initiating an activity, the systems being accessed and the authority under which an action is performed. Identity therefore becomes a foundational control layer for agentic GRC rather than merely an information-security concern. Appropriate governance of AI systems requires clearly defined responsibilities, controls and management processes throughout the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

Every agent should have a defined identity, purpose, permission set and scope of authority. Access should be contextual where appropriate, taking account of the sensitivity of the information, the nature of the task, the requesting user and the action being attempted. Privileges should be constrained by default and escalated only where explicitly justified.

This is particularly important as organisations move from agents that merely generate information towards agents capable of changing enterprise state. Reading a policy document, creating a draft risk assessment and modifying a customer record are materially different activities. The control architecture should reflect these differences rather than treating them as equivalent forms of system interaction.

The resulting principle is straightforward: the capability to perform an action should never be confused with the authority to perform it.

6.7 Evidence, provenance and observability

Governed agentic GRC also requires comprehensive observability. Organisations should be able to reconstruct how an agent arrived at a recommendation or action, what information it accessed, which tools it invoked, what instructions and policies constrained it, what approvals were obtained and what outcome followed.

This requires more than conventional application logging. Agentic workflows may involve multiple retrieval operations, model calls, tool interactions and intermediate decisions. Provenance must therefore extend across the complete workflow. Evidence should be linked to the decision it supports, and material actions should be traceable to the identity and authority under which they were performed. NIST emphasises documentation, transparency, measurement and ongoing risk management as important components of AI governance (NIST, 2023).

Such records provide the basis for auditability and accountability, but they also support continuous system improvement. Organisations can analyse where agents generate false positives, where human reviewers routinely override recommendations, where evidence is insufficient or where particular workflows create recurring exceptions.

Observability consequently becomes both a governance mechanism and a learning mechanism.

6.8 Verification, evaluation and controlled failure

Agentic systems should not be evaluated solely on the quality of their textual outputs. Their performance must be assessed at the workflow level, including whether they retrieve appropriate evidence, follow applicable policies, respect permissions, escalate appropriately and produce reliable downstream outcomes. This broader evaluation perspective is consistent with lifecycle-based AI risk management, which considers system performance, risks, impacts and controls beyond model accuracy alone (NIST, 2023).

Verification mechanisms should be introduced before consequential actions are executed. These may include deterministic policy checks, structured validation, independent evidence verification, threshold controls, dual approval or human confirmation. Where an agent encounters uncertainty, contradictory information or an unfamiliar situation, the preferred behaviour should be escalation rather than unsupported completion.

This principle is particularly important because agentic systems operate in environments where errors can propagate. A misleading interpretation may lead to an incorrect classification; the classification may trigger an inappropriate recommendation; the recommendation may initiate an operational action; and that action may create legal, financial or reputational consequences. The control architecture must therefore interrupt error propagation at appropriate points.

Continuous evaluation is also necessary because agent performance may change as models, data sources, prompts, tools and surrounding processes evolve. Agent governance should consequently be treated as a lifecycle discipline rather than a one-time approval process (NIST, 2023; ISO/IEC, 2023).

6.9 Designing the agentic GRC control environment

The deployment of agents requires a corresponding control environment. Organisations should define an explicit agent control plane covering identity, permissions, policies, tool access, approval thresholds, monitoring, evaluation, logging, incident response and retirement.

This control plane should operate independently enough from the agent to constrain it effectively. An agent should not be able to redefine its own permissions, disable its own monitoring or bypass an approval requirement. The separation between the agent's reasoning layer and the mechanisms that govern its execution is therefore critical. These arrangements translate broader principles of accountability, oversight and risk management into operational governance mechanisms (NIST, 2023; Novelli, Taddeo and Floridi, 2024).

Governance should also cover the agent's lifecycle. Before deployment, the organisation should establish the intended purpose, scope, data sources, permitted actions, risk classification and evaluation criteria. During operation, it should monitor performance, exceptions, overrides and incidents. When the surrounding process or model changes materially, the agent should be reassessed. Where an agent no longer meets its control objectives, it should be modified, restricted or withdrawn (NIST, 2023; ISO/IEC, 2023).

This approach converts abstract principles such as human oversight, accountability and responsible AI into operational control infrastructure.

6.10 Maturity-based progression towards autonomy

Agentic GRC should mature progressively rather than through a single transformation event. Organisations can begin with agents that observe and prepare information, progress to agents that recommend decisions, and subsequently permit bounded execution where sufficient evidence of reliability and control effectiveness has been established.

This progression can be conceptualised as a movement from observation to recommendation to supervised execution to bounded autonomy. At each stage, the organisation should demonstrate that the necessary data quality, workflow integration, identity controls, permissioning, observability, evaluation and human oversight are functioning effectively.

Importantly, maturity should not be measured by the degree of autonomy alone. An organisation with fewer autonomous agents but stronger controls may be more mature than one with extensive agent deployment and weak governance. The relevant question is whether autonomy is proportionate to capability, consequence and control effectiveness.

This is consistent with the broader principle that AI adoption should be evaluated according to how effectively human and machine capabilities are combined within the organisational context rather than according to automation levels alone (Raisch and Krakowski, 2021).

As agents interact with procurement systems, customer platforms, financial applications, cybersecurity infrastructure and regulatory workflows, the boundaries between GRC and operational execution will become less distinct. GRC must therefore govern not only the use of AI but also the actions that AI-enabled systems can cause the organisation to take.

6.11 From AI assistants to governed organisational agents

The strategic objective is consequently not to create an organisation populated by autonomous AI assistants. It is to establish a governed network of organisational agents whose capabilities are explicitly connected to business objectives, risk appetite, control requirements and decision rights.

Such agents should be understood as components of the wider GRC operating model rather than standalone technologies. Their value emerges when trusted data, contextual reasoning, workflow integration, controlled tools and human accountability operate together. This reflects the broader finding that the organisational effects of AI depend upon the interaction between technological capabilities, work processes and human expertise rather than on models alone (Raisch and Krakowski, 2021; Bharadwaj et al., 2013).

The strategic implication is therefore to adopt selective autonomy rather than universal autonomy. Organisations should deploy agents where their tasks are sufficiently structured, their actions sufficiently bounded and their consequences sufficiently manageable. As governance maturity increases, greater autonomy may be introduced where empirical evidence demonstrates that the associated risks remain controlled.

The most important design principle is that autonomy must be earned through demonstrable control. An agent should receive greater authority only when the organisation can demonstrate that it has reliable information, clearly defined permissions, observable behaviour, effective verification, appropriate escalation and accountable human oversight. This principle is consistent with lifecycle-based AI governance, in which controls and oversight should remain proportionate to the risks and impacts associated with an AI system (NIST, 2023; ISO/IEC, 2023).

Governed agentic GRC is therefore not an attempt to remove humans from the control environment. It is a redesign of the relationship between humans, machines and organisational authority. The end state is not human-free compliance, but a more responsive control system in which machines perform appropriate forms of sensing, reasoning and execution while humans retain responsibility for judgement, authority and accountability where the consequences require it.

7. Strategic pillar 4: Move from AI governance to organisational control

The fourth strategic priority is to transform AI governance from a policy and oversight function into an operational system of organisational control. A central risk in AI-enabled GRC is that organisations establish sophisticated governance committees, publish principles and complete formal assessments while leaving the underlying decision rights and operational processes largely unchanged. In such circumstances, governance may appear mature while having limited influence over how AI systems actually behave.

This creates a form of governance theatre. Policies exist, committees meet, risk assessments are documented and assurance activities are completed, yet the organisation lacks the practical mechanisms required to pause a system, change its permissions, challenge an output or prevent an inappropriate action. Governance becomes something performed around AI rather than something that actively controls it.

The distinction is between formal governance arrangements and operational control capability. Effective AI governance requires more than documented principles or assigned responsibilities; it also requires mechanisms through which risks are monitored, decisions are reviewed, permissions are constrained, incidents are managed and systems can be modified, restricted or withdrawn when necessary (NIST, 2023; ISO/IEC, 2023). Accountability likewise depends on the ability to identify responsible actors, evaluate how decisions were produced and establish whether appropriate oversight and intervention were exercised (Novelli, Taddeo and Floridi, 2024).

The implication is that governance should be assessed not only by the existence of policies, committees and completed assessments, but by whether the organisation can exercise meaningful control over AI-enabled activities in practice. A mature governance arrangement should make it possible to intervene in system behaviour, challenge recommendations, revoke access, interrupt execution and produce evidence that these mechanisms operate effectively. In this paper, the term governance theatre describes the condition in which governance is visible as a formal activity but weak as an operational control capability.

The distinction is consequential because AI-enabled GRC increasingly operates within business processes rather than in isolated technology environments. Where AI can influence customer decisions, financial processes, regulatory interpretation, supplier relationships or control execution, governance must be capable of intervening in those processes. The relevant question is therefore not whether an organisation has an AI policy, but whether it can demonstrate who has authority, who is accountable, what controls can intervene, and what evidence proves that those controls operate effectively.

A practical foundation can be expressed through four mutually reinforcing requirements:

Authority + accountability + intervention + evidence.

Authority establishes who can make decisions about the use and operation of AI. Accountability identifies the person or function ultimately responsible for outcomes. Intervention provides mechanisms to constrain, pause, modify or terminate AI-enabled activity. Evidence demonstrates what the system did, why it did it and whether the applicable controls operated as intended. Without all four, governance risks becoming advisory rather than controlling.

7.1 From governance frameworks to operational control

ISO/IEC 42001 provides an important management-system foundation for establishing structured AI governance, while the NIST AI Risk Management Framework provides a complementary approach to identifying, assessing and managing AI-related risks (ISO/IEC, 2023; NIST, 2023). Their strategic value, however, depends on whether their principles are translated into operational mechanisms.

A management system becomes materially stronger when governance requirements are embedded into workflows, system permissions, approval mechanisms, monitoring processes and evidence repositories. For example, a policy stating that high-risk AI applications require human oversight has limited value unless the system architecture actually prevents the relevant action from occurring without the required approval. Similarly, a requirement for periodic model evaluation is insufficient if the organisation cannot identify which systems are in scope, retrieve the necessary performance evidence or trigger remediation when performance deteriorates.

The transformation therefore involves moving from governance as documentation to governance as executable organisational infrastructure. Policies establish expectations; controls translate those expectations into operational constraints; monitoring determines whether those constraints are functioning; and assurance provides evidence that the overall system remains effective.

7.2 Establishing accountable ownership

Every material AI-enabled GRC capability should have a clearly identified accountable owner. This should not automatically be the technology function. Where AI affects a business decision, risk exposure or regulatory obligation, accountability should remain connected to the business process and its underlying risk.

This principle reflects the broader observation that AI value and risk are realised through organisational workflows rather than through models in isolation. Technological capabilities generate organisational value when they are integrated with business processes, complementary resources and organisational capabilities, rather than deployed as standalone technical assets (Bharadwaj et al., 2013). Similarly, the organisational consequences of AI depend upon how tasks, responsibilities and decision rights are allocated between humans and machines (Raisch and Krakowski, 2021).

A finance executive, compliance leader, procurement owner or business process executive may therefore have greater accountability for an AI-enabled capability than the team that operates the underlying model. The model team may be responsible for technical performance, maintenance and model-related controls, while the business or process owner remains accountable for the purpose of the capability, the decisions it supports, the controls surrounding its use and the consequences of its outputs. This distinction is consistent with AI governance approaches that emphasise clearly defined roles, responsibilities, human oversight and risk management across the AI system lifecycle (NIST, 2023; ISO/IEC, 2023).

The implication is that accountability should follow organisational purpose, decision rights and control responsibility, not merely technical ownership. Effective governance must therefore distinguish between responsibility for developing or operating a model and accountability for the AI-enabled process or outcome in which that model is used. The proposed GRC operating model consequently treats business and process ownership, technical stewardship, human oversight and assurance as related but distinct responsibilities that must be explicitly defined and coordinated.

Accountability should extend across the AI lifecycle. Someone must be responsible for determining whether a system should be deployed, defining its intended purpose, approving its risk classification, monitoring its performance, responding to incidents and deciding whether it should be modified or retired. Where responsibilities are distributed across technology, risk, legal and business functions, the organisation should still identify a single accountable authority for material outcomes.

This prevents a common governance failure in which responsibility becomes fragmented across multiple committees and technical teams, creating a situation in which everyone participates in governance but no individual possesses clear accountability for the resulting decision.

7.3 Making decision rights explicit

Governance becomes operational when decision rights are explicit. The organisation should determine who has authority to approve, reject, pause, modify, restrict or terminate an AI-enabled capability. These rights should be linked to risk thresholds and defined before material systems enter production.

Decision rights are particularly important where AI operates with increasing autonomy. An agent may be technically capable of executing an action but organisationally prohibited from doing so. Conversely, a human operator may possess formal authority but lack the technical means to intervene. Effective governance requires alignment between organisational authority and technical control.

This means that governance decisions should be reflected in system architecture. If a particular risk classification requires executive approval, the workflow should enforce that requirement. If a high-impact action requires human confirmation, the system should technically require confirmation rather than merely recommending it in policy documentation. If a model must be suspended following a material control failure, the organisation should have a tested mechanism for doing so.

The principle is therefore that decision rights must be both organisationally assigned and technically enforceable.

7.4 Business ownership of AI risk

AI risk should not become a technology-only responsibility. Technology teams are responsible for many aspects of system performance, security and infrastructure, but business functions remain accountable for the decisions and outcomes generated within their domains.

This is particularly important for GRC because the consequences of AI failure frequently arise outside the technology environment. An incorrect customer-risk assessment is a compliance and business risk. An inappropriate supplier decision is a procurement and operational risk. An inaccurate regulatory interpretation is a legal and compliance risk. An erroneous financial recommendation is a financial and potentially fiduciary risk.

Consequently, AI governance should be integrated with existing enterprise risk ownership rather than creating a parallel technology-centric risk universe. The role of GRC is to connect AI-related risks to the business processes, control objectives and risk owners that already govern organisational outcomes.

This is consistent with the broader conception of AI as an organisational capability rather than a standalone technology. Digital business strategy research indicates that technological capabilities generate organisational value when they are integrated with business processes, complementary resources and organisational capabilities rather than deployed as isolated technical assets (Bharadwaj et al., 2013). Similarly, the organisational consequences of AI depend upon how tasks, responsibilities and decision rights are allocated between humans and machines (Raisch and Krakowski, 2021).

Governance maturity therefore depends partly on whether AI-related risk is incorporated into existing accountability structures rather than isolated within specialist committees. Effective AI governance requires clearly defined roles, responsibilities, human oversight and risk-management processes across the AI system lifecycle (NIST, 2023; ISO/IEC, 2023). Specialist AI or model-risk functions remain important for technical oversight and challenge, but they should complement—not replace—the accountability of business, process and control owners for the organisational purposes and consequences of AI-enabled activities.

The implication is that AI governance should be treated as an enterprise responsibility, with accountability aligned to organisational purpose, decision rights and control ownership. The proposed GRC operating model therefore treats specialist AI expertise, business ownership, technical stewardship, human oversight and independent assurance as distinct but interconnected responsibilities that must be explicitly defined and coordinated.

7.5 Human oversight versus meaningful human control

A particularly important distinction is between human-in-the-loop and meaningful human control. The presence of a human somewhere within an AI workflow does not, by itself, establish effective oversight.

A human reviewer may formally approve every recommendation while lacking sufficient time, information, expertise or authority to challenge the system. In such a configuration, the human effectively becomes a rubber stamp rather than a control mechanism. The organisation may be able to demonstrate that a person approved the decision, but not that meaningful judgement was exercised.

Meaningful human control requires at least four conditions. The reviewer must have sufficient information to understand the recommendation and its evidentiary basis. They must possess the authority to reject, modify or escalate the recommendation. They must have adequate time and capability to exercise that authority. Finally, the workflow must allow intervention to occur before an irreversible or consequential action takes place.

This distinction is especially important for agentic systems. As AI becomes capable of performing multi-step activities, human oversight must be positioned at points where intervention can still affect the outcome. Placing a human after the agent has already executed the consequential action provides retrospective review, not meaningful control.

The objective should therefore be to design human–AI control systems, rather than simply inserting humans into automated workflows.

7.6 Embedding intervention mechanisms

Effective governance requires the ability to intervene when circumstances change or controls fail. Intervention mechanisms should include the ability to pause an AI workflow, revoke permissions, modify policies, require additional approval, route cases to human review and, where necessary, disable the relevant capability.

These mechanisms should be tested rather than assumed. An organisation may have a formal policy allowing an AI system to be suspended, but if no one knows who has authority to suspend it or the technical process takes several days, the control may be ineffective during a rapidly developing incident.

Intervention should also be proportionate. Not every anomaly requires complete system shutdown. Controls can operate at multiple levels, including restricting a particular tool, lowering an agent's permissions, increasing approval requirements, isolating a specific workflow or moving a capability temporarily into recommendation-only mode.

This creates a graduated control response that is better aligned with the dynamic nature of AI-enabled systems.

7.7 Evidence as a foundation of accountability

Governance cannot be demonstrated without evidence. AI-enabled GRC therefore requires systematic capture of the information necessary to reconstruct decisions and actions.

Evidence should extend beyond model outputs to include relevant input data, source provenance, model or agent version, applicable policies, permissions, tools invoked, recommendations generated, human interventions, approvals and resulting actions. Where an AI system contributes to a consequential decision, the organisation should be able to establish a defensible chain from evidence → reasoning → decision → action → outcome.

This requirement reinforces the importance of the data foundation established in Strategic Pillar 1. Without reliable provenance, lineage and authoritative sources, governance evidence becomes fragmented and difficult to defend. Similarly, without workflow integration, evidence may be captured in one system while the corresponding action occurs elsewhere.

Machine-generated evidence can therefore become a strategic GRC capability. Rather than relying on analysts to reconstruct an audit trail retrospectively, the system can produce contemporaneous records as part of normal operation. This reduces assurance costs while strengthening the organisation's ability to demonstrate control effectiveness.

7.8 Continuous assurance rather than periodic certification

Traditional assurance models frequently rely on periodic assessments: a system is reviewed, approved and then reassessed at a later date. This model becomes increasingly inadequate as AI systems, data sources, prompts, models and workflows change over time. The NIST AI Risk Management Framework emphasises that AI risks should be managed throughout the system lifecycle, including through ongoing measurement, monitoring and management, while ISO/IEC 42001 establishes a management-system approach based on monitoring and continual improvement (NIST, 2023; ISO/IEC, 2023).

AI governance should therefore evolve towards continuous assurance. Monitoring should identify material changes in system performance, data quality, control effectiveness, access permissions, model behaviour and operating context. Where such changes may alter the risk profile or effectiveness of existing controls, they should trigger proportionate reassessment rather than waiting for the next scheduled review (NIST, 2023; ISO/IEC, 2023).

This site refers to this approach as Continuous AI Compliance and Assurance (CAICA), in which assurance is integrated across the AI lifecycle rather than concentrated at discrete certification or assessment points. CAICA represents a shift from periodic assurance towards continuous, lifecycle-oriented assurance, with monitoring and control activities designed to identify material changes and support timely reassessment.

Continuous assurance does not imply continuous manual auditing. Much of the evidence collection, control testing and monitoring can itself be automated. Control performance can be assessed through system telemetry, exception rates, access events, approval patterns, evaluation results and workflow outcomes. Human assurance professionals can then focus on material exceptions, emerging risks, ambiguous cases and areas where automated evidence indicates deterioration or where judgement is required. This reflects the broader principle of designing human and AI activities according to the nature of the task and the level of judgement required (Raisch and Krakowski, 2021).

The result is a shift from “Is this system compliant at the time of assessment?” towards “Is this system continuing to operate within its approved risk and control boundaries?” Assurance consequently becomes an ongoing organisational capability rather than a discrete assessment event, providing a basis for earlier intervention when changes in the AI system, its environment or its controls may affect continued compliance and acceptable risk.

7.9 Escalation as a core governance mechanism

A mature governance architecture must also define what happens when an AI system encounters conditions outside its authorised operating envelope. Escalation should therefore be designed into workflows rather than treated as an exceptional administrative procedure.

Triggers may include uncertainty above an established threshold, conflicting evidence, anomalous system behaviour, novel scenarios, material changes in the regulatory environment, attempts to access restricted information or actions exceeding predefined authority limits. When such conditions occur, the system should route the case to an appropriately authorised human or control function.

Escalation is particularly important for agentic systems because their ability to act can amplify the consequences of uncertainty. An agent that cannot confidently determine whether an action is appropriate should not be encouraged to complete the task simply because the workflow expects an output. Controlled incompleteness is preferable to uncontrolled execution when the consequences of error are material. This reflects the broader principle that AI systems should be governed according to their potential risks and impacts, with appropriate human oversight and mechanisms for managing uncertainty and unintended outcomes (NIST, 2023; ISO/IEC, 2023).

For agentic systems, this requires explicit controls over the transition from machine-generated intelligence to operational action. Reasoning-and-acting approaches such as ReAct demonstrate how language-model systems can combine reasoning with interaction with external tools and environments (Yao et al., 2023). In a governed GRC context, however, the ability to identify an action and technically execute it should not be treated as sufficient authority to do so. Permissions, verification, approval checkpoints, monitoring and escalation mechanisms should determine whether and under what conditions a proposed action can proceed. These controls provide a governance boundary between what an agent is capable of doing and what it is authorised to do (NIST, 2023; ISO/IEC, 2023).

The resulting principle is that increasing agentic capability should not automatically imply increasing operational authority. Where uncertainty, materiality or potential impact exceeds predefined thresholds, the appropriate system response may be to pause, request additional evidence or escalate to an accountable human decision-maker rather than force completion. In this sense, controlled incompleteness becomes a deliberate feature of resilient agentic GRC rather than a failure of automation.

7.10 Integrating AI governance with enterprise GRC

AI governance should ultimately become part of the broader GRC architecture rather than remain a parallel specialist discipline. AI-related risks should connect to enterprise risk registers, control frameworks, regulatory obligations, policies, business processes, third-party dependencies and assurance activities.

This integration is increasingly important because AI risk is rarely isolated. A model may depend upon a third-party provider, enterprise data source, cloud infrastructure, identity system and external regulatory environment. A failure or material change in one component can therefore affect multiple organisational processes and control relationships. Enterprise risk management research highlights the importance of understanding interactions and interdependencies among different sources of organisational risk rather than treating exposures as entirely independent (Bromiley et al., 2015). Knowledge-graph approaches likewise provide mechanisms for representing relationships among entities and connecting otherwise distributed information (Hogan et al., 2021).

The networked nature of modern GRC therefore requires governance to account for dependencies, relationships and organisational boundaries rather than assessing AI systems solely as isolated technical objects. In the proposed GRC architecture, an AI capability should consequently be assessed in the context of the wider ecosystem on which it depends, including relevant data, technologies, suppliers, identities, processes, controls and regulatory obligations. This provides a basis for understanding how changes or failures in one part of the environment may create consequences elsewhere and for directing monitoring and assurance towards the relationships that are most material to organisational risk.

An integrated approach also reduces duplication. Rather than establishing separate governance processes for cybersecurity, privacy, AI, third-party risk and operational resilience, organisations can connect them through common ownership, evidence, controls and escalation mechanisms. AI governance then becomes one component of a broader organisational control architecture.

7.11 From governance theatre to demonstrable control

The strategic test of AI governance is ultimately whether the organisation can demonstrate that governance changes behaviour. A mature system should be able to answer, with evidence, several fundamental questions: Who owns this AI capability? Who authorised its use? What decisions may it make? What actions may it execute? What information may it access? What controls constrain it? When must a human intervene? What happens when those controls fail? Who can suspend the system? And what evidence demonstrates that the controls are working?

If these questions cannot be answered operationally, the organisation may have governance structures without effective organisational control.

The transformation therefore requires a shift from committee-centred governance to control-centred governance. Committees remain important for strategy, oversight and escalation, but they cannot substitute for embedded mechanisms that influence system behaviour. Policies remain necessary, but they must be translated into permissions, workflows, approval gates, monitoring rules and intervention capabilities.

This is consistent with the broader principle that governance must be translated into operational processes and infrastructure if it is to remain effective in increasingly automated environments. The NIST AI Risk Management Framework emphasises the integration of governance, risk management, measurement and ongoing management across the AI lifecycle, while ISO/IEC 42001 establishes a management-system approach through which AI governance can be embedded into organisational policies, responsibilities, processes, controls and continual improvement activities (NIST, 2023; ISO/IEC, 2023).

The implication is that governance should not remain confined to policy documents or specialist oversight forums. Its principles must be reflected in the data, workflows, permissions, decision rights, monitoring mechanisms and control processes through which AI-enabled activities are actually performed. This provides the foundation for moving from governance as a set of stated requirements towards governance as an operational organisational capability.

7.12 The organisational control system

The ultimate objective is to establish an organisational control system in which governance operates continuously across the AI lifecycle. Authority determines what the system is permitted to do; accountability determines who is responsible for the outcome; controls constrain execution; monitoring detects deviations; evidence makes behaviour observable; assurance tests effectiveness; and escalation provides mechanisms for intervention.

This represents a fundamental evolution in the role of GRC. Rather than operating primarily as an oversight layer positioned above technology and business processes, GRC becomes embedded within the architecture through which decisions are made and actions are executed.

The strategic implication is that AI governance should be designed to control organisational behaviour, not merely to govern AI technology. The strongest governance model is therefore not the one with the most policies, committees or assessment forms. It is the one capable of demonstrating, in real time, that the organisation knows who has authority, can intervene when necessary, can trace consequential decisions and can provide evidence that its controls remain effective.

In this model, governance ceases to be a periodic declaration of intent and becomes a continuous organisational capability. That is the transition from AI governance to organisational control.

8. Strategic pillar 5: Create continuous AI assurance

The fifth strategic priority is to replace static, point-in-time AI assurance with a continuous assurance capability capable of responding to changes in models, data, workflows, permissions, regulatory requirements and organisational use. Traditional assurance approaches generally assume that the system being assessed remains sufficiently stable between formal reviews. AI-enabled systems challenge this assumption because the conditions under which an AI capability operates can change materially after its initial approval.

The resulting governance problem is fundamentally temporal. A system approved at time t₀ may no longer satisfy its approved risk, control or performance requirements at time t₁. The model may have changed, its underlying data may have drifted, retrieval sources may have been updated, prompts may have been modified, a new tool may have been connected, a vendor may have changed its service, or users may have begun employing the system in ways that were not anticipated during the original assessment.

Consequently, AI assurance cannot be treated as a certification event that establishes enduring compliance. It must become a mechanism for determining whether an AI-enabled capability continues to operate within its approved boundaries throughout its lifecycle.

This emerging requirement is conceptualised in this paper through Continuous AI Compliance and Assurance (CAICA). CAICA reframes assurance as a lifecycle capability in which evidence, monitoring, testing and intervention are integrated into the operation of AI systems rather than concentrated around periodic assessments. This is consistent with the NIST AI Risk Management Framework, which treats AI risk management as an ongoing lifecycle activity involving governance, measurement and management rather than as a one-time approval process (NIST, 2023). The NIST Generative AI Profile further emphasises the need to consider risks arising from the broader AI system and its context of use, rather than reducing assurance to model performance or accuracy alone (Autio et al., 2024).

Under this approach, assurance becomes an ongoing control capability that can identify material changes, assess their implications and support proportionate intervention throughout the AI lifecycle. CAICA therefore represents a shift from periodic certification towards continuous, evidence-based assurance, in which the organisation maintains an evolving understanding of whether AI systems continue to operate within their approved risk, governance and control boundaries.

8.1 From point-in-time approval to continuous validity

The central weakness of static assurance is that it creates an implicit assumption of persistence: once a system has passed an assessment, its control state is presumed to remain sufficiently stable until the next review.

That assumption is increasingly difficult to defend.

AI systems are dynamic socio-technical environments. Their behaviour can be influenced by model updates, changes in input data, retrieval corpora, prompts, tools, interfaces, user behaviour and external services. A system may therefore remain technically operational while its risk profile changes significantly.

Consider an AI-enabled regulatory compliance agent approved to retrieve information from a defined set of authoritative sources. If an additional data source is subsequently connected, the information available to the agent has changed. If the agent receives a new tool that allows it to modify a system record, its action capability has changed. If the underlying regulatory corpus is altered without appropriate version control, the basis for its recommendations may have changed. If users begin applying the system to a higher-impact decision than originally intended, its use context has changed.

Each of these events may invalidate assumptions embedded in the original assurance assessment.

Continuous assurance therefore requires organisations to distinguish between system availability and control validity. A system can be functioning normally while its governance assumptions have become obsolete. The relevant assurance question is not simply whether the system is operating, but whether it continues to operate within the conditions under which it was authorised.

8.2 Assurance as a continuous control loop

A mature assurance architecture should operate as a feedback loop:

Observe → evaluate → detect deviation → assess materiality → intervene → remediate → revalidate → continue monitoring.

This is materially different from the traditional sequence of assess, certify and periodically reassess. Continuous assurance brings monitoring and intervention into the operating lifecycle.

The process begins with observation. Relevant system, data, workflow and control signals are collected continuously or at appropriate intervals. These signals are evaluated against defined expectations, thresholds and control objectives. Deviations are then assessed according to their materiality. Where a deviation exceeds the organisation's tolerance, the system may require remediation, additional human review, restriction of functionality or temporary suspension. Following remediation, the relevant capability is revalidated before normal operation resumes.

This creates a form of closed-loop GRC in which assurance is not external to operations but embedded within them.

8.3 What should be continuously monitored?

Continuous AI assurance should extend beyond conventional model-performance metrics. The object of assurance is the complete AI-enabled system, including its technical components, data environment, workflow, permissions, users and organisational context.

Model performance remains important. Organisations should monitor whether models continue to perform against defined objectives and whether performance deteriorates across relevant populations or scenarios. However, model accuracy alone provides an incomplete picture of risk.

Data should also be monitored for drift, quality deterioration, missingness, changes in distribution and changes in provenance. Where retrieval-augmented systems are used, organisations should monitor changes in the retrieval corpus, source authority, document versions and retrieval behaviour. Changes in training or retrieval data can alter outputs even where the underlying model has not changed.

Prompt and instruction changes are similarly relevant. In agentic environments, modifications to system prompts, policies, tool descriptions or contextual instructions may materially change behaviour. These changes should therefore be subject to appropriate versioning, approval and testing.

Tool permissions represent another critical assurance dimension. An agent with access only to read information has a different risk profile from an agent that can create records, approve transactions or modify customer or supplier information. Changes in permissions should therefore be treated as material control events where they alter the system's capacity to affect organisational state.

Agent behaviour should also be monitored. Relevant indicators may include unusual action sequences, unexpected tool invocation, repeated failed attempts, policy violations, excessive escalation, anomalous decisions or behaviour outside established operating patterns. This becomes particularly important as agents become capable of executing multi-step workflows.

Finally, assurance should monitor changes in the external environment. Regulatory requirements, organisational policies, third-party services, business processes and risk appetites can all change the conditions under which an AI system operates.

8.4 Monitoring the broader system rather than the model alone

One of the most important implications of generative and agentic AI is that assurance must move beyond the model as the primary object of evaluation. The relevant system includes the model, data, retrieval mechanisms, prompts, interfaces, tools, users, controls and surrounding workflow.

A technically accurate model may still create unacceptable risk if it is supplied with unreliable data. A well-governed model may become problematic if its permissions are expanded without reassessment. A model with acceptable benchmark performance may produce inappropriate outcomes when embedded in a particular organisational process. An agent may generate reasonable recommendations but create unacceptable risk if its execution controls are weak.

This systems perspective is reflected in the NIST Generative AI Profile, which emphasises risks associated with the broader sociotechnical context of generative AI rather than model performance in isolation (Autio et al., 2024). It is also consistent with the broader GRC perspective that risk management should be integrated with organisational strategy, performance and decision-making rather than treated as a separate reporting activity (COSO, 2017). More broadly, digital business strategy research indicates that technological capabilities generate organisational value when they are integrated with business processes and complementary organisational capabilities rather than operated as isolated technical resources (Bharadwaj et al., 2013).

Continuous assurance should therefore evaluate the interaction between components, not simply the quality of each component independently. In an AI-enabled GRC environment, this means considering how data, models, workflows, controls, human decisions, permissions and operating conditions interact to influence the overall risk and control environment. Assurance should consequently assess not only whether individual components remain within their expected parameters, but also whether their combined operation continues to support the intended governance, risk and control objectives.

8.5 Event-driven assurance

Continuous assurance does not necessarily mean that every control must be tested continuously in real time. A more practical architecture combines continuous monitoring with event-driven reassessment.

Certain events should automatically trigger a control review. These may include a material model update, a change in training or retrieval data, connection of a new tool, modification of agent permissions, significant prompt changes, a regulatory change, a material incident, deterioration in model performance or a substantial change in the business process in which the AI is used.

This creates a distinction between ordinary monitoring and assurance-triggering events. Routine operation can be monitored through automated controls and telemetry, while material changes initiate deeper assessment.

Such an approach is both more efficient and more defensible than relying exclusively on calendar-based reviews. A low-risk system with stable characteristics may require relatively limited intervention, while a system undergoing significant architectural or behavioural change can be reassessed immediately.

The principle is therefore:

Change should trigger assurance, not merely the passage of time.

8.6 Continuous control testing

Continuous assurance should also extend to the effectiveness of controls themselves. It is insufficient to verify that an organisation has a human-approval policy; the organisation should be able to determine whether the approval mechanism is actually functioning.

Examples include testing whether restricted actions genuinely require approval, whether agents possess only their authorised permissions, whether prohibited tools remain inaccessible, whether escalation thresholds are triggered correctly and whether audit records are generated for consequential actions.

Automated control testing can substantially reduce the cost of assurance while increasing its frequency. Machine-readable policies and system telemetry can be used to identify exceptions as they occur. Where controls are deterministic, testing can often be performed automatically. Where judgement is required, automated monitoring can identify cases requiring targeted human review.

This supports a shift from evidence collection for assurance towards assurance generated through normal system operation.

The distinction is important. Traditional assurance frequently requires teams to assemble evidence after an activity has occurred. In a continuous architecture, evidence is generated contemporaneously as decisions and actions take place. The system itself becomes a source of assurance evidence.

8.7 Human overrides as assurance signals

Human intervention should not be treated merely as an operational exception. Patterns of human override can provide valuable information about system performance and control design.

If reviewers routinely reject an agent's recommendations within a particular process, this may indicate inadequate model performance, insufficient contextual information, inappropriate decision thresholds or a mismatch between the agent's design and professional judgement. Similarly, repeated requests for escalation may indicate that the workflow has been assigned too much autonomy.

Human overrides should therefore be monitored as learning signals. The objective is not necessarily to minimise overrides. In some high-consequence processes, frequent intervention may be an appropriate feature of the control environment. The relevant question is whether the pattern of intervention is consistent with the intended risk and authority model.

This creates an important feedback mechanism between human expertise and system behaviour. Professional judgement becomes not only a safeguard against AI error but also a source of evidence for improving the AI-enabled workflow.

8.8 Incident management and anomalous behaviour

Continuous assurance must be closely connected to incident management. AI-related incidents may include incorrect decisions, unauthorised actions, data leakage, policy violations, inappropriate tool use, unexpected model behaviour or failures of human oversight.

An effective assurance architecture should detect relevant signals, classify their materiality, preserve evidence, initiate containment and determine whether broader reassessment is required. Where an incident reveals that an AI system has operated outside its approved boundaries, the appropriate response may extend beyond correcting the immediate problem to reassessing the underlying governance assumptions. This reflects the lifecycle-oriented approach to AI risk management, which emphasises ongoing monitoring, measurement, documentation and the management of risks as systems and their operating environments evolve (NIST, 2023; ISO/IEC, 2023).

Anomalous actions are particularly important in agentic systems because an unusual action may be an early indicator of a more significant control failure. Monitoring should therefore consider not only whether individual actions are permissible, but also whether sequences of actions remain consistent with the agent’s intended purpose, authorised permissions and applicable control requirements. This is particularly relevant where agentic systems combine reasoning with external tool use and iterative interaction with their environment (Yao et al., 2023).

This reinforces the need for comprehensive observability across agentic workflows, including tool invocation, permissions, decisions, approvals, exceptions and outcomes. Such observability should enable the organisation to reconstruct how an action was initiated, what information and permissions were available, which controls or approvals were applied, and what consequences followed. NIST and ISO/IEC 42001 both emphasise the importance of appropriate documentation, accountability, monitoring and oversight across the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

The objective is therefore not simply to detect isolated policy violations, but to identify patterns of behaviour that may indicate drift, misuse, control degradation or a mismatch between intended and actual system operation. Where such patterns are material, they should trigger proportionate containment, human review and, where necessary, reassessment of the system’s risk classification, permissions, controls or approved use.

8.9 Regulatory and policy change as assurance triggers

AI assurance must also remain connected to the external regulatory environment. Regulatory change can alter the obligations, risk tolerances or control requirements applicable to an AI-enabled process.

A regulatory change should therefore not remain confined to a regulatory-change register. It should be capable of propagating through the GRC architecture to identify affected policies, obligations, controls, processes, AI systems and accountable owners. Where an AI capability depends upon a regulatory interpretation that has changed, the relevant workflow should be reassessed.

This creates an important connection between continuous regulatory intelligence and continuous AI assurance. Regulatory horizon scanning identifies change; the GRC data foundation establishes the relationships between obligations and controls; workflow architecture identifies affected processes; and assurance mechanisms determine whether AI systems remain compliant with the revised requirements.

The resulting architecture is substantially more responsive than a model in which regulatory change is reviewed manually once or twice a year.

8.10 Assurance of third-party AI dependencies

Continuous assurance must also extend beyond internally developed AI. Organisations increasingly depend upon external foundation models, cloud platforms, data providers, retrieval services, software vendors and specialised AI components. A change in a third-party service may materially affect an organisation’s AI risk profile even if the organisation itself has not changed its configuration. Model updates, service modifications, changes in data handling, new subprocessors or altered security controls can all introduce new risks.

Third-party assurance should therefore move beyond static vendor questionnaires towards continuous monitoring of material dependencies. Contractual provisions, service-level commitments, security evidence, model or service changes and relevant incidents should feed into the organisation’s ongoing risk assessment. This reflects the lifecycle-oriented approach to AI risk management, which requires organisations to monitor and manage changes in AI systems and their operating environments, including risks arising from external dependencies (NIST, 2023).

The issue is also consistent with enterprise risk management research, which emphasises that organisational exposures are interconnected and that risks may arise through relationships among internal activities, external providers and wider organisational boundaries (Bromiley et al., 2015). In an AI-enabled environment, third-party assurance should therefore assess not only the provider as an individual entity, but also the dependencies and control relationships through which the provider contributes to the organisation’s AI-enabled processes.

The proposed GRC architecture consequently treats third-party AI assurance as an ongoing capability involving dependency mapping, change detection, evidence collection, contractual oversight, incident monitoring and proportionate reassessment. The objective is to ensure that material changes in the external AI ecosystem are identified and connected to the organisation’s own risk, control and decision processes rather than remaining outside the enterprise assurance boundary.

8.11 Assurance maturity and proportionality

Continuous assurance should be proportionate to the risk and consequence of the AI capability. Not every model requires the same level of monitoring, testing or human review.

Low-risk systems may require basic performance monitoring, access controls and periodic validation. Higher-risk systems should incorporate more extensive telemetry, automated control testing, event-driven reassessment, human oversight and independent assurance. Systems capable of autonomous action or decisions affecting individuals may require the strongest combination of monitoring, evidence, intervention and governance.

This creates a risk-based assurance architecture rather than a uniform compliance burden. The level of assurance should correspond to factors such as decision impact, reversibility, regulatory exposure, data sensitivity, autonomy, uncertainty and dependency on external providers.

Importantly, proportionality should not become an excuse for weak controls. The purpose of risk-based assurance is to allocate assurance resources according to materiality while maintaining minimum standards of accountability, traceability and intervention.

8.12 From assurance activity to assurance infrastructure

The strategic objective is ultimately to embed assurance into the architecture of AI-enabled GRC. Instead of creating a separate assurance process that periodically inspects AI systems, organisations should build systems capable of generating evidence, detecting deviations and initiating control responses as part of normal operation.

This requires a combination of data lineage, system telemetry, model evaluation, policy enforcement, identity controls, workflow monitoring, incident management and evidence repositories. The assurance layer should be connected to the same organisational knowledge infrastructure described in Strategic Pillar 1 and the workflow architecture established in Strategic Pillar 2.

The result is a continuous assurance fabric spanning the AI lifecycle:

Govern → deploy → observe → evaluate → intervene → remediate → revalidate → learn.

Such an architecture changes the economics of assurance as well as its effectiveness. If evidence is generated automatically and controls are continuously tested, organisations can reduce the dependence on labour-intensive retrospective evidence gathering. Assurance professionals can then focus on material exceptions, systemic weaknesses, emerging risks and areas requiring independent judgement.

8.13 Towards continuous organisational learning

The final purpose of continuous assurance is not simply to detect failure. It is to create a mechanism through which the organisation learns from system behaviour.

Performance deterioration, recurring overrides, control exceptions, incidents and anomalous actions should feed back into workflow redesign, agent configuration, data-quality improvement, policy updates and governance decisions. Assurance consequently becomes part of the organisation’s learning and control system, enabling evidence generated through monitoring and assurance activities to inform subsequent changes to processes, controls and decision-making. This is consistent with the broader enterprise risk management principle that risk management should be integrated with organisational strategy and performance rather than treated as a separate reporting activity (COSO, 2017).

This approach is also consistent with the lifecycle orientation of AI governance. NIST emphasises ongoing measurement, monitoring and management of AI risks, while ISO/IEC 42001 establishes a management-system approach that includes monitoring, evaluation and continual improvement (NIST, 2023; ISO/IEC, 2023). As AI systems evolve, the organisation must therefore be able to evaluate whether its assumptions, controls and governance arrangements remain appropriate and adapt them when evidence indicates that they no longer provide the intended level of control.

The strategic implication is that assurance must evolve at least as quickly as the systems it governs. A static annual review cycle is poorly matched to AI systems whose models, data, permissions, integrations and use cases can change continuously. The appropriate response is not to eliminate formal assurance, but to supplement it with continuous monitoring, event-driven reassessment, automated control testing and evidence generation (NIST, 2023; ISO/IEC, 2023).

Continuous AI assurance therefore represents a shift from certifying a system at a point in time to continuously demonstrating that it remains trustworthy, controlled and fit for purpose. This is the foundation of Continuous AI Compliance and Assurance (CAICA) proposed in this paper and an essential capability for AI-enabled GRC: governance becomes a living control system that observes change, detects deviation, enables proportionate intervention and generates evidence throughout the technology lifecycle.

The resulting feedback loop also creates an opportunity to improve how work is allocated between humans and AI. Evidence from exceptions, overrides and system performance can inform whether particular activities should remain automated, require greater human oversight or be redesigned altogether. This reflects the automation–augmentation perspective that the organisational value of AI depends partly on how tasks and responsibilities are continually reconfigured around human–AI interaction (Raisch and Krakowski, 2021).

9. Strategic pillar 6: Design GRC for failure

The sixth strategic priority is to design GRC architectures on the assumption that AI systems will sometimes be wrong, unavailable, manipulated or otherwise operate outside their intended conditions. This represents a fundamental shift from a traditional control philosophy focused primarily on preventing failure towards a resilience-oriented approach in which systems are designed to detect failure, contain its consequences, recover safely and learn from the event.

The assumption is not that AI systems are inherently unreliable. Rather, it is that uncertainty and failure are unavoidable characteristics of complex socio-technical systems. AI-enabled GRC introduces additional sources of uncertainty because outcomes may depend upon probabilistic models, dynamic data, retrieval systems, external services, user instructions, agent tools and interconnected enterprise infrastructure. A robust control architecture must therefore remain effective even when individual components perform imperfectly.

Potential failure modes include hallucinated or unsupported outputs, incorrect classifications, incomplete retrieval, stale information, model degradation, tool failure, permission errors, prompt injection, integration failures, vendor outages and inappropriate human reliance on AI-generated recommendations. These failure modes differ in origin and consequence, but they share a common implication: the organisation cannot make trustworthy GRC dependent upon the assumption that every AI component will behave correctly at all times.

Modern AI-enabled enterprise systems should be designed not merely to prevent failure, but also to detect, contain, recover from and learn from failure. This perspective is particularly important for GRC because failures in compliance, risk assessment or control execution can affect interconnected processes and dependencies. Enterprise risk management research highlights the interconnected nature of organisational risks, while the NIST AI Risk Management Framework emphasises the need to identify, assess and manage risks throughout the AI lifecycle, including risks arising from changing operating conditions and potential system failures (Bromiley et al., 2015; NIST, 2023).

Resilience should therefore be treated as an architectural and governance requirement from the outset, rather than as a capability added only after an incident. AI-enabled GRC systems should incorporate mechanisms for detecting abnormal conditions, constraining potentially harmful actions, escalating material exceptions, supporting recovery and preserving evidence for subsequent analysis. These mechanisms help ensure that a failure in one component does not automatically translate into uncontrolled consequences across the wider control environment.

The core operating principle proposed in this paper is:

Detect → constrain → fail safely → escalate → recover → learn.

This principle extends continuous assurance beyond the detection of non-compliance towards the design of a GRC environment that can remain controlled under degraded conditions. The objective is not to assume that failure can be eliminated, but to ensure that when failure occurs, its consequences are bounded, observable, recoverable and capable of generating evidence for organisational learning (NIST, 2023).

9.1 From prevention to resilience

Traditional GRC often approaches risk through prevention: identify the risk, implement a control and attempt to prevent the undesirable event. Prevention remains essential, but it is insufficient for complex AI-enabled environments.

No control system can eliminate every failure mode. A model can generate an incorrect conclusion despite appropriate training. A regulatory source can become unavailable. A third-party AI provider can experience an outage. A new prompt-injection technique can circumvent an otherwise effective safeguard. An integration can fail at precisely the point when a control decision is required.

Resilience engineering therefore asks a different question: What happens when the control fails?

This changes the design objective from perfect prevention to controlled degradation. A resilient GRC system should be able to recognise when a component is unreliable, restrict its authority, transfer the task to an alternative mechanism, escalate to a human and preserve sufficient evidence to support recovery.

This is consistent with broader resilience literature, which emphasises the ability of complex systems to absorb disruption, adapt to changing conditions and maintain critical functions rather than assuming that disruption can always be prevented (Christopher and Peck, 2004; Ivanov and Dolgui, 2021).

9.2 Designing for known AI failure modes

AI-enabled GRC should begin with explicit identification of plausible failure modes. These should include both technical failures and organisational responses to AI behaviour.

Hallucination occurs when a model produces information that is unsupported or incorrect. In GRC, this is particularly problematic where generated content is mistaken for authoritative regulatory, legal or risk information. Controls should therefore distinguish generated reasoning from authoritative evidence and require appropriate source validation for consequential outputs.

Incorrect classification can occur when an AI system assigns a case, entity, transaction or risk to the wrong category. Where classification drives downstream action, deterministic validation, confidence thresholds and human escalation may be necessary.

Incomplete retrieval is particularly relevant to retrieval-augmented systems. A system may retrieve relevant information while failing to retrieve all material information. Retrieval therefore should not automatically be interpreted as evidence of completeness. Critical decisions may require defined source coverage, retrieval validation or independent verification (Lewis et al., 2020).

Stale information creates a temporal failure. A previously accurate policy, regulatory requirement, customer record or risk assessment may become outdated. Data freshness and source versioning should therefore form part of the control environment.

Model degradation may occur as operating conditions change. A model that performed adequately during initial validation may behave differently when exposed to new populations, new data distributions or new use cases. Continuous evaluation is therefore necessary rather than assuming permanent validity.

These failure modes demonstrate why model-level assurance alone is inadequate. Resilience must be designed across the complete AI-enabled workflow.

9.3 Tool and integration failure

Agentic systems introduce additional failure modes because they can interact with enterprise tools and external systems. An agent may correctly identify an appropriate action but fail when attempting to execute it. An API may be unavailable, a downstream system may return an unexpected response, a transaction may partially complete, or a permission may expire or be incorrectly configured. These conditions become particularly important where AI systems combine reasoning with interaction with external tools and environments (Yao et al., 2023).

The agentic architecture must therefore distinguish between reasoning success and execution success. An agent’s decision to perform an action does not mean that the action was successfully completed or that the resulting enterprise state is correct. This distinction is important for governed AI systems because the organisation must be able to determine not only what the system intended to do, but also what actually occurred and whether the resulting state remains within the applicable control boundaries (NIST, 2023; ISO/IEC, 2023).

Critical workflows should therefore include transaction controls, confirmation mechanisms and state verification. Where an action is interrupted, the system should determine whether the transaction was completed, partially completed or not executed before attempting a retry. Automatic retries without state awareness can create duplicate actions or compound the original failure. The appropriate response should therefore depend upon the verified state of the affected system rather than assuming that an unsuccessful or interrupted tool call necessarily means that no action occurred.

This implies that resilient agentic architectures should incorporate explicit checkpoints, retries, timeouts, transaction boundaries and verification mechanisms appropriate to the consequences of the action. These controls should be designed into the workflow rather than treated as technical exceptions after deployment. Such an approach is consistent with the broader AI governance requirement to establish appropriate oversight, monitoring, documentation and risk-management mechanisms throughout the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

The resulting design principle is that agentic execution should be state-aware, verifiable and recoverable. An agent should not simply determine what should happen; the surrounding control architecture should establish whether the authorised action occurred, what state resulted, whether that state is acceptable and what response is required when execution deviates from expectation.

9.4 Safe failure and bounded degradation

A critical GRC system should have a defined safe-failure state. When the AI component becomes unreliable or unavailable, the organisation should know what happens next.

Safe failure may involve reverting from autonomous execution to recommendation-only mode, switching to a deterministic rule set, routing the case to a human analyst or activating an alternative workflow. The appropriate fallback depends upon the process and its risk.

For example, if an AI system supporting regulatory obligation extraction becomes unavailable, the organisation may be able to continue using an established manual review process. If an agent responsible for a high-impact control action becomes uncertain about whether the action is authorised, the appropriate response may be to halt execution and require human approval.

The key principle is that failure should reduce autonomy rather than increase risk.

This requires explicit degradation paths to be designed before deployment. A system that simply stops functioning may still create significant operational or compliance risk if no alternative process exists. Resilience therefore includes continuity of control, not merely availability of technology.

9.5 Checkpoints and transaction boundaries

Agentic workflows should be divided into meaningful stages separated by checkpoints. A checkpoint provides an opportunity to validate the state of the process before allowing further actions.

For example, an agent might first collect evidence, then analyse it, then generate a recommendation, then request approval and only subsequently execute an authorised action. Each transition creates a potential control boundary.

The purpose is to prevent a single erroneous inference from automatically propagating through an entire workflow. If the agent produces an unexpected result at the analysis stage, the organisation can intervene before the recommendation becomes an action. If a tool returns an unexpected response, execution can be paused before further transactions occur.

Transaction limits should also constrain the amount of change an agent can make within a single execution cycle. An agent authorised to update records should not necessarily be able to modify thousands of records without additional controls. Limiting transaction size reduces the potential impact of an erroneous or compromised agent.

These mechanisms embody a broader principle of bounded autonomy: an agent's authority should be constrained not only by what it is permitted to do, but also by how much it can do before additional validation is required.

9.6 Deterministic validation around probabilistic systems

AI systems are probabilistic, while many GRC requirements are deterministic. This creates an important architectural opportunity: deterministic controls can be positioned around probabilistic reasoning.

An AI system may interpret a regulatory requirement or assess whether evidence appears relevant. A deterministic control can then verify whether required fields are present, whether an action exceeds an authority threshold, whether a restricted system is being accessed or whether a mandatory approval has occurred.

This combination is often more robust than attempting to make the AI system responsible for every aspect of the control. AI can provide contextual reasoning where ambiguity exists, while conventional software can enforce non-negotiable constraints.

The objective should therefore not be to replace deterministic controls with AI. Instead, organisations should create layered control architectures in which probabilistic intelligence operates within deterministic boundaries.

This is particularly important for high-consequence GRC processes where the organisation must demonstrate that certain actions cannot occur unless specified conditions are satisfied.

9.7 Rollback and recoverability

Where AI agents can change organisational state, recoverability becomes a core governance requirement. Organisations should determine whether actions can be reversed and, where possible, establish mechanisms to restore the previous state.

Rollback is particularly valuable for reversible actions such as record changes, workflow updates or configuration modifications. Where an action is inherently irreversible, stronger pre-execution controls should apply because post-event recovery may not be possible.

The concept of recoverability should therefore influence autonomy decisions. A reversible, observable action may be suitable for greater automation than an irreversible action with significant consequences. This provides a practical connection between resilience engineering and the risk-based agent deployment framework established in Strategic Pillar 3.

The relevant question becomes:

If this agent makes a mistake, how quickly and completely can the organisation restore a safe state?

Where the answer is unclear, autonomous authority should be restricted.

9.8 Human escalation as a resilience mechanism

Human escalation should not be treated as evidence that an AI system has failed. In a resilient architecture, escalation is an intentional control mechanism.

Agents should be able to recognise conditions that exceed their authority or confidence and transfer responsibility to an appropriately qualified human. Escalation may be triggered by uncertainty, conflicting evidence, unusual behaviour, policy exceptions, material consequences or inability to verify an intended action.

Effective escalation requires more than a notification. The human recipient must receive sufficient context to make the decision efficiently, including the evidence considered by the agent, the recommendation produced, the reason for escalation and the potential consequences of the available options.

This is consistent with the distinction between superficial human involvement and meaningful human control. Escalation only functions as a control when the recipient possesses the authority, information and capability necessary to intervene.

9.9 Prompt injection and adversarial behaviour

Agentic GRC must also assume that AI systems may encounter deliberately manipulated or untrusted inputs. Prompt injection, malicious instructions embedded within documents, contaminated data and attempts to exploit tool permissions can cause agents to behave outside their intended operating boundaries. The NIST Generative AI Profile identifies the broader risks associated with the interaction between generative AI systems, their inputs, users and operating environments, reinforcing the need to consider risks beyond model performance alone (Autio et al., 2024).

The appropriate response is not to assume that improved prompting will eliminate these risks. Security and governance controls should operate independently of model reasoning wherever possible. Agents should have least-privilege permissions, constrained tools, explicit policy checks and restricted access to sensitive systems. External content should not automatically acquire the authority of organisational instructions. This reflects the broader requirement for AI systems to operate within defined governance, access, oversight and risk-management arrangements rather than relying solely on the system's ability to interpret inputs correctly (NIST, 2023; ISO/IEC, 2023).

This reinforces the importance of identity, access management and architectural separation. An agent should be able to encounter untrusted information without that information automatically gaining the ability to redefine its permissions, operating objectives or authorised actions. The distinction between information that an AI system can process and instructions that it is authorised to follow should therefore be enforced through the surrounding control architecture, including identity, permissions, policy constraints and human oversight (NIST, 2023).

The broader principle is that security boundaries must not depend solely upon the model correctly interpreting an instruction. Where an AI system can access tools, sensitive information or consequential enterprise processes, the organisation should establish independent controls that constrain what the system can access and do, even when the model encounters misleading, manipulated or adversarial content. This creates a separation between what the agent can perceive, what it can reason about and what it is authorised to execute.

9.10 Vendor and infrastructure resilience

AI-enabled GRC also inherits risks from its technology ecosystem. Organisations may depend upon cloud providers, foundation-model vendors, data providers, retrieval services and specialist GRC platforms. An outage, service degradation, commercial change or security incident affecting one provider can therefore disrupt a critical compliance capability. Enterprise risk management research highlights the importance of understanding interdependencies across organisational activities and external relationships rather than treating individual risk exposures as isolated (Bromiley et al., 2015).

Resilience requires consideration of these dependencies during architectural design. Critical processes may require alternative service paths, fallback mechanisms, data portability and appropriate contractual protections. Interoperability becomes strategically important because it can provide the flexibility to substitute, isolate or reroute components when a dependency becomes unavailable or unsuitable. Digital business strategy research similarly highlights the importance of integrating technological capabilities with organisational processes and capabilities, rather than treating technology as an isolated resource (Bharadwaj et al., 2013).

This does not mean that every organisation must maintain duplicate infrastructure for every AI component. Rather, resilience should be proportionate to criticality. Where an AI capability supports a material regulatory or operational process, the organisation should understand its dependency chain, assess the consequences of component failure and determine what happens if a key service becomes unavailable. The resulting architecture should provide an appropriate combination of redundancy, fallback, recoverability and substitution options based on the criticality and risk profile of the capability.

The objective is therefore not technological duplication for its own sake, but architectural optionality where dependency failure could materially affect organisational control. By understanding critical dependencies and designing appropriate alternatives, organisations can reduce the likelihood that the failure or strategic change of a single technology provider will compromise an essential GRC capability.

9.11 Human over-reliance as a system failure

Not all AI failure originates within the technology. Human behaviour can also become a source of systemic risk.

Users may over-trust AI recommendations, fail to challenge plausible outputs or gradually reduce independent verification as systems become familiar. This can create automation bias in which human reviewers formally remain responsible but practically defer to the machine.

Human over-reliance should therefore be treated as a control risk. Reviewers need sufficient visibility into evidence, uncertainty and system limitations to exercise meaningful judgement. Workflows should make disagreement and escalation possible rather than implicitly rewarding rapid approval.

Organisations should also monitor override patterns, approval times and reviewer behaviour. If human approval becomes almost automatic, this may indicate that the nominal human control has ceased to operate meaningfully.

The objective is not to maintain humans as passive validators of machine decisions, but to preserve an effective human–AI control relationship.

9.12 Immutable evidence and forensic recoverability

Resilience also requires the ability to reconstruct what happened after a failure. Critical agentic processes should therefore maintain robust and, where appropriate, immutable audit trails.

The evidence should establish the relevant sequence of events: what information was available, what the agent was instructed to do, what permissions it possessed, which tools it accessed, what decisions or recommendations it generated, what human approvals occurred, what actions were executed and what system state resulted.

Such evidence supports incident response, regulatory engagement, root-cause analysis and control improvement. Without it, organisations may be unable to distinguish between model failure, data failure, integration failure, permission failure or human error.

Forensic recoverability is therefore not simply an audit requirement. It is a prerequisite for organisational learning. The organisation cannot reliably improve a system if it cannot reconstruct the circumstances that produced the failure.

9.13 Learning from failure

The final component of resilient GRC is learning. A failure should not simply be contained and closed. It should generate information that improves the architecture, controls and operating model.

Post-incident analysis should determine whether the failure arose from inadequate data, inappropriate model behaviour, insufficient permissions, weak workflow design, ineffective human oversight, vendor dependency or a combination of factors. The resulting lessons should feed into system evaluation, control redesign, agent permissions, training, workflow architecture and risk assessment.

This creates a feedback loop:

Failure → evidence → diagnosis → control improvement → revalidation → renewed operation.

Such a loop is particularly important in AI environments because failure patterns may reveal weaknesses that were not apparent during initial testing. Resilience therefore becomes a mechanism for organisational learning rather than simply a mechanism for operational recovery.

9.14 Designing GRC around recoverability

The principle of designing for failure has a direct implication for agent deployment: autonomy should be proportional to recoverability.

An agent that can make a reversible change, operate within strict transaction limits and be continuously monitored may reasonably receive more authority than an agent whose actions are difficult to detect or reverse. Similarly, an agent operating within a well-understood and observable workflow may be safer than one operating across poorly integrated systems with unclear ownership.

This provides a practical test for agentic GRC:

No critical GRC agent should possess more authority than the organisation can monitor, constrain and recover.

The principle incorporates the central requirements of governed autonomy. Monitoring provides visibility. Constraint limits what the agent can do. Recovery limits the consequences when controls fail. Where any of these capabilities is materially deficient, the agent's authority should be reduced accordingly.

9.15 From fault tolerance to organisational resilience

Designing for failure ultimately extends beyond individual AI systems. GRC should be capable of maintaining critical control functions despite failures across technology, data, vendors, processes and human decision-making. This requires resilience to be considered at the level of the wider organisational control environment rather than only at the level of individual AI components.

This is increasingly important as organisations become more interconnected. A failure in a third-party data source can affect a risk assessment; the risk assessment can affect a control decision; the control decision can influence an operational process; and the operational process can create downstream exposure. Enterprise risk management research highlights the importance of understanding interactions and interdependencies among risk sources and organisational activities rather than assessing exposures in isolation (Bromiley et al., 2015). Resilience should therefore consider dependencies across the wider organisational network and the relationships through which failures can affect risk, controls and processes.

The objective is consequently not merely to create AI systems that are resistant to failure. It is to create a GRC operating environment that remains controlled when individual components fail. This requires the organisation to understand critical dependencies, establish appropriate containment and recovery mechanisms, and maintain sufficient visibility to determine how a failure affects the wider control environment.

This represents a significant shift in governance philosophy. The mature organisation does not ask whether its AI system can be guaranteed never to make an error. It asks whether an error can be detected quickly, whether its consequences can be constrained, whether the system can fail safely, whether an accountable human can intervene, whether operations can recover and whether the organisation can learn from the event. These principles are consistent with a lifecycle-oriented approach to AI risk management in which organisations monitor, assess and manage risks as systems and their operating environments evolve (NIST, 2023).

The strategic implication is therefore clear: resilience is not an additional feature of AI-enabled GRC; it is a prerequisite for trustworthy autonomy. As GRC systems become more intelligent and more capable of autonomous action, their architectures must become correspondingly more capable of containment, recovery, monitoring and adaptation. Governance must account not only for what systems are intended to do under normal conditions, but also for how they behave when information, technology, permissions, processes or human decisions deviate from expectation.

Designing GRC for failure thus completes the transition from preventive compliance towards resilient organisational control. The strongest AI-enabled GRC architecture is not one that assumes intelligent systems will always behave correctly. It is one that remains trustworthy precisely because it has been designed for the reality that they sometimes will not.

10. Strategic Pillar 7: Integrate Cybersecurity and GRC

AI-enabled GRC increasingly dissolves the traditional boundaries between cybersecurity, operational risk, regulatory compliance and enterprise architecture. As organisations deploy generative and agentic AI across increasingly consequential workflows, cybersecurity can no longer be treated as a technical function operating downstream from business and GRC decisions. Security becomes part of the architecture through which organisational authority is exercised, information is accessed, decisions are made and actions are executed.

This convergence is particularly significant because AI systems introduce new forms of organisational dependency. An AI system may retrieve sensitive information, invoke enterprise applications, interact with external services, generate recommendations or decisions, or execute transactions on behalf of employees. Consequently, the risk associated with an AI system is not determined solely by whether its outputs are accurate. It also depends on what information the system can access, what authority it possesses, which tools it can invoke, how its behaviour is monitored, and whether the organisation can intervene when its behaviour becomes unsafe. The NIST AI Risk Management Framework emphasises that AI risks should be considered within the broader system and context in which AI is designed, developed and deployed, while the NIST Generative AI Profile highlights the importance of considering risks arising from the wider sociotechnical environment rather than model performance alone (NIST, 2023; Autio et al., 2024). ISO/IEC 42001 similarly establishes organisational requirements for governing AI systems through defined responsibilities, processes and controls (ISO/IEC, 2023).

The implication is that cybersecurity and GRC should be designed as an integrated control architecture rather than as adjacent organisational disciplines. Security controls should therefore be connected to identity and access management, decision rights, workflow controls, AI governance, monitoring and assurance. This integrated perspective recognises that cybersecurity is not merely concerned with protecting technology; it also helps determine whether information, authority and actions remain within the organisation’s approved risk and control boundaries.

The proposed GRC operating model consequently treats cybersecurity as a foundational control layer that operates across the AI lifecycle and connects technical safeguards with organisational governance. The objective is to ensure that increasing AI capability does not create a corresponding expansion of uncontrolled access or authority, and that security remains embedded in the mechanisms through which AI-enabled organisational decisions and actions are governed.

10.1 From Cybersecurity as a Technical Function to Cybersecurity as a GRC Capability

Traditional GRC architectures have often treated cybersecurity as one risk domain among many. This distinction becomes increasingly difficult to sustain in AI-enabled environments. Cybersecurity controls determine whether AI systems can access data, invoke tools, interact with users and execute actions. These capabilities can directly influence compliance, operational resilience, privacy, financial risk and accountability. AI governance therefore needs to consider security within the broader system and organisational context in which AI operates rather than treating it solely as a separate technical risk category (NIST, 2023; Autio et al., 2024).

Trustworthy AI requires more than technically satisfactory outputs. It also depends upon appropriate mechanisms for accountability, transparency, oversight and trustworthiness within the organisational context in which AI systems are developed and used (Lahusen, Maggetti and Slavkovik, 2024). NIST and ISO/IEC 42001 similarly emphasise the importance of defined responsibilities, governance processes, risk management and appropriate oversight across the AI lifecycle (NIST, 2023; ISO/IEC, 2023). Security therefore forms part of the conditions under which AI can be considered governable and accountable, rather than being treated solely as a technical property of the underlying system.

This changes the GRC question from:

Is the AI system secure?

to a more consequential set of questions:

Who can use the system, what can it access, what can it do, under whose authority can it act, how can its behaviour be detected, and how can that authority be withdrawn?

These questions connect cybersecurity directly to governance and control. Identity determines authority; permissions determine capability; monitoring determines observability; policy determines acceptable behaviour; and intervention mechanisms determine whether the organisation can constrain the system when required. Together, these mechanisms establish the conditions under which AI-enabled activities can remain within approved organisational boundaries.

Cybersecurity therefore becomes an architectural property of GRC, rather than a separate technical control applied after GRC processes have been designed. The proposed operating model consequently treats security, identity, access, monitoring and intervention as interconnected components of the wider control architecture. This ensures that the organisation governs not only what an AI system produces, but also what it can access, what it is authorised to do and whether that authority can be observed, constrained and withdrawn.

10.2 Identity as the Foundation of AI Control

Identity becomes particularly important when AI agents operate within enterprise environments. Traditional access-control models are predominantly designed around human users, applications and service accounts. Agentic systems introduce an additional governance challenge: non-human entities capable of processing information, interacting with tools and potentially taking consequential actions. As AI systems become more integrated with organisational workflows, governance must therefore establish clear relationships between system identity, authority, access and accountability (NIST, 2023; ISO/IEC, 2023).

Effective AI governance requires organisations to define appropriate responsibilities, access arrangements and oversight mechanisms for AI systems throughout their lifecycle (NIST, 2023; ISO/IEC, 2023). This principle becomes particularly important when AI agents are granted operational capabilities. An agent should therefore possess an explicit and independently governable identity rather than simply inheriting unrestricted privileges from the employee or process that initiated it. The agent’s authority should be defined according to its intended purpose, the systems it needs to access and the actions it is authorised to perform.

The organisation should be able to determine:

• which agent is acting;

• which human or business process authorised the action;

• which permissions the agent possesses;

• which systems and data it can access;

• which tools it can invoke;

• what actions it has previously performed; and

• how its authority can be suspended or revoked.

These mechanisms create a direct relationship between identity governance and AI governance. An AI agent without a clearly attributable identity creates ambiguity over accountability, auditability and incident response. Conversely, an identifiable agent operating within bounded permissions can become a more controllable organisational actor, because its access, actions and authority can be monitored and governed through explicit controls.

The broader principle is therefore that identity should be treated as part of the control architecture for agentic GRC. The organisation must be able to distinguish between an agent’s technical capability and its authorised authority, establish who or what is accountable for its actions, and intervene when its permissions or behaviour no longer remain appropriate.

10.3 Zero Trust and Least-Privilege Agent Architecture

Zero-trust principles provide a useful foundation for extending cybersecurity controls into agentic GRC. Rather than assuming that an authenticated entity is inherently trustworthy, zero-trust architectures require access decisions to be evaluated according to factors such as identity, context, policy and risk. For AI agents, this principle implies that authentication should not be treated as equivalent to authorisation. An agent may be legitimate and appropriately deployed while still being prohibited from accessing particular information or executing particular actions.

Least privilege is therefore essential. Agents should receive only the minimum permissions required for the task they are performing, with privileges constrained by scope, time, context and transaction type where appropriate. This approach is consistent with the broader AI governance requirement that access, responsibilities and system capabilities should be subject to defined controls and oversight rather than determined solely by technical capability (NIST, 2023; ISO/IEC, 2023).

This principle is particularly important because the consequences of excessive permissions can be amplified by agentic behaviour. A human employee with broad access may make occasional mistakes; an AI agent operating at machine speed may reproduce an erroneous decision across hundreds or thousands of transactions. Excessive authority can therefore transform a local model or workflow error into a systemic control failure. The appropriate level of agent authority should consequently reflect the potential impact, reversibility and materiality of the actions the agent can perform.

Agent permissions should therefore be treated as GRC-controlled risk parameters, not merely as technical configuration. Permissions should be aligned with the agent’s intended purpose, organisational decision rights and risk appetite, monitored throughout its operation and capable of being modified or revoked when circumstances change. This creates a direct connection between identity, authorisation and organisational accountability, ensuring that an agent’s ability to act remains bounded by the authority the organisation has explicitly granted.

10.4 Securing the Agentic Execution Layer

The security architecture for AI-enabled GRC must extend beyond model security to the broader agentic execution environment. An agent can create risk through its interaction with APIs, enterprise applications, databases, external services and internal tools even when the underlying model itself performs as expected.

This creates several interdependent security requirements.

Secrets management is required to prevent credentials, tokens and other sensitive authentication material from being exposed through prompts, model contexts, logs or agent workflows. API security becomes critical because APIs increasingly provide the mechanism through which agents interact with enterprise systems. Application and model security must address vulnerabilities in both the AI component and the surrounding software environment. Data-loss prevention is necessary to constrain the movement of sensitive information into inappropriate destinations.

These controls should not operate independently. They should be connected to the broader GRC architecture so that security events can trigger risk assessment, escalation, control testing and assurance activities.

The resulting architecture is therefore better understood as a chain:

Identity → Permission → Context → Tool access → Action → Monitoring → Evidence → Intervention

Each link represents a potential control point. Weakness at any stage can undermine the effectiveness of the overall governance system.

10.5 Prompt Injection and Adversarial Behaviour as GRC Risks

Generative and agentic AI introduce security risks that do not map neatly onto conventional application-security models. Prompt injection is a particularly important example because malicious, misleading or otherwise untrusted instructions can influence an AI system's interpretation of context and potentially affect its subsequent behaviour. NIST's guidance on generative AI highlights the importance of managing risks arising from inputs, model behaviour, system context and downstream impacts, while the AI Risk Management Framework emphasises the need for organisations to establish appropriate governance, monitoring and risk controls across the AI lifecycle (Autio et al., 2024; NIST, 2023).

The significance of prompt injection extends beyond model behaviour. Where an AI agent has access to enterprise data or operational tools, successful manipulation can become a business control failure. An injected instruction could potentially result in inappropriate data retrieval, disclosure, workflow execution or external communication. The risk therefore depends not only on whether the model produces an incorrect response, but also on the authority and capabilities available to the system when that response is translated into action. This reinforces the broader governance requirement that AI systems should operate within clearly defined responsibilities, controls and boundaries appropriate to their intended use and potential impact (NIST, 2023; ISO/IEC, 2023).

Prompt-injection defence should therefore be integrated into the GRC control environment rather than treated solely as a model-security problem. Relevant mechanisms may include input validation, contextual separation, privilege restrictions, tool-level authorisation, output validation, behavioural monitoring, transaction controls and human escalation for high-risk actions. The precise combination of controls should reflect the nature of the use case, the sensitivity of the information involved, the capabilities exposed to the agent and the potential consequences of erroneous or unauthorised actions (NIST, 2023; Autio et al., 2024).

The underlying principle is that organisations should not rely on the model's ability to distinguish legitimate from malicious instructions as the sole security boundary. Critical controls should remain enforceable outside the probabilistic reasoning layer of the model. In practical terms, an agent may interpret an instruction, generate a recommendation or initiate a proposed action, but access permissions, policy constraints, authorisation requirements and other consequential controls should be independently enforceable by the surrounding system architecture. This creates a separation between what the model is capable of reasoning about and what the organisation permits the system to execute.

This principle is particularly important as AI systems become more agentic. ReAct-style architectures demonstrate how language models can combine reasoning with actions and interactions with external tools, illustrating why the boundary between model output and operational execution becomes increasingly significant (Yao et al., 2023). The governance implication is not that probabilistic systems should be excluded from consequential workflows, but that their capabilities should operate within explicitly governed, observable and enforceable control boundaries. Where the consequences of failure are material, authority should therefore be constrained by controls that do not depend solely on the model correctly interpreting or following instructions (NIST, 2023; ISO/IEC, 2023).

In the proposed GRC architecture, this establishes a clear separation between intelligence, authority and execution: AI may interpret and recommend, organisational governance determines what is authorised, and technical controls enforce the permitted boundaries. This separation is a core design principle for trustworthy agentic GRC and supports the broader objective of ensuring that increasing AI capability does not automatically translate into increasing organisational authority.

10.6 Agent Red Teaming and Adversarial Assurance

Conventional security testing focuses heavily on infrastructure, applications and known vulnerabilities. AI-enabled GRC requires this approach to be extended into the behavioural and agentic dimensions of the system.

Agent red teaming should therefore test not only whether an AI model can be manipulated, but whether manipulation can result in unacceptable organisational consequences. Testing should examine scenarios such as:

• attempts to bypass agent permissions;

• malicious or conflicting instructions;

• unauthorised tool invocation;

• inappropriate retrieval of confidential information;

• attempts to exfiltrate data;

• privilege escalation;

• manipulation of approval workflows;

• unsafe actions following ambiguous instructions;

• failure of escalation mechanisms; and

• attempts to induce an agent to circumvent established controls.

The objective is not simply to identify vulnerabilities. It is to determine whether the organisation's control architecture remains effective under adversarial conditions.

This connects red teaming directly to GRC assurance. Findings should feed into risk registers, control remediation, agent permissions, deployment decisions and continuous monitoring rather than remaining isolated within cybersecurity teams.

10.7 Behavioural Monitoring and Threat Intelligence

AI agents require behavioural monitoring because traditional infrastructure indicators may not adequately reveal inappropriate agent activity. Monitoring should consider both technical and organisational signals.

Relevant indicators may include unusual access patterns, unexpected tool invocation, abnormal transaction volumes, retrieval of atypical data sets, repeated policy violations, changes in agent behaviour, unexpected external communications and deviations from approved workflows.

Threat intelligence can provide additional context by identifying emerging attack patterns, vulnerabilities and adversarial techniques relevant to AI systems and their surrounding infrastructure. However, intelligence becomes valuable to GRC only when it is connected to decision and control mechanisms.

For example, a new threat pattern should be capable of triggering reassessment of relevant AI systems, modification of controls, increased monitoring, permission changes or targeted assurance activities. Cybersecurity intelligence should therefore flow into the same organisational control loop established elsewhere in the GRC architecture.

This creates a broader cycle:

Threat intelligence → Risk assessment → Control adjustment → Monitoring → Evidence → Reassessment

Cybersecurity thus becomes part of continuous organisational learning rather than a periodic compliance exercise.

10.8 Integrating Security Events with GRC Evidence and Assurance

One of the most important consequences of integrating cybersecurity with GRC is the creation of a shared evidence architecture. Security events should not remain confined to security-information systems when they have implications for compliance, operational risk, privacy, AI governance or organisational control. NIST's AI Risk Management Framework emphasises the importance of governance, documentation, monitoring and risk management across the AI lifecycle, while ISO/IEC 42001 establishes organisational processes and responsibilities for governing AI systems and their associated risks (NIST, 2023; ISO/IEC, 2023). These principles support a more integrated approach in which material security events can contribute evidence to the wider risk and control environment.

For example, an agent attempting to access unauthorised information may simultaneously represent:

• a cybersecurity event;

• a potential privacy incident;

• a control failure;

• an AI governance exception;

• an operational-risk indicator; and

• a potential regulatory-reporting issue.

A fragmented architecture may cause each function to interpret the event independently, resulting in duplicated investigation, inconsistent assessments and fragmented evidence. An integrated architecture instead allows the event to be connected across the relevant risk, control, decision and assurance structures. This is consistent with the broader enterprise risk-management principle that risks should be considered in relation to organisational objectives and performance rather than managed exclusively within isolated functional domains (COSO, 2017).

The value of integration is therefore not simply that the same event becomes visible to more functions. It is that the organisation can establish relationships between the event and the controls, risks, decisions and obligations to which it is relevant. In the proposed GRC architecture, a material security event can consequently become an input into risk reassessment, control evaluation, incident management, regulatory analysis and AI assurance without requiring each function to reconstruct the underlying evidence independently.

This reinforces the importance of provenance and traceability. Organisations should be able to reconstruct not merely what the agent did, but the broader decision and control chain surrounding the action: what data and instructions it received, which policies applied, which permissions were active, what tools were invoked, what outputs were generated, what controls were triggered, whether a human intervened and what outcome resulted. NIST emphasises documentation, transparency, accountability and ongoing risk management across the AI lifecycle, while ISO/IEC 42001 provides a management-system framework for establishing defined responsibilities, processes and controls around AI systems (NIST, 2023; ISO/IEC, 2023). For consequential AI-enabled activities, this evidence should be sufficient to support appropriate oversight and reconstruction of how the system operated within its authorised context.

Such evidence is essential for accountability, assurance and forensic investigation. It enables the organisation to distinguish between an isolated model error, a control failure, an inappropriate permission, an operational process weakness or a broader governance problem. It also creates the evidential foundation for evaluating whether controls operated as intended and for determining whether corrective action is required.

The proposed architecture therefore treats evidence not as a by-product of individual security or compliance processes, but as a shared organisational control asset. The objective is to establish a traceable chain from event → evidence → interpretation → decision → authorised action → outcome, allowing information generated in one control domain to support appropriate governance and assurance activities across the wider organisation.

10.9 Cybersecurity as a Cross-Functional Control Architecture

Integrating cybersecurity with GRC does not mean transferring responsibility for AI governance to the cybersecurity function. Rather, it requires shared ownership across business, technology, risk, compliance and security functions.

Business owners remain accountable for the risks associated with AI-enabled processes. GRC functions provide risk, regulatory and control frameworks. Cybersecurity establishes security architecture and protective mechanisms. Enterprise architecture ensures that these controls are embedded within the wider technology environment. Internal assurance functions evaluate whether the resulting system operates as intended.

The objective is therefore not organisational consolidation but architectural integration.

This distinction is important. A centralised cybersecurity function cannot compensate for poorly designed business processes, excessive agent permissions or unclear decision rights. Conversely, a strong GRC framework cannot compensate for insecure APIs, compromised credentials or inadequate monitoring. AI-enabled GRC requires these capabilities to operate as mutually reinforcing layers of the same control system.

10.10 Governing What AI Agents Can Do on Behalf of Users

The emergence of agentic AI creates a fundamental extension to traditional access governance.

Historically, organisations have primarily asked:

What can this employee do?

Agentic systems require a second question:

What can an AI system do on behalf of this employee?

The distinction is critical because the agent may operate at greater speed, scale and persistence than the human principal. Delegated authority must therefore be explicit rather than assumed.

An employee's permission to access a system should not automatically imply that an AI agent is permitted to perform every action available to that employee. Delegation should be constrained according to the purpose, context and consequence of the task. High-impact actions should require additional controls such as approval gates, transaction limits, deterministic validation or human confirmation.

This establishes an important principle for AI-enabled GRC:

Human authority should not automatically translate into unrestricted machine authority.

The agent's authority must instead be separately defined, constrained and observable.

10.11 From Security Controls to Integrated Organisational Control

The strategic objective is therefore not simply to “secure AI”. It is to create an integrated control environment in which cybersecurity mechanisms reinforce governance, risk management, compliance and operational resilience.

Such an architecture combines identity, zero trust, least privilege, secrets management, API security, adversarial testing, threat intelligence, behavioural monitoring, data-loss prevention and application security with GRC mechanisms for ownership, decision rights, escalation, evidence and assurance.

This produces a more mature conception of AI governance. Security is no longer an implementation concern that follows strategic decisions. Instead, security determines whether strategic decisions can be translated into controlled machine action.

The resulting architecture can be understood through five mutually reinforcing properties:

Authority — the organisation knows who or what is permitted to act.

Constraint — permissions and technical controls limit what can be done.

Observability — actions, decisions and interactions generate evidence.

Intervention — the organisation can interrupt or restrict unsafe behaviour.

Recoverability — the organisation can contain, reverse and learn from failures.

These properties connect cybersecurity directly to the broader organisational-control model developed throughout this chapter.

10.12 Conclusion: Cybersecurity as a Core Layer of AI-Enabled GRC

AI-enabled GRC cannot be robust if cybersecurity is treated as a downstream technical function. The deployment of intelligent and agentic systems creates a shared control problem spanning identity, data, applications, workflows, regulatory obligations and organisational authority.

The central challenge is no longer simply protecting systems from unauthorised users. Organisations must also govern machine identities, delegated authority, tool access, data movement, agent behaviour and autonomous execution.

Accordingly, cybersecurity should become a foundational layer of the GRC architecture. Zero-trust principles, least-privilege access, identity-centric security, secrets management, API protection, prompt-injection defence, agent red teaming, threat intelligence and behavioural monitoring should be integrated with risk ownership, compliance obligations, evidence, escalation and continuous assurance.

The strategic principle is therefore:

AI-enabled GRC must govern not only what people are authorised to do, but what AI systems are authorised to do on their behalf.

This represents a fundamental shift from conventional access control towards governed machine agency. As AI becomes increasingly embedded in organisational processes, cybersecurity and GRC should converge around the common objective of ensuring that machine capability remains aligned with organisational authority, risk appetite and regulatory obligations.

11. Strategic Pillar 8: Redesign the GRC Workforce

The transformation of GRC cannot be achieved through technology alone. AI may automate analysis, accelerate evidence collection and increase the scale of monitoring, but these capabilities do not eliminate the need for professional judgement. Instead, they change where judgement is required, how it is exercised and how GRC professionals interact with technology. Research on AI and management highlights the importance of understanding automation and augmentation as complementary possibilities, with the organisational impact of AI depending substantially on how tasks are allocated between humans and machines (Raisch and Krakowski, 2021).

This makes workforce redesign a strategic component of AI-enabled GRC. A transformation programme focused primarily on reducing headcount risks removing precisely the expertise required to interpret ambiguous regulatory requirements, challenge automated outputs, assess emerging risks and make consequential decisions. Effective AI governance likewise requires clearly defined roles, responsibilities and appropriate human oversight, particularly where AI systems can influence consequential organisational activities (NIST, 2023; ISO/IEC, 2023).

Evidence from generative AI research suggests that productivity gains can be significant, particularly where AI complements human capabilities rather than simply substituting for them. Experimental evidence indicates that generative AI can improve task performance and productivity in appropriate settings (Noy and Zhang, 2023), while research on generative AI in the workplace similarly demonstrates substantial productivity effects, with outcomes shaped by how AI is integrated into existing work and organisational processes (Brynjolfsson, Li and Raymond, 2025). These findings support the broader proposition that AI creates greater organisational value when its capabilities are combined with professional expertise, organisational knowledge, process maturity and human judgement, rather than treated as a standalone replacement for human work (Raisch and Krakowski, 2021).

The strategic question is therefore not:

How many GRC roles can AI eliminate?

It is:

How should GRC work be redistributed between people, deterministic automation and AI systems so that the organisation achieves greater assurance, better decisions and stronger control?

This distinction is fundamental. Workforce transformation should be understood as work redesign, not simply workforce reduction. The objective is to determine which activities should be automated, which should be augmented by AI, which require professional judgement and which should remain subject to explicit human authority. Such redesign should also consider accountability, decision rights, escalation mechanisms and the consequences of error, ensuring that increased technological capability does not result in inappropriate delegation of organisational responsibility (NIST, 2023; ISO/IEC, 2023).

The resulting workforce model is therefore not one in which AI simply replaces GRC professionals, but one in which routine cognitive and administrative activities are increasingly automated while human expertise is concentrated on interpretation, challenge, judgement, accountability and consequential decision-making. This represents a shift from managing a workforce around individual tasks towards designing a human–AI control system around the outcomes and decisions the organisation must govern.

11.1 From Headcount Reduction to Human–AI Complementarity

The most immediate risk in AI-enabled workforce transformation is to equate automation with substitution. This approach assumes that if AI can perform a task previously undertaken by a GRC professional, the corresponding human capacity can simply be removed.

Such reasoning overlooks the difference between performing an activity and understanding its significance.

AI may be capable of reviewing thousands of documents, identifying unusual transactions, comparing policies against regulations or summarising control evidence. Yet the interpretation of an ambiguous regulatory requirement, the assessment of competing risks or the decision to accept residual risk may require contextual understanding that cannot be reduced to pattern recognition alone.

The appropriate objective is therefore human–AI complementarity. AI should absorb high-volume, repetitive and information-intensive activities where machine processing creates scale and consistency. Human professionals should increasingly concentrate on activities involving ambiguity, materiality, accountability, stakeholder negotiation and consequential judgement.

This creates a new division of labour:

AI → scale, speed, pattern recognition and continuous monitoring

Humans → judgement, challenge, interpretation, accountability and decision-making

The boundary will not remain static. As AI capabilities mature, some tasks will move towards greater automation, while emerging risks will create new areas requiring human expertise. Workforce design must therefore remain adaptive rather than treating today's task allocation as permanent.

11.2 Decomposing GRC Work into Human and Machine Activities

Effective workforce transformation begins with decomposition of GRC processes into their constituent activities.

A conventional compliance process, for example, may contain data collection, evidence retrieval, control testing, exception identification, regulatory interpretation, stakeholder communication, remediation design and management approval. These activities have different degrees of suitability for automation.

AI and deterministic automation are particularly well suited to activities that are repetitive, rules-constrained, information-intensive and objectively verifiable. Human involvement becomes increasingly important where the activity requires contextual interpretation, negotiation, ethical judgement or acceptance of material uncertainty.

This suggests that organisations should redesign GRC jobs around activity portfolios rather than historical job descriptions.

A compliance analyst, for example, may previously have spent substantial time collecting evidence and maintaining spreadsheets. If these activities become automated, the role should not simply disappear. Its centre of gravity can move towards investigating exceptions, challenging control owners, interpreting regulatory developments and advising business leaders.

The result is a more valuable use of professional capacity.

AI therefore changes not only how efficiently work is performed, but which work is economically and organisationally worth performing.

11.3 Preserving and Elevating Traditional GRC Expertise

Workforce transformation should not be interpreted as a rejection of traditional GRC competencies. Regulation, risk management, audit, controls, compliance and governance remain foundational.

Indeed, the increasing use of AI may make these capabilities more important because professionals must be able to determine whether an AI-enabled process remains consistent with regulatory and organisational requirements.

A technically sophisticated AI system does not independently determine whether an organisation's risk appetite is appropriate, whether a regulatory interpretation is defensible or whether a control failure is sufficiently material to require escalation.

Traditional GRC expertise therefore becomes the domain foundation upon which AI-enabled capability is built.

The transformation challenge is to combine this expertise with new technological and analytical competencies rather than replacing one competency set with another.

11.4 The Emerging GRC Competency Model

The future GRC professional requires a broader and more interdisciplinary competency profile. As AI becomes embedded in risk, compliance and control processes, traditional regulatory and risk-management capabilities need to be complemented by sufficient understanding of data, technology, AI systems and organisational processes. This does not imply that every GRC professional must become a technical specialist. Rather, professionals need sufficient technological and analytical understanding to challenge AI-enabled processes, interpret their outputs and exercise informed judgement over their use (NIST, 2023; ISO/IEC, 2023).

Traditional capabilities should therefore be complemented by data literacy, enabling professionals to understand data provenance, quality, lineage, uncertainty and interpretation. AI literacy becomes necessary to understand model capabilities, limitations, failure modes and appropriate use. Process engineering allows professionals to redesign workflows rather than merely automate existing procedures. These capabilities are increasingly important because effective AI governance depends not only on model performance but also on the quality of the data, processes, responsibilities and controls surrounding the system (NIST, 2023; ISO/IEC, 2023).

Systems thinking becomes particularly important because GRC risks increasingly arise from interactions among data, models, applications, people, suppliers and business processes rather than from isolated control failures. Enterprise risk management research emphasises the importance of understanding risk in an integrated organisational context, including the relationships and interdependencies among different sources of risk (Bromiley et al., 2015). GRC professionals therefore need to understand not only individual controls or risk categories, but also how changes in one part of an organisational system can affect risks, controls, processes and decisions elsewhere.

Professionals also require sufficient model-risk understanding to evaluate uncertainty, validation requirements and the potential consequences of model error. Prompt and context engineering becomes relevant where GRC professionals are responsible for designing reliable interactions between AI systems and organisational knowledge, although these capabilities should be accompanied by appropriate governance controls rather than treated as substitutes for them. Agent supervision becomes increasingly important as AI systems acquire greater ability to interact with tools, initiate workflows and perform tasks. Governance frameworks such as NIST AI RMF and ISO/IEC 42001 reinforce the importance of clearly defined responsibilities, oversight and risk management as AI systems are incorporated into organisational processes (NIST, 2023; ISO/IEC, 2023).

These capabilities should be supplemented by analytics, technology risk, scenario analysis and the ability to interpret complex system behaviour. The objective is not to turn GRC professionals into data scientists, software engineers or cybersecurity specialists, but to ensure that they possess sufficient cross-disciplinary competence to operate effectively at the intersection of regulation, risk, technology, data and organisational decision-making.

The resulting professional profile is therefore hybrid: neither purely regulatory nor purely technical. The future GRC professional is increasingly a translator and integrator between these domains, combining regulatory judgement with data and AI literacy, process understanding, systems thinking and the ability to govern technology-enabled decisions. This represents a shift from the traditional GRC role of assessing and reporting on controls towards actively designing, challenging and governing the human–AI systems through which organisational control is exercised.

11.5 From Control Administration to Control Architecture

One of the most significant workforce changes concerns the nature of GRC work itself. Traditional GRC functions often devote substantial capacity to administering controls: requesting evidence, updating registers, tracking remediation actions, performing recurring assessments and preparing reports. As these activities become increasingly automated, the value of the professional shifts towards control architecture—designing the way risks, controls, processes, technology and human judgement interact to produce effective organisational control.

A control architect asks different questions:

• What risk is the control intended to address?

• Where should the control operate within the workflow?

• Which elements can be automated deterministically?

• Where can AI add contextual intelligence?

• Where must human judgement remain mandatory?

• What evidence should the process generate?

• What events should trigger escalation?

• How can the control be tested continuously?

• How can the organisation demonstrate that the control remains effective?

This represents a movement from administering controls to engineering control systems. The distinction is important because automation can make a poorly designed control operate faster without making it more effective. Enterprise risk management frameworks emphasise the integration of risk with organisational objectives and performance, reinforcing the importance of designing controls in relation to the activities and decisions they are intended to govern rather than treating them as isolated administrative mechanisms (COSO, 2017).

The shift also reflects the broader principle that technological capabilities create greater organisational value when they are integrated with business processes and complementary organisational capabilities rather than simply layered onto existing activities (Bharadwaj et al., 2013). Similarly, the automation–augmentation perspective suggests that organisations should deliberately determine which activities should be automated and where human expertise remains important, rather than assuming that increased automation should simply replace existing work (Raisch and Krakowski, 2021).

Workforce transformation should therefore increase the proportion of GRC capacity dedicated to control design, process architecture, decision-rights design, continuous assurance and control improvement, rather than simply accelerating administrative activities. The future GRC professional consequently becomes not only an administrator or assessor of controls, but an engineer of the organisational control system—responsible for determining how intelligence, automation, human judgement, evidence and authority are combined to produce reliable and demonstrable outcomes.

11.6 The GRC Professional as Risk Interpreter

AI can process information at a scale that exceeds human capacity. Its greatest value may therefore be in expanding the information available to GRC professionals rather than eliminating their role.

The professional increasingly becomes a risk interpreter.

This role involves translating machine-generated signals into organisational meaning. An AI system may identify an unusual supplier pattern, detect a regulatory change or identify a potential control deviation. The GRC professional must determine whether the signal represents a genuine risk, how material it is, what contextual factors matter and what response is proportionate.

This requires domain expertise combined with analytical capability.

The distinction between detection and interpretation is therefore important. AI can increase the organisation's ability to detect potential issues; human professionals remain essential to determine what those signals mean in context.

As GRC becomes more continuous, the volume of machine-generated signals will increase. The professional challenge will consequently shift from finding information to distinguishing meaningful risk from informational noise.

11.7 The GRC Professional as Decision Adviser

The next evolution is from risk interpretation towards decision support.

GRC functions have historically been associated with identifying risks, assessing compliance and evaluating the effectiveness of controls. In an AI-enabled organisation, they can increasingly contribute to business decision-making by combining regulatory intelligence, risk information, control performance and scenario analysis. This is consistent with the enterprise risk-management principle that risk should be considered in relation to organisational strategy, objectives and performance rather than treated as a separate compliance activity (COSO, 2017).

This does not mean that GRC should become the decision-maker for the business. Rather, its role becomes to improve the quality of decisions by making risk and control implications visible at the point where decisions are made. The objective is to provide decision-makers with relevant evidence, assumptions, constraints and potential consequences while preserving appropriate organisational decision rights and accountability. This distinction is also consistent with the broader automation–augmentation perspective, in which AI and analytical capabilities can support human decision-making without necessarily replacing the human responsibility for consequential judgements (Raisch and Krakowski, 2021).

The transition also depends upon integrating GRC capabilities with the business processes in which decisions actually occur. Digital business strategy research emphasises that technological capabilities generate organisational value when they are combined with business processes and complementary organisational capabilities rather than operated as isolated resources (Bharadwaj et al., 2013). For GRC, this means moving beyond producing risk assessments or compliance reports towards providing decision-relevant intelligence within the workflows where business choices are evaluated and executed.

A mature GRC professional should therefore be capable of answering not only:

Is this activity compliant?

but also:

What are the risk implications of this decision, what assumptions underpin the analysis, what controls constrain the downside, and what would cause us to reconsider the decision?

This represents a shift from reporting on risk towards enabling informed organisational judgement. It requires GRC professionals to understand not only regulatory requirements and control effectiveness, but also the business context in which decisions are made, the assumptions underlying analytical assessments and the mechanisms through which risks can be constrained or escalated.

The resulting role is considerably more strategic. GRC becomes a decision-support capability that connects regulatory and risk intelligence with organisational choices, while preserving the distinction between informing a decision and owning the decision. In this model, GRC strengthens organisational decision quality by making risk, control and uncertainty visible at the appropriate point of decision-making, while accountability for the resulting business decision remains with the authorised decision-maker.

11.8 The GRC Professional as AI Supervisor

The emergence of agentic AI creates another new responsibility: supervision of machine activity.

AI supervision should not be reduced to checking whether an output “looks right”. It should involve understanding whether the AI system is operating within its authorised scope, following applicable policies and controls, and producing behaviour consistent with its intended organisational purpose. This becomes increasingly important as AI systems move beyond generating recommendations and begin interacting with external tools and operational workflows (Yao et al., 2023).

The GRC professional may therefore need to monitor:

• whether agents remain within approved permissions;

• whether outputs conform to relevant policies;

• whether exceptions are being escalated appropriately;

• whether human approval requirements are functioning;

• whether the evidence trail remains complete;

• whether model or workflow changes alter the risk profile; and

• whether observed behaviour remains consistent with intended organisational outcomes.

These responsibilities extend conventional GRC oversight from assessing whether controls exist towards observing whether AI-enabled processes continue to operate within their intended governance boundaries. NIST emphasises the importance of ongoing risk management, monitoring, defined roles and responsibilities across the AI lifecycle, while ISO/IEC 42001 establishes a management-system approach involving organisational responsibilities, monitoring and continual improvement (NIST, 2023; ISO/IEC, 2023).

This is particularly important where agents can execute actions rather than merely generate recommendations. Agentic systems that combine reasoning with interaction and action introduce a closer relationship between AI output and operational execution (Yao et al., 2023). The organisation must therefore govern not only what an AI system produces, but also what it is authorised to do, under what conditions, with which permissions and subject to which controls. Increasing technical capability should not automatically result in increasing operational authority.

The GRC professional consequently becomes part of the organisational mechanism through which AI autonomy is supervised, evidenced and constrained. This represents an important evolution of the GRC role: from assessing controls applied to human-operated processes towards continuously overseeing the behaviour of human–AI systems and verifying that machine activity remains aligned with organisational policies, decision rights and control requirements.

11.9 Building Multidisciplinary GRC Teams

The competency transformation cannot be achieved entirely through retraining existing professionals. Some capabilities will require collaboration across traditionally separate disciplines.

Future GRC operating models are therefore likely to involve combinations of regulatory specialists, risk professionals, auditors, data specialists, AI practitioners, cybersecurity professionals, process engineers and technology-risk experts.

The objective should not be to make every GRC professional an expert in every technical domain. That would be neither realistic nor necessary. Instead, organisations should create T-shaped capability: deep expertise in one or more GRC domains combined with sufficient cross-disciplinary understanding to collaborate effectively across the AI-enabled control environment.

For example, a regulatory specialist does not need to become a machine-learning engineer. However, that specialist should understand enough about model limitations, retrieval, data provenance and AI workflows to identify where regulatory interpretation could be affected by system behaviour.

Similarly, an AI specialist should understand enough about regulatory obligations, control principles and organisational accountability to design systems that can operate safely within the GRC environment.

This interdisciplinary capability becomes particularly important because many AI risks occur at the interfaces between disciplines.

11.10 Learning, Reskilling and Professional Adaptation

Workforce transformation therefore requires an explicit capability-development strategy.

AI literacy should become a baseline capability across GRC functions, while more advanced skills should be developed according to role. Training should extend beyond generic awareness programmes to practical understanding of how AI affects evidence, controls, workflows, risk assessment and assurance.

Reskilling should focus particularly on the activities most likely to be transformed by automation. Professionals whose roles are heavily concentrated on evidence collection, recurring reporting or manual control administration should be supported in moving towards analytical, investigative, advisory and architectural responsibilities.

This is important for organisational adoption. Employees are more likely to engage constructively with AI when transformation is presented as an opportunity to increase professional impact rather than simply as a mechanism for removing roles.

At the same time, organisations should avoid assuming that every employee will naturally adapt to AI-enabled work. Workforce transformation requires investment in training, role redesign, performance measures and career pathways.

The strategic objective should be to increase the proportion of human capacity devoted to high-value judgement and organisational learning.

11.11 Measuring the Value of the GRC Workforce Differently

If AI transformation is evaluated primarily through headcount reduction, organisations may unintentionally optimise for the wrong outcome.

GRC performance should instead be assessed through measures such as:

• time required to identify material risk;

• quality and timeliness of management decisions;

• proportion of controls operating continuously;

• time required to investigate exceptions;

• quality of regulatory interpretation;

• effectiveness of human escalation;

• coverage of AI-enabled processes;

• quality and completeness of evidence;

• reduction in avoidable manual activity; and

• professional capacity redirected towards higher-value work.

These measures better reflect the strategic contribution of an AI-enabled GRC function. The goal is not necessarily to maximise the number of tasks performed without humans. It is to maximise organisational assurance and decision quality per unit of GRC capacity.

11.12 From GRC Roles to a Human–AI Control System

The workforce implications of AI ultimately extend beyond individual competencies. They require the organisation to redesign the relationship between people and intelligent systems.

AI systems increasingly perform sensing, analysis, classification, prediction, drafting and—in bounded circumstances—execution. Humans provide contextual judgement, accountability, challenge, escalation and decisions involving material consequences.

This can be understood as a human–AI control system rather than a collection of isolated roles.

Within such a system, humans define objectives and constraints; AI systems process information and identify patterns; deterministic controls enforce defined boundaries; human professionals interpret exceptions; and accountable decision-makers intervene where consequences exceed the authority delegated to machines.

The workforce therefore becomes part of the architecture of control.

This reinforces the central proposition of this chapter: AI transformation should not seek to remove humans from GRC. It should redesign where humans add value.

11.13 Conclusion: From Control Administrator to Risk Architect

The future GRC professional is unlikely to resemble the traditional control administrator. As AI automates evidence collection, monitoring, analysis and other repetitive activities, professional value increasingly shifts towards interpretation, challenge, architecture, supervision and strategic advice.

The emerging GRC role can therefore be understood through four complementary identities:

Risk interpreter — translating complex data and AI-generated signals into meaningful organisational risk.

Decision adviser — integrating risk, regulatory and control intelligence into business decisions.

Control architect — designing workflows and control environments in which automation and AI operate within defined boundaries.

AI supervisor — ensuring that intelligent systems remain observable, appropriately authorised and subject to meaningful human intervention.

This does not diminish the importance of traditional GRC expertise. It makes that expertise more consequential because regulatory knowledge, risk judgement and control principles provide the context within which AI must operate.

The strategic principle is therefore:

The objective of AI-enabled GRC is not to replace professional judgement, but to redeploy it towards the decisions, exceptions and control architectures where it creates the greatest organisational value.

Workforce redesign consequently becomes a prerequisite for successful GRC transformation. Organisations that combine domain expertise with data literacy, AI literacy, process engineering, systems thinking, cybersecurity awareness and agent supervision will be better positioned to convert AI capability into sustainable assurance and decision advantage. Those that treat AI primarily as a headcount-reduction mechanism risk achieving short-term efficiency while weakening the very judgement and organisational knowledge required to govern increasingly autonomous systems.

12. Strategic Pillar 9: Transform Third-Party and Ecosystem Governance

The expansion of AI-enabled and agentic systems fundamentally changes the organisation's relationship with third parties. Traditional technology procurement has often assumed that an organisation can evaluate a supplier, establish contractual requirements, perform periodic due diligence and monitor service performance over time. This model becomes increasingly challenging when critical organisational capabilities depend upon rapidly evolving foundation models, cloud infrastructure, data providers, software-as-a-service platforms, APIs and specialist AI agents.

AI therefore transforms third-party risk from a relatively discrete supplier-management problem into a broader ecosystem-governance challenge. Enterprise risk management research highlights the importance of understanding risk across organisational boundaries and recognising interactions and interdependencies among different sources of exposure (Bromiley et al., 2015). In AI-enabled environments, these interdependencies can extend across multiple technology, data and service providers that collectively contribute to a single organisational capability.

The organisation may not contract directly with every component involved in an AI-enabled process. A single application may depend upon a foundation model provider, cloud infrastructure provider, external data source, API service and downstream subcontractors. Changes introduced by any of these participants may alter the risk, compliance, security or operational characteristics of the overall system. The resulting exposure is therefore not necessarily attributable to a single supplier; it can arise from the configuration and interaction of multiple dependencies.

This creates a fundamental GRC challenge: the organisation must govern dependencies that it does not fully own and may not fully control. Effective AI governance consequently requires organisations to understand the systems, services and dependencies that contribute to AI-enabled activities and to establish appropriate responsibilities, risk controls and monitoring arrangements around them (NIST, 2023; ISO/IEC, 2023).

The objective of third-party governance should therefore extend beyond supplier selection and periodic due diligence towards maintaining visibility of material dependencies, assessing changes in their risk significance and establishing mechanisms for proportionate oversight and intervention. Where dependencies are critical to organisational control, governance should also consider the consequences of provider failure, material service changes, changes in underlying models or data, and the organisation's ability to respond when a dependency no longer meets its requirements (Bromiley et al., 2015; NIST, 2023).

This leads to the strategic objective of controlled optionality. Organisations should avoid unnecessary dependence on individual providers where such dependence could materially constrain their ability to maintain effective control. Where appropriate, this may involve alternative service paths, interoperable interfaces, data portability, contractual protections, contingency arrangements or the ability to substitute or isolate individual components. The purpose is not to eliminate third-party dependence—often neither feasible nor desirable—but to ensure that critical dependencies remain visible, governable and replaceable where necessary.

Controlled optionality therefore becomes an important dimension of resilient ecosystem governance. The strategic objective is not simply to select the best supplier at a point in time, but to preserve sufficient architectural and organisational flexibility to maintain control as the technology ecosystem evolves.

12.1 From Vendor Management to Ecosystem Governance

Traditional third-party risk management is generally organised around the supplier as the unit of analysis. A supplier is assessed, classified according to risk, subjected to due diligence and monitored according to its risk tier. This remains necessary, but it is increasingly insufficient for AI-enabled environments in which organisational capabilities may depend upon multiple interconnected technologies, services and providers.

The relevant unit of analysis is therefore increasingly the technology ecosystem rather than the individual vendor. An AI-enabled business process may depend upon multiple interconnected services, each contributing a different element of functionality, data, infrastructure or decision capability. Enterprise risk management research highlights the importance of understanding relationships and interdependencies among different sources of organisational risk rather than treating exposures as entirely independent (Bromiley et al., 2015).

For example, an AI compliance workflow might depend upon:

• a foundation model;

• cloud infrastructure;

• an external regulatory-data provider;

• an identity service;

• an API gateway;

• a workflow platform;

• an AI agent framework; and

• specialised third-party applications.

A weakness, failure or material change in one component may therefore affect the control environment of the entire workflow. The risk cannot necessarily be understood by assessing each provider independently because the organisation's exposure also depends upon how the components interact, what functions they perform and how their dependencies combine within the wider business process. NIST's AI Risk Management Framework similarly emphasises understanding AI systems within their broader context, including the characteristics of the system, its intended use, associated risks and the organisational processes through which those risks are managed (NIST, 2023).

This creates a shift in the object of GRC analysis: from asking “How risky is this supplier?” towards asking “What dependencies does this business capability rely upon, how are those dependencies connected, and what happens to the control environment if one of them changes or fails?”

Third-party governance must therefore evolve from supplier-centric assessment towards dependency-aware ecosystem governance. This does not eliminate supplier-level due diligence; rather, it places that assessment within a broader understanding of the technology ecosystem in which the supplier operates. The objective is to identify material dependencies, understand their relationships to critical processes and controls, monitor changes that could alter the risk profile, and ensure that the organisation retains appropriate visibility and governance over the resulting dependency network.

The implication is that the supplier is no longer always the most meaningful unit of GRC analysis. For AI-enabled processes, the more relevant unit may be the combination of the business capability, its technology dependencies and the control relationships connecting them. This provides the foundation for a more resilient form of third-party governance in which organisational risk is assessed not only at the level of individual entities, but also at the level of the ecosystem through which critical activities are delivered.

12.2 The New AI Dependency Chain

AI introduces a distinctive dependency structure because technology providers can influence not only infrastructure availability but also the behaviour and characteristics of the AI system itself.

A provider may change a model, alter its training or inference infrastructure, modify content filters, change an API, introduce new subcontractors, relocate data processing or retire a service. These changes may occur without the organisation redesigning its own business process.

This creates a form of indirect change risk.

The organisation may believe that its GRC process remains stable because its internal workflow has not changed, while the underlying AI dependency has materially changed.

Consequently, third-party governance should establish visibility across the dependency chain:

Business process → AI application → agent → model → data → cloud → infrastructure → subcontractors

Each layer can introduce risk and each may require different forms of assurance.

This means that vendor governance cannot be limited to the organisation's immediate contractual counterparty. It must also consider fourth-party and ecosystem dependencies where these materially affect risk.

12.3 From Point-in-Time Due Diligence to Continuous Supplier Assurance

Traditional supplier due diligence is commonly performed at onboarding and repeated periodically. This approach assumes that the supplier's risk profile remains sufficiently stable between assessments.

AI challenges this assumption.

Models, APIs, data sources, security controls, infrastructure configurations and subcontracting arrangements can change rapidly. A supplier that was considered acceptable at onboarding may therefore have a materially different risk profile months later.

Third-party assurance should consequently become more continuous and event-driven.

Relevant triggers may include:

• major model changes;

• changes in data-processing locations;

• material security incidents;

• new subcontractors;

• regulatory developments;

• significant service outages;

• changes in model performance;

• changes to API functionality;

• ownership changes;

• material concentration exposure; and

• changes in contractual or licensing terms.

The objective is not to conduct exhaustive reassessment every time a minor change occurs. Rather, organisations should establish risk-based change triggers that determine when supplier assurance must be revisited.

This aligns third-party governance with the continuous assurance model developed earlier in this chapter.

12.4 Data Location, Provenance and Jurisdictional Risk

Data location becomes particularly significant in AI-enabled ecosystems because sensitive organisational information may move through multiple technical environments.

Third-party assessment should therefore establish where data is:

• stored;

• processed;

• transmitted;

• replicated;

• backed up; and

• potentially exposed to subcontractors.

Data location should also be considered alongside data provenance. Organisations need sufficient visibility to determine where critical information originated, how it was transformed and which external services have processed it.

These considerations are particularly important where regulatory requirements impose restrictions on data transfer, confidentiality, privacy or operational resilience.

The relevant GRC question is therefore broader than whether a supplier has an acceptable privacy policy. It becomes:

Can the organisation demonstrate where sensitive information travels through the AI ecosystem, under what legal and contractual conditions, and with what controls?

This is fundamentally a traceability requirement.

12.5 Model Provenance and Model-Change Governance

Foundation models introduce another dimension of third-party risk: model provenance.

An organisation may rely on a model without having visibility into every characteristic of the underlying model development process. Questions may arise concerning training data, model versions, safety controls, evaluation methods, performance characteristics and subsequent modifications.

The issue becomes particularly significant where model behaviour affects regulated or high-impact processes.

Third-party governance should therefore consider not only whether a provider supplies a model, but how model changes are governed. Relevant questions include:

• How are model versions identified?

• How are material changes communicated?

• What testing accompanies major updates?

• Can the organisation remain on a previous model version?

• What performance guarantees or service commitments exist?

• What evidence is available concerning testing and assurance?

• Can changes trigger customer-side validation?

Model-change governance is important because a provider's update can effectively alter an organisation's control environment without a corresponding internal software release.

The supplier's change-management process therefore becomes part of the organisation's own GRC architecture.

12.6 Concentration Risk and Systemic Dependency

AI ecosystems can create significant concentration risk. A relatively small number of providers may supply critical foundation models, cloud infrastructure, data services or AI platforms to a large number of organisations. This creates a potential mismatch between conventional organisational risk assessments and the systemic significance of shared dependencies.

A supplier may be financially stable and technically sophisticated while still representing a significant concentration risk because the organisation has no practical alternative if that service becomes unavailable. The relevant question is therefore not only whether an individual supplier is reliable, but also how dependent the organisation has become upon that supplier and what consequences would follow from disruption, deterioration or loss of the service. Enterprise risk management research highlights the importance of understanding risk in relation to interconnected exposures and organisational dependencies rather than assessing individual risks entirely in isolation (Bromiley et al., 2015).

Concentration should therefore be assessed across dimensions such as:

• critical business processes;

• geographic dependency;

• technology stack;

• data services;

• foundation models;

• cloud infrastructure;

• specialised AI capabilities; and

• common underlying providers shared across multiple systems.

This assessment should consider both direct and indirect dependencies. An organisation may appear to have multiple suppliers while still being exposed to a common underlying provider, infrastructure platform, data source or technology component. Similarly, several apparently independent AI applications may depend upon the same foundation model or cloud environment. Such relationships can create correlated exposures that are not visible when third-party risk is assessed solely at the individual supplier level.

The implication is that third-party risk management must consider not only the quality and resilience of individual suppliers, but also the structure of organisational dependency. NIST's AI Risk Management Framework reinforces the importance of considering AI systems within their broader organisational and operational context and managing risks throughout their lifecycle (NIST, 2023).

This shifts third-party risk from supplier quality towards dependency structure. The strategic objective is not necessarily to eliminate concentration—some levels of concentration may be economically or technically unavoidable—but to make material dependencies visible, understand their potential consequences and establish appropriate mitigation, contingency or substitution mechanisms where concentration could materially affect organisational control.

In this context, optionality becomes a resilience capability. Where a dependency is critical and difficult to replace, the organisation should understand that constraint explicitly and determine whether alternative providers, architectural flexibility, contingency arrangements or other mitigating controls are required. The objective is to ensure that supplier dependence does not become an unmanaged constraint on the organisation's ability to maintain effective risk management and control.

12.7 Interoperability as a Governance Requirement

Interoperability is often treated primarily as an architectural or procurement consideration. In AI-enabled GRC, it becomes a governance mechanism.

If an organisation cannot move data, prompts, workflows, models or agent configurations between providers, its ability to respond to changing risk conditions is constrained.

Vendor lock-in can therefore become a governance problem.

Interoperability should consequently be considered during procurement rather than after implementation. Organisations should evaluate the portability of:

• data;

• metadata;

• workflows;

• prompts and context configurations;

• model interfaces;

• agent definitions;

• audit records;

• control evidence; and

• integration configurations.

The objective is not necessarily to maintain complete technical portability across every component. That may be economically impractical. The objective is to preserve strategic exit options for material dependencies.

This is why architectural optionality and GRC are increasingly connected.

12.8 Exit Capability as a GRC Control

A supplier exit plan should not be regarded merely as a contingency document. For critical AI dependencies, exit capability is itself a control.

An organisation should be able to determine:

• how quickly a critical service could be replaced;

• what data would need to be migrated;

• whether historical evidence would remain accessible;

• how business processes would operate during transition;

• whether an alternative provider exists;

• what contractual restrictions could impede migration; and

• whether the organisation retains sufficient internal capability to manage the transition.

This becomes particularly important for agentic systems because the dependency may extend beyond a single application. An agent may rely on specific model APIs, tools, prompts, data structures and workflow integrations.

Replacing the underlying provider may therefore require substantial architectural change.

Exit capability should consequently be assessed during system design and procurement, not discovered during a crisis.

The principle is straightforward:

A dependency that cannot realistically be exited should be treated as a strategic risk, not merely as a procurement relationship.

12.9 Contracting for AI Governance

Contracts remain a critical mechanism through which organisations extend GRC requirements into the external ecosystem.

AI-related supplier contracts should address issues including:

• security requirements;

• regulatory compliance;

• audit and assurance rights;

• data processing and location;

• subcontractor disclosure;

• model-change notification;

• incident notification;

• service continuity;

• performance commitments;

• intellectual-property rights;

• data retention and deletion;

• evidence availability; and

• termination and transition assistance.

However, contractual language alone does not create effective control.

A contractual requirement is meaningful only when the organisation can monitor whether the requirement is being satisfied and has mechanisms for remediation when it is not.

This reinforces the broader distinction developed throughout this chapter between governance on paper and operational control. Supplier contracts should therefore be connected to evidence collection, monitoring, assurance and escalation mechanisms.

12.10 Intellectual Property and Data Rights

AI ecosystems also introduce complex questions concerning intellectual property and data rights.

Organisations need clarity over how their data is processed, retained and potentially used by providers. They must also understand the contractual treatment of AI-generated outputs and the extent to which proprietary information may enter model-training or improvement processes.

These issues cannot be separated from broader GRC considerations because intellectual-property exposure can create legal, financial, competitive and reputational risk.

Third-party assessment should therefore examine not simply whether data is technically protected, but what rights the provider receives over organisational information and outputs.

This is particularly important for organisations whose competitive advantage depends upon proprietary data, processes or knowledge.

12.11 Security and Operational Resilience Across the Ecosystem

Third-party governance must also connect directly with cybersecurity and operational resilience.

A critical AI provider can become a single point of failure for an otherwise resilient internal architecture. An outage, cyberattack, API disruption or provider-side configuration change may interrupt multiple business processes simultaneously.

This makes supplier resilience part of organisational resilience.

Assessment should therefore consider:

• provider redundancy;

• recovery capabilities;

• service-level commitments;

• incident response;

• geographic resilience;

• infrastructure concentration;

• dependency on common cloud providers;

• disaster-recovery arrangements; and

• continuity of critical AI-enabled workflows.

Importantly, resilience should be tested rather than assumed. Organisations should periodically evaluate how critical processes would operate if a major AI dependency became unavailable.

This connects third-party governance with the failure-oriented GRC architecture developed earlier: organisations should assume that important dependencies will occasionally fail and design for controlled degradation and recovery.

12.12 Moving from Vendor Risk Scores to Dependency Intelligence

Traditional third-party risk management frequently compresses complex supplier information into a risk rating. Although useful for prioritisation, a single score can obscure the structure, significance and interconnectedness of the underlying dependency. Two suppliers with the same risk rating may create very different organisational exposures depending on the number of critical processes, systems and controls that rely upon them.

AI-enabled GRC therefore requires richer dependency intelligence.

The organisation should be able to understand not only that Vendor A represents “high risk”, but:

• which business processes depend upon Vendor A;

• which AI systems depend upon it;

• which other providers depend upon the same infrastructure;

• which regulatory obligations could be affected by disruption;

• which alternative providers exist;

• how quickly the dependency could be replaced; and

• what consequences would result from failure.

This shifts the focus from assessing a supplier in isolation towards understanding the role that the supplier plays within the wider organisational control environment. Enterprise risk management research highlights the importance of understanding relationships and interdependencies among sources of risk, while knowledge graphs provide a means of representing entities and the relationships connecting them (Bromiley et al., 2015; Hogan et al., 2021).

Knowledge graphs and relationship-based GRC architectures can therefore support this form of analysis by representing connections between vendors, applications, models, data, controls, business processes and regulatory obligations (Hogan et al., 2021). In the proposed GRC architecture, these relationships can be used to connect supplier information with the organisational processes and control structures that depend upon it, creating a richer representation of exposure than a conventional supplier register or risk score.

This represents a shift from vendor inventories towards dependency maps.

Such maps can help GRC teams identify hidden concentration, shared infrastructure, cascading dependencies and control weaknesses that conventional supplier registers may not reveal. They can also support impact analysis by allowing the organisation to trace how a change or failure affecting one dependency may intersect with critical business processes, AI systems, controls and regulatory obligations.

The strategic value of dependency intelligence therefore lies not simply in knowing which suppliers are risky, but in understanding why a dependency matters, what depends upon it, how its failure could affect the organisation, and what options exist to manage that exposure. This provides a stronger foundation for risk-based monitoring, resilience planning, assurance and third-party governance.

12.13 Controlled Optionality as a Strategic Capability

The ultimate objective of ecosystem governance is not to eliminate third-party dependency. Modern organisations cannot realistically operate without extensive external technology ecosystems.

The objective is to ensure that dependencies remain deliberate, visible and governable.

Controlled optionality means maintaining sufficient flexibility to change suppliers, architectures or service configurations when risk, cost, regulation or strategic requirements change.

This requires a combination of:

• interoperable architectures;

• portable data;

• clear contractual rights;

• documented dependencies;

• alternative suppliers where economically justified;

• internal architectural knowledge;

• tested exit strategies; and

• continuous monitoring of concentration risk.

Optionality therefore has both a technical and organisational dimension. An organisation may have multiple suppliers available in theory while remaining effectively locked into one provider because its data, workflows, integrations and organisational expertise have become dependent upon that provider.

True optionality exists only when the organisation can exercise the alternative in practice.

12.14 From Third-Party Risk Management to Ecosystem Control

The transformation of third-party governance ultimately requires a change in the unit of analysis, the frequency of assurance and the purpose of procurement.

The traditional model asks:

Is this supplier sufficiently reliable for us to contract with?

The AI-enabled model asks:

What role does this provider play in our technology ecosystem, what risks does that dependency create, how will we know when its characteristics change, and what options do we retain if the relationship becomes unacceptable?

This is a much more strategic conception of third-party governance.

Procurement, enterprise architecture, cybersecurity, legal, business continuity, GRC and business owners must therefore collaborate when evaluating material AI dependencies. Supplier selection becomes part of architectural design; contractual terms become part of the control environment; interoperability becomes a governance mechanism; and exit capability becomes a resilience control.

The organisation is no longer simply buying technology. It is embedding external dependencies into its operating model.

12.15 Conclusion: From Vendor Selection to Controlled Optionality

Agentic AI significantly increases the strategic importance of third-party and ecosystem governance. Organisations increasingly depend upon external foundation models, cloud platforms, data providers, SaaS applications, APIs and specialist AI agents. These dependencies can influence not only cost and availability but also security, compliance, model behaviour, data governance and operational resilience.

Third-party GRC must therefore move beyond periodic supplier assessments towards continuous, relationship-aware ecosystem governance.

The critical dimensions include data location and provenance, model provenance, subcontractor dependencies, model-change processes, concentration risk, interoperability, portability, exit capability, security, regulatory compliance, audit rights, incident notification, model performance, intellectual property and operational resilience.

The central strategic principle is:

The objective of AI-era procurement is not simply to select the best vendor; it is to construct an ecosystem in which critical dependencies remain visible, governable and replaceable.

Controlled optionality consequently becomes a source of organisational resilience and strategic autonomy. Organisations that preserve the ability to change providers, architectures and AI components can respond more effectively to regulatory change, security threats, technology disruption and shifts in market structure.

The mature GRC function therefore does not merely ask whether a third party is acceptable. It asks whether the organisation remains in control of the dependency itself.

13. Strategic Pillar 10: Extend GRC Across the Enterprise Ecosystem

Modern risk increasingly extends beyond the formal boundaries of the organisation. Customers, employees, suppliers, technology providers, outsourcing partners, financial institutions, cloud platforms and other ecosystem participants can all influence an organisation's risk exposure and ability to meet its regulatory obligations.

This challenges a fundamental assumption embedded in traditional GRC: that the organisation itself is the primary and sufficient unit of analysis.

That assumption is increasingly difficult to sustain. Digital business models create dense networks of interdependence in which risk can originate outside the organisation and propagate rapidly across organisational boundaries. A cyber incident at a supplier can disrupt internal operations. A failure at a cloud provider can affect multiple critical applications. A change in a foundation model can alter the behaviour of an internal AI-enabled process. A counterparty's ownership structure can change the organisation's financial-crime exposure. A geopolitical event can transform the risk associated with an otherwise stable supply relationship.

The consequence is that GRC must increasingly understand not only what the organisation controls, but also what the organisation depends upon and what depends upon it.

The evolution of KYC and customer due diligence provides a useful analogy. Risk-based approaches to customer due diligence and supervision place emphasis on understanding the nature and level of risk, applying proportionate measures and maintaining an assessment that can respond as relevant circumstances change (FATF, 2017; FATF, 2021). This represents a broader movement away from treating customer information as a static identification record towards understanding relationships, risk characteristics and changing conditions over time.

The same conceptual transition can be applied to enterprise GRC. Rather than maintaining static inventories of suppliers, systems, controls and obligations, organisations should increasingly seek to understand the relationships and dependencies connecting them. This means identifying which external providers support critical processes, which internal systems depend upon particular technologies or data sources, where common dependencies exist, and how changes in one part of the ecosystem could affect risks and controls elsewhere. Enterprise risk management research similarly emphasises the importance of understanding relationships and interdependencies among sources of organisational risk (Bromiley et al., 2015).

The strategic objective is therefore to develop extended-enterprise intelligence: the ability to continuously understand, assess and respond to risks arising across the networks and dependencies through which the organisation operates. This extends the scope of GRC beyond the boundaries of direct organisational control towards a more connected understanding of the ecosystem in which organisational capability and control are embedded.

Extended-enterprise intelligence does not imply that the organisation can control every participant within that ecosystem. Rather, it enables the organisation to distinguish between what it can directly control, what it can influence through governance and contractual mechanisms, and what it must monitor and prepare for because it lies outside its direct authority. This distinction is critical to effective risk management in increasingly interconnected operating environments.

13.1 From Organisational Boundaries to Risk Networks

Traditional GRC tends to organise information around organisational structures. Business units, legal entities, employees, suppliers and applications are assessed as relatively discrete objects. This structure remains useful for accountability and control ownership, but it can obscure the relationships through which risks and dependencies actually arise.

Modern enterprise risk is less discrete. Organisations operate through interconnected networks of entities, technologies, contractual relationships, financial flows, information exchanges and operational dependencies. Risk can therefore emerge not only from the characteristics of individual entities, but also from the relationships and interdependencies between them. Enterprise risk management research emphasises the importance of understanding such interactions rather than treating risk exposures as entirely independent (Bromiley et al., 2015).

This creates a fundamental shift in GRC architecture.

Instead of asking only:

Is this supplier compliant?

the organisation increasingly needs to ask:

What does this supplier depend upon, what do we depend upon it for, which other relationships are connected to it, and how could a change in its risk profile affect our wider ecosystem?

The same logic applies to customers, partners, technology providers and other counterparties. The relevant object of analysis is therefore not always the individual entity, but the entity together with the relationships and dependencies that connect it to the wider organisational system.

Knowledge-graph approaches provide a useful technical foundation for representing such relationships by explicitly connecting entities and the information associated with them (Hogan et al., 2021). Applied to GRC, this can support representations linking suppliers, customers, applications, data, controls, processes, obligations and other relevant entities, enabling risk information to be interpreted within its broader relational context.

GRC consequently needs to become increasingly relationship-aware. This means moving beyond static entity-level assessments towards an understanding of dependencies, connections and potential effects across the organisational ecosystem. The strategic objective is not to replace entity-level GRC, but to complement it with a relational perspective that allows organisations to identify exposures that may be invisible when entities are assessed in isolation.

13.2 The Enterprise as an Interconnected Ecosystem

The modern enterprise is better understood as an ecosystem than as an isolated organisational entity.

A simplified representation is:

Employees → Customers → Suppliers → Technology Providers → Partners → Financial Infrastructure → Regulators → Wider Ecosystems

These relationships are not merely informational. They create flows of:

• data;

• money;

• services;

• operational dependencies;

• contractual obligations;

• technology;

• authority; and

• risk.

Each flow can create control requirements.

For example, a supplier may process sensitive customer information; a cloud provider may host a critical AI application; a financial institution may enable transactions; a technology partner may have privileged system access; and a regulator may impose obligations that require information from several parties.

The GRC architecture must therefore be capable of representing these relationships rather than treating each entity as an independent risk object.

13.3 Learning from the Evolution of KYC

The development of KYC and customer due diligence demonstrates why this broader perspective matters. Traditional approaches placed substantial emphasis on customer identification and documentation, whereas risk-based financial-crime frameworks require organisations to understand the nature and level of risk associated with customers and to apply proportionate measures in response to relevant risk factors (FATF, 2017). Risk-based supervision similarly emphasises understanding risk in context and adapting supervisory attention to changing risk conditions (FATF, 2021).

The important conceptual development can therefore be expressed as:

Static identity → contextual relationship → continuous risk understanding

This logic can be extended beyond financial crime. A supplier should not be understood solely through its onboarding questionnaire. Its ownership, subcontractors, cyber posture, geographic exposure, technology dependencies and performance may change over time, potentially altering the organisation's exposure. Similarly, a technology provider should not be assessed only according to its initial security certification. Changes in infrastructure, ownership, subcontracting, data processing or model architecture may materially change the characteristics of the service and its associated risks.

This reflects the broader principle that enterprise risk is contextual, relational and dynamic. Risk management research emphasises the importance of considering interactions and interdependencies among different sources of organisational risk rather than treating exposures as isolated attributes of individual entities (Bromiley et al., 2015).

The broader lesson is therefore that entity-level assessment is necessary but insufficient where organisational risk depends upon changing relationships and dependencies. GRC should increasingly complement static records and point-in-time assessments with an ecosystem intelligence model that continuously updates its understanding of relevant entities, relationships, dependencies and risk conditions.

Such an approach would allow organisations to identify not only whether an entity remains within an acceptable risk category, but also what has changed, which relationships are affected, what dependencies have emerged or intensified, and what implications those changes have for the wider control environment. This provides the foundation for a more dynamic form of GRC in which risk understanding evolves alongside the organisational ecosystem it is intended to govern.

13.4 Extending Third-Party Risk into Dependency Risk

Third-party risk is the most obvious application of extended-enterprise GRC, but conventional third-party management can remain too narrowly focused on direct suppliers.

A supplier may itself depend upon other providers, infrastructure platforms or critical technologies. These fourth-party dependencies can become material even when they are outside the organisation's direct contractual relationship.

This creates a dependency chain:

Organisation → Supplier → Subcontractor → Technology Provider → Infrastructure

The organisation may ultimately be exposed to the failure of an entity several layers removed from the original procurement decision.

This is particularly significant for AI and cloud services. An organisation may contract with one SaaS provider while the service itself depends upon a cloud platform, foundation model provider and external data service.

Extended GRC should therefore seek to identify material dependency chains, particularly where failure could affect critical business processes.

The objective is not to map every relationship indefinitely. It is to establish sufficient visibility into dependencies that could create material operational, regulatory, financial or strategic risk.

13.5 Cyber Resilience Across the Ecosystem

Cybersecurity provides another clear example of why organisational boundaries are insufficient.

An organisation's security posture increasingly depends upon the security of external identities, APIs, suppliers, cloud infrastructure, software components and service providers. A vulnerability outside the organisation can therefore create an internal control failure.

Cyber resilience must consequently be considered at ecosystem level.

This requires organisations to understand:

• which critical services depend upon external providers;

• which providers have privileged access;

• where sensitive data is processed;

• which common infrastructure providers create concentration risk;

• how incidents propagate across dependencies; and

• how alternative arrangements would operate during disruption.

This approach moves cybersecurity from perimeter protection towards network-aware resilience, consistent with the broader transition towards identity-centric and ecosystem-based security described in the preceding chapters.

13.6 Financial Crime as an Ecosystem Risk

Financial crime also demonstrates the importance of extending GRC beyond the immediate organisational boundary. Money laundering, sanctions evasion, fraud and other forms of financial crime can involve networks of individuals and entities rather than isolated actors. Beneficial ownership structures, transactional relationships, intermediaries and cross-border connections can therefore be important to understanding the nature and level of exposure.

The development of more sophisticated KYC and customer due diligence practices reflects this broader risk-based perspective. FATF guidance emphasises understanding the nature and level of customer risk and applying appropriate measures based on relevant risk factors, while risk-based supervision similarly requires attention to the characteristics and changing conditions of the risks being supervised (FATF, 2017; FATF, 2021). This moves the focus beyond identity verification towards a more contextual understanding of relationships and risk.

AI-enabled GRC can extend this principle by connecting information across customers, counterparties, suppliers, transactions and external intelligence. By linking these sources within a governed information architecture, organisations can develop a more integrated view of relationships and dependencies that may be difficult to identify when information remains distributed across separate systems and functional processes. This is consistent with the broader enterprise risk-management principle that risks should be considered in relation to their interactions and interdependencies rather than treated as entirely isolated exposures (Bromiley et al., 2015).

However, greater analytical capability must be accompanied by strong governance. Relationship analysis should remain proportionate to the legitimate risk-management purpose, appropriately explainable and subject to applicable privacy, data-governance and regulatory requirements. AI governance frameworks emphasise the importance of managing data, transparency, accountability and potential impacts throughout the AI lifecycle (NIST, 2023; ISO/IEC, 2023). Greater ability to identify relationships therefore does not, by itself, justify unrestricted collection, linkage or analysis of information.

The objective is consequently not indiscriminate surveillance, but contextual risk intelligence based on legitimate and governed relationships. The strategic value lies in enabling the organisation to understand relevant connections, identify material changes in risk and direct proportionate investigation or intervention while preserving appropriate boundaries around privacy, authority and accountability.

This represents a broader GRC principle: the ability to see more relationships should be matched by the ability to govern how those relationships are interpreted and acted upon.

13.7 Supply-Chain and Outsourcing Risk

Supply chains create another important dimension of extended-enterprise governance.

Modern organisations increasingly outsource infrastructure, manufacturing, logistics, software development, data processing and business operations. Outsourcing can improve efficiency and access to specialist capabilities, but it can also transfer operational dependencies beyond the organisation's direct control.

AI-enabled GRC should therefore connect supplier intelligence with business-process criticality.

A supplier should receive greater attention when it supports a critical process, holds sensitive data, provides a unique capability or has limited substitutability.

This suggests a risk model based not solely on supplier characteristics, but on:

Supplier characteristics × Dependency criticality × Substitutability × Ecosystem connectivity

A relatively small provider may therefore represent greater strategic risk than a much larger supplier if the organisation has no practical alternative and the service is embedded deeply within critical operations.

13.8 AI Providers as Ecosystem Dependencies

The growth of foundation models and AI platforms makes ecosystem governance particularly important.

An organisation may rely on external providers for:

• foundation models;

• embeddings;

• retrieval services;

• AI agents;

• cloud infrastructure;

• vector databases;

• data services;

• content moderation;

• security tooling; and

• specialised AI applications.

These dependencies can affect model performance, data governance, security, regulatory compliance and operational continuity.

Moreover, AI providers can change their systems rapidly. A model update, pricing change, API modification or service retirement may alter the organisation's operational and risk profile.

This reinforces the principle developed in Chapter 12: AI provider governance must include change awareness, dependency visibility and controlled optionality.

The broader implication is that AI governance cannot be isolated within an internal model-risk framework. It must extend across the external technology ecosystem supporting the AI capability.

13.9 Cloud Concentration and Infrastructure Dependency

Cloud concentration represents another important form of ecosystem risk that may not be visible through conventional supplier assessments. An organisation may appear to have multiple technology suppliers while several of those suppliers ultimately depend upon the same cloud, infrastructure or underlying technology provider. This creates hidden concentration: apparent supplier diversity may mask a common underlying dependency.

If several critical services rely on shared infrastructure, an outage, cyber incident or material disruption affecting that infrastructure could produce correlated failures across suppliers that otherwise appear operationally independent. The resulting exposure is therefore not determined solely by the number or individual risk ratings of suppliers, but also by the relationships and dependencies connecting them. This reflects the broader enterprise risk-management principle that risks should be understood in terms of their interactions and interdependencies rather than treated as entirely isolated exposures (Bromiley et al., 2015).

Extended-enterprise GRC should therefore analyse dependencies below the immediate contractual layer. The relevant question is not simply which suppliers the organisation contracts with, but which underlying technologies, infrastructure providers, applications, data services and other dependencies support those suppliers and the business processes that rely upon them.

Relationship-aware data architectures can provide significant value in this context. Knowledge graphs, for example, can represent entities and the relationships between them, providing a basis for connecting suppliers, cloud providers, applications, data sets, business processes and controls within a common information structure (Hogan et al., 2021). Applied to GRC, this approach can support a more connected representation of the extended enterprise than conventional supplier registers based primarily on individual contractual relationships.

The resulting dependency intelligence can help reveal concentrations, shared infrastructure and potential cascading dependencies that may otherwise remain obscured. This shifts GRC from assessing suppliers primarily as individual entities towards understanding the dependency structures through which risk can propagate across the wider technology and organisational ecosystem.

13.10 Geopolitical Risk and Digital Sovereignty

The expansion of global technology ecosystems also introduces geopolitical considerations.

Technology providers may operate across multiple jurisdictions, rely upon international supply chains or be subject to changing regulatory and political conditions. Geopolitical developments can affect data access, technology availability, sanctions exposure, supply continuity and strategic autonomy.

Digital sovereignty therefore becomes an increasingly relevant GRC consideration.

Organisations may need to understand:

• where critical technology is controlled;

• where data is processed;

• which jurisdictions influence service availability;

• whether critical components can be substituted;

• whether sanctions or export controls could affect operations; and

• whether geopolitical disruption could impair critical business processes.

These considerations cannot be captured adequately through traditional compliance checklists. They require dynamic ecosystem intelligence that connects external developments with organisational dependencies.

13.11 ESG and Broader Ecosystem Risk

The same logic applies to environmental, social and governance considerations.

Organisational exposure may arise from suppliers, contractors, logistics providers and other ecosystem participants. Environmental disruption, labour practices, human-rights concerns or governance weaknesses within the extended supply chain can create financial, legal and reputational consequences for the focal organisation.

GRC should therefore increasingly distinguish between direct organisational exposure and ecosystem exposure.

This does not imply that organisations should assume unlimited responsibility for every activity within their ecosystem. Rather, risk-based governance should identify relationships where external behaviour could materially affect organisational obligations, stakeholder expectations or strategic objectives.

The principle remains proportionality: greater visibility and control should be directed towards relationships with greater potential consequence.

13.12 Relationship Intelligence and Knowledge Graphs

Extending GRC across the enterprise ecosystem creates a strong case for relationship-aware information architecture.

Traditional databases are effective at storing attributes associated with individual entities. However, many emerging GRC questions concern relationships:

• Who owns this supplier?

• Which applications depend upon this provider?

• Which customers are connected to this entity?

• Which jurisdictions are involved?

• Which controls depend upon this technology?

• Which business processes would be affected if this provider failed?

• Which other suppliers share the same infrastructure?

Knowledge graphs provide one potential architectural mechanism for representing these relationships because they model entities and the connections between them (Hogan et al., 2021).

When combined with provenance, event streams and authoritative data sources, such architectures can support more dynamic forms of GRC intelligence.

The resulting model moves from:

Entity records → Relationship intelligence → Network-aware risk analysis

This is particularly important for AI-enabled GRC because intelligent systems require structured representations of organisational context if they are to reason reliably about risk and dependencies.

13.13 From Static Counterparty Profiles to Continuous Ecosystem Monitoring

The extended-enterprise model also changes the temporal dimension of GRC.

A supplier profile, customer profile or technology assessment should not be regarded as permanently valid. Ownership can change, cyber incidents can occur, sanctions can change, geopolitical conditions can deteriorate and technology providers can modify their services.

Continuous monitoring therefore becomes increasingly important.

Relevant events may include:

• ownership changes;

• regulatory actions;

• sanctions developments;

• cyber incidents;

• financial distress;

• service disruptions;

• model changes;

• new subcontractors;

• geopolitical developments;

• adverse information; and

• changes in dependency or concentration.

The objective is not continuous surveillance of every ecosystem participant at equal intensity. Rather, monitoring should be risk-based and event-driven, with significant changes triggering reassessment or intervention.

This connects extended-enterprise governance directly with the continuous assurance architecture developed earlier.

13.14 Governance Across Organisational Boundaries

Extending GRC does not mean attempting to control entities that the organisation does not own. Instead, it requires the organisation to establish appropriate mechanisms for managing inter-organisational dependencies.

These mechanisms may include:

• contractual requirements;

• shared standards;

• assurance and audit rights;

• information-sharing arrangements;

• service-level commitments;

• incident-notification obligations;

• joint resilience testing;

• escalation mechanisms; and

• alternative-provider strategies.

The strength of ecosystem governance therefore depends partly on the organisation's ability to translate risk expectations into inter-organisational control mechanisms.

This is particularly important where critical activities are outsourced. Accountability may be shared operationally, but the organisation may retain ultimate responsibility for meeting certain regulatory or customer obligations.

Outsourcing therefore does not eliminate risk ownership. It changes the architecture through which that risk must be governed.

13.15 From Enterprise GRC to Extended-Enterprise Intelligence

The cumulative effect of these changes is a transformation in the role of GRC.

Traditional GRC largely asks:

What risks exist within our organisation?

Extended-enterprise GRC asks:

What networks, dependencies and relationships shape our risk exposure, and how are those relationships changing?

This is a materially different analytical problem.

It requires GRC to integrate information across internal and external sources, represent relationships, monitor changes and connect external signals to internal controls and decisions.

The resulting capability can be described as extended-enterprise intelligence.

It combines:

Entity intelligence — understanding relevant people, organisations, systems and providers.

Relationship intelligence — understanding how those entities interact and depend upon one another.

Risk intelligence — assessing how those relationships create or amplify risk.

Control intelligence — understanding which mechanisms constrain those risks.

Event intelligence — detecting changes that could alter the risk profile.

Decision intelligence — translating ecosystem information into actionable organisational decisions.

This represents a natural progression of the broader GRC transformation developed throughout this chapter.

13.16 Conclusion: From Organisational GRC to Ecosystem Governance

Modern organisations do not operate in isolation. Their risk profiles are shaped by customers, employees, suppliers, technology providers, financial infrastructure, outsourcing arrangements, regulators and broader geopolitical and economic ecosystems. Risk can therefore enter the organisation through relationships and dependencies that extend beyond its immediate organisational boundaries.

The evolution of KYC and customer due diligence demonstrates the value of moving beyond purely static entity assessment towards a more contextual and risk-based understanding of relationships and changing risk conditions. FATF guidance emphasises understanding the nature and level of risk associated with customers and applying proportionate measures based on relevant risk factors, while risk-based supervision similarly requires attention to the characteristics and changing conditions of the risks being supervised (FATF, 2017; FATF, 2021). Enterprise GRC can extend this principle beyond customers to the wider network of organisational relationships and dependencies.

The strategic objective is not to control every participant in the ecosystem. It is to understand the material relationships and dependencies through which risk can propagate, establish appropriate mechanisms of influence and continuously identify changes that could alter organisational exposure. This reflects the broader enterprise risk-management perspective that risks should be considered in relation to their interactions and interdependencies rather than treated as entirely isolated exposures (Bromiley et al., 2015).

This requires GRC architectures capable of integrating multiple dimensions of extended-enterprise exposure, including third-party risk, cyber resilience, financial crime, supply-chain risk, outsourcing, AI providers, cloud concentration, geopolitical risk, ESG and digital sovereignty. Such integration is particularly important where a change in one external dependency can affect multiple business processes, controls or risk categories simultaneously.

The strategic principle is therefore:

The organisation should govern not only the risks it directly owns, but the critical relationships and dependencies through which those risks can enter, propagate and amplify.

GRC consequently evolves from an organisation-centric compliance function into an extended-enterprise intelligence capability. The mature GRC function is no longer simply a boundary around the organisation. It becomes a mechanism for understanding and governing the network in which the organisation operates, identifying material dependencies, recognising changes in exposure and enabling proportionate responses across organisational boundaries.

14. The Transformation Roadmap

The transformation of GRC should not be approached as a single enterprise-wide AI implementation. Such an approach risks deploying intelligent technologies before the organisation has established the data, process, governance, security and assurance capabilities required to control them.

A more sustainable approach is to treat GRC transformation as a progressive capability-building programme. Each phase should establish the foundations required for the next. Data and architecture precede reliable intelligence; reliable intelligence precedes meaningful automation; controlled automation precedes bounded autonomy; and mature autonomy creates the foundation for decision-intelligent GRC.

The roadmap should therefore be understood not simply as a timetable, but as a sequence of increasing organisational capability and decreasing dependence on manual intervention for activities that can be safely automated.

The progression can be expressed as:

Foundation → Integration → AI augmentation → Governed autonomy → Decision intelligence

Importantly, the organisation should not advance because a predetermined date has been reached. Progression should depend on evidence that the relevant capabilities, controls and assurance mechanisms are sufficiently mature.

14.1 Phase 1: Establish the Foundation — 0–6 Months

The first phase should establish the strategic, organisational and architectural foundations for transformation.

The organisation should begin by defining a clear GRC transformation vision. This vision should identify what the organisation is attempting to improve, such as decision quality, regulatory responsiveness, control effectiveness, operational resilience, assurance, efficiency or a combination of these objectives. This strategic alignment is consistent with the enterprise risk-management principle that risk and control activities should be connected to organisational strategy and performance rather than treated as separate compliance activities (COSO, 2017).

The transformation should then identify the critical business decisions that GRC is expected to support. This is important because AI use cases should ultimately be connected to organisational outcomes and decision processes rather than implemented simply because a particular technology is available. Digital business strategy research similarly emphasises the integration of digital capabilities with business processes and organisational capabilities to create business value (Bharadwaj et al., 2013).

The organisation should also map its major GRC processes, identifying where manual activity, fragmented data, duplicated controls, delayed information or weak accountability currently constrain performance. This process-level assessment provides the basis for determining where AI can augment or automate work and where human judgement should remain central. The automation–augmentation perspective reinforces the importance of deliberately determining which activities should be automated and which should remain subject to human judgement and oversight (Raisch and Krakowski, 2021).

At the same time, foundational governance mechanisms should be established. These should include:

1. defining the GRC transformation vision;

2. identifying critical business decisions;

3. mapping major GRC processes;

4. establishing AI governance and decision rights;

5. creating an enterprise AI and GRC inventory;

6. assessing data quality, provenance and interoperability;

7. identifying high-value AI use cases;

8. defining risk-based levels of agent autonomy;

9. establishing architecture principles; and

10. selecting initial pilot processes.

The AI and GRC inventory is particularly important because organisations cannot effectively govern AI systems that they cannot identify. The inventory should provide visibility over AI applications, models, agents, business owners, data sources, suppliers, use cases and associated risks. This is consistent with the emphasis placed by NIST on governance structures, roles and responsibilities, documentation, data management and ongoing risk management across the AI lifecycle (NIST, 2023).

Use-case selection should be evidence-based rather than technology-driven. Candidate use cases should be assessed according to their strategic relevance, contribution to critical decisions and processes, data and systems readiness, expected organisational value, human–AI role allocation, control implications and governance requirements. This provides a more disciplined basis for prioritisation than selecting use cases according to novelty or technical feasibility alone. The underlying principle is that AI capability should be evaluated in relation to the organisational problem it is intended to address and the governance conditions under which it will operate (Bharadwaj et al., 2013; Raisch and Krakowski, 2021; NIST, 2023).

Foundation-stage principle

The first phase should answer:

What are we transforming, why does it matter, what information and authority are required, and what controls must exist before AI is introduced?

The output of Phase 1 should therefore be a GRC transformation architecture and prioritised portfolio, rather than a large collection of AI pilots. The objective is to establish the strategic direction, governance conditions, information foundations and decision priorities required for subsequent phases of AI-enabled GRC transformation.

14.2 Phase 2: Digitise and Integrate — 6–12 Months

The second phase focuses on creating the information infrastructure required for intelligent GRC.

AI systems cannot reliably produce useful organisational intelligence if relevant information remains fragmented across spreadsheets, document repositories, disconnected GRC applications and business systems. The organisation must therefore establish a trusted information layer before attempting to increase AI autonomy. Effective AI governance requires appropriate attention to data, documentation, traceability, roles, responsibilities and lifecycle management, making the quality and governance of the underlying information infrastructure a prerequisite for trustworthy AI-enabled GRC (NIST, 2023; ISO/IEC, 2023).

Key activities should include:

• establishing the GRC data fabric;

• connecting regulatory intelligence;

• integrating policy and control repositories;

• creating regulatory-to-control mappings;

• exposing relevant APIs;

• establishing governed knowledge retrieval;

• implementing provenance and data lineage;

• integrating GRC and operational workflow systems; and

• introducing continuous monitoring.

The objective is to create a coherent chain linking:

Regulation → Obligation → Policy → Risk → Control → Process → System → Evidence → Decision → Outcome

This relationship is central to AI-enabled GRC. Without it, AI may be able to retrieve documents or generate summaries but will struggle to understand the organisational significance of the information it processes. The value of an intelligent GRC information layer therefore lies not simply in making more information available, but in connecting information to the organisational relationships, controls and decisions that give it meaning.

The GRC data fabric should therefore provide not simply centralised storage but semantic consistency, provenance, traceability and interoperability. Relationship-oriented information structures can support this objective by representing entities and the connections between them, enabling information to be understood within a broader network of relationships rather than as isolated records (Hogan et al., 2021). NIST and ISO/IEC 42001 likewise emphasise the importance of governed information, documentation, accountability and appropriate lifecycle management for AI systems (NIST, 2023; ISO/IEC, 2023).

Knowledge retrieval should also be implemented carefully. Retrieval-augmented generation can connect generative AI systems to external sources of information and improve performance on knowledge-intensive tasks, but retrieval itself does not establish whether the retrieved information is authoritative, current, appropriate for the user or sufficient for a particular decision (Lewis et al., 2020). Retrieval therefore needs to be integrated with permissions, provenance, source governance and workflow controls. In an enterprise GRC environment, the relevant question is not simply whether an AI system can retrieve information, but whether it can retrieve the right information, from an appropriate source, within the authority and context of the decision being supported.

Integration-stage principle

The second phase should answer:

Can the organisation provide AI systems with trusted, traceable and appropriately governed information at the point where GRC decisions are made?

The objective is therefore information readiness, not maximum automation. AI autonomy should be developed only as the organisation establishes the information quality, relationships, provenance and governance mechanisms required to support reliable decision-making and controlled execution.

14.3 Phase 3: Introduce AI-Assisted GRC — 12–18 Months

Once the underlying information and workflow architecture has matured, the organisation can introduce AI primarily in an assistive capacity.

This phase should deliberately prioritise augmentation over autonomy. AI should increase the analytical capacity of GRC professionals while maintaining clear human accountability for consequential decisions.

Initial use cases may include:

• regulatory intelligence;

• policy analysis;

• evidence analysis;

• risk summarisation;

• control-testing support;

• regulatory-change impact analysis;

• audit preparation;

• financial-crime investigation support; and

• third-party intelligence.

These applications are attractive because they can reduce information-processing burdens without immediately transferring significant decision authority to machines.

For example, an AI system might identify regulatory changes and generate a preliminary impact assessment. A compliance professional can then validate the interpretation, assess materiality and determine the appropriate organisational response.

Similarly, an AI system might review control evidence and identify potential exceptions, while the accountable control owner determines whether the exception represents an actual control deficiency and what remediation is required.

This creates a deliberate division of labour:

AI → discover, classify, compare, summarise and prioritise

Human → interpret, challenge, decide and remain accountable

The purpose of this phase is also to generate organisational learning. The organisation should use early deployments to understand model limitations, data weaknesses, workflow friction, user behaviour, false positives, escalation patterns and assurance requirements.

AI-assistance-stage principle

The third phase should answer:

Where can AI materially improve GRC performance while keeping decision authority and accountability clearly within the organisation?

The answer should provide the evidence base for determining where greater autonomy is justified.

14.4 Phase 4: Introduce Governed Agents — 18–30 Months

Agentic capabilities should be introduced only after the organisation has demonstrated sufficient maturity in data, identity, permissions, workflow integration, monitoring, evidence and human oversight. This represents a significant architectural transition because the governance challenge changes when AI moves from primarily generating information for a human towards taking actions within an organisational environment.

An AI assistant primarily generates information for a human to evaluate. An agent can increasingly take actions within an organisational environment, including interacting with tools, retrieving information and initiating or executing activities. Agentic systems that combine reasoning with external actions therefore introduce additional requirements for control, observability and governance (Yao et al., 2023). AI governance frameworks similarly emphasise defined responsibilities, human oversight, risk management, documentation and ongoing monitoring across the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

Initial agentic use cases should therefore focus on bounded activities where objectives are clear, actions are observable, permissions can be constrained and consequences are reversible or otherwise containable. Agents may be authorised to:

• retrieve evidence;

• investigate exceptions;

• correlate risks;

• initiate workflows;

• prepare assessments;

• request approvals;

• update records;

• monitor remediation; and

• escalate emerging risks.

However, the introduction of agents should not be interpreted as a general delegation of organisational authority. Each agent should operate within an explicitly defined control envelope that establishes what it is intended to do, what it is permitted to access and which actions it may perform.

A useful design structure is:

Purpose → Identity → Permissions → Tools → Policies → Limits → Escalation → Evidence trail

The purpose establishes what the agent is intended to accomplish.

The identity establishes which machine entity is acting and enables attribution.

Permissions determine which data, systems and actions the agent can access.

Tools define the operational interfaces available to it.

Policies establish behavioural, organisational and regulatory constraints.

Limits define transaction, scope, frequency or consequence boundaries within which the agent may operate.

Escalation determines when authority must return to a human or higher-level control process.

The evidence trail records what the agent did, what information it used, which decisions or actions it initiated, and what outcome resulted.

This architecture reflects a fundamental governance distinction: intelligence, authority and execution should not be treated as the same capability. An AI system may provide analysis or recommendations without possessing authority to execute them. Where execution is permitted, the authority to act should be explicitly defined, constrained and observable rather than inferred from the system's technical capabilities. This is consistent with the broader emphasis on human oversight, defined responsibilities and risk-based governance in NIST AI RMF and ISO/IEC 42001 (NIST, 2023; ISO/IEC, 2023).

Agentic-stage principle

The fourth phase should answer:

Can the organisation allow an AI system to act while remaining able to observe, constrain, interrupt and recover from its behaviour?

If the answer is no, the organisation should not increase autonomy. The strategic objective is not maximum agentic capability, but controlled autonomy: increasing the ability of AI systems to act only as the organisation's governance, identity, permission, monitoring and recovery mechanisms become sufficiently mature to keep that activity within acceptable boundaries.

14.5 Phase 5: Decision-Intelligent GRC — 30+ Months

The final stage is the development of an integrated GRC decision system.

At this stage, GRC is no longer primarily a repository of policies, assessments and reports. It becomes an organisational capability that continuously integrates regulatory intelligence, risk signals, control performance, ecosystem dependencies, operational events and business context. This reflects the broader principle that enterprise risk management should be integrated with organisational strategy and performance rather than operating as a separate reporting activity (COSO, 2017).

The objective is to provide decision-makers with dynamic answers to questions such as:

What are our most material emerging risks?

Which regulatory changes could materially affect our strategy?

Which suppliers create concentration risk?

Which controls are deteriorating?

Where is residual risk exceeding appetite?

What would happen if this dependency failed?

Which interventions provide the greatest risk reduction per unit of cost?

These questions require more than dashboards. They require an architecture capable of connecting data, relationships, risk models, controls, business processes and decision context. Digital business strategy research similarly emphasises the importance of integrating digital capabilities with business processes and organisational capabilities so that technology contributes to organisational value rather than operating as a disconnected technical capability (Bharadwaj et al., 2013).

The mature GRC environment should therefore evolve towards decision intelligence: the systematic integration of information, analytical capability and organisational judgement to improve consequential decisions. AI can strengthen this capability by identifying patterns, synthesising information, analysing scenarios and generating recommendations, but the allocation of responsibility between AI systems and human decision-makers must remain deliberate and governed. The automation–augmentation perspective highlights the importance of determining where AI should automate activities and where human judgement should remain central (Raisch and Krakowski, 2021).

The resulting capability is therefore not simply a more sophisticated reporting environment. It is a decision-oriented GRC architecture in which regulatory developments, risk exposures, control performance, dependencies and operational events can be connected to the business decisions they may affect. The strategic value lies in moving from asking what has happened and what must be reported towards understanding what is changing, why it matters, what decisions may be affected and which interventions are available.

The final transformation is consequently:

GRC as evidence repository → GRC as intelligence capability → GRC as decision-support system → GRC as integrated organisational control capability.

14.6 The Roadmap as a Maturity Model

The five phases should not be understood as rigid chronological stages. Different parts of the organisation may progress at different rates.

A mature financial-crime process may already be capable of continuous monitoring and AI-assisted investigation, while another GRC domain may still depend upon fragmented data and manual evidence collection.

Transformation should therefore operate as a portfolio of capability journeys rather than a single enterprise-wide deployment.

Progression should be determined by capability maturity across several dimensions:

• data quality and accessibility;

• process maturity;

• system interoperability;

• identity and access control;

• AI governance;

• cybersecurity;

• evidence and provenance;

• human oversight;

• continuous assurance;

• workforce capability; and

• organisational change readiness.

An organisation should not introduce autonomous agents into a process merely because the technology is available. The process should first demonstrate sufficient maturity across these dimensions.

This creates a critical governance principle:

Autonomy should be earned through demonstrated control maturity, not granted through technological availability.

14.7 Stage Gates for Responsible Progression

Each transition should therefore include explicit stage gates.

Before moving from foundation to integration, the organisation should demonstrate that critical processes and decision rights are understood.

Before moving from integration to AI assistance, relevant data should be sufficiently accessible, traceable and governed.

Before moving from AI assistance to agentic execution, the organisation should demonstrate effective identity, permissions, monitoring, evidence, escalation and recovery mechanisms.

Before increasing agent autonomy, the organisation should demonstrate through testing and assurance that the relevant controls remain effective under normal, exceptional and adversarial conditions.

These gates prevent the roadmap from becoming a technology-driven race towards autonomy.

They also create an evidence-based basis for executive decision-making. Leadership can determine not simply whether a system is technically capable of greater autonomy, but whether the organisation is capable of governing that autonomy.

14.8 Pilot Selection and Scaling Strategy

Initial pilots should be selected according to both value and controllability. High-value pilots are not necessarily the most technically sophisticated applications. They are processes where:

• the business problem is material;

• relevant data exists;

• workflow integration is feasible;

• outcomes can be measured;

• risks can be bounded;

• human responsibilities are clear; and

• lessons can be transferred to other processes.

A well-designed pilot should therefore test more than model performance. It should test the complete GRC architecture:

Data → AI → Workflow → Human decision → Control → Evidence → Assurance

This is important because the organisational value of AI depends not only on the capability of the technology itself, but also on how effectively it is integrated with business processes and organisational capabilities (Bharadwaj et al., 2013). The pilot should therefore evaluate whether AI improves the target process while preserving appropriate human judgement, accountability and control. The automation–augmentation perspective further suggests that organisations should deliberately determine which activities are appropriate for AI and which should remain subject to human involvement (Raisch and Krakowski, 2021).

Pilot evaluation should consequently consider multiple dimensions, including business value, process performance, decision quality, control effectiveness, human–AI role allocation, evidence generation and operational risk. A technically successful model that cannot be reliably integrated into the workflow, governed within defined boundaries or supported by an adequate evidence trail should not be regarded as a successful GRC transformation pilot.

Once a pilot demonstrates measurable value and sufficient control effectiveness, the organisation can scale the underlying architecture, governance mechanisms and reusable implementation patterns to other GRC domains. Scaling should therefore replicate proven capabilities and control patterns, rather than simply replicate individual AI models or use cases.

14.9 Measuring Transformation Progress

Transformation progress should be measured through both business value and control maturity.

Relevant measures may include:

• reduction in manual GRC activity;

• speed of regulatory impact assessment;

• reduction in time required to investigate exceptions;

• improvement in control-testing coverage;

• quality of risk identification;

• decision-making cycle time;

• percentage of critical processes with continuous monitoring;

• percentage of AI systems with documented ownership;

• percentage of agents operating under explicit permission boundaries;

• evidence completeness;

• intervention and escalation effectiveness; and

• measurable reduction in material risk exposure.

This prevents the transformation programme from becoming an AI deployment exercise measured primarily by the number of models, assistants or agents introduced.

The appropriate question is not:

How much AI have we deployed?

It is:

How much better can the organisation sense, understand, decide and control risk as a result of the transformation?

14.10 The Roadmap as a Closed-Loop Transformation

The roadmap should also be understood as iterative rather than linear.

Experience from each phase should feed back into the previous stages. AI-assisted deployments may reveal data-quality problems. Agent pilots may expose weaknesses in identity or workflow architecture. Continuous assurance may identify previously unrecognised risks. Workforce adoption may reveal process-design weaknesses.

Transformation therefore becomes a learning loop:

Deploy → Observe → Evaluate → Learn → Redesign → Scale

This is consistent with the broader proposition that AI-enabled GRC should function as a continuously learning organisational control system rather than a collection of static governance activities.

The roadmap should consequently evolve as organisational experience accumulates.

14.11 From Transformation Programme to GRC Operating Model

The final objective is not the completion of a five-phase project. It is the establishment of a fundamentally different GRC operating model.

In the traditional model, GRC often operates through periodic assessments, manual evidence collection, specialist analysis and management reporting.

In the transformed model, GRC increasingly operates through:

Continuous sensing → AI-assisted interpretation → governed workflow execution → human judgement → automated control → continuous assurance → organisational learning

This represents a shift from GRC as a periodic function to GRC as embedded organisational infrastructure.

AI is important within this model, but it is not the transformation itself. The deeper transformation concerns the relationship between data, technology, processes, people, controls and decisions.

14.12 Conclusion: From AI Deployment to Decision-Intelligent GRC

The transformation roadmap should therefore be understood as a progressive movement from fragmented and periodic GRC towards an integrated, intelligent and increasingly continuous organisational control system.

The five phases establish a deliberate sequence:

Phase 1 — Foundation: establish vision, governance, ownership, architecture and priorities.

Phase 2 — Integration: build the data fabric, interoperability, provenance and workflow infrastructure.

Phase 3 — AI assistance: use AI to augment analysis while retaining human decision authority.

Phase 4 — Governed agents: introduce bounded machine execution where controls, permissions and assurance are sufficiently mature.

Phase 5 — Decision intelligence: integrate risk, regulatory, control and ecosystem intelligence into executive decision-making.

The progression is therefore not simply from less technology to more technology. It is from less organisational visibility and fragmented control towards greater sensing, intelligence, accountability and adaptive intervention.

The central strategic principle is:

Organisations should not pursue AI autonomy faster than they can build the governance, data, security, workforce and assurance capabilities required to control it.

The destination is consequently not an “AI-enabled GRC department”. It is a decision-intelligent GRC architecture in which information is continuously sensed, risk is continuously interpreted, controls operate increasingly within workflows, AI performs bounded tasks, human judgement remains concentrated where it matters most, and executives receive timely intelligence about the organisation's changing risk environment.

GRC thereby evolves from a reporting system into an organisational decision and control system.

15. Measuring Transformation

The transformation of Governance, Risk and Compliance (GRC) should not be measured primarily by the number of artificial intelligence (AI) tools deployed, models implemented, or processes labelled as automated. Such measures capture technological activity rather than organisational transformation. An organisation may deploy sophisticated AI while continuing to operate fundamentally through periodic assessments, fragmented data, manual control processes and retrospective reporting. In such circumstances, technological adoption can increase complexity without materially improving risk management, control effectiveness or decision quality.

The central measurement question should therefore be:

Is GRC becoming more intelligent, continuous, effective, resilient and capable of improving organisational decisions?

This shifts performance measurement from technology adoption towards capability development and organisational outcomes. Digital business strategy research emphasises that digital capabilities create organisational value through their integration with business processes and organisational capabilities rather than through technology deployment alone (Bharadwaj et al., 2013). Similarly, enterprise risk management is concerned with the relationship between risk, strategy and organisational performance, providing a basis for evaluating GRC transformation in terms of its contribution to organisational objectives and performance (COSO, 2017). The automation–augmentation perspective also reinforces the importance of evaluating how technology changes the allocation of work and judgement rather than treating automation itself as the primary measure of success (Raisch and Krakowski, 2021).

A balanced measurement framework should therefore examine five complementary dimensions:

1. Risk intelligence — whether the organisation can identify, interpret and anticipate material risks more effectively and continuously;

2. Operational efficiency — whether GRC processes become faster, less fragmented and less dependent on unnecessary manual activity;

3. Control effectiveness — whether controls operate more consistently, respond more rapidly to changing conditions and provide stronger evidence of effectiveness;

4. Decision quality — whether decision-makers receive more timely, relevant and contextualised risk and control information at the point of decision; and

5. Trust and resilience — whether the organisation can operate AI-enabled GRC in a manner that remains governed, observable, accountable and recoverable under changing or adverse conditions.

Together, these dimensions provide a more complete view of whether GRC is progressing from a predominantly reactive control function towards a continuously sensing and decision-intelligent organisational capability. The objective is therefore not to demonstrate that the organisation has deployed more AI, but that AI-enabled capabilities have produced a measurable improvement in how the organisation senses risk, understands exposure, exercises control, supports decisions and adapts to change.

15.1 Risk Intelligence

The first dimension concerns whether the organisation is becoming better at identifying, interpreting and anticipating risk.

Traditional GRC measurement tends to emphasise the number of assessments completed, issues identified or reports produced. These measures remain useful but are largely retrospective. A transformed GRC capability should instead demonstrate an increasing ability to detect emerging risks earlier, integrate multiple signals and provide decision-relevant intelligence before risks become control failures or material incidents. This is consistent with the emphasis on ongoing risk identification, assessment and monitoring throughout the AI lifecycle in the NIST AI Risk Management Framework (NIST, 2023).

Relevant measures include time to detect emerging risk, risk-signal coverage, prediction quality, early-warning accuracy and the proportion of material risks identified before they crystallise. These indicators assess whether GRC is moving beyond the documentation of known risks towards active sensing of changing risk conditions.

Risk-signal coverage is particularly important in an AI-enabled environment. Organisations increasingly generate risk-relevant information through transactions, operational events, cybersecurity telemetry, supplier changes, regulatory developments, customer behaviour and external intelligence. The value of AI is therefore partly determined by whether these signals can be connected and interpreted within the GRC architecture. This is particularly important where risks interact across organisational processes, technology dependencies and external relationships, since enterprise risk management research highlights the importance of understanding risk interactions and interdependencies rather than treating exposures as entirely isolated categories (Bromiley et al., 2015).

Prediction quality should also be assessed carefully. A system that produces large numbers of alerts is not necessarily intelligent. Excessive false positives can increase analyst workload, while false negatives can create a misleading perception of control. Measurement should therefore consider the quality, relevance, precision and timeliness of risk signals, rather than simply their volume. The organisation should also assess whether alerts lead to useful investigation, intervention or decision-making, rather than treating alert generation itself as evidence of improved risk intelligence.

The strategic objective is consequently to move from risk visibility towards risk anticipation. A mature capability should not merely provide more information about current exposure; it should help the organisation recognise meaningful changes earlier, understand their potential implications and support proportionate action before emerging risks become material events.

15.2 Operational Efficiency

The second dimension evaluates whether transformation is reducing unnecessary administrative effort and improving the speed and scalability of GRC processes.

Operational efficiency should not, however, be interpreted simply as headcount reduction. Automation may reduce manual activity while simultaneously creating new review, validation and exception-management requirements. The relevant question is whether human effort is being redirected towards activities where professional judgement creates greater value. Research on generative AI suggests that productivity effects depend on how AI is incorporated into work rather than simply on whether tasks are automated, reinforcing the importance of evaluating changes in the overall work process (Noy and Zhang, 2023; Brynjolfsson et al., 2025). The automation–augmentation perspective similarly highlights the importance of deliberately determining how work should be allocated between humans and AI systems (Raisch and Krakowski, 2021).

Useful measures include analyst hours saved, process cycle-time reduction, automation rates, exception-processing time, cost per assessment or control activity, and the proportion of GRC work performed without unnecessary manual intervention.

Cycle-time reduction is particularly significant because continuous GRC changes the temporal characteristics of control processes. A traditional compliance assessment may require weeks to collect information, review evidence and produce a conclusion. A more integrated architecture can allow evidence to be generated and evaluated closer to the point at which an event occurs. This can reduce delays between risk signals, analysis, decision-making and control response, provided that the underlying data and workflow integration are sufficiently mature.

Automation rate should therefore be interpreted alongside process quality. A high automation rate is not inherently desirable if it automates inefficient processes, introduces additional control complexity or transfers poorly designed decisions into machine workflows. Digital capabilities create greater organisational value when they are integrated with business processes and organisational capabilities rather than deployed as isolated technological solutions (Bharadwaj et al., 2013).

The objective is therefore process reinvention rather than automation for its own sake. Transformation should examine whether the GRC process itself has become faster, simpler, more scalable and more effective, rather than merely whether a greater proportion of its existing activities can be performed by machines.

Efficiency measurement should consequently capture both how much work is automated and whether the resulting process is materially better. A successful transformation should reduce unnecessary effort while improving timeliness, scalability, control quality and the allocation of human expertise.

15.3 Control Effectiveness

The third dimension concerns whether transformation actually improves the organisation's ability to prevent, detect and remediate control failures.

This is critical because GRC transformation should ultimately strengthen organisational control rather than simply make compliance activity faster. Control effectiveness can be assessed through measures such as control failure rates, remediation time, continuous-control coverage, repeat findings, exception frequency and the percentage of material controls supported by current and traceable evidence.

Continuous-control coverage is especially important for AI-enabled GRC. If a control remains dependent on an annual or quarterly review despite the availability of relevant real-time data, the organisation may have digitised the evidence-gathering process without fundamentally transforming the control itself. By contrast, event-driven controls can identify changes in risk conditions and trigger investigation, escalation or Continuous-control coverage is especially important for AI-enabled GRC. If a control remains dependent on an annual or quarterly review despite the availability of relevant real-time data, the organisation may have digitised the evidence-gathering process without fundamentally transforming the control itself. By contrast, event-driven controls can identify changes in risk conditions and trigger investigation, escalation or remediation closer to the point of occurrence. This reflects the broader emphasis on ongoing monitoring, risk management and continual improvement in AI governance frameworks (NIST, 2023; ISO/IEC, 2023).

Remediation time provides a complementary measure. A mature control environment is not one in which failures never occur; rather, it is one in which failures are detected promptly, constrained appropriately and resolved effectively. This reflects a broader resilience-oriented view of control effectiveness: organisations should be capable not only of preventing adverse events, but also of responding effectively when controls fail or conditions change. Enterprise risk management similarly requires organisations to consider how risk and control activities support organisational performance under changing conditions (COSO, 2017).

Control measurement should also distinguish between the existence of a control and its demonstrated operation. A policy, workflow or AI governance framework may exist formally while having limited influence over actual system behaviour. The stronger measure is therefore whether controls are operationally enforceable, continuously evidenced and capable of intervention. NIST emphasises the importance of governance, accountability, measurement and ongoing management of AI risks, while ISO/IEC 42001 establishes a management-system approach that includes monitoring, evaluation and continual improvement (NIST, 2023; ISO/IEC, 2023).

This distinction is particularly important as GRC becomes increasingly automated and agentic. A control should not be considered effective simply because it is documented or incorporated into a workflow. Its effectiveness should be demonstrated through evidence that it operates as intended, remains appropriate as conditions change and can intervene when defined risk thresholds or policy boundaries are exceeded.

The objective is therefore not simply more controls, but more demonstrably effective controls: controls that operate at the appropriate point in the process, respond to relevant changes, generate evidence of their operation and enable timely intervention when required.remediation closer to the point of occurrence.

15.4 Decision Quality

The fourth dimension assesses whether GRC transformation improves organisational decision-making.

This dimension is essential because the strategic value of intelligent GRC ultimately lies not in producing more risk information, but in enabling better decisions. If AI increases the volume of alerts, dashboards and assessments without improving management judgement, the transformation has generated information rather than intelligence.

Decision quality can be evaluated through measures including decision latency, escalation quality, risk-appetite breaches, management intervention effectiveness, decision rework, and the proportion of significant decisions supported by timely and relevant risk intelligence.

Decision latency is particularly valuable because effective GRC must balance speed with appropriate deliberation. Excessive delay can expose organisations to rapidly developing risks, while excessive automation can compress decision-making beyond the point at which meaningful human judgement is possible. The objective is therefore not simply faster decisions but faster decisions of appropriate quality.

Escalation quality should similarly assess whether material issues reach the appropriate decision-makers with sufficient context and at the appropriate time. An intelligent system should distinguish routine exceptions from situations requiring senior management, specialist or board-level intervention. This reinforces the principle of meaningful human control: human involvement should be concentrated where judgement, accountability or risk significance genuinely requires it rather than being inserted nominally into every workflow.

Risk-appetite breaches provide an outcome-oriented measure. If GRC transformation is successful, improved sensing, control execution and escalation should increasingly enable the organisation to identify decisions that may exceed approved risk tolerances before material consequences occur. Management intervention effectiveness can then assess whether the organisation acts appropriately when such signals are presented.

The strategic objective is consequently to move from reporting risk to improving decisions under uncertainty.

15.5 Trust and Resilience

The fifth dimension concerns whether the transformed GRC environment remains trustworthy, auditable and resilient as AI becomes increasingly embedded in organisational processes.

AI-enabled GRC introduces new failure modes, including model error, hallucination, inappropriate recommendations, prompt injection, data-quality failures, integration errors, permission failures, agentic execution errors and excessive human reliance on automated outputs. Transformation measurement must therefore capture not only performance during normal operation but also the organisation's ability to detect, constrain and recover from failure.

Relevant measures include AI incidents, override rates, auditability, agent-failure recovery time, recovery success rates, regulatory findings, unresolved AI control exceptions and the completeness of evidence trails.

Override rates require careful interpretation. A high override rate may indicate that AI recommendations are poor, that human review is appropriately conservative, or that the system has been deployed in contexts where autonomous decision-making is unsuitable. The metric therefore becomes meaningful only when combined with contextual analysis. Similarly, a low override rate is not necessarily evidence of success if users have become excessively dependent on AI outputs.

Auditability is another fundamental indicator of a trustworthy AI-enabled GRC environment. The organisation should be able to reconstruct what information was available, which model or agent was used, what decision or recommendation was produced, what permissions were exercised, what human intervention occurred and what outcome followed. This requires more than retaining technical logs. It requires sufficient documentation, traceability and accountability to reconstruct the relationship between information, system activity, human judgement and organisational outcomes. NIST emphasises documentation, transparency, accountability and ongoing risk management across the AI lifecycle, while ISO/IEC 42001 establishes governance and management-system requirements for the responsible management of AI systems (NIST, 2023; ISO/IEC, 2023). The accountability literature similarly emphasises the importance of mechanisms through which responsibility for AI-related decisions and actions can be established and assessed (Novelli et al., 2024).

Provenance and observability should therefore become measurable organisational capabilities rather than merely technical design principles. Relevant measures could include the completeness of decision and activity records, traceability of information sources, attribution of AI and human actions, coverage of agent activity monitoring, and the time required to reconstruct a consequential decision or incident.

Resilience should also be measured through recovery performance. For agentic systems, an important question is not merely whether an agent can complete a task successfully, but whether the organisation can safely interrupt, contain, roll back or recover from incorrect execution. This extends the assessment of AI capability from successful task completion to the organisation's ability to maintain control when AI behaviour deviates from expectations. NIST's risk-management approach emphasises the need to manage and monitor AI risks throughout the system lifecycle, providing a foundation for evaluating not only normal operation but also the organisation's ability to respond when risks materialise (NIST, 2023).

This leads to an important design principle: no critical GRC agent should possess more authority than the organisation can monitor, constrain and recover. Agentic capability should therefore be matched by corresponding capabilities for identity, permissions, observability, intervention and recovery. Greater autonomy without equivalent control and recovery capability would increase organisational exposure rather than necessarily increasing GRC effectiveness.

The strategic objective is therefore trusted and recoverable intelligence, rather than unrestricted automation. A mature AI-enabled GRC environment should demonstrate not only that its systems can generate useful intelligence and execute authorised activities, but also that their behaviour can be reconstructed, challenged, constrained and recovered when necessary.

15.6 Measuring the Shift from Reactive to Decision-Intelligent GRC

The five dimensions should not be treated as independent performance categories. Their greatest value emerges when they are interpreted as indicators of organisational maturity.

A useful maturity progression is:

Reactive → Preventive → Predictive → Adaptive → Decision-intelligent.

At the reactive stage, GRC primarily responds to incidents, audit findings, regulatory requests and control failures. Measurement focuses on whether required activities have been completed and whether identified issues have been remediated.

At the preventive stage, the organisation increasingly identifies risk conditions before they result in failure. Controls become more automated, evidence becomes more accessible, and risk management begins to influence operational processes rather than operating primarily as a retrospective assurance function.

At the predictive stage, GRC begins to combine historical information with current signals to anticipate emerging risks. AI-supported analytics, continuous monitoring and event-driven assurance become more prominent. The emphasis shifts from identifying what has happened to estimating what may happen next.

At the adaptive stage, the organisation can respond dynamically to changing risk conditions. Workflows, controls, monitoring thresholds and escalation mechanisms can adjust as the operating environment changes. This requires stronger integration between intelligence, workflow, authority and control execution.

At the decision-intelligent stage, GRC becomes an integrated organisational decision capability. Risk intelligence is embedded directly into material business decisions; controls operate continuously; AI and human expertise are coordinated; agents can undertake bounded activities under explicit authority; and the organisation learns systematically from outcomes, exceptions and failures.

This progression is important because maturity should not be inferred from technology adoption alone. An organisation with sophisticated AI but fragmented processes, weak data foundations and limited control over machine actions may remain operationally reactive. Conversely, an organisation with relatively modest AI capabilities but highly integrated data, continuous controls, strong decision rights and effective feedback mechanisms may demonstrate greater GRC maturity.

15.7 Measuring Transformation as a Closed-Loop Capability

Transformation measurement should ultimately become part of the transformation itself. Metrics should not simply be reported to a steering committee; they should provide feedback into the GRC operating model.

This creates a closed loop:

Measure → Evaluate → Learn → Redesign → Improve → Measure again.

For example, an increase in automation accompanied by declining decision quality should trigger workflow redesign. Improved detection accompanied by excessive false positives should prompt recalibration of risk models or thresholds. Reduced cycle times accompanied by increased control failures should indicate that efficiency gains have been achieved at the expense of control effectiveness. High AI override rates should trigger investigation into model quality, workflow design, user trust or inappropriate deployment boundaries. Repeated regulatory findings should prompt reassessment of the underlying control architecture rather than simply another remediation exercise.

Measurement should therefore operate at three levels.

First, activity metrics assess what the transformation is doing: tools deployed, processes automated, controls digitised and users trained.

Second, capability metrics assess what the organisation has become capable of doing: continuous monitoring, predictive risk detection, automated evidence generation, governed agentic execution and integrated decision support.

Third, outcome metrics assess whether those capabilities produce better organisational results: fewer material control failures, faster risk detection, better decisions, stronger resilience and more effective management intervention.

The third level is ultimately the most important. Activity without capability produces technology adoption. Capability without outcomes produces technical sophistication. Transformation is demonstrated when enhanced capabilities produce measurable improvements in organisational control and decision quality.

15.8 From AI Adoption Metrics to Transformation Metrics

The most significant measurement shift is therefore conceptual. Traditional technology programmes often ask whether systems have been implemented, users trained and automation targets achieved. An AI-enabled GRC transformation must ask a more demanding set of questions:

Can the organisation detect risk earlier? Can it understand risk more accurately? Can controls respond continuously? Can humans focus their judgement where it matters most? Can AI operate within clearly bounded authority? Can the organisation explain and evidence its decisions? Can it recover when AI fails? And, ultimately, are management decisions improving?

These questions align measurement with the broader transformation architecture established throughout this chapter. Data foundations should be measured through information quality and traceability; workflow transformation through cycle-time and process outcomes; governed agents through execution quality and recoverability; organisational control through accountability and intervention; continuous assurance through control coverage and change responsiveness; cybersecurity through identity, permission and behavioural control; workforce transformation through the effective allocation of human judgement; and ecosystem governance through visibility and management of external dependencies.

The resulting scorecard should therefore resist the temptation to reduce transformation to a single AI maturity score. GRC transformation is multidimensional, and weakness in one dimension can undermine apparent progress in another. High automation with weak resilience is not maturity. High predictive capability with poor accountability is not maturity. Extensive monitoring with ineffective decision rights is not maturity. AI deployment without measurable improvement in organisational control is not transformation.

The ultimate measure of success is consequently whether GRC has evolved from a retrospective compliance and reporting function into a continuously sensing, decision-supporting, control-executing and organisationally learning capability.

In this sense, the transformation journey can be understood as a progression from:

Reactive GRC → Preventive GRC → Predictive GRC → Adaptive GRC → Decision-Intelligent GRC.

The destination is not an organisation with more AI. It is an organisation that can sense more effectively, decide more intelligently, control more continuously, recover more reliably and learn more rapidly. AI becomes valuable precisely to the extent that it strengthens these organisational capabilities.

16. Target Architecture

The transformation of Governance, Risk and Compliance (GRC) described in the preceding chapters requires an architectural model capable of translating strategic principles into an operational technology and control environment. The target architecture should therefore not be understood as a conventional application stack or as a collection of AI technologies. It is better understood as a socio-technical control architecture in which external signals, organisational data, artificial intelligence (AI), workflow orchestration, enterprise systems, human authority and assurance mechanisms operate as an interconnected system.

The central architectural principle is that intelligence, authority and execution should be separated but tightly connected. AI systems should be able to analyse information, identify patterns, generate recommendations and support decisions without automatically possessing unrestricted authority to act. Where machine action is appropriate, execution should occur through governed interfaces, explicit permissions, observable workflows and verifiable control mechanisms. This distinction is consistent with the broader emphasis on human oversight, defined responsibilities and risk-based governance in AI management frameworks (NIST, 2023; ISO/IEC, 2023). It also reflects the importance of deliberately allocating activities between AI systems and human decision-makers rather than assuming that greater technical capability should automatically result in greater operational autonomy (Raisch and Krakowski, 2021).

The architectural implication is that capability should not be treated as authority. An AI system may possess the technical capability to access information, invoke tools or perform an action without being authorised to do so in a particular context. Authority should instead be established through explicit permissions, policy constraints, workflow controls and accountable decision rights. This creates a controlled connection between intelligence and execution while preventing analytical capability from becoming an implicit source of organisational authority.

The target architecture can therefore be conceptualised as a series of interconnected layers.

16.1 External Environment: The Source of Risk Signals

The architecture begins outside the organisation.

Regulation, financial and commercial markets, threat intelligence, geopolitical developments, suppliers, customers and broader ecosystem relationships generate signals that may alter the organisation's risk profile. These signals are increasingly dynamic and interconnected. Regulatory changes can affect products and processes; geopolitical developments can alter supply-chain exposure; cyber threats can affect third-party dependencies; customer behaviour can generate financial-crime or conduct-risk signals.

Traditional GRC architectures often treat much of this information as periodic input into discrete assessments. A transformed architecture instead treats the external environment as a continuous source of risk intelligence.

The architectural implication is that GRC should be capable of ingesting and contextualising relevant external signals rather than relying exclusively on internally maintained records. This reflects the broader enterprise risk-management perspective that organisational risk is shaped by interactions and interdependencies that may extend beyond the immediate organisational boundary (Bromiley et al., 2015). In an AI-enabled environment, ongoing risk identification and monitoring further require mechanisms for incorporating relevant information as risk conditions and external circumstances change (NIST, 2023).

The external environment therefore represents the sensing boundary of the GRC system. GRC should be able to observe relevant changes across customers, suppliers, technology providers, regulators, markets, geopolitical conditions and other material external dependencies, while applying appropriate governance to determine which signals are relevant, authoritative and proportionate to the organisation's risk-management objectives.

16.2 The GRC Intelligence Fabric

External signals and internal organisational information should converge within a GRC intelligence fabric comprising the data and knowledge foundations required for reliable analysis.

Core components include the data lakehouse, knowledge graph, regulatory corpus, risk data, policy repository and control library. These components should not operate as isolated repositories. Their strategic value comes from their relationships.

A regulation should be traceable to the obligations it creates; obligations should connect to policies; policies should connect to risks and controls; controls should connect to business processes and systems; and control execution should generate evidence and outcomes. This creates a traceability chain through which the organisation can understand not merely what information it possesses, but how individual pieces of information relate to organisational obligations, risks, decisions and controls.

The knowledge graph is particularly important because many GRC questions are relational rather than purely document-based. The organisation may need to determine which suppliers support a critical service, which regulations affect a particular product, which controls mitigate a specific risk, or which business processes depend upon a particular technology provider. Knowledge graphs provide a representation of entities and relationships that can make these dependencies more explicit and machine-interpretable (Hogan et al., 2021).

This architecture also reinforces the principle that AI readiness begins with the quality and structure of organisational information. AI cannot reliably compensate for fragmented definitions, inaccessible evidence, weak provenance or poorly governed data. Effective AI governance therefore depends on appropriate data management, documentation, traceability and accountability throughout the AI lifecycle (NIST, 2023; ISO/IEC, 2023). Structured information architectures can further strengthen the ability to connect relevant entities and relationships, supporting more contextualised retrieval and analysis (Hogan et al., 2021).

The GRC intelligence fabric consequently forms the organisational memory and contextual foundation of the architecture. It provides the information structures through which regulatory requirements, risks, controls, processes, systems, evidence and organisational relationships can be connected, interpreted and made available to AI systems and human decision-makers within appropriate governance boundaries.

16.3 The AI Intelligence Layer

Above the GRC intelligence fabric sits the AI intelligence layer.

This layer may contain large language models (LLMs), predictive models, classification systems, scenario-analysis capabilities, decision-intelligence applications and retrieval-augmented generation (RAG). These technologies perform different functions and should not be treated as interchangeable.

LLMs may interpret complex documents, synthesise evidence and support reasoning. Predictive models may identify patterns or estimate probabilities. Classification models may structure unstructured information. Scenario-analysis systems may explore potential future conditions. RAG can connect generative systems to controlled organisational and external knowledge sources.

However, retrieval alone does not create trustworthy GRC. A system may retrieve relevant information while still producing an inappropriate interpretation, acting outside its authority or relying on incomplete evidence. Consequently, the intelligence layer should be designed as one component of a broader control architecture rather than as the architectural centre of gravity.

This distinction is important because it prevents the target architecture from becoming model-centric. The organisation is not transforming GRC merely to introduce LLMs; it is developing a system capable of using different forms of computational intelligence appropriately within governed organisational processes.

The AI intelligence layer therefore provides interpretation, prediction, reasoning and decision support, but it does not inherently provide authority.

16.4 The Agentic Orchestration Layer

Where AI systems need to perform multi-step activities, an agentic orchestration layer connects intelligence with controlled execution.

This layer may include planning, tool calling, workflow orchestration, multi-agent coordination and verification. It enables AI systems to move beyond producing a response towards performing bounded sequences of activities.

For example, an agent may identify a regulatory change, retrieve the relevant policy, map the change to affected controls, identify impacted business processes, prepare an assessment and route the resulting exception to an accountable owner. Each step can be orchestrated through defined tools and workflow boundaries.

The architectural distinction between an AI model and an agent is therefore important. A model generates intelligence; an agent can use that intelligence to interact with systems and pursue an objective. The latter introduces substantially greater governance requirements because actions can have operational consequences.

Agentic orchestration should consequently incorporate verification, checkpoints, retries, timeouts and explicit transaction boundaries. High-impact actions should be capable of being paused or redirected, while failures should result in bounded degradation rather than uncontrolled continuation. These requirements become increasingly important as AI systems move from generating recommendations towards interacting with tools and taking actions within operational environments. The reasoning-and-acting paradigm illustrates how agentic systems can iteratively interact with external tools and environments, while AI governance frameworks emphasise the need for appropriate oversight, monitoring, accountability and risk management throughout the system lifecycle (Yao et al., 2023; NIST, 2023; ISO/IEC, 2023).

The orchestration layer therefore represents the bridge between machine intelligence and operational activity. Its purpose is not simply to coordinate AI tasks, but to provide the control mechanisms through which machine-generated decisions or actions can be authorised, monitored, interrupted, verified and recorded before they affect organisational processes or systems.

16.5 The Control Plane

The control plane is the architectural layer that determines what AI systems are permitted to do.

Its components include identity, permissions, policy enforcement, model governance, human approval, monitoring, logging and cost control. This layer is fundamental because intelligence without authority boundaries can create unacceptable organisational risk.

Identity should establish which human, service, model or agent is requesting an action. Permissions should define what that entity is allowed to access or execute. Policy enforcement should determine whether a proposed action complies with organisational and regulatory constraints. Human approval should provide intervention where material judgement or accountability is required. Monitoring and logging should make behaviour observable and reconstructable.

This architecture moves beyond conventional application security towards governed machine agency. A human employee may have authority to approve a transaction, but an AI agent acting on behalf of that employee should not automatically inherit unlimited authority. Machine permissions should be explicitly defined, limited to necessary functions and subject to contextual controls.

This principle is reinforced by an identity- and governance-centric cybersecurity perspective in which identity and access controls form an important part of the control architecture for AI-enabled systems. As AI systems increasingly interact with organisational data, applications and operational tools, effective governance requires clearly defined responsibilities, appropriate access controls, monitoring and mechanisms for intervention. NIST and ISO/IEC 42001 emphasise the importance of establishing governance structures, defined responsibilities, risk controls and ongoing monitoring across the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

The control plane therefore provides the architecture's authority, constraint and observability mechanism. It establishes which AI systems and users are authorised to perform particular activities, constrains those activities through policies and permissions, and provides the monitoring and evidence mechanisms required to determine whether actions remain within approved boundaries. In this sense, identity, authorisation and observability are not merely technical security functions; they are mechanisms through which organisational authority is translated into operational control.

16.6 Enterprise Systems: The Operational Context

The architecture must then connect to the systems in which organisational activity actually occurs.

These may include enterprise resource planning (ERP), customer relationship management (CRM), core banking platforms, human resources systems, procurement systems, IT service management (ITSM), security information and event management (SIEM), finance systems and existing GRC platforms.

This integration is critical because GRC cannot become decision-intelligent if intelligence remains isolated from the operational systems in which risks emerge and controls are executed.

For example, identifying a high-risk supplier should potentially influence procurement workflows; detecting a cybersecurity anomaly may need to trigger an incident-management process; identifying a regulatory change may require modification of a control; and detecting a customer-risk signal may require escalation within the appropriate business process.

Application programming interfaces (APIs), event-driven integration and interoperable data models therefore become strategic architectural capabilities. Digital business strategy research highlights the importance of integrating digital technologies with organisational processes and capabilities rather than treating technology as an isolated technical resource (Bharadwaj et al., 2013). From a GRC perspective, interoperability is particularly important because risk, control and compliance information must be able to move across organisational processes and systems where decisions and actions occur. This is also consistent with the enterprise risk-management perspective that emphasises the interactions and interdependencies between risks and organisational activities (Bromiley et al., 2015).

The enterprise-system layer consequently provides the operational context and execution environment for GRC intelligence. It connects GRC capabilities to the business applications, workflows, data and operational processes through which organisational decisions are made and controls are executed. In the proposed architecture, interoperability and architectural optionality therefore support not only technical integration but also the ability to maintain continuity, control and adaptability as systems, dependencies and operating conditions change.

16.7 Decision and Action

The next layer represents the point at which intelligence is converted into organisational consequences.

These consequences may include a risk decision, compliance action, control execution, escalation or remediation.

The critical architectural principle is that the transition from intelligence to action should be governed rather than automatic. Different decisions require different levels of authority. Low-risk and highly deterministic activities may be suitable for automated execution. More consequential activities may require recommendation followed by human approval. Certain decisions should remain firmly within human authority.

This creates a graduated relationship between intelligence and action:

Sense → Interpret → Recommend → Approve → Execute → Verify.

Not every process requires every stage to be performed manually, and not every stage needs human intervention. However, the architecture should make the authority boundary explicit. The more consequential, irreversible or difficult-to-explain the action, the stronger the requirement for human oversight, verification and intervention.

This is the architectural expression of the broader principle of meaningful human control developed throughout the transformation model.

16.8 Assurance and Learning

The final architectural layer closes the loop through assurance, performance monitoring and organisational learning. This layer includes outcome verification, audit trails, performance monitoring, incident learning and model evaluation. Its function is not merely to document what happened, but to determine whether the system performed as intended and whether the organisation should modify its controls, workflows or AI components. This reflects the lifecycle-oriented approach to AI risk management and governance emphasised by NIST and ISO/IEC 42001, which call for ongoing monitoring, evaluation, documentation and continual improvement (NIST, 2023; ISO/IEC, 2023).

Outcome verification is particularly important in agentic systems. Successful task completion should not be inferred solely from an agent reporting that it has completed an activity. Where actions have material consequences, the resulting state should be independently verified where appropriate. An agent instructed to update a control record, for example, should generate evidence that the intended change actually occurred. This reflects a broader accountability principle in which system activity and its consequences must remain sufficiently observable and attributable to support meaningful oversight (Novelli et al., 2024).

Audit trails should provide sufficient provenance to reconstruct relevant decisions and actions. Performance monitoring should identify changes in model quality, workflow outcomes and system behaviour. Incident learning should feed failure information back into control design, while model evaluation should determine whether continued use remains justified as data, models, prompts, tools and operating environments change. These activities support the broader requirement for AI systems to remain subject to ongoing risk management, monitoring and governance throughout their operational lifecycle (NIST, 2023; ISO/IEC, 2023).

The assurance layer therefore transforms the architecture from a one-directional processing pipeline into a closed-loop organisational control system. Rather than ending with execution or reporting, the architecture continually verifies outcomes, evaluates performance, captures evidence and feeds learning back into controls, workflows and AI components. Assurance consequently becomes an active mechanism for maintaining and improving organisational control rather than a retrospective documentation exercise.

16.9 Architectural Principles

Taken together, the target architecture rests on several interdependent principles.

First, context should precede intelligence. AI systems require access to authoritative, relevant and traceable organisational information if their outputs are to be useful.

Second, intelligence should be separated from authority. The ability to analyse or recommend should not automatically confer the ability to act.

Third, execution should be governed through explicit permissions and policies. Machine actions should occur within defined operational boundaries.

Fourth, high-impact actions should remain observable and verifiable. The organisation should be able to determine what happened, why it happened and whether the resulting outcome was correct.

Fifth, human judgement should be concentrated rather than eliminated. Human involvement should focus on ambiguity, materiality, exceptions, accountability and decisions where consequences justify intervention.

Sixth, failure should be expected and recoverable. Agents and AI systems should operate within architectures that support interruption, containment, rollback, escalation and recovery.

Seventh, evidence should be generated as part of normal operation. Assurance should not depend on reconstructing control evidence retrospectively.

Eighth, the architecture should remain interoperable and replaceable. Dependence on a particular model, vendor or technology should not become an unnecessary source of organisational concentration risk.

Finally, the architecture should learn from its own operation. Monitoring, incidents, overrides, control failures and outcomes should feed back into model evaluation, workflow redesign and governance improvement.

These principles reinforce the argument that AI-enabled GRC is fundamentally an architectural and organisational transformation rather than a software procurement exercise. The value of digital technologies depends on their integration with business processes and organisational capabilities rather than their deployment as isolated technological resources (Bharadwaj et al., 2013). Similarly, enterprise risk management emphasises the integration of risk considerations with organisational strategy and performance, supporting a view of GRC as an embedded organisational capability rather than a standalone compliance activity (COSO, 2017).

For AI-enabled GRC, this transformation also requires governance mechanisms to be embedded within the systems, processes and decision structures through which AI is developed and used. NIST and ISO/IEC 42001 emphasise governance, defined responsibilities, risk management, monitoring and continual improvement across the AI lifecycle (NIST, 2023; ISO/IEC, 2023). GRC therefore becomes part of the architecture through which organisational decisions are informed, controls are exercised and AI-enabled activities are monitored and governed.

16.10 From Technology Stack to Organisational Control Architecture

The target architecture can therefore be understood as a continuous chain:

External signals → GRC intelligence → AI interpretation → Governed orchestration → Controlled execution → Enterprise action → Assurance → Learning.

The importance of this chain lies in its integration. A highly capable AI model without trusted data produces unreliable intelligence. Trusted data without workflow integration produces information without action. Automated workflows without a control plane can create uncontrolled machine activity. Strong controls without operational integration can become disconnected governance mechanisms. Execution without assurance prevents the organisation from knowing whether the system actually worked. Assurance without learning produces recurring findings rather than organisational improvement.

The architecture must therefore operate as a system rather than a collection of components.

Its strategic purpose is to connect sensing, intelligence, authority, execution and learning while preserving accountability at every stage. This provides the architectural foundation for the transformation described throughout this chapter: GRC moves from a collection of periodic processes towards a continuously operating organisational capability.

16.11 Conclusion: The Architecture of Decision-Intelligent GRC

The target architecture represents the convergence of the major transformation themes developed throughout this work. Data infrastructure provides trusted organisational context. AI provides analytical and reasoning capability. Agentic orchestration provides bounded operational execution. The control plane establishes identity, authority and policy boundaries. Enterprise integration connects GRC to real organisational activity. Assurance provides verification and evidence. Learning creates the feedback required for continuous adaptation.

The fundamental design principle is therefore simple but consequential:

AI should be capable of intelligence without possessing unrestricted authority; when it is authorised to act, its actions should remain constrained, observable, verifiable and recoverable.

This separation allows organisations to capture the benefits of AI and agentic systems without collapsing the distinction between recommendation and authority, or between intelligence and execution. It also creates an architecture capable of supporting the maturity progression established in the previous chapter—from reactive and preventive GRC towards predictive, adaptive and ultimately decision-intelligent GRC.

The target state is consequently not an AI-enabled GRC platform in the conventional sense. It is an integrated organisational control architecture in which data, intelligence, workflows, agents, enterprise systems, humans and assurance mechanisms operate as a coherent system.

In this architecture, GRC no longer sits beside the business as a retrospective assurance function. It becomes embedded within the mechanisms through which the organisation senses risk, interprets uncertainty, makes decisions, executes controls, responds to change and learns from outcomes.

That is the architectural foundation of decision-intelligent GRC.

17. Strategic Principles

The transformation of Governance, Risk and Compliance (GRC) requires more than a technology roadmap, target architecture or portfolio of artificial intelligence (AI) use cases. It requires a set of principles that govern how the organisation makes choices about technology, authority, control, assurance and organisational design.

These principles provide the normative foundation for the transformation described throughout this work. They establish boundaries around where AI should be applied, how machine authority should be allocated, how evidence and accountability should be maintained, and how GRC should create value beyond the prevention of regulatory or operational failure.

Taken together, the ten principles define a transition from technology-led GRC automation towards decision-intelligent organisational control.

17.1 Principle 1 — Business Before Technology

GRC transformation should begin with material business decisions, processes and risks, rather than with the capabilities of a particular AI model.

Technology-led transformation frequently begins by asking what an AI system can do. This reverses the appropriate sequence. The more important question is where better intelligence, faster control execution or improved decision-making could create meaningful organisational value.

The starting point should therefore be the identification of significant business processes and decisions in which GRC currently creates friction, delay, uncertainty or insufficient visibility. Examples may include customer onboarding, regulatory change management, third-party risk, financial-crime monitoring, cybersecurity response, operational resilience and risk acceptance.

AI should then be evaluated against these problems rather than introduced as an objective in its own right. This reflects the broader principle that the value of digital technologies depends on their integration with business processes and organisational capabilities rather than technology deployment alone (Bharadwaj et al., 2013). In the context of AI, this also requires consideration of how tasks, judgement and decision-making are allocated between human and machine capabilities, rather than assuming that greater automation necessarily produces greater organisational value (Raisch and Krakowski, 2021).

The practical implication is straightforward: define the business problem, determine the required control outcome, redesign the process, and only then select the appropriate technology. This approach positions AI as an enabling capability within a broader process and control transformation, rather than as the starting point or objective of GRC transformation.

17.2 Principle 2 — Intelligence Before Autonomy

Organisations should establish trustworthy information and decision capabilities before granting AI agents significant execution authority.

Agentic AI creates the possibility of moving from systems that generate recommendations towards systems that perform actions. However, autonomy magnifies weaknesses in data, permissions, workflows and governance. An agent operating on poor information or within an unclear authority structure can convert an information-quality problem into an operational event.

The transformation should therefore follow a progression from trusted data → contextual intelligence → decision support → bounded execution → controlled autonomy.

This does not imply that organisations must wait until every GRC process is fully mature before deploying agents. Rather, autonomy should be proportional to demonstrated control maturity. Low-risk, reversible and observable activities may justify earlier automation, while material or irreversible activities should require stronger evidence of control effectiveness.

Autonomy should consequently be earned through demonstrated reliability, governance and recoverability, rather than granted merely because the underlying technology makes it possible. As AI systems move from generating recommendations towards interacting with tools and taking actions, the governance requirements associated with their operational use become more significant (Yao et al., 2023). NIST and ISO/IEC 42001 similarly emphasise risk-based governance, appropriate oversight, monitoring and continual evaluation across the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

The principle is therefore that increasing technical capability should not automatically result in increasing operational authority. Autonomy should expand only when the organisation can demonstrate that the relevant system can operate within defined boundaries, remain observable and controllable, and be appropriately interrupted or recovered when required.

17.3 Principle 3 — Separate Intelligence from Execution

AI intelligence and organisational authority should be architecturally distinct. An AI system may identify a risk, interpret a regulation, classify an event, recommend a control response or propose a remediation action. None of these capabilities should automatically imply that the system is authorised to execute the recommendation. The distinction between automation and augmentation is important here because the deployment of AI does not, by itself, determine how decision rights and responsibilities should be allocated between humans and machines (Raisch and Krakowski, 2021).

The control plane should determine whether an action is permitted, under what conditions and with what level of human involvement. Identity, permissions, policy enforcement, approval mechanisms, monitoring and logging therefore become fundamental components of AI-enabled GRC. This is consistent with the emphasis placed by NIST and ISO/IEC 42001 on defined responsibilities, governance mechanisms, risk controls, monitoring and oversight throughout the AI lifecycle (NIST, 2023; ISO/IEC, 2023).

This separation creates a critical distinction between what an AI system believes should happen and what the organisation has authorised it to do. The distinction becomes particularly important for agentic systems because the transition from generating information or recommendations towards interacting with tools and taking actions increases the potential organisational consequences of AI behaviour. Agentic systems can combine reasoning with external actions, making appropriate governance of their operating boundaries increasingly important (Yao et al., 2023).

The architectural consequence is that intelligence may inform authority, but intelligence should not define authority. In the proposed GRC architecture, AI can contribute analysis, interpretation and recommendations, while authority remains established through explicit organisational decision rights, permissions, policies and approval mechanisms. Execution must consequently remain governed, observable and subject to appropriate intervention.

17.4 Principle 4 — Continuous Rather Than Periodic

Where economically and technically appropriate, GRC should move from periodic assessment towards continuous sensing, monitoring, control execution and verification. Traditional GRC frequently operates according to reporting calendars: annual assessments, quarterly reviews, periodic control testing and scheduled certifications. Such mechanisms can create periods between assessment points during which material changes in the risk environment may not be fully reflected in the organisation's control activities.

This becomes increasingly significant in environments characterised by rapidly changing regulation, cyber threats, suppliers, markets, technologies and AI systems. Enterprise risk management recognises that risks interact and evolve across organisational activities and dependencies, reinforcing the importance of maintaining an understanding of changing risk conditions rather than treating exposures as static (Bromiley et al., 2015). NIST and ISO/IEC 42001 similarly emphasise ongoing risk management, monitoring and evaluation across the AI lifecycle (NIST, 2023; ISO/IEC, 2023). Continuous monitoring therefore allows material changes to become triggers for assessment and intervention rather than requiring the organisation to wait for the next scheduled review.

This principle does not mean that every GRC activity must become real-time. Continuous control should be proportional to risk, cost, technical feasibility and the volatility of the underlying environment. The objective is instead to align monitoring frequency with risk dynamics, so that higher-velocity or higher-consequence risks receive more timely monitoring and intervention while lower-risk activities can remain subject to proportionate periodic review.

The resulting shift is from:

Periodic assessment → continuous sensing → event-driven response → continuous assurance.

This paper develops this principle through the concept of Continuous AI Compliance and Assurance (CAICA), in which material changes to models, data, policies, regulations, controls and operating environments can trigger reassessment throughout the AI lifecycle. CAICA therefore extends conventional periodic assurance towards a more continuous, risk-responsive model of governance and control, consistent with the lifecycle-oriented monitoring and continual-improvement principles reflected in NIST and ISO/IEC 42001 (NIST, 2023; ISO/IEC, 2023).

17.5 Principle 5 — Evidence by Design

Every material AI-supported decision or action should produce sufficient evidence to allow its reconstruction and evaluation.

Evidence should not be treated as an administrative output generated after the decision has been made. It should be designed into the architecture and produced as part of normal operation. This reflects the emphasis placed by NIST and ISO/IEC 42001 on documentation, traceability, monitoring and accountability as integral elements of AI governance and lifecycle management (NIST, 2023; ISO/IEC, 2023).

For a material AI-supported decision, relevant evidence may include the information and sources considered, the applicable policy or rule, the model or agent involved, the decision or recommendation produced, the permissions exercised, human interventions, approvals, exceptions and resulting outcomes. Such evidence supports the ability to understand not only what the system produced, but also the governance context in which the decision or action occurred. This is consistent with broader conceptions of AI accountability that emphasise the ability to establish responsibility for system behaviour and its consequences (Novelli et al., 2024).

The objective is not to record every computational detail indiscriminately. Rather, evidence should be proportionate to materiality and sufficient for accountability, assurance, investigation and regulatory scrutiny. The depth and granularity of evidence should therefore reflect the potential consequences of the decision or action, the applicable governance requirements and the organisation's need to demonstrate that appropriate controls were operating.

This principle also changes the economics of assurance. If evidence is generated automatically through governed workflows, assurance becomes less dependent upon retrospective evidence collection. Auditability can consequently become an inherent property of the operating model rather than a periodic administrative exercise. Continuous documentation and monitoring also enable organisations to identify changes in system behaviour and control performance more promptly, supporting ongoing governance and improvement (NIST, 2023; ISO/IEC, 2023).

Evidence by design therefore supports the broader transition from governance claims to demonstrable organisational control. Rather than merely asserting that AI systems are governed, the organisation should be capable of producing appropriate evidence showing how decisions were made, what authority was exercised, what controls operated and what outcomes resulted.

17.6 Principle 6 — Human Control Must Be Substantive

Human oversight is meaningful only when humans possess the authority, information, competence and time required to challenge AI outputs.

The mere presence of a human approval step does not constitute effective human control. If an employee receives an AI recommendation but lacks sufficient information to evaluate it, has no practical ability to reject it, or is expected to review hundreds of machine-generated decisions under severe time pressure, human involvement may be nominal rather than substantive.

Meaningful human control therefore requires appropriately designed intervention mechanisms. Humans should understand when AI outputs require scrutiny, have access to relevant evidence, possess authority to intervene and be able to escalate uncertain or material cases.

Human judgement should also be concentrated where it adds the greatest value: ambiguous cases, material decisions, exceptions, ethical or legal judgement, risk acceptance and situations in which consequences are significant or difficult to reverse.

The objective is therefore not human-in-the-loop by default, but human control where human authority and judgement are genuinely necessary.

This principle reinforces the broader human–AI complementarity model developed earlier: AI can expand analytical capacity while human professionals retain accountability for decisions requiring contextual judgement and organisational authority.

17.7 Principle 7 — Design for Failure

Critical GRC systems should be designed on the assumption that AI systems, integrations, data sources and human processes will sometimes fail.

Potential failures include inaccurate model outputs, hallucination, incomplete retrieval, stale information, data-quality problems, tool failures, permission errors, prompt injection, integration outages, model degradation and inappropriate human reliance on automated recommendations.

The appropriate objective is therefore not perfect prevention. It is safe failure and rapid recovery.

Critical systems should be capable of detecting anomalous behaviour, constraining actions, escalating uncertainty, interrupting execution, reverting changes where feasible and preserving sufficient evidence for investigation. Agentic workflows should incorporate checkpoints, transaction boundaries, verification and bounded permissions.

This creates a resilience sequence:

Detect → Constrain → Fail safely → Escalate → Recover → Learn.

Designing for failure also changes the definition of system reliability. A system should not be considered resilient simply because it performs correctly under normal conditions. Its resilience depends on whether the organisation can retain control when conditions deviate from expectations.

As established in the preceding transformation framework, no critical GRC agent should possess more authority than the organisation can monitor, constrain and recover.

17.8 Principle 8 — Treat Data as Infrastructure

Data should be treated as a foundational organisational infrastructure rather than as a passive input to AI systems.

AI readiness depends upon data quality, semantic consistency, interoperability, provenance, lineage, accessibility and governance. Weaknesses in these areas can propagate directly into risk decisions, automated controls and agentic actions.

The organisation should therefore develop trusted data foundations capable of connecting regulations, obligations, policies, risks, controls, processes, systems, evidence and outcomes. Data should be traceable to authoritative sources, governed according to appropriate access requirements and represented in forms that both humans and machines can interpret reliably

This is particularly important as GRC moves towards knowledge graphs, retrieval-augmented generation, predictive analytics and agentic workflows. AI systems require contextual information, but the usefulness of that information depends on its relevance, provenance, reliability and governance. Knowledge graphs provide mechanisms for representing connected entities and relationships, while retrieval-augmented generation enables AI systems to access information from external knowledge sources (Hogan et al., 2021; Lewis et al., 2020). These capabilities increase the importance of understanding the sources, context and governance status of the information used by AI systems. NIST and ISO/IEC 42001 similarly emphasise appropriate data management, documentation, governance and lifecycle controls for AI systems (NIST, 2023; ISO/IEC, 2023).

Consequently, data governance should become data infrastructure: principles must be translated into operational mechanisms for quality, access, lineage, provenance, retention and control. The objective is not simply to establish policies governing data, but to embed those principles into the information architecture so that data can be accessed, interpreted and used within appropriate governance boundaries by both human and AI-enabled processes.

17.9 Principle 9 — Preserve Optionality

Organisations should avoid unnecessary dependence on individual AI models, vendors, platforms or architectural approaches. AI capabilities are developing rapidly, making long-term technological assumptions difficult to sustain. Excessive dependence on a particular model provider, proprietary data structure or tightly coupled platform can create switching costs, concentration risk and constraints on future innovation. From an enterprise risk-management perspective, such dependencies should be considered in relation to their interactions with other organisational exposures rather than treated as isolated supplier risks (Bromiley et al., 2015).

Optionality therefore becomes a strategic GRC capability. Architectures should favour interoperability, modularity, portable data, explicit interfaces and replaceable components where economically justified. Digital business strategy research similarly highlights the importance of integrating digital capabilities with organisational processes and capabilities, reinforcing the value of architectures that can evolve as business and technological requirements change (Bharadwaj et al., 2013). Contracts with technology providers should also address issues such as data portability, model changes, service continuity, security, audit rights and exit arrangements where these are material to the organisation's risk exposure.

This principle extends the concept of third-party risk into architectural dependency risk. The question is not simply whether a technology provider is acceptable today, but whether the organisation retains the ability to change providers, substitute components or modify its operating model if circumstances require it. This is particularly important where an AI dependency supports a critical business process or control and therefore creates consequences beyond the immediate supplier relationship. AI risk-management principles likewise require organisations to consider dependencies, risks and controls throughout the AI lifecycle rather than treating deployment as a one-time technology decision (NIST, 2023).

Optionality should therefore not be interpreted as avoiding standardisation. Rather, it means avoiding unnecessary and strategically dangerous lock-in. Standardisation can improve consistency and control, while modularity and interoperability preserve the ability to adapt when technology, risk conditions, regulatory requirements or strategic priorities change.

17.10 Principle 10 — Make GRC a Source of Advantage

The ultimate purpose of GRC transformation is not merely to prevent failure.

GRC exists within an environment of uncertainty in which organisations must continuously make decisions about customers, markets, investments, suppliers, technologies, products and strategic opportunities. Effective GRC should therefore help the organisation understand uncertainty and act within appropriate risk boundaries.

AI creates an opportunity to transform GRC from a predominantly defensive function into a source of decision advantage. Better risk intelligence can support faster market decisions. More continuous compliance intelligence can accelerate product development. Improved third-party visibility can strengthen procurement and resilience. Better control automation can reduce operational friction. Integrated decision intelligence can allow management to understand risk and opportunity together rather than treating compliance as an external constraint.

This does not mean weakening control requirements in pursuit of commercial outcomes. Rather, it means recognising that strong GRC can enable organisations to operate confidently within uncertainty by connecting risk management and control capabilities with organisational strategy and performance (COSO, 2017).

The strategic objective is therefore to move from:

Compliance as constraint → GRC as control capability → GRC as decision capability → GRC as competitive advantage.

This progression reflects the broader principle that digital capabilities create organisational value when they are integrated with business processes and organisational capabilities rather than deployed as isolated technologies (Bharadwaj et al., 2013). In the context of AI-enabled GRC, the objective is therefore not simply to automate existing compliance activities, but to improve how risk information, control intelligence and human–AI capabilities contribute to organisational decisions (Raisch and Krakowski, 2021).

The strategic value of GRC consequently arises when stronger control and assurance capabilities enable better-informed, more timely and more confident decisions without compromising the organisation's risk appetite, accountability or governance requirements.

17.11 The Principles as an Integrated System

The ten principles should not be implemented independently. Their value emerges from their interaction.

Business before technology determines where transformation should begin. Intelligence before autonomy determines how quickly machine authority should expand. Separation of intelligence and execution establishes the architectural boundary between recommendation and action. Continuous operation determines how GRC responds to changing conditions. Evidence by design establishes the basis for accountability and assurance. Substantive human control preserves meaningful organisational authority. Design for failure creates resilience when systems behave unexpectedly. Data as infrastructure provides the foundation for trustworthy intelligence. Optionality prevents transformation from creating excessive technological dependency. Finally, GRC as advantage establishes the strategic purpose of the entire transformation.

Together, the principles create a coherent control philosophy:

Sense → Understand → Decide → Authorise → Act → Verify → Learn.

Each stage should be supported by appropriate data, technology, human judgement and governance mechanisms. No single AI capability can provide the complete system.

The principles also establish an important boundary around the meaning of transformation. An organisation should not claim to have transformed GRC merely because it has deployed AI tools, introduced chatbots, automated document review or established an AI governance committee. Transformation occurs when these technologies become integrated into a redesigned organisational system in which information is trusted, decisions are improved, authority is explicit, actions are controlled, evidence is generated and learning is continuous.

17.12 Conclusion: Principles for Decision-Intelligent GRC

The ten strategic principles provide the normative foundation for the target state developed throughout this work. They establish that GRC transformation should be business-led, intelligence-driven, continuously operated, evidence-based, human-accountable, resilient, data-centric and architecturally flexible.

Most importantly, they redefine the purpose of GRC.

The objective is not to create an organisation in which machines perform an increasing proportion of compliance tasks. Nor is it to maximise automation or minimise human involvement. The objective is to create an organisational capability that can sense changes earlier, interpret risk more effectively, make better decisions, execute controls appropriately, recover from failure and learn continuously.

The resulting transformation can therefore be expressed as a progression:

Technology adoption → Process transformation → Intelligent control → Governed autonomy → Decision intelligence.

At its mature state, GRC becomes neither a reporting function nor a technology layer operating beside the business. It becomes part of the organisational infrastructure through which decisions are made and controlled.

The ultimate strategic principle is therefore that GRC should not merely protect the organisation from uncertainty; it should increase the organisation's capacity to operate intelligently within it.

18. Conclusion

The emergence of artificial intelligence, generative AI and agentic systems represents a structural challenge to traditional Governance, Risk and Compliance (GRC). The central issue is not whether GRC functions should adopt AI, but whether existing GRC operating models remain adequate for an environment in which risk signals are increasingly continuous, organisational dependencies increasingly interconnected, and machines increasingly capable of interpreting information and executing actions.

This paper has argued that they do not.

Traditional GRC was largely designed around a world of periodic assessments, stable processes, identifiable organisational boundaries and human-mediated control execution. Its mechanisms remain valuable, but their limitations become increasingly visible when applied to rapidly changing regulatory, technological, cyber, geopolitical and ecosystem conditions. Point-in-time assessments cannot fully capture continuously changing risk. Static control inventories provide limited insight into dynamic dependencies. Periodic assurance may provide evidence of historical compliance without establishing whether controls remain effective today. Manual workflows can create unnecessary friction while simultaneously limiting the scale and timeliness of risk intelligence.

AI creates the possibility of addressing some of these limitations, but technology alone is insufficient. The analysis developed throughout this paper demonstrates that the value of AI depends on the organisational environment into which it is introduced. Trusted data, interoperable architecture, redesigned workflows, explicit decision rights, governed machine permissions, human expertise, continuous assurance and organisational learning are prerequisites for sustainable transformation. Consequently, AI should be understood as a catalyst for GRC operating-model transformation, rather than as another technology layer added to an existing control environment.

18.1 From Periodic GRC to Continuous Organisational Control

The first major conclusion is that GRC should evolve from a predominantly periodic function towards a continuously operating organisational capability.

The transformation is not simply a matter of increasing monitoring frequency. It involves changing the underlying architecture of GRC. Regulations, market conditions, cyber threats, supplier dependencies, customer behaviour and operational events should increasingly be treated as continuous sources of risk signals. These signals should feed into trusted GRC intelligence infrastructure, where they can be contextualised, analysed and connected to relevant risks, obligations, controls, processes and decisions.

This creates a transition from:

Periodic assessment → continuous sensing → event-driven response → continuous assurance.

Such a model is more consistent with the dynamic nature of contemporary risk. It also creates the possibility of identifying emerging conditions before they become control failures or material incidents.

However, continuous GRC should remain proportional. Not every control requires real-time monitoring, and not every risk warrants continuous intervention. The appropriate objective is to align the frequency and intensity of monitoring with the volatility, materiality and potential consequences of the underlying risk.

18.2 From AI Governance to Organisational Control

A second conclusion is that AI governance cannot remain primarily a framework, policy or oversight activity.

Governance becomes meaningful only when it affects what systems are permitted to do. This requires governance principles to be translated into operational mechanisms such as identity, permissions, policy enforcement, workflow controls, approval gates, monitoring, logging, evidence and escalation.

This distinction becomes particularly important with agentic AI. A model that produces a recommendation presents one class of governance challenge; an agent capable of accessing enterprise systems and executing actions presents another. The architecture must therefore distinguish between intelligence, authority and execution.

An AI system may identify what should happen. The control plane must determine whether the organisation has authorised that action. The execution environment must constrain the action accordingly. Assurance mechanisms must subsequently establish whether the action occurred as intended.

This creates a fundamental control principle:

Intelligence may inform authority, but intelligence should not define authority.

The resulting approach moves beyond the notion of AI governance as an oversight layer and towards AI governance as an operational control system.

18.3 From Automation to Governed Autonomy

The analysis also demonstrates that the strategic question is not whether AI should be autonomous, but where and under what conditions autonomy is appropriate.

Some GRC activities are highly repetitive, rules-constrained, reversible and observable and may therefore be suitable for substantial automation or bounded agentic execution. Others involve regulatory interpretation, material financial consequences, legal judgement, risk acceptance, disciplinary decisions or high-impact customer outcomes and should retain stronger human authority.

This leads to a model of graduated autonomy:

Assist → Recommend → Approve → Execute within bounds → Adapt under governance.

Autonomy should be earned through demonstrated reliability, control maturity, observability and recoverability. It should not be granted merely because a technology can technically perform a task.

This principle also challenges simplistic measures of AI maturity. The most advanced organisation is not necessarily the one with the greatest number of autonomous agents. It may instead be the organisation that has developed the most sophisticated understanding of where autonomy creates value and where human authority remains essential.

18.4 From Control Prevention to Organisational Resilience

A further conclusion is that intelligent GRC must be designed for failure.

AI systems will sometimes produce incorrect outputs, retrieve incomplete information, encounter tool failures, operate with stale data, experience integration problems or become exposed to adversarial behaviour. Human users may also over-rely on automated recommendations. Third-party providers may experience outages or change models and services in ways that alter the organisation's risk profile.

The objective should therefore not be to construct an apparently infallible AI environment. It should be to construct an environment in which failure is bounded, observable, recoverable and learnable.

Critical GRC agents should operate with constrained permissions, transaction boundaries, verification mechanisms, checkpoints and escalation paths. Where failure occurs, the organisation should be capable of containing the impact, preserving evidence, recovering the affected process and learning from the event.

This represents a shift from conventional control thinking towards resilience engineering:

Detect → Constrain → Fail safely → Escalate → Recover → Learn.

The resulting GRC capability is stronger not because failure has been eliminated, but because the organisation has increased its capacity to operate safely when failure occurs.

18.5 From GRC Workforce Replacement to Human–AI Complementarity

The transformation also changes the role of the GRC professional.

The evidence and conceptual analysis developed in this paper do not support a simplistic substitution narrative in which AI replaces human GRC expertise. Instead, AI changes the allocation of work. Machines are increasingly capable of processing large information volumes, identifying patterns, classifying information, monitoring events and performing bounded repetitive activities. Human professionals remain critical for contextual interpretation, accountability, ethical judgement, ambiguity, escalation and decisions involving material organisational consequences.

The future GRC workforce should therefore be understood as a human–AI control system.

The GRC professional increasingly becomes a risk interpreter, decision adviser, control architect and AI supervisor. Traditional expertise in regulation, risk, controls and business processes remains essential because AI systems require domain context and because organisational accountability cannot simply be delegated to a model.

Workforce transformation is therefore not fundamentally a headcount programme. It is a redesign of where human judgement is deployed and where machine capability can augment it.

18.6 From Enterprise GRC to Ecosystem Governance

Another major conclusion is that organisational boundaries are becoming increasingly inadequate as the primary boundary for GRC.

Modern organisations depend upon complex networks of technology providers, cloud platforms, suppliers, partners, financial infrastructure, customers and other external relationships. AI adds further dependency layers through model providers, data providers, foundation-model infrastructure, software components and agentic services.

Risk therefore propagates through relationships.

This requires a transition from isolated counterparty assessment towards dependency intelligence and ecosystem governance. Third-party risk should increasingly consider fourth-party dependencies, concentration risk, data location, model provenance, interoperability, cyber resilience, geopolitical exposure and the organisation's ability to exit or replace critical dependencies.

Controlled optionality consequently becomes a strategic GRC capability. An organisation that cannot change a critical supplier, technology provider or AI model without unacceptable disruption has created a structural dependency that itself requires governance.

GRC must therefore increasingly understand not only the organisation's internal controls, but the network of relationships through which organisational risk is created and transmitted.

18.7 From Measurement of Activity to Measurement of Capability

The transformation cannot be governed effectively without changing how success is measured.

Counting AI tools, automated processes or deployed agents provides evidence of activity but not necessarily evidence of transformation. The more meaningful measures concern whether the organisation can detect risks earlier, operate controls more effectively, make decisions more quickly and appropriately, recover from AI failure and demonstrate trustworthy machine behaviour.

The proposed measurement framework therefore focuses on five dimensions:

Risk intelligence → Operational efficiency → Control effectiveness → Decision quality → Trust and resilience.

These dimensions provide a basis for evaluating the progression from:

Reactive → Preventive → Predictive → Adaptive → Decision-intelligent.

This maturity model is important because it prevents technological sophistication from being mistaken for organisational maturity. A highly automated GRC environment may remain fundamentally reactive if its data is fragmented, decisions are poorly integrated and controls remain retrospective. Conversely, an organisation with relatively modest AI capabilities may demonstrate greater maturity if its information, processes, decision rights and assurance mechanisms are well integrated.

The ultimate measure of transformation is therefore improved organisational capability and outcomes, not technology adoption.

18.8 The Target State: Decision-Intelligent GRC

The target architecture developed in this paper provides the structural expression of these conclusions.

External signals feed a GRC intelligence fabric. The intelligence fabric provides contextual information to AI systems. AI capabilities interpret, predict and recommend. Agentic orchestration connects intelligence to bounded workflows. A control plane establishes identity, permissions, policy and approval requirements. Enterprise systems provide operational context and execution environments. Assurance mechanisms verify outcomes, preserve evidence and feed learning back into the system.

The resulting architecture can be expressed as:

Sense → Understand → Decide → Authorise → Act → Verify → Learn.

This is fundamentally different from the traditional GRC model of:

Assess → Report → Remediate → Repeat.

The former is continuous, interconnected and adaptive. The latter is predominantly periodic and retrospective.

The target state should not be interpreted as a fully autonomous GRC environment. Indeed, the analysis suggests that complete autonomy is neither necessary nor desirable. The objective is a decision-intelligent GRC system in which machines perform appropriate analytical and operational tasks while humans retain meaningful authority over consequential decisions.

Such a system is capable of sensing changes in the external and internal environment, interpreting their significance, connecting them to organisational obligations and controls, recommending or executing proportionate responses, verifying outcomes and learning from experience.

18.9 The Strategic Significance of the Transformation

The broader implication is that GRC should no longer be positioned solely as a defensive organisational function.

When designed effectively, GRC can become a source of organisational advantage. Better risk intelligence can accelerate decisions. Continuous compliance can reduce the friction associated with product and process change. Integrated third-party intelligence can strengthen resilience. Automated evidence generation can reduce assurance costs. Governed AI can increase analytical capacity while preserving accountability.

The purpose is not to reduce the importance of control. It is to make control more intelligent, more timely and more closely connected to organisational decision-making.

This reframes the strategic relationship between risk and opportunity. Strong GRC does not merely prevent an organisation from doing something. It helps determine how the organisation can act confidently within acceptable boundaries of uncertainty.

The ultimate progression is therefore:

Compliance as constraint → GRC as control capability → GRC as decision capability → GRC as strategic advantage.

18.10 Final Conclusion

The transformation of GRC in the age of AI is ultimately a transformation in how organisations understand and exercise control.

It is not fundamentally about deploying larger language models, building more chatbots, automating more assessments or creating more AI governance committees. These may be components of the transformation, but none constitutes the transformation itself.

The deeper change is the emergence of a new organisational model in which data becomes infrastructure, intelligence becomes continuous, workflows become adaptive, machine authority becomes explicit, controls become executable, assurance becomes continuous, failure becomes recoverable, human expertise becomes more strategically focused, and ecosystem dependencies become visible and governable.

The ten strategic principles developed in this work provide the normative foundation for that model: business before technology; intelligence before autonomy; separation of intelligence from execution; continuous rather than periodic control; evidence by design; substantive human control; design for failure; data as infrastructure; preservation of optionality; and GRC as a source of organisational advantage.

Together, these principles lead to a single overarching proposition:

The future of GRC is not AI-automated compliance. It is decision-intelligent organisational control.

Decision-intelligent GRC represents the point at which risk, compliance, technology, data, cybersecurity, operations and management decision-making become interconnected within a continuously learning control system. Its purpose is not to eliminate uncertainty, because uncertainty is an inherent characteristic of organisational activity. Its purpose is to increase the organisation's capacity to sense uncertainty, interpret it, act within appropriate boundaries, control machine behaviour, recover from failure and learn from outcomes.

The most mature organisation will therefore not necessarily be the one with the most AI.

It will be the one that can use AI most intelligently while retaining the authority, evidence, resilience and human judgement necessary to remain in control.

References

Aldasoro, I., Gambacorta, L., Korinek, A., Shreeti, V. and Stein, M. (2024), Intelligent financial system: how AI is transforming finance, BIS Working Papers No. 1194, Bank for International Settlements, June 2024.

Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P. and Roberts, K. (2024) Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: National Institute of Standards and Technology.

Aven, T. (2020) ‘Risk Science Contributions: Three Illustrating Examples’, Risk Analysis, 40, pp. 1889–1899.

Barabási, A.-L. and Pósfai, M. (2016) Network Science. Cambridge: Cambridge University Press.

Bharadwaj, A.S. (2000) ‘A resource-based perspective on information technology capability and firm performance: an empirical investigation’, MIS Quarterly, 24(1), pp. 169–196.

Bharadwaj, A., El Sawy, O.A. and Pavlou, P.A. (2013) ‘Digital business strategy: toward a next generation of insights’, MIS Quarterly, 37(2), pp. 471–482.

Bromiley, P., McShane, M., Nair, A. and Rustambekov, E. (2015) ‘Enterprise risk management: review, critique, and research directions’, Long Range Planning, 48(4), pp. 265–276.

Brynjolfsson, E., Li, D. and Raymond, L.R. (2025) ‘Generative AI at work’, The Quarterly Journal of Economics, 140(2), pp. 889–942.

COSO (2017) Enterprise Risk Management—Integrating with Strategy and Performance. Durham, NC: Committee of Sponsoring Organizations of the Treadway Commission.

Davenport, T.H. and Harris, J.G. (2007) Competing on Analytics: The New Science of Winning. Boston, MA: Harvard Business School Press.

European Union (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.

Financial Action Task Force (FATF) (2017) Anti-Money Laundering and Terrorist Financing Measures and Financial Inclusion, with a Supplement on Customer Due Diligence. Paris: FATF.

Financial Action Task Force (FATF) (2021) Guidance on Risk-Based Supervision. Paris: FATF.

Fenton, N. and Neil, M. (2019) Risk Assessment and Decision Analysis with Bayesian Networks. 2nd ed. Chapman & Hall/CRC.

Helbing, D. (2013) ‘Globally networked risks and how to respond’, Nature, 497, pp. 51–59.

Hogan, A., Blomqvist, E., Cochez, M. et al. (2021) ‘Knowledge graphs’, ACM Computing Surveys, 54(4), pp. 1–37.

ISO (2018) ISO 31000: Risk Management Guidelines. Geneva: International Organization for Standardization.

ISO/IEC (2023) ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: International Organization for Standardization.

Ivanov, D. and Dolgui, A. (2021) ‘OR-methods for coping with the ripple effect in supply chains during COVID-19 pandemic: Managerial insights and research implications’, International Journal of Production Economics, 232, 107921.

Ivanov, D. (2021) ‘Digital Supply Chain Management and Technology to Enhance Resilience by Building and Using End-to-End Visibility During the COVID-19 Pandemic’, IEEE Transactions on Engineering Management, 71, pp. 10485–10495. DOI: 10.1109/TEM.2021.3095193.

Ji, Z., Lee, N., Frieske, R., Yu, T., Su, D., Xu, Y., Ishii, E., Bang, Y.J., Madotto, A. and Fung, P. (2023), Survey of Hallucination in Natural Language Generation, ACM Computing Surveys, 55(12), Article 248, pp. 1–38.

Lahusen, C., Maggetti, M. and Slavkovik, M. (2024) ‘Trust, trustworthiness and AI governance’, Scientific Reports, 14, 20752.

Lewis, P., Perez, E., Piktus, A. et al. (2020) ‘Retrieval-augmented generation for knowledge-intensive NLP tasks’, Advances in Neural Information Processing Systems, 33, pp. 9459–9474.

NIST (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg, MD: National Institute of Standards and Technology.

Noy, S. and Zhang, W. (2023) ‘Experimental evidence on the productivity effects of generative artificial intelligence’, Science, 381(6654), pp. 187–192.

Novelli, C., Taddeo, M. and Floridi, L. (2024) ‘Accountability in artificial intelligence: what it is and how it works’, AI & Society, 39, pp. 1871–1882.

Pearl, J. (2009) Causality: Models, Reasoning, and Inference. 2nd ed. Cambridge: Cambridge University Press.

Raisch, S. and Krakowski, S. (2021) ‘Artificial intelligence and management: the automation–augmentation paradox’, Academy of Management Review, 46(1), pp. 192–210.

Spetzler, C., Winter, H. and Meyer, J. (2016) Decision Quality: Value Creation from Better Business Decisions. Hoboken, NJ: Wiley.

Power, M. (2021) ‘Modelling the Micro-Foundations of the Audit Society: Organizations and the Logic of the Audit Trail’, Academy of Management Review. Published online 14 January 2021.

Yao, S. et al. (2023) ‘ReAct: synergizing reasoning and acting in language models’, International Conference on Learning Representations

Contact

Reach out via email for inquiries.

Email

Subscribe to newsletter

info@grcadvisory.ch

© 2025. All rights reserved.