AI By Design in Cybersecurity

Abstract

The rapid adoption of large language models (LLMs) is transforming cybersecurity operations by enabling new forms of information processing, decision support, knowledge retrieval, and workflow automation. Security organizations, however, face a fundamental tension: the data that makes LLMs valuable for cybersecurity—including security logs, incident information, vulnerability data, network telemetry, source code, and customer-specific configurations—is often highly sensitive and subject to stringent security, privacy, sovereignty, and regulatory requirements. This raises the question of how AI should be architected when the data processed by AI is itself security-critical.

This paper investigates how dedicated, organization-controlled AI infrastructure can contribute to data sovereignty, cybersecurity, and trustworthy governance of LLM-based security services. Based on a structured synthesis of recent peer-reviewed research on LLMs in cybersecurity, AI governance, privacy, security, and data sovereignty, the paper develops a conceptual framework for AI by Design. The framework extends the principles of Privacy by Design and Security by Design by treating infrastructure sovereignty, data governance, model governance, security engineering, human oversight, auditability, and accountability as interdependent architectural requirements.

The analysis shows that dedicated AI infrastructure can provide greater organizational control over sensitive data flows, model execution, access management, processing locations, logging, and external dependencies. This can be particularly relevant for cybersecurity providers operating security-critical workloads and regulated customer environments. However, the analysis also demonstrates that on-premises deployment does not inherently establish security, sovereignty, or regulatory compliance. Infrastructure ownership transfers significant responsibilities to the organization, while modern AI remains dependent on global hardware, software, model, and knowledge ecosystems. Sovereignty is therefore conceptualized not as technological independence but as controlled interdependence and demonstrable organizational control over critical AI processes.

The paper further proposes a conceptual five-level AI-by-Design maturity model ranging from external AI consumption to AI-native cybersecurity operations, and develops an empirical evaluation framework covering sovereignty, security, operational efficiency, response performance, quality, governance, cost, energy consumption, human factors, and customer trust. The paper argues that AI adoption should ultimately be evaluated at the use-case and workflow level, rather than through model accuracy alone.

The central contribution is a conceptualization of sovereign AI as a trust and control architecture rather than a hosting model. Dedicated infrastructure can provide an important foundation for trustworthy AI-enabled cybersecurity, but its strategic value emerges only when infrastructure control is combined with appropriate governance, security engineering, validated automation, human oversight, and continuous evaluation.

Keywords: artificial intelligence; large language models; cybersecurity; security operations centers; AI governance; data sovereignty; sovereign AI; AI by Design; trustworthy AI; cybersecurity automation; on-premises AI; data protection

1. Introduction

Generative artificial intelligence (GenAI), and particularly large language models (LLMs), is evolving from an experimental technology into an emerging component of enterprise information and cybersecurity infrastructures. Unlike conventional machine-learning systems that are typically optimized for narrowly defined classification or prediction tasks, LLMs can process and generate natural language, synthesize heterogeneous information, support knowledge retrieval, produce and interpret code, and interact with users through flexible natural-language interfaces. These capabilities make LLMs particularly relevant to cybersecurity, where analysts must continuously interpret large volumes of heterogeneous, incomplete, and time-sensitive information across logs, alerts, threat intelligence, vulnerability data, tickets, documentation, and incident artefacts.

The research literature increasingly confirms this shift. Hasanov et al. (2024), in a systematic review of 177 publications, demonstrate the breadth of emerging LLM applications across cybersecurity, encompassing defensive and offensive security, security software development, administrative activities, cyberethics, and governance. Their review further shows that defensive cybersecurity has become one of the principal research directions in the field, indicating a transition from conceptual experimentation toward operational security applications. More specifically, Habibzadeh, Feyzi, and Ebrahimi Atani (2026) synthesize 216 studies on the integration of LLMs into Security Operations Centers (SOCs) and provide a structured mapping of LLM applications to the NIST Cybersecurity Framework and the MITRE ATT&CK knowledge base. Their findings position LLMs as potentially important instruments for augmenting human analysts and automating elements of detection, analysis, and response, while simultaneously identifying substantial gaps in the evidence base, including the limited maturity of LLM-supported recovery processes.

The significance of these developments is best understood against the operational pressures confronting contemporary SOCs. Security operations are characterized by high alert volumes, information overload, heterogeneous data sources, a shortage of specialized expertise, and the need to make time-critical decisions under uncertainty. Habibzadeh et al. (2026) identify alert fatigue, skills shortages, and delayed incident response as central challenges motivating the adoption of LLM-based decision support and automation. LLMs may address parts of this problem by accelerating log analysis, supporting alert triage, enriching investigations with contextual knowledge, assisting threat analysis, and reducing the cognitive burden associated with repetitive analytical tasks.

The potential value of LLMs in cybersecurity, however, should not be equated with autonomous or unrestricted automation. The emerging literature suggests considerable variation in performance across cybersecurity tasks, architectures, and evaluation settings. An LLM capable of producing a coherent incident summary, for example, cannot thereby be assumed to be reliable for prioritizing alerts or recommending consequential response actions. The distinction between generating plausible information and producing operationally trustworthy security decisions is therefore fundamental. Habibzadeh et al. (2026) emphasize precisely this broader challenge by identifying trade-offs among LLM architectures and persistent gaps between research prototypes and comprehensive real-world SOC workflows.

At the same time, cybersecurity is an unusually sensitive domain for the deployment of generative AI because the information required to improve security operations may itself constitute highly sensitive security information. Security logs, network telemetry, vulnerability assessments, incident reports, source code, customer configurations, authentication information, threat intelligence, forensic artefacts, and internal security procedures can expose the architecture, defensive capabilities, vulnerabilities, and operational dependencies of an organization. Consequently, the adoption of LLMs in cybersecurity creates a fundamental tension: the effectiveness of AI-supported security operations may depend on access to rich organizational data, while the processing of that same data introduces additional confidentiality, privacy, security, and governance risks.

This tension extends beyond conventional data protection. Liu et al. (2025) demonstrate that generative AI systems are exposed to a range of privacy threats, including membership inference, model inversion, and other forms of information leakage, while emphasizing the continuing need for privacy-preserving approaches. In cybersecurity environments, such risks acquire particular significance because sensitive information may concern not only identifiable individuals but also the technical security posture of organizations and their customers. The relevant security question is therefore not merely whether an AI provider protects transmitted data, but whether the organization can establish meaningful control over the complete lifecycle of the information processed by its AI systems.

The governance challenge is consequently inseparable from the technical one. Humphreys et al. (2024) caution against the rapid adoption of generative AI driven by technological or competitive hype without corresponding attention to cybersecurity and ethical risks. Their analysis highlights the dangers of overreliance and over-trust in generative AI, arguing that organizations have an ethical responsibility to understand and mitigate the vulnerabilities introduced by these systems. This is particularly pertinent in cybersecurity, where an erroneous or manipulated AI output can potentially influence the detection, investigation, prioritization, or response to an actual security incident.

The legal and regulatory dimensions reinforce this need for controlled deployment. Novelli et al. (2024) show that generative AI creates interconnected challenges involving privacy, cybersecurity, intellectual property, and liability, while also raising questions concerning predictability and legal compliance. Their analysis demonstrates that the emergent and partially unpredictable characteristics of LLM-based systems complicate the application of existing legal and regulatory frameworks. Thus, trustworthy deployment cannot be reduced to model accuracy. It requires an institutional and technical environment in which data processing, system behavior, access, accountability, and risk management can be controlled and, where necessary, demonstrated to external stakeholders.

These considerations fundamentally change the question that organizations should ask when introducing LLMs into cybersecurity. The relevant issue is not simply whether LLMs can improve security operations, but under which architectural and governance conditions their use can generate operational value without creating unacceptable dependencies and risks. In particular, the location and governance of AI processing become strategic considerations when the underlying data is itself security-critical.

One architectural response is the deployment of LLM capabilities on dedicated infrastructure under the direct control of the cybersecurity organization. Such an approach can reduce the need to transfer sensitive security information to externally operated AI platforms and can provide greater control over data flows, network boundaries, identity and access management, logging, model deployment, software dependencies, and system lifecycle management. Dedicated infrastructure can therefore serve as an important technical mechanism for strengthening organizational control over AI-enabled processing.

It is important, however, not to equate infrastructure ownership with sovereignty or compliance. An on-premises deployment does not automatically make an AI system secure, private, trustworthy, or legally compliant. Sovereignty is better understood as the ability to exercise meaningful control over where and how data is processed, which models and software are used, who can access the system, how information is retained and deleted, and how AI-mediated activities can be monitored and audited. Likewise, compliance depends on the interaction between technical architecture, organizational processes, contractual arrangements, risk management, and applicable law. Dedicated infrastructure can strengthen these capabilities, but it cannot substitute for them.

This distinction motivates the central concept of this paper: AI by Design. AI by Design conceptualizes the deployment of generative AI not as the subsequent addition of governance controls to an existing technology stack, but as an architectural problem in which security, privacy, data sovereignty, accountability, transparency, and human oversight are incorporated from the outset. The concept therefore extends the logic of security-by-design and privacy-oriented approaches into the specific context of LLM-enabled cybersecurity operations.

Against this background, the paper addresses the following research question:

How can dedicated, organization-controlled AI infrastructure contribute to data sovereignty, cybersecurity, and trustworthy governance in LLM-based security services?

The paper develops a conceptual framework rather than presenting empirical findings from a controlled experiment. The motivating context is a cybersecurity service provider establishing dedicated AI infrastructure in collaboration with an external technology partner. This organizational setting serves as an illustrative case through which the broader architectural and governance implications of LLM deployment in cybersecurity can be examined. The objective is not to argue that on-premises AI is universally superior to cloud-based alternatives, but to investigate under which conditions organizational control over AI infrastructure can contribute to more sovereign, secure, auditable, and trustworthy cybersecurity services.

The central proposition is therefore that AI infrastructure should be understood as part of the cybersecurity governance architecture rather than merely as computational infrastructure. As LLMs become increasingly embedded in SOC workflows, the infrastructure on which they operate determines not only computational performance and latency, but also the boundaries within which sensitive security information is processed and the extent to which an organization can exercise control over its AI-enabled operations. The strategic question consequently shifts from access to AI toward the governance of AI: who controls the data, the models, the processing environment, the interfaces, and ultimately the decisions supported by the system.

This perspective provides the foundation for examining AI by Design as a model for integrating LLM capabilities into cybersecurity operations while preserving the principles of security, privacy, sovereignty, accountability, and human control.

2. From Generative AI to AI-Enabled Cybersecurity

2.1 LLMs as cybersecurity technologies

The significance of large language models (LLMs) for cybersecurity lies not simply in their ability to generate natural language, but in their capacity to operate as flexible interfaces between heterogeneous information sources, analytical processes, and human decision-makers. Conventional cybersecurity analytics are typically designed around relatively well-defined tasks, such as anomaly detection, classification, correlation, or signature matching. LLMs introduce a different computational paradigm: they can interpret and transform unstructured and semi-structured information while maintaining a natural-language interaction layer through which analysts can interrogate data, formulate hypotheses, retrieve contextual information, and receive synthesized explanations.

This capability is particularly relevant to Security Operations Centers (SOCs), where operational knowledge is distributed across multiple systems and formats. Analysts routinely work across security information and event management systems, endpoint telemetry, vulnerability databases, threat-intelligence feeds, incident tickets, technical documentation, malware reports, and organizational knowledge bases. The challenge is therefore not only the detection of individual security events, but the rapid interpretation and contextualization of information distributed across heterogeneous sources. LLMs can potentially provide an abstraction layer across these sources, allowing security analysts to interact with complex technical environments through a common reasoning and language interface.

The breadth of this potential is reflected in the recent cybersecurity literature. Hasanov et al. (2024), in a systematic review of 177 publications, identify a broad spectrum of LLM applications spanning defensive and offensive cybersecurity, security software development, administrative activities, cyberethics, legal considerations, and cybersecurity governance. Their analysis finds particularly strong research activity around the use of AI as a defensive cybersecurity measure, indicating that the field is increasingly moving from general-purpose language applications toward security-specific capabilities.

Habibzadeh et al. (2026) provide a more operationally focused perspective by systematically reviewing 216 studies on LLM integration into SOCs. Their analysis maps applications to the NIST Cybersecurity Framework and uses MITRE ATT&CK to examine the role of LLMs in granular threat-detection activities. They organize the emerging literature around the principal SOC workflow phases of detection, analysis, and response and identify applications including log analysis, network analysis, vulnerability analysis, alert handling, threat detection, investigation, and response support. Their findings are particularly important because they demonstrate that LLM research is no longer confined to isolated demonstrations of language-model capabilities; rather, it is increasingly concerned with how these capabilities can be embedded into the operational processes through which cybersecurity is actually delivered.

Within these workflows, the value of LLMs can be understood as a progression from information processing to contextual interpretation and, ultimately, controlled operational action. At the most basic level, LLMs can reduce the effort required to process security information by summarizing logs, extracting indicators, classifying events, transforming technical information into structured representations, and generating incident documentation. Such capabilities are particularly valuable where analysts must process large volumes of information under significant time pressure.

A second level concerns contextual correlation. Cybersecurity decisions rarely depend on an individual event in isolation. The significance of an alert may depend on the affected asset, its known vulnerabilities, the identity of the user involved, recent threat-intelligence information, historical incidents, and the sequence of related events. LLMs can potentially assist in connecting these heterogeneous sources and presenting their relationships in a form that is more readily interpretable by human analysts. This capability moves the role of AI beyond simple classification toward contextualized security analysis.

A third level involves decision support. LLMs can formulate investigative hypotheses, explain technical findings, retrieve relevant organizational knowledge, propose investigative steps, and assist analysts in assessing the significance of security events. In this role, the LLM functions less as an autonomous decision-maker than as a cognitive augmentation mechanism. It can reduce the time required to assemble and interpret evidence while leaving the ultimate responsibility for consequential decisions with the human analyst.

The fourth and most consequential level is operational automation. Once LLMs are connected to security tools and workflows, they can potentially execute bounded tasks rather than merely provide information. Examples include enriching alerts, initiating predefined investigative queries, creating or updating incident records, generating standardized reports, or triggering predefined workflows. Habibzadeh et al. (2026) identify this capacity to automate complex workflows and augment human analysts as one of the central motivations for LLM adoption in SOCs. At the same time, their review shows that the evidence remains uneven across the different phases of the SOC lifecycle, with particularly significant gaps in the NIST Recover function.

This progression is important because it reveals that the value and risk of an LLM increase together as it moves closer to operational decision-making. An LLM used solely to summarize a closed incident has a fundamentally different risk profile from an LLM that can query production systems, modify security configurations, or initiate response actions. Consequently, the question of whether an LLM is “good enough” for cybersecurity cannot be answered at the level of the model alone. Suitability is a property of the model–task–workflow configuration.

This observation also challenges the assumption that general language capability automatically translates into reliable cybersecurity performance. The literature demonstrates substantial variation across tasks and evaluation settings. A model may perform effectively in information extraction or classification while producing less reliable results when asked to prioritize incidents, reason across incomplete evidence, or recommend consequential actions. Habibzadeh et al. (2026) consequently emphasize architectural trade-offs and the need for further research into real-world SOC integration rather than treating LLM capability as a uniform property.

The distinction between capability and operational reliability is particularly important because LLMs are probabilistic systems. They can generate fluent and apparently plausible outputs without guaranteeing that those outputs are factually correct, complete, reproducible, or appropriately grounded in the available evidence. In cybersecurity, where an incorrect interpretation can result in an incident being missed, incorrectly prioritized, or inappropriately escalated, fluency is therefore an inadequate proxy for quality.

LLM-enabled cybersecurity should consequently be understood primarily as human-augmented security operations rather than unrestricted autonomous security operations. Automation is valuable where the task can be clearly bounded, its inputs and outputs can be validated, and the consequences of an erroneous action are limited or reversible. Human oversight becomes increasingly important as the potential impact of the AI-supported action increases. The objective is therefore not to maximize autonomous decision-making, but to allocate tasks between humans and AI according to their respective strengths and limitations.

This perspective is consistent with the broader governance concerns raised by Humphreys et al. (2024), who warn that organizational enthusiasm surrounding generative AI can lead to premature deployment without adequate consideration of security risks. They argue that organizations have a responsibility to understand the risks associated with generative AI rather than treating technological adoption as an end in itself. In cybersecurity, this implies that the introduction of an LLM should be justified by a demonstrable operational benefit and accompanied by task-specific validation, security controls, monitoring, and clearly defined human accountability.

Accordingly, the appropriate unit of evaluation is not the LLM in isolation but the AI-enabled cybersecurity task. Each use case should be evaluated according to its intended purpose, the sensitivity and quality of its inputs, the reliability of its outputs, the consequences of errors, the degree of human oversight, and the controls governing its interaction with other systems. Such task-level validation provides a more defensible basis for AI adoption than general claims about the intelligence or performance of a particular model.

2.2 The cybersecurity paradox of AI

The increasing integration of LLMs into cybersecurity creates a fundamental paradox. The data that makes AI useful for security operations is often the same data that organizations have the strongest reasons to protect.

Effective AI-supported security analysis may require access to detailed logs, network telemetry, vulnerability information, endpoint data, incident reports, threat-intelligence material, source code, configuration information, customer environments, and historical security cases. The richer the contextual information available to the model, the greater its potential ability to support analysis and decision-making. At the same time, however, the aggregation and processing of this information creates an attractive concentration of sensitive data and introduces additional opportunities for unauthorized disclosure, inference, manipulation, or misuse.

The relationship can therefore be expressed as a fundamental architectural tension: increasing the information available to an AI system may increase its analytical utility while simultaneously increasing the consequences and attack surface associated with that system.

This tension distinguishes cybersecurity from many lower-risk enterprise applications of generative AI. An organization using an LLM to draft generic marketing text does not normally expose the same category of information as a SOC using an LLM to analyze live security telemetry. In the latter case, the model may receive information that directly describes an organization's infrastructure, vulnerabilities, users, security controls, and active incidents. Furthermore, as LLMs become integrated with security tooling, the issue extends beyond confidentiality: the AI system may acquire access to systems capable of producing operational consequences.

The resulting security problem is therefore bidirectional. Organizations must protect the information provided to AI systems, but they must also protect the AI systems that process that information. Generative AI introduces an additional attack surface encompassing the model, its prompts and context, retrieval mechanisms, interfaces, supporting infrastructure, connected tools, and the data flows between these components.

The literature identifies a broad range of risks associated with this emerging attack surface. These include privacy leakage, adversarial manipulation, prompt-based attacks, data poisoning, model manipulation, hallucination, and unauthorized disclosure of sensitive information. Liu et al. (2025), in a comprehensive survey of generative-AI privacy, demonstrate that privacy risks can arise not only from conventional data handling but also from properties of the models themselves. Their analysis covers attacks such as membership inference and model inversion and emphasizes that protecting sensitive information in generative AI requires dedicated privacy-preserving mechanisms rather than reliance on conventional security controls alone.

The implications are particularly significant when LLMs process security-sensitive organizational information. Privacy in this context should not be interpreted exclusively in terms of personally identifiable information. Security telemetry can itself be sensitive even where no individual is identifiable: network architecture, vulnerability information, defensive configurations, incident details, and customer-specific security data may reveal capabilities and weaknesses that an adversary could exploit. Consequently, information security and privacy considerations converge in the architecture of AI-enabled cybersecurity.

The problem becomes more pronounced when LLMs are granted access to external tools or operational systems. An LLM that can retrieve information from a knowledge base presents one category of risk; an LLM that can execute queries against production infrastructure or initiate response actions presents another. The latter transforms the model from an analytical component into an operational actor. Its security therefore depends not only on the confidentiality of the data it processes but also on the permissions, interfaces, and constraints through which it can influence external systems.

This creates a second fundamental principle for AI-enabled cybersecurity: the privileges granted to an LLM should be proportional to the task it performs and the consequences of potential failure. In practice, this implies least-privilege access, explicit tool boundaries, strong authentication and authorization, isolation of sensitive workloads, validation of model outputs, comprehensive logging, and human approval for high-impact actions. The objective is not to prevent AI from interacting with cybersecurity infrastructure, but to ensure that such interaction occurs within controlled and auditable boundaries.

The governance dimension is equally important. Humphreys et al. (2024) argue that organizations face an ethical responsibility to resist AI adoption driven primarily by competitive pressure or technological hype when corresponding security safeguards are insufficient. Novelli et al. (2024) further demonstrate that generative AI creates interconnected challenges involving privacy, cybersecurity, liability, and regulatory compliance, partly because the emergent and probabilistic characteristics of LLMs complicate conventional assumptions about predictability and accountability. The implication is that AI governance cannot be separated from system architecture: decisions concerning where models operate, which data they receive, which external services they depend upon, and what actions they are permitted to perform are simultaneously technical, security, and governance decisions.

The cybersecurity paradox therefore leads directly to the architectural question at the heart of this paper. If effective AI-enabled security operations require access to sensitive security information, organizations must determine where that information can be processed and under whose control. External AI services may provide scalability, model diversity, and rapid access to advanced capabilities, but they can also introduce additional data-processing relationships, infrastructure dependencies, and governance requirements. Conversely, dedicated or organization-controlled AI infrastructure can increase control over data flows, model execution, access boundaries, logging, and operational dependencies, although it also transfers greater responsibility for securing and operating the AI environment to the organization itself.

The relevant choice is consequently not simply between “AI” and “no AI,” nor between “cloud” and “on-premises.” It is a question of control over the AI-enabled processing chain. The more deeply LLMs become embedded in security operations, the more important it becomes to understand where sensitive information is processed, how models interact with that information, which entities can access the processing environment, and how AI-supported actions can be constrained and audited.

This observation provides the conceptual bridge to the notion of AI by Design developed in the subsequent sections. If LLMs are to become components of critical cybersecurity services, their architecture must account simultaneously for analytical utility and organizational control. Security, privacy, sovereignty, accountability, and human oversight therefore cannot be treated as secondary controls added after deployment; they become design requirements for the AI-enabled cybersecurity environment itself.

3. Data Sovereignty and the Case for Dedicated AI Infrastructure

3.1 Beyond data residency

The increasing use of artificial intelligence in cybersecurity makes the question of data sovereignty more consequential than in many conventional enterprise applications. Large language models require access to contextual information to perform effectively, while cybersecurity data frequently contains information of strategic, operational, personal, or commercially sensitive character. The resulting challenge is therefore not simply where data is stored, but under whose control it is processed, which actors can access it, which technologies are involved, and how dependencies across the AI infrastructure can be governed.

The concept of data sovereignty is frequently reduced to geographical data residency: the assumption that data is sovereign if it is physically stored within a particular country or jurisdiction. This interpretation is insufficient for contemporary AI systems. Data may be physically located within a national territory while its processing remains dependent on foreign-controlled cloud infrastructure, proprietary models, software components, external support services, remote administration, or other transnational dependencies. Conversely, data may cross geographical boundaries while remaining subject to strong contractual, technical, and organizational controls. Location is therefore an important dimension of sovereignty, but it is not equivalent to sovereignty itself.

Recent scholarship increasingly conceptualizes sovereignty in broader terms. Von Scherenberg, Hellmeier, and Otto (2024) characterize data as a strategic asset whose value emerges through its use and emphasize the organizational and technological mechanisms required to maintain control over data throughout its lifecycle. Their work illustrates that data sovereignty is not merely a question of storage location, but concerns the ability of organizations to determine how data is accessed, processed, exchanged, and governed. Similarly, research on data spaces emphasizes that sovereignty depends on the ability of different actors to retain meaningful authority over their data within complex technical and institutional environments.

The distinction becomes even more important in the context of artificial intelligence because the relevant object of control is no longer the data repository alone. An AI-enabled processing chain encompasses data, models, compute infrastructure, networks, software, interfaces, identity systems, monitoring mechanisms, and external services. Roberts (2024) consequently conceptualizes digital sovereignty across multiple layers of the digital stack, ranging from physical resources and semiconductor technologies through networks and cloud infrastructure to AI models, applications, and connected devices. This perspective demonstrates why sovereignty cannot be reduced to the physical location of a data centre: control over one layer may coexist with dependencies on other layers that remain outside organizational or jurisdictional control.

For AI-enabled cybersecurity, sovereignty should therefore be understood as the capacity to exercise meaningful and sustained control over the AI-enabled processing chain. This includes control over where sensitive information is stored and processed, but also over who can access it, which models process it, how models and software are updated, which external services participate in processing, how activities are logged and monitored, and how information can ultimately be retained, transferred, or deleted. It also includes the organizational capacity to inspect, audit, restrict, or terminate dependencies that are considered incompatible with the organization's security, legal, or strategic requirements.

This broader interpretation is consistent with the literature on digital sovereignty, which cautions against treating sovereignty as a single, universally defined concept. Fratini et al. (2024) demonstrate that existing models of digital sovereignty differ substantially in their underlying assumptions and objectives, while Adler-Nissen and Eggeling (2024), examining the European cloud debate surrounding Gaia-X, identify competing conceptions of sovereignty associated with security, economic competitiveness, rights, and political authority. The implication is important for enterprise AI: an organization should specify what it seeks to make sovereign and why, rather than treating “sovereign AI” as an intrinsic property of a particular deployment model.

This distinction is particularly relevant to the difference between data sovereignty and digital sovereignty. Data sovereignty concerns the organization's ability to govern its data and the conditions under which that data is processed and shared. Digital sovereignty is broader: it concerns the capacity to maintain meaningful control and strategic autonomy across the technological systems on which digital activities depend. In an AI context, this distinction matters because an organization may have strong control over its data while remaining strategically dependent on an externally controlled model, accelerator platform, cloud provider, software ecosystem, or proprietary application stack.

The literature on cloud sovereignty illustrates this problem clearly. Blancato (2024) argues that European data-sovereignty initiatives are motivated not only by confidentiality and data-protection concerns but also by the strategic dependencies created by reliance on dominant foreign cloud providers. Similarly, research on the relationship between European governments and hyperscale cloud providers describes sovereignty as a continuing negotiation over access and control and concludes that technology alone cannot resolve the underlying trust deficit between infrastructure providers and their users.

For cybersecurity organizations, this suggests a more precise definition:

Data residency describes where data is located; data sovereignty describes the ability to govern and control that data; digital sovereignty additionally concerns the organization's capacity to control or strategically manage the technological dependencies through which that data is processed.

The distinction is not merely semantic. It determines how AI architectures should be evaluated. A system hosted within the desired jurisdiction may still expose an organization to significant external dependencies if model execution, software updates, telemetry, administrative access, or supporting infrastructure remain externally controlled. Conversely, a carefully governed hybrid architecture may provide meaningful sovereignty even where selected components are externally hosted, provided that the organization retains effective control over the relevant data and processing activities.

Sovereignty should therefore be understood as a continuum of control rather than a binary property. An organization can have greater or lesser degrees of control over infrastructure, data, models, software, access, dependencies, and governance. This perspective avoids the overly simplistic assumption that a system is either “sovereign” or “non-sovereign” and instead allows AI architectures to be evaluated according to the specific dependencies they introduce.

This is particularly important for cybersecurity service providers. Their AI systems may process information belonging not only to the provider itself but also to multiple customers, potentially across different jurisdictions and regulatory environments. The relevant sovereignty question consequently extends beyond the provider's own data: it concerns the provider's ability to demonstrate that customer information remains within agreed processing boundaries and that the AI infrastructure does not introduce uncontrolled secondary flows or dependencies.

The objective of sovereignty is therefore not necessarily complete technological independence. Such independence would be difficult to achieve in contemporary digital infrastructures, which depend on globally distributed semiconductor supply chains, software ecosystems, open-source projects, specialized hardware, and international research and technology providers. Roberts (2024) emphasizes precisely this layered and globally distributed character of digital technologies. The more defensible objective is controlled interdependence: understanding which dependencies exist, determining which are acceptable, and maintaining sufficient technical and organizational capabilities to manage the resulting risks.

3.2 Dedicated infrastructure as a sovereignty mechanism

Against this conceptual background, dedicated AI infrastructure can be understood as one mechanism through which organizations increase their degree of control over AI-enabled processing. The argument for dedicated infrastructure is not that physical ownership automatically creates sovereignty, but that reducing the number of uncontrolled processing dependencies can materially strengthen an organization's ability to govern sensitive AI workloads (Chesterman et al., 2024; Swaminathan and Danks, 2024; Walter, 2024).

An organization operating dedicated AI infrastructure can establish a defined processing environment in which sensitive information remains within explicitly controlled organizational and jurisdictional boundaries. This can provide greater control over network architecture, identity and access management, storage, compute resources, encryption, system monitoring, logging, software deployment, and the physical environment in which inference takes place. For cybersecurity providers, these capabilities are particularly relevant because the information processed by AI may describe customer security architectures, vulnerabilities, incidents, defensive controls, threat intelligence, and other information whose unauthorized disclosure could itself create security risk (Liu et al., 2025; Hasanov et al., 2024; Novelli et al., 2024).

The importance of such control increases as AI systems move from isolated experimentation toward operational integration. An LLM that merely processes sanitized public information has limited exposure to sensitive organizational assets. By contrast, an LLM integrated into a SOC may require access to security telemetry, incident-management systems, internal knowledge bases, vulnerability information, and potentially security orchestration tools. The resulting AI environment becomes part of the organization's security architecture rather than an independent productivity application (Hasanov et al., 2024; Rieger et al., 2026; Habibzadeh et al., 2026).

Dedicated infrastructure can consequently provide a stronger basis for establishing explicit trust boundaries around these workloads. Sensitive data can be segmented from general-purpose enterprise environments; access can be restricted according to security roles; model interfaces can be isolated from unauthorized networks; and AI-related events can be integrated into existing monitoring and incident-response processes. Such controls do not eliminate risk, but they can reduce uncertainty concerning where data is processed and which technical actors have access to it (Liu et al., 2025; Ye et al., 2024; Novelli et al., 2024).

The argument also has a strategic dimension. Reliance on external AI and cloud platforms creates dependencies that extend beyond conventional information-security considerations. An organization may become dependent on a provider's pricing model, availability, technical roadmap, model lifecycle, terms of service, geographical processing arrangements, or decisions regarding software and model updates. Research on AI governance and distributed AI development highlights how dependencies across technological and organizational ecosystems can create governance and accountability challenges (Chesterman et al., 2024; Swaminathan and Danks, 2024; Walter, 2024).

Dedicated infrastructure can mitigate some of these dependencies by bringing critical components of the AI processing chain under direct organizational control. This can increase the organization's ability to determine which models are deployed, when they are updated, how they are configured, and how they interact with sensitive information. It can also make it easier to establish organization-specific security policies and assurance mechanisms (Chesterman et al., 2024; Swaminathan and Danks, 2024).

However, these benefits should not be overstated. Dedicated infrastructure does not remove technological dependencies; it changes their nature. An organization operating its own AI hardware may still depend on external semiconductor manufacturers, model developers, software frameworks, operating systems, firmware, open-source components, maintenance providers, or specialist technology partners. The sovereignty achieved is therefore necessarily partial and relational (Swaminathan and Danks, 2024; Walter, 2024; Chesterman et al., 2024).

This observation is consistent with emerging literature on AI governance and distributed AI development, which indicates that effective governance cannot be achieved through technical infrastructure alone. Relationships between organizations, technology providers, developers, and regulatory institutions remain fundamentally questions of governance, accountability, and trust (Swaminathan and Danks, 2024; Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

The appropriate conclusion is therefore not that dedicated infrastructure is synonymous with sovereign AI, but that it can increase the organization's control over critical layers of the AI stack. The extent of that increase depends on the architecture surrounding the infrastructure. If the organization operates the compute environment but relies on opaque externally controlled models, unrestricted external telemetry, or unmanaged software dependencies, the resulting sovereignty may remain limited. Conversely, if infrastructure control is combined with carefully governed models, data classification, access controls, software assurance, monitoring, and lifecycle governance, dedicated infrastructure can form a substantial component of a sovereign AI architecture (Chesterman et al., 2024; Swaminathan and Danks, 2024; Liu et al., 2025).

This leads to a more rigorous proposition:

Dedicated AI infrastructure is an enabling mechanism for AI sovereignty because it can increase organizational control over critical elements of the AI processing chain; however, infrastructure control alone is neither necessary nor sufficient to establish comprehensive AI sovereignty (Chesterman et al., 2024; Lahusen et al., 2024; Swaminathan and Danks, 2024).

AI sovereignty emerges instead from the interaction of infrastructure control, data governance, model governance, security engineering, dependency management, and organizational accountability (Chesterman et al., 2024; Liu et al., 2025; Swaminathan and Danks, 2024). This understanding also avoids a false dichotomy between public cloud and on-premises deployment. Different workloads may require different degrees of control. Public, private, sovereign-cloud, hybrid, and dedicated on-premises architectures can occupy different positions on a sovereignty continuum, depending on how effectively they constrain data flows and external dependencies (Walter, 2024; Swaminathan and Danks, 2024).

For sensitive cybersecurity workloads, however, the value proposition of dedicated infrastructure is particularly strong because the sensitivity of the underlying data and the operational consequences of AI failure are unusually high. The organization is not merely seeking computational capacity; it is seeking a controllable environment in which AI can process security-critical information without unnecessarily expanding the organization's external trust boundaries (Hasanov et al., 2024; Rieger et al., 2026; Habibzadeh et al., 2026).

Dedicated infrastructure should therefore be regarded as an architectural control rather than simply an infrastructure procurement decision. Its strategic value derives from the degree to which it enables the organization to define, enforce, observe, and audit the boundaries of AI-enabled data processing (Chesterman et al., 2024; Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

This perspective provides the foundation for the subsequent concept of AI by Design. If sovereignty is fundamentally about meaningful control, then AI architecture must make that control explicit. Data flows, model interactions, access privileges, external dependencies, logging, monitoring, human oversight, and lifecycle management must be designed as interconnected elements of a single governance architecture. The objective is not to eliminate all external dependencies, but to ensure that dependencies are visible, deliberate, proportionate to the use case, and subject to organizational control (Chesterman et al., 2024; Swaminathan and Danks, 2024; Lahusen et al., 2024).

In this sense, the case for dedicated AI infrastructure is ultimately not a case for hardware ownership. It is a case for architectural control over AI-enabled cybersecurity. Dedicated infrastructure can provide the technical foundation for such control, but sovereignty is realized only when that foundation is combined with the organizational capabilities required to govern the data, models, dependencies, and decisions that constitute the AI system as a whole (Chesterman et al., 2024; Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

Note: Your original paragraph referring specifically to “Roberts (2024)” cannot be cited from the reference list you provided because that source is not included. I therefore replaced it with the closest relevant sources from your list, particularly Swaminathan and Danks (2024), Walter (2024), and Chesterman et al. (2024).

4. AI by Design

4.1 From Privacy by Design to AI by Design

The preceding analysis establishes that the deployment of large language models in cybersecurity creates a problem that cannot be addressed through model performance or infrastructure security alone. LLM-enabled security services simultaneously involve sensitive data, complex software and infrastructure dependencies, probabilistic model behavior, human decision-making, and potentially consequential interactions with operational security systems. These characteristics require governance to be embedded into the architecture and lifecycle of the AI system itself (Hasanov et al., 2024; Rieger et al., 2026; Habibzadeh et al., 2026; Chesterman et al., 2024).

The concept proposed in this paper is AI by Design. It extends the underlying logic of Privacy by Design and Security by Design to the development, deployment, operation, and retirement of AI systems. The fundamental premise is that privacy, security, sovereignty, accountability, and human oversight should not be treated as controls that are added after an AI application has been implemented. Instead, they should constitute explicit design requirements that influence architectural decisions from the earliest stages of system conception (Chesterman et al., 2024; Novelli et al., 2024; Tamò-Larrieux et al., 2024).

This distinction is important because conventional approaches to technology governance frequently separate system development from governance. Technology is first selected and implemented, after which organizations attempt to identify risks and introduce policies, contractual controls, or compliance mechanisms. For LLM-based systems, such a sequential approach is increasingly problematic. Architectural decisions made at the beginning of the lifecycle—such as the choice between external and dedicated infrastructure, the selection of a model, the location of inference, the design of retrieval mechanisms, and the permissions granted to AI agents—can fundamentally determine the organization's subsequent ability to protect data, demonstrate accountability, and exercise control (Swaminathan and Danks, 2024; Humphreys et al., 2024; Chesterman et al., 2024).

The emerging AI-governance literature supports this lifecycle-oriented perspective. Research on AI governance increasingly emphasizes that governance must address questions of responsibility, the objects and processes subject to governance, the stages at which governance occurs, and the mechanisms through which governance is implemented. Existing approaches, however, often focus on individual principles without integrating responsibility, lifecycle timing, implementation mechanisms, and accountability into a comprehensive governance framework (Chesterman et al., 2024; Swaminathan and Danks, 2024; Walter, 2024).

This finding is particularly relevant to AI-enabled cybersecurity. An abstract commitment to transparency or privacy is insufficient if an organization cannot identify who is accountable for an AI use case, which data and system components fall within its governance scope, at what stage controls must be applied, and how compliance and risk controls are actually implemented. AI governance therefore needs to move from a collection of principles toward an operational architecture of responsibility and control (Lahusen et al., 2024; Tamò-Larrieux et al., 2024; Chesterman et al., 2024).

The responsible-AI literature reaches a similar conclusion. Recent research identifies a persistent gap between the formulation of responsible-AI principles and their operationalization in the design, implementation, monitoring, and evaluation of AI systems. Responsible AI governance must therefore encompass structural, relational, and procedural practices rather than relying solely on abstract ethical commitments. In this sense, AI by Design can be understood as an attempt to close the gap between what organizations claim to require from AI systems and what the architecture of those systems is actually capable of enforcing (Swaminathan and Danks, 2024; Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

AI by Design consequently treats privacy, security, sovereignty, traceability, transparency, accountability, and human oversight as mutually reinforcing architectural requirements. These properties should not be interpreted as independent objectives. They interact throughout the AI lifecycle. For example, an organization cannot establish meaningful accountability if AI activities are not sufficiently logged; it cannot guarantee meaningful privacy if data flows cannot be identified; and it cannot credibly claim AI sovereignty if critical model execution or administrative access remains outside its effective control (Chesterman et al., 2024; Liu et al., 2025; Swaminathan and Danks, 2024).

The concept also implies a shift from principle-based governance to control-based governance. Principles such as fairness, transparency, privacy, and accountability provide normative objectives, but an operational AI architecture requires mechanisms through which those objectives can be implemented and verified. Privacy may require data minimization, access controls, retention policies, and processing restrictions. Security may require segmentation, encryption, vulnerability management, and continuous monitoring. Accountability may require explicit ownership, approval processes, logging, and incident management. Sovereignty may require control over data flows, infrastructure, model execution, and external dependencies. Human oversight may require defined intervention points and authorization thresholds (Liu et al., 2025; Ye et al., 2024; Chesterman et al., 2024; Tamò-Larrieux et al., 2024).

AI by Design therefore seeks to translate governance requirements into properties of the AI system and its surrounding organizational processes (Chesterman et al., 2024; Swaminathan and Danks, 2024).

This perspective is particularly important in cybersecurity because the AI system may itself become part of the organization's critical security infrastructure. The distinction between an AI application and an AI-enabled security service becomes increasingly blurred when an LLM is connected to security telemetry, threat-intelligence platforms, incident-management systems, vulnerability databases, or security orchestration mechanisms. In such environments, the architecture of the AI system directly influences the security architecture of the organization (Hasanov et al., 2024; Rieger et al., 2026; Habibzadeh et al., 2026).

AI by Design consequently starts from a simple proposition:

If AI is to process security-critical information or influence security-critical decisions, the requirements for controlling that AI must be incorporated into the architecture of the system itself (Hasanov et al., 2024; Chesterman et al., 2024; Novelli et al., 2024).

This does not imply that every AI system requires the same level of control. Governance should be proportionate to the sensitivity of the data, the criticality of the use case, the autonomy of the system, and the potential consequences of failure. A system used to summarize public threat reports requires a different control environment from an LLM capable of querying customer infrastructure or initiating incident-response actions. AI by Design therefore implies risk-proportionate architecture, rather than a uniform set of controls (Rieger et al., 2026; Habibzadeh et al., 2026; Humphreys et al., 2024; Tamò-Larrieux et al., 2024).

4.2 A layered AI-by-Design architecture

The AI-by-Design concept developed in this paper can be operationalized as a layered architecture encompassing infrastructure, data, models, security engineering, governance, human oversight, and auditability. The layers should not be understood as independent technical components. Rather, they represent interdependent control dimensions that collectively determine whether an AI-enabled cybersecurity system can be considered secure, sovereign, and trustworthy (Chesterman et al., 2024; Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

At the foundation is infrastructure sovereignty. The physical and virtual computing environment establishes the boundaries within which AI processing takes place. This includes servers, accelerators, storage, virtualization, network connectivity, and associated management systems. Infrastructure control is significant because it determines the physical and logical environment in which sensitive information is processed and establishes the first layer of the organization's trust boundary. In the context of dedicated AI infrastructure, the organization can define network segmentation, administrative access, physical security, storage policies, and system monitoring according to its own security requirements (Novelli et al., 2024; Liu et al., 2025; Swaminathan and Danks, 2024).

Infrastructure sovereignty should nevertheless be interpreted as a foundation rather than an endpoint. As established in the previous chapter, control over compute resources does not automatically imply control over the complete AI stack. External models, software frameworks, firmware, update mechanisms, support providers, and hardware supply chains can introduce dependencies beyond the organization's direct control. The infrastructure layer must therefore be considered together with the higher layers of the AI-by-Design architecture (Swaminathan and Danks, 2024; Walter, 2024; Chesterman et al., 2024).

The second layer is data sovereignty. AI systems should process only the information required for their defined purpose, and the movement of that information should be governed according to its sensitivity and the risk of the use case. Data classification therefore becomes an architectural mechanism rather than merely a documentation exercise. Different categories of security information may require different processing environments, access privileges, retention periods, or prohibitions on external transfer (Liu et al., 2025; Ye et al., 2024; Novelli et al., 2024).

For a cybersecurity provider, this distinction can be particularly important because the same AI infrastructure may process information ranging from publicly available threat intelligence to highly confidential customer telemetry and incident data. AI by Design requires these categories to be explicitly distinguished and connected to enforceable processing policies. Sensitive information should remain within authorized processing boundaries, while data that does not require the same degree of protection should not unnecessarily inherit the complexity and cost of highly restricted environments (Hasanov et al., 2024; Liu et al., 2025; Ye et al., 2024).

The third layer concerns model sovereignty and model governance. Control over AI processing cannot be reduced to control over the hardware on which inference occurs. Organizations must also understand and govern which models are deployed, how they are configured, which versions are in production, how they are updated, what data they can access, and under what conditions they may be replaced (Chesterman et al., 2024; Swaminathan and Danks, 2024).

This is particularly relevant for LLMs because model behavior is influenced not only by the model itself but also by system prompts, retrieval mechanisms, fine-tuning, context windows, tool interfaces, model versions, and surrounding application logic. A change to any of these components can potentially alter system behavior. Model governance must therefore extend across the complete AI application rather than treating the base model as an isolated artifact (Hasanov et al., 2024; Rieger et al., 2026; Habibzadeh et al., 2026).

The fourth layer is security engineering. AI systems should be protected according to established information-security principles while also accounting for threats specific to generative AI. Identity and access management, least-privilege authorization, network segmentation, encryption, secrets management, vulnerability management, secure configuration, monitoring, and incident response provide the technical controls necessary to protect the AI environment (Hilario et al., 2024; Hasanov et al., 2024; Novelli et al., 2024).

The principle of least privilege is particularly important when LLMs interact with external systems. An AI system should receive only those permissions necessary to perform its defined task. A model used for incident summarization may require read-only access to selected information sources, whereas an automated response system may require additional privileges. The latter should consequently be subject to substantially stronger controls, validation mechanisms, and human authorization (Rieger et al., 2026; Habibzadeh et al., 2026; Hasanov et al., 2024).

Security engineering must also account for the distinctive attack surface introduced by LLMs. Prompt injection, malicious context, data poisoning, model manipulation, unauthorized information extraction, and insecure tool invocation can undermine otherwise well-protected infrastructure. The AI application therefore needs security controls at the interfaces between users, models, retrieval systems, data sources, and external tools (Hilario et al., 2024; Hasanov et al., 2024; Liu et al., 2025).

The fifth layer is AI governance at the organizational level. Every AI use case should have an explicitly defined purpose, an accountable owner, a documented risk classification, approval criteria, monitoring requirements, and a defined lifecycle. This organizational dimension is essential because technical controls cannot determine whether an AI use case should exist in the first place or whether its intended application is proportionate to the risks involved (Chesterman et al., 2024; Walter, 2024; Tamò-Larrieux et al., 2024).

The literature on AI governance is particularly relevant here because it demonstrates that questions concerning responsibility, accountability, and the distribution of governance roles remain central challenges in the development and deployment of AI systems. Effective governance requires identifiable stakeholders and responsibilities, rather than diffuse organizational accountability. In a cybersecurity context, this means that responsibility for an AI-enabled security service should not disappear into a generic IT function. Ownership must extend across security, data protection, legal, compliance, technology, and operational teams as appropriate to the use case (Swaminathan and Danks, 2024; Chesterman et al., 2024; Lahusen et al., 2024).

Governance must also extend across the entire AI lifecycle. Decisions made before deployment—such as use-case approval, data selection, model selection, and risk assessment—are as important as controls applied during operation. Post-deployment monitoring is equally important because model behavior, threat environments, dependencies, and organizational requirements can change over time. AI governance should therefore be conceived as a continuous process rather than a one-time approval (Chesterman et al., 2024; Walter, 2024; Humphreys et al., 2024).

The sixth layer is human oversight. The role of humans should not be framed simply as a final safety check appended to an otherwise autonomous AI system. Instead, human involvement should be deliberately designed into the workflow according to the consequences of AI error (Lahusen et al., 2024; Tamò-Larrieux et al., 2024; Chesterman et al., 2024).

Low-risk and highly repetitive tasks may reasonably be automated when their outputs can be validated and failures are reversible. More consequential activities should introduce explicit human review or authorization. An LLM may, for example, automatically summarize an incident while requiring an analyst to validate the underlying findings before a customer-facing report is issued. Similarly, an AI system may recommend a response action while requiring human authorization before that action is executed (Rieger et al., 2026; Habibzadeh et al., 2026; Hasanov et al., 2024).

The appropriate level of oversight therefore depends on the impact and reversibility of the AI-supported action, not simply on whether an LLM is involved. This provides a more nuanced approach than treating human-in-the-loop oversight as a universal requirement. In some workflows, continuous human intervention may reduce the efficiency gains that justify automation in the first place; in others, insufficient oversight may create unacceptable operational risk. AI by Design therefore requires explicit determination of where human judgment adds the greatest assurance (Lahusen et al., 2024; Rieger et al., 2026; Tamò-Larrieux et al., 2024).

The seventh layer is auditability and compliance. Trustworthy AI requires the ability to reconstruct relevant aspects of system behavior after an event has occurred. This requires appropriate records of data flows, model versions, configurations, prompts and contextual inputs where appropriate, outputs, access events, system changes, and human decisions. The purpose is not necessarily to record every computational detail of an AI system, but to retain sufficient evidence to establish what system was used, under which conditions, with which inputs and permissions, and how consequential outputs were handled (Chesterman et al., 2024; Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

Auditability serves several functions simultaneously. It supports security monitoring and incident investigation; enables model and workflow evaluation; provides evidence for compliance; facilitates accountability; and creates a basis for identifying systematic failures. Without adequate traceability, organizations may be unable to determine whether an erroneous outcome resulted from the model, the underlying data, the retrieval mechanism, a configuration change, an external dependency, or human interaction with the system (Chesterman et al., 2024; Novelli et al., 2024; Tamò-Larrieux et al., 2024).

This requirement reinforces the relationship between AI governance and information security. Governance cannot be demonstrated solely through policies. It requires evidence that controls are implemented and operating effectively. In this respect, AI governance becomes closely connected to established information-security management practices, risk management, and assurance processes (Chesterman et al., 2024; Humphreys et al., 2024; Lahusen et al., 2024).

The seven layers should ultimately be understood as a coupled control system rather than a linear stack. Infrastructure security cannot compensate for poor data governance. Strong data controls cannot compensate for an inadequately governed model. A well-performing model cannot compensate for excessive system privileges. Human oversight cannot provide meaningful accountability if the organization lacks sufficient auditability to reconstruct what the AI system did. Conversely, effective governance can lose much of its practical value if the underlying technical architecture does not provide mechanisms through which governance requirements can actually be enforced (Chesterman et al., 2024; Swaminathan and Danks, 2024; Lahusen et al., 2024).

The central contribution of AI by Design is therefore to connect these dimensions. It treats the AI system, its infrastructure, its data, its models, its users, and its governance processes as a single socio-technical system (Swaminathan and Danks, 2024; Lahusen et al., 2024; Walter, 2024).

This perspective also provides a more precise interpretation of trustworthy AI. Trustworthiness should not be understood as an intrinsic characteristic of an LLM. A model does not become trustworthy merely because it achieves a high benchmark score or is produced by a reputable provider. Trustworthiness is an emergent property of the complete system in which the model operates: its data, architecture, security controls, governance, human oversight, monitoring, and institutional accountability. Research on AI governance similarly emphasizes that responsible and trustworthy AI depends on structural, relational, and procedural practices rather than on principles alone (Lahusen et al., 2024; Tamò-Larrieux et al., 2024; Swaminathan and Danks, 2024).

For cybersecurity organizations, this distinction is decisive. The relevant question is not whether an LLM is trustworthy in isolation, but whether the AI-enabled security service is sufficiently controlled and trustworthy for its intended purpose (Hasanov et al., 2024; Rieger et al., 2026; Habibzadeh et al., 2026).

AI by Design consequently represents a shift from treating governance as an external constraint on technological innovation toward treating governance as an architectural capability. Privacy, security, sovereignty, accountability, and human oversight become mechanisms through which the organization can safely extract value from AI rather than merely limitations imposed upon it (Chesterman et al., 2024; Humphreys et al., 2024; Tamò-Larrieux et al., 2024).

The resulting proposition is therefore:

AI by Design embeds the governance requirements of AI into the architecture and lifecycle of the AI-enabled system, transforming privacy, security, sovereignty, accountability, traceability, and human oversight from post-deployment controls into design properties of the cybersecurity service (Chesterman et al., 2024; Lahusen et al., 2024; Swaminathan and Danks, 2024).

For organizations operating sensitive cybersecurity services, this approach provides a conceptual bridge between AI adoption and organizational control. It allows dedicated AI infrastructure to be understood not merely as a means of keeping data physically within a defined environment, but as one component of a broader architecture through which AI processing can be governed, constrained, monitored, and audited. In this sense, AI by Design provides the architectural foundation for translating the principle of AI sovereignty into an operational cybersecurity capability (Hasanov et al., 2024; Chesterman et al., 2024; Novelli et al., 2024).

5. Privacy and Security Implications

5.1 Privacy risks of generative AI

he integration of generative AI into cybersecurity operations creates privacy risks that extend substantially beyond those associated with conventional databases and information systems. Traditional data-protection approaches generally focus on controlling access to stored information, securing transmission, and preventing unauthorized disclosure. Generative AI introduces an additional layer of complexity because sensitive information may be incorporated into prompts, contextual windows, retrieval systems, model inputs, outputs, logs, evaluation datasets, and potentially model parameters. Privacy must therefore be considered across the complete lifecycle of AI-mediated data processing rather than at the point of storage alone (Liu et al., 2025; Ye et al., 2024; Novelli et al., 2024).

The literature increasingly recognizes this broader privacy challenge. Liu et al. (2025), in a comprehensive survey of privacy in generative AI, identify a wide range of privacy threats and corresponding mitigation approaches across generative models. Their analysis includes attacks such as membership inference and model inversion, demonstrating that information leakage can occur not only through conventional access to datasets but also through interactions with or analysis of model behavior. The authors consequently emphasize the continuing need for privacy-preserving mechanisms specifically adapted to generative AI systems (Liu et al., 2025).

This distinction is particularly significant for cybersecurity operations because the sensitivity of security data cannot be assessed solely according to whether it contains personally identifiable information. Security logs, network telemetry, vulnerability assessments, incident reports, source code, security configurations, customer environments, threat-intelligence information, and forensic artefacts may reveal the technical architecture and defensive posture of an organization. Their disclosure can therefore create security and competitive risks even when individual privacy is not directly implicated (Hasanov et al., 2024; Novelli et al., 2024; Habibzadeh et al., 2026).

When such information is processed by an externally operated LLM service, the organization must consequently understand the complete data-processing chain. The relevant questions extend beyond whether a provider encrypts data in transit or at rest. They include whether prompts and outputs are retained, whether customer information is used for service improvement or model development, where inference occurs, which subprocessors can access the information, how long data remains available, whether deletion can be verified, how administrative access is controlled, and how changes to the underlying model or service affect the processing environment (Liu et al., 2025; Ye et al., 2024; Novelli et al., 2024).

These considerations become especially important because LLM applications increasingly rely on contextual architectures rather than isolated model inference. Retrieval-augmented generation, external knowledge bases, conversation histories, observability systems, evaluation pipelines, and tool interfaces can all create additional locations in which sensitive information is processed or stored. A privacy assessment that considers only the base model therefore risks overlooking significant parts of the actual AI data lifecycle (Liu et al., 2025; Hasanov et al., 2024; Habibzadeh et al., 2026).

The distinction between data submitted to a model and information potentially recoverable from a model is also important. Generative models can exhibit forms of memorization, and research has demonstrated the possibility of extracting information from models under particular conditions. Liu et al. (2025) describe membership inference and model inversion among the privacy attacks relevant to generative AI, illustrating that privacy protection cannot be reduced to controlling the initial transmission of information (Liu et al., 2025).

For cybersecurity providers, this creates a particularly demanding governance requirement. The organization may process information originating from multiple customers, each of whom may impose different contractual, regulatory, or security requirements. The AI architecture must therefore provide mechanisms for maintaining separation between datasets, controlling contextual access, enforcing retention policies, and preventing information from one customer environment from inadvertently becoming accessible in another (Novelli et al., 2024; Ye et al., 2024; Liu et al., 2025).

Dedicated or internally controlled AI infrastructure can reduce several of these dependencies. Keeping inference and associated data-processing components within an organization-controlled environment can reduce the need to transfer sensitive information to external AI platforms and can provide greater control over storage, network access, logging, retention, and administrative privileges. It can also simplify the establishment of explicit processing boundaries for particularly sensitive workloads (Chesterman et al., 2024; Liu et al., 2025; Swaminathan and Danks, 2024).

The privacy benefits of dedicated infrastructure should nevertheless be understood carefully. Moving a model on-premises does not make the model private by default. A locally deployed model can still memorize sensitive information, expose confidential content through generated outputs, leak information through application logs, or be accessed by unauthorized users. Similarly, retrieval systems, vector databases, backups, monitoring systems, and administrative interfaces can create additional channels through which sensitive information may be disclosed (Liu et al., 2025; Hasanov et al., 2024; Novelli et al., 2024).

Privacy therefore has to be implemented across multiple architectural layers. At the data layer, this includes classification, minimization, retention, segregation, and access control. At the application layer, it includes controlled prompt construction, contextual isolation, output handling, and protection against unintended disclosure. At the model layer, it may involve appropriate model selection, fine-tuning practices, privacy-preserving techniques, and evaluation for memorization or information leakage. At the infrastructure layer, it includes encryption, identity management, network segmentation, logging, and secure administration (Liu et al., 2025; Ye et al., 2024; Novelli et al., 2024).

The resulting principle is:

AI privacy is a property of the complete data-processing architecture, not merely of the location in which model inference occurs (Liu et al., 2025; Ye et al., 2024).

This principle also changes how privacy should be evaluated. The relevant question is not simply whether data leaves the organization, but whether the organization can identify, constrain, monitor, and demonstrate control over the lifecycle of information processed by AI. An architecture that keeps data physically within an organizational facility but permits unrestricted administrative access or uncontrolled retention may offer less effective privacy protection than an appropriately governed external service. Conversely, dedicated infrastructure can provide a strong foundation when combined with enforceable data and application-level controls (Liu et al., 2025; Novelli et al., 2024; Chesterman et al., 2024).

Privacy should therefore be understood as one dimension of the broader sovereignty and governance framework developed in the preceding chapters. The ability to control where data is processed is valuable precisely because it increases the organization's ability to enforce privacy requirements. It does not replace those requirements (Chesterman et al., 2024; Ye et al., 2024; Tamò-Larrieux et al., 2024).

5.2 Security of the AI system itself

The security implications of generative AI are fundamentally bidirectional. AI can become an instrument for improving cybersecurity, while the AI infrastructure introduced to provide those capabilities simultaneously becomes a new cybersecurity asset that must itself be protected.

This distinction is particularly important because the attack surface of an LLM-enabled cybersecurity service extends well beyond the model weights. It may include the model-serving infrastructure, APIs, system prompts, retrieval mechanisms, vector databases, data pipelines, user interfaces, authentication systems, connected security tools, plugins, orchestration systems, and the external data sources that provide context to the model. Each component introduces potential opportunities for manipulation, unauthorized access, information disclosure, or service disruption.

The emerging cybersecurity literature therefore increasingly treats LLMs simultaneously as defensive technologies, enablers of offensive activity, and targets of attack. Hasanov et al. (2024) document this dual role across the broader cybersecurity literature, showing that LLMs are being investigated for defensive applications while also raising security concerns associated with their capabilities and misuse. (research.utu.fi) Habibzadeh et al. (2026) further demonstrate that the increasing integration of LLMs into SOC workflows expands their role from analytical assistance toward interaction with operational security processes, making architectural controls increasingly important.The security implications become particularly pronounced when an LLM is connected to external tools. A model that merely generates a textual explanation has limited ability to affect the underlying environment. A model capable of querying a SIEM, retrieving endpoint information, creating tickets, executing scripts, modifying configurations, or initiating security orchestration actions has substantially greater operational agency.

This creates a qualitative change in the threat model. The LLM is no longer simply an analytical component; it becomes an interface through which decisions can influence security infrastructure. An attacker who can manipulate the information presented to the model may consequently influence downstream behavior. Malicious instructions embedded in untrusted documents, logs, emails, web content, or retrieved threat-intelligence material can potentially manipulate the model's interpretation of context. If the model simultaneously possesses broad tool privileges, the resulting combination of input manipulation and excessive authority can create pathways toward unauthorized actions.

This is one reason why prompt security and input validation cannot be treated as purely model-level concerns. Security controls must also be applied to the interfaces surrounding the model. The system should distinguish trusted from untrusted information, constrain the sources that can influence high-impact decisions, validate tool parameters, and prevent the model from directly translating untrusted natural-language content into unrestricted operational commands.

The problem can be conceptualized as an interaction between model uncertainty and system authority. A probabilistic system with minimal privileges may produce an incorrect answer without causing significant harm. The same system with broad administrative privileges can turn an incorrect or manipulated output into a consequential security event. Risk therefore depends not only on the likelihood of erroneous model behavior but also on the authority granted to the AI system and the reversibility of the actions it can initiate.

This leads to a central architectural principle for AI-enabled cybersecurity:

Minimum necessary agency: an LLM should receive only the data, permissions, tools, and operational authority necessary to perform its explicitly defined task.

The principle extends the conventional information-security principle of least privilege into the AI domain. Instead of asking only which users are permitted to access a system, organizations must also determine what an AI system is permitted to know, invoke, modify, and execute.

Minimum necessary agency implies that LLMs should generally operate through controlled interfaces rather than unrestricted access to underlying infrastructure. Tools should expose narrowly defined functions with explicit parameters and authorization requirements. Read-only access should be preferred where write access is unnecessary. High-impact operations should require additional validation or explicit human authorization. Sensitive credentials should not be exposed directly to model contexts, and secrets should be managed through dedicated security mechanisms rather than natural-language prompts.

The principle also implies a separation between recommendation and execution. An LLM may be highly useful for analyzing an incident and proposing a response while remaining technically incapable of executing that response without an independent authorization mechanism. Such separation reduces the consequences of hallucination, prompt manipulation, and model compromise because the model's output does not automatically become an operational action.

For lower-risk activities, greater automation may be appropriate. Automated enrichment, summarization, classification, report generation, and other reversible activities can potentially be executed with limited human intervention when their outputs are continuously monitored and their failure modes are well understood. For higher-risk activities—such as modifying security configurations, isolating production systems, deleting information, or executing arbitrary code—deterministic controls and explicit authorization should generally be introduced.

This creates a graduated model of AI agency rather than a binary distinction between human-controlled and autonomous AI. The appropriate degree of autonomy depends on the sensitivity of the information involved, the privileges required, the potential impact of an error, and the reversibility of the resulting action.

Security monitoring must consequently encompass both conventional infrastructure events and AI-specific behavior. Relevant telemetry may include model access, authentication events, tool invocations, retrieval activity, unusual prompt patterns, policy violations, configuration changes, model-version changes, and consequential AI-supported decisions. Such observability is necessary not only for detecting attacks but also for reconstructing incidents involving AI components.

This requirement connects AI security directly to the auditability principle established in the AI-by-Design architecture. An organization cannot effectively secure what it cannot observe, and it cannot reliably investigate an AI-related incident if it lacks sufficient evidence concerning what the model received, which tools it invoked, what permissions it possessed, and how its outputs were handled.

The same principle applies to model and software lifecycle management. AI systems should be treated as evolving security components rather than static applications. Model updates, changes to prompts, modifications to retrieval pipelines, new tool integrations, and changes to underlying infrastructure can alter system behavior and therefore potentially introduce new vulnerabilities. Controlled deployment, versioning, testing, rollback mechanisms, and change management are consequently essential components of AI security.

The distinction between securing AI and using AI to secure must therefore remain explicit. An organization may successfully employ an LLM to improve detection and incident response while simultaneously creating new vulnerabilities through insecure model integration. The security value of the AI system must consequently be evaluated against the additional attack surface and privileges introduced by its deployment.

For cybersecurity service providers, this produces a particularly important architectural requirement. An AI-enabled security service should not become a privileged shortcut into the very environments it is intended to protect. Instead, the AI component should operate within deliberately constrained trust boundaries, with explicit permissions, controlled interfaces, independent validation, comprehensive monitoring, and proportionate human oversight.

The combined privacy and security analysis leads to a broader conclusion. Dedicated AI infrastructure can reduce certain external data-processing dependencies, but it does not by itself establish a secure AI environment. Sovereignty without application security can merely create a locally controlled vulnerable system; application security without data governance can protect an AI system while allowing inappropriate data processing. Trustworthy AI-enabled cybersecurity therefore requires the simultaneous management of the confidentiality of the information processed by AI and the security of the AI system performing that processing.

The resulting architectural principle can be summarized as follows:

Protect the data from the AI, protect the AI from attackers, and constrain the AI's ability to affect the environment.

This threefold requirement provides an important bridge between the concepts of sovereignty, AI by Design, and operational cybersecurity. Data must remain within appropriately governed processing boundaries; the AI infrastructure and its interfaces must be protected as security-critical assets; and the model's operational agency must be deliberately constrained according to the consequences of failure.

Under this model, dedicated AI infrastructure is not valuable merely because it is physically located within the organization's premises. Its strategic value arises when infrastructure control is combined with privacy-preserving data architecture, secure model deployment, least-privilege access, bounded AI agency, continuous monitoring, and accountable human oversight. These combined properties transform dedicated infrastructure from a hardware decision into an architectural mechanism for trustworthy AI-enabled cybersecurity.

6. AI for Security Operations

The operational case for dedicated AI infrastructure becomes particularly compelling in Security Operations Centers (SOCs), where the primary challenge is not a lack of security information but the ability to interpret, prioritize, and act upon that information under conditions of time pressure and uncertainty. Contemporary SOCs continuously process security alerts, system and network logs, endpoint telemetry, vulnerability information, threat-intelligence reports, incident tickets, customer information, and organizational knowledge. The resulting volume and heterogeneity of information contribute to analyst workload and alert fatigue and can constrain the ability of security teams to investigate incidents comprehensively (Hasanov et al., 2024; Habibzadeh et al., 2026).

Recent research identifies precisely these operational pressures as major drivers for integrating LLMs into SOC workflows. Habibzadeh et al. (2026), based on a systematic review of 216 studies, identify alert fatigue, analyst workload, skills shortages, and the need for faster detection and response as important motivations for LLM adoption in security operations. Their analysis maps LLM applications across the NIST Cybersecurity Framework and demonstrates that current research is concentrated particularly on detection, analysis, and response activities. At the same time, the authors identify substantial gaps in the evidence for complete end-to-end SOC automation, indicating that the maturity of individual AI capabilities should not be confused with the maturity of autonomous security operations (Habibzadeh et al., 2026).

The operational role of LLMs should therefore be understood as augmentation of the SOC analytical workflow rather than straightforward replacement of human analysts. The broader cybersecurity literature similarly identifies LLMs as potentially valuable across security analysis, knowledge retrieval, information processing, and defensive workflows, while emphasizing limitations in reliability, security, and operational validation (Hasanov et al., 2024). Rather than replacing the analyst, an LLM can operate as an intermediary between large volumes of machine-generated security information and human decision-making. It can reduce the effort required to retrieve, transform, correlate, and communicate information while allowing analysts to concentrate on activities requiring contextual judgment and responsibility.

The distinction between augmentation and autonomy is particularly important because the consequences of an incorrect security decision can be substantial. A false negative may allow an attack to progress, whereas a false positive can consume scarce analytical resources or lead to unnecessary disruption. Moreover, LLMs can produce plausible but incorrect outputs, meaning that linguistic fluency cannot be treated as evidence of factual correctness. Research on the application of LLMs to cybersecurity emphasizes precisely these reliability, security, and misuse concerns (Hasanov et al., 2024; Hilario et al., 2024). The operational suitability of an LLM must therefore be evaluated at the level of individual tasks and workflows, with controls proportionate to the consequences of error.

This risk-proportionate approach is consistent with the broader literature on AI governance. Effective governance requires organizations to establish mechanisms for accountability, oversight, risk management, and control rather than assuming that technical capability alone determines whether an AI system can be responsibly deployed (Chesterman et al., 2024; Swaminathan and Danks, 2024). Questions of trustworthiness are similarly dependent not only on system performance but also on the institutional and organizational arrangements through which AI is developed and used (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

6.1 Alert triage

Alert triage represents one of the most immediate applications of LLMs in SOC environments. Modern security infrastructures can generate large numbers of alerts originating from different detection systems, each providing different levels of context and confidence. Analysts must determine which events require immediate attention, which can be investigated further, which can be correlated with other events, and which can ultimately be dismissed. Alert overload and analyst workload are among the recurring challenges identified in the literature on LLM-enabled security operations (Habibzadeh et al., 2026; Hasanov et al., 2024).

LLMs can assist with this process by interpreting alert descriptions, extracting entities and indicators, incorporating contextual information, and producing structured summaries for analysts. When connected to appropriate knowledge sources, an LLM can potentially enrich an alert with information concerning the affected asset, known vulnerabilities, historical incidents, relevant threat intelligence, or associated adversary techniques. Such capabilities are consistent with the broader evidence that LLMs can support information extraction, analysis, knowledge retrieval, and other cybersecurity tasks (Hasanov et al., 2024; Habibzadeh et al., 2026).

However, alert classification and alert prioritization should not be treated as equivalent tasks. A model may successfully determine the broad category of an alert while being considerably less reliable in determining its operational severity or urgency. The distinction is important because prioritization requires reasoning about context, business impact, uncertainty, and potential consequences rather than simply recognizing textual or technical patterns. Recent research specifically examining LLMs for alert classification and prioritisation highlights the need to distinguish these tasks and to evaluate their performance under realistic SOC conditions (Rieger et al., 2026).

The evidence synthesized by Habibzadeh et al. (2026) supports this more cautious interpretation. Their review identifies alert analysis and detection as important LLM application areas while also emphasizing the heterogeneity of results across tasks and the continuing need for robust evaluation in operational environments. Rieger et al. (2026) similarly demonstrate that the potential usefulness of LLMs for alert classification and prioritisation must be considered in relation to the limitations and task-specific performance of the models.

LLMs should therefore initially be positioned as decision-support mechanisms within alert triage rather than autonomous authorities for severity assignment. The model can propose a classification or priority, explain the evidence supporting its recommendation, and retrieve additional context, while the analyst or an independently validated deterministic mechanism retains authority over consequential decisions. This allocation of authority is consistent with a broader AI-governance approach in which the level of human oversight should correspond to the risks associated with the system's decisions (Chesterman et al., 2024; Swaminathan and Danks, 2024).

6.2 Incident summarization

Incident summarization represents a comparatively lower-risk but potentially high-value application. During an investigation, relevant information may be distributed across alerts, logs, endpoint telemetry, analyst notes, threat-intelligence sources, tickets, chat messages, and previous incidents. Constructing a coherent incident narrative manually can therefore consume significant analyst time. The ability of LLMs to process and transform large quantities of heterogeneous textual information is one of the principal reasons for their growing application across cybersecurity workflows (Hasanov et al., 2024; Habibzadeh et al., 2026).

An LLM can synthesize this heterogeneous information into a structured narrative describing the observed activity, affected assets, known indicators, timeline, investigative findings, and outstanding questions. Such summaries can reduce cognitive workload and accelerate communication between technical analysts, incident managers, customers, and executive stakeholders. The potential value is therefore not limited to reducing the time required to produce documentation; it can also improve the accessibility of security information across organizational roles.

The value of this capability extends beyond efficiency. A standardized AI-supported summarization process can improve the consistency of incident documentation and facilitate knowledge transfer between analysts working on different shifts. It can also support the creation of customer-facing and management-level reports from the same underlying evidence while allowing the level of technical detail to be adapted to the intended audience. Such information transformation is consistent with the broader observation that LLMs can assist with cybersecurity knowledge processing and communication tasks (Hasanov et al., 2024).

Nevertheless, summarization introduces an important reliability requirement: compression must not become fabrication. An LLM may omit relevant information, incorrectly infer relationships, or present uncertain conclusions as established facts. These limitations are part of the broader reliability problem associated with generative AI, in which apparently coherent outputs cannot necessarily be assumed to be factually accurate (Hasanov et al., 2024; Liu et al., 2025).

AI-generated incident narratives should therefore preserve the distinction between observed evidence, inferred relationships, and analyst conclusions. Where possible, generated statements should remain traceable to their underlying evidence. Retrieval-based architectures and explicit source attribution can strengthen this property by allowing analysts to verify important claims against the original logs, alerts, or intelligence reports. In high-impact contexts, the generated narrative should consequently be regarded as a representation of the evidence rather than as evidence in itself.

This distinction is also important from a trust perspective. Research on trust and trustworthiness in AI indicates that confidence in an AI system cannot be established solely through the apparent quality of its outputs; organizational mechanisms for verification, accountability, and oversight are also necessary (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

6.3 Threat intelligence enrichment

Threat intelligence is another domain in which LLMs can provide substantial analytical value because a significant proportion of intelligence remains unstructured or semi-structured. Reports may contain indicators of compromise, descriptions of adversary behavior, vulnerability information, malware characteristics, infrastructure relationships, and references to tactics and techniques distributed throughout lengthy textual documents. LLMs are particularly relevant to such tasks because they can transform unstructured language into structured information and support information extraction and correlation (Hasanov et al., 2024; Habibzadeh et al., 2026).

LLMs can assist by extracting relevant entities and relationships from these sources and transforming them into structured information that can subsequently be correlated with internal security data. This can include identifying IP addresses, domains, file hashes, vulnerabilities, malware families, threat actors, techniques, and affected technologies.

An important application is the mapping of unstructured intelligence to established security knowledge frameworks. Habibzadeh et al. (2026) specifically identify the use of LLMs in conjunction with MITRE ATT&CK as an important research direction, demonstrating how language models can assist in connecting natural-language threat descriptions with structured representations of adversary tactics and techniques.

The principal value of LLMs in this context is therefore not necessarily to replace conventional threat-intelligence platforms, but to act as a transformation and correlation layer between unstructured information and structured security knowledge. This can reduce the manual effort required to incorporate external intelligence into internal detection and investigation workflows (Hasanov et al., 2024; Habibzadeh et al., 2026).

At the same time, extracted intelligence should be treated as potentially uncertain until validated. An incorrect indicator, technique mapping, or inferred relationship can propagate into downstream detection and response processes. AI-generated enrichment should consequently retain provenance and confidence information wherever feasible, allowing analysts and automated systems to distinguish source-derived information from model-generated interpretation.

This requirement is particularly important because cybersecurity applications of generative AI can create both defensive opportunities and new risks. Research on generative AI for penetration testing, for example, demonstrates that the same capabilities that enable useful security automation can also create undesirable or harmful outcomes when inadequately controlled (Hilario et al., 2024). Consequently, AI-enabled intelligence processing should be embedded within governance and security controls rather than treated as a neutral information-processing function.

6.4 Investigation assistance

LLMs can also support the investigative reasoning process by helping analysts formulate hypotheses, retrieve relevant organizational knowledge, interpret technical artefacts, and generate investigative queries. This capability is particularly relevant to complex incidents where analysts must repeatedly move between different information sources and translate between technical representations. Such information retrieval and analytical assistance are among the broader cybersecurity applications identified in systematic reviews of LLM research (Hasanov et al., 2024; Habibzadeh et al., 2026).

A conversational interface can reduce the cognitive and operational cost of this interaction. Instead of manually navigating multiple systems, an analyst could formulate a natural-language question and receive a structured response based on authorized security data. The model could subsequently suggest additional questions or investigative steps based on the available evidence.

Such functionality represents a form of cognitive augmentation rather than autonomous reasoning. The LLM can broaden the range of hypotheses considered by an analyst and accelerate information retrieval, but generated hypotheses should remain explicitly distinguishable from verified facts.

This distinction is essential because LLMs can produce plausible explanations that are not supported by the available evidence. An AI-generated hypothesis should therefore be treated as a candidate explanation to be tested rather than as a conclusion. Retrieval mechanisms, evidence citation, deterministic queries, and analyst validation can help maintain this distinction (Hasanov et al., 2024; Liu et al., 2025).

The architecture becomes more consequential when investigation assistance is connected to operational security systems. An LLM capable of generating queries against a SIEM or endpoint platform can provide substantial efficiency gains, but it should operate through constrained interfaces with explicit permissions. The system should not be given unrestricted access merely because the analyst's task requires information from several sources.

This reinforces the principle of minimum necessary agency established in the previous chapter. AI should have sufficient access to perform its analytical function but no broader authority than necessary. Read-only access may be sufficient for many investigative tasks, while actions that modify systems or initiate response procedures should require additional controls. This principle is consistent with risk-based AI governance approaches that emphasize accountability, oversight, and clearly allocated responsibility (Chesterman et al., 2024; Swaminathan and Danks, 2024).

6.5 Security reporting

Security reporting provides another relatively well-defined domain for AI augmentation. SOCs routinely generate incident reports, customer notifications, executive summaries, operational documentation, and post-incident records. Much of this activity involves transforming existing information into different formats and levels of abstraction rather than generating genuinely new knowledge.

LLMs are well suited to this type of transformation. A single incident record can potentially be converted into a detailed technical report for security specialists, a concise management summary for executives, or a customer-oriented communication that focuses on impact and recommended actions. Automating such transformations can reduce repetitive work and allow analysts to allocate more time to investigation and decision-making (Hasanov et al., 2024; Habibzadeh et al., 2026).

The principal risk is again the possibility that generated language obscures uncertainty. Reporting systems should therefore distinguish clearly between confirmed observations, analytical assessments, recommendations, and unresolved questions. Particularly in customer-facing reporting, AI-generated content should remain subject to appropriate human review because inaccurate statements can have operational, contractual, reputational, and potentially legal consequences.

The legal dimension is significant because generative AI can raise questions relating to liability, privacy, intellectual property, and cybersecurity. Novelli et al. (2024) demonstrate that these legal dimensions are interconnected rather than isolated concerns. Consequently, organizations using LLMs to generate external or customer-facing security communications must consider not only technical accuracy but also the legal and accountability implications of automated content generation.

From an AI-by-Design perspective, reporting also represents an opportunity to establish clear human-approval boundaries. Draft generation may be automated, while publication or external communication requires explicit authorization. This creates a practical separation between content generation and consequential communication. Such separation is consistent with governance approaches that seek to maintain meaningful human oversight over consequential AI-supported decisions and actions (Chesterman et al., 2024; Tamò-Larrieux et al., 2024).

6.6 Knowledge management and retrieval-augmented security operations

Knowledge management represents one of the strategically important applications of LLMs in cybersecurity because effective security operations depend heavily on organizational knowledge that is distributed across documentation, previous incidents, technical procedures, architectural information, detection rules, runbooks, and expert experience. Systematic research on LLMs in cybersecurity identifies knowledge retrieval, information processing, and assistance with security tasks as important application areas (Hasanov et al., 2024; Habibzadeh et al., 2026).

Retrieval-augmented generation (RAG) provides an architectural mechanism through which an LLM can use this information without requiring the information itself to be incorporated into the model's parameters. A locally controlled RAG architecture can retrieve relevant documents or records from authorized organizational knowledge sources and provide them as contextual information to the model at inference time.

This architecture can offer several advantages for cybersecurity organizations. First, it can improve factual grounding by connecting generated responses to current organizational information rather than relying solely on the model's pretrained knowledge. Second, it can support more rapid updating because changes to organizational knowledge can be reflected in the retrieval layer without necessarily retraining the underlying model. Third, when deployed within an organization-controlled environment, it can allow sensitive knowledge to remain within defined processing boundaries.

These advantages are particularly relevant to the privacy and data-governance concerns associated with generative AI. Research on generative AI model privacy identifies a range of risks associated with the handling, memorization, exposure, and processing of sensitive information (Liu et al., 2025). Similarly, Ye et al. (2024) emphasize the importance of privacy and personal-data risk governance in generative AI systems. For cybersecurity providers handling highly sensitive customer information, these concerns strengthen the case for infrastructure and architectures that provide meaningful control over data flows and processing environments.

However, RAG does not eliminate the underlying security and privacy challenges. The retrieval system itself becomes a security-critical component because unauthorized retrieval can expose information that the user or model should not access. Access controls therefore need to apply not only to the LLM but also to the underlying knowledge sources and retrieval mechanisms.

This makes authorization-aware retrieval an important component of AI-enabled SOC architecture. The information retrieved for a given request should depend on the identity, role, customer context, and purpose of the requester. In a multi-customer cybersecurity environment, tenant isolation is particularly important because the knowledge available to one customer or analyst must not inadvertently become available to another. Such controls are consistent with the broader principle that privacy and security governance must encompass the complete AI system rather than only the model itself (Ye et al., 2024; Liu et al., 2025).

The combination of LLMs and controlled retrieval can therefore be understood as a mechanism for turning organizational security knowledge into an interactive operational capability. Rather than treating the LLM as an independent source of truth, the architecture positions it as an interface through which authorized users can interrogate and synthesize existing organizational knowledge.

6.7 From individual use cases to an AI-augmented SOC

The use cases described above should not be considered independent applications. Their greater value emerges when they are integrated into a coherent SOC workflow. An alert can be automatically enriched with threat intelligence, summarized for an analyst, correlated with organizational knowledge, used to formulate investigative hypotheses, and subsequently transformed into a structured incident report. In such a workflow, the LLM becomes an orchestration and knowledge interface spanning multiple stages of security operations. The systematic literature on LLMs in SOCs increasingly identifies this breadth of potential application, while also emphasizing that the evidence for fully autonomous workflows remains limited (Habibzadeh et al., 2026; Hasanov et al., 2024).

This integration also illustrates why AI infrastructure becomes strategically important. An LLM supporting a single low-risk reporting task can potentially be isolated from much of the organization's sensitive infrastructure. An LLM supporting the complete analytical workflow, by contrast, may require controlled access to multiple security data sources and operational systems. The more integrated the AI becomes, the more important data sovereignty, access control, auditability, model governance, and infrastructure security become.

These requirements reflect the broader evolution of AI governance from questions concerning individual models toward governance of complete sociotechnical systems, including organizational processes, accountability mechanisms, technical controls, and institutional responsibilities (Chesterman et al., 2024; Swaminathan and Danks, 2024). The governance challenge is consequently not simply whether an LLM is accurate, but whether its deployment can be trusted within a defined operational and organizational context (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

Habibzadeh et al. (2026) highlight precisely this distinction by demonstrating that the research field contains numerous promising task-level applications while evidence for comprehensive end-to-end SOC automation remains comparatively limited. Their systematic mapping across the NIST Cybersecurity Framework indicates substantial research activity around detection, analysis, and response but also reveals gaps in later stages of the cybersecurity lifecycle, particularly recovery.

The implication is that organizations should avoid evaluating AI adoption through isolated demonstrations of model capability. Instead, they should assess how an AI capability performs within the complete operational workflow. Relevant evaluation dimensions include accuracy, recall, precision, latency, analyst workload, false-positive and false-negative consequences, explainability, provenance, security, and the degree of human intervention required (Rieger et al., 2026; Habibzadeh et al., 2026).

The objective should therefore not be to maximize the number of SOC activities performed autonomously. Rather, it should be to identify those activities for which AI provides a measurable improvement in speed, consistency, analytical capacity, or workload reduction without introducing disproportionate operational risk. This is consistent with the broader literature's emphasis on responsible and risk-sensitive AI governance rather than capability-driven deployment alone (Chesterman et al., 2024; Walter, 2024).

This leads to a distinction between AI-enabled and AI-augmented security operations. An AI-enabled SOC may incorporate AI into individual tools or processes, whereas an AI-augmented SOC deliberately allocates tasks between humans and machines according to their respective capabilities. AI handles information-intensive, repetitive, and well-bounded activities; analysts retain responsibility for contextual judgment, exception handling, escalation, and consequential decisions. Such allocation also addresses concerns that organizational enthusiasm surrounding generative AI can encourage inappropriate adoption before risks and limitations have been sufficiently understood (Humphreys et al., 2024).

Such an approach provides a more realistic path toward automation. Rather than moving directly from manual security operations to autonomous AI agents, organizations can progressively increase automation as individual tasks become validated and their failure modes understood. A low-risk summarization function can be automated earlier than an autonomous incident-response function. Similarly, read-only investigative assistance can precede systems capable of modifying production environments.

The resulting model can be characterized as progressive, risk-proportionate automation. AI capabilities are introduced at the task level, evaluated under realistic operational conditions, integrated with appropriate security and governance controls, and granted additional agency only when evidence demonstrates that the associated risks are manageable. This approach reflects the broader governance principle that AI systems should be subject to controls proportionate to their capabilities, context, and potential consequences (Chesterman et al., 2024; Swaminathan and Danks, 2024).

For a cybersecurity provider, dedicated AI infrastructure can provide the technical foundation for this model by keeping sensitive SOC data and AI processing within controlled boundaries. It can support organization-specific RAG systems, secure integration with internal security platforms, centralized monitoring, controlled model deployment, and differentiated access policies across customers and operational teams. The infrastructure therefore becomes an enabler of AI-augmented security operations rather than an end in itself.

This infrastructure perspective is also relevant to the international and regulatory environment in which AI systems increasingly operate. AI governance is developing across multiple jurisdictions and policy levels, producing a fragmented but increasingly comprehensive set of expectations concerning accountability, risk, privacy, security, and responsible deployment (Walter, 2024; Chesterman et al., 2024). For organizations operating across jurisdictions, infrastructure that provides stronger control over data location, access, processing, and auditability can therefore contribute to both technical resilience and governance compliance. European deployments additionally need to account for the interaction between generative AI and existing legal regimes governing liability, privacy, intellectual property, and cybersecurity (Novelli et al., 2024).

The central proposition of this chapter is consequently:

LLMs are most valuable in security operations not as autonomous replacements for analysts, but as controlled cognitive and computational augmentation mechanisms embedded within well-defined SOC workflows.

Their operational value arises from their ability to transform, correlate, retrieve, explain, and communicate security information at scale. Their safe deployment, however, depends on maintaining clear boundaries between generated information and verified evidence, between recommendation and execution, and between analytical assistance and consequential decision-making. These boundaries are fundamental to establishing trustworthy AI systems because technical capability alone does not guarantee trustworthiness or responsible use (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

In this model, the objective of AI adoption is not to remove the human analyst from the security operation. It is to increase the analytical capacity of the SOC while preserving human accountability and organizational control. This provides the operational rationale for the AI-by-Design architecture developed in the preceding chapters and establishes the basis for examining how such an architecture can translate into measurable improvements in cybersecurity service delivery.

7. Automation Without Loss of Quality

The proposition that artificial intelligence can automate repetitive cybersecurity activities without compromising quality is central to the business case for LLM-enabled security operations. Scientifically, however, this proposition should not be treated as an inherent property of the technology. It is an empirical hypothesis that depends on the characteristics of the task, the quality of the underlying data, the architecture surrounding the model, the consequences of error, and the effectiveness of validation mechanisms. Research on LLM applications in cybersecurity consistently emphasizes both the potential of these systems and the need to evaluate their performance within specific operational contexts rather than extrapolating from general-purpose model capabilities (Hasanov et al., 2024; Habibzadeh et al., 2026).

This distinction is particularly important in cybersecurity. An LLM can substantially reduce the time required to process information, but speed and linguistic fluency do not necessarily correspond to analytical accuracy. A model may produce an apparently coherent incident summary while omitting a critical indicator, assign an inappropriate priority to an alert, generate an unsupported investigative hypothesis, or present an uncertain inference as an established fact. The operational consequences of such errors vary considerably across tasks. An incorrect draft report may require correction, whereas an incorrect automated containment decision may disrupt a critical production environment. The potential for generative AI to produce both useful security capabilities and harmful or unreliable outcomes has been demonstrated across cybersecurity applications (Hilario et al., 2024; Hasanov et al., 2024).

The literature on LLMs in cybersecurity consequently emphasizes the need for task-specific evaluation rather than assuming that general model capability translates directly into reliable security performance. The systematic survey by Habibzadeh et al. (2026), for example, identifies substantial potential for LLM-supported automation across SOC workflows while also highlighting limitations in reliability and the lack of sufficient evidence for unrestricted end-to-end autonomous incident response. More broadly, research on LLM security applications identifies reliability, hallucination, factual inconsistency, privacy, and security as persistent challenges when models are used in contexts in which incorrect information can affect security decisions (Hasanov et al., 2024; Liu et al., 2025).

The appropriate objective is therefore not simply to automate a task, but to establish whether automation produces measurable net operational value under defined quality constraints. Such an assessment should consider not only model accuracy but also latency, analyst workload, false-positive and false-negative rates, reproducibility, explainability, traceability, and the consequences associated with different classes of error. This risk-sensitive perspective is consistent with the broader development of AI governance, which increasingly emphasizes proportionality, accountability, oversight, and the relationship between technical capabilities and their social and organizational consequences (Chesterman et al., 2024; Walter, 2024).

7.1 From automation to validated automation

A useful distinction can be made between automation, autonomous decision-making, and validated automation.

Automation refers to the execution of a defined activity by a machine without requiring a human to perform every individual step. This does not necessarily imply that the machine is making the underlying decision. For example, an LLM may automatically summarize an incident, extract indicators from a threat report, or transform an analyst's findings into a predefined reporting format. Such applications correspond closely to the task-level augmentation identified in the emerging literature on LLM-supported SOC operations (Habibzadeh et al., 2026).

Autonomous decision-making goes further by allowing the AI system to determine and potentially execute actions without human intervention. The associated risk is considerably higher because an incorrect model output can directly produce a consequential operational outcome. This distinction is particularly significant in cybersecurity because the same generative capabilities that can support defensive activities can also introduce security risks or facilitate harmful actions when insufficiently controlled (Hilario et al., 2024).

Validated automation occupies the intermediate position. The AI system performs substantial parts of the workflow, but its outputs are subject to deterministic, procedural, or human controls before consequential actions are taken. This model is particularly appropriate for cybersecurity because it allows organizations to capture efficiency gains while constraining the impact of probabilistic model behavior. It is also consistent with governance approaches that emphasize meaningful human oversight and clearly allocated responsibility for AI-supported decisions (Chesterman et al., 2024; Swaminathan and Danks, 2024).

The distinction can be expressed through a simple principle:

The appropriate target is not maximum automation, but maximum validated operational value.

This changes how AI use cases should be selected. Activities should not be automated merely because an LLM is technically capable of performing them. They should be automated when the task has sufficiently well-defined objectives, measurable outputs, identifiable failure modes, and controls capable of detecting or containing unacceptable errors.

A low-risk transformation task such as generating a first draft of an incident report may therefore justify a high degree of automation. A task involving customer notification may require automated generation but human approval before transmission. An activity involving changes to production security infrastructure may require substantially stronger controls, potentially including independent deterministic validation and explicit authorization. This differentiation is consistent with the principle that the governance and oversight applied to AI should reflect the context and consequences of its use (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

Automation maturity should consequently be risk-proportionate rather than technology-driven.

7.2 A quality-assurance architecture

Quality assurance should be embedded into the AI workflow itself rather than introduced retrospectively through occasional manual review. A robust AI-by-Design architecture can be understood as a sequence of controls spanning the lifecycle of an AI-supported task. This approach reflects the broader movement in AI governance toward managing complete AI systems and organizational processes rather than treating the model as an isolated technical component (Chesterman et al., 2024; Swaminathan and Danks, 2024).

The first stage is input validation. Before information is presented to an LLM, the system should establish that the input is relevant, sufficiently complete, authorized for processing, and appropriately classified. This is particularly important in cybersecurity environments because inputs may originate from untrusted sources. Logs, emails, threat-intelligence documents, web content, or other external artefacts may contain instructions or content that should be treated as data rather than as trusted commands.

Input validation should therefore encompass both data quality and security. The system should determine whether the model is permitted to access the information, whether the information belongs to the appropriate customer or security domain, and whether untrusted content can influence model behavior inappropriately. These controls are particularly important where sensitive personal or organizational information is involved, given the privacy risks associated with generative AI systems and their handling of potentially sensitive data (Liu et al., 2025; Ye et al., 2024).

The second stage is AI processing. The LLM performs the defined analytical or transformation task, such as classification, summarization, extraction, correlation, hypothesis generation, or report drafting. At this stage, the architecture should make the intended task and permitted scope explicit. System instructions, available tools, retrieval sources, and model permissions should be constrained according to the approved use case.

The third stage is deterministic validation. This stage is essential because it introduces controls that do not depend on the LLM correctly evaluating its own output. Generated information can be tested against schemas, business rules, security policies, authoritative databases, known indicators, mathematical constraints, or other deterministic mechanisms.

For example, an LLM may extract an IP address from a threat-intelligence report, but a deterministic process can verify whether the extracted value conforms to the required format. A model may recommend a severity classification, while predefined rules can determine whether the proposed classification is compatible with the presence of specific indicators or asset characteristics. Similarly, an AI-generated action can be checked against an explicit authorization policy before it is passed to an operational system.

This separation between probabilistic generation and deterministic validation is particularly valuable in security operations. It recognizes that LLMs are useful at interpreting heterogeneous information while deterministic systems remain well suited to enforcing explicit constraints. The distinction also provides an architectural response to the reliability limitations identified in the cybersecurity LLM literature (Hasanov et al., 2024; Habibzadeh et al., 2026).

The fourth stage is human review. Human oversight should not be applied identically to every AI-supported activity. Its intensity should correspond to the potential consequences of error. Low-risk and reversible tasks can potentially proceed with limited intervention, whereas high-impact actions should require explicit analyst approval. This is consistent with risk-based governance approaches in which human responsibility and oversight are retained for consequential decisions (Chesterman et al., 2024; Lahusen et al., 2024).

Human review should also be designed as a meaningful control rather than a purely formal step. Analysts need sufficient evidence to understand why an AI system produced a particular result, what information it relied upon, and where uncertainty remains. Interfaces should therefore distinguish between retrieved evidence, model-generated interpretation, and proposed action. Such distinctions are important for establishing trustworthiness because trust in AI cannot be reduced to confidence in the apparent fluency or usefulness of its outputs (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

The final stage is feedback and continuous monitoring. AI quality cannot be established once and assumed to remain constant. Changes in threat landscapes, data distributions, customer environments, models, prompts, retrieval sources, and surrounding software can alter system performance. The governance literature similarly emphasizes that AI systems require continuing oversight because their operational context and associated risks can evolve over time (Chesterman et al., 2024; Walter, 2024).

Continuous monitoring should therefore assess both technical and operational outcomes. Relevant indicators may include classification performance, false-positive and false-negative rates, analyst overrides, escalation rates, processing latency, hallucination frequency, unsupported recommendations, and the proportion of AI outputs requiring substantive correction.

The resulting architecture creates a feedback loop in which AI performance becomes an observable property of the operational system rather than an assumption based on benchmark results.

7.3 The importance of task-level evaluation

A central implication of this approach is that AI systems should be evaluated at the level of specific operational tasks, not simply at the level of the underlying model.

An LLM that performs well in natural-language summarization may not perform equally well in alert prioritization. A model that can extract indicators reliably from structured reports may still generate unreliable conclusions when asked to infer attacker intent. Similarly, a model that performs well in a controlled evaluation may behave differently when exposed to noisy SOC data, incomplete logs, ambiguous incidents, or adversarial inputs. Systematic reviews of cybersecurity applications consistently demonstrate that LLM performance varies according to the particular task and operational context (Hasanov et al., 2024; Habibzadeh et al., 2026).

This problem is especially significant because cybersecurity tasks frequently involve asymmetric costs. In some contexts, false positives are relatively inexpensive, whereas false negatives are highly consequential. In other contexts, excessive false positives can create alert fatigue and reduce the effectiveness of the SOC. The appropriate performance threshold therefore depends on the operational purpose of the AI system. Rieger et al. (2026), in their examination of LLMs for alert classification and prioritisation, further illustrate why these functions should be evaluated according to their distinct operational requirements rather than treated as interchangeable forms of classification.

Evaluation should consequently reflect the actual decision environment. For alert classification, relevant measures may include precision, recall, and calibration. For summarization, factual consistency, completeness, and omission rates become more important. For threat-intelligence extraction, entity-level accuracy and provenance may be critical. For investigative assistance, the usefulness and correctness of generated hypotheses may matter more than conventional classification metrics.

This task-specific perspective is consistent with the broader findings of the LLM-for-SOC literature. Habibzadeh et al. (2026) demonstrate that the research landscape contains a wide variety of proposed LLM applications but that evidence varies considerably across functions and levels of operational integration. The implication is that organizations should validate each intended use case against its own operational requirements rather than extrapolating from general model benchmarks.

Task-level evaluation should also account for the possibility that performance changes when AI systems are exposed to real operational data. Controlled benchmarks may not adequately represent incomplete telemetry, contradictory evidence, organizationally specific terminology, unusual incidents, or adversarially constructed inputs. This reinforces the need for evaluation using representative operational scenarios and continuous post-deployment monitoring rather than one-time pre-deployment testing (Hasanov et al., 2024; Habibzadeh et al., 2026).

7.4 Quality as a socio-technical property

Quality should also not be conceptualized as a property of the LLM alone. In operational cybersecurity, the resulting quality of an AI-supported process depends on the interaction between the model, data, retrieval architecture, software integrations, human analysts, organizational procedures, and governance controls.

A highly capable model operating on poor-quality or incomplete data may produce poor results. Conversely, a less capable model operating within a tightly controlled workflow may provide substantial operational value if its limitations are known and its outputs are appropriately validated. This supports a socio-technical understanding of AI quality in which the relevant unit of analysis is not necessarily the model but the AI-enabled workflow.

This perspective is consistent with contemporary approaches to AI governance, which increasingly recognize that accountability and risk arise from the interaction between technical systems and the organizational environments in which they are deployed (Chesterman et al., 2024; Swaminathan and Danks, 2024). Trustworthiness likewise depends on institutional arrangements, processes, and mechanisms for controlling AI rather than solely on model performance (Lahusen et al., 2024).

Such a perspective is particularly important for dedicated AI infrastructure. The value of controlling the infrastructure does not arise solely from running a particular model locally. It enables the organization to control the surrounding environment in which quality is produced: the data sources, retrieval mechanisms, model versions, security controls, monitoring systems, integration interfaces, and feedback processes.

Dedicated infrastructure can therefore support reproducibility and governance by providing greater control over model deployment and system configuration. However, it does not guarantee higher model accuracy. A poorly designed local deployment remains capable of producing unreliable outputs. Infrastructure sovereignty should consequently be understood as an enabler of controlled quality assurance rather than as evidence of quality itself.

This distinction is particularly important when evaluating the business case for dedicated AI infrastructure. The technical ability to retain data within an organizational environment can strengthen privacy and governance controls, but privacy-preserving infrastructure does not automatically produce trustworthy AI outputs. Data governance and model reliability are related but distinct dimensions of system quality (Liu et al., 2025; Ye et al., 2024).

7.5 Bounded autonomy and progressive automation

The distinction between automation and autonomy becomes particularly important as LLMs are increasingly connected to tools and operational systems. An AI system that can only produce a report has limited agency. An AI system that can query security infrastructure, execute commands, isolate endpoints, modify firewall rules, or communicate directly with customers has substantially greater agency and therefore requires stronger controls.

This suggests a model of bounded autonomy in which the authority granted to an AI system is explicitly limited according to the risk of the tasks it performs. Such an approach is consistent with risk-proportionate AI governance, where the potential consequences of system behavior determine the required level of oversight and control (Chesterman et al., 2024; Walter, 2024).

The principle developed in Chapter 5—minimum necessary agency—provides the architectural foundation for this approach. AI systems should have only the data access, permissions, and tool capabilities required for their approved tasks. Where an activity can be performed using read-only access, write access should not be granted. Where a recommendation can be generated without execution privileges, execution privileges should remain outside the model.

This principle is particularly important because generative AI systems can introduce new attack and misuse opportunities as well as defensive capabilities. Research on generative AI for penetration testing demonstrates the dual-use nature of these technologies: capabilities that can improve security testing can also create risks when placed in inappropriate operational contexts (Hilario et al., 2024). Consequently, increasing the agency of an LLM should be treated as a material change in the system's risk profile.

Automation can then increase progressively as evidence accumulates. Organizations may begin with information processing and summarization, progress toward contextual enrichment and investigative assistance, and only subsequently consider automated actions in narrowly defined and reversible situations. Each step should be supported by empirical evaluation and explicit risk acceptance.

This progression is preferable to an undifferentiated concept of “autonomous AI” because it recognizes that different cybersecurity activities have fundamentally different risk profiles. The appropriate question is not whether an organization trusts AI in general, but which AI capabilities it is prepared to trust for which purposes under which controls.

7.6 Preserving quality through human–AI complementarity

The objective of AI adoption should ultimately be to establish an effective division of labor between humans and machines. LLMs are particularly effective at processing large quantities of information, transforming unstructured content, retrieving relevant knowledge, and generating candidate interpretations. Human analysts remain essential for contextual judgment, handling ambiguity, understanding organizational consequences, challenging AI-generated conclusions, and accepting responsibility for consequential decisions (Hasanov et al., 2024; Habibzadeh et al., 2026).

This complementarity suggests that AI should be designed to make analysts more capable rather than merely faster. If automation simply increases the volume of AI-generated alerts, recommendations, or reports that analysts must verify, the resulting system may shift rather than reduce workload. Similarly, an AI system that produces opaque recommendations may reduce apparent effort while increasing cognitive and verification costs.

The quality objective should therefore include the human interaction cost of AI. A useful system should reduce the amount of effort required to reach a reliable conclusion, not merely reduce the time required to generate an initial answer.

This is particularly important in the context of alert fatigue. Automation that produces large numbers of low-confidence recommendations may exacerbate the very workload problem it is intended to solve. Effective AI augmentation should instead prioritize high-value information, expose relevant evidence, communicate uncertainty, and allow analysts to override or challenge model outputs. Alert fatigue and analyst workload are themselves among the principal motivations for LLM adoption in SOCs, meaning that poorly designed automation could undermine the original business objective (Habibzadeh et al., 2026).

The organizational dimension is equally important. Humphreys et al. (2024) caution that AI hype can itself become a cybersecurity risk when organizations adopt generative AI without adequately considering implementation responsibilities and associated risks. Consequently, the success of AI automation should not be measured by the number of processes converted to AI, but by whether the resulting human–AI system produces demonstrable operational improvement.

7.7 Measuring validated operational value

The effectiveness of AI automation should ultimately be demonstrated through measurable operational outcomes. Potential measures include reductions in analyst processing time, improvements in detection or investigation speed, reductions in repetitive workload, consistency of reporting, quality of threat-intelligence enrichment, and changes in escalation or resolution times. These measures correspond to the operational motivations identified in research on LLM adoption in SOCs, particularly the need to address workload, alert fatigue, skills constraints, and response speed (Habibzadeh et al., 2026).

These efficiency measures should be evaluated together with quality and risk indicators. A reduction in analyst workload is not necessarily beneficial if it results in lower detection quality. Similarly, faster incident response is not necessarily an improvement if automation increases erroneous containment actions.

The appropriate evaluation concept is therefore validated operational value, defined as the measurable improvement produced by AI after accounting for accuracy, human verification effort, security risk, and operational consequences.

This framing also supports a more rigorous economic evaluation of dedicated AI infrastructure. The relevant comparison is not simply the cost of local hardware against the cost of an external AI service. It should consider the total operational value generated by the architecture, including productivity gains, latency improvements, governance benefits, reduced external dependencies, and potentially reduced exposure of sensitive information. These benefits must then be weighed against infrastructure, maintenance, model operations, energy, security, and governance costs.

The privacy dimension is particularly relevant to this calculation. Generative AI systems may process personal, confidential, or commercially sensitive information, creating risks associated with data exposure and inappropriate processing (Liu et al., 2025; Ye et al., 2024). For organizations handling sensitive cybersecurity data, therefore, the value of infrastructure control may include governance and risk-reduction benefits that are not captured by simple measures of model throughput or processing cost.

Legal and regulatory considerations should similarly be incorporated into the evaluation. Generative AI introduces questions concerning liability, privacy, intellectual property, and cybersecurity, meaning that an apparently efficient automation architecture may create additional organizational obligations if its outputs are used in consequential contexts (Novelli et al., 2024). AI investment decisions should therefore consider not only whether automation is technically feasible, but whether the resulting system can be operated within the organization's legal, governance, and accountability framework.

Such an assessment provides a more defensible basis for investment decisions than the assumption that AI automation is inherently beneficial.

7.8 From automation to trustworthy automation

The central proposition of this chapter can therefore be formulated more precisely:

Trustworthy cybersecurity automation does not eliminate human control; it systematically constrains, validates, and monitors AI-generated activity according to the consequences of error.

This perspective connects automation directly to the AI-by-Design principles developed earlier. Data sovereignty determines where sensitive information can be processed. Infrastructure security protects the AI environment. Minimum necessary agency limits what the system can do. Deterministic controls constrain probabilistic behavior. Human oversight provides accountability for consequential decisions. Continuous monitoring provides evidence that the system continues to perform within its intended boundaries.

These principles reflect the broader evolution of AI governance from an emphasis on technological capability toward governance of the complete socio-technical system (Chesterman et al., 2024; Swaminathan and Danks, 2024). They also address the distinction between trust and trustworthiness identified by Lahusen et al. (2024): an organization should not simply expect users to trust an AI system, but should establish the technical and institutional conditions that justify such trust.

The resulting architecture replaces the simplistic objective of “automating as much as possible” with a more rigorous principle:

Automate what can be bounded, validate what can be measured, escalate what is consequential, and continuously reassess what is trusted.

Under this model, automation does not represent a transfer of responsibility from humans to machines. It represents a deliberate redistribution of work within a controlled socio-technical system. The LLM performs activities for which probabilistic generation provides a meaningful advantage, while deterministic mechanisms and human experts retain control where uncertainty or consequence makes unrestricted automation inappropriate.

This approach also provides a practical response to the risks associated with excessive confidence in generative AI. AI hype can encourage organizations to interpret technological capability as evidence of organizational readiness, while responsible deployment requires explicit consideration of implementation risks, accountability, and the consequences of failure (Humphreys et al., 2024). Trustworthy automation therefore requires evidence that extends beyond demonstrations or benchmark scores.

For AI-enabled cybersecurity services, this approach offers a more credible path toward the promise of increased efficiency without sacrificing quality. The objective is not to demonstrate that an LLM can perform a security task in isolation, but to demonstrate that an AI-enabled workflow can produce better or equivalent operational outcomes under controlled conditions. This distinction is particularly important because current research demonstrates considerable promise at the task level while providing more limited evidence for unrestricted end-to-end autonomous SOC operations (Habibzadeh et al., 2026).

The distinction is fundamental to the broader argument of the paper. Dedicated AI infrastructure provides the organizational control required to build such workflows, but infrastructure alone does not create trustworthy automation. Trust emerges from the interaction of controlled data flows, secure infrastructure, validated models, bounded agency, deterministic safeguards, human oversight, and continuous measurement (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

In this sense, automation without loss of quality is not a characteristic of the model; it is an architectural and governance achievement. It requires the organization to demonstrate that the complete AI-enabled process performs reliably within its intended operational boundaries. The resulting approach provides a foundation for progressive automation in which greater levels of AI agency are earned through evidence, validation, and controlled deployment rather than assumed from general-purpose model capability.

The ultimate objective is therefore not autonomous cybersecurity for its own sake. It is a SOC in which AI absorbs information-intensive and repetitive work, deterministic systems enforce explicit constraints, and human analysts retain authority over ambiguity, escalation, exception handling, and consequential decisions. Such an architecture offers a more defensible basis for achieving efficiency gains while preserving quality, accountability, security, and organizational control.

8. Compliance, Data Protection and AI Governance

8.1 Compliance as an architectural property

The proposition that an AI environment is “compliant” should not be understood as an intrinsic property of a particular deployment model, technology, or infrastructure location. Deploying an AI system on dedicated or on-premises infrastructure does not, by itself, establish compliance with data-protection, cybersecurity, or AI-governance requirements. Compliance emerges from the interaction between technical architecture, organizational processes, contractual arrangements, risk management, and applicable legal obligations. This broader understanding is consistent with contemporary AI-governance research, which emphasizes responsibility, governance scope, lifecycle timing, and implementation rather than treating governance as a set of abstract principles (Batool, Zowghi and Bano, 2025; Chesterman et al., 2024; Swaminathan and Danks, 2024).

This distinction is particularly important for AI-enabled cybersecurity because the relevant regulatory requirements extend across the complete lifecycle of data and AI systems. A model may be hosted entirely within an organization's premises while still being operated without appropriate access controls, retention policies, documentation, risk assessments, or mechanisms for responding to data-subject requests. Conversely, an externally hosted service may, under appropriate contractual and technical conditions, satisfy particular legal requirements. Infrastructure location therefore influences the organization's control environment, but it is not itself a legal compliance mechanism.

The AI-governance literature supports this broader interpretation. Batool, Zowghi and Bano (2025), in their systematic review of AI governance, identify responsibility, governance scope, lifecycle timing, and implementation as fundamental dimensions of effective AI governance. Their findings demonstrate that governance cannot be reduced to high-level principles: organizations must determine who is responsible, what is governed, when governance takes place, and how requirements are operationalized. This is consistent with the wider evolution of AI governance toward lifecycle-based and organizational approaches to accountability (Chesterman et al., 2024; Swaminathan and Danks, 2024).

For AI-enabled cybersecurity, this implies that compliance should be treated as an architectural and organizational capability. The organization must be able to identify the AI systems it operates, understand the information they process, establish ownership and accountability, assess risks, enforce access restrictions, monitor system behavior, manage suppliers and dependencies, and demonstrate that relevant controls operate throughout the AI lifecycle.

An effective governance framework should therefore maintain an inventory of AI systems and use cases and associate each system with a defined purpose, responsible owner, data categories, model and infrastructure dependencies, risk classification, and applicable regulatory requirements. This creates a practical connection between AI governance and the accountability principles identified in the literature (Batool, Zowghi and Bano, 2025; Chesterman et al., 2024). The inventory provides the foundation for determining which governance controls are necessary and prevents experimental or operational AI systems from developing outside established organizational oversight.

Data governance constitutes a second essential component. Data processed by an AI system should be classified according to its sensitivity, purpose, legal basis where applicable, customer or contractual restrictions, and permitted processing environment. This becomes particularly important for cybersecurity providers because AI systems may simultaneously process public threat intelligence, internal operational data, personal information, and highly confidential customer security information. Research on generative AI privacy emphasizes that the processing, retention, memorization, and potential exposure of sensitive information can create significant risks that need to be considered throughout the AI lifecycle (Liu et al., 2025). Ye et al. (2024) similarly emphasize the importance of privacy and personal-data risk governance in generative AI environments.

Risk assessment must similarly extend beyond conventional information-security risks. An AI use case may introduce risks associated with inaccurate outputs, hallucination, information leakage, prompt manipulation, excessive autonomy, model drift, inappropriate automation, and dependency on external model or infrastructure providers. The relevant risk assessment should therefore consider not only whether the AI system itself can be attacked, but also how an erroneous or manipulated AI output could affect the cybersecurity service (Hasanov et al., 2024; Hilario et al., 2024; Habibzadeh et al., 2026).

Model validation and lifecycle governance are equally important. Organizations should document the models deployed for material use cases, their versions, configurations, relevant evaluation results, intended operating conditions, and criteria for replacement or rollback. Model updates should be treated as potentially consequential changes because modifications to the underlying model or surrounding application can alter system behavior. This requirement is especially important when AI is integrated into operational security workflows where seemingly minor changes may affect alert interpretation, investigative recommendations, or automated actions (Rieger et al., 2026; Habibzadeh et al., 2026).

Access management must encompass both human and machine identities. The organization should be able to determine which users, services, models, and applications can access particular datasets or invoke particular AI capabilities. The principle of least privilege developed earlier in this paper is therefore also a governance requirement: AI systems should possess only those permissions necessary for their approved purpose. This principle supports both security and accountability because it limits the consequences of model error or compromise and creates clearer boundaries around responsibility (Chesterman et al., 2024; Swaminathan and Danks, 2024).

Logging and monitoring provide the evidentiary dimension of governance. An organization cannot credibly demonstrate control over an AI system if it cannot reconstruct its relevant activities. Depending on the use case and applicable requirements, this may include records of system access, model versions, configuration changes, data retrieval, tool invocation, significant prompts and outputs, human approvals, and security events. Such records support both compliance assurance and forensic investigation. The importance of documentation, logging, risk management, and lifecycle monitoring is also reflected in emerging European AI governance requirements (Novelli et al., 2024; Chesterman et al., 2024).

Supplier and dependency management are particularly relevant to AI because a single AI application may depend on numerous external components. These may include model providers, software libraries, cloud services, hardware manufacturers, support organizations, and data providers. Governance should therefore extend beyond the immediate AI application to the dependencies that determine where information is processed and who can potentially access or influence the system. This is consistent with the growing emphasis on supply-chain and dependency risk within cybersecurity governance frameworks.

Finally, governance requires explicit lifecycle procedures for incidents, retention, deletion, periodic review, and system retirement. An AI system should not remain indefinitely in operation merely because it has already been approved. Changes in models, data, regulations, threats, customers, or business processes can alter the risk profile of a use case and should trigger reassessment where appropriate. The lifecycle perspective is particularly important because AI systems can change through model updates, changes in retrieval sources, revised prompts, altered integrations, or changes in the surrounding operational environment (Batool, Zowghi and Bano, 2025; Chesterman et al., 2024).

These requirements lead to a fundamental distinction:

Compliance is not a property of AI infrastructure; it is a property of the controlled relationship between infrastructure, data, models, processes, people, and applicable legal obligations.

Dedicated infrastructure can nevertheless make that relationship easier to control. By reducing certain external processing dependencies, it may simplify the identification of data flows, administrative boundaries, and technical responsibilities. It can also facilitate centralized logging, access control, network segmentation, and infrastructure-level assurance. Its contribution is therefore best understood as compliance enablement, rather than compliance itself.

8.2 Swiss data protection

For a Swiss cybersecurity provider, the Federal Act on Data Protection (FADP/DSG) provides a central legal framework for AI-supported processing of personal data. The Swiss framework is technology-neutral: the Federal Data Protection and Information Commissioner (FDPIC) explicitly states that the FADP applies directly to AI-supported data processing. The use of AI therefore does not create an exemption from existing data-protection obligations; rather, organizations must apply the existing framework to the characteristics and risks of their AI-supported processing activities.

This technology-neutrality is important because it shifts attention from the question of whether an organization is “using AI” to the actual characteristics of the processing operation. The relevant assessment concerns which personal data is processed, for which purpose, under which legal conditions, by which actors, and with what technical and organizational safeguards. The FDPIC has specifically emphasized transparency concerning the purpose, functionality, and data sources involved in AI-based processing.

For AI-enabled cybersecurity, this can be complex because security operations frequently involve information that is highly contextual. User identifiers, IP addresses, authentication events, endpoint information, communications metadata, and incident records may constitute personal data depending on the circumstances. An LLM may then combine such information with organizational knowledge or external threat intelligence, potentially creating new processing operations that need to be understood and governed.

The Swiss data-protection framework therefore reinforces the principle established in the previous chapters that data flows must be explicitly designed and controlled. An organization should be able to identify what information enters an AI system, how it is transformed, which supporting systems receive it, where processing occurs, how long it is retained, and who can access the resulting information. This is particularly important where generative AI is used to combine information from multiple sources because the resulting processing may be broader or more complex than the individual source systems considered separately (Liu et al., 2025; Ye et al., 2024).

The FDPIC has emphasized the importance of transparency and appropriate risk assessment in connection with AI-supported processing. Under the FADP, a data protection impact assessment (DPIA) is required where planned processing is likely to result in a high risk to the personality or fundamental rights of data subjects. The FDPIC identifies the use of new technologies as one factor that can contribute to such risk, while emphasizing that the assessment must consider the nature, scope, circumstances, and purpose of the processing.

For an AI-by-Design architecture, the resulting governance questions can therefore be formulated more precisely:

What data is processed, for what purpose, under whose authority, by which AI system, within which processing environment, with which safeguards, and with what evidence that the resulting processing remains within the applicable legal and organizational boundaries?

Dedicated infrastructure can contribute to answering some of these questions by making the processing environment more directly controllable. If inference, storage, retrieval, logging, and supporting services operate within an organization-controlled environment, the organization may have greater visibility into processing locations and access paths. This can simplify certain aspects of data governance and risk assessment.

It does not, however, remove the substantive requirements of Swiss data protection. The organization remains responsible for determining the appropriateness of the processing, implementing required safeguards, respecting data-subject rights where applicable, and maintaining appropriate documentation and accountability. An on-premises model that processes excessive personal data for an undefined purpose is not rendered compliant merely because no data leaves the building.

The sovereignty argument developed earlier therefore complements rather than replaces Swiss data protection. Sovereignty increases the organization's ability to exercise control; data protection determines how that control should be exercised.

This distinction is particularly important because the Swiss regulatory position is explicitly not based on the assumption that AI requires an entirely separate data-protection regime. The FDPIC's current guidance instead confirms that existing data-protection law directly governs AI-supported processing, including requirements concerning transparency, control over personal data, and appropriate safeguards.

8.3 GDPR and European operations

The General Data Protection Regulation (GDPR) introduces a similarly lifecycle-oriented perspective for organizations processing personal data within its territorial scope. AI deployment can engage multiple GDPR principles, including lawfulness, fairness and transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability.

The central challenge is again that AI systems can create complex and sometimes distributed processing chains. A cybersecurity service may transmit information from a customer environment to an AI application, retrieve additional contextual information from internal knowledge repositories, invoke external services, store interaction records for monitoring, and subsequently use outputs in customer-facing processes. Each stage may create a distinct processing activity that needs to be understood from a data-protection perspective.

This reinforces the importance of data-flow mapping as an architectural governance mechanism. Organizations should know not only where the primary AI model is hosted, but also where prompts, retrieved documents, outputs, logs, evaluation data, backups, telemetry, and administrative information are processed. A claim that an AI system is “European-hosted” or “on-premises” is therefore insufficient without understanding the complete supporting architecture.

The emerging legal literature emphasizes precisely this complexity. Novelli et al. (2024) identify interconnected challenges involving privacy, cybersecurity, intellectual property, and liability in the governance of generative AI and highlight the difficulties created by the probabilistic and evolving characteristics of these systems. The implication is that AI governance cannot be reduced to a single regulatory question. Different legal obligations may apply simultaneously to the same AI-enabled service.

For organizations operating across Switzerland and the European Union, the distinction between Swiss and European processing environments is consequently important. A Swiss-based infrastructure strategy may reduce some cross-border data-transfer complexity for Swiss operations, but it does not automatically exclude the GDPR where the regulation applies. Conversely, processing data within the European Economic Area does not eliminate the need to establish appropriate governance, security, transparency, and accountability.

The GDPR also introduces specific considerations for automated decision-making and data-subject rights. Where AI systems influence decisions concerning individuals, organizations must assess whether the relevant processing engages provisions governing automated decision-making and ensure that applicable transparency and safeguards are provided. In cybersecurity operations, this issue is particularly relevant when AI-supported risk assessments, behavioral classifications, or automated prioritization could materially affect identifiable individuals.

The emergence of the EU AI Act adds another layer to the European regulatory environment. Regulation (EU) 2024/1689 establishes a risk-based framework whose obligations depend on the characteristics, intended purpose, and role of the relevant AI system. The Act addresses prohibited practices, high-risk systems, transparency requirements, general-purpose AI models, governance, and cybersecurity-related obligations.

Its significance for an organization therefore depends on the specific AI use case, its intended purpose, and the organization's role within the AI value chain. The existence of an internal or on-premises deployment does not, in itself, determine whether or how the AI Act applies. The regulatory analysis must instead consider what the system does, how it is supplied or deployed, and whether the relevant provisions apply to the organization in its particular role.

This reinforces a broader point:

Regulatory applicability follows the characteristics and use of the AI system, not simply the location of its infrastructure.

Dedicated infrastructure can nevertheless provide practical governance advantages. It can reduce the number of external processors or infrastructure operators involved in particular data flows, provide greater control over retention and deletion, and facilitate the implementation of technical and organizational measures. It can also simplify evidence generation for certain controls because the organization directly operates more of the relevant technology stack.

These advantages should be interpreted as reducing governance complexity, not as eliminating regulatory obligations. The organization must still establish lawful processing, appropriate safeguards, accountability, data-subject rights mechanisms where applicable, and appropriate contractual arrangements with relevant suppliers and processors.

The AI Act also reinforces the importance of lifecycle risk management for applicable systems. For high-risk AI systems, the Regulation requires a risk-management system that is established, implemented, documented, and maintained as a continuous iterative process throughout the system's lifecycle. This is closely aligned with the AI-by-Design approach developed in this paper, in which risk assessment, validation, monitoring, and reassessment are treated as continuing architectural and governance activities rather than one-time approval steps.

8.4 NIS2 and cybersecurity governance

The NIS2 Directive introduces a complementary perspective because its primary focus is not data protection but cybersecurity risk management and organizational resilience. Directive (EU) 2022/2555 establishes cybersecurity risk-management measures and reporting obligations for entities within its scope, with the broader objective of achieving a high common level of cybersecurity across the European Union.

For organizations within its scope, AI infrastructure should therefore be considered as part of the broader cybersecurity risk-management system where it supports or forms part of critical operational processes. The introduction of an LLM into a SOC does not create a separate category of cybersecurity compliance; rather, the AI component becomes another technology and dependency that must be incorporated into the organization's risk-management and security-control framework.

This is particularly important where AI is integrated directly with operational security systems. An LLM connected to SIEM, endpoint, orchestration, ticketing, or customer-management systems may become part of the organization's operational security architecture. Its availability, integrity, confidentiality, access controls, and supply-chain dependencies should consequently be considered within the broader cybersecurity risk assessment.

NIS2's emphasis on risk management and supply-chain security is particularly relevant to the sovereignty argument developed in this paper. An organization may have strong internal security controls while remaining dependent on external AI models, cloud services, software components, or infrastructure providers. These dependencies can introduce availability, confidentiality, integrity, and strategic risks that should be identified and managed as part of the organization's cybersecurity posture. The broader European cybersecurity framework similarly emphasizes the importance of supply-chain and dependency risks in assessing the security of ICT environments.

Dedicated AI infrastructure can mitigate some of these dependencies by bringing compute and inference under organizational control. It may also provide greater control over availability, patching, network segmentation, identity management, and operational monitoring. However, it simultaneously creates additional responsibilities. The organization becomes responsible for securing and maintaining the infrastructure itself, including hardware, virtualization, operating systems, model-serving software, and associated management components.

This creates an important trade-off:

Externalization can reduce operational responsibility while increasing dependency; internalization can increase control while increasing operational responsibility.

Neither architecture is inherently compliant or secure. The appropriate choice depends on the organization's risk appetite, capabilities, threat model, regulatory environment, and required degree of control.

For cybersecurity providers, the integration of AI into SOC processes also raises questions of resilience. If an AI service becomes operationally important, its failure should not result in an inability to perform essential security functions. AI-enabled workflows should therefore include appropriate fallback mechanisms, monitoring, service continuity arrangements, and procedures for operating without the AI component when necessary. This reflects the broader principle of progressive and risk-proportionate automation developed in Chapter 7.

This is especially relevant to the distinction between AI-assisted and AI-dependent security operations. An AI-assisted SOC can continue its core activities when the model is unavailable, although perhaps with reduced efficiency. An AI-dependent SOC may be unable to perform essential processes without the AI system. The latter creates a materially different operational risk and should be treated accordingly.

For organizations subject to NIS2, this distinction also has practical implications for business continuity and resilience. AI should therefore be incorporated into existing continuity, incident-response, and recovery planning rather than treated as an isolated innovation project.

8.5 From regulatory compliance to demonstrable control

Taken together, Swiss data protection, the GDPR, NIS2, and the emerging European AI regulatory framework illustrate that compliance is inherently multidimensional. Data-protection regimes emphasize lawful and proportionate processing, transparency, security, and individual rights. Cybersecurity regulation emphasizes risk management, resilience, incident handling, and organizational responsibility. AI governance adds requirements concerning the development, deployment, monitoring, and accountability of AI systems according to their characteristics and risk.

No single technical architecture can satisfy all of these requirements automatically. Dedicated AI infrastructure should therefore not be presented as a shortcut to compliance. Its more defensible role is to provide a controlled technical environment within which compliance requirements can be implemented and evidenced.

This distinction can be expressed as follows:

AI infrastructure can support compliance; governance processes establish compliance; evidence demonstrates compliance.

The first element concerns architecture. The organization must establish appropriate boundaries for compute, data, networks, models, identities, and external dependencies. The second concerns organizational governance: policies, ownership, risk assessments, approvals, procedures, monitoring, training, supplier management, and lifecycle controls. The third concerns assurance: logs, records, assessments, documentation, audit trails, test results, and other evidence demonstrating that controls have been implemented and remain effective.

The importance of evidence is particularly clear in emerging AI governance. For applicable high-risk AI systems, the EU AI Act explicitly links compliance to documentation, quality-management systems, logging, risk management, and conformity assessment rather than merely to the deployment environment (European Union, 2024).

This three-part distinction is particularly relevant to the concept of AI by Design. If compliance is considered only after deployment, organizations may discover that architectural choices have made certain requirements difficult or costly to implement. By contrast, if regulatory and governance requirements are translated into design constraints before deployment, the AI system can be constructed with appropriate data boundaries, access controls, logging, retention mechanisms, human-approval points, and dependency controls from the outset.

The resulting model is therefore not “compliance through on-premises AI”, but “compliance-enabled AI by Design.” Dedicated infrastructure can strengthen sovereignty and control; security engineering can protect the resulting environment; governance can assign responsibility and manage risk; and auditability can provide evidence that the resulting system operates within defined boundaries.

For a cybersecurity provider, this integrated approach is particularly important because the AI system and the service it supports may themselves become part of the organization's security and compliance perimeter. AI governance must therefore be integrated into existing information-security management, data-protection management, supplier governance, business continuity, and incident-response processes rather than operating as an isolated AI policy.

This integrated approach is also consistent with the broader literature on trustworthy AI. Lahusen et al. (2024) distinguish between trust and trustworthiness, emphasizing that confidence in AI should be supported by characteristics and governance arrangements that justify reliance. Tamò-Larrieux et al. (2024) similarly examine whether legal and regulatory mechanisms can establish trust in AI, highlighting the importance of institutional and regulatory conditions rather than technological performance alone.

The broader implication is that compliance should be treated as an emergent property of a governed socio-technical system. Neither geographical location, infrastructure ownership, model selection, nor certification is sufficient in isolation. Compliance arises when the organization can demonstrate that its AI systems are appropriately designed, operated, monitored, controlled, and reviewed in relation to the risks and obligations that apply to them.

This provides the final link between the concepts developed throughout this paper. Data sovereignty provides control over critical information flows; dedicated infrastructure provides technical control over important parts of the AI stack; AI by Design translates governance principles into architectural requirements; and compliance governance provides the organizational mechanisms through which those controls are maintained and demonstrated. Together, these elements form the basis for trustworthy and accountable AI-enabled cybersecurity services.

The resulting proposition is therefore stronger than the claim that local infrastructure is inherently more compliant. The defensible argument is that greater infrastructure control can provide an organization with stronger technical and evidentiary foundations for implementing compliance, provided that this control is embedded within appropriate governance, risk management, legal analysis, and operational processes. This distinction preserves the strategic value of dedicated AI infrastructure without overstating its legal significance.

9. AI Governance as a Trust Architecture

The strategic value of controlled AI infrastructure extends beyond confidentiality, data residency, or regulatory compliance. Its deeper significance lies in its potential contribution to trust. In the context of cybersecurity services, trust is not established merely by demonstrating that an AI system produces useful outputs. It depends on whether customers and other stakeholders can understand the conditions under which those outputs are produced, identify who controls the underlying systems, determine how sensitive information is processed, and establish who remains accountable when AI-supported decisions have consequences (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

This distinction is particularly important because cybersecurity services involve a fundamental delegation of responsibility. Customers provide a security provider with access to information about their systems, vulnerabilities, incidents, users, infrastructure, and defensive capabilities. When AI becomes part of the service-delivery architecture, customers are no longer delegating security operations only to human analysts and conventional information systems. They are also entrusting parts of the processing and analytical workflow to AI systems (Novelli et al., 2024; Habibzadeh et al., 2026).

The resulting trust relationship is therefore broader than trust in the model itself. A customer does not necessarily need to believe that an LLM is inherently reliable. Rather, the customer needs confidence that the organization has established sufficient controls to ensure that the model is used appropriately, that its limitations are understood, that sensitive information is protected, and that consequential outputs remain subject to appropriate validation and accountability. This is consistent with the emerging view that trustworthy AI is a socio-technical property rather than a characteristic that can be attributed to model performance alone (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

This interpretation is also consistent with the broader AI-governance literature, which increasingly conceptualizes trustworthy AI as a multidimensional socio-technical property involving technical robustness, privacy, security, transparency, accountability, human oversight, and organizational governance (Chesterman et al., 2024; Swaminathan and Danks, 2024; Lahusen, Maggetti and Slavkovik, 2024). Governance therefore extends beyond high-level ethical principles and requires mechanisms through which responsibilities, controls, risks, and lifecycle processes are operationalized (Chesterman et al., 2024; Swaminathan and Danks, 2024).

The concept of AI governance as a trust architecture developed in this paper builds on this perspective. Governance is not understood merely as a collection of policies that constrain AI after deployment. Instead, governance is embedded into the architecture through which data, models, infrastructure, people, and decisions interact. Such an interpretation reflects the broader evolution of AI governance from abstract principles toward institutional and technical mechanisms capable of making those principles operational (Chesterman et al., 2024; Swaminathan and Danks, 2024).

9.1 From technical trust to organizational trust

Trust in AI-enabled cybersecurity exists at several interconnected levels. At the technical level, stakeholders need confidence that the AI system is secure, sufficiently reliable for its intended purpose, and protected against unauthorized manipulation. At the data level, they need confidence that information is processed only for authorized purposes and within appropriate boundaries. At the operational level, they need confidence that AI outputs are appropriately validated and that consequential decisions are not delegated beyond the system's demonstrated capabilities. At the organizational level, they need confidence that responsibility has been assigned and that failures can be investigated and addressed (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

These dimensions are interdependent. A highly accurate model does not establish trust if the organization cannot explain where customer data is processed. Conversely, an extremely well-governed infrastructure does not establish operational trust if the AI produces unreliable recommendations that analysts routinely accept without verification. Trustworthiness therefore emerges from the relationship between capability and control, rather than from technical capability in isolation (Lahusen, Maggetti and Slavkovik, 2024).

This is an important distinction from conventional perceptions of AI reliability. The question is not whether the model can always be trusted to produce the correct answer. Given the probabilistic nature of LLMs, such an assumption would be difficult to justify for many cybersecurity applications. Research on generative AI in cybersecurity identifies reliability, hallucination, and incorrect or misleading outputs as continuing concerns, particularly where generated information can influence security decisions (Hasanov et al., 2024; Hilario et al., 2024; Habibzadeh et al., 2026).

The more defensible objective is therefore to design the surrounding system so that model uncertainty is recognized, bounded, observable, and appropriately managed. In this sense, trustworthy AI does not require eliminating uncertainty. It requires governing uncertainty. This is consistent with the broader governance literature, which treats trustworthiness as dependent not only on system capabilities but also on institutional mechanisms for managing limitations, risks, and accountability (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

9.2 Demonstrable control as the foundation of trust

For cybersecurity service providers, trust must ultimately be demonstrable. Customers should not have to rely exclusively on generalized statements such as “AI is secure,” “data remains in Switzerland,” or “the system is compliant.” Instead, the provider should be able to explain the relevant architecture and governance mechanisms in terms that can be independently assessed. This emphasis on demonstrable governance is consistent with the broader shift from principle-based AI governance toward mechanisms for implementation, monitoring, and accountability (Chesterman et al., 2024; Swaminathan and Danks, 2024).

The fundamental questions are therefore architectural as well as organizational:

Where is customer data processed? Who can access it? Which models process it? What external dependencies are involved? Is customer information used for model training or improvement? Which controls constrain the model? How are outputs validated? Which actions can the AI system perform? What information is logged? How are model and system changes governed? What happens when the AI is wrong? And who retains responsibility for consequential decisions?

The ability to answer these questions is itself an important component of trust. Research on trust and AI governance emphasizes that confidence in AI depends not simply on performance but also on the ability to understand and assess the governance arrangements surrounding its use (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

This leads to a distinction between assumed control and demonstrable control. An organization may assume that a cloud service does not retain customer prompts, for example, but meaningful governance requires contractual, technical, or audit mechanisms through which this assumption can be substantiated. Similarly, an organization may state that an AI system is subject to human oversight, but the claim becomes significantly stronger when approval mechanisms, audit logs, and operational procedures demonstrate how that oversight actually functions (Chesterman et al., 2024; Swaminathan and Danks, 2024).

Dedicated AI infrastructure can strengthen this demonstrability because the organization directly controls a larger portion of the processing environment. Infrastructure ownership can make network boundaries, access privileges, storage locations, model-serving components, logging, and administrative operations more directly observable and governable. However, this should be understood as a governance advantage rather than proof of trustworthiness in itself. The literature on AI governance emphasizes that effective governance depends on the combination of technical and organizational controls rather than on infrastructure choices alone (Chesterman et al., 2024; Lahusen, Maggetti and Slavkovik, 2024).

This does not mean that on-premises infrastructure is inherently more trustworthy. Rather, it can increase the organization's capacity to demonstrate control, provided that appropriate governance and security mechanisms are implemented.

9.3 Transparency without exposing sensitive architecture

Trust architecture also requires an appropriate interpretation of transparency. Complete technical transparency is neither always possible nor always desirable in cybersecurity. Revealing detailed defensive configurations, detection mechanisms, model-security controls, or infrastructure architecture could itself create security risks. The objective should therefore be meaningful transparency, in which stakeholders receive sufficient information to assess the governance and risk characteristics of an AI system without requiring disclosure of information that would compromise security.

Transparency, accountability, and explainability are recurring dimensions of trustworthy AI governance (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024). Customers should therefore be provided with sufficient information to understand how their data and security operations are treated without requiring the provider to expose information that would compromise the security of the service. This can include information concerning data-processing locations, categories of processed information, model governance, retention policies, access controls, human-approval mechanisms, security controls, and relevant assurance processes.

For higher-assurance environments, transparency can be strengthened through evidence rather than disclosure of sensitive implementation details. Audit records, control assessments, certifications, independent evaluations, documented procedures, and appropriately scoped assurance reports can provide evidence that governance mechanisms operate as intended. This approach is consistent with the broader understanding of accountability as requiring mechanisms through which AI practices can be examined and assessed rather than relying exclusively on declarations of responsible use (Chesterman et al., 2024; Swaminathan and Danks, 2024).

This approach is particularly relevant to AI because model behavior can otherwise be difficult for external stakeholders to assess. A customer may not be able to inspect the internal reasoning of an LLM, nor should model-generated explanations automatically be treated as faithful representations of its internal computational process. Trust should instead be established through the observable architecture surrounding the model: the information supplied to it, the permissions it possesses, the controls applied to its outputs, and the records generated during its operation (Hasanov et al., 2024; Lahusen, Maggetti and Slavkovik, 2024).

9.4 Accountability in AI-enabled cybersecurity

Trust also requires a clear allocation of responsibility. One of the risks associated with increasingly autonomous AI systems is the possibility of creating an accountability gap in which responsibility for an outcome becomes difficult to assign. An organization cannot reasonably attribute a consequential security decision simply to “the AI.” The governance literature identifies responsibility and accountability as fundamental elements of effective AI governance, particularly as AI systems become increasingly integrated into organizational decision-making (Chesterman et al., 2024; Swaminathan and Danks, 2024).

The responsibility for deploying and governing the AI system remains with the organization operating the service. This does not mean that every AI-supported action must be manually performed by a human. Rather, it means that the organization must define who is accountable for the design, approval, operation, monitoring, and review of the AI-enabled process (Lahusen, Maggetti and Slavkovik, 2024; Swaminathan and Danks, 2024).

This principle is particularly important for cybersecurity providers because customers may reasonably expect the provider to retain responsibility for the quality of the service even when AI performs substantial parts of the underlying workflow. The distinction between execution and accountability is therefore essential. An LLM may execute a classification, generate a recommendation, retrieve information, or prepare a report, while accountability for the process remains assigned to the responsible organization and its designated roles.

This provides another justification for the bounded-autonomy model developed earlier. Research on LLMs in cybersecurity identifies significant potential for automation while simultaneously emphasizing reliability, security, and governance limitations that constrain unrestricted autonomy (Hasanov et al., 2024; Hilario et al., 2024; Habibzadeh et al., 2026). By separating AI-generated recommendations from consequential actions, organizations can preserve clear responsibility even as automation increases.

9.5 Trust and auditability

Auditability provides the bridge between governance and trust. If an AI-supported cybersecurity service can reconstruct what information was processed, which model was used, which permissions were available, what outputs were generated, which validation mechanisms were applied, and whether a human approved a consequential action, then the organization can provide substantially stronger evidence of responsible operation. Auditability is therefore closely connected to the accountability and implementation dimensions of AI governance (Chesterman et al., 2024; Swaminathan and Danks, 2024).

This does not require recording every possible internal model state. Rather, the objective is to establish an appropriate operational audit trail. Such an audit trail may include model and application versions, access events, relevant data sources, retrieval activity, tool invocations, policy decisions, significant configuration changes, validation results, and human approvals. The precise level of logging should remain proportionate to the sensitivity and risk of the use case and should itself comply with applicable data-protection and security requirements (Novelli et al., 2024; Liu et al., 2025).

Auditability has two complementary functions. First, it supports accountability by allowing an organization to establish what happened after an incident or disputed decision. Second, it supports continuous improvement by allowing recurring errors, inappropriate automation, or unexpected system behavior to be identified and corrected. These functions are consistent with the lifecycle-oriented approach to AI governance, in which monitoring and reassessment remain necessary after deployment rather than governance ending at initial approval (Chesterman et al., 2024; Swaminathan and Danks, 2024).

In this respect, auditability should not be regarded merely as a compliance burden. It is a mechanism for making AI systems operationally governable.

9.6 Sovereignty as demonstrable control

The preceding chapters have deliberately distinguished data residency from data sovereignty. The trust perspective developed here extends this distinction further.

Data residency answers the question:

Where is the data?

Data sovereignty asks:

Who has meaningful control over the data and its processing?

A trust architecture adds a third question:

Can that control be demonstrated and audited?

This produces a more comprehensive understanding of sovereignty. Sovereignty is not simply the ability to keep information inside a geographical boundary. Nor is it merely the ownership of physical infrastructure. It is the organizational ability to determine and demonstrate what happens to information, models, and processing activities throughout the AI lifecycle. This interpretation is consistent with the broader governance literature, which treats control, accountability, organizational responsibility, and lifecycle management as interconnected dimensions of AI governance (Chesterman et al., 2024; Lahusen, Maggetti and Slavkovik, 2024).

Under this interpretation, sovereignty encompasses control over processing location, access, model execution, software and model updates, external dependencies, logging, retention, deletion, and auditability. It also encompasses the ability to impose and enforce organizational policies over these dimensions.

Dedicated AI infrastructure can contribute significantly to this capability because it places critical parts of the AI processing chain within an environment directly controlled by the organization. But the ultimate objective is not physical possession of servers. The objective is effective and demonstrable control over the AI system and its data flows.

This distinction prevents the sovereignty argument from becoming purely technological. An organization can own its hardware while lacking control over proprietary model updates, external telemetry, software dependencies, or administrative access. Conversely, a well-governed service can establish strong controls across externally operated infrastructure. Sovereignty should therefore be evaluated according to the actual control relationships in the system rather than according to infrastructure ownership alone. This broader interpretation is consistent with the literature distinguishing trust and trustworthiness from simple technical or infrastructural characteristics (Lahusen, Maggetti and Slavkovik, 2024).

9.7 Trust as a competitive and operational capability

For cybersecurity providers, this trust architecture has implications beyond regulatory compliance. The ability to demonstrate controlled AI processing can become an important component of service differentiation as customers become increasingly concerned about how AI is incorporated into security operations. Trust has therefore both a governance function and a potential strategic value (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

Customers may be willing to adopt AI more readily when they can establish that sensitive security information remains within explicitly defined processing boundaries, that AI systems are governed by documented controls, and that human accountability remains intact. This is particularly relevant to organizations operating in regulated or security-sensitive environments, where uncertainty concerning data handling, third-party dependencies, and AI decision-making may create barriers to adoption (Novelli et al., 2024; Walter, 2024).

For such customers, the decision to use an AI-enabled cybersecurity service is not simply an evaluation of model performance. It is an evaluation of whether the provider's entire AI operating model is sufficiently trustworthy for the sensitivity and consequences of the service. This broader conception of trust is consistent with research emphasizing that AI governance encompasses technical, organizational, legal, and societal dimensions rather than model performance alone (Chesterman et al., 2024; Lahusen, Maggetti and Slavkovik, 2024).

The resulting value proposition is therefore broader than improved efficiency. Controlled AI infrastructure can contribute simultaneously to operational performance, security assurance, regulatory governance, and customer confidence. However, this proposition should not be overstated. Trust cannot be created through infrastructure architecture alone. Customers may also require evidence concerning model performance, security testing, governance maturity, incident management, supplier dependencies, and organizational accountability.

The trust architecture must therefore integrate technical, organizational, and evidentiary mechanisms.

9.8 AI governance as an integrated architecture

The concepts developed throughout this paper can now be brought together into a single model.

Data sovereignty establishes controlled boundaries around sensitive information. Dedicated infrastructure provides direct control over critical components of the computational environment. AI by Design translates privacy, security, sovereignty, accountability, and human oversight into architectural requirements. AI-augmented SOC operations translate these capabilities into operational value. Validated automation constrains probabilistic model behavior through deterministic controls, human oversight, and continuous evaluation. Governance and compliance provide the organizational processes through which these controls are assigned, maintained, and demonstrated (Chesterman et al., 2024; Swaminathan and Danks, 2024; Habibzadeh et al., 2026).

Trust emerges from the interaction of these elements. This suggests that AI governance should not be treated as an additional management layer placed above the technology. It should be understood as an architecture of control spanning the entire AI-enabled service. Governance determines who is responsible; infrastructure determines where and how processing occurs; security controls determine who and what can interact with the system; model governance determines which AI capabilities are permitted; workflow controls determine how outputs influence operations; and auditability provides evidence that the resulting system behaves within its intended boundaries (Chesterman et al., 2024; Lahusen, Maggetti and Slavkovik, 2024).

The resulting conceptual relationship can be stated as:

Sovereignty provides control, security protects control, governance directs control, auditability demonstrates control, and accountability gives control organizational meaning.

This formulation also clarifies the role of dedicated AI infrastructure within the broader argument of this paper. Its strategic value does not derive simply from avoiding public cloud services or keeping data within national borders. Its value lies in enabling an organization to construct a more controllable, observable, and auditable AI processing environment. Such control can be particularly significant where cybersecurity services process sensitive personal, operational, or customer information and where AI systems interact with multiple internal and external dependencies (Liu et al., 2025; Novelli et al., 2024).

The objective is therefore not AI without risk, which would be unrealistic, but AI with governable risk. The governance literature supports this shift from the pursuit of abstractly “trustworthy” technology toward mechanisms through which risks can be identified, assigned, monitored, and controlled throughout the AI lifecycle (Chesterman et al., 2024; Swaminathan and Danks, 2024).

A trustworthy AI-enabled cybersecurity service is consequently one in which stakeholders can establish not only that the AI produces useful results, but also that the organization understands the system's limitations, controls its data flows, constrains its agency, validates its outputs, monitors its behavior, and retains responsibility for consequential outcomes (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

This leads to the central proposition of the chapter:

Trustworthy AI is not produced by the model alone. It emerges from the demonstrable alignment of data, infrastructure, models, security controls, organizational governance, human oversight, and accountability.

From this perspective, sovereignty is ultimately a trust capability. The ability to retain sensitive information within defined boundaries is important, but the deeper benefit is the ability to explain and demonstrate how that information is processed. For cybersecurity providers entrusted with highly sensitive customer environments, this ability to explain, control, and audit AI-supported operations may become as important as the computational capabilities of the models themselves. This follows the broader literature's treatment of trustworthiness as dependent on institutional arrangements surrounding AI rather than solely on technical performance (Lahusen, Maggetti and Slavkovik, 2024; Tamò-Larrieux et al., 2024).

The concept of AI by Design therefore reaches beyond privacy or security by design. It represents an architectural approach in which trust requirements are incorporated into the system before AI becomes operationally embedded. Under such an approach, sovereignty is designed rather than asserted, security is engineered rather than assumed, compliance is governed rather than claimed, and trust is supported by evidence rather than expectation.

This provides the conceptual foundation for the concluding discussion: the strategic significance of dedicated AI infrastructure lies not simply in where AI runs, but in whether the resulting architecture enables controlled, accountable, measurable, and demonstrably trustworthy AI-enabled cybersecurity.

10. Organizational and Strategic Implications

The adoption of dedicated AI infrastructure has implications that extend beyond the technical architecture of AI-enabled cybersecurity services. Once LLMs become embedded in security operations, the underlying infrastructure, data, models, workflows, and governance mechanisms collectively become part of the organization's strategic capability. The relevant strategic question is therefore not simply whether an organization should deploy an LLM, but whether it should develop the organizational capabilities required to control, integrate, evaluate, and continuously improve AI as part of its core cybersecurity service model. This broader understanding is consistent with contemporary AI-governance research, which increasingly treats AI deployment as a lifecycle and organizational governance challenge rather than as a purely technical implementation problem (Chesterman et al., 2024; Swaminathan & Danks, 2024).

This distinction is important because access to general-purpose foundation models is increasingly becoming commoditized. If competing organizations can obtain access to similar underlying models, access to the model itself is unlikely to constitute a durable source of competitive advantage. Strategic differentiation is more likely to emerge from the organization's ability to combine models with proprietary data, domain expertise, security workflows, operational experience, and governance mechanisms. This reflects the broader evolution of AI governance, in which organizational control, implementation capability, and the surrounding socio-technical environment increasingly determine the value and risks associated with AI systems (Chesterman et al., 2024; Walter, 2024).

The cybersecurity literature increasingly supports this broader interpretation. The recent survey by Habibzadeh et al. (2026) identifies not only the expanding range of LLM applications across SOC activities, but also the importance of infrastructure, data confidentiality, integration with existing security systems, reliability, and responsible deployment. Their findings reinforce the view that successful LLM adoption is not primarily a question of selecting the most capable model, but a systems-integration and organizational-capability problem (Habibzadeh et al., 2026).

10.1 Reducing strategic dependency

One of the most immediate strategic implications of dedicated AI infrastructure is a potential reduction in dependency on external AI platform providers. Organizations that rely entirely on externally hosted models may become dependent on the provider's pricing structure, availability, technical roadmap, model-access policies, contractual conditions, and geographic processing arrangements. Such dependencies are increasingly relevant to AI governance because AI systems are embedded within wider technical and organizational ecosystems rather than operating as isolated technologies (Chesterman et al., 2024; Walter, 2024).

Such dependencies are not necessarily problematic. External AI platforms can provide substantial advantages in terms of scalability, access to state-of-the-art models, operational simplicity, and reduced infrastructure-management requirements. However, dependency becomes strategically significant when AI functionality is integrated into business-critical cybersecurity processes. The more extensively AI is embedded in operational workflows, the greater the potential consequences of changes in external model availability, functionality, or provider conditions (Habibzadeh et al., 2026).

If a provider changes its pricing model, retires a model, modifies service conditions, changes data-processing arrangements, introduces substantial behavioral changes through model updates, or experiences an extended outage, a dependent cybersecurity organization may have limited ability to respond independently. These concerns are consistent with broader AI-governance discussions concerning technological dependency, lifecycle management, and the governance of rapidly evolving AI ecosystems (Chesterman et al., 2024; Walter, 2024).

Dedicated infrastructure can reduce some of these dependencies by allowing the organization to operate selected models within an environment under its own operational control. This creates greater freedom to determine which models are deployed, when they are updated, how they are configured, and under which conditions they are replaced.

This does not eliminate vendor dependency. Local AI infrastructure may itself depend on hardware manufacturers, model developers, open-source projects, software frameworks, and specialized support providers. Indeed, bringing infrastructure in-house can shift dependency rather than eliminate it. The strategic objective should therefore be understood as dependency diversification and controllability, rather than complete technological independence.

This distinction is consistent with the broader sovereignty argument developed in this paper. Strategic sovereignty does not mean that an organization must produce every component itself. Rather, it means that the organization retains sufficient control and optionality over critical capabilities to avoid unacceptable dependencies. For cybersecurity providers, this can be particularly valuable where AI becomes embedded in customer-facing security services. The ability to maintain service continuity despite changes in a particular external AI platform can become part of the organization's operational resilience.

10.2 From model access to capability integration

A second strategic implication concerns the source of competitive advantage.

General-purpose LLMs provide increasingly broad capabilities in language understanding, reasoning, information transformation, and code generation. However, these capabilities are available to many organizations. Consequently, the strategic value of AI is unlikely to reside primarily in possessing access to a particular model. Research on generative AI governance similarly emphasizes that organizational outcomes depend on how AI technologies are embedded within institutional, technical, and governance structures rather than on model capability alone (Chesterman et al., 2024; Swaminathan & Danks, 2024).

Instead, advantage may emerge from the organization's ability to integrate several complementary assets:

models + proprietary data + security workflows + organizational expertise + governance.

The model provides general computational capability. Proprietary or organization-specific data provides context. Security workflows determine how the capability is operationalized. Domain expertise determines which outputs are meaningful and how they should be interpreted. Governance determines where the technology can safely be used and under what conditions. The importance of this combination follows from the socio-technical nature of trustworthy AI, in which technical capability and organizational controls jointly influence outcomes (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

This combination is particularly relevant to cybersecurity because security operations are highly contextual. An LLM may have broad knowledge of cybersecurity concepts, but effective operational use requires access to information about specific customers, assets, vulnerabilities, historical incidents, detection logic, organizational policies, and threat environments. The growing literature on LLMs in SOCs demonstrates that practical value depends on integration with security data and operational workflows rather than on generic language capability alone (Habibzadeh et al., 2026; Rieger et al., 2026).

A cybersecurity provider can therefore create value by building AI systems that are deeply integrated with its existing knowledge and operational processes. Retrieval-augmented generation, for example, can connect a general-purpose model to controlled internal knowledge sources, enabling the system to answer questions using organization-specific information without requiring that information to become part of the model's general training process. This is consistent with the broader privacy and security concerns surrounding generative AI systems, particularly where sensitive organizational information is involved (Liu et al., 2025; Novelli et al., 2024).

The strategic value lies not merely in the retrieval architecture itself, but in the resulting combination of general model capability and proprietary operational context.

This also explains why data sovereignty has strategic significance beyond regulatory compliance. If sensitive organizational knowledge can be used within a controlled AI environment, the organization can potentially develop AI-enabled capabilities around information that would be difficult or inappropriate to expose to external model platforms. The result is a transition from AI as a generic technology resource to AI as an organizational knowledge capability.

10.3 Proprietary knowledge and organizational learning

The strategic importance of internal knowledge is further reinforced by the dynamic nature of cybersecurity. Threat actors, vulnerabilities, attack techniques, defensive mechanisms, and customer environments continuously change. Static access to a general-purpose model therefore provides only part of the required capability. Research on LLM-supported cybersecurity similarly emphasizes the need to integrate models with current security information and domain-specific knowledge rather than relying exclusively on pretrained model knowledge (Habibzadeh et al., 2026; Rieger et al., 2026).

An effective cybersecurity AI system should be able to incorporate current organizational knowledge while maintaining appropriate controls over its provenance and quality. Internal incident histories, detection engineering knowledge, threat-intelligence relationships, customer-specific context, operational procedures, and lessons learned can become valuable resources for AI-supported analysis.

This creates a potential feedback mechanism in which AI becomes part of organizational learning. Analysts use AI to process information and generate candidate insights; validated outcomes can then improve knowledge repositories, workflows, evaluation datasets, and future AI-supported processes. Such feedback mechanisms are consistent with the lifecycle-oriented understanding of AI governance, in which AI systems and their surrounding knowledge and governance structures are continuously monitored and adapted (Chesterman et al., 2024; Swaminathan & Danks, 2024).

However, this feedback loop must be carefully governed. Automatically feeding AI-generated outputs back into organizational knowledge without validation can propagate hallucinations or analytical errors. Research on generative AI privacy, reliability, and cybersecurity highlights the broader risks associated with inaccurate or uncontrolled model outputs and information propagation (Hasanov et al., 2024; Liu et al., 2025). Organizational learning therefore depends on distinguishing generated information from validated knowledge.

The architecture developed in Chapter 7 is consequently relevant at the strategic level. Validation is not only a mechanism for preventing operational errors; it is also a mechanism for protecting the organization's knowledge base from contamination.

Over time, this can become an important source of differentiation. Competitors may have access to similar foundation models, but they may not possess the same combination of historical security knowledge, validated workflows, evaluation data, customer-specific expertise, and accumulated experience in deploying AI safely. The resulting advantage is therefore more closely associated with organizational learning and accumulated capability than with model ownership alone.

10.4 Controlled experimentation as an organizational capability

Dedicated AI infrastructure can also change how organizations experiment with AI.

Early enterprise AI experimentation often occurs through publicly accessible AI platforms because they offer low barriers to entry. This facilitates rapid experimentation but can create challenges when experiments involve sensitive security information. Analysts may face uncertainty concerning data retention, external processing, model training, logging, or third-party access. These concerns are consistent with the broader privacy, security, and governance risks identified in research on generative AI systems (Liu et al., 2025; Novelli et al., 2024).

A controlled internal environment can provide a different experimentation model. Security teams can test alternative models, prompts, retrieval strategies, evaluation methods, and workflow integrations within defined technical and governance boundaries. This can accelerate organizational learning because experimentation becomes less dependent on whether sensitive information is permissible for use with an external service.

At the same time, internal experimentation should not be interpreted as inherently risk-free. Development environments can themselves contain sensitive data and may introduce vulnerabilities if access controls, model isolation, logging, and lifecycle management are inadequate. AI governance research therefore emphasizes that governance should extend across the AI lifecycle, including experimentation and development rather than only production deployment (Chesterman et al., 2024; Swaminathan & Danks, 2024).

The relevant strategic capability is therefore not simply the ability to experiment locally, but the ability to experiment safely and systematically.

This requires an evaluation infrastructure in which AI systems can be benchmarked against representative security tasks, failure cases can be analyzed, model changes can be compared, and deployment decisions can be based on evidence rather than enthusiasm. The need for task-specific evaluation is particularly important in SOC environments because research indicates substantial variation in LLM performance across different security functions (Habibzadeh et al., 2026; Rieger et al., 2026).

Such an environment can establish an internal AI engineering capability that extends beyond individual models. The organization develops knowledge about which models perform well for which tasks, how retrieval strategies affect results, where hallucinations occur, which prompts are robust, how models behave under adversarial inputs, and where human intervention remains necessary. The accumulation of this knowledge can itself become a strategic asset.

10.5 AI infrastructure as an organizational capability

These developments suggest that dedicated AI infrastructure should not be conceptualized merely as an IT investment. Once AI becomes operationally embedded, infrastructure becomes part of a broader organizational capability involving architecture, cybersecurity, data engineering, model operations, AI evaluation, governance, and domain expertise. This interpretation is consistent with governance research that treats AI implementation as a multidimensional organizational process involving responsibilities, lifecycle management, and implementation mechanisms (Chesterman et al., 2024; Swaminathan & Danks, 2024).

This creates new requirements for organizational structure and skills. Cybersecurity teams need to understand not only conventional security technologies but also model behavior, retrieval architectures, prompt and tool security, evaluation methodology, and AI-specific failure modes. Infrastructure teams need capabilities in model serving, accelerator management, software dependencies, capacity planning, and secure deployment. Governance functions need to understand how AI use cases alter existing privacy, security, and compliance processes.

The organizational consequence is therefore a form of capability convergence between cybersecurity, infrastructure engineering, data management, and AI governance. This convergence reflects the socio-technical character of trustworthy AI, where technical robustness, privacy, security, accountability, human oversight, and organizational governance interact rather than operate independently (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

This is especially important because the boundaries between these disciplines become less distinct when AI is integrated directly into security operations. An LLM used by a SOC is simultaneously a software component, a data-processing system, an analytical tool, a potential security interface, and a governance object.

Organizations that manage these dimensions independently may therefore encounter coordination problems. Conversely, organizations that establish integrated AI operating models may be better positioned to translate technical capabilities into reliable operational services.

10.6 Infrastructure ownership and innovation capacity

Infrastructure control can also affect the organization's ability to innovate. When an AI system depends entirely on an external platform, experimentation is constrained by the interfaces, models, capabilities, rate limits, policies, and update cycles provided by that platform. Such dependencies form part of the broader governance and strategic challenges associated with rapidly evolving AI ecosystems (Chesterman et al., 2024; Walter, 2024).

A controlled environment can provide greater freedom to evaluate different model architectures, serving strategies, quantization approaches, retrieval mechanisms, security controls, and workflow designs. This is particularly relevant for specialized cybersecurity applications where the optimal solution may not always be the largest or most general-purpose model.

The organization can instead optimize for the requirements of individual tasks. Some applications may benefit from larger models with stronger reasoning capabilities, whereas others may be better served by smaller, faster, or more specialized models. Research on LLM-supported SOC operations likewise indicates that different cybersecurity tasks exhibit different requirements and performance characteristics (Habibzadeh et al., 2026; Rieger et al., 2026).

This supports a broader principle of model pluralism. An organization does not necessarily need to standardize on a single LLM. Different models may be appropriate for different security tasks, provided that their use is governed, evaluated, and secured consistently.

Such an approach also reduces the risk of treating a model as a permanent strategic dependency. Models can be evaluated and replaced as capabilities evolve, provided that the surrounding application architecture separates business logic, security controls, retrieval systems, and governance mechanisms from any individual model. This reflects the lifecycle-oriented approach to AI governance identified in contemporary governance research (Chesterman et al., 2024; Swaminathan & Danks, 2024).

In this sense, the strategic asset is not ownership of a particular model. It is the organization's ability to operate and govern a changing portfolio of models.

10.7 The economics of control

Dedicated infrastructure also introduces an important economic trade-off. On-premises AI requires capital investment in compute, accelerators, storage, networking, power, cooling, maintenance, security, and specialized expertise. It may also involve substantial operational complexity.

The strategic case for such infrastructure should therefore not be based on an assumption that local AI is universally cheaper than external AI services. Depending on utilization, model size, hardware lifecycle, energy costs, staffing, and workload characteristics, external services may remain economically attractive for many use cases.

The economic value of dedicated infrastructure is broader than direct inference cost. It can include reduced dependency risk, greater control over sensitive data, improved predictability of service availability, lower processing latency for certain workloads, experimentation capabilities, and the ability to build organization-specific AI capabilities. These considerations are consistent with broader analyses of AI development, regulation, and socioeconomic consequences, which emphasize that the effects of AI adoption extend beyond direct technological performance (Walter, 2024).

These benefits are difficult to capture through conventional infrastructure accounting because some represent option value rather than immediate cost savings. For example, an organization-controlled AI environment may allow the organization to develop new AI-enabled services or respond more quickly to changes in external AI providers.

The investment decision should therefore consider total cost of ownership together with strategic value and risk reduction. This is particularly relevant for cybersecurity providers because the cost of a loss of confidentiality, service interruption, or regulatory failure may be substantially greater than the direct cost of AI inference.

The appropriate economic question is consequently not:

Is local AI cheaper than cloud AI?

but rather:

Does the additional control, resilience, sovereignty, and innovation capacity generated by dedicated infrastructure justify its total lifecycle cost for the organization's risk and strategic position?

This framing is consistent with the broader argument that AI adoption should be evaluated according to organizational and socioeconomic consequences rather than technological capability alone (Walter, 2024).

10.8 Organizational resilience and strategic autonomy

The preceding considerations converge on the concept of strategic autonomy.

Strategic autonomy does not imply complete technological independence. Modern technology ecosystems are too interconnected for most organizations to control every component of an AI stack. Rather, autonomy refers to the ability to make and execute critical strategic decisions without being exposed to unacceptable dependencies. This interpretation is consistent with broader discussions of AI governance and the strategic implications of increasingly interconnected AI ecosystems (Chesterman et al., 2024; Walter, 2024).

For an AI-enabled cybersecurity provider, relevant dimensions include the ability to determine where sensitive data is processed, which models are used, how models are updated, which external providers are trusted, how AI capabilities are integrated into customer services, and how operations continue if a particular AI dependency becomes unavailable.

Dedicated infrastructure can strengthen this autonomy by bringing critical components under organizational control. Combined with model portability, open standards, internal expertise, and strong governance, it can provide a degree of flexibility that is difficult to achieve when AI capabilities are entirely dependent on a single external platform.

This also creates a resilience benefit. If the organization can operate multiple models or maintain alternative processing paths, it can reduce the likelihood that a single provider outage or policy change will interrupt essential cybersecurity services. Such resilience is particularly relevant to SOC environments where AI capabilities are increasingly integrated with detection, analysis, and response workflows (Habibzadeh et al., 2026).

Strategic autonomy should therefore be understood as another dimension of resilience, alongside conventional availability and business-continuity considerations.

10.9 From technology investment to strategic capability

The central strategic implication is that dedicated AI infrastructure should not be evaluated as an isolated hardware investment. Its significance lies in the organizational capabilities that can be built around it.

The infrastructure provides controlled compute and data-processing boundaries. Data governance determines what information can be used. Model governance determines which AI capabilities are trusted. Security engineering protects the environment. Evaluation mechanisms determine whether AI delivers reliable results. Human expertise provides contextual judgment. Governance establishes accountability. Together, these capabilities transform AI from an externally consumed technology service into an organizational capability that can be continuously developed. This integrated perspective reflects the socio-technical understanding of trustworthy AI developed in the governance literature (Lahusen et al., 2024; Tamò-Larrieux et al., 2024).

This distinction is particularly important as foundation models become increasingly accessible. If access to general-purpose intelligence becomes broadly available, competitive differentiation will increasingly depend on how organizations integrate that intelligence into their own operational systems and knowledge environments. The cybersecurity literature provides support for this interpretation because current LLM applications are increasingly being investigated in conjunction with domain-specific SOC data, workflows, security platforms, and organizational knowledge (Habibzadeh et al., 2026; Rieger et al., 2026).

For cybersecurity providers, the resulting capability can be conceptualized as:

AI capability = model capability × proprietary context × workflow integration × organizational expertise × governance maturity.

The multiplicative formulation is intentional. Weakness in any one dimension can substantially constrain the value of the overall system. A powerful model without relevant organizational context may produce generic outputs. Rich security data without appropriate governance may create unacceptable privacy and security risks. Sophisticated workflows without reliable models may automate poor decisions. Strong technology without organizational expertise may fail to translate into operational value. These interdependencies are consistent with the broader understanding of AI governance as a socio-technical and lifecycle-oriented activity (Chesterman et al., 2024; Lahusen et al., 2024).

The strategic objective is therefore not to maximize model capability in isolation. It is to optimize the entire AI-enabled operating system of the organization.

10.10 Strategic implications for cybersecurity service providers

For cybersecurity providers, this perspective suggests that AI adoption should be managed as a strategic transformation rather than as a conventional technology deployment.

The first requirement is to identify where AI can create measurable operational value and where its risks are acceptable. The second is to establish an architecture that allows sensitive data and AI processing to be governed according to the requirements established in earlier chapters. The third is to build the evaluation and governance capabilities necessary to determine which AI applications should move from experimentation into production. The fourth is to develop organizational expertise so that AI capability becomes embedded in the organization's operating model rather than remaining dependent on a small number of technical specialists. This lifecycle perspective is consistent with research emphasizing the importance of governance throughout AI development and deployment rather than treating governance as a post-deployment activity (Chesterman et al., 2024; Swaminathan & Danks, 2024).

Over time, these activities can create cumulative capability. Each validated use case generates knowledge about data, workflows, model performance, evaluation, governance, and human interaction. Each subsequent use case can build upon this knowledge.

The organization therefore moves from isolated AI experimentation toward an AI capability lifecycle:

experiment → evaluate → validate → govern → operationalize → monitor → learn → improve.

This lifecycle is consistent with the AI-by-Design approach developed throughout this paper because it treats deployment not as the end of the design process but as the beginning of continuous governance and learning.

The strategic significance of dedicated infrastructure ultimately lies in enabling this lifecycle under organizational control. It creates a foundation on which the organization can experiment with models, integrate proprietary knowledge, measure operational performance, manage sensitive information, and develop AI-enabled services without making every strategic decision dependent on external AI platforms.

The resulting competitive advantage is therefore unlikely to come from infrastructure ownership alone. Hardware can be purchased by competitors. Models can increasingly be accessed by many organizations. What is more difficult to replicate is the combination of controlled infrastructure, proprietary security knowledge, validated workflows, accumulated evaluation data, organizational expertise, and mature AI governance. This follows the broader principle that AI governance and implementation capability increasingly determine how effectively organizations can convert general AI capabilities into context-specific value (Chesterman et al., 2024; Swaminathan & Danks, 2024).

This leads to the broader strategic proposition of the paper:

The strategic value of sovereign AI infrastructure lies not primarily in owning compute, but in creating organizational control over the complete AI-enabled value chain.

For cybersecurity providers, such control can support resilience, innovation, customer trust, regulatory assurance, and the development of domain-specific AI capabilities. At the same time, it introduces new responsibilities and costs that must be actively managed. Dedicated infrastructure is therefore neither universally superior to external AI services nor an end in itself. Its strategic value depends on whether the organization can convert infrastructure control into measurable operational capability and sustainable strategic autonomy.

In this sense, the transition from generative AI to AI-enabled cybersecurity represents a broader organizational shift. AI is moving from being an externally accessed computational service toward becoming an embedded component of the cybersecurity operating model. The organizations best positioned to benefit are likely to be those that can integrate AI capabilities with proprietary knowledge, security expertise, operational workflows, and governance while maintaining sufficient control over the underlying technology and data. This interpretation is consistent with the emerging literature on LLM-supported cybersecurity, which increasingly frames effective deployment in terms of integration, evaluation, governance, and operational context rather than model capability alone (Habibzadeh et al., 2026; Hasanov et al., 2024).

The central implication is therefore consistent with the argument developed across this paper:

Sovereign AI is strategically valuable not because the organization owns the infrastructure, but because infrastructure, data, models, workflows, expertise, and governance can be brought together into a controlled and continuously improving organizational capability.

11. A Conceptual AI-by-Design Maturity Model

The preceding analysis indicates that organizational AI capability should not be conceptualized as a binary choice between adopting and rejecting artificial intelligence, nor as a simple progression from external to on-premises infrastructure. Rather, AI capability develops across several interdependent dimensions, including data governance, infrastructure control, model governance, security engineering, human oversight, operational integration, and continuous evaluation.

The literature on AI governance supports a maturity-oriented perspective because responsible AI cannot be established through a single technical intervention. Governance evolves as organizations develop mechanisms for assigning responsibility, assessing risk, monitoring AI systems, and embedding governance throughout the system lifecycle. Batool, Zowghi, and Bano (2025), for example, identify governance responsibility, scope, timing, and implementation as recurring dimensions across the AI-governance literature. Similarly, research on LLMs in cybersecurity indicates that organizations can progress from relatively simple information-processing applications toward increasingly integrated SOC capabilities, while the requirements for validation, security, infrastructure, and governance become progressively more demanding. Habibzadeh et al. (2026) highlight both the breadth of potential LLM applications across SOC functions and the continuing limitations concerning reliability, integration, and autonomous incident response.

Against this background, this paper proposes a five-level conceptual AI-by-Design maturity model. The model is not intended as a universal empirical measurement instrument or certification framework. Instead, it provides an analytical structure for understanding how organizations can progress from relatively uncontrolled AI consumption toward governed, measurable, and deeply integrated AI-enabled cybersecurity operations.

The levels are broadly cumulative: higher maturity presupposes capabilities developed at earlier stages. However, maturity should not be interpreted as strictly linear. Organizations may exhibit characteristics of several levels simultaneously across different business units, use cases, or technological environments.

The proposed progression is:

External AI Consumption → Controlled Enterprise AI → Dedicated AI Environment → Governed AI Operations → AI-Native Cybersecurity Operations

The central progression is therefore not from “cloud” to “on-premises,” but from limited organizational control toward increasingly integrated, demonstrable, and continuously managed AI capability.

11.1 Level 1: External AI Consumption

At the first maturity level, AI is primarily consumed as an externally provided service. Employees or individual teams use publicly accessible or externally hosted generative-AI systems for activities such as drafting text, summarizing information, generating code, or supporting analysis. The organization may have general acceptable-use policies, but AI use is not yet integrated into a comprehensive governance framework.

This stage is characterized by a significant separation between AI adoption and organizational control. Individual users may determine which information is submitted to external systems, while the organization has limited visibility into the resulting processing activities. The risks therefore extend beyond model accuracy to include uncontrolled disclosure of confidential information, uncertain data retention, unclear processing locations, inappropriate use of customer information, and insufficient understanding of external providers' data-handling practices.

For cybersecurity organizations, this exposure can be particularly significant because analysts routinely handle information that is itself security-sensitive. An analyst seeking assistance with an investigation could inadvertently expose incident details, network information, vulnerability data, source code, or customer-specific information to a service outside the organization's direct control.

The defining characteristic of Level 1 is therefore limited organizational visibility and control.

The appropriate objective at this stage is not necessarily to prohibit AI. Rather, organizations should first establish visibility into where AI is being used, which information is being processed, which external services are involved, and which risks arise from those activities. This provides the foundation for controlled enterprise adoption.

11.2 Level 2: Controlled Enterprise AI

At the second level, AI use becomes an organizationally managed capability. External AI services may continue to be used, but their use is governed through contractual, technical, and organizational controls.

Organizations establish approved AI services, define permitted and prohibited data categories, introduce identity and access controls, establish retention requirements, and develop procedures for assessing external providers. Procurement and supplier-management processes become part of AI governance, while employees receive explicit guidance concerning appropriate AI use.

The critical transition is therefore from individual AI consumption to organizationally governed AI consumption.

Data governance becomes particularly important at this stage. Organizations classify information according to sensitivity and determine which categories may be processed by which AI services. High-risk information may be prohibited from external processing, while lower-risk information may remain eligible for approved services.

Contractual governance can reduce uncertainty concerning data retention, model training, subprocessors, security controls, and processing locations. Nevertheless, contractual assurances should not be treated as substitutes for technical enforcement. Organizations should establish mechanisms through which policies can actually be implemented and monitored.

Level 2 therefore provides greater visibility, data governance, and organizational control, while substantial external dependencies remain. The organization continues to rely on external providers for model execution, infrastructure, service availability, and potentially model updates.

This level represents an important organizational transition: AI governance becomes an enterprise responsibility rather than an individual-user concern. However, it does not yet provide the degree of processing and infrastructure control that may be required for highly sensitive cybersecurity applications.

11.3 Level 3: Dedicated AI Environment

At Level 3, the organization introduces a dedicated or otherwise strongly controlled AI environment for use cases requiring greater control over data processing, infrastructure, or model execution.

This may involve on-premises infrastructure, dedicated private infrastructure, or another environment in which processing boundaries, network connectivity, storage, access mechanisms, and model deployment can be controlled more directly.

The defining transition is from governed consumption to controlled operation.

Dedicated infrastructure can strengthen data sovereignty by providing greater control over where sensitive information is processed and stored. It can also reduce selected external dependencies and facilitate network segmentation, identity management, logging, encryption, monitoring, and infrastructure-level security controls.

For cybersecurity providers, this level can be particularly significant because sensitive operational information may remain within explicitly defined processing boundaries. Security logs, incident information, customer configurations, forensic artefacts, vulnerability information, and internal security knowledge can potentially be processed without transmission to a general-purpose external AI platform.

However, Level 3 should not be equated with complete AI sovereignty or mature AI governance. Infrastructure ownership does not automatically establish appropriate model governance, data governance, validation, accountability, or lifecycle management. The organization may still depend on external model developers, software components, hardware suppliers, and support providers. Local deployment also does not eliminate hallucination, prompt injection, model manipulation, or inappropriate access.

The defining capability at Level 3 is therefore increased technical control over AI processing, rather than comprehensive governance.

This distinction is important because it prevents “on-premises” from becoming a proxy for maturity. A technically sophisticated AI environment can remain immature if it lacks systematic evaluation, lifecycle governance, accountability, and operational controls.

11.4 Level 4: Governed AI Operations

Level 4 represents the transition from controlled infrastructure to institutionalized AI governance.

At this stage, AI systems are governed through a formal lifecycle integrating infrastructure, data, models, applications, users, security controls, risk management, and accountability. Each significant AI use case has a defined purpose, responsible owner, risk classification, approval process, evaluation methodology, monitoring regime, and lifecycle status.

Model governance becomes an explicit organizational capability. Organizations maintain information about deployed models, configurations, accessible data, available tools, intended use cases, evaluation results, and conditions for modification, replacement, or withdrawal. Significant model or application changes may trigger reassessment rather than being treated as routine software updates.

Data governance is similarly integrated into the AI lifecycle. Data sources are classified and authorized, while retrieval systems and knowledge bases are subject to appropriate quality, provenance, and access controls.

At this maturity level, the quality-assurance mechanisms described in Chapter 7 become operational requirements. AI outputs are evaluated against task-specific performance criteria, deterministic validation is applied where appropriate, and human oversight is calibrated according to the consequences of error.

The organization should also be able to reconstruct relevant AI activity. Logging and auditability allow it to establish which system was used, what information was accessed, what outputs were generated, what controls were applied, and where human intervention occurred.

The defining capability of Level 4 is therefore accountability and demonstrable control.

This is also the stage at which AI governance becomes closely connected to compliance. Applicable Swiss data-protection requirements, GDPR obligations, cybersecurity requirements such as NIS2, and emerging AI-specific regulation must be translated into technical and organizational controls appropriate to the relevant use cases.

The organization is no longer simply using AI securely. It is operating an AI capability for which governance processes, control mechanisms, and evidence have been established.

11.5 Level 5: AI-Native Cybersecurity Operations

The fifth level represents the most mature state proposed by the model: AI-native cybersecurity operations.

At this stage, AI is no longer an isolated productivity tool or supplementary analytical component. It becomes deeply integrated into the organization's cybersecurity operating model.

LLMs and potentially other AI techniques are embedded across multiple workflows, including alert triage, incident summarization, threat-intelligence enrichment, investigative assistance, knowledge retrieval, reporting, detection engineering, and other bounded operational activities. The organization possesses the infrastructure, governance, evaluation, and operational capabilities required to operate these systems at scale.

Importantly, AI-native does not mean fully autonomous.

The defining characteristic of Level 5 is instead systematic, evidence-based AI augmentation. AI performs activities for which it provides demonstrable operational value, while deterministic controls and human experts retain authority over consequential decisions.

Automation is progressively expanded on the basis of empirical evidence. Use cases are continuously evaluated using operational metrics, while model behavior is monitored for degradation, unexpected failure modes, and changes in the threat environment. Models and AI workflows can be modified, replaced, restricted, or withdrawn when evidence indicates that their performance or risk profile has changed.

This corresponds directly to the concept of validated automation developed in Chapter 7. The mature organization does not ask how many decisions can be delegated to AI. It asks which activities can be reliably automated within explicitly defined boundaries.

Level 5 therefore represents the transition from AI as a technology project to AI as a continuously governed organizational capability.

11.6 Maturity Is Multidimensional Rather Than Purely Linear

Although the five levels provide a useful progression, organizational maturity should not be interpreted as a strictly linear sequence. An organization may have highly mature infrastructure but relatively immature model governance. Another may possess sophisticated governance policies while continuing to rely primarily on external AI services. A third may operate advanced AI-enabled SOC workflows while having limited mechanisms for measuring model performance.

The model should therefore be understood as a conceptual capability map rather than a single scalar score.

Relevant dimensions include:

• infrastructure control;

• data sovereignty and governance;

• model governance;

• security engineering;

• AI risk management;

• human oversight;

• operational integration;

• evaluation capability;

• auditability; and

• organizational expertise.

Progress requires development across these dimensions rather than optimization of any single one.

This is particularly important for interpreting the role of dedicated AI infrastructure. Infrastructure investment may enable movement from Level 2 toward Level 3, but infrastructure alone does not produce Level 4 or Level 5 maturity. Governance, validation, monitoring, organizational expertise, and accountability must subsequently be developed around the infrastructure.

Conversely, high organizational maturity does not necessarily require complete infrastructure ownership. Organizations operating external AI services can potentially establish strong governance, contractual control, monitoring, and risk-management mechanisms. The strategic value of dedicated infrastructure therefore depends on the sensitivity of the use cases and the degree of control required.

The model consequently avoids equating sovereignty with physical ownership. Sovereignty is instead treated as one dimension of the organization's broader ability to control and govern AI throughout its lifecycle.

11.7 Maturity as Increasing Organizational Control

The five levels can also be interpreted as a progression in the organization's ability to control the AI value chain.

At Level 1, control is largely delegated to external providers and individual users. At Level 2, the organization begins imposing governance on external AI consumption. At Level 3, critical processing environments are internalized or otherwise strongly controlled. At Level 4, the organization governs the AI lifecycle through formal processes, validation, monitoring, and accountability. At Level 5, AI is deeply integrated into cybersecurity operations while continuously measured and adapted.

The progression can therefore be summarized as:

consume → control → operate → govern → continuously optimize

This progression also demonstrates why AI maturity should not be measured by model sophistication alone. A highly capable LLM deployed without appropriate governance may represent lower organizational maturity than a less capable model operating within a rigorously validated and controlled workflow.

The relevant unit of analysis is consequently the AI-enabled socio-technical system, rather than the model itself.

11.8 Maturity and the Economics of Infrastructure Investment

The model also provides a framework for interpreting the strategic value of dedicated infrastructure.

The economic justification for dedicated infrastructure is likely to be relatively weak when AI use remains at Levels 1 or 2 and consists primarily of low-risk productivity applications. At these stages, the capital and operational costs of dedicated infrastructure may outweigh its benefits.

The value proposition changes as organizations move toward sensitive, high-volume, and operationally integrated use cases. At Level 3, infrastructure control can become strategically valuable because it supports data sovereignty and reduces selected external processing dependencies. At Level 4, the same infrastructure can become part of a governed AI platform supporting validated and auditable applications. At Level 5, it can form part of a strategic AI capability integrated across the cybersecurity operating model.

The model therefore suggests that infrastructure investment should be evaluated in relation to organizational AI maturity, use-case sensitivity, workload characteristics, and required degree of control, rather than as an isolated technology decision.

This is particularly relevant to cybersecurity providers. If AI is expected to become a core component of SOC operations, customer-facing services, and internal security processes, dedicated infrastructure may provide strategic value that would not be visible in a simple comparison of inference costs.

11.9 A Maturity Model for Continuous Progression

The model should ultimately be interpreted as a mechanism for continuous improvement rather than a certification scheme. Movement between levels should be supported by evidence that the organization has developed the capabilities necessary to operate AI safely and effectively at the next degree of integration.

Progression can therefore be understood through increasingly demanding questions:

Level 1 — Visibility:
Where is AI being used?

Level 2 — Control:
Which AI use is authorized, and under what data and contractual controls?

Level 3 — Processing sovereignty:
Which AI processing should remain under direct organizational control?

Level 4 — Governance:
Can the organization govern, validate, monitor, and audit the complete AI lifecycle?

Level 5 — Optimization:
Can AI be continuously integrated into cybersecurity operations while producing measurable value within controlled risk boundaries?

These questions represent an evolution from visibility to control, from control to governance, and from governance to continuous optimization.

The maturity model therefore reinforces a central proposition of this paper: dedicated AI infrastructure is neither the starting point nor the endpoint of trustworthy AI adoption. It is one component within a broader progression toward organizational control and AI-enabled operational maturity.

11.10 Implications for the AI-by-Design Framework

The maturity model provides a practical synthesis of the AI-by-Design concept developed throughout this paper.

At lower maturity levels, AI adoption tends to be driven primarily by immediate functionality: users select models because they are useful, and organizations subsequently attempt to establish appropriate controls. At higher maturity levels, the direction is reversed. Organizational requirements concerning sovereignty, privacy, security, accountability, and operational resilience shape the architecture before specific AI capabilities are deployed.

This represents the fundamental transition from AI adoption to AI by Design.

The most mature organization is therefore not necessarily the organization using the most advanced model or automating the greatest number of activities. It is the organization that can demonstrate that AI capabilities are deliberately selected, securely deployed, appropriately governed, continuously evaluated, and integrated with human expertise.

The conceptual model can consequently be summarized through five principles:

Visibility before scale.
Control before sensitive processing.
Governance before operational dependence.
Validation before automation.
Evidence before trust.

These principles provide a practical interpretation of AI maturity for cybersecurity organizations.

Ultimately, the objective should not be to reach an arbitrary state of “maximum AI.” Rather, organizations should develop sufficient maturity to support the AI use cases that create meaningful value while maintaining an appropriate degree of control over data, infrastructure, models, decisions, and accountability.

For a cybersecurity provider, the transition toward sovereign and AI-enabled operations is therefore best understood as a capability-building journey. Dedicated infrastructure can establish a stronger technical foundation; governance can convert that foundation into controlled operations; validated automation can convert controlled operations into measurable efficiency; and accumulated organizational knowledge can transform these capabilities into a sustainable strategic advantage.

The ultimate maturity state is therefore not characterized by autonomous AI, but by evidence-based, continuously governed AI augmentation of cybersecurity operations.

This formulation preserves the central premise of the paper: trustworthy AI is achieved not through technology selection alone, but through the deliberate alignment of infrastructure, data, models, security engineering, governance, human expertise, and organizational strategy.

12. Proposed Research and Evaluation Framework

The conceptual arguments developed in this paper should ultimately be subjected to empirical validation. In particular, claims concerning the benefits of dedicated AI infrastructure should not be treated as inherent consequences of on-premises deployment. Whether organization-controlled AI improves security, sovereignty, operational efficiency, quality, resilience, or trust depends on the characteristics of the workload, architecture, model, governance regime, and degree of integration into human workflows.

This is particularly important because the emerging literature does not support the assumption that LLM performance is uniform across cybersecurity tasks. Recent research demonstrates substantial variation across security-operations use cases, while empirical studies of SOC alert classification and prioritization indicate that strong performance at one stage of the analytical workflow does not necessarily translate into reliable performance at another. Habibzadeh et al. (2026), in their systematic survey of 216 studies, similarly identify substantial potential for LLM-supported SOC operations while emphasizing unresolved challenges relating to reliability, integration, automation, and end-to-end incident response.

Future research should therefore move beyond evaluations of isolated model capabilities and investigate the AI-enabled cybersecurity system as a socio-technical workflow. The relevant object of evaluation is not simply the LLM, but the interaction between model, infrastructure, data, retrieval mechanisms, security controls, human analysts, organizational processes, and governance.

The proposed framework consequently treats infrastructure architecture as one explanatory variable within a broader system rather than as an independent determinant of performance. Its purpose is to establish how different AI operating models affect measurable outcomes and under what conditions dedicated infrastructure provides sufficient benefits to justify its additional cost and complexity.

12.1 Comparative research design

A particularly valuable research design would compare externally hosted AI architectures with organization-controlled or dedicated AI architectures under otherwise comparable operational conditions.

Such comparisons should, where feasible, use the same or functionally equivalent cybersecurity tasks, comparable datasets, equivalent evaluation criteria, and clearly documented differences in infrastructure and governance. Depending on the research setting, this could take the form of a controlled experiment, a longitudinal field study, a quasi-experimental comparison between operational environments, or a mixed-methods case study.

The objective should not be to demonstrate that on-premises AI is universally superior to externally hosted AI. Rather, research should identify the conditions under which increased infrastructure control generates measurable benefits and the conditions under which those benefits do not justify the associated cost and complexity.

This distinction is essential because the two architectural approaches offer different advantages. External AI services may provide access to highly capable models, scalability, simplified operations, and potentially favorable economics. Dedicated environments may provide greater control over data processing, sovereignty, latency, customization, infrastructure configuration, and operational independence.

A meaningful comparison must therefore evaluate both benefits and trade-offs, rather than treating infrastructure control as an outcome in itself.

A comparative study could consequently formulate a central research question such as:

Under what organizational, technical, and operational conditions does dedicated AI infrastructure provide superior overall value to externally hosted AI for cybersecurity operations?

This question can then be decomposed into more specific hypotheses concerning control, security, performance, governance, cost, and trust.

12.2 Data sovereignty and control

The first evaluation dimension concerns data sovereignty. Rather than treating sovereignty as a binary property determined by infrastructure location, research should operationalize it through measurable indicators of control over the AI data lifecycle.

Potential indicators include:

• the proportion of sensitive processing remaining within explicitly authorized organizational or jurisdictional boundaries;

• the number and type of external processors involved;

• the extent of third-party access to customer information;

• the number of uncontrolled or insufficiently documented data transfers;

• the proportion of AI workflows for which processing locations can be independently verified;

• the degree of control over retention and deletion;

• the ability to identify all relevant subprocessors and dependencies; and

• the organization's ability to reconstruct data flows throughout the AI lifecycle.

Research could additionally examine whether dedicated infrastructure reduces uncertainty concerning data retention, subprocessors, model-training practices, telemetry, and cross-border data transfers.

This would allow the concept of sovereignty developed throughout the paper to be tested empirically as demonstrable control rather than geographical residence alone.

The evaluation should also distinguish infrastructure control from complete AI sovereignty. A locally operated system may remain dependent on external model developers, software repositories, hardware suppliers, update mechanisms, or support providers. Research should therefore map the complete AI supply chain rather than simply recording whether the primary compute environment is located on-premises.

A useful research question is therefore:

Does dedicated infrastructure measurably increase an organization's ability to identify, control, and demonstrate the complete lifecycle of sensitive AI processing?

12.3 Security performance and AI-specific risk

The second dimension concerns security.

Dedicated infrastructure may reduce certain forms of data exposure and provide greater control over network boundaries, access privileges, logging, configuration, and system connectivity. However, local deployment simultaneously creates an AI infrastructure that the organization must itself secure, maintain, and update.

Empirical evaluation should therefore measure both the security benefits and newly introduced risks associated with AI deployment.

Relevant indicators could include:

• number and severity of AI-related security incidents;

• unauthorized access attempts;

• successful prompt-injection attacks;

• tool-abuse events;

• sensitive-information disclosure;

• model and application vulnerabilities;

• privilege-escalation events;

• policy-enforcement failures;

• insecure model or application configurations; and

• compromise of AI-connected security infrastructure.

The evaluation should also consider whether the AI system introduces new pathways into operational cybersecurity environments. An LLM connected to SIEM platforms, ticketing systems, endpoint-management tools, threat-intelligence systems, or security-orchestration platforms may possess capabilities that materially increase the consequences of compromise.

Security research should therefore assess not only whether the model itself is robust, but whether the complete AI-enabled workflow remains secure under realistic adversarial conditions.

This reflects the increasingly bidirectional nature of AI security. AI can function as a defensive technology while simultaneously creating new attack surfaces and enabling new forms of abuse. The security evaluation must consequently encompass both the infrastructure used to operate AI and the AI-enabled interfaces through which the system interacts with cybersecurity environments.

12.4 Operational efficiency

The third dimension concerns operational efficiency.

A major justification for AI adoption in cybersecurity is the expectation that AI can reduce repetitive analytical work and allow security professionals to focus on higher-value activities. This proposition should be tested using operational rather than purely technical metrics.

Potential measures include:

• mean analyst handling time per alert;

• analyst workload;

• alerts processed per analyst;

• investigation duration;

• time spent preparing reports;

• time spent retrieving contextual information;

• proportion of repetitive activities automated; and

• human-review time required per AI-assisted task.

Efficiency should not, however, be defined simply as the number of activities removed from human workflows. An AI system that produces large numbers of incorrect recommendations may increase rather than decrease workload because analysts must verify, correct, or reverse its outputs.

A more meaningful measure is therefore net operational benefit:

Net operational benefit = time and effort saved through AI − validation, correction, monitoring, and governance effort introduced by AI.

This distinction is particularly important for LLM-based SOC applications. AI may provide substantial value for information transformation, summarization, retrieval, and analyst assistance without being sufficiently reliable for unrestricted autonomous decision-making.

The relevant empirical question is consequently not whether AI reduces human involvement, but whether it reduces total operational effort while maintaining or improving security outcomes.

12.5 Response performance

Operational efficiency should be complemented by measures of cybersecurity response performance.

Relevant indicators include:

• mean time to triage;

• mean time to investigate;

• mean time to respond;

• time required to enrich alerts;

• time required to produce incident reports;

• escalation time for high-severity incidents; and

• time required to identify relevant contextual information.

These measures are important because faster processing does not necessarily imply better security. A system that rapidly prioritizes the wrong alerts may reduce measured handling time while degrading actual security outcomes.

Research should therefore examine the relationship between AI assistance and both speed and decision quality.

Longitudinal studies would be particularly valuable. AI may initially increase workload because personnel must learn how to interpret and validate its outputs. Over time, organizational familiarity, improved prompts, refined retrieval systems, and workflow optimization may increase its value.

A short-term benchmark may therefore underestimate the benefits—or risks—associated with organizational learning.

12.6 Quality and reliability

Quality represents one of the most important dimensions of the proposed framework.

LLMs can generate fluent and plausible outputs that are nevertheless factually incorrect, incomplete, inconsistent, or unsupported by available evidence. Conventional measures of language quality are therefore insufficient for many cybersecurity applications.

Evaluation should instead be task-specific and may include:

• precision;

• recall;

• false-positive rate;

• false-negative rate;

• factual accuracy;

• hallucination frequency;

• completeness;

• consistency;

• evidence support;

• ranking quality; and

• confidence calibration where appropriate.

For incident summarization, for example, evaluation should determine whether generated summaries preserve critical facts, distinguish confirmed events from hypotheses, and avoid introducing information absent from the underlying evidence.

For alert classification, precision and recall may be appropriate. For alert prioritization, ranking quality and analyst utility may be more meaningful. For investigation assistance, evaluation should determine whether generated hypotheses are supported by available evidence and whether the system introduces unsupported conclusions.

The central methodological implication is therefore:

There is no single meaningful measure of “LLM accuracy” for cybersecurity.

Performance should instead be evaluated against the actual purpose, risk, and consequences of each use case.

12.7 Governance and auditability

A further dimension concerns governance.

An AI system may generate technically useful outputs while remaining unsuitable for production if its actions cannot be reconstructed or its data-processing activities cannot be adequately governed.

Research should therefore measure the extent to which AI-supported activities are traceable, controllable, and auditable.

Potential indicators include:

• proportion of AI actions associated with a known model and application version;

• proportion of outputs linked to identifiable source information;

• percentage of consequential actions subject to human approval;

• completeness of access and activity logs;

• ability to reconstruct AI-supported decisions after an incident;

• existence and enforcement of use-case approval procedures;

• completeness of AI and model inventories;

• completeness of data-processing inventories;

• effectiveness of change-management procedures; and

• frequency of periodic AI evaluations.

This dimension is particularly important for testing the AI-by-Design proposition. If dedicated infrastructure improves technical control but does not improve the organization's ability to demonstrate what the AI system did, then the anticipated governance advantage may not materialize.

Governance should therefore be evaluated as an observable organizational capability, rather than inferred from infrastructure ownership.

12.8 Human factors and analyst acceptance

Technical performance should be complemented by human-centered evaluation.

AI-enabled cybersecurity systems operate within organizational workflows, meaning that their effectiveness depends partly on whether analysts understand, trust, challenge, and appropriately use their outputs.

Relevant measures include:

• analyst acceptance;

• perceived usefulness;

• cognitive workload;

• time spent verifying AI outputs;

• frequency of human overrides;

• frequency of analyst corrections;

• trust calibration; and

• rate of acceptance of incorrect AI recommendations.

The final measure is particularly important. High acceptance is not necessarily evidence of successful AI adoption. Excessive trust can create automation bias, whereby analysts accept AI recommendations without sufficient scrutiny. Conversely, very low acceptance may indicate that the system provides insufficient value or that its outputs are difficult to interpret.

The desired state is therefore not maximum trust but appropriately calibrated trust.

Analysts should rely on AI when it performs reliably and intervene when uncertainty, consequences, or system limitations warrant additional scrutiny.

This suggests that future studies should evaluate not simply whether analysts trust AI, but whether their level of reliance corresponds appropriately to the system's demonstrated reliability.

12.9 Cost, energy, and infrastructure utilization

Any empirical comparison between dedicated and externally hosted AI should include economic and environmental dimensions.

Dedicated infrastructure introduces capital and operational costs associated with compute hardware, accelerators, storage, networking, power, cooling, maintenance, security, and specialist personnel. Relevant measures should therefore include:

• total cost of ownership;

• cost per inference;

• cost per completed cybersecurity task;

• hardware utilization;

• accelerator utilization;

• energy consumption;

• energy per validated task;

• infrastructure lifecycle costs; and

• staffing requirements.

External AI services should be evaluated using comparable measures, including service costs, network and data-transfer requirements, and relevant operational dependencies.

Energy efficiency is particularly relevant because AI workloads can vary considerably in computational intensity. A large model operating continuously on dedicated hardware may have a substantially different resource profile from a smaller model deployed selectively or an externally hosted service optimized across many customers.

Infrastructure evaluation should therefore focus on cost and energy per unit of validated operational value, rather than utilization alone.

This connects the economic and technical dimensions of the framework. A system that consumes more computational resources but substantially reduces analyst workload may be strategically preferable to a more resource-efficient system that produces limited operational value.

12.10 Customer trust as an outcome variable

Because the framework is concerned with sovereignty and trustworthy AI, customer trust should be treated as an empirical outcome rather than merely a conceptual benefit.

Research could examine whether customers perceive organization-controlled AI environments as more trustworthy than externally hosted alternatives and which factors explain those perceptions.

Potential variables include:

• perceived data sovereignty;

• transparency;

• security assurance;

• accountability;

• perceived control over data processing;

• regulatory confidence;

• human oversight; and

• confidence in the provider's ability to respond when AI fails.

Customer trust should also be distinguished from technical trust in the model.

A customer may have limited confidence in an LLM's ability to make autonomous decisions while nevertheless having high confidence in the provider's governance mechanisms surrounding that model.

This distinction provides a direct empirical test of the proposition developed in Chapter 9: that trust can emerge from demonstrable control surrounding the AI system rather than from model capability alone.

12.11 Use-case-level evaluation

A central methodological principle of the proposed framework is that AI performance should be evaluated at the use-case and workflow level.

A general-purpose model may perform extremely well for one cybersecurity task and poorly for another. Even within the same application, performance can vary according to data quality, customer context, language, attack type, retrieval sources, prompt structure, and integration with existing security systems.

Evaluation should therefore begin by defining the operational task and its acceptable risk threshold.

For each use case, researchers should specify:

1. the intended function;

2. required inputs;

3. permitted outputs;

4. potential consequences of error;

5. evaluation metrics;

6. human-oversight requirements;

7. acceptable failure rates; and

8. conditions under which the system must defer to a human or deterministic control.

This replaces the simplistic question:

“Is the LLM accurate?”

with the more meaningful question:

“Is this AI-enabled workflow sufficiently reliable, secure, efficient, and governable for this particular cybersecurity task and its associated risk?”

This shift from model-level to workflow-level evaluation is essential because cybersecurity outcomes are produced by systems rather than models in isolation.

12.12 Longitudinal evaluation and continuous monitoring

Finally, AI-enabled cybersecurity systems should be evaluated longitudinally.

LLM performance is not necessarily static. Models can change, retrieval sources can evolve, threat environments can shift, and organizational workflows can adapt. A system that performs adequately during initial validation may subsequently experience performance degradation or develop new failure modes.

Continuous evaluation should therefore form part of the operational architecture. Organizations should:

• establish baseline performance;

• monitor relevant metrics after deployment;

• conduct periodic re-evaluation;

• test significant model and application changes;

• monitor for emerging failure modes;

• reassess performance when threat conditions change; and

• define explicit thresholds that trigger rollback, restriction, or revalidation.

This is particularly important for cybersecurity because the underlying environment is adversarial and dynamic. Threat actors continuously modify their techniques, while security teams continuously modify detection and response processes.

AI systems must therefore be evaluated not only against historical benchmark datasets but also against representative and evolving operational conditions.

The appropriate research paradigm is consequently closer to continuous assurance than one-time model validation.

12.13 Toward an empirical theory of sovereign AI

Taken together, these dimensions provide the basis for an empirical research program examining whether and when dedicated AI infrastructure produces measurable advantages for cybersecurity organizations.

Future studies should evaluate at least five interconnected outcome categories:

1. control and sovereignty;

2. security and resilience;

3. operational performance;

4. quality and reliability; and

5. governance and trust.

These should be complemented by economic, environmental, and human-factor measures.

The resulting conceptual research model can be expressed as:

Infrastructure architecture → degree of control → governance capability → AI workflow quality → operational outcomes → organizational and customer value.

However, this relationship should not be treated as deterministic.

Dedicated infrastructure may increase control without improving workflow quality. Improved infrastructure may reduce data-exposure risks without improving analyst productivity. Conversely, a well-designed external service may perform extremely well for a low-risk task while offering better economics than a local deployment.

The purpose of empirical research is therefore to identify the boundary conditions under which the hypothesized relationships hold.

The framework also enables empirical testing of the maturity model proposed in Chapter 11. Organizations at different maturity levels could be compared in terms of governance capabilities, operational performance, AI risk, infrastructure costs, and customer trust. Longitudinal studies could then investigate whether progression toward higher AI-by-Design maturity produces measurable improvements in these outcomes.

This approach transforms claims concerning sovereign or dedicated AI from normative assertions into testable empirical hypotheses.

For example, future studies could examine hypotheses such as:

• H1: Greater infrastructure control is associated with greater demonstrable control over sensitive AI data flows.

• H2: Greater infrastructure control reduces selected categories of third-party processing and dependency risk.

• H3: AI workflow integration improves operational efficiency only when model reliability exceeds task-specific thresholds.

• H4: Governance maturity moderates the relationship between AI capability and operational value.

• H5: Appropriately calibrated human oversight improves the reliability of AI-assisted cybersecurity workflows.

• H6: Customer trust is more strongly associated with demonstrable governance and control than with model capability alone.

• H7: Dedicated infrastructure provides greater strategic value as AI use cases become more sensitive, operationally integrated, and risk-critical.

• H8: The benefits of dedicated infrastructure are mediated by organizational maturity rather than produced by infrastructure ownership alone.

These hypotheses illustrate how the conceptual argument can be transformed into an empirical research program without presupposing its conclusions.

12.14 Methodological implications

The framework also has implications for how empirical studies should be designed.

First, comparisons should control for model capability wherever possible. Comparing a powerful locally deployed model with a substantially weaker external model would make it impossible to determine whether observed differences arise from infrastructure or model quality.

Second, studies should distinguish between technical performance and organizational performance. A model may improve benchmark accuracy while providing little operational value if analysts cannot integrate its outputs effectively.

Third, evaluations should account for total system cost, including infrastructure, integration, governance, human validation, maintenance, and operational overhead.

Fourth, research should distinguish between assumed and demonstrated control. Claims concerning sovereignty, security, or compliance should be supported by observable architectural and organizational evidence wherever possible.

Finally, studies should explicitly document the assumptions and boundaries of the comparison. The objective is not to establish a universal hierarchy between cloud and on-premises AI, but to identify the conditions under which particular architectures are appropriate.

This methodological discipline is important because otherwise infrastructure architecture risks becoming a proxy for broader assumptions concerning security, trust, or quality.

12.15 Conclusion of the research framework

The proposed framework moves the discussion beyond the proposition that sovereign or dedicated AI is inherently safer, more compliant, or more efficient. Instead, these propositions are treated as empirical questions whose answers depend on the interaction between architecture, AI capability, organizational maturity, regulatory requirements, and operational context.

The central methodological conclusion is therefore:

The appropriate unit of analysis is not the LLM, nor the infrastructure in isolation, but the governed AI-enabled cybersecurity workflow operating within a specific organizational and risk context.

This perspective provides a basis for rigorous comparative research and prevents infrastructure architecture from becoming a proxy for AI quality.

Ultimately, the relevant question is not whether AI runs on-premises or in the cloud as an abstract technological choice. The question is whether a particular architecture enables an organization to achieve a superior balance between data sovereignty, security, operational efficiency, reliability, governance, cost, resilience, and trust for the cybersecurity tasks it is required to perform.

This distinction is essential for developing an evidence-based understanding of sovereign AI. Dedicated infrastructure should neither be treated as a universal solution nor dismissed as merely an alternative hosting model. Its value is an empirical question whose answer depends on the interaction between technical architecture, AI capability, organizational maturity, regulatory requirements, and the operational characteristics of the cybersecurity service.

The resulting research agenda therefore extends the central argument of this paper: sovereign AI should be evaluated not by where the model runs, but by whether the resulting socio-technical system provides measurable and sustainable control over sensitive data, AI behavior, operational risk, and organizational outcomes.

13. Discussion

aThe analysis developed throughout this paper suggests that dedicated AI infrastructure should be understood as more than a technical deployment decision. For cybersecurity organizations, it can constitute an important component of a broader organizational strategy for governing AI-enabled data processing, securing sensitive information, strengthening operational resilience, and developing domain-specific AI capabilities. The strategic value of such infrastructure, however, depends not on infrastructure ownership itself but on the extent to which ownership can be translated into meaningful and demonstrable organizational control.

This qualification is particularly important given the rapidly expanding use of LLMs in cybersecurity. Recent literature identifies substantial opportunities for LLMs across security operations, including information processing, threat intelligence, investigation support, reporting, and workflow automation, while simultaneously highlighting limitations in reliability, integration, security, and autonomous decision-making. Habibzadeh et al. (2026), in their systematic survey of 216 studies, emphasize precisely this tension: LLMs offer considerable potential for augmenting SOC activities, but significant challenges remain before reliable end-to-end automation can be assumed.

The findings of this conceptual analysis should therefore be interpreted neither as an argument for universal on-premises AI nor as a rejection of externally hosted AI services. Instead, they support a more conditional proposition: dedicated AI infrastructure can be strategically valuable when the sensitivity, risk, regulatory context, and operational importance of AI-enabled workloads justify a higher degree of organizational control.

Three qualifications are particularly important.

13.1 On-premises does not equal secure

The first qualification concerns security.

A locally operated AI environment can reduce certain external dependencies and provide greater control over physical infrastructure, network boundaries, storage, access management, logging, and data flows. These properties can be particularly valuable when AI processes security-critical information.

However, these benefits do not imply that on-premises AI is inherently more secure.

With greater infrastructure control comes greater organizational responsibility. An organization operating its own AI environment becomes responsible for securing the servers, accelerators, storage, networks, model-serving infrastructure, operating systems, software dependencies, administrative interfaces, and supporting services. Vulnerability management, patching, identity management, secrets management, backup, disaster recovery, monitoring, and incident response consequently become organizational responsibilities rather than functions delegated to an external AI provider.

The same applies to the AI-specific attack surface. An internally operated LLM can still be vulnerable to prompt injection, malicious inputs, model manipulation, sensitive-information disclosure, insecure tool use, and other attacks identified in the emerging LLM-security literature. Indeed, local deployment may create additional risks when the model is integrated deeply with internal security systems.

The relevant question is therefore not whether infrastructure is physically located inside the organization, but whether the resulting architecture provides an appropriate security control environment for the intended AI workload.

This reinforces the principle developed earlier in the paper that dedicated infrastructure should be regarded as an enabling condition for sovereignty and control, rather than as a guarantee of security.

The distinction is particularly important for cybersecurity providers. An AI system connected to SIEM, SOAR, endpoint, identity, ticketing, or customer-management systems can become a highly privileged component of the security architecture. If its permissions are excessive or its outputs are trusted without adequate validation, the system may introduce rather than reduce operational risk.

Consequently, secure deployment requires defense in depth: infrastructure security must be complemented by model and application security, least-privilege access, input validation, output controls, deterministic guardrails, monitoring, and human oversight.

The central implication is:

On-premises deployment changes the locus of control; it does not remove the need for security.

13.2 Sovereignty does not equal isolation

The second qualification concerns sovereignty.

The analysis has deliberately distinguished data residency from data sovereignty. Residency concerns where information is physically stored or processed. Sovereignty concerns the organization's ability to exercise meaningful control over that processing.

This distinction becomes particularly important when considering the claim that an AI system can be “100% sovereign.” Such a formulation risks implying a degree of technological independence that is difficult to achieve in contemporary AI ecosystems.

AI infrastructure is embedded in complex international supply chains. Compute hardware depends on semiconductor manufacturers and global production networks. AI software relies on operating systems, libraries, frameworks, container technologies, security components, and open-source ecosystems. Models may originate from organizations operating in other jurisdictions. Hardware and software updates may depend on external suppliers. Technical standards, research, and security knowledge are inherently international.

Consequently, physical control over servers cannot realistically be equated with complete technological independence.

A more defensible conceptualization is controlled interdependence.

An organization can remain dependent on external suppliers while retaining sufficient control over the critical aspects of AI operation. The strategic objective is therefore not to eliminate all external dependencies but to understand, classify, and govern them.

This leads to a more nuanced interpretation of sovereignty. An organization should determine which dependencies are acceptable, which can be substituted, which require contractual or technical safeguards, and which constitute unacceptable concentrations of risk.

For example, dependence on a particular hardware supplier may be strategically acceptable if alternative suppliers or procurement strategies exist. Dependence on an external model provider may be acceptable for low-risk applications but inappropriate for highly sensitive customer-security data. Similarly, reliance on an external software component may be manageable if it is subject to vulnerability monitoring, software composition analysis, and controlled update procedures.

Sovereignty therefore becomes a question of dependency governance.

This interpretation is consistent with the broader argument of the paper: sovereignty is not the absence of external relationships. It is the organization's ability to determine and enforce the conditions under which those relationships affect its critical data and AI capabilities.

The strategic objective can consequently be formulated as:

not independence from the ecosystem, but autonomy over critical decisions within the ecosystem.

13.3 Compliance does not equal infrastructure certification

The third qualification concerns compliance.

A dedicated AI environment can support compliance by providing greater control over data flows, access management, processing locations, logging, retention, and security architecture. Nevertheless, compliance cannot be inferred from infrastructure architecture alone.

Whether an AI-enabled service satisfies applicable legal and regulatory requirements depends on the interaction between technology, organizational processes, contractual relationships, data characteristics, purposes of processing, risk assessments, and applicable law.

This is particularly relevant to the Swiss and European contexts discussed earlier. The fact that data remains within Switzerland, for example, does not automatically establish compliance with the Swiss Federal Act on Data Protection. Similarly, keeping data within the European Economic Area does not automatically establish compliance with the GDPR.

Compliance requires organizations to establish what information is processed, why it is processed, under whose authority, under which legal basis where applicable, for how long, by which systems and processors, with which safeguards, and with what mechanisms for exercising relevant rights and demonstrating accountability.

The same principle applies to cybersecurity regulation such as NIS2. The existence of dedicated AI infrastructure does not itself satisfy risk-management or governance obligations. Instead, AI infrastructure becomes one component of the organization's broader cybersecurity and risk-management framework.

The appropriate formulation is therefore:

Infrastructure can enable compliance; governance, processes, controls, and evidence establish compliance.

This distinction also has implications for organizational communication. Statements such as “fully compliant AI” or “100% sovereign AI” may be attractive from a marketing perspective but can obscure the conditional nature of compliance and sovereignty. A scientifically and legally more defensible approach is to specify which dimensions of control the architecture provides and which governance mechanisms support the resulting claims.

13.4 The paradox of control

The three qualifications reveal an important paradox.

Dedicated infrastructure increases organizational control, but increased control also increases organizational responsibility.

When an external AI provider operates infrastructure, some responsibilities concerning hardware maintenance, service availability, patching, and infrastructure security are delegated to the provider. When an organization brings these capabilities in-house, it gains greater control but also assumes responsibility for ensuring that this control is exercised effectively.

This means that sovereignty has an associated governance cost.

The organization must possess the expertise, resources, processes, and operational maturity necessary to manage the environment securely. Without these capabilities, the theoretical benefits of sovereignty may not translate into practical security or trustworthiness.

This observation challenges simplistic comparisons between “cloud” and “on-premises” AI. Neither architecture is inherently secure, sovereign, compliant, or trustworthy. The relevant question concerns the quality of the control environment and whether that environment is appropriate to the organization's risk profile.

In some circumstances, a highly mature external provider may offer stronger security capabilities than an organization operating a poorly maintained internal system. In other circumstances, particularly where data sensitivity and regulatory requirements are high, the additional control afforded by dedicated infrastructure may be strategically decisive.

Architecture should therefore be selected according to risk and required control, not ideology.

13.5 The trade-off between control and complexity

A further implication is that greater control can introduce greater complexity.

Dedicated AI infrastructure requires organizations to manage hardware capacity, model deployment, updates, software dependencies, observability, security, energy consumption, and lifecycle management. It may also require specialist expertise that is scarce in the labor market.

This creates a trade-off between control and operational complexity.

External AI platforms abstract much of this complexity away from the customer. They can provide rapid access to highly capable models without requiring the organization to operate the underlying infrastructure. Dedicated environments provide greater control but require greater internal capability.

The strategic question is consequently not whether more control is always better. It is whether the additional control provides sufficient value to justify the additional complexity.

This reinforces the maturity argument developed in Chapter 11. Dedicated infrastructure becomes more strategically meaningful as organizations develop the governance, security, infrastructure, and AI-engineering capabilities necessary to exploit it effectively.

In other words:

Infrastructure sovereignty without organizational capability can become operational burden rather than strategic advantage.

13.6 Sovereignty as controlled interdependence

The combined findings support a refinement of the sovereignty concept proposed earlier in the paper.

Traditional notions of sovereignty tend to emphasize independence and territorial control. Applied to AI, however, such a conception is difficult to sustain because modern AI systems depend on globally distributed technological ecosystems.

A more appropriate concept is controlled interdependence.

Under this model, an organization acknowledges that it cannot—and generally should not attempt to—eliminate all external dependencies. Instead, it seeks to maintain control over the dependencies that matter most to its security, regulatory obligations, and strategic autonomy.

This requires identifying critical components of the AI value chain and determining the degree of control required over each. For sensitive cybersecurity workloads, these may include customer data, model execution, retrieval sources, access rights, system integrations, logs, and consequential actions.

Less critical components may remain externally sourced where the associated risks are acceptable.

This produces a more pragmatic form of sovereignty: selective sovereignty based on risk and criticality.

Such an approach also supports architectural flexibility. An organization may use external models for low-risk productivity tasks while processing highly sensitive customer data through a dedicated internal environment. Similarly, different models may be used for different workloads according to their performance, cost, security, and sovereignty requirements.

The result is not a binary “sovereign versus non-sovereign” architecture but a sovereignty-aware AI portfolio.

13.7 Implications for AI by Design

These qualifications strengthen rather than weaken the AI-by-Design argument.

If on-premises deployment were automatically secure, sovereignty were equivalent to geographic isolation, and compliance were guaranteed by infrastructure location, AI governance would largely be an infrastructure-selection problem.

The analysis demonstrates that this is not the case.

AI by Design is necessary precisely because trustworthy AI emerges from the interaction of multiple layers. Infrastructure establishes processing boundaries. Data governance determines what information can cross those boundaries. Security engineering protects the environment. Model governance determines which models and capabilities are permitted. Workflow controls determine how AI outputs influence operational decisions. Human oversight manages consequential uncertainty. Auditability provides evidence. Organizational governance establishes accountability.

Dedicated infrastructure is therefore one architectural component within a larger system of controls.

This interpretation also explains why the concept is potentially more useful than simply advocating “on-premises AI.” The latter describes a deployment model. AI by Design describes a governance philosophy and architectural methodology.

The distinction is important for research as well as practice. An empirical comparison should not simply compare cloud and on-premises infrastructure. It should compare how different architectures affect measurable outcomes such as data exposure, control, security incidents, operational efficiency, model quality, auditability, cost, and customer trust.

13.8 Implications for the strategic proposition

The strategic argument consequently becomes more nuanced.

Dedicated infrastructure should not be presented as an end in itself or as a universal replacement for external AI services. Its strategic value arises when the organization's requirements make direct control over AI processing particularly important.

These requirements may include highly sensitive data, strict data-sovereignty expectations, customer contractual requirements, regulatory constraints, operational dependence on AI, low-latency requirements, or the need to develop proprietary AI-enabled capabilities.

Where these conditions exist, dedicated infrastructure can provide an important foundation for strategic autonomy. It can allow organizations to determine more directly where sensitive information is processed, which models are used, how systems are integrated, how data flows are controlled, and how AI capabilities evolve.

Where these conditions do not exist, external AI services may remain economically and operationally preferable.

The strategic decision should therefore be based on a portfolio assessment of risk, criticality, control requirements, cost, capability, and expected operational value.

13.9 Limitations of the present conceptual analysis

Several limitations should also be acknowledged.

First, the argument is primarily conceptual and does not establish causal relationships between dedicated infrastructure and improved cybersecurity outcomes. The proposed benefits require empirical validation using the evaluation framework developed in Chapter 12.

Second, the literature on LLMs in cybersecurity remains relatively young and heterogeneous. Many studies evaluate individual tasks or benchmark environments rather than long-term operational deployments. Results obtained in controlled experimental settings may therefore not generalize directly to production SOC environments.

Third, the concept of sovereignty remains multidimensional and context-dependent. The degree of control required by an organization depends on its regulatory environment, threat model, contractual obligations, infrastructure, and business model.

Fourth, technological change may alter the trade-offs identified in this paper. Improvements in model efficiency, confidential computing, privacy-preserving technologies, model portability, and AI infrastructure services could change the relative advantages of different deployment architectures.

These limitations reinforce the need for longitudinal and comparative research rather than definitive claims based on current infrastructure configurations.

13.10 Synthesis

The central contribution of this discussion is therefore a refinement of the proposition that dedicated AI infrastructure creates “sovereign AI.”

A stronger and more defensible formulation is:

Dedicated AI infrastructure can provide greater organizational control over critical AI processing, sensitive data flows, model execution, and operational dependencies, but this control becomes strategically meaningful only when supported by appropriate security engineering, governance, organizational capabilities, and continuous evaluation.

This formulation avoids three conceptual errors.

First, it avoids equating location with security. On-premises infrastructure can improve control but remains subject to technical and organizational vulnerabilities.

Second, it avoids equating sovereignty with independence. Modern AI systems remain embedded in global technology ecosystems; the realistic objective is controlled interdependence and strategic autonomy over critical capabilities.

Third, it avoids equating infrastructure with compliance. Compliance is an organizational property emerging from the interaction between architecture, processes, governance, evidence, and applicable law.

These distinctions ultimately strengthen the central argument of the paper. The value of dedicated AI infrastructure does not lie in the physical location of compute alone. Its value lies in the ability to establish a controlled environment in which sensitive data, AI models, security workflows, human decisions, and governance mechanisms can be integrated and continuously managed.

The resulting strategic objective can therefore be expressed as:

Control what must be controlled, externalize what can safely be externalized, and govern the dependencies that remain.

This is a more realistic conception of AI sovereignty than the pursuit of absolute technological independence. It also aligns with the AI-by-Design framework developed throughout this paper: trustworthy AI requires deliberate architectural choices that connect infrastructure control with privacy, security, governance, human oversight, auditability, and accountability.

Ultimately, the question facing cybersecurity organizations is not whether AI should be “on-premises” or “in the cloud” in the abstract. It is which architecture provides the appropriate degree of control, security, efficiency, resilience, and governance for a particular AI-enabled cybersecurity function.

The answer may differ between use cases. What matters is that the decision is explicit, risk-informed, measurable, and supported by evidence.

In this sense, dedicated AI infrastructure should be understood neither as a guarantee of sovereignty nor as merely an alternative hosting model. It is better understood as a strategic control mechanism that, when embedded within a mature AI-by-Design architecture, can contribute to data sovereignty, operational resilience, trustworthy AI governance, and the development of differentiated cybersecurity capabilities.

The broader conclusion is therefore consistent with the maturity and evaluation frameworks proposed in the preceding chapters:

Sovereign AI is not defined by where the server is located. It is defined by the organization's ability to control, govern, secure, explain, and audit the critical AI-enabled processes on which it depends.

This distinction provides a more rigorous foundation for both future research and practical AI strategy in cybersecurity.

14. Conclusion

The rapid emergence of generative AI and large language models is creating significant opportunities for cybersecurity organizations. LLMs can process heterogeneous security information, support analysts in complex investigations, enrich threat intelligence, summarize incidents, retrieve organizational knowledge, and automate repetitive activities. Recent research indicates substantial potential for these capabilities across security operations while simultaneously demonstrating that reliability, security, governance, and autonomous decision-making remain unresolved challenges. The strategic question is therefore no longer whether AI can contribute to cybersecurity, but how AI can be integrated into cybersecurity operations without compromising the security, sovereignty, accountability, and trustworthiness of the underlying service.

This paper addressed this question by examining how dedicated, organization-controlled AI infrastructure can contribute to data sovereignty, cybersecurity, and trustworthy governance of LLM-based security services. The analysis supports a qualified but significant conclusion: dedicated AI infrastructure can strengthen organizational control over critical AI processing and sensitive data flows, but infrastructure control alone does not constitute trustworthy or sovereign AI.

The distinction between data residency and data sovereignty is central to this conclusion. Data residency concerns where information is stored or processed. Sovereignty concerns who can meaningfully control that processing and whether such control can be demonstrated. For AI systems, this includes control over processing location, access, model execution, software and model updates, logging, retention, deletion, external dependencies, and auditability. Dedicated infrastructure can bring a greater proportion of these activities under direct organizational control, thereby reducing certain forms of external dependency and strengthening the organization's ability to establish defined processing boundaries.

However, the analysis also demonstrates that on-premises does not equal secure. Operating AI infrastructure internally transfers responsibilities for infrastructure security, model and application security, vulnerability management, patching, supply-chain security, monitoring, resilience, and incident response to the organization. A locally deployed LLM remains exposed to hallucinations, prompt injection, unauthorized access, model manipulation, insecure tool use, and other AI-specific risks. Consequently, the security benefits of dedicated infrastructure can only be realized when it is embedded within a comprehensive security architecture.

Similarly, sovereignty does not equal isolation. Contemporary AI systems depend on globally distributed semiconductor supply chains, software ecosystems, model providers, open-source communities, research networks, and technical standards. Complete technological independence is therefore neither realistic nor necessarily desirable. The paper consequently proposes controlled interdependence as a more useful conception of AI sovereignty. Organizations should identify which external dependencies are acceptable, which require mitigation, and which critical capabilities or data flows should remain under direct organizational control.

The same qualification applies to compliance. Compliance is not a property of infrastructure location. A system operating entirely on-premises does not automatically satisfy Swiss data-protection law, the GDPR, NIS2, or other applicable requirements. Compliance emerges from the interaction between technical architecture, organizational processes, contractual relationships, data governance, risk management, accountability, and evidence. Dedicated infrastructure can support compliance by increasing control over processing and data flows, but governance processes are required to establish and demonstrate compliance.

These findings support the broader concept of AI by Design developed in this paper. Rather than treating governance as an additional layer introduced after deployment, AI by Design incorporates privacy, security, sovereignty, transparency, accountability, human oversight, and auditability into the architecture and lifecycle of AI systems from the outset. The resulting architecture spans infrastructure sovereignty, data sovereignty, model governance, security engineering, AI governance, human oversight, and auditability. These layers are interdependent: infrastructure control cannot compensate for poor data governance, while sophisticated model governance cannot compensate for uncontrolled access to the underlying environment.

The analysis also leads to an important qualification concerning automation. LLMs should not be evaluated according to the extent to which they can replace human decision-making. Their value is better assessed according to the amount of validated operational value they can produce within defined risk boundaries. This supports a model of AI-augmented cybersecurity in which AI performs computationally intensive, repetitive, and information-processing tasks while deterministic controls and human experts retain authority over consequential decisions. The distinction between automation and uncontrolled autonomy is particularly important in SOC environments, where erroneous prioritization or unsupported conclusions can have significant consequences.

The proposed maturity model provides a conceptual pathway for organizations undertaking this transition. AI adoption can progress from external AI consumption, through controlled enterprise AI and dedicated AI environments, toward governed AI operations and ultimately AI-native cybersecurity operations. Importantly, maturity is not defined by infrastructure sophistication or model capability alone. It reflects the organization's ability to control data, secure infrastructure, govern models, validate outputs, maintain human oversight, demonstrate accountability, and continuously evaluate operational outcomes.

This also changes how dedicated AI infrastructure should be evaluated strategically. Its value cannot be reduced to whether local inference is cheaper or faster than an external AI service. The relevant benefits may include increased control over sensitive data, reduced dependency on individual AI providers, greater resilience against external service changes, controlled experimentation, model portability, lower latency for selected workloads, and the ability to integrate proprietary security knowledge into AI-enabled services. At the same time, these benefits must be weighed against infrastructure costs, energy consumption, specialist skills, maintenance requirements, and supply-chain dependencies.

The paper therefore argues that the competitive advantage of AI in cybersecurity is unlikely to arise primarily from access to a particular foundation model. As model capabilities become increasingly accessible, differentiation is more likely to emerge from the organization's ability to combine:

models + proprietary data + security workflows + organizational expertise + governance.

Dedicated infrastructure can provide an important foundation for this combination, particularly where sensitive data and critical cybersecurity operations require a high degree of control. Yet the infrastructure itself is not the strategic asset. The strategic asset is the organizational capability built around it.

This conclusion also has implications for future research. The claims developed in this paper are conceptual and should not be interpreted as empirical evidence that dedicated AI infrastructure is universally superior to externally hosted alternatives. Future research should compare alternative architectures using use-case-specific measures of data sovereignty, security, operational efficiency, response performance, quality, governance, cost, energy consumption, analyst acceptance, and customer trust. Particular attention should be paid to longitudinal evaluation because model behavior, threat environments, organizational workflows, and AI technologies continuously evolve.

Most importantly, future studies should evaluate AI at the level of the governed cybersecurity workflow, rather than treating model performance as the primary unit of analysis. A model that performs well in incident summarization may perform poorly in alert prioritization; a highly capable model may generate limited operational value if its outputs require extensive verification; and a technically accurate system may remain unsuitable for production if its data flows and actions cannot be governed or audited.

The central conclusion is therefore deliberately more nuanced than the proposition that organizations should simply “move AI on-premises.”

Dedicated AI infrastructure is not synonymous with sovereign, secure, or compliant AI. Rather, it is an architectural mechanism through which organizations can increase control over critical AI processing and data flows. Its strategic and governance value emerges when that control is combined with security engineering, data and model governance, validated automation, human oversight, auditability, and organizational accountability.

This leads to the final conceptual proposition of the paper:

Sovereign AI is not defined by where the server is located. It is defined by the organization's ability to control, govern, secure, explain, and audit the critical AI-enabled processes on which it depends.

Under this interpretation, sovereignty is best understood as demonstrable control within a system of controlled interdependence. Organizations do not need to eliminate every external dependency. They need to understand which dependencies matter, determine which can be accepted, protect those that cannot, and retain sufficient autonomy over critical AI capabilities.

For cybersecurity service providers, this distinction is particularly consequential. Their customers entrust them with information that is simultaneously operationally valuable and security-critical. The deployment of AI therefore creates a second-order responsibility: providers must not only secure their customers' environments but also ensure that the AI systems used to provide that security are themselves appropriately controlled, governed, and accountable.

The future of AI-enabled cybersecurity is consequently unlikely to be characterized by fully autonomous security operations. A more credible trajectory is toward highly capable, continuously evaluated, human-augmented security operations, supported by architectures that make AI processing increasingly controllable, auditable, and trustworthy.

The contribution of dedicated AI infrastructure within this trajectory is therefore best understood not as an end state, but as an enabling capability. When combined with AI by Design, it can provide the technical foundation for controlled data flows, domain-specific AI services, operational resilience, and trustworthy governance. The ultimate objective is not to maximize AI autonomy or minimize external dependencies at any cost. It is to maximize validated operational value under controlled risk.

In this sense, the strategic question for cybersecurity organizations is not simply where AI runs, but whether the organization can remain in meaningful control of what the AI processes, what it produces, what it is permitted to do, and who remains accountable for the outcome.

That is the fundamental premise of AI by Design—and, ultimately, the basis for trustworthy sovereign AI in cybersecurity.

References

Chesterman, S., Gao, Y., Hahn, J., & Sticher, V. (2024). The evolution of AI governance. Computer, 57(9), 80–92.

Hasanov, I., Virtanen, S., Hakkala, A., & Isoaho, J. (2024). Application of large language models in cybersecurity: A systematic literature review. IEEE Access, 12, 176751–176778.

Hilario, E., Azam, S., Sundaram, J., et al. (2024). Generative AI for pentesting: The good, the bad, the ugly. International Journal of Information Security, 23, 2075–2097.

Humphreys, D., Koay, A., Desmond, D., et al. (2024). AI hype as a cyber security risk: The moral responsibility of implementing generative AI in business. AI and Ethics, 4, 791–804.

Lahusen, C., Maggetti, M., & Slavkovik, M. (2024). Trust, trustworthiness and AI governance. Scientific Reports, 14, 20752.

Liu, Y., Huang, J., Li, Y., Wang, D., et al. (2025). Generative AI model privacy: A survey. Artificial Intelligence Review, 58, 33.

Novelli, C., Casolari, F., Hacker, P., Spedicato, G., & Floridi, L. (2024). Generative AI in EU law: Liability, privacy, intellectual property, and cybersecurity. Computer Law & Security Review, 55, 106066.

Rieger, M., Shah, A., Alam, A., & Hossain, M. J. (2026). Possibilities and limitations of using large language models (LLMs) for alert classification and prioritisation in security operations centers (SOCs). Expert Systems with Applications, 331, 133194.

Swaminathan, N., & Danks, D. (2024). Governing ethical gaps in distributed AI development. Digital Society, 3, 7.

Tamò-Larrieux, A., Guitton, C., Mayer, S., & Lutz, C. (2024). Regulating for trust: Can law establish trust in artificial intelligence? Regulation & Governance, 18, 780–801.

Walter, Y. (2024). Managing the race to the moon: Global policy and governance in Artificial Intelligence regulation—A contemporary overview and an analysis of socioeconomic consequences. Discover Artificial Intelligence, 4, 14.

Ye, X., Yan, Y., Li, J., & Jiang, B. (2024). Privacy and personal data risk governance for generative artificial intelligence: A Chinese perspective. Telecommunications Policy, 48(10), 102851.

Habibzadeh, A., Feyzi, F., & Ebrahimi Atani, R. (2026). Large language models for security operations centers: A comprehensive survey. Journal of Electrical and Computer Engineering, 2026, 3383674.

Contact

Reach out via email for inquiries.

Email

Subscribe to newsletter

info@grcadvisory.ch

© 2025. All rights reserved.