Unpopular opinion: Sentinel's ML detections are a black box and create more work than they save

I've been implementing and managing Microsoft Sentinel for three enterprise clients over the past two years, and I've reached a conclusion that seems to run counter to the prevailing positive sentiment in most review forums: the platform's built-in machine learning (ML) and fusion detections, while conceptually powerful, often function as an operational liability rather than an asset. The core issue is not the underlying technology but the complete opacity of their logic, which transforms what should be a time-saving automation into a significant investigative burden.

My primary grievance stems from the investigative workflow. When a traditional, rule-based alert triggers—for instance, a scheduled query detecting a user account added to a privileged group—an analyst can trace the logic. They can examine the KQL query, understand the thresholds, and validate the data path. In contrast, an alert generated by "Anomalous SSH Login Detection" or "ML-Based Password Spray Detection" provides no such transparency. The alert description is generic, and there is no accessible documentation on what specific behavioral model was used, what the baseline was for *this particular* environment, or which data points weighted the decision. This forces the security analyst to essentially conduct a full investigation from scratch to validate the alert, defeating the purpose of an intelligent detection system.

Consider the following practical implications for vendor management and operational compliance:

* **Increased Mean Time to Respond (MTTR):** Analysts spend disproportionate time performing root cause analysis on ML alerts because they cannot trust the "why." They must manually reconstruct session logs, correlate unrelated events, and often find the alert was triggered by an approved, but unusual, administrative action.
* **Audit and Compliance Challenges:** In regulated industries, we must document detection logic for audit purposes. With rule-based alerts, we can present the KQL. For Microsoft's ML detections, we can only present a Microsoft documentation page describing the feature in broad strokes, which frequently fails to satisfy auditors seeking control validation.
* **Negotiation and Licensing Inefficiency:** A significant portion of Sentinel's cost is ingested log volume. ML detections, by their nature, require broad data collection. However, without clear efficacy metrics or tuning parameters, it is impossible to conduct a cost-benefit analysis. We are paying for data ingestion to feed a system whose output we then must spend additional human hours to decipher. The ROI becomes questionable.

I have attempted to mitigate this through Microsoft support and documentation. The guidance invariably suggests treating these detections as "enhancements" to a solid baseline of custom rules. Yet, this positioning conflicts with their marketing as core, intelligent differentiators. Furthermore, tuning options are virtually non-existent; we cannot adjust sensitivity, exclude certain entity groups from specific models, or feed back false positives to refine the algorithm for our tenant.

My question to this community is whether others have encountered this operational friction. For those who claim success with these features, what is your investigative workflow? Have you found undocumented methods to glean more context from these alerts, or have you simply accepted the black box nature and built custom incident playbooks that treat every ML alert as a full-blown investigation? I am particularly interested in perspectives from environments with mature SIEM processes, where the cost of alert validation is meticulously measured.