Why AI Should Not Independently Manage Telemetry- image 1

Why AI Should Not Independently Manage Telemetry

The article is also available at:
Ukrainian, Azerbaijani, Kazakh, Russian

At every profile conference on information security, the same thesis is heard: delegate routine data work to artificial intelligence, eliminate the human factor, and improve overall efficiency. When one of the security teams automated log filtering using an AI agent, the data volume instantly dropped by 40%, and costs were proportionally reduced. However, six months later, during the investigation of a real incident, it was discovered that the algorithm independently lowered the priority of DNS logs for some endpoints, leaving only 5% of the original volume and creating critical gaps in the forensic trail. This vividly demonstrates the destructive impact radius of an entire protection program: delegating telemetry management requires precision, where AI only recommends and humans approve.

Why AI Should Not Independently Manage Telemetry - image 1
FILTERING

Destruction or Preservation of Relevant Data

Automation tools excel in recognizing information noise, repetitive events, and redundant fields. Identifying candidates for storage volume reduction takes the model only minutes instead of weeks of manual auditing. However, the algorithm should not independently decide to exclude information from the workflow.

A “low-value” event remains insignificant only until it becomes the sole key to an investigation. If the algorithm makes unilateral decisions to discard telemetry, it creates blind spots that will only become apparent after an incident. At Cribl Company, they emphasize that artificial intelligence should only serve as an identifier of opportunities. A specialist must verify these suggestions, testing each planned deletion for threat detection logic compliance, and the change rollback mechanism must remain simple and predictable.

MAPPING

Changing Values Through New Data Schemes

Mapping raw telemetry to standards like OCSF is a routine task where machine learning systems demonstrate high efficiency, allowing new sources to be integrated within hours. However, the main risk here is developers’ false confidence in the infallibility of automation.

An incorrectly classified authentication event may never trigger brute-force attack detection. Externally, the schema may appear correct, but on a system level, its essence is distorted — for example, when the outgoing IP address attribute receives the proxy server value instead of the real source. As a result, the logic of all interconnected systems degrades. Therefore, algorithms should only suggest mapping options. Approval of the schema is a critical control stage, especially for those fields that directly feed the SIEM logic.

COMPLIANCE

Decisions on Data Masking and Preservation

The ability of models to find sensitive data where it is not expected (API keys in debug logs or confidential information outside of DLP rules’ attention) is extremely useful. But simple detection is not equivalent to data management policy and does not take regulatory context into account.

Excessive concealment deprives analysts of the necessary context for investigations, while insufficient concealment violates compliance and creates legal threats. Technologies do not understand the details of data processing agreements and are unaware of business exceptions agreed upon by the company’s legal department. These are not pattern search tasks, but decisions with legal consequences. Policy formation always remains the prerogative of specialists, and any changes in masking rules or retention terms undergo the same strict audit as modifications to critical infrastructure elements.

ROUTING

Changes in Pipelines and Work Environments

Some manufacturers promote the idea of full automation of data pipeline settings using textual queries. However, in engineering practice, it is not customary to deploy unverified code or change firewall configurations without review. Telemetry pipelines carry a similar level of corporate risk.

Machine algorithms are ideally suited for creating configuration drafts, writing regular expressions, and locating errors. However, the argument of “speed” does not justify automatic deployment in a production environment. A small routing change, which imperceptibly stops the sending of account logs to the security platform, will make the infrastructure vulnerable in practice. That’s why any generated configurations are tested by engineers, and the organization is obliged to record the chronology of architectural updates.

INVESTIGATION

Assessment of Incident Criticality and Conclusions

Machine learning technologies can compress hours of initial information collection into a few minutes, generate queries, and correlate evidence. And these capabilities are indeed worth using aggressively. But the risk assessment stage requires an understanding of the company’s institutional memory.

The algorithm does not understand that the array of “low-priority” alerts came from newly acquired company systems, which have not yet been officially announced. It cannot accurately distinguish whether the execution of PowerShell commands was part of last year’s Red Team exercises or if the attacked server belonged to a dismissed employee. This business context remains outside the data pipeline. The final determination of the criticality level of the incident is always the task of analysts: the work results of automated agents are only input data for decision-making.

The discussion about the appropriateness of using the latest technologies in cybersecurity data operations is no longer relevant — they have become an integral part of modern industry processes. The main question boils down to who will bear the responsibility for possible consequences. Teams that use intelligent assistants for parsing and accelerating triage win in speed. Those who allow algorithms to unobtrusively manage filtering and establish the truth in investigations will inevitably face a loss of control.

iIT Distribution Company as a distributor and expert partner in cybersecurity helps businesses build a reliable data management architecture. iITD specialists provide comprehensive project support from needs assessment to the implementation of solutions by world vendors (including Cribl). The distributor’s technical team offers thorough consultations, analyzes infrastructure, and becomes part of the partner’s team, individually working on each case to build a sustainable, manageable, and secure IT environment.

News

Current news on your topic

All news
All news