Privacy notice
What we collect, why, who else sees it, how long we keep it, and what you can ask us to do about it. Written to the disclosure requirements of the EU GDPR and the UK GDPR, in plain language.
Last updated 9 September 2026. Applies to VarnaOps as offered in the United States, the European Union and the United Kingdom.
- We hold your sign-up details and email, the file you upload, your results, your run and billing records, and service logs.
- We use them to run your analysis, run your account, take payment, and keep the service working.
- Uploads go after 7 days, results after 30 days, logs after 30 days, and our record of who touched a file after 400 days.
- Your browser holds your sign-in and what you typed into the wizard, on your own device; signing out clears it.
- One person, the founder, can reach stored files, and since 31 August 2026 every access is recorded.
- Amazon Web Services supplies the language model that some steps call, through Amazon Bedrock and inside our own AWS account: it gets metadata and text, never your expression matrix, and keeps none of it. Until 9 September 2026 this was a second company, Anthropic, which kept what it got for 30 days.
- You can submit any run with the no-model option, which makes no language-model call at all.
- You delete a run, or your whole account, yourself from the site, and you can ask to see, correct or export your data by writing to us, and we set no advertising cookies and run no third-party analytics. Our web host does count page requests by country, with no address, no browser detail and no cookie, and we keep an anonymous record of which analyses are chosen, with nothing in it that points at you, your file or your run.
This summary is for orientation; the full text below is what applies.
- Who we are
- Where we are established
- What we collect
- Why, and on what legal basis
- Who at VarnaOps can reach it
- Who else sees it
- Where it is processed
- How long we keep it
- Your rights
- Deleting a run or your account
- Complaints
- Automated decisions
- Where your data goes: the language-model steps
- Other deployment models
Who we are, and how to reach us
For your account, billing and run records, the controller of your personal data, meaning the company that decides why and how it is processed, is the company below. For the contents of the file you upload, the roles are reversed: you (or your institution) decide why it is processed and we process it on your instructions, as your processor:
| Legal name | VarnaOps LLC |
| Registered address | 30 North Gould Street Ste N, Sheridan, WY 82801, United States |
| Registration number | 2026-001911287 (Wyoming Secretary of State Filing ID) |
| Contact | support@varnaops.com |
For anything in this notice, including any request about your data, write to support@varnaops.com. That address is read by a person and is the fastest route to us.
Data protection officer
We have not appointed a data protection officer, and we are not required to. Art. 37(1) of the GDPR applies to public authorities, to core activities that monitor people regularly and systematically on a large scale, and to core activities that process health data or other special-category data on a large scale. We are a one-person company processing a small number of research cohorts on our customers' instructions: what your file contains is processed for your purposes, which makes us your processor for that content, while we remain the controller of your account, billing and run records.
The controller-and-processor split is written out in our Data Processing Agreement, which is incorporated into the terms of use and accepted by ticking the box when you sign in.
Where we are established, and our UK representative
VarnaOps LLC is registered in Wyoming, but the business is operated from Italy, and that is what matters here. Under the GDPR, being established somewhere turns on actually carrying on the activity there through stable arrangements; Recital 22 says in terms that legal form is not the deciding factor. Running the service from Italy makes us established in the European Union, so the GDPR applies to us directly under Art. 3(1), and the Art. 27 requirement to appoint a representative in the Union does not apply, because it is addressed to controllers who are not established there.
Practically, that means a person in the EU deals with us, not with a stand-in, and can take a complaint to the Italian authority named under complaints below.
The United Kingdom is a separate question
Being established in Italy answers the EU question and not the UK one. Since Brexit the two regimes run separately, so for the UK GDPR we are a controller not established in the UK, and Art. 27 of the UK GDPR applies once we offer the service to people there. We have not appointed a UK representative. We will assess whether one is required as UK users join; ask us for the current position.
A representative is not a data protection officer and the two are not alternatives. Not needing the second, as set out above, says nothing about the first.
Both readings above are our own assessment of the Regulation against how the business
actually operates, recorded in web/controller.json. They are not advice
from a lawyer.
How your data is handled today
Your data is processed to produce your result. Parts of the pipeline call a third-party language model to do that, so some of what you send reaches a sub-processor: which parts, and which ones never do, are set out under where your data goes below. The table here reflects how the current pipeline works.
| Aspect | How it works today |
|---|---|
| Your data | Each run executes as its own container, on its own machine: a job reserves that instance's only GPU, so two runs are never on one, and the instance and its disk are destroyed when the run ends. A running job cannot reach the upload area at all: to read the file you gave it, the container has to ask for a short-lived link to that one object, and the link is issued only after a check that the request came from that job's own container. The area holding finished results is not separated that way yet, so reaching your stored upload and results is limited to the service itself and to one named administrator, and access to them is recorded. Both are set out under who can reach your data. |
| Model training | Your data is never used to train or improve our models. Models are trained only on public reference atlases. |
| Reference atlases | Built solely from public, properly-licensed data (the CZI CELLxGENE Census, CC BY 4.0), never from customer data. |
| In transit & at rest | Uploads and results move over encrypted connections and are stored encrypted in cloud object storage. |
| Your results | Returned to you as a self-contained, reproducible report; the run records its own provenance. |
| What we need | The pipeline operates on expression matrices and sample metadata, not personal identifiers. |
| Sub-processors | Amazon Web Services hosts the platform, and since 9 September 2026 also provides the language model several steps call, through Amazon Bedrock. See where your data goes. |
Who at VarnaOps can reach your data
One person. VarnaOps is a company of one: Leonardo Golinelli, who founded it, operates it, and is the person behind the contact address at the top of this page. He holds the administrative credential on our cloud account, and that credential can reach any file the platform stores. There is no second administrator, no support team with a way in, and no engineer on call who could look at your data without being that same person.
That access is recorded. Since 31 August 2026 an audit trail on our cloud account logs administrative actions and, separately, reads and writes of the individual objects in the storage that holds uploads and results. So there is a durable record of which file was opened, when, and under which credential. It is our record rather than a report you receive automatically. If you have a specific security question about your own data, contact us and we will do what the record allows. Before that date no such record was kept, and we cannot reconstruct one for earlier periods.
Both facts are stated because the honest answer for a company this size is defensible only if we give it. One administrator with broad access is a real limitation, not a control we are dressing up: what bounds it is that the access is logged, that the storage expires on the schedule under how long we keep it, and that nothing in the product exposes one customer's data to another.
What we collect
Almost everything here is data you hand us on purpose. We set no advertising cookies and run no third-party analytics. That is a narrower statement than it may look: your browser does keep things for us on your own device, which is a different thing from a cookie and is set out under how long we keep it.
| Category | What it is | Where it comes from |
|---|---|---|
| Account | Your email address, and the name, organization and intended use you give on the access-request form. | You, at sign-up. |
| Your query file | The expression matrix and per-cell metadata columns in the file you upload. Processed on your instructions: for this data you are the controller and we are your processor. | You, at upload. |
| Run records | The run id, its status and timing, the file name you uploaded, the reference you chose, your email so we can tell you when it finishes, and whether you have asked us not to send that email. | Generated as the run executes. |
| Results | The annotated output and the HTML report built from it. | Produced by the run. |
| Billing | Your balance and a ledger of purchases and usage. Card details go to the payment processor and never to us. | You, and the payment processor. |
| Terms acceptance | Which version of the terms and the data processing agreement you accepted, when you accepted it, and the network address and browser you accepted from. Kept until you delete your account. | You, when you tick the box at sign-in. |
| Service logs | Operational records of requests and job execution, used to run and debug the platform. | Generated automatically. |
| Website visits | A count of page requests: the time, the page, the response status, and the country and the nearest edge location the request came from. No address, no browser detail, no cookie. | Recorded by our web host as you browse. |
| Analysis choices | For each analysis submitted, an anonymous record of the reference, the analyses chosen, the size band of the data, whether your own labels were used, and which roles you assigned to metadata columns. No account, no file name, no column names, no run. | Recorded when a run is submitted. |
One thing worth knowing about the logs, because it is the kind of detail a notice usually leaves out: a job log line records the batch or donor identifier taken from your own file, so whatever you named those columns appears there. If you would rather it did not, rename or drop those values before uploading.
And one about visiting the site at all, since it is the only thing here you do not hand us on purpose. Our web host records, for each page request, the time, the page, the response status, and the country and edge location the request came from, and nothing else: no network address, no browser or device detail, no cookie. That is not enough to tell one visitor from another or to follow anyone between pages. These records are kept for 30 days and are used only to count visits.
And one about the choices themselves. For each analysis submitted we keep an anonymous record of the reference it ran against, the analyses chosen and the size band of the data, with nothing in it that identifies the account, the file or the run; we keep it indefinitely and use it only to see which analyses are used.
Why we process it, and on what legal basis
Under the GDPR every purpose needs its own lawful basis. Ours, purpose by purpose:
| Purpose | Legal basis | Why that basis |
|---|---|---|
| Running your analysis and returning your results | Performance of a contract, Art. 6(1)(b) | It is the service you asked for. Without the file there is nothing to process. |
| Creating and running your account, and telling you when a run finishes | Performance of a contract, Art. 6(1)(b) | Same contract. We send one email per run, when it finishes, whether it succeeded or failed. It is the only email we send you about a run, and you can turn it off on your account page; your runs and results stay reachable there either way. |
| Reviewing an access request before approving it | Steps prior to a contract, Art. 6(1)(b), and legitimate interests, Art. 6(1)(f) | You asked for access, and each run costs real GPU time, so we check who is asking before opening the tap. |
| Taking payment and keeping the credit ledger | Performance of a contract, Art. 6(1)(b) | You paid us and we have to record what you paid and what you spent. |
| Keeping financial records after you leave | Legal obligation, Art. 6(1)(c) | Accounting and tax law requires a business to keep its records for a period that outlasts any individual account. |
| Keeping the platform up, secure and debuggable | Legitimate interests, Art. 6(1)(f) | See below. |
Where we rely on legitimate interests, what those interests are
Two purposes rest on legitimate interests, and Art. 13(1)(d) requires us to say what they are rather than just cite the article.
- Operating and securing the service. Our interest is a platform that stays up, resists abuse, and can be debugged when a run fails. The processing is operational: request and job logs, error traces, and the records needed to trace one run. We weighed that against your interests and consider it proportionate because the logs are not used to build any picture of you, they are not combined with anything else, they are read only when something breaks, and they expire on a schedule. You can object to this at any time using the contact address above.
- Deciding who gets access. Our interest is not handing GPU capacity to anyone who fills in a form. We look at the name, organization and stated use once, to approve or decline. There is no scoring and no profile.
Who else sees your data
We do not sell data and we do not share it for anyone else's marketing. Three companies process some of it on our behalf or alongside us, and each is there for a specific job.
| Recipient | What they get | Why |
|---|---|---|
| Amazon Web Services | Everything the platform stores or runs: your uploaded file, your results, run records, account records, logs. | They host the platform. It runs in our own AWS account. |
| Amazon Web Services (Amazon Bedrock) | Metadata and text only, never your expression matrix. Exactly what, step by step, is set out under where your data goes. | They supply the language model three steps call. Same company and same account as the row above; listed separately because it is a different service, engaged on different occasions. |
| Stripe | Your name, email and payment details, given to them directly at their checkout, and the account id we put on the checkout link so the money reaches the right account. They tell us only that a purchase succeeded and for which account. | They handle credit purchases as merchant of record, through Stripe Managed Payments, acting for us rather than selling to you themselves. The name on the receipt is Stripe's affiliate, Sold through Link, LLC. |
Beyond those: we would disclose data if the law required it, and if the business were ever sold or reorganised, customer records would move with it. Neither has happened.
Where your data is processed
In the United States. The platform runs in the AWS
us‑east‑1 region in Northern Virginia, and Stripe is a US
company. Language-model calls are placed in that same region and may be processed in two
other United States AWS regions, us-east-2 and us-west-2, under a US routing profile;
they stay on the AWS network.
This applies to everyone, wherever you live. We are established in Italy, so the data protection rules that govern us are the European ones, and sending your data to a US company means sending it out of the European Union. That is true of every account. It depends on where we are and where our providers are, not on where you are, so a customer in the United States is in exactly the same position as one in Rome. The United States has not been the subject of an adequacy decision we rely on.
The safeguard we rely on
Art. 13(1)(f) asks us to name the legal mechanism that carries a transfer like this. For Amazon Web Services, it is the EU Standard Contractual Clauses (controller-to-processor), the standard terms approved by the European Commission in Implementing Decision (EU) 2021/914. The contract brings those clauses in by reference, so they apply to our account without anything for us to sign or switch on. Since 9 September 2026 the same instrument carries the language-model calls too, because they no longer leave that account: Amazon Web Services (Amazon Bedrock) is covered by the EU Standard Contractual Clauses (controller-to-processor) for exactly that reason — it is the same company, the same contract and the same account as the hosting above.
For Stripe it is a different instrument, and which one it is was not ours to pick. Stripe's Data Transfers Addendum says that where more than one mechanism could apply, a transfer runs under one of them only, taking the EU-US Data Privacy Framework first and the clauses second. Stripe, LLC is on that framework's public list of certified companies, which we checked on 29 August 2026 and which runs to May 2027, so the framework is the instrument carrying this transfer today. If the certification lapses, Stripe has to tell us without undue delay, and the EU Standard Contractual Clauses (controller-to-processor), which the same addendum sets out in full, take over on their own terms with nothing for us to negotiate. The addendum carries a controller-to-controller version of those clauses as well, because alongside processing the payment for us Stripe uses payment data for its own purposes: fraud checks, anti-money-laundering and identity obligations, and developing its products.
The affiliate whose name is on the receipt is on the clauses, not the framework. Sold through Link, LLC appears on no certification list, so the first limb cannot reach it. It is covered instead by the clauses, as a named sub-processor on Stripe's published sub-processor list.
For the United Kingdom, a second instrument does the work. The EU clauses have no effect under UK law on their own, so all three companies add the International Data Transfer Addendum issued by the Information Commissioner in February 2022, which adapts those clauses to the UK GDPR. Where UK data protection law applies, that addendum is the operative instrument for Amazon Web Services, and the EU clauses alone would not be enough. For Stripe the same order of precedence applies as above: Stripe, LLC's certification covers the UK extension of the framework, and the UK addendum sits behind it as the fallback.
What naming a mechanism does and does not tell you. It means the contractual machinery is in place. It is not a finding that the transfer is safe, and we are not making one. Under Schrems II the exporter, which is us, is expected to assess the destination country's law against those clauses, and every one of these providers puts that assessment on us rather than supplying one. We have now carried it out: for AWS on 4 August 2026, and for Stripe, LLC on 29 August 2026. Each one follows the EDPB's Recommendations 01/2020 on measures that supplement transfer tools, six steps in order, and each concludes proceed at low residual risk: low for AWS, and low for Stripe, LLC. A third assessment, of the transfer to Anthropic, was carried out on the same date and concluded low with a narrower margin; it is retained as the record of the path used until 9 September 2026 and no longer covers a live transfer. These are internal records rather than published documents, and they are available to customers on request. Read this section as telling you which instrument governs the transfer and what we found when we assessed it, and not as telling you we have concluded the transfer is lawful or that any safeguard removes the risk.
How long we keep it
| What | How long | Then what |
|---|---|---|
| Your uploaded file | 7 days, and a little over | Deleted automatically by a storage lifecycle rule. It is only needed while the run executes. The seventh day is when deletion becomes due, not when it completes: the clock is rounded up to the next midnight UTC, and the sweep itself runs on Amazon's schedule rather than ours. So the honest description is deleted shortly after the seventh day, not deleted at seven. This row is not the answer to "when is my expression data gone". It covers the file you sent, and copies of it derived by the run live in your results under the next row. |
| Your results and report | 30 days, and a little over | Deleted automatically. Download anything you want to keep before then. Same arithmetic as your uploaded file above: the thirtieth day is when deletion becomes due, and it completes shortly after. Your results contain copies of your expression data, not only summaries of it. The annotated output you download carries your matrix, and the run also leaves a gene-harmonized copy of it beside the report, kept in case the report has to be rebuilt. So the window that governs your expression data is this 30 day one and not the 7 day one above. Deleting the run removes them immediately, which is the only way to make the shorter window true. |
| Run records | Until you delete the run or your account | No automatic expiry today. Deleting is the only thing that removes them. |
| Account records | Until you delete your account | Removed with the account, subject to the exceptions below. |
| Billing records | Kept indefinitely | Deliberate. Financial records outlive the account, see below. |
| Request logs | 30 days | Expire on a schedule. |
| Website visit logs | 30 days | Deleted automatically by a storage lifecycle rule. These are the page-request counts described under what we collect, and they carry nothing that points at a person. |
| Analysis choice records | Kept indefinitely | Deliberate. These are the anonymous per-submission records described under what we collect; they carry nothing that points at a person, an account, a file or a run, so there is nothing in them to delete with an account. |
| Job logs | 30 days | Same schedule as everything else we log. These are the logs that can carry an identifier from your file, so it is worth saying that they expire on the same clock rather than a longer one. |
| Database backups | Up to 35 days | A rolling backup window. Anything deleted stays restorable inside it, see below. |
| Data sent to the language model | Not kept | Amazon Bedrock's default is zero retention, and it runs in our own AWS account, so there is no separate copy. Set out under where your data goes. Before 9 September 2026 this row read "30 days, with two exceptions", at Anthropic. |
| Things kept in your browser | 7 days, or until you sign out | Held on your own device by your browser, not on our servers, and never sent to us. It is what lets a reload pick up where you left off: your sign-in token, which file you uploaded, the column names you confirmed, anything you typed into the wizard including the interpretation prompt, and which analyses you ticked. Signing out clears all of it, and so does your browser's own "clear site data". |
Your rights
If the GDPR or the UK GDPR applies to you, you have all of the following. Erasure needs no request: you delete a run from My runs and the whole account from your account page, and it happens immediately. For the rest, ask by writing to support@varnaops.com. We answer within one month, and we do not charge for it.
| Right | What it means here |
|---|---|
| Access | A copy of the personal data we hold about you, and confirmation of what we do with it. |
| Rectification | Correction of anything wrong. Your account details are the usual case. |
| Erasure | Deletion of your runs or your whole account, done by you rather than requested from us. Read what erasure actually removes first, because three things survive it. |
| Restriction | We keep the data but stop processing it, for example while you contest something in it. |
| Objection | You can object to anything we do on the legitimate-interests basis, which is the operational and access-review processing named above. |
| Portability | The data you gave us, in a machine-readable form. Your results already come as a self-contained file you own. |
Deleting a run, or your whole account
You do this yourself, from the site, and it takes effect at once: a run and its results from My runs, an uploaded file from the upload step, and the whole account from your account page. Deleting a run stops it if it is still executing, removes its stored results, and removes the record of it. Deleting your account does that for every run you have, and also removes your uploads, your access-request details and your login. You do not have to email us for any of it.
Three things survive that, and you should know all three before you do it. We would rather set them out than let you find them later.
| What survives | How long | Why |
|---|---|---|
| Billing records | Indefinitely | Purchases, refunds and the ledger behind them are kept on purpose. Art. 17(3)(b) of the GDPR says the right to erasure does not override a retention duty the business is under, and accounting law imposes one. These records stay linked to you through the payment processor's own copy. |
| Database backups | Up to 35 days | Deleting a record removes it from the live database but not from the rolling backup that protects every customer against data loss. Nothing in the product can read it and no request returns it, but it is restorable by us until it ages out. So the honest description is removed from our systems within 35 days, not removed immediately. |
| Logs | Until they expire | Log retention runs on a clock, not on request. Deleting your account does not reach back into log entries already written; they age out on the schedule in the table above. |
What deletion does remove, it removes properly. Stored objects are deleted by every version, not just the most recent, so nothing is left behind as an older copy. And a request to delete something that is already gone succeeds rather than erroring, so retrying a request that timed out is safe.
You get a written record of the deletion. When you close your account we produce a destruction record: how many stored objects and storage prefixes were deleted, when, that every prefix was listed again afterwards and found to be empty, and a plain statement you can forward to a data access committee or a funder. It also carries the list of what deletion does not reach, so the document is complete on its own. It is kept in a separate audit store that the deletion cannot touch, and a copy is returned to you at the time. It records counts, prefixes and timestamps only: not your run identifiers and not your file names, because a permanent record of what you once uploaded would undo part of the erasure it certifies. Live, deployed 1 September 2026.
There used to be one more limit here, belonging to a sub-processor rather than to us: we could not shorten the model provider's retention window for anything already sent. It applies only to data sent before 9 September 2026, when the model moved inside our own AWS account. That is set out in full under where your data goes.
Complaints
If you think we have handled your data wrongly, tell us first and we will try to put it right. You do not have to, and going to us does not affect your right to complain to a regulator.
Because we are established in Italy, our lead supervisory authority is the Garante per la protezione dei dati personali, the Italian data protection authority. You can complain to them wherever you are.
That is not your only route. Art. 77 of the GDPR lets you complain to the authority in the country where you live, where you work, or where you think the problem happened, and you do not have to come to Italy to be heard.
- European Union: the Garante above, or your own national authority. The European Data Protection Board lists them all.
- United Kingdom: the Information Commissioner's Office, ico.org.uk.
- Elsewhere: your national data-protection or consumer authority, if your country has one.
Automated decisions and profiling
We do not make automated decisions about you, and we do not profile you. Nothing about you as a person is decided by a machine, so the right in Art. 22 of the GDPR to object to such a decision does not arise here.
Worth separating from that, because the product is obviously automated: the pipeline does make automated predictions, but they are about biological cells in the file you upload, not about you. A predicted cell type has no legal effect on you and nothing similarly significant. Every prediction ships with a confidence score, the report says where the model is uncertain, and the whole thing is research use only and never a diagnosis.
Where your data goes: the language-model steps
Several steps in the pipeline use a large language model, supplied by Amazon Web Services through Amazon Bedrock, in the same AWS account that runs everything else here. It reads your metadata so it can propose which of your columns holds what, match your cell-type names to the reference vocabulary, and write the interpretation section of your report. This is a normal part of how the product works, and it is worth being precise about what it means.
.h5ad or a 10x .h5, and none sends your
file. That guarantee holds by construction: the server accepts only those two formats,
and neither of the paths that would read a raw table can be reached with either of them.
Some of your data does leave, and it is not only column names. Up to three example values from each metadata column are sent with the column name, so whatever those columns actually contain goes with them. Alongside that: cell-type label text, statistics we have already computed, and anything you typed yourself.
Every step that calls the model, and exactly what each one sends:
| Step | When it runs | What is sent |
|---|---|---|
| Column roles | Only when you press the button that asks for it, and it is priced separately. | The name of each column, its data type, how many distinct values it holds, and up to three real example values from it, so the model can propose which column is your sample, donor or cell type. If a column contains identifiers, three of them go too. |
| Label matching | Only if you choose to use your own cell-type labels. | The distinct cell-type names in your data, as text, together with the reference's own vocabulary. |
| Interpretation | Only if you tick "Interpret results". | The results the run computed, and the question you typed in the focus box if you wrote one. |
Two further steps exist in the engine and cannot be reached from this
application: a layout resolver that reads the first few rows of an ambiguous
spreadsheet, and an error explainer that reads the start of a file that failed to load.
The upload here accepts only .h5ad and 10x .h5, neither of which
takes either path, and the error explainer is switched off. They apply to the
command-line tool, where a spreadsheet is an accepted input and a short preview of it,
including any values in those rows, does reach the model.
None of these steps is required to get a result. Column roles runs only when you press
the button for it, label matching only on labels you chose to bring, and you confirm
every proposal before it is applied; the interpretation is an option you tick. A whole
run can also be submitted with the no-model option (no_llm on the API,
--no-llm on the command line), which makes no language-model call anywhere
and refuses, before the run starts, any analysis that would need one. See
how your data is handled.
What the model provider may and may not do with it
Your data never leaves AWS at any step. The model runs on Amazon Bedrock, inside the same account that already holds your file and your results, so nothing here goes to a second company. AWS states that the companies that build the models it serves have no access to Bedrock's logs or to customer prompts and completions.
Bedrock's published default is zero data retention: it does not store what is sent to a model or what comes back. For a short published list of named models AWS does keep inputs and outputs for as long as 30 days to detect abuse; when it does, they stay inside AWS and are still not passed to the model's developer. The model we call is not on that list, and we check it before changing models.
It is not used to train anything. AWS's service terms let AWS learn from what you send only for a named list of services, and that list does not include Amazon Bedrock; the clause says it "does not apply to ... any AI Service that is not listed". And the company that built the model cannot train on it either, because it never receives it.
One exception, and it is about billing rather than content: AWS may tell a model's provider information about your use of that model. AWS's terms are explicit that this "does not include Your Content". Your data still never leaves AWS; the fact that a call happened does.
What this changed, on 9 September 2026. Until that date these steps called Anthropic's API. Anthropic's commercial terms said it may not train models on customer content, and it retained inputs and outputs for 30 days, flagged content for up to two years and safety classification scores for up to seven, with no way for us to request ad-hoc deletion inside that window. That limit applied to anything sent before 9 September 2026 and cannot be undone; it does not apply to anything sent after. If it matters for data you sent earlier, talk to us.
Other deployment models
This notice describes how the platform works today. Other deployment models are not available today; ask us what is.