Creative privacy is not a single checkbox. A manuscript can be exposed through upload, analytics, diagnostics, backups, collaboration links, support attachments, model-training terms, or retained generated assets. The safest workflow begins by understanding exactly where the material travels and why.
1. Map local and cloud processing
Ask which operations occur on your device and which require a server. A product that says it is private may still upload text for generation, telemetry, crash reporting, abuse prevention, or synchronization. The boundary should be visible before use, not buried in a general policy.
- Does the full manuscript leave the device, or only selected passages?
- Are generated voices or audio stored locally, remotely, or both?
- Can cloud features be disabled without breaking core workflows?
- Does the application work without an account for local projects?
- Are diagnostic logs scrubbed of manuscript text and file names?
2. Read the data-use language precisely
Look for statements about training, improvement, service providers, human review, retention, and de-identified data. The phrase 'we do not sell your data' does not answer whether content is retained or used to improve models. Prefer explicit terms stating that customer manuscripts are not used to train unrelated systems.
3. Understand retention and deletion
- How long are uploads retained after processing?
- Do backups preserve deleted material, and for how long?
- Can you delete individual projects, generated audio, and custom voices separately?
- Does account deletion remove content from active systems and queued processing?
- Can you export a complete project before deletion?
4. Protect voice rights as carefully as manuscript rights
A voice reference may involve performer consent, contract scope, territory, duration, derivative use, and revocation. Do not assume that owning a recording gives unrestricted permission to create a synthetic voice. Keep provenance attached to the voice: source file, participant, authorization basis, intended project, creation date, and deletion status.
- Use your own voice or a voice you are explicitly authorized to use.
- Do not imitate a recognizable person without permission.
- Avoid using public video merely because it is technically accessible.
- Preserve consent records with the generated voice profile.
- Separate experimental references from approved production voices.
5. Reduce unnecessary exposure
Use scene-level excerpts when a full manuscript is not required. Remove comments, revision history, personal addresses, embedded contracts, and production notes from exports. Create a dedicated project copy rather than uploading the master writing file.
Export scenes 12 through 18 to a clean FDX or Fountain file for a table-read test. Keep the complete draft, research binder, notes, and prior revisions inside the original writing environment.
6. Secure the local project too
- Use full-disk encryption and a strong device login.
- Keep operating systems and creative software current.
- Review cloud-backup settings for project folders.
- Avoid shared user accounts on production machines.
- Store sensitive exports in clearly controlled locations.
- Delete temporary audio and reference files after approval when no longer needed.
7. Document the workflow for teams
Studios, classrooms, and collaborative teams should define who may import material, create voices, approve cloud processing, export audio, and delete projects. A private tool used without shared rules can still create uncontrolled copies.