Evaluators are using AI to assess your application. Maybe. Would your proposal survive?

Evaluators are using AI to assess your application.

Maybe.

But that is not the real question.

The real question is:

This is where many applicants are underprepared.

AI does not know what you meant.

AI does not know how strong your team is beyond what the proposal proves.

AI does not infer missing evidence.

AI does not connect vague arguments for you.

AI does not reward effort.

It reads what is there.

In practice, that is close to how an overloaded evaluator may read too.

Coldly.

Quickly.

With limited patience.

Looking for evidence, logic, consistency and risk.

That is why applicants should stop asking only whether AI is involved in proposal evaluation.

They should ask something more useful:

Because many EU funding proposals do not fail because the project is weak.

They fail because the proposal requires too much interpretation, goodwill, reconstruction and trust.

At around 2.6% success rates in highly competitive programmes such as the EIC Pathfinder Open, that is dangerous.

The real issue is not whether AI is used

The debate around AI in EU funding proposals often becomes too simplistic.

Some people act as if AI is automatically unprofessional.

Others act as if AI can magically solve proposal quality.

Both views are wrong.

Using AI to support proposal writing, internal review, consistency checking, claim testing or evaluator-style questioning is not necessarily a problem.

The problem starts when responsibility is delegated.

AI should not invent evidence.

AI should not decide strategy.

AI should not replace expert judgement.

AI should not become the author of the credibility of the proposal.

But used properly, AI can help teams detect issues that are easy to miss when they are too close to the project.

The relevant question is not:

The relevant question is:

If the answer is yes, good.

If the answer is no, the team has not accelerated quality.

It has accelerated weakness.

This distinction matters because the European research and innovation ecosystem is already discussing responsible AI use in research, funding and assessment processes. The European Commission and the European Research Area Forum have published living guidelines on the responsible use of generative AI in research, including strong caution around sensitive activities such as peer review and the evaluation of research proposals.

That caution is important.

But for applicants, the practical implication is even more immediate.

Whether an official evaluator uses AI or not, your proposal will increasingly be written, reviewed, compared, summarised, challenged and stress-tested in an AI-assisted environment.

The proposal therefore needs to survive a colder standard of reading.

Not a more unfair one.

A more literal one.

What an AI-assisted cold reading exposes

An AI-assisted review is useful because it is often less forgiving than a friendly internal reader.

That does not mean AI is always right.

It is not.

It can misunderstand technical details.

It can miss strategic nuance.

It can overemphasise wording patterns.

It can penalise complexity when the complexity is justified.

But it is very good at exposing certain proposal weaknesses.

Especially these:

• Unsupported claims
• Inconsistent terminology
• Missing baselines
• Unclear logic chains
• Vague impact pathways
• Weak links between work packages and outcomes
• Repeated assertions without evidence
• Unexplained assumptions
• Risks that do not match the real uncertainty
• Partner roles that sound generic
• Milestones that do not support decision-making

These are not superficial writing problems.

They are evaluation problems.

They influence whether the reader can trust the proposal.

We have discussed a similar pattern before in Most EU proposals do not fail because of evaluators. In many cases, proposals lose strength because small avoidable weaknesses accumulate long before submission. The evaluator only makes those weaknesses visible.

AI-assisted review can do something similar.

It can expose the hidden cost of ambiguity before the Evaluation Summary Report does.

Rule 1. Make the logic explicit

Do not assume the evaluator will connect the problem, solution, methodology, work plan, consortium and impact.

Write the connections.

A common mistake in Horizon Europe, EIC Accelerator and EIC Pathfinder proposals is that the team understands the project so deeply that it stops explaining the reasoning.

The project logic may be obvious to the authors.

It may be obvious to the coordinator.

It may even be obvious to the consortium.

But that does not mean it is obvious to the evaluator.

A proposal should not force the reader to reconstruct the intervention logic.

For example, this is weak:

This is stronger:

The difference is not only style.

The second version gives the evaluator a chain:

That is what a cold reading needs.

Rule 2. Use one name for one thing

Inconsistent terminology creates evaluation risk.

Many proposals describe the same asset as:

• a platform
• a tool
• a framework
• an engine
• a module
• a solution
• an AI system
• a decision-support layer

The team may know these terms refer to the same core technology.

The evaluator may not.

AI may not.

And even when the reader understands, inconsistency creates friction.

Friction reduces trust.

Trust influences scoring.

This is especially important in complex technical proposals where the evaluator needs to understand architecture, TRL progression, work package responsibilities and expected outputs.

If the proposal uses five names for the same asset, the reader may start wondering whether the project contains one system, several components, or a loosely defined concept.

A simple rule helps:

Define the core terms early.

Use them consistently.

If a term changes because the scope changes, explain the relationship.

Do not make the evaluator guess.

Rule 3. Turn claims into evidence

“Innovative” is not evidence.

“Scalable” is not evidence.

“Strong market need” is not evidence.

“High impact” is not evidence.

“World-class consortium” is not evidence.

Every serious claim needs proof, context or a measurable basis.

This is where many proposals become vulnerable to both human and AI-assisted review.

They contain claims that sound strong but remain difficult to evaluate.

For example:

That may be true.

But the evaluator still needs to know:

• Which healthcare segment?
• Which buyer or user group?
• Which problem creates the willingness to adopt?
• Which current alternatives exist?
• What evidence supports the demand?
• What regulatory or procurement barriers remain?
• What route to market is realistic?
• What assumptions drive the adoption forecast?

Without that evidence chain, the sentence remains promotional.

Not evaluable.

The same applies to technical claims.

For example:

Superior how?

Compared with which benchmark?

Under which operating conditions?

Measured by which KPI?

Validated through which dataset, experiment or pilot?

This is why quantified credibility is essential. We explored this in What cannot be measured does not exist: ambition only becomes assessable when it is connected to measurable KPIs, thresholds, baselines and operating conditions.

A cold reading does not reward impressive claims.

It rewards claims that can be verified.

Rule 4. Make key information easy to extract

A proposal should be readable as a narrative.

But it should also be extractable as an evaluation object.

That means the evaluator should be able to quickly identify:

• The objective
• The novelty
• The state of the art
• The main technical risks
• The TRL logic
• The work package structure
• The consortium rationale
• The expected outputs
• The impact pathway
• The exploitation route
• The evidence base
• The assumptions behind the main claims

If these elements are buried, scattered or inconsistently described, the proposal becomes harder to defend.

This matters because evaluators do not read proposals under ideal conditions.

They are often reading several applications.

They need to compare projects.

They need to justify scores.

They need to translate their reading into evaluation comments.

A proposal that hides the core logic inside long paragraphs creates unnecessary work for the evaluator.

And when success rates are very low, unnecessary work becomes a competitive disadvantage.

A practical test is this:

If not, the proposal may be too difficult to evaluate fairly.

Rule 5. Remove ambiguity before adding detail

More text does not always create more clarity.

Sometimes it creates more places to find contradictions.

This is one of the most common mistakes in proposal improvement.

A team receives feedback that something is unclear.

The natural reaction is to add paragraphs.

But if the underlying logic remains ambiguous, the additional text does not fix the problem.

It may make it worse.

For example, a vague impact pathway does not become credible because it is longer.

A weak risk mitigation plan does not become stronger because it has more bullet points.

A poorly justified partner role does not become convincing because the partner description is longer.

The first task is not expansion.

The first task is clarification.

Before adding more text, ask:

• What exactly is unclear?
• Which claim lacks evidence?
• Which assumption is hidden?
• Which link in the logic chain is missing?
• Which term is being used inconsistently?
• Which section contradicts another section?
• Which evaluator question remains unanswered?

Only then should the proposal be expanded.

Good proposal editing is not about making text longer.

It is about making meaning harder to misunderstand.

Rule 6. Do not delegate judgement to AI

Using AI is not unprofessional.

Using AI without accountability is.

AI can help you draft, review, challenge and stress-test.

It can help detect repeated claims, missing evidence, inconsistencies and unclear logic.

It can help compare sections.

It can help test whether a proposal is understandable to a non-insider.

It can help identify areas where the proposal sounds generic.

But AI should not decide the strategy.

It should not invent evidence.

It should not replace technical expertise.

It should not decide whether a market assumption is credible.

It should not judge regulatory feasibility without expert review.

It should not rewrite a proposal into fluent but unsupported language.

The final responsibility remains human.

This applies to applicants.

It applies to consultants.

It applies to internal reviewers.

And it applies to any evaluation context where AI may be used as support.

AI can assist judgement.

It cannot own judgement.

How to write for a fair AI-assisted reading

The goal is not to game AI.

The goal is to make the proposal evaluable.

A fair reading requires clarity, evidence and traceability.

The following practices help.

1. State the main evaluation argument early

Do not wait until page 15 to make the project logic clear.

At the beginning of the proposal, the evaluator should already understand:

• What problem is being addressed
• Why it matters now
• Why current solutions are insufficient
• What the project will do
• Why the approach is novel
• Why the consortium can deliver it
• What measurable outcomes are expected

A proposal should create orientation before adding complexity.

2. Use evidence close to the claim

Do not place evidence far away from the statement it supports.

If a section claims that the market need is urgent, provide the supporting data nearby.

If a technical objective depends on preliminary results, show the result near the objective.

If a risk is manageable because of prior experience, connect the experience directly to the mitigation.

A cold reading penalises distance between claim and proof.

3. Define acronyms and technical concepts clearly

AI tools can process acronyms, but they can also misinterpret them when definitions are inconsistent.

Human evaluators face the same problem.

Define acronyms once.

Avoid unnecessary acronym density.

Use technical language when it improves precision.

Do not use technical language to hide unclear logic.

4. Make assumptions visible

Strong proposals do not pretend there is no uncertainty.

They show that uncertainty is understood and managed.

For every important assumption, explain:

• What is assumed
• Why it is reasonable
• What evidence supports it
• What happens if it is wrong
• How the project will test or reduce the uncertainty

This is especially important for impact, market adoption, clinical validation, regulatory pathways, manufacturing scale-up, user engagement and data availability.

5. Make numbers traceable

A number without derivation can be more damaging than no number at all.

If the proposal includes a KPI, market forecast, cost reduction, performance improvement, adoption estimate or emission reduction, explain:

• Baseline
• Calculation method
• Data source
• Scope
• Assumptions
• Validation plan
• Boundary conditions

This is not just good writing.

It is evaluation protection.

What not to do

A proposal written for a cold reading should avoid several common traps.

Do not rely on implied expertise

The evaluator cannot evaluate what is not written.

If the consortium has relevant experience, show it.

If the team has access to key infrastructure, explain it.

If the company has customer validation, summarise it.

If a partner is essential, justify the role.

Do not expect the evaluator to know why the team is credible.

Do not confuse polish with quality

AI can make a weak proposal sound fluent.

That is useful only if the underlying logic is strong.

Fluent writing can hide weak assumptions, missing evidence and inconsistent reasoning.

A proposal can sound professional and still be fragile.

Do not use buzzwords as substitutes for proof

Words such as transformative, disruptive, scalable, unique, robust and breakthrough can be useful when justified.

But they create a burden of proof.

The stronger the adjective, the stronger the evidence should be.

Do not bury the weakness

If there is a major technical, regulatory, clinical, commercial or operational risk, do not hide it.

Evaluators prefer credible risk management to unrealistic confidence.

A proposal that pretends everything is solved can look less mature than a proposal that clearly explains what remains uncertain and how the project will address it.

Do not write only for insiders

Internal clarity is not the same as evaluator clarity.

A proposal team may understand all the background.

The evaluator does not have access to internal meetings, technical debates, investor decks, customer calls, lab notes or strategy discussions.

For evaluation purposes, if the evidence is not visible in the proposal, it may as well not exist.

A practical cold reading checklist

Before submission, ask whether the proposal can survive these questions.

Logic

• Is the problem clearly connected to the solution?
• Is the methodology clearly connected to the objectives?
• Are the work packages clearly connected to the expected results?
• Is the impact pathway clearly connected to the project outputs?
• Is the consortium clearly connected to the delivery needs?

Evidence

• Are key claims supported?
• Are numbers traceable?
• Are baselines clear?
• Are assumptions visible?
• Are validation methods credible?

Consistency

• Are core terms used consistently?
• Do objectives, tasks, deliverables, milestones and impacts align?
• Do risks match the real uncertainties?
• Does the budget support the ambition?
• Do partner roles match expertise and responsibilities?

Evaluability

• Can the evaluator quickly identify the novelty?
• Can the evaluator understand the TRL progression?
• Can the evaluator see why the project is feasible?
• Can the evaluator explain the impact logic?
• Can the evaluator justify a high score from the evidence on the page?

If the answer is no, the proposal is not yet ready.

Not because the project is necessarily weak.

Because the case is not yet evaluator-proof.

Why this matters for Horizon Europe, EIC Accelerator and EIC Pathfinder proposals

The more competitive the call, the less room there is for ambiguity.

In programmes such as Horizon Europe, the EIC Accelerator and the EIC Pathfinder, applicants often present complex technologies, uncertain markets, high-risk research plans, ambitious exploitation routes and multidisciplinary consortia.

That complexity is not a problem.

But complexity must be controlled.

A complex project needs an even clearer proposal.

If the evaluator cannot follow the logic, the project may look less mature than it is.

If the evidence is scattered, the impact may look overstated.

If the work plan is dense but not decision-oriented, implementation may look fragile.

If the consortium is impressive but roles are not justified, excellence may not convert into credibility.

If the proposal relies on expert generosity, it becomes vulnerable.

And at very low success rates, vulnerability is expensive.

Where Ruthless Evaluator fits

This is why we built Ruthless Evaluator.

Not to generate polished proposal language.

Not to replace experts.

Not to give applicants comforting feedback.

But to simulate a cold, demanding, evaluator-style reading before submission.

Ruthless Evaluator is designed to help applicants, consultants, universities, research centres, startups and innovation teams detect problems such as:

• Unsupported claims
• Inconsistencies
• Vague logic
• Weak assumptions
• Unclear impact pathways
• Implementation gaps
• Misalignment with the call logic
• Missing evidence
• Weak baselines
• Unclear partner roles
• Risks that are too generic
• Claims that sound stronger than they are

The goal is not to make proposals sound better.

The goal is to make them harder to misread.

That difference matters.

Because whether your proposal is read by a human, AI, or both, one thing remains true:

You get funded for what the proposal makes undeniable.

Better to test the cold reading before submission

AI-assisted proposal review should not be feared.

It should not be blindly trusted either.

It should be treated as one more way to test whether the proposal is coherent, evidence-based and evaluable.

The strongest proposals are not the ones that depend on the reader being generous.

They are the ones that remain clear under pressure.

Clear when read quickly.

Clear when summarised.

Clear when compared.

Clear when challenged.

Clear when translated into evaluation comments.

Before submitting an EU funding proposal, ask:

• What could be misunderstood?
• What still depends on goodwill?
• Which claims lack evidence?
• Which numbers lack derivation?
• Which assumptions are hidden?
• Which sections do not fully align?
• Which evaluator doubts remain unanswered?

If the proposal cannot answer these questions before submission, the Evaluation Summary Report may answer them later.

And that is much harder to fix.

Better to meet Ruthless Evaluator before submission than inside the Evaluation Summary Report.

app.ruthlessevaluator.ai