eBPF network policy enforcement vs CNI plugin rules: where do you draw the line?

We're re-evaluating our network policy stack on EKS. Currently running Cilium with eBPF dataplane, but a growing chunk of our policy is still expressed as Kubernetes NetworkPolicy objects that get compiled down to iptables fallback chains on older nodes. The split creates a real maintenance headache: engineers write K8s NP, ops debug eBPF maps, and neither side has a clean audit trail of "what actually blocks what." For teams that went all-in on eBPF-native policies (CiliumClusterwideNetworkPolicy, Tetragon, or custom XDP programs): - Did you fully decommission iptables-based enforcement, or run both in parallel? - How do you handle policy rollback when an eBPF program pins the wrong socket? - What's your audit story — eBPF tail-call maps don't exactly lend themselves to compliance screenshots. We're a ~40-engineering-team shop, mostly Go/Python services, running 3 EKS clusters (1.27+). Not looking for "what is eBPF" — looking for production war stories.