AI register

pegnitz.city discloses where artificial intelligence (AI) is used in the documented functions. This public AI register is our current self-assessment and supports transparency under Art. 50 of the EU AI Regulation (EU AI Act); it is neither a legal certification nor an independent audit. For every function described below we name its purpose, data basis, model, human oversight and logging. Where a function is withheld from the public or evidence is still outstanding, we say so. The classification is re-examined whenever a function changes substantially.

Operator and responsibility

Risk classification

Risk classification (EU AI Act). According to our current, non-binding self-assessment, we classify the functions described here predominantly as limited-risk functions with transparency obligations. The released core functions generate hints, summaries, planning proposals or synthetic speech; they do not decide on access to essential public services and take no decision with legal effect on individual persons. Source checking, editorial approval, safety stops and disclosure differ per function and are therefore described individually below. The mentor safety check classifies danger signals only for the current turn and stores no plain text in doing so; because such signals can touch special categories under Art. 9 GDPR, it remains documented separately. The register supports the transparency goal of Art. 50 but does not replace a final legal or regulatory assessment. Prohibited practices such as social scoring or remote biometric identification are not part of the documented release scope.

AI functions on this platform

Translation and review of the public UI catalogue at build time

Purpose: Grok, Codex, GLM 5.3 and Ox Alpha Free may translate and linguistically review fixed interface texts written by the crew before a new language ships. No model call takes place when a page is displayed.

Data & limits: The outgoing job is rebuilt from a closed allow list: German catalogue texts from the repository, the glossary, register notes and the names of unresolved ICU placeholders. No names of private individuals, contact details, citizen contributions, dreams, mentor memories, session data, database extracts or logs. Before every external call a fail-closed gate checks the entire batch; one hit keeps the whole batch on the device.

Models: Exclusively the approved Plane-A subscription doors Grok (xAI), Codex (OpenAI), GLM 5.3 (Z.AI) and Ox Alpha Free (OpenCode Zen gateway, Anomaly Innovations, Inc., USA; unnamed stealth sub-processor; per the provider US hosting, zero retention and no training — no DPA in our records, the same honest gap class as Z.AI; never "EU" or "adequacy"). Exactly one model ID is approved (x-preview-f-free); every other free Zen model trains or logs according to the provider and is excluded. An unknown provider or an unknown data class is refused. Citizen, mentor, dream, child and crisis inference remains exclusively EU-local on our own Ollama infrastructure.

Human control: The models may translate and review, but not approve. An external review pass ends in the state “reviewed by AI, waiting for a human”. Only a recorded human decision may set the status “approved”; shipping a language remains a separate human and board step.

Fallback rule: A repeated safety-gate hit, a breach of catalog provenance, a new provider, or a new data class ends the external permission for the affected strings. The rule then reverts to: EU-local or no run.

Mentor-first dream pre-planning ("Your dream")

Purpose: When you describe a dream for Pegnitz, a private mentor first helps you sharpen it. After at most three steps you can lock in the pre-planned dream; only then does a reviewed projection go into review, research and possible operations.

Data & sources: Your freely entered vision text (limited to 2000 characters), optionally a refinement request and the plan so far; signed-in users only. NEW since 15.08.2026: before planning starts, the city looks your dream up in its OWN verified knowledge — your dream text serves as a search query against the already published knowledge projection (the same function the city's knowledge answer uses), and the nodes found are handed to the model as facts. This lookup runs entirely IN PROCESS on the EU-local machine: a file read, a purely computational ranking and the local Xenova vectors — no network call, no external service, no transmission of your dream to any provider. Excluded are the source-code self-description part of the graph, the crew profiles and other people's dreams. If the city finds nothing or is too slow, the prompt states explicitly that nothing was looked up — an empty block is never passed off as research. In addition, the framing conditions of a small Franconian town (~13,600 inhabitants) given in the prompt. No external databases of personal data.

Model (with hosting country): EU-local, self-hosted inference on XBANQ® GmbH's own hardware — gemma4:31b-mlx on the Mac Studio in Pegnitz (Germany), reached through a private, encrypted tunnel; a second EU-local endpoint (Hetzner, Nuremberg, Germany) serves only as a fallback HOST. HONEST, and made precise since 15.08.2026: there is NO model substitution any more — your dream is planned by the model this city has vetted for it, or it is not planned and we tell you so. For minors with valid consent of their legal guardians the vetted children's model is set instead (also EU-local); a non-EU provider is hard-blocked on this path (fail-closed, no GLM/US fallback for citizen content). The answer is streamed via SSE.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — generates a non-binding planning proposal, no decision with legal effect; no assessment of access to public services.

Human control: A human at the wheel, and since 15.08.2026 literally so: you can OVERRIDE the proposed plan YOURSELF — your changed steps are stored as their own layer next to the model's proposal, and the version you shaped is the version that moves on. The plan is at first visible only to you; publication as a node happens only after editorial approval (moderation:'pending'), and even your self-typed text passes through the same PII scrubbing as every other public field. You can have your contribution deleted at any time.

Logging: Submitted contributions (vision text, generated plan, your own plan version, user ID, timestamp) are stored per account; the live run is not kept as a public log. For every run a person-free operations line is written (event, attempt, model, duration) — never your dream, never the answer, never an account identifier. Rate limiting per user.

Dream-plan queue and delivery email ("Your dream")

Purpose: Since 24.08.2026 the first draft ("preplan") runs through ONE durable queue: no job is lost when a process restarts, and per account the city works on exactly one job — a second button press is told honestly that planning is already under way. Instead of a waiting timeout, the job literally says: you don't have to wait — we will notify you as soon as your draft is ready. That is exactly what the delivery email is for: it only says that your draft is waiting in your protected account. The further job types (refine, legacy assistant, admin surface) are being moved onto the same queue one after another; until then the door refuses them with an honest notice instead of secretly working around the model.

Data & sources: Your raw dream (12–2000 characters) lives exclusively in its own holding row: written only by the server service, readable only for your account, and the column holding the raw dream itself is visible to the server service only. After completion it is deleted — at the latest 24 hours later a cleanup run forces the rest. The notification queue contains no content. A possible email only says that your plan is ready in your protected account; title, first step and dream text are not sent along. Automatic planning begins only once your email is confirmed and your account is approved.

Model: Plan generation itself is unchanged: the EU-local, self-hosted inference described above (gemma4:31b-mlx; the children's path fixed to the vetted children's model, no non-EU provider). New about the queue: access to the single EU-local model is deliberately pinned to exactly one concurrent run — nobody is bumped up, nobody is pushed aside. And the queue closes itself for minors: only an explicit adult answer at the age gate runs the adult model; every missing or undetermined age counts as a child and gets the children's model (fail-closed). For the email itself NO AI model is called — it is a fixed, rule-based template on our own infrastructure in Germany.

Risk class: Plan generation unchanged: limited risk / transparency obligation (Art. 50) — a non-binding planning proposal, no decision with legal effect. The email is not AI within the meaning of the EU AI Act (rule-based delivery). Under data-protection law it rests on Art. 6(1)(b) GDPR (performance of the "Your dream → plan" function you requested): it is delivery of the result you ordered, not advertising and not a newsletter — and can be switched off in your account at any time, additionally with a one-click unsubscribe link.

Human control: You place the job with your dream; the draft stays visible only to you at first, and publication as a node happens only after editorial approval (moderation:'pending'). After completion your coach takes the first step: a fixed, rule-based greeting built from your plan welcomes you — no model improvises it, and it is created before any email even enters the queue; if the handover fails, no mail is sent. The job via the admin surface for already submitted dreams is reserved for signed-in admins.

Logging: Operations lines about the queue are person-free: event, attempt, model, duration — never your dream, never the answer, never an account identifier. For the email a private delivery line with status and reason is kept (for example: queued, or skipped because unsubscribed); a line counts as sent only once the service provider has actually confirmed the delivery.

Structuring the city intelligence's knowledge (data pipeline)

Purpose: With AI support it researches, structures and curates publicly verifiable facts about institutions, places, organisations and offices in Pegnitz and orders them into the knowledge intelligence (clusters, nodes, relationships).

Data & sources: Publicly accessible sources (websites, registers, official figures). Factual statements are meant to be linked to a checkable source reference; gaps are never passed off as verified. No personal data of private individuals — public office-holders only in their official role.

Model: Headless swarm: opencode-GLM and Codex as executors, steered and planned by Claude (Opus) as planner; assembly happens at build time, not on every page view.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — structures public factual information; no decision about persons, no profiling.

Human oversight: Source duty; content intended for publication passes through the described source and approval process. The respective surface or this register discloses the documented AI support.

Logging: Logged in agent_runs / verification_results (internal, server-side only — no public feed).

AI verification stage (source matching)

Purpose: Checks the source-bound values handed to a verification run against their stated live sources. Deviating values, unreachable sources, empty mandatory fields or unresolved rights lead to rejection and must be worked through before an approval.

Data & sources: Structured nodes and statements from the pipeline and their source URLs.

Model: Claude (Opus) through the Claude Code CLI (subscription login, no API key) as verifier.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — a quality gate that secures factual fidelity; makes no decision about persons.

Human oversight: The verification run supports human control: a value rejected there may not leave this approval path as passed.

Logging: Every rejection with reason and, where applicable, source URL in verification_results (internal, not public).

Cluster and node synthesis (intelligence texts in the intelligence)

Purpose: Generates the summarising analysis and recommendation texts ("intelligence"/synthesis) that explain a sphere of life in the cluster and node view of the knowledge intelligence.

Data & sources: The already verified, structured nodes and relationships of the graph. The texts are generated at build time and stored in the graph; on display the surface computes only from the loaded graph, with no renewed model call.

Model: Headless swarm (opencode-GLM / Codex) at build time.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — descriptive synthesis of public matters; no personal decision.

Human oversight: Editorial review is intended for public approval; this register discloses the AI-supported generation of the synthesis.

Logging: Generation within the pipeline runs (agent_runs, internal).

PII generalisation of the AI free texts (scrub-pii)

Purpose: Generalises privately or owner-run small businesses named by name in the AI free texts (synthesis, analyses, recommendations), so that no identifiable natural persons appear in the public texts.

Data & sources: AI-generated free texts from the synthesis. Public office-holders in their official role are kept (lawful under Art. 6(1)(f) GDPR).

Model: Deterministic rule and regex function — NO AI, no language model. Carried here for transparency because it post-processes AI output.

Risk class: No AI within the meaning of the EU AI Act (rule-based); GDPR data-minimisation measure — purely deterministic text replacement; it serves data protection and makes no decision.

Human oversight: The rule list is maintained editorially and extended with every regeneration.

Logging: No separate logging; part of the pipeline export.

"Ask the city" — knowledge answer (grounded RAG)

Purpose: You ask a question about the town and get a short answer bound to real sources. The city first searches its own knowledge purely lexically (the verified graph nodes), shows you the real nodes it found as cards, and formulates a brief summary from them. If it finds nothing solid, it says so honestly ("The city does not know anything about that yet") — entirely without a model call.

Data & sources: Your freely entered question (limited to a short length) and ONLY the already verified, publicly source-based nodes of the knowledge intelligence (web/.artifacts/graph.json) — no external databases, no internet access during the answer. The model receives only the previously retrieved node excerpts plus your question and may cite ONLY these nodes; any other source statement is discarded server-side (source whitelist). The question is not stored by content.

Model (with hosting country): EU-local, self-hosted inference on our own hardware — gemma4:31b-mlx on the Mac Studio in Pegnitz (Germany), reached through a private, encrypted tunnel; a second EU-local endpoint (Hetzner, Nuremberg, Germany) is only a fallback HOST, not a substitute MODEL. Fail-closed (no GLM/US fallback for citizen content), with tools switched off (no file or network access); the answer is streamed via SSE. An answer is cached briefly in working memory (per instance) to answer repeated identical questions without a renewed model call.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — answers factual questions from verified public knowledge; makes no decision about persons, no profiling, no legal effect.

Human oversight: Grounding by design: the model sees only already verified nodes and may cite only those — an invented source cannot pass the whitelist. The displayed source cards stand on their own; if the summary fails, they remain the honest answer. AI answers are recognisable as such.

Logging: No content storage of the question. Rate limiting per anonymised (hashed) IP — the raw IP is never stored or logged.

Business position-finding (website analysis / dossier) — in preparation

Status (honest): The public website input and its citizen API are withheld in Core V1. Existing internal review and deletion paths remain; citizens cannot start an analysis at present. A public activation follows only after its own security, privacy and browser evidence.

Purpose: Once active, you enter your business's web address and confirm that you operate it or are authorised to do so. The city reads the publicly reachable website and creates a first free position-finding from it: a brief classification of the presence plus concrete, evidence-based recommendations. The result is created as a node with status moderation:'pending' and appears publicly only after editorial approval.

Data & sources: Only the publicly retrievable content of the website you name (name, description, services, headings, public contact and social details, structured data, text excerpt). The scraper checks the target address against internal and local addresses (SSRF protection) and respects robots.txt. The text read in is DATA to be analysed, never an instruction to the model (prompt-injection protection). No personal data of private individuals; public office-holders only in their official role.

Model: Claude (Opus) through the Claude Code CLI (subscription login, no API key), called as a server process. If the CLI is unavailable, an honest evidence scaffold built exclusively from the recognised gaps is returned — never an invented claim.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — generates a non-binding analysis and recommendations for a business; no automated decision with legal effect about persons, no credit-rating or access assessment, no profiling.

Human oversight: The model analyses ONLY from the evidence presented and names gaps instead of guessing. The generated node is moderation:'pending' and becomes public only after editorial approval; only signed-in users who confirm the entitlement can trigger the analysis. You can have the contribution deleted at any time (GDPR Art. 17).

Logging: The generated (pending) node is stored in the dossier inbox; the live run is not kept as a public log. Rate limiting per user.

Personal mentor agent ("Your agent")

Status (honest): This V1 is released for confirmed adults: you describe your dream, choose a stance (mentor, sparring partner or "Your CEO"), and a personal, client-side encrypted agent record is created for you. Minors and people of undetermined age receive no model answer in this V1. The protected conversation is wired as an account function: the plain text is processed in working memory only for the single answer turn, not stored server-side, and encrypted again client-side afterwards. You can keep several saved conversations: every chat has a title you assign freely, and this title too is stored client-side encrypted. You can archive older conversations; they remain encrypted until you delete them.

Purpose: The private, personal agent of a citizen (mentor, sparring partner or "Your CEO"). It is meant to accompany you on your own dream — as a coaching, sparring and implementation counterpart. It decides nothing for you; you decide, own and sign.

Data & sources: Only your own content entered by you (profile, dream, conversation history, chat title). The CONTENT is held client-side encrypted as AEAD ciphertext (messages and chat titles alike); the key is derived from a passphrase you hold. The operator cannot read this content. HONEST and complete: per chat a few CONTENT-FREE administrative details are additionally kept unencrypted so the chat list works — number of messages, time of the last message, and whether a chat is pinned or archived. These metadata contain no conversation content and no title. For the single answer turn plain text can be processed transiently in the server-side environment; it is not stored server-side. NEW since 15.08.2026: before the answer the mentor looks up your last message in the verified city knowledge — through exactly the same function as the dream pre-planning, entirely in process on the EU-local machine (file read, computational ranking, local vectors), with no network call and no transmission of your message to any provider. Excluded are the source-code self-description part of the graph, the crew profiles and other people's dreams; if the lookup does not land within its short time window, the prompt states explicitly that nothing was looked up. No external profiling, no tracking, no passing on to advertising or profiling services.

Model: The private mentor inference for adults runs exclusively EU-local and self-hosted with the model vetted for this V1, gemma4:e4b, on the operator's Mac Studio in Pegnitz (Germany), reachable through a private, encrypted tunnel. There is no fallback node and no substitute model for this mentor: if the Mac is unreachable, overloaded, or an answer takes longer than 25 seconds, a limited not-available answer appears. Every run returns exactly one buffered JSON answer, uses no tools, changes no files and logs no message content. The client stores its own turn and the answer together, encrypted, afterwards.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — a personal coaching and sparring tool without automated decision with legal or comparably significant effect; no profiling, no assessment of access to public services.

Human oversight: A human at the wheel: the agent is meant to propose and accompany; the citizen decides and owns the outcome. The current V1 refuses minors and people of undetermined age the model call even when a consent is already on file. A later children's version needs its own model evaluation, its own output protection and the child-protection approval. Distress recognition runs deterministically before every inference and once more server-side across every conversation turn: on self-harm, abuse or danger signals the model call stops, no answer is generated and real help routes appear. pegnitz.city is not an emergency service; in acute need you turn directly to real help: telephone counselling 0800 111 0 111 or 0800 111 0 222 (free, anonymous, around the clock), Nummer gegen Kummer 116 111 (free, anonymous, Mon–Sat 14:00–20:00), fire brigade and ambulance 112 or police 110 (both free, around the clock).

The one door from your mentor to the crew (new since 15.08.2026): Your mentor can now do two things — and only two. FIRST ASKING: it answers the question of what the city has actually done with your dream, exclusively from YOUR OWN lines that you can read back in your account; the sentence is assembled from counted lines, no model formulates it, and if there is nothing, it says exactly that. SECOND REQUESTING: you can place a request to the crew — it is stored as a PROPOSAL that is shown to nobody without your explicit approval and triggers no crew work. What leaves this door is narrowly limited: a pseudonymous tag of your dream (a derived hash value, never your account identifier) and the already scrubbed public short version, plus your request text, which is first scrubbed of contact details AND then checked once more for whether anything personal remains. If something remains, the request does NOT go out and you are told so. Anyone who has locked their dream anonymously has no such tag — then nothing goes out at all, and the asking still works. The mentor itself gets no tool in hand for this: the inference still has no tool access whatsoever.

Logging: No content logging by the operator — stored content is encrypted and unreadable to the operator; the live inference logs no message content. Archiving vs. deletion: archiving only hides a chat from the active list; the encrypted history remains. Right to deletion (GDPR Art. 17): only deleting your keys and ciphertexts makes the content irrecoverable — this continues to work unchanged for archived chats.

Mentor reminders of your own next steps — email delivery withheld

Status (honest): Reminders are OFF by default and only arise when you switch them on yourself. In the app you see them in your account. The EMAIL delivery remains withheld — locked threefold: first, delivery is switched off in the operating configuration and the sender domain is not approved; second, the confirmation step (double opt-in by email) is not yet built — a consent therefore cannot be confirmed at all and so cannot become deliverable; third, the check before every delivery demands a confirmed, current consent and fails closed without it. Since 17.08.2026 this consent under Art. 7 GDPR has been storable in the database — versioned, word-identical, with separate revocation that takes effect in your settings at any time and overrides every earlier confirmation. The storage location therefore exists; but without the built confirmation step every consent remains in the state "not confirmed", and exactly that is what every attempt to send fails on. As long as that holds, no reminder email goes out. We will disclose an activation here only once it has really taken place.

Purpose: To remind you of ONE step you set yourself — not to pull you back into the app. No step, no reminder: we prefer silence to a manufactured occasion.

Data & sources: Your own settings (on/off, quiet hours, time zone), the title of your own open mentor task and — only at the moment of a real delivery — your confirmed account email address. The queue itself stores neither your email address nor a finished rendered private email nor your raw dream. No external data sources, no profiling, no advertising.

Model (with hosting country): For the reminder itself NO AI model is called: selection and text are a fixed, rule-based template running on our own infrastructure in Germany. The step named comes from your own mentor plan previously generated EU-locally. For transparency this point still stands here because it delivers an AI output. If a delivery happened, the delivery service would be an email provider (Resend, EU/USA, DPF-certified, DPA in place) — this point is disclosed here before it becomes active, not afterwards.

Risk class: No AI within the meaning of the EU AI Act (rule-based delivery). Under data-protection law a direct communication on the basis of your consent (Art. 6(1)(a), Art. 7 GDPR).

Human control: You decide threefold: reminders are off until you switch them on; an email additionally requires its own consent given explicitly for this purpose in the double-opt-in procedure, separate from the newsletter consent; and you can revoke it separately at any time — via the one-click unsubscribe link or in your settings. A missing, a revoked and an unconfirmed proof all lead to the same outcome: nothing is sent.

Logging: For every delivery attempt a private line with status and reason is kept (for example: queued, or skipped because no consent is on file), so that no duplicate reminder arises. A line counts as sent only once the service provider has actually confirmed the delivery — a waiting reminder is never shown as sent. Unsubscribes, bounces and complaints are kept as private block data.

The crew voice (live spoken work updates of the agents)

Status (honest) — speaker identity: The name you read and hear on a spoken line is the self-report of the respective agent run. The platform records for every line whether this identity could be technically evidenced — and for the lines played out publicly this flag currently reads "not evidenced". So we tell you WHICH NAME filed the message — not that this identity is proven. If an unevidenced line claims a leadership role (e.g. CEO or child protection), it is explicitly marked as unevidenced in the crew view; for all other roles no such note appears so far. A machine-checkable speaker proof is in preparation; as soon as it really carries the public lines, that will be disclosed here.

Purpose: On the start page and in the crew view you can switch on the crew's voices: a real work beat of an agent (start or completion of a task) can become audible as a short, freely worded spoken status message — under which name the message was filed, what is being worked on, why it helps the town and who takes over next. Not every beat becomes audible: lines that do not pass the safeguards described below stay silent. The written feed stays German; the spoken line is English.

Data & sources: ONLY internal operating facts held in the repository: the authored identity of the agent (name, role, character), the crew's real work report and the board-registered facts of the related operation. No citizen data, no personal data — a work report containing an email address or phone number produces NO spoken line (fail-closed).

Model: The spoken line is authored by the executing agent session itself — no model composes it (per line, model = NULL and speechAuthor = 'agent' is on record). This session runs on the provider the respective work runs on; for Plane-A coding lanes that is outside the EU (e.g. Z.AI/China, Anthropic/USA, OpenAI/USA). No citizen and no personal data enters these prompts — the outgoing transfer is the PII-free coding prompt (already registered as Plane A), the speech line is output that flows back into the EU. The speech output itself happens through self-hosted TTS engines (Piper/Qwen) on our own infrastructure.

Safeguards (grounding, fail-closed): Every composed line passes a deterministic checker: refusal phrases, unevidenced numbers, invented people or authorities (e.g. a board okay never given), missing operation codes and unevidenced success or approval claims lead to the line being discarded — the beat then stays silent in the written feed. The work report is handed to the model structurally as DATA, never as an instruction (prompt-injection protection).

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — synthetic speech output about the agent crew's own work; no decision about persons, no profiling. The speech output is labelled as AI in the surface (switch "AI voices on/off") and is only active if you switch it on yourself.

Logging: Every spoken line originates from a publicly visible line in the crew view's live feed (table warroom_live_activity; the older feed agent_activity no longer carries these lines) — what is spoken is also readable and traceable. For every line it is additionally recorded internally whether the speaker identity could be technically evidenced; this flag is the basis of the honest limitation disclosed above.

Ziggy Kosmos — learning companion for children (public showcase page)

Status (honest): Publicly reachable is the showcase page with guided tours and a read-aloud function — fixed, editorially maintained texts explaining the planned learning system. The learning system itself (account, exercises, mentor conversations, drawing check) is NOT publicly released: it is a guided pilot behind sign-in and its own approvals. Before children can use it, an own review of the knowledge for age-appropriateness (JMStV), the child-protection approval and the binding evaluation of the children's model are required — until then this part stays withheld.

Purpose: The page introduces Ziggy Kosmos: a private learning companion that offers children exercises following the Bavarian LehrplanPLUS, accompanies them socratically (the AI never simply gives the solution) and, at a teacher's request, generates 3D scenes on learning topics. On the public page itself no learning happens — it only explains.

Data & sources: On the public page the platform processes NO citizen data: the read-aloud function speaks exclusively fixed slide texts from a closed catalogue that you can select slide by slide — free text is not accepted and can never reach the voice. For abuse defence only an anonymised (hashed) IP address serves for rate limiting. The (non-public) learning system processes children's learning progress and conversations exclusively with the consent of their legal guardians (Art. 8 GDPR), encrypted and EU-local — this part is not active.

Model (with hosting country): The read-aloud is a synthetic voice: self-hosted Piper speech output (German voice) on XBANQ® GmbH's own hardware in Germany — no external service, no transmission to third countries. The learning system (not public) computes with self-hosted, EU-local models on Ollama (mentor: gemma4; drawing check: qwen3-vl) — fixed for children's paths with no fallback model (fail-closed).

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — synthetic voice and explanatory presentation; no decision about persons. The learning system is classified as limited risk under the binding condition that learning stands remain private and are never used as an official school assessment; a high-risk situation (official assessment or access) would block any go-live.

Human oversight: The public page consists of fixed, editorially maintained content. In the learning system: teacher, legal guardians and the child steer; the AI does not assess officially, decides nothing and replaces no school. pegnitz.city is and remains not an official offer of the town of Pegnitz.

Logging: No content storage on the public page; rate limiting per anonymised (hashed) IP — the raw IP is never stored. The learning system logs internally, per account, and is not publicly active.

City media library: AI media analysis (image, sound, search) — in preparation

Status (honest): Public upload, public search and public media view are withheld in V1. Existing owner proofs and revocations as well as separate reviewer, admin and analysis paths remain. The EU-local AI analysis works fail-closed: without a reachable local model no automatic analysis is created, the person signal stays "unknown" and there is no automatic publication. A public activation is disclosed here only after its own approval evidence.

Purpose: Once active, the AI supports the human review of uploaded media: an image AI describes and tags a medium and estimates whether people or presumably minors are visible (youth-protection pre-sorting); audio tracks are transcribed locally; for the media search local vectors are computed.

Data & sources: Only the media you upload and your own details (title, category, person classification). No external databases, no matching against third-party person records, no biometric recognition.

Model: EU-local, self-hosted inference on our own hardware in Germany — image AI: exclusively the pinned, capability-evidenced image AI (OLLAMA_KIDS_MODEL, currently gemma4:e4b on the Mac Studio in Pegnitz (Germany)); adult or generic vision overrides are deliberately ignored, without the pin no analysis runs (fail-closed). Transcription whisper.cpp, search vectors Xenova multilingual-e5-small; no transmission to a third country.

Risk class: According to our current self-assessment: limited risk / transparency obligation (Art. 50) — preparatory description and pre-sorting; no automated decision with legal effect about persons. The minor pre-sorting serves youth protection and can touch special categories (Art. 9 GDPR); it decides nothing, but lays every doubtful case before a human.

Human oversight: A human at the wheel and fail-closed: nothing becomes visible or used before a human has approved it. If the uploading person's statement deviates from an AI signal, or the AI analysis is unavailable, a human necessarily reviews. Media with recognisable minors stay locked without documented consent of their legal guardians.

Logging: Analysis results (description, transcript, person signal, model) are stored per medium internally (media_vault_analysis, accessible server-side only through row-level security). On revocation or deletion, the analysis, transcript and search vector are removed with them.

No training on city data — attestation per model

For every model this instance can use, the table below attests why its outputs do not flow into the training or fine-tuning of general models: contractually assured and evidenced in the data processing agreement, or technically impossible because the model is self-hosted with no provider connection. Each entry carries the date its verification was last checked.

Human control & logging

Human control and logging differ per approval path. In the data pipeline the source-bound values handed to a run are checked; a value rejected there must be worked through before approval. Citizen visions are stored as origin:'citizen', moderation:'pending' and appear in the public knowledge intelligence only after an explicit editorial approval. The documented core surfaces disclose their AI support on the result or in this register. Pipeline runs are logged internally in agent_runs and verification_results, among others with status, check result, rejection reason and, where applicable, source URL. These logs are no public real-time feed; a public live audit viewer does not exist at present. The source duty remains a binding quality claim, not the assertion that every historical node is already completely evidenced. Media with unresolved rights are not released publicly.

In preparation

• Publicly viewable audit and log viewer: the logs (agent_runs, verification_results) already exist but are currently accessible server-side only (service_role). A publicly viewable audit area is not yet implemented — as soon as it arrives, it will be disclosed transparently here.
• Editorial approval workflow for citizen visions: contributions are already held as moderation:'pending'; the approval process is implemented as a principle, a comfortable moderation front end is in preparation.
• City media library — AI media analysis: public intake and public search stay closed in V1. The internal analysis and review paths are activated publicly only after their own approval evidence.
• Machine-checkable speaker proof for the crew voice: as long as it does not carry the publicly played lines, the displayed agent name is a self-report of the respective run and no proof. The state stands honestly at the top of the "Crew voice" section and will be changed here as soon as the proof really grips.
• Mentor reminder emails: the delivery path is built and checked, but withheld. The consent under Art. 7 GDPR has been storable and separately revocable since 17.08.2026; the confirmation step by email (double opt-in) is the still-missing part, and without it the check refuses every delivery. We will change this paragraph only when the confirmation step is built and the first delivery is actually approved.
• Further AI functions are added here as soon as they are actually released; withheld functions remain explicitly marked "In preparation" until then.