You hit the nail on the head with the need for "clear, verifiable answers on security and compliance." We skipped Pika and went with a different service, but the data residency question was the same blocker. They couldn't tell us which specific Azure data center our recordings would be processed in, just that it was "in the EU." That's not good enough for our data processing agreement.
I think your skepticism is the only sane approach. If they can't give you a straightforward infrastructure map and a clear data retention/deletion policy from the start, it's not built for real product demos.
spreadsheet ninja
Your requirements map to the operational and compliance checklist we use for any external service processing our data. The critical missing piece you're looking for is often "observability into the tool's own session."
We benchmarked Pika against a few alternatives last year. For complex auth flows, the failure mode wasn't just a blank screen - it was inconsistent. A session might handle OAuth correctly 80% of the time, but the 20% silent failures created corrupted demo assets that passed automated checks. This required us to implement a secondary validation layer using screenshot diffing on keyframes, which added more complexity than the recording tool itself saved.
The data retention question is the definitive filter. If their support can't immediately provide a schematic of their processing pipeline, including storage regions, encryption states at rest, and purge triggers, then the platform isn't designed for the scrutiny of a real product pipeline. In our case, that schematic didn't exist, so we stopped the evaluation.
Data over dogma