AI agents & observers#
Profile owners: iSHARE + iLabs (engagement: University of the Aegean) · LDT-UC-06 · Status: 🟠 skeleton pre-filled
1–2 · Identity, problem & context#
The LDT adds an AI layer: a trustworthy dual-use AI agent stack (reference architecture + prototype, due M18) and an observer chatbot that lets non-expert stakeholders query the twins. Agents act within the trust framework: they hold credentials, their data access runs through policy enforcement, and their actions are logged like any participant's.
3 · Objectives & KPIs#
Decided Metrics: observer engagement (active users); agent-mediated queries answered; zero policy-violating agent data accesses.
Proposed The third is not a target to be approached but a conformance condition: agents hold credentials and their access runs through the same PEP/PDP path as any participant's, so a policy-violating access is a defect in the enforcement layer, not an acceptable rate. It should be reported as an incident, not as a KPI percentage.
Needs owner — iSHARE + iLabs, with the University of the Aegean on engagement.** Targets and measurement window for the first two. For observer engagement, say who the intended users are — residents, municipal staff, or partner organisations — since the number is meaningless without the population.
4 · Stakeholders#
iSHARE (governance of agent credentials), iLabs (stack), SIMPL governance-agent alignment (watching brief — evolving), Aegean (observer UX/engagement), all sites (data exposure).
5–6 · Data needs & sharing rules this use case needs#
- Agents get least-privilege credentials: scoped to declared purpose, revocable, short-lived.
- AI-Act posture: transparency duties (users know they talk to an AI), risk classification of each agent use, logging for post-hoc audit.
- Observer chatbot answers from open and authorised tiers only; no leakage of restricted data into model context.
Needs owner — iLabs.** The retrieval-boundary design note, and it is more consequential than its placement on this page suggests. The scheme's enforcement model assumes a requester with a credential and a declared purpose; a retrieval-augmented chatbot blurs that — the question is whether retrieval happens under the viewer's credential or under the agent's, and the answer determines whether the chatbot can leak restricted data to an unauthorised viewer.
The scheme's position, for iLabs to confirm or correct: retrieval runs under the viewer's authorisation, so an unauthenticated resident reaches open-tier content only, and no restricted content enters model context for that session. Caching and conversation memory must respect the same boundary, which is the part usually missed.
7 · Architecture (building blocks used)#
Agent identities as VCs; PEP/PDP enforcement identical to human participants; provenance log of agent actions; SIMPL governance-agent interface (risk R4: SIMPL still evolving — keep adapter thin).
8–12 · Timeline, value, risks, EU alignment#
Decided Agent stack prototype at M18 (TR3.2); observer chatbot per T4.4 (M9–M18). Value: accessibility of the LDT for non-experts, and a governance-as-code demonstration.
Proposed Risks and mitigations:
| Risk | Mitigation |
|---|---|
| AI Act classification effort | classify each agent use case early rather than at M18; transparency duties (users know they are talking to an AI) are already committed |
| Hallucinated answers about live city data | answer-with-source policy — every factual answer cites the offering it came from, so a reader can verify. Also the cheapest provenance consumer the scheme has |
| Retrieval boundary leakage | see section 5–6 above; unresolved |
| Agent credentials over-scoped | least-privilege, purpose-scoped, short-lived, revocable — stated on this profile; the policy that implements it does not exist |
| SIMPL instability (risk R4) | keep the adapter thin; watching brief, not a dependency |
Needs owner — iSHARE.** The agent-credential policy draft: which credential types an agent holds, how its declared purpose is bound into the credential, who may issue one, maximum lifetime, and the revocation trigger. This gates admission of agent services under Value creation services section 2, so nothing in the agent layer can be admitted until it exists.