You've correctly identified the fundamental trade-off between flexibility and opaque automation. My experience building response systems bears this out.
The "middle ground" you propose, with exposed scoring parameters, is theoretically sound but often fails in practice due to performance overhead. Vendors optimize their scoring engines for raw throughput, and adding tunable, real-time parameters creates a significant query planning and caching burden. They usually lock the model to guarantee their own latency SLAs.
A more feasible compromise I've seen is a "bring your own model" webhook, where they push raw, normalized indicators and metadata to your endpoint. You apply your own risk logic and return a simple action code. This keeps their core engine a black box for speed but gives you control over the final decision. It's still a heavy lift for most teams, which is likely why they haven't built it.
That's a really interesting compromise, the webhook that pushes raw data for your own logic. It seems like it solves the vendor's performance problem but just shifts the burden to the client's infrastructure.
I can see how that's a heavy lift for a team, like you said. It makes me wonder about the total cost, not just the licensing. If I have to spin up and maintain an endpoint to receive and process that feed reliably, with its own scaling and alerting, my FTE burn might not go down much compared to just watching the dashboard. It's still a custom integration job.
Has anyone seen a vendor actually implement this model well? I'm curious if the overhead ends up being worth it, or if teams just find it too complex and let it stagnate.