PoliRural+ — Bridging Rural and Urban Europe · knowledge baseInteractive book · llms.txt · For AI agents

Known limits of AI tools, and the safeguards

A wrong programme name, a daily usage cap, advice that ignored allergens: the project's own record of AI limits, and the fixes it names.

What problems did PoliRural+ testers and pilots find with the project's AI tools, and which safeguards do the sources name?

Advisor testers met wrong or outdated facts (a Horizon 2020 reference), daily usage caps and generic advice; first-time JackDaw users felt lost and wanted more data-backed answers; pilots reported weak multilingual and place-name handling and heavy manual data curation. The named safeguards are human judgement on anything forward-looking, visible sources and limits, onboarding and in-tool help, and feedback channels.

Open in the interactive book · missions, mini-games and memory cards there

What testers and pilots found AI getting wrong

main tellingdepth: standard3 min markdown

The project tested its own AI tools and wrote down what went wrong. In February 2025, partners and pilot users ran 8 structured cognitive walkthroughs of the PoliRural+ Advisor (D2.3 Annex B). The Beta platform report (D4.2), the policy brief and the open-call report (D6.3) add more.

The findings

What went wrongWhere it was foundSafeguard the source names
The Advisor gave wrong information, naming the EU Horizon 2020 programme; a later answer was correctedAdvisor walkthroughs, D2.3 Annex BCheck facts; building context over the conversation improved accuracy
Answers were “a snapshot in the past”, which makes forward-looking RAP advice “tricky”SameHuman intervention for future planning
A daily usage limit on the free version cut sessions shortSameExpanded access for key users, batch queries
AI suggestions were too generic, ignoring local needs and allergen limitsPäijät-Häme story, D2.3 §2.8A deliberate multi-step feedback process
Standard tools were not flexible enough for hands-on indicator workVidzeme story, D2.3 §2.8Custom GPT-based tools with region-specific instructions in the local language
First-time JackDaw users felt lost; they expected more data-backed answersD2.3 evaluation of JackDaw60-second tutorial, tooltips, a “Help Me Get Started” button; links to live RAP datasets
Multilingual and place-name handling, and map performance on rural connectionsPilot testing, D4.2 §6.4Strengthen both; show sources, data validity and limits in every output
Feeding rural, multilingual data to AI took months of manual workPolicy Brief No. 1Fund the “human layer”: a data curation line, digital stewards
Applicants lacked clear maturity (TRL) expectations for JackDaw; feedback needed faster bug fixesD6.3 §4.1Clearer upfront definitions; agile bug-resolution channels

What the testers concluded

The Advisor scored 1.0 for difficulty of access on a 1–4 scale (no problems) and 2.9 for clarity and usefulness of the dialogue, rated “useful”. Testers valued its structure and its hints on funding instruments, including ones that fit Community-Led Local Development. One wrote the line that sums up the chapter: the Advisor gives ideas, but advice on the future of the RAP “can be tricky. We need to think for ourselves.” Another noted that it “lacks detailed information that needs to be acquired during the project instead of asking a chatbot.”

Three safeguards that recur

  1. Human review of anything that becomes a plan, a funding decision or a claim about the future (D2.3 Annex B; D4.2 §10.2).
  2. Visible sources and limits: D4.2 §6.4 asks that user-facing outputs carry clear source references, data validity information and limitations relevant to planning decisions.
  3. Onboarding and feedback: in-tool help for first-time users, and a widget asking “How helpful was this answer?” on a 1–5 scale with an optional comment (D2.3).

D4.2 frames such issues as evidence for the final development roadmap, not as failures of the Beta. For the evidence trail that makes errors visible, see from data to decisions.

Play

Related

Sources