Post-Incident Review and Lessons Learned for AI Systems
5 minutes
5 Questions
Post-Incident Review (PIR) and Lessons Learned for AI systems is a structured, blameless process conducted after an AI-related incident—such as model drift causing harmful outputs, a data poisoning attack, prompt injection exploitation, biased decisions, privacy leakage, or unsafe autonomous actions—to understand what happened, why it happened, and how to prevent recurrence. Within AI Security Management and Governance, PIR closes the loop of the AI risk lifecycle and feeds continuous improvement into the AI management system (e.g., ISO/IEC 42001, NIST AI RMF 'Manage' function). Key components include: (1) Incident reconstruction: building a timeline using logs, model versions, prompts, training data lineage, and deployment records; AI incidents require capturing model inputs/outputs, confidence scores, and data provenance, not just infrastructure events. (2) Root cause analysis: distinguishing technical causes (adversarial inputs, weak guardrails, insufficient evaluation), data causes (bias, contamination, drift), process causes (inadequate testing, missing human oversight), and governance causes (unclear ownership, weak change control). (3) Impact assessment: evaluating harm to individuals, groups, the organization, and regulatory exposure (EU AI Act serious-incident reporting, GDPR). (4) Control effectiveness review: assessing whether detection, monitoring, red-teaming, and response playbooks performed as designed. (5) Remediation and lessons learned: producing actionable items—retraining, updated guardrails, revised risk registers, improved evaluation benchmarks, policy changes, and training—each with owners and deadlines tracked to closure. AI-specific challenges make PIR distinctive: non-determinism complicates reproduction; opaque models hinder causal explanation; incidents may involve third-party foundation models with limited transparency; and harms can be diffuse or discovered long after occurrence. Effective programs therefore maintain AI incident taxonomies, share anonymized learnings (e.g., AI Incident Database), integrate findings into model cards and risk assessments, and report outcomes to AI governance committees and boards. Ultimately, PIR transforms incidents into organizational knowledge, strengthening resilience, accountability, regulatory compliance, and trustworthy AI over time.
Post-Incident Review and Lessons Learned for AI Systems (ISACA AAISM – AI Governance and Program Management)
Why Post-Incident Review Matters for AI Systems
AI systems fail in ways that traditional IT systems do not. A model may drift silently, produce biased outputs, hallucinate confidently, leak training data, be manipulated through prompt injection or adversarial inputs, or make automated decisions that cause harm long before anyone notices. Because these failures are often probabilistic, gradual, and difficult to reproduce, the organization's ability to learn from them is one of the most valuable governance capabilities it can build. A post-incident review (PIR) converts a costly event into institutional knowledge, strengthens controls, satisfies regulatory and stakeholder expectations for accountability, and demonstrates that the AI governance program is a living, improving system rather than a static set of policies. For the ISACA Advanced in AI Security Management (AAISM) exam, this topic sits within the AI Governance and Program Management domain because lessons learned feed directly back into risk assessment, policy, training, and program maturity.
What a Post-Incident Review Is
A post-incident review (also called a post-mortem, after-action review, or lessons-learned exercise) is a structured, blameless examination conducted after an AI-related incident has been contained and resolved. Its purpose is to establish what happened, why it happened, how well the organization responded, and what must change to prevent recurrence or reduce impact. In the AI context, an "incident" includes not only security breaches but also model performance failures, fairness or bias harms, safety events, unintended outputs, data poisoning, model theft, supply chain compromises of third-party models or datasets, and governance failures such as deployment without required approvals.
Key characteristics of an effective AI PIR:
• Blameless culture – focus on systemic and process causes, not individual fault, so that people report honestly.
• Evidence-based – grounded in logs, model monitoring data, prompts and outputs, version histories, and timelines rather than opinion.
• Multidisciplinary – involves data scientists, ML engineers, security, legal, privacy, compliance, risk, business owners, and where relevant ethics or responsible-AI functions.
• Action-oriented – produces owned, prioritized, time-bound corrective and preventive actions that are tracked to closure.
• Governance-linked – findings are reported to the AI governance body or steering committee and update the AI risk register.
How the Process Works
1. Trigger and scoping. The PIR is triggered once the incident response process has moved to recovery or closure. The scope defines which systems, models, datasets, decisions, and time period are in view. Severity classification (often aligned to the AI risk tiering used in the governance program) determines the depth and formality of the review.
2. Timeline reconstruction. The team builds a factual chronology: when the issue first began (not just when detected), when it was detected, how it was detected (monitoring alert, user complaint, auditor, media), escalation steps, containment actions, and resolution. For AI systems, the timeline should include model version deployed, data pipeline changes, retraining events, configuration or prompt changes, and third-party model updates. Metrics such as mean time to detect (MTTD) and mean time to respond (MTTR) are captured.
3. Root cause analysis (RCA). Techniques such as the 5 Whys, fishbone (Ishikawa) diagrams, fault tree analysis, or causal factor charting are used to move beyond the proximate cause to systemic causes. AI-specific root-cause categories include: data quality or data poisoning, training-serving skew, concept or data drift, inadequate validation or testing, insufficient guardrails, weak access controls on models or pipelines, over-reliance on vendor assurances, missing human oversight, unclear accountability, and gaps in change management or MLOps controls. The review should distinguish between the technical cause, the process cause, and the governance cause.
4. Impact assessment. Document actual and potential impacts: affected individuals or groups (with attention to disproportionate impact on protected groups), business impact, financial loss, regulatory exposure, privacy breaches, reputational harm, and safety consequences. Determine whether notification obligations were met (for example under data protection law or emerging AI regulations such as the EU AI Act serious-incident reporting requirements).
5. Response evaluation. Assess what worked and what did not: Were playbooks adequate for an AI incident? Could the model be rolled back or disabled quickly (kill switch)? Was there a known-good prior version? Were communications to stakeholders, regulators, and users timely and accurate? Did logging and monitoring provide enough evidence?
6. Lessons learned and recommendations. Translate findings into specific improvements: control enhancements, monitoring thresholds, model validation requirements, data governance changes, updated acceptable-use policies, training, vendor contract clauses, or architecture changes. Each action has an owner, priority, due date, and success measure.
7. Reporting and knowledge sharing. The PIR report is distributed to appropriate audiences with sensitivity in mind. Sanitized lessons are shared across teams and, where appropriate, with industry bodies (for example AI incident databases or ISACs). Results feed the AI risk register, the control library, the AI inventory, risk appetite discussions, and board or governance committee reporting.
8. Follow-up and verification. Governance requires that actions are tracked to closure and their effectiveness verified, often through a later audit or test. Recurring themes across multiple PIRs indicate program-level weaknesses and should drive maturity improvements.
Integration with the AI Governance Program
Post-incident review is the feedback loop of the AI lifecycle. It links to:
• Risk management – updates likelihood and impact ratings, reveals unidentified risks, and tests the validity of prior risk assessments.
• Policies and standards – incidents often expose gaps between documented requirements and actual practice.
• Monitoring and metrics – lessons define new key risk indicators (KRIs) and alert thresholds for drift, output anomalies, or misuse.
• Third-party management – findings may require changes to vendor due diligence, SLAs, and incident notification clauses for foundation model providers.
• Training and awareness – real incidents become case studies that build organizational competence.
• Continuous improvement – aligns with frameworks such as NIST AI RMF (Govern, Map, Measure, Manage), ISO/IEC 42001 (AI management system with continual improvement), ISO/IEC 27035 (incident management), and COBIT's monitor, evaluate and assess practices.
Common Pitfalls
• Treating the PIR as a blame exercise, which suppresses reporting.
• Stopping at the proximate technical cause (\"the model drifted\") without asking why monitoring did not catch it or why there was no retraining governance.
• Failing to involve business owners and affected-stakeholder perspectives.
• Producing recommendations without owners or deadlines.
• Not revisiting whether corrective actions actually worked.
• Ignoring near-misses, which are rich sources of lessons at low cost.
• Failing to update the AI risk register and governance documentation.
Exam Tips: Answering Questions on Post-Incident Review and Lessons Learned for AI Systems
Tip 1 – Think like a governance leader, not a technician. The AAISM exam is a management-level certification. When asked for the BEST or MOST important action after an AI incident, prefer answers about structured review, root cause analysis, updating the risk register, reporting to the governance body, and improving the program over answers that are purely technical fixes (such as \"retrain the model\" or \"patch the API\"). Technical remediation happens during incident response; the PIR is about learning and systemic improvement.
Tip 2 – Know the sequence. Questions often test order of operations: contain and recover first, then conduct the post-incident review once the incident is resolved. Within the review, root cause analysis precedes recommendations, and recommendations precede policy or control updates. If an answer skips to changing policy before understanding root cause, it is usually wrong.
Tip 3 – \"Blameless\" is a signal word. If an option emphasizes identifying who made the mistake or disciplinary action, it is almost always a distractor. Correct answers emphasize systemic causes, process failures, and a culture that encourages reporting.
Tip 4 – Distinguish root cause from symptom. Expect scenarios where a model produced biased outcomes or hallucinations. The exam wants you to look past the immediate symptom to governance causes such as inadequate validation testing, lack of representative training data, missing human oversight, absent monitoring thresholds, or poor change management. The BEST answer usually addresses the deeper cause.
Tip 5 – Look for the feedback loop. The primary objective of lessons learned is continuous improvement of the AI governance program. Correct answers typically mention updating the AI risk register, revising controls or policies, adjusting monitoring and KRIs, and feeding results into training and future risk assessments.
Tip 6 – Remember AI-specific incident types. The exam may define incidents broadly: model drift, data poisoning, prompt injection, adversarial examples, model inversion or extraction, biased or discriminatory outputs, unsafe automated decisions, and third-party model failures. Do not assume \"incident\" means only a confidentiality breach.
Tip 7 – Stakeholder involvement and reporting. When asked who should be involved or who receives the report, favor multidisciplinary participation (data science, security, legal, privacy, business owners, risk) and escalation to the AI governance committee or senior management. Regulatory reporting obligations and communication to affected individuals are governance responsibilities that may appear in scenarios.
Tip 8 – Watch for metrics questions. Be ready to identify MTTD, MTTR, recurrence rate of similar incidents, percentage of corrective actions closed on time, and number of near-misses reported as indicators of incident management maturity. Improvement in these metrics over time demonstrates that lessons learned are effective.
Tip 9 – Verification matters. If an option mentions tracking corrective actions to closure and validating their effectiveness (for example through follow-up audit or testing), it reflects mature governance and is frequently the best answer compared to simply \"documenting\" the lessons.
Tip 10 – Eliminate extremes. Options that suggest permanently shutting down all AI use, ignoring minor incidents, or relying solely on the vendor's explanation are usually distractors. The exam favors proportionate, risk-based, documented, and accountable responses.
Sample Question Walkthrough
An organization's AI-based credit decisioning model was found to have systematically disadvantaged a protected group for several months before a customer complaint triggered investigation. The issue has now been corrected. What should the AI security manager do FIRST as part of the post-incident review?
A. Discipline the data science team for inadequate testing.
B. Conduct a root cause analysis to determine why bias was introduced and why monitoring failed to detect it.
C. Immediately rewrite the AI ethics policy.
D. Replace the model with a rules-based system.
Correct answer: B. The review must establish root causes (both technical and governance-related) before policies are changed or technology decisions are made. A is blame-oriented, C is premature, and D is a technical decision that ignores the learning process.
Summary
Post-incident review and lessons learned turn AI failures into governance improvements. The process is structured, blameless, evidence-based, and multidisciplinary; it moves from timeline reconstruction through root cause analysis, impact and response evaluation, to owned corrective actions that are tracked, verified, and fed back into the AI risk register, controls, monitoring, training, and program maturity. On the AAISM exam, answer from the governance perspective: understand causes before acting, favor systemic and cultural improvements over blame or quick technical fixes, and always close the loop back to the AI governance program.
AI systems fail in ways that traditional IT systems do not. A model may drift silently, produce biased outputs, hallucinate confidently, leak training data, be manipulated through prompt injection or adversarial inputs, or make automated decisions that cause harm long before anyone notices. Because these failures are often probabilistic, gradual, and difficult to reproduce, the organization's ability to learn from them is one of the most valuable governance capabilities it can build. A post-incident review (PIR) converts a costly event into institutional knowledge, strengthens controls, satisfies regulatory and stakeholder expectations for accountability, and demonstrates that the AI governance program is a living, improving system rather than a static set of policies. For the ISACA Advanced in AI Security Management (AAISM) exam, this topic sits within the AI Governance and Program Management domain because lessons learned feed directly back into risk assessment, policy, training, and program maturity.
What a Post-Incident Review Is
A post-incident review (also called a post-mortem, after-action review, or lessons-learned exercise) is a structured, blameless examination conducted after an AI-related incident has been contained and resolved. Its purpose is to establish what happened, why it happened, how well the organization responded, and what must change to prevent recurrence or reduce impact. In the AI context, an "incident" includes not only security breaches but also model performance failures, fairness or bias harms, safety events, unintended outputs, data poisoning, model theft, supply chain compromises of third-party models or datasets, and governance failures such as deployment without required approvals.
Key characteristics of an effective AI PIR:
• Blameless culture – focus on systemic and process causes, not individual fault, so that people report honestly.
• Evidence-based – grounded in logs, model monitoring data, prompts and outputs, version histories, and timelines rather than opinion.
• Multidisciplinary – involves data scientists, ML engineers, security, legal, privacy, compliance, risk, business owners, and where relevant ethics or responsible-AI functions.
• Action-oriented – produces owned, prioritized, time-bound corrective and preventive actions that are tracked to closure.
• Governance-linked – findings are reported to the AI governance body or steering committee and update the AI risk register.
How the Process Works
1. Trigger and scoping. The PIR is triggered once the incident response process has moved to recovery or closure. The scope defines which systems, models, datasets, decisions, and time period are in view. Severity classification (often aligned to the AI risk tiering used in the governance program) determines the depth and formality of the review.
2. Timeline reconstruction. The team builds a factual chronology: when the issue first began (not just when detected), when it was detected, how it was detected (monitoring alert, user complaint, auditor, media), escalation steps, containment actions, and resolution. For AI systems, the timeline should include model version deployed, data pipeline changes, retraining events, configuration or prompt changes, and third-party model updates. Metrics such as mean time to detect (MTTD) and mean time to respond (MTTR) are captured.
3. Root cause analysis (RCA). Techniques such as the 5 Whys, fishbone (Ishikawa) diagrams, fault tree analysis, or causal factor charting are used to move beyond the proximate cause to systemic causes. AI-specific root-cause categories include: data quality or data poisoning, training-serving skew, concept or data drift, inadequate validation or testing, insufficient guardrails, weak access controls on models or pipelines, over-reliance on vendor assurances, missing human oversight, unclear accountability, and gaps in change management or MLOps controls. The review should distinguish between the technical cause, the process cause, and the governance cause.
4. Impact assessment. Document actual and potential impacts: affected individuals or groups (with attention to disproportionate impact on protected groups), business impact, financial loss, regulatory exposure, privacy breaches, reputational harm, and safety consequences. Determine whether notification obligations were met (for example under data protection law or emerging AI regulations such as the EU AI Act serious-incident reporting requirements).
5. Response evaluation. Assess what worked and what did not: Were playbooks adequate for an AI incident? Could the model be rolled back or disabled quickly (kill switch)? Was there a known-good prior version? Were communications to stakeholders, regulators, and users timely and accurate? Did logging and monitoring provide enough evidence?
6. Lessons learned and recommendations. Translate findings into specific improvements: control enhancements, monitoring thresholds, model validation requirements, data governance changes, updated acceptable-use policies, training, vendor contract clauses, or architecture changes. Each action has an owner, priority, due date, and success measure.
7. Reporting and knowledge sharing. The PIR report is distributed to appropriate audiences with sensitivity in mind. Sanitized lessons are shared across teams and, where appropriate, with industry bodies (for example AI incident databases or ISACs). Results feed the AI risk register, the control library, the AI inventory, risk appetite discussions, and board or governance committee reporting.
8. Follow-up and verification. Governance requires that actions are tracked to closure and their effectiveness verified, often through a later audit or test. Recurring themes across multiple PIRs indicate program-level weaknesses and should drive maturity improvements.
Integration with the AI Governance Program
Post-incident review is the feedback loop of the AI lifecycle. It links to:
• Risk management – updates likelihood and impact ratings, reveals unidentified risks, and tests the validity of prior risk assessments.
• Policies and standards – incidents often expose gaps between documented requirements and actual practice.
• Monitoring and metrics – lessons define new key risk indicators (KRIs) and alert thresholds for drift, output anomalies, or misuse.
• Third-party management – findings may require changes to vendor due diligence, SLAs, and incident notification clauses for foundation model providers.
• Training and awareness – real incidents become case studies that build organizational competence.
• Continuous improvement – aligns with frameworks such as NIST AI RMF (Govern, Map, Measure, Manage), ISO/IEC 42001 (AI management system with continual improvement), ISO/IEC 27035 (incident management), and COBIT's monitor, evaluate and assess practices.
Common Pitfalls
• Treating the PIR as a blame exercise, which suppresses reporting.
• Stopping at the proximate technical cause (\"the model drifted\") without asking why monitoring did not catch it or why there was no retraining governance.
• Failing to involve business owners and affected-stakeholder perspectives.
• Producing recommendations without owners or deadlines.
• Not revisiting whether corrective actions actually worked.
• Ignoring near-misses, which are rich sources of lessons at low cost.
• Failing to update the AI risk register and governance documentation.
Exam Tips: Answering Questions on Post-Incident Review and Lessons Learned for AI Systems
Tip 1 – Think like a governance leader, not a technician. The AAISM exam is a management-level certification. When asked for the BEST or MOST important action after an AI incident, prefer answers about structured review, root cause analysis, updating the risk register, reporting to the governance body, and improving the program over answers that are purely technical fixes (such as \"retrain the model\" or \"patch the API\"). Technical remediation happens during incident response; the PIR is about learning and systemic improvement.
Tip 2 – Know the sequence. Questions often test order of operations: contain and recover first, then conduct the post-incident review once the incident is resolved. Within the review, root cause analysis precedes recommendations, and recommendations precede policy or control updates. If an answer skips to changing policy before understanding root cause, it is usually wrong.
Tip 3 – \"Blameless\" is a signal word. If an option emphasizes identifying who made the mistake or disciplinary action, it is almost always a distractor. Correct answers emphasize systemic causes, process failures, and a culture that encourages reporting.
Tip 4 – Distinguish root cause from symptom. Expect scenarios where a model produced biased outcomes or hallucinations. The exam wants you to look past the immediate symptom to governance causes such as inadequate validation testing, lack of representative training data, missing human oversight, absent monitoring thresholds, or poor change management. The BEST answer usually addresses the deeper cause.
Tip 5 – Look for the feedback loop. The primary objective of lessons learned is continuous improvement of the AI governance program. Correct answers typically mention updating the AI risk register, revising controls or policies, adjusting monitoring and KRIs, and feeding results into training and future risk assessments.
Tip 6 – Remember AI-specific incident types. The exam may define incidents broadly: model drift, data poisoning, prompt injection, adversarial examples, model inversion or extraction, biased or discriminatory outputs, unsafe automated decisions, and third-party model failures. Do not assume \"incident\" means only a confidentiality breach.
Tip 7 – Stakeholder involvement and reporting. When asked who should be involved or who receives the report, favor multidisciplinary participation (data science, security, legal, privacy, business owners, risk) and escalation to the AI governance committee or senior management. Regulatory reporting obligations and communication to affected individuals are governance responsibilities that may appear in scenarios.
Tip 8 – Watch for metrics questions. Be ready to identify MTTD, MTTR, recurrence rate of similar incidents, percentage of corrective actions closed on time, and number of near-misses reported as indicators of incident management maturity. Improvement in these metrics over time demonstrates that lessons learned are effective.
Tip 9 – Verification matters. If an option mentions tracking corrective actions to closure and validating their effectiveness (for example through follow-up audit or testing), it reflects mature governance and is frequently the best answer compared to simply \"documenting\" the lessons.
Tip 10 – Eliminate extremes. Options that suggest permanently shutting down all AI use, ignoring minor incidents, or relying solely on the vendor's explanation are usually distractors. The exam favors proportionate, risk-based, documented, and accountable responses.
Sample Question Walkthrough
An organization's AI-based credit decisioning model was found to have systematically disadvantaged a protected group for several months before a customer complaint triggered investigation. The issue has now been corrected. What should the AI security manager do FIRST as part of the post-incident review?
A. Discipline the data science team for inadequate testing.
B. Conduct a root cause analysis to determine why bias was introduced and why monitoring failed to detect it.
C. Immediately rewrite the AI ethics policy.
D. Replace the model with a rules-based system.
Correct answer: B. The review must establish root causes (both technical and governance-related) before policies are changed or technology decisions are made. A is blame-oriented, C is premature, and D is a technical decision that ignores the learning process.
Summary
Post-incident review and lessons learned turn AI failures into governance improvements. The process is structured, blameless, evidence-based, and multidisciplinary; it moves from timeline reconstruction through root cause analysis, impact and response evaluation, to owned corrective actions that are tracked, verified, and fed back into the AI risk register, controls, monitoring, training, and program maturity. On the AAISM exam, answer from the governance perspective: understand causes before acting, favor systemic and cultural improvements over blame or quick technical fixes, and always close the loop back to the AI governance program.
Test mode:
AAISM - Post-Incident Review and Lessons Learned for AI Systems Example Questions
Test your knowledge of Post-Incident Review and Lessons Learned for AI Systems
Question 1
An enterprise's fraud-detection model began approving fraudulent transactions. The team contained the incident and rolled back to a prior model version. The post-incident review then confirmed that mislabeled records had been inserted into a training data feed supplied by a third party. Which action should the information security manager PRIORITIZE as an outcome of the review?
Question 2
After a data leakage incident involving an LLM-based customer assistant was contained and service was restored, the post-incident review found that investigators could not reconstruct which user inputs triggered the disclosure or when it began. Which improvement should the information security manager prioritize based on this lesson learned?
Question 3
An LLM assistant that uses retrieval-augmented generation disclosed internal pricing after an indirect prompt injection was planted in an indexed document. The incident has been contained and the assistant restored. During the post-incident review, participants disagree about what the review should achieve. Which outcome BEST shows that the review met its PRIMARY objective?
Unlock Premium Access
Advanced in AI Security Management
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 3073 Superior-grade Advanced in AI Security Management practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- AAISM: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Post-Incident Review and Lessons Learned for AI Systems questions
20 questions (total)
Other AI Governance and Program Management concepts
Adding AI Requirements to Existing Security PoliciesAI Acceptable Use Policies and Generative AI GuidelinesAI Asset Decommissioning and Model RetirementAI Asset Inventory and Model RegistryAI Data Life Cycle From Collection to DisposalAI Governance Charter, Committee and RACIAI Incident Response Playbooks and EscalationAI Security Awareness Training ProgramsAI Security Incident Definition and ClassificationAI Security in the SDLC and MLOps PipelinesAI Security Metrics, KPIs and KRIsAI Security Program Maturity AssessmentAI Security Program Roadmap, Resources and BudgetAI Security Stakeholders and Their ExpectationsAI Security Strategy Aligned to Business ObjectivesAI-Specific Security Policy DevelopmentAI Standards, Procedures and Guidelines HierarchyBoard and Executive Reporting on AI SecurityBuilding the AI Security ProgramBusiness Continuity Planning for AI-Dependent ProcessesClassification of AI Systems and Their DataContainment, Eradication and Recovery for AI IncidentsData Ownership, Stewardship and Custodianship for AIData Protection Law and AI ProcessingDetecting and Triaging AI Security IncidentsDisaster Recovery for Models, Data and PipelinesInvestigating and Documenting AI Security IncidentsIP and Licensing of Models and DatasetsISO/IEC 42001 AI Management SystemsManaging Embedded AI Features in Enterprise SoftwareNIST AI Risk Management Framework for Security ManagersOWASP Top 10 for LLM Applications and MITRE ATLASPolicy Exceptions and Risk Acceptance for AI UsePolicy Review Cycles for a Fast-Moving AI LandscapeRegulatory and Contractual Incident Reporting for AIReporting AI Security Program PerformanceResponsible AI Principles and Ethical Use MandatesRetention and Secure Disposal of AI Data and ModelsRisk-Tiered AI Regulation and Prohibited UsesRoles and Responsibilities in AI Security PoliciesSector and Contractual Requirements for AI SecuritySelecting and Implementing AI Security ToolsShadow AI Discovery and Policy EnforcementThird-Party Assurance Reporting for AI SecurityTraining Data Provenance and Lineage RecordsUsing AI to Improve Security Operations