01
False negatives over history
Of the real incidents the organisation had, how many the system would have discarded.
Why it governs
It is the metric that decides whether to automate. Any other figure without this one is marketing.
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.
4–8 weeks to production · 1 week to measure against historical incidents · 3 actionable findings or the diagnostic is not billed
- Alert triage
- Correlation
- Incident summary
- False positives
- False negatives
- SIEM
- Human review
Built on
An engineering team that has already been on the other side.
Ninety seconds: who we are, how we work and what you get at the end.
The same sourced answer on every channel
WhatsApp, the website or email land in the same system: it understands the question, searches your documents, answers with a citation and hands over to a person when unsure.
Example: an odd alert comes in at 3 a.m. The system checks whether it is an incident and opens the ticket.
WhatsApp connected
Web connected
Email connected
01 Channels
02Understands
Reads the message
Detects the entityseverity = high
Picks the sourceSecurity_policies.pdf
Is this 3 a.m. login from another country an incident?
03Searches
94 of 100finds the right chunk
142 mstakes
Searches by meaning and by exact words, and filters by the tag before choosing.
04Answers with a source
Yes: no registered travel and MFA failed twice. Source: SIEM, alert 88410, against policy 5.2.
answers with a source · 91 of 100
05Hands over
- Not enough backing
- A person on the team is notified
- Full conversation attached
- Human answer logged
Swipe to follow the flow →
Where a security team loses time
01
More alerts than the team can look at
The consequence is not fatigue: it is that the important ones get lost among the ones that are not.
02
False-positive fatigue
When most of what fires is nothing, the team starts dismissing by default, and that is when the serious thing happens.
03
Signals spread across tools
The full incident is only visible by assembling pieces from three different consoles, by hand.
04
Reconstructing what happened takes hours
The time goes into building the narrative from logs, not into deciding what to do.
05
The knowledge lives in the most senior analyst’s head
And the night shift does not have it.
01
The right order
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.
How it is measured
The numbers before letting it filter
02
False-positive reduction
How much noise it removes, measured only after the false-negative rate is acceptable.
Why it governs
It is the benefit, but it is the second number, never the first.
03
Summary accuracy
On a sample reviewed by the team: whether what the system says about the incident is in the logs.
Why it governs
A summary that invents a detail sends the investigation in the wrong direction.
04
Time to decision
How long the analyst takes to decide what to do, with and without the system.
Why it governs
That is the real saving. "Alerts processed" only rises with volume and says nothing.
What we are not
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
Connecting the systems that do not talk today
MCP servers against the systems already in operation.
AI automation
If someone does it by copying and pasting, it can be automated
Applied where there is volume and stable rules, not where there is expectation.
AI consulting
AI consulting for enterprises
Architecture, evaluation criteria and cost per query before writing code.
Software development
Custom software development
The system around the model, not just the model.
Key takeaways
Four things before the call
- 01
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.
- 02
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.
- 03
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.
- 04
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.
This is where the data comes in
An AI system is worth what its sources are worth. These are the standard connectors; anything with an API or a database connects the same way, and what has no API is handled by file.
SAP
Enterprise ERP
Oracle
ERP and database
NetSuite
Cloud ERP
Salesforce
CRM and service
HubSpot
CRM and marketing
PostgreSQL
Database and pgvector
Microsoft SQL
Database
Snowflake
Data warehouse
BigQuery
Google data warehouse
Databricks
Data platform
Redshift
AWS data warehouse
Synapse
Azure data warehouse
Supabase
Managed Postgres
Workday
Payroll and HR
QuickBooks
Accounting
Sage
Accounting and ERP
Xero
Cloud accounting
Shopify
Catalogue and orders
WooCommerce
Catalogue and orders
Magento
Catalogue and orders
Stripe
Payments and subscriptions
Google Drive
Documents and folders
CSV y Excel
Flat files
Nothing in this category
A RAG system in production: three years, two million users
We built and operated the assistant for a loyalty platform serving more than two million active users across ten countries.
We built the full pipeline: document ingestion and normalization, chunking, embedding generation, vector store on Azure AI Search and Pinecone, and retrieval with grounded generation on LangChain.
We held it above 99% availability for three years.
RAG systems →Frequently asked questions
01 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.
02 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.
03 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.
04 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.
05 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.
06 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.
Fifteen minutes. A concrete answer.
It gets fixed, it gets built, or it is not worth it. And if the diagnostic does not reach three actionable findings, it is not charged.