From AI Governance to Organisational Control

Abstract

The rapid integration of artificial intelligence (AI), automated decision-making and AI-enabled information technology into organisational processes has created new challenges concerning accountability, risk management and regulatory compliance. Existing approaches frequently conceptualise AI compliance as a largely documentary exercise in demonstrating conformity with legal or ethical requirements. This paper argues that such an approach is insufficient for dynamic sociotechnical systems whose risks and impacts extend across organisational boundaries and throughout the technology lifecycle. Drawing on recent scholarship on AI governance and accountability, together with the management-system logic of ISO/IEC 42001:2023 and the risk-based regulatory framework established by the EU Artificial Intelligence Act, the paper conceptualises AI governance as an organisational control architecture. Within this architecture, governance must establish not only policies but also decision rights, accountable ownership, operational controls, intervention mechanisms and evidence-producing processes.

The paper develops a practical governance model comprising seven interconnected capabilities: identify, assign, assess, control, evidence, assure and improve. The model translates regulatory and governance principles into organisational capabilities through which AI systems, automated processes and relevant IT platforms can become auditable, controllable and demonstrably compliant. Auditability is conceptualised as the organisational capacity to reconstruct and evaluate how systems were authorised, configured, operated and monitored, while controllability concerns the capacity of authorised actors to influence, constrain, modify or suspend system behaviour. The analysis further argues that these capabilities must be proportionate to risk, integrated with existing enterprise governance arrangements and embedded throughout the AI lifecycle.

The paper concludes that effective AI governance should not be understood as a static compliance checklist or an isolated technical function. Rather, it is a continuous organisational capability through which responsibility, authority, risk, control, evidence and assurance are connected and adapted as technologies, organisational contexts and regulatory expectations evolve.

Keywords: artificial intelligence governance; AI compliance; AI accountability; AI Act; ISO/IEC 42001; auditability; controllability; AI risk management; organisational governance; assurance.

1. Introduction

Artificial intelligence (AI) is increasingly embedded within the organisational infrastructure through which decisions are made, services are delivered and operational processes are controlled. AI capabilities now support recruitment, credit and insurance assessment, healthcare, customer interaction, fraud detection, cybersecurity, software development and business-process automation. Their governance cannot therefore be reduced to the performance of an individual model. AI-related risks and consequences emerge from interactions between models, data, software infrastructure, organisational processes, human users, suppliers and the institutional context in which outputs are acted upon. AI governance must consequently encompass how systems are selected, designed, procured, developed, deployed, monitored, modified and retired.

This broader conception is reflected in recent scholarship. Batool, Zowghi and Bano (2025), in a systematic review of AI governance, identify four fundamental questions: who governs AI, what is governed, when governance occurs across the lifecycle, and how governance is implemented through policies, frameworks, tools and organisational mechanisms. Their analysis demonstrates that AI governance operates across multiple levels, from teams and organisations to industries and international institutions. It is therefore better understood as a distributed organisational capability than as a discrete compliance or IT function.

This perspective challenges the treatment of AI compliance as a checklist applied to a completed technology. AI systems are sociotechnical: their risks arise from interactions between technical systems and the people, processes and institutions surrounding them. Responsibility may therefore be distributed across business owners, developers, data specialists, IT functions, procurement teams, suppliers, users and senior management. Effective governance must establish how these responsibilities relate to one another and who possesses the authority to act when risks emerge.

Grote, Parker and Crowston (2026) sharpen this issue through their concept of control-accountability alignment. They distinguish control, understood as the capacity to influence outcomes, from accountability, understood as the obligation to achieve or prevent them. As AI systems become more autonomous and adaptive, the relationship between the two becomes increasingly important. Assigning accountability to an individual or function without providing the information, resources or authority required to intervene creates responsibility without meaningful control. Conversely, technical intervention capability without clearly assigned accountability leaves uncertainty about who is obliged to act.

AI governance therefore requires deliberate alignment between responsibility, authority, information and intervention capability. This extends accountability beyond the simple assignment of responsibility. Novelli, Taddeo and Floridi (2024) conceptualise AI accountability as answerability, emphasising the authority to question decisions, the standards against which they are assessed, the forums in which actors can be held to account, and the processes and consequences that follow. The governance question is consequently not merely who is responsible, but who can be questioned, by whom, according to which standards, through what process and with what consequences.

The proposition that organisations should design governance structures that make AI systems, automated processes and IT platforms auditable, controllable and compliant can therefore be understood as a practical expression of this literature. It describes an organisational architecture through which technological activity is brought within established systems of authority, accountability, risk management and assurance. The objective is not simply to determine whether a model is technically accurate or whether an AI policy exists, but whether the organisation can demonstrate what systems it operates, why they are used, who is responsible for them, what risks have been identified, what controls are in place, how those controls are monitored and how failures are addressed.

The European regulatory environment gives this challenge particular urgency. Regulation (EU) 2024/1689, the EU Artificial Intelligence Act (EU AI Act), establishes a risk-based regulatory framework for AI within the European Union. Its importance for organisational governance lies in the extent to which it translates regulatory expectations into organisational, technical and evidential obligations. For high-risk AI systems, Article 9 requires a documented risk-management system that operates as a continuous and iterative process throughout the system lifecycle (European Parliament and Council of the European Union, 2024). Compliance is therefore not confined to a pre-deployment assessment. Risks must be identified, evaluated, controlled and reviewed as systems and their operating contexts evolve.

The Act also makes the relationship between auditability and control explicit. Article 12 requires relevant high-risk AI systems to support automatic event logging, while Article 19 establishes requirements concerning the retention of automatically generated logs. These provisions reflect a fundamental governance principle: organisations cannot effectively investigate or demonstrate the operation of systems whose relevant behaviour cannot subsequently be reconstructed (European Parliament and Council of the European Union, 2024).

Auditability should therefore be understood as more than conventional technical or financial auditing. In an AI context, it is the organisational and technical capacity to reconstruct the decisions, configurations, processes and events necessary to establish how a system was governed and whether applicable requirements were satisfied. This requires an evidential chain connecting governance decisions to technical implementation and operational behaviour, including appropriate documentation, approvals, testing, monitoring, logging, incident records and change histories.

The EU AI Act reinforces this evidential conception through its requirements for documentation and quality management. Article 17 requires providers of high-risk AI systems to establish a documented quality-management system covering areas including regulatory compliance, design and development, testing and validation, data management, record-keeping, post-market monitoring and organisational responsibilities (European Parliament and Council of the European Union, 2024). AI regulation consequently extends beyond technical performance into the domain of organisational management systems.

Controllability provides the complementary dimension. Whereas auditability concerns the capacity to reconstruct and evaluate what happened, controllability concerns the capacity to influence what happens. It includes the ability to configure, restrict, monitor, override, correct, suspend or terminate system behaviour where necessary. A system may be highly observable yet poorly governable if authorised actors lack the practical ability to intervene.

Human oversight is therefore central to meaningful control. Article 14 of the EU AI Act requires relevant high-risk AI systems to enable effective human oversight during use. Such oversight cannot be reduced to placing a person nominally “in the loop”. Effective oversight requires appropriate information, competence and authority to understand system behaviour and intervene when necessary (European Parliament and Council of the European Union, 2024). This again reinforces the control-accountability relationship identified by Grote, Parker and Crowston (2026): responsibility must be accompanied by the practical means to exercise control.

This distinction exposes the difference between nominal and substantive governance. An organisation may formally appoint an AI owner, compliance officer or human overseer while providing that person with insufficient information, resources or authority to influence outcomes. Substantive governance exists only where formal responsibility is matched by operational capacity.

ISO/IEC 42001:2023 provides an important complementary perspective. Unlike the EU AI Act, which is legally binding within its scope, ISO/IEC 42001 is an international management-system standard for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS) (ISO, 2023). Its significance lies in institutionalising AI governance through policies, objectives, risk and opportunity management, operational controls, performance evaluation and continual improvement.

The two instruments therefore perform different but complementary functions. The EU AI Act establishes legal obligations and prohibitions; ISO/IEC 42001 provides a management-system architecture through which organisations can systematically identify, allocate, implement, monitor and improve AI-related governance requirements. ISO/IEC 42001 is not a substitute for legal compliance. Rather, it can provide organisational infrastructure through which legal, ethical, technical and business requirements are translated into repeatable processes and controls.

This management-system perspective is particularly important because AI governance is necessarily dynamic. Technologies, applications, data, suppliers, threats and regulatory expectations change over time. Static policies and point-in-time assessments are therefore insufficient. A mature governance system must support continuing review, corrective action and improvement, consistent with the lifecycle orientation identified by Batool, Zowghi and Bano (2025) and embedded within the management-system approach of ISO/IEC 42001.

The governance perimeter should also extend beyond systems formally labelled “AI”. Organisations increasingly operate technology ecosystems in which AI models interact with conventional software, automated workflows, cloud platforms, data pipelines, APIs and third-party services. Consequential outcomes may therefore arise from chains of automated components rather than from a single model. Governance should consequently focus on risk, consequence and accountability, as well as technological classification.

The central argument of this paper is that AI governance should be understood as an organisational control architecture: an integrated system of decision rights, responsibilities, risk-management processes, technical safeguards, documentation, monitoring, assurance and intervention mechanisms. Within this architecture, auditability is the capacity to produce credible evidence about how systems have been designed, approved, operated and changed; controllability is the capacity of authorised actors to influence, constrain, correct or terminate system behaviour; and compliance is the capacity to identify applicable obligations, implement appropriate controls and demonstrate conformity over time.

These dimensions are mutually reinforcing. Auditability without control produces retrospective knowledge without effective intervention. Control without accountability creates technical capability without institutional responsibility. Compliance without either risks becoming documentation without substantive governance.

The challenge for organisations is therefore not simply to create an AI policy or appoint an AI governance officer. It is to establish an organisational system in which authority, accountability, risk, control and evidence are deliberately connected throughout the technology lifecycle. This provides the foundation for examining how governance structures can be designed and implemented in practice, and how regulatory and management frameworks such as the EU AI Act and ISO/IEC 42001 can be translated into operational mechanisms of organisational control.

2. From “AI Compliance” to AI Governance

A narrow conception of AI compliance treats regulation as a conformity exercise: identify applicable requirements, assess whether a system satisfies them, document the result and remediate deficiencies. This approach is useful for establishing a baseline of regulatory conformity, but it is inadequate as a model of AI governance. AI systems are dynamic sociotechnical systems whose behaviour and consequences emerge from interactions between models, data, infrastructure, human actors, organisational processes and changing contexts of use. They cannot therefore be assessed once and regarded as permanently compliant.

The distinction is fundamental. Compliance asks whether specified requirements have been met; governance asks how an organisation exercises authority, manages risk and remains accountable over time. Compliance is consequently a component of governance, not its endpoint.

Recent scholarship supports this broader interpretation. Batool, Zowghi and Bano (2025) identify four central questions in AI governance: who governs, what is governed, when governance occurs across the lifecycle and how governance is operationalised. Their systematic review also demonstrates that AI governance operates across multiple organisational and institutional levels. Governance is therefore not a single compliance or IT function but a distributed organisational capability.

This matters because AI-related responsibility is frequently fragmented across organisational boundaries. A system may be developed by one team, trained on data controlled by another, hosted by a third party, procured by a business unit and used by employees who had no role in its development. In complex AI supply chains, foundation-model providers may be several organisational layers removed from the organisation deploying an AI-enabled application. The governance problem is therefore not simply whether a system satisfies a prescribed requirement, but where authority and responsibility reside across its lifecycle and value chain.

Novelli, Taddeo and Floridi (2024) provide an important theoretical foundation through their conception of AI accountability as answerability. Accountability involves more than assigning responsibility; it requires authority, the possibility of interrogation and mechanisms for limiting power. Their framework considers the context, agents, forums, standards, processes and consequences through which accountability operates. The central question is therefore not simply who is responsible?, but who can be questioned, by whom, according to which standards, through what process and with what consequences?

This distinction is particularly clear in human oversight. An organisation may require an employee to review AI outputs and thereby appear compliant with an oversight requirement. Yet if the reviewer lacks adequate information, competence or authority to challenge an output, the arrangement provides formal oversight without substantive control. Article 14 of the EU AI Act illustrates this principle by requiring effective human oversight of relevant high-risk AI systems, rather than merely the presence of a human actor (European Parliament and Council of the European Union, 2024). Human presence is therefore not synonymous with human control.

The same problem applies to documentation. An organisation may possess model documentation while lacking the evidence necessary to reconstruct how a particular decision was produced, which model version was used, what material changes occurred, which data were involved or who authorised deployment. AI governance consequently requires an evidence architecture, not simply a document repository. Depending on risk and context, relevant evidence may include system ownership, intended purpose, risk assessments, data provenance, model versions, validation results, approval decisions, human-oversight records, operational logs, incidents, changes and corrective actions.

The EU AI Act reinforces this lifecycle-based conception. Article 9 requires a continuous and iterative risk-management process for high-risk AI systems, while Article 12 establishes requirements concerning automatic logging and traceability (European Parliament and Council of the European Union, 2024). Governance is therefore not a one-off approval event. Risks, controls and evidence must remain relevant throughout operation and change.

This leads to a critical distinction between static compliance and dynamic governance. A static compliance approach asks whether a system met requirements at a particular point in time. Governance instead establishes an ongoing process through which purpose, risk, controls, performance and regulatory obligations are continually reviewed. The difference is consequential because models, data, operating environments, suppliers, users and regulatory expectations can all change after deployment.

ISO/IEC 42001:2023 reflects this latter conception. The standard establishes an Artificial Intelligence Management System (AIMS) through which organisations can establish, implement, maintain and continually improve processes for managing AI-related risks and opportunities (ISO, 2023). Its management-system orientation places AI governance within organisational processes of planning, implementation, performance evaluation and improvement rather than treating compliance as an isolated assessment.

This is particularly important because AI governance intersects with established disciplines including information security, privacy, data governance, enterprise risk, software engineering, procurement, business continuity and internal audit. Treating AI governance as the exclusive responsibility of an AI or IT function risks fragmenting control and separating technical decisions from their legal, operational and organisational consequences. Effective governance is therefore inherently cross-functional.

The relationship between control and accountability identified by Grote, Parker and Crowston (2026) is central to this problem. Their concept of control-accountability alignment highlights the difficulty created when the capacity to control an outcome becomes separated from responsibility for that outcome. As AI systems become more autonomous, organisations must deliberately determine where control resides and how it relates to accountability.

This produces a straightforward organisational principle: responsibility should not be assigned without corresponding authority. A manager cannot meaningfully be accountable for an AI system if they cannot access relevant information, challenge its outputs, require remediation, influence its configuration or suspend its operation. Conversely, a system may possess technical rollback or shutdown capabilities without anyone having explicit authority or responsibility to exercise them. The first is accountability without control; the second is control without accountable decision-making.

Effective governance therefore requires alignment between responsibility, authority, information and control. A policy establishes an expectation, but governance requires an accountable actor with the authority and information necessary to implement that expectation, together with mechanisms for intervention when it is not achieved.

This also clarifies the role of assurance. Assurance should not be treated as an activity performed only at the end of a governance process. In a dynamic environment, monitoring should identify deviations, incidents should trigger investigation, audit findings should lead to corrective action, and regulatory or technological changes should prompt reassessment. Assurance is therefore part of a continuous governance feedback loop.

This is why the concept of AI governance is more useful than that of AI compliance when describing the organisational objective. Compliance concerns conformity with defined requirements. Governance incorporates compliance but extends to direction, decision-making, risk appetite, accountability, oversight, intervention and organisational learning. It also addresses questions that legislation alone may not resolve. A system may satisfy minimum legal requirements while still presenting material operational, reputational, fairness or customer-trust risks. Governance provides the institutional mechanisms through which such questions can be considered and decided.

The distinction should not be interpreted as diminishing the importance of compliance. Legal conformity remains essential. Rather, compliance is a necessary but insufficient condition of effective governance. An organisation may be formally compliant while still possessing weak governance if responsibilities are unclear, decision rights are fragmented, controls are ineffective or intervention mechanisms are unavailable.

The more useful conception is therefore to treat governance as the organisational architecture within which compliance operates. It connects external requirements with internal authority, risk management, operational controls, evidence and assurance. ISO/IEC 42001 provides a management-system structure for institutionalising these activities, while the EU AI Act establishes legally binding requirements within its scope. The accountability and control literature explains why these mechanisms must be connected to meaningful authority and answerability.

The central proposition is consequently that organisations should move from a compliance mindset to a governance capability. The objective is not merely to demonstrate that an AI system satisfied specified requirements at a particular point in time. It is to establish an enduring capacity to understand what systems are doing, determine whether their behaviour remains acceptable, identify who has authority to act, intervene when necessary and demonstrate through credible evidence that appropriate control has been exercised.

AI governance is therefore ultimately a problem of institutionalising control over technological power. As AI becomes more autonomous and increasingly embedded within consequential organisational processes, the critical question is not simply whether machines can make or support decisions, but whether organisations retain sufficient authority, accountability and capability to govern those decisions. The transition from AI compliance to AI governance is consequently a transition from checking conformity to establishing continuous, evidence-based organisational control.

3. What Does “Auditable” Mean?

If AI governance is understood as an organisational control architecture, auditability is the evidential infrastructure that makes that architecture visible, testable and defensible. An AI system is not auditable merely because it has documentation or because its source code can be inspected. Rather, auditability concerns whether an authorised and sufficiently independent reviewer can reconstruct and evaluate the decisions, controls, processes and events that shaped the system and its outcomes.

This is particularly important because AI-enabled services are rarely discrete technical artefacts. They may combine models, data, application software, APIs, cloud infrastructure, third-party services, business rules and human decision-makers. Their behaviour may also change as models are updated, data distributions shift, configurations are modified or systems are deployed in new contexts. Auditability must therefore extend across the sociotechnical system and its lifecycle, rather than being confined to the model itself.

The central argument is that AI auditability should be understood as an evidence architecture: an organisational capability to create, preserve, connect and retrieve sufficient evidence to establish how an AI system was conceived, assessed, approved, developed, deployed, operated, monitored, changed and, where necessary, withdrawn. Auditability thus moves beyond record-keeping towards traceable organisational accountability.

3.1 Auditability and Accountability

The relationship between auditability and accountability is fundamental. Novelli, Taddeo and Floridi (2024) conceptualise AI accountability as answerability, requiring authority, the possibility of interrogation and mechanisms for limiting power. Their framework emphasises the roles of agents, forums, standards and processes through which decisions can be questioned and evaluated. (DOI)

Auditability provides much of the evidential foundation for this relationship. Questions such as who approved the system?, why was the risk accepted?, which model generated this decision?, what controls were operating at the time? and what happened when the system failed? cannot be answered reliably without appropriate evidence.

Auditability therefore enables accountability by supporting three related functions: reconstruction, by establishing what happened; evaluation, by determining whether it was appropriate; and attribution, by establishing who made relevant decisions and exercised control. It is consequently not an administrative by-product of governance but one of the mechanisms through which governance becomes demonstrable.

This also connects auditability to control. Grote, Parker and Crowston (2026) argue that effective AI risk management depends on aligning control with accountability: actors who are accountable for outcomes must have sufficient capacity to influence them. Audit evidence should therefore make not only system behaviour visible, but also the organisational relationships through which decisions and interventions were made.

3.2 Decision Auditability

Decision auditability concerns the ability to reconstruct the organisational decisions that led to an AI system being adopted, deployed, modified or retired.

These decisions establish the governance context in which the technology operates. They include the purpose for which AI is being used, acceptable levels of risk, data and supplier choices, human involvement, deployment conditions and the allocation of responsibility. An appropriate audit trail should therefore enable an authorised reviewer to determine who proposed and approved the use case, its intended purpose, the risks identified, the controls required, who accepted residual risk and what conditions would trigger reassessment or withdrawal.

This becomes particularly important following an adverse or unexpected outcome. A technical investigation may ask whether the model performed correctly. An organisational audit must also ask why the system was deployed, who authorised it, what evidence supported that decision, whether known limitations were accepted and whether appropriate controls were implemented.

Decision auditability should also extend to material changes after deployment. A system initially approved for one purpose may later be integrated with new data, used for a different population or applied to a more consequential decision. Maintaining the rationale and approval history for such changes enables the organisation to determine whether the original governance assumptions remain valid.

3.3 Technical Auditability

Technical auditability concerns whether the characteristics and operational behaviour of an AI system can be sufficiently reconstructed to support investigation and evaluation. Depending on the system and its risk, relevant evidence may include model and software versions, data provenance, testing and validation results, configurations, dependencies, deployment environments, performance measures, security events, access records, outputs, human interventions and material changes.

The objective is not to retain every technical artefact indefinitely. It is to preserve sufficient evidence to answer relevant governance and regulatory questions proportionately to risk.

The EU AI Act illustrates this principle. Article 12 requires high-risk AI systems to possess technical capabilities for automatic event recording, or logging, over their operational lifetime, while Article 19 establishes retention requirements for automatically generated logs under the provider's control. Logging therefore has significance beyond ordinary IT operations: it contributes to traceability and regulatory accountability.

However, logging alone does not create auditability. Large quantities of disconnected data may be practically useless if reviewers cannot establish which model version was operating, which configuration applied, what initiated the event or what action followed. Technical auditability therefore depends on the integrity, context, correlation and retrievability of evidence, rather than its volume.

The objective is ultimately causal reconstruction: linking relevant inputs and context to the system version, processing, output, subsequent human or automated action and resulting outcome. The precise evidence required will vary according to the governance question being investigated.

3.4 Process Auditability

Process auditability concerns whether an organisation can demonstrate that its governance processes actually occurred and operated as intended.

This distinction is crucial. A policy stating that all high-risk AI systems must undergo risk assessment demonstrates an organisational expectation; it does not demonstrate that the assessment occurred. Evidence of process execution might include completed risk assessments, approvals, testing and validation records, human-oversight arrangements, supplier due diligence, monitoring reports, incident investigations, corrective actions and management reviews.

The distinction can be stated simply: policy evidence demonstrates what an organisation says it does; process evidence demonstrates what it actually did.

ISO/IEC 42001:2023 is particularly relevant because it establishes requirements for an Artificial Intelligence Management System through which organisations establish, implement, maintain and continually improve processes for managing AI-related risks and opportunities. (ISO) Its management-system logic therefore reinforces the importance of evidence that controls are not merely defined but implemented, evaluated and improved.

This leads to an important progression in assurance: an organisation should be able to establish not only that a control exists, but that it operates, that it is effective, and that appropriate action is taken when it fails.

3.5 Regulatory Auditability

Regulatory auditability concerns the ability to demonstrate how organisational practices correspond to applicable legal, regulatory and standards-based requirements.

This becomes increasingly important as organisations operate under overlapping requirements, including the EU AI Act, data-protection and cybersecurity obligations, sectoral regulation, contractual requirements and voluntary standards such as ISO/IEC 42001.

Regulatory auditability therefore requires traceability between external requirements and internal controls. A regulatory obligation should be capable of being connected to the relevant organisational policy, operational control, evidence and assurance activity. Conversely, evidence generated by a system should be traceable back to the control and requirement that make it relevant.

Recent work by Buscemi et al. (2025) illustrates this movement from legal requirements towards operational verification. Their proposed EU AI Act verification framework maps legal requirements to concrete assessment activities across data, models, processes and products, illustrating the need to translate regulatory language into testable controls and evidence.

This represents an important shift from interpreting compliance to demonstrating compliance. A statement such as “the organisation manages AI risk” has limited assurance value unless it can be connected to a documented risk-management process, evidence that the process was applied, and assurance that the resulting controls were effective.

3.6 From Documentation to Traceability

Auditability should therefore not be confused with documentation. Documentation is primarily descriptive: it records what an organisation says a system is or how a process is intended to operate. Auditability is reconstructive: it enables an authorised reviewer to establish what actually happened.

Consider an AI system approved for use in recruitment. A policy or model document may establish that the system was approved. Following an adverse outcome, however, an investigation may need to determine which version generated the relevant output, what data and configuration were used, whether human oversight occurred, whether known performance problems existed and what action followed.

The question therefore changes from “Do we have documentation?” to “Can we reconstruct the relevant decision and demonstrate that appropriate controls operated?”

This is the difference between documentation and traceability. Evidence must be connected across the governance lifecycle. Risk assessments should relate to particular systems and versions; deployments should relate to approvals; material changes should trigger appropriate reassessment; and incidents should be linked to corrective actions. Auditability is consequently a property of the relationships between evidence items, not merely of the existence of individual records.

A useful conception is therefore that auditability depends upon evidence that is sufficiently complete, reliable, traceable, accessible and interpretable for the governance question at hand.

3.7 Auditability Across the Lifecycle

Because AI systems change, auditability must also be lifecycle-based. Evidence requirements arise from initial conception and classification through design, development, validation, approval, deployment, monitoring, change management, incident response and retirement.

Early-stage evidence should establish intended purpose, affected stakeholders, regulatory classification and risk assumptions. Development evidence may concern data governance, technical specifications, testing and validation. Deployment evidence should establish approval, conditions and assigned responsibilities. Operational evidence becomes increasingly concerned with monitoring, performance, incidents and interventions. Change records should establish what changed, why it changed, who approved it and whether reassessment was necessary. Retirement evidence should establish how the system was decommissioned and which records and dependencies were retained.

This lifecycle orientation is consistent with the EU AI Act's treatment of high-risk AI risk management as a continuous and iterative process. It is also consistent with ISO/IEC 42001's management-system approach to continual improvement.

The implication is significant: auditability must be designed into AI systems rather than retrofitted after deployment. If logging, version control, decision records and evidence retention are not considered during design and procurement, reconstructing consequential events later may be difficult or impossible.

3.8 Auditability and Complex or “Black-Box” Systems

Auditability becomes more difficult where complex machine-learning or generative AI systems are difficult to interpret. It would be unrealistic, however, to make complete internal explainability a prerequisite for auditability.

The more defensible objective is sufficient auditability for the governance question being asked. A cybersecurity investigation may require different evidence from an assessment of discrimination, operational failure or regulatory conformity. Auditability should therefore be proportionate to system risk, purpose and potential impact.

This approach is compatible with the EU AI Act's broader risk-based logic. Higher-risk applications warrant stronger governance because their potential consequences are greater. The same principle should apply to evidence: the greater the potential impact of system failure, the stronger the requirement for reliable, reconstructable and independently verifiable evidence.

Auditability should consequently avoid two extremes: requiring exhaustive evidence for every low-risk AI interaction while accepting inadequate traceability for systems capable of materially affecting individuals, organisations or society.

3.9 Auditability, Assurance and Independent Challenge

Auditability also needs to be distinguished from assurance.

An organisation may possess extensive evidence without that evidence being independently challenged. Internal audit, compliance, risk functions, external assessors and certification bodies can provide different forms of scrutiny, depending on the organisation and risk involved.

This reflects Novelli, Taddeo and Floridi's (2024) emphasis on the forum dimension of accountability. Accountability requires not only an agent and standards but an institutional setting in which conduct can be questioned and evaluated. 

Accordingly, auditability makes governance inspectable; assurance makes governance challengeable. For higher-risk AI systems, evidence should be accessible to actors possessing sufficient independence, competence and authority to challenge decisions, identify weaknesses and require corrective action.

3.10 Auditability as a Design Requirement

The preceding analysis suggests that auditability should be treated as a design requirement, not an administrative obligation imposed immediately before an audit.

At the design stage, organisations should determine what events need to be logged, which decisions need to be traceable, what evidence must be retained, how versions and material changes will be identified, how human interventions will be recorded, who may access evidence and how evidence will be protected from unauthorised alteration.

These considerations should extend into procurement. Where AI capabilities are supplied by external providers, contractual and technical arrangements should address the availability of relevant documentation, version information, logs, incident information and assurance evidence. Outsourcing development or infrastructure does not necessarily remove the deploying organisation's governance obligations.

This is particularly important for systems built on external foundation models or cloud services. Where direct control over the underlying technology is limited, governance depends increasingly upon the organisation's ability to obtain sufficient information and contractual assurance from suppliers.

3.11 The Evidence Architecture

The four dimensions of auditability are interdependent rather than separate control domains. Technical evidence has limited value if the organisation cannot establish who was accountable for the relevant deployment. A risk assessment is of limited value if its relationship to the deployed system or model version cannot be established. A regulatory mapping is similarly weak if there is no operational evidence demonstrating that the corresponding control was implemented.

The strength of an audit environment therefore lies in the integrity of the evidential chain connecting governance decisions, systems, controls, events and assurance.

The practical objective is an evidence environment in which an authorised reviewer can move from a regulatory or organisational requirement to the relevant decision, system, control and evidence, and then from an observed event back through those same relationships to the responsible actors and applicable requirements.

This is the foundation of evidence-based AI governance.

3.12 Conclusion

Auditability should therefore be understood as substantially more than the ability to inspect an AI model or produce documents for a regulator. It is the organisational capacity to reconstruct, evaluate and challenge the decisions, processes, controls and technical events through which an AI system operates.

Four dimensions are particularly important: decision auditability, which establishes why a system was adopted and who authorised it; technical auditability, which establishes what system operated and how it behaved; process auditability, which establishes whether governance procedures were implemented and effective; and regulatory auditability, which establishes how organisational evidence demonstrates conformity with applicable requirements.

Together, these dimensions constitute an evidence architecture for AI governance. The approach is consistent with the EU AI Act's emphasis on risk management, logging, documentation, human oversight and traceability, and with ISO/IEC 42001's management-system orientation towards documented processes, performance evaluation and continual improvement. (ISO)

The strategic implication is that organisations should engineer auditability into AI governance from the outset. Audit trails, versioning, logging, decision records, control evidence and regulatory mappings should be treated as components of the governance architecture rather than paperwork generated for an eventual audit.

Ultimately, an auditable AI system is not one that produces the most documentation. It is one for which, when a consequential question arises, the organisation can produce a credible, coherent and sufficiently complete evidential chain showing what was intended, what was built, what was approved, what occurred, who was responsible, which controls operated, what was learned and what action followed. Auditability thus transforms AI governance from a collection of assertions into a system of demonstrable organisational accountability.

4. What Does “Controllable” Mean?

If auditability concerns an organisation’s ability to establish what happened, controllability concerns its ability to determine what happens next. The distinction is fundamental. Auditability is primarily evidential and retrospective: it enables an organisation to reconstruct decisions, system behaviour and control operation. Controllability is operational and prospective: it concerns the capacity of authorised actors to influence, constrain, correct, suspend or terminate an AI-enabled system when circumstances require intervention.

An organisation may therefore possess extensive auditability while having little practical control. A system may generate comprehensive logs and retain detailed documentation while continuing to make consequential decisions even when its behaviour becomes unreliable or harmful. Conversely, an organisation may possess technical intervention mechanisms but lack the information needed to determine when intervention is warranted. Effective governance requires both visibility and the capacity to act.

This distinction becomes increasingly important as AI systems acquire greater autonomy, adapt to changing data and become embedded in complex organisational processes. Grote, Parker and Crowston (2026) argue that increasing AI agency and adaptivity can weaken the ability of those who develop and operate such systems to control their outcomes. At the same time, responsibility may remain distributed across developers, users, managers, vendors and other stakeholders. Their concept of control-accountability alignment therefore provides an important foundation for understanding controllability: responsibility for outcomes should be accompanied by sufficient capacity to influence those outcomes.

Control should not, however, be understood simply as the technical ability to switch a system off. It is an organisational and sociotechnical capability involving authority, information, competence, intervention mechanisms and organisational capacity. An employee may have access to a system without being authorised to change it. A manager may have decision-making authority without access to relevant performance information. A technical team may be able to modify a model without having the mandate to suspend its use. In each case, part of the control structure exists, but effective governance does not.

The central proposition is therefore that controllability is the organisational capacity to maintain meaningful influence over AI-enabled behaviour throughout the system lifecycle. It depends on clear decision rights, appropriate technical safeguards, meaningful human oversight, monitoring, escalation and intervention mechanisms.

4.1 From Observation to Intervention

The distinction between auditability and controllability can be expressed through two basic governance questions: Can we establish what the system did? and Can we influence what it does when necessary?

The first is principally a question of evidence; the second is a question of action. Consider an automated recruitment system that begins producing anomalous recommendations. If the organisation can reconstruct the relevant outputs, identify the model version and examine its logs, it has achieved a degree of auditability. If no authorised actor can suspend the process, however, the organisation remains exposed to continuing harm.

Controllability therefore requires a functioning pathway from detection to assessment, decision, intervention and verification. The speed of that pathway must reflect the speed at which harm can materialise. A control that takes weeks to activate may be adequate for a low-risk administrative application but ineffective for an automated system making consequential decisions in real time.

Control must therefore be assessed not merely by whether an intervention mechanism exists, but by whether it can be exercised quickly enough, by the right person and with sufficient information to be meaningful.

4.2 Human Oversight as Meaningful Control

The EU AI Act provides an important legal expression of this principle through Article 14, which requires high-risk AI systems to be designed and developed so that natural persons can effectively oversee them during operation. The required oversight must be proportionate to the system’s risks, degree of autonomy and context of use.

Human oversight is not satisfied merely by placing an employee somewhere in the workflow. Depending on the circumstances, the overseer must be able to understand relevant system capabilities and limitations, monitor its operation, identify anomalies, recognise automation bias, interpret outputs, disregard or override them and, where appropriate, interrupt the system.

The distinction is therefore important: human presence is not necessarily human oversight, and human oversight is not necessarily human control. Meaningful control requires the overseer to possess the competence, information, authority and technical means necessary to intervene.

This interpretation is consistent with research on human oversight under the EU AI Act. Corrêa, Garsia and Elbi (2025) emphasise that human oversight should be understood as a governance mechanism rather than merely a procedural requirement. Its value lies in creating a practical capacity to identify and address risks arising during the operation of AI systems.

4.3 Aligning Responsibility and Control

The control-accountability relationship identified by Grote, Parker and Crowston (2026) has a direct organisational implication: responsibility should not be assigned without corresponding authority and control.

Suppose a compliance manager is formally accountable for an AI-enabled decision process but cannot modify the system, access relevant performance information, influence the supplier or suspend automated decisions. The organisation has assigned accountability without providing the means to discharge it. Conversely, a technical team may possess extensive ability to modify or disable a system while having no responsibility for the business consequences of its use.

Neither arrangement represents effective governance. Complex AI systems may appropriately distribute responsibility, authority, information and technical control across several actors, but those relationships must be explicit and coordinated. The organisation should be able to establish who is answerable for an outcome, who can make the relevant decisions, who has access to the necessary information and who can actually influence or stop the system.

Controllability is therefore not simply a technical property. It is also a property of organisational design.

4.4 Controllability as a Sociotechnical Property

Effective control emerges from the interaction of technology with people, processes and institutional authority. Consider an AI system used to identify potentially fraudulent transactions. The system may automatically flag transactions above a particular risk threshold, but meaningful control depends on what happens around that technical function. Someone must be responsible for reviewing the alerts; that person must have sufficient information to assess them; they must be able to challenge the system's recommendation; and the organisation must have a mechanism for preventing a transaction from proceeding when necessary. It must also be clear who can recalibrate or suspend the system, how quickly this can occur and what happens operationally if it is unavailable.

The technology therefore provides capabilities, but the organisation determines whether those capabilities amount to meaningful control.

Controllability should consequently be understood as a sociotechnical capability arising from the interaction of technology, people, authority, information, processes and organisational capacity. Technically sophisticated systems can therefore remain poorly governed if these elements are not connected.

4.5 Risk-Proportionate Control

Controllability should also be proportionate to risk. A low-risk system used to generate internal meeting summaries does not necessarily require continuous human intervention. An AI system influencing medical treatment, employment, access to essential services or other consequential decisions requires substantially stronger oversight and intervention capabilities.

Article 14 of the EU AI Act reflects this principle by requiring human-oversight measures to be proportionate to the risks, autonomy and context of use. Organisations should therefore calibrate control mechanisms according to potential consequences rather than applying identical requirements to every AI application.

For lower-risk systems, monitoring and periodic review may be sufficient. More consequential systems may require defined escalation procedures and active human oversight, while unacceptable or uncontrolled risks may require restriction or suspension. Risk-proportionate governance also avoids unnecessary bureaucracy while ensuring that systems capable of causing significant harm remain subject to meaningful intervention.

4.6 Preventing, Detecting and Correcting

A mature control environment should combine preventive, detective and corrective mechanisms. Preventive controls constrain unacceptable behaviour before it occurs through measures such as access restrictions, approved-use rules, input validation, testing and restricted permissions. Detective controls identify emerging problems through performance monitoring, anomaly detection, security monitoring, fairness monitoring, user complaints and incident reporting. Corrective controls allow the organisation to respond through human override, rollback, configuration changes, suspension, remediation, recalibration or retirement.

These mechanisms are interdependent. Prevention reduces the likelihood of failure; detection identifies failures that nevertheless occur; and correction limits their consequences. A governance environment lacking any one of these capabilities is materially weaker.

The most important test is whether detection can lead to action. Monitoring is not a control if no authorised actor can respond to what it reveals.

4.7 Intervention Rights

One of the clearest tests of substantive governance is whether the organisation can answer the question: Who can stop the system?

The answer is often more complicated than it appears. An operator may not have authority to suspend the system. A business owner may have decision authority but lack technical access. A technology team may be able to disable the application but lack the mandate to make that decision. A supplier may control the underlying model or service.

Effective governance therefore requires explicit intervention rights. For material AI systems, the organisation should establish who can pause or stop the system, the circumstances requiring intervention, who may authorise continued operation, who must be notified and how the intervention is recorded and reviewed. It should also establish an appropriate fallback process and conditions for safe restoration.

Article 14 of the EU AI Act reinforces this principle by requiring appropriate mechanisms for human overseers to disregard, override or reverse outputs and, where appropriate, interrupt the system. Human oversight is consequently not merely an ethical aspiration; for relevant high-risk systems, it becomes a concrete design and operational requirement.

4.8 Automation Bias and Effective Intervention

Formal intervention rights do not, however, guarantee effective control. Human operators may defer to AI recommendations because the system appears authoritative, technically sophisticated or highly accurate. The EU AI Act expressly recognises the risk of automation bias in its human-oversight requirements.

Effective intervention therefore requires more than technical permission to override a system. The person exercising oversight must understand its limitations, possess sufficient information and competence, have time to exercise judgement, and be institutionally permitted to challenge the output. Organisational incentives also matter. If employees are implicitly expected to follow automated recommendations, a formal override function may have little practical effect.

Controllability therefore depends partly on organisational culture and role design, not only on system architecture. Meaningful human oversight requires both technical capability and institutional permission to exercise judgement.

4.9 Monitoring and Operational Control

a Controllability depends on continuous monitoring because an organisation cannot intervene effectively if it cannot recognise when system behaviour has departed from acceptable conditions. AI governance literature emphasises that governance must address risks throughout the AI lifecycle rather than being limited to development or deployment, with responsibility distributed across different organisational and stakeholder levels (Batool, Zowghi and Bano, 2025). Monitoring may therefore address performance, reliability, data or model drift, cybersecurity, anomalous outputs, fairness, inappropriate use, human overrides, complaints and incidents. For autonomous or mission-critical AI systems, continuous risk management controls and mechanisms for human oversight are particularly important because assurance, interpretability and accountability need to be maintained during operation rather than assumed from design alone (‘Enabling affordances for AI governance’, 2024).

Monitoring should be linked to defined thresholds and escalation procedures. A dashboard showing declining performance is not itself a control. It becomes a control only when someone is authorised to assess the deviation, understand its significance and take appropriate action. This is consistent with the EU AI Act's approach to human oversight, which requires relevant high-risk AI systems to enable designated persons to monitor operation, identify anomalies and unexpected performance, interpret outputs and, where appropriate, disregard, override or reverse system outputs (European Parliament and Council of the European Union, 2024).

This illustrates the reciprocal relationship between auditability and controllability. Observation without intervention produces awareness without control; intervention without observation produces power without informed governance. Effective control therefore requires both evidence of system behaviour and practical mechanisms through which authorised actors can respond. This aligns with Novelli, Taddeo and Floridi's (2024) account of AI accountability, which identifies oversight and enforcement as complementary accountability goals and emphasises the importance of authority, interrogation and limitation of power.

4.10 Change Management and the Preservation of Control

AI systems can change through software updates, model retraining, configuration changes, prompt modifications, new data, supplier changes or changes in intended use. Control must therefore extend to change management. AI governance is inherently lifecycle-oriented, requiring governance mechanisms to remain applicable as systems evolve and as responsibility moves between different actors (Batool, Zowghi and Bano, 2025). ISO/IEC 42001 similarly establishes an AI management system intended to be established, implemented, maintained and continually improved, providing an organisational framework for managing AI-related risks and opportunities over time (ISO/IEC, 2023).

Material changes should trigger an appropriate assessment of what has changed, why it changed, who authorised it, whether testing or reassessment is required and whether the existing control arrangements remain adequate. This is particularly important where changes affect system performance, intended use, human oversight or risk exposure. The EU AI Act explicitly recognises changes to high-risk AI systems and their performance within the regulatory framework and requires post-market monitoring to collect and analyse information about system performance throughout the system's lifetime (European Parliament and Council of the European Union, 2024). Where necessary, the system should therefore be restricted, reapproved or redeployed under revised conditions.

This is particularly important because a system that was controllable under one configuration may not remain controllable after a significant change. Autonomous adaptivity can reduce control even for the experts who create AI systems, while interdependencies between development and use can make it difficult to locate control and accountability clearly (Grote, Parker and Crowston, 2026). Change management therefore provides an essential connection between lifecycle governance and operational control, ensuring that changes in system capability or context are accompanied by corresponding changes in authority, monitoring and intervention mechanisms.

4.11 Third-Party AI and Distributed Control

Controllability becomes more difficult when AI capabilities are supplied by external providers. An organisation may rely on a model, infrastructure or service that it does not itself control, while remaining responsible for the way that capability is deployed and used. The distributed and sociotechnical nature of AI makes it difficult to locate control and accountability within a single actor, particularly where development, deployment and operation involve different stakeholders (Grote, Parker and Crowston, 2026). AI governance research similarly identifies multiple levels of governance, ranging from teams and organisations to industry, national and international actors (Batool, Zowghi and Bano, 2025).

This creates distributed control. Organisations should therefore use procurement and contractual arrangements to preserve sufficient visibility and intervention capability. Relevant measures may include supplier assurance, information and audit rights, notification of material changes, incident reporting, documentation, security requirements, data-management obligations, service-level commitments and mechanisms for suspension, replacement or exit. These arrangements are consistent with a broader view of AI governance that treats transparency, accountability, risk management, safety and cybersecurity as interconnected organisational responsibilities rather than purely technical properties (Camilleri, 2024).

Outsourcing development does not necessarily outsource accountability. If an organisation remains responsible for the consequences of deployment, it must retain sufficient influence over the supplier and the resulting system to exercise that responsibility. Accountability requires identifiable agents, standards, processes and mechanisms through which decisions and outcomes can be questioned and enforced (Novelli, Taddeo and Floridi, 2024).

Controllability is therefore partly a supply-chain governance issue, and procurement becomes an important component of AI governance. This is particularly significant for general-purpose and externally provided AI capabilities, where changes to models or services may occur outside the direct control of the deploying organisation. Maintaining contractual rights to obtain relevant information, receive change notifications, investigate incidents and suspend or replace a service helps preserve organisational control despite technical dependency on external providers.

4.12 From Policy to Operational Control

The practical value of controllability is that it converts governance expectations into operational capabilities. A policy stating that AI systems must be monitored and subject to human oversight is only an expectation. Effective governance requires the organisation to determine who owns the control, what is monitored, which thresholds trigger escalation, who can decide what to do, how intervention occurs, what evidence is generated and how the outcome is reviewed. This reflects the broader finding that AI governance encompasses not only policies and principles but also the organisational mechanisms, processes and tools through which governance is implemented throughout the AI lifecycle (Batool, Zowghi and Bano, 2025).

In other words, a policy states what should happen; a control establishes how the organisation will make it happen. Novelli, Taddeo and Floridi (2024) similarly distinguish accountability as a structured process involving authority, standards, agents, forums and implications, rather than simply an abstract allocation of responsibility. This distinction is important because nominal responsibility is insufficient where the responsible actor lacks the information, authority or technical means necessary to intervene.

This distinction also clarifies the relationship between controllability and assurance. Assurance should test not merely whether intervention mechanisms exist, but whether they function under realistic conditions. Testing should establish whether alerts are generated, whether the right people receive them, whether decision rights are understood, whether intervention can be executed within an appropriate timeframe and whether the system can be safely restored, suspended or retired. Research on AI governance affordances similarly emphasises the importance of designing systems and development processes to support assurance, explainability, interpretability and human oversight rather than treating these as purely documentary requirements (‘Enabling affordances for AI governance’, 2024).

Controllability is therefore ultimately demonstrated through operational performance rather than policy language. A mature control environment should be able to demonstrate, through evidence and testing, that an identified deviation can move from detection → assessment → decision → intervention → review within defined organisational and risk parameters.

4.13 Conclusion

Controllability is the operational counterpart to auditability. Auditability enables an organisation to reconstruct and evaluate what happened; controllability enables it to influence what happens next. Neither is sufficient on its own. Accountability provides the organisational mechanism that connects the two by identifying who has authority, who must answer for outcomes and what processes exist for oversight and enforcement (Novelli, Taddeo and Floridi, 2024).

The challenge is particularly acute for AI because increasing autonomy and adaptivity can weaken the ability of individual actors to predict and control outcomes while organisational responsibility remains distributed across business functions, technical teams, suppliers and other stakeholders. Grote, Parker and Crowston's (2026) control-accountability framework helps explain this problem by arguing that effective AI risk management depends on aligning control and accountability across the stakeholders involved in AI development and use.

The EU AI Act's human-oversight requirements provide a concrete regulatory expression of this principle. For relevant high-risk systems, meaningful oversight requires more than human presence. It requires people assigned to oversight to understand the system's capabilities and limitations, monitor its operation, detect anomalies, interpret outputs and, where appropriate, disregard, override or reverse those outputs (European Parliament and Council of the European Union, 2024). The Act's post-market monitoring provisions further reinforce the lifecycle dimension of control by requiring systematic collection and analysis of information concerning the performance of high-risk AI systems throughout their lifetime.

A mature control environment therefore combines preventive, detective and corrective controls with defined decision rights, monitoring, escalation, intervention, change management and supplier governance. These mechanisms should be proportionate to risk and designed to remain effective as systems evolve. ISO/IEC 42001 reinforces this lifecycle perspective by providing a management-system framework for establishing, maintaining and continually improving organisational arrangements for responsible AI use (ISO/IEC, 2023).

The central conclusion is that control must be designed, exercised and tested, not assumed. An AI system is not effectively governable merely because it has a policy, a dashboard or a designated owner. It is governable when authorised actors have sufficient information, authority and practical means to influence its operation in accordance with defined organisational and regulatory objectives. This reflects the wider AI governance literature, which increasingly treats governance as a combination of organisational structures, lifecycle processes, technical affordances and accountability mechanisms rather than as a purely policy-level activity (Batool, Zowghi and Bano, 2025; ‘Enabling affordances for AI governance’, 2024).

Taken together with the preceding discussion of auditability, the principle is straightforward: auditability makes governance visible; controllability makes governance actionable; accountability determines who must act. Effective AI governance connects all three through an organisational system of authority, evidence, intervention and assurance.

5. Governance Structures: Allocating Responsibility, Authority and Assurance

If AI governance is to function as an organisational control architecture, it must determine not only which controls exist, but who can make decisions, who is accountable for outcomes, who can challenge decisions, who can intervene when controls fail, and who provides independent assurance.

Governance is therefore fundamentally an organisational-design problem. Sophisticated technical controls can remain ineffective where responsibilities are fragmented, decision rights are ambiguous, or governance functions lack authority, information or resources. Conversely, relatively simple controls can be effective when embedded within clear structures and supported by appropriate decision rights.

This perspective is consistent with Batool, Zowghi and Bano's (2025) systematic review, which conceptualises AI governance across multiple levels and around four questions: who is accountable, what is governed, when governance occurs across the lifecycle, and how governance is implemented. AI governance consequently cannot be reduced to a technical function; it must connect organisational, regulatory and institutional levels.

Empirical evidence reinforces this distinction. Frimpong and Botchey (2026), in a study of 351 organisations, identify four governance configurations—Governance Absence, Symbolic Governance, Operational Governance and Institutionalised Governance—and show that formal governance roles may remain weak where authority, resources and organisational integration are limited.

The central implication is straightforward:

Creating an AI governance role does not necessarily create AI governance capacity.

A governance officer or committee may exist formally while lacking the authority to reject deployments, access to technical information, resources to conduct meaningful assessments, or an effective route to senior decision-makers. Effective governance therefore requires an architecture of distributed but coordinated accountability, linking strategic oversight, business ownership, technical control, risk and compliance, data governance, operational users and independent assurance.

5.1 Governance as the Allocation of Decision Rights

At its core, governance concerns the allocation and exercise of decision rights. AI governance literature increasingly frames governance as an organisational process involving the distribution of responsibilities, authority and oversight across multiple actors rather than as a purely technical or compliance function (Batool, Zowghi and Bano, 2025; Novelli, Taddeo and Floridi, 2024). An effective AI governance structure should therefore make clear:

• who approves AI use cases and risk classifications;

• who owns the business purpose and consequences;

• who can require additional testing or remediation;

• who accepts residual risk;

• who can suspend or restrict a system;

• who authorises reinstatement;

• who monitors compliance; and

• who provides independent assurance.

This extends the accountability and controllability principles developed in Chapters 3 and 4. Accountability requires an identifiable actor who can be questioned; controllability requires that relevant actors possess sufficient authority and capability to influence outcomes. Novelli, Taddeo and Floridi (2024) emphasise that accountability is not simply the attribution of responsibility after an event; it involves mechanisms through which actors can be identified, questioned, evaluated and, where appropriate, subject to consequences. Similarly, Grote, Parker and Crowston (2026) argue that effective AI risk management depends on alignment between accountability and control across the actors involved in developing and using AI systems.

Accordingly:

Accountability without decision rights produces nominal responsibility; decision rights without accountability produce uncontrolled authority.

Organisational charts alone are insufficient because actual AI decision-making may cross business, technology, data, procurement, risk and supplier boundaries. AI governance research identifies this distributed nature of responsibility as a central challenge, with governance operating across multiple organisational and institutional levels (Batool, Zowghi and Bano, 2025). Governance must therefore make both formal authority and operational decision rights visible. ISO/IEC 42001 reinforces this management-system perspective by requiring organisations to establish defined roles, responsibilities and authorities for AI management and to integrate AI governance into organisational processes (ISO/IEC, 2023).

5.2 Governance Capacity and the Risk of Symbolic Governance

The distinction between a governance role and governance capacity is central. A role allocates responsibility; capacity provides the means to exercise it effectively. The existence of an AI committee, responsible executive or policy does not necessarily demonstrate that effective governance exists. Research on AI governance implementation highlights the gap that can arise between formal governance arrangements and the organisation's practical ability to implement and enforce them (Rêgo de Almeida and dos Santos Júnior, 2025; Biroğul, Şahin and əsgərli, 2025).

A useful formulation is:

Governance capacity = responsibility + authority + information + resources + competence + escalation.

The absence of any of these elements can undermine governance. An accountable person without authority cannot act; authority without information produces uninformed decisions; information without escalation leaves serious issues unresolved. This is consistent with Novelli, Taddeo and Floridi's (2024) treatment of accountability as requiring more than attribution: effective accountability depends upon identifiable actors, standards against which conduct can be assessed, forums for scrutiny and mechanisms through which consequences can follow.

This helps explain Frimpong and Botchey's (2026) distinction between symbolic, operational and institutionalised governance. A committee that cannot challenge deployments, require remediation or escalate material risks may demonstrate formal commitment without possessing substantive governance capability. This concern is also reflected in the broader AI governance literature, which distinguishes between the existence of governance principles and the organisational mechanisms required to operationalise them (Batool, Zowghi and Bano, 2025).

Governance maturity should therefore be assessed not by asking merely whether a governance function exists, but whether it can influence decisions and cause action. Evidence of mature governance should include examples of decisions being challenged, risks being escalated, remediation being required, deployments being restricted where necessary and controls being reassessed when circumstances change. In this sense, governance effectiveness is demonstrated through its capacity to alter organisational behaviour rather than through the existence of governance artefacts alone.

5.3 A Multi-Layer Governance Architecture

A mature governance model should distribute responsibilities across complementary functions rather than concentrate them in a single AI governance office. Board and executive leadership should provide strategic direction, establish AI risk appetite, and approve material risk acceptance. A cross-functional AI governance committee should coordinate governance across the organisation, review high-risk use cases, resolve conflicts between business objectives and control requirements, and escalate material risks. This distributed model is consistent with research describing AI governance as operating across multiple organisational levels and requiring coordination between technical, managerial, legal, ethical and societal considerations (Batool, Zowghi and Bano, 2025; Camilleri, 2024).

The business or AI system owner should remain accountable for the system's purpose, intended outcomes and operational use. Risk, compliance and legal functions should interpret regulatory requirements, challenge risk classifications and assess conformity. Data governance should oversee data quality, provenance, access and lifecycle requirements, while IT and cybersecurity should ensure technical resilience, security, availability and continuity.

AI and model teams should be responsible for technical development, testing, validation, documentation, monitoring and remediation, without assuming broader organisational accountability for the business consequences of deployment. Procurement and supplier-management functions should govern third-party AI through appropriate assurance, audit, change-notification and exit requirements. This is particularly important where organisations depend on external AI providers and therefore need contractual and governance mechanisms to retain visibility and control over externally supplied capabilities.

At the operational level, end-users and human overseers form an important part of the control environment by monitoring outputs, challenging inappropriate results, exercising override authority where required, and escalating concerns. The EU AI Act provides a regulatory example of this principle by requiring human oversight for relevant high-risk AI systems and identifying the need for persons responsible for oversight to have the competence, authority and ability to intervene appropriately (European Parliament and Council of the European Union, 2024). Internal audit should finally provide independent assurance over the design and effectiveness of governance and controls.

Together, these functions create a distributed governance architecture in which strategic authority, business accountability, technical control, regulatory challenge, operational oversight and independent assurance are connected through explicit decision rights and escalation mechanisms. This approach also reflects ISO/IEC 42001's management-system model, which treats AI governance as an organisational system requiring defined responsibilities, risk management, monitoring, continual improvement and management oversight rather than as a standalone technical activity (ISO/IEC, 2023).

This is not a mandatory organisational chart. Functions may be combined in smaller organisations or distributed across specialist teams in larger ones. The underlying requirement is functional completeness: every material responsibility should have an identifiable owner, and every significant decision should have an identifiable decision-maker. The precise organisational structure may vary, but the governance capabilities themselves should not disappear merely because responsibilities are combined or outsourced.

5.4 Executive Accountability and Cross-Functional Governance

AI governance should be integrated into existing enterprise governance rather than developed as a parallel structure. Executive leadership should establish the organisation's AI strategy, risk appetite, material escalation thresholds and boundaries for acceptable AI use. This integration helps ensure that AI-related decisions are connected to established enterprise risk management, compliance, information security, procurement and assurance processes rather than being treated as an isolated emerging-technology issue (Biroğul, Şahin and əsgərli, 2025; Rêgo de Almeida and dos Santos Júnior, 2025).

A cross-functional AI governance committee can then translate these boundaries into operational governance, particularly for high-risk, novel or contentious use cases. Its membership should reflect the risks being governed and may include business, technology, data, risk, legal, compliance, cybersecurity, procurement and responsible-AI expertise. The precise membership should remain proportionate to the organisation and the risk profile of its AI portfolio.

The committee's value lies not in creating another approval layer but in providing a forum for cross-functional judgement and escalation. Its terms of reference should specify decision rights, quorum, escalation routes and the circumstances in which it can require remediation or restrict deployment. It should also have access to sufficient information and subject-matter expertise to exercise those rights effectively.

Without such authority, the committee risks becoming symbolic governance. Conversely, a committee with extensive approval powers but inadequate information, expertise or accountability can create a different form of governance weakness: decisions may be formally authorised without being sufficiently informed or challenged. Effective governance therefore requires the alignment of authority, accountability, information and competence, ensuring that governance bodies possess not only the mandate to decide but also the practical capacity to make and enforce those decisions.

5.5 Business Ownership, Technical Control and Data Governance

AI governance should retain clear business ownership. The business owner should be accountable for the purpose and consequences of AI use: why AI is being deployed, who is affected, what outcomes are acceptable, what residual risks are accepted and when the system should be reviewed or retired. This separation between business accountability and technical implementation is important because AI governance concerns not only whether a system works technically, but whether its use is appropriate within the organisation's objectives, risk appetite and regulatory obligations. AI governance literature emphasises the need to connect technical and organisational decision-making across the AI lifecycle rather than treating governance as a purely technical activity (Batool, Zowghi and Bano, 2025; Camilleri, 2024).

Technical teams, by contrast, should own technical development and controls without being expected to determine whether the organisation should use a system for a particular purpose. Their responsibilities may include model development, validation, testing, security, performance monitoring, documentation and remediation. However, technical capability does not by itself establish that a particular use case is acceptable from a business, legal, ethical or risk perspective. ISO/IEC 42001 supports this distinction by positioning AI management within an organisational management system, requiring responsibilities, risk management and governance processes to operate alongside technical controls (ISO/IEC, 2023).

Technical performance is not equivalent to organisational acceptability.

This distinction reflects the control-accountability problem identified by Grote, Parker and Crowston (2026): responsibility should be aligned with the capacity to influence outcomes, while technical control should not automatically become organisational accountability. Their control-accountability framework highlights the risk that those who have the greatest technical ability to influence an AI system may not be the actors who are accountable for the broader consequences of its deployment. Effective governance therefore requires an explicit connection between the person or function responsible for the business outcome and the technical teams capable of influencing system behaviour.

Business ownership should consequently extend across the AI lifecycle. The business owner should participate in initial use-case approval, risk classification, definition of intended use, acceptance criteria, monitoring, incident response, material change assessment and decisions concerning continued operation, restriction or retirement. This ensures that accountability does not end once an AI system has been approved for deployment.

Data governance should likewise form part of the AI governance architecture. Questions concerning provenance, suitability, quality, access, transformation, retention and protection have legal, operational and ethical dimensions as well as technical ones. The quality and provenance of data can directly influence AI outputs, while inappropriate access, retention or use can create privacy, security and compliance risks. AI governance research therefore identifies data governance and data-related controls as important components of broader AI governance rather than as isolated technical concerns (Batool, Zowghi and Bano, 2025; Camilleri, 2024).

Data governance should therefore be integrated into AI lifecycle decisions rather than treated as a separate technical discipline. Data owners and governance functions should have defined decision rights over data suitability, access and use, while business and technical owners should remain accountable for understanding how data dependencies affect the system's risks and performance. This creates a shared governance chain in which business ownership determines why data and AI are being used, data governance determines whether the data can appropriately support that use, and technical governance determines whether the system processes and protects the data effectively.

5.6 The Three Lines and Independent Assurance

AI governance can also be aligned with the Three Lines Model, providing a useful structure for separating operational ownership, oversight and independent assurance. The Institute of Internal Auditors' Three Lines Model distinguishes between management's responsibility for achieving objectives and managing risk, specialist functions that provide expertise, support, monitoring and challenge, and internal audit's independent and objective assurance role. Applying this model to AI helps prevent responsibility for operating AI systems from becoming confused with responsibility for independently assessing whether the associated controls are effective.

First line — ownership and operation: Business owners, product teams, developers and operational users manage AI risks in day-to-day activities. They are responsible for implementing controls, following approved use conditions, monitoring system behaviour, addressing identified issues and escalating risks when they exceed their authority or tolerance.

Second line — oversight and challenge: Risk, compliance, legal, data governance, cybersecurity and related functions establish frameworks, monitor adherence and challenge management decisions. These functions should have sufficient independence from day-to-day AI operations to provide meaningful challenge while retaining enough access to information and expertise to understand the systems they oversee. Their role is not to assume the business owner's accountability, but to establish standards, identify weaknesses and require appropriate escalation or remediation.

Third line — independent assurance: Internal audit assesses whether governance and controls are appropriately designed and operating effectively. This should include consideration of whether decision rights are clearly allocated, whether risk classifications and approvals are appropriately supported, whether monitoring and escalation mechanisms operate as intended, and whether management has implemented effective responses to identified weaknesses. Independent assurance is particularly important for AI because system behaviour, data dependencies and third-party services can create risks that are not fully visible to operational teams.

This separation is important because operational ownership and independent assurance serve different purposes. The function responsible for operating an AI system should not be the sole judge of whether its own controls are effective. Novelli, Taddeo and Floridi (2024) similarly emphasise that meaningful accountability requires mechanisms through which conduct and decisions can be questioned and assessed, rather than relying solely on self-assessment.

The Three Lines approach should nevertheless be applied proportionately. Smaller organisations may combine some first- and second-line responsibilities, while specialist assurance may be provided through shared or external arrangements. What should not be lost is the functional separation between ownership, challenge and independent assurance. This separation creates a governance mechanism through which AI risks can be managed operationally, challenged independently and ultimately subject to objective assurance.

Those who operate AI should own its risks; those who oversee AI should challenge them; those who audit AI should independently assess both.

5.7 Human Oversight and Operational Governance

Governance does not end with senior management. End-users and human overseers form part of the operational control environment because they may be the first to identify anomalous outputs, misuse, systematic errors or changes in system behaviour.

For high-risk AI, the EU AI Act's Article 14 requirements reinforce this point by requiring appropriate human oversight capabilities, including the ability to monitor, interpret and, where appropriate, override or interrupt system operation. Human oversight therefore requires more than the presence of a person in the workflow. It requires information, competence, authority and practical intervention capability.

This connects the organisational architecture directly to the controllability principle developed in Chapter 4. Decision rights must reach the operational level where intervention may actually be required.

5.8 Governance as a Network Across the AI Lifecycle

AI governance is better understood as a network of accountability and control relationships than as a simple hierarchy. AI systems are developed, deployed and operated through interactions between business owners, technical teams, data specialists, risk and compliance functions, suppliers, operational users and assurance functions. Governance must therefore connect actors who possess different forms of information, authority and technical capability. Batool, Zowghi and Bano (2025) identify this multi-level and lifecycle-oriented character as a central feature of AI governance, while Grote, Parker and Crowston (2026) demonstrate why alignment between control and accountability becomes more complex when AI development and use involve multiple stakeholders.

Business owners require technical information to make informed decisions; technical teams require business context to understand intended use and acceptable outcomes; risk functions require system evidence to assess exposure; executives require aggregated information to determine organisational risk; operational users require clear escalation routes; and internal audit requires sufficient access across the governance structure to provide independent assurance. Governance must therefore support both vertical escalation and horizontal coordination. Horizontal coordination is particularly important where a decision crosses functional boundaries—for example, where a model change has implications for data quality, cybersecurity, regulatory compliance, supplier risk and business performance simultaneously.

Governance must also operate throughout the AI lifecycle. Governance responsibilities should evolve from:

Ideation → Classification → Design → Development → Validation → Approval → Deployment → Monitoring → Change → Retirement

At each stage, different functions may take the lead, but accountability must remain traceable. Early stages may require greater involvement from business, strategy and risk functions; development may place greater responsibility on technical and data teams; deployment and monitoring require stronger operational ownership; while material change or retirement may require renewed business, risk and governance approval. ISO/IEC 42001's management-system approach reinforces this lifecycle perspective by requiring organisations to establish, maintain and continually improve processes for managing AI-related risks and opportunities (ISO/IEC, 2023). This prevents governance from being reduced to a one-time approval process and instead treats governance as a continuing organisational capability.

The lifecycle perspective is also consistent with the EU AI Act, which establishes obligations that extend beyond initial conformity assessment into operational monitoring and post-market activities for relevant high-risk AI systems (European Parliament and Council of the European Union, 2024). Governance should therefore be capable of following the system as it changes, rather than assuming that the controls established at approval will remain sufficient indefinitely.

5.9 Preventing Governance Gaps

A critical function of governance design is to prevent responsibilities from falling between organisational functions. AI governance research highlights the risk of fragmented responsibility where different actors control different aspects of an AI system without any single actor having a complete view of its risks or consequences (Batool, Zowghi and Bano, 2025; Grote, Parker and Crowston, 2026). Common gaps include uncertainty over:

• who owns the AI use case;

• who approves risk classification;

• who monitors model drift;

• who assesses supplier changes;

• who accepts residual risk;

• who can suspend the system;

• who investigates incidents; and

• who provides independent assurance.

These gaps may remain invisible until an incident occurs. A system can therefore appear well governed because individual functions are performing their assigned tasks while important responsibilities between those functions remain unowned. The resulting problem is not necessarily the absence of controls, but the absence of end-to-end ownership and decision rights.

A simple completeness test is therefore:

For every material AI risk, is there a named owner, a control, a decision right, an escalation route and an assurance mechanism?

If any element is missing, the governance architecture is incomplete. This test can be applied to individual AI systems, use cases, lifecycle stages and material risk categories. It also provides a practical basis for governance assurance because it allows an organisation to identify not only whether a control exists, but whether someone has the authority and responsibility to act when that control identifies a problem.

The same principle applies to third-party AI. Where a supplier controls the underlying model or infrastructure, the organisation should still be able to identify who owns the deployment risk, who monitors supplier performance, who assesses material changes and who can invoke suspension, replacement or exit mechanisms. Outsourcing a technical capability should not create an accountability gap.

5.10 Governance Maturity

The four configurations identified by Frimpong and Botchey (2026) provide a useful maturity model:

1. Governance absence — responsibilities are not clearly established.

2. Symbolic governance — formal roles exist but lack sufficient authority, resources or integration.

3. Operational governance — governance is embedded in processes and can materially influence decisions.

4. Institutionalised governance — AI governance is integrated with strategy, risk, compliance, technology, data and assurance.

The important point is that maturity is not measured by the number of policies, committees or governance officers. Research on AI governance implementation similarly indicates that formal structures and policies do not necessarily translate into effective governance if organisations lack the capacity to implement them or integrate them into existing organisational practices (Rêgo de Almeida and dos Santos Júnior, 2025; Biroğul, Şahin and əsgərli, 2025).

Governance maturity is the extent to which responsibility, authority, information, controls and assurance are institutionally integrated.

An organisation with fewer governance artefacts but clear decision rights, effective controls and independent assurance may therefore be more mature than one with extensive documentation but little practical authority. Maturity should be assessed through evidence of governance in operation: decisions being challenged, risks being escalated, controls being tested, remediation being enforced and deployment decisions being changed when evidence indicates that existing arrangements are inadequate.

Institutionalised governance does not mean that every organisation must establish a large central AI governance function. Rather, it means that AI-related responsibilities and controls are embedded into the organisation's existing management system. ISO/IEC 42001 provides a useful framework for this approach by connecting AI governance with organisational leadership, risk management, operational processes, performance evaluation and continual improvement (ISO/IEC, 2023).

5.11 Organisational Design Principles

The analysis supports ten practical principles:

1. Assign accountability explicitly. Every material AI system should have a named accountable owner.

2. Match authority to accountability. Accountable actors must possess sufficient decision rights or direct access to those who do.

3. Separate ownership from assurance. Operational functions should not provide the sole assurance over their own controls.

4. Integrate AI governance with enterprise governance. Connect it to risk, compliance, legal, cybersecurity, data, procurement and audit.

5. Design explicit escalation. Material risks must have defined routes to senior decision-makers.

6. Give humans meaningful intervention rights. Oversight requires competence, information, authority and technical capability.

7. Govern third parties. Supplier dependence must not eliminate meaningful organisational control.

8. Govern across the lifecycle. Accountability and controls must extend from conception through retirement.

9. Test effectiveness. Governance should be tested for operation and effectiveness, not merely existence.

10. Avoid symbolic governance. Authority and resources should be proportionate to the risks governed.

These principles translate the broader AI governance literature into practical organisational design requirements. The emphasis on explicit accountability and escalation reflects the relationship between accountability and control identified by Grote, Parker and Crowston (2026), while the lifecycle and management-system orientation is consistent with Batool, Zowghi and Bano (2025) and ISO/IEC 42001 (ISO/IEC, 2023). The emphasis on human intervention is also consistent with the EU AI Act's requirements for appropriate human oversight of relevant high-risk AI systems (European Parliament and Council of the European Union, 2024).

Taken together, the principles indicate that governance should be designed around capabilities and decision rights rather than organisational labels. Different organisations may place responsibilities in different functions, but they should be able to demonstrate that the necessary governance capabilities exist and are connected.

5.12 From Organisational Chart to Control Architecture

The ultimate objective is therefore not an organisational chart but a control architecture.

An organisational chart answers:

Who reports to whom?

A governance architecture must additionally answer:

Who decides? Who can challenge? Who can intervene? Who must be consulted? Who is accountable? Who provides independent assurance?

These questions matter because reporting relationships do not necessarily correspond to decision rights. A Responsible AI Lead may have responsibility without authority; a CTO may possess technical control without business accountability; a business executive may accept risk without sufficient technical information; and an auditor may identify a weakness without possessing authority to remediate it. Grote, Parker and Crowston's (2026) control-accountability framework is particularly relevant here because it demonstrates why responsibility and practical control must remain aligned across the actors involved in AI development and use.

The governance architecture must connect these actors through:

Responsibility → Authority → Control → Evidence → Challenge → Escalation

This sequence provides a practical representation of how governance becomes operational. Responsibility identifies who owns the outcome; authority establishes who can make or require decisions; controls provide mechanisms for influencing behaviour; evidence makes performance and decisions observable; challenge tests whether decisions and controls remain appropriate; and escalation ensures that issues beyond an actor's authority reach an appropriate decision-maker.

When these relationships are explicit and operational, governance becomes a control system rather than a collection of roles. This is consistent with the broader conception of AI governance as a combination of organisational structures, processes, technical mechanisms and accountability arrangements (Batool, Zowghi and Bano, 2025; ‘Enabling affordances for AI governance’, 2024). The objective is therefore not to create the most elaborate governance structure, but to create one in which every material AI decision has an accountable owner, every significant risk has a control, every control has an appropriate decision-maker, and every material weakness has a route to challenge, escalation and independent assurance.

5.13 Conclusion

Governance structures are the organisational mechanism through which accountability, controllability and assurance become operational. AI governance cannot be reduced to policies, technical controls or individual governance roles because AI systems cross organisational boundaries and involve multiple forms of expertise, authority and responsibility.

Batool, Zowghi and Bano (2025) demonstrate that AI governance operates across organisational and institutional levels and throughout the AI lifecycle. Frimpong and Botchey (2026) further show that formal governance structures vary substantially in their authority, resources and organisational integration. Together, these findings support a distinction between governance as a formal role and governance as organisational capability.

The central question is therefore not simply who is responsible for AI? but:

Who is responsible, who has authority, who has the necessary information and resources, who can intervene, who can challenge decisions, and who independently assures that controls are effective?

A mature governance architecture connects executive accountability, cross-functional oversight, business ownership, technical development, data governance, risk and compliance, procurement, operational users and independent audit.

Its logic can be summarised as:

Strategy → Accountability → Decision rights → Controls → Evidence → Independent assurance → Escalation

This architecture provides the institutional foundation for the auditability and controllability developed in Chapters 3 and 4. Auditability requires ownership of evidence; controllability requires authority to intervene; accountability requires identifiable actors and forums for challenge; governance structures connect all three.

The strategic conclusion is therefore clear:

AI governance is not created by appointing a governance officer. It is created by designing an organisation in which responsibility, authority, information, control and assurance are deliberately aligned.

This provides the bridge from organisational design to the next stage of the governance architecture: the management system through which these structures are translated into policies, processes, controls, evidence and continual improvement.

6. ISO/IEC 42001 as a Management-System Approach

The preceding chapters established that effective AI governance requires more than policies, technical controls or individual accountability. It requires an organisational system that translates principles and regulatory obligations into responsibilities, risk assessments, controls, evidence, monitoring, management oversight and continual improvement. ISO/IEC 42001:2023 is significant because it provides a formal management-system architecture for doing precisely this.

ISO/IEC 42001 should therefore be understood not as a technical standard for AI models, but as an organisational management system for governing the development, provision and use of AI. Its Artificial Intelligence Management System (AIMS) establishes a structured approach to organisational context, leadership, planning, support, operation, performance evaluation and improvement.

Its significance to the argument of this paper is consequently straightforward: the standard provides a bridge between AI governance as an organisational principle and AI governance as an operational capability.

6.1 From Controls to a Management System

A control addresses a particular risk; a management system establishes the organisational conditions under which controls are selected, implemented, monitored and improved.

The distinction can be stated simply:

A control asks: What mechanism addresses this risk?
A management system asks: How does the organisation systematically identify risks, assign responsibility, implement controls, evaluate effectiveness and improve them?

ISO/IEC 42001 is important because it connects these activities into a continuous organisational process rather than treating them as isolated compliance exercises. Its management-system structure supports institutional continuity as AI systems, data, suppliers, use cases and regulatory requirements change.

This reinforces a central proposition of this paper:

AI governance is not a state that an organisation achieves; it is a capability that must be continually maintained and improved.

6.2 The PDCA and Continual-Improvement Logic

ISO/IEC 42001 follows the established management-system logic of Plan–Do–Check–Act (PDCA). Applied to AI governance, this can be expressed as:

Plan → Implement → Monitor → Evaluate → Correct → Improve

Planning establishes organisational context, objectives, applicable requirements and AI-related risks. Implementation translates these into policies, responsibilities, controls and processes. Monitoring and evaluation determine whether systems and controls perform as intended. Corrective action addresses deficiencies, while continual improvement adapts the AIMS to changing technology, risks and organisational circumstances.

This cyclical structure is particularly important for AI because models, data, suppliers, intended purposes and operating environments can change after deployment. Governance must therefore remain active throughout the lifecycle rather than ending at initial approval.

6.3 Context, Scope and the AI Inventory

Management-system governance begins with understanding what is being governed. Organisations must establish the relevant internal and external context, interested parties and boundaries of the AIMS.

In practice, this requires sufficient visibility of the organisation's AI landscape. An AI inventory can provide a central governance mechanism by recording, as appropriate, the system, business and technical owners, purpose, users, affected parties, data sources, supplier, risk and regulatory classification, lifecycle status, applicable controls and review dates.

The inventory is therefore more than an asset register. It can connect ownership, risk, regulatory obligations, controls and lifecycle management.

6.4 Leadership, Roles and Accountability

ISO/IEC 42001 places responsibility for the AIMS firmly within organisational leadership. Top management is expected to demonstrate leadership, establish relevant policies and objectives, integrate AIMS requirements into business processes and provide the resources necessary for effective operation. It also requires relevant responsibilities and authorities to be assigned and communicated.

This directly reinforces the organisational architecture developed in Chapter 5. AI governance cannot be delegated entirely to technical specialists.

The relevant governance chain is:

Role → Responsibility → Authority → Information → Action → Escalation

A governance role without authority, information or resources risks becoming symbolic. Conversely, decision-making authority without clear accountability creates uncontrolled discretion.

The core principle is therefore:

Responsibility must be matched by sufficient authority and organisational support.

6.5 Risk Management and Risk Treatment

Risk management is central to the AIMS. ISO/IEC 42001 requires organisations to identify risks and opportunities, establish appropriate risk criteria, assess AI-related risks and determine appropriate treatment. It also addresses the assessment of AI impacts.

This moves governance beyond a narrow compliance model. The relevant question is not simply whether a requirement has been met, but:

What risks arise from this AI system in this organisational context, and what controls are necessary to manage them?

A mature process therefore follows:

Risk identification → Analysis → Evaluation → Treatment → Control implementation → Monitoring → Review

Risk treatment should result in identifiable owners, controls, evidence, monitoring, escalation and corrective action. In this sense, risk management is the mechanism through which governance decisions become operational controls.

6.6 Annex A: From Control Catalogue to Control Architecture

ISO/IEC 42001 Annex A provides a reference set of AI-related controls. These should not, however, be treated as a universal checklist. The management-system approach requires organisations to determine which controls are appropriate to their context, objectives, risks and activities.

This distinction is important:

A control catalogue identifies possible controls; a control architecture determines which controls apply, why they apply, who owns them, how they operate, what evidence they produce and how their effectiveness is assessed.

The latter is consistent with the broader argument of this paper: effective governance depends on the integration of controls within organisational decision-making rather than the accumulation of compliance artefacts.

6.7 Documentation, Evidence and Auditability

ISO/IEC 42001 strengthens the concept of auditability developed in Chapter 3 by requiring documented processes and evidence across governance activities, performance evaluation, management review and corrective action.

Relevant evidence may include AI inventories, risk and impact assessments, approval records, system documentation, testing and validation results, monitoring reports, incident records, corrective actions, audit reports and management-review records.

This creates several layers of evidence:

System evidence — What did the AI system do?

Process evidence — What governance processes were performed?

Decision evidence — Who made the relevant decisions?

Control evidence — Which controls operated?

Assurance evidence — Were those controls tested?

Management evidence — Did leadership review the results?

This distinction is critical:

Documentation demonstrates that a process exists or occurred; it does not, by itself, demonstrate that the process was effective.

6.8 Performance Evaluation and Management Review

A management system must establish whether it is working. ISO/IEC 42001 therefore incorporates monitoring, measurement, analysis, evaluation, internal audit and management review.

Useful measures may include:

• coverage of AI systems within the inventory;

• percentage with assigned owners and completed risk assessments;

• control failures and overdue remediation;

• model performance, drift and incident rates where relevant;

• unresolved governance escalations;

• audit findings; and

• evidence of regulatory-control coverage.

The objective is not to maximise metrics but to provide decision-useful information to those responsible for governance.

Management review then connects this information to executive decision-making. Top management reviews the continuing suitability, adequacy and effectiveness of the AIMS, considering changes in context, performance, non-conformities, corrective actions, monitoring and audit results.

The resulting feedback loop is:

Evidence → Evaluation → Management review → Decision → Change → Monitoring

This prevents AI governance from becoming detached from organisational strategy and resource allocation.

6.9 Non-Conformity and Corrective Action

ISO/IEC 42001 also provides a structured approach to non-conformity and corrective action. Organisations are expected not merely to correct identified problems but to determine their causes, assess whether similar problems exist elsewhere and evaluate whether corrective actions are effective.

The distinction is therefore between:

Correction: fix the immediate problem.

Corrective action: address the cause and reduce the likelihood of recurrence.

For example, if an AI system is deployed without the required risk assessment, the appropriate response is not simply to complete the missing assessment. The organisation should ask why the control failed: Was responsibility unclear? Did the workflow permit deployment without approval? Was training inadequate? Did governance lack capacity? Could the control be automated?

This converts incidents into organisational learning and supports continual improvement.

6.10 Integration with Existing Management Systems

ISO/IEC 42001 need not create a separate governance universe. AI intersects with established management disciplines, including information security, privacy, quality, business continuity, enterprise risk and compliance.

The objective should therefore be integration rather than duplication.

For example, information-security controls may address access, confidentiality, integrity and availability, while the AIMS adds AI-specific considerations such as intended purpose, AI risks, human oversight, impact and lifecycle governance.

This illustrates an important principle:

AI governance should integrate with existing management systems without conflating their purposes.

The same logic applies to ISO/IEC 27001. An information-security management system can provide important infrastructure for an AIMS, but the two standards have different scopes. ISO/IEC 27001 focuses on information-security management, whereas ISO/IEC 42001 addresses the broader organisational governance of AI-related risks and responsibilities.

6.11 ISO/IEC 42001 and the EU AI Act

ISO/IEC 42001 and the EU AI Act perform different functions and should not be treated as equivalent.

The EU AI Act is legislation establishing legally binding obligations within its scope. ISO/IEC 42001 is a voluntary management-system standard that organisations can use to structure AI governance and support compliance. ISO explicitly states that the standard does not replace applicable laws or regulations.

The relationship can therefore be expressed as:

Law → obligation → organisational process → control → evidence → assurance

ISO/IEC 42001 can provide the organisational mechanism for managing this chain, but it does not determine the legal obligation itself.

Accordingly, certification to ISO/IEC 42001 should not be presented as proof of legal compliance. An organisation may operate a certified AIMS and still fail to meet a specific legal requirement; conversely, an organisation may meet applicable legal requirements without certification.

6.12 Mapping Regulation into Operational Governance

The practical value of the management-system approach lies partly in its ability to translate external requirements into accountable organisational processes.

A useful chain is:

Regulatory requirement → Organisational obligation → Policy → Risk/control requirement → Owner → Procedure → Evidence → Monitoring/assurance

For example, a human-oversight requirement can be translated into defined oversight responsibilities, training, intervention procedures and override records. A risk-management requirement can become an assessment methodology, treatment process and documented risk decision. Monitoring requirements can become defined performance indicators, reporting processes and escalation thresholds.

This creates traceability between regulatory requirements and organisational evidence.

It also connects the management-system approach directly to the auditability framework developed in Chapter 3.

6.13 ISO/IEC 42001 and Controllability

The AIMS also strengthens the concept of controllability developed in Chapter 4. A control is useful only if the organisation can assign it, operate it, monitor it and intervene when it fails.

A mature intervention process can therefore be represented as:

Detection → Threshold exceeded → Owner notified → Risk assessed → Authorised intervention → Corrective action → Verification → Management review

The important point is that controllability is not merely the technical ability to stop or modify an AI system. It is the organisational ability to determine who acts, when they act, on what evidence and with what authority.

ISO/IEC 42001 provides a framework for embedding that capability within repeatable organisational processes.

6.14 From Symbolic Governance to Institutional Capability

The broader contribution of ISO/IEC 42001 is therefore institutionalisation.

Chapter 5 distinguished between governance roles and genuine governance capacity. A management-system approach strengthens that capacity by connecting otherwise separate activities:

Policy → Objectives → Risk assessment → Controls → Operation → Monitoring → Audit → Management review → Corrective action → Improvement

This provides a mechanism for moving from symbolic governance towards operational and institutionalised governance, consistent with the governance-maturity model discussed in Chapter 5 and the organisational findings of Frimpong and Botchey (2026).

The progression can be expressed as:

Artefacts → Controls → Governance architecture → Management system → Institutional capability

ISO/IEC 42001 is particularly valuable at the fourth level because it provides a formal structure for integrating the preceding elements.

6.15 Limitations of the Management-System Approach

ISO/IEC 42001 should not, however, be treated as a complete solution to AI governance.

First, management systems can become bureaucratic, with organisations prioritising documentation over substantive control. Second, certification can create compliance substitution, where certification is mistaken for evidence that AI is safe, lawful or effective. Third, management systems cannot resolve every substantive question concerning fairness, human rights, social impact or acceptable risk. Those questions still require organisational judgement and, where appropriate, legal and ethical expertise.

Finally, formal compliance does not guarantee an effective governance culture. Escalation can still be ignored, incentives can still undermine controls and employees may still fail to report problems.

The central limitation is therefore:

A management system is infrastructure for governance, not a substitute for governance judgement.

6.16 AIMS as an Organisational Operating Model

The role of ISO/IEC 42001 can now be stated more precisely. It is not simply an “AI compliance standard”; it provides an organisational operating model for AI governance.

The model can be reduced to nine questions:

1. Scope — What AI activities are governed?

2. Purpose — Why are they being used?

3. Risk — What could go wrong?

4. Responsibility — Who owns the outcome and risk?

5. Control — What mechanisms manage the risk?

6. Evidence — How can implementation be demonstrated?

7. Performance — Are the systems and controls working?

8. Assurance — How is effectiveness evaluated?

9. Improvement — What must change as circumstances evolve?

Together, these questions establish a continuous management cycle linking AI strategy, risk, accountability, controls, evidence and improvement.

6.17 Conclusion

ISO/IEC 42001 provides the management-system foundation for the governance architecture developed throughout this paper. Its principal contribution is not to prescribe how individual AI models should be engineered, but to establish an organisational framework through which AI can be systematically governed across its lifecycle.

The standard strengthens the three core capabilities developed in earlier chapters:

• Auditability, by creating documented processes and evidence through which governance activities can be demonstrated;

• Controllability, by embedding responsibilities, authorities, controls, monitoring and corrective action; and

• Accountability, by requiring defined responsibilities, authorities and reporting to management.

Biroğul, Şahin and əsgərli (2025) further support this organisational interpretation by examining ISO/IEC 42001 in relation to responsible AI, data security, operational efficiency and regulatory compliance.

At the same time, ISO/IEC 42001 must remain conceptually distinct from the EU AI Act. The Act establishes legal obligations; ISO/IEC 42001 provides a management-system framework through which an organisation can identify, implement, evidence and continually review processes addressing those obligations.

The resulting architecture is:

Regulation establishes obligations.
Governance structures allocate responsibility and authority.
ISO/IEC 42001 provides the management-system architecture.
Controls operationalise governance.
Evidence makes governance auditable.
Monitoring and intervention make governance controllable.
Audit and management review drive continual improvement.

The next chapter can therefore move from management-system architecture to integration: how ISO/IEC 42001 and the EU AI Act can be mapped into a single organisational control architecture that connectsregulatory requirements with accountable owners, operational controls, evidence and assurance.

7. Integrating the EU AI Act and ISO/IEC 42001

The relationship between the EU Artificial Intelligence Act (EU AI Act) and ISO/IEC 42001:2023 is central to an effective organisational AI governance architecture. Although both address AI risk, accountability and responsible use, they perform fundamentally different functions.

The EU AI Act is binding legislation establishing legal obligations for actors and systems within its scope. ISO/IEC 42001 is an international management-system standard providing a framework for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS).

The distinction can therefore be stated simply:

The EU AI Act establishes external legal obligations; ISO/IEC 42001 provides an organisational system for managing AI risks, responsibilities, controls, evidence and improvement.

The two instruments should consequently be viewed as complementary rather than interchangeable. The AI Act establishes what the law requires; the AIMS provides a structured mechanism through which an organisation can identify applicable requirements, translate them into controls, assign responsibility, generate evidence and evaluate effectiveness.

ISO itself makes clear that ISO/IEC 42001 does not replace laws or regulations; it provides a management framework that can help organisations address applicable compliance obligations.

7.1 Different Functions, One Governance Architecture

The distinction between the two instruments is best understood as a distinction between external obligation and internal management capability.

The EU AI Act determines, among other things:

• which AI practices are prohibited;

• which systems fall within particular regulatory categories;

• which obligations apply to providers, deployers and other actors;

• requirements concerning risk management, data governance, documentation, logging and human oversight;

• transparency and other specific obligations; and

• enforcement and sanctions.

ISO/IEC 42001 addresses the organisational questions required to manage these and other AI risks:

• What AI systems and activities does the organisation have?

• Which risks and obligations apply?

• Who is accountable?

• What controls are required?

• How are controls implemented and monitored?

• What evidence demonstrates implementation?

• How are incidents and non-conformities addressed?

• How does management review performance?

• How are governance arrangements improved?

The resulting architecture is:

Law and regulation
↓
Regulatory obligations
↓
Organisational governance
↓
ISO/IEC 42001 management system
↓
Policies, risk assessments and controls
↓
Operational and technical implementation
↓
Evidence, monitoring and assurance

This distinction prevents a common analytical error: treating a legal requirement itself as a control. A requirement establishes an obligation; the organisation must determine how that obligation will be operationalised.

7.2 The EU AI Act as the External Regulatory Layer

The EU AI Act should therefore be positioned as an external regulatory layer within the wider governance architecture.

It is also only one component of the organisation's regulatory environment. Depending on the use case, AI may simultaneously be subject to data-protection, employment, consumer-protection, financial-services, product-safety, cybersecurity, intellectual-property and sector-specific requirements.

This reinforces the value of an AIMS. ISO/IEC 42001 is not structured around one statute or regulatory jurisdiction. It provides an organisational framework for managing AI across different contexts and for incorporating changing external requirements. ISO describes the AIMS as a set of interrelated organisational elements for establishing policies, objectives and processes relating to the responsible development, provision or use of AI systems.

The management system therefore provides continuity while the external regulatory environment changes.

7.3 Risk-Based Regulation and Enterprise AI Risk

The two instruments also differ in their organising logic.

The EU AI Act uses a risk-based regulatory framework, with different requirements applying according to the characteristics and regulatory classification of AI systems and uses.

ISO/IEC 42001 instead provides a management-system framework for managing AI-related risks and opportunities across an organisation. It is therefore not limited to systems that fall within a particular statutory category.

This distinction matters at enterprise level.

An organisation should not equate:

“AI regulated by the AI Act”

with:

“AI that requires governance.”

AI systems outside a particular AI Act category may nevertheless create material:

• cybersecurity risk;

• privacy risk;

• operational risk;

• discrimination risk;

• intellectual-property risk;

• safety risk;

• reputational risk; or

• strategic risk.

The AI Act therefore defines important legal boundaries, while the AIMS can establish a broader enterprise risk perimeter.

This allows governance to remain proportionate without becoming dependent upon legal classification alone.

7.4 A Dynamic Regulatory Environment

The importance of this distinction has increased as implementation of the AI Act has progressed.

The Act entered into force on 1 August 2024. Prohibitions and AI-literacy provisions began applying from 2 February 2025; governance provisions and obligations concerning general-purpose AI models began applying from 2 August 2025; and the broader framework applies from 2 August 2026, subject to specific transitional arrangements.

As of August 2026, the implementation timetable remains differentiated. Following the 2026 AI Omnibus changes, rules for certain high-risk systems under Annex III apply from 2 December 2027, while high-risk AI systems embedded in regulated products under Annex I apply from 2 August 2028.

The practical implication is important: regulatory change itself becomes a governance process.

An organisation must be able to determine:

1. what requirements currently apply;

2. what requirements will apply later;

3. which AI systems are affected;

4. which controls require modification;

5. who owns the transition;

6. what evidence is required; and

7. whether existing controls remain effective.

A mature AIMS provides an appropriate organisational mechanism for managing this cycle.

7.5 From Regulatory Requirement to Operational Control

The central practical challenge is translating legal requirements into organisational controls.

A useful chain is:

Requirement → Applicability → Risk → Control → Owner → Evidence → Assurance

For example, a requirement concerning human oversight should not simply be copied into an AI policy. The organisation must determine:

Who?
Who performs oversight?

What?
What information must they receive?

When?
At what points must intervention occur?

Authority?
Can the individual reject or override an AI output?

Capability?
Can the system actually be stopped or overridden?

Competence?
What training is required?

Evidence?
How is oversight demonstrated?

Assurance?
How is its effectiveness evaluated?

This illustrates why AI compliance cannot be reduced to a checklist. Legal concepts such as appropriate, effective, proportionate and risk-based require organisational interpretation and operationalisation.

ISO/IEC 42001 provides the management-system structure through which that translation can occur.

7.6 Mapping the AI Act into the AIMS

A practical way of implementing this approach is through a regulatory-to-control matrix that translates regulatory requirements into specific organisational responses and identifiable evidence. Rather than treating regulatory compliance as a purely legal exercise, the matrix connects each requirement area to the processes, controls and governance mechanisms through which the organisation intends to address it.

For risk management, the organisation should establish an AI risk assessment and treatment process, supported by risk assessments and treatment records. Data governance should be addressed through data-quality, provenance and governance controls, with evidence such as data specifications and testing records. Technical documentation should be managed through a defined documentation lifecycle with clear ownership, supported by technical documentation and version records. Logging should be governed through appropriate logging, retention and access controls, with logs and retention records providing evidence of operation.

Human oversight should be implemented through defined oversight roles, intervention and override procedures, supported by training records, role assignments and records of overrides or interventions. Accuracy, robustness and cybersecurity should be addressed through validation, testing and security controls, with test results, validation evidence and security assessments demonstrating their operation. Monitoring should cover system performance, impacts and incidents, supported by monitoring and incident reports. Where weaknesses or non-conformities are identified, a defined corrective-action process should ensure that issues are recorded, assigned, remediated and followed up, with corrective-action records providing evidence. Finally, management review should provide periodic executive oversight of the AI management system's performance, with management-review records demonstrating that governance effectiveness, risks and improvement needs have been considered.

The matrix does not mean that ISO/IEC 42001 automatically satisfies the corresponding AI Act obligations. Rather, it demonstrates how an AI Management System (AIMS) can provide the organisational scaffolding through which legal requirements are allocated, implemented, evidenced and reviewed. The AI Act remains the source of the applicable legal obligations, while ISO/IEC 42001 can provide a structured management framework for embedding those obligations into organisational processes, controls and assurance activities.

7.7 Standards as a Bridge Between Law and Practice

The relationship becomes more complex because standards can also occupy an important position between legislation and implementation.

The European Commission has mandated European standardisation organisations to develop standards supporting implementation of the AI Act. Where applicable harmonised standards are followed, providers of relevant high-risk AI systems can benefit from a presumption of conformity with corresponding requirements, subject to the applicable legal conditions. The standardisation work remains ongoing.

This creates several distinct layers:

Legislation
→ establishes binding obligations

Regulatory guidance
→ supports interpretation and implementation

Harmonised European standards
→ may support conformity with specified legal requirements

ISO/IEC 42001
→ establishes an organisational management-system framework

Internal policies and controls
→ translate requirements into organisational action

Technical implementation
→ executes the controls

These layers should not be conflated.

In particular, ISO/IEC 42001 is not a harmonised AI Act standard merely because it is an ISO standard. Its value is primarily organisational: it helps establish the processes through which legal and other requirements can be managed.

7.8 One Control Architecture, Multiple Sources of Authority

A mature organisation should avoid creating separate compliance programmes for each framework.

Instead, it should establish common controls with multiple sources of authority.

For example, a single AI risk-management process may support:

• EU AI Act obligations;

• ISO/IEC 42001 requirements;

• enterprise-risk policy;

• information-security requirements;

• privacy obligations; and

• sector-specific regulation.

The architecture becomes:

Multiple requirements
↘ ↓ ↙
Shared control
↓
Shared evidence
↓
Common assurance

The efficiency gains are significant, but only if traceability is maintained. The organisation should be able to identify which requirements a control addresses, which systems it applies to, who owns it and what evidence demonstrates effectiveness.

7.9 The Regulatory-Control Matrix

A practical governance instrument is therefore a regulatory-control matrix that connects each applicable requirement to its regulatory or management-system source, the circumstances in which it applies, the control established to address it, the person or function responsible, the evidence generated and the mechanism through which effectiveness is assured. This provides a clear line of sight from requirement → applicability → control → ownership → evidence → assurance, helping to ensure that regulatory obligations are translated into operational governance rather than remaining at the level of policy statements.

For human oversight, relevant EU AI Act requirements should be translated into defined oversight and intervention procedures, owned by the business or system owner and evidenced through training records and override or intervention records, with internal audit providing independent assurance. Risk management requirements arising from the EU AI Act and ISO/IEC 42001 should be addressed through AI risk assessments for material AI systems, owned by the risk function and evidenced through the risk register and associated assessment records, with risk assurance testing their effectiveness. Documentation requirements should be addressed through a defined documentation lifecycle for relevant systems, with the AI owner accountable for maintaining technical documentation and compliance review providing assurance.

Monitoring should translate applicable EU AI Act and ISO/IEC 42001 requirements into performance and impact monitoring controls, with AI teams responsible for operation and monitoring reports providing evidence, supported by model assurance. Incident management should be implemented through a defined AI incident process, owned operationally and evidenced through incident records, with internal audit providing independent assurance where appropriate. Finally, management review under ISO/IEC 42001 should provide periodic executive review of the AI management system, with executive management accountable for the review and formal review records providing evidence, supported by internal audit and, where applicable, external certification.

The matrix should therefore be treated as a living governance artefact, rather than a static compliance document. Applicability should be reassessed when systems, regulations, suppliers or intended uses change; controls should be tested for effectiveness; evidence should be retained; and assurance findings should feed back into risk management and corrective action. Importantly, the matrix does not imply that ISO/IEC 42001 automatically establishes compliance with the EU AI Act. Instead, it provides a structured mechanism for connecting legal requirements with organisational controls, ownership, evidence and assurance, while preserving the distinction between regulatory obligation and management-system implementation.

The matrix establishes six critical properties:

• traceability — where does the requirement originate?

• applicability — which systems are affected?

• accountability — who owns implementation?

• control — what mechanism addresses the requirement?

• auditability — what evidence exists?

• assurance — who tests effectiveness?

This converts regulatory interpretation into an operational governance structure.

Do the same for this section:7.10 Avoiding Two Opposite Errors
Two analytical errors should be avoided.

ISO/IEC 42001 does not equal AI Act compliance

It would be incorrect to conclude:

“The organisation is ISO/IEC 42001 certified; therefore it complies with the EU AI Act.”

Certification demonstrates conformity of the management system to the standard within the relevant scope. It does not constitute a blanket legal-compliance determination for every AI system or activity.

ISO itself states that ISO/IEC 42001 does not replace applicable laws or regulations.

The correct proposition is:

ISO/IEC 42001 can support compliance; it cannot replace legal compliance analysis.

The AI Act does not equal complete AI governance

The reverse assumption is equally problematic.

The AI Act establishes important legal requirements, but enterprise AI risk extends beyond statutory classification. Organisations may face material risks from AI systems that are not subject to the same regulatory requirements as high-risk systems.

An enterprise governance framework should therefore maintain a broader risk perimeter than the AI Act alone.

7.11 Regulatory Change as an Internal Control

Regulatory horizon scanning should itself be treated as an internal governance process.

A mature organisation should maintain a cycle of:

Regulatory monitoring
↓
Legal interpretation
↓
Applicability assessment
↓
Affected-system identification
↓
Control-gap analysis
↓
Implementation
↓
Evidence
↓
Assurance
↓
Management review

This creates a feedback loop between the external environment and the AIMS.

Such a process becomes increasingly important as AI regulation, guidance and technical standards evolve. The current AI Act implementation timetable demonstrates why a static compliance assessment is insufficient.

The objective is not to predict every regulatory change. It is to ensure that the organisation has a repeatable mechanism for detecting, interpreting and absorbing change.

7.12 Assurance Across Multiple Layers

The complementary relationship also requires layered assurance.

Different assurance activities answer different questions:

Legal assurance
Are applicable legal obligations being addressed?

Management-system assurance
Is the AIMS operating as designed?

Control assurance
Are individual controls implemented and effective?

Technical assurance
Does the AI system perform within defined requirements?

Independent assurance
Can an independent function challenge management's assessment?

These should not be treated as interchangeable.

A model-validation exercise may establish technical performance without demonstrating regulatory compliance. Conversely, an audit may establish that a risk-assessment process was followed without establishing that the underlying model is technically robust.

AI governance therefore requires assurance across law, management system, controls and technology.

7.13 Traceability and Accountability

The most important practical consequence of integrating the two frameworks is traceability.

A mature governance architecture should support both:

Forward traceability

Regulation → requirement → control → owner → system → evidence

and:

Backward traceability

Incident → failed control → requirement → responsibility → regulatory exposure

Forward traceability supports compliance planning and implementation.

Backward traceability supports investigation, accountability and remediation.

Together, they create a stronger basis for auditability because the organisation can demonstrate not only what requirements exist, but how those requirements connect to actual systems, decisions, controls and evidence.

This is consistent with the management-system logic of ISO/IEC 42001, which is designed to create structured organisational processes for managing AI risks and opportunities across the organisation.

7.14 Integrated Governance Architecture

The combined architecture can therefore be expressed as:

EXTERNAL ENVIRONMENT

EU AI Act + other legislation + regulatory guidance
↓
REQUIREMENTS MAPPING
↓
ISO/IEC 42001 — AIMS
↓
Governance + Leadership + Risk Management
↓
AI CONTROL ARCHITECTURE
↓
Technical controls + process controls + human oversight
↓
OPERATIONAL AI SYSTEMS
↓
MONITORING + EVIDENCE
↓
ASSURANCE + MANAGEMENT REVIEW
↓
CORRECTIVE ACTION + IMPROVEMENT
↺
AIMS

This model captures the central relationship between the two instruments.

The EU AI Act operates primarily as an external source of legal requirements.

ISO/IEC 42001 operates as the internal management-system architecture through which those and other AI risks can be governed.

Governance functions connect the two.

Controls translate requirements into action.

Evidence makes implementation demonstrable.

Assurance tests effectiveness.

Management review determines whether the system must change.

7.15 Strategic Value: Regulatory Adaptability

The strategic value of this integration extends beyond immediate compliance.

An organisation with an established AIMS is likely to possess many of the organisational capabilities needed to absorb future requirements:

• AI inventories;

• defined governance roles;

• risk-assessment processes;

• control libraries;

• evidence mechanisms;

• monitoring;

• audit processes; and

• management-review mechanisms.

When a new requirement emerges, the organisation can therefore adapt the existing architecture rather than establish another independent compliance programme.

This creates a form of regulatory adaptability.

The value of ISO/IEC 42001 is consequently not limited to helping an organisation address today's requirements. Its greater value may lie in providing an organisational infrastructure capable of incorporating tomorrow's requirements.

7.16 Limitations and Qualifications

The integration should nevertheless be treated with caution.

First, a management system can become bureaucratic if organisations optimise for documentation rather than control effectiveness.

Second, certification can create compliance substitution, where managers treat certification as evidence that all AI activities are lawful and appropriately governed.

Third, ISO/IEC 42001 cannot resolve substantive questions of acceptable risk, fairness, fundamental rights or appropriate AI use. These require organisational judgement and, where appropriate, legal, ethical and technical expertise.

Fourth, the European standardisation environment remains dynamic. The Commission has noted delays in the development of harmonised standards supporting high-risk AI requirements, which contributed to the revised implementation timetable.

Finally, the effectiveness of any AIMS depends upon how seriously it is implemented. A formally conforming management system can remain weak if escalation is ignored, controls are ineffective or commercial incentives consistently override governance decisions.

The appropriate conclusion is therefore:

A management system is infrastructure for governance, not a substitute for governance judgement.

7.17 Conclusion

The EU AI Act and ISO/IEC 42001 should be understood as complementary components of an integrated AI governance architecture.

The EU AI Act provides the external legal framework. It establishes binding obligations, prohibitions, risk classifications and requirements applicable to relevant AI systems and actors. ISO/IEC 42001 provides an organisational management-system framework through which AI policies, risks, responsibilities, controls, monitoring and continual improvement can be institutionalised.

Their relationship can therefore be expressed as:

Law establishes the obligation.
Governance assigns accountability.
ISO/IEC 42001 structures the management response.
Controls operationalise the response.
Evidence demonstrates implementation.
Assurance tests effectiveness.
Management review drives adaptation.

The significance of this relationship is heightened by the evolving implementation of the AI Act. As of August 2026, the Act's broader framework is applicable, while specific high-risk provisions remain subject to differentiated transition dates, including 2 December 2027 and 2 August 2028.

The appropriate organisational response is therefore not a static “AI Act compliance project”, nor two parallel programmes for the AI Act and ISO/IEC 42001. It is a single, integrated control architecture with multiple sources of authority.

The central proposition of this chapter is therefore:

The strategic value of ISO/IEC 42001 in the context of the EU AI Act lies not in substituting for legal compliance, but in providing an organisational infrastructure through which regulatory obligations can be identified, interpreted, assigned, operationalised, evidenced, assured and continually improved.

This establishes the foundation for the next chapter: a requirements-to-controls-to-evidence model showing how legal requirements and management-system requirements can be translated into accountable owners, operational controls, evidence and assurance within a single AI governance architecture.

8. Compliance as a Continuous Lifecycle

The preceding chapters have established that AI governance is not adequately understood as a static compliance exercise. The same principle becomes particularly important when governance is considered across the AI lifecycle. The proposition that organisations should make AI systems “auditable, controllable and compliant” necessarily implies that these properties must be established and maintained from initial conception through deployment, operation, modification and eventual retirement.

AI governance should therefore be understood as a lifecycle capability, rather than a point-in-time approval mechanism.

A simplified lifecycle can be represented as:

Idea → Classification → Risk assessment → Design → Data → Development → Validation → Approval → Deployment → Monitoring → Incident response → Change management → Retirement

The precise stages will differ between organisations and AI technologies. However, the underlying principle remains consistent: governance decisions, controls and evidence should accompany the system throughout its lifecycle.

This perspective is particularly important because AI systems are not necessarily static once deployed. Models may be retrained, data distributions may change, suppliers may modify underlying models or APIs, system purposes may expand, users may develop new practices and regulatory requirements may evolve. Consequently, a system that was appropriately governed at deployment may no longer remain appropriately governed later in its lifecycle.

8.1 From Point-in-Time Compliance to Continuous Governance

A conventional compliance model often assumes a sequence such as:

Build → Assess → Approve → Deploy

This creates an implicit assumption that compliance is something that can be established before production and then maintained passively.

For AI systems, this assumption is problematic.

A more appropriate model is:

Govern → Build → Assess → Approve → Operate → Monitor → Reassess → Change → Reapprove where necessary

The difference is fundamental.

In the first model, compliance is an event.

In the second, compliance is a process.

This distinction mirrors the broader management-system logic of ISO/IEC 42001, which requires organisations to establish, implement, maintain and continually improve an Artificial Intelligence Management System. The standard therefore provides an organisational basis for treating AI governance as an ongoing management activity rather than a one-off certification or approval exercise (ISO, 2023).

The EU AI Act similarly embeds lifecycle thinking into its requirements for relevant high-risk AI systems. Article 9 requires providers to establish, implement, document and maintain a risk-management system as an iterative process that runs throughout the lifecycle of the high-risk AI system (European Parliament and Council of the European Union, 2024).

Thus, two complementary ideas converge:

The AI Act establishes lifecycle-oriented legal obligations for relevant systems.

ISO/IEC 42001 provides a management-system architecture for continually governing AI across organisational processes.

8.2 Why Lifecycle Governance Matters

The need for lifecycle governance arises from the sociotechnical character of AI systems.

An AI system's risk is not determined solely by the algorithm.

It may depend upon:

• the purpose for which it is used;

• the data on which it operates;

• the population affected;

• the surrounding workflow;

• human decision-making;

• technical infrastructure;

• supplier dependencies;

• cybersecurity conditions;

• changes in the operating environment; and

• organisational incentives.

Consequently, AI risk can change without the underlying model code changing.

For example, an AI system used to prioritise customer-service requests might initially be deployed for low-impact internal triage. If the organisation subsequently changes the workflow so that the system determines which customers receive expedited treatment, the system's consequences may change substantially.

Similarly, a model trained on historical data may exhibit acceptable performance when initially validated but deteriorate as the underlying population or behaviour changes.

Lifecycle governance therefore recognises that:

The governance status of an AI system is partly a function of its changing context, not merely its original technical configuration.

8.3 The AI Lifecycle as a Governance Lifecycle

The AI lifecycle should consequently be understood as two interrelated processes:

Technical lifecycle

Design → Develop → Test → Deploy → Operate → Modify → Retire

Governance lifecycle

Classify → Assess → Authorise → Monitor → Review → Intervene → Reassess → Retire

These processes should be integrated.

A technically driven lifecycle may ask:

“Is the model ready for production?”

A governance-driven lifecycle additionally asks:

“Is the organisation authorised to deploy it, are the risks acceptable, are required controls operational, is the evidence complete and is there sufficient authority to intervene if circumstances change?”

The result is a dual lifecycle in which technical development and governance evolve together.

8.4 Stage 1: Idea and Use-Case Definition

Governance should begin before technical development.

At the ideation stage, the organisation should establish:

• the intended purpose;

• the business problem;

• expected benefits;

• proposed users;

• affected individuals or groups;

• decision-making consequences;

• data requirements;

• proposed AI technology;

• anticipated level of autonomy;

• supplier dependencies; and

• preliminary risk classification.

This stage is particularly important because the intended purpose can determine the regulatory and governance consequences of an AI system.

A poorly defined use case creates ambiguity later.

For example, “use generative AI to improve HR processes” is insufficiently precise for governance purposes.

A more useful definition might specify:

“Use an AI system to summarise candidate application materials for recruitment personnel, without allowing the system to make final hiring decisions.”

The distinction affects risk assessment, human oversight, data governance, validation and approval.

Thus:

Purpose definition is itself a governance control.

8.5 Stage 2: Classification and Applicability Assessment

Once the use case is defined, the organisation should determine which regulatory and organisational requirements apply.

This can include:

• whether the system is within the scope of the EU AI Act;

• whether it constitutes a prohibited practice;

• whether it is classified as high-risk;

• whether transparency obligations apply;

• whether it involves general-purpose AI;

• whether sector-specific legislation applies;

• whether personal data is involved;

• whether internal AI-risk criteria classify the system as material.

This stage should produce a documented applicability decision.

A governance register can provide a structured record of the key decisions made when an AI use case enters the governance process. It should first establish whether an AI system has been identified and whether its intended purpose has been documented. The organisation can then record whether the EU AI Act is applicable and, where it is, the relevant risk category. The register should also capture the assessment of important cross-cutting implications, including privacy and cybersecurity, and record whether human oversight is required.

The register should additionally document whether the system falls within the scope of the organisation's AI Management System (AIMS) and identify the authority responsible for approving the use case. For example, the governance record may establish that an identified AI system has a documented intended purpose, is subject to the EU AI Act, falls within a high-risk or other applicable category, has had its privacy and cybersecurity implications assessed, requires human oversight, is included within the AIMS scope and requires approval by the AI governance committee.

This creates a clear governance decision trail from the initial identification of an AI use case through to its regulatory classification, risk assessment, applicable controls and approval authority. The register therefore provides the foundation for traceability between the original business decision and the subsequent control architecture, while also creating an auditable record of why particular governance requirements were applied.

8.6 Stage 3: Risk and Impact Assessment

Classification should be followed by structured risk and impact assessment.

The organisation should consider both technical risks and sociotechnical consequences.

Relevant questions may include:

• What can go wrong?

• Who may be affected?

• How severe could the consequences be?

• How likely are adverse outcomes?

• Can affected individuals challenge decisions?

• Can human operators detect system failure?

• Can the system be overridden?

• What dependencies exist?

• What happens if the system becomes unavailable?

• What new risks arise from automation?

For high-risk systems, Article 9 of the EU AI Act requires a documented risk-management system covering the identification and analysis of known and reasonably foreseeable risks, evaluation of risks under intended and reasonably foreseeable misuse conditions, and adoption of appropriate risk-management measures (European Parliament and Council of the European Union, 2024).

This supports the broader argument that risk assessment should not be a static document.

It should be iterative.

8.7 Stage 4: Design for Governance

A significant implication follows from lifecycle thinking:

Governance requirements should influence system design before implementation decisions become expensive or difficult to reverse.

This is sometimes described as “governance by design” or, in related fields, “privacy by design” and “security by design”.

Governance requirements may influence:

• system architecture;

• data flows;

• logging;

• access control;

• human interfaces;

• escalation mechanisms;

• explainability mechanisms;

• model versioning;

• rollback capability;

• monitoring;

• audit trails; and

• retention.

For example, if the organisation determines that authorised humans must be able to intervene in a particular AI process, this requirement should influence architecture from the beginning.

It is considerably harder to create meaningful intervention capability after an automated workflow has been fully integrated into downstream systems.

Thus:

Governance is most effective when incorporated into architecture rather than retrofitted through documentation.

8.8 Stage 5: Data Governance

Data should be treated as a distinct lifecycle governance domain.

Relevant governance questions include:

• What data is being used?

• Where did it originate?

• What rights or permissions apply?

• Is it appropriate for the intended purpose?

• How is quality assessed?

• How is bias or representativeness assessed?

• How is access controlled?

• How long is data retained?

• What changes occur over time?

• What happens when source data changes?

For relevant high-risk AI systems, the EU AI Act establishes requirements concerning data and data governance, including examination of relevant data sets with respect to factors such as relevant design choices, data collection processes, preparation, biases and appropriateness for the intended purpose (European Parliament and Council of the European Union, 2024).

The governance implication is that data should not be viewed simply as an input into model development.

It is itself a governed asset with a lifecycle.

8.9 Stage 6: Development

During development, governance should be integrated with technical engineering processes.

Relevant controls may include:

• secure development practices;

• version control;

• model documentation;

• training-data records;

• experiment tracking;

• reproducibility;

• access control;

• code review;

• testing;

• validation;

• dependency management; and

• segregation of development and production environments.

This is where the concept of governance affordances becomes important.

Recent research argues that governance requirements need to be incorporated into software-development processes rather than treated as separate activities. Governance affordances can be understood as technical and organisational features that make responsible governance possible within development and operational workflows.

The significance is that governance should become part of the developer's normal workflow.

For example, rather than requiring a developer to remember to produce a separate compliance report at the end of a project, the development environment could automatically capture:

• model version;

• dataset version;

• test results;

• approval status;

• change history; and

• deployment metadata.

The system therefore produces evidence as a by-product of development.

8.10 Stage 7: Validation and Assurance

Before deployment, the organisation should establish whether the system satisfies its defined technical, organisational and regulatory requirements.

Validation may include:

• performance testing;

• robustness testing;

• security testing;

• bias and fairness assessment where relevant;

• data-quality assessment;

• explainability assessment;

• human-oversight testing;

• adversarial testing;

• usability assessment; and

• operational resilience testing.

Importantly, validation should be linked to intended purpose.

A model can perform well on a technical benchmark and still be unsuitable for a particular organisational use.

The relevant question is therefore not merely:

“Is the model accurate?”

but:

“Is the system sufficiently reliable, safe, secure and controllable for the purpose for which the organisation intends to use it?”

For relevant high-risk AI systems, the EU AI Act requires appropriate levels of accuracy, robustness and cybersecurity, while also requiring appropriate testing and documentation (European Parliament and Council of the European Union, 2024).

8.11 Stage 8: Approval and Authorisation

Deployment should be an explicit governance decision.

The organisation should be able to demonstrate:

• who approved deployment;

• what information they considered;

• which risks were accepted;

• which controls were required;

• whether outstanding issues were accepted or remediated;

• what monitoring would be undertaken;

• what conditions were attached to deployment; and

• when reassessment would be required.

This is a critical point at which decision rights become operational.

A mature governance model might establish:

Technical team: confirms technical readiness.

Risk/compliance: confirms governance requirements have been assessed.

Business owner: confirms operational purpose and accepts accountable ownership.

Authorised governance body: approves deployment where required by organisational policy or risk threshold.

This prevents technical readiness from being mistaken for organisational authorisation.

8.12 Stage 9: Deployment and Operational Control

Deployment marks the transition from development to operational governance.

At this point, the organisation should ensure that:

• approved versions are deployed;

• access is controlled;

• monitoring is active;

• logs are generated;

• human oversight is operational;

• escalation procedures are known;

• fallback processes exist;

• incidents can be reported; and

• unauthorised changes are prevented.

This is where the earlier distinction between auditability and controllability becomes particularly important.

The deployed system should be:

observable enough to understand and controllable enough to intervene.

Logging without intervention capability creates observability without meaningful control.

Conversely, intervention capability without sufficient monitoring may result in an organisation being unable to determine when intervention is necessary.

8.13 Stage 10: Continuous Monitoring

Deployment is therefore not the end of governance.

The organisation should monitor relevant dimensions of:

Technical performance

• accuracy;

• reliability;

• latency;

• failure rates;

• model drift.

Risk

• emerging risks;

• unexpected uses;

• adverse impacts;

• misuse.

Security

• attacks;

• anomalous behaviour;

• vulnerabilities;

• unauthorised access.

Human oversight

• override frequency;

• escalation frequency;

• operator workload;

• evidence of effective intervention.

Regulatory compliance

• changes in applicable requirements;

• new guidance;

• changes in classification;

• documentation requirements.

Operational context

• changes in users;

• changes in data;

• changes in business processes;

• changes in suppliers.

Monitoring therefore provides the feedback mechanism between operation and governance.

8.14 Drift and Changing Conditions

Model drift is often discussed as a technical phenomenon, but lifecycle governance demonstrates that it is also a governance issue.

There are at least three relevant forms of change:

Data drift

The characteristics of input data change.

Model drift

Performance changes as the relationship between inputs and outcomes evolves.

Context drift

The organisational or social context changes even when the model itself does not.

The third category is particularly important.

Suppose a fraud-detection model remains technically unchanged but the organisation begins using it to automatically block transactions rather than merely flag suspicious activity.

The technical system may be identical.

The governance significance is not.

This demonstrates that lifecycle reassessment should be triggered not only by model changes but also by changes in intended purpose, decision authority, affected populations and operating context.

8.15 Stage 11: Incident Response

AI incidents should be integrated into the organisation's broader incident-management architecture.

An AI incident could include:

• materially incorrect outputs;

• harmful recommendations;

• unexpected discriminatory outcomes;

• security compromise;

• privacy breach;

• unauthorised use;

• loss of human control;

• material system failure;

• prohibited use;

• significant model drift; or

• failure of required governance controls.

The incident process should establish:

1. detection;

2. triage;

3. containment;

4. escalation;

5. investigation;

6. notification where required;

7. corrective action;

8. root-cause analysis; and

9. lessons learned.

The distinction between incident response and corrective action is important.

Stopping an incident addresses the immediate problem.

Understanding why the governance system permitted the incident to occur supports longer-term improvement.

8.16 Stage 12: Change Management

Change management is one of the most important lifecycle controls because an AI system can change materially after its initial approval. Changes may arise through retraining, fine-tuning, model replacement, changes to data sources, parameter adjustments, prompt modifications, software or infrastructure updates, vendor changes, alterations to downstream workflows, or changes in the system's intended purpose. Each of these changes has the potential to alter system behaviour, risk exposure or the population affected by the system.

However, not every change should require complete reapproval. A mature governance system should therefore establish defined change thresholds that determine the appropriate governance response according to the significance and potential impact of the change. A minor configuration change may be managed through standard change control, whereas the introduction of a new data source may require a data-risk review. A model-version update may require technical validation, while a material change in performance may trigger formal risk reassessment. Changes affecting the user population may require an impact assessment, while a new intended purpose should result in a broader governance reassessment. A change that increases the degree of autonomous decision-making may warrant formal reapproval, while a material regulatory change should trigger a compliance reassessment.

This approach establishes the principle of proportionate reassessment. The objective is not to subject every technical modification to the same level of governance, but to ensure that the governance response is commensurate with the potential significance of the change. Changes that could alter the system's risk profile, intended purpose, affected population, autonomy or regulatory status should receive greater scrutiny than routine operational changes. In this way, change management becomes a mechanism for preserving the validity of the original governance assumptions as the system evolves.

8.17 Stage 13: Reassessment and Reapproval

Lifecycle governance therefore requires explicit reassessment triggers. Governance should not rely solely on scheduled reviews; certain events should automatically prompt consideration of whether the system's existing risk assessment, controls and approval remain appropriate. Potential triggers include a significant model or data change, a change in intended purpose or affected population, a material incident, significant deterioration in performance, a new regulatory requirement, a change in supplier, an increase in system autonomy or a significant cybersecurity event.

The organisation should define in advance which events require continued monitoring, risk reassessment, formal governance approval or temporary suspension. This allows governance decisions to be made consistently rather than on an ad hoc basis after a change has already occurred. It also establishes clear decision rights around when a system may continue operating, when additional controls or assessment are required, and when operation should be restricted until the implications of the change have been understood.

Reassessment and reapproval therefore form a critical component of controllability. The organisation is effectively defining the conditions under which the governance status of an AI system must be reconsidered. This creates an important feedback mechanism within the lifecycle: changes in the system or its environment can trigger renewed assessment, which can in turn result in revised controls, additional assurance, renewed approval or suspension. The objective is to ensure that an AI system does not retain an outdated governance status simply because it was once assessed and approved under materially different circumstances.

8.18 Stage 14: Retirement

Retirement is often treated as the point at which an AI system ceases to be operational. From a governance perspective, however, retirement is itself a significant lifecycle event. The withdrawal of an AI system can create legal, operational, data-protection, contractual, security and accountability consequences that require deliberate management.

The organisation should therefore determine whether the system is genuinely no longer required, whether other systems or business processes depend upon it, what data and records must be retained, which logs remain necessary for audit or regulatory purposes, whether contractual or supplier obligations continue, whether users require transition arrangements, whether model artefacts should be preserved, whether access and credentials should be revoked, and whether residual risks remain after operational use has ended.

Retirement should consequently be understood as a controlled transition from active operation to an appropriate state of decommissioning, retention or archival. The appropriate outcome will depend on the nature of the system and the organisation's legal and operational obligations. Some systems may simply be deactivated and securely disposed of; others may require substantial retention of technical documentation, decision records, logs, risk assessments, incident history and approval records.

The distinction between operational status and governance status is important. A system that is no longer producing outputs may nevertheless remain relevant to audit, regulatory enquiries, litigation, incident investigation, contractual obligations or organisational learning. Historical records may also be required to explain decisions made while the system was operational.

This creates an important principle:

The end of operational use does not necessarily mean the end of governance obligations.

The retirement stage therefore completes the lifecycle without erasing its history. Effective retirement preserves sufficient evidence to reconstruct why the system was introduced, how it was governed, what risks were identified, what occurred during operation and why it was ultimately withdrawn. This supports the wider conception of evidence as organisational memory developed in the preceding chapter.

Retirement also provides an opportunity for governance learning. The organisation should consider why the system was retired, whether the original purpose remained appropriate, whether its risk profile changed, whether incidents or performance limitations contributed to the decision, and whether lessons should influence other AI systems. Retirement can therefore function not only as a technical decommissioning activity but also as a point of organisational reflection and continual improvement.

8.19 Lifecycle Governance and the EU AI Act

The EU AI Act provides an important legal foundation for understanding AI governance as a lifecycle process. Article 9 requires providers of high-risk AI systems to establish, implement, document and maintain a risk-management system consisting of a continuous and iterative process planned and run throughout the entire lifecycle of the high-risk AI system (European Parliament and Council of the European Union, 2024).

The significance of this provision is both legal and conceptual. It rejects the assumption that AI risk can be adequately addressed through a single assessment performed before deployment. Instead, risk management must remain responsive to information and circumstances that emerge as the system is developed, deployed and used.

This includes consideration of known and reasonably foreseeable risks, the intended purpose of the system, reasonably foreseeable misuse and information obtained through operation and monitoring. Where circumstances change, the organisation must be capable of reassessing whether existing controls remain appropriate.

The lifecycle perspective is particularly important because AI systems operate within changing environments. Data may change, users may behave differently from anticipated, models may be modified, suppliers may change, regulatory requirements may evolve and new risks may become apparent through operational experience. A risk assessment that was reasonable at the point of initial deployment may therefore become inadequate later.

The EU AI Act's lifecycle orientation consequently supports the central proposition of this chapter:

AI compliance is a lifecycle property rather than a deployment event.

Compliance should therefore be understood as an ongoing organisational capability through which the organisation maintains the conditions necessary for lawful, safe and appropriately governed operation rather than as a status achieved once and then preserved automatically.

This perspective also reinforces the relationship between the EU AI Act and the broader governance architecture developed in this chapter. Regulatory requirements establish obligations, but those obligations must be translated into organisational responsibilities, technical controls, monitoring processes, evidence and intervention mechanisms. The value of the lifecycle is that it establishes when these mechanisms must operate and when earlier governance decisions must be revisited.

8.20 Lifecycle Governance and ISO/IEC 42001

ISO/IEC 42001 provides a complementary organisational mechanism for embedding lifecycle governance within the management system of the organisation (ISO, 2023). Whereas the AI lifecycle describes what happens to an AI system, an AI management system provides the organisational structure through which the organisation governs those activities.

ISO/IEC 42001 establishes a management-system approach involving planning, risk management, operational control, performance evaluation, internal audit, management review, nonconformity, corrective action and continual improvement. These processes create recurring organisational mechanisms through which AI governance can be evaluated and adjusted rather than leaving governance dependent on individual project teams or one-off compliance exercises.

The relationship can therefore be understood as follows:

The AI lifecycle describes how the system changes over time.

The AI management-system lifecycle describes how the organisation governs those changes.

The two should operate together.

This distinction is important because a technically well-managed AI lifecycle does not necessarily constitute effective organisational governance. Development teams may follow sound engineering practices while the organisation lacks clear decision rights, risk ownership, independent assurance or mechanisms for management review. Conversely, an organisation may possess extensive governance policies without integrating them into the processes through which AI systems are actually developed and operated.

ISO/IEC 42001 provides a mechanism for connecting these two dimensions. Its management-system structure allows AI governance to become part of established organisational processes, including risk management, operational control, performance evaluation, audit and management review (ISO, 2023). Research examining the organisational implications of ISO/IEC 42001 similarly suggests that the standard can provide a systematic basis for embedding AI governance into organisational practice rather than treating it as an isolated technical responsibility (Biroğul, Şahin and Əsgərli, 2025).

The resulting architecture is therefore complementary rather than substitutive. The AI lifecycle provides the sequence of system-related events; the management system provides the organisational mechanisms for governing those events; and the evidence architecture provides the records necessary to demonstrate that governance occurred.

8.21 Governance Gates Across the Lifecycle

One practical way of translating lifecycle governance into operational decision-making is through governance gates. A governance gate is a defined decision point at which the organisation determines whether an AI system may proceed to the next stage of its lifecycle, whether additional controls are required or whether the system should be stopped, reassessed or returned to an earlier stage.

The value of governance gates lies in making decision rights explicit. Rather than assuming that a system will automatically progress from ideation through development to deployment, each significant transition becomes an opportunity to confirm that the conditions for progression have been satisfied.

An initial gate may concern use-case approval. The organisation determines whether the proposed purpose is permissible, sufficiently defined and consistent with organisational objectives and applicable requirements. This is particularly important because inappropriate use cases should ideally be identified before substantial resources are committed to development.

A subsequent risk gate determines whether material risks and impacts have been adequately assessed and whether the proposed controls are proportionate to those risks. The emphasis should be on the quality and completeness of the assessment rather than simply on the existence of a completed risk document.

A development-readiness gate can then establish whether the necessary data, security, architecture and governance controls are sufficiently mature to support development or progression towards validation. This may include confirmation of approved data sources, relevant security controls, ownership, documentation and applicable testing requirements.

A validation gate provides an opportunity to establish whether the system satisfies the defined technical and governance requirements. Validation should consider not only model performance but also relevant dimensions such as robustness, security, data quality, human oversight, documentation and compliance with applicable controls.

A deployment gate represents the formal authorisation to place the system into operational use. It should establish that required assessments have been completed, material risks have been addressed or explicitly accepted by an authorised decision-maker, required controls are operational and the deployment is within the approved purpose and risk parameters.

After deployment, an operational review gate can determine whether the system continues to perform as expected. Monitoring evidence, incidents, user feedback, changes in the operating environment and emerging risks should inform this assessment. The objective is not necessarily to impose a rigid periodic approval cycle on every system, but to ensure that material changes in risk or performance can trigger governance reconsideration.

A change gate is particularly important because AI systems are rarely static. Changes to models, data, purpose, users, suppliers, infrastructure or operating context may alter the system's risk profile. The organisation should therefore determine whether a proposed change is immaterial, requires additional testing, or constitutes a material change requiring renewed assessment or approval.

Finally, a retirement gate confirms that the system can be withdrawn in a controlled manner. This should include consideration of dependencies, data and evidence retention, access revocation, contractual obligations, transition arrangements and residual risk.

The value of these gates is not that every AI system must pass through an identical sequence of formal committees. Such an approach could create unnecessary bureaucracy, particularly for lower-risk systems. Rather, governance gates should be proportionate to the system's potential impact and risk. This is consistent with the broader principle that governance intensity should correspond to potential consequences rather than technological complexity alone.

Governance gates also provide a direct connection between accountability and decision rights. At each significant transition, the organisation can identify who has authority to approve progression, what evidence must be available, what conditions must be satisfied and what happens when those conditions are not met.

This creates a more meaningful governance structure than simply assigning responsibility at the beginning of a project. Responsibility becomes associated with identifiable decisions, evidence and authority at each stage of the lifecycle.

The concept also connects directly with the governance-affordance perspective discussed earlier. Where governance gates are embedded into technical workflows, deployment systems can prevent unauthorised progression rather than merely record that approval was supposed to occur. An unapproved model version, for example, could be technically prevented from deployment; a missing risk assessment could prevent progression into production; and an expired approval could trigger a review requirement. Such mechanisms turn governance requirements into operational constraints rather than relying exclusively on procedural compliance (Enabling affordances for AI governance, 2024).

Governance gates should therefore be understood not simply as meetings or administrative checkpoints, but as decision-control mechanisms. Their purpose is to connect organisational authority, evidence and technical execution so that an AI system progresses through its lifecycle only when the relevant governance conditions have been satisfied.

Taken together, retirement, the EU AI Act's lifecycle requirements, ISO/IEC 42001 and governance gates reinforce the broader proposition developed throughout this chapter: AI governance must accompany the system throughout its lifecycle, with governance decisions recurring whenever the system, its purpose, its environment or its risks materially change. The lifecycle is consequently not merely a sequence of technical development stages. It is the organisational structure through which responsibility, risk, evidence, assurance and intervention are continuously connected.

8.22 Continuous Evidence Production

The lifecycle model extends the principle of auditability by replacing the notion of a single compliance dossier prepared before deployment with continuous evidence production. AI governance literature increasingly emphasises that accountability depends not only on the existence of policies but also on the ability to demonstrate how governance decisions were made and implemented throughout the system lifecycle (Novelli, Taddeo and Floridi, 2024; Batool, Zowghi and Bano, 2025). Evidence should therefore be generated as a natural consequence of lifecycle activity rather than reconstructed retrospectively.

At ideation, this evidence may include the definition of the use case, intended purpose and relevant stakeholders. Classification should establish evidence of regulatory applicability and risk categorisation, while risk assessment should produce documented risk and impact assessments. During design and data preparation, the organisation should retain evidence concerning governance requirements, data provenance, data quality and relevant security considerations. Development should generate records of model versions, experiments and development decisions, while validation should produce testing and assurance results.

The same principle should continue through deployment and operation. Approval should generate an authorisation decision; deployment should create a deployment record; and monitoring should produce performance, risk and compliance information. Incidents should result in incident and corrective-action records, while material changes should generate change assessments and, where appropriate, renewed validation or approval. Retirement should be accompanied by appropriate records concerning decommissioning, retention and disposal.

Together, these records form a lifecycle evidence chain through which an organisation can reconstruct not only what an AI system did, but also what governance decisions shaped its development and operation. This approach is particularly important for accountability because it connects evidence to decision-making authority rather than treating documentation as an independent compliance artefact (Novelli, Taddeo and Floridi, 2024). It also supports the EU AI Act's lifecycle-oriented approach to risk management, under which relevant risks must be addressed on an ongoing basis rather than solely at the point of initial conformity or deployment (European Parliament and Council of the European Union, 2024).

8.23 Governance by Design

The lifecycle perspective supports a broader proposition that governance should be designed into AI systems rather than merely documented around them. This parallels established concepts such as security-by-design and privacy-by-design and reflects the emerging literature on AI governance affordances, which examines how technical and organisational environments can be structured to enable or constrain governance behaviour (Enabling affordances for AI governance, 2024).

Governance requirements can therefore be incorporated directly into system architecture and operational processes through mechanisms such as embedded logging, approval workflows, automated access controls, policy-enforcement mechanisms, model versioning, automated testing, threshold-based alerts, human-override interfaces, rollback capabilities and automated evidence capture. These mechanisms create what can be described as governance affordances: features that make appropriate governance behaviour easier, more reliable or, where appropriate, mandatory.

This is significant because it moves governance from the level of formal policy towards the level of operational control. An organisation may formally require that only approved model versions are deployed, for example, but a stronger governance arrangement can technically prevent deployment of an unapproved version. Similarly, a requirement for human oversight becomes more meaningful when the system provides the information, interface and authority necessary for an individual to intervene effectively. Governance by design therefore reduces the risk that governance requirements become detached from actual system behaviour (Camilleri, 2024; Enabling affordances for AI governance, 2024).

8.24 DevSecOps and the Emergence of Governance Operations

The lifecycle perspective also has implications for software engineering practice. DevSecOps demonstrates how security controls can be integrated into development and deployment pipelines rather than being treated as a separate stage performed after development. A comparable principle can be applied to AI governance by incorporating governance controls into development and operational processes.

Development and deployment pipelines can incorporate automated checks for required documentation, risk classification, approved model versions, data-source approval, security testing, performance thresholds, bias testing where appropriate, human-oversight mechanisms, approval status and deployment authorisation. Governance requirements can thereby become part of the same technical workflows through which AI systems are developed, tested and deployed.

The terminology used for this approach is less important than the underlying architectural principle: governance controls should increasingly become part of the technical delivery pipeline. This represents a practical extension of the management-system orientation associated with ISO/IEC 42001, which treats AI governance as an organisational management system involving planning, operational controls, performance evaluation and continual improvement rather than as a one-time compliance exercise (ISO/IEC, 2023; Biroğul, Şahin and Əsgərli, 2025).

8.25 The Limits of Automation

Lifecycle governance should not, however, be interpreted as implying that every governance activity can or should be automated. AI governance necessarily involves questions of judgement, accountability and institutional responsibility. These include whether a particular use case is ethically appropriate, whether residual risk is acceptable, whether deployment is justified despite uncertainty, whether an impact is proportionate, whether a system should be suspended, and whether a change materially alters the system's purpose or risk profile.

Such questions cannot always be reduced to technical rules or predefined thresholds. Research on AI governance and accountability emphasises the importance of maintaining clear human responsibility for consequential decisions, particularly where technical systems distribute control among developers, users, managers and other organisational actors (Grote, Parker and Crowston, 2024; Novelli, Taddeo and Floridi, 2024).

Automation can nevertheless provide substantial support. It can collect evidence, monitor performance, detect thresholds, enforce workflows, maintain documentation, generate alerts and test controls. The appropriate division is therefore not between automated and human governance, but between automated control and human judgement. Human governance remains necessary for accountability, interpretation and exceptional decisions. Meaningful human oversight consequently requires more than human presence: it requires people with appropriate authority, competence, information and practical means to intervene.

8.26 Lifecycle Governance and Accountability

The lifecycle model also clarifies how accountability can be distributed across an AI system's development and operation. Accountability should correspond to decision rights and control, rather than being assigned simply because an individual or team was technically involved in creating the system. This is consistent with the literature's distinction between accountability as a formal organisational concept and the practical mechanisms through which responsibility is exercised (Novelli, Taddeo and Floridi, 2024).

Different actors may therefore hold primary responsibility at different stages. The business owner may be accountable for the purpose and intended outcomes of a system. AI governance or compliance functions may lead regulatory classification, while risk and the business owner jointly address risk assessment. Architecture and AI teams may lead design and development, with data governance responsible for data-related decisions. Validation may require independent technical assurance, while deployment approval may rest with an authorised governance body.

Once a system is operational, the business owner and operations may assume primary responsibility for its use, while AI, risk, security and governance functions contribute to monitoring. Operations and risk may lead incident response, while material changes may require both the change owner and governance functions to reassess the system. Retirement may involve the business owner together with IT and data governance, while internal audit retains a distinct role in providing independent assurance across the lifecycle.

This demonstrates why AI accountability cannot be reduced to the developer. A developer may control model construction, while the business owner controls purpose and intended outcomes; the risk function may control the risk methodology; executives may determine whether residual risk is accepted; operations may control deployment; and internal audit may provide independent assurance. The lifecycle therefore provides a mechanism for distributing accountability according to decision rights (Grote, Parker and Crowston, 2024).

A formal responsibility-assignment mechanism can make these relationships explicit. Its precise terminology or format should, however, reflect the organisation's structure and risk profile. What matters is that, at each significant lifecycle stage, the organisation can identify who is accountable, who is responsible for execution, who must be consulted and who must be informed.

8.27 Continuous Compliance and Organisational Learning

Lifecycle governance also transforms compliance from a static obligation into a mechanism for organisational learning. ISO/IEC 42001 is particularly relevant to this perspective because it frames AI governance through an iterative management-system structure involving performance evaluation, corrective action and continual improvement (ISO/IEC, 2023). The objective is therefore not simply to demonstrate that controls exist, but to establish whether those controls remain appropriate and effective.

Each stage of the lifecycle generates information that can inform subsequent governance decisions. Deployment generates operational data; monitoring generates performance information; incidents reveal weaknesses or unexpected behaviour; audits generate assurance findings; changes generate new risk assessments; and management reviews generate decisions about controls and organisational practice. These inputs should feed back into the governance system rather than being treated as isolated records.

This creates a continual improvement cycle in which organisational experience produces evidence, evidence informs assessment, assessment informs decisions, decisions lead to changes in controls, and those controls generate new operational experience. The organisation therefore moves beyond asking “Did we comply?” towards asking “What have we learned about whether our governance mechanisms actually work?” This represents a more mature conception of AI governance because governance is evaluated not only by its formal existence but also by its capacity to learn and improve (Batool, Zowghi and Bano, 2025; Biroğul, Şahin and Əsgərli, 2025).

8.28 Lifecycle Governance as a Control Architecture

The lifecycle can consequently be understood as an integrated control architecture rather than a sequence of disconnected compliance activities. An AI use case begins with ideation and classification, followed by risk and impact assessment and the design of appropriate governance arrangements. Data, model and security controls are then established before validation and approval. Following deployment, the system is continuously monitored, with incidents, drift and material changes triggering reassessment and, where necessary, renewed approval or corrective action. The lifecycle ultimately concludes with retirement and appropriate record retention.

The crucial characteristic is the feedback loop. Governance does not terminate at deployment. Operational experience, monitoring results, incidents and changes can all trigger reassessment and further governance decisions. This reflects the EU AI Act's emphasis on continuous and iterative risk management for high-risk AI systems and complements ISO/IEC 42001's management-system approach to ongoing evaluation and improvement (European Parliament and Council of the European Union, 2024; ISO/IEC, 2023).

The lifecycle therefore functions simultaneously as a sequence of activities and as a control mechanism. Earlier governance decisions establish conditions for subsequent stages, while information generated during later stages can require earlier decisions to be revisited.

8.29 The Lifecycle as a Regulatory Control Loop

The broader proposition is that AI compliance is best understood as a regulatory control loop operating across the AI lifecycle. External regulatory requirements and organisational risk appetite establish expectations that are translated into classifications, policies and controls. Those controls are implemented technically and organisationally, generating evidence that can be monitored and independently assured. Where weaknesses, incidents or changes are identified, corrective action follows and the system and its governance arrangements are reassessed.

This approach brings together the principal concepts developed throughout the paper. The EU AI Act provides an important source of external legal requirements, including its lifecycle-oriented risk-management obligations for high-risk systems (European Parliament and Council of the European Union, 2024). ISO/IEC 42001 provides a management-system structure through which organisations can institutionalise these governance activities (ISO/IEC, 2023). Governance arrangements allocate decision rights; controls operationalise requirements; lifecycle processes establish when controls apply; evidence creates auditability; monitoring creates observability; intervention creates controllability; assurance tests effectiveness; and management review supports continual improvement.

The resulting model is therefore neither purely regulatory nor purely technical. It is an organisational control loop in which legal requirements, management systems, technical architecture and operational practice continuously interact.

8.30 Implications for Organisational Design

The lifecycle perspective has important implications for organisational design. Governance functions should not merely exist as static departments; they should have defined touchpoints across the AI lifecycle. Legal and compliance functions should contribute to classification and regulatory interpretation. Risk should participate in initial assessment and reassessment. Data governance should operate during data acquisition, preparation and subsequent changes. Security should remain involved throughout development, deployment and monitoring. AI governance should coordinate lifecycle decisions, while business owners should remain accountable for purpose and operational outcomes. Internal audit should provide independent assurance across the lifecycle.

This arrangement reflects a broader finding in AI governance research: effective governance depends on coordination across organisational functions rather than on the creation of isolated governance structures (Batool, Zowghi and Bano, 2025; Rêgo de Almeida and dos Santos Júnior, 2025).

The lifecycle consequently becomes the mechanism through which organisational functions interact. Instead of treating legal, risk, security, data, technology and assurance functions as separate silos, it connects their responsibilities to the decisions and controls that arise as an AI system progresses from conception through operation and retirement.

8.31 Implications for Technology Architecture

Lifecycle governance also has direct consequences for technical architecture. An auditable and controllable AI environment should provide capabilities such as model registries, data lineage, version control, experiment tracking, deployment approvals, access controls, logging, monitoring, alerting, incident management, configuration management, rollback, retention and evidence repositories.

These should not be viewed as unrelated technical tools. Collectively, they form part of a broader AI control plane that connects governance decisions with technical execution. Such integration is consistent with the governance-by-design principle because it enables organisational requirements to influence the technical conditions under which AI systems can operate (Enabling affordances for AI governance, 2024).

An approved model version, for example, can determine what may be deployed; a risk classification can determine which controls must be enabled; and the classification of a material change can determine whether additional validation or approval is required. The resulting architecture establishes a direct relationship between organisational decision-making and technical enforcement, reducing the possibility that governance decisions remain disconnected from system configuration and operational behaviour.

8.32 The AI Control Plane

The concept of an AI control plane provides a further synthesis of this approach. Such a capability could maintain information concerning system identity, ownership, regulatory classification, risk status, approved versions, applicable controls, monitoring thresholds, approval status, evidence, incidents, exceptions and reassessment dates.

The control plane would provide a common interface connecting governance, risk, compliance, technology, operations and assurance. Its purpose would not necessarily be to centralise every governance activity in one system, but to establish a reliable relationship between governance decisions and the technical and operational state of AI systems.

This concept translates the otherwise abstract idea of AI governance into an implementable organisational and technical architecture. It also supports the broader argument that effective governance requires alignment between accountability structures, organisational controls and technical mechanisms (Grote, Parker and Crowston, 2024; Enabling affordances for AI governance, 2024).

8.33 Lifecycle Governance and Evidence Architecture

The relationship between lifecycle governance and auditability can be expressed through the principle of evidence continuity. The objective is not simply to retain evidence somewhere within the organisation, but to ensure that evidence remains connected to the decisions and actions that produced it.

For example, a decision to deploy a particular model version should be connected to the model version itself, the approval control governing deployment, the resulting authorisation record, the deployment log and subsequent post-deployment monitoring. Evidence is therefore connected to decisions rather than merely accumulated as a collection of documents.

This traceability strengthens both internal accountability and external assurance. During audits, investigations or regulatory enquiries, the organisation can demonstrate not only what occurred but also why it occurred, which controls applied and under whose authority the decision was made. Such traceability gives practical effect to the concept of accountability by linking responsibility to observable organisational decisions and actions (Novelli, Taddeo and Floridi, 2024).

8.34 Lifecycle Governance and Proportionality

Lifecycle governance should also be proportionate to risk. AI governance should not impose the same level of scrutiny on every system merely because each system uses artificial intelligence. The appropriate governance intensity depends primarily on the potential consequences of the system's use, including its impact on individuals, organisations and society.

Lower-impact systems may require relatively lightweight classification, documentation and monitoring. Systems presenting material organisational risk may require formal risk assessment, named ownership and structured monitoring. High-impact or regulated systems may require formal assessment, validation, governance approval, enhanced monitoring and assurance. Systems with critical or highly consequential impacts may warrant enhanced independent assurance, continuous monitoring, formal intervention thresholds and executive oversight.

This risk-based approach is consistent with the EU AI Act's differentiated regulatory treatment of AI systems and with the broader governance literature's emphasis on contextual and proportionate approaches to AI risk (European Parliament and Council of the European Union, 2024; Carey, 2025; Buscemi et al., 2025).

The underlying principle is that governance intensity should be proportional to potential impact, not simply to technological complexity. A technically sophisticated system used for a low-consequence internal task may warrant less governance than a comparatively simple system that materially influences employment, healthcare, education, credit or access to essential services. Proportionality therefore allows organisations to avoid unnecessary bureaucracy while directing scrutiny towards systems where governance failure could produce the greatest consequences.

8.35 Conclusion

AI compliance should not be conceptualised as an assessment performed immediately before deployment. It is better understood as a continuous lifecycle process through which the organisation repeatedly establishes whether an AI system remains appropriately classified, controlled, authorised and monitored. The EU AI Act provides an important legal foundation for this perspective, particularly through its requirements concerning continuous and iterative risk management for relevant high-risk AI systems (European Parliament and Council of the European Union, 2024). ISO/IEC 42001 complements this framework by providing a management-system architecture through which organisations can institutionalise lifecycle governance through planning, risk management, operational controls, performance evaluation, audit, management review, corrective action and continual improvement (ISO/IEC, 2023).

The practical implication is that governance should operate across the complete lifecycle, from ideation and classification through risk assessment, design, data management, development, validation, approval, deployment, monitoring, incident response, change, reassessment and retirement. At each stage, the organisation should be able to identify who holds decision rights, what controls apply, what evidence is generated, how performance is monitored, what intervention is possible and when governance decisions must be revisited.

This lifecycle approach synthesises several complementary strands of the AI governance literature. Governance establishes the organisational structures through which AI-related decisions are made (Batool, Zowghi and Bano, 2025). Accountability requires those decisions to be attributable to identifiable actors and supported by mechanisms of control and assurance (Novelli, Taddeo and Floridi, 2024). Governance affordances show how desired behaviour can be embedded into organisational and technical environments (Enabling affordances for AI governance, 2024). ISO/IEC 42001 provides a management-system mechanism for institutionalising these practices, while the EU AI Act establishes legally binding requirements for relevant categories of AI systems (ISO/IEC, 2023; European Parliament and Council of the European Union, 2024).

This leads to the chapter's central proposition: AI compliance should be treated as a continuous organisational control loop embedded within the AI lifecycle, rather than as a static compliance artefact produced at the point of deployment. Organisations should therefore avoid designing AI systems first and attempting to add compliance afterwards. Regulatory classification, risk management, human oversight, auditability, technical controls, evidence generation and intervention mechanisms should instead form part of the system-development and operational lifecycle itself.

The ultimate objective is not simply to produce compliant AI documentation. It is to create an organisational and technical environment in which compliance, auditability and controllability are continuously produced by the way AI is designed, approved, deployed, operated, monitored and changed. In this sense, mature AI governance is not an additional layer placed around the AI lifecycle; it becomes an integral part of the lifecycle's control architecture.

9. The Importance of Evidence

The preceding analysis leads to a central practical proposition: AI governance becomes meaningful when principles and policies are translated into demonstrable evidence. An organisation may possess sophisticated responsible AI principles, comprehensive policies and clearly assigned governance responsibilities, yet these instruments provide limited assurance if the organisation cannot demonstrate how they operate in practice. Governance therefore depends not only on what an organisation says it requires, but on whether it can demonstrate that those requirements have been translated into decisions, controls, actions and outcomes.

This distinction can be expressed as one between declared governance and demonstrable governance. A policy may state that human oversight of AI systems must be effective. Evidence-based governance requires the organisation to demonstrate who provides that oversight, what authority that person possesses, what information they receive, whether they are competent to perform the role, what decisions they can challenge or override, whether they can intervene or suspend the system, and whether their interventions are recorded and reviewed. The governance question therefore moves from whether a principle exists to whether its implementation can be demonstrated and evaluated.

This is closely connected to the conception of accountability developed by Novelli, Taddeo and Floridi (2024). Accountability requires more than assigning responsibility. It requires structures through which decisions can be questioned against relevant standards and through which responsibility can lead to review and, where appropriate, consequences. Evidence provides the factual basis for that process.

Evidence should therefore not be understood merely as a by-product of governance or as material produced primarily for auditors. It is one of the principal outputs of a functioning governance system. It provides the basis on which management, assurance functions, regulators and other legitimate stakeholders can determine whether governance requirements have actually been implemented and whether they remain effective.

9.1 From Principles to Demonstrable Controls

Responsible AI frameworks commonly articulate principles concerning fairness, transparency, accountability, human oversight, safety, security, privacy and explainability. The difficulty is that such principles are generally expressed at a high level of abstraction. A statement that AI should be transparent does not, by itself, constitute an operational control. Similarly, a requirement that AI risks should be managed does not establish who performs the assessment, what methodology is used, when reassessment occurs or what evidence demonstrates completion.

AI governance therefore requires a process through which abstract principles are translated into operational requirements and observable activity. A principle concerning human oversight might lead to a requirement that appropriately authorised personnel must be capable of supervising the system effectively. That requirement may then be implemented through controls assigning trained individuals to defined oversight roles, providing them with appropriate information and authority, and establishing mechanisms through which they can intervene. Evidence could include role assignments, competence records, oversight activity, intervention records and management reviews. Assurance can subsequently test whether these arrangements operate as intended.

This translation from principle to control and from control to evidence is fundamental to an auditable governance architecture. It also reflects the broader governance literature's emphasis on moving beyond high-level ethical commitments towards organisational mechanisms capable of shaping actual AI development and use (Batool, Zowghi and Bano, 2025; Camilleri, 2024).

9.2 Evidence as the Link Between Policy and Assurance

The existence of a policy does not demonstrate that a control operates, and the existence of a control does not demonstrate that it is effective. These distinctions are essential because organisations can accumulate substantial governance documentation while remaining unable to demonstrate effective operational control.

Consider a requirement that all high-risk AI systems receive governance approval before deployment. The policy establishes the expectation, but further questions immediately arise. What mechanism prevents deployment without approval? Was that mechanism actually used? Where is the evidence of authorisation? Has anyone independently tested whether the mechanism can be bypassed?

These questions distinguish documentary compliance from operational governance. The first establishes what the organisation says should happen. The second establishes what actually happened and whether the mechanisms intended to make it happen were effective.

This distinction is consistent with the management-system approach of ISO/IEC 42001, which places emphasis not merely on establishing policies and processes but on implementing, evaluating and continually improving the AI management system (ISO, 2023). Evidence is therefore the link that connects governance intent with operatioA further variable that can be used to differentiate automated and AI-enabled systems is their degree of effective autonomy. Autonomy is important from a governance perspective because the significance of a system is determined not only by the technology it uses, but also by the extent to which it can influence or determine outcomes without direct human intervention.

At the lowest level, a system may operate primarily as an information tool, providing data or analysis to human users while leaving the substantive decision entirely to the individual. In such circumstances, governance is principally concerned with information accuracy, data quality and appropriate use.

A greater degree of autonomy exists where the system provides recommendations that materially influence human decisions. The human decision-maker remains formally responsible for the final outcome, but governance must increasingly address the reliability of recommendations, the basis on which they are generated and the potential for users to become overly dependent on automated outputs.

At a further level, systems may perform conditional automation, in which the system is authorised to act automatically in defined circumstances but requires human intervention for specified cases, exceptions or decisions. Governance at this level requires clearly defined intervention thresholds, escalation procedures and decision rights.

Higher levels of autonomy arise where a system can perform actions with limited human intervention. In such circumstances, governance must place greater emphasis on the boundaries of the system's authority, monitoring, exception handling, intervention mechanisms and the ability to suspend or reverse automated actions.

At the highest level, a system may be capable of autonomous action, meaning that it can initiate or complete consequential activities without case-by-case human approval. Such systems require particularly strong governance over delegated authority, monitoring, human intervention, accountability and the conditions under which automated activity may be suspended or terminated.

These levels should be understood as illustrative governance categories rather than regulatory classifications. They are intended to demonstrate a relationship between autonomy and governance intensity rather than establish a formal classification system. The appropriate level of control will also depend on the consequences of the system's actions, the sensitivity of the data involved, the reversibility of decisions, the number of people affected and the applicable regulatory requirements.

The central governance principle is therefore:

The greater the system's effective decision-making authority, the greater the need for explicit controls over that authority.

This principle connects directly with the relationship between control and accountability identified by Grote, Parker and Crowston (2024). As technological systems exercise greater autonomy, responsibility cannot simply be assigned to a human or organisational actor who lacks the practical ability to influence the relevant outcome. Accountability must therefore remain connected to meaningful authority, information, resources and intervention capability.

This also has implications for human oversight. The existence of a human somewhere within the process does not necessarily establish meaningful human control. Where a system can act autonomously, governance should establish who is authorised to intervene, when intervention is required, what information must be available to the decision-maker, and whether the intervention can actually change or stop the system's behaviour. This is consistent with the broader approach to human oversight under the EU AI Act, which treats human oversight as an operational governance requirement rather than simply the presence of a human in the process (European Parliament and Council of the European Union, 2024).

Autonomy should consequently be treated as a governance variable that influences the level and nature of controls applied to an AI or automated system. The higher the effective autonomy and the greater the potential consequences of automated action, the stronger the organisation's requirements should generally be for authority management, monitoring, intervention, evidence and independent assurance.nal reality.

9.3 Evidence and Accountability

The relationship between evidence and accountability is particularly important. Novelli, Taddeo and Floridi (2024) conceptualise accountability in terms of answerability: actors must be situated within institutional arrangements through which their actions and decisions can be evaluated against applicable standards. This means that accountability cannot be reduced to assigning an individual as the owner of an AI system.

A statement such as "the Chief Data Officer is accountable for AI governance" is incomplete unless the organisation can establish what decisions fall within that person's accountability, what authority they possess, what information they receive, which standards apply, where they report, what evidence supports their decisions and what happens when governance requirements are not met.

Accountability therefore requires an institutional pathway through which responsibility becomes observable and contestable. Evidence makes that pathway visible. It connects responsibility to decisions, decisions to controls, controls to operational activity and operational activity to outcomes.

This also supports the argument developed by Grote, Parker and Crowston (2024) that AI accountability depends on the alignment of control and responsibility among the different actors involved in developing and using AI. Accountability is strongest when responsibility corresponds to actual decision rights and when those decisions can subsequently be examined.

9.4 The Audit Trail of Accountability

A mature AI governance system should therefore create an audit trail of accountability. This is broader than a technical audit log. A technical log may show that a particular model version generated an output at a particular time. An accountability trail should additionally allow the organisation to establish who authorised that model version, for what purpose it was approved, what risk assessment supported its use, which controls applied, who was responsible for monitoring it, what evidence demonstrated that monitoring occurred, whether incidents were identified and who authorised subsequent changes.

The distinction is between system traceability and decision traceability.

System traceability explains what the technology did. Decision traceability explains the organisational circumstances within which it was permitted to do it. Both are necessary for meaningful governance.

This distinction is particularly important because governance failures often arise from organisational decisions rather than from isolated technical events. A model may behave exactly as designed, yet the organisation may nevertheless have failed because the system was deployed for an inappropriate purpose, an identified risk was improperly accepted, or an intervention mechanism was insufficient. Evidence must therefore capture the decisions surrounding AI, not merely the technical events produced by it.

9.5 Categories of Governance Evidence

AI governance evidence can usefully be understood in four broad categories: decision evidence, control evidence, performance evidence and assurance evidence.

Decision evidence demonstrates what the organisation decided and who exercised the relevant authority. It includes use-case approvals, risk-acceptance decisions, governance committee decisions, deployment authorisations, exceptions, escalation decisions, change approvals and retirement decisions. Such evidence demonstrates the exercise of organisational authority.

Control evidence demonstrates what mechanisms were established and whether they operated. It can include access-control records, approval workflows, segregation-of-duties arrangements, human-oversight assignments, policy-enforcement mechanisms, deployment gates, monitoring thresholds and change-management records. Control evidence connects governance requirements to operational mechanisms.

Performance evidence demonstrates what occurred in practice. This may include accuracy, robustness, error rates, drift, security events, incidents, override rates, false-positive and false-negative rates, monitoring results and user feedback. Performance evidence is particularly important because a control can exist and operate while nevertheless failing to achieve its intended objective.

Assurance evidence demonstrates that governance itself has been evaluated. Internal-audit reports, control-testing results, independent validation, compliance assessments, management reviews and corrective-action verification can establish whether governance mechanisms are operating effectively. This introduces a second-order governance question: how does the organisation know that its governance system works?

9.6 Evidence Is Not the Same as Documentation

A critical distinction must be maintained between documentation and evidence.

Documentation describes what should happen. Evidence demonstrates what did happen.

A policy requiring risk assessment before deployment establishes an organisational expectation. A risk-assessment methodology establishes how that assessment is intended to be performed. A completed risk assessment demonstrates that an assessment was undertaken for a particular system. An approval record demonstrates that the resulting risk was considered by an authorised decision-maker. Subsequent monitoring evidence can demonstrate whether the assumptions made during the original assessment remained valid during operation.

The distinction is important because a document can exist without the underlying activity having occurred. Conversely, an operational activity may have occurred without being adequately evidenced. Effective governance requires both implementation and the ability to demonstrate implementation.

This is consistent with the management-system logic of ISO/IEC 42001, in which documented information, operational controls, performance evaluation, internal audit, management review and corrective action form interconnected elements of an organisational system (ISO, 2023).

9.7 Linking Evidence to Requirements

Evidence becomes substantially more valuable when it is explicitly connected to the requirement it demonstrates. A repository containing hundreds of governance documents may provide little assurance if the organisation cannot establish which requirement each record supports, which control produced it, who owns the control and whether the control has been tested.

A stronger architecture establishes a traceable relationship between the requirement, the control, its owner, the evidence generated by its operation and the assurance activity used to evaluate it.

For example, a requirement for effective human oversight should lead to identifiable controls concerning the appointment and competence of overseers, their authority to intervene, the availability of appropriate information and the operation of escalation mechanisms. The resulting evidence might include role records, training records, system configurations, intervention logs and review reports. Assurance can then examine whether those mechanisms operate in practice.

This converts compliance from a collection of documents into a traceable control system.

The same principle applies across AI governance. Risk requirements should be linked to risk assessments and treatment decisions; data requirements to provenance and quality evidence; security requirements to security controls and testing; monitoring requirements to operational metrics and alerts; and change requirements to change assessments and approval records.

9.8 Regulatory Traceability

The principle can also be applied directly to regulatory requirements. Rather than maintaining a general statement that an organisation complies with the EU AI Act, the organisation should establish traceability between applicable regulatory obligations and its internal governance arrangements.

A regulatory requirement should be capable of being connected to the relevant internal policy, control objective, operational control, responsible owner, evidence and assurance procedure. This creates a regulatory traceability structure through which legal obligations can be translated into operational requirements.

Such traceability becomes particularly valuable in a changing regulatory environment. When regulatory requirements change, the organisation can identify which controls, systems, owners and evidence repositories are affected rather than attempting to reassess the entire governance environment from the beginning.

The approach therefore supports both compliance and change management. It allows legal developments to be translated into specific operational consequences and provides a basis for demonstrating how the organisation responded.

9.9 Evidence and the EU AI Act

The EU AI Act makes evidence particularly significant because a number of its obligations are explicitly concerned with documentation, record-keeping, monitoring and demonstrability. For relevant high-risk AI systems, the Act establishes requirements concerning risk management, data governance, technical documentation, record-keeping, transparency, human oversight, quality management and post-market monitoring (European Parliament and Council of the European Union, 2024).

The Act's requirements concerning automatic recording of events and the retention of generated logs illustrate the importance of evidence as an inherent feature of system design. Requirements concerning technical documentation similarly demonstrate that compliance cannot depend exclusively on statements made after deployment; relevant information must be established and maintained as part of the system's lifecycle.

The broader implication is significant. Regulation increasingly requires organisations not only to behave appropriately but also to be capable of demonstrating that they have established and operated the required controls. Compliance therefore becomes partly an evidence-management problem.

This expands the role of compliance and governance functions. Their responsibility is not limited to interpreting regulatory requirements. They must also ensure that those requirements can be translated into controls and that the operation of those controls generates sufficiently reliable evidence.

9.10 Evidence and ISO/IEC 42001

ISO/IEC 42001 reinforces this orientation through its management-system logic. The standard provides a framework through which organisations can establish objectives, identify AI-related risks and opportunities, implement controls, evaluate performance, conduct internal audits, undertake management review and pursue continual improvement (ISO, 2023).

The significance for evidence is that these activities are interconnected. Evidence should not sit outside the management system as material collected only when an audit is approaching. It should be generated through the normal operation of the management system itself.

This also supports the findings of research examining the organisational implications of ISO/IEC 42001. Biroğul, Şahin and Əsgərli (2025) highlight the standard's potential to influence organisational practices by providing a systematic framework for AI governance rather than treating AI responsibility as an isolated technical concern.

Evidence is therefore not an additional administrative layer placed on top of ISO/IEC 42001. It is a means through which the organisation demonstrates that its management system is operating.

9.11 Evidence as a Control Objective

The analysis supports a stronger proposition: evidence production should itself be treated as a governance control objective.

Organisations should ask, at the design stage of each important governance process, what evidence would be required if the organisation were later asked to demonstrate that the process had operated correctly.

This question changes system and process design. Rather than merely requiring human oversight, for example, an organisation can design its systems to record the identity of the overseer, the relevant output, the time of review, the decision taken, any override, the reason for intervention and subsequent escalation.

The resulting governance mechanism does not merely perform the control. It also produces evidence of the control's operation.

This is particularly valuable because retrospective evidence reconstruction is costly, unreliable and vulnerable to gaps. Evidence generated contemporaneously as part of normal system operation is generally more useful than evidence reconstructed after an incident or regulatory enquiry.

9.12 Evidence by Design

The concept can therefore be extended into evidence by design. Evidence by design means deliberately engineering organisational processes and technical systems so that reliable governance evidence is generated as part of normal operation.

Deployment pipelines can automatically record model version, approval status, deployment date, environment and responsible actors. Model registries can maintain information concerning identity, purpose, ownership, version, validation status and risk classification. Data platforms can record provenance, lineage, transformations, access and retention. Monitoring platforms can capture performance, thresholds, alerts, incidents and remediation. Governance workflows can retain approvals, exceptions, decisions, escalations and reassessments.

The underlying principle is straightforward: the most reliable evidence is often evidence generated automatically by the process being governed.

This connects directly to the concept of governance affordances discussed in the preceding chapter. If a technical architecture makes appropriate governance behaviour easier to perform and simultaneously records that behaviour, governance becomes less dependent on administrative discipline and more deeply embedded in system operation (Enabling affordances for AI governance, 2024).

9.13 Evidence Quality Matters

The quantity of evidence is not, however, sufficient. A mature evidence architecture must also consider evidence quality.

At minimum, evidence should be assessed in terms of authenticity, integrity, completeness, traceability and timeliness. The organisation should be able to establish that records are genuine, have not been improperly altered, capture the relevant activity, can be connected to the relevant system and decision, and were generated sufficiently close to the event they purport to demonstrate.

These requirements become more difficult as AI environments become distributed across model registries, cloud platforms, software repositories, data platforms, ticketing systems, monitoring tools, identity systems, governance repositories and third-party platforms.

The governance challenge is therefore not simply to collect evidence. It is to maintain the integrity and relationships of evidence across a distributed technical and organisational environment.

9.14 The Evidence Chain

The concept of an evidence chain provides a useful way to understand this relationship. A governance requirement gives rise to a risk consideration, which informs a control. That control has an owner and generates operational activity. The activity produces evidence, which can be tested. Testing may identify a finding, which leads to corrective action and potentially a reassessment of the original risk or control.

Consider a requirement for effective human oversight. The organisation may identify the risk that automated outputs could lead to inappropriate decisions. It may respond by requiring a trained and authorised reviewer to approve specified outputs. The review activity generates evidence through approval records and timestamps. Assurance can sample those records and identify, for example, that a proportion of decisions lacked documented review. The organisation can then modify the workflow so that a decision cannot proceed without the required review.

The resulting chain is substantially more informative than the statement that human oversight exists. It demonstrates how a governance requirement was translated into risk treatment, control design, operational activity, evidence, assurance and corrective action.

9.15 Evidence and Exceptions

Evidence is particularly important where organisations depart from standard governance processes. A mature governance system should maintain a clear record of exceptions, including the relevant requirement, reason for departure, associated risk, approving authority, compensating controls, expiry or review date and remediation plan.

This prevents temporary deviations from becoming permanent undocumented practices.

An exception should therefore be understood as a governance decision, rather than as an informal failure to follow a process. It should have an identifiable owner, an explicit rationale and a defined review point. Evidence of the exception then provides a basis for subsequent challenge and reassessment.

This is consistent with the broader accountability principle that significant departures from established standards should remain attributable to identifiable decision-makers and subject to review (Novelli, Taddeo and Floridi, 2024).

9.16 Evidence and Accountability at the Individual Level

The evidence architecture also has implications for individual accountability. Assigning a person as an AI owner is insufficient if there is no evidence that the individual exercised the responsibilities assigned to them.

A mature governance system should therefore distinguish between accountability assignment and accountability exercise.

The first establishes who holds responsibility. The second demonstrates how that responsibility was exercised. A business owner may be assigned responsibility for continued operation of an AI system, but evidence of quarterly review, decisions concerning continued operation, responses to monitoring results and approval of corrective action demonstrates that the assigned accountability was actually exercised.

This distinction is important because accountability without evidence can become nominal. Conversely, evidence without clear ownership can become organisationally ambiguous. Effective governance therefore requires both identifiable decision rights and a reliable record of how those rights were exercised.

9.17 Evidence and Organisational Memory

Evidence performs an important function beyond compliance and audit: it creates institutional memory.

AI systems may outlive their developers, business owners, suppliers, technology platforms and even the regulatory assumptions under which they were originally deployed. Without reliable evidence, organisations can lose the ability to answer basic questions about why a system was introduced, who approved it, what data was used, what risks were identified, why particular controls were selected, why exceptions were granted or when the system materially changed.

Evidence therefore provides continuity across organisational change.

This is particularly important for AI because the lifecycle of a system may extend across multiple generations of models, vendors, infrastructure and organisational ownership. A robust evidence architecture allows the organisation to reconstruct the history of the system even when the people and technologies originally involved are no longer present.

Evidence is consequently not simply an auditor's resource. It is a form of organisational memory and institutional control.

9.18 Evidence and Explainability

The evidence perspective also helps distinguish technical explainability from governance explainability.

Technical explainability concerns questions such as why a model generated a particular output. Governance explainability concerns a different set of questions: why the organisation deployed the system, why a particular risk was accepted, who authorised its use, why specific controls were considered sufficient, and why an intervention did or did not occur.

An organisation may therefore possess a technically explainable model while remaining unable to explain the organisational decisions surrounding its deployment.

Effective AI governance consequently requires both model-level explanation and decision-level explanation. The latter depends substantially on evidence concerning governance decisions, risk assessments, approvals, exceptions, monitoring and intervention.

This expands the conventional understanding of explainability. The relevant question is not only whether the model can be explained, but whether the organisation can explain the circumstances under which the model was authorised and governed.

9.19 Evidence and Independent Assurance

Evidence becomes particularly valuable when evaluated independently. Internal audit or another appropriately independent assurance function can examine whether required assessments were performed, approvals were properly authorised, controls operated, evidence is complete, monitoring thresholds remain appropriate, exceptions were adequately governed and corrective actions were completed.

This supports a distinction between operational control, oversight and independent assurance. Those responsible for developing or operating an AI system should not necessarily be the sole arbiters of whether its governance is effective.

The three-lines model is therefore relevant to AI governance. Operational functions establish and operate controls; second-line functions provide oversight, challenge and risk management; and internal audit provides independent assurance. The precise organisational arrangement will vary, but the underlying principle is that effective assurance requires an appropriate degree of independence from the activity being assessed.

9.20 Evidence and Control Effectiveness

Evidence must also distinguish control existence from control effectiveness.

The existence of a human override function demonstrates that an intervention mechanism has been implemented. It does not demonstrate that authorised personnel can access it, understand when it should be used, exercise it successfully or cause the intended system response.

Evidence of effectiveness therefore requires more than configuration records. It may require testing that the mechanism operates under realistic conditions, that personnel can use it, that interventions are recorded and that the resulting action is appropriate.

This distinction is fundamental to assurance. A mature assessment does not stop at asking whether a control exists. It asks whether the control operates as intended and whether it achieves its control objective.

This principle is particularly important for AI because technical and organisational controls can fail in ways that are not immediately apparent from their configuration. Monitoring may operate while using inappropriate thresholds; human oversight may exist while being practically ineffective; and risk assessments may be completed while becoming obsolete as system behaviour or operating context changes.

9.21 From Evidence to Metrics

Once evidence is systematically structured, it can also support governance metrics. Management can measure the proportion of AI systems with assigned owners, completed classifications, current risk assessments, approved deployments and active monitoring. Organisations can assess evidence completeness, control effectiveness, outstanding exceptions, the timeliness of change reassessment and the speed with which AI incidents are detected and resolved.

Human oversight can likewise be evaluated through measures such as the proportion of relevant decisions receiving documented review, the frequency of overrides and the time taken to intervene where thresholds are exceeded.

The value of such metrics is not that they create a single numerical definition of good governance. Rather, they enable management to identify patterns, weaknesses and areas requiring attention. They convert evidence from a passive repository into a source of management information.

This aligns with ISO/IEC 42001's emphasis on performance evaluation and management review, whereby information generated through the management system should inform subsequent governance decisions (ISO, 2023).

9.22 Evidence as a Management Resource

Evidence should therefore serve management as well as auditors.

Executives require reliable information to determine which AI systems present the greatest risks, where ownership is unclear, where control weaknesses are concentrated, which regulatory requirements are difficult to demonstrate, how many exceptions remain open, which systems require reassessment and where human oversight or monitoring is failing.

A well-designed evidence architecture can consequently become a management information resource for AI risk. It allows management to move beyond assertions about the maturity of governance towards evidence-based assessments of where governance is operating effectively and where intervention is required.

This is particularly important as organisations move from managing a small number of experimental AI applications towards portfolios containing numerous models, applications, vendors and use cases. At scale, governance cannot depend on senior management knowing the status of every system individually. It requires reliable information structures through which governance status can be understood and challenged.

9.23 Evidence and the AI Governance Control Plane

The evidence concept can be integrated with the AI control plane developed in the preceding chapter. The control plane should not merely maintain system metadata. Its greater value lies in connecting the system to its owner, purpose, risk classification, applicable requirements, controls, evidence, assurance findings and corrective actions.

In this architecture, a change to an AI system can therefore have governance consequences that are visible within the same environment. A change to an approved model version can trigger reassessment. A change in regulatory classification can activate additional controls. A failed monitoring threshold can generate an incident and initiate a corrective-action process. An expired approval can prevent deployment.

The control plane thus provides a technical representation of governance accountability. It creates relationships between organisational decisions and technical state, while the evidence architecture provides the records necessary to demonstrate how those relationships have operated over time.

This approach reflects the broader argument that governance is strengthened when organisational requirements are embedded into technical and organisational environments rather than maintained solely through policy (Enabling affordances for AI governance, 2024).

9.24 Evidence and Continuous Compliance

The importance of evidence becomes even clearer when compliance is understood as a continuous lifecycle process.

At each stage, the organisation should be able to establish what decision was made, who made it, what information supported it, what control was established, what evidence demonstrates that the control operated and what happened when circumstances changed.

This creates a continuous evidence chain from ideation and classification through risk assessment, design, development, validation, approval, deployment, monitoring, incident management, change and retirement. It also reinforces the argument developed in the preceding chapter that compliance is better understood as a continuous organisational control loop than as a static compliance artefact.

The organisation can therefore move beyond the assertion that an AI system is compliant towards a more defensible proposition: that it can demonstrate how relevant requirements were interpreted, implemented, monitored, tested and reviewed throughout the system's lifecycle.

9.25 Requirements-to-Evidence Architecture

A practical governance architecture should maintain an explicit relationship between governance domains, control objectives, evidence and assurance questions. This does not require a single centralised repository or a rigid template. The important feature is traceability.

For ownership, the relevant control objective may be that every material AI system has identifiable accountability. Evidence might include an ownership register and formal assignment record, while assurance asks whether ownership remains current.

For classification, the objective may be that the applicable regulatory and organisational status of the system is documented. Evidence may include classification assessments, with assurance testing whether the classification remains correct as the system or regulatory environment changes.

For risk management, evidence may include risk assessments, treatment decisions and reassessments, with assurance examining whether identified risks remain current and whether controls correspond to the assessed risk.

For data governance, evidence may include provenance, lineage and quality assessments, while assurance examines whether the organisation can demonstrate the suitability and governance of relevant data.

For human oversight, evidence may include role assignments, competence records, intervention configurations and override records, while assurance tests whether authorised individuals can actually intervene effectively.

For security, evidence may include access records, security testing and incident records, with assurance assessing whether security controls operate effectively.

For monitoring, evidence may include performance reports, alerts and threshold breaches, with assurance examining whether monitoring remains appropriate and whether identified deterioration leads to intervention.

For change management, evidence may include change records and reassessment decisions, while assurance examines whether material changes reliably trigger the required governance response.

Finally, assurance itself should generate evidence through audit reports, control-testing results and remediation records, demonstrating whether identified weaknesses have been addressed.

This approach creates a bridge between regulatory requirements, ISO/IEC 42001 processes and organisational controls without requiring governance to depend on a single document or repository.

9.26 The Risk of Evidence Theatre

The emphasis on evidence introduces an important danger: evidence can become performative rather than substantive.

An organisation can produce extensive documentation while failing to exercise meaningful control. Risk assessments may be completed without influencing system design. Human oversight may be recorded but remain nominal. Logs may be generated but never reviewed. Metrics may be collected without intervention thresholds. Assessments may be performed without affecting deployment or operational decisions.

This can be described as evidence theatre.

The problem is not that the evidence is false in a narrow sense. It is that evidence becomes detached from governance action. The organisation can demonstrate that a form was completed or a record was generated, but not that the information influenced decisions or that the associated control achieved its purpose.

Evidence therefore has value only when it remains connected to decision-making and control. The strongest evidence demonstrates not merely that something was recorded, but that the organisation interpreted the information and acted upon it when necessary.

9.27 From Evidence to Action

This leads to a critical relationship between evidence, governance and intervention. Evidence identifies what happened. Interpretation determines its significance. Decision-making determines what should happen next. Intervention changes the system or its operation.

Suppose monitoring evidence shows that model error has exceeded an established threshold. The organisation must then determine whether the deterioration creates material operational risk. If it does, an authorised decision-maker may suspend automated decisions and route affected cases to human review. Corrective action may subsequently investigate model drift, data changes or other causes and determine whether retraining, redesign or retirement is required.

This is the point at which auditability and controllability converge.

Auditability provides the evidence necessary to understand what happened. Controllability provides the practical capacity to respond. Governance connects the two by establishing who has authority to interpret evidence and intervene.

A governance architecture that records events but cannot act on them is therefore incomplete. Equally, an organisation capable of intervention but unable to establish when and why intervention is necessary lacks sufficient observability. Effective AI governance requires both.

9.28 A More Complete Conception of Accountability

The analysis permits the conception of accountability developed by Novelli, Taddeo and Floridi (2024) to be operationalised more fully. Accountability can be understood through a relationship between authority, responsibility, decision, evidence, review, intervention and consequence.

This is stronger than simply assigning ownership because an individual cannot meaningfully be held accountable for a decision if they lacked the authority, information or resources necessary to make it, if the decision was not recorded, or if there was no mechanism through which it could be reviewed.

Effective accountability therefore requires an evidentiary infrastructure. It must make decision-making visible while preserving the institutional mechanisms necessary to challenge and evaluate those decisions.

This also reinforces the importance of control-accountability alignment identified by Grote, Parker and Crowston (2024). Accountability is meaningful where actors have sufficient control over the decisions for which they are held responsible and where evidence allows those decisions to be examined.

9.29 Evidence as Organisational Infrastructure

The central argument of this chapter can therefore be sharpened: evidence should be treated as infrastructure for AI governance rather than as paperwork generated for auditors.

This requires organisational and technical systems to generate evidence continuously, connect it to decisions, attribute it to responsible actors, trace it to applicable requirements, protect its integrity, retain it appropriately and make it available to authorised reviewers.

Such an architecture changes the practical meaning of governance. Instead of maintaining a policy that states how AI should be governed and a repository containing documents that supposedly demonstrate compliance, the organisation creates an environment in which governance activity itself generates a reliable record.

The distinction is consequential. A governance system that produces evidence continuously can support management decisions, regulatory engagement, audit, incident investigation, organisational learning and corrective action. It also reduces dependence on retrospective reconstruction, which is particularly valuable when systems have changed, personnel have moved or the original decision context has been forgotten.

Evidence consequently becomes part of the infrastructure through which governance persists over time.

9.30 Conclusion

The importance of evidence follows directly from the distinction between formal governance and effective governance.

A principle establishes an expectation. A requirement translates that expectation into something that must be achieved. A control establishes a mechanism for achieving it. Responsibility assigns decision rights. Operational activity demonstrates implementation. Evidence demonstrates what actually occurred. Assurance evaluates whether the control operated effectively. Corrective action addresses weaknesses and feeds the resulting knowledge back into the governance system.

This provides an operational interpretation of accountability. As Novelli, Taddeo and Floridi (2024) emphasise, accountability requires answerability: actors must be situated within standards, processes and institutional arrangements through which their decisions can be questioned and evaluated. Evidence provides the factual foundation for that process.

The EU AI Act reinforces this orientation through its requirements concerning risk management, technical documentation, logging, human oversight, quality management and post-market monitoring for relevant AI systems (European Parliament and Council of the European Union, 2024). ISO/IEC 42001 complements the regulatory framework by embedding performance evaluation, internal audit, management review, corrective action and continual improvement within an organisational AI management system (ISO, 2023). The wider AI governance literature similarly points towards governance arrangements that integrate organisational responsibility, technical controls and mechanisms for continuous evaluation rather than relying solely on high-level principles (Batool, Zowghi and Bano, 2025; Camilleri, 2024).

The central proposition can therefore be stated more precisely: a mature AI governance system should continuously produce an auditable chain connecting applicable requirements to organisational decisions, operational controls, responsible actors, evidence, assurance and corrective action.

This changes the meaning of compliance. Compliance is no longer adequately expressed through the proposition that an organisation has met a requirement. A stronger governance position is one in which the organisation can demonstrate who was responsible, what was decided, which control was applied, what actually happened, what evidence was generated, how effectiveness was evaluated and what action was taken when the control proved insufficient.

The objective is therefore not to maximise the quantity of governance documentation. It is to establish evidence continuity: a reliable relationship between requirements, decisions, controls, actions and outcomes throughout the AI lifecycle. When that relationship is embedded into organisational processes and technical architecture, evidence becomes more than an audit resource. It becomes a mechanism for accountability, organisational memory, management decision-making, regulatory traceability, assurance and continual improvement.

The transition is consequently from principle-based AI governance to evidence-based AI assurance. Mature governance is demonstrated not by the existence of policies, but by the organisation's ability to show that its principles have been operationalised, that controls have operated, that responsible actors have exercised their decision rights, that outcomes have been monitored, and that the organisation has acted when evidence indicates that governance is no longer sufficient.

10. Governance of Automated Processes and IT Platforms

The proposition under examination extends beyond AI systems narrowly defined. It refers explicitly to AI systems, automated processes and IT platforms, thereby locating AI governance within the broader domain of organisational technology governance.

This distinction is important because consequential automated decision-making does not necessarily depend upon what would conventionally be described as an artificial-intelligence model. An organisation may, for example, use rules-based automation to approve transactions, determine access privileges, trigger fraud alerts, prioritise customer cases, route healthcare interventions or initiate employment processes. A technically simple workflow may therefore produce consequences comparable to those of a sophisticated machine-learning system.

The governance question is consequently not only:

“Is this AI?”

but also:

“What authority does this automated system exercise, what consequences can it produce, and what controls govern its operation?”

This broader perspective is consistent with the sociotechnical understanding of AI governance. Batool, Zowghi and Bano (2025) conceptualise AI governance across multiple levels and dimensions rather than as a narrowly technical activity. Their analysis supports the proposition that governance must consider the organisational and institutional context in which computational systems operate. Similarly, Grote, Parker and Crowston (2024) emphasise the relationship between automation, control and accountability, highlighting the importance of ensuring that organisational actors retain meaningful control over systems whose outputs may have consequential effects.

The implication is that organisations should avoid constructing an artificial boundary between AI governance and IT governance. In practice, the two are increasingly interdependent.

10.1 From AI Governance to Automated Decision Governance

A useful starting point is to distinguish between the technology used and the decision authority exercised.

An automated system may employ:

• machine learning;

• generative AI;

• statistical models;

• deterministic business rules;

• robotic process automation;

• workflow engines;

• decision trees;

• rules-based access controls; or

• combinations of these technologies.

From a governance perspective, the critical question is not necessarily which technical mechanism is used. It is the extent to which the system:

1. makes or influences decisions;

2. acts autonomously;

3. affects individuals or organisations;

4. accesses sensitive or critical information;

5. initiates consequential actions;

6. interacts with other automated systems; or

7. creates material operational, legal, financial, security or reputational risk.

This suggests a broader governance principle:

Governance intensity should be proportionate to the consequences and autonomy of automated activity, rather than determined solely by its technical label.

This approach also helps prevent technology-classification arbitrage, in which materially similar systems receive different governance treatment simply because one is labelled “AI” and another “automation”.

The resulting governance perimeter should therefore be based on function, authority, impact and risk, with technology classification used as one input rather than as the sole determinant.

10.2 Why the Boundary Between AI and IT Governance Is Becoming Less Clear

The distinction between AI and conventional IT is becoming increasingly difficult to sustain operationally.

A modern AI application may consist of a chain such as:

User interface → Application → AI model → API → Data platform → Cloud infrastructure → Identity system → Monitoring platform

The AI model is therefore only one component of a larger sociotechnical system.

A failure at another layer can materially alter the behaviour or risk profile of the AI-enabled application. For example:

• an incorrect identity configuration may expose an AI system to unauthorised users;

• a compromised API may manipulate model inputs;

• poor data lineage may undermine the reliability of model outputs;

• an infrastructure failure may disable human-oversight mechanisms;

• inadequate logging may prevent reconstruction of consequential decisions;

• a cloud-service outage may interrupt critical operations; or

• a third-party model update may materially change system behaviour.

Consequently, governing the model without governing its surrounding infrastructure may create a misleading impression of organisational control.

The relevant object of governance is therefore often not the model alone, but the AI-enabled system and its dependencies.

10.3 Automated Processes as Governance Objects

This broader perspective is particularly important for business-process automation.

Consider an automated loan-processing workflow:

Application → Identity verification → Data validation → Risk calculation → Decision → Notification

Even if the individual components are conventional software, the overall process can produce a consequential outcome.

Governance must therefore establish:

• who owns the process;

• what decisions are automated;

• what rules or models determine those decisions;

• what data is used;

• what exceptions exist;

• when human intervention is required;

• how decisions are recorded;

• how errors are detected;

• how the process can be suspended; and

• who is accountable for outcomes.

The same logic applies to automated processes in recruitment, insurance, healthcare, financial services, cybersecurity and public administration.

The governance unit is consequently better understood as the automated decision process rather than the individual algorithm.

10.4 The Consequences of Automation

Automation changes organisational control because it can increase the speed, scale and persistence with which decisions are made.

A human decision-maker may process ten cases. An automated system may process ten thousand.

A configuration error that would have affected a small number of cases manually can therefore become systemic when embedded within automation.

This produces an important governance relationship:

Automation amplifies both operational capability and control failure.

The same mechanism that produces efficiency can also:

• propagate erroneous decisions;

• amplify discriminatory outcomes;

• create systemic security vulnerabilities;

• accelerate fraudulent activity;

• spread inaccurate information;

• create widespread service disruption; or

• make erroneous decisions difficult to reverse.

Governance should therefore assess not only the probability of failure but also the scale, severity and reversibility of automated consequences.

10.5 Autonomy as a Governance Variable

A further variable that can be used to differentiate automated and AI-enabled systems is their degree of effective autonomy. Autonomy is important from a governance perspective because the significance of a system is determined not only by the technology it uses, but also by the extent to which it can influence or determine outcomes without direct human intervention.

At the lowest level, a system may operate primarily as an information tool, providing data or analysis to human users while leaving the substantive decision entirely to the individual. In such circumstances, governance is principally concerned with information accuracy, data quality and appropriate use.

A greater degree of autonomy exists where the system provides recommendations that materially influence human decisions. The human decision-maker remains formally responsible for the final outcome, but governance must increasingly address the reliability of recommendations, the basis on which they are generated and the potential for users to become overly dependent on automated outputs.

At a further level, systems may perform conditional automation, in which the system is authorised to act automatically in defined circumstances but requires human intervention for specified cases, exceptions or decisions. Governance at this level requires clearly defined intervention thresholds, escalation procedures and decision rights.

Higher levels of autonomy arise where a system can perform actions with limited human intervention. In such circumstances, governance must place greater emphasis on the boundaries of the system's authority, monitoring, exception handling, intervention mechanisms and the ability to suspend or reverse automated actions.

At the highest level, a system may be capable of autonomous action, meaning that it can initiate or complete consequential activities without case-by-case human approval. Such systems require particularly strong governance over delegated authority, monitoring, human intervention, accountability and the conditions under which automated activity may be suspended or terminated.

These levels should be understood as illustrative governance categories rather than regulatory classifications. They are intended to demonstrate a relationship between autonomy and governance intensity rather than establish a formal classification system. The appropriate level of control will also depend on the consequences of the system's actions, the sensitivity of the data involved, the reversibility of decisions, the number of people affected and the applicable regulatory requirements.

The central governance principle is therefore:

The greater the system's effective decision-making authority, the greater the need for explicit controls over that authority.

This principle connects directly with the relationship between control and accountability identified by Grote, Parker and Crowston (2024). As technological systems exercise greater autonomy, responsibility cannot simply be assigned to a human or organisational actor who lacks the practical ability to influence the relevant outcome. Accountability must therefore remain connected to meaningful authority, information, resources and intervention capability.

This also has implications for human oversight. The existence of a human somewhere within the process does not necessarily establish meaningful human control. Where a system can act autonomously, governance should establish who is authorised to intervene, when intervention is required, what information must be available to the decision-maker, and whether the intervention can actually change or stop the system's behaviour. This is consistent with the broader approach to human oversight under the EU AI Act, which treats human oversight as an operational governance requirement rather than simply the presence of a human in the process (European Parliament and Council of the European Union, 2024).

Autonomy should consequently be treated as a governance variable that influences the level and nature of controls applied to an AI or automated system. The higher the effective autonomy and the greater the potential consequences of automated action, the stronger the organisation's requirements should generally be for authority management, monitoring, intervention, evidence and independent assurance.

10.6 The IT Platform as a Governance Boundary

The phrase “IT platform” introduces another important dimension.

AI governance cannot operate effectively if the underlying platform is outside the governance perimeter.

The platform may determine:

• who can access the system;

• which model version is deployed;

• what data the system can retrieve;

• which APIs it can invoke;

• what actions it can execute;

• what logs are retained;

• how changes are authorised; and

• whether the system can be suspended.

Platform governance therefore provides part of the technical foundation for AI governance.

This is particularly significant for cloud-based AI architectures in which organisations may rely on external infrastructure, model providers, software libraries, APIs and managed AI services.

The organisation may not control every component. Nevertheless, it remains responsible for establishing appropriate controls over the system it deploys and operates.

10.7 Integration with Enterprise Risk Management

AI governance should connect with enterprise risk management (ERM) rather than operate as a separate technical-risk function.

The enterprise-risk perspective enables AI-related risks to be considered alongside:

• financial risk;

• operational risk;

• legal and regulatory risk;

• cybersecurity risk;

• privacy risk;

• third-party risk;

• reputational risk; and

• business-continuity risk.

This is particularly important for senior management and boards.

The relevant question is not simply:

“Is the model technically accurate?”

It is:

“What organisational risks does this AI-enabled process create, how significant are they, who owns them, and are the controls proportionate to the organisation's risk appetite?”

This shifts AI governance from model-centric risk management towards enterprise-level accountability.

10.8 Integration with Information Security

AI systems inherit conventional information-security risks while also introducing additional attack surfaces.

An AI-enabled process may depend on:

• identity and access management;

• network infrastructure;

• cloud environments;

• APIs;

• databases;

• secrets management;

• software dependencies;

• model repositories; and

• monitoring systems.

Compromise of any of these components can affect the confidentiality, integrity or availability of the AI-enabled system.

AI governance should therefore be integrated with information-security management rather than treated as an isolated governance domain.

This is consistent with ISO/IEC 42001's management-system orientation, which permits AI governance to be integrated with existing organisational management systems, including information-security management systems (ISO, 2023).

The relationship can be expressed simply:

AI governance determines what must be controlled; information security provides many of the mechanisms through which those controls are implemented.

10.9 Data Governance as a Shared Control Layer

The relationship with data governance is equally important.

AI systems frequently depend on data for:

• training;

• validation;

• retrieval;

• inference;

• monitoring;

• decision-making; and

• post-deployment evaluation.

Automated processes may similarly depend on databases and reference data to execute business rules.

Data governance should therefore establish:

• provenance;

• ownership;

• quality;

• access;

• classification;

• lineage;

• retention;

• permitted use;

• transformation; and

• deletion.

Poor data governance can undermine an otherwise sophisticated AI governance system.

For example, an organisation may possess an excellent model-development process but be unable to demonstrate where a material dataset originated, whether it was appropriately obtained or how it was transformed.

This creates a fundamental dependency:

Model assurance cannot be stronger than the governance of critical inputs on which the model depends.

10.10 Software Development and DevSecOps

Governance should also be integrated into software-development processes.

Traditional software-development lifecycle controls may include:

• requirements management;

• code review;

• testing;

• release approval;

• version control;

• security testing;

• change management; and

• deployment controls.

AI-enabled systems require these controls to be extended to include:

• model versioning;

• dataset changes;

• prompt or configuration changes;

• evaluation results;

• model validation;

• performance thresholds;

• AI-specific security testing; and

• reassessment following material changes.

This creates the possibility of governance embedded in the development pipeline.

For example:

Code change → Testing → AI evaluation → Risk check → Governance approval → Deployment → Monitoring

Rather than requiring governance teams to inspect every system retrospectively, organisations can introduce controls directly into the engineering process.

The objective is to make governance part of the normal development workflow, rather than an additional documentation exercise performed after technical work has been completed.

10.11 IT Service Management

AI systems also need to be governed as operational services.

Once deployed, they require:

• service ownership;

• incident management;

• problem management;

• change management;

• service-level monitoring;

• capacity management;

• availability controls; and

• retirement procedures.

An AI system that is treated as a model but not as an operational service may lack the processes required to manage:

• outages;

• degraded performance;

• security incidents;

• supplier failures;

• material model changes; or

• unexpected user behaviour.

The management challenge is therefore not simply model lifecycle management, but service lifecycle management.

10.12 Business Continuity and Resilience

Dependence on AI-enabled processes also creates business-continuity considerations.

If an automated process becomes unavailable, organisations need to determine:

• what business activities are affected;

• whether manual alternatives exist;

• how long the organisation can operate without the system;

• whether automated decisions can safely be suspended;

• how transactions are reconciled after restoration; and

• who has authority to activate contingency arrangements.

For high-impact systems, deactivation capability is therefore a resilience control.

This reinforces the distinction between auditability and controllability.

A system may be fully observable while still creating substantial operational risk if the organisation cannot safely suspend, override or revert it.

10.13 Third-Party and Vendor Governance

The governance perimeter becomes more complicated where AI capability is supplied by third parties.

Organisations may use:

• foundation-model providers;

• cloud AI services;

• external APIs;

• data vendors;

• software libraries;

• managed security services; or

• outsourced business-process providers.

In these circumstances, the organisation may lack direct control over:

• model training;

• underlying datasets;

• infrastructure;

• model updates;

• security architecture;

• availability;

• logging; or

• technical documentation.

This creates a significant governance challenge.

The organisation should therefore establish contractual and operational mechanisms for obtaining appropriate assurance from suppliers.

These may include:

• contractual control requirements;

• security obligations;

• data-use restrictions;

• change-notification requirements;

• audit rights;

• incident-notification requirements;

• service-level commitments;

• documentation requirements; and

• evidence-access provisions.

The critical principle is:

Outsourcing technology does not necessarily outsource organisational accountability.

A third-party model may be externally developed, but the organisation remains responsible for understanding how it is used within its own processes and risk environment.

10.14 Interdependencies and the Control Chain

A useful way of understanding the governance problem is through the concept of a control chain.

An AI-enabled business process might depend upon:

Data → Model → Application → API → Infrastructure → Identity → Monitoring → Human oversight

A governance failure at any point can affect the overall system.

For example:

Data failure

→ inappropriate input

→ erroneous model output

→ incorrect application decision

→ automated business action

→ customer impact.

Alternatively:

Identity failure

→ unauthorised access

→ manipulation of AI inputs

→ compromised output

→ automated action

→ operational or security incident.

The risk therefore resides not exclusively within the model. It emerges from interdependencies across the technology stack and organisational process.

This is why system-level governance is necessary.

10.15 Governance Should Follow the Control Boundary

This suggests a more sophisticated principle for defining governance scope:

The governance boundary should follow the boundary of consequential control.

If an AI model merely generates an internal draft that a qualified employee independently reviews, governance requirements may be relatively limited.

If the same model automatically determines access, initiates financial transactions or makes consequential decisions affecting individuals, governance requirements become substantially stronger.

The relevant unit is therefore:

System + process + decision + authority + consequence

rather than:

AI model alone

This distinction helps organisations avoid both under-governance and unnecessary bureaucratic controls.

10.16 A Layered Governance Architecture

The preceding discussion can be understood as a layered governance architecture in which different organisational and technological dimensions are subject to distinct but interconnected governance questions and controls. At the enterprise level, the organisation determines which risks it is prepared to accept through mechanisms such as risk appetite, governance arrangements and board oversight. At the regulatory level, it identifies the external legal and regulatory requirements that apply and translates them into applicable obligations through legal assessment and compliance mapping.

At the AI-system level, the organisation determines how the AI system itself should be governed, including through risk assessment, documentation and human oversight. At the process level, attention shifts to the decisions and actions that are automated, with controls addressing matters such as approval, segregation of duties and escalation. The data layer addresses whether the information on which the system depends is appropriately governed, including its provenance, quality, access and lineage.

The application layer concerns how AI functionality is implemented within software and business applications. Relevant controls include secure development, testing and change management. The infrastructure layer addresses whether the underlying technical environment is adequately controlled, including security, resilience and access management. At the operational level, governance focuses on whether the system remains controlled once deployed, supported by monitoring, incident management and IT service-management processes.

The third-party layer addresses dependencies on external suppliers and whether they can provide sufficient assurance regarding the services and technologies on which the organisation relies. Relevant controls include due diligence, contractual requirements and ongoing supplier monitoring. Finally, the assurance layer considers whether the overall governance framework is actually effective, using mechanisms such as audit, testing and management review.

Taken together, these layers demonstrate that AI governance is not a single control function operating in isolation. Rather, it is an integrated governance architecture in which enterprise, regulatory, system, process, data, application, infrastructure, operational, third-party and assurance controls interact. This approach allows AI governance to be incorporated into existing enterprise governance structures while avoiding the assumption that each layer requires a separate governance function or independent control framework.

10.17 Avoiding Governance Fragmentation

A major risk is the emergence of separate governance silos:

AI governance
IT governance
Data governance
Cybersecurity governance
Privacy governance
Compliance governance
Operational governance

If each function maintains independent policies, risk registers and control frameworks, the organisation may create duplication while still leaving important gaps.

A more mature model is integrated governance.

For a single AI-enabled system, this should ideally produce:

• one accountable business owner;

• one system inventory record;

• one consolidated risk profile;

• mapped regulatory obligations;

• linked data and security controls;

• defined operational responsibilities;

• integrated incident management;

• change-management triggers; and

• a common evidence and assurance trail.

This does not require every function to perform the same role. Rather, it requires the functions to operate around a shared governance object.

10.18 The Role of the AI and Automation Inventory

An integrated governance model requires visibility.

An organisation cannot govern systems it does not know it operates.

An AI and automation inventory should therefore capture, where proportionate:

• system identity;

• business owner;

• technical owner;

• purpose;

• users;

• data categories;

• model or automation type;

• third-party dependencies;

• regulatory classification;

• risk classification;

• deployment environment;

• lifecycle status;

• monitoring arrangements;

• material changes; and

• retirement date.

The inventory becomes the organisational reference point from which risk, compliance, security and assurance processes operate.

This is particularly important in large organisations where AI capabilities may emerge through local experimentation, procurement, software features and third-party services rather than through a centrally controlled programme.

10.19 Governance of Shadow AI and Unauthorised Automation

The broader perspective also provides a useful response to shadow AI.

Employees may introduce AI-enabled services or automation through:

• consumer AI tools;

• browser extensions;

• SaaS applications;

• developer libraries;

• workflow automation platforms; or

• embedded AI functionality within existing enterprise software.

A model-centric governance programme may fail to identify these systems because they are not formally registered as AI projects.

A process- and platform-oriented approach instead asks:

What automated capabilities are being used to perform organisational activities?

Discovery should therefore combine mechanisms such as:

• procurement controls;

• platform monitoring;

• access controls;

• data-loss prevention;

• software inventories;

• vendor assessments;

• employee training; and

• risk-based registration.

The objective is not necessarily to prohibit experimentation. It is to ensure that consequential use becomes visible to governance functions.

10.20 AI Governance as an Extension of Enterprise Control

AI governance should not be treated as an entirely new organisational discipline.

Rather, it can be understood as an extension of existing enterprise-control architecture.

Existing functions already address many of the underlying governance questions:

• Who has authority?

• What risks are acceptable?

• How are systems approved?

• How are changes controlled?

• How are incidents managed?

• How is evidence retained?

• How are suppliers governed?

• How is independent assurance provided?

AI introduces new technical characteristics and new risk scenarios, but many governance mechanisms remain recognisable.

ISO/IEC 42001 is particularly relevant because its management-system architecture allows AI governance to be integrated with other organisational management systems rather than requiring an entirely separate control environment (ISO, 2023).

The objective should therefore be integration rather than institutional duplication.

10.21 From Model Governance to System Governance

This chapter supports a shift from:

Model governance

towards:

AI-enabled system governance

and ultimately towards:

Automated decision and technology governance.

The distinction is important.

Model governance asks:

Is the model technically valid?

System governance additionally asks:

• Is the model being used for the purpose for which it was approved?

• Is the surrounding application secure?

• Is the data appropriately governed?

• Can authorised people intervene?

• Are changes controlled?

• Are suppliers adequately governed?

• Can the system be suspended?

• Are decisions and interventions recorded?

• Can the organisation demonstrate compliance?

The second set of questions is much closer to the practical meaning of organisational accountability.

10.22 A Unified Governance Model

The analysis can be consolidated into a unified control architecture:

Enterprise governance
↓
Regulatory and risk requirements
↓
AI and automation inventory
↓
System and process risk assessment
↓
Data, model, application and infrastructure controls
↓
Human oversight and intervention
↓
Operational monitoring
↓
Evidence and audit trail
↓
Independent assurance
↓
Corrective action and continual improvement

This architecture provides a bridge between the EU AI Act, ISO/IEC 42001 and established enterprise IT controls.

It also makes explicit why governance cannot reside solely within an AI or data-science team.

10.23 Implications for Organisational Design

The integration of AI, automation and IT governance has several organisational consequences.

First, AI governance should have access to enterprise authority. A function unable to influence procurement, deployment, risk acceptance or system suspension cannot provide meaningful governance.

Second, technical teams should remain responsible for technical controls, rather than transferring all responsibility to compliance functions.

Third, business owners must retain accountability for the organisational purpose and consequences of automated systems.

Fourth, risk, compliance, privacy and security functions must provide challenge and specialist expertise.

Finally, internal audit should retain sufficient independence to evaluate the effectiveness of the overall governance system.

This reinforces the central argument of Grote, Parker and Crowston (2024): accountability should be aligned with the capacity to exercise control.

10.24 A Practical Control Matrix

An organisation can operationalise this integrated governance approach through a control matrix that links each governance domain to a specific question, accountable owner and form of evidence. Such a matrix provides a practical mechanism for translating governance principles into defined responsibilities and auditable controls.

The system inventory domain establishes what automated and AI-enabled systems exist within the organisation. The central governance question is: What automated systems exist? Responsibility may sit with AI or IT governance, with the inventory serving as the primary evidence.

The business purpose domain establishes why a system is being used and what organisational objective it is intended to support. The relevant question is: Why is the system used? The business owner should be accountable for this determination, supported by a documented use-case record.

The risk domain considers what could go wrong and what consequences may arise. The question is: What risks does the system create? Responsibility should be shared between the relevant risk function and business owner, with the risk assessment providing the evidence.

The regulatory domain determines which legal and regulatory requirements apply. The question is: Which requirements apply to the system and its use? Legal or compliance functions should normally lead this assessment, with regulatory mapping providing the evidence of the determination.

The data domain addresses the information used by the system. The relevant question is: What information does the system use, and is that information appropriately governed? Data governance should provide the primary oversight, supported by evidence such as data lineage, classification and related governance records.

The model and logic domain examines how the system generates its outputs. The question is: How does the system generate outputs or decisions? AI, engineering or technical teams should be accountable for this area, with technical documentation providing evidence of the relevant architecture, model, rules or processing logic.

The security domain considers whether the system could be compromised and what consequences such a compromise could produce. The question is: Can the system or its supporting environment be compromised? The security function should provide the primary oversight, supported by security assessments and related testing evidence.

The access domain addresses who is authorised to operate, administer or otherwise interact with the system. The relevant question is: Who can access or operate the system? IT and security functions should manage this control area, with access records providing evidence that permissions are appropriately assigned and controlled.

The human oversight domain establishes who has authority to intervene in the system's operation. The question is: Who can intervene, under what circumstances, and with what authority? The business owner should remain accountable for ensuring that appropriate intervention responsibilities are defined, with role definitions and intervention records providing supporting evidence.

The change domain addresses how governance is maintained when the system changes. The question is: What happens when the system, model, data, configuration or operating context changes? Engineering and IT functions should manage the relevant change processes, with change records demonstrating that material changes were identified, assessed and appropriately authorised.

The operations domain considers whether the system continues to perform as expected after deployment. The question is: Is the system performing as expected in its operational environment? Operational teams should provide primary oversight, supported by monitoring records, performance information and other operational evidence.

The incident domain addresses how the organisation responds when the system fails or produces an adverse outcome. The relevant question is: What happens when the system fails or creates a material incident? Responsibility should normally be shared between operations and risk functions, with incident records documenting detection, escalation, investigation, containment and remediation.

The supplier domain addresses dependencies on external providers and technology. The question is: What external dependencies exist, and can suppliers provide sufficient assurance? Procurement and vendor-risk functions should oversee this area, supported by due-diligence records, contractual requirements, supplier assessments and ongoing monitoring.

The assurance domain determines whether the governance arrangements actually operate effectively. The question is: Does governance work in practice? Internal audit or another appropriately independent assurance function should provide the relevant challenge, with audit reports, testing results and management-review records providing evidence.

Finally, the improvement domain establishes how identified weaknesses, incidents, audit findings and changes in circumstances are addressed. The question is: What needs to change? The relevant governance owner should coordinate corrective action and continual improvement, with corrective-action records demonstrating how identified issues were addressed.

Taken together, these domains create a chain from identification and purpose through risk, regulation, technical implementation, security, human oversight, operation, incident management, assurance and improvement. The matrix therefore converts governance requirements into an operational structure in which each material question has an accountable owner and corresponding evidence.

Importantly, this does not require every organisation to adopt the same organisational structure. Responsibilities may be distributed differently depending on the organisation's size, complexity and risk profile. What matters is that the organisation can demonstrate that each governance question has been assigned, controlled, evidenced and subject to appropriate assurance.

10.25 The Central Governance Principle

The broader argument can now be sharpened into a single proposition:

Organisations should govern consequential automation according to the authority, autonomy and impact it creates, while integrating AI-specific controls with existing IT, data, security, risk and assurance mechanisms.

This principle avoids two opposing errors.

The first is under-governance:

“It is only automation, so AI governance does not apply.”

The second is over-fragmentation:

“AI is different, so it requires an entirely separate governance universe.”

A more defensible position is that AI introduces additional risks and regulatory requirements, but these should be incorporated into an integrated enterprise-control environment.

10.26 Conclusion

The phrase “AI systems, automated processes and IT platforms” therefore has substantial conceptual significance.

It indicates that effective AI governance cannot be limited to model development or AI policy. AI systems operate within broader technological and organisational infrastructures, while conventional automation can exercise consequential decision-making authority without employing advanced AI.

The appropriate governance object is consequently not simply the model. It is the sociotechnical system through which automated capability is converted into organisational action.

This leads to a broader governance equation:

Effective technology governance = authority + risk management + technical controls + operational controls + human oversight + evidence + assurance

The EU AI Act provides legally binding requirements for specified categories and uses of AI, including requirements concerning risk management, documentation, logging, human oversight and post-market monitoring (European Parliament and Council of the European Union, 2024). ISO/IEC 42001 provides a management-system architecture through which organisations can institutionalise policies, risk processes, operational controls, performance evaluation and continual improvement (ISO, 2023).

The two should therefore be integrated with established organisational disciplines rather than implemented as isolated compliance programmes.

The ultimate objective is an enterprise environment in which:

AI systems are governed as systems; automated processes are governed according to their consequences; and IT platforms are governed as the infrastructure through which organisational authority is exercised.

This provides the foundation for the subsequent argument that auditability and controllability must extend across the entire technology and decision chain, from data and models through applications and infrastructure to human decision-makers, business processes and organisational outcomes.

11. Challenges and Limitations

The governance architecture developed in the preceding chapters provides a useful basis for making AI systems, automated processes and IT platforms more auditable, controllable and accountable. However, the existence of policies, committees, risk assessments, controls and assurance processes does not, by itself, guarantee effective governance. Implementation is complicated by distributed responsibility, technical complexity, changing system behaviour, regulatory uncertainty, organisational capability and the possibility that governance itself becomes excessively bureaucratic.

The central challenge is therefore not simply to increase the amount of governance, but to design governance that is effective, proportionate, adaptive and capable of producing meaningful control. This is particularly important because AI governance operates within a sociotechnical environment in which responsibility is distributed across people, organisational units, technologies and external suppliers, while the systems being governed may themselves change over time. Batool, Zowghi and Bano (2025) emphasise the multilevel character of AI governance, while Grote, Parker and Crowston (2024) highlight the importance of aligning control and accountability where technological systems exercise increasing autonomy.

The fundamental governance problem can therefore be framed as follows: how can an organisation establish sufficient control and evidence without creating structures that are fragmented, ineffective, excessively costly or incapable of adapting to technological change?

11.1 Responsibility and Accountability Across the AI Value Chain

One of the most significant challenges concerns the allocation of responsibility. Contemporary AI systems may involve a complex chain of actors, including data providers, model developers, platform providers, system integrators, deploying organisations, business users and, ultimately, individuals affected by the system. Responsibility can therefore be distributed across several legal entities and organisational functions.

For example, a foundation model may be developed by one organisation, hosted by another, incorporated into an enterprise application by a third party and ultimately used by an organisation to make decisions affecting customers or employees. The resulting governance question is not simply who developed the model, but who has authority over the particular risks created by its use.

The deploying organisation may control the use case, the data supplied to the system, the operational context, the decision process, human oversight and the consequences of deployment. The model provider, by contrast, may control aspects of the model architecture, training processes, model updates, infrastructure and technical safeguards. This distinction makes it important to separate technical responsibility from organisational accountability.

An organisation cannot necessarily control every technical component of an AI system, but it must establish who has sufficient authority, information and resources to manage the risks arising from its deployment. This supports the argument made by Grote, Parker and Crowston (2024) that accountability should be aligned with meaningful control. Assigning responsibility to an actor who lacks the ability to influence the relevant outcome creates what may be described as accountability without control.

Distributed responsibility also creates a distributed knowledge problem. A business owner may understand the organisational purpose without understanding the technical architecture; a data scientist may understand the model without understanding the regulatory environment; a compliance officer may understand the legal requirements without understanding their technical implementation; and a supplier may understand the underlying model without understanding how the customer uses it. Effective governance must therefore connect these different forms of knowledge rather than assume that any single function possesses a complete understanding of the system.

11.2 Technical Opacity and Governance Explainability

Technical opacity presents another significant limitation. Some AI systems are difficult to interpret because their outputs emerge from complex interactions between data, model parameters and system components. Nevertheless, the governance challenge should not be reduced to the question of whether a model is technically explainable.

Different stakeholders require different forms of explanation. Users may require an understandable explanation of an output, while affected individuals may require information about how a decision affecting them was reached. Regulators and auditors may require evidence concerning the system's design, controls and operation, whereas developers may require detailed technical information about model behaviour. Senior management may instead need to understand why the system was deployed, what risks were accepted and whether those risks remain within the organisation's tolerance.

This distinction suggests a useful separation between model explainability and governance explainability. The latter concerns whether the organisation can explain why the system was deployed, what risks were identified, who authorised its use, which controls were considered necessary, what happened when those controls were triggered and why intervention or non-intervention was considered appropriate. This broader conception of explanation is consistent with the accountability literature, which treats answerability as extending beyond the internal mechanics of a technical system to the institutional processes through which decisions are authorised and reviewed (Novelli, Taddeo and Floridi, 2024).

Technical opacity also creates challenges for conventional audit. Traditional IT assurance may appropriately examine access controls, change management, configurations, security controls, logs and documented procedures. For AI systems, however, assurance may additionally need to consider training and validation data, model performance, subgroup performance, robustness, drift, evaluation methodologies, prompt or configuration changes, human oversight and the interaction between model outputs and organisational processes.

This does not mean that every internal auditor must become a machine-learning specialist. It does mean that assurance functions require access to appropriate multidisciplinary expertise, potentially combining audit, law, risk management, data science, cybersecurity, software engineering and AI expertise in proportion to the risk being assessed.

11.3 Dynamic Risk and Changing System Context

A further challenge is that AI-related risks are not necessarily static. Risk can change as a result of new data, changing data distributions, model updates, retraining, prompt or configuration changes, external API changes, user behaviour, adversarial activity, changes in the operating environment or changes in the purpose for which a system is used.

Consequently, a system that was appropriately governed at the time of deployment may not remain appropriately governed throughout its operational life. This is particularly important because AI systems can change not only through deliberate technical modifications but also through changes in the environment in which they operate.

Two forms of change are especially important. The first is model or data drift, in which the relationship between inputs and expected outcomes changes. A fraud-detection system, for example, may become less effective as patterns of fraudulent behaviour evolve. The second is context drift, where the organisation changes how the system is used. An AI system originally designed to assist employees may subsequently become embedded in an automated decision process. The underlying model may remain identical, while the consequences of its use become substantially more significant.

Governance triggers should therefore not depend exclusively on technical model changes. Changes in purpose, decision authority, affected populations or consequences may also require reassessment. This reinforces the lifecycle-oriented approach to risk management reflected in the EU AI Act for relevant high-risk systems (European Parliament and Council of the European Union, 2024).

Organisations consequently need clear criteria for determining when reassessment is required. Potential triggers include material model or data changes, deteriorating performance, incidents, new vulnerabilities, regulatory developments, changes in intended purpose, changes in user or affected populations, increases in autonomy and changes in third-party dependencies. Governance therefore needs to move from a point-in-time compliance model towards continuous governance.

11.4 Regulatory Uncertainty and Overlapping Obligations

Regulatory uncertainty presents a further limitation. Although the EU AI Act establishes a comprehensive legal framework, its practical implementation continues to interact with guidance, harmonised standards, codes of practice, delegated and implementing acts, supervisory practice and developing legal interpretation. Carey (2025) illustrates the uncertainty associated with aspects of the emerging AI regulatory environment.

This creates a tension between the need for organisations to make immediate decisions and the fact that regulatory interpretation may continue to develop. Organisations may therefore need to design controls before every aspect of implementation has become settled. A static compliance checklist is poorly suited to this environment because assumptions underlying the checklist may subsequently change.

A management-system approach provides a more resilient alternative because it creates processes for identifying regulatory developments, assessing their organisational impact, assigning responsibility, updating controls, communicating changes, testing implementation and retaining evidence. This is one of the advantages of integrating AI governance with the continual-improvement logic of ISO/IEC 42001 (ISO, 2023).

The challenge is further complicated by regulatory overlap. An AI-enabled process may simultaneously raise questions under AI regulation, data protection law, cybersecurity requirements, consumer protection, employment law, financial regulation, medical regulation, intellectual property law and sector-specific regimes. Organisations should therefore avoid treating these as completely separate compliance exercises. Instead, they should develop integrated control mapping so that common risks and controls can be addressed once and linked to the different legal and organisational requirements that apply.

11.5 Organisational Capability and Proportionality

Effective AI governance requires multidisciplinary capability. Relevant expertise may include AI and data science, software engineering, cybersecurity, legal and regulatory analysis, privacy, risk management, internal audit, organisational governance and business operations. Large organisations may be able to establish specialist functions covering these areas, whereas smaller organisations may have considerably fewer resources.

This creates a potential governance-capability gap. Organisations may face similar underlying governance expectations while possessing very different levels of expertise, staffing and technical infrastructure. Governance should therefore be proportionate to the organisation's circumstances as well as to the risks posed by the system.

Governance itself creates costs, including assessment time, documentation, specialist personnel, technical controls, monitoring, testing, audit and approval processes. If every AI-enabled tool is subjected to an identical level of governance, organisations may create substantial bureaucracy without achieving corresponding reductions in risk. A low-risk internal summarisation tool, for example, should not necessarily be subject to the same governance requirements as a system that determines eligibility for a consequential service.

The appropriate principle is therefore more governance where the consequences justify it, rather than more governance everywhere. This also has implications for innovation. Excessive approval requirements can encourage employees to circumvent formal processes rather than comply with them. Proportionate governance can instead provide development teams with predictable requirements concerning controls, evidence, approval and deployment.

11.6 Governance Can Become a Source of Risk

Governance is itself an organisational control and should therefore be assessed according to whether it produces meaningful risk reduction. Poorly designed governance can create excessive approval layers, duplicated controls, inconsistent requirements, decision paralysis and administrative burdens that divert resources from substantive risk reduction. Rigid governance processes may also become obsolete as technology and regulatory expectations change.

The relevant question should consequently be:

Does the control materially reduce the risk it is intended to address?

A control that produces substantial administrative costs while providing little additional risk reduction cannot necessarily be regarded as effective simply because it is formally documented.

This concern is particularly relevant to the possibility of compliance theatre. An organisation may establish an AI policy, committee, risk register, inventory and ethics statement while giving these structures little practical authority. Batool, Zowghi and Bano (2025) distinguish between different stages of organisational AI governance, including forms that remain largely symbolic rather than becoming operationally embedded.

The existence of governance structures should therefore not be treated as evidence of effective governance. A committee that cannot influence deployment, require remediation, reject a use case or escalate unacceptable risks has a fundamentally different governance role from one that possesses meaningful decision rights.

11.7 Fragmented Governance and System-Level Accountability

Governance can also become fragmented when different functions assume responsibility for different aspects of the same system. Legal may own compliance, security may own cybersecurity, data teams may own data quality, AI teams may own model risk, IT may own infrastructure and the business may own outcomes. Each allocation may appear reasonable in isolation, yet the organisation may still lack a clear owner for the system-level risk.

The answer is not necessarily to establish a single department responsible for every aspect of AI governance. Specialist functions should continue to provide expertise, control and challenge. However, there should also be a clearly identified system or business owner who remains accountable for the overall use case and its consequences.

This principle is particularly important where third parties are involved. Organisations increasingly depend on foundation-model providers, cloud infrastructure, APIs, data suppliers, software libraries and outsourced services. They may therefore be unable to inspect or independently validate every component on which an AI-enabled system depends.

This creates an assurance asymmetry, because the organisation may need evidence from a supplier that the supplier is unwilling or unable to provide in sufficient detail. Supplier governance must therefore include appropriate due diligence, contractual assurance, security requirements, change notification, incident reporting, evidence-access provisions and, where appropriate, exit or substitution strategies. Outsourcing technical capability does not necessarily transfer organisational accountability.

11.8 The Limits of Auditability

Auditability is itself subject to limitations. Comprehensive logging does not necessarily mean that an organisation can explain why a system behaved as it did. Large volumes of system events, application logs, model telemetry, user interactions and infrastructure records can create an evidence paradox in which more information does not necessarily produce greater understanding.

Effective auditability therefore depends on structured evidence, rather than simply extensive evidence. Evidence should be relevant, attributable, interpretable, sufficiently complete, appropriately retained and connected to the governance decision or event under investigation.

This reinforces a distinction developed throughout the wider governance framework: evidence should not be collected merely because it can be collected. It should be designed around the questions that the organisation may later need to answer. An audit trail is valuable when it enables the organisation to reconstruct material decisions, interventions, changes, incidents and control outcomes.

11.9 The Limits of Human Oversight and Automation Bias

Human oversight presents another practical limitation. A system may formally include a human reviewer while providing little meaningful human control. The reviewer may lack sufficient information, technical competence, time or authority to intervene. Organisational pressure to maintain throughput may further discourage intervention.

Human presence is therefore not equivalent to human control. The relevant question is not simply whether a person is involved, but whether that person can understand the relevant circumstances, identify when intervention is necessary and actually change the outcome.

This is particularly significant in relation to the EU AI Act's approach to human oversight, which requires oversight to be effective and appropriate to the circumstances rather than merely nominal (European Parliament and Council of the European Union, 2024).

Human oversight can also produce an apparent paradox. As automated systems become more capable and confident, human operators may become more inclined to accept their recommendations without independent assessment. This phenomenon, commonly described as automation bias, can result in nominal human oversight while effective decision authority shifts towards the system.

Organisations should therefore consider reviewer training, appropriate decision thresholds, escalation mechanisms, override monitoring, independent review and periodic testing of whether human oversight is actually functioning. The objective is meaningful human judgement rather than simple human confirmation.

11.10 Measurement and the Problem of Unknown Risks

Governance metrics can also create misleading impressions of precision. A statement that 99.5 per cent of governance controls were completed does not necessarily demonstrate that the organisation is well governed. The remaining 0.5 per cent could concern the organisation's most consequential AI system. Similarly, an overall model accuracy figure may conceal significant differences in performance across populations, use cases or operational conditions.

Governance metrics should therefore be interpreted within their context and linked to risk. Aggregate completion rates are useful indicators, but they should not replace substantive assessment of whether controls are effective and whether material risks remain within acceptable boundaries.

AI governance also faces a more fundamental epistemic limitation: organisations cannot always anticipate all risks before deployment. Users may employ systems in unintended ways, models may interact unexpectedly with other systems, attackers may discover new vulnerabilities and downstream users may become excessively dependent on system outputs. Some failure modes may only become visible through operational experience.

This means that governance cannot rely exclusively on ex ante risk assessment. Monitoring, incident reporting, feedback mechanisms and continual improvement are necessary because organisations must be capable of learning from events that could not reasonably have been anticipated in advance.

11.11 The Need for Proportionate, Adaptive and Accountable Governance

Taken together, these challenges suggest that effective AI governance should possess three fundamental characteristics: proportionality, adaptability and accountability.

Proportionality means that governance controls correspond to the magnitude and nature of the risk. Adaptability means that governance changes when technology, regulation, organisational use or risk changes. Accountability means that responsibility remains clearly assigned and supported by sufficient authority.

These characteristics are mutually reinforcing. Without proportionality, governance becomes unnecessarily bureaucratic. Without adaptability, governance becomes obsolete. Without accountability, governance risks becoming symbolic.

A practical approach is therefore to differentiate governance intensity according to factors such as the potential impact on individuals, financial consequences, system autonomy, scale, data sensitivity, reversibility of decisions, regulatory exposure, security criticality, third-party dependency and potential for systemic harm.

Lower-risk systems may require basic inventory, ownership and acceptable-use controls. Moderate-risk systems may justify structured risk assessment, testing, monitoring and documented approval. Higher-risk systems may require formal governance approval, independent validation, enhanced monitoring and defined intervention mechanisms. Systems presenting particularly significant consequences may additionally require executive oversight, stronger segregation of duties, continuous monitoring, independent assurance and tested suspension or rollback capability.

These categories should be understood as organisational design principles, not as substitutes for statutory classifications under the EU AI Act. Internal risk management and legal classification are related but distinct.

11.12 Governance and Innovation

Risk-proportionate governance can support innovation rather than simply restrict it. Development teams are more likely to work effectively within governance processes when they understand which controls are required, when review is necessary, what evidence must be produced, who makes decisions and what conditions permit deployment.

The objective should therefore not be to position governance and innovation as opposing objectives. Instead, governance should enable controlled innovation by becoming sufficiently integrated with development processes that governance requirements are treated as design inputs rather than last-minute deployment barriers.

This is particularly consistent with the management-system approach of ISO/IEC 42001. The value of a management system lies not in imposing a fixed set of controls on every system, but in creating an organisational mechanism through which risks can be identified, controls selected, performance evaluated and arrangements changed when circumstances require it (ISO, 2023).

11.13 The Central Trade-Off

The challenges described above ultimately create a trade-off between control, cost, speed and flexibility. Too little governance can increase exposure to uncontrolled risk. Excessive governance can increase cost, delay, bureaucracy, resistance, circumvention and constraints on innovation.

A mature governance architecture should therefore ask:

What is the minimum set of controls capable of providing reasonable assurance for this particular risk?

This is more defensible than asking how much documentation an organisation can produce. The purpose of governance is not to maximise paperwork but to create sufficient organisational capability to control material risks and demonstrate that appropriate decisions have been made.

11.14 Implications for ISO/IEC 42001 and the EU AI Act

The challenges identified in this chapter reinforce the value of the management-system approach represented by ISO/IEC 42001. A management system can accommodate changing risks, evolving objectives, performance monitoring, internal audit, management review, nonconformities, corrective action and continual improvement (ISO, 2023). Its principal value therefore lies less in providing a fixed catalogue of AI controls than in establishing an organisational mechanism through which controls can be selected, implemented, evaluated and changed.

The same considerations demonstrate why the EU AI Act should not be treated as a static checklist. The Act establishes specific legal requirements for relevant high-risk AI systems, including requirements relating to risk management, technical documentation, record-keeping, human oversight, quality management and post-market monitoring (European Parliament and Council of the European Union, 2024). However, organisations must determine how these obligations are translated into their own business processes, IT systems, data environments, development practices, supplier relationships and assurance activities.

The distinction is therefore important: the legal requirement and the organisational control are not the same thing. Law establishes obligations, while governance establishes the organisational capability through which those obligations can be implemented and demonstrated.

11.15 Governance Maturity

These challenges also support a maturity perspective. Organisations may begin with a reactive approach in which AI-related incidents are addressed as they arise. A more developed organisation may establish policies, inventories and basic responsibilities. At a further stage, risk assessments, approvals, controls and monitoring may operate systematically. More mature organisations integrate AI governance with enterprise risk management, cybersecurity, data governance, IT, procurement and internal audit. The most adaptive organisations establish mechanisms through which governance continuously responds to changes in technology, regulation, risk and organisational context.

This progression should not be interpreted as requiring every organisation to achieve the highest possible level of maturity. Governance should remain appropriate to the organisation's risk, scale, complexity and capability.

11.16 Fundamental Limitations

Ultimately, no governance framework can eliminate AI risk. Governance can identify risks, allocate responsibility, establish controls, monitor performance, provide intervention mechanisms, generate evidence and improve organisational responses. It cannot guarantee that every failure will be predicted, every model decision will be explainable, every supplier will behave as expected, every regulatory requirement will be unambiguous or every human decision-maker will exercise sound judgement.

The appropriate objective is therefore not zero risk, but controlled and accountable risk.

This distinction is fundamental. Governance should be understood as a mechanism for improving an organisation's capacity to make informed decisions, maintain appropriate control, respond to failure and demonstrate accountability in an environment characterised by uncertainty and change.

11.17 Conclusion

The implementation of AI governance is constrained by several interconnected organisational, technical and regulatory challenges. Distributed accountability makes it difficult to determine where responsibility resides across complex AI value chains. Technical opacity can limit the ability of conventional audit methods to understand system behaviour. Dynamic risk means that a system's governance requirements can change after deployment as models, data, users, purposes and operating environments evolve. Regulatory uncertainty requires organisations to maintain mechanisms for adapting controls as legal interpretation and technical expectations develop. Organisational capability can constrain the sophistication of governance that can realistically be implemented, particularly in smaller organisations. Finally, disproportionate governance can create bureaucracy, delay, circumvention and compliance theatre without producing equivalent reductions in risk.

These limitations lead to a more nuanced conception of effective AI governance. The objective is neither to construct an exhaustive bureaucracy around every AI system nor to establish policies and committees that lack operational authority. Rather, effective governance requires proportionate organisational capabilities that allocate authority and responsibility, establish controls, generate meaningful evidence, enable intervention and adapt as technology, risk and regulation change.

This perspective also clarifies the relationship between auditability and controllability developed throughout this work. Auditability without controllability may enable an organisation to reconstruct failures without possessing sufficient mechanisms to prevent or contain them. Controllability without auditability may provide mechanisms for intervention while leaving the organisation unable to demonstrate why decisions were made or whether controls operated appropriately.

The mature governance objective is therefore the combination of auditability, controllability, accountability, proportionality and adaptability. Together, these characteristics provide a basis for governing AI not as an isolated technical artefact, but as part of broader systems of automated decision-making, IT infrastructure, organisational processes and institutional authorit

controls, independently assure their effectiveness, and adapt the governance system as circumstances change.

This formulation brings together the principal arguments developed throughout the paper.

The EU AI Act provides the external legal obligations for relevant AI systems and uses. ISO/IEC 42001 provides a management-system architecture through which organisations can institutionalise AI governance. The accountability literature explains why governance requires answerability, authority and consequences. The control literature explains why accountability must be accompanied by meaningful capacity to intervene. The resulting organisational architecture provides the practical bridge between these theoretical, regulatory and managerial perspectives.

The ultimate objective is therefore not simply to demonstrate that an organisation has complied.

It is to establish an organisational system in which:

compliance can be demonstrated, risks can be controlled, decisions can be reconstructed, responsible actors can be held answerable, and governance can adapt as AI systems and their environments evolve.

That is the practical meaning of making AI auditable, controllable and compliant.

12. A Practical Governance Model

The preceding analysis can be translated into a practical organisational model based on seven interconnected capabilities: identify, assign, assess, control, evidence, assure and improve. These capabilities should not be treated as a linear compliance checklist. Rather, they form a continuous governance cycle through which an organisation establishes visibility over its AI and automated systems, allocates responsibility and authority, evaluates risks, implements appropriate controls, generates evidence, tests whether those controls are effective and learns from operational experience.

The distinction is important because the individual components of governance are mutually dependent. An inventory without ownership does not establish accountability; ownership without risk assessment may lead to inappropriate decisions; risk assessment without controls does not reduce exposure; controls without evidence are difficult to demonstrate; evidence without assurance does not establish effectiveness; and assurance without improvement risks becoming a purely administrative activity. Effective governance therefore depends on the interaction between these capabilities rather than on the existence of any single policy, committee or control.

The model can consequently be expressed as:

Identify → Assign → Assess → Control → Evidence → Assure → Improve → Reassess

The final stage connects the governance cycle back to identification and assessment because AI governance must respond to changes in technology, organisational purpose, risk, suppliers, operating environments and regulatory requirements. This cyclical orientation is consistent with the management-system approach reflected in ISO/IEC 42001 (ISO, 2023) and with the lifecycle-oriented approach to risk management established for relevant high-risk AI systems under the EU AI Act (European Parliament and Council of the European Union, 2024).

12.1 Identify: Establishing Organisational Visibility

The first capability is identification. An organisation cannot effectively govern systems that it does not know exist. This presents a significant challenge in large organisations, where AI and automation may enter the organisation through formal technology programmes, procurement processes, software development, business-unit experimentation or functionality embedded within existing enterprise applications.

Organisations should therefore establish and maintain an inventory of consequential AI systems and automated processes. The scope of the inventory should be proportionate to organisational risk, but should normally capture information such as the system's purpose, business and technical owners, users, affected populations, data dependencies, model or technology providers, deployment environment, regulatory status, internal risk classification, lifecycle status and significant third-party dependencies.

The inventory should not be understood as merely an administrative register. Its primary purpose is to establish the governance population against which risk assessments, controls, monitoring and assurance activities can be applied. In this respect, visibility is the foundation upon which subsequent governance capabilities depend.

12.1.1 Identification Should Extend Beyond AI

A significant implication of this approach is that governance should not depend exclusively on whether a technology is formally described as "AI". Consequential automated processes may create material organisational risks even where they are based on conventional rules, statistical techniques or established IT functionality.

For example, an AI model, an automated credit decision process, an automated fraud-detection system, a rules-based access-control mechanism and an AI-enabled customer-service platform may all warrant inclusion in an organisational governance inventory where their consequences, autonomy or organisational significance justify it.

This approach avoids creating a governance gap in which consequential automation escapes oversight simply because it is classified as conventional IT rather than AI. The relevant question is therefore not merely what technology is being used, but what the technology does, what authority it exercises and what consequences may result from its operation.

12.1.2 The Inventory as a Governance Control Plane

The inventory can also become the foundation of an organisational governance control plane. Each system record should, where appropriate, connect the system with its owner, purpose, risk profile, applicable requirements, controls, evidence and assurance activities.

Such relationships allow the organisation to respond more effectively when circumstances change. For example, if a regulatory requirement changes, the organisation should be able to determine which systems are affected, which owners are responsible, which controls require review, what evidence already exists and where additional assurance is required.

The value of the inventory therefore lies not simply in knowing what systems exist, but in establishing relationships between systems, responsibilities, risks, controls and evidence.

12.2 Assign: Establishing Authority and Accountability

The second capability is assignment. Every material system should have clearly defined responsibility for its business purpose, technical operation, risk management, compliance, data, security, monitoring and lifecycle decisions. This does not mean that one person must perform all of these functions. Rather, the organisation must establish a clear allocation of responsibilities between the accountable owner and the specialist functions responsible for individual controls.

The business owner would normally retain accountability for the purpose, outcomes and operational consequences of the system. A model or AI owner may be responsible for technical performance and model lifecycle management, while a data owner may oversee data quality, provenance and permitted use. Security functions may remain responsible for cybersecurity and access, risk and compliance functions may provide regulatory challenge, and IT or platform teams may manage infrastructure and resilience. Where human oversight is required, an appropriately authorised operational role must also be established. Internal audit or another independent assurance function should remain sufficiently separate from system operation to evaluate governance objectively.

This arrangement reinforces an important principle: AI governance is not exclusively a technical responsibility. It is an organisational responsibility distributed across business, technology, risk, legal, data, security and assurance functions.

12.2.1 Authority Must Accompany Accountability

Responsibility is meaningful only when it is accompanied by sufficient authority. A person who is formally accountable for a system but lacks the ability to suspend deployment, require remediation, reject material changes, obtain relevant information or escalate concerns does not possess meaningful control.

This reflects the relationship between control and accountability identified by Grote, Parker and Crowston (2024). Accountability should therefore be accompanied by clearly defined decision rights. Organisations should establish who can approve a new use case, reject a deployment, accept residual risk, approve material changes, suspend a system, restore a system following an incident, grant an exception and initiate escalation.

This converts abstract responsibility into operational authority.

12.2.2 Governance Committees Need Decision Rights

The same principle applies to governance committees. Committees can provide valuable coordination and challenge, but their existence alone does not constitute effective governance. A committee that can advise but cannot require additional testing, impose conditions, reject unacceptable risk, mandate remediation or escalate matters to executive management may provide visibility without exercising substantive control.

The appropriate authority will depend upon organisational circumstances and system risk. However, higher-risk systems generally require stronger approval, escalation and intervention mechanisms. This distinction is consistent with research identifying different stages of organisational AI governance, from symbolic arrangements to more operationally embedded governance structures (Batool, Zowghi and Bano, 2025).

12.3 Assess: Understanding and Managing Risk

The third capability is assessment. Risk assessment should occur before deployment and continue throughout the operational lifecycle of the system. It should consider more than technical model performance and should incorporate the broader organisational context in which the technology operates.

Relevant considerations may include technical and operational risks, cybersecurity, privacy, legal and regulatory exposure, discrimination and fairness, fundamental rights, safety, reputational consequences, third-party dependencies, business continuity and, where appropriate, broader societal or systemic impacts.

This reflects the multidisciplinary character of contemporary AI governance. The risks associated with AI cannot necessarily be understood by technical assessment alone.

12.3.1 Assessment Should Be Contextual

The same underlying technology may present very different governance risks depending on how it is used. A generative-AI model used for internal brainstorming, for example, presents a substantially different risk profile from the same technology embedded in a system that influences decisions affecting individuals.

Risk should therefore be understood as a characteristic of the technology-in-context, rather than of the technology in isolation. Assessment should consider the interaction between the technology, its purpose, users, affected individuals, level of autonomy, consequences and operating environment.

This contextual approach also helps prevent governance from becoming overly model-centric.

12.3.2 Regulatory Classification Is Only One Dimension

Legal classification is an important component of assessment, but it should not necessarily determine the entirety of an organisation's internal risk assessment. A system may fall outside a particular regulatory category while nevertheless presenting material cybersecurity, operational, reputational, financial or data-related risks.

Internal governance should therefore distinguish between legal compliance and enterprise risk management. Legal requirements establish minimum obligations where applicable, while organisational risk management should consider the wider consequences of operating the system.

12.3.3 Continuous Assessment

Assessment should also be repeated when material circumstances change. Relevant triggers may include significant model updates, changes in input or training data, new users or jurisdictions, changes in intended purpose, increased autonomy, deterioration in performance, security incidents, regulatory developments or significant changes to suppliers.

This lifecycle perspective is particularly consistent with the risk-management approach applicable to relevant high-risk AI systems under the EU AI Act (European Parliament and Council of the European Union, 2024).

12.4 Control: Embedding Governance in Technology and Processes

The fourth capability is control. Controls translate governance requirements and risk assessments into mechanisms capable of influencing system behaviour.

The distinction between a requirement and a control is important. A policy may state that human oversight must be effective. An operational control might require specified decisions to be reviewed and approved by an authorised and appropriately trained person before they can be finalised. The latter creates a mechanism capable of influencing behaviour.

Controls may therefore include access restrictions, segregation of duties, approval workflows, model validation, testing, deployment gates, human intervention, automated policy enforcement, monitoring, threshold-based alerts, change management, rollback, suspension, incident response, data controls and supplier controls.

12.4.1 Preventive, Detective and Corrective Controls

Controls can usefully be understood as preventive, detective and corrective.

Preventive controls seek to stop undesirable activities before they occur. Examples include deployment approval, access restrictions, segregation of duties and prohibited-use rules.

Detective controls seek to identify undesirable behaviour or deteriorating performance. Examples include monitoring, anomaly detection, audit logging, performance thresholds and incident alerts.

Corrective controls provide mechanisms for responding when undesirable outcomes occur. Examples include rollback, suspension, remediation, incident response, retraining and corrective action.

A mature governance architecture should generally combine all three. Prevention reduces the probability of failure, detection improves the ability to identify emerging problems, and correction limits the consequences when failures occur.

12.5 Evidence: Making Governance Demonstrable

The fifth capability is evidence. Governance should produce reliable evidence that decisions have been made, responsibilities exercised and controls operated.

Relevant evidence may include system inventories, risk assessments, approval records, model documentation, data-provenance information, validation results, training records, access logs, system logs, human-oversight records, monitoring results, incident records, change approvals, exception records, audit reports and corrective-action documentation.

The underlying principle is that evidence should be generated as part of normal governance activity, rather than reconstructed retrospectively when an audit or regulatory review takes place.

12.5.1 Evidence Should Be Traceable

Evidence becomes particularly valuable when it can be connected to the requirement and control that generated it. A useful conceptual chain is:

Requirement → Control → Owner → Activity → Evidence → Test

For example, a requirement for human oversight may be translated into a control requiring an authorised reviewer to approve specified decisions. The business process owner becomes responsible for that control, the review constitutes the relevant activity, the review record provides evidence and sampling of those records provides a basis for testing whether the control operated.

This creates an evidence chain of accountability.

Such traceability is important because auditability depends not simply on possessing records, but on being able to demonstrate the relationship between requirements, decisions, controls and outcomes.

12.5.2 Evidence Should Support Management

Governance evidence should not exist solely for auditors or regulators. It should also support management decision-making by providing information about control effectiveness, open risks, unresolved incidents, system changes, exceptions, deteriorating performance, supplier dependencies and emerging governance weaknesses.

In this way, evidence becomes a management resource rather than merely a compliance artefact.

12.6 Assure and Improve: Testing the Governance System

The sixth and seventh capabilities are assurance and continual improvement. Controls cannot be assumed to be effective simply because they have been designed or documented. Organisations need mechanisms to determine whether controls operate, whether they operate as intended, whether they remain appropriate and whether corrective actions have actually addressed identified weaknesses.

Assurance can involve internal audit, management review, compliance monitoring, technical validation, control testing and other forms of independent or specialist assessment. The appropriate combination should reflect the risk and complexity of the system.

12.6.1 Three Lines of Governance

The governance model can be aligned conceptually with the three-lines approach.

The first line consists of operational management, which owns and operates systems and controls. The second line consists of risk, compliance and specialist functions, which provide policy, monitoring, challenge and expertise. The third line, typically internal audit, provides independent assurance concerning the effectiveness of governance and controls.

This separation can reduce conflicts of interest because those responsible for developing or operating a system are not necessarily the only people determining whether its governance is effective.

12.6.2 Management Review

Management review is particularly important because AI governance ultimately represents an organisational responsibility. Senior management should receive information concerning material AI risks, regulatory developments, significant incidents, control failures, open exceptions, performance concerns, high-risk deployments, supplier issues and remediation progress.

This allows AI governance to become integrated into organisational decision-making rather than remaining a specialist compliance activity operating at the periphery of management.

The management-system orientation of ISO/IEC 42001 is particularly relevant because it incorporates evaluation and continual improvement into the organisational governance process (ISO, 2023).

12.7 Continual Improvement

The final component of the governance cycle is improvement. Governance findings should not terminate in audit reports or incident investigations. Instead, they should feed back into policies, controls, training, system architecture, development practices, risk assessments, supplier requirements and governance structures.

A significant incident, for example, should lead to investigation and root-cause analysis. If the investigation identifies a control weakness, corrective action should follow. The revised control should then be tested for effectiveness, with the resulting learning incorporated into the wider governance process.

This creates a continuous organisational learning loop:

Incident → investigation → root-cause analysis → control improvement → effectiveness testing → governance update → reassessment

The importance of this cycle is consistent with the continual-improvement logic of ISO/IEC 42001 (ISO, 2023).

12.8 The Governance Cycle

The complete practical model can therefore be understood as a continuous cycle:

Identify → Assign → Assess → Control → Evidence → Assure → Improve → Reassess

Identification establishes visibility over relevant systems and processes. Assignment establishes accountability and decision rights. Assessment determines the risks and requirements associated with the system. Control converts those risks and requirements into operational mechanisms. Evidence makes governance demonstrable. Assurance tests whether the controls work. Improvement addresses weaknesses and incorporates organisational learning. Reassessment then determines whether the system remains appropriately governed as circumstances change.

The cyclical structure is significant because governance should not terminate when a system is deployed. Nor should assurance represent the end of governance activity. Instead, assurance generates learning, learning changes controls, and changed controls require renewed assessment.

12.9 Relationship with ISO/IEC 42001

The seven capabilities are conceptually compatible with the management-system logic of ISO/IEC 42001 (ISO, 2023). Identification corresponds broadly with establishing organisational scope, context and visibility over AI systems. Assignment relates to defining roles, responsibilities and authority. Assessment corresponds to the identification and evaluation of AI-related risks and impacts. Control involves establishing operational processes and controls. Evidence relates to documented information and operational records. Assurance encompasses monitoring, measurement, internal audit and management review. Improvement corresponds to corrective action and continual improvement.

This mapping should not be interpreted as suggesting that the seven capabilities reproduce ISO/IEC 42001 clause by clause. Rather, it demonstrates how the standard's management-system philosophy can provide an institutional mechanism through which AI governance becomes embedded within organisational processes.

The value of a management-system approach lies precisely in its ability to institutionalise governance rather than reduce AI compliance to a collection of isolated technical controls.

12.10 Relationship with the EU AI Act

The same model can be used to interpret how legal obligations under the EU AI Act may be translated into organisational capabilities. Identification can support the determination of relevant systems, roles and regulatory status. Assignment can support the allocation of provider and deployer responsibilities and the establishment of appropriate human oversight. Assessment can support risk management and the evaluation of relevant impacts. Control can encompass risk controls, data governance, human oversight and quality-management measures. Evidence can encompass technical documentation, records, logs and monitoring information. Assurance can support compliance monitoring and evaluation, while improvement can support corrective action, post-market monitoring and lifecycle reassessment.

This should be understood as an analytical mapping, rather than a claim that the seven capabilities are themselves statutory requirements. The significance of the model is that it demonstrates how legal obligations can be translated into organisational capabilities and operational processes.

This distinction is important because law establishes obligations, whereas governance establishes the organisational capability to meet, manage and demonstrate compliance with those obligations.

12.11 Governance as a Control Architecture

The seven capabilities can also be understood as stages in a broader organisational control architecture.

Visibility asks what must be governed and establishes the relevant population of systems and processes.

Authority establishes who is responsible and who possesses decision rights.

Risk determines what could go wrong and what consequences may arise.

Control establishes mechanisms to prevent, detect or correct undesirable outcomes.

Evidence establishes what demonstrates that governance and controls operated.

Assurance determines whether those controls are effective.

Improvement determines what should change in response to experience.

This provides a more rigorous interpretation of the proposition that organisations should make AI systems, automated processes and IT platforms auditable, controllable and compliant.

12.12 Connecting Auditability and Controllability

The model also clarifies the relationship between auditability and controllability.

Auditability is principally supported by identification, assignment, evidence and assurance. These capabilities establish visibility, accountability, traceability and the ability to evaluate governance decisions.

Controllability is principally supported by assignment, assessment, control and improvement. These capabilities establish authority, risk-based intervention and the capacity to change the system or its operating conditions.

The two dimensions converge through evidence and assurance. An organisation that can reconstruct decisions but cannot intervene effectively possesses auditability without sufficient controllability. Conversely, an organisation that can intervene but cannot demonstrate why decisions were taken or whether controls operated effectively possesses controllability without sufficient auditability.

The relationship can therefore be expressed conceptually as:

Auditability = visibility + traceability + evidence + assurance

Controllability = authority + intervention + monitoring + adaptation

Governance = auditability + controllability + accountability

These formulations provide a concise theoretical expression of the central argument developed throughout the paper.

12.13 Practical Application

The model can be illustrated through an organisation deploying an AI system to support customer fraud detection.

The identification stage would place the system within the organisation's AI and automation inventory and record its business and technical ownership, data sources, model provider, purpose, deployment environment and relevant regulatory considerations.

The assignment stage would allocate accountability to the business owner while assigning specialist control responsibilities to security, data, compliance and technical functions.

During assessment, the organisation would consider financial and customer impacts, privacy, cybersecurity, model performance, false positives, human oversight and third-party dependencies.

The control environment might include access management, model validation, performance thresholds, human review, escalation procedures, change management and incident response.

The system would generate evidence through records of model versions, approvals, decisions, human reviews, alerts, overrides, incidents and changes.

During assurance, internal audit or another independent assurance function could sample cases to determine whether required reviews occurred, whether thresholds operated appropriately, whether evidence was complete and whether the model remained within approved parameters.

Finally, if the organisation observed a significant increase in false-positive results, the improvement process could initiate investigation, reassessment, model adjustment, renewed validation and governance approval.

The important point is that the model transforms governance from a compliance checklist into an operational control system.

12.14 Governance by Design

The practical model also supports the principle of governance by design. Governance requirements should be considered when systems are designed rather than after deployment.

If an organisation knows that it will need to demonstrate human oversight, maintain model-version histories, document approvals, record interventions, monitor performance and manage incidents, these requirements should influence system architecture from the outset.

The preferred lifecycle is therefore:

Governance requirements → system design → technical controls → operational evidence

rather than:

System development → deployment → retrospective compliance documentation

The first approach is more likely to produce durable governance because control mechanisms become embedded within the technology and associated business processes.

12.15 Governance as an Organisational Capability

The seven-capability model ultimately suggests that AI governance should be understood as an organisational capability rather than a department.

The capability exists when an organisation can consistently discover consequential AI and automation, assign meaningful accountability, evaluate risks, implement proportionate controls, generate reliable evidence, independently evaluate effectiveness and adapt when circumstances change.

Different organisations may distribute these capabilities in different ways. A large multinational organisation might establish a dedicated AI governance office, AI risk committee and specialist assurance team. A smaller organisation might integrate the same capabilities into existing risk, IT, security, compliance, data and audit functions.

The organisational structure may therefore vary considerably while the underlying governance capabilities remain substantially similar.

This distinction is important because it avoids assuming that effective AI governance requires a particular organisational design. What matters is whether the necessary capabilities exist and whether they possess sufficient authority, expertise and independence.

12.16 Proportionality Within the Model

The seven capabilities should not imply identical governance requirements for every system. The appropriate intensity of governance should depend upon factors such as potential impact, autonomy, data sensitivity, regulatory exposure, operational criticality, affected populations and the reversibility of decisions.

A relatively low-risk AI tool might require basic inventory, ownership, acceptable-use controls and proportionate monitoring. A high-impact system may require formal classification, comprehensive risk assessment, independent validation, enhanced human oversight, extensive evidence, continuous monitoring and independent assurance.

The model therefore defines governance capabilities rather than a universal control catalogue.

This distinction is essential because it allows the architecture to accommodate the proportionality concerns identified in Chapter 11. Governance should be sufficiently rigorous to manage the relevant risks without creating unnecessary bureaucracy.

12.17 The Governance Maturity Path

The model can also provide a practical maturity pathway. An organisation may initially focus on visibility, ensuring that it knows what AI and consequential automation it operates. The next stage is accountability, in which systems have identified owners and defined decision rights. The third stage is risk control, where risks are systematically assessed and controls implemented. The fourth stage is evidence, where governance activities generate reliable and traceable records. The fifth stage is assurance, where controls are independently evaluated. The final stage is adaptation, where governance continuously learns from operational experience and responds to technological, regulatory and organisational change.

This progression provides organisations with a practical development path without requiring them to implement the entire governance architecture simultaneously.

Importantly, maturity should not be treated as an end in itself. The appropriate level of governance depends upon the organisation's risk profile, scale, complexity, regulatory environment and available capabilities.

12.18 The Model's Theoretical Contribution

The seven-capability framework provides a conceptual bridge between several strands of the existing literature.

The accountability literature demonstrates that responsibility involves answerability and identifiable actors capable of being held to applicable standards (Novelli, Taddeo and Floridi, 2024). The literature on control and accountability further demonstrates that responsibility should be accompanied by meaningful authority and control (Grote, Parker and Crowston, 2024). Research on AI governance highlights the multilevel and distributed nature of governance across organisational and institutional settings (Batool, Zowghi and Bano, 2025).

ISO/IEC 42001 provides a management-system mechanism through which organisations can institutionalise policies, risk management, monitoring, assurance and continual improvement (ISO, 2023). The EU AI Act provides legally binding requirements for specified AI systems and uses, including requirements relating to risk management, documentation, record-keeping, human oversight and monitoring (European Parliament and Council of the European Union, 2024).

The practical model synthesises these perspectives into an organisational control cycle:

Identify → Assign → Assess → Control → Evidence → Assure → Improve

Its contribution is therefore not to propose another isolated AI governance framework. Rather, it demonstrates how existing concepts concerning accountability, risk, management systems and regulation can be translated into a practical organisational architecture.

12.19 Conclusion

The proposition that organisations should design and implement governance structures that make AI systems, automated processes and IT platforms auditable, controllable and compliant can be operationalised through seven interconnected capabilities: identify, assign, assess, control, evidence, assure and improve.

Identification establishes organisational visibility. Assignment establishes accountability and decision rights. Assessment establishes an understanding of risk and applicable requirements. Control converts those requirements into operational mechanisms. Evidence makes governance demonstrable. Assurance tests whether governance and controls operate effectively. Improvement ensures that governance adapts to operational experience, technological change and regulatory development.

The model therefore moves beyond a conventional conception of compliance as a point-in-time assessment. It represents governance as a continuous organisational control cycle in which visibility, authority, risk assessment, control, evidence and assurance reinforce one another.

Its central proposition can be stated as follows:

AI governance is effective when an organisation can identify the systems it operates, assign meaningful authority and accountability, assess the risks they create, implement proportionate controls, continuously generate evidence of those controls, independently evaluate their effectiveness and adapt governance as circumstances change.

This formulation also reinforces the broader argument of the paper. AI governance should not be understood as a separate technical discipline concerned only with models. It is an organisational capability that connects technology, business processes, risk management, regulatory compliance, internal control and assurance.

The ultimate objective is therefore not simply to make AI systems compliant at a particular point in time. It is to create an organisational environment in which AI-enabled systems remain visible, accountable, controllable, auditable and adaptable throughout their lifecycle.

13. Conclusion

The increasing integration of AI and automated processes into organisational decision-making requires a reconsideration of what it means for an organisation to be “compliant”. A narrow compliance model, centred upon policies, documentation and point-in-time assessments, is poorly suited to technologies whose behaviour, data, operating environments, suppliers and purposes can change throughout their lifecycle. The central argument of this paper has therefore been that AI governance should be understood not simply as a compliance activity, but as an organisational control architecture.

This perspective changes the question from:

Does the organisation have an AI policy?

to:

Can the organisation demonstrate who is responsible for an AI system, who has authority over it, what risks have been identified, which controls operate, what evidence those controls generate, how their effectiveness is assured, and how the organisation responds when circumstances change?

The distinction between auditability and controllability is particularly important. Auditability provides the capacity to reconstruct and evaluate decisions, system operation and governance processes. Controllability provides the capacity to intervene, constrain, modify or suspend system behaviour. An organisation possessing only the former may be capable of explaining a failure without being capable of preventing or containing it. An organisation possessing only the latter may be capable of intervention without being able to demonstrate why decisions were made or whether controls operated appropriately. Effective governance therefore requires both.

The analysis has also demonstrated that accountability cannot be separated from authority. As the accountability literature emphasises, responsibility involves answerability to relevant forums against applicable standards and processes (Novelli, Taddeo and Floridi, 2024). Similarly, the relationship between control and accountability becomes increasingly important as automated systems acquire greater decision-making capacity (Grote, Parker and Crowston, 2024). Assigning responsibility to individuals or committees that lack sufficient information, resources or authority to intervene creates nominal rather than substantive accountability.

The paper consequently proposes a practical governance cycle:

Identify → Assign → Assess → Control → Evidence → Assure → Improve

Each capability addresses a different organisational requirement.

Identify establishes visibility over AI systems, automated processes and relevant technological dependencies. Without visibility, governance cannot establish its scope.

Assign establishes ownership, accountability and decision rights. Responsibility must be accompanied by sufficient authority to approve, restrict, remediate or suspend systems where necessary.

Assess establishes an understanding of technical, operational, legal, cybersecurity, privacy, fundamental-rights and other relevant risks. Importantly, risk should be assessed in the context in which technology is deployed rather than inferred solely from the characteristics of the underlying model.

Control translates risk assessments into preventive, detective and corrective mechanisms. These include access controls, validation, monitoring, human oversight, change management, incident response and intervention capabilities.

Evidence transforms governance from an assertion into something demonstrable. Risk assessments, approvals, logs, testing records, monitoring results, human-oversight records and corrective actions provide the evidentiary basis through which an organisation can demonstrate that governance processes have actually operated.

Assure provides independent or appropriately objective evaluation of whether controls are effective. Internal audit, compliance monitoring, management review and technical assurance can provide different but complementary forms of challenge.

Finally, improve establishes the feedback mechanism through which incidents, audit findings, regulatory developments, technological changes and operational experience modify governance arrangements.

The significance of the model is that these capabilities are interdependent rather than sequential compliance tasks. An inventory without ownership creates visibility but not accountability. An assessment without controls identifies risk without reducing it. Controls without evidence may operate but cannot readily be demonstrated. Evidence without assurance does not establish effectiveness. Assurance without improvement can become a retrospective administrative exercise. The governance cycle therefore closes by feeding assurance and learning back into renewed identification and assessment.

The relationship between the EU AI Act and ISO/IEC 42001 is particularly important in this context. The EU AI Act represents binding law, establishing obligations for specified AI systems and uses according to the regulatory framework's risk-based approach (European Parliament and Council of the European Union, 2024). ISO/IEC 42001, by contrast, provides a management-system framework for establishing, operating, reviewing and continually improving organisational arrangements for AI (ISO, 2023). They should therefore not be treated as interchangeable.

Rather, they perform complementary functions:

The EU AI Act establishes what the organisation is legally required to achieve; ISO/IEC 42001 provides a management-system structure through which the organisation can systematically organise, operate and improve its AI governance capabilities.

This distinction is particularly valuable in a regulatory environment characterised by continuing development in standards, guidance, supervisory expectations and technical practice. A static compliance checklist is vulnerable to becoming obsolete. A management-system approach can instead provide the organisational infrastructure through which new requirements can be identified, interpreted, allocated and incorporated into existing controls.

The analysis also demonstrates why AI governance should not be isolated within an IT or data-science function. AI systems frequently depend upon conventional IT infrastructure, cloud services, APIs, cybersecurity controls, data platforms and external suppliers. Moreover, consequential automated processes may exist without sophisticated machine-learning components. Governance should therefore focus on risk, consequence and organisational authority, rather than relying exclusively upon technological labels.

At the same time, governance must remain proportionate. Excessive controls can produce bureaucracy, delay and governance circumvention without generating equivalent reductions in risk. Effective governance therefore requires differentiation according to factors such as impact, autonomy, scale, affected populations, regulatory exposure, reversibility and organisational criticality. The objective is not maximum documentation or maximum oversight, but an appropriate level of control for the risks presented.

This leads to a broader conceptual proposition:

AI governance should be understood as the organisational capability to make consequential technological systems visible, accountable, controllable, evidentiary and continuously improvable.

Such a capability moves the organisation beyond “AI compliance” towards institutionalised governance.

The contribution of this paper is consequently threefold. First, it reframes AI governance from a predominantly policy and compliance problem into a problem of organisational control and accountability. Second, it connects the accountability and control literature with the management-system approach of ISO/IEC 42001 and the legally binding requirements of the EU AI Act. Third, it translates these perspectives into a practical governance architecture comprising identify, assign, assess, control, evidence, assure and improve.

The model does not eliminate the fundamental uncertainties associated with AI. It cannot guarantee that every failure will be anticipated, that every model decision will be explainable, or that every emerging regulatory question will be immediately resolved. Its purpose is more practical: to ensure that when risks arise, the organisation has identifiable responsibilities, meaningful decision rights, operational controls, reliable evidence, mechanisms for intervention and processes for learning.

The ultimate objective is therefore not simply to demonstrate that an organisation has complied.

It is to establish an organisational system in which:

compliance can be demonstrated, risks can be controlled, decisions can be reconstructed, responsible actors can be held answerable, and governance can adapt as AI systems and their environments evolve.

In this sense, making AI systems, automated processes and IT platforms auditable, controllable and compliant is not primarily a documentation exercise. It is a question of organisational design: creating the authority, capabilities, controls and assurance mechanisms necessary to keep increasingly autonomous technologies within accountable systems of human and institutional governance.

References

Batool, A., Zowghi, D. and Bano, M. (2025) ‘AI governance: a systematic literature review’, AI and Ethics, 5, pp. 3265–3279.

Biroğul, S., Şahin, Ö. and əsgərli, H. (2025) ‘Exploring the impact of ISO/IEC 42001:2023 AI management standard on organizational practices’, Advances in Artificial Intelligence Research, 5(1).

Buscemi, A., Deckenbrunnen, T., Kabir, F., Mowla, N. and Mishchenko, K. (2025) ‘Assessing high-risk systems: an EU AI Act verification framework’. arXiv.

Carey, S. (2025) ‘Regulating uncertainty: governing general-purpose AI models and systemic risk’, European Journal of Risk Regulation.

Camilleri, M.A. (2024) ‘Artificial intelligence governance: ethical considerations and implications for social responsibility’, Expert Systems.

European Parliament and Council of the European Union (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.

Grote, G., Parker, S.K. and Crowston, K. (2024) ‘Taming artificial intelligence: a theory of control-accountability alignment among AI developers and users’, Academy of Management Review.

International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) (2023) ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO.

Manganello, F., Nico, A., Ragusa, M. and Boccuzzi, G. (2025) ‘Testing the applicability of a governance checklist for high-risk AI-based learning outcome assessment in Italian universities under the EU AI Act Annex III’, Frontiers in Artificial Intelligence, 8.

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.

Rêgo de Almeida, P.G. and dos Santos Júnior, C.D. (2025) ‘Artificial intelligence governance: understanding how public organizations implement it’, Government Information Quarterly, 42(1), 102003.

‘Enabling affordances for AI governance’ (2024) Journal of Responsible Technology, 18, 100086.

Contact

Reach out via email for inquiries.

Email

Subscribe to newsletter

info@grcadvisory.ch

© 2025. All rights reserved.