Du musst FlameP nicht vertrauen. Du musst es prüfen können.

1. Das eigentliche Problem ist die Asymmetrie

Ein digitales System weiß heute unter Umständen sehr viel über seinen Nutzer.

Der Nutzer weiß erstaunlich wenig über das System.

Er sieht eine Oberfläche. Er sieht eine Antwort. Vielleicht sieht er noch den Namen eines Modells.

Darunter können zahlreiche technische Vorgänge stattfinden. Informationen werden ausgewählt, ergänzt, gespeichert, an externe Systeme geschickt, dort verarbeitet und anschließend wieder zusammengesetzt. Ein anderes Modell kann die erste Antwort prüfen. Eine Suchmaschine kann Quellen liefern. Ein Sicherheitssystem kann Inhalte klassifizieren. Persönlicher Kontext kann hinzugefügt worden sein, den der Nutzer in dieser konkreten Unterhaltung gar nicht eingegeben hat.

Das Problem beginnt dort, wo der Mensch nur noch das Endergebnis sieht und keine vernünftige Möglichkeit mehr hat zu verstehen, wie es zustande gekommen ist.

Selbst für die Betreiber solcher Systeme ist vollständige Übersicht keineswegs selbstverständlich. Das amerikanische National Institute of Standards and Technology weist in seinem AI Risk Management Framework ausdrücklich darauf hin, dass KI-Systeme aus vielen voneinander abhängigen Komponenten und Akteuren bestehen können. Die Verantwortlichen für einen Teil des Systems haben deshalb häufig weder vollständige Sicht auf noch vollständige Kontrolle über andere Teile. NIST empfiehlt unter anderem dokumentierte Verantwortlichkeiten, kontinuierliches Risikomanagement, die Überwachung eingesetzter Drittsysteme und nachvollziehbare Entscheidungen über den gesamten Lebenszyklus. [1]

Wenn schon die Organisation, die eine KI-Anwendung baut, aktiv dafür sorgen muss, ihre eigene technische Lieferkette zu verstehen, ist es ja geradezu absurd, vom Nutzer einfach Vertrauen zu verlangen.

2. Transparenz ist noch kein Beweis

Unternehmen und auch FlameP reagieren darauf gern mit Transparenz.

Wir erklären, welche Provider wir verwenden.

Wir veröffentlichen eine Datenschutzerklärung.

Wir beschreiben unsere Sicherheitsmaßnahmen.

Das ist notwendig, aber nicht ausreichend.

Eine Information darüber, was theoretisch geschehen soll, ist etwas anderes als ein Nachweis darüber, was in einem konkreten Fall tatsächlich geschehen ist.

Ein einfaches Beispiel:

Eine Plattform kann schreiben, dass sie personenbezogene Daten nach einem bestimmten Zeitraum löscht.

Das ist eine Regel.

Ein Nachweis wäre etwas anderes. Er müsste zeigen können, dass für einen konkreten Datensatz die entsprechende Löschregel tatsächlich ausgeführt wurde.

Dasselbe gilt für KI.

LeitgedankeWir verwenden nur den für deine Aufgabe notwendigen Kontext.

Das ist ein Versprechen.

LeitgedankeFür diese konkrete Aufgabe wurden die Informationsbereiche A und B verwendet, Bereich C blieb ausgeschlossen.

Das ist überprüfbarer.

LeitgedankeWir arbeiten mit mehreren KI-Anbietern und wählen das geeignete Modell.

Das ist eine Produktbeschreibung.

LeitgedankeDiese Aufgabe wurde am 10. August mit Modell X bei Provider Y verarbeitet, weil sie in diese Aufgabenklasse fiel.

Das ist ein Beleg für einen konkreten Vorgang.

Genau diese Unterscheidung interessiert uns.

Auch das Datenschutzrecht kennt sie. Das Prinzip der Rechenschaftspflicht der DSGVO verlangt nicht nur die Einhaltung der Datenschutzgrundsätze. Verantwortliche müssen ihre Einhaltung auch nachweisen können. Der Europäische Datenschutzausschuss beschreibt ausdrücklich, dass dies in der Praxis unter anderem bedeutet, Datenschutzentscheidungen und Prozesse zu dokumentieren. [2] [3]

Das ist eine andere Haltung als „Vertrau uns, wir machen das ordentlich“.

Sie lautet: Wenn eine Aussage relevant ist, müssen wir in der Lage sein, Evidenz dafür vorzulegen.

3. Die Regulierung bewegt sich bereits in diese Richtung

Der europäische AI Act greift diesen Gedanken für bestimmte KI-Systeme ebenfalls auf.

Für Hochrisiko-KI-Systeme verlangt die Verordnung unter anderem technische Möglichkeiten zur automatischen Protokollierung von Ereignissen. Außerdem müssen solche Systeme so transparent gestaltet sein, dass Betreiber ihre Ausgaben angemessen interpretieren und verwenden können. Informationen zu Fähigkeiten, Leistungsgrenzen, zum vorgesehenen Einsatz und gegebenenfalls zu Mechanismen für die Auswertung von Protokollen gehören ebenfalls zu den Anforderungen. Für Hochrisikosysteme verlangt der AI Act außerdem geeignete Möglichkeiten menschlicher Aufsicht. [4]

Wir sollten daraus nicht den falschen Schluss ziehen, jedes KI-Produkt unterliege denselben Pflichten. Das tut es nicht. Der AI Act arbeitet bewusst mit unterschiedlichen Risikokategorien und unterschiedlichen Anforderungen.

Interessanter als die juristische Einstufung finden wir deshalb das Prinzip dahinter.

Ein technisch komplexes System wird nicht vertrauenswürdiger, weil sein Hersteller versichert, dass es vertrauenswürdig sei.

Vertrauenswürdigkeit braucht Strukturen, Dokumentation, Protokollierung, Verantwortlichkeiten, Möglichkeiten zur Kontrolle, bekannte Grenzen.

Und die Fähigkeit, Fehler später rekonstruieren zu können.

Das NIST AI Risk Management Framework behandelt genau diese Punkte als Teil einer kontinuierlichen Governance. Dokumentation soll Transparenz verbessern, menschliche Überprüfung unterstützen und Verantwortlichkeit stärken. Das Rahmenwerk fordert außerdem, Rollen, Risiken, externe Komponenten, menschliche Aufsicht und Systemgrenzen zu dokumentieren und regelmäßig zu überprüfen. [1]

Die OECD geht inzwischen noch einen Schritt weiter. Ihre 2026 veröffentlichte Due Diligence Guidance for Responsible AI verbindet klassische unternehmerische Sorgfaltspflichten mit KI-Governance. Unternehmen sollen Risiken und mögliche negative Auswirkungen identifizieren, Maßnahmen umsetzen, deren Ergebnisse verfolgen, darüber kommunizieren und gegebenenfalls Abhilfe ermöglichen. [6]

Es ist die Bewegung weg von der Behauptung hin zur Nachweisbarkeit.

4. Aber was soll ein normaler Mensch eigentlich prüfen?

Hier wird die Sache kompliziert.

Wir könnten einem Nutzer nach jeder FlameP-Sitzung einen technischen Bericht mit 300 Einträgen zeigen.

Zeitstempel, API-Aufrufe, Modellversionen, Tokenzahlen, Hashwerte, Speicheroperationen, Berechtigungsobjekte, Netzwerkereignisse.

Das wäre transparent, aber nicht nützlich.

Transparenz kann nämlich selbst zur Tarnung werden. Oder anders gesagt: „Beat them with details.“

Wer Menschen mit genügend Informationen überschüttet, kann anschließend behaupten, alles offengelegt zu haben. Nur verstanden hat es niemand.

Wir kennen dieses Muster längst aus Allgemeinen Geschäftsbedingungen und Cookie-Dialogen. Formal ist vieles erklärt. Praktisch klickt der Mensch auf „Akzeptieren“, weil er nicht einen halben Arbeitstag investieren möchte, bevor er eine Webseite benutzen darf.

Für FlameP bedeutet Beweis vor Vertrauen deshalb nicht maximale Information.

Es bedeutet relevante Nachprüfbarkeit.

Der Nutzer muss nicht verstehen, wie ein Transformer mathematisch funktioniert.

Er muss bei einer normalen Nutzung auch nicht den vollständigen internen Routing-Algorithmus prüfen.

Er sollte aber Antworten auf einige sehr einfache Fragen bekommen können.

Was wusste FlameP für diese Aufgabe?

Wohin gingen Informationen?

Was geschah mit ihnen?

Was hat eine Maschine entschieden?

Was hat ein Mensch entschieden?

Was bleibt gespeichert?

Und was ist jetzt beendet?

Die aus unserer Sicht eigentliche Aufgabe einer guten Transparenzschicht ist nicht, alles zu zeigen. Transparenz bedeutet für uns, das Richtige zu zeigen.

5. Wir brauchen deshalb unterschiedliche Ebenen des Beweises

Wir stellen uns Nachprüfbarkeit nicht als eine einzige große Protokolldatei vor.

Es braucht mindestens drei Ebenen.

Die erste gehört dem Nutzer.

Sie muss verständlich sein.

Ein Mensch sollte für eine relevante Aufgabe beispielsweise nachvollziehen können, welcher FlameP-Raum verwendet wurde, welche Kontextbereiche freigegeben waren, welcher Provider beteiligt war und ob die Verarbeitung abgeschlossen wurde.

Nicht in Entwicklersprache.

Sondern ungefähr so:

LeitgedankeVerwendeter Kontext: Projekt FlameP und öffentliches Autorenprofil.

LeitgedankeNicht verwendet: persönliche Gespräche, Gesundheitsinformationen, andere Projekte.

LeitgedankeExterne Verarbeitung: Provider X, Modell Y.

LeitgedankeSpeicherung beim Provider: nach den für diese Route geltenden Bedingungen.

LeitgedankeFlameP-Status: Aufgabe abgeschlossen, temporäre Freigaben geschlossen.

Das ist kein vollständiges Audit.

Es ist eine verständliche Quittung.

Die zweite Ebene benötigen wir selbst.

Dort muss wesentlich detaillierter dokumentiert werden können, was technisch geschehen ist. Sonst können wir weder Fehler untersuchen noch Sicherheitsprobleme rekonstruieren oder unsere eigenen Regeln kontrollieren.

Die dritte Ebene wird dort notwendig, wo unabhängige Kontrolle sinnvoll oder vorgeschrieben ist.

Auditoren, Aufsichtsbehörden oder andere berechtigte Stellen benötigen möglicherweise tiefere Nachweise, die ein normaler Nutzer weder sehen muss noch sehen sollte.

Drei Ebenen.

Verständlichkeit für den Menschen.

Rekonstruktion für den Betreiber.

Prüfbarkeit für unabhängige Kontrolle.

6. Das erzeugt jedoch ein neues Problem

Protokollierung kann selbst zur Datensammlung werden.

Das ist einer dieser schönen Widersprüche, die in einer Präsentation gern verschwinden.

Wir wollen möglichst gut beweisen können, was mit Daten passiert ist, also protokollieren wir möglichst viel. Und plötzlich haben wir eine neue Datenbank gebaut, die ziemlich genau dokumentiert, was ein Mensch wann getan hat.

Das wäre absurd.

Beweis vor Vertrauen darf deshalb nicht bedeuten, jeden Vorgang für immer personenbezogen aufzubewahren. Auch Nachweise brauchen Datenminimierung.

Die DSGVO nennt Datenminimierung, Zweckbindung und Speicherbegrenzung als zentrale Grundsätze. Organisationen sollen personenbezogene Informationen nur in dem Umfang und so lange verarbeiten, wie dies für den jeweiligen Zweck erforderlich ist. [3]

Für FlameP folgt daraus ein anspruchsvoller technischer Spagat.

Wir müssen nachweisen können, dass etwas geschehen ist, ohne dafür unnötig den gesamten Inhalt dessen aufzubewahren, was geschehen ist.

Manchmal kann ein Ereignis protokolliert werden, ohne den Inhalt zu speichern.

Manchmal genügt die Information, dass ein bestimmter Kontexttyp freigegeben war, ohne den kompletten Kontext in das Auditprotokoll zu kopieren.

Manchmal kann eine technische Referenz beweisen, dass eine bestimmte Version einer Policy galt, ohne sämtliche Nutzerdaten erneut abzulegen.

Und manchmal wird ein ausführlicherer Nachweis erforderlich sein.

Das lässt sich nicht mit einem einzigen Schalter lösen. Das ist harte Architekturarbeit.

7. Noch schwieriger wird es bei KI-Antworten

Nehmen wir an, FlameP zeigt sauber:

Dieses Modell wurde verwendet. Diese Quellen wurden abgerufen. Dieser Kontext war freigegeben. Diese Berechtigungen galten.

Alles schön und gut, aber bewiesen, dass die Antwort richtig ist, haben wir damit natürlich nicht.

Das ist eine wichtige Grenze unseres Prinzips. Bei vielen KI-Ergebnissen kann FlameP nicht beweisen, dass eine Aussage wahr ist. Ein Sprachmodell kann trotz sauberem Prozess einen Fehler machen.

Zwei Modelle können sich irren. Eine Quelle kann veraltet sein. Eine wissenschaftliche Studie kann später widerlegt werden. Eine unternehmerische Entscheidung kann trotz hervorragender Analyse scheitern.

Beweis vor Vertrauen darf deshalb selbst nicht zur Illusion absoluter Sicherheit werden.

Wir können in vielen Fällen den Prozess beweisbarer machen. Welche Quellen wurden genutzt? Welche Prüfung wurde durchgeführt? Welche Unsicherheiten wurden erkannt? Wurde ein zweites Modell eingesetzt? Hat ein Mensch das Ergebnis freigegeben? Welche Version einer Information lag zu diesem Zeitpunkt vor?

Das Ergebnis bleibt trotzdem eine Entscheidung unter Unsicherheit.

Genau deshalb trennt auch NIST die verschiedenen Eigenschaften vertrauenswürdiger KI voneinander. Transparenz, Erklärbarkeit, Datenschutz, Sicherheit, Zuverlässigkeit und Verantwortlichkeit sind miteinander verbunden, aber keines davon garantiert allein, dass ein System in jeder Situation korrekt handelt. [1]

Wir wollen also nicht aus „Vertrau der KI“ ein neues „Vertrau dem Audit-Log“ machen.

Der Nachweis ersetzt das Denken nicht, aber er schafft eine bessere Grundlage dafür.

8. Auch Provider dürfen nicht hinter FlameP verschwinden

Eine der bequemsten Möglichkeiten beim Aufbau einer Multi-Provider-Plattform wäre, die technische Komplexität vollständig unsichtbar zu machen.

Der Nutzer spricht mit FlameP.

Im Hintergrund wählen wir das Modell.

Fertig. Das wäre angenehm, hätte aber einen Preis.

FlameP würde zu einem neuen zentralen Vertrauenspunkt. Der Nutzer wäre zwar nicht mehr direkt von einem einzelnen Modellanbieter abhängig, müsste dafür aber glauben, dass wir im Hintergrund immer das Richtige tun.

Das wäre genau die Abhängigkeit, die wir eigentlich reduzieren wollen.

Deshalb gehört Providertransparenz für uns zu Beweis vor Vertrauen.

Das bedeutet nicht, dass jemand bei jeder einfachen Anfrage zunächst fünf technische Entscheidungen treffen muss. Ein gutes System darf Komplexität organisieren.

Aber relevante Entscheidungen müssen rekonstruierbar bleiben. Welcher Provider wurde gewählt? Warum war diese Route zulässig? Welche Datenklasse durfte diesen Provider erreichen? Welche Regelversion galt? Gab es eine Alternative?

Wurde eine besonders sensible Aufgabe anders behandelt als ein belangloser Textentwurf?

Die OECD AI Principles betonen neben Transparenz und Erklärbarkeit ausdrücklich Verantwortlichkeit und Rückverfolgbarkeit als Elemente verantwortlicher KI-Governance. [5]

Rückverfolgbarkeit ist für uns kein technisches Luxusproblem.

Rückverfolgbarkeit entscheidet darüber, ob Providerunabhängigkeit wirklich Unabhängigkeit schafft oder nur einen neuen undurchsichtigen Vermittler.

9. Beweis vor Vertrauen gilt auch gegen uns selbst

Bis hierhin könnte man den Eindruck bekommen, FlameP wolle hauptsächlich beweisen, was andere Provider mit Daten machen.

Wenn wir sagen, dass persönlicher Kontext getrennt bleibt, müssen unsere Systeme diese Trennung tatsächlich erzwingen.

Wenn wir behaupten, ein FlameP-Raum habe nur auf bestimmte Informationen Zugriff, darf nicht im Hintergrund doch die gesamte persönliche Historie verfügbar sein.

Wenn eine temporäre Berechtigung beendet wurde, muss sie technisch beendet sein.

Wenn wir behaupten, dass eine Aufgabe abgeschlossen ist, sollten die dafür geschaffenen temporären Verbindungen nicht einfach unbegrenzt weiterleben.

Wenn wir sagen, dass ein bestimmter Vorgang nicht gespeichert wird, müssen unsere eigenen Protokolle diesem Versprechen entsprechen.

Und wenn etwas noch nicht funktioniert, dürfen wir nicht so schreiben, als funktioniere es bereits.

Produktvision und Produktrealität bewegen sich unterschiedlich schnell. Ein Konzept ist in einem Workshop beschlossen. Die Benutzeroberfläche zeigt bereits die neue Sprache. Im Backend fehlt aber noch ein Teil der technischen Umsetzung.

Das Unternehmen beginnt, über das Produkt zu sprechen, das es bauen will, als wäre es bereits das Produkt, das Menschen benutzen.

Capability vor Claim.

Was wir behaupten, muss das System tragen können.

Und wenn es das noch nicht trägt, nennen wir es Plan, Ziel oder Entwicklung. Nicht Funktion.

10. Dasselbe gilt für gesellschaftliche Wirkung

Dieser Punkt verbindet Beweis vor Vertrauen direkt mit unserem Nordstern des Wertflusses.

Nehmen wir an, FlameP beschließt, 20.000 Euro einem gesellschaftlichen Programm zuzuordnen.

Dann können mindestens fünf verschiedene Dinge gemeint sein. Wir haben berechnet, dass 20.000 Euro nach unserer Regel dafür vorgesehen wären. Wir haben diesen Betrag intern reserviert.

Wir haben ihn einem Projekt verbindlich zugesagt. Wir haben ihn tatsächlich überwiesen.

Oder wir können zusätzlich belegen, dass das Geld angekommen und für den beschriebenen Zweck eingesetzt worden ist.

Diese fünf Zustände sind nicht dasselbe.

In Unternehmenskommunikation werden sie gern zusammengezogen.

„20.000 Euro für gesellschaftliche Wirkung.“ Klingt wunderbar. Nur weiß anschließend niemand mehr, was wirklich geschehen ist.

Wir wollen diese Zustände trennen, und ganz sicher nicht, weil Buchhaltung unser Lieblingshobby ist.

Sondern weil gesellschaftliche Wirkung besonders anfällig für gut gemeinte Selbsttäuschung ist.

Dasselbe gilt für Anwendungen.

Wenn wir schreiben, dass FlameP eine bestimmte Sprache unterstützt, muss geklärt sein, was „unterstützt“ bedeutet.

Kann das System einige Sätze übersetzen? Kann ein Muttersprachler damit tatsächlich arbeiten? Wurde die Qualität von Menschen geprüft, die diese Sprache sprechen? Funktioniert Spracheingabe? Funktioniert das nur in einer Demo oder im realen Produkt?

11. Totale Transparenz wäre trotzdem ein Fehler

Es gibt eine romantische Vorstellung von Transparenz: Wenn nur alles offen wäre, wäre alles gut. Das stimmt aber nicht.

Ein Sicherheitssystem sollte nicht jede interne Schutzregel veröffentlichen. Sonst liefert es möglichen Angreifern gleich die Anleitung.

Ein Nutzer sollte nicht die persönlichen Daten anderer Nutzer sehen können, nur weil wir Transparenz versprochen haben.

Auch Geschäftsgeheimnisse und geistiges Eigentum verschwinden nicht dadurch, dass ein Unternehmen verantwortungsvoll sein möchte.

Und manche technischen Informationen sind nicht nur unverständlich, sondern für die konkrete Entscheidung völlig irrelevant. Beweis vor Vertrauen bedeutet deshalb nicht radikale Offenlegung.

Es bedeutet proportionale Nachprüfbarkeit.

Was muss ein bestimmter Akteur wissen oder prüfen können, um eine relevante Behauptung beurteilen zu können?

Der Nutzer braucht eine andere Sicht als ein Sicherheitsprüfer. Eine Datenschutzaufsicht braucht eine andere als ein Kunde. Ein Entwickler braucht andere Informationen als ein Auditor.

NIST arbeitet aus gutem Grund mit Rollen, dokumentierten Verantwortlichkeiten und unterschiedlichen Prüfprozessen statt mit einer einzigen universellen Transparenzanforderung. [1]

12. Ganz wichtig jedoch: Es wird trotzdem Vertrauen brauchen

Nun könnte man unseren Grundsatz ziemlich leicht gegen uns verwenden.

Wenn alles bewiesen werden soll, warum überhaupt noch Vertrauen? Weil kein komplexes System ohne Vertrauen funktioniert. Kein normaler Mensch wird den Quellcode aller Komponenten von FlameP lesen. Niemand wird die Rechenzentren jedes Providers persönlich inspizieren.

Auch ein unabhängiger Auditor prüft nur bestimmte Bereiche zu bestimmten Zeitpunkten.

Zertifizierungen können fehlerhaft sein. Logs können falsch implementiert werden. Gesetze werden verletzt. Menschen machen Fehler. Es wird immer eine Grenze dessen geben, was ein einzelner Nutzer selbst überprüfen kann. Unser Ziel ist deshalb nicht, Vertrauen abzuschaffen.

Unser Ziel ist, den Bereich zu verkleinern, in dem blindes Vertrauen notwendig ist.

Heute funktioniert vieles nach dem Prinzip: Vertraue uns zuerst. Vielleicht kannst du später überprüfen, ob wir es verdient haben. Wir wollen es umdrehen: Wir zeigen so viel relevante Evidenz, wie sinnvoll möglich ist. Daraus kann Vertrauen entstehen.

13. Das verändert auch die Machtverteilung

Am Ende ist Beweis vor Vertrauen keine technische Detailfrage.

Es geht um Macht.

Wer allein weiß, was ein System getan hat, besitzt einen Informationsvorsprung.

Wer allein entscheiden kann, welche Information sichtbar wird, kontrolliert die Erzählung darüber.

Und wer gleichzeitig Daten besitzt, Regeln bestimmt und den Nachweis über die Einhaltung dieser Regeln selbst formuliert, verlangt ziemlich viel Vertrauen.

Wir werden diese Asymmetrie nicht vollständig beseitigen können. FlameP betreibt das System. Damit besitzen wir zwangsläufig Macht. Die relevante Frage lautet deshalb nicht, ob Macht existiert. Für uns ist die relevante Frage, wie wir Mechanismen bauen, die sie begrenzen.

Dokumentation begrenzt Macht. Nachvollziehbare Berechtigungen begrenzen Macht. Trennung von Kontext begrenzt Macht. Ein sichtbarer Provider begrenzt Macht. Unabhängige Prüfungen können Macht begrenzen.

Und eine Unternehmenskultur, in der eine Behauptung einen Beleg benötigt, begrenzt zumindest die Versuchung, Wirklichkeit und Marketing zu nahe zusammenrücken zu lassen.

Auch die OECD verbindet verantwortliche KI inzwischen ausdrücklich mit einem kontinuierlichen Prozess aus Risikoerkennung, Prävention, Überwachung, Kommunikation und gegebenenfalls Abhilfe. [6]

14. Schluss: Unser Anspruch ist einfach. Seine Umsetzung wird es nicht sein.

Wir wissen heute nicht, wie gut uns das in jedem Bereich gelingen wird. Manche Nachweise werden technisch relativ einfach sein.

Andere werden teuer. Manche Informationen werden wir verständlich darstellen können.

Bei anderen werden wir feststellen, dass Transparenz und Datenschutz miteinander kollidieren.

Vielleicht werden wir anfangs Dinge protokollieren, die wir später anders lösen müssen.

Vielleicht stellen Nutzer fest, dass unsere Transparenzoberfläche die falschen Informationen zeigt.

Vielleicht wird uns eine externe Prüfung auf einen blinden Fleck hinweisen, den wir selbst nicht gesehen haben.

Beweis vor Vertrauen bedeutet nicht, dass wir keinen Fehler machen.

Es bedeutet, dass unser System möglichst so gebaut wird, dass Fehler sichtbar, rekonstruierbar und korrigierbar werden.

Das ist ein bescheideneres Versprechen. Und ein anspruchsvolleres.

Wir möchten nicht sagen:

LeitgedankeFlameP ist vertrauenswürdig.

Das wäre eine Behauptung über uns selbst. Wir möchten lieber sagen:

LeitgedankeHier ist, was FlameP getan hat. Hier sind die relevanten Regeln. Hier sind die Grenzen. Und hier ist das, was sich überprüfen lässt.

Danach kann jeder selbst entscheiden, wie viel Vertrauen daraus entsteht. Wir halten das für die ehrlichere Reihenfolge.

Du musst FlameP nicht vertrauen. Wir müssen uns dieses Vertrauen verdienen.

Und wo immer es möglich ist, sollte dafür nicht unser Wort genügen.