AI has long since found its way into cybersecurity. At the same time, the sober reality remains that the bottleneck rarely lies in a lack of AI, but rather in unclear architecture, processes that are not being followed, and a lack of risk transparency. AI makes anomalies visible more quickly, but it does not remedy a poor starting point.
In cybersecurity, AI is both an established tool and the subject of hype. What is particularly new is the widespread attention being paid to large language models, which significantly simplify documentation, scripting and integration tasks. Here in particular, the following applies: LLMs speed up workflows, but they do not replace governance or approval processes. Without safeguards, they actually increase the risk of misconfigurations and data leaks.
AI delivers its greatest added value, above all, when it learns typical behaviour patterns and derives anomalies from them. In SIEM and MDR environments, User and Entity Behaviour Analytics (UEBA) identifies anomalies in log data and network traffic that pure signature-based methods often fail to detect. In the field of email security in particular, generative and detection-focused AI solutions come into direct contact with one another. Policy optimisation is an increasingly relevant field: machine learning (ML) analyses real-world application communication and maps firewall rules to specific applications. This accelerates the implementation of a recertification process, as required, for example, by the DORA framework, and streamlines established rule sets to the essentials. AI can also provide excellent support with documentation. However, one thing remains crucial: AI can suggest rules and flag anomalies. Whether a rule is business-critical, who is responsible for it, and what level of residual risk is acceptable must be clarified at an organisational level.
Regulation and Trust
Regulatory requirements are increasingly shaping the conditions for the use of AI within organisations. They demand traceability, accountability and manageable risks – precisely the foundations that AI does not automatically provide.
EU AI Act: For the use of AI in critical infrastructure, for example, specially authorised AI systems are required. Training staff in the use of AI is also mandatory. For low-risk infrastructure, only limited transparency and information obligations apply. These include, amongst other things, the requirement to label AI-generated content as such. The provisions of the AI Regulation (EU) 2024/1689, known as the EU AI Act, will in principle apply directly from 2 August 2026.
GDPR: Where AI processes analyse user-related data, such as in User and Entity Behaviour Analytics (UEBA), the system is subject not only to the AI Act but also to the strict requirements laid down in the GDPR regarding purpose limitation, data minimisation, data processing on behalf of others, data location and potential access by regulatory authorities. Organisations must know where specific data is stored, who is processing it, and which jurisdictions might have access to it in the event of an incident.
Beyond compliance
Apart from the regulations, there are other aspects that must be taken into account. A freely accessible, free AI may, under certain circumstances, be trained using the data entered. This becomes a problem if, for example, intellectual property, such as a programme, is to be optimised using AI. The AI is trained using the code, and the AI system could pass on parts of it to others. Personal data queries are equally problematic. If, for example, an AI is used in a support portal and provides incorrect instructions, this can lead to liability.
Critical assessment
For these reasons, it is strongly recommended to consider an AI provider’s offering with an appropriate licensing model, so that intellectual property does not find its way into the training data.
A healthy dose of scepticism helps to scrutinise the marketing promises made by cloud AI providers. So-called ‘sovereignty washing’ – that is, marketing claims of GDPR compliance or ‘EU-only’ operation without robust evidence – should be scrutinised critically. It is equally important to be aware that AI responses depend on the context of their training data: depending on the origin and political environment, blind spots may arise. Cybersecurity must therefore operate according to the multi-source principle and cross-check manufacturers’ specifications.
In summary: anyone who has not yet regulated the use of AI within their organisation should assume that it is being used in an uncontrolled manner.
Conclusion: Create a robust architecture and clear processes
The near future belongs to AI-supported hygiene automation. Tools will increasingly issue recommendations and actively suggest configurations – from policy optimisation and rule refinement right through to configuration hardening based on learned patterns. From a regulatory perspective, it is becoming clear that ‘risk-by-design’ is becoming the standard. DORA, NIS2, the EU AI Act and the GDPR enshrine governance, traceability and data ethics as non-negotiable foundations. After all, if AI is used ‘incorrectly’, in the worst-case scenario, trade secrets may be learnt by the AI or user-related customer data processed without a legal basis. The conclusion: design and process maturity are the prerequisites for AI to act as a protective shield. AI is the accelerator – the foundation remains a sound architecture, clear processes and accountability in practice.
Author: Eike Trapp, Senior Security Consultant at Axians [www.axians.com]
