So werden Ihre Daten verarbeitet.

Lokales Python kann sortieren, berechnen, abstimmen, filtern, aggregieren und Ergebnisse erstellen. Ein Workflow kann dies vor einem Modellschritt nutzen, wenn es die Arbeit verbessert.

Die Plugins anonymisieren oder pseudonymisieren Daten nicht automatisch. Namen, Dokumente, Originalformulierungen und Fallfakten bleiben erhalten, wenn sie dem beruflichen Zweck dienen.

Jeder Workflow kann Daten anders nutzen. Seine eigene Seite erklärt den Ablauf: was das Modell sieht, was der Code verarbeitet und wann der Prozess stoppt. Diese Seite dupliziert diese spezifischen Aussagen nicht.

Geben Sie niemals Passwörter, API-Schlüssel, Authentifizierungs-Cookies, Zugriffstoken oder Sitzungsdaten in Prompts oder Dateien ein, die die gewählte KI-Arbeitsumgebung lesen kann.

Nach jeder substanziellen Vera-Ausführung dokumentiert ein kompakter Bericht jede für das Modell sichtbare Phase in den natürlichen Einheiten des Workflows. Er unterscheidet den verfügbaren Quellumfang, die lokale Codeverarbeitung, die für das Modell sichtbaren Daten, den Teil, der für das Modell nie sichtbar war, den Zweck des Kontexts und die verfügbare Nachweisgrundlage. Kann die Umgebung Dateien schreiben, speichert Vera einen JSON-Bericht und eine Markdown-Version im Ergebnis dieser Ausführung; andernfalls zeigt sie den Bericht im Chat und erklärt, dass kein dauerhafter Bericht erstellt wurde. Der lokal verarbeitete Gesamtumfang und der für das Modell nie sichtbare Teil überlappen; sie sind keine alternativen Kategorien, die addiert werden dürfen.

Ein möglicher engerer Codepfad erscheint nur, wenn die Nachweise der Ausführung ihn stützen und eine Sicherung der analytischen Qualität nennen. Ein vollständiges relevantes Dokument oder eine vollständige Grundgesamtheit kann das richtige Minimum sein. Der Bericht ist keine Netzwerküberwachung, Provider-Bestätigung, Datenschutz-Folgenabschätzung, Rechtsauskunft oder DSGVO-Zertifizierung; ein gespeicherter Hash bindet einen Beleg an Bytes, beweist aber keine Übermittlung auf Providerseite.

Der Vera-Befehl zur Erstellung eines Berichts mit Beleg sendet automatisch vier Felder an Mparanza: Schemaversion, zufällige Beleg-ID, Vera-Version und SHA-256-Hash des lokalen Berichts. Mparanza ergänzt Serverzeit und Ed25519-Signatur und speichert nur diese Nachweisfelder, nicht den Bericht, Mandantendaten, Dateinamen, Inhalte oder Hashes der Quelldokumente. Der HTML-Beleg kann an den Mandanten gesendet, als PDF gespeichert und öffentlich geprüft werden. Er belegt nur Existenz, Serverzeit und Berichtsintegrität und weist den Absender des Hashes nicht unabhängig nach. Ist der Dienst nicht verfügbar, bleiben die Arbeit und der lokale Bericht abgeschlossen und die Anfrage für einen erneuten Versuch ausstehend.

Das Lesen eines bestehenden Berichts, der allgemeine lokale Berichtsgenerator von Studio Archive und die ausdrücklich lokale Einführung fordern keinen Serverbeleg an. Der Belegdienst läuft in Finnland, EU, und speichert den signierten Nachweis ohne automatischen Ablauf. IP-Adressen werden nicht in der Belegdatenbank gespeichert: Sie dienen zur Begrenzung übermäßiger Anfragen und werden separat in Zugriffsprotokollen erfasst. Nginx bewahrt 14 tägliche Archive und die aktuelle Datei auf; für das Uvicorn-Protokoll wurde keine feste Höchstdauer ermittelt. Das Betriebsskript überschreibt es beim Neustart. Noch umzusetzen: eine Aufbewahrungsfrist von 14 Tagen mit automatischer Löschung der technischen Protokolle. Signierte Belege sind von dieser Löschung ausgenommen.

Der SHA-256-Hash ist ein lokal aus dem Bericht berechneter Fingerabdruck aus 64 Zeichen, keine verschlüsselte Kopie: Es gibt keinen Entschlüsselungsvorgang, der den Inhalt wiederherstellt. Wer den Bericht besitzt, kann seinen Hash lokal neu berechnen und mit dem signierten Nachweis vergleichen, ohne den Bericht an Mparanza zu senden. Mparanza erhält weder Kundennamen noch eine Zuordnung zwischen Hashes und Personen. Die Vertraulichkeit wird dadurch geschützt, dass die Anfrage keine Dokumentinhalte enthält; die automatische Übermittlung erstellt den technischen Beleg.

Eine verbundene App, öffentliche Suche, ein Portal oder eine Sendefunktion wird nur genutzt, wenn dieser Weg Teil der gewählten Arbeit ist. Bedingungen und Kontrollen des Ziels gelten separat.

Die Nutzung eines externen Ziels macht Mparanza nicht zum Empfänger. Der Workflow oder der Hinweis am Nutzungsort kennzeichnet einen von Mparanza gehosteten Weg, wenn er beteiligt ist.

Wenn eine Funktion einen Mparanza-gehosteten Dienst nutzt, erreichen die erforderlichen Inhalte von Mparanza kontrollierte Systeme. Gehostete Interviews, Spracherfassung und Retail-Daten sind Beispiele.

Der Hinweis dort, wo der Dienst genutzt wird, nennt die übermittelten Inhalte und die geltenden Zugriffs-, Aufbewahrungs- und Löschregeln.