Privacy Policy

Real Fake Intelligence, Inc., a Delaware corporation (RFI, we), operates rfi.dev. This policy covers the rfi.dev website, the account portal, and the inference API (the Service). It sits alongside our Terms of Service.

For your account, billing, and support data we are the controller — we decide why and how it is processed. For the content you send to the API we act as a processor on your behalf: it is your data, we handle it to return a response, and we do not decide what to do with it beyond that.

We are a United States service, and we say so up front. We operate from the United States, the data we keep is stored in the United States, and we direct the Service at users there. Where inference itself runs is a separate question, and section 7 answers it: not always here. We have not built the machinery that serving the European Economic Area or the United Kingdom properly requires — a local representative and EU-specific transfer terms — so we do not market the Service in those places and this policy is not written to satisfy their law. We do not block anyone: if you sign up from outside the United States, you are choosing a US-operated service and the data we keep comes here. We would rather state that plainly than publish a policy that gestures at rules we are not yet set up to follow. If you need us to serve one of those markets properly, email support@rfi.dev — we are tracking the requests, and the ask is what will move it up the list.

• Account data. Your email address, and the name and avatar your identity provider (Google or GitHub) returns when you sign in. We receive a profile, not a password — we never see your credentials for those providers.
• Your acceptance of our terms. When you create an account or sign in, we record that you accepted the Terms of Service and this policy, which version of them you were shown, when, and the network address and browser your device reported at that moment. This is the record that an agreement between us exists at all, so we keep it rather than reconstructing it later.
• Billing data. Your credit balance, ledger entries, and a Stripe customer identifier. Card numbers, CVCs, and expiry dates never reach our servers — payment details are entered on Stripe's hosted checkout page. We can see what Stripe shows us afterwards: the amount, the currency, the outcome, and the last four digits and brand of a saved card.
• API usage metadata. For each request: a request identifier, the timestamp, the model, the number of prompt, cached, and completion tokens, the cost, and which of your API keys was used. This is the billing record, and it is what the portal's Activity page is built from. It does not include the text of your prompt or response.
• Prompt and completion text. Processed in memory to serve the request, and never recorded — not in our application database, not in a log, not anywhere else. We do read responses as they pass through us to count how often they come back malformed, and we keep the count rather than the response. Section 5 is the detail.
• Support data. If you email us or use the chat widget, we keep the conversation and the address you sent it from.
• Technical data. IP address, user agent, request path, response status, timing — the technical detail generated when you use the website or the API.

We do not ask for, and do not want, special-category personal data (health, biometrics, political opinions, and similar). Please do not send it in a prompt.

• To provide the Service — routing your request and returning a response.
• To meter usage, charge credits, take payment, and produce receipts.
• To show you your own usage and balance in the portal.
• To keep the Service up and secure — capacity planning, debugging, rate limiting, and investigating abuse or fraud.
• To contact you about your account: balance warnings, failed payments, security notices, and material changes to our terms.
• To comply with law, tax, and accounting obligations.

• We do not train on your data. Your prompts and completions are never used to train, fine-tune, or evaluate a model. We serve an open-weights model we did not train, and there is no pipeline that feeds your data back into it.
• We do not sell personal information, and we do not share it for cross-context behavioural advertising. We have never done either.
• We do not advertise to you or track you across the web. There are no advertising cookies on rfi.dev, we buy no advertising audiences, and nothing we run follows you to another company's site. Section 11 says what does run in your browser, and what we ask you about before it does.
• No human at RFI reads your prompts. There is no store of them for anyone here to read — section 5 explains why — so the only prompt text a person at RFI ever sees is text you send us yourself, such as an example you paste into a support conversation. An investigation into a security incident or a suspected acceptable-use breach works from the metadata in section 5, not from your prompts. Automated checks as a response passes through are a different thing, they do happen, and section 5 describes exactly what they look at and what they keep.
• We never log or record prompts or completions. Section 5 draws the line between what we keep about a request and what we never keep from it.

Prompts and completions are never logged and never recorded. Not to a database, not to a log, not to a backup, not to an analytics tool, not anywhere else. Your prompt is held in memory for as long as it takes to compute your response, and then it is gone. This is not a policy we intend to follow — it is a property we build for: our application database has no field for message content, and our billing gateway is configured not to persist request or response bodies.

That covers software we did not write, too, and we say so deliberately. We run an open-source inference server and we rent the machines it runs on. We do not treat those as somebody else's problem or as a reason to soften the sentence above: it is a commitment about the whole system. If we found a component of it writing your prompt into a log, that would be a defect we fix, not a practice we disclose and keep. We would rather owe you the fix than publish a carve-out.

What we do keep is data about your request, never data from it. That distinction is the whole of this section, so it is worth being exact about which side of it things fall on — some of what we keep, we keep indefinitely, and you should know precisely what that is.

• Never recorded — the text you send us and the text the model sends back. The words in your prompt, the documents and code you paste into it, the system prompt you wrote, the answer you got. The content.
• Recorded, and kept — the facts about the request that do not reveal what it said: which model served it, how many tokens went in and came out, when it arrived, how long it took, whether it succeeded or failed, which API key was used, and the IP address it came from. A row saying “this key sent 4,000 tokens at 09:14 and got 900 back” is a billing record. It is not your prompt, and it cannot be turned back into your prompt.

Everything in that second list is what an invoice, an incident investigation, and an abuse report are made of, so we keep it for as long as we need it and we do not promise to delete it on a schedule. Everything in the first list has no retention period because it is never written down in the first place.

Reading in transit, without keeping. There is one thing we do to request and response content that is neither storing it nor logging it, and it is easier to name than to leave implied: as a response passes through us on its way back to you, we look at it well enough to tell whether it came back broken. Today that means an empty or degenerate generation and a failed response status; as we add checks it will cover more of the same kind, such as a tool call that comes back malformed. What we keep is the count: how many requests errored, of what kind, over what period. The response itself goes to you and is not written down. This is how we know the Service is healthy, and it is the same measurement our marketplace listings publish as an error rate.

Caching. We cache an encoded representation of prompts so that a repeated or shared prefix does not have to be recomputed. This is what makes cached input faster and cheaper, and it is why cached input is priced separately on our rate card. What is held is derived numeric state, not your original text.

These caches are held in memory on the machines that serve your requests, and nowhere else. They are never written to disk, never copied into a database, a backup, or an analytics system, and they never leave our serving infrastructure. A cache is gone when the process holding it restarts, and gone with the machine when the machine goes away. Section 7 says where those machines are, and the answer is not always the United States.

A cache entry is derived model state addressed by content, not a record filed under your name. There is no account identity in the key, the cache is not organised by user, and there is no way to ask it what a particular customer sent — the only way to reach an entry is to already hold the identical text. The note below on the cache being shared rather than per-customer explains what that means in practice, because it cuts both ways.

They exist for one purpose — making a repeated prefix faster and cheaper to serve — and are used for nothing else. They are never read for analytics, never mined, and never used for training.

What we are not promising: entries are evicted continuously under memory pressure and the whole cache is gone the moment a serving process restarts, so in practice they are short-lived. That is what we observe, not a retention period we commit to: we do not run a timer that expires cache entries, and we would rather tell you that than imply a mechanism we have not built. It is not a copy of your prompt that we keep; it is working state that happens to outlive one request.

One property of that cache worth stating plainly: it is shared, not per-customer. A cache entry is addressed by the content of the prompt prefix itself, so two requests carrying an identical prefix reuse the same entry regardless of which account sent them. No account can read another account's prompt this way — an entry is only reachable by someone who already has the identical text — but it does mean the speed of a response can reflect that the same prefix was recently sent by someone else. If that matters for your use case, email us — we would rather hear about it early, and we can tell you where per-account cache scoping sits on our roadmap.

Metadata, which we do log. We record the operational detail needed to bill, troubleshoot, and keep the Service healthy: timestamps, durations, request and response sizes, token counts, the endpoint called, the model served, the response status, which API key was used, and the IP address the request came from. When a request fails, we also record the error message our own systems produced for it, which is a sentence about what broke and not a copy of what you sent. None of this includes the content of a prompt or a completion.

We list the IP address explicitly rather than folding it into “metadata”, because it is the one item in that list that identifies a person rather than a request. It is there for abuse handling and for working out where a problem is happening.

How long each thing is kept:

• Prompt and completion content — never kept, so there is no period to state. It is not in this list because it is not in any of our systems.
• Operational logs and request metadata — the detail listed above, which is data about a request and never data from it — for as long as we need it to operate, secure, and bill for the Service. We do not state a fixed window for these, and we would rather tell you that than publish a number we do not enforce.
• Caches of encoded prompts — held in memory on the serving hosts, never written to disk, and never a durable record. Short-lived in practice; see section 5 for why that is an observation rather than a commitment.
• API usage metadata (token counts and charges, no content) — while your account is open, because it is the record of what you were billed for and what you can see in Activity.
• Billing and ledger records — seven years after the transaction, as tax and accounting law requires, even if you close your account.
• Account data — until you delete your account, then removed within 30 days, apart from the billing records above, the acceptance record below, and any support conversation you have had with us, which keeps the address you wrote from for as long as the row below says.
• Your acceptance of our terms — kept after you close your account. It is the record that an agreement existed, and the parts of that agreement which outlive the account depend on it. It holds no prompt or response content.
• Support conversations — three years.

Closing your account does not retroactively delete the billing records the law requires us to hold. It does delete your keys, which stops any further use immediately.

We use a small number of vendors to run the Service. All of them are United States companies, and all of them are bound by contract to use your data only to provide their service to us:

• A payment processor — checkout, card handling, receipts. This is the vendor whose hosted page takes your card details, which is why they never reach us.
• Cloud infrastructure providers — hosting for the portal, the billing gateway, and their databases.
• An observability and telemetry provider — the service that receives our operational logs, metrics, and error and performance telemetry, so that we can tell whether the Service is up, fast, and working for you. What reaches it is the technical detail section 5 calls data about a request — timestamps, response status, timing, IP addresses, and account or key identifiers — and never the content of a prompt or a completion.
• A rented GPU compute provider — the hardware that runs inference. Your prompts are processed on machines it operates. See the note below, because this one has a limit worth knowing.
• A support chat and inbox provider — the widget on our pages and the mailbox behind support@rfi.dev.
• An email delivery provider — transactional email (balance warnings, payment notices).
• The identity provider you choose to sign in with — currently Google or GitHub. You pick this one yourself at sign-in, and it sees only that you signed in to RFI.

We will name every one of these, in writing, to anyone who asks. Email support@rfi.dev and we will send the current list; it also comes with the Data Processing Agreement described in section 7. We describe them by category here rather than by name so that this page does not go stale the week we change a vendor — a policy that names a vendor we no longer use is worse than one that says what the vendor does.

Two of them we do name, and the line is deliberate: the identity provider you sign in with, and the payment processor whose hosted page takes your card. You meet both of those yourself — you click their button and read their name on the screen — and our Terms make your purchase subject to the payment processor's own terms, which we could not do without naming it. Naming what you can already see is not the same as publishing our back-end supply chain, and the rest of this list is the back-end supply chain.

A note on the GPUs, because it is a real limit. We rent GPU capacity; we do not own the datacentres your request runs in. Our physical-security promises are only as strong as the infrastructure controls of the provider underneath, and we are not in a position to audit those end to end. We would rather say that plainly than imply a supply chain we control. What this does not qualify is section 5: never recording your prompts is a commitment about the whole system, rented hardware included, and we hold ourselves to it there rather than discounting it here.

We will update this section before adding a category of vendor that processes personal data. We may also disclose data where the law requires it — a valid legal demand, or to establish or defend a legal claim — and in connection with a merger or sale of assets, in which case this policy continues to apply until it is replaced with notice to you.

What we keep is kept in the United States. RFI is a US company, and the systems that store data — the account portal, the billing gateway, the databases behind them, and our support inbox — run in the United States. If you use the Service from anywhere else, that data is transferred here to be stored.

Inference is the part worth reading carefully. We rent GPU capacity rather than owning datacentres, and that capacity is not all in the United States — a request may be served on a machine in another country. What makes that a smaller fact than it sounds is section 5: on a serving machine your prompt and the completion are processed in memory and are never written down, so a request leaves nothing behind wherever it ran. The metadata we do keep is stored here, as the paragraph above says. We do not sell a data-residency option and we cannot promise today that a request will be served in a particular country; if that changes we will say so here.

If you need a Data Processing Agreement for your own compliance — including the named list of the vendors in section 6 — email support@rfi.dev and we will send one.

We give everyone the same rights, wherever you are, because sorting customers by jurisdiction is more work than just honouring the request. You can ask us for a copy of your data, ask us to correct it, ask us to delete it, and ask us to stop processing it. We will not discriminate against you for asking.

If you are in California, Colorado, Connecticut, Virginia, or another state with its own privacy statute, those are your statutory rights and this is how you exercise them. California residents also have the right to know what we collect and to opt out of the sale or sharing of personal information — and as section 4 says, we do neither, so there is nothing to opt out of.

Much of this is self-serve: your usage is in the portal, and account deletion is a button. For anything else, email support@rfi.dev. We will respond within 30 days, and sooner if we can. We may need to verify that the request comes from the account holder before we act on it, and if we have to refuse part of a request — the tax records in section 5 are the usual reason — we will tell you which part and why.

Traffic between you and our API is encrypted in transit with TLS. Traffic between our own components travels over private or encrypted links wherever the underlying provider supports it; where it does not, we say so here rather than implying otherwise. Data at rest sits in managed databases and object storage with access limited to the people and services that need it. API keys are stored as hashes, not as recoverable secrets, which is why we can show you a key exactly once and never again.

No system is perfectly secure, and we do not claim a compliance certification we have not been through — we hold no SOC 2 or ISO report today, and we will say so here when that changes rather than implying it earlier. If you believe you have found a vulnerability, email support@rfi.dev. We will not bring a legal claim against you, or refer you for prosecution, for good-faith security research that: reports what you found to us promptly and privately; does not access, change, or keep another customer's data or prompts; does not degrade the Service for anyone else; and stops as soon as you have established that the issue exists. Research meeting those conditions is permission for the purposes of section 5 (Acceptable use) of our Terms.

The Service is for people aged 18 and over. We do not knowingly collect personal data from children. If you believe a child has given us data, email us and we will delete it.

Start with what stays true whatever we add later. There are no advertising cookies on rfi.dev. Nothing we run follows you across other companies' websites. We do not sell your data, and we do not share it for anyone else's advertising — section 4 is the fuller version of that one. Those are commitments about every version of this site, not a description of this week's build.

Essential cookies. We set first-party cookies to keep you signed in and to keep the site secure — the ones without which the portal cannot work. Those are the only cookies rfi.dev sets on its own.

Optional features are a question we ask, not a thing we assume. Some parts of the site are run for us by another company and set their own cookies or browser storage when they load — our support chat is the one we offer today, and its identifier lasts about nine months. On our public pages we ask before loading any of them: nothing loads until you choose, saying no loads nothing, and the site works normally either way. You can change your mind by clearing this site's data in your browser.

This page, and our Terms, load nothing from anyone else. No chat widget, no analytics, no fonts or scripts from another company's servers. A document explaining what we do with your data seemed like the wrong place to hand your IP address to a vendor, so these two pages are built to contact nobody, and a test fails our build if that stops being true.

Once you are signed in, the product loads without asking. At that point you have an account with us, and two things come with it: support chat, which is the channel we owe you, and the technical telemetry that tells us whether the Service is up, fast, and returning errors to you. We treat both as part of running the product rather than as something to consent to separately. That telemetry never includes the content of your prompts or completions. It is the technical detail described in section 5 — timings, statuses, errors — and section 6 names the category of vendor that receives it.

If you would rather nothing ran in your browser, most browsers let you block storage for a site, and the portal works normally without it. That is a browser-side control only: the server-side records in section 5 are made whether or not your browser stores anything, and section 5 says what they are and how long we keep them.

We may update this policy. If a change materially affects how we use your data, we will give at least 30 days' notice by email or in the portal before it takes effect. The date at the top of this page always reflects the current version.

Real Fake Intelligence, Inc.
Privacy enquiries and data requests: support@rfi.dev