Where your manuscript is processed

PerfectPaper’s application servers and PostgreSQL database run in Frankfurt, and manuscripts uploaded to PerfectPaper are stored in EU object storage in the eu-central region, encrypted at rest. Producing a review requires sending manuscript text to model providers, and the subprocessor page reports each provider’s region from live configuration. Error monitoring and product analytics run on United States endpoints and receive no manuscript text.

This page is written for the person at your institution who has to sign off on that, so it includes the parts that do not run in Europe.

The route, stage by stage

PerfectPaper’s processing route has six stages, and residency is a separate answer at each one. A single sentence about “EU hosting” collapses all six, which is why data protection officers keep asking the same question twice.

Read the table downward rather than across. The first three rows are settled facts about a deployment; the fourth is a value read from configuration at render time; the last two are the rows most vendor pages omit.

Common questions about where the data goes

Where does my manuscript actually go when I upload it to PerfectPaper?

PerfectPaper’s application servers and PostgreSQL database run in Frankfurt, the uploaded file itself is stored in EU object storage in the eu-central region, and the review models run in whichever region the subprocessor page reports for that specific provider. Three destinations, three separate answers — no single phrase like “EU hosting” covers all of it at once.

Are my documents stored in the EU?

Manuscripts uploaded to PerfectPaper are stored in EU object storage in the eu-central region. That covers files uploaded from 27 August 2026 onward; documents uploaded earlier remain in their original Ohio (us-east-2) location and were never migrated, so the honest answer for an older file is whatever region is printed in its own storage key.

Compute and database

PerfectPaper’s application servers run in Frankfurt. The PostgreSQL database holding your account, manuscript metadata, and review history runs in the same region.

Nothing about the application tier is distributed across regions for convenience. Frankfurt is where it lives.

The database holds more than metadata in the narrow sense, and naming its contents is more useful than naming its region alone. It holds the parsed manuscript as structured JSON — every paragraph, table, figure and reference — because that structure is what the reading room shows you and what the reviewers read. It holds every finding written about your paper, every comment and edit, the interview questions drafted about your work and the answers you gave, and the access log. Placing that row set in Frankfurt puts it under the General Data Protection Regulation and the German Federal Data Protection Act, the Bundesdatenschutzgesetz, rather than under a regime chosen by a load balancer.

Document storage

Manuscripts uploaded to PerfectPaper are stored in EU object storage in the eu-central region, encrypted at rest with provider-managed keys rather than customer-managed keys.

The specifics behind that sentence are worth stating, because “encrypted at rest” is the least discriminating phrase in vendor security copy. At-rest encryption is AES-256 with storage-provider-managed keys, not an AWS KMS customer-managed key, and PerfectPaper reports which of the two is configured rather than letting the reader assume the stronger one. The stored object’s SHA-256 is verified during storage, so a corrupted or truncated write fails loudly instead of producing a manuscript that reads as short. The storage key itself is a region name followed by 24 random bytes: no filename, no account identifier, no title. A person holding a listing of the bucket learns the region and nothing else about whose paper it is.

Provider-managed keys and that integrity check answer two different threats, and conflating them is the shallow reading of “encrypted at rest”: AES-256 with a provider-managed key defends against a stolen disk or a breach outside the storage vendor, not against the storage vendor itself, which holds the key and can technically decrypt on its own infrastructure. A customer-managed key would move that boundary; it is not what PerfectPaper has configured.

Storage keys are region-prefixed, which means the region a document lives in is a property of that document rather than a global setting that can silently move. One consequence is worth stating: documents uploaded before EU storage was enabled remain in their original region and continue to be read from there. The estate is mixed by design rather than by oversight, and a migration would move those objects rather than relabel them.

The date is publishable, so it is published. Files uploaded before 27 August 2026 are in Ohio, in the us-east-2 region, and were deliberately not moved. If your assessment covers a manuscript uploaded before that date, the honest answer for that file is Ohio, and the region prefix on its key is what makes that answer checkable rather than a matter of recollection.

Questions about file storage and encryption

Which country is my uploaded file kept in?

Frankfurt, Germany, in the eu-central-1 region, encrypted at rest with AES-256 and provider-managed keys — for files uploaded from 27 August 2026 onward. Files uploaded before that date remain in Ohio, in the us-east-2 region, and were deliberately left there rather than moved; the region prefix on the file’s own storage key is what makes that answer checkable.

I uploaded my paper before the EU migration — is my old file still sitting in the US?

Yes. PerfectPaper’s storage keys are region-prefixed, so a document’s region is a property of that specific file rather than a global setting, and files uploaded before 27 August 2026 were left in Ohio (us-east-2) rather than relabelled or silently moved. A later migration would move the object itself, not just rename its region.

Are the encryption keys mine, or does the storage vendor hold them?

The storage vendor holds them. PerfectPaper’s at-rest encryption is AES-256 with provider-managed keys, not a customer-managed key such as an AWS KMS key you would control yourself, and the subprocessor page states which of the two is configured rather than leaving you to assume the stronger option.

The review itself

Producing a review means sending manuscript text to model providers, so this is the step that matters most for a residency assessment, and it is the step most vendor pages skip.

PerfectPaper reports the region for each provider on the subprocessor page, derived from the configuration the application is actually running under rather than declared in the page template. That design exists specifically so the page cannot claim a residency the traffic does not have. If a provider’s endpoint changes, the page changes with it.

The reason the answer is reported per provider rather than as a single verdict is mechanical, not evasive. Anthropic models run the reviewers and the verification pass; Google’s Gemini API runs the literature and journal research lanes. Moving each to Europe is a different piece of work — a Vertex europe-west4 deployment is a configuration change, while an Amazon Bedrock eu-central-1 route is a new adapter — so the two will land weeks apart. A page that reported the pessimistic answer for both would be understating the one that had already moved, and a page that reported the optimistic answer for both would be lying. Reading the value from the running configuration is the only version of that sentence that stays true without an editor.

What each provider receives

PerfectPaper’s providers receive different things depending on the lane, and that difference matters more than how many providers are on the list.

The review models receive manuscript text, because reading the paper is the work they do. The scholarly search and embedding services receive substantially less — a title and an abstract, not the body. When assessing exposure, that distinction is usually more informative than the length of the vendor list, and the subprocessor page states it per provider.

A contractual promise not to train is a narrower guarantee than a promise not to process: the manuscript text still passes through the provider’s inference stack — and, unless the agreement separately addresses it, potentially transient request logging — for the duration of the call, even where the same contract forecloses using that text to update model weights. The two questions are worth asking separately of any vendor.

Concretely: Anthropic receives the whole manuscript on every review. Google’s Gemini API receives the whole manuscript for the literature and journal research lanes. Voyage AI receives your title and abstract only, turned into embeddings for journal and literature matching. Crossref, OpenAlex, Semantic Scholar and ORCID receive a title, a DOI or an author name at a time, for the works you cite and for your own publication record, and never the paper. Six services hold or read your manuscript — the application tier, the database, the object store, Anthropic, Google and Voyage AI; the rest of the list handles payments, email, edge delivery, diagnostics and scholarly lookups.

A vendor list that gives you only company names hides exactly this. “Stripe” and “Anthropic” look alike in a table and are nothing alike to an author, and a procurement assessment that counts subprocessors without separating them is counting the wrong thing. The procurement checklist states the question in the form worth sending to any vendor: which third parties receive customer content, what does each receive, and where does each process it.

The parts that are not in the EU

Error monitoring and product analytics run on United States endpoints.

Neither receives manuscript text, but both receive operational telemetry associated with your account, and an assessment that omitted them would be incomplete. Moving them to EU endpoints is tracked internally rather than done, and this page will say so until it changes.

Two more United States endpoints belong in the same disclosure. Payments run through Stripe in the United States and Ireland, which receives no manuscript content but does hold billing identity. Outbound email runs through Resend in the United States — and so does inbound email to your ingestion address. That second clause is the one that changes behaviour: a manuscript you email to your ingestion address transits a United States mail provider before it lands in Frankfurt object storage, while a manuscript you upload through the application does not. If the transit region is a term of your ethics approval or of the data management commitments in your grant, upload the file rather than emailing it. Cloudflare sits in front of the application on a global edge network and terminates TLS; it carries request traffic rather than storing documents.

Common questions about AI model processing and US-hosted services

Does my manuscript leave the EU during review?

Whether the manuscript leaves the EU depends on which provider is handling that particular review lane. Anthropic runs the reviewer and verification passes and Google’s Gemini API runs the literature and journal research lanes, and PerfectPaper reports each provider’s region on the subprocessor page from live configuration rather than asserting one blanket answer for both.

Where does the AI model that reads my paper actually run?

Anthropic models run PerfectPaper’s reviewer and verification passes, and Google’s Gemini API runs the literature and journal research lanes. The region each runs in is reported on the subprocessor page from the configuration the application is actually running under, because a Vertex europe-west4 deployment and an Amazon Bedrock eu-central-1 route are different pieces of engineering work that land weeks apart.

Will Anthropic or Google train their models on my unpublished paper?

PerfectPaper’s position is that neither provider trains on manuscript content sent for review — a claim that rests on vendor contract terms rather than a technical flag sent with the request. That is a separate question from where the data is processed; see AI that never trains on your research for what the contracts actually say.

Is anything about PerfectPaper hosted in the United States?

Yes. Error monitoring and product analytics run on United States endpoints and receive no manuscript text. Payments run through Stripe in the United States and Ireland, and email — including papers sent to your ingestion address — runs through a United States provider before landing in Frankfurt storage.

Storage residency and processing residency are different questions

Storage residency is where a document sits at rest; processing residency is where the model reads it. PerfectPaper answers the first with a region and a date, and the second with a per-provider value read from live configuration, because they are governed by different mechanisms and change on different schedules.

The distinction has a concrete consequence inside PerfectPaper. An organisation can carry a region constraint, and the resolution order for a new document is organisation constraint first, then the individual’s preference, then the configured default. That setting governs where the document is stored. It does not select which provider region reviews it, because the review lane’s region is deployment configuration rather than a per-document property. Anyone told that a residency toggle “keeps everything in the EU” should ask which of the two questions the toggle answers; for most products, including this one, the answer is storage.

The same split explains why a residency claim can be true and unhelpful at once. A tool can store in the EU while processing elsewhere, and both halves of that sentence can appear on the same marketing page without contradiction. Ask for the two answers separately, in writing, and ask whether the second one is read from configuration or typed by hand.

How a residency claim breaks, and how the break is recorded

A residency claim usually breaks at a fallback rather than at a decision. Some component asks for a region, the region is unavailable or unconfigured, and the work proceeds somewhere else — quietly, successfully, with a 200 response and a happy user.

PerfectPaper treats that moment as an event to record rather than an error to swallow. When the region a request asked for is not the region the work happened in, a residency event is emitted carrying the expected region, the actual region, whether the context was storage or a model call, and a correlator that identifies the document or supporting-document revision involved. Where a storage adapter can refuse the mismatch outright it does, and emits nothing to correlate, because a refusal is not a border crossing. One model adapter — the supporting-document curation lane — reports the region it actually routed to, so the ledger records what that provider did rather than what the default would have implied. The reviewer and literature lanes do not yet report a routed region, so today the ledger’s model-side entries come from that one lane and carry a supporting-document correlator.

Ask any vendor the same question in that shape: not “do you offer EU processing”, but “what happens when the EU endpoint is unavailable, and where is that recorded”. A vendor whose answer is a silent fallback cannot tell you afterwards which documents crossed a border, which means the answer to your next question — the one your DPO will ask after an incident — is unavailable by construction.

What GDPR actually asks you to record

A data protection officer assessing PerfectPaper needs four things for a record of processing, and each maps to a specific article of Regulation (EU) 2016/679 rather than to a general principle.

The recipients and the transfers. Article 30(1) requires records naming the categories of recipients to whom personal data have been or will be disclosed, and, where applicable, transfers to a third country including the identification of that country. The subprocessor page is written to be copied into that record: one row per company, with what it receives and where it runs.

The instruction constraint. Article 28(3)(a) requires that a processor “processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation”. Transfers are named inside the instruction clause, which is why “we host in the EU” is not by itself a Chapter V answer.

The security measures. Article 32(1) lists, as a first example of appropriate technical measures, “the pseudonymisation and encryption of personal data”. The answer PerfectPaper gives is AES-256 at rest with provider-managed keys, TLS in transit, and storage keys that carry no filename, title or account identifier.

The transfer mechanism. Article 44 states that a transfer “shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers”. Where no adequacy decision applies, Article 46(2)(c) makes standard data protection clauses adopted by the Commission the usual instrument. The European Commission adopted its adequacy decision for the EU–U.S. Data Privacy Framework on 10 July 2023, which matters only for United States recipients that are certified under it — a fact to check per recipient, not per vendor.

Satisfying Article 30(1) by listing categories of recipients does not by itself satisfy Article 28(3)(a): the latter requires the transfer to be named in a documented instruction from the controller, so a research office’s own data processing agreement still needs its own transfer clause even where the subprocessor page already discloses the recipient and its region.

PerfectPaper’s published position is deliberately narrow here: no particular transfer mechanism is represented as active until it is confirmed for the production processing path, and the mechanism that applies to your organisation belongs in a signed agreement rather than in a web page. That is a weaker sentence than most vendor pages offer and a more accurate one.

The EDPB’s Recommendations 01/2020, adopted in final form on 18 June 2021, set out the six-step roadmap institutions are expected to follow: know your transfers, identify the transfer tools you rely on, assess whether the Article 46 tool is effective in light of the third country’s law and practice, adopt supplementary measures, take the procedural steps, and re-evaluate at appropriate intervals. Step one is the step this page exists to make possible. You cannot assess a transfer you cannot enumerate, and enumeration is the thing a vendor either gives you or does not.

Where the data sits is not the same question as whose law reaches it

Storage location and legal reach are two different questions, and a residency page that answers only the first is answering the easier one. Placing the stored copy in Frankfurt puts it under the GDPR and the Bundesdatenschutzgesetz and outside the reach of a disclosure order aimed at a United States data centre.

Frankfurt storage does not, by itself, dispose of the question your institution’s counsel will ask next. Under 18 U.S.C. § 2713, added by the CLOUD Act on 23 March 2018, a United States provider of electronic communication or remote computing service “shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.” The Court of Justice made the parallel point from the other direction in Case C-311/18 (Schrems II, judgment of 16 July 2020): a transfer instrument is only as good as the law and practice of the destination.

The distinction has a second layer worth naming: CLOUD Act reach attaches to the provider’s nationality, not to the document’s location, so a US-domiciled processor is reachable for whatever it holds regardless of which region its servers sit in, while a German-domiciled one is not reachable under that statute even for a copy it happens to hold in the United States. PerfectPaper’s Frankfurt-hosted application and database sit outside that exposure for the reason above; Stripe’s billing identity and Resend’s mail transit remain within it, because both are US companies, not because of where their servers happen to be.

The practical reading for a research office is that provider nationality, encryption key custody and enumerated recipients all belong in the assessment alongside the region. PerfectPaper publishes all four inputs and claims none of them settles the question on its own.

Frequently asked questions about legal compliance

Does the US CLOUD Act reach my manuscript even though it’s stored in Frankfurt?

The CLOUD Act binds the provider, not the server’s location: 18 U.S.C. § 2713 requires a US electronic-communication-service provider to comply with a lawful US disclosure order regardless of whether the data sits inside or outside the United States. Frankfurt storage puts the file under GDPR; it does not, by itself, remove US legal reach from a US-domiciled provider.

Can I just tell my ethics committee my data never leaves the EU?

Only for the storage half of the claim. PerfectPaper stores manuscripts in Frankfurt, but the review models that read the text run in whichever region each provider reports on the subprocessor page — so “my data never leaves the EU” is true of the stored file and not automatically true of every processing step. State both halves, not one.

Does an EU region setting keep the whole review inside the EU?

No. An organisation’s region constraint governs where the document is stored, and it resolves before the individual’s own preference and the configured default — but it does not select which provider region reviews the document, because the review lane’s region is deployment configuration rather than a property of the document itself.

What a research office writes back

A research office assessing PerfectPaper rarely rejects a tool outright — instead it sends four or five specific sentences back, and this page exists to answer each one in advance.

“Your page says EU hosting; confirm separately where inference runs.” “Name the subprocessors individually and state what each receives, not the categories.” “Does the residency setting apply to data already uploaded, or only to new uploads?” “Are the encryption keys provider-managed or customer-managed?” “What is the legal basis for any transfer outside the EEA, and is it in the signed agreement?” “Who at the vendor can read manuscript content, and under what trigger?” “If the EU endpoint is unavailable, what happens to the request?”

The third of those is the one that most often changes an approval decision, because residency changes usually apply going forward and leave an older estate exactly where it was. PerfectPaper’s answer is a date — 27 August 2026 — rather than a reassurance.

When EU-only processing is a hard requirement

PerfectPaper does not offer a user-facing switch that guarantees EU-only inference today, and saying so is more useful than describing a roadmap. If your ethics approval, the data management commitments in your grant or your institution’s policy requires EU-only processing of the document text, there are four honest options.

Check the per-provider region on the subprocessor page before uploading, since that value reflects the running deployment on the day you read it. De-identify before upload: manuscripts carrying direct or indirect participant identifiers should be reduced to the reporting-level text your journal will publish anyway, which is the same discipline that ethics and data-sharing statements and data availability and accession reporting already require of you. That reporting-level rewrite is pseudonymisation, not anonymisation, and the difference matters under the Regulation: GDPR Recital 26 treats pseudonymised text as still personal data where it can be reassociated with a person by means reasonably likely to be used, so removing names from a case description does not, by itself, take the manuscript outside GDPR’s scope — only text that cannot reasonably be re-identified qualifies as anonymous. Upload rather than email, so the file does not transit a United States mail provider. And raise the requirement through the security contact before you upload, because an organisation-level constraint is a configuration question rather than a support question.

Two categories deserve a firmer answer than “de-identify”. Individual-level genomic data held under controlled access, and identifiable clinical trial records, should not be pasted into any third-party tool merely because the manuscript around them is being reviewed — see genomics review and clinical trial review for what belongs in the manuscript and what belongs in a repository under a data access agreement.

There is also a case where the answer is no. If you are refereeing someone else’s manuscript rather than your own, the confidentiality obligation runs to the journal and not to you, and uploading that manuscript anywhere is a decision for the editor rather than for you — reviewers using AI on manuscripts sets out what the major publishers actually say, and journal AI policies for authors and referees separates the two rulebooks.

How to verify any of this

The subprocessor page is the authoritative list and reports live configuration rather than a static claim.

The mechanism that makes it authoritative is worth naming, because “our page is accurate” is a promise and this is a control. The list is code covered by tests, and those 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 scope is what is configured in production rather than what the repository can talk to: PerfectPaper’s source carries connectors for DeepSeek, Kimi, Qwen, Ollama and SerpAPI, none of which holds a production credential or receives anything, and none of which is listed. A subprocessor page that inventories dormant code makes the estate look larger than it is, which is its own kind of false statement.

For an institutional review that needs more than a public page, the security contact published in PerfectPaper’s security.txt is the right route, and questions from research offices about data handling are answered directly rather than through a sales process. The procurement checklist sets out what else is worth asking, and secure AI review for unpublished research covers what PerfectPaper does not claim.

Residency is one of three questions about an unpublished manuscript, and the other two have their own pages: whether the content is used to train a model, answered in AI that never trains on your research, and what changes when the tool is a general-purpose chat product rather than a dedicated review tool, answered in is it safe to upload a manuscript to ChatGPT.

Related

Secure AI review for unpublished research · AI that never trains on your research · Procurement checklist · Uploading to ChatGPT · Peer review software

Review my manuscript