Secure AI review for unpublished research

PerfectPaper reviews unpublished manuscripts, and never uses your content to train a model. Not the paper, not the model’s reasoning, not its reply, not the derived metadata. Application servers, database and document storage run in Frankfurt and the eu-central region, and every third party that receives any part of your manuscript is named publicly.

An unpublished manuscript is the one document in a researcher’s working life with no protection from a publication date. The findings are not yet credited, the priority claim is not yet established, and the methods are not yet in the public record. That is a different risk profile from a published PDF, and it deserves different handling. This page answers the questions a research office asks, in specifics rather than in adjectives.

Why an unpublished manuscript is a different risk class

An unpublished manuscript carries four exposures that a published paper does not, and each has a different remedy. Naming them separately matters, because a single assurance about confidentiality addresses only the first.

Priority. Until the work is public, nothing in the record establishes that you had the finding first. Confidentiality protects the document; it does not create a claim. The mechanism that creates one is a timestamped public deposit — bioRxiv, medRxiv, arXiv, SSRN or Research Square — and a preprint is compatible with almost every journal’s policy provided it is declared at submission. That compatibility is not universal, though: a minority of journals, particularly in clinical medicine, still apply a stricter version of the traditional prior-publication rule to trial results specifically, so confirm your target journal’s instructions to authors before you post a preprint, not after. If priority is the thing you are actually worried about, a stricter vendor does not solve it and a preprint does.

Patent novelty. United States law at 35 U.S.C. § 102(a)(1) bars a patent where the claimed invention was “patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention”. Section 102(b)(1) then provides that “a disclosure made 1 year or less before the effective filing date of a claimed invention shall not be prior art to the claimed invention under subsection (a)(1)” where the disclosure came from the inventor. That one-year grace period is a United States provision and does not travel; whether an equivalent exists where you intend to file is a question for your technology transfer office, and it is worth asking before a preprint rather than after one. Ask specifically, because the answer is not uniform: a number of major patent offices outside the United States apply an absolute-novelty standard with no general grace period at all, so a disclosure that is harmless under §102(b)(1) can still be fatal to a filing elsewhere.

Participant data. A manuscript under review often carries more identifiable material than the version that will eventually be published: small-cell subgroup tables, verbatim interview quotations, participant-level supplementary files. Reduce those to the reporting-level text your journal will publish anyway before any third-party tool receives them. That reporting-level bar is a different, and generally lower, threshold than the de-identification your ethics board approved for the original data collection — clearing the second does not automatically clear the first, so treat manuscript text as its own disclosure decision rather than one inherited from your IRB approval’s scope. This is the same discipline that ethics and data-sharing statements already require of you.

Someone else’s confidence. A collaborator’s unpublished dataset, an embargoed result carried into your discussion, or a manuscript you have been assigned to referee are not yours to route anywhere. The last of those is a hard line rather than a judgement call — see reviewers using AI on manuscripts.

Common questions about priority and confidentiality

Will an AI reviewer scoop my results before I publish?

Not on its own. PerfectPaper never trains a model on your manuscript, so running a review does not put your findings into any system another researcher could later draw from, and confidentiality is a separate guarantee from priority. What actually establishes that you had the finding first is a timestamped public deposit — bioRxiv, medRxiv, arXiv, SSRN or Research Square — not the absence of a tool in your workflow.

Does running my manuscript through an AI tool count as prior publication?

No. Using an AI tool to review your own draft is not publication in any sense a journal’s prior-publication rule recognizes, because nothing is made public. Most journals ask authors to disclose AI assistance rather than treat it as disqualifying; the confidentiality rule that restricts peer reviewers, such as NIH notice NOT-OD-23-149, binds referees handling someone else’s application, not authors reviewing their own manuscript.

Do I need my co-authors’ permission before uploading our paper to an AI reviewer?

Not for a paper you jointly authored and control together, but yes for anything embedded in it that belongs to someone else. Co-author notes, an embargoed result carried into your discussion, or a collaborator’s unpublished dataset are not yours alone to route anywhere — ask before those specific materials go into any third-party tool, PerfectPaper included.

Your research is never used to train a model

PerfectPaper never uses your content to train a model. Three separate things make that true.

PerfectPaper’s own code trains nothing and fine-tunes nothing, so no customer manuscript is training data by construction. The model providers that process your text are bound by commercial and cloud contract terms rather than by a per-request switch. And PerfectPaper’s evaluation corpus contains no customer work at all — it is eight synthetic papers written for the test harness with deliberately planted flaws.

The middle layer is the one worth reading closely, and how the no-training guarantee is enforced sets it out in full, including what PerfectPaper does not do.

The reason to read it closely is that the enforcement is contractual, not technical. PerfectPaper sends no per-request do-not-train flag, because most provider APIs do not offer one; the commitment rests on the agreements under which those providers process the traffic. A research office is entitled to know which kind of guarantee it is being handed, and a vendor that lets you assume the technical one when it holds the contractual one has told you something untrue by omission.

Training, retention, human review and evaluation are four commitments

Training, retention, human review and evaluation-set inclusion are four separable commitments, and a vendor can honour any one of them while doing the other three. “We do not train on your data” is the answer to one question out of four, and it is the question most often asked alone.

The fourth row is the one most often omitted from a vendor answer, and it is the one worth asking explicitly, because an evaluation set is not training and a company that has answered honestly about training has not yet answered about it. The procurement checklist puts all four in a form you can send to any vendor, including this one.

The human-review row is the narrowest of the four, and the easiest to overstate in either direction. It is not routine quality assurance — providers describe it as exception handling for suspected safety or abuse violations — but PerfectPaper receives no telemetry on how often that trigger fires, so treat it as real and bounded rather than as either negligible or common.

Common questions about training and data use

Is my unpublished paper used to train AI models?

No. PerfectPaper never uses your content to train a model — not the paper, not the model’s reasoning, not its reply, not the derived metadata. PerfectPaper’s own code trains on nothing, and the model providers processing your text are bound by contract terms rather than by a per-request setting that most provider APIs do not even offer.

Will ChatGPT or Claude’s own team ever read my manuscript?

Only under a narrow, provider-controlled exception, and PerfectPaper does not control when it fires. Model providers reserve limited human review for safety and abuse investigation under their own terms; in practice that is exception handling for suspected misuse, not routine quality assurance — but PerfectPaper has no visibility into how often it fires and does not claim a rate it cannot observe.

Is it safe to use an AI reviewer on an unpublished manuscript?

Safety resolves into four properties you can check in advance: whether customer content trains a model, how long it is retained, who may read it, and whether every processor is named. PerfectPaper answers all four in public, and is equally explicit about what it does not hold — no external audit report, and no user-facing switch guaranteeing EU-only inference.

Where your manuscript is processed

PerfectPaper runs in Frankfurt. Application servers and the PostgreSQL database are hosted there, and manuscripts uploaded to PerfectPaper are stored in EU object storage in the eu-central region, encrypted at rest. That encryption protects the stored file from someone who obtains a disk or a backup; it says nothing about the manuscript text while it sits in memory on a model provider’s inference server during the review itself, which is a distinct exposure this page does not represent as covered by the same control.

Producing a review requires sending manuscript text to model providers, so the route those calls take is the part that matters most for an institutional assessment. Where your manuscript is processed sets out the full route, including the components that do not run in Europe.

Two specifics from that page belong here, because they are the two an assessment usually turns on. Storage residency and processing residency are different questions with different answers: the region a document is stored in is a property of that document, carried in its storage key, while the region a review runs in is deployment configuration reported from the running system rather than typed into a template. And the estate is mixed by date rather than uniform — files uploaded before 27 August 2026 remain in Ohio, in the us-east-2 region, and were deliberately not moved rather than quietly relabelled.

Who receives your manuscript, and how much of it

Not every service PerfectPaper uses receives the whole paper. The review models receive manuscript text, because reading the manuscript is the work. The embedding service receives far less — a title and an abstract, not the body — and the scholarly lookup services never receive the paper at all.

The subprocessor page names every one of them and states what each receives. That page is the authoritative list and reports live configuration; this page summarises it and will always be the less current of the two. Under GDPR Article 28, each named company acts as a sub-processor to PerfectPaper’s own role as processor for its institutional customers, which is why that list — not a certification — is the operative document for a data protection impact assessment.

The shape of the answer is worth understanding before you read the list, because the count of subprocessors is the least informative number on it. Three model providers receive manuscript text, and they receive markedly different amounts of it. Anthropic models run the reviewers and the verification pass and receive the whole paper on every review; Google’s Gemini API receives the whole paper for the literature and journal research lanes; Voyage AI receives a title and abstract only, turned into embeddings for journal and literature matching.

Crossref, OpenAlex, Semantic Scholar and ORCID sit outside that set entirely: they receive one identifier at a time — a title, a DOI, an author name — and never the paper. Three more subprocessors hold the paper rather than read it: Fly.io runs the application, Fly Managed Postgres holds the parsed paper and every finding written about it, and Amazon S3 holds the uploaded file itself. Everything else on the list handles payments, email, edge delivery or diagnostics. A vendor table that lists company names without a column for what each one receives hides the only distinction an author cares about, because it makes a diagnostics tool and a model provider look like the same kind of exposure.

Questions about where your manuscript goes

Where is my manuscript stored?

Manuscripts uploaded to PerfectPaper are stored in EU object storage in the eu-central region and encrypted at rest; application servers and the PostgreSQL database run in Frankfurt. Files uploaded before 27 August 2026 remain in the us-east-2 region in Ohio and were deliberately not moved rather than quietly relabelled as European.

Who else can see my manuscript?

No other PerfectPaper user can see your manuscript unless you share the workspace with them. Model providers and a small number of named service providers process it to produce your review, and each one is listed on the subprocessor page along with exactly what it receives — a title, an abstract, or the whole paper.

What else you upload alongside the manuscript

A PerfectPaper review takes more than the manuscript, and the supporting material is unpublished too. Supporting documents are classified into six kinds — a reviewer letter, journal guidelines, a grant call, co-author notes, a prior draft, or other — and each is stored, region-tracked and deleted through the same path as the manuscript itself.

Each supporting document carries a visibility of either private or workspace, recorded as a column on the document rather than as a share link that can be forwarded. A private document is bound to your user account; a workspace document is visible to the people you have already invited to that workspace, and to nobody else.

The reviewer letter deserves a note of its own. A decision letter is another journal’s confidential correspondence, but it was sent to you and it is yours to work with; uploading it so the reviewer’s objections can be read alongside your revision is an ordinary author act, not a referee act. That is the material how to write a response to reviewers is built around. Co-author notes are the one category worth a moment’s thought before uploading, because they may contain a collaborator’s unpublished material that the collaborator has not agreed to route anywhere.

Who else can see your work

No other PerfectPaper user can see your manuscript unless you share the workspace with them, and the population that could be invited is narrow by design. Opening an account requires an academic or government email address, checked against a rule rather than a claim on a form.

The rule accepts .edu, .gov and .mil; the academic and government second-level namespaces under a country-code domain — ac.uk, edu.au, ac.jp, gouv.fr, gob.mx, go.jp, govt.nz; and a named list of institutions whose domains follow neither pattern, because much of continental Europe never adopted one. Heidelberg is uni-heidelberg.de, ETH is ethz.ch, the Sorbonne is sorbonne-universite.fr, and Aristotle University of Thessaloniki is auth.gr. Subdomains inherit from their parent, so cs.tu-berlin.de passes on tu-berlin.de without needing an entry of its own.

That list will always be incomplete, and a named-institution list is the honest way to say so: a pattern-only rule turns away most of the researchers this product exists for. The consequence for your manuscript is the one that matters here — the set of people who can hold an account, and therefore the set who could ever be invited into a workspace holding your paper, is bounded by a published rule rather than by an open sign-up form.

What PerfectPaper does not claim

PerfectPaper holds no third-party security certification and does not imply one. Identifiable patient records belong in a repository under a data access agreement rather than in a manuscript body or any third-party tool, and should be reduced to reporting-level text before upload in line with your institution’s policy. Encryption at rest uses provider-managed keys rather than customer-managed keys.

Naming these plainly is deliberate. A research office evaluating a vendor needs the boundaries as much as the capabilities, and a page that lists only strengths is a page that has to be verified twice. If you are running that evaluation, the procurement checklist is written to be used against PerfectPaper as readily as against anything else.

Three further boundaries belong in the same list, stated as specifications rather than as apologies. Because there is no external audit report to request, an assessment has to rest on the published subprocessor list and on the residency, retention and deletion controls — which are, in any case, the properties that actually govern your data, where an audit report is a statement about the process that produced them. There is no user-facing switch that guarantees EU-only inference today, so if your ethics approval or your funder’s data management plan requires it, raise that through the security contact published in PerfectPaper’s security.txt before you upload rather than after. And no particular international transfer mechanism is represented as active until it is confirmed for the production processing path; the one that applies to your institution belongs in a signed agreement, not on a web page.

Using an AI reviewer without breaching journal policy

Using an AI reviewer on your own manuscript does not, by itself, breach journal policy: the rule that actually restricts AI use targets peer reviewers handling someone else’s submission, not authors reviewing their own draft. Journal policies on artificial intelligence treat those two roles very differently, and conflating them leads researchers to avoid tools they are permitted to use. Journal AI policies for authors and referees explains which rule applies to you and what a disclosure statement usually contains.

The strictest published version of the referee rule is worth quoting, because it is the text most often paraphrased into something broader than it says. NIH notice NOT-OD-23-149, “The Use of Generative Artificial Intelligence Technologies is Prohibited for the NIH Peer Review Process”, released 23 June 2023, states that “the 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 for grant applications and R&D contract proposals”, 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 notice gives its own reason: “AI tools have no guarantee of where data are being sent, saved, viewed, or used in the future.”

Read the subject of those sentences. The prohibition binds a reviewer handling someone else’s confidential application, and the objection is custody and consent rather than technology — which is why a better privacy policy does not cure it and why PerfectPaper is not a route around it. An author running a review of their own manuscript is not the person that notice addresses, and publisher policies for authors generally ask for disclosure rather than abstention. If you are unsure which side of the line you are on, ask who would have to consent for the upload to be proper: if the answer is anyone other than you and your co-authors, do not upload it.

Deleting your work

A manuscript and its review can be deleted from your account at any time. PerfectPaper also operates a self-service privacy rights path for access, correction, export and erasure requests rather than routing them through a support queue. Accounts are limited to verified academic researchers, which narrows who can hold your work on the platform in the first place.

What deletion reaches is defined in one place rather than assembled by hand: the set of storage keys a document owns is the original upload, every figure extracted from it, and every Word version’s blob. Before that set existed, version blobs could outlive the rows that named them — the kind of gap that produces a deletion which is honest about the database and silent about the object store.

Removing the stored object is then recorded as a durable intent rather than attempted as a side effect. A blob tombstone deliberately holds no owner, workspace or session foreign key, so the rows that produced a blob can be deleted in the same transaction that records the only surviving locator for it, and a cascade can never orphan an object in storage. The tombstone moves through pending, retryable, watching and complete, and there is no terminal failure state: a transient storage error retries indefinitely with bounded backoff, because a terminal state would strand a real object with no recovery path. That is the difference between a deletion feature and a deletion guarantee — and it reaches PerfectPaper’s own stores only. A model provider’s own short-term abuse-monitoring logs sit outside that guarantee entirely; they persist on the provider’s own retention schedule, independent of any deletion event you trigger here.

The rights path covers the requests a data protection officer will name by article: access under Article 15 of Regulation (EU) 2016/679, rectification under Article 16, erasure under Article 17 and portability under Article 20. Requests arrive through a form rather than a support queue precisely so the answer does not depend on who reads the mailbox.

Frequently asked questions

Does using PerfectPaper affect my ability to publish?

No. Using an AI tool on your own manuscript is not prior publication. Most journals ask authors to disclose AI assistance rather than prohibit it, which is a separate question from the confidentiality rules that restrict peer reviewers — NIH notice NOT-OD-23-149, for example, binds reviewers of grant applications, not authors of their own work.

Can I use PerfectPaper to review a manuscript I’ve been asked to referee for a journal?

No. That is the one hard line on this page rather than a judgement call: an assigned reviewer may not upload another author’s manuscript to PerfectPaper any more than to a general-purpose chat product, because the objection is the author’s lack of consent, and no vendor can supply that consent on the author’s behalf.

How long does PerfectPaper keep my unpublished manuscript?

Until you delete it. There is no automatic expiry and no separate archive copy once you have deleted them — removal covers the stored objects as well as the database rows. It does not, however, reach into a model provider’s own short-term abuse-monitoring logs, which persist on the provider’s own retention schedule regardless of your deletion here.

Can I delete my manuscript?

Yes. You can delete a manuscript and its review from your account at any time, and PerfectPaper operates a self-service privacy rights path for access, export and erasure requests. Deletion covers the original upload, every extracted figure and every Word version’s blob, and the stored object’s removal is recorded as a durable retry rather than a best-effort attempt.

How to verify every claim on this page

Verify the claims on this page in three tiers, because they are not all checkable by the same method. Knowing which tier a claim sits in is more useful than any assurance about the claim itself.

Checkable by you, right now. The subprocessor page reports live configuration, and it is code covered by tests: the tests fail if the configured review model is not listed, if a service that reads your paper does not name the country it runs in, or if an adapter holding no production credential is advertised as though it were in use. The account gate is checkable by trying an address. The deletion path is checkable by deleting something.

Checkable by asking. The security contact published in PerfectPaper’s security.txt takes institutional questions directly rather than through a sales process, and processing agreements, region constraints and organisation-level configuration are handled there. Reluctance to answer a specific question is itself informative, which is the premise the procurement checklist is built on.

Not checkable by anyone from outside. Whether a provider honours its contract terms is not observable from a web page, here or anywhere. This is the limit of what any vendor disclosure can do, and a page claiming otherwise is overstating. What a disclosure can do is name the parties, so that the commitment attaches to identifiable companies under identifiable terms instead of to an anonymous supply chain — see is it safe to upload a manuscript to ChatGPT for the same three checks applied to a general-purpose chat product.

What PerfectPaper is not for

PerfectPaper reviews original research articles that you wrote, submitted as .docx. It does not read LaTeX source, it does not referee other people’s manuscripts, and it does not decide anything: every finding is reported for a human author to accept, revise or reject.

The boundary that matters most for this page is the referee one. An assigned reviewer may not upload another author’s manuscript to PerfectPaper any more than to a general-purpose chat product, because the objection is the author’s lack of consent, and no vendor can supply that consent on the author’s behalf. If you are looking for a tool to help you write a review of someone else’s paper, this is not it, and peer review software covers what editors and referees actually use.

The second boundary is scope. Individual-level genomic data under controlled access and identifiable clinical trial records do not belong in a manuscript body or in any third-party tool merely because the paper around them is being reviewed — genomics review and clinical trial review set out what belongs in the paper and what belongs in a repository under a data access agreement.

Related

AI that never trains on your research · Where your manuscript is processed · Procurement checklist · Journal AI policies · What an AI peer review tool does

Review my manuscript