Before you paste source code into an AI detector, check what the service collects, how long it keeps submissions, and who can access them.
A few lines in its privacy policy can clarify whether your code may be stored, shared, or used to improve a model.
Why privacy matters when using an AI code detector
Source code can contain more than the logic you want analyzed.
It may include unreleased product features, internal names, API endpoints, comments, database structures, or credentials accidentally left in a file.
Submitting a snippet to an external service may transfer that information beyond your device or organization.
An AI code detector attempts to classify code by characteristics associated with AI-generated or human-written code.
That classification is different from code similarity or plagiarism analysis, which compares code against other known material.
Neither type of score establishes who wrote a particular program or proves misconduct.
Privacy review is useful even when a detector is only being used for an informal check.
Policies vary by provider, account type, and product, so do not assume that a free checker, paid service, browser extension, or institutional tool handles submissions in the same way.
What should you look for in the privacy policy?
Search the service’s privacy policy, terms of service, and product documentation for clear answers to these questions:
- What information is collected? Look for source code, prompts, uploaded files, account details, device data, IP addresses, and usage logs.
Check whether the service collects the whole file or only the submitted text. - How is submitted code used? Determine whether it is processed only to return a result, reviewed for support or safety, or used to develop or train models.
Note whether the policy distinguishes code from other user content. - How long is it retained? Look for a stated retention period, deletion schedule, or criteria for keeping submissions. “As long as necessary” may leave the timing unclear; check linked documentation for more detail.
- Who can access it? Check whether access is limited to service providers, employees, contractors, or affiliates, and whether the company describes safeguards or access controls.
- Is it shared with third parties? Identify hosting providers, analytics companies, model providers, or other recipients.
A policy may allow sharing to operate the service without naming every vendor in the main text. - Can you delete submissions? Find out whether you can delete an upload or account, whether deletion applies to backups, and whether any exceptions apply for legal, security, or operational reasons.
- Does the policy cover your use case? Check whether the terms differ for logged-in users, business accounts, education plans, API access, or organization-managed accounts.
How to review a detector’s policy step by step
- Confirm the exact service. Verify the website address and product name.
Search results and third-party descriptions may refer to a different tool or an older policy. - Open the current policy and terms. Use links provided by the service itself.
Check the effective or updated date and whether the detector has separate terms from the company’s other products. - Search for key terms. Use the page’s find function for words such as “code,” “content,” “submission,” “retain,” “training,” “improve,” “delete,” “share,” and “third party.” Read the surrounding paragraphs rather than relying on one matching phrase.
- Follow linked documents. The privacy policy may point to a data-processing agreement, security page, FAQ, or account-specific terms.
Review the documents that apply to your plan and region. - Compare policy language with the upload flow. Note what the form says about file types, account requirements, and data use.
If the upload screen makes a promise that the policy does not explain, seek clarification before submitting sensitive code. - Record unresolved questions. If the policy does not say whether code is retained or used for training, contact the provider or choose a workflow with terms your organization has approved.
Red flags and unclear language
A missing retention period is a reason to ask how long code remains available.
Broad permission to use “user content” may be ambiguous if the document never specifically addresses source code.
Likewise, a statement that data is “de-identified” does not by itself explain what is removed, whether code can still reveal confidential details, or how re-identification risk is handled.
Be cautious about relying on a marketing claim such as “private,” “secure,” or “not stored” without checking its scope.
It may apply only to a particular account tier, only after processing, or only to information submitted through a specific product.
Look for definitions, exceptions, and the date of the claim.
If the policy is silent, do not interpret silence as a promise that code is not stored or shared.
For work code, follow your employer’s, client’s, or school’s rules and ask the responsible security or privacy contact when needed.
Reduce exposure before submitting code
If using an external service is allowed, submit the smallest useful sample.
Remove API keys, passwords, access tokens, personal information, proprietary comments, and internal identifiers.
Replacing names alone may not make code anonymous if its structure or logic reveals confidential product details.
Prefer a local or organization-approved workflow when code is sensitive.
Check whether the service offers account controls or contractual terms that address retention and model training, and verify that those terms actually apply to your account.
Avoid uploading an entire repository when a short, non-sensitive excerpt is sufficient.
Privacy questions specific to code detection
Ask whether the detector stores the submitted code alongside its result, whether staff can inspect it, and whether the provider sends it to another model or analysis service.
Also ask whether the output itself contains or reproduces parts of the submission, and whether deletion requests cover both code and related logs.
Do not confuse a privacy statement with evidence that a detector can reliably identify authorship.
AI-authorship classification is an uncertain inference, and a detector’s result should not be treated as proof that a person used AI.
Similarity tools answer a different question by identifying matching or related code; their findings also require context and review.
For example, Turnitin states that its AI writing model does not reliably detect code.
Its AI writing report should not be confused with source-code similarity products.
Codespy is an external source-code detector; review its current privacy terms directly before submitting code, and do not treat a product mention as an independent test or endorsement.
What to do when the policy does not answer your questions
Send the provider specific questions: Is submitted source code retained, for how long, and can it be used to train or improve models?
Which vendors process it?
How can a user request deletion, and what data remains in backups or logs?
Ask for answers that apply to your plan and submission method.
If you cannot establish terms that fit your requirements, do not submit confidential or restricted code.
Use an approved alternative, request an internal review, or limit any evaluation to code that is safe to disclose.
Revisit the policy before future use because services can change their practices and documentation.