European Public Funding News
Published Sep 7, 2026 · 11 min read

Koncentriq and OpenAI sign agreement enabling Zero Data Retention for Ruthless Evaluator

Koncentriq and OpenAI have signed an agreement enabling Zero Data Retention for Ruthless Evaluator. Here is what that changes, why it matters for confidential proposals, and what you should ask any AI-powered SaaS before trusting it with sensitive information.

Koncentriq and OpenAI sign agreement enabling Zero Data Retention for Ruthless Evaluator - EU funding proposal evaluation context

This is an important milestone for Ruthless Evaluator.

Koncentriq and OpenAI have signed an agreement that enables Zero Data Retention for the OpenAI API project used by Ruthless Evaluator, and ZDR is now active in our production configuration.

That sentence sounds technical. The idea behind it is not.

If you use an AI-powered SaaS to analyse a confidential document, there is a very simple question worth asking: what happens to my information after the AI has finished processing it?

Most people ask a different question first: “Is my data used to train the AI?” That is a good question, but it is only half of the story. Training and retention are not the same thing.

For organisations working with unpublished research, intellectual property, commercial plans, financial information or funding proposals that may not even have been submitted yet, that distinction matters a lot.

The easiest way to understand Zero Data Retention

Imagine that you hand a confidential proposal to an expert for review.

There are two promises that expert could make:

“I will not use your proposal to teach myself how to review other proposals.”

and:

“I will read what I need to read, give you the review, and I will not keep a copy afterwards.”

Those are not the same promise.

The first is similar to a no-training commitment. Your content is not being used to improve the underlying model.

The second is closer to what Zero Data Retention, usually shortened to ZDR, is designed to achieve for eligible API processing: the content is processed to produce the requested result, but it is not kept afterwards as customer content under the covered retention path.

This distinction is easy to miss because the phrases sound similar. “We do not train on your data” sounds reassuring, and it is important. But it does not automatically answer whether the API provider may retain prompts and outputs for operational or abuse-monitoring purposes.

OpenAI makes this distinction explicitly in its data controls documentation. Data sent to the OpenAI API is not used to train or improve OpenAI models by default unless the customer explicitly opts in. Separately, OpenAI explains that abuse-monitoring logs may normally contain customer content and may be retained for up to 30 days, subject to its documented conditions and exceptions.

That is why ZDR matters.

“Not used for training” is not the end of the conversation

There is a useful habit we would like more people to develop when they evaluate an AI-powered SaaS.

Do not stop at:

“Do you train on my data?”

Ask the next question too:

“Can the underlying AI provider retain my content after the request?”

This is particularly important because many SaaS products do not run their own foundation model. They call an external LLM provider through an API. The SaaS may have excellent privacy controls itself, but the complete data flow also depends on what happens at the model-provider layer.

That does not make API-based AI unsafe. It simply means you should understand the full chain rather than only the application you can see on screen.

We have written before about the difference between a general-purpose AI assistant and a purpose-built proposal evaluation platform in Ruthless Evaluator vs ChatGPT. The same principle applies to privacy. The visible interface is only one part of the system. What matters is the architecture behind it, the contractual commitments around it and the controls actually enabled in production.

What OpenAI normally does with API data

OpenAI states that API data is not used to train its models by default. That is the baseline and it is already an important privacy safeguard.

Retention is a separate control.

According to OpenAI's current API data controls documentation, abuse-monitoring logs are generated by default for API feature usage and may contain customer content such as prompts and responses. Those logs are normally retained for up to 30 days unless a longer period is required by law or is reasonably necessary to protect OpenAI's services or third parties from harm.

OpenAI also explains that eligible customers can be approved for Modified Abuse Monitoring or Zero Data Retention, subject to additional requirements and documented limitations. Approved customers can configure those controls at organisation or project level.

In other words, ZDR is not simply a marketing label that any API user can turn on by default. It is a specific data-retention configuration that requires approval and activation.

That is the change Koncentriq has now secured for Ruthless Evaluator.

What the Koncentriq and OpenAI agreement changes for Ruthless Evaluator

Koncentriq and OpenAI have signed a written agreement covering Modified Retention for the OpenAI organisation used by Ruthless Evaluator. Following approval and implementation by OpenAI, Zero Data Retention has been activated for the API project used by Ruthless Evaluator in production.

For covered requests to ZDR-eligible endpoints, OpenAI documents that Zero Data Retention excludes customer content from abuse-monitoring logs. It also states that ZDR-eligible endpoints do not retain customer content for application state, subject to the limitations described in its documentation.

Ruthless Evaluator currently uses an API route that OpenAI lists as ZDR-eligible. Our request configuration is also designed so that customer content is not intentionally stored as API application state.

What does this mean in normal language?

When Ruthless needs the model to analyse relevant proposal text, OpenAI systems still have to process that text to generate the requested evaluation. There is no way to use an LLM without the model processing the input.

But processing is not the same as retention.

With ZDR active for the covered processing, the proposal content sent through that path is not meant to remain in OpenAI's abuse-monitoring logs or application state after the request in the way it may under standard retention settings. OpenAI's documented limitations and safety exceptions still apply, which is why we avoid exaggerated claims such as “OpenAI never sees the data”.

The accurate statement is stronger than that slogan anyway: the content is processed to provide the service, while Zero Data Retention is active for the covered Ruthless Evaluator API processing.

Why this matters more for a funding proposal than for many ordinary documents

A proposal is not just a Word file with some nicely formatted sections.

It can contain material that is commercially or scientifically sensitive long before it becomes public, including:

  • unpublished research results and hypotheses;
  • patentable technical information and know-how;
  • exploitation and intellectual-property strategies;
  • consortium composition and partner responsibilities;
  • customer, pilot and investor discussions;
  • financial projections and funding needs;
  • regulatory plans and clinical strategies;
  • technical risks, weaknesses and unresolved evidence gaps.

Some of that information may later appear in a public project summary. Much of it will not.

And a proposal under preparation is often at its most sensitive precisely when a team wants external feedback. That creates an awkward tension: the document needs independent scrutiny, but the team may be reluctant to upload it to a tool unless it understands what happens to the content afterwards.

That concern is entirely reasonable.

For Ruthless Evaluator, confidentiality cannot be a footnote because the product exists to perform a deep review of exactly this kind of material. If we ask users to trust the platform with an unpublished proposal, we should be prepared to explain the data flow in plain language.

ZDR is one layer, not the whole privacy story

Zero Data Retention is a major improvement, but it should not be presented as if one setting magically solves every privacy question.

A secure AI SaaS still has to think about what happens before, during and after the LLM request.

In Ruthless Evaluator, the original proposal file is handled separately from the OpenAI API request. The uploaded PDF or DOCX is parsed in the Ruthless processing environment. The original PDF or DOCX is not sent to OpenAI through the Files API, File Search or Vector Stores. Only the text required for the requested processing is provided to the model layer.

The original uploaded proposal is treated as transient input and is automatically removed after processing completes, is cancelled or fails. Structured evaluation outputs are stored in the authenticated Ruthless Evaluator account so that the user can access the evaluation, history and related product functionality.

We also deliberately separate operational security information from proposal content. Monitoring and security logs are designed to contain operational metadata rather than the proposal or evaluation report itself.

The broader approach is described on our Security page and Privacy Policy.

This matters because good privacy architecture is rarely one spectacular control. It is usually a sequence of less glamorous decisions that all point in the same direction: minimise what is collected, minimise what is transmitted, minimise what is retained, restrict who can access it and make the remaining data flow explicit.

What ZDR does not mean

There is a temptation in privacy marketing to take a good technical control and turn it into an impossible absolute.

We do not want to do that.

ZDR does not mean that OpenAI's systems never process proposal content. They must process the relevant text to generate an output.

It does not mean that every possible OpenAI endpoint or feature behaves identically. OpenAI publishes an endpoint-by-endpoint table describing ZDR eligibility and application-state behaviour, and it documents specific limitations, including around some file and image inputs and safety processes.

It does not remove Koncentriq's responsibility to design Ruthless Evaluator carefully. We still have to control which API project receives production traffic, avoid unnecessary provider-side state, secure our own infrastructure and apply appropriate moderation and security controls.

And it does not mean users should stop asking questions.

Quite the opposite. The whole point of explaining ZDR publicly is to make those questions easier to ask.

Seven questions to ask any AI-powered SaaS

You do not need to be a security engineer to have a useful privacy conversation with an AI vendor. If a SaaS asks you to upload confidential material, these seven questions reveal a surprising amount:

  1. Which AI or LLM provider processes my content?
    “We use AI” is not enough. You should know which external providers are involved in the data flow.
  2. Is my content used to train or improve models?
    Ask about both the SaaS provider and the underlying LLM provider.
  3. Can the LLM provider retain my prompts, documents or outputs after processing?
    This is the question that no-training statements do not answer.
  4. Is Zero Data Retention actually enabled, or merely available in theory?
    There is a big difference between “our provider offers ZDR” and “the project processing your data is configured for ZDR”.
  5. Are original files sent to the LLM provider?
    File uploads may follow different retention rules from plain text requests. Ask whether the SaaS extracts only what it needs or forwards the entire document.
  6. What does the SaaS itself retain?
    ZDR at the model provider does not tell you what the application stores in its own database, backups, analytics or logs.
  7. Can the provider put these commitments in writing?
    A privacy page is useful. A DPA, contract or other written commitment is better when confidential or personal data is involved.

You do not need every answer to be “nothing is ever stored anywhere”. Many useful SaaS products need to store account data and user-requested outputs to work properly. The objective is not zero data everywhere. The objective is clear, proportionate and intentional data handling.

A few red flags worth noticing

Some answers should make you ask a second question.

For example, if a vendor says only “we are GDPR compliant” without explaining its subprocessors, that tells you very little about LLM retention.

If it says “we never train on your data”, ask how long the underlying model provider can retain the content.

If it says “our AI provider offers ZDR”, ask whether ZDR is actually enabled for the project handling your requests.

If it says “files are deleted after processing”, ask whether the original file was also sent to the model provider before that deletion happened.

And if a privacy answer requires twelve paragraphs of legal language before you can understand whether your confidential document is kept, ask for the plain-English version.

Trust should not depend on the customer being able to reverse-engineer a SaaS architecture.

Why we are making a big deal about this

Ruthless Evaluator is designed to be demanding with proposals. We think it is fair for users to be demanding with us too.

The agreement with OpenAI and the activation of Zero Data Retention are important because they remove a retention layer that can matter to universities, research organisations, innovative companies and proposal teams handling highly confidential material.

It is also an important product milestone for a broader reason: AI SaaS is becoming normal faster than good questions about AI data handling are becoming normal.

A growing number of tools can summarise, score, review, rewrite, classify or analyse documents. The user experience can be excellent while the underlying privacy model remains almost invisible.

We would like that to change.

If you are using AI to review an EU funding proposal, there are already good reasons to think carefully about the difference between generic AI assistance and evaluator-style analysis. We explored that in our article on whether an EU proposal would survive an AI-assisted cold reading. Privacy deserves the same level of attention.

The quality of an AI answer matters. So does what happens to the information used to produce it.

The standard we think users should expect

When confidential information is involved, “we do not use your data for training” should not be the end of the conversation.

Ask what is sent to the model provider. Ask whether the original file is transmitted. Ask what is retained. Ask for how long. Ask whether ZDR is genuinely active for the processing path being used. Ask what the SaaS itself stores. And ask whether the vendor is prepared to document those answers.

For Ruthless Evaluator, we can now give a clearer answer than before.

Koncentriq and OpenAI have signed an agreement enabling Zero Data Retention for Ruthless Evaluator, and ZDR is active for the OpenAI API project used in production. Combined with our existing approach to transient proposal files, text-only model processing, account isolation and data minimisation, this gives users a stronger confidentiality architecture for proposal evaluation.

If you want to see how the platform works in practice, our step-by-step Ruthless Evaluator guide explains the evaluation workflow from upload to structured feedback.

And if you are evaluating any other AI-powered SaaS, keep one question from this article:

After the AI has finished processing my confidential information, what exactly is still kept?

That question is simple enough for anyone to ask.

It is also one that every serious AI SaaS provider should be ready to answer.

Next step

Run an evaluator grade review on the draft

Upload a version, select programme context, and get structured feedback you can act on.

Cookies

We use essential cookies to make the site work. Optional cookies, such as analytics, are disabled by default. You can accept, reject, or configure your preferences.

See: Privacy Policy