Privacy Policy

Version 7.2 · effective 2026-10-29 · in force

This Privacy Policy explains what personal data RunMyB processes, why, with whom it is shared, and the rights you have. It applies to the RunMyB platform and console, and to the records the platform keeps of visits to the products hosted on it (Section 4). The processing RunMyB performs on a customer's behalf is governed by the Data Processing Addendum; the console's cookies are described in the Cookie & Tracker Notice.

1. Who is the controller

RunMyB, Inc., a Delaware corporation ("RunMyB", "we"), operates the platform and is the data controller for the platform's own data about you: your account and login identity, your billing and credit-ledger records, your legal-acceptance records, and the platform's security and operational data — and for the records it keeps of visits to the platform and to the products hosted on it, whoever the visitor is, and the statistics counted from them (Section 4), and for the records that keep the e-mail it sends, and the messages it receives for the applications hosted on it, within its limits, and the record of the addresses confirmed for, or unsubscribed from, the applications hosted on it, whoever the recipient is, and the records of what became of each message it sends, and of the messages it refuses to send, whoever the recipient is, and the record of each time an application's own messages are switched off or back on, and the record of where Google user data is and of the requests sent for it (Section 2), and for the automated check it makes of each photo added to an application hosted on it, for content its rules prohibit or restrict, with the record of that check (Section 2.8).

Two processor relationships sit beside that controllership, and both are governed by the Data Processing Addendum:

for the personal data that your applications process about their end-users, and about the people shown in the photos you add to them (Section 2.8), you (or your own client) are the controller and RunMyB is your processor — including the messages an application has the platform send its end-users, written from the application's own templates, which the platform renders and sends, keeping no copy of them, the messages people write to an application through its contact form or send to its own address by e-mail, with the files kept from such an e-mail, which the platform keeps for the application's owner and deletes after 90 days (Section 2), and, where an application offers its end-users sign-in with a sign-in provider the platform offers for it (today Google or GitHub), the identity that provider returns for them, which the platform relays to the application in transit without keeping it (the Data Processing Addendum, Section 2);
for the team-workspace data a customer manages about its members, the customer is the controller and RunMyB is the customer's processor (Section 3).

Contact for anything in this Policy: privacy@runmyb.com.

2. What we process, why, and on what basis

Account and identity (your login identity, your principal) — to operate your account (contract). Your login identity — the address you sign in with, and the password you set, which the platform never reads — is held by the platform's identity provider, Amazon Cognito, a service of Amazon Web Services (Section 5.1). The identity provider also sends you its own messages about signing in to the console — an invitation with a temporary password, and any code it sends you for signing in or for a new password — from RunMyB <account@mail.runmyb.com>, through the platform's mail provider but not through the platform's own code; the platform receives the mail provider's reports on them (below).
Ventures, products, documents, and your own conversation turns — to provide the service you asked for (contract). The AI providers that process this content — including, for the build roles, the venture's knowledge pages, lessons and Document Library index as the build agents read them — are named in Section 5.1, or Section 5.1 states how OpenRouter chooses them; RunMyB does not permit any of them to use this content to train or improve its models on RunMyB's behalf (the Data Processing Addendum's Section 7, which also records the exception for the build roles that ended on 2026-10-18). This content includes the pictures the platform itself takes of a product's screens — its pages at computer and phone width, the screens its checks walk through, and the design variants it offers you — which may show what the product holds about its own users: the AI models that design, verify, review, repair and change the product receive them, and so does the console's assistant when you ask it about a build. Where a product's files hold photos, such as the photos you add to it (Section 2.8), a request that carries, or may carry, a picture of the product or an image from its files also carries a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data, and, where the request's model has no such route or the request cannot carry that instruction, the picture or image is left out (Section 5.1).
The activity narrator's journal — a running written account of a venture's work, composed by the platform for the venture's owner from the venture's own records, including bounded excerpts of the venture's conversations with the assistant (yours and other members' alike) — to provide the account that module exists for (contract; what leaves the platform for it, to whom, and what is kept are in Section 2.2).
The avatar's learned actions — the short descriptions of the actions the console's chat avatar was asked to act out in the account's conversations, the animations written for them, and who asked for and kept each one — to let the avatar act out what a conversation asks of it (contract; what leaves the platform for it, to whom, and what is kept are in Section 2.3).
Avatars members create — the description a member writes, in any language, of an avatar they want; the one-sentence restatement of it and the drawing an AI model makes from it; the drawings not yet used; and which of them the member uses — to draw the avatar the member asked for (contract; what is checked, what leaves the platform for it, to whom, what is kept and who sees it are in Section 2.4).
The field survey and the references you name — the public pages of the leading services of your product's type, and of any service you name, that the platform captures and studies before a plan, with their screenshots and the comparison it writes; and the references you name and the files you choose for them — to plan the product you asked for (contract) and, for personal data about other people that the public material studied happens to carry, RunMyB's own legitimate interest in studying publicly offered services (what is fetched, what is kept, who receives it and RunMyB's role are in Section 2.5).
Voice dictation and the voice assistant — your audio, as each feature's provider processes it, the transcripts, the copy of a voice session's audio the platform receives and discards on the OpenAI engine, and the assistant's voice the platform relays to your browser on the ElevenLabs engine — to provide the feature you started (contract; Sections 6 and 6.1).
The language you last used — one short language code for you in each account you belong to, with where and when it was seen — so that the platform's assistants answer you in your language, and the ideas the platform offers you suit your market (contract; Sections 2.6 and 2.7).
The time zone your browser reports — its name, such as Europe/Warsaw, which the console sends with each message you send in a conversation; the platform keeps it, if its time-zone database knows the name, with that message and, where the message leads to a product's plan, with the run that plans the product and in the plan, as the product's time zone unless you name another, which the plan states before you approve it; it reaches the AI models that write the plan and work on the product, and may reach the platform's assistant when it reads the plan for you and, with the run's records, the activity narrator's model; and, unlike your language, it is not remembered for you — so that the times of the product you ask for follow your own time zone (contract; Sections 2.2, 5.1 and 8).
Your idea interests and reactions — in the platform's Ideas stream, the ideas you are shown, your reactions to them and the ideas you launch, the areas you choose and the line about yourself you may add, and the ideas the platform writes for you from them — to rank the ideas you are offered and to write ideas for you (contract) and, for personal data about other people that the public material an idea is written from happens to carry, RunMyB's own legitimate interest in offering ideas grounded in publicly available information (what leaves the platform for them, to whom, what is kept and RunMyB's role are in Section 2.7).
Photos you add to your apps — the photos you add for one of your apps to show, the copies the platform prepares from them, the description of each — yours, or the platform's suggestion until you confirm or replace it — and your confirmation that you may use them — to show your photos in your app as you asked (contract); for the people the photos show, RunMyB processes them on your behalf under the Data Processing Addendum, and it keeps your confirmation as its evidence of what was confirmed (legitimate interest); and the automated check of each photo for content the platform's rules prohibit or restrict, with its record, which RunMyB makes as controller so as not to host such content (legitimate interest, and legal obligation where EU or Member State law requires RunMyB to act on what it finds; what is checked, what is removed, what leaves the platform, to whom, what is kept and RunMyB's role are in Section 2.8).
Billing and credit ledger — to charge you, keep credits, and meet accounting obligations (contract and legal obligation).
Usage-metering records — what paid features you used, when, and the derived charges (contract and legal obligation). The platform also combines what the ventures launched on it have cost, from these records, with how long the platform worked on them, from the ventures' own records of when they were created and when their plan and publication approvals were asked for and decided, into the ranges of cost and time shown on idea cards (Section 2.7): a range is shown only when at least five launches stand behind it, is rounded, and names no account or venture (legitimate interest — telling the people who use the platform what a launch has cost on it before they start one, a purpose compatible with the one these records are kept for).
Content-safety records — the record of each automated safety check the platform runs on what you ask it to build, import or draw, including the text it checked — to keep the platform's evidence of its safety decisions and to recognise repeated abuse (legitimate interest; Sections 8 and 9).
Publication records — the public address a product was published at, the state of its publication, the decision of the check on that address, and who requested, unpublished or released it or turned its demo notice on or off, and when, with the confirmation an owner gives when removing a demo notice — to serve the product at that address (contract), and to keep an address that once served one account from being claimed by another and as the platform's evidence of those changes (legitimate interest; Sections 8 and 9).
Connection records — for third-party services you connect: the provider, the label you gave the connection, your access tokens encrypted at rest, and the bindings that say which product or venture uses the connection (contract; the data flows themselves are described in Section 5.2).
The record of where Google user data is, and of the requests sent for it — for your account and for each conversation, venture or run into which content from your Google connections has entered, the record that it has, with the Google service it came from, how it entered and when it was first received; and, for each request the platform's model gateway composes for such a conversation, venture or run, a record of the request's time, the part of the platform and the role it served, the models it named, whether it was sent, moved to another model or refused, and the model and the provider that served it (Section 5.3) — to keep Google user data away from the models and the providers Section 5.3 excludes and to keep the platform's evidence that it did (legitimate interest: keeping that commitment and RunMyB's obligations under Google's Limited Use requirements; Section 8 states how long each is kept). Neither record holds the content itself.
Operational logs and events — to run, secure, and debug the platform (legitimate interest).
Notices by e-mail — if you are an administrator of an account, the platform e-mails you, at the address you sign in with (the platform's identifier for you), a notice when a card in the console waits for your decision, when one of the account's products is published, its go-live request is declined, its own messages to its users are switched off, its background jobs are paused by RunMyB, a file it stores is withheld because the platform's scan found malicious software in it, files it stores cannot be scanned, or someone writes to it through its contact form or by e-mail to its own address, when one of its runs finishes, fails or is stopped at a limit, when the account's credits run low or run out, and when the account nears or reaches its daily credit limit; and the administrators of every account receive RunMyB's notices about the service itself, such as a change of its sub-processors. The notice that someone wrote to a product that only one member of the account can see in the console goes to that member alone, whether or not they are an administrator. You can choose, in the console under Account → Notifications, whether the notices about the account reach you at once, in a daily summary or not at all — for all of them together, or for each kind: cards waiting for you, products going live (the notices that a product's own messages were switched off, that its background jobs were paused by RunMyB, or that files it stores cannot be scanned, among them), runs that did not finish, finished runs, spending and credits, and messages to your products; until you choose, the notice that a run finished comes in the daily summary and the others come at once. RunMyB's notices about the service itself, and the notice that a file a product stores was withheld, have no such setting, and that notice comes at once unless the law requires, or a public authority asks, RunMyB to delay it. A notice may name what it is about as the account's console names it — a card's title, for example — and such text goes only to that account's own administrators, or, for a notice about a product that only one member of the account can see, to that member; no notice carries the material attached to a card, the notice that a file was withheld describes the file by its kind, its size and when it was stored, never by its name, and the notice that someone wrote to a product carries nothing of what was written, nor the name or address the writer gave. A notice about the account carries a reply address of the platform's own, made for that notice and its recipient; the notice that someone wrote to a product, a daily summary that includes one, and RunMyB's notices about the service itself carry none. If you answer a notice that carries one by e-mail, from the address it went to and while you are a member of the account, the platform keeps the text of your answer — not its subject, nor any file attached to it — as a message to you in your Messages in the console (Section 3.1), and does nothing because of it: it decides nothing, and none of the platform's assistants is shown it. The platform receives and checks your answer as it does an e-mail to an application (below), and deletes the e-mail as it was received once it has kept that text or decided not to; an answer from another address, an automatic reply, an answer that arrives after the notice's record is deleted (Section 8) and one beyond the platform's limits are deleted, and nothing of them is kept. For each notice and each recipient the platform keeps a record of the kind of notice, the account it concerns, the recipient's address, the identifier of the event it reports — never that event's text — when the notice was due, whether it waits for the daily summary, and whether and when it was sent, skipped or failed. To tell an account's administrators — and, about a product that only one member of the account can see, that member — what happens in the account and on the service (contract; Section 8 states how long the record is kept).
Notification choices — each choice you make in the console under Account → Notifications about which notices you receive for an account: the kind of notice it concerns, or all of them, whether it reaches you at once, in the daily summary or not at all, your sign-in identity and when you made the choice; the latest choice that covers a kind — its own, or one made for all of them — is the setting in force, and the earlier ones are kept with it as the history of your choices. To send you the notices you chose (contract; Section 8 states how long they are kept).
E-mail delivery records — for each message the platform sends you, its own or one that an application hosted on it asks it to send you, and for each message its identity provider sends you through the platform's mail provider (Account and identity, above), the delivery events the mail provider reports — that it was sent, delivered, bounced, reported as spam or rejected — with your address; the platform's own record of the message and of what became of it, and its record of the messages to you that it refused to send, with the reason, which identify you only by a hash made with a secret key the platform holds; and, if a message to you bounces permanently or you report one as spam, your address on the platform's suppression list and on the mail provider's, so that no further e-mail is sent to it, the identity provider's messages included, until RunMyB removes it from them, which you can ask it to do — to run the platform's e-mail, protect its ability to deliver e-mail and honour your report (legitimate interest; Section 8 states how long each is kept). RunMyB keeps them for its own purposes, as an independent controller, also for the people an application hosted on the platform asks it to write to; who else sees what became of a message is stated in the next point.
What became of an e-mail, in the console — the console shows parts of those records, never a hash. You see, under Account → Notifications, the platform's notices to you about the account you are working in, and RunMyB's notices about the service itself, each with whether it was sent and what became of it, and the other e-mail the platform sent you for that account, such as an invitation or a notice about a data request. The members of an application's account who can see the application in the console see the messages the platform sent, or refused to send, for the application, each with what became of it — for example that it was delivered, bounced or reported as spam by the person it went to, or why it was not sent — but not the address it went to; an application that keeps its own record of the messages it asked for can match a time to one of them. Such a member may also type one address to see which of the application's messages went to that address and what became of each, including that the person reported one as spam, or that one was not sent because the person had unsubscribed from the application, or because the address is on the platform's suppression list or paused after repeated bounces, whichever application's message led to the suppression or the pause. The platform matches the address by its hash, shows it back only in part and keeps neither the address typed nor its hash, and each member can make only a limited number of such look-ups a day in an account, which the console states. RunMyB shows the application's owner these records so that the application's mail reaches its users and stops going to people who do not want it, the application having given the platform each address it wrote to (legitimate interest, RunMyB's and the owner's); and it keeps, for each member of an account and each day, a count of the look-ups the member made that day and the time of the last one, with their sign-in identity and never the address looked up, to hold them to that limit (legitimate interest; Section 8 states how long it is kept). The account's data export, which is an administrator's (Section 3.2), carries the platform's records of the e-mail it sent, or refused to send, to the sign-in addresses of the account's members — active, invited or disabled — for that account, among them the e-mail a preview of one of its applications sent the member who started it, without the hash; a member's own export carries the records of their own (Section 3.2). The records of an application's e-mail to its own users, of RunMyB's notices about the service itself, and of the identity provider's messages (Account and identity, above), which concern no one account, are part of no account's export, and no account's view in the console shows the records of the identity provider's messages: RunMyB gives a person the records about them on request (Section 9).
E-mail sending limits — when an application hosted on the platform asks the platform to send an address-verification or password-reset message, a count of how many such messages were sent to the recipient's address that day, from that application and from all applications together; when it asks the platform to send one of its own messages, a count of how many of its own messages were sent to the recipient's address that day; and, for any address the platform sends e-mail to, a record that the address is paused after repeated bounces that were not hard bounces. Each identifies the address only by a hash made with a secret key the platform holds, never by the address itself. For each application, the platform also keeps a record of each time the application's own messages are switched off or back on — switched off automatically, when the platform receives enough spam reports about them, or about the platform's requests to confirm an address sent in their place, or by RunMyB's administrators, and switched back on only by RunMyB's administrators — with the reason, the numbers of reports and of messages behind an automatic switch-off, who decided and when; it names no address. RunMyB keeps them for its own purposes, as an independent controller — also for the people an application hosted on the platform asks it to write to — to keep the platform's e-mail within its limits and to protect the people it writes to and its ability to deliver e-mail (legitimate interest; Section 8 states how long each is kept).
Confirmed and unsubscribed addresses — the address-verification and password-reset messages the platform sends for an application hosted on it carry, in place of the application's own link, the platform's link, on the application's own web address on runmyb.app, which then opens the application's link, and every message the platform sends on an application's behalf carries an unsubscribe. Mail the platform sends from an application's preview is the exception: it goes only to the address that the person who started that preview from the console signs in to the platform with, whether or not that address is confirmed for the application, without the platform's link and without an unsubscribe, and never to an address unsubscribed from the application. For each application and each address it writes to, the platform keeps a record of each time the address is confirmed for that application — when one of the platform's links, sent to that address in a message from that application, is opened while it is valid — of each time the address is unsubscribed from that application, and of each time an unsubscribe is undone. Each entry says which of these it is and how it arose — through the link in an address verification (the messages asking for the address to be confirmed that the platform sends in place of a password reset, or of one of the application's own messages, among them), through the link in a password reset, or through the unsubscribe — with, where a link gave rise to it, that link's identifier and when it was issued, and when the entry was made. An address to which one of the application's address-verification or password-reset messages, sent before those messages carried the platform's link, was delivered is recorded as confirmed, with the time of that message, as the platform's records of those messages' delivery show. The record identifies the address only by a hash made with a secret key the platform holds, never by the address itself; it keeps nothing about the browser or device that opened the link, and the platform stores nothing on it; the request itself appears in the load balancer's request logs, as any request does (Section 4). When a password reset or one of the application's own messages is replaced, or a message withheld, because of this record, the application's owner can see in the console how many were and why, and the time of each one the platform recorded, but not the address; an application that keeps its own record of the requests it made can match the time to one of them, and a member who types one address in the console sees which of them concerned that address (the point on what became of an e-mail, above). RunMyB keeps the record for its own purposes, as an independent controller — also for the people an application hosted on the platform asks it to write to — so that a password reset, and any of the application's own messages, goes only to an address confirmed for that application, an address not yet confirmed being sent one message of the platform's own asking for it to be confirmed instead, and so that the platform sends no message on an application's behalf to an address unsubscribed from it until that is undone, protecting the people it writes to and its ability to deliver e-mail (legitimate interest; Section 8 states how long it is kept).
Messages to the applications hosted on the platform — when someone writes to an application hosted on the platform through its contact form, the application's own server hands the platform the message, the address the person gave for a reply and, if they gave one, their name, and the platform keeps them, with when the message arrived, in the application's inbox in the console (an application the platform hosts with a server of its own may do this, and only one whose form does receives any). There they are shown, as plain text with any link shown as text, to the members of the application's account who can see the application — for an application that only one member of the account can see in the console, to that member alone — with the name and the reply address as the person gave them; they are also part of the account's data export, which is an administrator's (Section 3.2). The platform takes such a message from the application's server, not from the person, and does not check who wrote it or what it says: not for viruses, not for spam, and not whether the name and address are the person's own. It sends nothing to the address the person gave: any answer comes from the application's owner, from their own e-mail. No AI model, and none of the platform's assistants, reads a message, and the platform acts on nothing a message says. The account's administrators, or that one member, are e-mailed a notice that a message arrived, which carries nothing of it (the notices by e-mail, above). The members who can see the application can delete a message, and can switch the application's inbox off and on; while it is off, while the application's account is suspended or terminated, and beyond the platform's daily limits for the application and for each reply address, the platform takes no message from its form and keeps nothing of one it refuses, and it takes none from a preview of the application, where a message written stays on the preview. The platform keeps a record of each time an application's inbox is switched off or on, who did it and when. An application the platform hosts with a server of its own may also have an e-mail address of its own on the platform, made from the application's address on runmyb.app — name@in.mail.runmyb.app for an application at name.runmyb.app — which the console shows the members who can see the application; e-mail sent to it reaches the application's inbox whether or not the application shows the address. The platform receives such e-mail through Amazon Web Services' mail service (Section 5.1), which scans it for viruses and spam; it holds an e-mail, as it was received, in the platform's private storage only until it has delivered it or counted it as not delivered, and it delivers it only if that scan found neither, if it is within the platform's size limit and if its sender's address passes the e-mail authentication of its own domain, or of a domain related to it — which shows that the e-mail came through a mail service that domain allows, not who wrote it, and leaves the sender's name unchecked — and, as for a message from the form, only while the inbox is on and the account is neither suspended nor terminated, and within the platform's daily limits, for the application and for each sender's address. Of an e-mail it delivers, the platform keeps in the application's inbox, with when it arrived, the sender's address and name as the e-mail gives them, its subject, its text — its plain text, or its formatted text turned into plain text with any link written out as text, cut at a set length — the list of the files attached to it, and which of those authentications its sender's address passed; of the files, it keeps only those of a few common kinds — PDF, PNG, JPEG, GIF, WebP and plain text — whose contents match the kind they state, and only a set number from one e-mail. The platform never opens or runs a kept file; the members who can see the application download it in the console, under a name the platform gives it from the kind it verified; it is deleted with its e-mail, and it is not part of the account's data export, so it can be had only by downloading it while it is kept. An e-mail is otherwise shown, noticed, exported and deleted as a message from the form is, above. An e-mail the platform does not deliver is deleted once the platform has counted it, by day and reason, for each application it was sent to — a count that names no sender, which the members who can see the application see in the console for the current day — and the platform sends its sender nothing, not even word that it was not delivered; an e-mail sent to no application on the platform is deleted, and nothing of it is kept. The messages are kept to deliver them to the application's owner, as the owner asked (contract with the owner); for the people who write them, the application's owner is the controller and RunMyB processes the messages on the owner's behalf under the Data Processing Addendum: if you wrote to an application hosted here and write to RunMyB about your message, RunMyB passes your request to the application's owner, who answers for it, unless the owner has instructed RunMyB otherwise or the law requires otherwise (Data Processing Addendum, Section 3(e)) — except for the count below, which is RunMyB's own and which RunMyB answers for; the application's own notice names its owner. RunMyB also keeps, for its own purposes as an independent controller, for each application and each reply address given to it, or each address that sends it e-mail, a count of how many messages that application handed the platform that day with that address, or of how many of that address's e-mails the platform delivered to it that day, identifying the address only by a hash made with a secret key the platform holds, never by the address itself — to keep the messages an application hands the platform, and the e-mail it receives, within the platform's daily limits (legitimate interest; Section 8 states how long each is kept).
Visit records and statistics — the platform's records of requests to the console and to its hosted products, and the cookieless first-party beacon's records of page views in hosted products, kept for up to 30 days for three purposes — statistics for each product's owner, the security and operation of the platform, and aggregate statistics about the platform and the products built on it — and counted into statistics that identify no visitor (legitimate interest; what the records contain, how long they are kept and RunMyB's controller role are stated in Section 4). The beacon stores nothing on your device and is the platform's own first-party audience measurement, so no tracking consent is sought for it (Section 4).
Correspondence — e-mail you send to the platform's contact addresses (legitimate interest, and contract or legal obligation where it concerns your account or a legal claim).
Pre-launch waitlist signups — your e-mail address and the version identifier of the consent wording you agreed to, collected when you join the waitlist on runmyb.com (consent; the full description, including what is deliberately not stored, is Section 2.1).

2.1 The pre-launch waitlist

Before the platform opens publicly, runmyb.com offers a waitlist form. If you join it, the record we keep is:

your e-mail address, normalized to lowercase — a repeat submission changes nothing and is never distinguishable from a first one;
the version identifier of the consent wording you agreed to, stored verbatim as the evidence of your consent (see below);
a short source token naming which page carried the form, the time of your signup, and — if and when we invite you — the time of the invitation and an internal identifier linking the record to the account the invitation created.

That is the whole record. We deliberately store no IP address, no browser or device information, no name, and no free text with a waitlist signup; the checkbox state itself is checked and then discarded, never stored.

Purpose. We use your address for one purpose: corresponding with you about access to the RunMyB beta. Because access is granted by hand, one person at a time, that correspondence includes the questions we need to ask before deciding — for example what you would build, who it is for, and how you would reach them. We do not promise to write, we do not promise access, and we make no statement about when, whether, or in what order invitations happen. We send no newsletter and no marketing mail to this address, we do not sell it, and it is not shared beyond the infrastructure on which the platform runs (Section 5.1).

Legal basis: consent (Article 6(1)(a) GDPR), given by ticking the unticked checkbox beside the form. The evidence of your consent is the stored version identifier together with the signup time; the exact wording each identifier refers to is preserved in this section, so what you agreed to remains recoverable for as long as the record exists. You may withdraw consent at any time by writing to privacy@runmyb.com; withdrawal does not affect the lawfulness of processing before it.

The consent wording, preserved verbatim. Version waitlist-privacy-v1 of the consent wording is:

Email me about access to the RunMyB beta, including any questions we need to ask before deciding. RunMyB, Inc. will use your address for that and nothing else, and you can withdraw any time at privacy@runmyb.com. Privacy Policy

("Privacy Policy" is rendered on the form as a link to this document.) If the wording ever changes, the version identifier changes with it and this section keeps every wording it has carried.

Retention. We keep a waitlist record until you are invited — the record is then the invitation's provenance and follows the life of the account it led to — or until you ask to come off the list, whichever comes first.

Your rights. A waitlist signup has no account and therefore no in-platform data-request flow; the route for access to, correction of, a copy of, or erasure of a waitlist record is privacy@runmyb.com, handled by hand within the statutory response period. If you have not been invited, an erasure request deletes the record; after an invitation, the record follows the account, and the account's own rights machinery (Section 9) covers it.

2.2 The activity narrator

Every venture has an activity narrator: a running written account of the work on that venture — what has been done, what is being worked on, what was decided and what waits on a decision — composed by the platform for the venture's owner, in plain language, from the venture's own records, and shown on the venture's "What's happening" card. It is a module: it is on for every venture unless it is turned off, and any member of the account may turn it off, or on again, for a venture on that venture's Modules card. In this section:

what it is composed from. The venture's own records: the platform's log of what happened in the venture, its decisions and approvals, the build agents' recorded work (the steps they took and, in bounded excerpts, the working output they produced along the way), the artifacts and versions they produced, and what was agreed in the venture's conversations with the platform's assistant. The narrator never reads what a call cost or which model served it. It reads the evidence attached to an approval only for an approval to publish a build, and only so that the platform can work out, from what is recorded there about the platform's own checks of that build, one plain outcome — the checks passed, they found problems, they did not finish, or no outcome could be read. Only that outcome is sent to the model; the evidence itself never leaves the platform for the narrator;
what leaves the platform, and to whom. For each entry, the platform composes a digest of those records and sends it to an AI model, which writes the entry. Before anything is sent, the platform cleans the digest by the shape of what it finds: web addresses, identifiers and hashes, dollar figures and qualified model names are removed; file paths are shortened to their last few parts, so folder names may remain; in structured records, values whose field names say they carry money, a model, an identifier or a token count are dropped; and every text field is bounded in length. These checks recognise shapes, not meaning: a name, an address or a secret typed into a chat message is not recognised by them and may leave with the excerpt. The last few entries already written and the narrator's own carried notes on the work ride with each request so the account stays continuous. Excerpts of the venture's conversations with the assistant leave too — the messages sent in that venture's conversations — yours and those of other members of the account — and the assistant's replies, each bounded in length and cleaned the same way — so that what was agreed in those conversations can be recorded; a whole conversation never leaves, and the narrator is instructed to record what was agreed, not to restate or quote the messages. The request goes to OpenRouter, Inc., our sub-processor for AI model routing (Section 5.1), under RunMyB's own account and key, and OpenRouter routes it to the provider of the model the platform has configured for the narrator — today Google LLC, whose Gemini model serves the narrator as OpenRouter's own provider. RunMyB has no account and no contract with Google for this;
what the providers do with it, as their own published terms state it, and how the narrator's requests are routed. OpenRouter states in its privacy policy that it does not use inputs or outputs for model training, and in its documentation that it stores request metadata but not the prompts or responses themselves unless the account holder opts in to such logging; that is OpenRouter's published default, not a statement about RunMyB's own account settings. The narrator's requests, like every request RunMyB sends through OpenRouter on its own account, are sent with a routing instruction that excludes providers whose terms allow the use of request data for model improvement, so they may be served only by a provider whose published policy, as OpenRouter records it, states that request data is not used for training — today Google LLC's Gemini model, under Google's paid-API terms; if no such provider is available for the configured model, no model provider receives the request and the account simply waits. OpenRouter names Google as the provider for the narrator's model; Google's published terms for its Gemini API state that for its paid services Google does not use prompts or responses to improve its products and logs them for a limited time solely to detect and prevent violations of its prohibited-use policy. RunMyB has no direct contract with Google and relays that documentation as Google publishes it; the commitment RunMyB relies on is OpenRouter's own;
RunMyB itself does not use the digest, the conversation excerpts or the entries to train any model, does not permit any provider to do so on RunMyB's behalf, and sends them solely to produce the account for the venture's owner (Data Processing Addendum, Section 7);
what RunMyB keeps. The entries the model writes — the platform does not rewrite their wording: it may shorten an over-long entry, drops one that rests on no record, and files one of an unknown kind as a note — and an entry in which the platform's own check still finds an identifier, a path, a money figure or a model name is kept and flagged in the platform's records, never silently edited — together with the narrator's working state for the venture (its carried notes on the work, its reading position in the records, and the counts of what its checks removed or flagged). Both are kept for the life of the venture and deleted with it, and both are part of the account's data export (Section 9). RunMyB also keeps every earlier version of the narrator's short note on what the work is on, and every item it listed as finished, each with the time it first appeared, so that the venture's earlier descriptions can be read in the console. That history is part of the account's data export and leaves the platform for no one: each line went to the narrator's model provider only while it was among the narrator's carried notes, as described above, and nothing reads the kept history back into a request. It is kept for the life of the venture and deleted with it — or earlier: erasing any one of the venture's products deletes the venture's whole history, together with the narrator's working state and the entries that record that product or work on it, and the account continues from what remains. Each request the narrator makes is also a usage-metering record, as any AI call on the platform is (Section 2);
turning it off. Turning the narrator off for a venture stops the account and stops any data leaving for it; the entries written before are kept, not deleted, and are shown again when it is turned on;
the account is informational. Nothing in it acts on your behalf: it has no controls, proposes nothing and executes nothing, and a decision the platform needs from you is taken where that decision is put to you, never in the account. The entries are written by an AI model and may be inaccurate or incomplete (Terms of Service & Acceptable Use, Section 13).

2.3 The avatar's learned actions and the avatar director

The console's chat avatar can act out a short action on screen — waving, dancing, playing with a ball — when the platform's assistant, in a conversation, asks it to; the assistant is instructed to do so when you ask for one, and to answer you in words as well. The platform first looks for an action the avatar already knows: one in your account's library of learned actions, or one of the avatar's built-in actions. Only when neither fits does it ask the avatar director — an AI model that writes a new animation for the action — and the platform checks every animation the director writes before anything plays. In this section:

what leaves the platform, and to whom. For each attempt, the platform sends the director one request carrying: the short description of the action that the assistant passed — the assistant is asked to write it as a short English phrase, and the platform reduces it to lower-case letters, digits and spaces and limits its length, but the platform does not check its language, and it may carry words from your message, such as a name; an optional short mood phrase, treated the same way; a description of what the avatar's body can do; the short descriptions of the actions your account has already kept — whichever member's conversation they were learned in — and of the built-in actions, so that the director can reuse one instead of writing a new one; and, when an earlier attempt was refused, the director's own previous answer with the reasons it was refused. At most three attempts are made for one request. Your message itself, the rest of the conversation, and your name or any other detail of your account are not sent with it — only what the short description itself contains. The request goes to OpenRouter, Inc., our sub-processor for AI model routing (Section 5.1), under RunMyB's own account and key, and OpenRouter routes it to the provider of the model the platform has configured for the director — today Google LLC, whose Gemini model serves the director as OpenRouter's own provider. RunMyB has no account and no contract with Google for this;
what the providers do with it, as their own published terms state it, and how the director's requests are routed. OpenRouter states in its privacy policy that it does not use inputs or outputs for model training, and in its documentation that it stores request metadata but not the prompts or responses themselves unless the account holder opts in to such logging; that is OpenRouter's published default, not a statement about RunMyB's own account settings. The director's requests, like every request RunMyB sends through OpenRouter on its own account, are sent with a routing instruction that excludes providers whose terms allow the use of request data for model improvement, so they may be served only by a provider whose published policy, as OpenRouter records it, states that request data is not used for training — today Google LLC's Gemini model, under Google's paid-API terms; if no such provider is available for the configured model, no model provider receives the request and the avatar shows a simple facial expression instead. OpenRouter names Google as the provider for the director's model; Google's published terms for its Gemini API state that for its paid services Google does not use prompts or responses to improve its products and logs them for a limited time solely to detect and prevent violations of its prohibited-use policy. RunMyB has no direct contract with Google and relays that documentation as Google publishes it; the commitment RunMyB relies on is OpenRouter's own;
RunMyB itself does not use the descriptions, the requests or the animations to train any model, does not permit any provider to do so on RunMyB's behalf, and sends them solely to have the animation written (Data Processing Addendum, Section 7);
what RunMyB keeps. An animation the director writes is saved in your account's library straight away, marked as new, so that the same request plays it again without asking the director a second time; a member of the account may keep it or drop it, and a kept action is also offered to the director for reuse, as described above. For each action the library holds its short description (and a fingerprint of it, used to find it again); the animation as the platform's check accepted it, and that check's results — or, where the director reused an action, which kept or built-in action it points to; how many attempts it took and which model wrote it; how often and when it last played; who asked for it and who kept it — the sign-in identifier the platform holds for each of them, today the e-mail address they sign in with, or the identifier their sign-in provider supplies instead; and when. The library belongs to the account: it is shared by the account's members, and an action learned from a request in one member's conversation plays for every member who asks for the same thing. An action stays in the library until a member drops it — which deletes it from the library (the action as it played remains in the conversation's own records, below) — or until the platform discards it because it no longer passes the platform's checks, or until the account is erased; you may also ask for any of them to be deleted through the route in Section 9. The library is part of the account's data export (Section 9). The assistant's request to the avatar and the action that played are also part of the conversation's records, like the rest of the conversation. Each attempt the director makes is a usage-metering record, as any AI call on the platform is (Section 2);
there is no setting that turns the director off. The avatar learns a new action only when a conversation asks it to act one out; if you do not want an action learned, do not ask the avatar to act one out. Dropping an action removes it from the library;
the avatar's actions are animations only. They change nothing in your workspace, act on nothing on your behalf, and decide nothing; an animation the director writes may not look like what was asked for.

2.4 An avatar you create from your own description

In your account settings you may create your own avatar instead of choosing a character from the platform's gallery (Section 3.1). You describe it in a sentence, in any language — or pick one of the ideas the platform offers — and the platform has an AI model, the avatar author, restate your description as one short sentence and draw the avatar from that sentence, in the same request; the author is asked to write the sentence in the language you wrote your description in and in the manner of the gallery's own characters. You then see the drawing with the sentence under it and choose to use it, to change it with a one-sentence instruction, or to try another. The author is instructed to draw people's avatars only — never a robot, which is how the platform's agents appear — and not to depict a real, identifiable person, brand, logo or trademark, but to turn such a request into a generic character. The drawing itself is made of drawn shapes and colours only: it has no text field, picture or link. In this section:

what is checked first. Before anything is sent to be drawn, your description — and a change you ask for — passes the platform's automated safety check, itself made by an AI model reached through OpenRouter, and the record of that check keeps the text it checked (Section 9 states what the check sends, to whom, and what its record keeps). A description that falls under the platform's prohibited or restricted categories is refused, with the reason and the route to appeal, and nothing is drawn;
what leaves the platform, and to whom. For each attempt at a drawing, the platform sends the avatar author one request carrying: your description exactly as you wrote it; or, for a change, your instruction together with the drawing and the sentence you are changing; or, when you try another, the sentence the platform wrote for your earlier drawing; the instructions and example characters the platform writes for every such request; and, when an earlier attempt did not pass the platform's checks, the author's own previous answer with the reasons it was refused. At most three attempts are made for one drawing. To offer you ideas, the platform sends a request at most a few times a day carrying nothing you wrote — only the language your browser is set to and the platform's own instructions, with a random value that varies the ideas from day to day. Your name, your e-mail address and any other detail of your account are not sent with any of these requests — only what your description or instruction itself contains: a name or other personal detail you write into it leaves with it. The request goes to OpenRouter, Inc., our sub-processor for AI model routing (Section 5.1), under RunMyB's own account and key, and OpenRouter routes it to the provider of the model the platform has configured for the avatar author — today OpenAI (OpenAI OpCo, LLC), whose model serves the avatar author as OpenRouter's own provider. OpenRouter also lists other providers of the same model and may route a request to one of them — for example when OpenAI's own service is unavailable — if that provider meets the routing instruction described below: today Microsoft Corporation, through its Azure service, and Amazon Web Services, Inc., through its Amazon Bedrock service, each listed as OpenRouter's own provider under its own terms with OpenRouter. This is OpenRouter's route, not RunMyB's own: RunMyB has no contract with Microsoft for it, and RunMyB's own agreements with OpenAI, which serves RunMyB directly only for the voice assistant (Section 6.1), and with Amazon Web Services, which hosts the platform (Section 5.1), do not cover it;
what the providers do with it, as OpenRouter's and OpenAI's own published terms state it, and how the avatar author's requests are routed. OpenRouter states in its privacy policy that it does not use inputs or outputs for model training, and in its documentation that it stores request metadata but not the prompts or responses themselves unless the account holder opts in to such logging; that is OpenRouter's published default, not a statement about RunMyB's own account settings. The avatar author's requests, like every request RunMyB sends through OpenRouter on its own account, are sent with a routing instruction that excludes providers whose terms allow the use of request data for model improvement, so they may be served only by a provider whose published policy, as OpenRouter records it, states that request data is not used for training — today OpenAI, and Microsoft or Amazon Web Services only if OpenRouter records the same for them; if no such provider is available for the configured model, no model provider receives the request and no avatar is drawn. OpenRouter names OpenAI, the model's maker, among the providers of the avatar author's model; OpenAI's published terms for its API state that OpenAI does not use the content sent to its API to train or improve its models unless the customer opts in, and that it may retain API inputs and outputs for up to 30 days to provide its services and to identify abuse. On this route OpenAI's API customer is OpenRouter, not RunMyB; RunMyB relays that documentation as OpenAI publishes it. Where Microsoft or Amazon Web Services serves a request, it does so under its own terms with OpenRouter, which RunMyB does not hold; RunMyB relays nothing from Microsoft's or Amazon Web Services' published terms for those services. On every one of these routes the commitment RunMyB relies on is OpenRouter's own, with the routing instruction;
RunMyB itself does not use your descriptions, the sentences or the drawings to train any model, does not permit any provider to do so on RunMyB's behalf, and sends them solely to have your avatar drawn (Data Processing Addendum, Section 7);
what RunMyB keeps. For each drawing: the sentence the platform wrote; the drawing as the platform's checks accepted it, with its style and kind of character; which model drew it; which earlier drawing it was changed from; whose it is — your sign-in identifier, as Section 2.3 describes it; and when. Your description itself is not kept with your avatars: the only copy the platform keeps is in the record of the safety check (Section 9). The drawing you use becomes your avatar: it replaces your previous one, which is deleted together with every drawing you had not used. Drawings you do not use are kept only for you to come back to: when you create again, any that are more than a day old are deleted, and no more than ten are kept. Choosing a gallery character instead keeps your avatar, so that you can switch back to it; deleting it removes it, and your avatar returns to the default. What remains is kept until you replace or delete it, or until the account is erased; you may also ask for it to be deleted through the route in Section 9. Your avatars and unused drawings are part of your own data export (Section 3.2) and of the account's data export (Section 9). The ideas the platform offers are held only in its working memory for the day and are not stored. Each request — the safety check included — is a usage-metering record, as any AI call on the platform is (Section 2); it carries a pseudonymous code derived from the account and your sign-in identifier, not the identifier itself, so that the platform can count your use against the usage limits shown in the product;
who sees it. The avatar you use is shown to the account's other active members wherever the console shows you to them, as a chosen avatar is (Section 3.1), and they may see the sentence that describes it. The drawings you have not used are shown to no one else in the console. The account-wide export, which is an administrator's (Section 3.2), carries your avatars and unused drawings, and — in the safety check's records — the descriptions and changes you wrote;
the drawing is made by an AI model. When the console shows you a new drawing, it marks it as made by AI, with the sentence that says what was drawn; a drawing may not look like what you asked for, and you may change it or try another. An avatar is a picture only: it changes nothing in your workspace and acts on nothing on your behalf. Creating your own avatar is optional: nothing leaves the platform for it unless you open the place in your settings where avatars are created, nothing is checked, drawn or kept unless you ask for a drawing, and the gallery remains.

2.5 The field survey and the references you name

Before the platform writes the plan for a product, it studies the field: the leading public services of the product's type, and any service you name — in a conversation, or in the venture's list of services and material to study — so that the plan can learn from what those services do and from how their users judge them. The study is a module: it is on for every venture unless it is turned off, and any member of the account may turn it off, or on again, for a venture on that venture's Modules card; you may also ask the assistant to skip it before a plan. In this section:

what is fetched. The platform studies a service from publicly available material only. A browser the platform runs on its own infrastructure opens up to ten of the service's public pages — for example its features, pricing and help pages — and keeps the text of each page and a screenshot of the part of it a visitor first sees; it does not log in, type or fill in forms. In its own automated fetching the platform honours each site's robots.txt: a page the site asks automated tools not to read is not captured, and the service is then studied from other public material. The AI models doing the study may also read other public material about the services — search results, their help pages, app-store listings, review sites and articles — through the web tools available to them;
the references you name. You may name a service, a link, a description or a file as a reference for your product. A reference may calibrate the platform's reviews of your product — for a link the platform keeps a short excerpt of public material about it and a record of where it came from; for a file, it reads the file you chose — and, once you confirm it for that purpose, it is studied with the field before a plan. When you name a reference you confirm a short statement on screen (Terms of Service & Acceptable Use, Section 10.4), and the platform keeps a record of it: the statement's exact wording, the link or a reference to the file it covers, who confirmed it, by their sign-in identifier, and when. That record is append-only and is kept as Section 8 states for the affirmations named there;
public reviews: the study's own summaries only. The study reads public reviews of the services for what their users praise and complain about, and keeps only its own short summaries of them. It is built to keep no reviewer's name, handle, picture or words: the study has no place for a person, its summaries are written in its own words, e-mail addresses and @handles are removed from them, a review's source is recorded as the review page's address, the study being built not to record a reviewer's profile, and the researchers' working notes are deleted once the study is recorded;
what leaves the platform, and to whom. What you asked for (your description of the product you want and of its venture, in your own words or as the platform restated them, and the services you named), the captured text, the other public material read, and the references and files you chose are sent to the AI models that do the study, and the study's findings to the models that write the plan and review the product, and to the platform's assistant in a conversation, when it reads the study for you; the providers of all of them are named in Section 5.1, or Section 5.1 states how OpenRouter chooses them. Each request the study makes to an AI model is also a usage-metering record, as any AI call on the platform is (Section 2);
what is kept, and who sees it. The captured pages' text and screenshots, and the comparison the study writes — the features and patterns of the services studied, what the plan should adopt, do better or add of its own, and where each finding came from — are kept with the venture, for the life of the venture, and deleted with it (Section 8). The comparison is shown, with the screenshots, where the plan is put to you, and it is part of the account's data export (Section 9);
RunMyB's role, and the basis. What you asked for, the references you name and the files you choose are processed to provide the plan you asked for (contract; where a file carries other people's personal data, RunMyB processes it on your behalf under the Data Processing Addendum). Personal data about other people that the public material the study reads happens to carry — a published testimonial, a name or a face in a screenshot, a name in a public review — is processed by RunMyB as controller, on its legitimate interest in studying publicly offered services, from their public pages, to plan the features of a customer's product. It is processed for that purpose only: nobody is contacted, profiled or identified from it. Because the platform cannot know or reach the people a public page shows, this section is how RunMyB makes the information about that processing publicly available, as Article 14(5)(b) GDPR provides: the source is the public web pages of the services studied and the other public material the study reads; what is kept, for how long, who receives it and how it is protected where a provider processes it outside the EU are stated above and in Sections 5.1, 7 and 8; and anyone whose data appears in what the study keeps may exercise the rights in Section 9, including the right to object, by writing to privacy@runmyb.com.

2.6 The language you last used

So that the platform's assistants — in your conversations, in a venture's conversations, in the account assistant and in a spoken conversation with Remi — answer you in your language, the platform remembers one language for you in each account you belong to: the language you last used with them, as a short language code, with where it was seen (your browser, a conversation or a voice session) and when. In this section:

where it comes from. It starts from the language your browser reports to the platform with your requests. After that it follows the language of what you yourself type and say; a click on a button or a card does not change it. For what you type, and for what you say to Remi on the voice assistant's OpenAI engine, a language detector that runs on the platform's own servers, and sends nothing anywhere, works the language out from your words. On the ElevenLabs engine it is the language Jev names for what you said (Section 6.1), remembered only when Jev names the same language for two things you say in a row;
what else it is used for. The Ideas stream takes it as your market: it offers you ideas aimed at that market, and has ideas written for it (Section 2.7);
what leaves the platform. Only the language code: it travels with the instructions of the AI models that serve the platform's assistants and Remi (Section 5.1), on the voice assistant's ElevenLabs engine as the conversation's language that Section 6.1 describes, and with the idea author's requests as the market an idea is aimed at (Section 2.7);
what is kept, and for how long. The language code, where it was seen and when — nothing more. It is kept for the life of the account and deleted when the account is erased; when your access to an account ends, it is retained under that account with your preferences (Section 3.4). It is part of your own data export (Section 3.2). There is no setting for it: it follows the language you use.

2.7 Your idea interests and reactions

The platform's Ideas stream offers you ideas for products you could launch — in the console, where you start a new conversation, and through the platform's assistants when you ask them for ideas. The platform writes the ideas itself, with an AI model, the idea author, from the results of web searches it runs, and offers beside them a starting set of ideas it collected before the stream opened, from public material about services and products and from its own research; sorts them into lanes such as "For you", "Fresh" and "Proven"; and ranks them for you. The Ideas stream is part of every account unless the account's administrators turn it off for the account. In this section:

what is recorded. For you, in each account you belong to: which ideas you have been shown, and how often; your reactions to them — "More like this" or "Not for me"; the ideas you launch; and the idea picked for you as the idea of the day. If you choose to tune your ideas, also the areas you choose and the line about yourself you may add; once you have saved them, the platform also writes ideas for you from them — your personal ideas — and keeps those too. Ideas the platform writes from one of the account's ventures (its spin-offs) belong to the account, like the venture;
why. To rank the ideas you are offered — ideas like the ones you favour come first, ideas you turn down are not offered to you again, and ideas you have already seen move down — and to write ideas for you (contract). The ranking only orders ideas: no decision about you is made from it;
what leaves the platform, and to whom. For each set of ideas it writes, the platform sends the idea author one request — and at most one more, when the answer cannot be read — carrying: the area the ideas are for, and the market they are aimed at, which for ideas aimed at you is the language code the platform remembers for you (Section 2.6); the titles of ideas already written in that area, so that the author does not repeat them; and the results of web searches the platform runs for the request, which ask only about the area, the market and the year. A request for your personal ideas also carries the areas you chose and your line about yourself; a request for spin-offs of one of the account's ventures also carries the venture's name, its one-line description and its audience, and the idea it was launched from, if any. Your name, your e-mail address and any other detail of your account are not sent with these requests — only what your line about yourself itself contains: a name or other personal detail you write into it leaves with it. The request goes to OpenRouter, Inc., our sub-processor for AI model routing (Section 5.1), under RunMyB's own account and key, and OpenRouter routes it to a provider of the model configured for the idea author, as Section 5.1 states, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement. When the platform's assistant in a conversation, or the account assistant, suggests ideas to you, it reads the ideas ranked for you, and may read your areas and your line about yourself so that it can say why an idea fits you; what it reads goes to its model as the rest of the conversation does (Section 5.1);
RunMyB itself does not use your areas, your line, your reactions or the ideas to train any model, does not permit any provider to do so on RunMyB's behalf, and sends them solely to have ideas written and suggested to you (Data Processing Addendum, Section 7);
what is kept, for how long, and who sees it. What this section lists is kept for the life of the account and deleted when the account is erased. Reset, where you tune your ideas, deletes your areas, your line and the record of the ideas you were shown, reacted to and launched, at any time; the personal ideas already written for you stay until the account is erased. When your access to an account ends, all of it is retained under that account (Section 3.4); Reset is how you clear your areas, your line and your reactions yourself before you leave. It is part of your own data export (Section 3.2) and of the account's data export, which is an administrator's (Section 3.2). The console shows your areas, your line and your reactions to no one else, and offers your personal ideas to you alone. Each request the idea author makes is a usage-metering record, as any AI call on the platform is (Section 2), paid by the platform within a daily allowance it sets for each account — nothing is charged to you or your account for it;
what other people see. The cost and time an idea card shows for a launch are ranges measured on launches made on the platform — at first, on those its operator made while measuring it (Section 2, usage-metering records). A card may also say how many ventures have been launched from that idea across the platform: a count of the launches recorded in the accounts' Ideas streams, shown only from three and naming no account or person (legitimate interest — telling the people who use the platform how often an idea has been taken up, a purpose compatible with the one launches are recorded for);
ideas offered to everyone, and people named in ideas. Ideas other than your personal ideas and the account's spin-offs — those written for everyone, and the starting set — are offered to everyone, and no account's content goes into them: they are the platform's own content, kept in its catalogue of ideas for as long as the platform offers ideas — an idea the platform stops offering stays in the catalogue, marked as retired, as the platform's record of what it has offered and so that the same idea is not written and offered again — and part of no account's data export. The idea author is instructed to name services, never people, but an idea, and the search results it is written from, may still name a person whom public material mentions, such as a founder or a public figure. Such personal data is processed by RunMyB as controller, on its legitimate interest in offering ideas for products grounded in publicly available information, for that purpose only: nobody is contacted, profiled or identified from it. Because the platform cannot know or reach the people public material names, this section is how RunMyB makes the information about that processing publicly available, as Article 14(5)(b) GDPR provides: the source is the results of public web searches and, for the starting set, the public material it was collected from; what is kept, for how long, who receives it and how it is protected where a provider processes it outside the EU are stated above and in Sections 5.1, 7 and 8; and anyone named in an idea may exercise the rights in Section 9, including the right to object, by writing to privacy@runmyb.com.

2.8 Photos you add to your apps

You may add your own photos to an app the platform builds for you — your place, your team, your work — when you approve the app's plan, or later on the app's page in the console, and the app then shows them where they fit. Adding photos is optional: an app without them is built as before. In this section:

what you confirm first. Before your first photo for an app, you confirm a short statement on screen: that you may use the photos you add to that app, including on its public site, and that everyone who can be recognised in them has agreed to appear in it (for a child, their parent or guardian has agreed), as the Terms of Service & Acceptable Use, Section 10.5, state. The platform keeps a record of it: the statement's exact wording, the app it covers, who confirmed it, by their sign-in identifier, and when. That record is append-only and is kept as Section 8 states for the affirmations named there;
what is checked, and what is removed. Each photo you add is first stored in the platform's private storage on Amazon Web Services, where Amazon GuardDuty scans it for malicious software; nothing else reads it before the scan's verdict. A file in which the scan finds such software is never opened by the platform, used in your app or shown to anyone, and the console tells you why (Section 9). Any other photo — one the scan cannot judge included, for which the platform's own image reader, which accepts JPEG, PNG, WebP and AVIF images alone, is then the only check — is opened in an isolated process within fixed limits, and the platform prepares from its pixels alone a small set of copies, in several sizes and in formats for the web. Nothing else of the original file is carried into them: not the place where the photo was taken, the camera or phone that took it, when it was taken, or any other data embedded in it. The platform keeps the original file only until the check the next point describes has passed the photo — for a photo that check holds, for as long as the hold lasts — keeps no file name, and does not use the photos to recognise or identify anyone;
the check for prohibited content. Before your app may use a photo, and before anyone outside your account but RunMyB's operating team can see it, the platform checks it automatically for three kinds of content its rules prohibit or restrict (the "Platform Rules — Content-Safety Taxonomy"): sexually explicit content, any sexual depiction of a person who may be a minor, and graphic violence. The check is made by an AI classifier, which receives one of the prepared copies — at most 1280 pixels wide, without the data the point above says is removed — with the platform's own instructions for the check, and nothing else: not the photo's description, and not your name, your e-mail address or any other detail of your account. The request goes to OpenRouter, Inc. (Section 5.1), under RunMyB's own account and key, which routes it to the one provider the platform names for the classifier it asks: today Microsoft Corporation (its Azure service) for the classifier the platform asks first, and Deep Infra Inc. for those it asks next, in a fixed order, when that one cannot answer. Each request carries a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place. The check is an automated assessment of what a photo shows — including whether a person in it may be a minor, and whether it is sexual — and records a label about the photo, never a trait of a person; it decides only whether the photo may be used in your app: no decision about the people it shows follows from it. Until a classifier has answered, the photo stays in your account, unused, and the platform tries again on its own schedule; a photo no classifier answers for goes to a person at RunMyB. A photo the check passes goes on as this section describes. A photo it finds to show sexually explicit content or graphic violence is held: kept, not deleted, and not used in your app, and the console tells you, on the photo, what was found, that this was decided automatically, and how to contest it (Section 9). A photo the check finds may sexually depict a minor, a photo a provider declines to look at, and a photo for which the platform cannot show that the classifier received the image go to a person at RunMyB before anything is decided, and the console says that a person is checking it. You may remove a photo the check held, which deletes it, and erasing your app or your account deletes it too; a photo that is with a person at RunMyB before anything is decided, and a photo RunMyB holds because of a notice it received, or because the law requires RunMyB to preserve it (Terms of Service & Acceptable Use, Section 15, item 4), you cannot remove, and while such a photo is in your app the app and your account cannot be erased: it stays as it is until RunMyB decides on it, and for as long as the law requires. RunMyB aims to decide on such a photo within 14 days. A hold placed on a photo your app already shows keeps the photo out of your app from the app's next update; the version already published shows it until then, unless RunMyB stops serving your app. Nothing is reported to anyone automatically: a held photo waits for a person at RunMyB. Where that person finds apparent child sexual abuse material and US law requires it, RunMyB preserves it and reports it to the National Center for Missing & Exploited Children (NCMEC), as the Terms of Service & Acceptable Use, Section 15, item 4 state. Where that person finds information that gives rise to a suspicion of a criminal offence threatening the life or safety of a person — and RunMyB treats apparent child sexual abuse material as such — RunMyB also informs law-enforcement or judicial authorities of an EU Member State, or Europol, as Article 18 of the EU Digital Services Act requires. RunMyB makes this check as controller, for its own purpose — not hosting content that is illegal or that its rules prohibit or restrict — on its legitimate interest in that, which includes preserving what it finds and reporting it to NCMEC as US law requires (Terms of Service & Acceptable Use, Section 15, item 4), and, where EU or Member State law requires RunMyB to preserve or report what it finds — as Article 18 of the EU Digital Services Act does for the notification above — to meet that legal obligation; the check is not processing on your behalf;
the description, which AI may suggest. So that visitors who cannot see a photo know what it shows, each photo needs a short description — the text a screen reader speaks. You may write it yourself, mark the photo as decoration only, or use the platform's suggestion: once the check has passed a photo, an AI model, the photo describer, suggests a plain description of what can be seen in it, in your app's language, instructed to name no one and to guess at no one's identity, health, origin, beliefs or other sensitive trait. The console marks the suggestion as written by AI. It becomes your app's text only once you confirm it, as it stands or after editing it; until then it is kept apart and never given to the build, and a photo whose description you have not confirmed is not used in your app;
what leaves the platform, and to whom. What leaves for the check is stated in the point on it. For each photo the check has passed, the platform sends the photo describer one request carrying one of the prepared copies — at most 1280 pixels wide, without the data embedded in the original file — your app's language and the platform's own instructions. Your name, your e-mail address and any other detail of your account are not sent with it — only what the photo itself shows, which may include people. The request goes to OpenRouter, Inc., our sub-processor for AI model routing (Section 5.1), under RunMyB's own account and key, and OpenRouter routes it to a provider of the model the platform has configured for the photo describer, as Section 5.1 states, with a routing instruction that excludes providers whose terms allow the use of request data for model improvement and a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data; where no such route can serve it, the platform suggests no description and you write it yourself. Once you have confirmed a photo's description, the prepared copies and the description are placed among your app's working files, and the AI models that build your app read them there: what they open goes to those models' providers as the rest of your app's working files does (Section 5.1), and, because your app's files then hold photos, a request that carries, or may carry, an image from them or a picture of your app's screens also carries a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data, or goes without the image (Section 2). Once your app is published, its visitors receive the copies it shows from your app's own address, as they receive the rest of the app;
RunMyB itself does not use your photos or their descriptions to train any model, does not permit any provider to do so on RunMyB's behalf, and sends them solely to have your photos checked and described and your app built (Data Processing Addendum, Section 7);
what RunMyB keeps. For each photo: the prepared copies, with their sizes and formats; the photo's width, height and average colour; the result of the scan for malicious software, and the size and a checksum of the file you added (never the file itself once the check has passed the photo); its description, with its language, who confirmed it — by their sign-in identifier — and when; a suggestion not yet confirmed; and who added the photo, and when. All of it is kept with the app, until you remove the photo or the app is erased (Section 8). The record of the check of a photo it passed — which classifier answered, what it answered and the platform's measurement of the request, never the photo — is kept as long as the photo and deleted with it. For any other photo, the record of its checks and of what RunMyB decided about it, with the reasons stated to you, is kept with the app as RunMyB's evidence of those decisions until the app is erased, or for longer where the law requires RunMyB to preserve it. A photo whose description you have not confirmed stays, unused, until you describe or remove it. A file in which the scan found malicious software is kept as it is — the platform never opens, uses or shows it, though RunMyB's operating team may examine it to review the decision — until you remove it or the app is erased. Your confirmation is kept as the first point states;
when you remove a photo. It leaves your photos at once: the platform deletes it, with its prepared copies, from its own store of photos. Your app keeps showing it until the app's next update — which you can start from the same place in the console — and stops showing it then. Older copies remain elsewhere: in the earlier versions of your app that the platform keeps — those it published, kept so that your app can be restored to one of them, and those it prepared for previews — in the platform's copy of your app's code history, and in the platform's storage backups, which keep a copy for 35 days. If a person shown in a photo asks to have it erased and you instruct RunMyB to erase it — by writing to privacy@runmyb.com — RunMyB's operating team removes the photo from those earlier versions and from the platform's copy of your app's code history; an earlier version that carried the photo can then no longer be restored, and the backups' copy is gone within those 35 days. Without such an instruction, the earlier versions and the code history keep the photo until your app is erased. The copy of your app's code at your own git provider, if you connected one, is yours (Terms of Service & Acceptable Use, Section 12): removing the photo from its history is for you to do;
who sees it. In the console, your photos and their descriptions are shown to the people in your account who can open the app, and a photo the check holds or sends to a person is shown to RunMyB's operating team, who decide on it. Once your app is published, anyone who visits it can see the photos it shows, with their descriptions;
RunMyB's role, and the basis. The photos you add, the copies prepared from them and their descriptions are processed to show your photos in your app, as you asked (contract). For the people your photos show, you are the controller, and RunMyB processes the photos on your behalf under the Data Processing Addendum: their agreement, telling them what your app does with their image, and a lawful basis for any special category of personal data a photo reveals — about someone's health or beliefs, for example — are yours to see to (Terms of Service & Acceptable Use, Section 10.5). The record of your confirmation is RunMyB's own evidence of what was confirmed, kept for that purpose (legitimate interest). The check for prohibited content, and its record, are RunMyB's own, as the point on the check states. If you are shown in a photo on an app hosted here and write to RunMyB about it, RunMyB passes your request to the app's owner, who answers for it, unless the owner has instructed RunMyB otherwise or the law requires otherwise (Data Processing Addendum, Section 3(e)) — except for the check and its record, which are RunMyB's own and which RunMyB answers for; the app's own notice names its owner.

3. Team members

Where a customer's account has more than one user, the additional users (members — typically the customer's employees or contractors) are data subjects in their own right, and two relationships coexist:

For the platform's own records about you personally — your acceptance records for these documents, your login identity, the notices the platform e-mails you as an administrator or about a product that only you can see in the console, their record and your choices of which of them you receive, the records of what became of the e-mail the platform sends you, the count of the look-ups of an address you make in the console (Section 2), and the platform's security and operational logs — RunMyB is the controller, as for any user.
For the team-workspace data the customer manages about you — your membership and role, your invitation, your per-member environment, your attribution in shared work — the customer is the controller and RunMyB is the customer's processor: the customer's administrators decide who is admitted, what role they hold, and when access ends, and the platform processes accordingly. This processor relationship is described in the Data Processing Addendum.

3.1 What member personal data we process, why, and on what basis

Membership record — your role (administrator/member), status, display name, who invited you, and timestamps — to operate the customer's team account on its instructions (contract with the customer, processed under Article 28 GDPR; for the platform's own administration of access, legitimate interest).
Invitation records — the invited e-mail address, the inviting administrator, the role offered, and expiry. Before you accept, the invited address is third-party personal data (you have no account yet): we process it on the legitimate interest of the customer in admitting you and ours in operating the invitation mechanism. On the administrator's instruction, the platform itself e-mails the invited address the acceptance link; that e-mail names who invited you, into which team, and that the invitation is to join them on RunMyB, and it states that nothing happens if you ignore it — the invitation e-mail is itself the first notice you receive about this processing. Invitation tokens are stored only as a cryptographic hash (the raw token is shown once to the inviting administrator and never stored); an invitation is valid for the period stated in the invitation itself, and expired or revoked invitation records are purged after a short, fixed period — an address that never accepts does not linger.
Your per-member environment — your console arrangement, preferences, pins, and working context, remembered for you across machines — to provide the personalised service (contract).
Your remembered language — the language you last used in this account's conversations or with Remi, as a short language code, with where and when it was seen — so that the assistants answer you in it, and the ideas offered to you suit your market (contract; Sections 2.6 and 2.7).
Your idea interests and reactions — the ideas you were shown in this account's Ideas stream, your reactions and launches, the areas and the line about yourself you chose, and the ideas written for you — so that the stream ranks and writes ideas for you (contract; Section 2.7).
Your chosen avatar — the character you may pick from the platform's gallery, in your account settings, to stand for you in the account's workspace, and which is shown to the account's other active members wherever the console shows you to them — today, beside your name on your turns in shared venture conversations — so that the team can tell members apart at a glance (contract). The record holds that character's identifier, whose avatar it is and who chose it — both your sign-in identifier, as Section 2.3 describes it — and when it was chosen and last changed; nothing more. Changing back to the default avatar deletes it. The characters an administrator picks for the account's agents — the platform's assistant and the other agents that work in the account — are the customer's workspace settings (the customer's instruction): every member sees them. The platform keeps, with each, which administrator chose it (by their sign-in identifier, as Section 2.3 states) and when; that is not shown in the console and is part of the customer's account-wide export only (Section 3.2). Instead of a gallery character, you may create your own avatar from a description you write (Section 2.4): the one you use is shown in the same way, and what is checked, sent and kept for it, and who sees it, are stated in Section 2.4.
Attribution in shared records — your authorship of turns in shared venture conversations and your recorded decisions — for accountability within the customer's team and the integrity of the customer's records (legitimate interest of the customer and the platform; these attributions live inside the customer's records, Section 3.3).
Venture assignments — which of the customer's ventures you work on — to organise the workspace (contract / the customer's instruction).
Member-to-member messages — the messages you exchange with other members inside the account's workspace, and your answers by e-mail to the platform's notices about the account, which the platform keeps as messages to you, as Section 2 states (contract / the customer's instruction; the export posture is in Section 3.2).
Your acceptance records — which document versions you personally accepted, when, and from where — kept as append-only compliance evidence (legal obligation and legitimate interest in proving consent).

3.2 Your rights as a member — the self-export

Every member has the data-subject rights in Section 9 personally. In addition, you can export your own data — your acceptance records, membership record, environment and preferences, remembered language (Section 2.6), idea interests and reactions and the ideas written for you (Section 2.7), chosen avatar, the avatars you created and the drawings you have not used (Section 2.4), venture assignments, your messages, the platform's notices to you about the account and the records of the e-mail it sent you, or refused to send you, for the account, with what became of it (Section 2), and the conversations you own — yourself, without an administrator's involvement, and download the bundle you filed for; the account's administrators can download it too. In the messages you sent, the other party's read and delivery markers are redacted: your export does not reveal when someone else received or read your message. Account-wide requests are the customer's: a tenant-wide export or the deletion of the whole account is an administrator-only act (it concerns every member's and the customer's data at once).

3.3 Shared conversations are the customer's records

Your authored turns in shared venture conversations are part of the customer's records (see the Terms of Service & Acceptable Use, Teams — "Work products and shared records belong to the customer"). Your self-export therefore covers the conversations you own — your private lanes — and excludes shared venture lanes; the exclusion is reported in the export, with counts, never silently. Access to your personal data inside the customer's shared records is exercised through the customer, as is usual between employer and employee. Where the activity narrator is on for a venture, your turns in that venture's shared conversations may also leave the platform — bounded and cleaned, for the narrator's model — as Section 2.2 describes. The avatar's library of learned actions is likewise the account's: an action learned from a request in any member's conversation — the conversations you own included — joins the account's shared library, where the account's members see the short description it was learned for and who asked for it (by their sign-in identifier, as Section 2.3 states), and its description may be sent to the avatar director with later requests (Section 2.3).

3.4 When you leave — the departed-member posture

When an administrator disables your membership, your access ends but the account's records do not change:

Your personal lanes and preferences are retained under the customer's account but are inaccessible — nobody else gains access to your private assistant conversations by your departure; they simply stop being reachable. Your chosen avatar — one you created included (Section 2.4) — is likewise retained, and is no longer shown to the account's members. Your remembered language (Section 2.6) is likewise retained, and so are your idea interests and reactions and the ideas written for you (Section 2.7); Reset, where you tune your ideas, clears your interests and reactions before you leave, if you wish.
Your contributions to shared work remain, attributed, as the customer's records (Article 17(3) GDPR and the employment-records reality; retention follows Section 8).
Erasure of a departed member's data narrower than the whole account is exercised through the customer as controller: the departed member's data is retained inaccessible under the customer's account, with the account-wide erasure machinery and the retention schedule in Section 8 as the outer bound.
Disabling is reversible; the customer may re-enable you. Your acceptance records are not affected by disablement (they are compliance evidence, kept append-only).

4. The statistics posture

When anyone uses the platform — the console, or a product hosted on it, in its preview or on its public pages — two first-party sources, both operated by RunMyB, keep a record of the visit with information about the visitor:

The load balancer's request logs — the platform's load balancer, which every request to the console and to the hosted products passes through, writes a record of each request.
A cookieless first-party beacon — a small script served with hosted product pages that reports each page view to the platform's own collection endpoint on the same site. The beacon sets no cookies, uses no local storage, does no fingerprinting, and performs no cross-site tracking — it reads nothing from your device beyond the page context it runs in, and a hosted product can switch it off entirely.

What the records contain. Depending on the source: the visitor's network address; browser and device information, such as the browser's identifier; the page requested and the site that referred the visitor to it; the time of the visit; the platform's response; and a pseudonymous visitor identifier, which the collection endpoint derives from the network address, the browser information and the product's address with a key that changes every day. The beacon's records keep that identifier in place of the network address and the browser information. It can be traced back to a visit's address and browser only by someone holding that day's key. The identifier is different on every product and every day, and RunMyB does not use it to recognise a visitor across days or across products. Where further indicators are derived from these records as a visit is recorded — such as the kind of device, or the country a visit comes from — they are kept no longer than the records they come from.

Why, and for how long. RunMyB keeps these records for three purposes: to give each hosted product's owner statistics about the use of their product; to keep the platform and the products on it secure and running, including investigating faults and abuse; and to compile aggregate statistics about the platform and the products built on it. The records are kept for up to 30 days, then deleted. The statistics counted from them identify no visitor and are kept for as long as they are useful. RunMyB may publish aggregate statistics about the platform at any time; the statistics of a single product are shown publicly only with its owner's consent (Terms of Service & Acceptable Use, Section 15.5).

The beacon stores nothing on your device and reads nothing from it beyond the page context it runs in — the page's address and the page that referred to it — and it is the platform's own, first-party audience measurement, whose records serve the statistics this Section describes and nothing else. On those grounds, which the French CNIL's guidance on first-party audience measurement supports, the platform shows no cookie-consent banner. The strictly-necessary session cookies the console itself uses are described in the Cookie & Tracker Notice.

Whose processing this is, stated plainly. RunMyB keeps these records, and the statistics counted from them, as an independent controller, on the basis of its legitimate interests in keeping its platform secure and running and in understanding — and showing — whether and how the platform and its hosted products are used, and of each product owner's interest in knowing how their own product is used. This includes the records of visits to a customer's hosted product: they are RunMyB's own processing, not processing on the customer's instructions, which is why they are described here rather than in the Data Processing Addendum, and they are not Customer Personal Data under it. A customer's own notice to the visitors of their product can say so (Terms of Service & Acceptable Use, Section 15.1). The customer's lever over the beacon is the per-product opt-out: a hosted product can switch the beacon off entirely, and the platform then derives no beacon statistics from that product's pages; the load balancer's records are kept for every request, the platform's security and operation needing them.

5. Recipients

5.1 Our sub-processors

We share personal data with a small, named set of providers engaged by RunMyB, each under the provider's standard data-protection terms:

Sub-processor	Function
Amazon Web Services (AWS)	Cloud infrastructure and hosting — compute, storage, database, and networking for the hosted platform, the platform's identity provider, which holds the login identities of the people who use the console and sends them its messages about signing in (Amazon Cognito), the scan for malicious software of the files the hosted apps keep and of the photos you add to them (Amazon GuardDuty), and the sending of the platform's e-mail and the receiving of the e-mail sent to the apps hosted on it and to the reply addresses of its notices, with that e-mail's scan for viruses and spam (Amazon Simple Email Service)
Anthropic PBC	AI model provider — runs the AI assistants and build agents that process workspace content, for every platform role configured to use it; where a role is configured to route through OpenRouter instead — today among them the automated content-safety checks that Section 9 describes — the OpenRouter row states how the provider that serves it is chosen, and names today's providers for the models the platform configures
Neon, Inc.	Hosted-product databases — an isolated, dedicated Postgres database (one Neon project per product) for each data-bearing hosted product, holding that product's data, including any personal data the product processes (US region)
Stripe, Inc.	Payments and billing — partially an independent controller for payment data; card data is collected and held by Stripe, not RunMyB
Cloudflare, Inc.	DNS and edge services — domain name resolution and edge delivery; no workspace content, except the voice assistant's test sessions of RunMyB's own administrators through a Cloudflare tunnel
ElevenLabs (Eleven Labs Inc.)	Speech-to-text for voice dictation — engaged when you use the voice-dictation feature with an ElevenLabs engine (Section 6); audio is sent under RunMyB's own key, which never reaches your browser — and the speech engine and voice of the voice assistant when your session runs on its ElevenLabs engine (Section 6.1): your browser sends your audio directly to ElevenLabs' speech engine, which transcribes it and sends the platform the text, over a connection the platform sets up for each session under RunMyB's own account, whose key never reaches your browser; ElevenLabs' voice model turns the text of Remi's replies, which the platform sends it, into Remi's voice, which the platform relays to your browser without storing it
OpenAI (OpenAI OpCo, LLC)	Speech model for the voice assistant on its OpenAI engine, the default — engaged only when you open a spoken conversation with the platform's assistant while that engine is configured, or while the voice assistant's ElevenLabs engine is configured and cannot serve your session when it starts (Section 6.1); your browser exchanges audio directly with OpenAI under RunMyB's own account and key, which never reaches your browser; OpenAI also sends the platform, over the platform's own connection to the session, a copy of the session's audio, which the platform receives only transiently and discards without it being decoded or kept (Section 6.1); the platform sends OpenAI, as text, what the assistant says about your workspace and receives the transcripts; OpenAI also serves, as OpenRouter's own provider, the avatar author (Section 2.4), the phrasing of the voice assistant's notes on its ElevenLabs engine (Section 6.1) and the other platform roles configured to one of OpenAI's models, the console's chat assistants among them — those routes are OpenRouter's, not RunMyB's own OpenAI account (the OpenRouter row)
OpenRouter, Inc.	AI model routing — engaged for platform-side engine tasks where a platform role is configured to route through it, among them the activity narrator (Section 2.2), the avatar director (Section 2.3), the avatar author (Section 2.4), the automated content-safety checks that Section 9 describes, among them the check of the photos you add to your apps (Section 2.8), the voice assistant's reaction model and the phrasing of its notes on its ElevenLabs engine (Section 6.1) and the build roles; for such a task OpenRouter routes the request to the provider of the model configured for that role, which serves it as OpenRouter's own provider — for the narrator and for the avatar director, today, Google LLC (its Gemini model); for the check of the photos you add to your apps (Section 2.8), which RunMyB makes as controller, the one provider the platform names for the classifier it asks — today Microsoft Corporation (its Azure service), serving OpenAI's model, for the classifier it asks first, in the European Union where the platform names Azure's endpoint there and otherwise wherever Azure serves the request, which may be the United States, and Deep Infra Inc. for the classifiers of other makers it asks next, in a fixed order, when that one cannot answer — each request carrying a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place; for the other content-safety checks, today, Google LLC (its Gemini model), each check's request carrying a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place; for the voice assistant's reaction model, Jev, today, TypeSafe AI, Inc., each request carrying a routing instruction that allows that one provider only, only where OpenRouter records it as not using request data for training, and never another provider in its place; for the avatar author and for the phrasing of the voice assistant's notes, today, OpenAI (OpenAI OpCo, LLC), serving under its terms with OpenRouter, or — where OpenRouter routes a request to another provider of that model, for example when OpenAI's own service is unavailable — Microsoft Corporation (its Azure service) or Amazon Web Services, Inc. (its Amazon Bedrock service), each serving under its own terms with OpenRouter, the requests of both carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement; for every other role so routed — among them the build roles, the console's chat assistants, the roles that research the market and plan a product (Section 2.5), the idea author (Section 2.7) and the photo describer (Section 2.8), whose requests also carry a routing instruction under which OpenRouter sends them only to a route it records as retaining no request data — OpenRouter routes the request to a provider of the model configured for that role, or chosen for a conversation, which serves it as OpenRouter's own provider under its own terms with OpenRouter, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement, and each request that concerns an application whose files hold photos and carries, or may carry, a picture the platform took of that application or an image from its files also carrying a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data, the picture or image being left out where the model has no such route or the request cannot carry that instruction (Section 2): for OpenAI's models, today, OpenAI (OpenAI OpCo, LLC), Microsoft Corporation (its Azure service) or Amazon Web Services, Inc. (its Amazon Bedrock service); for Google's Gemini model, today, Google LLC; for DeepSeek's model, which platform roles, among them the build roles, the general worker and the development executor (`build-ui`, `build-core`, `worker` and `dev-executor` on the account's Models card), may be configured to, a provider of that model that OpenRouter chooses among those whose published data policy, as OpenRouter records it, does not use request data for training — for example Deep Infra Inc., Parasail, Inc. or the provider OpenRouter lists as InferenceNet — the routing instruction excluding DeepSeek's own endpoint while OpenRouter records its policy as allowing the use of request data for training (DeepSeek's published privacy policy states that it uses the personal data it collects to train and improve its models); the requests routed to DeepSeek's model carry no instruction that requires a zero-data-retention policy, except as this row states for a request that concerns an application whose files hold photos and for a request that carries Google user data; a request that carries Google user data is routed to DeepSeek's model only on RunMyB's own OpenRouter account, and it also carries a routing instruction that excludes DeepSeek's own endpoint, whatever OpenRouter records of its policy, and one under which OpenRouter sends it only to an endpoint that OpenRouter lists as having a zero-data-retention policy (Section 5.3) — and, from 2026-09-15 until 2026-10-18, the build roles' requests carried no such routing instruction, RunMyB's OpenRouter account permitted routing to providers whose terms allow the use of request data for model improvement and OpenRouter was instructed to prefer DeepSeek's own endpoint (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.), so that the build content routed in that period was disclosed to DeepSeek or, where that endpoint could not serve, to another of OpenRouter's providers for that model, as the Data Processing Addendum's Section 7 records; for SpaceXAI's Grok model, which platform roles, among them the general worker and the development executor (`worker` and `dev-executor` on the account's Models card), may be configured to, SpaceXAI LLC (xAI) or Amazon Web Services, Inc. (its Amazon Bedrock service), each request also carrying a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data — SpaceXAI's zero-data-retention service, or Amazon Bedrock; for Anthropic's Claude models, Anthropic PBC or another of OpenRouter's providers for those models; and, for a model of another maker that you choose for a conversation, or that your account's administrators configure for a role on the account's Models card, a provider of that model — the model by your own choice, the provider by OpenRouter's routing — that RunMyB does not name in advance; and, when you choose the Microsoft engine for voice dictation (Section 6), to route your recording to Microsoft's MAI-Transcribe model, which Microsoft Corporation serves as OpenRouter's provider; RunMyB has no direct contract with Google, DeepSeek, Microsoft, TypeSafe, SpaceXAI or any other provider OpenRouter routes to, other than Anthropic, OpenAI and AWS, whose own agreements with RunMyB (their rows) do not cover any route through OpenRouter
Zoho Corporation	E-mail correspondence — mailboxes for the platform's support, privacy, and legal contact addresses (EU data centre)

The Data Processing Addendum contains the authoritative sub-processor list, the change-notice and objection mechanics, and the transfer safeguards.

5.2 Connected services you authorize

These recipients are your choice — they are not our sub-processors. When you connect a third-party service to your account, the platform transmits data to it at your direction, under your own account and authorization; your own contract and the provider's privacy terms govern that processing, and the provider acts for you, not for us. Data flows only for what you explicitly connect or bind. Disconnecting stops the flow, immediately deletes the stored token from our encrypted vault, and — where the provider offers a revocation endpoint — revokes the token upstream as well, except that, for a Google service, RunMyB asks Google to end its access when the last Google service connected with the same Google account is disconnected: Google keeps one access grant per app on each Google account, shared by those services (Section 5.3).

Git providers (GitHub, GitLab, Bitbucket, or a self-hosted service). If you export, synchronise, or import a product repository, the platform transmits that product's code and its git metadata (commit contents, messages, and timestamps) to your provider — only for products you explicitly bind to a connection. To operate the connection we store the provider's name and base URL, the label you gave it, and your access token, encrypted at rest through a write-only field: never shown back, never logged, never placed in command lines or URLs, used only at the moment of a git operation, and deleted when you delete the connection. Secret-scan findings reported to you carry masked values only.
Google Drive (import). For Drive access the connection requests only the drive.file scope — Google's narrowest Drive scope, alongside basic identity (your e-mail address, to label the connection): access is limited to the individual files you explicitly pick in the Google Picker, never your whole Drive and never files you did not pick. A picked Google Docs file is exported to text and a regular file is downloaded as-is; the imported copy lives in your venture's document library with its provenance recorded, and we store only what you imported. The imported copy is part of your venture's content: when you ask them to, the platform's AI assistants, the knowledge module (where you attach an import to shared knowledge) and the brand import read it, and the build agents read the pages distilled from it — the build agents also see the names of the file and of the Google account it came from in your venture's library, and the activity narrator (Section 2.2) sees those names, and what an assistant said about the file in a conversation, in the venture's records — and what they read travels in their requests to the AI model providers Section 5.1 names or describes, under the no-training routing and never to DeepSeek's own service, as Section 5.3 states; its text, bounded, is also examined by the automated content-safety check Section 9 describes when you import it, before a changed version of it is copied, and when you attach it to shared knowledge. Your Google tokens live only in the platform's encrypted vault, by reference — they never appear in logs, responses, prompts, or model transcripts — and your browser drives the Picker with its own short-lived token, distinct from the vaulted one. While the connection stays, the platform periodically checks Google for changes to the files you imported. A changed file is first examined by the same automated content-safety check as an import: if the check admits it, it is copied again as a new version of the imported copy, the earlier version being kept with it; if the check holds or refuses it, it is not copied, and the earlier version stays the current one. A file removed at Google stays in your library.
Gmail (where you connect it). The send scope only. The platform sends an e-mail through your account only after you have confirmed the exact message: assistants may draft, you confirm the precise payload, and the platform executes only what you confirmed, integrity-verified against what you saw. Of Google's answer the platform keeps only the identifier of the sent message, with the record of your confirmation; the platform never reads your mail.
Google Calendar (where you connect it). Read-only event access; the platform reads your primary calendar only. It periodically reads that calendar's event list to notice new, changed or cancelled events and to tell you about them, marking one about to start as needing your attention now; of each event it keeps only a reference and a fingerprint from which it can tell that the event has changed — titles, attendees and descriptions stay at Google. When you ask the platform's assistant about an event, it reads that event live from Google, and the event's details travel in the assistant's request to the AI model provider Section 5.1 names or describes for the assistant, under the no-training routing and never to DeepSeek's own service, as Section 5.3 states; the details then stay in that conversation's records like anything else said there, and a conclusion the assistant records from them as a derived note is a distillation held for your review, never a copy.
Trello. Your own Trello token; the platform periodically reads the boards and cards you connect.
Notion. Your own Notion authorization (OAuth or an internal integration token you create); the platform reads pages and search results of the connected workspace.
AI providers under your own keys. You may store your own AI-provider key (for example, an OpenRouter key) in the platform's encrypted vault and run your product's live AI features on it during previews: requests then flow to that provider under your key and your own relationship with it — distinct from the platform's own engine-lane use of OpenRouter listed in Section 5.1. Where your product offers its end-users their own keys, those keys belong to the end-user's own provider relationship and are stored encrypted for that purpose alone.
Sign-in providers for your products (today Google or GitHub). Where one of your applications offers its end-users sign-in with such a provider, you register the sign-in app in your own account with that provider and the platform relays the application's exchange with the provider through that registration, passing the identity the provider returns to your application and keeping none of it (Section 1; the Data Processing Addendum, Section 2). The client secret you register is held in the platform's custody, encrypted at rest, read only by the relay and never placed in your application, and it is deleted from that custody when you ask us to stop using that provider for the product; you can also delete or reset it in your own account with the provider.

Imported content passes an automated content-safety admission before it enters the shared document library — the same category catalog the platform's build lanes use. An item flagged as needing review is held (not surfaced), with the reason recorded for a platform administrator; this is a security fail-safe applied at import time to content you chose to import, not an editorial review, and it operates within the human-review limits stated in Section 5.3.

5.3 Google user data — the Limited Use commitment

RunMyB's use of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use of information received from Google Workspace scopes will adhere to the Google User Data Policy, including the Limited Use requirements. In particular, for data received through your Google connections:

No model training. Google Workspace APIs are not used to develop, improve, or train generalized or non-personalized AI and/or ML models, and neither is the data obtained through them nor any data derived from it — by RunMyB or by any third party. Content obtained from your Google account is never used to create, train, or improve any machine-learning or artificial-intelligence model — RunMyB's or a third party's.
AI model providers. Google user data reaches an AI model only when a feature you use needs it — the assistant you ask about an imported file or a calendar event, in writing or, through the voice assistant (Section 6.1), in speech; the knowledge module you attach an import to; the builds you run (which read the pages distilled from an import and the names in your venture's library); the brand import you give an imported file to; the activity narrator (Section 2.2), which reads the venture's records and conversations; and the automated content-safety and go-live checks — and only in a request sent under RunMyB's own account to a provider that Section 5.1 names or describes, whose terms, the routing instruction RunMyB attaches or the setting of RunMyB's account with it (Section 6) exclude the use of request data for training. Every such request that RunMyB sends through OpenRouter, Inc. carries a routing instruction that excludes every provider whose published data policy, as OpenRouter records it, allows the use of request data for training or model improvement, and RunMyB keeps switched off every setting of its OpenRouter account that would permit routing to such a provider. It is never sent on an AI key of your own, and it is sent to a model for no platform purpose other than the feature that needs it. What an application you build carries in its own code and prompts is that application's content; where you run its AI features on a key of your own (Section 5.2), its requests are yours, under your own relationship with the provider — and RunMyB's model gateway (below) still refuses a DeepSeek model for them where the application's venture holds Google user data.
Never to DeepSeek's own service. Google user data is never sent to DeepSeek's own service (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.) — even where you, or your account's administrators, have chosen a DeepSeek model for the work that would carry it. RunMyB does not call DeepSeek's own service: the platform reaches DeepSeek's models only through OpenRouter, Inc. (Section 5.1). A request that carries Google user data may be served by a model made by DeepSeek only where RunMyB sends it on its own OpenRouter account, and only under three routing instructions. The first is the one the bullet above states: it excludes every provider whose published data policy, as OpenRouter records it, allows the use of request data for training or model improvement. The second excludes DeepSeek as a provider, whatever OpenRouter records of its policy. Under the third, OpenRouter sends the request only to an endpoint that OpenRouter lists as having a zero-data-retention policy. So, for such a request, a DeepSeek model is served by a provider other than DeepSeek, whose published data policy, as OpenRouter records it, does not use request data for training, at an endpoint that OpenRouter lists as having a zero-data-retention policy. A provider other than DeepSeek can serve the model because DeepSeek publishes the model's weights. The third instruction applies to the whole request: a model of another maker named for the same request, as its model or as a fallback, is also served only at such an endpoint, and where OpenRouter has no such endpoint for the request, the request is not served. When the platform receives content from a Google API, it records that Google user data has entered the conversation, venture or run that receives it, and it carries that record with the content wherever the platform's own tools take it — into a run started from such a conversation, into the venture's own pages, notes, records and messages derived from it, and into a conversation that reads any of them. The record cannot follow content that you yourself copy out of the platform and type or paste elsewhere; such a copy is your own input. RunMyB's model gateway composes every request the platform sends through OpenRouter, other than the two fixed routes Sections 6 and 6.1 name — the Microsoft dictation engine and the voice assistant's reaction model — each of which names one fixed model of another maker and admits no other, so that neither can reach a DeepSeek model. For a conversation, venture or run that the record shows to hold Google user data, or where it cannot establish what that record shows, the gateway adds the instruction that excludes DeepSeek as a provider to every request it composes, and the zero-data-retention instruction to every such request that names a DeepSeek model, as its model or as a fallback; it refuses, before sending it, any such request to a DeepSeek model unless RunMyB sends it on its own OpenRouter account under the three routing instructions above; and it records each request it composes for such a conversation, venture or run in an audit record that names the model and the provider that served it, as OpenRouter reports them. Should OpenRouter report DeepSeek as the provider that served such a request, or report no provider for such a request that a DeepSeek model served, the platform raises an alarm and opens an incident.
No advertising and no sale. Google user data is never sold, never transferred to advertising platforms, data brokers, or information resellers, and never used to serve advertisements.
No human review, except (a) with your affirmative agreement, (b) for security purposes such as investigating abuse, or (c) where required by law. Beyond the security-purpose admission hold described in Section 5.2, RunMyB operates no human-review pipeline over your Google data — the bounded excerpts kept with the automated checks' records (Section 9) are read by RunMyB's operating team for that security purpose only.
What we keep and how it is deleted. An imported Drive file, and the pages distilled from it, are kept as part of your venture's content until the venture or the account is erased (Section 8); deleting the file in your venture's library removes it from the library but does not erase the copy sooner. Of each calendar event the platform has seen, and of each file you imported, the platform keeps a reference and a fingerprint until the account is erased; when you disconnect a Google service you may also choose to purge those references, which takes them out of use. An event's details that the assistant read for you stay in that conversation's records (Section 5.2). The identifier Google returns for a message sent through Gmail is kept with the record of your confirmation for the life of the account. The bounded excerpt an automated safety check examined is kept as that check's record for the period Section 8 states, also after erasure. Disconnecting a Google service deletes its token from our vault at once, and RunMyB then keeps no token for that service. Google keeps one access grant per app on each Google account, shared by the Google services connected with that account, so RunMyB asks Google to end that grant when the last Google service connected with that Google account is disconnected; until then, Google's own list of the third-party apps with access to your Google account can still show RunMyB, and there you can end RunMyB's access at any time. The imported copy, like the rest of your venture's content, is stored encrypted at rest on our hosting provider's storage, and it travels over encrypted connections whenever it leaves the platform's private network at that provider.
Onward transfers only as necessary to provide the features you requested, for security, or to comply with law.

6. Voice dictation and the voice assistant

The console offers two optional voice features: voice dictation, which turns what you say into text in your composer (this section), and a spoken conversation with the platform's assistant (Section 6.1). Each is off unless you use it. Dictation uses the providers this section names; the voice assistant runs on one of two engines — OpenAI's or ElevenLabs' (Section 6.1) — so ElevenLabs may serve both features.

The console's composer offers optional voice dictation. It is off unless you use it: nothing is captured or transmitted until you start dictation, and it stops when you stop it, when a session limit is reached, or when the session ends. Dictation produces text in your composer and never sends a message for you: the text becomes part of your conversation records only if you send it yourself, after editing it as you wish. Two modes are offered; in the first you also choose the transcription engine:

After you stop. Your browser records the audio and uploads it to RunMyB, over an encrypted connection, while you speak. When you stop, the platform sends the recording to the engine you selected — ElevenLabs (Eleven Labs Inc., its Scribe speech-to-text service) or Microsoft's MAI-Transcribe model, reached through OpenRouter, Inc. (for that engine the platform first converts the recording to an audio format the model accepts) — and places the returned text in your composer. The platform holds the recording only until it is transcribed, plus a short retry window measured in minutes, so that a failed transcription can be retried, including with the other engine; then it is deleted. The platform keeps no copy of the audio after that.
Live. Your audio is streamed through the platform to ElevenLabs (its Scribe real-time service) as you speak; provisional text appears in your composer and is replaced by the final text when you stop. The platform stores no audio in this mode: the stream passes through it and nothing of it is kept.

In both modes:

ElevenLabs processes your audio as our sub-processor (Section 5.1), under RunMyB's own account and key. For the Microsoft engine the sub-processor is OpenRouter, Inc. (Section 5.1), under RunMyB's own account and key; OpenRouter routes your recording to Microsoft as its own provider, and RunMyB holds no account and no contract with Microsoft. No provider key ever reaches your browser, and the audio leaves the platform only through the platform's enforced connection to the API endpoint of the provider you chose. Which providers receive your audio depends only on the mode and engine you chose;
what each provider does with the audio, as its own published terms state it. ElevenLabs' published terms allow ElevenLabs to use content submitted to its service to improve its models unless the account holder opts out of that use; RunMyB's ElevenLabs account is set to opt out, and the processing of your audio by ElevenLabs is governed by ElevenLabs' Data Processing Addendum. If you have reason to believe that statement is not true, tell us through the privacy route in Section 9; we will verify the setting and answer you. ElevenLabs keeps a history of the requests made under the account under its own terms; "zero retention" is an ElevenLabs feature for its enterprise customers that RunMyB does not have and does not claim. OpenRouter states in its privacy policy that it does not use inputs or outputs for model training and does not keep audio beyond what routing the request needs, except as required for abuse detection, security, billing, or legal compliance. OpenRouter names Microsoft as the provider for that model; Microsoft's published documentation for its speech-to-text service states that for real-time and fast transcription it does not retain or store customer data. RunMyB has no direct contract with Microsoft and relays that documentation as Microsoft publishes it; the commitment RunMyB relies on is OpenRouter's own;
RunMyB itself does not use your voice audio to train any model, does not permit any provider to do so on RunMyB's behalf, and sends your audio to the engine you chose solely to provide the transcription you requested;
your dictation glossary. You may keep a list of terms — names, product names, jargon — that the platform sends with each request, as a recognition hint, to the engine you chose, so that those words come back spelled as you wrote them. You write the list and see it in full; where a venture you work in has brand or product names on record, the platform may offer them as suggestions that you accept or decline — nothing joins the list without your act. The list is stored with your account and deleted with it. Hints influence recognition; they do not guarantee a spelling;
the language you select is a hint about the language you are speaking; dictation does not translate;
no voiceprint, no identification. Voice is never used to identify or authenticate anyone: the platform derives and stores no voiceprint or other biometric template from your audio, and it does not ask either engine to identify or separate speakers;
other people in the room. While a dictation session is open, the microphone captures whatever is audible, and the platform transmits it as described above. You are responsible for what you allow the microphone to capture, including other people's speech;
what remains after a session is the text in your composer and a usage-metering record (the mode, the engine, the audio or session duration, and the derived charge) kept for billing; usage limits apply and are enforced in-product.

6.1 The voice assistant — a spoken conversation with Remi

Beside dictation, the console offers an optional spoken conversation with Remi, the platform's assistant (the "Conversation" entry beside the composer's microphone). It is off unless you open it: nothing is captured or transmitted until you start a voice session, and the session ends when you end it, when it has been idle, when a session or daily limit is reached, or when the connection drops. Remi is an AI system, not a person, and speaks with a synthetic voice (Terms of Service & Acceptable Use, Section 13). In a voice session:

which engine serves your session. Voice sessions run on one of two engines, chosen by the platform's administrators for the whole platform — never by you: OpenAI's speech model, the default, or a pipeline built on ElevenLabs' speech engine and voice. The administrators may choose a different engine for their own sessions than for everyone else's. Where they have chosen ElevenLabs' engine for everyone else's sessions and that engine cannot serve one of those sessions when it starts — for example because ElevenLabs cannot be reached or is not ready on the platform at that moment — the session runs on OpenAI's engine instead. A session keeps the engine it started on until it ends. The bullets below say what happens on each engine; a bullet that names no engine holds on both;
where your voice goes — on the OpenAI engine. Your browser exchanges audio directly with OpenAI (OpenAI OpCo, LLC), whose GPT-Live-1 speech model listens and speaks, over an encrypted connection between your browser and OpenAI that the platform sets up for you under RunMyB's own OpenAI account and key: the platform relays your browser's connection request to OpenAI and hands OpenAI's answer back to your browser, and the key never reaches your browser. OpenAI processes your audio as our sub-processor (Section 5.1);
where your voice goes — on the ElevenLabs engine. Your browser sends your audio directly to ElevenLabs (Eleven Labs Inc.), whose speech engine listens: it transcribes what you say, detects when you have finished speaking, and sends the platform the text — never the audio. The platform sets that connection up for each session under RunMyB's own ElevenLabs account and key: the key never reaches your browser, which receives only an address that opens a connection for that one session and which the platform revokes when the session ends. For every session the platform asks ElevenLabs not to keep a recording of the audio and to keep the conversation's transcript for zero days — the setting ElevenLabs documents as scheduled deletion, without saying how soon after the conversation it runs. On this engine your microphone's audio does not reach the platform. ElevenLabs processes your audio as our sub-processor (Section 5.1);
Remi's voice — on the ElevenLabs engine. The platform writes Remi's replies as text and sends that text to ElevenLabs' voice model, under RunMyB's own account and key, which turns it into Remi's voice. The platform relays the voice to your browser as it plays and does not store it or analyse its sound: the timing of Remi's on-screen face comes from timing information ElevenLabs returns with the voice (which letters sound when) and from how much of the voice has reached your browser. A speech detector runs in your browser, so that Remi pauses when you start speaking over it. It works on your audio inside your browser, and your browser sends the platform signals only — when you start or stop speaking, when Remi paused or resumed, how much of each reply played, and how long Remi took to start answering — never audio;
the copy of the audio that reaches the platform — on the OpenAI engine. The platform holds its own control connection to the same session (next bullet), and over it OpenAI automatically sends the platform a copy of the session's audio: what your microphone sends during the session — whether or not Remi is listening at that moment — and Remi's spoken replies. (When you mute in the console, your browser switches your microphone track off, so nothing you say then leaves your browser.) OpenAI's service sends that copy on its own; it offers no setting that switches it off. The platform receives each fragment of the copy only transiently, in working memory, as it reads that connection, and discards it without it being decoded: it does not analyse, store, log or record the audio, never sends it to your browser or anywhere else, and keeps nothing of it once each fragment has been handled. This is part of operating the voice session you opened, on the same basis as the conversation itself — the contract (Section 2). The platform does not analyse any of the copy today. If it begins to use Remi's own voice — never yours — to time the speech of Remi's on-screen face, it will analyse that voice only in working memory, keep nothing of the audio itself — only the timings derived from it (when Remi's voice is sounding and when each reply begins) — and state that use in this section before it begins; the audio of your microphone will not be decoded or used for it;
what the platform sends and receives as text. On the OpenAI engine, over its own control connection to the same session, the platform sends OpenAI, as text, Remi's instructions; the name your workspace membership shows for you (your display name), handed to Remi as a fact it may use to address you; and the facts Remi speaks about your workspace, the same workspace content the platform's other assistants process; and, besides the audio copy described in the bullet above, it receives the transcripts of what you said and of what Remi said. On the ElevenLabs engine, the platform receives from ElevenLabs the transcript of what you said, and sends ElevenLabs' voice model the text Remi speaks, which may carry your display name and the facts about your workspace that Remi tells you. Remi's instructions go to the AI model that writes Remi's replies, the model that serves the conversation the session belongs to (Section 5.1), and to a second AI model, which the platform configures for the whole platform, that puts the platform's own notes into Remi's words — for example the greeting, a card waiting for your confirmation with the values of the change, a change's result, a fault or the end of the session. That second model receives each note and the conversation's language, and — only for Remi's late reactions (next bullet) — what you said and Remi's last reply; it is reached through OpenRouter, Inc., our sub-processor for AI model routing, under RunMyB's own account and key, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement (Section 5.1). Your display name is handed to that second model, in the greeting's note, as a fact it may use to address you, so it may appear in the text Remi speaks and, as part of Remi's last reply, in what is sent to Jev (next bullet); it is never sent to any provider as a field of its own;
Remi's quick reactions, and whether you were speaking to Remi — on the ElevenLabs engine. For each thing you say, the platform sends a small AI model, Jev: the words ElevenLabs transcribed; Remi's last reply; the conversation's language; whether a change is waiting for your confirmation; and any words set aside in the last few seconds as meant for someone else. Jev judges what kind of thing you said, names the language you are speaking, and judges whether you have finished your thought and whether the words were meant for Remi or for someone else in the room. Depending on a setting the platform's administrators choose, Remi then either says a short reaction from the platform's fixed list at once or, only when its answer is late, a short reaction written for the moment: for that, the words ElevenLabs transcribed, Remi's last reply and the conversation's language are also sent to the second AI model described in the bullet above, through OpenRouter, Inc. under RunMyB's own account and key, with the same routing instruction (Section 5.1) — never while a change is waiting for your confirmation. While a change is waiting for your confirmation, Jev is also asked whether your words agree to it; its answer is recorded only to compare it with the platform's own check, which alone decides. Jev judges from the words alone — never from your voice — and cannot tell who spoke. Jev is reached through OpenRouter, Inc., our sub-processor for AI model routing (Section 5.1), under RunMyB's own account and key, and OpenRouter routes each request to TypeSafe AI, Inc., which serves Jev as OpenRouter's own provider; RunMyB has no account and no contract with TypeSafe. Words Jev is confident were meant for someone else are not stored: they are not shown, not added to the transcript and not answered. The platform holds them in working memory for a few seconds, as context for judging what is said next, and counts them without keeping them. When Jev is unsure, or does not answer in time, the words are treated as meant for Remi;
the language a session starts in. When the platform remembers a language for you (Section 2.6), a voice session starts in it: on the OpenAI engine the platform hands it to Remi, as a short language code, with Remi's instructions, so that Remi greets you in it; on the ElevenLabs engine it is the conversation's language when the session starts, where Remi's voice there offers that language. What you say then updates the remembered language as Section 2.6 states — on the OpenAI engine the platform's own language detector reads the transcript of what you said; on the ElevenLabs engine the language Jev names for it is remembered once it is the same for two things you say in a row;
what RunMyB keeps. The transcript, as ordinary records of the conversation the session belongs to (as if typed; every line of Remi's carries the AI marker, and a line that did not come from the voice session is marked as such). On the ElevenLabs engine, the transcript holds, of what you said, the words judged meant for Remi, as each is judged, and of what Remi said, what was sent to your browser to play, so that a reply you cut short ends in the record about where you stopped hearing it. RunMyB also keeps the cards Remi shows you on screen, and a usage-metering record (when the session started and ended, its duration in seconds, why it ended, which engine served it, and the derived charge — on the ElevenLabs engine also how many characters of text were sent to be spoken, how many reaction requests were made, and the cost the providers reported for those requests and for putting the platform's notes into Remi's words; on either engine also the cost the provider reported for checking your spoken reply to a card — a short request carrying your words to the AI model that serves the conversation (Section 5.1) — when neither an account nor a venture carries that cost; sessions are metered at the rates shown in-product, and usage limits apply and are enforced in-product). No audio is stored: on the OpenAI engine the copy of the session's audio that reaches the platform is discarded without being decoded; on the ElevenLabs engine your audio never reaches the platform, and Remi's voice is relayed to your browser as it plays without being kept;
what OpenAI does with the audio and the transcripts, as its own published terms state it — on the OpenAI engine. OpenAI's services agreement for its API provides that OpenAI will not use customer content to develop or improve its services unless the customer explicitly agrees to that use, and OpenAI states that data sent to its API is not used to train or improve OpenAI models unless the customer opts in; RunMyB has not opted in and will not. OpenAI states that it may retain API inputs and outputs for up to 30 days to provide its services and to identify abuse, after which they are removed from its systems unless it is legally required to retain them or retention is reasonably necessary to protect its services or a third party from harm. OpenAI's session storage — its option to keep a recording of a voice session for later replay — is off for every session the platform opens: it is off by OpenAI's default and the platform does not turn it on. "Zero data retention" is a control OpenAI grants on request for qualifying use cases; RunMyB does not have it and does not claim it. OpenAI's processing of your data is governed by OpenAI's Data Processing Addendum;
what ElevenLabs, OpenRouter and TypeSafe do with it, as their own published terms state it — on the ElevenLabs engine. What Section 6 says of ElevenLabs' published terms holds here too: they allow ElevenLabs to use content submitted to its service to improve its models unless the account holder opts out; RunMyB's ElevenLabs account is set to opt out; and ElevenLabs' processing is governed by its Data Processing Addendum. Besides the settings the platform asks for on each session (above), ElevenLabs keeps a history of the requests made to its voice model under the account — the text Remi spoke — under its own terms, and it keeps listing each conversation of its speech engine — its identifier, when it started and how long it lasted — after the transcript and audio are no longer available. "Zero retention" is an ElevenLabs feature for its enterprise customers that RunMyB does not have and does not claim. OpenRouter's published terms are as Section 2.2 states them. TypeSafe states in its published privacy policy that it does not train or fine-tune any model on the input it receives, that its services are hosted in the United States, and that it keeps data as long as reasonably necessary to provide its services; it offers zero data retention to its enterprise customers only, and RunMyB has no such arrangement. Jev's requests are sent with a routing instruction that allows that one provider only, and only where OpenRouter records it as not using request data for training. If that provider cannot serve, no other provider receives the words, and Remi answers without a quick reaction. RunMyB has no contract with TypeSafe and relays its published terms as TypeSafe publishes them; the commitment RunMyB relies on is OpenRouter's own;
RunMyB itself does not use your voice audio or your voice transcripts to train any model, does not permit any provider to do so on RunMyB's behalf, and engages its voice providers solely to provide the conversation you asked for;
how Remi is identified as an AI. On the OpenAI engine the platform gives Remi no fixed wording to speak. On the ElevenLabs engine, Remi's short reactions — acknowledgements, greetings, goodbyes — and the short lines it says during a longer wait are chosen from a fixed list the platform writes and translates or, where the platform's administrators have chosen late reactions, written for the moment by an AI model; neither states an outcome; when the platform's report of what has happened is not put into words in time, Remi may say a line from the same list instead — that something went wrong and you may ask again, that the answer or its details are on your screen, or that the card on your screen is waiting for your tap. No line on that list carries a number or a name, and everything else Remi says is written for the moment by an AI model. On either engine the identification does not depend on a recited sentence. It rests on where and how you meet Remi: a voice session exists only because you opened it, from the console's Conversation entry offering a spoken conversation with the platform's assistant; on screen, every line of Remi's in the transcript carries the AI marker throughout the session; and this section and Section 13 of the Terms of Service & Acceptable Use state that Remi is an AI system, not a person, speaking with a synthetic voice — and that its output may be inaccurate and is worth checking on screen;
Remi changes nothing by itself. Every change Remi proposes is shown as a card on screen, and by default it runs only when you tap to confirm it. You may turn on voice confirmation in your settings — your own choice, off unless you turn it on, remembered until you turn it off, and made known to Remi at the start of a session when it is on, so that Remi can tell you. With it on, a spoken confirmation runs the change — including a change that spends credits — only after the change that will run has been put to you (on the card on screen, and handed to Remi to state in speech) and a short veto window has passed; at any point in that window, saying that you want it stopped — in any words, in any language — or tapping Cancel on the card stops it. Decisions on the platform's own approval gates are never taken from voice: Remi shows the card, and you tap;
other people in the room. While a voice session is open, the microphone captures whatever is audible. On the OpenAI engine it travels to OpenAI, and OpenAI's copy of it reaches the platform, as described above. On the ElevenLabs engine it travels to ElevenLabs, which transcribes it, and the transcribed words go to Jev, as described above; words Jev is confident were meant for someone else are not stored, but Jev judges from the words alone, so words that someone else says to Remi are treated as yours. On either engine nothing in the transcript distinguishes your voice from anyone else's the microphone picks up. You are responsible for what you allow the microphone to capture, including other people's speech — and, if you have turned voice confirmation on, for a confirmation spoken within the microphone's range;
no voiceprint, no identification. As in dictation, voice is never used to identify or authenticate anyone: the platform derives and stores no voiceprint or other biometric template, and it does not ask OpenAI or ElevenLabs to identify or separate speakers; on the ElevenLabs engine, whether words were meant for Remi is judged from their text, never from the voice.

7. International transfers

Some recipients process personal data in the United States; DeepSeek, the provider preferred for the build roles while their exception ran, from 2026-09-15 until 2026-10-18 (the OpenRouter row in Section 5.1), states in its published privacy policy that it stores data in the People's Republic of China. For personal data subject to the GDPR, the UK GDPR, or the Swiss FADP, transfers are protected as follows:

Transfers to AWS, Stripe, Cloudflare, and ElevenLabs rest on those providers' certifications under the EU–US Data Privacy Framework (with its UK and Swiss extensions), with the Standard Contractual Clauses in each provider's terms as the contractual fallback. ElevenLabs publishes hosting locations in the United States, the Netherlands, and Singapore; where it processes dictation audio, or a voice session's audio and the text of Remi's replies, outside the United States, the transfer rests on the Standard Contractual Clauses incorporated in ElevenLabs' Data Processing Addendum (with the UK Addendum where it applies).
Transfers to Anthropic, OpenRouter, OpenAI, Neon, and Zoho rest on the 2021 EU Standard Contractual Clauses (with the UK Addendum and Swiss amendments where those regimes apply) incorporated in those providers' data-protection terms. (Neon hosts each hosted product's database in a US region; Zoho hosts the platform's mailboxes in an EU data centre and the Clauses cover any extra-EEA access. For OpenAI, the Clauses — Modules Two and Three, with the UK Addendum — are incorporated in OpenAI's Data Processing Addendum, which OpenAI's API terms apply to every API customer; OpenAI is not a participant in the EU–US Data Privacy Framework, so no transfer to it rests on that framework. For OpenRouter, the Clauses — Module Two, with the UK Addendum and the Swiss amendments — are incorporated in OpenRouter's Data Processing Agreement, which OpenRouter's Terms of Service incorporate by reference for organisations and for commercial use of its service; OpenRouter is not a participant in the EU–US Data Privacy Framework, so no transfer to it rests on that framework.) Dictation audio that OpenRouter routes to Microsoft's MAI-Transcribe model (Section 6) is an onward transfer under OpenRouter's terms; Microsoft Corporation is itself certified under the EU–US Data Privacy Framework. The activity narrator's and the avatar director's requests, and the requests of the platform's automated content-safety checks, that OpenRouter routes to Google's Gemini model (Sections 2.2, 2.3 and 9) are likewise an onward transfer under OpenRouter's terms; Google LLC is itself certified under the EU–US Data Privacy Framework, with its UK and Swiss extensions, and the Standard Contractual Clauses named in Google's published data-processing terms are the contractual fallback. Jev's requests on the voice assistant's ElevenLabs engine, which OpenRouter routes to TypeSafe AI, Inc. (Section 6.1), are likewise an onward transfer under OpenRouter's terms with TypeSafe, which RunMyB does not hold; TypeSafe states that its services are hosted in the United States, and its published Data Processing Addendum incorporates the Standard Contractual Clauses (Module Two, and Module Three where its customer acts as a processor) with the UK Addendum; TypeSafe AI, Inc. is not a participant in the EU–US Data Privacy Framework, so no part of that transfer rests on it. The avatar author's requests, and the requests that put the voice assistant's notes into Remi's words, that OpenRouter routes to OpenAI's model (Sections 2.4 and 6.1) are likewise an onward transfer under OpenRouter's terms with OpenAI, which RunMyB does not hold; OpenAI states that its Data Processing Addendum, which incorporates the Standard Contractual Clauses, applies to every customer of its API — on this route, OpenRouter — and, as stated above, OpenAI is not a participant in the EU–US Data Privacy Framework, so no part of that transfer rests on it. Where OpenRouter routes such a request to Microsoft's Azure service or to Amazon Web Services' Amazon Bedrock service instead (Sections 2.4 and 6.1), that too is an onward transfer under OpenRouter's terms with that provider, which RunMyB does not hold; Microsoft Corporation, as stated above, is itself certified under the EU–US Data Privacy Framework, and Amazon Web Services, Inc. is covered by the certification of Amazon.com, Inc. under that framework. The requests of the check of the photos you add to your apps (Section 2.8) that OpenRouter routes to Microsoft's Azure service — in the European Union where the platform names Azure's endpoint there, and otherwise wherever Azure serves them, which may be the United States — or to Deep Infra Inc. are likewise an onward transfer under OpenRouter's terms with that provider, which RunMyB does not hold and which the Clauses incorporated in OpenRouter's Data Processing Agreement (Module Two, Clause 9) oblige OpenRouter to make under equivalent protections; Microsoft Corporation, as stated above, is itself certified under the EU–US Data Privacy Framework, and Deep Infra Inc., headquartered in the United States as OpenRouter records it, is not a participant, so no part of the transfer to it rests on that framework. Every other request that OpenRouter routes for a platform role or for a conversation (Section 5.1) is likewise an onward transfer under OpenRouter's terms with the provider that serves it, which RunMyB does not hold; where that provider is Anthropic PBC, OpenAI, Microsoft Corporation, Amazon Web Services, Inc. or Google LLC, what is stated above for that provider applies to it. The requests that OpenRouter routes to SpaceXAI's Grok model, which platform roles, among them the general worker and the development executor, may be configured to (Section 5.1), are such an onward transfer, under OpenRouter's terms with SpaceXAI LLC, which RunMyB does not hold; SpaceXAI states that it may process personal data on a global basis, including in the United States, and its published Data Processing Addendum incorporates the Standard Contractual Clauses (Module Two, or Module Three where its customer acts as a processor) with the UK Addendum and the Swiss amendments; SpaceXAI LLC is not a participant in the EU–US Data Privacy Framework, so no part of that transfer rests on it. The requests that OpenRouter routes to DeepSeek's model (Section 5.1), those that carry Google user data included, which are never routed to DeepSeek's own service (Section 5.3), are likewise an onward transfer under OpenRouter's terms with the provider that serves them, which RunMyB does not hold — a provider of that model that OpenRouter chooses among those whose published data policy, as OpenRouter records it, does not use request data for training, headquartered where OpenRouter records it, in the United States for Deep Infra Inc. and Parasail, Inc., for example; RunMyB claims no certification under the EU–US Data Privacy Framework for any provider so chosen (neither Deep Infra Inc. nor Parasail, Inc. is a participant), so no part of that transfer rests on it. From 2026-09-15 until 2026-10-18, the build agents' requests left RunMyB for OpenRouter under OpenRouter's Standard Contractual Clauses, and the onward leg from OpenRouter to the provider that served them — DeepSeek, preferred, or another of OpenRouter's providers for the model — was governed by OpenRouter's terms with that provider, which RunMyB does not hold; DeepSeek states in its published privacy policy that it stores data in the People's Republic of China and names no transfer instrument there, and the EU–US Data Privacy Framework is open to United States organisations only, so no transfer to DeepSeek rested on it.
Where RunMyB processes personal data on your behalf, the Standard Contractual Clauses, Modules Two and Three, are incorporated through the Data Processing Addendum.

Data you send to a connected service under your own authorization (Section 5.2) is transferred under your own relationship with that provider, governed by its terms.

8. Retention

We keep personal data only as long as needed for its purpose, then delete or pseudonymise it. The criteria that determine the period, per category:

Account, workspace, and content data — kept for the life of the account; on account deletion it is erased through the tiered erasure described in Section 9, subject only to the retention carve-outs below.
Data-export bundles — the bundle the platform prepares when you request your data (Section 9) or self-export (Section 3.2) is kept for 7 days after it is prepared, the window in which you can download it, then deleted; every bundle of an account is deleted when the account is erased. The record that the request was made and answered is kept as the platform's compliance evidence for the limitation period.
Billing, ledger, and acceptance records — retained after account deletion for the statutory accounting and limitation periods that apply to the record (where Polish accounting law applies, the accounting retention period it fixes), in pseudonymised form where possible, then deleted.
Affirmations — the affirmations you make when you name a reference, import code, import a brand or add photos to an app (Sections 2.5 and 2.8; Terms of Service & Acceptable Use, Sections 10.4, 10.5 and 12.3) are append-only records, kept as they are, as the platform's evidence of what was affirmed, for the limitation period that applies to them — also after the reference, the photos, the app, the venture or the account is erased — then deleted.
The record of where Google user data is, and of the requests sent for it — the record that content from your Google connections has entered your account or a conversation, venture or run (Section 2) is kept until the account is erased, a venture's own record being deleted also when that venture is erased; the audit record of each request the platform's model gateway composes for such a conversation, venture or run, naming the model and the provider that served it (Section 5.3), is kept until the account is erased, also after the conversation, venture or run it names has been erased. Neither record holds the content itself.
Security and operational logs — kept for a bounded operational window sized to the security and debugging purpose they serve, then deleted or aggregated.
E-mail sending limits — the daily counts of the address-verification and password-reset messages, and of an application's own messages, sent to an address (Section 2) are kept for the day they count and the following day, then deleted; the record that an address was paused after repeated bounces, which names no account and is not deleted with one, is kept for 13 months, then deleted; the record of each time an application's own messages were switched off or back on is kept for as long as the platform operates, also after the application or the account is erased, as the platform's evidence of those decisions.
Confirmed and unsubscribed addresses — the record of the addresses confirmed for, or unsubscribed from, an application (Section 2) is kept for as long as the application exists, and is deleted when the application is erased or the account it belongs to is erased.
Messages to the applications hosted on the platform — each message written to an application through its contact form, with the name and the reply address given with it, and each e-mail delivered to an application's own address, with what the platform keeps of it and the files it keeps from it (Section 2), is deleted after 90 days from its arrival, and sooner when a member of the application's account deletes it or the application or the account is erased; the record of each time an application's inbox was switched off or on is kept for as long as the application exists and is deleted with it or with the account; the count by reply address is kept for the day it counts and the following day, then deleted, and so is the count by the address an e-mail came from; an e-mail as it was received is kept only until the platform has delivered it or counted it as not delivered, and is deleted within minutes of that.
Notices by e-mail — the record of each notice the platform e-mails (Section 2) is kept for 30 days after the notice was sent, skipped or failed, then deleted; the records of an account's notices are deleted when the account is erased, if they have not been already. The records of RunMyB's notices about the service itself concern no one account, so they are not deleted with one: they too are deleted 30 days after the notice was sent, skipped or failed.
Notification choices — each choice you make about which notices you receive (Section 2) is kept for as long as the account exists, the latest being the setting in force, and is deleted when the account is erased.
E-mail delivery records — the delivery events the mail provider reports for a message, with the recipient's address, are kept for 30 days, then deleted; the platform's own record of each message and of what became of it, and its record of the messages it refused to send, which identify the recipient only by a hash, are kept for 13 months, also after the application or the account they concern is erased, then deleted; an address on the suppression list is kept for as long as it stays suppressed — also after the account is erased — so that no further e-mail is sent to it.
What became of an e-mail, in the console — the count of the look-ups of an address that a member of an account makes in the console (Section 2) is kept for the day it counts and the following day, then deleted, and sooner when the account is erased.
Waitlist records — kept until the signup is invited (the record then follows the life of the account the invitation led to) or until the subject asks to come off the list, whichever comes first (Section 2.1).
Visit records and statistics — the load balancer's request logs (also security and operational logs, above) and the beacon's records of visits (Section 4) are kept for up to 30 days, then deleted; the aggregate statistics counted from them identify no visitor and are kept for as long as they are useful.
Dictation audio — in the after-you-stop mode, held only until transcribed plus a short retry window measured in minutes, then deleted; in the live mode, never stored (Section 6). The transcribed text follows the conversation it is sent into, or is discarded with the composer if it is not sent.
Dictation glossary — kept for the life of the account and deleted with it (Section 6).
Voice-assistant sessions — no audio, ever: on the OpenAI engine the copy of the session's audio that OpenAI sends the platform is discarded without being decoded as it arrives; on the ElevenLabs engine your audio never reaches the platform, and Remi's voice is relayed to your browser as it plays without being kept; words judged meant for someone else in the room are not stored (Section 6.1). The transcript and the on-screen cards follow the conversation they belong to (account, workspace, and content data above); the session's metering record (times, duration, stop reason, the engine, the derived charge and the counts it is priced on) is kept with the billing records.
Activity-narrator journal — the entries, the narrator's working state and the history of its earlier notes and finished items for a venture are kept for the life of the venture and deleted with it (Section 2.2) — and earlier, when any of the venture's products is erased: the working state and the history whole, and the entries that record that product or work on it; while the narrator is switched off for a venture they are retained, not deleted.
The avatar's learned actions — kept until a member of the account drops an action, the platform discards it because it no longer passes the platform's checks, or the account is erased, whichever comes first (Section 2.3).
Chosen avatars — a member's chosen avatar, and the character chosen for each of the account's agents, are kept until changed — choosing another character replaces the record, and changing back to the default deletes it — or until the account is erased (Section 3.1); a disabled member's choice is retained but no longer shown (Section 3.4).
Avatars members create — the avatar a member uses is kept until the member replaces or deletes it, or until the account is erased; using a new drawing deletes the previous avatar and every drawing not used, and a drawing not used is deleted when the member creates again once it is more than a day old, no more than ten being kept (Section 2.4). A disabled member's avatar is retained but no longer shown (Section 3.4).
Field-survey captures and studies — the captured pages' text and screenshots and the comparison a study writes are kept for the life of the venture and deleted with it; public reviews are kept only as the study's own summaries (Section 2.5).
Remembered language — kept for the life of the account and deleted when the account is erased; a departed member's is retained under the account (Sections 2.6 and 3.4).
The Ideas stream's records — the record of the ideas a person was shown, reacted to and launched, the areas and the line about themselves they chose, and the ideas written for them or from the account's ventures, are kept for the life of the account and deleted when the account is erased; Reset deletes a person's areas, line and that record at any time; a departed member's are retained under the account (Sections 2.7 and 3.4).
The platform's catalogue of ideas — the ideas written for everyone, and the starting set, are kept as the platform's own content for as long as the platform offers ideas; a retired idea stays in the catalogue, marked as retired, as the record of what was offered and so that it is not written again; a person named in an idea may object as Section 2.7 states (Sections 2.7 and 9).
Photos you add to your apps — the prepared copies of each photo, its description and the record of who confirmed it are kept with the app, until you remove the photo or the app is erased; the original file is kept only until the check for prohibited content has passed the photo, or, for a photo it holds, for as long as the hold lasts, and a file in which the scan found malicious software is kept as it is until you remove it or the app is erased. The record of the check of a photo it passed is kept as long as the photo and deleted with it; the record of the checks of any other photo, and of what RunMyB decided about it, is kept with the app, until the app is erased, or for longer where the law requires RunMyB to preserve it. A photo that is with a person at RunMyB, and a photo RunMyB holds because of a notice or because the law requires it to preserve it, is kept until RunMyB decides on it, and for as long as the law requires; the app and the account cannot be erased while it is. A photo you remove is deleted from the platform's store of photos at once and leaves your app at its next update. The earlier versions of your app that the platform keeps, and its copy of your app's code history, keep it until the app is erased, unless a person shown in it asks to have it erased and you instruct RunMyB to erase it: RunMyB then removes it from them. The platform's storage backups keep a copy for 35 days (Section 2.8). Your confirmation that you may use the photos is kept as the affirmations above are.
Content-safety records — the record of each automated safety check (Section 9), including the text it checked, bounded in length, is kept as the platform's evidence of its safety decisions for the limitation period that applies to them; it is not deleted when the account is erased. The records of the check of the photos you add to your apps are kept as the bullet above states instead.
Publication records — the public address a product was published at, the state of its publication and the decision of the check on that address (Section 9) are kept after the publication ends and after the account is erased, so that an address that once served one account cannot be claimed by another; who requested the publication is kept with them (Section 9). The record of who later unpublished or released it, or turned its demo notice on or off, and when — for a removal of the demo notice by the product's owner, with a record of the confirmation they gave (Terms of Service & Acceptable Use, Section 15) — is kept as the platform's evidence of those changes for the limitation period that applies to it, also after the account is erased, then deleted.

The full, per-store retention schedule is maintained internally as the platform's data map, which also drives the erasure machinery (Section 9); the criteria above are the rules that schedule implements.

9. Your rights

You have the rights of access, rectification, erasure, restriction, portability, and objection, and the right not to be subject to solely-automated decisions with legal effect. To exercise them, use the in-platform data-request flow (the primary mechanism — it records your request and tracks it against the statutory 30-day response clock) or e-mail privacy@runmyb.com. Data exports are produced as structured bundles you download yourself, with a manifest that lists every store the platform keeps and, for each store a bundle does not include, why; a team member can additionally self-export the data held about them personally (Section 3.2). Erasure is a tiered operation: content is hard-deleted, while the narrow set of records the law requires us to keep (billing, ledger, and acceptance evidence) is pseudonymised and retained for the legally required window, then deleted; the affirmations you make when you name a reference, import code, import a brand or add photos to an app are retained as they are, as the platform's evidence of what was affirmed, for the period Section 8 states; the records of the platform's automated safety checks are retained as they are, as the platform's evidence of those decisions, for the period Section 8 states. The publication records Section 8 names — the address, the state of the publication, the check's decision, and who requested, unpublished or released it or turned its demo notice on or off, and when — are retained as Section 8 states. The platform's records of the e-mail it sent and of the e-mail it refused to send, which identify each recipient only by a hash, are retained as they are, as the platform's evidence of its e-mail and of what became of it, for the period Section 8 states.

Automated checks, disclosed. The platform runs automated safety checks: every build request is screened against the content-safety taxonomy (the "Platform Rules — Content-Safety Taxonomy") before any app is built, and imported content passes an automated admission check that can hold an item from the shared library pending review. A hold routes to human review — it is a fail-safe, not a final decision — and you may contest safety decisions through the appeal route in the Terms of Service & Acceptable Use, Section 7. A description you write to create your own avatar, and a change you ask for to it, are screened the same way before anything is sent to be drawn (Section 2.4): one that falls under the prohibited or restricted categories is refused, with the reason and the appeal route, and nothing is drawn; one the check flags as needing review is drawn, and the flag is recorded for the platform's review. Each check is itself made by an AI model reached through OpenRouter, Inc., our sub-processor for AI model routing (Section 5.1), under RunMyB's own account and key. The check's request carries the text it checks — the build request with the names of any attached files, the imported content, or the description or change you wrote — together with the platform's instructions for the check; your name, your e-mail address and the account's identifiers are not sent with it. OpenRouter routes it to the provider of the model the platform has configured for the checks — today Google LLC, whose Gemini model serves the checks as OpenRouter's own provider; RunMyB has no contract with Google for this, and RunMyB relays nothing from Google's terms for this route beyond the transfer basis Section 7 states; OpenRouter's own published terms are as Section 2.2 states them. The request carries a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place: if that provider cannot serve, no other provider receives the text and the check is treated as one needing review. The record of every check — refused, flagged or clear — keeps the text it checked, bounded in length (the whole of an avatar description, which is short), with the decision. That record is for the platform's operating team: it is not shown in the console, it is part of the account's data export, which is an administrator's (Section 3.2), and it is kept as Section 8 states. The platform's automated checks also screen a public web address you choose when you ask to publish a product, before that address is reserved for it: that check's request, sent through OpenRouter in the same way and under the same routing instruction, carries the address and, if you gave one, your own description of what the product is, with the platform's instructions for the check; an address it finds to impersonate a brand, an institution or an authority is refused, with the reason (the appeal route above applies); any other doubt it raises goes to RunMyB's human go-live review, which decides whether the product goes public; and the address and the check's decision are kept with the publication request rather than in the record described above (Section 8 states how long) — your description is not kept by this check. The go-live review's own automated leg reads, for the product submitted, its name, type and intended audience, the public address you asked for it and whether you had previewed it, the description of what it is that you gave when asking to publish it, your own words recorded as what the product should be, its specification, a summary of its accepted build and of the platform's checks of it, the file names of its bundle and the bounded texts that the venture's most recent automated checks recorded — which may include content you imported — through the same route and under the same routing instruction. Separately from those checks, each photo you add to an app is scanned for malicious software by Amazon GuardDuty, on the platform's own storage on Amazon Web Services, before anything else reads it (Section 2.8): a file in which the scan finds such software is not used or shown, and the console tells you so, that the decision was made automatically, and how to contest it through the appeal route above. Each photo is then checked by an AI classifier, before your app may use it, for sexually explicit content, any sexual depiction of a person who may be a minor, and graphic violence, through OpenRouter under the routing instruction Section 2.8 states. That check is an automated assessment of what the photo shows, including whether a person in it may be a minor and whether it is sexual; it decides only whether the photo may be used in your app, and no decision about the people it shows follows from it. A photo it holds is kept, never deleted by the check, and the console tells you on the photo what was found, that the decision was made automatically, and how to contest it through the appeal route above, which a person at RunMyB decides — never the automated check.

The scan of the files your apps keep. Every file an app hosted on the platform stores for its users is scanned for malicious software by Amazon GuardDuty, in the platform's own storage on Amazon Web Services in the United States, soon after it is stored; GuardDuty deletes its copy once the scan is done, and RunMyB lets Amazon Web Services keep or use none of the files it scans for a purpose of its own. GuardDuty's record of a file it finds malicious — which file, and what it found — is one of the platform's security records (Section 8). A file in which the scan finds such software is withheld automatically — kept, not deleted, and no longer served — and the account's administrators are e-mailed, unless the law requires, or a public authority asks, RunMyB to delay it, the reasons and how to contest the decision through the appeal route above, which a person at RunMyB decides, never the scan (Terms of Service & Acceptable Use, Section 15, item 8). The scan looks only for malicious software: it identifies no one, and it decides only whether a file may be served. For these files RunMyB is the processor of the app's owner (Section 1), and the Data Processing Addendum states what is kept.

10. Complaints

If you believe your data is processed unlawfully, you may lodge a complaint with the Polish data protection authority, the President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warsaw, or with your local supervisory authority.

11. US residents

We do not sell personal data, and we do not share it for cross-context behavioural advertising, as those terms are defined in US state privacy laws (including the California Consumer Privacy Act as amended). Stated honestly: RunMyB currently falls below the applicability thresholds of those laws, so most of their specific mechanics do not yet apply to it — but the no-sale, no-share posture is our commitment regardless of thresholds, and if the platform grows into those laws' scope, this Policy will be updated with the notices and rights they require.

12. Changes

This Policy evolves with the platform, under the same change process as the Terms of Service & Acceptable Use: a material change requires your renewed acceptance before you continue using the console; a non-material change takes effect on posting, with the version number, effective date, and changelog as the notice, and you are invited to review them. Every version is dated, versioned, and kept in the changelog.

Version history (the document's changelog)

1.0 — initial draft edition. 1.1 — named privacy@runmyb.com as the data-rights e-mail channel beside the in-platform flow; non-material clarification (0418). 2.0 — final edition: RunMyB, Inc. named as controller; the team-member category folded in (controller/processor split, member data inventory, member self-export, departed-member posture); recipients rebuilt as sub-processors versus connected services you authorize (git providers, Google Drive/Gmail/Calendar with the Google Limited-Use commitments, Trello, Notion, AI providers under your own keys); the voice-dictation disclosure added; definitive per-recipient international-transfer mechanisms (DPF/SCCs); operational values stated by reference to the in-product surfaces where they are shown (0529). 3.0 — MATERIAL: the statistics posture (Section 4) widened to name the cookieless first-party beacon in hosted product pages — what it reads (the visited page's address, the referring page, the visit itself), what it never does (no cookies, no local storage, no fingerprinting, no cross-site tracking), the daily-salted server-side visitor hash with raw identifiers discarded immediately, aggregates-only retention, and the per-product opt-out (0537). 3.1 — disclosures and clarifications (NON-MATERIAL; effective on posting): Neon, Inc. added to the sub-processor table (Section 5.1) and the transfer mechanisms (Section 7) — this corrects an omission: the vendor was already in use for hosted-product databases and should have been listed when that feature went live; the aggregate-statistics processing gains its stated legal basis (legitimate interest) and its stated controller hat (Section 2 and Section 4); the retention criteria are now stated per category in the notice itself (Section 8); Section 3.1 discloses that the platform itself e-mails the invitee; the automated safety checks are disclosed as existing, with the human-review posture (Section 9); a US-residents statement added (Section 11). 3.2 — disclosures (NON-MATERIAL; effective on posting): the pre-launch waitlist section added (Section 2.1) — what a signup stores and the checkable negatives (no IP, no user-agent, no name, no free text), the correspondence purpose stated to include the screening questions asked before an access decision, consent as the basis with the stored consent-wording version as the evidence and the wording itself preserved verbatim in the section, retention (until invited or until the subject asks off the list), and the manual privacy@runmyb.com rights route for pre-invite records; a matching retention bullet in Section 8; the frontmatter gains waitlist_consent_version, minting the consent-wording version this document preserves. 3.3 — the voice-dictation providers replaced (NON-MATERIAL; effective on posting; the sub-processor replacement itself is recorded under the Data Processing Addendum's Section 4 mechanism — its changelog entry 2.2, which also records that the Section 4 notice period and objection window were waived for this change on 2026-09-11 by the platform's sole Customer): Google LLC removed from the sub-processor table (Section 5.1) and the transfer mechanisms (Section 7) — the Google-based relay is retired; ElevenLabs (Eleven Labs Inc.) added as the speech-to-text provider; OpenRouter, Inc.'s function widened to route dictation audio to Microsoft's MAI-Transcribe model, with OpenRouter as the sub-processor for that engine and Microsoft named as OpenRouter's own provider (RunMyB has no contract with Microsoft); Section 7 names the Standard Contractual Clauses in ElevenLabs' Data Processing Addendum as the basis for any ElevenLabs processing outside the United States; Section 6 rewritten for the two dictation modes (after-you-stop with a choice of engine, and live), stating per provider what that provider's own published terms say about training and retention rather than one promise for all, the platform's own transient holding of after-you-stop recordings until transcribed plus a short retry window, the live mode's no-storage posture, the user-controlled dictation glossary sent as a recognition hint, the no-voiceprint/no-identification statement, the responsibility for other people the microphone captures, that dictation never sends a message by itself, and that the language selector is a spoken-language hint (no translation); Section 8 gains the dictation-audio and dictation-glossary retention bullets. 3.4 — the voice assistant added (NON-MATERIAL; effective on posting; the sub-processor addition itself is recorded under the Data Processing Addendum's Section 4 mechanism — its changelog entry 2.3, which also records that the Section 4 notice period and objection window were waived for this change on 2026-09-12 by the platform's sole Customer): OpenAI (OpenAI OpCo, LLC) added to the sub-processor table (Section 5.1) as the speech model behind the optional spoken conversation with the platform's assistant, engaged only when the user opens a voice session, with the audio exchanged directly between the user's browser and OpenAI under RunMyB's own account and key and never passing through the platform; Section 6 extended with a voice-assistant sub-section (6.1) stating what is transmitted and to whom, what the platform keeps (the transcript as conversation records, the on-screen cards, a metering record — no audio), what OpenAI's own published terms say about training and retention (no training on API content unless the customer opts in, which RunMyB has not; abuse-monitoring retention of up to 30 days as OpenAI publishes it; OpenAI's session storage switched off; zero data retention not held and not claimed), the spoken AI disclosure at the start of every session and on request, that the assistant changes nothing by itself (a tap confirms by default; voice confirmation is the user's own remembered setting, off unless turned on; gate decisions never from voice), the responsibility for other people the microphone captures, no voiceprint and no identification, and per-second metering at the in-product rate; Section 7 adds OpenAI to the Standard-Contractual-Clauses group (OpenAI is not a Data Privacy Framework participant); Section 8 gains the voice-assistant retention bullet. Adding a sub-processor for an optional feature the user opts into, with the feature's protections disclosed, reduces no right and adds no obligation. 4.0 — the spoken AI disclosure withdrawn (MATERIAL under the Terms' Section 24 — withdrawing a stated in-product restatement is none of the non-material kinds, so the re-consent gate fires): the platform no longer gives Remi any fixed wording to speak — Remi is told what happened, never what to say — so Section 6.1 no longer states that Remi says at the start of every session, or when asked, that it is an AI, and the record of the moment such a disclosure was spoken is removed both from the what-RunMyB-keeps list and from the platform's session data. What identifies Remi as an AI for a voice user is stated in its place: the session exists only because the user opened it, from the console's Conversation entry offering a spoken conversation with the platform's assistant; every line of Remi's in the on-screen transcript carries the AI marker; and Section 6.1 and Terms Section 13 state that Remi is an AI system, not a person, with a synthetic voice. Two corrections travel with it: the name sent so that Remi can address the user is the workspace membership display name (which may be more than a first name), handed as a fact Remi may use (a clarification of what was always sent); and the voice-confirmation description no longer promises a fixed announcement or a fixed veto word — when the setting is on, Remi is told so at session start so it can tell the user, and during the pre-run veto window any spoken words calling the change off, in any language, or a tap on Cancel, stop it (a clarification in the user's favour: the veto was never limited to one word). 5.0 — two disclosures and one narrowed commitment (MATERIAL under the Terms' Section 24: part (2) below narrows a protection you had, so the re-consent gate fires and renewed acceptance is required; effective 2026-09-17; both parts are recorded under the Data Processing Addendum's Section 4 mechanism — its changelog entry 2.4, which also records that the Section 4 notice period and objection window were waived for this posting on 2026-09-17 by the platform's sole Customer). Part (1), the activity narrator — a disclosure and a sub-processor function widening, which on its own would be non-material: a new Section 2.2 describes the activity narrator — a running written account of a venture's work, composed by the platform for the venture's owner from the venture's own records, on for every venture unless a member turns it off on the venture's Modules card — stating what it is composed from, what leaves the platform for each entry (a digest of those records cleaned by shape before sending — web addresses, identifiers and hashes, dollar figures and qualified model names removed, file paths shortened to their last parts, money, model, identifier and token-count fields dropped from structured records, every text field bounded — with the stated limit that a name, an address or a secret typed into a message is not recognised by those checks; and bounded, cleaned excerpts of the venture's conversations with the assistant — the messages of the owner and of other members of the account alike, and the assistant's replies — never a whole conversation), to whom (OpenRouter, Inc., which routes it to the provider of the configured model — Google LLC today, as OpenRouter's own provider; RunMyB has no account and no contract with Google for it), what the providers' own published terms say about training and retention, that RunMyB's OpenRouter account permits routing to providers whose terms allow the use of request data for model improvement (a setting kept for other platform roles) while the narrator's requests carry a routing instruction that excludes such providers, so that only a provider whose published policy states that request data is not used for training may serve them, RunMyB's own no-training commitment restated, what the platform keeps (the entries and the narrator's working state, for the life of the venture, deleted with it, part of the data export, retained while the module is off), and that the account is informational — nothing in it acts on the owner's behalf; a matching bullet in Section 2; a sentence in Section 3.3 that a member's turns in a shared venture conversation may leave for the narrator's model as Section 2.2 describes; the OpenRouter row in Section 5.1 widened to name the model's provider for the engine tasks OpenRouter routes — Google LLC for the narrator, named as Microsoft is for dictation; Section 7 states the narrator's onward transfer to Google under OpenRouter's terms, Google LLC's Data Privacy Framework certification and the Standard Contractual Clauses in Google's published terms as the fallback; Section 8 gains the activity-narrator retention bullet. Part (2), the build roles' provider — the part that makes this edition MATERIAL: Section 5.1's OpenRouter row states that for the build roles (build-ui and build-core) OpenRouter routes each request to a provider of the configured model, preferring DeepSeek's own first-party endpoint (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.), whose published privacy policy states that it uses the personal data it collects to train and improve its models, and that where that endpoint cannot serve another of OpenRouter's providers for the model may serve the request — a provider RunMyB does not name in advance — with RunMyB's OpenRouter account set to permit routing to providers whose terms allow the use of request data for model improvement; the Anthropic PBC row is corrected to the roles configured to use it; Section 2 points at Section 5.1 for the providers of workspace content and at the Data Processing Addendum's Section 7 for the exception; Section 7 states what is held for the build agents' requests (RunMyB's transfer to OpenRouter under OpenRouter's Standard Contractual Clauses; the onward leg under OpenRouter's terms with its provider, which RunMyB does not hold; DeepSeek's stated storage in the People's Republic of China with no transfer instrument named; the Data Privacy Framework open to US organisations only) and names the People's Republic of China among the processing locations; and the Data Processing Addendum's Section 7 no-training commitment is narrowed by an express exception for the build roles, stating how the routing may be ended (no per-venture switch exists; the account's Models card, or a written instruction to RunMyB). Narrowing that commitment reduces a protection the Customer had — hence MATERIAL and renewed acceptance; part (1) alone would have been 4.1. 5.1 — NON-MATERIAL clarification (effective on posting, 2026-09-17): Section 7 names the instrument for the transfer to OpenRouter — OpenRouter's Data Processing Agreement, which OpenRouter's Terms of Service incorporate by reference for organisations and for commercial use of its service and which incorporates the 2021 Standard Contractual Clauses (Module Two, with the UK Addendum and the Swiss amendments) — and states that OpenRouter is not a participant in the EU–US Data Privacy Framework (the public registry, read 2026-09-17). No recipient, purpose, retention or processing changes; the basis 5.0 stated (the Clauses incorporated in the provider's data-protection terms) is unchanged and now named. 5.2 — a correction (NON-MATERIAL under the Terms' Section 24: a disclosure of what was already true, a clarification, and a new restriction on RunMyB; effective on posting, 2026-09-26; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 is not engaged — its changelog entry 2.6 makes the matching correction): Sections 5.1, 6.1 and 8 said that during a voice session no audio passes through the platform and that the platform never holds or receives it. That was inaccurate from the edition that added the voice assistant (3.4) on: OpenAI's service automatically sends the platform, over the platform's own control connection to the session, a copy of the session's audio — what the user's microphone sends, whether or not the assistant is listening at that moment, and the assistant's spoken replies — and offers no setting that switches it off. The platform's handling of that copy has been the same since the first voice session: each fragment is received only transiently in working memory as the connection is read and is discarded without being decoded — never analysed, stored, logged, recorded or sent to the browser. Section 6.1 gains a bullet stating this, with its basis (the contract), and a forward restriction on RunMyB: should the platform begin to use the assistant's own voice — never the user's — to time the speech of the assistant's on-screen face, it will analyse that voice only in working memory, keep nothing of the audio but the timings derived from it, and state that use in Section 6.1 before it begins. Section 5.1's OpenAI row, Section 6.1's what-RunMyB-keeps and other-people-in-the-room bullets, and Section 8's voice-assistant bullet are corrected to match. No recipient, purpose or retention changes: no audio is kept, as before. The earlier entries in this changelog are left as written; this entry is the record that their no-audio statement was wrong. Also in 5.2: Section 2 gains the voice features' own line (dictation and the voice assistant, on the contract basis), and Section 6.1 states that muting in the console switches the microphone track off in the browser. 5.3 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a new feature's processing, reduces no right and adds no obligation; effective on posting, 2026-09-27; no sub-processor is added or replaced and no new onward provider is named — Google LLC is already named as OpenRouter's provider for the activity narrator — so the Data Processing Addendum's Section 4 is not engaged; its changelog entry 2.7 records the matching changes): a new Section 2.3 describes the avatar's learned actions and the avatar director. The console's chat avatar acts out a short action when the assistant asks it to — from the account's library of learned actions or from the avatar's built-in actions — and, when neither fits, the platform asks an AI model, the avatar director, to write a new animation, and checks every animation it writes before anything plays. Section 2.3 states what leaves the platform for each attempt (the short description of the action that the assistant passed, reduced to lower-case letters, digits and spaces and limited in length, which may carry words from the user's message; an optional short mood phrase, treated the same way; a description of what the avatar can do; the short descriptions of the actions the account has kept and of the built-in actions; and, on a repeated attempt, the director's own previous answer and why it was refused — at most three attempts for one request; the user's message itself, the rest of the conversation and the user's account details are not sent), to whom (OpenRouter, Inc., which routes it to the provider of the model configured for the director — Google LLC today, as OpenRouter's own provider; RunMyB has no account and no contract with Google for it), what the providers' own published terms say, that the director's requests carry the same routing instruction as the narrator's, excluding providers whose terms allow the use of request data for model improvement, RunMyB's own no-training commitment, what the platform keeps (the account's library of learned actions — for each action its short description, the animation the platform accepted and the results of its checks, which model wrote it, how often and when it last played, and who asked for it and who kept it, by the sign-in identifier the platform holds for each — today the e-mail address they sign in with, or the identifier their sign-in provider supplies instead — shared by the account's members and kept until a member drops the action (which deletes it from the library; the action as it played remains in the conversation's own records), the platform discards it because it no longer passes the platform's checks, or the account is erased; part of the data export; each attempt a usage-metering record), that there is no setting that turns the director off — the avatar learns a new action only when a conversation asks for one — and that the avatar's actions are animations only and act on nothing; a matching bullet in Section 2; a sentence in Section 3.3 that an action learned from a request in any member's conversation joins the account's shared library, where the account's members see its short description and who asked for it, by their sign-in identifier; the OpenRouter row in Section 5.1 names the avatar director beside the narrator; Section 7's onward-transfer sentence for the narrator's requests to Google covers the director's too; Section 8 gains the learned-actions retention bullet. 5.4 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a new feature's processing, reduces no right and adds no obligation; effective on posting, 2026-09-27; no recipient, provider or sub-processor is added — the records are stored on the platform's own hosting infrastructure (Section 5.1) like every other account record and leave it for no provider — so the Data Processing Addendum's Section 4 is not engaged; its changelog entry 2.8 records the matching change): Section 3.1 gains a bullet for the member's chosen avatar — the character a member may pick from the platform's gallery, in the account settings, to stand for them in the account's workspace, shown to the account's other active members wherever the console shows that member to them (today, beside the member's name on their turns in shared venture conversations), on the contract basis; the record holds the character's identifier, whose avatar it is and who chose it — both the member's sign-in identifier — and when it was chosen and last changed, nothing more, and changing back to the default avatar deletes it; the same bullet states that the characters an administrator picks for the account's agents (the platform's assistant and the other agents that work in the account) are the customer's workspace settings, on the customer's instruction, seen by every member, and that the platform keeps with each which administrator chose it (by their sign-in identifier) and when, not shown in the console and part of the customer's account-wide export only; Section 3.2 adds the chosen avatar to the member self-export; Section 3.4 states that a disabled member's chosen avatar is retained and no longer shown to the account's members; Section 8 gains the chosen-avatars retention bullet. 5.5 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a new feature's processing, reduces no right and adds no obligation; effective on posting, 2026-09-28; OpenAI (OpenAI OpCo, LLC) is named as OpenRouter's own provider for a new platform role, and Microsoft Corporation and Amazon Web Services, Inc. as the other providers of the same model to which OpenRouter may route that role's requests — a change recorded under the Data Processing Addendum's Section 4 mechanism, its changelog entry 2.9, which also records that the Section 4 notice period and objection window were waived for this change on 2026-09-28 by the platform's sole Customer): a new Section 2.4 describes the avatar a member may create from their own description. In the account settings a member may describe an avatar in a sentence, in any language, or pick one of the ideas the platform offers; after the platform's automated safety check, an AI model — the avatar author — restates the description as one short sentence and draws the avatar from it in the same request, and the member chooses to use it, to change it with a one-sentence instruction, or to try another; the author is asked to write the sentence in the language of the description, and is instructed to draw people's avatars only, never a robot, and not to depict a real, identifiable person, brand, logo or trademark; the drawing is made of drawn shapes and colours only, with no text field, picture or link. Section 2.4 states what is checked first (the description, and a change asked for, pass the automated safety check; a refused one is not drawn); what leaves the platform for each attempt (the description exactly as written; for a change, the instruction with the drawing and the sentence being changed; for another try, the sentence the platform wrote; the platform's own instructions and example characters; on a repeated attempt, the author's previous answer and why it was refused — at most three attempts for one drawing; for the ideas, nothing the member wrote — only the language the browser is set to and the platform's own instructions, with a random value that varies the ideas from day to day; never the member's name, e-mail address or other account details); to whom (OpenRouter, Inc., which routes it to the provider of the model configured for the avatar author — OpenAI today, as OpenRouter's own provider, under OpenAI's terms with OpenRouter; OpenRouter may also route a request to another provider it lists for that model, for example when OpenAI's own service is unavailable, if that provider meets the routing instruction — today Microsoft Corporation (its Azure service) or Amazon Web Services, Inc. (its Amazon Bedrock service), each under its own terms with OpenRouter; RunMyB has no contract with Microsoft for this, and RunMyB's own agreements with OpenAI, which covers the voice assistant, and with Amazon Web Services, which covers the platform's hosting, do not cover this route); what OpenRouter's and OpenAI's own published terms say, RunMyB relaying nothing from Microsoft's or Amazon Web Services' published terms for those services; that the author's requests carry the same routing instruction as the narrator's and the director's, excluding providers whose terms allow the use of request data for model improvement; RunMyB's own no-training commitment; what the platform keeps (for each drawing, the platform's sentence, the drawing as its checks accepted it, which model drew it, which earlier drawing it was changed from, whose it is by the sign-in identifier, and when — never the member's description, whose only kept copy is in the safety check's record; the avatar used replaces the previous one, which is deleted with every unused drawing; unused drawings more than a day old are deleted when the member creates again, and no more than ten are kept; choosing a gallery character keeps the created avatar, and deleting it returns the member to the default; kept until replaced or deleted, or the account is erased; part of the member's own export and of the account's export; the ideas held in working memory for the day only; each request a usage-metering record carrying a pseudonymous code for the member); who sees it (the avatar used, and the sentence that describes it, by the account's other active members, as a chosen avatar is; unused drawings by no one else in the console; the account-wide export, an administrator's, carries the avatars, the unused drawings and — in the safety check's records — the descriptions and changes the member wrote); and that the drawing is made by an AI model, may not look like what was asked for, and acts on nothing; a matching bullet in Section 2, and a Section 2 bullet stating the purpose and legal basis of the records of the automated safety checks (legitimate interest: the platform's evidence of its safety decisions, and recognising repeated abuse); Section 3.1's chosen-avatar bullet points to Section 2.4; Section 3.2 adds the created avatars and the unused drawings to the member self-export; Section 3.4 states that a disabled member's created avatar is retained and no longer shown, like a chosen one; the OpenRouter row in Section 5.1 names the avatar author with OpenAI as its provider today and Microsoft Corporation and Amazon Web Services, Inc. as the other providers OpenRouter may route it to, and the OpenAI row points to it; the Anthropic row in Section 5.1 states that Anthropic today also runs the platform's automated content-safety checks, which receive the text they check — already true of the checks on build requests, and now stated; Section 7 states the onward transfers to OpenAI, and to Microsoft Corporation or Amazon Web Services, Inc. where OpenRouter routes a request to them, under OpenRouter's terms; Section 8 gains the created-avatars retention bullet and a bullet for the records of the automated safety checks — kept as the platform's evidence of its safety decisions and not deleted when the account is erased, which was already true of the checks on build requests and is now stated, and Section 8's bullet on account, workspace and content data now refers to the retention carve-outs below it, that record among them; Section 9's erasure sentence states that the records of the automated safety checks are retained as they are when the account is erased, for the period Section 8 states; Section 9's automated-checks paragraph adds the check on avatar descriptions and changes, points to Section 5.1 for the provider that makes each check, and states that the record of every check keeps the text it checked, is not shown in the console and is part of the account's data export. 5.6 — a disclosure (NON-MATERIAL under the Terms' Section 24: it narrows one stated restriction on RunMyB — that the narrator never reads the evidence attached to an approval — while keeping, and now stating expressly, the protection that restriction gave, that the evidence does not reach the model or its provider; it discloses a changed feature's processing, in the reader's favour, reduces no right and adds no obligation; effective on posting, 2026-09-30; no recipient, provider or sub-processor is added and nothing leaves the platform for a new recipient or a new purpose, so the Data Processing Addendum is not engaged and is unchanged): Section 2.2 said that the activity narrator never reads the evidence attached to an approval. For an approval to publish a build, the narrator now reads that evidence so that the platform can work out, from what is recorded there about the platform's own checks of that build, one plain outcome — the checks passed, they found problems, they did not finish, or no outcome could be read — and sends only that outcome, and nothing else of the evidence, to its model with the approval, because without it the account had called a build verified when the build's own publication card said its checks had found problems. Section 2.2 now states this, and states that the evidence itself never leaves the platform for the narrator. The outcome goes to the same recipients, for the same purpose, as the rest of the narrator's request; no new record is kept. The earlier entries in this changelog are left as written; this entry is the record that the never-reads statement no longer holds for an approval to publish a build. 5.7 — a correction (NON-MATERIAL under the Terms' Section 24: a clarification of something that would otherwise become untrue — the platform's configuration already named the new route when this edition posted, and the platform's call records show no check served through it before the posting; it reduces no right and adds no obligation; effective on posting, 2026-10-03; the automated content-safety checks that Section 9 describes move from Anthropic PBC to a model reached through OpenRouter, Inc., whose provider for them is Google LLC — a change recorded under the Data Processing Addendum's Section 4 mechanism, its changelog entry 2.10, which also records that the Section 4 notice period and objection window were waived for this change on 2026-10-03 by the platform's sole Customer): the platform's automated content-safety checks — the screening of build requests, of imported content, and of the descriptions and changes a member writes for an avatar (Section 9) — are made by an AI model reached through OpenRouter, Inc., under RunMyB's own account and key, which routes each check's request to Google LLC (its Gemini model) as OpenRouter's own provider; RunMyB has no contract with Google for this and relays nothing from Google's terms for this route beyond the transfer basis Section 7 states. Each check's request carries the text it checks with the platform's instructions for the check — never the member's name, e-mail address or the account's identifiers — and a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place: if that provider cannot serve, no other provider receives the text and the check is treated as one needing review. Section 9's automated-checks paragraph states this in place of its pointer to Section 5.1, and Section 2.4's first bullet points to it; the Anthropic row in Section 5.1 no longer states that Anthropic runs those checks and names them, as the automated content-safety checks that Section 9 describes, among the roles routed through OpenRouter; the OpenRouter row in Section 5.1 names them in the same words, with Google LLC as their provider today and their routing instruction; Section 7's onward-transfer sentence for the requests OpenRouter routes to Google covers the checks' requests. Section 9 also discloses, correcting an omission, that the platform's automated checks screen a public web address a member chooses when asking to publish a product, before that address is reserved, through the same route and under the same routing instruction: that check's request carries the address and, where the member gave one, the member's own description of what the product is, with the platform's instructions for the check; an address the check finds to impersonate a brand, an institution or an authority is refused, any other doubt it raises goes to RunMyB's human go-live review, which decides whether the product goes public, and the address and the check's decision are kept with the publication request — after the publication ends and after the account is erased, as Section 8's new Publication records bullet states — the description not. What the checks record, and for how long, is unchanged (Sections 2, 8 and 9). 5.8 — two disclosures and three clarifications (NON-MATERIAL under the Terms' Section 24: it discloses a second engine for the voice assistant and a new kept record of a feature already described, corrects statements that would otherwise become untrue, and states, as a clarification of something already true, what erasing a product does to the activity narrator's records; it reduces no right and adds no obligation; effective on posting, 2026-10-07; ElevenLabs (Eleven Labs Inc.), already a sub-processor for voice dictation, is engaged for the voice assistant, OpenRouter, Inc.'s function is widened to route the voice assistant's reaction model, with TypeSafe AI, Inc. named as OpenRouter's own provider for it, and the model that puts the platform's notes into the assistant's words, served by OpenRouter's providers for the avatar author — a change recorded under the Data Processing Addendum's Section 4 mechanism, its changelog entry 2.11, which also records that the Section 4 notice period and objection window were waived for this change on 2026-10-07 by the platform's sole Customer). Part (1), the voice assistant's ElevenLabs engine: Section 6.1 states that voice sessions run on one of two engines chosen by the platform's administrators — never by the user — OpenAI's speech model, the default, or a pipeline built on ElevenLabs' speech engine and voice, and that a session keeps the engine it started on. For the ElevenLabs engine it states that the user's browser sends the audio directly to ElevenLabs' speech engine, which transcribes it, detects the end of each turn and sends the platform the text, never the audio, over a connection the platform sets up for each session under RunMyB's own account and key, the platform asking ElevenLabs on every session not to keep a recording and to keep the conversation's transcript for zero days; that the user's microphone audio does not reach the platform; that ElevenLabs' voice model turns the text of Remi's replies into Remi's voice, which the platform relays to the browser as it plays without storing it or analysing its sound, the face's timing coming from timing information ElevenLabs returns with the voice; that a speech detector runs in the browser and sends the platform signals only, never audio; and that for each turn the platform sends a small model, Jev — reached through OpenRouter and served by TypeSafe AI, Inc. as OpenRouter's own provider — the transcribed words, Remi's last reply, the conversation's language, whether a change awaits confirmation and the words set aside in the last few seconds. Jev chooses a short reaction, names the language and judges whether the thought is complete and whether the words were meant for Remi, from the words alone, never the voice. It states that on this engine the platform's own notes to Remi — the greeting, which carries the user's display name, and notes such as a card awaiting confirmation with the values of the change, a result, a fault or the end of the session — are put into Remi's words by a second model the platform configures for the whole platform, which receives each note and the conversation's language, never the transcript, through OpenRouter, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement. Section 6.1 also states that words Jev is confident were meant for someone else are not stored, shown or answered, and that words are treated as meant for Remi when Jev is unsure or does not answer in time; what ElevenLabs', OpenRouter's and TypeSafe's published terms say; the routing instruction on Jev's requests; and what RunMyB keeps — the transcript (on this engine the words judged meant for Remi and, of Remi's, what was sent to be played), the cards, and the metering record, which also holds the engine and, on this engine, the counts it is priced on and the cost the providers reported for the reaction requests and the phrasing of the platform's notes, and, on either engine, the cost of checking a spoken reply to a card where neither an account nor a venture carries it. Correcting a statement that would otherwise become untrue, Section 6.1 states that on this engine Remi's short reactions and the short lines it says during a longer wait are chosen from a fixed list the platform writes and translates, and never state an outcome; that Remi may say a line from the same list — that something went wrong, that the answer is on screen, or that a card on screen is waiting for a tap — when the platform's report of what has happened is not put into words in time; that no line on that list carries a number or a name, and everything else Remi says is written for the moment by an AI model; and that on the OpenAI engine the platform gives Remi no fixed wording to speak. Its other-people-in-the-room and no-voiceprint bullets now cover both engines. Section 2's voice line, Section 6's opening paragraph, the Cloudflare, ElevenLabs, OpenAI and OpenRouter rows of Section 5.1 (the Cloudflare row now naming the voice assistant's test sessions of RunMyB's own administrators through a Cloudflare tunnel), Section 7 (ElevenLabs' processing of a voice session's audio and of the text of Remi's replies outside the United States under the Standard Contractual Clauses in ElevenLabs' Data Processing Addendum; the onward transfers under OpenRouter's terms to TypeSafe and, for the phrasing of the platform's notes, to the avatar author's providers) and Section 8's voice-assistant bullet are amended to match. Before this posting the ElevenLabs engine served only voice sessions opened by the platform's administrators. Part (2), the activity narrator's history: Section 2.2 names the kept history of the narrator's earlier notes and finished items, that it is part of the account's export and leaves the platform for no one, and that erasing any one of the venture's products deletes it together with the narrator's working state and the entries that record that product; Section 8 states the same retention; part (2) on its own engages no provider and would need no change to the Data Processing Addendum or the Terms. The Terms' Section 13 names the voice assistant's two engines (edition 4.4). 5.9 — a disclosure and two clarifications (NON-MATERIAL under the Terms' Section 24: it discloses when the voice assistant's default engine serves a session while the other engine is chosen for everyone, and corrects statements that would otherwise become untrue; it reduces no right and adds no obligation; effective on posting, 2026-10-07; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged, and its changelog entry 2.12 records the matching disclosure). Section 6.1 states that where the platform's administrators have chosen ElevenLabs' engine for everyone else's sessions and that engine cannot serve one of those sessions when it starts, the session runs on OpenAI's engine instead, and keeps it until it ends. Section 5.1's OpenAI row states that OpenAI is engaged for such a session too, and its ElevenLabs row now describes the voice assistant's sessions on the ElevenLabs engine; Section 6's opening paragraph states that the voice assistant runs on one of two engines. The Terms' Section 13 states the same (edition 4.5). 6.0 — two disclosures and one change of retention (MATERIAL under the Terms' Section 24: part (3) below keeps a record that until now was erased with the venture it concerned, which narrows what an erasure removes, so the re-consent gate fires and renewed acceptance is required; parts (1) and (2) alone would have been NON-MATERIAL; effective 2026-10-10, published with the Terms' edition 5.0; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged, and its changelog entry 2.13 records the matching disclosures). Part (1), the field survey and the references you name: a new Section 2.5 states that before the platform writes a product's plan it studies the leading public services of the product's type and any service the user names, unless the study is turned off for the venture on its Modules card or the user asks to skip it; that a browser the platform runs on its own infrastructure captures up to ten public pages of each service — the text of each and a screenshot of the part a visitor first sees — without logging in, typing or filling in forms, and that in its own automated fetching the platform honours each site's robots.txt; that the AI models doing the study may also read other public material about the services through the web tools available to them; that a reference the user names may calibrate the platform's reviews and, once confirmed for that purpose, is studied before a plan, and that the platform keeps an append-only record of the statement the user confirmed; that public reviews are kept only as the study's own summaries, the study being built to keep no reviewer's name, handle, picture or words; that the captured text, the other public material read and the user's references and files go to the AI models that do the study, and its findings to the models that write the plan and review the product, whose providers Section 5.1 names; that the captured pages, their screenshots and the comparison the study writes are kept with the venture for its life and deleted with it; and that the user's references and files are processed on the contract basis, while personal data about other people that the public material studied happens to carry is processed by RunMyB as controller, on its legitimate interest in studying publicly offered services to plan the features of a customer's product, for that purpose only — Section 2.5 being how RunMyB makes that information publicly available, as Article 14(5)(b) GDPR provides; a matching bullet in Section 2, and a retention bullet in Section 8. Part (2), the language you last used: a new Section 2.6 states that the platform remembers one language for each person in each account — a short language code, with where it was seen and when — so that its assistants, Remi included, answer the person in it; that it starts from the language the browser reports and then follows the language of what the person types and says, a click on a button or a card not changing it; that for typed words, and for speech on the voice assistant's OpenAI engine, a language detector running on the platform's own servers works it out, sending nothing anywhere, and that on the ElevenLabs engine it is the language Jev names, remembered only when Jev names the same language for two utterances in a row; that only the code leaves the platform, with the instructions of the AI models that serve the assistants and Remi; and that it is kept for the life of the account, retained under the account when a member's access ends, part of the person's own export and deleted when the account is erased; a matching bullet in Section 2, a bullet in Section 3.1, Section 3.2's self-export list, Section 3.4's departed-member posture, a Section 6.1 bullet on the language a voice session starts in, and a retention bullet in Section 8. Part (3), the affirmations kept: the affirmation a user makes when naming a reference — the statement's exact wording, the link or a reference to the file it covers, who confirmed it and when — is now kept as it was recorded, append-only, through the limitation period, also after the reference, the venture or the account is erased, as the platform's evidence of what was affirmed; until this edition such a record was erased with the venture. A new Section 8 bullet beside the one on billing, ledger and acceptance records, and Section 9's erasure sentence, now name it, together with the affirmations made when importing code or a brand, which were already kept in this way and are now stated. 6.1 — a disclosure and a correction (NON-MATERIAL under the Terms' Section 24: it names a provider that serves platform roles and states how the providers behind the platform roles routed through OpenRouter, Inc. are chosen, where a sentence said that each such provider was named and not every one was, and it names the platform's assistant among those the field survey's findings are sent to, and what you asked for — which the study has received since it began — among what is sent to the models that do the study; it reduces no right and adds no obligation; effective on posting, 2026-10-12; the Data Processing Addendum's changelog entry 2.14 records the matching sub-processor changes under its Section 4 mechanism). Section 5.1's OpenRouter row states that, for every platform role OpenRouter routes beyond those it names one by one — among them the console's chat assistants and the roles that research the market and plan a product — OpenRouter routes the request to a provider of the model configured for that role, or chosen for a conversation, which serves it as OpenRouter's own provider, each request carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement; and it names those providers today by the model's maker: OpenAI, Microsoft (its Azure service) or Amazon Web Services (its Amazon Bedrock service) for OpenAI's models; Google LLC for its Gemini model; SpaceXAI LLC (xAI), a provider this Policy did not name before, or Amazon Web Services for SpaceXAI's Grok model, which the general worker and the development executor are configured to today, each such request sent only to a route OpenRouter records as retaining no request data: SpaceXAI's zero-data-retention service, or Amazon Bedrock; Anthropic PBC or another of OpenRouter's providers for Anthropic's Claude models; and, for a model of another maker that you choose for a conversation or that your account's administrators configure for a role, a provider of that model, chosen by OpenRouter's routing, that RunMyB does not name in advance. The platform's configuration named SpaceXAI's model for those two roles before this edition posted, and the hosted platform's call records show no request served through it before the posting. Section 5.1's Anthropic row now says that the OpenRouter row states how the provider that serves such a role is chosen and names today's providers for the models the platform configures, where it said that the OpenRouter row names the provider that serves it; the OpenAI row names the other roles OpenAI serves as OpenRouter's provider; Sections 2 and 2.5 say that Section 5.1 names the providers, or states how OpenRouter chooses them; Section 2.5 also names the platform's assistant in a conversation, when it reads the study for you, among those the field survey's findings are sent to, where it named only the models that write the plan and review the product; it also names what you asked for — your description of the product you want and of its venture, in your own words or as the platform restated them, and the services you named — among what is sent to the AI models that do the study, where it named only the captured text, the other public material read and the references and files you chose; and Section 7 states that every other request OpenRouter routes is an onward transfer under OpenRouter's terms with the provider that serves it, and states SpaceXAI's transfer basis. The Terms' Section 13 states the same (edition 5.1). Also in 6.1, the Ideas stream — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a new feature's processing, reduces no right and adds no obligation; OpenRouter, Inc.'s function is widened to route the requests of a new platform role, the idea author, to the providers Section 5.1 names for the model configured for it — a change that the Data Processing Addendum's changelog entry 2.14 also records under its Section 4 mechanism). A new Section 2.7 describes the Ideas stream — ideas for products that the platform writes with an AI model, the idea author, from the results of web searches it runs, or draws from a starting set it collected before the stream opened, and ranks for each person — stating what is kept for each person in each account (which ideas the person was shown and how often, their reactions, the ideas they launch and the idea picked for them as the idea of the day, and, if they tune their ideas, the areas they choose, the line about themselves they may add and the ideas then written for them); why (to rank the ideas the person is offered and to write ideas for them, on the contract basis, no decision about them being made from the ranking); what leaves the platform for each request to the idea author (the area and the market the ideas are aimed at — for ideas aimed at the person, their remembered language code — the titles of ideas already written in that area and the results of the platform's web searches, which ask only about the area, the market and the year; for the person's own ideas, their areas and line; for spin-offs of one of the account's ventures, the venture's name, one-line description and audience and the idea it was launched from; never the person's name, e-mail address or other account details) and to whom (OpenRouter, Inc., which routes it to a provider of the model configured for the idea author, as Section 5.1 states, under a routing instruction that excludes providers whose terms allow the use of request data for model improvement); that the platform's assistants read the ideas ranked for a person, and may read their areas and line, when suggesting ideas; RunMyB's own no-training commitment; what is kept and for how long (for the life of the account; Reset deletes the person's areas, line and the record of their reactions at any time; retained under the account when a member's access ends; part of the person's own export and of the account's export; shown in the console to no one else); that the idea author's requests are paid by the platform within a daily allowance it sets for each account, nothing being charged to the person or the account; that a card may show how many ventures were launched from it across the platform, from three launches and naming no account or person, on RunMyB's legitimate interest; and that the ideas written for everyone, and the starting set, are the platform's own content, kept for as long as the platform offers ideas, a retired idea included, as the record of what was offered and so that it is not written again, and that personal data about other people that the public material an idea is written from happens to carry — a founder or a public figure, for example — is processed by RunMyB as controller, on its legitimate interest in offering ideas grounded in publicly available information, for that purpose only, Section 2.7 being how RunMyB makes that information publicly available, as Article 14(5)(b) GDPR provides. Section 2 gains a matching bullet, and its usage-metering bullet states that those records, with how long the platform worked on each launched venture, are combined into the ranges of cost and time shown on idea cards — a range shown only when at least five launches stand behind it, rounded, naming no account or venture — on RunMyB's legitimate interest in telling people what a launch has cost before they start one, a purpose compatible with the one the records are kept for. Section 2's bullet on the language you last used, Section 2.6 and Section 3.1 state that the remembered language code is also the market the Ideas stream aims ideas at, and that it travels with the idea author's requests; Section 3.1 gains a bullet for the Ideas stream's records, Section 3.2's self-export list and Section 3.4's departed-member posture name them, and Section 8 gains two retention bullets; and Section 5.1's OpenRouter row names the idea author among the other platform roles it routes. The Terms' Section 13 names the idea author (edition 5.1). 6.2 — a correction and a disclosure (NON-MATERIAL under the Terms' Section 24: it corrects a sentence that called the data-export bundles complete, which they were not, and states how long a bundle and the record of a data request are kept; deleting a bundle when its download window ends and when the account is erased is a new restriction on RunMyB; it reduces no right and adds no obligation; effective on posting, 2026-10-16; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged; the Data Processing Addendum's edition 2.15 corrects the same sentence in its Section 3(e)). Section 9 now says that data exports are produced as structured bundles you download yourself, with a manifest that lists every store the platform keeps and, for each store a bundle does not include, why, where it said that they were produced as complete, structured bundles; records about an account that no bundle selects stay outside them. Section 8 gains a retention bullet for data-export bundles: the bundle the platform prepares when you request your data or self-export is kept for 7 days after it is prepared, the window in which you can download it, then deleted, and every bundle of an account is deleted when the account is erased — before this edition, nothing in the platform deleted a bundle when its window ended or when the account was erased; and the record that the request was made and answered is kept as the platform's compliance evidence for the limitation period, as it has been since the in-platform data-request flow began. Also in 6.2, a correction (NON-MATERIAL under the Terms' Section 24: a disclosure of what was already true and a clarification; no sub-processor is added or replaced; the Terms' edition 5.2, the Data Processing Addendum's edition 2.15 and the Cookie & Tracker Notice's edition 3.2 make the matching changes): Section 4 said that the statistics' two sources both produce aggregates only, that the network address and browser signature from which the visitor hash is derived are discarded immediately and never logged or stored, that the hash cannot link the same visitor across days, and that what is retained is only bucketed, aggregate counts. That was inaccurate from the edition that added the beacon (3.0) on: the platform's load balancer keeps a record of every request to the console and to the hosted products — with the visitor's network address, browser identifier and the full address requested — for 30 days; the beacon keeps a record of each page view — its time, the page's host, the referring host and the daily visitor identifier — for 7 days; and the key from which each day's identifier is derived is kept by the platform, so that the platform, holding the key, could link the identifier across days, which it does not do. The processing has been the same since 3.0. Section 4 now states it: what the records contain, by category; their three purposes — statistics for each product's owner, the security and operation of the platform, and aggregate statistics about the platform, which RunMyB may publish, a single product's statistics being shown publicly only with its owner's consent; that the records are kept for up to 30 days, and the statistics counted from them, which identify no visitor, for as long as they are useful; that RunMyB keeps them as an independent controller, also for the visitors of a customer's hosted product, and not as the customer's processor; and that the platform shows no cookie-consent banner because the beacon stores nothing on and reads nothing from the device beyond the page context it runs in and is the platform's own first-party audience measurement, the French CNIL's guidance supporting that posture rather than founding it. Section 1 names these records in this Policy's scope and in RunMyB's role as controller, and Sections 2 and 8 are corrected to match. The earlier entries in this changelog are left as written; this entry is the record that their statements on the statistics, among them 3.0's aggregates-only retention, were wrong. 6.3 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes two new records that keep the platform's e-mail within its limits, reduces no right and adds no obligation, and deleting the daily counts after the following day is a new restriction on RunMyB; effective on posting, 2026-10-18; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged; the Data Processing Addendum's edition 2.17 states that these records are RunMyB's own and not Customer Personal Data). Section 2 gains a bullet for the platform's e-mail sending limits: when an application hosted on the platform asks the platform to send an address-verification or password-reset message, the platform counts how many such messages were sent to the recipient's address that day, from that application and from all applications together; and, for any address the platform sends e-mail to, it records that the address is paused after repeated bounces that were not hard bounces; both identify the address only by a hash made with a secret key the platform holds, never by the address itself; RunMyB keeps them for its own purposes, as an independent controller, also for the people an application hosted on the platform asks it to write to, on its legitimate interest in keeping the platform's e-mail within its limits and protecting the people it writes to and its ability to deliver e-mail. Section 1 names them among the records RunMyB keeps as controller, whoever the recipient is. Section 8 gains a retention bullet: the daily counts are kept for the day they count and the following day, then deleted, and the record that an address was paused is kept with the platform's security and operational logs. Section 5.1's AWS row names the sending of the platform's e-mail through Amazon Simple Email Service, which the platform already does: a disclosure. The Terms' edition 5.3 corrects an unrelated cross-reference in its Section 10.2. 6.4 — a change in your favour and a disclosure (NON-MATERIAL under the Terms' Section 24: it ends the one exception to the no-training commitment, a new restriction on RunMyB, names today's providers for a model the platform configures, and reduces no right and adds no obligation; effective on posting, 2026-10-19; the Data Processing Addendum's edition 2.18 records the naming of those providers inside OpenRouter's row as a change under its Section 4). The build roles (build-ui and build-core) no longer route to a provider that may train on what it receives: their exception ended on 2026-10-18, when RunMyB's OpenRouter account stopped permitting routing to providers whose terms allow the use of request data for model improvement, and their requests now carry, like every request RunMyB sends through OpenRouter on its own account, a routing instruction that excludes such providers. Section 5.1's OpenRouter row lists the build roles among the other roles it routes; it names, for DeepSeek's model, which platform roles, among them the build roles, the general worker and the development executor (worker and dev-executor), may be configured to, today's providers, Deep Infra Inc. or Parasail, Inc., which OpenRouter lists among the endpoints with a zero-data-retention policy, though these requests carry no instruction that requires one; it states that the routing instruction excludes DeepSeek's own endpoint while OpenRouter records DeepSeek's policy as allowing the use of request data for training, DeepSeek's published privacy policy stating that it uses the personal data it collects to train and improve its models; and it records that from 2026-09-15 until 2026-10-18 the build roles' requests carried no such instruction, under an account setting that permitted such providers, and that OpenRouter was instructed to prefer DeepSeek's own endpoint, so that the build content routed in that period was disclosed to DeepSeek (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.) or to another of OpenRouter's providers for that model. The row's sentence on SpaceXAI's Grok model says that platform roles, among them the general worker and the development executor, may be configured to that model, where it said that those two are configured to it today; both moved to DeepSeek's model before this edition posted. Section 7's sentence on the requests that OpenRouter routes to SpaceXAI's Grok model is worded the same way. Sections 2.2, 2.3 and 2.4 no longer state that RunMyB's OpenRouter account permits routing to providers whose terms allow the use of request data for model improvement, a setting kept for other platform roles, and state that the requests of the narrator, the avatar director and the avatar author carry the routing instruction, like every request RunMyB sends through OpenRouter on its own account. Section 2 states that RunMyB does not permit any provider that processes your content to use it to train or improve its models on RunMyB's behalf. Section 7 states that DeepSeek was the provider preferred for the build roles until 2026-10-18, with what was held for that leg, and states the leg to today's providers for DeepSeek's model as an onward transfer under OpenRouter's terms. The Terms' edition 5.4 and the Data Processing Addendum's edition 2.18 make the matching changes. 6.5 — a disclosure, and the correction of an omission (NON-MATERIAL under the Terms' Section 24: it describes the notices the platform now e-mails to the administrators of accounts, the choice each of them has of how and whether the notices about the account reach them, and the records kept of those notices, of those choices and of the delivery of each message the platform sends its users, reduces no right and adds no obligation, and deleting a notice's record 30 days after the notice was sent, skipped or failed is a new restriction on RunMyB; effective on posting, 2026-10-19; no sub-processor is added or replaced — the messages are sent through Amazon Simple Email Service, which Section 5.1's AWS row already names — so the Data Processing Addendum's Section 4 mechanism is not engaged). Section 2 gains three bullets. Notices by e-mail: an administrator of an account is e-mailed, at the address they sign in with, a notice when a card in the console waits for their decision, when one of the account's products is published or its go-live request is declined, when one of its runs finishes, fails or is stopped at a limit, when the account's credits run low or run out and when the account nears or reaches its daily credit limit, and the administrators of every account receive RunMyB's notices about the service itself, such as a change of its sub-processors; each administrator can choose in the console whether the notices about the account reach them at once, in a daily summary or not at all, for all of them or for each kind, the notice that a run finished coming in the daily summary until they choose, and RunMyB's notices about the service itself have no such setting; text the account's console shows, such as a card's title, goes only to that account's own administrators, and no notice carries the material attached to a card; for each notice and each recipient the platform keeps a record of the kind of notice, the account it concerns, the recipient's address, the identifier of the event it reports, when the notice was due, whether it waits for the daily summary and whether and when it was sent, skipped or failed, never the event's text; the basis is contract. Notification choices: each choice a user makes in the console about which notices they receive for an account — the kind of notice or all of them, at once, in the daily summary or not at all, their sign-in identity and when they made it — the latest for each kind being the setting in force; the basis is contract. E-mail delivery records: for each message the platform sends a user, the delivery events the mail provider reports, with the user's address; the platform's own record of the message and of what became of it, which identifies the recipient only by a hash made with a secret key the platform holds; and, after a permanent bounce or a spam report, the address on the platform's suppression list, so that no further e-mail is sent to it; the basis is legitimate interest; the platform has kept these records since it began sending e-mail and this Policy did not name them before this edition, which corrects that omission. Section 8 gains the retention of each: a notice's record is kept for 30 days after the notice was sent, skipped or failed, then deleted, and the records of an account's notices are deleted when the account is erased; a notification choice is kept for as long as the account exists and deleted when the account is erased; the delivery events are kept for 30 days, then deleted; the platform's own delivery record is kept with the security and operational logs; a suppressed address is kept for as long as it stays suppressed, also after the account is erased. Section 3 names, among the platform's own records about a member, the notices the platform e-mails a member who is an administrator, their record and the member's choices of which of them they receive. The Terms' edition 5.5 and the Data Processing Addendum's edition 2.19 make the matching changes. 6.6 — a disclosure, and the correction of an omission (NON-MATERIAL under the Terms' Section 24: it names a record, its basis and how long it is kept, reduces no right and adds no obligation; effective on posting, 2026-10-19, published with the Terms of Service & Acceptable Use's edition 6.0 and the Cookie & Tracker Notice's edition 3.3; no recipient is added and the Data Processing Addendum is unchanged): Section 8's publication records now also state that the record of who later unpublished or released a publication, or turned its demo notice on or off, and when, is kept as the platform's evidence of those changes for the limitation period that applies to it, also after the account is erased, then deleted, and that for a removal of the demo notice by the product's owner it keeps a record of the confirmation they gave (Terms of Service & Acceptable Use, Section 15). Section 2 gains a bullet on the publication records — the address, the state of the publication, the check's decision, and who requested, unpublished or released it or turned its demo notice on or off, and when, with the confirmation an owner gives when removing a demo notice — kept to serve the product at that address (contract), and to keep an address that once served one account from being claimed by another and as the platform's evidence of those changes (legitimate interest). Section 9's erasure sentence names them beside the affirmations and the safety-check records. The platform has kept the record of who unpublished or released a publication since products were first published, and this Policy did not name it, or the basis of the publication records, before this edition, which corrects that omission. A visitor's acknowledgement of a demo notice is kept only in the visitor's own browser, and RunMyB's script never sends it anywhere, as the Cookie & Tracker Notice describes; this Policy is not changed for it. 6.7 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a new feature's processing within the processor relationship, reduces no right and adds no obligation; effective on posting, 2026-10-19, published with the Terms of Service & Acceptable Use's edition 7.0; no sub-processor is added or replaced — the sign-in provider acts under the customer's own registration, as Section 5.2 states for the services a customer connects — so the Data Processing Addendum's Section 4 mechanism is not engaged; the Data Processing Addendum's edition 2.20 records the matching disclosure): Section 1 names, within the processor relationship, the platform's in-transit relay of an application's sign-in with a sign-in provider the platform offers for it (today Google or GitHub), and Section 5.2 gains a bullet on the sign-in providers for a customer's products — the customer's own registration, the relay keeping nothing it passes on, and the custody of the client secret, deleted when the customer asks the platform to stop using that provider for the product. 6.8 — a disclosure, the correction of an omission, and a new restriction on RunMyB (NON-MATERIAL under the Terms' Section 24: it describes processing the platform already performs on the data it receives from Google, reduces no right and adds no obligation, and its commitment that Google user data is never sent to an AI model on a key of the user's own and is sent to a model for no platform purpose other than the feature that needs it is a new restriction on RunMyB; effective on posting, 2026-10-19; no sub-processor is added or replaced and every recipient it names is already named in Section 5.1, so the Data Processing Addendum's Section 4 mechanism is not engaged; the Data Processing Addendum's edition 2.21 records the matching commitment in its Section 7): Section 5.2's Google Drive bullet states that an imported file is part of the venture's content; that, when asked to, the platform's AI assistants, the knowledge module and the brand import read it, and the build agents read the pages distilled from it — the build agents also seeing the names of the file and of the Google account it came from in the venture's library, and the activity narrator seeing those names, and what an assistant said about the file in a conversation, in the venture's records; and that what they read travels in their requests to the AI model providers Section 5.1 names, under the no-training routing Section 5.3 states, its text, bounded, being examined by the automated content-safety check when it is imported, before a changed version of it is copied, and when it is attached to shared knowledge, and that while the connection stays the platform periodically checks Google for changes to the imported files, examines a changed file first with the same check, copies it again as a new version of the copy, keeping the earlier version, only if the check admits it, and leaves the earlier version as the current one where the check holds or refuses the change, a file removed at Google staying in the library; its Gmail bullet states that of Google's answer the platform keeps only the identifier of the sent message, with the record of the confirmation, and that the platform never reads mail; its Google Calendar bullet states that the platform reads only the primary calendar, that it reads that calendar's event list periodically to notice new, changed or cancelled events and to tell the user about them, marking one about to start as needing attention now, that of each event it keeps only a reference and a fingerprint from which it can tell that the event has changed, and that an event the assistant is asked about is read live from Google, travels in the assistant's request to the AI model provider Section 5.1 names for the assistant and then stays in that conversation's records, a derived note recorded from it being a distillation held for review, never a copy. Section 5.3 states the Limited Use commitment in the wording Google now publishes, with the wording Google publishes for Google Workspace scopes beside it, the limit on onward transfers staying in its own bullet, and gains two bullets: the features through which Google user data reaches an AI model — among them the assistant asked about an imported file or a calendar event, in writing or, through the voice assistant, in speech — and that it does so only in a request sent under RunMyB's own account to a provider named in Section 5.1 whose terms, the routing instruction RunMyB attaches or the setting of RunMyB's account with it exclude the use of request data for training, never on an AI key of the user's own and to a model for no platform purpose other than the feature that needs it; and what is kept of Google user data and how it is deleted — an imported file and the pages distilled from it until the venture or the account is erased, deleting the file in the library not erasing the copy sooner; the references and fingerprints of calendar events and imported files until the account is erased, with the choice, when a service is disconnected, of purging them; the identifier of a message sent through Gmail, for the life of the account; the safety checks' excerpts for the period Section 8 states, also after erasure; a disconnected service's token, deleted at once, its revocation asked of Google; and the imported copy, stored encrypted at rest and travelling over encrypted connections whenever it leaves the platform's private network. Section 5.3's human-review bullet states that the bounded excerpts kept with the automated checks' records are read by RunMyB's operating team for that security purpose only. Section 9 states what the go-live review's automated leg reads — among it the texts that the venture's most recent automated checks recorded, which may include imported content — and that it goes through the same route and under the same routing instruction as the other automated checks. Except for the new restriction, each of these describes processing the platform already performed when this edition posted, which this Policy did not state before; this edition corrects that omission. 6.9 — a change in the user's favour and the correction of an omission (NON-MATERIAL under the Terms' Section 24: disconnecting one Google service no longer ends RunMyB's access to the other Google services connected with the same Google account, the disconnected service's token is still deleted at once, the user can end RunMyB's access at Google at any time, and it reduces no right and adds no obligation; effective on posting, 2026-10-20; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged, and the Data Processing Addendum, which states nothing about revoking a connection's token, is unchanged): Section 5.2 states that, for a Google service, RunMyB asks Google to end its access when the last Google service connected with the same Google account is disconnected, Google keeping one access grant per app on each Google account, shared by those services; Section 5.3's bullet on what is kept and how it is deleted states that disconnecting a Google service deletes its token from the vault at once and that RunMyB then keeps no token for that service, that RunMyB asks Google to end that grant when the last Google service connected with that Google account is disconnected, and that until then Google's own list of the third-party apps with access to the Google account can still show RunMyB, and there the user can end RunMyB's access at any time. Edition 6.8 said that disconnecting a Google service asks Google to revoke its token, which the platform then did, and did not say that, Google keeping one grant for all of them, the request ended RunMyB's access to every Google service connected with that Google account, those the user kept connected among them; from this edition the request waits for the last of them. 6.10 — a disclosure and a new restriction on RunMyB (NON-MATERIAL under the Terms' Section 24: it describes a new record that RunMyB keeps as an independent controller, reduces no right and adds no obligation, and sending a password reset only to an address confirmed for the application, and no message on an application's behalf to an address unsubscribed from it, restricts what RunMyB sends; effective on posting, 2026-10-22; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged; the Data Processing Addendum's edition 2.22 states that this record is RunMyB's own and not Customer Personal Data). Section 2 gains a bullet for confirmed and unsubscribed addresses: the address-verification and password-reset messages the platform sends for an application hosted on it carry, in place of the application's own link, the platform's link, on the application's own web address on runmyb.app, which then opens the application's link, and every message the platform sends on an application's behalf carries an unsubscribe; for each application and each address it writes to, the platform keeps a record of each time the address is confirmed for that application, when one of the platform's links, sent to that address in a message from that application, is opened while it is valid, of each time the address is unsubscribed from that application and of each time an unsubscribe is undone, each entry saying which of these it is and how it arose, with, where a link gave rise to it, that link's identifier and when it was issued, and when the entry was made; an address to which one of the application's address-verification or password-reset messages, sent before those messages carried the platform's link, was delivered is recorded as confirmed, with the time of that message; the record identifies the address only by a hash made with a secret key the platform holds and keeps nothing about the browser or device that opened the link; when a password reset is replaced, or a message withheld, because of this record, the application's owner can see in the console how many were and why, and the time of each one the platform recorded, but never the address; an application that keeps its own record of the requests it made can match the time to one of them; RunMyB keeps the record for its own purposes, as an independent controller, also for the people an application hosted on the platform asks it to write to, on its legitimate interest in sending a password reset only to an address confirmed for that application, an address not yet confirmed being sent one message of the platform's own asking for it to be confirmed instead, in sending no message on an application's behalf to an address unsubscribed from it until that is undone, and in protecting the people it writes to and its ability to deliver e-mail. Section 1 names the record among those RunMyB keeps as controller, whoever the recipient is. Section 8 gains a retention bullet: the record is kept for as long as the application exists and is deleted when the application is erased or the account it belongs to is erased. The 1403 late-reaction correction — the operator CONFIRMED the late reaction for the platform (2026-10-21) and ruled ONE targeted check with NO fable LEGAL review; LEAD-approved as D139; non-material (a disclosure) — is also part of this edition: Section 6.1 now states that Jev judges what kind of thing the user said and that, depending on a setting the platform's administrators choose, Remi either says a short reaction from the platform's fixed list at once or, only when its answer is late, a short reaction written for the moment, for which the words ElevenLabs transcribed, Remi's last reply and the conversation's language are also sent to the second AI model, through OpenRouter, Inc. under RunMyB's own account and key with the same routing instruction, never while a change is waiting for confirmation; that the second model receives, only for those late reactions, what the user said and Remi's last reply, where it had said that the model never receives the transcript; and that Remi's short reactions are chosen from the fixed list or, where the administrators have chosen late reactions, written for the moment by an AI model, neither stating an outcome; no recipient is added, OpenRouter and the second model's providers being named already in Sections 5.1 and 7. 6.11 — a disclosure and a new restriction on RunMyB (NON-MATERIAL under the Terms' Section 24: it describes two new records that RunMyB keeps as an independent controller, reduces no right and adds no obligation, and sending an application's own messages only to an address confirmed for that application restricts what RunMyB sends; effective on posting, 2026-10-22; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged; published with the Terms' edition 8.0 and the Data Processing Addendum's edition 2.23). Section 2's bullet on e-mail sending limits now also names, when an application hosted on the platform asks the platform to send one of its own messages, a count of how many of its own messages were sent to the recipient's address that day, identifying the address only by a hash made with a secret key, and, for each application, a record of each time the application's own messages are switched off or back on — switched off automatically, when the platform receives enough spam reports about them or about the platform's requests to confirm an address sent in their place, or by RunMyB's administrators, and switched back on only by RunMyB's administrators — with the reason, the numbers of reports and of messages behind an automatic switch-off, who decided and when, naming no address; RunMyB keeps them for its own purposes, as an independent controller, on its legitimate interest in keeping the platform's e-mail within its limits and in protecting the people it writes to and its ability to deliver e-mail. Section 2's bullet on confirmed and unsubscribed addresses now states that the record also lets an application's own messages go only to an address confirmed for that application, the platform's message asking for an address to be confirmed that it sends in place of one of them being among the address verifications through whose link an address is confirmed, and that the owner sees such a message replaced or withheld as for a password reset. Section 2's bullet on notices by e-mail names the notice that one of the account's products' own messages to its users are switched off, among the notices about products going live. Section 1 names, within the processor relationship, the messages an application has the platform send its end-users, written from the application's own templates, which the platform renders and sends, keeping no copy of them, and, among the records RunMyB keeps as controller, the record of each time an application's own messages are switched off or back on. Section 8: the daily counts of an application's own messages sent to an address are kept for the day they count and the following day, then deleted, and the record of each time an application's own messages were switched off or back on is kept for as long as the platform operates, also after the application or the account is erased, as the platform's evidence of those decisions. The changes concerning Google user data — a new restriction on RunMyB, a disclosure, a clarification and a correction (NON-MATERIAL under the Terms' Section 24: it narrows where RunMyB may send Google user data, states in the words of Google's policy the commitment that this data trains no model, states the routing instruction and the account settings that keep providers which may train on request data out of every request carrying it, describes the two records the platform keeps to hold to that, clarifies what an application the user builds carries, and describes accurately how OpenRouter chooses the providers of DeepSeek's model, and it reduces no right and adds no obligation; no sub-processor is added or replaced, OpenRouter remaining the sub-processor, so the Data Processing Addendum's Section 4 mechanism is not engaged; the Data Processing Addendum's edition posted with it makes the matching corrections) — are also part of this edition. Section 5.3 states that Google Workspace APIs are not used to develop, improve, or train generalized or non-personalized AI and/or ML models, and neither is the data obtained through them nor any data derived from it, by RunMyB or by any third party, beside its statement, unchanged, that content obtained from the Google account is never used to create, train, or improve any machine-learning or artificial-intelligence model; that every request carrying Google user data that RunMyB sends through OpenRouter, Inc. carries a routing instruction that excludes every provider whose published data policy, as OpenRouter records it, allows the use of request data for training or model improvement, and that RunMyB keeps switched off every setting of its OpenRouter account that would permit routing to such a provider; that what an application the user builds carries in its own code and prompts is that application's content, whose requests on the user's own key are the user's, under the user's own relationship with the provider, the model gateway still refusing a DeepSeek model for them where the application's venture holds Google user data; and, in a new bullet, that Google user data is never sent to a model made by DeepSeek (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.), whichever provider would serve it, nor to DeepSeek's own service, even where a DeepSeek model has been chosen for the work that would carry it; that RunMyB does not call DeepSeek's own service and reaches DeepSeek's models only through OpenRouter; that, when the platform receives content from a Google API, it records that Google user data has entered the conversation, venture or run that receives it, the record following the content wherever the platform's own tools take it, and not a copy a user makes by hand; that RunMyB's model gateway, which composes every request sent through OpenRouter other than the two fixed routes of Sections 6 and 6.1, refuses before sending any request to a DeepSeek model for a conversation, venture or run that the record shows to hold Google user data, or where that cannot be established, and records each request it composes for such a conversation, venture or run in an audit record that names the model and the provider that served it, as OpenRouter reports them; that such work which would otherwise be served by a DeepSeek model is served by another model the platform admits for it or, where it admits none or a DeepSeek model was set for that work explicitly, refused; and that DeepSeek's models remain available for work into which no Google user data has entered. Section 2 states the two records the platform keeps for this, the record that content from the Google connections has entered the account or a conversation, venture or run, and the audit record of each request the gateway composes for one, on its legitimate interest in keeping that commitment and RunMyB's obligations under Google's Limited Use requirements, neither holding content; Section 8 states that the first is kept until the account is erased, a venture's own record going also with that venture, and that the audit record is kept until the account is erased, also after the conversation, venture or run it names has been erased. Section 5.1's OpenRouter row and Section 5.2's Drive and Calendar bullets state that no request carrying Google user data is routed to DeepSeek's model, and Section 7 states that the requests OpenRouter routes to DeepSeek's model never carry Google user data. Until this edition, the Policy did not exclude DeepSeek's model for the requests carrying Google user data, which a provider that the routing instruction admitted for that model could then serve; from this edition no such request is routed to it. Section 5.1's OpenRouter row and Section 7 now describe the providers that serve DeepSeek's model by the rule that chooses them, those whose published data policy, as OpenRouter records it, does not use request data for training, naming Deep Infra Inc., Parasail, Inc. and the provider OpenRouter lists as InferenceNet as examples in the row, and the first two in Section 7, where they had named those two as today's providers; OpenRouter routed the build roles' requests to a third such provider, the one it lists as InferenceNet, on 2026-10-21, which the named pair did not state; this is a correction, a disclosure made accurate. What Sections 5.1 and 7 record of the build roles' routing from 2026-09-15 until 2026-10-18 is unchanged. 6.12 — a disclosure (NON-MATERIAL under the Terms' Section 24: it names one more notice the platform e-mails an account's administrators, reduces no right and adds no obligation; effective on posting, 2026-10-23; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged; published with the Terms' edition 9.0 and the Data Processing Addendum's edition 2.24). Section 2's bullet on notices by e-mail names the notice that one of the account's products' background jobs are paused by RunMyB, among the notices about products going live. The background jobs themselves — what the platform runs for a hosted application, the record of each run and the data the application hands for it — are processing on the customer's behalf, which the Data Processing Addendum's edition 2.24 describes (its Section 2), and the Terms' edition 9.0 states their limits (Section 15, item 9); nothing else in this Policy changes for them. 6.13 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes mail the platform did not send before — mail from an application's preview, which goes only to the person who started that preview — reduces no right and adds no obligation; effective on posting, 2026-10-25; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged; the Data Processing Addendum's edition 2.25 makes the matching disclosure). Section 2's bullet on confirmed and unsubscribed addresses now states that mail the platform sends from an application's preview is the exception to the platform's link and the unsubscribe that the platform's messages for an application otherwise carry: it goes only to the address that the person who started that preview from the console signs in to the platform with, whether or not that address is confirmed for the application, without the platform's link and without an unsubscribe, and never to an address unsubscribed from the application. 6.14 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a new, optional feature and the checks that go with it, reduces no right and adds no obligation — the confirmation the feature asks for is the Terms' own, in their edition 10.0, Section 10.5 — and the instruction it states for more requests, that no provider retain them, is in your favour; effective on posting, 2026-10-25; published with the Terms' edition 10.0, the Data Processing Addendum's edition 2.26, whose Section 4 records that OpenRouter, Inc.'s function is widened to the new platform roles this edition names and that Microsoft Corporation (its Azure service) and Deep Infra Inc. are engaged for a new purpose, and the Platform Rules — Content-Safety Taxonomy's edition 2.2). A new Section 2.8, photos you add to your apps: you may add your own photos to an app the platform builds for you, when you approve its plan or later on its page in the console, and the app shows them where they fit; before your first photo for an app you confirm a short statement on screen, that you may use the photos you add to that app, including on its public site, and that everyone who can be recognised in them has agreed to appear in it (for a child, their parent or guardian has agreed), of which the platform keeps an append-only record — its exact wording, the app it covers, who confirmed it, by their sign-in identifier, and when — kept as Section 8 states for the affirmations; each photo is stored in the platform's private storage on Amazon Web Services and scanned there for malicious software by Amazon GuardDuty before anything else reads it, a file in which the scan finds such software being never opened by the platform, used or shown, and the console saying why; any other photo, one the scan cannot judge included, for which the platform's own image reader, accepting JPEG, PNG, WebP and AVIF images alone, is then the only check, is opened in an isolated process within fixed limits and the platform prepares from its pixels alone a small set of copies, in several sizes and web formats, carrying nothing else of the original file — not where or when the photo was taken, not the camera or phone, not any other embedded data — keeping the original file only until the check for prohibited content has passed the photo, or for as long as a hold lasts, keeping no file name, and using the photos to recognise or identify no one; before your app may use a photo, and before anyone outside your account but RunMyB's operating team can see it, the platform checks it automatically for sexually explicit content, any sexual depiction of a person who may be a minor and graphic violence, with an AI classifier that receives one prepared copy, at most 1280 pixels wide, and the platform's instructions — never the photo's description or a detail of your account — through OpenRouter, Inc. under RunMyB's own account and key, which routes the request to the one provider the platform names for the classifier it asks, today Microsoft Corporation (its Azure service) for the classifier asked first and Deep Infra Inc. for those asked next, in a fixed order, when that one cannot answer, under a routing instruction that allows that one provider only, only where OpenRouter records it as neither using request data for training nor retaining it, and never another provider in its place; the check is an automated assessment of what a photo shows, including whether a person in it may be a minor and whether it is sexual, recording a label about the photo, never a trait of a person, and deciding only whether the photo may be used in your app and nothing about the people it shows; until a classifier has answered the photo stays unused and the platform tries again, a photo no classifier answers for going to a person at RunMyB; a photo the check finds to show sexually explicit content or graphic violence is held — kept, not deleted and not used — the console saying what was found, that it was decided automatically and how to contest it; a photo the check finds may sexually depict a minor, a photo a provider declines to look at and a photo for which the platform cannot show that the classifier received the image go to a person at RunMyB before anything is decided, the console saying that a person is checking it; you may remove a photo the check held, which deletes it, and erasing your app or your account deletes it too, while a photo that is with a person at RunMyB before anything is decided, and a photo RunMyB holds because of a notice or because the law requires it to preserve it, you cannot remove, the app and your account not being erasable while such a photo is in your app, and it stays as it is until RunMyB decides on it and for as long as the law requires, RunMyB aiming to decide on such a photo within 14 days; a hold on a photo your app already shows keeps it out of the app from the app's next update; nothing is reported to anyone automatically, and apparent child sexual abuse material a person finds is preserved and reported to NCMEC where US law requires, RunMyB also informing law-enforcement or judicial authorities of an EU Member State, or Europol, where a person finds information that gives rise to a suspicion of a criminal offence threatening the life or safety of a person — apparent child sexual abuse material treated as such — as Article 18 of the EU Digital Services Act requires; and RunMyB makes the check as controller, on its legitimate interest in not hosting content that is illegal or that its rules prohibit or restrict, which includes preserving what it finds and reporting it to NCMEC as US law requires, and, where EU or Member State law requires it to preserve or report what it finds, as Article 18 of the EU Digital Services Act does, to meet that legal obligation, not as processing on your behalf; each photo the check has passed needs a short description for visitors who cannot see it, which you may write, replace with a mark that the photo is decoration only, or take from the platform's suggestion, written by an AI model, the photo describer, in your app's language, instructed to name no one and to guess at no one's identity, health, origin, beliefs or other sensitive trait, the console marking the suggestion as written by AI, the suggestion becoming your app's text only once you confirm it, as it stands or after editing it, and a photo whose description you have not confirmed not being used in your app; for each such photo one request carrying one prepared copy, at most 1280 pixels wide, your app's language and the platform's own instructions — never your name, your e-mail address or another detail of your account — goes to OpenRouter, Inc. under RunMyB's own account and key, which routes it to a provider of the model the platform has configured for the photo describer, with the routing instruction that excludes providers whose terms allow the use of request data for model improvement and a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data, the platform suggesting no description where no such route can serve it; the prepared copies and the confirmed descriptions are placed among your app's working files, where the AI models that build your app read them, what they open going to those models' providers as the rest of your app's working files does, a request that carries, or may carry, an image from them or a picture of your app's screens also carrying that zero-retention routing instruction or going without the image, and a published app's visitors receive the copies it shows from the app's own address; RunMyB does not use the photos or their descriptions to train any model and does not permit any provider to do so on its behalf; what RunMyB keeps for each photo — among it the result of the scan for malicious software and the size and a checksum of the file you added, never the file itself once the check has passed the photo — is kept with the app until you remove the photo or the app is erased, the record of the check of a photo it passed being kept as long as the photo and deleted with it, and the record of the checks of any other photo, and of what RunMyB decided about it, with the reasons stated to you, being kept with the app until the app is erased, or for longer where the law requires RunMyB to preserve it; a photo you remove leaves your photos at once and your app at its next update, the earlier versions of your app that the platform keeps — those it published, kept so that your app can be restored to one of them, and those it prepared for previews — and the platform's copy of your app's code history keeping it until the app is erased unless a person shown in it asks to have it erased and you instruct RunMyB to erase it, by writing to privacy@runmyb.com, when RunMyB's operating team removes it from them, and the platform's storage backups keeping a copy for 35 days, while the copy of your app's code at your own git provider is yours to clean; who sees the photos, RunMyB's operating team seeing a photo the check holds or sends to a person, and deciding on it; and RunMyB's role — for the people your photos show you are the controller and RunMyB your processor under the Data Processing Addendum, their agreement, telling them what your app does with their image and a lawful basis for any special category of personal data a photo reveals being yours, the record of your confirmation being RunMyB's own evidence of what was confirmed, kept on its legitimate interest, and the check and its record being RunMyB's own; and a person shown in a photo on an app hosted here who writes to RunMyB about it is told that RunMyB passes the request to the app's owner, who answers for it, unless the owner has instructed RunMyB otherwise or the law requires otherwise (the Data Processing Addendum's Section 3(e)), except for the check and its record, which are RunMyB's own and which RunMyB answers for. Section 1 names RunMyB as the controller for the automated check of each photo added to an application hosted on the platform, with the record of that check, and its first processor bullet names the people shown in the photos you add to your applications. Section 2's bullet on ventures, products, documents and conversation turns states that this content includes the pictures the platform itself takes of a product's screens — its pages at computer and phone width, the screens its checks walk through and the design variants it offers you — which may show what the product holds about its own users, and that the AI models that design, verify, review, repair and change the product receive them, as does the console's assistant when you ask it about a build; and that, where a product's files hold photos, a request that carries, or may carry, a picture of the product or an image from its files also carries a routing instruction under which OpenRouter sends it only to a route it records as retaining no request data, the picture or image being left out where the request's model has no such route or the request cannot carry that instruction. Section 2 gains the bullet for the photos, with the bases. Section 5.1's OpenRouter row names the check of the photos among the automated content-safety checks, with its providers — today Microsoft Corporation (its Azure service), serving OpenAI's model, in the European Union where the platform names Azure's endpoint there and otherwise wherever Azure serves the request, which may be the United States, and Deep Infra Inc. for the classifiers of other makers asked next — under the one-provider, no-training, no-retention routing instruction; names the photo describer, whose requests also carry the zero-retention routing instruction, among the other platform roles OpenRouter routes; states the zero-retention routing instruction for each request that concerns an application whose files hold photos and carries, or may carry, a picture the platform took of that application or an image from its files, the picture or image being left out where the model has no such route or the request cannot carry that instruction; and states that the requests routed to DeepSeek's model carry no instruction that requires a zero-data-retention policy except as the row states for such a request. Section 7 states that the check's requests routed to Microsoft's Azure service or to Deep Infra Inc. are an onward transfer under OpenRouter's terms with that provider, which the Clauses incorporated in OpenRouter's Data Processing Agreement (Module Two, Clause 9) oblige OpenRouter to make under equivalent protections, Microsoft Corporation being certified under the EU–US Data Privacy Framework and Deep Infra Inc. not being a participant. Section 8's affirmations bullet names the confirmation you give before your first photo for an app; a new bullet states how long the photos and the records of their checks are kept, as Section 2.8 does; and the content-safety records bullet states that the records of the check of the photos are kept as that bullet states. Section 9 names that confirmation among the affirmations retained at erasure; states that each photo you add is scanned for malicious software by Amazon GuardDuty before anything else reads it, a file in which the scan finds such software not being used or shown, and the console saying so, that the decision was made automatically, and how to contest it through the appeal route; and states the check for prohibited content as an automated assessment of what a photo shows, including whether a person in it may be a minor and whether it is sexual, deciding only whether the photo may be used and nothing about the people it shows, a photo it holds being kept, never deleted by the check, the console saying what was found, that the decision was made automatically and how to contest it, and a contest being decided by a person at RunMyB, never by the automated check. The new front-matter key states_owner_photos records that this notice states the feature. Also in 6.14, a disclosure (NON-MATERIAL under the Terms' Section 24: it reduces no right and adds no obligation — the withholding it describes is the Terms' own, in their edition 10.0, Section 15, item 8): Section 2 names, among the notices by e-mail, the notice that a file one of the account's products stores was withheld because the platform's scan found malicious software in it, which has no setting, comes at once unless the law requires, or a public authority asks, RunMyB to delay it and describes the file by its kind, its size and when it was stored, never by its name, and the notice that files a product stores cannot be scanned, among the notices about products going live; Section 9 states that every file an app hosted on the platform stores for its users is scanned for malicious software by Amazon GuardDuty, in the platform's own storage on Amazon Web Services in the United States, soon after it is stored, GuardDuty deleting its copy once the scan is done and RunMyB letting Amazon Web Services keep or use none of the files it scans for a purpose of its own, GuardDuty's record of a file it finds malicious being one of the platform's security records; that a file in which the scan finds such software is withheld automatically, kept and no longer served, the account's administrators being e-mailed, unless the law requires, or a public authority asks, RunMyB to delay it, the reasons and how to contest the decision through the appeal route, which a person at RunMyB decides, never the scan; and that the scan looks only for malicious software, identifies no one and decides only whether a file may be served, RunMyB being the app owner's processor for these files; and Section 5.1's row for Amazon Web Services names the scan of the files the hosted apps keep and of the photos you add to them (Amazon GuardDuty). 6.15 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a new feature — the messages people write in the contact form of an application hosted on the platform, which the platform keeps for the application's owner — and a new notice about them, reduces no right and adds no obligation; effective on posting, 2026-10-27, published with the Terms' edition 10.2 and the Data Processing Addendum's edition 2.27; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged). Section 2 gains a bullet on messages to the applications hosted on the platform: when someone writes to such an application through its contact form, the application's own server hands the platform the message, the reply address and, if given, the name, which the platform keeps with when the message arrived and shows in the console, as plain text with any link shown as text, to the members of the application's account who can see the application — for an application that only one member of the account can see in the console, to that member alone — and which are part of the account's data export; the platform does not check who wrote a message or what it says, sends nothing to the reply address, lets no AI model or assistant read a message and acts on nothing a message says; the members who can see the application can delete a message and switch its inbox off and on, the platform keeping a record of who did so and when; the platform takes no message while the inbox is off, while the account is suspended or terminated, beyond its daily limits or from a preview; for the people who write, the application's owner is the controller and RunMyB its processor under the Data Processing Addendum, RunMyB passing a request about a message to the owner; and RunMyB keeps, as an independent controller, a daily count for each application and reply address that identifies the address only by a hash made with a secret key. Section 8 states that a message is deleted after 90 days from its arrival, and sooner when a member deletes it or the application or the account is erased, that the record of the inbox's switch is kept for as long as the application exists, and that the count is kept for the day it counts and the following day. Section 1 names the messages among what RunMyB processes for an application's owner and the count among the records RunMyB keeps as controller. Section 2's bullet on notices by e-mail names the notice that someone wrote to one of the account's products through its contact form, which carries nothing of what was written, and the group of notices it belongs to, and states that the notice about a product that only one member of the account can see in the console goes to that member alone, whether or not they are an administrator; Section 3 names those notices among the platform's own records about a member. 6.16 — a disclosure, a clarification and a new restriction on RunMyB (NON-MATERIAL under the Terms' Section 24: it names the period for which the platform's own records of the e-mail it sends and refuses to send are kept and that they are kept after an account's erasure, and describes what the console now shows of those records, a new record that bounds look-ups in them and what the data exports carry, reducing no right and adding no obligation; effective on posting, 2026-10-27, published with the Data Processing Addendum's edition 2.28; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged). Section 2's bullet on e-mail delivery records covers the messages an application hosted on the platform asks it to send and the platform's record of the messages it refuses to send, with the reason, and states that RunMyB keeps them as an independent controller, also for the people an application asks it to write to. A new bullet states what the console shows of those records: a person sees the platform's notices to them about the account and about the service, with what became of each, and the other e-mail sent them for that account; the members of an application's account who can see it see the messages the platform sent or refused to send for it and what became of each, never the address, and may type one address to see which of the application's messages went to it and what became of each, including that the person reported one as spam, or that one was not sent because the person had unsubscribed or because the address is suppressed or paused, the address being matched by its hash, shown back only in part and not kept, a limited number of such look-ups a day for each member in an account, which the console states, on RunMyB's and the owner's legitimate interest; RunMyB keeps a daily count of each member's look-ups; the account's data export carries the records of the e-mail sent or refused to its members' sign-in addresses for the account, and a member's own export their own, without the hash, while the records of an application's e-mail to its own users and of RunMyB's notices about the service are part of no account's export and are given on request. The bullet on confirmed and unsubscribed addresses states that a member who types one address sees which withheld or replaced messages concerned it. Section 1 names the records of what became of the messages the platform sends or refuses to send among the records RunMyB keeps as controller; Section 3 names those records and the look-up count among the platform's own records about a member; Section 3.2 adds to the self-export the member's notices and the records of the e-mail sent them for the account, and states that the account's administrators can download that bundle too. Section 8 states that the platform's records of each message and of the messages it refused to send are kept for 13 months, also after the application or the account is erased, then deleted, that the record of a pause after repeated bounces, which names no account and is not deleted with one, is kept for 13 months, that the records of RunMyB's notices about the service are not deleted with an account and are deleted 30 days after the notice was sent, skipped or failed, and that the look-up count is kept for the day it counts and the following day; Section 9 names those e-mail records among what is retained on erasure. 7.0 — a narrowed commitment and a disclosure (MATERIAL under the Terms' Section 24: it narrows a protection you had, the commitment that Google user data is never sent to a model made by DeepSeek, so the re-consent gate fires and renewed acceptance is required; effective on posting, 2026-10-28; the Data Processing Addendum's edition 2.29 makes the matching change to its Section 7, put to the Customer for renewed acceptance through this edition; no sub-processor is added or replaced, OpenRouter remaining the sub-processor, so the Data Processing Addendum's Section 4 mechanism is not engaged). Section 5.3 states that Google user data is never sent to DeepSeek's own service, even where a DeepSeek model has been chosen for the work that would carry it; that a request carrying Google user data may be served by a model made by DeepSeek only where RunMyB sends it on its own OpenRouter account, and only under three routing instructions — the one that excludes every provider whose published data policy, as OpenRouter records it, allows the use of request data for training or model improvement, one that excludes DeepSeek as a provider, whatever OpenRouter records of its policy, and one under which OpenRouter sends the request only to an endpoint that OpenRouter lists as having a zero-data-retention policy — so that a DeepSeek model is served for such a request by a provider other than DeepSeek, whose published data policy, as OpenRouter records it, does not use request data for training, at such an endpoint; that the zero-data-retention instruction applies to the whole request, a model of another maker named for the same request, as its model or as a fallback, being served only at such an endpoint too, and that where OpenRouter has no such endpoint for the request it is not served; and that RunMyB's model gateway adds the instruction that excludes DeepSeek as a provider to every request it composes for a conversation, venture or run that the record shows to hold Google user data, or where it cannot establish what that record shows, and the zero-data-retention instruction to every such request that names a DeepSeek model, as its model or as a fallback, refuses before sending any such request to a DeepSeek model unless RunMyB sends it on its own OpenRouter account under the three instructions, records each such request in the audit record, and raises an alarm and opens an incident should OpenRouter report DeepSeek as the provider that served one, or report no provider for one that a DeepSeek model served. Until this edition, Section 5.3 stated that Google user data was never sent to a model made by DeepSeek, whichever provider would serve it, and that work which would otherwise have been served by a DeepSeek model was served by another model the platform admitted for it or refused; from this edition a DeepSeek model may serve such work under those instructions. Unchanged: the commitment that Google user data trains no model, the record of where Google user data is and how it follows the content, the two fixed routes, the audit record and its retention, and the refusal of a DeepSeek model for the requests of an application you run on a key of your own where its venture holds Google user data. Section 5.1's OpenRouter row states that a request carrying Google user data is routed to DeepSeek's model only on RunMyB's own OpenRouter account, under a routing instruction that excludes DeepSeek's own endpoint whatever OpenRouter records of its policy and one under which OpenRouter sends it only to an endpoint that OpenRouter lists as having a zero-data-retention policy, such a request being the second exception to the row's statement that the requests routed to DeepSeek's model carry no zero-data-retention instruction; Section 7 states that the requests OpenRouter routes to DeepSeek's model include those that carry Google user data, which are never routed to DeepSeek's own service; Section 5.2's Drive and Calendar bullets state that such data never goes to DeepSeek's own service; Sections 5.2 and 5.3 refer to the providers that Section 5.1 names or describes, the providers of DeepSeek's model being described there by the rule that chooses them; Section 2 states that the record of the requests also serves to keep Google user data away from the providers Section 5.3 excludes. This edition also carries a disclosure about e-mail to the applications hosted on the platform and answers to the platform's notices, NON-MATERIAL on its own and riding this edition's renewed acceptance (published with the Terms' edition 10.3): Section 2's bullet on messages to the applications hosted on the platform now also covers e-mail — an application the platform hosts with a server of its own may also have an e-mail address of its own on the platform, made from its address on runmyb.app, and e-mail sent to it reaches the application's inbox whether or not the application shows the address; the platform receives such e-mail through Amazon Web Services' mail service, which scans it for viruses and spam, holds it as received only until it has delivered it or counted it as not delivered, and delivers it only if that scan found neither, if it is within the platform's size limit and if its sender's address passes the e-mail authentication of its own domain or of a domain related to it, which shows the mail service the e-mail came through, not who wrote it, and only while the inbox is on, the account neither suspended nor terminated and within the platform's daily limits, for the application and for each sender's address; of an e-mail it delivers it keeps the sender's address and name, the subject, the text as plain text with any link written out as text, cut at a set length, the list of attached files and which authentication the sender's address passed, and keeps only attached files of a few common kinds whose contents match the kind they state, which the platform never opens or runs, which the members who can see the application download under a name the platform gives them, which are deleted with their e-mail and which are not part of the account's data export; an e-mail it does not deliver is deleted once counted, by day and reason, for the application, and its sender is sent nothing; and RunMyB keeps, as an independent controller, for each application and each address that sends it e-mail, a daily count of the e-mails the platform delivered, identifying the address only by a hash made with a secret key. Section 2's bullet on notices by e-mail names the notice that someone wrote to a product by e-mail to its own address, and states that a notice about the account carries a reply address of the platform's own, the notice that someone wrote to a product, a daily summary that includes one, and RunMyB's notices about the service itself carrying none: an answer by e-mail from the address the notice went to, by a member of the account, is kept as text, without its subject or attached files, as a message to that member in their Messages in the console, where it decides nothing and none of the platform's assistants is shown it, any other answer being deleted with nothing of it kept; Section 3.1 names those answers among the member's messages. Section 8 states that an e-mail delivered to an application, with what is kept of it and the files kept from it, is deleted after 90 days from its arrival, and sooner when a member deletes it or the application or the account is erased, that the count by the address an e-mail came from is kept for the day it counts and the following day, and that an e-mail as received is kept only until it is delivered or counted as not delivered, then deleted within minutes. Section 1 names that e-mail and the files kept from it among what RunMyB processes for an application's owner, and Section 5.1's row for Amazon Web Services names its receiving of that e-mail and of the answers to the notices, with the scan for viruses and spam; Amazon Web Services was already listed, so no sub-processor is added or replaced by this part either. 7.1 — a disclosure and a change in your favour (NON-MATERIAL under the Terms' Section 24: it describes how the platform's identity provider sends its messages about signing in to the console and what the platform keeps of them, reducing no right and adding no obligation; effective on posting, 2026-10-29; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged). Section 2's bullet on account and identity states that your login identity — the address you sign in with, and the password you set, which the platform never reads — is held by the platform's identity provider, Amazon Cognito, a service of Amazon Web Services, which also sends you its own messages about signing in to the console — an invitation with a temporary password, and any code it sends you for signing in or for a new password — from the address account@mail.runmyb.com, through the platform's mail provider but not through the platform's own code, the platform receiving the mail provider's reports on them. Section 2's bullet on e-mail delivery records covers those messages, and states that an address on the platform's suppression list and on the mail provider's receives no further e-mail, the identity provider's messages included, until RunMyB removes it from them, which you can ask it to do; its bullet on what became of an e-mail states that the records of the identity provider's messages concern no one account, are part of no account's export and are shown in no account's view in the console, RunMyB giving a person the records about them on request. Section 5.1's row for Amazon Web Services names the identity provider, Amazon Cognito: a description of an existing sub-processor's function, Amazon Web Services being already listed. 7.2 — a disclosure (NON-MATERIAL under the Terms' Section 24: it describes a piece of data the platform now processes to provide the service you ask for, the time zone your browser reports, reducing no right and adding no obligation; effective on posting, 2026-10-29, the day edition 7.1 is posted, published with the Cookie & Tracker Notice's edition 3.4; no sub-processor is added or replaced, so the Data Processing Addendum's Section 4 mechanism is not engaged). Section 2 gains a bullet, after the one on the language you last used, stating that the console sends, with each message you send in a conversation, the name of the time zone your browser reports, such as Europe/Warsaw; that the platform keeps it, if its time-zone database knows the name, with that message and, where the message leads to a product's plan, with the run that plans the product and in the plan, as the product's time zone unless you name another, which the plan states before you approve it; that it reaches the AI models that write the plan and work on the product, and may reach the platform's assistant when it reads the plan for you and, with the run's records, the activity narrator's model; that, unlike your language, it is not remembered for you; and that it is processed so that the times of the product you ask for follow your own time zone.