AI for cybersecurity
A security team’s problem is not a shortage of alerts: it is that there are so many the important ones get lost. Automated triage helps with that, and only if its false-negative rate is measured before you let it filter anything.
Key takeaways
The metric that decides everything here is the false negative: how many real alerts the system would have discarded. Measured over historical incidents before it filters anything.
A triage layer that cuts noise by 80% and swallows a real incident did harm, not saving. Which is why the order is measure first, automate second.
Where it pays without argument is in summarising and correlating: pulling signals from several sources into a readable narrative so the analyst decides faster, without taking the decision away.
We do not replace a security operations centre and we do not sell it that way. We take away the reading and sorting, which is where the shift goes.
Where a security team loses time
None of these is solved by more detection. All five are about volume and context.
- The consequence is not fatigue: it is that the important ones get lost among the ones that are not.
- When most of what fires is nothing, the team starts dismissing by default, and that is when the serious thing happens.
- The full incident is only visible by assembling pieces from three different consoles, by hand.
- The time goes into building the narrative from logs, not into deciding what to do.
- And the night shift does not have it.
Measure the false negative before automating anything
A triage system that cuts noise is easy to build and easy to sell: a dashboard shows 80% fewer alerts and everyone is happy. The question almost nobody asks is what went out with that 80%. If a real incident was among the discarded, the system did not save work: it created a breach with evidence that somebody approved it.
So the order is not negotiable. Take the organisation’s real historical incidents — the ones that did turn out to be something — and run the triage over them as if they were new. A number comes out: how many it would have discarded. That number gets handed over before the system is connected to anything, and if it is not zero you discuss what gets automated and what keeps human review.
And the separation between assisting and acting. Summarising, correlating and prioritising carry no risk: the analyst still sees everything and decides faster. Filtering and responding do, because they remove information or execute changes. We always start with the first, measure, and only then discuss the second with explicit limits.
The numbers before letting it filter
| What is measured | What it means | Why it governs |
|---|---|---|
| False negatives over history | Of the real incidents the organisation had, how many the system would have discarded. | It is the metric that decides whether to automate. Any other figure without this one is marketing. |
| False-positive reduction | How much noise it removes, measured only after the false-negative rate is acceptable. | It is the benefit, but it is the second number, never the first. |
| Summary accuracy | On a sample reviewed by the team: whether what the system says about the incident is in the logs. | A summary that invents a detail sends the investigation in the wrong direction. |
| Time to decision | How long the analyst takes to decide what to do, with and without the system. | That is the real saving. "Alerts processed" only rises with volume and says nothing. |
We are not a security vendor and not a security operations centre. We do not monitor your network, we do not do incident response and we do not replace the tools you already have. If that is what you need, there are specialist firms and that is the right path.
What we do is the engineering layer over what those tools already produce: correlate, summarise, prioritise and measure whether that filter is swallowing anything. And we do not automate any response — blocks, isolations — without explicit limits approved by whoever owns security.
Related services
Integrations and APIs
MCP servers against the systems already in operation.
View serviceAI automation
Applied where there is volume and stable rules, not where there is expectation.
View serviceAI consulting
Architecture, evaluation criteria and cost per query before writing code.
View serviceSoftware development
The system around the model, not just the model.
View serviceMore from the blog
Why does my AI chatbot answer wrong?
The model gets blamed almost every time, and it is almost never the model.
Keep readingHow to measure a RAG system
Most retrieval systems ship with no number attached to them.
Keep readingThe 15 best nearshore software development companies in Colombia
Colombia has been exporting engineering to the United States for twenty years, and the market is already segmented.
Keep readingFrequently asked questions
Does this replace our SOC or our tools?
No, and we do not sell it that way. We do not monitor your network, we do not do incident response, and we do not substitute the SIEM or EDR you already run. We work over what those tools produce: correlating signals across them, summarising the incident into a readable narrative and prioritising, so the analyst spends the shift deciding rather than reading and sorting.
How do you know the filter does not swallow a real alert?
It gets measured over the organisation’s historical incidents before anything is connected. We take the cases that did turn out to be something, run triage as if they were new, and count how many it would have discarded. That number is handed over first, before any noise-reduction figure. If it is not zero, you discuss what gets automated and what keeps human review, and that conversation belongs to whoever owns security, not to us.
Can it respond to an incident automatically?
Technically yes, and we recommend not starting there. An automated response — blocking an account, isolating a machine — has an operational cost when it fires on a false positive, and the business pays that cost. We start by assisting: summarising, correlating and prioritising, which carry no risk. Response automation is discussed afterwards, with the false-negative rate measured and with explicit limits approved in writing.
What tools does it integrate with?
With the SIEM, the EDR and the log sources you already have, over API or an MCP server. We do not ask you to change tools: the proposal is the opposite, getting more out of what is already installed and paid for. If the organisation does not yet have a central log source, that is the first project and it is not this one.
Does our security data leave our infrastructure?
Not if you do not accept that, and in this domain it is almost never accepted. We deploy on Azure OpenAI or Amazon Bedrock inside your own subscription, so logs and alerts never leave your cloud. In any configuration we use enterprise plans where data sent through the API is not used for training, and we filter identifiers before inference where the case requires it.
How long does it take and how is it priced?
The measurement over historical incidents takes a week and can be contracted on its own, as a diagnostic. A correlation and summarisation system in production, four to eight weeks depending on how many sources have to be connected. It is quoted with fixed scope, price and date in a proposal 48 hours after the first call, and the diagnostic cost is credited if you go ahead with the project.
Book 15 minutes
Tell us what you are building, or what stopped working. You leave the call with a concrete answer: it can be fixed, it can be built, or it isn't worth it.