FAQ

Oui, et ce indépendamment de piighost. Les enjeux (exfiltration vers les providers, réquisition légale, entraînement sur les conversations, conformité RGPD, fuites de données) sont détaillés dans Pourquoi dé-identifier ?. La page est agnostique à la librairie. Elle explique pourquoi le problème existe avant de justifier une solution comme piighost.

Cela dépend entièrement du détecteur que vous branchez. Le pipeline lui-même est agnostique à la langue. Avec un détecteur gliner2 et un modèle GLiNER2 multilingue, vous obtenez environ 100 langues d'office. Avec un détecteur spacy, tout ce que spaCy supporte. Avec un détecteur regex, la langue n'a pas d'importance. Voir Étendre piighost pour le catalogue de détecteurs.

Aucune. piighost ne livre pas son propre modèle NER, c'est un choix volontaire. Vous apportez le détecteur. Utilisez un détecteur exact pour des dictionnaires fixes, un détecteur regex avec un groupe tiré du catalogue (catalog:piighost/generic, catalog:piighost/us, catalog:piighost/eu, catalog:piighost/fr) ou vos propres motifs, un détecteur gliner2 pour du NER ouvert (PERSON, LOCATION, ORGANIZATION, EMAIL, n'importe quel label que vous lui demandez), ou composez-les avec un détecteur composite.

Non, par conception. Un validateur de checksum rejette une valeur dont les chiffres ne calculent pas. Or c'est exactement ce que produit du bruit d'OCR ou une faute de frappe. Rejeter cette valeur ferait fuiter la PII que le validateur était censé attraper. Le détecteur regex matche sur la forme seule et penche vers la sur-détection, la direction sûre pour la dé-identification. Si vous devez resserrer un match, ajoutez un motif plus strict plutôt qu'un validateur.

Écrivez un fichier TOML ou JSON décrivant chaque étage, puis chargez-le. load_pipeline construit un pipeline sans état. load_thread_pipeline construit un pipeline de conversation avec une mémoire de conversation. Le suffixe du fichier choisit le parser. Chaque section et chaque type de composant sont dans la référence de configuration. L'extra config est requis (pip install "piighost[config]").

Le pipeline lui-même est de l'ordre de la milliseconde (regex et lookups). Le vrai coût vient du détecteur. GLiNER2 sur CPU pour un message de 200 tokens, c'est typiquement 50 à 200 ms. Un LLM utilisé comme détecteur, plusieurs centaines de millisecondes. Renvoyer un message dans une conversation évite la détection, parce qu'un pipeline de conversation garde en cache les détections de chaque message. Une mesure sur votre charge réelle reste recommandée avant de dimensionner la production.

Oui. Avec un détecteur local (gliner2, spacy, regex, exact), aucune donnée ne quitte votre processus. Un groupe du catalogue épinglé sur un commit est récupéré à la première construction, puis relu depuis le cache sur disque, et cette récupération n'envoie aucun texte au catalogue. Le middleware ne transmet au LLM que du texte déjà dé-identifié. Garder un LLM hébergé sous contraintes RGPD sans exfiltrer de PII brutes est la raison principale de l'adoption de piighost. Voir Pourquoi dé-identifier ? pour le contexte juridique.

Non. Le format est piloté par la placeholder factory choisie dans [anonymizer.placeholder]. label_counter produit <<PERSON:1>>, label_hash produit <<PERSON:a1b2c3d4>>, label produit <<PERSON>> sans compteur, mask produit P***, et vous pouvez écrire votre propre factory. Voir Fabriques de placeholders.

Non, et ce n'est pas prévu. Une factory Faker, qui émettrait un nom plausible à la place de Patrick, est écartée à dessein dans la roadmap. Deux personnes pourraient tirer le même faux nom, et un faux pourrait coïncider avec une vraie valeur, donc la restauration ne serait plus fiable. Aujourd'hui les factories émettent des jetons synthétiques ou des masques, jamais une valeur qui ressemble à du vrai.

Cela dépend de la stratégie d'appel outil. Avec la valeur par défaut (FULL), non. Le middleware restaure les arguments juste avant l'exécution de l'outil, puis dé-identifie à nouveau la réponse avant qu'elle ne retourne au LLM. L'outil voit les vraies valeurs, le LLM ne voit que les placeholders. Les modes INPUT, OUTPUT et PASSTHROUGH modifient ce comportement, voir la question suivante et Stratégies d'appel outil. Diagramme complet dans Architecture.

La stratégie d'appel outil de PIIAnonymizationMiddleware expose quatre modes (INPUT, OUTPUT, FULL, PASSTHROUGH). Le bon choix dépend de la possibilité que l'outil émette de nouvelles données confidentielles et du niveau de cloisonnement souhaité. Voir Stratégies d'appel outil pour les compromis et l'arbre de décision. Le middleware exige aussi une factory qui préserve l'identité et reste reconnaissable, voir Fabriques de placeholders pour cette contrainte.

Elle n'est pas dé-identifiée par piighost. Le linking d'entités travaille sur les détections issues de l'entrée, pas sur des valeurs inventées. Un guard de données confidentielles résiduelles peut re-vérifier la sortie et la refuser, voir la section guard de la référence de configuration et Limites.

Non. La mémoire est scopée par thread_id. Deux conversations parallèles ne voient pas les jetons l'une de l'autre. Ce cloisonnement évite les fuites latérales entre utilisateurs. Le thread_id est extrait automatiquement de la config LangGraph.

Utilisez la mémoire de conversation Redis, partagée par tous les workers. La mémoire en RAM est locale au processus, donc deux workers numéroteraient la même valeur différemment en pleine conversation. Voir Déploiement multi-instance pour le piège et la parade, et Déploiement pour la mise en place complète.

Oui. Les pipelines sans état et de conversation sont utilisables seuls, sans middleware. Voir Comment dé-identifier un texte et le restaurer.

La mémoire de conversation Redis, oui. Elle chiffre chaque valeur stockée en AES-GCM et hache chaque clé, en lisant son pepper et sa clé de cipher dans l'environnement. La mémoire en RAM ne chiffre rien et sert au développement seulement. Voir Sécurité pour le modèle de menace au repos.

Via OpenTelemetry. Le pipeline émet un span par étage vers le TracerProvider OTel que votre application a configuré. Il ne fait lui-même aucune corrélation de backend, parce que cette corrélation relève de la configuration OTel du déploiement. Voir Observation. L'extra observation est requis.