The first question security buyers ask about an AI-run SOC is usually not about detection quality. It is "where does my data go?" That is the right question. A platform that investigates alerts with a language model necessarily sends some security data to that model. The useful answer is a specific one: what gets sent, to whom, under what terms, and what your alternatives are. Here is ours.
Most data never reaches a model
Start with volume. Raw telemetry streams into SiemCore, the detection engine, which compares every event against the tenant's baseline. Around 99% of events match established normal and are eliminated there, by the engine, without becoming AI work. The language model is used for the parts that need reasoning: triaging what remains, investigating it, talking to the customer about it, and writing it up.
That ordering matters for privacy as much as for cost. The model sees the slice of data relevant to a specific investigation, not a copy of your log pipeline.
What context is sent
When the AI investigates, the model receives the context an analyst would need to reach a verdict:
- Alert details: the detection, the entities involved, timestamps, and severity.
- Log excerpts: the specific events relevant to the alert, not entire log streams.
- Investigation context: enrichment results, summaries of entity history from the tenant's baseline, and related events found during correlation.
- Conversation content: when a customer asks a question in chat, the question and the incident data needed to answer it.
That context can include personal information such as usernames, email addresses, IP addresses, and hostnames, because security investigations are about who did what. It is processed on behalf of the customer, who controls it.
Why not send more?
Sending only what the investigation needs is a privacy principle, but it is also good engineering. Models reason better over focused, relevant context than over a dump of everything nearby. The same discipline that keeps data exposure small keeps verdicts sharp and their evidence chains readable. It also makes the data flow easier to describe to an auditor: the model receives what one investigation needs, for one tenant, at the moment it is needed.
Which providers, under what terms
In cloud deployments, the AI layer uses the model provider configured for that deployment. The providers we work with are Anthropic, OpenAI, Google Gemini, and OpenRouter. We use them under their commercial API terms, and we do not authorize any of them to use customer data to train their models.
One point deserves precision. Providers may retain inputs and outputs for a limited period to detect abuse and misuse of their services, under their own retention policies. That is standard for commercial model APIs, and it is a different thing from training. If your compliance team needs the details, ask us which providers are enabled for your organization and we will walk through them.
Provider API keys are stored encrypted, and the AI is used only for defensive security operations on behalf of our customers.
The questions to ask any AI SOC vendor: Which model providers process my data? Under what terms? Is it used for training? How long is it retained, and by whom? Is there a deployment where it never leaves my network? If any answer is vague, keep asking.
On-prem: the model runs where the data lives
For some organizations, any third-party processing is ruled out by regulation, contract, or internal policy. For them, mysoc.ai runs on-premises and the AI layer can use a locally hosted model. The investigation context described above is processed inside your environment, and security data never leaves your network.
The tradeoffs are real: a local model is infrastructure you size and run, and the most capable frontier models are offered as cloud APIs. We cover them in detail in AI for Regulated SOCs: Running the Model On-Prem.
Tenant isolation applies to the model too
In a multi-tenant platform, the model call is an isolation boundary like any other. Each investigation is scoped to a single tenant: the context assembled for tenant A's alert comes only from tenant A's data and baseline. Baselines are built per tenant, verdicts are reached per tenant, and customer chat answers from that customer's own incident data. Customer data is logically segregated, and access is restricted to authorized personnel for the purpose of operating the service.
And because providers are not authorized to train on customer data, one customer's alerts do not end up shaping the model that analyzes another customer's.
What comes back, and where it lives
The model's output is the investigation itself: the verdict, the written summary, the ATT&CK mapping, recommended actions, chat replies, and report text. Those outputs are stored with the rest of the tenant's data in mysoc.ai, under the same segregation and access controls, and retained according to the configuration and contract agreed with the customer. When a contract ends, customer data is deleted or returned as that agreement provides.
This matters for audits. When someone asks why an alert was closed six months ago, the answer is not locked inside a provider's logs. It is in the investigation record: the evidence that was gathered, the reasoning the AI recorded, and, for escalated incidents, the analyst who reviewed it.
A checklist for your compliance review
If you are taking an AI-run SOC through a procurement or compliance review, these are the items worth settling up front, with us or with any vendor:
- Deployment model: cloud, or on-prem with a local model.
- Model provider: which provider is configured for your deployment, and whether that provider is on your approved list.
- Training: written confirmation that customer data is not used to train models.
- Provider retention: the provider's abuse-monitoring retention terms, from the provider's own documentation.
- Personal data: which categories appear in investigation context, and the lawful basis your organization relies on.
- Paperwork: the DPA and the current sub-processor list.
None of this is unusual. It is the same diligence you would apply to any processor of security data. The difference with AI is only that the model provider is one more link in the chain, and it deserves the same scrutiny as the others.
The rest of the stack
Model data handling sits inside the platform's broader controls: encryption in transit and at rest, role-based access with least privilege, monitoring and audit logging, and ongoing vulnerability management. Our security page summarizes them. A Data Processing Agreement and the current sub-processor list are available on request.
Trust in an AI-run SOC should not rest on "we take privacy seriously." It should rest on a data flow you can draw on a whiteboard. The full details are in our privacy policy; ask us for the DPA when you are ready to go deeper.
See mysoc.ai in action
One AI-run platform for your entire SOC—triage, investigation, customer communication, and reporting.