What alert data reveals
Security alerts are among the most sensitive data a company produces. They carry machine names, internal addresses, user names, command lines, file paths and, at times, fragments of documents or messages. Taken together, they map how a company is built and where it is weak.
An AI investigator reads all of this. It searches events, looks up accounts and follows process chains, and it passes what it finds to a language model to reason about. Where that model runs decides where your alert data goes.
The investigation records matter as much as the alerts. They hold the agent’s questions, the searches it ran and its conclusions about your weaknesses, and they deserve protection to the same standard.
Data residency and regulation
Many organisations are bound by rules on where data may be processed and who may see it. Banks, healthcare providers, public bodies and their suppliers often have contracts or regulators that limit transfers to outside services, especially across borders. Sending alert data to a hosted AI service can mean new data processing agreements, new risk assessments and new questions from auditors.
Running the AI inside your own environment keeps those questions simple. The data stays where it already is, under the controls you already have, and the list of parties that can see it does not grow.
Residency is not only a legal matter. Security teams are reasonably cautious about handing a map of their weaknesses to any third party, however trustworthy that party is.
Cost per investigation
Hosted AI services usually charge by the amount of text processed. An investigation that reads many records and asks many questions processes a lot of text, and alert volumes are high. Costs can be hard to predict, and they grow with each new alert.
On your own hardware the cost is mostly fixed: the hardware, its power and the people who look after it. Once that is in place, the running cost of each extra investigation is small. Our own estimate for armor360 is about $0.10 of compute per investigation. That is an estimate of running cost on suitable hardware, not a price.
The trade-off is up-front spend and the work of keeping the system running. At low alert volumes a hosted model may cost less overall. At steady, high volumes, or where data must stay inside, local hardware tends to make more sense.
When comparing, count the whole cost. On one side: hardware spread over its life, power, support and staff time. On the other: usage charges, data processing agreements and the review work they bring.
Hardware considerations
Language models need accelerators with enough memory to hold the model and the text it is working on. The right size depends on the model, how many investigations run at once and how quickly you need verdicts.
Plan for sustained load, not peaks alone. An investigator working through a queue overnight keeps the hardware busy for hours, and heat and power limits matter more than headline speed. Pacing the work so that the hardware is not run at its limit is a sensible default.
Test with your own alerts before buying at scale. Long investigations on busy machines need far more memory than short ones on quiet machines, and only your own data shows the mix.
- Memory: enough to hold the model and long investigations
- Throughput: how many investigations can run side by side
- Cooling and power: sustained load runs hot
- Resilience: what happens when a card fails or needs maintenance
- Placement: close to the SIEM and the data the agent queries
Choosing between hosted and on-premises
Neither choice is right for everyone. A hosted deployment asks less of your team: no hardware to buy, no models to update, no capacity to plan. An on-premises deployment asks more, and in return keeps the data, the model and the running cost under your control.
Start from your constraints, not from the technology. If contracts or regulators limit where alert data may go, the choice may already be made. If they do not, weigh the cost of hardware and the people to run it against the cost and risk of sending alert data outside.
Whichever you choose, ask the same questions of the supplier: where each piece runs, what leaves the environment, and how you would know if that changed.
- Where alert data is allowed to be processed
- Who may see it, suppliers included
- Expected alert volume, now and in a year
- Whether you have people to look after the hardware
- How quickly verdicts are needed
Keep the cloud fallback off
Some AI products send work to a hosted model when the local one is busy or fails. That is convenient, and it quietly undoes the reason you ran locally. If alert data must not leave your environment, any external fallback must be switched off, and the setting should be checked at every review.
With the fallback off, a busy local model means investigations wait in a queue rather than leaving the building. Size the hardware so the queue clears in good time, and decide in advance what happens if it falls behind: which alerts go first, and who is told.
Check the other outbound paths too. Threat intelligence lookups, telemetry, update checks and notification services all send data somewhere. Review each one and decide what it may send.
How armor360 runs inside your environment
armor360 runs on its own AI model, fine-tuned by our team. It can run fully inside your environment, the AI included, on your own hardware, so alert data need not leave it. External AI fallback can be switched off. If you would rather not run it yourself, we can host it for you.
Pricing is by quote, sized to what you protect, with no charge per person.