Draw the project boundary
‘Offline’ and ‘cloud’ describe where work happens, not whether a project is safe or ethical. List the materials first: unreleased vocal takes, client dialogue, reference tracks, contact names, cue notes and exported masters do not carry the same sensitivity. A local editor can keep a file on a workstation, while a browser service may require an upload, account and stored project. The right question is not which model is private in the abstract; it is which material is allowed to cross which boundary for this job.
Make a two-column intake note: ‘may leave the studio’ and ‘must remain local.’ Put client-provided recordings, identifiable voice material and embargoed media in the second column unless the project owner has explicitly approved a transfer. This is workflow hygiene, not an assertion that every cloud service mishandles uploads. It makes a later decision reviewable.
Match capability to the boundary
Local work has real costs: disk space, backups, updates, compute time and somebody responsible for the machine. Cloud work may add collaboration, remote access or specialised processing, but it also creates a provider relationship. Audacity's desktop notice is a useful reminder that a desktop application and an associated online service can have separate privacy arrangements; reading only the app name is not enough.
MusicGen's published materials show another distinction worth checking: code, model weights and a hosted demo are different things, with different licences and deployment choices. A local model may avoid sending audio to a hosted generator, but it does not erase obligations about the source material, the model licence or a shared workstation. Treat ‘local’ as one controlled step, not a magical solution.
Build a mixed workflow deliberately
A practical split might keep original session audio and client notes in a local project folder, send only a non-sensitive text description to a cloud ideation tool, then bring a downloaded sketch back for human arrangement. Another team may approve cloud stem processing only after creating a duplicate and removing identifying filenames. Neither is universally correct. The decision should follow the project’s permission, sensitivity and delivery needs.
For each external step, record the service, account, material sent, date, purpose and resulting file. Save the applicable terms or privacy page as a reference, not as a substitute for permission. If a collaborator cannot reconstruct what crossed the boundary, the team cannot honestly explain its data path later.
Use a five-minute preflight
Before upload, ask: is this an original or third-party recording; who may approve the transfer; does the service need the audio or only a description; where will the output be stored; and what is the local backup? If the answer is uncertain, do the next creative step locally or pause for project direction. This keeps privacy decisions proportional instead of making them a late-stage emergency.
The exercise is deliberately not a security certification or a claim about vendor compliance. It is a documented choice about a particular file and purpose. Repeat it when a tool changes, a new collaborator joins, or a rough idea becomes a release candidate.
Continue in Tool decisions, or Meta open-sourced MusicGen with a licensed dataset and an NC licence.
Evidence & further reading
Go to the source.
Primary references checked 19 September 2026. Practical exercises are editorial guidance, not reported product tests.
- Desktop Privacy Policy ↗
Current desktop-app notice identifies the app's data practices and distinguishes it from Audio.com.
Audacity · Accessed 2026-09-19 - MusicGen Model Card ↗
Primary model documentation distinguishes model details and licence terms relevant to local deployment decisions.
Meta AI · Accessed 2026-09-19