Security1 distinct publisher2 min readPublished
A SecurityWeek column puts the logs and alerts reaching a SIEM at 10 to 20 percent of what an environment generates, already stripped of context and timing. Layer a model on that pipe and it inherits the gaps rather than closing them.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
The loss happens upstream of where the model runs. Products filter and normalize before they forward, so the SIEM never holds the discarded fields and cannot be asked to hand them back. A detector reading that index is not working with a compressed copy of the environment. It is working with a curated one, and it has no record of what was curated out. Timing is the expensive part: a process-creation event that arrives without its timing relationship to adjacent events [2] cannot be sequenced against them, and sequence is most of the evidence in an intrusion.
Invert the column's ingest figure and the operative number is the complement. Between 80 and 90 percent of what the environment generated never reaches the analysis layer at all [10]. Now run the departing-employee case against that. The column describes four steps across four distinct systems [3]. Two of them raise anything a SIEM sees, the DLP alert on the download and the CASB flag on the upload [4], so half the chain is visible [11], and neither visible half carries the document's lineage or the user's six-month baseline [4]. Adding a model to that index buys faster inference over the same two fragments.
The premise underneath is that AI-assisted attacks now cross products, and stitching them requires multi-product data [14]. Same for the defensive baseline: one login at 1am is ambiguous, and it takes fifty logins over six months correlated with device telemetry to separate a travelling CFO from stolen credentials [5]. That is a retention requirement before it is a modelling requirement.
Two caveats, kept separate. First, this is a single opinion column at securityweek.com, and it states no methodology, sample or dataset behind the 10 to 20 percent [12]. Read it as a practitioner's estimate, not a measurement. Second, the remedy the column reaches is architectural: it argues that excluding source code, financial models and customer records from analysis is a choice rather than a technical limit, and that running AI inside the organisation's own environment lets that data in [8]. The compliance pressure it cites, GDPR, the US CLOUD Act, DORA and HIPAA [8], is real. The conclusion is also the shape of an on-premises product pitch. Both hold at once.
There is no CVE here and no deadline. What there is, is a ratio you can measure locally without asking a vendor: what a source generates against what your SIEM indexes and retains. The second figure is on your invoice. The distance between them is the ceiling on every detection model you buy, and nothing purchased at the analytics layer moves it.
Ranked by verification strength, evidence, and original report placement.
The column's example: a departing employee opens a competitive-analysis document, downloads it, uploads it to personal cloud storage, and emails a copy externally, a chain spanning four distinct systems.
In that example a traditional SIEM catches only isolated fragments, a DLP alert on the download and a CASB flag on the upload, and cannot reconstruct intent without the file's lineage: what the document contained, who else accessed it, and how the user's behaviour compared with a six-month baseline.
The column argues AI-powered security needs complete, full-fidelity data unfiltered from the source, including network, OT sensors, IoT devices, SaaS and cloud, plus human and non-human identity such as service accounts, API keys and tokens, and end-user files and content.
The column names GDPR, the US CLOUD Act, DORA and HIPAA as reasons cloud-dependent architectures cannot be trusted with sensitive data, calls the exclusion an architectural choice rather than a technical limit, and proposes running the AI inside the organisation's own environment under its own control.
The column asserts that modern AI-powered attacks span multiple domains and that detecting and stitching them together requires complete, multi-product data.
A single login at 1am is ambiguous, while fifty logins from the same account over six months, correlated with device telemetry and access patterns, indicate whether it is the CFO on international travel or an adversary using stolen credentials.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One unsourced opinion column
The entire cluster is a single securityweek.com opinion column. Its load-bearing quantitative claim (10-20% of telemetry reaching the SIEM, hence 80-90% lost) carries no methodology, sample, vendor set or dataset, and the insider-chain visibility ratio comes from an authored hypothetical rather than an incident. Claims about what the column argues are fully verifiable from the text; claims about the world are not corroborated by anything supplied.
No adoption signal supplied
The supplied material contains no release, deployment, benchmark, pricing, licensing or usage disclosure. No product, vendor, customer or in-environment AI security deployment is named, so there is nothing to measure about uptake of the completeness-and-sovereignty architecture the column proposes.
Quantified claim outrunning its evidence
The column converts an undocumented ratio into a general law of AI security ('the future of AI-driven security won't be defined by who has the most sophisticated models, but by who gives their AI the most complete data') and asserts that removing cloud dependency unlocks crown-jewel analysis, all without measurement, cost accounting or any deployment evidence. The direction of overstatement is the precision of the numbers and the sweep of the conclusion, not the underlying observation that pre-filtering causes blind spots, which is plausible but unquantified here.
Prescriptive thought-leadership framing
The piece is a bylined opinion column that builds from a restated prior thesis to a specific architectural recommendation - run the AI inside the organisation's own environment, with sovereignty over data, models and weights - a position that maps directly onto a commercial category. That prescriptive shape, plus the absence of any affiliation or interest disclosure in the supplied text, is an observable incentive to frame the problem as one only that architecture solves. No sponsorship, employer or funding fact is stated in the material, so this is scored on the article's argumentative structure alone rather than on a disclosed commercial tie.
Clear text, thin substrate
What the column says is unambiguous and easy to attribute, so claims about its argument are held with high confidence. Confidence in the world-facing claims is low because there is one publisher, one format and no corroboration or methodology, and adoption cannot be scored at all. The overall read - a plausible architectural argument carrying an unsourced headline number - is stable, but any single quantitative element could move with one additional source.
product
amber's 7mn-euro bet: the AI cost centre has moved upstream of the model1 distinct publisher
security
Encrypted, then readable: Korea's startup platform shipped the key inside the API1 distinct publisher
build
"The model does not retain training data" is a testable claim, and someone else runs the test1 distinct publisher
science
HIPAA Covers Less Than You Think, And "Anonymized" Is Not A Legal Shield1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026