Performance in scanning

Your instinct is right, define and publish the policy before you scan.

Policy only evaluates each file only against the SITs referenced in auto-labeling conditions of labels published to the scanner's service account. All regresses every file against the full SIT catalogue, so cost scales with the number of patterns rather than the number of files. That's why you got a 3-day run and a saturated server for no additional signal. All gives you more hits, not more decisions.

Your numbers show it clearly: 572,895 files with matched info types but Labeled: 0. With Enforce off that's expected, but it means you now have a 573k-row haystack with no needle definition. The 96% falling into a single label also suggests the published label already has a very broad condition, worth checking, because Policy only is only as good as the policy behind it.

Suggested order: build your CUI SITs (regex/keyword, note EDM isn't supported by the on-prem scanner), create a CUI label with those as auto-labeling conditions, publish it to the scanner account only, then set the job to Policy only / Enforce Off / Manual and test on a small repo first.

One gotcha: switching to Policy only fails with "policy doesn't include any automatic labeling condition" if no such label is published to the scanner account yet.

For the server itself: drop ReportLevel from Debug, exclude the scanner temp path from AV real-time scanning, keep SQL off the scanner box, and consider splitting that repository across multiple content scan jobs or nodes.

Also worth pulling the CSV detail reports for those 41,318 failures, that's 1.2% of files never assessed, which matters more for CUI than the extra SIT hits do.