Trust guide
Deepinfra privacy starts with what you send
Deepinfra privacy is not determined by a model name alone. Before sending prompts, files, or personal information to Deepinfra, check the current provider terms and decide what data your task truly requires.
One-line definition
Privacy in an inference workflow means understanding what enters a service, what comes back, and which handling claims you can verify.
- InputA Deepinfra request may carry sensitive information in its prompt even when the chosen model is publicly available.
- OutputA Deepinfra response can repeat details from the request, so outputs need review before they are shared.
- EvidenceCurrent Deepinfra terms and documentation, rather than this guide, are the source for retention and handling commitments.
How it works: where the checks belong
A useful review follows the data through preparation, submission, and output. This page cannot inspect Deepinfra systems or establish what happens to any particular request.
Cannot guarantee zero retention
This guide has no access to Deepinfra's current logging settings, contractual terms, or operational records. A promise about deletion would need evidence from the provider.
What to do instead
Read the current handling documentation and ask the provider about the specific endpoint and deployment you intend to use.
Cannot make a sensitive prompt anonymous
Removing a person's name may leave identifying context, document excerpts, or unique events in a request sent to Deepinfra.
What to do instead
Replace real records with synthetic examples and review the entire prompt for indirect identifiers.
Cannot certify an application
A provider's published controls do not automatically cover your own storage, access rules, logs, or onward sharing of Deepinfra outputs.
What to do instead
Review the full application data flow and obtain the approvals your organization requires.
Can and cannot do: a preflight checklist
Use this checklist before testing a Deepinfra workflow. It helps reduce unnecessary disclosure; it does not replace a legal, security, or compliance review.
-
Identify every field, file, and prompt fragment you plan to submit to Deepinfra. — Include material added by your application, not just text typed by a user.
-
Check current provider documentation for retention, access, and data-use terms relevant to your request. — Record when you checked it; terms may change.
-
Remove secrets, direct identifiers, and unnecessary context before testing. — Use a synthetic prompt when the task allows it.
-
Review the response for details that should not be stored or forwarded. — Output handling matters as much as input handling.
-
Document your internal approval for any workflow involving regulated or confidential data.optional — The necessary review depends on your organization and use case.
Who uses it: workflows worth checking
Developers comparing model choices, teams preparing document search, and evaluators running test prompts each have different exposure points. These related guides help place a privacy review in context.
- deepinfra models Compare model categories so your data review matches the kind of input your application sends.
- deepinfra embeddings Examine the document-to-vector workflow before submitting source text from a private collection.
- deepinfra vs openrouter Trace how a provider comparison changes the questions you ask about routing and data handling.
A boundary you can explain
- CHECK TERMS
- REVIEW INPUT
- TRACE OUTPUT
Send only what the task needs
The safest initial Deepinfra test uses invented, non-sensitive content. That lets you examine the request shape and the response without treating an unverified retention assumption as a privacy control.
For real records, write down where the data originates, who may submit it, what the Deepinfra request contains, and where the answer goes next. Verify provider claims against current documentation before deciding whether that path is acceptable.
A review cadence, not a historical claim
These dates describe a suggested review cycle for your workflow, not milestones in Deepinfra's product history.
-
Map the request
List the fields your application sends to Deepinfra and mark anything confidential, identifying, or unnecessary.
-
Check published terms
Read the current documentation for the service and deployment you will use; save the date and the questions it does not answer.
-
Test with synthetic data
Run a harmless example through Deepinfra and inspect both the submitted payload and the returned text.
-
Recheck the data flow
Review application logs, stored outputs, and any changes to Deepinfra documentation before expanding the workflow.
Start with a harmless example
Use an invented prompt to see whether the model fits your task. Keep personal details and confidential files out of the test, and complete your Deepinfra data-handling review before moving to real material.
Test the workflow without exposing real records
- Use synthetic input
- Inspect the returned text
- Verify current handling terms
Deepinfra privacy FAQ
Inspect the entire payload for secrets, personal data, and identifying context. Then check the current Deepinfra documentation for terms that apply to your intended service and consider whether a synthetic prompt would answer the same question.
No. This guide cannot verify current retention practices or the settings for a particular deployment. Consult the provider's current documentation and seek a direct answer for any requirement your decision depends on.
That depends on the document, your organization's rules, and the applicable provider terms. Do not submit confidential material merely because a test with public text worked; obtain the required review and minimize the material sent.
Yes. A Deepinfra response may include details supplied in its prompt, which can create exposure if the output is saved or shared. Review output storage and access alongside the original request.