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

Data protection and responsible AI on the platform

Who may open a dataset, what it must declare about itself, and what happens when an AI provider changes its service.

Which safeguards does the PoliRural+ Beta platform use to protect data and keep AI outputs accountable?

Time-limited OAuth tokens validated server-side over secure HTTP; dataset-level permissions in Raven, with an access level, licence and sensitive-data flag on every resource and reuse governed separately from access; and responsible-AI safeguards in D4.2 §10.2: transparency on model limits, human oversight, a clear line between evidence and interpretation, and fallback through a hybrid strategy that includes self-hosted open-weight models.

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

Data protection, access control and AI independence on the Beta platform

main tellingdepth: standard3 min markdown

The Beta platform report (D4.2) treats data protection and responsible AI as one risk area. It combines AI services, geospatial data, stakeholder information, external tools and open-call extensions, so a weak point in any of them affects trust in all.

Who may see what

Users sign in through an OAuth-based flow and receive a time-limited access token. Server-side APIs validate the token on each relevant request, and key exchange, issue and renewal run over secure HTTP. Authorisation sits at service level, so a backend can check both that a request is authenticated and that the role allows it. The modules share one authentication endpoint, which gives users an SSO-like experience across JackDaw and the Multi-Actor tool. D4.2 is explicit that this is not full single sign-on and not enterprise-grade federation, but a deliberate compromise for the Beta stage.

What each dataset must declare

In the Raven catalogue, permissions are set per dataset and can be granted or revoked for named users. Every resource should carry an access level (open, project-internal, restricted, private or approval-based), a licence and a sensitive-data flag for personal, confidential or commercially sensitive content. Automatic processing by AI tools must not bypass legal or organisational constraints. The provenance levels and the rule that access is not reuse are explained in from data to decisions.

Responsible-AI safeguards

D4.2 §10.2 names four: transparency on model limitations, appropriate human oversight, a clear distinction between evidence and interpretation, and fallback mechanisms when a proprietary or unstable AI service becomes unavailable or unsuitable. The risk matrix scores likelihood times impact (each 1–3):

Risk (D4.2, Table 15)ScoreMitigation
Inconsistent metadata quality9Strict metadata guidance; validation at Raven ingestion
Provenance gaps: sources and limits of outputs cannot be traced6Log provenance at four levels; show evidence trails next to outputs
Over-reliance on proprietary or unstable AI models6Hybrid strategy: commercial cloud APIs and self-hosted open-weight models (e.g. Ollama); fallbacks
Poor adoption by non-technical stakeholders6Reference workflows, role-specific training

The hybrid strategy is the platform’s answer to dependence on a single provider: if an external API changes or fails, critical functions should still run.

Rules for funded partners

The Open Call Package (D6.2 §8) binds every funded third party to EU fundamental values, including the protection of minorities and the right to protection of personal data. Activities raising ethical issues need all approvals from the relevant ethics committees and authorities before they start, and beneficiaries keep a file on the research they carry out.

Whether an output is fit for a planning decision is a separate question, covered in grounded AI for rural planning.

Related

Sources