Privacy Policy
Dailies Render, Inc.
1. Who we are and what this policy covers
Dailies Render, Inc. (“Dailies”, “we”, “us”) provides an API that renders talking-actor ad variants from a manifest a customer's scheduled job posts: it generates each performance from a script and a licensed actor, captions and cuts it, fits the customer's brand kit and product clips, and returns finished vertical video files with a per-second cost line for each.
Registered at 1355 NW Everett Street, Suite 200, Portland, OR 97209, United States.
We handle personal data in two different situations, and different rules apply to each:
| Whose data | Our role | What applies | |
|---|---|---|---|
| Part A | People who visit this website, ask about the service or write to us | Controller: we decide why and how the data is used | This policy |
| Part B | People who appear in or are named in a customer's scripts and product clips, the licensed performers in our actor catalog, and the customer's staff who hold keys and review jobs | Set out in B.1, because it depends on the data | This policy and the data processing agreement we sign with each customer |
If the data processing agreement (“DPA”) and this policy ever disagree about Part B, the DPA wins.
2. Part A: this website and our contact with you
This part covers the personal data we collect for our own purposes: running this website, answering requests, and staying in touch with people who are or might become customers.
A.1 What we collect
What you give us. When you send the form on this site, we collect what you type into it, such as your name, email address, phone number or company, and the fact that you agreed to be contacted. If you email or talk to us, we keep that correspondence and any contact details in it.
What is collected automatically. Our web server records the IP address a request came from, the browser used, the pages requested, the page you came from and the time. These logs exist to keep the site running and secure.
We don’t ask for sensitive data (the “special categories” in Article 9 GDPR) through this website, so please don’t send any through the form.
A.2 Why we use it, and what allows us to
| Why | What | Legal basis (GDPR Art. 6) |
|---|---|---|
| Answering your request and working out whether the service fits | What you sent in the form, our correspondence | Art. 6(1)(b): steps you asked for before a contract |
| Looking after customers, billing and support | Contact details, correspondence | Art. 6(1)(b): carrying out a contract |
| Keeping the site running, secure and free of abuse | Server logs | Art. 6(1)(f): our legitimate interest in running a secure service |
| Contacting you about the service | Email address, company | Art. 6(1)(f): our legitimate interest in business-to-business marketing. You can object at any time |
| Meeting tax, accounting and legal duties | Billing and contract records | Art. 6(1)(c): a legal obligation |
Where we rely on legitimate interest, we have weighed that interest against your rights, and you can ask to see the assessment.
A.3 How long we keep it
- Requests from people who don’t become customers: 12 months from our last contact, then deleted.
- Customer contact and contract records: for the length of the agreement plus 6 years, to cover legal claims and accounting rules.
- Server logs: 30 days.
- A record that you objected or opted out: kept indefinitely, so we can keep respecting it.
A.4 Your rights
If you are in the EEA or the UK, you can ask to see your data, correct it, have it deleted, limit or object to how we use it, get a copy you can take elsewhere, and withdraw consent where we rely on it. Write to [email protected] and we will answer within one month.
You can also complain to a data protection authority. If you are in the EEA, that can be the authority where you live or work.
3. Part B: data inside the service
Our customers are brands and studios that post manifests to our endpoint from their own scheduled jobs. A manifest carries scripts, a choice of actor and voice, and references to a brand kit and product clips the customer uploaded. This part explains what is in a job, what we do with it, and where it is kept.
B.1 What we handle, and in what role
For everything inside a manifest, a brand kit and a finished file we act as a processor: the customer decides what is scripted, what footage is uploaded and when a file is released. For the accounts of the customer's staff and for our performer catalog we act as a controller. Inside the service we handle:
- Manifests. Scripts in three named parts, actor and voice identifiers, B-roll markers, variant names, and the ad account and ad set named when a push is requested.
- Brand kits and product clips. Fonts, caption styles, end cards, logos, and the screen recordings or product footage uploaded to fill B-roll markers. We ask that these clips not show identifiable people unless the customer holds a release for them.
- Finished files and job reports. The rendered MP4s, each variant's finished seconds and cost line, sync scores, screen flags with their reasons, and the release, hold and drop decisions with the member's name and time.
- Member accounts and keys. The name and work email of each member, the sandbox and live keys issued to the workspace, and the runner named at signup.
We do not receive a customer's ad account credentials beyond the token scope needed to create paused ads in a named ad set, and only when the customer connects that account. We do not read performance data from any ad account.
The voices in the catalog are synthetic and the actors are licensed performers. We do not accept footage of a customer's own people as an actor and cannot build a likeness from it.
B.2 What we do with it
Storage. Manifests, brand kits, product clips, finished files and job reports are stored encrypted on cloud infrastructure in Oregon. Each workspace's data is held under its own key and is not readable from another workspace.
Rendering. Speech, the actor's performance and caption alignment are produced by models we serve ourselves on cloud GPU capacity we control in Oregon. No script, clip or frame is sent to a third-party hosted model API.
Screening. Each script is screened for claim categories ad platforms reject by a classifier running on the same cloud GPU capacity we control in Oregon. A flag is written to the job report with its confidence and reason; it holds a variant, it never deletes one.
Labeled records. Each release, drop and hand-corrected caption is stored as a labeled record (the script line, the flag and the decision) inside the workspace. Those records tune that workspace's own screen. They are used to train the screen all customers use only if the workspace owner has opted in, and that training runs on cloud GPU capacity we control in Oregon.
Ad account push. On an approve call naming an ad set, we upload the finished file to that ad set as a paused ad carrying the variant name and, on TikTok, the AI-generated content label. We hold the account token for that purpose only and delete it when the account is disconnected.
Staff access. Our staff open a customer's jobs only to resolve a support request the customer raised, only for the workspace named in it, and every such access is written to the workspace's audit log.
B.3 AI models: where they run and what they learn from
Where models run. Four models run inside the service: a text-to-speech model that reads each script in the chosen voice, an audio-driven video model that renders the actor's performance from that speech, a forced-alignment model that places each caption word on the frame it is spoken, and a classifier that screens scripts for claim categories ad platforms reject. All four are models we serve ourselves on cloud GPU capacity we control in Oregon, beside the manifests, clips and finished files, which are stored on cloud infrastructure in Oregon. No script, clip, frame or finished file is sent to a third-party hosted model API by us. A push to an ad account sends the finished file to that platform under your own account and is governed by your agreement with the platform.
Training. We do not train models on customer scripts, product clips, brand kits or finished files. The actor model is fine-tuned only on footage of performers who have licensed it to us under a written contract, and no customer footage enters it. The one exception on the customer side is the labeled-record corpus: when a member releases, holds, drops or corrects a variant, we store the script line concerned, the screen flag and the decision, not the finished file and not the clips around it. Inside a workspace those records belong to the customer and are not shared between customers; they tune that workspace's own screen, so that the same kind of line is held or released the way the team decided last time. The screen all customers use is trained on labeled records only from workspaces whose owner has opted in. The opt-in is off by default, can be withdrawn for future training, and contributed records are limited to the script line, the flag and the decision. That training runs on the same cloud GPU capacity we control in Oregon, and contributed records do not leave it. Retrieval over a workspace's own labeled records, planned for September 2027, will read only that workspace's records.
Where a person decides. The models render; people release. Every take gets an audio-visual sync score, and a take under 0.80 is re-rendered with a new seed, twice at most, before it returns as failed and unbilled rather than shipped. A screen flag above 0.85 confidence holds the variant in the job report with its reason for a named member to release or drop; below that threshold the variant renders with the note attached, and a flag never deletes a variant. Every finished file starts in hold, and nothing reaches an ad account until an approve call from the customer's workspace names it. No output of the service is an automated decision with legal or similarly significant effect on any individual: the service renders advertising from a customer's script, and the decisions about people in it, the performer's license and the customer's releases, are made by contract and by the customer's staff, not by a model.
B.4 Where the data is kept
All data inside the service is stored and processed on cloud infrastructure in Oregon, United States. Model inference runs on cloud GPU capacity we control in Oregon, and so does any tuning of the script screen on labeled records a workspace has opted in to contribute. We keep no copy outside the United States.
Customers outside the United States should note that using the service means their manifests, clips and finished files are transferred to and held in Oregon. A push to an ad account sends the finished file to that platform under the customer's own account, and what the platform does with it is governed by the customer's agreement with the platform.
The suppliers that handle data in the service are named on our subprocessor list, which comes with the data processing agreement and which we send to anyone who asks: write to [email protected].
B.5 How long we keep it, and what deleting can’t remove
Finished files and job reports are kept for 90 days from the job's close and then deleted with their thumbnails and cost lines. The customer's runner is expected to copy the files it wants to keep into its own storage; the webhook fires so that it can.
Manifests are kept for 90 days beside their job. Brand kits and product clips are kept until the customer deletes them or the workspace closes.
Labeled records are kept for the life of the workspace. When a workspace is closed, the customer can export job reports, cost lines and labeled records as JSONL for 30 days. After that everything in the workspace is deleted, and backups roll off within a further 35 days.
B.6 Requests from people whose data is in the service
The customer is the controller of what its scripts say and who appears in its product clips. If a person asks us about their data in a manifest or a clip, we pass the request to the customer within five business days and do not answer it ourselves. Performers in our catalog contract with us directly and can withdraw an actor from the catalog for future jobs on 30 days' notice; finished files already rendered belong to the customer and are not recalled. A member of a customer's staff can ask us to delete their account, and we do so within 30 days.
For everyone
4. Moving data between countries
Dailies Render, Inc. is a company in the United States. When personal data from the EEA or the UK reaches us, for example because someone there writes to us or a customer there uses the service, it is protected by the European Commission’s Standard Contractual Clauses, a transfer impact assessment and the extra technical measures described in our security documentation. You can ask us for a copy of the clauses.
EU representative (Article 27 GDPR). Write to [email protected] with “EU representative” in the subject line and we will send you our representative’s details.
5. Security
We protect data in line with the risk. That includes encryption in transit and at rest, access limited to the people and systems that need it, each customer’s data kept separate from every other’s, and a log of every access to production systems.
If a personal data breach affects you, we tell you without undue delay, and at the latest within 36 hours of finding out, with the information you need to meet your own reporting duties.
6. Children
The service is sold to businesses and is not meant for children. We don’t knowingly collect personal data from anyone under 16.
7. Changes to this policy
We may update this policy. If a change matters, we email customers at least 30 days before it takes effect. The version number and date at the top of this page change every time.
8. Contact
Privacy questions and anything else: [email protected]
By post: Dailies Render, Inc., 1355 NW Everett Street, Suite 200, Portland, OR 97209, United States