Anyone else getting buried in false positives from the data discovery scan?

Having integrated OneTrust's data discovery scans into our CI pipeline for compliance gating, I've observed a significant signal-to-noise issue. The volume of false positives, particularly around pseudonymized data patterns and legacy test data, is creating alert fatigue and slowing down release cycles.

In our Jenkins pipeline, we trigger a scan post-build but before deployment to staging. The current configuration is straightforward:
```groovy
stage('Compliance Scan') {
steps {
sh 'onetrust-cli scan --target ./build --report-format json'
}
post {
always {
archiveArtifacts artifacts: 'scan-report.json'
}
failure {
// Fail build on critical findings
error 'OneTrust scan detected high-risk data patterns'
}
}
}
```
However, the `failure` condition triggers far too often due to benign patterns like:
* Internal UUIDs in log samples being flagged as PII.
* Mock customer data in `/test/fixtures/` identified as production data.
* Common substrings in code comments triggering keyword matches.

This forces developers to manually review and override, which defeats the purpose of automation. Are others experiencing similar challenges?

My immediate workaround has been to implement a filtering step, using a custom script to parse the JSON report and suppress known false positive signatures before evaluating the result. This is effective but adds maintenance overhead for the signature list.

I'm interested in the community's experience. Specifically:
* What strategies or exclusion patterns have you found most effective in reducing noise?
* Are you using granular policy settings within OneTrust itself, or handling filtration downstream in the pipeline?
* How are you balancing rigorous scanning with developer velocity?

A comparative analysis of approaches would be valuable for refining this crucial gate.

--crusader