Registre de l'IA

pegnitz.city divulgue où l'intelligence artificielle (IA) est employée dans les fonctions documentées. Ce registre public de l'IA est notre auto-évaluation actuelle et soutient la transparence au titre de l'Art. 50 du règlement européen sur l'IA (EU AI Act) ; il n'est ni une certification juridique ni un audit indépendant. Pour chaque fonction décrite ci-dessous, nous nommons son objectif, sa base de données, son modèle, son contrôle humain et sa journalisation. Là où une fonction est retenue loin du public ou qu'une preuve manque encore, nous le signalons. La classification est réexaminée à chaque modification substantielle de la fonction.

Opérateur et responsabilité

Classification des risques

Classification des risques (EU AI Act). Selon notre auto-évaluation actuelle, non contraignante, nous classons les fonctions décrites ici de manière prépondérante comme des fonctions à risque limité avec obligations de transparence. Les fonctions centrales publiées génèrent des indications, des résumés, des propositions de planification ou de la voix synthétique ; elles ne décident pas de l'accès à des services publics essentiels et ne prennent aucune décision à effet juridique sur des personnes individuelles. La vérification des sources, l'approbation éditoriale, les arrêts de sécurité et la divulgation diffèrent selon la fonction et sont donc décrits individuellement ci-dessous. Le contrôle de sécurité du mentor classe des signaux de danger uniquement pour le tour en cours et ne stocke aucun texte en clair ce faisant ; parce que de tels signaux peuvent toucher des catégories particulières au sens de l'Art. 9 RGPD, il reste documenté séparément. Le registre soutient l'objectif de transparence de l'Art. 50, mais ne remplace pas une appréciation juridique ou réglementaire définitive. Les pratiques interdites comme la notation sociale ou l'identification biométrique à distance ne font pas partie du périmètre de publication documenté.

Fonctions d'IA sur cette plateforme

Traduction et vérification du catalogue d'interface public au moment de la construction

Objectif : Grok, Codex, GLM 5.3 et Ox Alpha Free peuvent traduire et vérifier linguistiquement des textes d'interface fixes rédigés par l'équipe avant qu'une nouvelle langue ne soit livrée. Lors de l'affichage d'une page, aucun appel de modèle n'a lieu.

Données et limites : Le travail sortant est reconstruit à partir d'une liste blanche fermée : des textes de catalogue allemands du dépôt, le glossaire, les indications de registre de langue et les noms des marqueurs ICU non résolus. Aucun nom de personnes privées, aucune donnée de contact, aucune contribution de citoyens, aucun rêve, aucun souvenir du mentor, aucune donnée de session, aucun extrait de base de données ni aucun protocole. Avant chaque appel externe, une porte fail-closed vérifie tout le lot ; une seule correspondance retient tout le lot sur l'appareil.

Modèles : Uniquement les portes d'abonnement Plan A déjà admises Grok (xAI), Codex (OpenAI), GLM 5.3 (Z.AI) et Ox Alpha Free (passerelle OpenCode Zen, Anomaly Innovations, Inc., États-Unis ; sous-traitant furtif non nommé ; selon le prestataire hébergement aux États-Unis, zéro rétention et aucun entraînement — aucun DPA dans nos dossiers, la même classe d'incertitude honnête que Z.AI ; jamais « UE » ni « adéquation »). Exactement un identifiant de modèle est admis (x-preview-f-free) ; tout autre modèle Zen gratuit, selon le prestataire, entraîne ou journalise, et est exclu. Un prestataire inconnu ou une classe de données inconnue est rejeté. L'inférence citoyenne, mentor, rêve, enfant et crise reste exclusivement locale à l'UE sur notre propre infrastructure Ollama.

Contrôle humain : Les modèles peuvent traduire et vérifier, mais pas valider. Un passage de vérification externe se termine dans l'état « vérifié par IA, attend un humain ». Seule une décision humaine enregistrée peut poser le statut « validé » ; la livraison d'une langue reste une étape humaine et du conseil séparée.

Règle de repli : Un échec répété de la porte de protection, une violation de l'origine du catalogue, un nouveau prestataire ou une nouvelle classe de données met fin à l'autorisation externe pour les textes concernés. Le principe redevient alors : local à l'UE ou pas d'exécution.

Pré-planification du rêve avec le mentor en premier (« ton rêve »)

Objectif : Quand tu décris un rêve pour Pegnitz, un mentor privé t'aide d'abord à l'affûter. Après trois étapes au maximum, tu peux fixer le rêve pré-planifié ; seulement ensuite, une projection vérifiée passe en revue, en recherche et en opérations possibles.

Données et sources : Ton texte de vision saisi librement (limité à 2000 caractères), éventuellement une demande d'affinage et le plan jusqu'ici ; réservé aux utilisateurs connectés. NOUVEAU depuis le 15.08.2026 : avant la planification, la ville cherche ton rêve dans sa PROPRE connaissance vérifiée — le texte de ton rêve sert de requête de recherche contre la projection de connaissance déjà publiée (la même fonction que la réponse de connaissance de la ville utilise), et les nœuds trouvés sont remis au modèle comme faits. Cette recherche tourne entièrement EN PROCESSUS sur la machine locale UE : une lecture de fichier, un classement purement calculatoire et les vecteurs Xenova locaux — aucun appel réseau, aucun service externe, aucune transmission de ton rêve à un prestataire. Sont exclus la partie d'auto-description du code source du graphe, les profils de l'équipe et les rêves d'autres personnes. Si la ville ne trouve rien ou est trop lente, l'invite indique explicitement que rien n'a été cherché — un bloc vide n'est jamais présenté comme une recherche. En outre, les conditions cadres d'une petite ville franconienne (~13.600 habitants) données dans l'invite. Aucune base de données externe de données personnelles.

Modèle (avec pays d'hébergement) : Inférence locale UE, auto-hébergée, sur le matériel propre de la XBANQ® GmbH — gemma4:31b-mlx sur le Mac Studio à Pegnitz (Allemagne), rejoint par un tunnel privé chiffré ; un second point de terminaison local UE (Hetzner, Nuremberg, Allemagne) ne sert que d'HÔTE de repli. HONNÊTE, et précisé depuis le 15.08.2026 : il n'y a PLUS de substitution de modèle — ton rêve est planifié par le modèle que cette ville a vérifié pour cela, ou il n'est pas planifié et nous te le disons. Pour les mineurs avec consentement valable de leurs représentants légaux, le modèle enfant vérifié est fixé à la place (également local UE) ; un prestataire hors UE est bloqué durement sur ce chemin (fail-closed, aucun repli GLM/États-Unis pour les contenus citoyens). La réponse est diffusée en streaming via SSE.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — génère une proposition de planification non contraignante, aucune décision à effet juridique ; aucune appréciation de l'accès aux services publics.

Contrôle humain : Un humain au volant, et depuis le 15.08.2026 au sens propre : tu peux RÉÉCRIRE TOI-MÊME le plan proposé — tes étapes modifiées sont stockées comme leur propre couche à côté de la proposition du modèle, et la version que tu as façonnée est celle qui continue. Le plan n'est d'abord visible que de toi ; une publication en nœud n'a lieu qu'après approbation éditoriale (moderation:'pending'), et même ton texte saisi toi-même passe par le même nettoyage des PII que tout autre champ public. Tu peux faire supprimer ta contribution à tout moment.

Journalisation : Les contributions soumises (texte de vision, plan généré, ta propre version du plan, identifiant d'utilisateur, horodatage) sont stockées par compte ; l'exécution en direct n'est pas tenue comme protocole public. Pour chaque exécution, une ligne d'exploitation sans personne est écrite (événement, tentative, modèle, durée) — jamais ton rêve, jamais la réponse, jamais un identifiant de compte. Limitation de débit par utilisateur.

File plan-du-rêve et courriel de mise à disposition (« ton rêve »)

Objectif : Depuis le 24.08.2026, le premier brouillon (« preplan ») passe par UNE file durable : aucune tâche n'est perdue quand un processus redémarre, et par compte la ville travaille sur exactement une tâche — à une seconde pression du bouton, il est dit honnêtement que la planification est déjà en cours. Au lieu d'un délai d'attente, la tâche dit littéralement : tu n'as pas à attendre — nous t'avertissons dès que ton brouillon est prêt. C'est exactement là que le courriel de mise à disposition intervient : il dit seulement que ton brouillon t'attend dans ton compte protégé. Les autres types de tâches (affinage, ancien assistant, surface d'administration) sont transférés sur la même file l'un après l'autre ; jusque-là, la porte les refuse avec un avis honnête au lieu de contourner secrètement le modèle.

Données et sources : Ton rêve brut (12–2000 caractères) vit exclusivement dans sa propre ligne de garde : écrite uniquement par le service serveur, lisible uniquement pour ton compte, et la colonne portant le rêve brut lui-même n'est visible que du service serveur. Après achèvement, elle est supprimée — au plus tard 24 heures plus tard, un passage de nettoyage force le reste. La file de notification ne contient aucun contenu. Un courriel éventuel dit seulement que ton plan est prêt dans ton compte protégé ; titre, première étape et texte du rêve ne sont pas transmis. La planification automatique ne commence que lorsque ton courriel est confirmé et ton compte approuvé.

Modèle : La création du plan elle-même reste l'inférence locale UE, auto-hébergée, décrite ci-dessus (gemma4:31b-mlx ; le chemin enfant fixé sur le modèle enfant vérifié, aucun prestataire hors UE). Nouveau avec la file : l'accès à l'unique modèle local UE est volontairement cloué à exactement une exécution simultanée — personne n'est privilégié, personne n'est évincé. Et la file se ferme d'elle-même pour les mineurs : seule une réponse explicite d'adulte au portail d'âge exécute le modèle adulte ; tout âge manquant ou indéterminé compte comme enfant et reçoit le modèle enfant (fail-closed). Pour le courriel lui-même, AUCUN modèle d'IA n'est appelé — c'est un gabarit fixe, fondé sur des règles, sur notre propre infrastructure en Allemagne.

Classe de risque : Création du plan inchangée : risque limité / obligation de transparence (Art. 50) — une proposition de planification non contraignante, aucune décision à effet juridique. Le courriel n'est pas de l'IA au sens de l'EU AI Act (livraison fondée sur des règles). En droit de la protection des données, il repose sur l'Art. 6, par. 1, let. b) RGPD (exécution de la fonction « ton rêve → plan » que tu as demandée) : c'est la livraison du résultat commandé, pas de la publicité et pas un bulletin d'information — et désactivable à tout moment dans ton compte, en plus avec un lien de désinscription en un clic.

Contrôle humain : Tu passes la commande avec ton rêve ; le brouillon reste d'abord visible de toi seul, et une publication en nœud n'a lieu qu'après approbation éditoriale (moderation:'pending'). Après achèvement, ton coach fait le premier pas : un accueil fixe, fondé sur des règles, construit depuis ton plan te reçoit — aucun modèle ne l'improvise, et il est créé avant même qu'un courriel n'entre dans la file ; si la passation échoue, aucun courriel n'est envoyé. La commande via la surface d'administration pour des rêves déjà soumis est réservée aux administrateurs connectés.

Journalisation : Les lignes d'exploitation sur la file sont sans personne : événement, tentative, modèle, durée — jamais ton rêve, jamais la réponse, jamais un identifiant de compte. Pour le courriel, une ligne privée de livraison avec statut et raison est tenue (par exemple : en file, ou sautée car désinscrit) ; une ligne ne compte comme envoyée qu'une fois que le prestataire a effectivement confirmé l'envoi.

Structuration de la connaissance de l'intelligence de la ville (pipeline de données)

Objectif : Avec l'appui de l'IA, elle recherche, structure et cure des faits publiquement vérifiables sur des institutions, des lieux, des organisations et des administrations de Pegnitz et les ordonne dans l'intelligence de la connaissance (clusters, nœuds, relations).

Données et sources : Des sources accessibles au public (sites web, registres, indications officielles). Les énoncés factuels doivent être liés à une référence de source vérifiable ; les lacunes ne sont jamais présentées comme vérifiées. Aucune donnée personnelle de personnes privées — les titulaires de charges publiques uniquement dans leur rôle officiel.

Modèle : Essaim headless : opencode-GLM et Codex comme exécutants, pilotés et planifiés par Claude (Opus) en planificateur ; la construction se fait au moment de la construction, pas à chaque affichage de page.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — structure des informations factuelles publiques ; aucune décision sur des personnes, aucun profilage.

Supervision humaine : Devoir de source ; les contenus destinés à la publication passent par le processus de source et d'approbation décrit. La surface respective ou ce registre signale l'appui documenté de l'IA.

Journalisation : Journalisé dans agent_runs / verification_results (interne, accessible uniquement côté serveur — aucun flux public).

Étage de vérification par IA (confrontation des sources)

Objectif : Vérifie les valeurs liées aux sources, remises à une exécution de vérification, contre leurs sources vivantes indiquées. Des valeurs divergentes, des sources inaccessibles, des champs obligatoires vides ou des droits non clarifiés conduisent au rejet et doivent être traités avant une approbation.

Données et sources : Des nœuds et énoncés structurés du pipeline et les URL de sources associées.

Modèle : Claude (Opus) via la CLI Claude Code (connexion par abonnement, aucune clé d'API) comme vérificateur.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — une porte de qualité qui assure la fidélité aux faits ; ne prend aucune décision sur des personnes.

Supervision humaine : L'exécution de vérification soutient le contrôle humain : une valeur rejetée là-bas ne peut pas quitter ce chemin d'approbation comme réussie.

Journalisation : Chaque rejet avec raison et, le cas échéant, URL de source dans verification_results (interne, non public).

Synthèse des clusters et nœuds (textes d'intelligence dans l'intelligence)

Objectif : Génère les textes d'analyse et de recommandation résumants (« intelligence »/synthèse) qui, dans la vue clusters et nœuds de l'intelligence de la connaissance, expliquent une sphère de vie.

Données et sources : Les nœuds et relations du graphe déjà vérifiés et structurés. Les textes sont générés au moment de la construction et stockés dans le graphe ; à l'affichage, la surface calcule uniquement depuis le graphe chargé, sans nouvel appel de modèle.

Modèle : Essaim headless (opencode-GLM / Codex) au moment de la construction.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — synthèse descriptive d'affaires publiques ; aucune décision sur des personnes.

Supervision humaine : Pour une approbation publique, une vérification éditoriale est prévue ; ce registre signale la génération de la synthèse avec appui d'IA.

Journalisation : Génération dans le cadre des exécutions du pipeline (agent_runs, interne).

Généralisation des PII des textes libres d'IA (scrub-pii)

Objectif : Généralise, dans les textes libres d'IA (synthèse, analyses, recommandations), des petites entreprises privées ou gérées par leur propriétaire nommément citées, afin qu'aucune personne physique identifiable n'apparaisse dans les textes publics.

Données et sources : Des textes libres générés par IA issus de la synthèse. Les titulaires de charges publiques dans leur rôle officiel sont conservés (licite selon l'Art. 6, par. 1, let. f) RGPD).

Modèle : Fonction déterministe de règles et regex — AUCUNE IA, aucun modèle de langue. Portée ici par transparence parce qu'elle post-traite des sorties d'IA.

Classe de risque : Pas d'IA au sens de l'EU AI Act (fondée sur des règles) ; mesure de minimisation des données du RGPD — remplacement de texte purement déterministe ; sert la protection des données, ne prend aucune décision.

Supervision humaine : La liste de règles est entretenue éditorialement et étendue à chaque régénération.

Journalisation : Aucune journalisation propre ; partie de l'export du pipeline.

« Pose ta question à la ville » — réponse de connaissance (RAG ancré)

Objectif : Tu poses une question sur la ville et reçois une réponse courte, liée à de vraies sources. La ville fouille d'abord sa propre connaissance de façon purement lexicale (les nœuds vérifiés du graphe), te montre les vrais nœuds trouvés sous forme de cartes, et en formule un bref résumé. Si elle ne trouve rien de solide, elle le dit honnêtement (« La ville ne sait encore rien là-dessus ») — entièrement sans appel de modèle.

Données et sources : Ta question saisie librement (limitée à une longueur courte) et UNIQUEMENT les nœuds déjà vérifiés et fondés sur des sources publiques de l'intelligence de la connaissance (web/.artifacts/graph.json) — aucune base de données externe, aucun accès à Internet pendant la réponse. Le modèle ne reçoit que les extraits de nœuds préalablement récupérés plus ta question et ne peut citer QUE ces nœuds ; toute autre indication de source est rejetée côté serveur (liste blanche des sources). La question n'est pas stockée quant au contenu.

Modèle (avec pays d'hébergement) : Inférence locale UE, auto-hébergée, sur notre propre matériel — gemma4:31b-mlx sur le Mac Studio à Pegnitz (Allemagne), rejoint par un tunnel privé chiffré ; un second point de terminaison local UE (Hetzner, Nuremberg, Allemagne) n'est qu'un HÔTE de repli, pas un MODÈLE de remplacement. Fail-closed (aucun repli GLM/États-Unis pour les contenus citoyens), avec outils désactivés (aucun accès aux fichiers ni au réseau) ; la réponse est diffusée en streaming via SSE. Une réponse est mise en cache brièvement en mémoire de travail (par instance) pour répondre à des questions identiques répétées sans nouvel appel de modèle.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — répond à des questions factuelles depuis une connaissance publique vérifiée ; ne prend aucune décision sur des personnes, aucun profilage, aucun effet juridique.

Supervision humaine : Ancrage par conception : le modèle ne voit que des nœuds déjà vérifiés et ne peut citer que ceux-là — une source inventée ne peut pas franchir la liste blanche. Les cartes de sources affichées se tiennent par elles-mêmes ; si le résumé tombe, elles restent la réponse honnête. Les réponses d'IA sont reconnaissables comme telles.

Journalisation : Aucun stockage du contenu de la question. Limitation de débit par IP anonymisée (hachée) — l'IP brute n'est jamais stockée ni journalisée.

Positionnement de l'entreprise (analyse de site web / dossier) — en préparation

Statut (honnête) : La saisie publique du site web et son API citoyenne sont retenues dans la Core V1. Les chemins internes existants de vérification et de suppression demeurent ; les citoyennes et les citoyens ne peuvent actuellement pas lancer d'analyse. Une activation publique ne suivra qu'après sa propre preuve de sécurité, de protection des données et de navigateur.

Objectif : Une fois active, tu indiques l'adresse web de ton entreprise et confirmes que tu l'exploites ou que tu y es habilité. La ville lit le site web publiquement accessible et en crée un premier positionnement gratuit : un classement concis de la présence plus des recommandations concrètes, fondées sur des preuves. Le résultat naît comme nœud avec le statut moderation:'pending' et n'apparaît publiquement qu'après approbation éditoriale.

Données et sources : Uniquement les contenus publiquement récupérables du site web que tu indiques (nom, description, prestations, titres, indications publiques de contact et sociales, données structurées, extrait de texte). Le scraper vérifie l'adresse cible contre les adresses internes/locales (protection SSRF) et respecte robots.txt. Le texte lu est une DONNÉE à analyser, jamais une instruction au modèle (protection contre l'injection d'invite). Aucune donnée personnelle de personnes privées ; les titulaires de charges publiques uniquement dans leur rôle officiel.

Modèle : Claude (Opus) via la CLI Claude Code (connexion par abonnement, aucune clé d'API), appelé comme processus serveur. Si la CLI n'est pas disponible, une charpente de preuves honnête, construite exclusivement à partir des lacunes reconnues, est renvoyée — jamais une affirmation inventée.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — génère une analyse et des recommandations non contraignantes pour une entreprise ; aucune décision automatisée à effet juridique sur des personnes, aucune appréciation de solvabilité ou d'accès, aucun profilage.

Supervision humaine : Le modèle analyse UNIQUEMENT à partir des preuves présentées et nomme les lacunes au lieu de deviner. Le nœud généré est moderation:'pending' et ne devient public qu'après approbation éditoriale ; seuls des utilisateurs connectés confirmant l'habilitation peuvent déclencher l'analyse. Tu peux faire supprimer la contribution à tout moment (RGPD Art. 17).

Journalisation : Le nœud généré (en attente) est stocké dans la boîte du dossier ; l'exécution en direct n'est pas tenue comme protocole public. Limitation de débit par utilisateur.

Agent mentor personnel (« ton agent »)

Statut (honnête) : Cette V1 est publiée pour des adultes confirmés : tu décris ton rêve, choisis une posture (mentor, partenaire d'entraînement ou « ton CEO »), et un enregistrement d'agent personnel, chiffré côté client, est créé pour toi. Les mineurs et les personnes d'âge indéterminé ne reçoivent aucune réponse de modèle dans cette V1. La conversation protégée est branchée comme fonction du compte : le texte en clair n'est traité dans la mémoire de travail que pour le tour de réponse unique, pas stocké côté serveur, puis chiffré à nouveau côté client. Tu peux mener plusieurs conversations enregistrées : chaque chat porte un titre que tu attribues librement, et ce titre aussi est conservé chiffré côté client. Les conversations plus anciennes peuvent être archivées ; elles restent conservées chiffrées jusqu'à ce que tu les supprimes.

Objectif : L'agent personnel et privé d'une citoyenne ou d'un citoyen (mentor, partenaire d'entraînement ou « ton CEO »). Il doit t'accompagner dans ton propre rêve – comme vis-à-vis d'accompagnement, d'entraînement et de mise en œuvre. Il ne décide rien pour toi ; tu décides, possèdes et signes.

Données et sources : Uniquement tes propres contenus saisis par toi (profil, rêve, historique de conversation, titre de chat). Les CONTENUS reposent chiffrés côté client comme chiffrat AEAD (messages et titres de chat alike) ; la clé est dérivée d'une phrase secrète que tu détiens. L'exploitant ne peut pas lire ces contenus. HONNÊTE et complet : par chat, quelques indications administratives SANS CONTENU sont en outre tenues non chiffrées pour que la liste des chats fonctionne — nombre de messages, moment du dernier message, et si un chat est épinglé ou archivé. Ces métadonnées ne contiennent aucun contenu de conversation et aucun titre. Pour le tour de réponse unique, du texte en clair peut être traité de façon transitoire dans l'environnement côté serveur ; il n'est pas stocké côté serveur. NOUVEAU depuis le 15.08.2026 : avant la réponse, le mentor cherche ton dernier message dans la connaissance vérifiée de la ville — par exactement la même fonction que la pré-planification du rêve, entièrement en processus sur la machine locale UE (lecture de fichier, classement calculatoire, vecteurs locaux), sans appel réseau et sans transmission de ton message à un prestataire. Sont exclus la partie d'auto-description du code source du graphe, les profils de l'équipe et les rêves d'autres personnes ; si la recherche n'arrive pas dans sa courte fenêtre temporelle, l'invite indique explicitement que rien n'a été cherché. Aucun profilage externe, aucun pistage, aucune transmission à des services publicitaires ou de profilage.

Modèle : L'inférence privée du mentor pour adultes tourne exclusivement locale UE et auto-hébergée avec le modèle vérifié pour cette V1, gemma4:e4b, sur le Mac Studio de l'exploitant à Pegnitz (Allemagne), joignable par un tunnel privé chiffré. Il n'y a pour ce mentor aucun nœud de repli ni modèle de remplacement : si le Mac est injoignable, surchargé, ou si une réponse prend plus de 25 secondes, une réponse limitée d'indisponibilité apparaît. Chaque exécution renvoie exactement une réponse JSON tamponnée, n'utilise aucun outil, ne modifie aucun fichier et ne journalise aucun contenu de message. Le client stocke ensuite son propre tour et la réponse ensemble, chiffrés.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — outil personnel d'accompagnement et d'entraînement sans décision automatisée à effet juridique ou comparablement significatif ; aucun profilage, aucune appréciation de l'accès aux services publics.

Supervision humaine : Un humain au volant : l'agent propose et accompagne ; la citoyenne ou le citoyen décide et possède le résultat. La V1 actuelle refuse aux mineurs et aux personnes d'âge indéterminé l'appel de modèle même lorsqu'un consentement est déjà déposé. Une version enfant ultérieure exigera sa propre évaluation de modèle, sa propre protection de sortie et la validation de la protection de l'enfance. La reconnaissance de détresse tourne de façon déterministe avant chaque inférence et une nouvelle fois côté serveur sur tous les tours de conversation : devant des signaux d'automutilation, d'abus ou de danger, l'appel de modèle s'arrête, aucune réponse n'est générée et de vraies voies d'aide apparaissent. pegnitz.city n'est pas un service d'urgence ; en besoin aigu, tu te tournes directement vers l'aide réelle : téléphone d'écoute 0800 111 0 111 ou 0800 111 0 222 (gratuit, anonyme, jour et nuit), numéro contre l'angoisse 116 111 (gratuit, anonyme, lun–sam 14:00–20:00), pompiers et ambulance 112 ou police 110 (tous deux gratuits, jour et nuit).

L'unique porte de ton mentor vers l'équipe (nouveau depuis le 15.08.2026) : Ton mentor peut désormais faire deux choses — et seulement deux. D'ABORD DEMANDER : il répond à la question de ce que la ville a réellement fait de ton rêve, exclusivement à partir de TES PROPres lignes que tu peux relire toi-même dans ton compte ; la phrase est assemblée à partir de lignes comptées, aucun modèle ne la formule, et s'il n'y a rien, il le dit exactement. ENSUITE DEMANDER UN SERVICE : tu peux adresser un souhait à l'équipe — il est stocké comme PROPOSITION qui, sans ton approbation explicite, n'est présentée à personne et ne déclenche aucun travail de l'équipe. Ce qui quitte cette porte est étroitement limité : un sigle pseudonyme de ton rêve (une valeur de hach dérivée, jamais ton identifiant de compte) et la version courte publique déjà nettoyée, plus ton texte de demande, d'abord nettoyé des données de contact PUIS vérifié une nouvelle fois pour savoir s'il reste quelque chose de personnel. S'il reste quelque chose, la demande NE sort PAS et on te le dit. Quiconque a verrouillé son rêve anonymement n'a pas un tel sigle — alors rien ne sort du tout, et le demander fonctionne quand même. Le mentor lui-même ne reçoit aucun outil en main pour cela : l'inférence continue de n'avoir aucun accès aux outils.

Journalisation : Aucune journalisation de contenu par l'exploitant – les contenus stockés sont chiffrés et illisibles pour l'exploitant ; l'inférence en direct ne journalise aucun contenu de message. Archiver vs. supprimer : archiver masque seulement un chat de la liste active, l'historique chiffré demeure. Droit à l'effacement (RGPD Art. 17) : seule la suppression de tes clés et chiffrats rend les contenus irrécupérables – cela continue de fonctionner inchangé aussi pour les chats archivés.

Rappels du mentor sur tes propres prochaines étapes — envoi de courriel retenu

Statut (honnête) : Les rappels sont ÉTEINTS par défaut et ne naissent que lorsque tu les actives toi-même. Dans l'app, tu les vois dans ton compte. L'envoi par COURRIEL reste retenu — verrouillé triplement : d'abord, l'envoi est désactivé dans la configuration d'exploitation et le domaine d'expéditeur n'est pas validé ; ensuite, l'étape de confirmation (double opt-in par courriel) n'est pas encore construite — un consentement ne peut donc pas du tout être confirmé et ainsi devenir envoyable ; troisièmement, le contrôle avant chaque envoi exige un consentement confirmé et actuel et se ferme en refus sans lui. Depuis le 17.08.2026, ce consentement selon l'Art. 7 RGPD est stockable dans la base de données — versionné, identique au mot près, avec révocation séparée qui vaut à tout moment dans tes réglages et prime sur toute confirmation antérieure. Le lieu de stockage existe donc ; mais sans l'étape de confirmation construite, tout consentement reste dans l'état « non confirmé », et c'est exactement là que chaque tentative d'envoi échoue. Tant qu'il en est ainsi, aucun courriel de rappel ne part. Nous ne signalerons une activation ici que lorsqu'elle aura réellement eu lieu.

Objectif : Te rappeler UNE étape que tu t'es toi-même fixée — non pas te tirer vers l'app. Pas d'étape, pas de rappel : nous préférons le silence à une occasion fabriquée.

Données et sources : Tes propres réglages (activé/désactivé, heures de repos, fuseau horaire), le titre de ta propre tâche mentor ouverte et — seulement au moment d'un envoi réel — ton adresse de courriel de compte confirmée. La file elle-même ne stocke ni ton adresse de courriel, ni un courriel privé déjà mis en forme, ni ton rêve brut. Aucune source de données externe, aucun profilage, aucune publicité.

Modèle (avec pays d'hébergement) : Pour le rappel lui-même, AUCUN modèle d'IA n'est appelé : la sélection et le texte sont un gabarit fixe, fondé sur des règles, tournant sur notre propre infrastructure en Allemagne. L'étape nommée provient de ton propre plan mentor précédemment généré en local UE. Par transparence, ce point figure quand même ici, parce qu'il livre une sortie d'IA. S'il y avait envoi, le service de livraison serait un prestataire de courriel (Resend, UE/États-Unis, certifié DPF, DPA disponible) — ce point est signalé ici avant qu'il ne devienne actif, pas après.

Classe de risque : Pas d'IA au sens de l'EU AI Act (livraison fondée sur des règles). En droit de la protection des données, une communication directe sur la base de ton consentement (Art. 6, par. 1, let. a), Art. 7 RGPD).

Contrôle humain : Tu décides triplement : les rappels sont éteints jusqu'à ce que tu les actives ; un courriel exige en outre un consentement propre, donné explicitement pour ce but selon la procédure de double opt-in, séparé du consentement à la lettre d'information ; et tu peux le révoquer séparément à tout moment — via le lien de désinscription en un clic ou dans tes réglages. Une preuve manquante, révoquée et non confirmée conduisent toutes au même résultat : rien n'est envoyé.

Journalisation : Pour chaque tentative de livraison, une ligne privée avec statut et raison est tenue (par exemple : en file, ou sautée faute de consentement), afin qu'aucun rappel double ne naisse. Une ligne ne compte comme envoyée qu'une fois que le prestataire a effectivement confirmé l'envoi — un rappel en attente n'est jamais affiché comme envoyé. Désinscriptions, rebonds et réclamations sont tenus comme données privées de blocage.

Voix de l'équipe (comptes rendus de travail parlés en direct des agents)

Statut (honnête) — identité du porte-parole : Le nom que tu lis et entends sur une ligne parlée est l'auto-déclaration de l'exécution d'agent respective. La plateforme consigne pour chaque ligne si cette identité a pu être prouvée techniquement — et pour les lignes diffusées publiquement, ce marqueur vaut actuellement « non prouvée ». Nous te disons donc QUEL NOM a déposé le message — non que cette identité est démontrée. Si une ligne non prouvée revendique un rôle de direction (p. ex. CEO ou protection de l'enfance), elle est expressément marquée comme non prouvée dans la vue de l'équipe ; pour tous les autres rôles, aucune telle mention n'apparaît pour l'instant. Une preuve du locuteur vérifiable par machine est en préparation ; dès qu'elle portera réellement les lignes publiques, cela sera signalé ici.

Objectif : Sur la page d'accueil et dans la vue de l'équipe, tu peux activer les voix de l'équipe : une vraie pulsation de travail d'un agent (début/achèvement d'une tâche) peut devenir audible comme bref message de statut parlé, formulé librement — sous quel nom le message a été déposé, sur quoi on travaille, pourquoi cela sert la ville et qui reprend ensuite. Toute pulsation ne devient pas audible : les lignes qui ne passent pas la protection décrite ci-dessous restent muettes. Le flux écrit reste allemand ; la ligne parlée est en anglais.

Données et sources : UNIQUEMENT des faits d'exploitation internes déposés dans le dépôt : l'identité rédigée de l'agent (nom, rôle, caractère), le compte rendu de travail réel de l'équipe et les faits de l'opération associée enregistrés au conseil. Aucune donnée citoyenne, aucune donnée personnelle — un compte rendu de travail contenant une adresse de courriel ou un numéro de téléphone ne produit AUCUNE ligne parlée (fail-closed).

Modèle : La ligne parlée est rédigée par la session d'agent qui l'exécute — aucun modèle ne la compose (par ligne, model = NULL et speechAuthor = 'agent' est consigné). Cette session tourne chez le prestataire chez qui le travail respectif tourne ; pour les voies de code du Plan A, c'est hors de l'UE (p. ex. Z.AI/Chine, Anthropic/États-Unis, OpenAI/États-Unis). Dans ces invites n'entre aucune donnée citoyenne ni personnelle — le transfert sortant est l'invite de code sans PII (déjà enregistrée comme Plan A), la ligne de voix est une sortie qui reflue vers l'UE. La sortie vocale elle-même se fait par des moteurs TTS auto-hébergés (Piper/Qwen) sur notre propre infrastructure.

Protection (ancrage, fail-closed) : Chaque ligne composée passe par un contrôleur déterministe : formules de refus, chiffres non prouvés, personnes ou autorités inventées (p. ex. un accord du conseil jamais donné), codes d'opération manquants et affirmations de réussite ou d'approbation non prouvées conduisent au rejet de la ligne — la pulsation reste alors muette dans le flux écrit. Le compte rendu de travail est remis au modèle structurellement comme DONNÉE, jamais comme instruction (protection contre l'injection d'invite).

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — voix synthétique sur le propre travail de l'équipe d'agents ; aucune décision sur des personnes, aucun profilage. La sortie vocale est étiquetée IA dans la surface (interrupteur « voix IA activées/coupées ») et n'est active que si tu l'actives toi-même.

Journalisation : Chaque ligne parlée naît d'une ligne publiquement visible dans le flux en direct de la vue de l'équipe (table warroom_live_activity ; le plus ancien flux agent_activity ne porte plus ces lignes) — ce qui est parlé est aussi lisible et traçable. Pour chaque ligne, il est en outre consigné en interne si l'identité du locuteur a pu être prouvée techniquement ; ce marqueur est le fondement de la limitation honnête signalée ci-dessus.

Ziggy-Kosmos — compagnon d'apprentissage pour enfants (page publique vitrine)

Statut (honnête) : Publiquement accessible est la page vitrine avec visites guidées et une fonction de lecture à voix haute — des textes fixes, entretenus éditorialement, qui expliquent le système d'apprentissage planifié. Le système d'apprentissage lui-même (compte, exercices, conversations de mentor, vérification de dessin) n'est PAS publié : c'est un pilot guidé derrière connexion et validations propres. Avant que des enfants puissent l'utiliser, sont exigées une propre vérification de la connaissance quant à l'adéquation à l'âge (JMStV), la validation de la protection de l'enfance et l'évaluation contraignante du modèle enfant — jusque-là, cette partie reste retenue.

Objectif : La page présente Ziggy-Kosmos : un compagnon d'apprentissage privé qui propose aux enfants des exercices selon le LehrplanPLUS bavarois, les accompagne de façon socratique (l'IA ne donne jamais simplement la solution) et, à la demande d'un enseignant, génère des scènes 3D sur des thèmes d'apprentissage. Sur la page publique elle-même, aucun apprentissage n'a lieu — elle explique seulement.

Données et sources : Sur la page publique, la plateforme ne traite AUCUNE donnée citoyenne : la fonction de lecture à voix haute prononce exclusivement des textes fixes de diapositives issus d'un catalogue fermé que tu peux choisir diapositive par diapositive — le texte libre n'est pas accepté et ne peut jamais atteindre la voix. Pour la défense contre les abus ne sert qu'une adresse IP anonymisée (hachée) pour la limitation de débit. Le système d'apprentissage (non public) traite des progrès et conversations d'apprentissage d'enfants exclusivement avec le consentement de leurs représentants légaux (Art. 8 RGPD), chiffré et local UE — cette partie n'est pas active.

Modèle (avec pays d'hébergement) : La lecture à voix haute est une voix synthétique : sortie vocale Piper auto-hébergée (voix allemande) sur le matériel propre de la XBANQ® GmbH en Allemagne — aucun service externe, aucune transmission vers des pays tiers. Le système d'apprentissage (non public) calcule avec des modèles auto-hébergés, locaux UE, sur Ollama (mentor : gemma4 ; vérification de dessin : qwen3-vl) — ancré fixe pour les voies enfants sans modèle de repli (fail-closed).

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — voix synthétique et présentation explicative ; aucune décision sur des personnes. Le système d'apprentissage est classé à risque limité à la condition contraignante que les niveaux d'apprentissage restent privés et ne soient jamais utilisés comme appréciation scolaire officielle ; une situation à haut risque (appréciation officielle ou accès) bloquerait toute mise en service.

Supervision humaine : La page publique consiste en contenus fixes, entretenus éditorialement. Dans le système d'apprentissage vaut : enseignant, représentants légaux et l'enfant dirigent ; l'IA n'apprécie pas officiellement, ne décide rien et ne remplace aucune école. pegnitz.city est et reste autre chose qu'une offre officielle de la ville de Pegnitz.

Journalisation : Aucun stockage de contenu sur la page publique ; limitation de débit par IP anonymisée (hachée) — l'IP brute n'est jamais stockée. Le système d'apprentissage journalise en interne, lié au compte, et n'est pas publiquement actif.

Médiathèque de la ville : analyse de médias par IA (image, son, recherche) — en préparation

Statut (honnête) : Le téléversement public, la recherche publique et la vue publique de médias sont retenus dans la V1. Les preuves de propriété et révocations existantes ainsi que les voies séparées de révision, d'administration et d'analyse demeurent. L'analyse IA locale UE travaille en fail-closed : sans modèle local joignable, aucune analyse automatique ne naît, le signal de personne reste « inconnu » et il n'y a aucune publication automatique. Une activation publique ne sera signalée ici qu'après sa propre preuve de validation.

Objectif : Une fois active, l'IA soutient la vérification humaine des médias téléversés : une IA d'image décrit et étiquette un média et estime si des personnes ou des présomptifs mineurs sont visibles (prétri de protection de la jeunesse) ; les pistes audio sont transcrites localement ; pour la recherche de médias, des vecteurs locaux sont calculés.

Données et sources : Uniquement les médias que tu téléverses et tes propres indications (titre, catégorie, classement des personnes). Aucune base de données externe, aucune confrontation avec des fichiers de personnes tierces, aucune reconnaissance biométrique.

Modèle : Inférence locale UE, auto-hébergée, sur notre propre matériel en Allemagne — IA d'image : exclusivement l'IA d'image épinglée et prouvée par preuve de capacité (OLLAMA_KIDS_MODEL, actuellement gemma4:e4b sur le Mac Studio à Pegnitz (Allemagne)) ; les recouvrements de vision adulte ou générique sont délibérément ignorés, sans épingle aucune analyse ne tourne (fail-closed). Transcription whisper.cpp, vecteurs de recherche Xenova multilingual-e5-small ; aucune transmission vers un pays tiers.

Classe de risque : Selon notre auto-évaluation actuelle : risque limité / obligation de transparence (Art. 50) — description et prétri préparatoires ; aucune décision automatisée à effet juridique sur des personnes. Le prétri des mineurs sert la protection de la jeunesse et peut toucher des catégories particulières (Art. 9 RGPD) ; il ne décide rien, mais soumet chaque cas douteux à une personne.

Supervision humaine : Un humain au volant et fail-closed : rien ne devient visible ou utilisé avant qu'une personne l'ait validé. Si l'indication de la personne qui téléverse diverge d'un signal d'IA, ou que l'analyse IA est indisponible, une personne vérifie nécessairement. Les médias avec des mineurs reconnaissables restent verrouillés sans consentement documenté de leurs représentants légaux.

Journalisation : Les résultats d'analyse (description, transcription, signal de personne, modèle) sont stockés par média en interne (media_vault_analysis, accessible uniquement côté serveur par la sécurité au niveau des lignes). Lors de la révocation ou de la suppression, l'analyse, la transcription et le vecteur de recherche sont emportés avec eux.

Kein Training mit Stadtdaten — Attestierung je Modell

Für jedes Modell, das diese Instanz nutzen kann, ist unten attestiert, warum seine Ausgaben nicht in das Training oder Fine-Tuning allgemeiner Modelle fliessen: vertraglich zugesichert und nachgewiesen im Auftragsverarbeitungsvertrag, oder technisch ausgeschlossen, weil das Modell selbst betrieben wird und keine Verbindung zu einem Anbieter besteht. Der Stand der Prüfung ist je Eintrag datiert.

Contrôle humain et journalisation

Le contrôle humain et la journalisation diffèrent selon la voie de validation. Dans le pipeline de données, les valeurs liées aux sources remises à une exécution sont vérifiées ; une valeur rejetée là-bas doit être traitée avant la validation. Les visions citoyennes sont stockées comme origin:'citizen', moderation:'pending' et n'apparaissent dans l'intelligence de la connaissance publique qu'après une approbation éditoriale explicite. Les surfaces principales documentées signalent leur appui d'IA sur le résultat ou dans ce registre. Les exécutions du pipeline sont journalisées en interne dans agent_runs et verification_results, entre autres avec statut, résultat de vérification, motif de rejet et, le cas échéant, URL de source. Ces protocoles ne sont pas un flux public en temps réel ; une visionneuse publique d'audit en direct n'existe pas actuellement. Le devoir de source reste une exigence de qualité contraignante, non l'affirmation que chaque nœud historique serait déjà prouvé sans lacune. Les médias aux droits non clarifiés ne sont pas publiés publiquement.

En préparation

• Visionneuse d'audit et de protocole publiquement consultable : les protocoles (agent_runs, verification_results) existent déjà, mais ne sont aujourd'hui accessibles que côté serveur (service_role). Un espace d'audit publiquement consultable n'est pas encore réalisé – dès qu'il arrive, il sera signalé ici de façon transparente.
• Flux éditorial de validation pour les visions citoyennes : les contributions sont déjà tenues comme moderation:'pending' ; le processus de validation est réalisé en principe, une interface confortable de modération est en préparation.
• Médiathèque de la ville – analyse de médias par IA : la réception publique et la recherche publique restent closes dans la V1. Les voies internes d'analyse et de vérification ne seront activées publiquement qu'après leur propre preuve de validation.
• Preuve du locuteur vérifiable par machine pour la voix de l'équipe : tant qu'elle ne porte pas les lignes diffusées publiquement, le nom d'agent affiché est une auto-déclaration de l'exécution respective et non une preuve. L'état figure honnêtement en haut de la section « Voix de l'équipe » et sera changé ici dès que la preuve prendra réellement effet.
• Courriels de rappel du mentor : la voie d'envoi est construite et vérifiée, mais retenue. Le consentement selon l'Art. 7 RGPD est stockable et révocable séparément depuis le 17.08.2026 ; l'étape de confirmation par courriel (double opt-in) est la partie encore manquante, et sans elle le contrôle refuse tout envoi. Nous ne changerons ce paragraphe que lorsque l'étape de confirmation sera construite et le premier envoi réellement validé.
• D'autres fonctions d'IA seront ajoutées ici dès qu'elles seront réellement publiées ; les fonctions retenues restent jusque-là expressément marquées « en préparation ».