Trust, Trustworthiness und Zero Trust: Warum Vertrauen in Zukunft überprüfbar sein muss

Fast jedes Technologieunternehmen möchte Vertrauen schaffen. Doch der Satz „Trust us“ offenbart bereits das eigentliche Problem: Er verlangt Vertrauen, bevor Gründe dafür geliefert wurden.

Ein Softwareanbieter behauptet beispielsweise: „Ihre Daten sind bei uns sicher.“ Ein Kunde kann diese Aussage glauben und dem Anbieter vertrauen. Ob der Anbieter tatsächlich vertrauenswürdig ist, steht auf einem anderen Blatt. Erst Nachweise über implementierte Sicherheitsmaßnahmen, deren Wirksamkeit und ihre aktuelle Überprüfung schaffen eine begründete Grundlage für dieses Vertrauen.

Genau an dieser Stelle werden Begriffe wie Trust, Trustworthiness, Assurance, Reliance, Compliance und Zero Trust häufig miteinander vermischt. Sie beschreiben jedoch unterschiedliche Dinge. Wer sie sauber trennt, erkennt auch, wie digitales Vertrauen in Zukunft funktionieren sollte.

Vertrauen beginnt dort, wo Gewissheit endet

In der organisationspsychologischen Forschung wird Trust häufig als die Bereitschaft verstanden, sich gegenüber einer anderen Partei verwundbar zu machen. Diese Bereitschaft beruht auf positiven Erwartungen darüber, wie sich die andere Partei verhalten wird [1, p. 395]. Ein ähnlich einflussreiches Modell definiert Vertrauen als die Bereitschaft, ein relevantes Risiko einzugehen, obwohl die andere Partei nicht vollständig überwacht oder kontrolliert werden kann [2, p. 712]. (elearning.unite.it)

Damit setzt Vertrauen zwei Dinge voraus: Unsicherheit und mögliche Konsequenzen.

Ist das Ergebnis vollständig sicher, braucht es kein Vertrauen. Steht nichts auf dem Spiel, handelt es sich eher um Bequemlichkeit als um Vertrauen. Trust wird erst relevant, wenn wir von einer Person, Organisation oder Technologie abhängig sind und diese Abhängigkeit uns verwundbar macht.

Vertrauen ist deshalb niemals einfach eine allgemeine Eigenschaft:

A vertraut B, in Bezug auf X, unter den Bedingungen Y, zu einem bestimmten Zeitpunkt.

Ein Unternehmen kann einem Cloud-Anbieter beispielsweise bei der Speicherung öffentlicher Inhalte vertrauen, ihm aber nicht ohne Weiteres besonders sensible Gesundheitsdaten anvertrauen. Dieselbe Technologie kann für einen Anwendungsfall ausreichend zuverlässig und für einen anderen vollkommen ungeeignet sein.

Trust ist somit immer relational, kontextspezifisch und risikobezogen.

Trusted ist nicht dasselbe wie trustworthy

Im Alltag verwenden wir „trusted“ und „trustworthy“ häufig fast synonym. Konzeptionell liegt zwischen ihnen jedoch ein entscheidender Unterschied.

Trusted beschreibt, dass jemand oder etwas tatsächlich Vertrauen genießt.

Trustworthy beschreibt, dass jemand oder etwas dieses Vertrauen verdient.

Ein überzeugender Betrüger kann trusted sein, ohne trustworthy zu sein. Umgekehrt kann ein sehr sicher entwickeltes System trustworthy sein, aber von seinen Nutzern nicht als vertrauenswürdig wahrgenommen werden, weil seine Funktionsweise, Grenzen und Sicherheitsmaßnahmen unsichtbar bleiben.

Die klassische Organisationsforschung beschreibt drei wesentliche Grundlagen wahrgenommener Vertrauenswürdigkeit:

Ability bezeichnet die Kompetenz, eine bestimmte Aufgabe zuverlässig zu erfüllen.

Integrity bezeichnet die Übereinstimmung zwischen Aussagen, Prinzipien und tatsächlichem Verhalten.

Benevolence bezeichnet die Erwartung, dass die vertrauenswürdige Partei nicht ausschließlich den eigenen Vorteil verfolgt, sondern auch die Interessen der anderen Seite berücksichtigt [2, pp. 717–720]. (JSTOR)

Für technische Systeme müssen diese Kategorien übersetzt werden. Ability wird beispielsweise zu Leistungsfähigkeit, Zuverlässigkeit und Sicherheit. Integrity zeigt sich in vorhersehbarem Verhalten, unveränderten Regeln, nachvollziehbarer Verarbeitung und wahrheitsgemäßer Kommunikation. Benevolence lässt sich nicht ohne Weiteres einer Maschine zuschreiben, wohl aber der Organisation, die das System entwickelt, betreibt und über seine Grenzen informiert.

NIST beschreibt Trustworthiness im Systems Engineering als die Eigenschaft, kritische Anforderungen erfüllen zu können und dies nachvollziehbar zu demonstrieren. Dazu können nicht nur Security, sondern auch Safety, Reliability, Resilience und weitere Systemeigenschaften gehören [3, p. 62]. Trustworthiness ist damit keine abstrakte moralische Auszeichnung, sondern eine auf konkrete Anforderungen bezogene Eigenschaft. (NIST Publikationen)

Trust, Reliance und Compliance sind nicht dasselbe

Eine weitere wichtige Unterscheidung besteht zwischen Trust und Reliance.

Trust ist eine Haltung oder Erwartung. Reliance ist ein beobachtbares Verhalten.

Eine Person kann einer KI misstrauen und ihre Antwort trotzdem übernehmen, weil keine bessere Alternative verfügbar ist, weil Zeitdruck besteht oder weil der organisatorische Prozess dies verlangt. Umgekehrt kann sie einem System grundsätzlich vertrauen, seine Empfehlung in einem bestimmten Fall aber bewusst nicht verwenden.

Dieser Unterschied ist besonders für KI-Systeme relevant. Eine Umfrage, in der Nutzer angeben, wie sehr sie einer KI vertrauen, sagt nicht automatisch voraus, wann sie deren Empfehlungen tatsächlich übernehmen. Aktuelle Forschung fordert deshalb, subjektiv empfundenes Vertrauen, beobachtbare Reliance und die tatsächliche Leistungsfähigkeit eines Systems getrennt zu messen [8]–[10]. (TU Delft Research Portal)

Auch Compliance ist nicht mit Trustworthiness gleichzusetzen.

Compliance beantwortet zunächst die Frage, ob bestimmte Anforderungen innerhalb eines definierten Scopes erfüllt wurden. Das kann einen wichtigen Beitrag zur Vertrauenswürdigkeit leisten. Eine Zertifizierung, ein Auditbericht oder ein Assessment ist jedoch keine grenzenlose und zeitlich unbegrenzte Aussage darüber, dass eine Organisation „sicher“ ist.

Ein Audit kann beispielsweise bestätigen, dass ein bestimmtes Managementsystem zu einem bestimmten Zeitpunkt und innerhalb eines bestimmten Geltungsbereichs angemessen implementiert war. Es beweist nicht automatisch, dass jede aktuelle Konfiguration korrekt ist, alle neuen Systeme abgedeckt wurden oder niemals ein Sicherheitsvorfall eintreten kann.

NIST warnt deshalb davor, Compliance als alleinige Grundlage für Assurance und Trustworthiness zu behandeln. Eine reine Compliance-Perspektive kann eine äußere Sicherheitsschicht erzeugen, ohne die tatsächliche Wirksamkeit der zugrunde liegenden Systeme hinreichend zu belegen [3, p. 105]. (NIST Publikationen)

Compliance ist wertvoll. Aber Compliance ist ein Beitrag zu begründetem Vertrauen, nicht dessen vollständiger Ersatz.

Assurance ist die Brücke zwischen Trust und Trustworthiness

Zwischen dem subjektiven Vertrauen einer Partei und der tatsächlichen Vertrauenswürdigkeit eines Systems fehlt noch ein verbindendes Element: Assurance.

NIST beschreibt Assurance als „grounds for justified confidence“ – als Grundlage für begründete Zuversicht, dass eine bestimmte Behauptung erfüllt wurde oder erfüllt werden wird [3, p. 50]. (NIST Publikationen)

Assurance ist damit weder ein Bauchgefühl noch eine Garantie. Es ist eine strukturierte Begründung.

Eine belastbare Assurance-Struktur enthält mindestens:

Claims: Was wird konkret behauptet?

Arguments: Warum sollen die vorliegenden Informationen die Behauptung stützen?

Evidence: Welche Nachweise belegen die Umsetzung und Wirksamkeit?

Assumptions: Unter welchen Voraussetzungen gilt die Schlussfolgerung?

Scope: Für welche Systeme, Daten, Prozesse und Zeiträume gilt sie?

NIST bezeichnet eine solche nachvollziehbare Struktur als Assurance Case. Sie soll prüfbar darstellen, wie Behauptungen, Argumentation, Annahmen und Evidenzen zusammenhängen [3, pp. 107–108]. (NIST Publikationen)

Nehmen wir die Aussage:

Alle Produktionsdaten werden im Ruhezustand verschlüsselt.

Eine Richtlinie zur Verschlüsselung beweist zunächst nur, dass es eine Vorgabe gibt. Ein Screenshot aus der Konfiguration einer Datenbank zeigt, dass bei dieser Datenbank eine bestimmte Einstellung aktiviert war. Erst eine Kombination aus vollständigem Asset-Inventar, Storage-Konfigurationen, Key-Management-Regeln, Tests, Logs, Reviews und einem aktuellen Zeitbezug kann die ursprüngliche Aussage belastbar stützen.

Dabei müssen mehrere Ebenen unterschieden werden:

Eine Policy belegt die Absicht und das Design.

Eine Konfiguration belegt die technische Implementierung.

Ein Test oder kontinuierliche Telemetrie belegt die tatsächliche Funktionsweise.

Ein Review belegt, dass Ergebnisse bewertet und verantwortet wurden.

Keiner dieser Nachweise ist isoliert ausreichend. Assurance entsteht erst durch die nachvollziehbare Verbindung zwischen Aussage, Scope, Umsetzung und Evidenz.

Eine ausgereifte Assurance-Struktur muss außerdem negative Ergebnisse sichtbar machen können. Sie sollte nicht nur „erfüllt“ anzeigen, sondern auch feststellen können:

• Die Evidenz reicht nicht aus.
• Der Nachweis ist veraltet.
• Ein Teil des Scopes fehlt.
• Die Implementierung weicht von der Behauptung ab.
• Die Wirksamkeit wurde noch nicht geprüft.

Ein System, das ausschließlich grüne Statusanzeigen erzeugen kann, produziert möglicherweise Beruhigung. Es produziert noch keine glaubwürdige Assurance.

Zero Trust bedeutet nicht, niemandem zu vertrauen

Auf den ersten Blick scheint Zero Trust dem Ziel von mehr Vertrauen vollständig zu widersprechen. Tatsächlich behandelt Zero Trust jedoch eine andere Ebene des Problems.

Zero Trust ist keine psychologische oder kulturelle Aussage. Es ist ein Sicherheitsmodell für Zugriffsentscheidungen.

Nach NIST soll Vertrauen nicht allein aufgrund von Netzwerkstandort, Gerätebesitz oder organisatorischer Zugehörigkeit implizit vergeben werden. Zugriffe werden stattdessen ressourcenbezogen, mit möglichst geringen Berechtigungen und für einzelne Requests bewertet. Dabei wird davon ausgegangen, dass ein Netzwerk oder System bereits kompromittiert sein könnte [4, pp. 4–7]. (NIST Publikationen)

Das traditionelle Perimetermodell komprimiert eine komplexe Vertrauensentscheidung häufig auf eine einfache Annahme:

Innerhalb des Unternehmensnetzwerks bedeutet vertrauenswürdig.

Zero Trust zerlegt diese pauschale Annahme in kleinere Entscheidungen:

Darf diese Identität mit diesem Gerät unter diesen Bedingungen jetzt auf diese Ressource zugreifen?

Das ist nicht das Ende von Vertrauen. Es ist das Ende von unverdientem, pauschalem und dauerhaftem Vertrauen.

Eine präzisere Übersetzung von Zero Trust wäre deshalb:

Zero implicit trust. Zero unearned privilege.

Ein Unternehmen kann gleichzeitig eine ausgeprägte High-Trust-Kultur und eine Zero-Trust-Architektur haben. Mitarbeiter müssen sich nicht persönlich verdächtigen, nur weil Zugriffe technisch verifiziert werden. Im Gegenteil: Gut gestaltete Kontrollen können zwischenmenschliches Vertrauen erleichtern, weil einzelne Fehler oder kompromittierte Accounts nicht automatisch uneingeschränkte Schäden verursachen.

Zero Trust ersetzt eine große, diffuse Vertrauensannahme durch viele kleine, kontextspezifische und widerrufbare Entscheidungen. Genau darin liegt die Verbindung zu einem modernen Verständnis von Trust.

Digital Trust erweitert den Blick auf das gesamte Ökosystem

Während Trustworthiness meist die Eigenschaften einer bestimmten Person, Organisation oder Technologie betrachtet, erweitert Digital Trust den Blick auf das gesamte digitale Ökosystem.

Das World Economic Forum beschreibt Digital Trust als die Erwartung, dass digitale Technologien, Dienste und die Organisationen dahinter die Interessen ihrer Stakeholder schützen und gesellschaftliche Erwartungen und Werte respektieren. Sein Framework verbindet Digital Trust unter anderem mit Cybersecurity, Privacy, Transparenz, Auditierbarkeit, Fairness, Interoperabilität, Safety und Möglichkeiten zur Wiedergutmachung [5]. (World Economic Forum)

ISACA definiert Digital Trust als Vertrauen in die Integrität der Beziehungen, Interaktionen und Transaktionen zwischen Anbietern und Nutzern innerhalb eines digitalen Ökosystems. Dieses Ökosystem umfasst Menschen, Organisationen, Prozesse, Informationen und Technologie [6]. (ISACA)

Digital Trust ist damit ein nützlicher Oberbegriff. Er macht deutlich, dass Vertrauen nicht allein durch eine sichere Anwendung entsteht.

Ein SaaS-Anbieter hängt beispielsweise von einem Cloud-Provider, einem Identity-Provider, Softwarebibliotheken, Zahlungsdienstleistern und möglicherweise einem Anbieter von KI-Modellen ab. Die Vertrauenswürdigkeit des sichtbaren Produkts hängt daher auch von unsichtbaren Abhängigkeiten und den Kontrollen entlang dieser Lieferkette ab.

Digital Trust ist das gesellschaftliche und wirtschaftliche Ergebnis dieses Ökosystems. Trustworthiness bezeichnet dessen überprüfbare Eigenschaften. Assurance schafft die Grundlage, um beides miteinander zu verbinden.

KI zeigt, warum „mehr Vertrauen“ das falsche Ziel ist

Bei künstlicher Intelligenz wird die Trennung zwischen tatsächlicher Trustworthiness, wahrgenommenem Trust und beobachtbarer Reliance besonders wichtig.

Eine KI kann flüssig, selbstbewusst und überzeugend formulieren, ohne zuverlässig richtigzuliegen. Ein Interface kann Transparenz und Kompetenz suggerieren, obwohl die zugrunde liegende Leistung für den konkreten Anwendungsfall unzureichend ist. Auch Erklärungen und Confidence Scores sind nicht automatisch Beweise für Korrektheit.

NIST beschreibt Trustworthy AI daher nicht als einzelne Eigenschaft. Das AI Risk Management Framework nennt unter anderem Validität und Zuverlässigkeit, Sicherheit, Resilienz, Accountability, Transparenz, Erklärbarkeit, Privacy und den Umgang mit schädlichem Bias. NIST betont zugleich, dass diese Eigenschaften kontextabhängig sind und zwischen ihnen Zielkonflikte bestehen können [7, p. 12]. (NIST Publikationen)

Ein System kann sehr genau, aber nicht fair sein. Es kann transparent, aber unsicher sein. Es kann datenschutzfreundlich, aber für seinen vorgesehenen Zweck unzuverlässig sein. Das Label „trustworthy AI“ darf diese Unterschiede nicht verdecken.

Die aktuelle Human-AI-Forschung spricht deshalb zunehmend von appropriate trust, calibrated trust und vor allem von appropriate reliance. Das Ziel besteht nicht darin, dass Menschen einem System möglichst stark vertrauen. Sie sollen seine Fähigkeiten und Grenzen möglichst korrekt einschätzen und sich nur dann darauf verlassen, wenn dies für den konkreten Fall gerechtfertigt ist.

Eine systematische Untersuchung von Mehrotra et al. zeigt, dass es bislang keine einheitliche Definition von „appropriate trust“ gibt. Forschungsarbeiten verwenden unterschiedliche Messgrößen für Vertrauen, Reliance, wahrgenommene Fähigkeiten und tatsächliche Systemleistung [8]. Eine weitere Untersuchung von 70 empirischen Arbeiten kommt zu dem Ergebnis, dass die Beziehung zwischen Explainability, Vertrauen und Reliance weiterhin gemischt und teilweise widersprüchlich ist [9]. (TU Delft Research Portal)

Eine 2026 veröffentlichte Literaturauswertung argumentiert noch deutlicher: Subjektive Trust-Messungen erlauben nicht automatisch Aussagen darüber, ob Menschen angemessen auf KI-Empfehlungen zurückgreifen. Die Autoren unterscheiden daher explizit zwischen Trust, bloßer Reliance und Appropriate Reliance [10]. Da es sich bei dieser Arbeit zum Zeitpunkt der Recherche um ein Preprint handelt, sollten ihre Ergebnisse als aktueller Forschungsbeitrag und nicht als abschließender Konsens verstanden werden. (arXiv)

Auch Misstrauen ist nicht zwangsläufig negativ. Eine gewisse Skepsis kann Aufmerksamkeit, Überprüfung und das Erkennen von Fehlern fördern. Gleichzeitig kann pauschales Misstrauen dazu führen, dass korrekte Informationen ignoriert werden. Eine experimentelle Studie aus dem Jahr 2026 versuchte, „healthy distrust“ anhand visueller Aufmerksamkeit zu erfassen. Die Ergebnisse waren jedoch nicht eindeutig und verdeutlichen, wie schwierig die empirische Messung von angemessenem Vertrauen und Misstrauen weiterhin ist [11]. (Frontiers)

Die gewünschte Beziehung lässt sich als einfache Matrix darstellen:

Tatsächliche Trustworthiness	Niedriges Vertrauen	Hohes Vertrauen
Niedrig	begründete Skepsis	gefährliches Overtrust
Hoch	unnötiges Undertrust oder Nichtnutzung	begründetes, kalibriertes Vertrauen

Das Ziel ist nicht grundsätzlich das Feld rechts oben. Das Ziel ist, dass Vertrauen und Reliance zur tatsächlichen Trustworthiness, zum Risiko und zum jeweiligen Kontext passen.

Eine im Juli 2026 veröffentlichte Arbeit von Busuioc und Maggetti fordert entsprechend einen Wechsel von Trust Maximization zu Calibrated Trust. Die Autoren warnen davor, Vertrauen von tatsächlicher Trustworthiness zu entkoppeln oder durch kommunikative und technische Signale lediglich den Eindruck von Vertrauenswürdigkeit zu erzeugen. Besonders bei öffentlichen KI-Systemen müssten Vulnerabilität, Accountability und die Verteilung möglicher Schäden berücksichtigt werden [12]. (OUP Academic)

Auch der europäische AI Act folgt grundsätzlich der Logik, Trustworthiness nicht nur zu behaupten, sondern durch konkrete Prozesse und Nachweise zu operationalisieren. Für relevante Hochrisikosysteme sieht er unter anderem Risikomanagement, Data Governance, technische Dokumentation, Logging, Transparenz, menschliche Aufsicht sowie Anforderungen an Genauigkeit, Robustheit und Cybersecurity vor [13, Arts. 9–15]. (EUR-Lex)

Trustworthy AI ist deshalb kein Designstil und kein Marketinglabel. Es ist eine fortlaufende Governance- und Assurance-Aufgabe.

Unser Standpunkt: Vertrauen muss begründet und kalibriert sein

Bei Secani wollen wir Vertrauen weder als bloßes Gefühl noch als absoluten Beweis verstehen.

Absolute Sicherheit existiert in realen digitalen Systemen nicht. Selbst sehr gute Nachweise können nicht garantieren, dass niemals ein Fehler oder Angriff auftreten wird. Würde jede Unsicherheit vollständig verschwinden, wäre Vertrauen nicht mehr erforderlich.

Deshalb sprechen wir bewusst von justified confidence, nicht von certainty.

Unsere Definition lautet:

Trust is justified, context-specific confidence that a security claim is true now because the claim, its implementation, and current evidence verifiably align.

Auf Deutsch:

Vertrauen ist die begründete, kontextspezifische Zuversicht, dass eine Aussage über Sicherheit aktuell zutrifft, weil Aussage, tatsächliche Umsetzung und verfügbare Evidenz überprüfbar übereinstimmen.

Die zugrunde liegende Kette ist:

Aussage → Umsetzung → Evidenz → Assurance → kalibriertes Vertrauen

Eine Organisation behauptet etwas über ihre Sicherheit. Diese Aussage wird auf konkrete Controls, Systeme und Verantwortlichkeiten heruntergebrochen. Aktuelle Nachweise zeigen, ob und wie die Maßnahmen umgesetzt wurden. Eine nachvollziehbare Bewertung erklärt, ob diese Evidenz die ursprüngliche Aussage tatsächlich stützt. Erst daraus entsteht eine rationale Grundlage für Vertrauen.

Diese Definition enthält fünf bewusste Einschränkungen.

Vertrauen ist claim-specific. „Wir sind sicher“ ist zu breit, um überprüft zu werden. „Alle produktiven Datenspeicher verwenden freigegebene Verschlüsselungskonfigurationen“ ist konkret prüfbar.

Vertrauen ist context-specific. Eine Kontrolle kann für ein System wirksam sein und für ein anderes nicht. Eine KI kann für die Zusammenfassung interner Dokumente geeignet, für autonome Freigabeentscheidungen aber ungeeignet sein.

Vertrauen ist zeitabhängig. Organisationen verändern sich. Neue Assets werden hinzugefügt, Konfigurationen angepasst, Mitarbeiter wechseln und Dienstleister aktualisieren ihre Systeme. Nachweise verlieren deshalb mit der Zeit an Aussagekraft.

Vertrauen ist evidenzbasiert, aber nicht absolut. Evidenz reduziert Unsicherheit und macht Entscheidungen begründbar. Sie eliminiert Risiko nicht vollständig.

Vertrauen muss widerrufbar sein. Wenn neue Evidenz einer bisherigen Aussage widerspricht, muss sich auch die Vertrauensentscheidung verändern können.

Von jährlichen Vertrauenssignalen zu Continuous Assurance

Das traditionelle Modell digitaler Vertrauensbildung beruht häufig auf periodischen Signalen: Fragebögen, Reports, Zertifikate und Audits. Diese Instrumente bleiben wichtig. Sie sind jedoch für eine digitale Welt, in der sich Systeme täglich verändern, allein nicht ausreichend.

Das zukünftige Modell verschiebt sich:

Traditionelles Modell	Zukünftiges Modell
„Trust us“	Überprüfe eine konkrete Aussage
allgemeines Sicherheitsversprechen	definierter Scope und klarer Claim
periodischer Nachweis	kontinuierlich aktualisierte Evidenz
statisches Dokument	verknüpfte, maschinenlesbare Informationen
binärer Status	Kontext, Unsicherheit und Gültigkeitszeitraum
versteckte Annahmen	explizite Annahmen und Abhängigkeiten
ausschließlich positive Nachweise	sichtbare Lücken und widersprechende Evidenz

Das bedeutet nicht, dass jede Organisation permanent jede Aktivität überwachen muss. Continuous Assurance sollte risikobasiert und verhältnismäßig sein. Kritische Aussagen benötigen aktuellere und stärkere Evidenz als wenig folgenreiche Aussagen.

Entscheidend ist, dass Trust nicht mehr an ein einzelnes Dokument gebunden bleibt. Anforderungen, Implementierungen, Evidenzen, Reviews, Findings und Abhängigkeiten sollten als zusammenhängendes Modell betrachtet werden.

Maschinenlesbare Strukturen werden dabei eine zentrale Rolle spielen. Sie ermöglichen, dass ein Nachweis nicht für jeden Standard, jedes Assessment und jeden Geschäftspartner erneut manuell interpretiert werden muss. Gleichzeitig muss seine Herkunft, sein Scope, sein Erstellungszeitpunkt und seine Gültigkeit erhalten bleiben.

Die Zukunft von Trust ist deshalb nicht nur kontinuierlich. Sie ist granular, nachvollziehbar, übertragbar und widerrufbar.

Zero Trust und High Trust sind keine Gegensätze

Damit lassen sich die verschiedenen Konzepte kohärent zusammenführen:

Zero Trust regelt, wie einzelne Zugriffsentscheidungen getroffen werden.

Trustworthiness beschreibt, ob ein System oder eine Organisation Vertrauen verdient.

Assurance liefert die nachvollziehbare Begründung dafür.

Evidence stützt konkrete Aussagen über Umsetzung und Wirksamkeit.

Compliance prüft die Übereinstimmung mit definierten Anforderungen.

Digital Trust ist das Vertrauen, das daraus im gesamten Ökosystem entstehen kann.

Ein Zero-Trust-System verhindert, dass Vertrauen unkontrolliert vorausgesetzt wird. Eine Assurance-Struktur zeigt, wann Vertrauen dennoch gerechtfertigt ist. Beides verfolgt daher dasselbe Ziel: Vertrauen soll dort entstehen, wo es verdient ist, und dort begrenzt werden, wo die Grundlage fehlt.

Die Zukunft liegt nicht in einem pauschalen „Trust everyone“ und auch nicht in einem kulturellen „Trust no one“.

Sie liegt in verifiable, calibrated trust.

Was „Optimize for trust“ für Secani bedeutet

„Optimize for trust“ darf nicht bedeuten, die Wahrnehmung von Vertrauenswürdigkeit zu maximieren.

Es bedeutet nicht, möglichst viele grüne Häkchen, Badges oder allgemeine Sicherheitsversprechen zu produzieren. Und es bedeutet nicht, Menschen dazu zu bringen, einem System stärker zu vertrauen, als dessen tatsächliche Fähigkeiten rechtfertigen.

Für uns bedeutet es:

Do not optimize for being trusted. Optimize for being worthy of justified trust.

Wir bauen Secani deshalb mit dem Ziel, Aussagen, Anforderungen, Umsetzungen und Evidenzen dauerhaft miteinander zu verbinden. Vertrauen soll nicht allein aus einer überzeugenden Präsentation oder einem periodischen Dokument entstehen, sondern aus einer überprüfbaren und aktuellen Begründung.

Der vielleicht präziseste Satz dafür lautet:

Trust is not a promise. It is a continuously supported conclusion.

Organisationen sollten nicht vertrauenswürdig erscheinen müssen. Sie sollten nachweisbar vertrauenswürdig werden können.

Und Menschen sollten nicht mehr vertrauen müssen.

Sie sollten besser vertrauen können.

Literaturverzeichnis

[1] D. M. Rousseau, S. B. Sitkin, R. S. Burt, and C. Camerer, “Not So Different After All: A Cross-Discipline View of Trust,” Academy of Management Review, vol. 23, no. 3, pp. 393–404, 1998, doi: 10.5465/AMR.1998.926617. (elearning.unite.it)

[2] R. C. Mayer, J. H. Davis, and F. D. Schoorman, “An Integrative Model of Organizational Trust,” Academy of Management Review, vol. 20, no. 3, pp. 709–734, 1995, doi: 10.5465/amr.1995.9508080335. (JSTOR)

[3] R. Ross, M. McEvilley, and M. Winstead, Engineering Trustworthy Secure Systems, NIST Special Publication 800-160, vol. 1, rev. 1, National Institute of Standards and Technology, Gaithersburg, MD, USA, Nov. 2022, doi: 10.6028/NIST.SP.800-160v1r1. (NIST Publikationen)

[4] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, NIST Special Publication 800-207, National Institute of Standards and Technology, Gaithersburg, MD, USA, Aug. 2020, doi: 10.6028/NIST.SP.800-207. (NIST Publikationen)

[5] World Economic Forum, Earning Digital Trust: Decision-Making for Trustworthy Technologies, Geneva, Switzerland, Nov. 2022. [Online]. Accessed: Aug. 3, 2026. (World Economic Forum)

[6] ISACA, “What Is Resilience and How Does It Promote Digital Trust,” ISACA Journal, vol. 4, 2024. [Online]. Accessed: Aug. 3, 2026. (ISACA)

[7] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, Jan. 2023, doi: 10.6028/NIST.AI.100-1. (NIST Publikationen)

[8] S. Mehrotra, C. Degachi, O. Vereschak, C. M. Jonker, and M. L. Tielman, “A Systematic Review on Fostering Appropriate Trust in Human-AI Interaction: Trends, Opportunities and Challenges,” ACM Journal on Responsible Computing, vol. 1, no. 4, Art. no. 26, pp. 1–45, 2024, doi: 10.1145/3696449. (ACM Digital Library)

[9] R. Visser, T. M. Peters, I. Scharlau, and B. Hammer, “Trust, distrust, and appropriate reliance in (X)AI: A conceptual clarification of user trust and survey of its empirical evaluation,” Cognitive Systems Research, vol. 91, Art. no. 101357, 2025, doi: 10.1016/j.cogsys.2025.101357. (ScienceDirect)

[10] M. Raees and K. Papangelis, “From Trust to Appropriate Reliance: Measurement Constructs in Human-AI Decision-Making,” arXiv:2604.23896, Apr. 2026, doi: 10.48550/arXiv.2604.23896. Preprint. (arXiv)

[11] T. M. Peters, K. Biermeier, and I. Scharlau, “Assessing healthy distrust in human-AI interaction: Interpreting changes in visual attention,” Frontiers in Psychology, vol. 16, Art. no. 1694367, Jan. 2026, doi: 10.3389/fpsyg.2025.1694367. (Frontiers)

[12] M. Busuioc and M. Maggetti, “Worthy of trust? AI governance and the role of (dis)trust,” Perspectives on Public Management and Governance, Art. no. gvag007, Jul. 2026, doi: 10.1093/ppmgov/gvag007. (OUP Academic)

[13] European Parliament and Council of the European Union, “Regulation (EU) 2024/1689 of 13 June 2024 laying down harmonised rules on artificial intelligence,” Official Journal of the European Union, Jul. 2024. (EUR-Lex)