Grant & research proposal screening and reviewer assignment (funder side)

Research councils, foundations and ministries receive thousands of proposals per call and have to check each against the call rules, then find qualified, conflict-free reviewers. AI reads the long narrative texts, checks eligibility and completeness, spots duplicates and text reuse, can flag immature proposals for a human decision, and proposes reviewers by topic fit. Humans make every funding decision; the system keeps an audit trail and shows why each match or flag arose.

Problem & value

• Today: programme officers manually check page limits, mandatory sections, applicant eligibility and budget rules, then assemble panels from personal networks and keyword searches. Both steps are slow and uneven, and panel composition is a known source of bias (a case study of the Norwegian AI Center call questions disciplinary alignment of panels [4]).
• AI value: consistent first-pass checks, less officer time on clearly ineligible submissions, wider and better-documented reviewer pools, and early detection of overlapping or reused text.
• Documented deployment: the "la Caixa" Foundation has used a content-eligibility model since 2023 in its biomedical call to detect immature proposals before peer review; the model only recommends exclusion, human overseers check each case, and redress is available to applicants [1][2]. In the 2023 call the model flagged 98 of 493 proposals; eligibility reviewers confirmed 63 exclusions and rescued 35 [1]. Treat figures from single funders as indicative only.
• Reviewer matching: some funders are reported to use algorithmic support for assigning reviewers; check each funder's current documentation before citing specifics.

Variants

• Eligibility and completeness check (rule-driven): call rules turned into a checklist an LLM verifies with quotes from the proposal.
• Maturity or quality pre-screening: classifier trained on past decisions; highest-risk variant (see regulation).
• Duplicate, overlap and plagiarism screening: similarity against earlier submissions and published work; links to ANOM-029.
• Reviewer assignment and conflict-of-interest (COI) checks: embedding-based topic match plus co-authorship and affiliation graph.
• Sectors: public research councils, private foundations, ministries, development banks, EU-programme project officers, university internal seed-funding.
• Not covered: the applicant side (LANG-006, KNOW-017) and tender analysis by bidders (DOC-015).

How it works

1. submission (PDF + form + CV + budget)
2. parsing (OCR/layout, section detection, language detection)
3. rule checks (page/word limits, mandatory sections, applicant eligibility, budget caps)
4. LLM checklist against call text, each verdict with quoted evidence
5. similarity & reuse screening (internal archive, published literature)
6. [optional] maturity flag from a classifier trained on past outcomes
7. proposal embedding + reviewer-profile embedding
8. ranked candidates
9. rerank
10. COI screen (co-authorship, shared institution, supervision, funder rules)
11. officer review screen: flags, evidence, match explanation, override
12. human decision, audit log, applicant notification and redress channel

• Topic matching: document embeddings of proposals and of reviewers' publications (scientific-document models such as SPECTER2 or general multilingual embedding models) retrieve candidates, a cross-encoder reranker orders them, and an LLM writes a short justification. Match scores are an aid, not a decision.
• COI detection: structured data (ORCID, Crossref/OpenAlex co-authorship, institution IDs) beats LLM guesswork; the LLM only explains.
• Human-in-the-loop: officers confirm every ineligibility finding before an applicant is rejected; any "weak proposal" flag goes to a trained human who decides; panel chairs approve reviewer assignments.

Data preparation

Needed are the call texts and rules, submitted proposals (PDF, forms, CVs, budgets), past decisions and outcomes, reviewer pool profiles, and conflict-of-interest data. They typically live in the submission portal or grant-management database, on file shares, in e-mail and in paper or scanned archives of older calls. Typical gaps are scanned or image-only PDFs, inconsistent form fields, duplicate reviewer records, missing ORCID or institution IDs, call rules only in prose, and access rights not separating applicants' confidential data.

Preparation steps: 1. Export proposals and metadata from the portal and normalise them (PREP-005, PREP-011). 2. OCR old PDFs (PREP-006, DOC-014, DOC-018) and detect language. 3. Clean and deduplicate the reviewer pool, add ORCID and institution IDs. 4. Turn call rules into explicit checklists (PREP-019) and derive labels from past eligibility decisions (PREP-020). 5. Build a test set with officers (PREP-018) and pseudonymise data for development (PREP-022); check legal basis for reuse of past proposals (PREP-025).

Rough share of total effort: about 30 percent, mostly reviewer data and rule formalisation.

Implementation paths

Which path for whom

• Public: C — proposals are confidential, unpublished and personal, and public funders have sovereignty and procurement constraints, so self-hosted open models on HW2 (or a sovereign German cloud) fit best.
• Enterprise: B — foundations and corporate funders can use EU-region cloud APIs with contractual no-training clauses and integrate with their portal.
• Developer: C — building for funders usually means delivering an on-premises or sovereign-hosted stack that the client controls.

Path A — Buy (off-the-shelf)

• Grant-management platforms: Fluxx, SmartSimple, Submittable, Flexi-Grant, Optimy, and EU-based options such as Proposal Central-type submission systems from society publishers and the funder-specific systems of national agencies. Several add rule checks and reviewer suggestions; verify what is rule-based versus AI.
• Reviewer finders: publisher-ecosystem tools (e.g. Elsevier Reviewer Recommender, Clarivate, Digital Science/Dimensions) index publications for expertise search; check data-protection terms.
• Research-integrity checks: Turnitin / iThenticate, Crossref Similarity Check for text overlap.
• Choose A when: a mid-size funder wants rule checks and expert search without building models.

Path B — Build on cloud APIs

• LLM and parsing: Azure AI Document Intelligence or Mistral OCR (EU provider) for parsing; frontier LLMs via EU regions (Azure OpenAI EU data zone, Google Vertex EU, AWS Bedrock Frankfurt, Mistral La Plateforme) with structured outputs for checklist verdicts.
• Data for matching: OpenAlex API (open, CC0) and ORCID public API for publications, affiliations and co-authorship.
• Search stack: managed vector search (Azure AI Search, OpenSearch) plus a reranker.
• Workflow: integrate into the funder's existing submission portal; log prompts, outputs and versions for audit.
• Choose B when: custom call rules, funder-specific data and EU residency matter. Proposals are confidential and unpublished; contractually exclude training on inputs.

Path C — Self-host (open source)

• Parsing: Docling, MinerU, PaddleOCR.
• Models: open-weight LLMs (e.g. Qwen3, Mistral, Llama families) via vLLM; embeddings such as BGE-M3 or multilingual-e5, SPECTER2 for scientific text; rerankers such as bge-reranker.
• Stack: PostgreSQL/pgvector or Qdrant, OpenSearch, a graph store for co-authorship, n8n or Camunda for workflow.
• Hardware: HW2 handles a call of a few thousand proposals; HW3 for larger open LLMs. Self-hosting keeps confidential proposals in-house and aids public-body sovereignty requirements.

Path D — Custom training

Worth it for a maturity or fit classifier on a funder's own decision history, or for domain-tuned reviewer-matching embeddings. Needs thousands of labelled past proposals with outcomes, careful bias auditing (field, gender, career stage, language, institution) and a documented purpose. Past decisions encode past biases, which is the main reason to treat this as high-risk.

State of the art (2026)

• Embeddings plus rerankers are the practical standard for reviewer matching; LLMs add explanation, query generation from the call, and expertise summaries. Graph-based COI checks remain more reliable than text-only.
• LLM checklists against call text are accurate on formal criteria (sections, limits, eligibility statements) and weaker on judging novelty, feasibility or quality; do not use them to rank scientific merit.
• Funder policy is cautious: the European Commission's living guidelines on generative AI in research recommend refraining from using generative AI in sensitive activities such as peer review and proposal evaluation, and warn against uploading confidential material or third parties' personal data to online tools; they were revised again in 2026 [3]. Several funders also require reviewers to disclose any AI use. Many funders therefore restrict AI to administrative steps (eligibility, assignment) and keep merit assessment human.
• Limits and failure modes: maturity classifiers may penalise unconventional, interdisciplinary or non-native-English proposals and reinforce the status quo [2]; embedding similarity favours well-published reviewers and can miss emerging fields; name disambiguation errors create false or missed conflicts; hidden-prompt injection in submitted PDFs can manipulate LLM checks, so strip hidden text and treat proposal content as untrusted [3].

Shared resources & combinations

• Same stack: DOC-003 (forms), DOC-014 (parsing for RAG), DOC-016 (rule compliance checking), DOC-015 (requirement extraction) share parsing and checklist logic.
• Integrity side: ANOM-029 (duplicate-submission and paper-mill screening) and DOC-021 (similarity and review of large text sets).
• Applicant side counterparts: LANG-006, KNOW-017.
• Infrastructure: one embedding/vector service (HW2) supports reviewer matching, portfolio analysis and knowledge search.

Effort, cost & KPIs

• Path A: weeks to a few months incl. procurement; per-seat or per-call licences.
• Path B: 3-6 months with pilot on a past call; cost drivers are integration with the portal, evaluation, legal review and bias audits rather than inference.
• Path C: 4-9 months; a GPU server plus MLOps.
• KPIs: officer hours per proposal, share of formal checks confirmed by officers (precision/recall of ineligibility flags), appeal and overturn rate, reviewer acceptance rate of invitations, reviewer expertise rating by panels, time to assemble panels, COI incidents found late, subgroup disparity in flags.

People & change

Involve management and the programme lead (process owner) for scope and accountability, the grant officers as daily users, IT security and IT for hosting, the data protection officer, legal/compliance for procedure law and fairness duties, and the works council or staff council. Plan the DPO and staff council before the pilot, not after.

Works council: yes. In public bodies the staff council (Personalrat) under BPersVG or state law co-decides; in private funders §87(1) no. 6 BetrVG applies because the system logs officer actions, and §90(1) no. 3 BetrVG requires information when AI shapes work processes. Engaging an AI expert is necessary under §80(3) BetrVG. §95(2a) BetrVG matters only if the tool were used for staff selection.

Data protection: personal data of applicants and reviewers, systematic evaluation and possible high-risk use make a DPIA (Art. 35 GDPR) likely; an AVV (Art. 28 GDPR) is needed for any cloud processor. The AI Act classification must be checked (Annex III, access to benefits), with duties from 2 Dec 2027.

AI literacy: support officers with training on bias and limits (Art. 4 AI Act). Pilot on a closed past call alongside the manual process. Concern: "the AI decides on my application". Answer: it only prepares flags; humans decide, with redress. See GUIDE-004, GUIDE-005 and GUIDE-014.

Risks, regulation & compliance

• EU AI Act: classification depends on function. Formal completeness checks and administrative matching are likely minimal risk. Systems that determine or materially influence access to public funding or benefits may fall under Annex III (e.g. eligibility for essential public benefits and services); funders should assess case by case, and a quality or maturity pre-screen that removes applicants before review is the most exposed. Reviewer selection for researchers is not itself an Annex III employment case, but check scope. Art. 5 prohibitions (social scoring, inferring emotions) must not be approached, for example by scoring applicants' character or personal traits. Art. 4 AI literacy applies. This is not legal advice.
• GDPR: proposals, CVs and reviewer profiles are personal data; legal basis is typically public task or legitimate interest; DPIA advisable; Art. 22 safeguards if a decision is solely automated (avoid by design, keep meaningful human review); transparency to applicants and reviewers, and a redress channel [1].
• Confidentiality: unpublished ideas, with the Commission guidance advising against online tools in evaluation [3].
• Fairness and explainability: show cited evidence per flag; audit subgroups; publish a description of the AI use; allow applicants to challenge.
• Mitigations: human decision on every rejection, no AI-only merit scoring, version-pinned models, immutable logs, prompt-injection filtering.

Getting started

1. Define what AI may do (formal checks, duplicate flags, reviewer suggestions) and what it may never do (funding decisions, merit ranking), and publish that policy.
2. Convert one call's rules into a machine-checkable checklist and test on a past call against officer decisions.
3. Build reviewer profiles from OpenAlex/ORCID, test matching against past panel assignments with panel feedback.
4. Run a shadow pilot in parallel to the normal process for one round, measure errors and subgroup differences.
5. Complete DPIA and AI Act assessment, set up the appeal path, then go live with human sign-off.

Sources

1. AI-assisted prescreening of biomedical research proposals: ethical considerations and the pilot case of "la Caixa" Foundation, Data & Policy (Cambridge) — https://www.cambridge.org/core/journals/data-and-policy/article/aiassisted-prescreening-of-biomedical-research-proposals-ethical-considerations-and-the-pilot-case-of-la-caixa-foundation/D17CC86C884D4F9E3A6DD9ABF3F4605E
2. Science Business — The risks and benefits of AI in screening research grant proposals — https://sciencebusiness.net/news/r-d-funding/risks-and-benefits-ai-screening-research-grant-proposals
3. European Commission — Living guidelines on the responsible use of generative AI in research — https://research-and-innovation.ec.europa.eu/document/download/2b6cf7e5-36ac-41cb-aab5-0d32050143dc_en?filename=ec_rtd_ai-guidelines.pdf
4. Trust, transparency, and disciplinary alignment in research funding evaluations: Norwegian AI Center call (2024-2025), PMC — https://pmc.ncbi.nlm.nih.gov/articles/PMC13350320/
5. "la Caixa" Foundation — Eligibility and evaluation guidelines 2026 — https://caixaresearch.org/documents/d/caixaresearch/health-research-call-eligibility-evaluation-guidelines-2026-pdf
6. OpenAlex API documentation — https://docs.openalex.org/
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj