Where does AI really help in cybersecurity?
The greatest value of AI appears where a security team must quickly understand many events: logins, network traffic, email, endpoint behaviour, administrator actions and permission changes. A model can group similar alerts, highlight unusual patterns, summarise incidents and suggest which events require immediate escalation.
- In a SOC, AI can support initial assessment, alert grouping and incident summaries; measure any improvement in speed and quality.
- In SIEM, the model helps correlate logs from Microsoft 365, firewalls, VPN, servers, applications and identity systems.
- In EDR and MDR, AI supports the assessment of processes, files, network connections and user behaviour on endpoints.
- In corporate email, models help detect phishing, supplier impersonation and unusual payment requests.
- In backup, anomaly analysis can identify file encryption, mass deletion or unusual account activity faster.
SOC, SIEM and EDR: anomaly detection and response automation
AI does not replace security tools. It works best as an analysis and prioritisation layer above an existing SOC, SIEM, EDR, MDR or XDR stack. It helps turn raw alerts into an incident hypothesis, but high-risk actions should have escalation thresholds, a decision owner and evidence records.
- An automated recommendation may suggest host isolation, password reset, mail-rule blocking or escalation to an administrator.
- Decisions that affect business continuity, management access, customers or personal data should be approved by a human.
- Every playbook should record data sources, model output, the decision, the performed action and the post-incident result.
SOC, SIEM and SOAR
Event correlation, response playbooks, alert handling and reports that give the model reliable context.
EDR Endpoint Detection and Response
Endpoint, process, file and user activity context needed for better alert classification.
AI and automation
Designing automations that support the security process without losing control over data.
When AI in security should not act automatically
The biggest mistake is launching a model as an invisible security operator. AI may prepare a recommendation, but it should not independently block critical accounts, delete data, change firewall rules or send customer communications when the process lacks risk thresholds, a decision owner, a fallback plan and execution evidence.
Incomplete logs
Missing logs and context increase the risk of incorrect conclusions. The model should expose gaps and an analyst should verify hypotheses.
No response owner
Host isolation, password reset, customer communication or incident notification need an approving person and an escalation path.
Sensitive data in prompts
Logs, tickets, addresses and configurations need rules for anonymisation, retention, access and processing environment selection.
AI risks: prompt leakage, data leakage and the AI Act
AI in cybersecurity may process logs, tickets, email addresses, customer data and incident descriptions. Before sharing this data, assess contracts, retention, access and the legal basis. AI Act, GDPR, NIS2 and DORA duties depend on the role, system use and organisational status. ISO 27001 is a separate, voluntary management standard rather than another law.
- System prompt leakage is disclosure of system instructions through model output. Putting passwords, API keys or other confidential data in those instructions risks exposing them. A “do not disclose” instruction is not access control.
- Prompt injection can hide instructions in an analysed email, log or document. Treat that material as data. Enforce tool and source permissions in the application independently of model output.
- AI Act obligations depend on intended purpose, the organisation’s role and the applicable classification. Using AI in a SOC does not automatically make it high-risk or fully compliant merely because a human supervises it.
AI Act audit
AI system inventory, risk classification, human oversight and compliance evidence.
Offline AI models
Processing prompts, logs and tickets in a controlled environment without sending data to public tools.
NIS2 audit
Connecting security automation with accountability, risk, incidents and board-level evidence.
Secure architecture: offline AI, RAG and data control
Start with a limited task and access only to required sources. RAG must enforce user permissions before retrieving documents; a local model still needs account, log, integration and update controls. Verify answers against sources because models can produce incorrect conclusions.
RAG knowledge bases
Structured knowledge for IT, SOC and helpdesk teams without mixing public documents with confidential material.
Offline AI models
A local model or separated environment for organisations that cannot move logs and tickets outside controlled processing.
MFA
Access control for AI tools, administration panels and knowledge sources used by the model.
Stages of AI deployment in security
Account protection, backups, detection and incident handling must operate independently of the AI project. Run the pilot on separated data and compare results with analyst assessment: time, accuracy, missed events and false alarms. Expand scope only after assessing and accepting the pilot results.
1. Data and ownership
Log sources, system owners, data quality, basic correlation rules, MFA, EDR and backup.
2. Controlled pilot
Limited-scope model testing, anonymisation, escalation thresholds, prompt policy and human-approved decisions.
3. Acceptance and expansion
Board reporting, incident-handling evidence, false-positive lessons and a plan to extend automation.
What should the board and IT team receive?
The board does not need a list of thousands of alerts. It needs clear information about exposed processes, incident impact, who made a decision and which controls reduce recurrence. The IT team needs playbooks, escalation rules, integration configuration, data-quality criteria and instructions for handling exceptions.
- Pilot results: analysis time, accuracy, missed events, false alerts, sources used and the accepted automation scope.
- A list of use cases that can be automated and use cases that require human approval.
- Rules for processing prompts, logs, tickets and customer data, including restrictions for public tools.
- An evidence plan for NIS2, DORA, ISO 27001 or the AI Act covering sources, decisions, outcomes and periodic reviews.
How Virtline approaches AI in security
We treat AI as part of the security process, not as a separate tool experiment. In practice this means reviewing data sources, access, retention, backup, MFA, EDR, SIEM, playbooks, accountability and compliance evidence. Virtline connects this work with cybersecurity, IT outsourcing and offline AI/RAG implementations, so recommendations can become configuration, documentation and operations.
Evidence and compliance
In security projects, we assign responsibility for the model, data sources, exceptions and review schedule, and record the verification results.
AI Act and human oversight
We help distinguish an analyst assistant from a system that affects a decision, risk classification or automated response.
Technical implementation
After a successful pilot, we design integrations, retries after failures, event logging, monitoring and a way for staff to take over the process manually.
Related articles
AI in security should be read together with phishing, the security triad and backup topics. A model can speed up analysis, but it does not replace mature controls for confidentiality, integrity, availability and recovery after an incident.
Harm of spam
How spam and phishing provide signals that can be analysed in email, SIEM and anti-phishing tools.
The data security triad
How confidentiality, integrity and availability help assess the value of automation and the risk of AI decisions.
Creating backups
Why anomaly detection should be paired with proven post-incident data recovery.
