An AI assistant can answer questions from your organisation's own documents, cite the source behind every claim, and admit when it does not know. This is achievable in production today, not a research promise. The condition: build it under a strict grounding contract (corpus-only answers, per-claim citations, honest refusal) and treat the knowledge base beneath it as the real project. The model is the least important decision you will make.
Picture the failure case first. A partner asks the assistant whether subcontracting is allowed under the project's grant agreement. The assistant, drawing on its general training instead of the actual agreement, answers confidently and incorrectly. The partner acts on it. The coordinator spends the next reporting period repairing the damage, and from that day every member double-checks everything the assistant says, so it saves nobody any time.
The economics are asymmetric. A correct answer saves a few minutes. A confident error about eligibility, budget rules or deadlines can cost an audit finding, a strained partnership, or the credibility of the whole platform. So the first question to ask about any assistant is not how smart it is, but what it does when it does not know.
A trustworthy assistant operates under three clauses. Clause one: it answers only from a defined corpus: your grant agreement, handbook, deliverables and decisions, nothing else. Clause two: every claim carries a citation to the specific document, ideally the specific section, it came from. Clause three: when the corpus does not contain the answer, it says so plainly, "this is not in my materials, ask the coordinator."
Drop any clause and the contract fails. Corpus-only answering without citations cannot be verified. Citations without corpus discipline decorate invented answers with real-looking references, which is worse than no citations. Without refusal, the assistant fills every gap with plausible fabrication, which is exactly the failure above.
Grounding means the assistant's answers are anchored in specific documents you control rather than in the model's general training. A grounded answer can be traced to a place in your corpus; an ungrounded one can only be believed or doubted.
Retrieval is the search step that runs before the model writes anything. The question is used to find the most relevant passages in your corpus, and only those passages are handed to the model. The assistant never reads your whole archive; it reads the few excerpts retrieval selected, which is why retrieval quality caps answer quality.
Citation is the link from a claim back to its source: document name, section, version, date. It exists so a human can verify the answer in seconds, and it shifts reader behaviour from trusting the bot to checking the source, the habit you want members to keep.
Hallucination is the model producing fluent, confident text with no basis in any source. It is not a rare malfunction; it is the default behaviour of language models asked something they cannot ground. The contract above exists to contain it, and nothing eliminates it completely.
Step 1. A member asks: "Can we shift budget between work packages?" Step 2. The system searches the corpus and retrieves the best-matching passages, say two grant agreement clauses and an internal decision note. Step 3. The model is instructed to answer using only those passages. Step 4. The answer ties each claim to its passage: it names the clause it relies on and the decision note with the consortium's own procedure, each a visible source the member can open. Step 5. If retrieval found nothing strong enough, the assistant declines and points to a human. A serious implementation also logs each step, so you can later audit why an answer was produced and from which documents.
Swapping one leading model for another changes a grounded assistant far less than fixing the corpus does. If the knowledge base holds three versions of the partner handbook, a draft budget next to the approved one, and call documents from a closed round, retrieval will faithfully surface the wrong material and the assistant will cite it correctly. Sourced answers from a messy corpus are messy answers with footnotes.
The work that matters happens before the pilot: one authoritative version per topic, superseded files removed or marked, an owner and a date on every document, known gaps written down. This is knowledge management, the same discipline behind a good cohort knowledge base, and in our experience it takes longer than the technical integration. That ratio is healthy, and the corpus work pays off whether or not an assistant sits on top.
Three limits survive good engineering. First, contradictory documents: if two versions of a rule both live in the corpus, the assistant can surface both and name them, but it cannot arbitrate which one binds the consortium; a human owns that call. Second, questions outside the corpus: an assistant grounded in your materials cannot answer what your materials do not contain, and pretending otherwise is the failure the contract forbids. Third, interpretation: "will the evaluator accept this" is a judgement question, and the correct behaviour is to show the relevant rule and stop.
Refusal, done visibly, is a feature. A tool that says "not in my materials" is auditable, and an evaluator who probes it learns quickly that its answers mean something. A confident fabrication discovered later does far more harm than a refusal ever did.
The strong use cases are internal and factual: onboarding a new partner into the project's rules and templates, answering member questions the handbook already covers, finding deliverables and past decisions, and keeping project knowledge reachable after the funded period ends, when the people who knew everything have moved on. That last case belongs in your sustainability plan: a sourced assistant over project outputs is dissemination infrastructure that survives the grant.
In a proposal, do not promise accuracy percentages you cannot yet measure, a replacement for the coordinator or the helpdesk, legal advice on the grant agreement, or a general-purpose AI advisor. Promise the narrow, checkable thing: an assistant grounded in the project's own outputs, citing sources, refusing beyond them, with human review wherever answers carry consequences. Evaluators have read many AI paragraphs by now, and the modest version with named limits is the credible one.
Building from scratch only makes sense with engineers on staff. Buying works when a vendor passes the questions below. Open source sits between: it removes lock-in but not the operating burden, since running the assistant and updating the corpus remain your work. We build and operate these assistants in production on our open-source Agentic Platform (Apache-2.0: memory, gateway, tracing, assurance), and the questions below are the ones we expect any serious builder to answer.
A practical next step needs no procurement: collect the questions your members actually asked last month, gather the documents that answer them, and check how many have one authoritative, dated version. The exercise tells you whether you are ready for an assistant and improves your knowledge base even if you never build one.
We operate Impactful, a community impact platform for the Founders community in Cyprus, and build grounded assistants in production on our open-source Agentic Platform. Behind our grant work sits a consortium graph of 114,731 organisations and 83,490 projects, built from CORDIS and Erasmus+ open data (2014-2027). The contract described above is the one we apply in our own systems, not a pattern we read about.