Privacy for studios and testers

You are the controller of what your testers record. Mulno is your processor for what its own servers receive. This page maps who does what and what to do before a real person plays your build, and links the documents behind it. The documents are all at /legal/.

1. Who is who

The software isn't the processing. The recorder, the uploader, Studio and mulno run on your and your testers' computers. Mulno processes personal data only where its own servers receive it. Its sub-processors are listed on Subprocessors, and a new one appears there with 30 days' notice before it processes anything.

2. What Mulno's servers hold

Whatever bucket a recording goes to, a remote playtest passes a little metadata through Mulno's broker: your campaign's settings and limits, invite codes as one-way hashes, a session's state (including whether the tester withdrew), a yes/no age answer, byte counts, an NDA acceptance (the version and a hash of the text, never a name), upload tickets as hashes, and capture-health numbers. Never held, in any mode: a tester's name, email address or birth date, or their IP address in readable form outside the traffic log. Separately, Mulno keeps its own traffic log for 90 days, as Thailand's Computer-Related Offences Act asks: the time, kind and result of each request and its source IP address, with no session, campaign or studio id, so it can't be joined to a recording. Kept for:

• 90 days after a campaign closes, expires or is stopped: codes, sessions, redemptions, tickets and NDA acceptances. A campaign with no end date never starts that clock, so set an expiry.
• 90 days for capture-health records. A year for the audit log. About an hour for the keyed, truncated IP hash used for rate limits.
• Deleted rows can stay in Cloudflare's database backups for up to 30 more days, which can't be turned off.

Per storage mode, including what a Private bucket, the lent key and Mulno Cloud add, read What we store and Retention. Your workspace's region decides where its own rows live, but the broker's records sit in one Asia-Pacific database whatever the region.

3. Before your first real tester

1. Write what testers agree to. Set the PlaytestConfig's Consent Text, and Min Age. Keep Min Age equal to the campaign's age gate (the game warns when they differ). 0 asks no age question, and the build asks for a birth year and never keeps it. For testers in Thailand set Min Age to 20.
2. Add an NDA if you need one, in your own words. A fresh config's NDA text is a marked placeholder, and a build that ships it logs a warning.
3. Keep a copy of the exact consent and NDA texts you ship. A session records only their version and a hash.
4. Leave the recording indicator on. A build with a Broker Url fails if it's turned off, because a tester must always see when they are recorded. Mic and webcam are off by default and a tester opts in on the consent screen.
5. Don't turn on Decline Records Events for testers in the EU or UK: recording after someone declines needs a legal basis you'd have to justify.
6. Publish a notice to your testers that says what is collected, why, who receives it, how long it's kept and how to complain. Mulno gives you a template with your beta (tester-privacy-notice, and tester-consent for the on-screen text). It is written for the GDPR, the UK GDPR and Thailand's PDPA.
7. Know your deletion path (next section) and set a Studio Contact so the end screen tells testers how to reach you.
8. Read the transcription notice. Transcribing sends the tester's mic track to OpenAI or ElevenLabs under your account. Below ElevenLabs' Enterprise plan, audio sent there is used to improve its models by default unless you opt out in your ElevenLabs account.

Schools and classes aren't offered: class workspaces are planned for a later release. A tester under your age gate gets an events-only session, with no picture or sound, unless the campaign says you collect parental consent yourself.

4. When a tester asks you to delete

The end screen shows the tester a session ID with a Copy button, and your Studio Contact if you set one. That ID is how a request finds a recording without knowing anyone's name.

• Your own bucket: delete the session's folder. If it's an R2 bucket with a lock rule, the delete waits until the rule's window (seven days by default) has passed. Also delete every copy your reviewers downloaded: Studio's cache on each PC, and any clips or exports.
• Mulno's records of the session: in Studio, open the campaign and use Delete Mulno's records of this session; it deletes them at once. A tester can also ask on Mulno's deletion page with their session ID, and the session then shows Tester asked for deletion in your campaign.
• Mulno Cloud: a tester's request on Mulno's deletion page hides the session at once and deletes it for good 30 days later, with its notes and what we indexed from it. Your workspace's owners get an e-mail, and the web app's campaign screen lists the request with the date and a Restore button. A session ID isn't a secret (a moment link carries it), so Mulno can't tell a tester's own request from anyone else's: restore the session only if you are sure the request wasn't the tester's, or the law lets you keep the recording. A tester's own request is an erasure request you must honour otherwise. While the request stands nobody can export the session, a plan change's hold doesn't delay its deletion, and after the 30 days it can't be restored. If the tester asks again after you restored it, Mulno doesn't hide the session again: your owners get one e-mail and the request is listed again with Delete now and Keep. To delete one yourself, an owner or admin uses Delete in the session's review: hidden at once and deleted for good 30 days later (restorable until then), or right away with no undo. Deleting a session from its campaign also deletes it at once.
• A Private bucket, when a tester asks on Mulno's deletion page: Mulno can't delete the recording, because it is in your bucket. We hide our index entry for the session now, delete it after 30 days and e-mail your workspace's owners; the web app lists the open request with a Restore action (until the 30 days end) and a Delete action, and the recording itself you delete from your bucket. With a lent key on, what we indexed from it is deleted at once when you ask through the product.
• Anything else we hold of a session: ask through the product; we act within 10 business days. Don't email us session IDs or other details of your testers: our mailbox isn't used for them.
• A withdrawal in the game ("Stop and delete my recording") deletes the recording on the tester's PC at once, and tells your campaign the tester withdrew. Anything already uploaded stays in your bucket until you delete it. Watch for sessions that never finish uploading: one may be a withdrawal.
• A code leaked? Use Kill this campaign: it stops new redemptions and any upload in progress at once, and deletes nothing. You can turn it back on for 90 days.

5. What a tester sees and can do

A tester sees your consent text (and your NDA) before anything records, with mic and webcam unticked. A small REC light is on screen whenever anything records. They can pause (F9), open the menu (F10) to finish or stop and delete their recording, and back out of any screen with Esc. Mulno's tester terms claim no rights over a recording, and its biometric statement says it builds no face or voice templates and does no emotion recognition. Testers can read what happens on the page for testers and Tester screens and hotkeys.

6. AI and privacy

A local mulno mcp doesn't pass through Mulno's servers: what an agent reads goes to your AI provider under your own account. Mulno's own statement on named providers, no training, retention and the admin switch for hosted features is the AI statement. Read-only is the default: Connect Claude over MCP.

7. The documents