AI in cyber security: a model that acts when it counts

When the model says no

In security there is an obstacle in the way: the model refuses the task.

Forensic analysis means putting real attack commands, real exploit payloads and real command-and-control artefacts in front of a model. Commercial guardrails cannot separate the incident responder from the intruder — so they block both. The same hits pentest reports, reverse engineering, phishing analysis and detection engineering.

We wrote this up in detail: when HuggingFace investigated a real incident, the commercial frontier model refused to help. The analysis only became possible once the team ran an open model on their own infrastructure.

Incident data at the worst possible moment

During an incident you are working with credentials, infrastructure maps, log extracts and customer data — at exactly the moment that data is most sensitive. That is the worst imaginable time to hand it to a provider whose business model rests on processing inputs.

This is where "no logs, no training, processed in the EU" stops being a compliance checkbox and becomes containment. There is no second body of data to be compromised while you are still cleaning up the first.

You cannot procure trust in the middle of an attack

The practical core: a tool you are neither allowed to use nor able to use at 3 a.m. is not a tool. Approval, contract and the model's actual behaviour have to be settled before the alarm goes off, not during it. Switching provider under time pressure, with an unreviewed DPA and unknown refusal behaviour, is not an option you still have open mid-incident.

What security teams actually use AI for

1. Incident response: structuring log extracts and timelines, classifying artefacts, drafting technical incident reports and regulatory notifications.
2. Malware and sample analysis: describing behaviour, explaining scripts and obfuscated code, extracting IOCs.
3. Detection engineering: drafting and documenting Sigma, YARA and KQL rules, explaining alert logic, reasoning through false-positive patterns.
4. Pentest and red team: writing up findings, structuring evidence, management summaries from technical notes.
5. Threat intelligence: condensing advisories, CVE notices and vendor bulletins down to what matters for your environment.
6. Policies and evidence: security policies, hardening baselines, awareness material, audit responses, NIS2 and supplier questionnaires.
7. Automation via the API: alert enrichment and pre-sorting as decision support directly in SIEM/SOAR — what gets suppressed or escalated stays your team’s call. Telemetry does not leave the building.

How PrivatAI meets the requirements

Open models instead of commercial guardrails: PrivatAI runs capable open models (including GPT-OSS-120B and GLM-5.2). That is the same class of model security teams fall back to when commercial providers block them.

No body of data: inputs and responses are processed and discarded — not logged, never used for training. Processing exclusively within the EU: the application in Germany (Hetzner), the AI processing in France (Scaleway); no US parent company, no CLOUD Act access. Contractually through the DPA under Art. 28 GDPR with documented technical and organisational measures; the sub-processor chain is public and therefore reviewable for your own supply-chain assessment.

Ready immediately: chat for the team, OpenAI-compatible API for SIEM/SOAR integration. Both today, not after a procurement project.

An open model can decline a request too, and no AI replaces the analyst. What it replaces is the hours between working something out and having it written up.

PrivatAI (privatai.com) — AI chat & API from Germany. No content logs, no training on your data, GDPR-compliant.

PrivatAI compared