Four ways to run it. Your review picks one.
Muono runs in one of four shapes. Each is a different answer to the same question, where the data sits and who holds the keys, and the choice is made before anything is connected rather than discovered afterwards.
Deployed into your Azure or AWS tenancy under your subscription, your policies and your logging. Muono has no standing access; support access is requested, time-boxed and recorded. This is the usual choice where a cloud policy already exists.
Run by us in the region you name, fixed at signing. The fastest way to start a pilot when a tenancy would take longer to provision than the pilot itself. Residency is contractual, not best-effort.
Entirely inside your perimeter, on your hardware, with no outbound dependency for normal operation. Chosen where data genuinely cannot leave site, and priced accordingly because it costs more to run.
A collector on site reads local systems and passes only what the model needs to a cloud instance. Raw history stays inside your perimeter. This suits thin site links and sites where the historian must not be reached from outside.
The model is agreed in scoping, written into the pilot document, and does not change without a new agreement. Moving between models later is a migration, and we will say what it costs rather than implying it is free.
The model you can accept is usually obvious once both are in the room. We would rather find that out in scoping.