Author interview
PerfectPaper asks targeted questions about design decisions and fixed constraints before review, then carries your answers into the critique.
SOLUTIONS
Check three things before uploading an unpublished manuscript to an AI tool: your plan's training default, its retention window, and your institution's policy.
Affiliations
Current platform
PerfectPaper now carries context from setup through research, revision, and export—without turning the paper into a generic writing prompt.
Prepare
PerfectPaper asks targeted questions about design decisions and fixed constraints before review, then carries your answers into the critique.
Search the journal catalogue, choose up to three targets, and compare compatible open-access journals before the review starts.
Brief up to three custom reviewers, declare ground truths, attach instructions, and choose standard or deep-research depth with specific tools.
Investigate
Specialist reviewers inspect the full paper in context, including figures and tables—not isolated paragraphs.
Deep-research reviewers can search the web and scholarly literature, inspect sources, and attach vetted citations to research-backed findings.
The reading room shows which review areas are working, which findings have arrived, and when a research step could not complete.
Revise
Move between each comment and its passage, read your paper as you wrote it in Word, filter feedback, and discuss any finding.
Preview suggested revisions, apply accepted changes, keep an edit history, and reverse a change without losing the review trail.
Export the revised paper and saved feedback as DOCX, annotated PDF, or print view, and prepare an anonymous copy for blinded review.
Uploading an unpublished manuscript to ChatGPT is safe or unsafe depending on which product and which plan you are signed in to. Consumer chat, business and API accounts differ on retention, on whether your content may improve future models, and on their defaults. Check three things: your plan’s training default, its retention window, and your institution’s policy.
Those three checks are the whole answer. The rest of this page explains what each one means, where the answer is written down, what journal and funder rules add on top, and what to do when the tool you are permitted to use is not the tool you wanted.
Yes — ChatGPT’s terms do not forbid it. Whether doing so is advisable is a separate question that depends on your plan’s training default, its retention window, and your institution’s policy on third-party AI services for unpublished research data. Check all three before uploading; “permitted by the vendor” is not the same as “permitted by your funder or your co-authors.”
The same three checks apply, because each vendor sets its own defaults and publishes its own terms rather than following one shared industry standard. Anthropic, Google and OpenAI differ in which tier trains on content by default and how long a deleted item persists, so a policy written around “ChatGPT” by name may not answer the question for a different product at all — re-run the check per vendor.
No. Sending a manuscript to an AI service is processing, not publication — it creates no public record and nothing a reader could cite. Prior-publication policies (sometimes called the Ingelfinger rule) concern public dissemination, such as posting the full text somewhere indexable, not a private exchange with a chatbot. Confidentiality and disclosure are the real questions here, not novelty.
Whether your content can be used to improve a model is usually a per-plan setting rather than a per-company fact. The same vendor often applies one default to a consumer account and a different one to an API or enterprise account, and the control may be a toggle you have to find rather than a default you inherit.
The clearest worked example is the sentence researchers quote most often. OpenAI’s API documentation states that “As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us).” That sentence is accurate and it is about the API — the programmatic interface a developer calls with a secret key. It is not a statement about the ChatGPT web app you signed into with your university address, and transplanting it from one to the other is the most common error in this whole subject. When a colleague tells you “OpenAI doesn’t train on your data”, ask which of the two they read it in.
Read the terms attached to the plan you are actually signed in to, and check the setting rather than assuming it. This is the item researchers most often get wrong, because a colleague’s accurate description of their own account may not describe yours. In the ChatGPT web app the relevant controls sit under Settings, in the data controls section; on business and education tiers a workspace administrator’s configuration can override an individual member’s choice, so the switch you see is not always the switch that governs you.
Ask a fourth question that almost nobody asks: whether your content may be used to build evaluation or benchmark datasets. Training corpora and evaluation corpora are separate collections under separate governance, and a commitment not to train does not automatically speak to the second. The procurement checklist puts that question, and fifteen others, into a form you can send to any vendor.
Some institutional and enterprise tiers apply a training exclusion automatically, with no user-facing toggle to check at all — the absence of a switch is itself the answer on that tier. Confirm with the administrator that this is actually how your specific tier is configured rather than assuming it from the tier’s name alone; procurement language and the deployed configuration are not guaranteed to match on day one.
It depends on the plan. OpenAI’s API documentation states that, as of March 1, 2023, data sent to the API is not used to train or improve models unless you explicitly opt in — but that sentence describes the API, not the consumer ChatGPT web app. Open Settings → Data controls in your own account and check the model-improvement toggle directly rather than assuming either default applies to you.
Temporary Chat and the account-level training toggle are two different settings, and turning one on does not automatically configure the other. A conversation excluded from training by one setting can still fall under the ordinary abuse-monitoring retention window governed by the other — check both settings by name in Settings → Data controls rather than assuming either one implies the other.
Retention is a separate question from training, and the two are routinely confused. A service may commit to not training on your content while still storing that content for a period for abuse monitoring, support, or legal reasons.
For an unpublished manuscript the question worth asking is how long a copy exists after you delete the conversation, and whether deletion happens immediately or on a schedule.
OpenAI’s API documentation shows what a specific answer looks like, in numbers. Abuse-monitoring logs “are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law, or is reasonably necessary to protect our services or any third party from harm”. Objects related to the Assistants API “are deleted from our servers 30 days after you delete them via the API or the dashboard”, and — the clause that matters more — “objects that are not deleted via the API or dashboard are retained indefinitely”, so a file you merely stop using is not a file you have removed. Prompt caches store data on local GPU machines that “is not retained after the 24-hour expiration”. Zero Data Retention, the arrangement that excludes customer content from those logs altogether, requires prior approval and does not cover every endpoint: conversations, assistants, threads, files and vector stores are all marked ineligible. Those are the terms of a developer contract; the consumer chat product publishes its own windows separately, which is exactly why the plan you are signed in to has to be identified before any number means anything.
Read the qualifying clause, not the headline number. “Unless longer retention is required by law” is the clause doing the real work. A preservation obligation arising from litigation or a regulatory demand can suspend an ordinary deletion schedule without any change to the published policy and without notice to the individual account holder. A published retention window describes the ordinary case, so treat any figure you are quoted as a floor on exposure rather than a ceiling.
Write down three retention facts for whichever service you choose: the window for a deleted conversation, the window for abuse-monitoring copies of the same text, and whether those two windows are the same. They frequently are not, and the second usually outlives the first. A vendor that answers the first question and skips the second has answered the easier half.
A stated deletion window describes primary storage. Most cloud services also keep encrypted backups for disaster recovery on a separate, usually longer, cycle that consumer-facing help pages rarely disclose — treat a published window as a floor on how long a copy can exist somewhere, not a ceiling, and ask explicitly about backup retention if that distinction matters to your case.
Staff access is normally limited and governed by the terms attached to your specific plan, though most providers reserve a narrow exception for safety or abuse investigation. OpenAI’s API documentation, for example, describes abuse-monitoring logs retained for up to 30 days unless longer retention is required by law — that exception is the stated case for “someone reads this,” not proof no one ever does.
Deleting a conversation removes it from your own view immediately, but backend deletion of the underlying copy typically runs on its own schedule, and abuse-monitoring copies sit under a separate, usually longer, window than the conversation itself. A published retention figure describes the ordinary case; it is a floor on exposure, not a guarantee about the last copy anywhere.
Most universities and research institutes now have written policies on third-party AI services, and a growing number name specific products as approved or not approved for unpublished research data. Research offices, IT security teams, and grant compliance teams may each hold a view, and a grant’s data management plan may constrain the answer further.
Checking takes one email and settles the question more definitively than any vendor page can, including this one. If you are the person being asked, the procurement checklist lists the questions worth putting to any vendor.
Make the email specific enough to be answerable in one reply. Name the exact product and tier, say what will be uploaded — a full manuscript draft, a methods section, a figure legend — say whether it contains personal data from research participants, and ask for a yes, a no, or a named alternative service. A question phrased as “is ChatGPT allowed?” produces a policy link. A question phrased as “may I paste the results section of an unpublished manuscript containing no participant identifiers into a personal ChatGPT account?” produces a decision you can keep.
Funder rules sit alongside institutional ones and are not superseded by them. The US National Science Foundation’s notice of 14 December 2023, “Notice to Research Community: Use of Generative Artificial Intelligence Technology in the NSF Merit Review Process”, states that “Proposers are encouraged to indicate in the project description the extent to which, if any, generative AI technology was used and how it was used to develop their proposal.” Where an institutional rule, a funder rule and a publisher rule all apply, the strictest applicable one governs — and in practice that is usually the institutional one, because it is the only one written by people who can see your data classification.
Signing up with a university email address is not, by itself, the thing your institution’s policy is checking for. The institutional relationship that policy relies on exists only where the university has actually signed an enterprise or education agreement with the vendor; an account opened individually under an @university.edu address, on the vendor’s ordinary consumer terms, is still a personal account for this purpose even though it looks institutional. Ask your IT security office whether an agreement exists, not just whether your address was accepted at sign-up.
A personal consumer account creates no contractual relationship between your institution and the vendor, and that absence — not the vendor’s security posture — is what most institutional policies are actually about.
Where an unpublished manuscript contains personal data, the General Data Protection Regulation makes your institution the controller. Article 28(1) provides that “Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.” Article 28(3)(a) requires that a processor “processes the personal data only on documented instructions from the controller”. An account held in your own name, under consumer terms you accepted personally, gives the institution no processor, no documented instructions, and no mechanism to satisfy either clause.
That is a structural defect rather than a security one, and it is why a research office can refuse a service whose engineering it does not dispute. It bites hardest on work that carries participant material inside the manuscript itself: verbatim interview quotations in a qualitative results section, unstructured clinical narratives, small-cell demographic tables in which an individual is identifiable. Ethics and data-sharing statements are the part of a paper where this most often becomes visible, and qualitative rigour manuscripts carry the exposure in their central evidence.
Replacing a participant’s name with a code such as “P4” does not, on its own, move a quotation out of scope. GDPR’s own framing looks at whether a person remains identifiable from what is left — a rare job title, a specific clinic, an unusual combination of age and diagnosis can re-identify someone even with the name removed. Pseudonymised is not the same status as anonymised, and the difference is a judgement about the surrounding detail, not about whether a name string appears on the page.
Purely methodological or theoretical text carries none of this, and the exposure also scales with how much of the manuscript you paste in. A high-level abstract summary typically carries less of the concrete, re-identifiable detail this section is about than a results section built from verbatim quotations, raw case narratives or small-cell tables — but “less” is not “none,” and an abstract can still contain a rare diagnosis or a small identifiable cohort on its own. Treat the amount and specificity of what you paste as a variable you control, not as an all-or-nothing choice between the whole file and nothing. The distinction worth drawing is between a manuscript that is merely confidential and one that also contains personal data, because only the second engages a data protection regime.
“Unsafe” collapses three different failures with three different remedies, and naming which one you are worried about shortens every subsequent conversation.
One: your text becomes training data. The manuscript enters a corpus used to improve a future model. The remedy is a plan whose default excludes it, confirmed in the account settings rather than assumed, or a service that trains on nothing at all. Turning the setting off today does not reach backward: training is a discrete process run against a fixed corpus snapshot, so a manuscript already incorporated into a released model checkpoint before you changed the setting is not withdrawn by changing it — the setting only governs what happens next. This is the failure researchers fear most.
Two: your text persists and is readable. A copy survives deletion for a defined window, may be examined by staff under an abuse-review process, and may be produced under a legal obligation. The remedies are a shorter window, an exclusion arrangement where the vendor offers one, and deleting promptly rather than leaving drafts in a chat history for months. The honest limit: no vendor setting defeats a lawful order. This is the failure that actually appears in institutional assessments.
Three: your text reaches a third party in breach of an obligation you personally hold. A referee’s confidentiality undertaking, a funder’s review rules, a collaborator’s embargo, an industry partner’s agreement. There is no vendor remedy at all here, because the rule binds you rather than the service, and better privacy terms do not cure it. This is the failure that ends careers rather than papers.
For an author working on their own manuscript, failure three is usually not in play, failure one is what gets asked about, and failure two is what gets audited. Ranking them in that order tells you where to spend your attention.
Whether it is safe to upload and whether you must disclose are separate questions with separate answers.
Journal policies for authors typically permit AI assistance and ask for a disclosure statement. The confidentiality rules that prohibit uploading a manuscript outright are usually aimed at peer reviewers handling another author’s work, not at authors handling their own. Confusing the two leads researchers to avoid tools they are permitted to use — journal AI policies for authors and referees covers the distinction in full.
The ICMJE Recommendations set the author-side expectation directly: “At submission, the journal should require authors to disclose whether they used artificial intelligence (AI)-assisted technologies”, and “If AI was used for writing assistance, describe this in the acknowledgment section.” The same document rules out AI authorship — “Chatbots (such as ChatGPT) should not be listed as authors because they cannot be responsible for the accuracy, integrity, and originality of the work” — and puts the verification burden on you: “Authors should carefully review and edit the result because AI can generate authoritative-sounding output that can be incorrect, incomplete, or biased.”
Elsevier publishes a declaration template authors can copy: “During the preparation of this work the author(s) used [NAME OF TOOL/SERVICE] in order to [REASON]. After using this tool/service, the author(s) reviewed and edited the content as needed and take(s) full responsibility for the content of the publication.” Check your target journal’s wording before submission, because placement varies — some specify the acknowledgements, some a dedicated declaration section, and a few ask for it in the cover letter instead.
Journals also differ in how granular the disclosure has to be, and treating them as one requirement is the second most common error here. Some ask only for a blanket statement that AI assistance was used somewhere in preparing the manuscript. Others ask authors to name which sections it touched and to what end — language polish versus data analysis are different disclosures even under the same template — so copying a declaration you used for one journal into a submission to another can under-disclose without you noticing.
An assigned referee handling someone else’s manuscript is under a different rule, and that rule is a prohibition rather than a disclosure requirement.
The ICMJE Recommendations state that “Reviewers must maintain the confidentiality of the manuscript as outlined above, which may prohibit the uploading of the manuscript to software or other AI technologies where confidentiality cannot be assured”, and that “Reviewers must request permission from the journal prior to using AI technology to facilitate their review.” Elsevier states that “Reviewers should not upload a submitted manuscript or any part of it into an AI tool as this may violate the authors’ confidentiality and proprietary rights and, where the paper contains personally identifiable information, may breach data privacy rights” — author confidentiality, proprietary rights, and data privacy being the three stated reasons. Elsevier does allow narrow supportive uses on a private tool, such as improving the language of the review report or a background literature search, provided confidentiality is maintained and the use is disclosed to the journal. The line sits between the report and the manuscript, not between “using AI” and “not using AI”: asking a tool to tighten a sentence in your own draft report stays on the permitted side, while asking it to summarise, explain or evaluate a passage of the submission — even one sentence, even paraphrased rather than pasted verbatim — moves the manuscript’s content into the tool and crosses it.
Grant review is stricter still. NIH notice NOT-OD-23-149, released 23 June 2023 and titled “The Use of Generative Artificial Intelligence Technologies is Prohibited for the NIH Peer Review Process”, states that “NIH prohibits NIH scientific peer reviewers from using natural language processors, large language models, or other generative Artificial Intelligence (AI) technologies for analyzing and formulating peer review critiques”, and that “uploading or sharing content or original concepts from an NIH grant application, contract proposal, or critique to online generative AI tools violates the NIH peer review confidentiality and integrity requirements”. The NSF notice of 14 December 2023 is equally direct: “NSF reviewers are prohibited from uploading any content from proposals, review information and related records to non-approved generative AI tools.”
Note what NIH gives as its reason — that “AI tools have no guarantee of where data are being sent, saved, viewed, or used in the future”. That reasoning does not depend on a vendor’s terms improving, which is why a better privacy policy does not unlock referee use. Reviewers using AI on manuscripts treats the referee case on its own, and peer review sets out the confidentiality expectation the rules are protecting.
Checking your own account is a six-step procedure with a written result, not a judgement call.
Researchers without a research office behind them — independent researchers and many PhD students working across institutions — should keep the same record anyway, because it is the evidence that the check happened.
The obvious remedy — use only an institutionally approved service — fails in five recognisable situations, and each has a different next step.
Your institution has no written policy. Then the data management plan, the journal’s rules and the funder’s rules govern. Ask once in writing, keep the reply, and treat the absence of a policy as an unanswered question rather than as permission.
The approved service is worse than the one you want. Request a scoped exception rather than a blanket one: name the service, the tier, the specific document, the retention setting and the deletion date. Narrow requests get decided; broad ones get deferred.
You have already uploaded it. Delete the conversation, record what you uploaded and when, and check whether the model-improvement switch was on at that moment. Then ask the proportionate question: were you the author or the referee? An author uploading their own draft under a vendor’s ordinary terms has done something disclosable, not something reportable. A referee who uploaded someone else’s manuscript should tell the handling editor promptly — editors deal with this regularly, and a late self-report is treated far better than a discovery.
The manuscript is not entirely yours. Unpublished data contributed by a collaborator, material under an industry agreement, or a co-author’s section under embargo travels with its own restrictions. Consent to upload is not something one co-author can give on behalf of the group.
A co-author has already uploaded it. Establish which account and which tier, apply the same six-step check to their account rather than yours, and record the result once for the whole author group. On multi-institution papers the strictest institutional rule in the group is the one that governs the manuscript.
PerfectPaper never uses your content to train a model — not the paper, not the model’s reasoning, not its reply, not the derived metadata. Manuscripts uploaded to PerfectPaper are stored in EU object storage and can be deleted from your account, with a self-service path for erasure requests; files uploaded before 27 August 2026 remain in their original region and were deliberately not moved. Every processor that receives your text is named publicly along with what it receives, so an institutional reviewer can evaluate the chain without having to ask.
Against the three checks: the training default is not a per-account setting you have to find, because there is no setting — PerfectPaper trains no models and fine-tunes none, and its evaluation corpus is eight synthetic papers written for the test harness rather than any customer’s work. Retention is your decision, because your manuscript and review stay in your account until you delete them. And the institutional question is answerable from public pages, because the application tier and database run in Frankfurt, storage is in the eu-central region, and the subprocessor list reports live configuration rather than a static claim.
Accounts are limited to verified academic researchers, which narrows who can hold your work on the platform at all. How the no-training guarantee is enforced explains what holds that sentence up, including the part PerfectPaper does not claim: enforcement rests on contract terms with the model providers rather than on a per-request switch, because few provider interfaces offer such a switch.
The wider picture is on secure AI review for unpublished research, including what PerfectPaper does not claim, and where your manuscript is processed sets out the full route, including the components that do not run in Europe.
Secure AI review for unpublished research · AI that never trains on your research · Where your manuscript is processed · Journal AI policies for authors and referees · Procurement checklist
A manuscript under review is still confidential regardless of who is asking. If you are the author, you may generally use AI assistance on your own work subject to disclosure. If you are the assigned referee, most publishers prohibit uploading any part of the manuscript to an external AI tool, and the ICMJE Recommendations require reviewers to seek the journal’s permission before using AI at all.
Delete the conversation, and write down what you uploaded, when, and whether the model-improvement toggle was on at that moment. Then ask which role you held: an author uploading their own draft under a vendor’s ordinary terms has done something disclosable, not something reportable, while a referee should tell the handling editor promptly — a late self-report is treated far better than a discovery.
Potentially, yes, because consent to upload a shared manuscript is not something one co-author can give for the whole group, especially where a collaborator’s data, an industry agreement, or an embargoed section is involved. Establish which account and tier your co-author used, apply the same three checks to it, and record the result once for the whole author group rather than assuming your own account settings cover it.
The same three checks apply, with one addition: a thesis containing unpublished chapters intended for later journal submission carries the same exposure as a manuscript, and university policies on third-party services usually cover student work explicitly. Check your programme’s own rules alongside the institutional AI policy — a graduate school’s policy and a research office’s policy are not always the same document.
A service whose terms state that customer content is not used for training, that names its subprocessors publicly, and that gives you a deletion path you control rather than one you have to request. Those three properties can be checked in advance from published pages. A general assurance that a company takes privacy seriously cannot be checked at all, which is the tell.
Last updated September 10, 2026
Upload your paper and receive structured, sourced feedback before you submit.
Connection lost
Reconnecting…
Something went wrong on our end
Attempting to reconnect