AIML and Cybersecurity

Chapter 14
Enterprise Strategy, Cases and Emerging Directions

Post Graduate Program in Cyber Security
AIML and Cybersecurity   •   Post Graduate

14. Enterprise Strategy, Cases and Emerging Directions

Introduction and Context

Artificial intelligence and machine learning have moved from experimental security tools to strategic capabilities that influence how enterprises detect threats, manage exposure, respond to incidents, and allocate scarce security resources. Yet the acquisition of an AI platform does not constitute cyber transformation. Transformation occurs when intelligence, operating models, governance, technology, and people are redesigned so that an organisation can make better security decisions at an acceptable level of risk and cost.

For enterprise leaders, the central question is not simply whether AI can identify malware or classify alerts. It is whether an AI-enabled security capability improves business resilience, reduces decision latency, supports regulatory obligations, and remains trustworthy during adversarial conditions. This requires a business case, an implementation roadmap, measurable outcomes, and a clear understanding of what should be built internally, purchased from a vendor, or delivered through a hybrid model.

This chapter examines strategic decision-making for AI-driven cybersecurity. It connects technical capabilities with investment reasoning, organisational change, resilience, talent, procurement, and governance. It also considers emerging developments—including autonomous agents, synthetic media, quantum-era risks, and adaptive defence—that may alter the balance between attackers and defenders.

Learning Objectives

After studying this chapter, students should be able to:

1. Construct a business case for AI-enabled cybersecurity transformation.

2. Evaluate cost, value, resilience, talent, and risk in strategic decisions.

3. Compare build, buy, and hybrid approaches to AI security capability.

4. Design a phased roadmap with governance, metrics, and assurance controls.

5. Analyse an enterprise incident involving AI-supported cyber defence.

6. Explain the strategic implications of autonomous agents, synthetic media, quantum computing, and adaptive defence.

7. Identify ethical, regulatory, operational, and supply-chain risks in enterprise AI security.

From Security Tooling to Enterprise Capability

Traditional cybersecurity investment often follows a tool-centred logic: a business purchases a system to address a defined technical problem. AI changes the scale and character of this decision. A detection model may depend on identity data, endpoint telemetry, cloud logs, network flows, threat intelligence, and analyst feedback. Its effectiveness therefore depends on data architecture and operating discipline as much as on the algorithm.

An enterprise AI security capability can be viewed as a socio-technical system with five interacting layers:

  • Mission and risk layer: business services, critical assets, risk appetite, legal duties, and resilience objectives.
  • Data layer: collection, quality, lineage, access control, retention, labelling, and privacy protection.
  • Analytical layer: detection models, anomaly analysis, language models, graph analytics, and decision-support logic.
  • Operational layer: security operations, incident response, vulnerability management, identity administration, and recovery.
  • Governance layer: accountability, assurance, model risk management, auditability, and human oversight.

Weakness at any layer can undermine the whole capability. For example, a highly accurate model trained on incomplete endpoint data may fail during a cloud migration. A technically effective automated response may disrupt a critical manufacturing process if business context is absent. Strategic planning must therefore begin with the enterprise mission and risk landscape rather than with a particular AI product.

Building the Business Case

A business case translates a technical proposal into an investment decision. It should explain the problem, the proposed intervention, expected benefits, costs, risks, alternatives, and measures of success. Cybersecurity benefits are frequently uncertain because the organisation is paying to reduce the probability or impact of future events. A credible case should therefore avoid claiming that a tool will prevent all attacks.

Establishing the Baseline

The baseline should include current incident volume, mean time to detect, mean time to respond, false-positive rates, analyst workload, control coverage, vulnerability remediation time, third-party exposure, and recovery performance. Financial information may include security staffing costs, technology licensing, consulting expenditure, outage costs, regulatory penalties, contractual losses, and the value of disrupted business services.

The baseline should also distinguish activity measures from outcome measures. The number of alerts processed is an activity measure; reduction in the time required to contain a material incident is an outcome measure. Similarly, the number of models deployed says little about whether critical assets are better protected.

Estimating Value

The value of AI-enabled security may arise through several channels:

1. Loss avoidance: lowering the likelihood or impact of compromise.

2. Operational efficiency: reducing repetitive investigation and triage.

3. Decision quality: improving prioritisation of vulnerabilities and incidents.

4. Resilience: reducing service interruption and improving recovery confidence.

5. Compliance and assurance: producing evidence for internal and external scrutiny.

6. Strategic enablement: allowing secure adoption of cloud, automation, and digital services.

A simplified expected-loss model is:

Expected annual loss = probability of an adverse event × business impact of the event.

An investment is not automatically justified when its cost is lower than estimated loss reduction, because uncertainty, dependencies, and residual risk must also be considered. Scenario analysis is preferable to a single precise estimate. Management may compare conservative, central, and severe assumptions, including the possibility that a new system introduces errors or creates a concentration risk with a vendor.

The business case should include total cost of ownership rather than acquisition price alone. Relevant costs include integration, data engineering, model evaluation, cloud consumption, retraining, monitoring, specialist staff, licensing changes, incident investigation, contractual assurance, and eventual migration or exit.

A Strategic Framework for Transformation

A useful enterprise framework combines four questions: What must be protected? What decisions should AI improve? What level of autonomy is acceptable? How will the organisation know that the capability is working?

Risk and Mission Alignment

Security priorities should be derived from business services and dependencies. A hospital, a bank, and a logistics provider may use similar detection technology, but their highest-value assets, safety requirements, recovery tolerances, and regulatory obligations differ. Critical service mapping helps determine where automated containment is appropriate and where human approval is mandatory.

Capability Maturity

A practical maturity path is:

  • Ad hoc: disconnected tools, manual analysis, limited data ownership.
  • Visible: centralised telemetry, documented use cases, baseline metrics.
  • Integrated: data pipelines, coordinated workflows, identity and asset context.
  • Measured: model performance, business outcomes, assurance testing, and continuous improvement.
  • Adaptive: controlled automation, adversarial testing, resilient architecture, and rapid learning from incidents.

Maturity is not simply the number of AI features. An organisation with fewer models but reliable data, strong response processes, and effective governance may be more mature than one with extensive automation and weak control.

Portfolio Rather Than Single-Project Thinking

AI security transformation should be managed as a portfolio. Early projects may include alert summarisation, phishing analysis, vulnerability prioritisation, identity anomaly detection, and investigation assistance. Projects should be selected according to value, feasibility, risk, and learning potential. Low-risk decision support can generate experience before high-impact automated actions are introduced.

A portfolio board should examine dependencies. For example, automated identity response depends on accurate asset ownership, privileged-access controls, tested rollback procedures, and reliable communication with service owners. Treating each use case as independent often produces fragmented data and duplicated expenditure.

Build, Buy, or Hybrid?

The build-versus-buy decision is strategic rather than ideological. Building internally may provide differentiation, control over sensitive data, customisation, and institutional knowledge. It also requires sustained investment in data engineering, machine learning, security operations, model governance, and platform maintenance. Buying may provide speed, specialised research, threat intelligence, and vendor-supported updates, but can create lock-in, opaque models, data-use concerns, and dependence on a supplier’s resilience.

A hybrid approach is often appropriate. An enterprise may purchase a security data platform and foundation model, while building proprietary detection logic, contextual risk scoring, workflow integration, and governance controls. The decision should consider:

  • sensitivity and sovereignty of data;
  • uniqueness of the organisation’s processes;
  • required time to value;
  • available technical talent;
  • performance and explainability requirements;
  • integration and portability;
  • vendor financial and operational resilience;
  • contractual rights to data, logs, models, and derived artefacts;
  • audit, testing, and incident-notification obligations.

Procurement should require evidence rather than demonstrations alone. Evaluation should use representative enterprise data, realistic attack scenarios, adversarial testing, failure analysis, and total-cost projections. Contracts should address service availability, model changes, data retention, subcontractors, security testing, breach notification, intellectual property, exit assistance, and secure deletion.

Roadmapping Implementation

A credible roadmap is phased, measurable, and reversible.

Phase one—foundation: identify critical services, establish data ownership, improve asset and identity inventories, define governance, and select a small number of use cases.

Phase two—controlled pilots: test decision-support applications in a sandbox or limited operational setting. Establish reference datasets, human review, performance thresholds, and rollback procedures.

Phase three—operational integration: connect validated capabilities to security workflows, ticketing, case management, identity systems, and incident response. Introduce automation only where authority boundaries are explicit.

Phase four—scaling and assurance: extend coverage, monitor drift, conduct red-team assessments, validate supplier controls, and report business outcomes to senior leadership.

Phase five—continuous adaptation: incorporate lessons from incidents, threat evolution, regulatory change, and changes in business architecture. Retire models and workflows that no longer produce sufficient value.

Each phase should have entry and exit criteria. A pilot should not proceed to autonomous action merely because its average accuracy is high. It should demonstrate acceptable performance on rare but high-consequence cases, resistance to manipulation, traceability, and safe failure.

Measuring Strategic Performance

Metrics should connect technical performance with enterprise outcomes. Useful measures include mean time to detect and contain, proportion of critical assets covered, reduction in false positives, analyst hours saved, percentage of high-risk vulnerabilities remediated within target time, recovery time, model drift, override frequency, and the rate of harmful automated actions.

A balanced scorecard can include:

  • Security outcomes: incidents prevented, contained, or reduced in impact.
  • Operational outcomes: response speed, investigation quality, workload, and service availability.
  • Economic outcomes: cost per investigated case, avoided loss, and total cost of ownership.
  • Trust outcomes: audit findings, privacy incidents, user complaints, and explainability quality.
  • Learning outcomes: validated improvements following exercises or real incidents.

Metrics can themselves become misleading targets. If analysts are rewarded only for closure speed, they may close cases prematurely. If a model is judged only by precision, missed attacks may be ignored. Balanced measures and periodic qualitative review are therefore necessary.

Talent and Organisational Change

AI-driven cyber transformation does not eliminate the need for professionals; it changes the composition of expertise. Organisations need security analysts who can interrogate model output, data engineers who understand telemetry and privacy, machine learning specialists who understand adversarial conditions, incident responders who can validate automated actions, and leaders capable of connecting cyber risk to business priorities.

Operating models should define responsibility using mechanisms such as a responsibility assignment matrix. The security function may own detection logic, while business service owners approve disruption thresholds, privacy officers assess personal-data processing, legal teams review contractual exposure, and internal audit evaluates control effectiveness.

Change management is essential. Analysts may distrust systems that produce unexplained recommendations, while managers may overtrust fluent language-model output. Training should cover limitations, escalation, evidence preservation, prompt-injection risks, and the difference between confidence and correctness. Human oversight must be meaningful: reviewers need sufficient time, authority, context, and technical ability to reject an automated recommendation.

Case Study: The Meridian Health Network Transformation

This is an illustrative case designed for academic analysis.

Background

Meridian Health Network operates hospitals, diagnostic laboratories, outpatient clinics, and a telehealth platform. Its environment includes medical devices, cloud services, identity systems, electronic health records, and several suppliers. The security team receives approximately 30,000 alerts per month from endpoint, email, network, and identity systems. Analysts spend considerable time investigating duplicate alerts and low-value events, while critical identity compromises have occasionally remained hidden among normal administrative activity.

Situation and Problem

The board approves a three-year cyber-resilience programme after a sector ransomware incident disrupts patient scheduling. Meridian’s chief information security officer proposes an AI platform for alert correlation, phishing analysis, identity anomaly detection, and response recommendations. The finance department is concerned about recurring licensing costs; clinicians are concerned about service disruption; the privacy office is concerned about sending sensitive telemetry to an external provider.

Analysis

An initial review finds that Meridian lacks a reliable inventory of medical devices and has inconsistent ownership information for cloud accounts. Historical alert labels are incomplete, and different hospitals use different incident classifications. The team concludes that model accuracy will be limited unless data quality and process consistency improve. It also identifies a safety constraint: automated account isolation could interrupt clinical operations if applied to shared service accounts.

A business-case analysis compares three options: buying a fully managed platform, building an internal system, and adopting a hybrid approach. The fully managed option is fastest but has extensive data-transfer and lock-in concerns. The internal option offers control but cannot be staffed within the desired timeframe. The hybrid option combines a managed analytics service with local data minimisation, internally governed response logic, and a retained audit store.

Strategy and Implementation

During the first six months, Meridian maps critical clinical services, improves identity ownership, standardises incident categories, and establishes a privacy-preserving telemetry architecture. A pilot is limited to phishing analysis and alert summarisation. Analysts must validate every recommendation, and all model outputs are recorded with source evidence.

In the second phase, identity anomaly detection is introduced for privileged accounts. The system can recommend temporary access restrictions, but execution requires approval from an on-call security manager and the relevant service owner. A break-glass process is tested for clinical emergencies. The organisation conducts adversarial exercises involving poisoned feedback, misleading email content, and attempts to manipulate model context.

In the third phase, selected low-risk actions—such as quarantining a confirmed malicious email—are automated. High-impact actions remain subject to human approval. Vendor contracts require notification of material model changes, independent assurance reports, data deletion, portability, and support during exit.

Outcome

After one year, Meridian reports faster triage, fewer duplicate investigations, and improved visibility into privileged-account activity. It does not claim that AI prevented all attacks. Instead, it reports improved containment time and a clearer evidence trail for major incidents. The programme also identifies weaknesses in device inventory and supplier access, leading to investments outside the AI platform.

Learning Points

The case demonstrates that transformation depends on foundations, not only algorithms. It also shows why autonomy should be graduated according to business impact, why privacy and clinical safety must shape architecture, and why outcome metrics are more meaningful than model counts. Finally, the hybrid approach preserves strategic control while obtaining specialist capability from a supplier.

Autonomous Agents and the Changing Control Problem

An autonomous cyber agent is a software system that can interpret objectives, plan tasks, call tools, and execute actions with limited human intervention. Such agents may investigate alerts, query logs, test controls, open tickets, or coordinate containment. Their potential value lies in speed and persistence; their risk lies in compounding errors across multiple actions.

Agentic systems require bounded authority. A useful control design includes explicit tool permissions, narrow objectives, transaction limits, approval gates, time limits, immutable logging, sandbox execution, and emergency shutdown. Agents should not be allowed to redefine their own authority or treat unverified retrieved content as instructions. Prompt injection, tool misuse, excessive privilege, hidden state, and poorly understood interactions are central risks.

The strategic question is not whether an agent is intelligent, but whether its actions are safe, reversible, observable, and proportionate to the business impact. In high-consequence environments, agents should initially operate as advisers or execute only pre-approved playbooks.

Synthetic Media, Fraud, and Trust Infrastructure

Generative systems make it easier to create convincing text, voice, images, and video. Synthetic media can support phishing, executive impersonation, fraudulent payment instructions, fabricated evidence, and social engineering. Detection alone is insufficient because generated content changes rapidly and detectors may produce false positives.

Organisations should combine technical detection with identity verification, transaction controls, out-of-band confirmation, least privilege, staff awareness, provenance mechanisms, and clear escalation procedures. A voice message requesting an urgent transfer should not be trusted merely because it resembles a known executive. Trust must be anchored in process and cryptographic or organisational verification rather than appearance.

Quantum-Era Risks and Preparation

Quantum computing creates a strategic concern because sufficiently capable quantum systems could threaten widely used public-key cryptography through algorithms such as Shor’s algorithm. The timing of practical capability is uncertain, but data with long confidentiality lifetimes may already be at risk from “harvest now, decrypt later” collection.

Quantum readiness begins with cryptographic inventory: identifying algorithms, certificates, protocols, embedded devices, suppliers, and data whose confidentiality or authenticity must persist. Organisations should favour crypto-agile architectures, maintain upgrade paths, test post-quantum cryptographic standards as appropriate, and require supplier plans. Migration is not a single replacement exercise; it involves interoperability, performance, certification, legacy systems, and operational deployment. Strategic preparation is justified by long system lifecycles and the difficulty of replacing cryptography embedded in devices and contracts.

Adaptive Defence and Resilience

Adaptive defence uses continuous sensing, analysis, controlled experimentation, and feedback to change protections as threats and business conditions evolve. It may include dynamic access policies, deception environments, automated attack-surface prioritisation, moving-target techniques, and recovery orchestration. Adaptation should not mean uncontrolled change. Security controls that change without testing can create instability or obscure accountability.

Resilience provides the governing objective. A resilient organisation can resist, absorb, recover from, and learn through disruption. AI may improve anticipation and response, but resilience also depends on segmentation, backups, manual procedures, alternate suppliers, communications, exercises, and leadership decisions. AI systems themselves require resilience: redundant data paths, model fallback, supplier continuity, degraded-mode operation, and recovery of configuration and evidence.

Risks, Ethics, and Governance

Enterprise AI security introduces several forms of risk. Data may contain personal, confidential, or regulated information. Models may encode bias, generate unsupported explanations, or fail on rare events. Attackers may poison training data, evade detection, steal prompts, extract sensitive information, or manipulate feedback. Vendors may change models without adequate notice, creating performance drift or audit problems.

Governance should address purpose limitation, data minimisation, access control, retention, transparency, accountability, testing, and incident reporting. High-impact decisions should have documented human responsibility and appeal or review mechanisms where individuals may be affected. Organisations must comply with applicable privacy, critical-infrastructure, sectoral, employment, records-management, and AI regulation requirements; technical capability does not remove legal responsibility.

Common mistakes include purchasing before defining the problem, measuring demonstrations instead of outcomes, automating high-impact actions too early, ignoring data lineage, failing to plan vendor exit, and treating a model’s confidence score as proof. Another mistake is assuming that a language model’s fluent explanation is an audit-quality explanation. Evidence must be independently traceable to authoritative data and recorded actions.

Current Strategic Directions

Several developments are shaping enterprise planning. Security operations are moving toward natural-language investigation interfaces, but these require strict evidence grounding. Organisations are combining graph analytics with machine learning to represent relationships among identities, devices, applications, and behaviours. Privacy-enhancing techniques may support collaborative detection while reducing exposure of raw data. Small, specialised models may be preferred for predictable security tasks because they can be cheaper, faster, and easier to constrain than general-purpose models.

The strategic trend is toward continuous assurance. Instead of assessing an AI system once before deployment, enterprises will increasingly test it throughout its lifecycle for drift, adversarial behaviour, unsafe actions, supply-chain changes, and resilience. The most mature organisations will treat AI security as an enterprise capability governed by risk appetite, not as an isolated innovation project.

Best-Practice Principles

A practical set of principles is as follows:

1. Start with critical services and decisions, not fashionable technology.

2. Establish data ownership, lineage, quality, and protection before scaling models.

3. Use pilots to learn, but define measurable exit criteria.

4. Introduce autonomy gradually according to reversibility and business impact.

5. Preserve human accountability for consequential decisions.

6. Test models and agents against adversarial, rare, and failure scenarios.

7. Include integration, monitoring, skills, and exit costs in investment decisions.

8. Demand contractual transparency and portability from vendors.

9. Measure resilience and business outcomes, not only accuracy or activity.

10. Reassess the portfolio as threats, regulation, technology, and organisational priorities change.

Chapter Summary

AI-driven cybersecurity transformation is an enterprise strategy rather than a technology purchase. A sound business case begins with critical services, establishes a baseline, estimates value under uncertainty, and includes total cost of ownership. Strategic choices must address data, operating models, talent, governance, resilience, and the balance between building and buying capability.

A phased roadmap allows organisations to begin with controlled decision support, integrate validated use cases, and introduce autonomy only when actions are bounded, observable, reversible, and proportionate. The Meridian case illustrates the importance of data foundations, hybrid sourcing, privacy, clinical or operational safety, and outcome-based measurement.

Emerging autonomous agents, synthetic media, quantum risks, and adaptive defence expand both opportunity and exposure. Their responsible use requires cryptographic and operational agility, human accountability, adversarial testing, supplier assurance, and continuous evaluation. Strategic maturity is demonstrated not by the number of AI systems deployed, but by the organisation’s ability to improve security decisions while preserving trust and resilience.

Key Terms

AI-driven cyber transformation: Organisational change using AI to improve cybersecurity decisions, operations, and resilience.

Business case: A structured justification for investment based on benefits, costs, risks, alternatives, and outcomes.

Total cost of ownership: All lifecycle costs of a capability, including acquisition, integration, operation, assurance, and exit.

Expected annual loss: Estimated loss obtained by combining event probability with business impact.

Security telemetry: Data generated by systems and controls that supports monitoring and analysis.

Model drift: Decline or change in model performance caused by changing data, behaviour, or conditions.

Build-versus-buy: Strategic comparison between internal development and external procurement.

Hybrid sourcing: Combining purchased platforms or services with internally developed logic, integration, or governance.

Crypto-agility: The ability to replace cryptographic mechanisms without major architectural disruption.

Autonomous agent: Software that can plan and execute tasks using tools with limited human intervention.

Prompt injection: Manipulation of an AI system through hostile instructions embedded in input or retrieved content.

Synthetic media: Artificially generated or manipulated text, audio, images, or video.

Adaptive defence: Security that changes controls or priorities in response to threat and environmental feedback.

Resilience: The capacity to resist, absorb, recover from, and learn through disruption.

Human oversight: Meaningful human responsibility to review, approve, reject, or correct AI-supported actions.

Data lineage: A record of data origin, transformation, movement, and use.

Vendor lock-in: Dependence on a supplier that makes substitution or migration difficult or costly.

Model assurance: Evaluation of a model’s performance, safety, security, fairness, and reliability.

Review Questions

Short Answer Questions

1. Why is AI security transformation considered a socio-technical capability rather than a software purchase?

2. What is included in total cost of ownership for an AI security system?

3. Define crypto-agility and explain its relevance to quantum-era preparation.

4. What is model drift, and why should it be monitored?

5. State two controls required before deploying an autonomous cyber agent.

Long Answer Questions

1. Explain how an enterprise can construct a defensible business case for AI-enabled cybersecurity transformation.

2. Compare build, buy, and hybrid sourcing approaches, including their strategic risks and benefits.

3. Describe a phased roadmap for implementing AI security capabilities from foundation to continuous adaptation.

4. Discuss the role of talent, operating models, and human accountability in AI-driven cyber transformation.

5. Explain how synthetic media, quantum computing, and adaptive defence affect enterprise cybersecurity strategy.

Analytical / Application Questions

1. An organisation has accurate alert summarisation but unreliable asset ownership data. Should it introduce automated account isolation? Analyse the decision and propose conditions for proceeding.

2. A vendor offers a highly capable security agent but refuses to provide model-change notifications or data-portability rights. Evaluate the procurement risk and recommend contract or sourcing actions.

3. Design a measurement framework for an AI security programme in a critical-service organisation. Distinguish technical, operational, economic, trust, and resilience outcomes.

22. Multiple Choice Questions with Answers

Question 1

Which consideration most directly distinguishes an enterprise AI security capability from a standalone security tool?

A. The number of machine learning algorithms used

B. Integration of mission, data, operations, people, and governance

C. The use of a cloud-based interface

D. The purchase of a high-performance graphics processor

Correct Answer: B. Integration of mission, data, operations, people, and governance

Question 2

Which measure is an outcome measure rather than an activity measure?

A. Number of alerts processed

B. Number of models deployed

C. Reduction in time to contain a material incident

D. Number of analyst logins

Correct Answer: C. Reduction in time to contain a material incident

Question 3

What is a major reason for adopting a hybrid build-and-buy strategy?

A. It eliminates the need for internal expertise

B. It combines vendor capability with internal control over context and governance

C. It guarantees that models will never drift

D. It removes all supplier and integration risks

Correct Answer: B. It combines vendor capability with internal control over context and governance

Question 4

Before granting an autonomous cyber agent authority to isolate accounts, an organisation should primarily ensure that the action is:

A. Fast, irreversible, and independent of business context

B. Based only on the agent’s confidence score

C. Bounded, observable, reversible, and proportionate to business impact

D. Hidden from service owners to prevent delay

Correct Answer: C. Bounded, observable, reversible, and proportionate to business impact

Question 5

In the Meridian case, why was automated isolation of some accounts considered unsafe?

A. The organisation had no internet connectivity

B. Shared accounts could support clinically important operations

C. The models used no telemetry

D. The vendor prohibited all automation

Correct Answer: B. Shared accounts could support clinically important operations

Question 6

Which procurement requirement most directly reduces vendor lock-in?

A. A larger marketing budget

B. Data portability and exit assistance

C. A shorter model name

D. Exclusive dependence on one supplier

Correct Answer: B. Data portability and exit assistance

Question 7

The ‘harvest now, decrypt later’ concern is most closely associated with:

A. Synthetic media fraud

B. Quantum-era threats to long-lived encrypted data

C. False-positive alert triage

D. Cloud service availability

Correct Answer: B. Quantum-era threats to long-lived encrypted data

Question 8

Which practice best addresses synthetic voice fraud involving an urgent payment request?

A. Trusting the voice if it resembles an executive

B. Using out-of-band verification and transaction controls

C. Disabling all email systems permanently

D. Relying exclusively on a media detector

Correct Answer: B. Using out-of-band verification and transaction controls

Question 9

Why should AI security programmes use balanced metrics?

A. A single metric may encourage behaviour that improves the measure but harms security

B. Balanced metrics eliminate the need for audits

C. Technical metrics are never useful

D. They guarantee that every attack will be prevented

Correct Answer: A. A single metric may encourage behaviour that improves the measure but harms security

Question 10

Which sequence best reflects a responsible transformation roadmap?

A. Full autonomy, data collection, governance, and pilot evaluation

B. Foundation, controlled pilots, operational integration, scaling and assurance

C. Vendor purchase, immediate deployment, and retrospective risk assessment

D. Model development, removal of human oversight, and indefinite operation

Correct Answer: B. Foundation, controlled pilots, operational integration, scaling and assurance

AIML and Cybersecurity
Chapter 14 of 14