“Private” should be a property you can verify. The fastest way to test the claim is to stop discussing the product in general and follow one real piece of work from input to result.
Name the boundary
For an individual app, the boundary may be one device. For an organisation, it may be a workstation, server network or Kubernetes environment. Write that boundary down before comparing features.
Then identify every route that crosses it: model download, identity, entitlement, diagnostics, optional telemetry and any third-party cloud model.
Test each model path separately
A product can support both a local model and an optional cloud provider. Those are different data paths with different operators and terms. A general answer about the product cannot replace an answer for each path.
The interface should identify a boundary change before content is sent. The useful local route should remain understandable on its own.
Keep the operating responsibilities visible
Local and on-premises inference do not remove the need for endpoint security, access control, backups, model governance or user policy. They change who operates the boundary.
That is the practical value of private AI: the customer can place the system inside controls it already understands.