Eine neue AI-Idee entsteht. Ein anderes System wird gerade entwickelt. Ein drittes trifft längst auf die Realität. Sie stehen an völlig unterschiedlichen Punkten und doch führen sie zu denselben grundlegenden Fragen: Was müssen wir wissen, was können wir belegen und wie weit dürfen wir vertrauen? Aus unserer Projekt- und Research-Arbeit sind acht Fragen entstanden. Keine acht Phasen, sondern eine Journey, die dort beginnt, wo Ihre relevante Frage liegt.

Acht Fragen für Trustworthy AI

Ihre AI ist produktiv. Sie wurde getestet. Security hat sie geprüft. Governance ist definiert. Die Benutzer arbeiten damit.

Können Sie erklären, warum Sie ihr vertrauen?

Wissen Sie auch, wofür das System heute tatsächlich verwendet wird? Ob seine ursprünglichen Annahmen noch gelten? Welche Evidence diese Annahmen stützt? Wo die Grenzen des Vertrauens liegen? Und wer eine Entscheidung verantwortet, die mit ihrer Hilfe getroffen wurde?

Aus einer scheinbar einfachen Frage werden schnell weitere. Das ist kein Zufall.

In unserer Research-Arbeit zu Trustworthy AI und in der praktischen Auseinandersetzung mit AI-Systemen in Kundenprojekten sind wir immer wieder auf dasselbe Muster gestossen: Die schwierigsten Fragen entstehen nicht innerhalb einer einzelnen Disziplin. Sie entstehen zwischen ihnen.

Die Auseinandersetzung mit Trust und den richtigen Fragen begleitet uns dabei seit Jahren. Bereits 2018 betrachteten wir Trust in AI in On Trust in AI – A Systemic Approach aus unterschiedlichen Perspektiven, darunter Person, Process, Environment und Time. Zwei Jahre später untersuchten Marisa Tschopp und Marc Ruef im scip Labs Trust and AI – Three Wrong Questions, warum vermeintlich naheliegende Fragen wie Does the user trust our AI? oder How can we increase trust? am eigentlichen Problem vorbeiführen können. Der damalige Gedanke ist auch für unsere heutige Arbeit relevant: Bevor wir versuchen, Trust zu erzeugen oder zu erhöhen, sollten wir verstehen, welche Frage wir überhaupt beantworten wollen.

Eine Architektur kann sinnvoll sein, Security Controls können funktionieren, Governance kann definiert und ein Modell erfolgreich getestet sein. Trotzdem bleibt eine entscheidende Frage offen: Versteht eine Organisation ausreichend, warum sie diesem System in diesem Kontext vertrauen darf?

Wir haben uns deshalb intensiv damit auseinandergesetzt, wie sich technische, organisatorische und menschliche Perspektiven miteinander verbinden lassen. Aus Research, methodischer Entwicklung und praktischer Erfahrung ist unsere AAM Customer Journey entstanden. Nicht als weiterer AI Lifecycle. Sondern als eine Journey entlang von Fragen.

Vielleicht sind die Fragen wichtiger als die Antworten

AI ist inzwischen von Frameworks, Standards und Methoden umgeben. Lifecycles strukturieren Entwicklung und Betrieb. Security Frameworks betrachten Bedrohungen und Controls. Risk Frameworks strukturieren Risiken. Governance-Modelle definieren Verantwortlichkeiten. Regulierung schafft zusätzliche Anforderungen.

Wir brauchen diese Perspektiven. Aber sie beantworten unterschiedliche Fragen. Was passiert, wenn wir stattdessen beim AI-System selbst beginnen und fragen: Was müssen wir über dieses System wissen, damit wir begründet mit ihm arbeiten können?

Unsere Research- und Projektarbeit hat uns dabei zu acht grundlegenden Fragen geführt:

• Was haben wir, was wollen wir erreichen und was ist wirklich relevant?
• Wie sollten wir es gestalten?
• Funktioniert es tatsächlich wie beabsichtigt, auch unter widrigen Bedingungen?
• Wer trägt Verantwortung und wie behalten wir die Kontrolle?
• Haben wir genügend Evidence, um ihm zu vertrauen?
• Können wir darauf verantwortungsvoll Entscheidungen stützen?
• Wie schaffen wir mit Trustworthy AI organisatorischen Mehrwert?
• Woher wissen wir, dass es vertrauenswürdig bleibt?

Bevor Sie weiterlesen, lohnt sich ein kleiner Selbsttest:

Wie viele dieser Fragen können Sie für eine wichtige AI-Anwendung Ihrer Organisation heute überzeugend beantworten?

Nicht mit “wir haben dazu eine Policy”, nicht mit “das System wurde getestet” und auch nicht mit “der Hersteller erfüllt Standard X”. Sondern mit nachvollziehbarer Evidence. Vielleicht alle acht. Vielleicht entdecken Sie aber auch eine Frage, die schwieriger zu beantworten ist, als sie zunächst klingt.

Genau dafür sind die Fragen da.

Acht Fragen, nicht acht Phasen

Wir nennen diese acht Fragen:

Understand → Design → Validate → Govern → Trust → Decide → Transform → Improve

Gemeinsam bilden sie die AAM Customer Journey.

Der Begriff Journey kann zu einem Missverständnis führen. Die acht Steps sind keine Projektphasen, keine vorgeschriebene Reihenfolge von Assessments und auch keine acht Services, die nacheinander durchgeführt werden müssen.

Acht Fragen, nicht acht Phasen.

Eine Phase beschreibt typischerweise, was als Nächstes getan werden soll. Unsere Journey beschreibt dagegen, was eine Organisation verstehen, wissen, belegen und verantworten können muss.

Ein AI Red Team ist beispielsweise nicht automatisch eine Phase der Journey. Vielleicht steht eine Organisation vor der Frage, ob bestimmte Annahmen über ihr System tatsächlich belastbar sind. Daraus entsteht der Bedarf nach VALIDATE. Ein Red Team kann eine geeignete Methode sein, um dafür Evidence zu erzeugen. Die Aktivität folgt der Frage. Nicht umgekehrt.

UNDERSTAND – Wissen wir wirklich, was wir haben?

Was haben wir, was wollen wir erreichen und was ist wirklich relevant?

Stellen wir uns eine AI-Anwendung vor, die ursprünglich eingeführt wurde, um Dokumente zusammenzufassen. Zwei Jahre später nutzt ein Team ihre Ergebnisse zur Priorisierung von Kundenfällen. Das Modell ist vielleicht dasselbe. Seine Bedeutung ist es nicht.

UNDERSTAND fragt deshalb nicht nur, was gebaut wurde. Es fragt, was heute tatsächlich existiert, wie es genutzt wird und welche Menschen, Daten, Abhängigkeiten und Auswirkungen dazugehören.

Ein Inventar sagt uns, was vorhanden ist. Verständnis sagt uns, was es bedeutet.

DESIGN – Passt das Design noch zur Realität?

Wie sollten wir es gestalten?

AI-Systeme entwickeln sich weiter. Neue Datenquellen, Modelle, APIs, Agenten oder externe Services verändern Architektur und Abhängigkeiten. Bei einer bestehenden Lösung wird aus der ursprünglichen Designfrage deshalb eine weitere: Ist das, was wir heute haben, noch angemessen für das, was daraus geworden ist? Eine Architektur kann technisch funktionieren und trotzdem nicht mehr zum tatsächlichen Einsatz passen.

DESIGN bedeutet deshalb bewusste Gestaltung und die Bereitschaft, diese Gestaltung erneut zu hinterfragen, wenn sich Zweck, System oder Umfeld verändern.

Gutes Design muss auch bei einem sich verändernden System bewusstes Design bleiben.

VALIDATE – Welche unserer Annahmen halten tatsächlich?

Funktioniert es tatsächlich wie beabsichtigt auch unter widrigen Bedingungen?

Ein AI-System wurde umfassend getestet. Sechs Monate später wurde das Modell aktualisiert, eine neue Datenquelle integriert und ein Agent erhielt Zugriff auf zusätzliche Tools. Was genau beweist der damalige Test heute noch? Jedes Design enthält Annahmen über Daten, Controls, Benutzer, Systemgrenzen oder das Verhalten eines Modells. Doch eine Annahme ist noch keine Evidence.

VALIDATE stellt diese Annahmen der Realität gegenüber auch unter unerwarteten oder adversarial Bedingungen.

Das Ziel lautet deshalb nicht: Wir haben das System getestet. Sondern: Wir haben Evidence dafür, dass unsere Annahmen halten. Und wenn eine Annahme nicht hält, wissen wir ebenfalls mehr als vorher.

Das ist kein Scheitern von Assurance. Es ist Evidence.

GOVERN – Wer ist wirklich in Kontrolle?

Wer trägt Verantwortung und wie behalten wir die Kontrolle?

Ein Mensch trifft die finale Entscheidung. Auf dem Prozessdiagramm ist Human Oversight damit erfüllt. Was aber, wenn dieser Mensch hunderte AI-Empfehlungen pro Tag beurteilt, fast alle übernimmt und weder Zeit noch Informationen besitzt, um sie ernsthaft zu hinterfragen? Haben wir Human Oversight oder einen menschlichen Bestätigungsschritt? Governance wird nicht dadurch wirksam, dass Verantwortung dokumentiert ist. Sie wird wirksam, wenn Verantwortung tatsächlich wahrgenommen werden kann.

GOVERN fragt deshalb nicht nur, wer auf dem Papier verantwortlich ist, sondern wer verändern, freigeben, eingreifen, Risiken akzeptieren und letztlich Verantwortung übernehmen kann.

Governance muss nicht nur existieren. Sie muss funktionieren.

TRUST – Vertrauen wir, oder hoffen wir?

Haben wir genügend Evidence, um ihm zu vertrauen?

Das Modell erzielt gute Resultate. Die Architektur wurde geprüft. Security Controls sind implementiert. Governance ist definiert. Aber niemand kann genau sagen, unter welchen Bedingungen seine Ergebnisse nicht verwendet werden sollten. Ist das Vertrauen oder Hoffnung? Trust ist für uns weder ein Zertifikat noch eine permanente Eigenschaft eines AI-Systems. Ein System kann für einen bestimmten Zweck, unter bestimmten Bedingungen und innerhalb bekannter Grenzen ausreichend vertrauenswürdig sein und für einen anderen Einsatz nicht.

Die Frage: Ist diese AI vertrauenswürdig? ist zu grob. Interessanter ist: Für welchen Zweck, unter welchen Bedingungen, auf Basis welcher Evidence und innerhalb welcher Grenzen ist unser Vertrauen begründet? Trustworthy AI bedeutet damit nicht, Unsicherheit vollständig zu beseitigen. Es bedeutet, genügend zu wissen, um Vertrauen begründen und dessen Grenzen erkennen zu können.

DECIDE – Was folgt aus unserem Vertrauen?

Können wir darauf verantwortungsvoll Entscheidungen stützen?

Begründbares Vertrauen in ein AI-System ist wichtig. Es ist aber nicht dasselbe wie eine begründbare Entscheidung, die mit seiner Unterstützung getroffen wird. Genau an diesem Übergang beginnt für uns Decision Security. In unserer Publikation Decision Security – From Secure Information to Trustworthy Decisions untersuchen wir den gesamten Weg von Information über Interpretation und Empfehlung bis zu Entscheidung und Wirkung.

Für die Customer Journey bleibt hier eine Frage: Wenn wir begründen können, warum wir dem System vertrauen, können wir auch begründen, was wir aufgrund dieses Vertrauens tun?

TRANSFORM – Kann Vertrauen Handlungsfähigkeit schaffen?

Wie schaffen wir mit Trustworthy AI organisatorischen Mehrwert?

Trustworthy AI ist kein Selbstzweck. Organisationen investieren in AI, weil sie Wissen erschliessen, Menschen unterstützen, Prozesse verbessern oder neue Fähigkeiten schaffen wollen. Begründbares Vertrauen soll deshalb nicht nur Grenzen aufzeigen. Es soll ermöglichen, bewusst zu entscheiden, wo AI sinnvoll eingesetzt werden kann, wo menschliche Beurteilung notwendig bleibt und wo ein Einsatz nicht angemessen ist. Assurance und Innovation sind damit keine Gegenspieler.

Trust muss verantwortungsvolles Handeln ermöglichen.

IMPROVE – Was hat uns die Realität beigebracht?

Woher wissen wir, dass es vertrauenswürdig bleibt?

Ein AI-System kann technisch unverändert bleiben und sich trotzdem verändern. Menschen nutzen es anders, Daten verschieben sich, neue Bedrohungen entstehen oder die Bedeutung seiner Empfehlungen wächst. Damit verändert sich auch die Grundlage unseres Vertrauens. Reality produces new evidence. Reale Nutzung, Incidents, Near Misses und tatsächliche Entscheidungen liefern Evidence, die beim ursprünglichen Assessment noch gar nicht existieren konnte. Sie kann unsere Annahmen bestätigen oder widerlegen.

IMPROVE führt deshalb zurück zu UNDERSTAND: Nicht weil eine Customer Journey einen schönen Kreis benötigt, sondern weil neue Evidence unser Verständnis verändern kann.

Sie müssen nicht am Anfang beginnen

Vielleicht betreiben Sie bereits AI-Systeme und denken an dieser Stelle: Für uns kommt diese Journey zu spät. Das Gegenteil ist der Fall.

Die Reise hat eine Richtung, aber keinen festgelegten Einstiegspunkt.

Die Fragen gelten für eine erste Idee genauso wie für ein System mitten in der Entwicklung oder eine Lösung, die seit Jahren produktiv eingesetzt wird.

Gerade bestehende Systeme sind interessant. Neue Datenquellen werden angebunden, Modelle ausgetauscht, APIs und Agenten kommen hinzu, Berechtigungen verändern sich und Menschen entdecken neue Nutzungsweisen. Eine ursprünglich unterstützende Funktion kann schleichend zu einem relevanten Bestandteil eines Entscheidungsprozesses werden. Das System trägt noch denselben Namen. Aber ist es noch dasselbe System? Mit der Zeit können Beabsichtigte Nutzung und tatsächliche Nutzung, geplante Architektur und entstandene Architektur oder angenommene Kontrollmassnahmen und wirksame Kontrollmassnahmen auseinanderdriften.

Bestehende Systeme besitzen gleichzeitig etwas, das eine neue Initiative noch gar nicht haben kann: Reale Nutzung und reale Evidence. Der technische Reifegrad bestimmt deshalb nicht, wo die Journey beginnen muss. Die relevante Frage bestimmt den Einstiegspunkt.

Von AI-Verständnis zu begründbaren Entscheidungen

Darin liegt für uns der Kern der AAM Customer Journey: Von AI-Verständnis zur Fähigkeit, die damit getroffenen Entscheidungen zu begründen. Wir verstehen dies als: AI verstehen. Vertrauen begründen. Entscheidungen verantworten.

Eine Organisation sollte nicht nur erklären können, welches Modell sie verwendet, welche Controls implementiert oder welche Tests durchgeführt wurden. Sie sollte begründen können, warum dieses System für diesen Zweck eingesetzt wird, welche Annahmen gelten, welche Evidence diese stützt, welche Grenzen bekannt sind, welche Unsicherheit verbleibt und wie weit das daraus entstehende Vertrauen reichen darf. Das ist etwas anderes als: Unsere AI hat das Assessment bestanden. Die stärkere Aussage lautet: Wir wissen, warum wir ihr vertrauen und wir kennen die Grenzen dieses Vertrauens.

Eine vereinfachte Darstellung von Justified Trust

Die acht Fragen betrachten unterschiedliche Aspekte eines AI-Systems. Zusammengenommen schaffen sie eine Grundlage, auf der Vertrauen begründet werden kann.

Diesen Zusammenhang können wir als vereinfachte Darstellung ausdrücken:

T_t = f(C_t, E_t, L_t, U_t, G_t)

Dabei steht:

• T für Justified Trust das für einen bestimmten Zweck begründbare Vertrauen in das AI-System.
• C für Context Zweck, Einsatzumgebung, betroffene Menschen, Prozesse, Daten und die tatsächliche Nutzung.
• E für Evidence Beobachtungen, Tests, Reviews und andere belastbare Erkenntnisse, mit denen Annahmen bestätigt oder widerlegt werden können.
• L für Known Limitations bekannte Grenzen des Systems, seiner Modelle, Daten, Architektur und des vorgesehenen Einsatzes.
• U für Uncertainty die verbleibende Unsicherheit darüber, was wir nicht oder noch nicht ausreichend sicher beurteilen können.
• G für Governance and Effective Controls Verantwortung, Entscheidungsbefugnisse und tatsächlich wirksame technische, organisatorische und menschliche Kontrollmechanismen.

Die Funktion ist bewusst kein Trust Score und keine mathematische Berechnung von Vertrauen. Sie ist eine vereinfachte Darstellung der Faktoren, die unsere Beurteilung von Justified Trust beeinflussen.

Auch die Verbindung zur Journey ist bewusst nicht vollständig eins zu eins. UNDERSTAND schafft vor allem Context C. DESIGN macht Annahmen, Abhängigkeiten und Known Limitations L sichtbar. VALIDATE erzeugt und hinterfragt Evidence E. GOVERN etabliert Verantwortung und Effective Controls G. Diese Erkenntnisse bilden gemeinsam eine Grundlage für TRUST.

Eine Variable verhält sich jedoch anders: Uncertainty U gehört keinem einzelnen Journey Step.

Unsicherheit zieht sich durch die gesamte Journey. Wir können uns über den Kontext unsicher sein, Designannahmen nicht ausreichend kennen, durch Validation neue Unsicherheit entdecken oder bei Entscheidungen mit verbleibender Unsicherheit umgehen müssen. Daraus folgt etwas zunächst vielleicht Überraschendes: Mehr Evidence bedeutet nicht zwangsläufig weniger Unsicherheit. Manchmal macht neue Evidence Unsicherheit sichtbar, von der wir bisher nicht wussten, dass sie existiert.

Evidence kann Unsicherheit reduzieren. Sie kann aber ebenso zeigen, dass eine bisher vermeintlich klare Grenze weniger klar ist als angenommen. Das ist ein wichtiger Unterschied zwischen L und U: Known Limitations beschreiben Grenzen, die wir kennen. Uncertainty beschreibt, wie sicher wir uns über unser Wissen und diese Grenzen überhaupt sein können.

Auch deshalb besitzt T einen Zeitindex. Vereinfacht gilt zu einem Zeitpunkt t0:

T_t0 = f(C_t0, E_t0, L_t0, U_t0, G_t0)

Zu einem späteren Zeitpunkt t1 kann die Beurteilung auf einer veränderten Grundlage erfolgen:

T_t1 = f(C_t1, E_t1, L_t1, U_t1, G_t1)

Nicht zwangsläufig, weil das System schlechter geworden ist. Sondern weil wir mehr, weniger oder anderes über das System wissen.

Diese vereinfachte Darstellung verstehen wir nicht als abschliessende Formalisierung von Trust. Sie ist eine Verdichtung unserer bisherigen Arbeit und gleichzeitig Ausgangspunkt für weitere Research-Fragen. Wie verändert neue Evidence die Qualität von Trust? Wann verliert vorhandene Evidence ihre Aussagekraft? Wie beschreiben wir verbleibende Uncertainty? Welche Veränderungen erfordern eine erneute Beurteilung? Und wie weit darf Justified Trust reichen, bevor daraus Entscheidungen und Handlungen entstehen?

Unsere Überlegungen stehen dabei nicht isoliert. Eine 2026 in Nature Reviews Psychology veröffentlichte Arbeit von Forschenden der University of Kent und des Uehiro Oxford Institute der University of Oxford unterscheidet ausdrücklich zwischen Trustworthiness, Trust und Trusting Behaviour und beschreibt Trust in AI als multidimensional, dynamisch und kontextabhängig. Diese Unterscheidung ist auch für unsere Betrachtung relevant: Die Eigenschaften eines Systems, das Vertrauen eines Menschen in dieses System und das daraus resultierende Handeln sind miteinander verbunden, aber nicht dasselbe.

Auch Evidence und Uncertainty verdienen eine differenzierte Betrachtung. Eine in MIT News vorgestellte Forschungsarbeit zur Uncertainty Quantification zeigt beispielsweise, wie wichtig belastbare und gut kalibrierte Unsicherheitsschätzungen für die Beurteilung von Modellaussagen sind. Gleichzeitig beschreibt die über das Stanford Center for International Security and Cooperation veröffentlichte Arbeit Mind the Gap: The Challenges of Assurance for Artificial Intelligence AI Assurance als eine Sammlung von Ansätzen und Techniken zur Beurteilung von Qualität, Reliability und Trustworthiness und weist zugleich auf die Grenzen eines noch jungen Assurance-Ökosystems hin. Assurance schafft damit nicht automatisch Trust. Sie kann aber Evidence erzeugen, bestehende Annahmen prüfen und sichtbar machen, was wir noch nicht ausreichend wissen.

Diese Fragen führen uns bereits weiter. Eine unserer aktuellen Überlegungen betrifft das Verhältnis zwischen Justified Trust und dem, was wir vorläufig als Assurance-backed Trust bezeichnen: Vertrauen, dessen relevante Grundlagen und Annahmen nicht nur nachvollziehbar sind, sondern durch geeignete Assurance-Aktivitäten und belastbare Evidence systematisch hinterfragt wurden. Dabei interessiert uns insbesondere, was tatsächlich überprüft werden kann. Vielleicht ist es weniger der Trust selbst als vielmehr die Annahmen, auf denen er beruht. Verification erzeugt neue Evidence, diese verändert unser Wissen und kann gleichzeitig neue Uncertainty sichtbar machen. Wie weit sich daraus ein belastbares methodisches Konzept entwickeln lässt, ist eine der Fragen, die wir weiter untersuchen.

Die Funktion schliesst unsere Research-Arbeit nicht ab. Sie öffnet die nächsten Fragen.

Fazit

AI Assurance braucht aus unserer Sicht nicht einfach mehr Controls, Frameworks oder abgeschlossene Assessments. Sie braucht Organisationen, die die richtigen Fragen stellen, belastbare Evidence erzeugen und daraus begründen können, warum und wie weit sie einer AI vertrauen.

Genau dafür haben wir die AAM Customer Journey entwickelt. Ihre acht Fragen verbinden technische, organisatorische und menschliche Perspektiven. Sie funktionieren bei einer ersten Idee ebenso wie bei einer längst produktiven AI. Nicht der Lifecycle bestimmt den Einstiegspunkt, sondern die Frage, die heute beantwortet werden muss.

AI verstehen. Vertrauen begründen. Entscheidungen verantworten.

Unsere bisherige Research- und Projektarbeit zeigt gleichzeitig, dass dieser Weg neue Fragen hervorbringt. Die Beziehung zwischen Evidence, Uncertainty und Justified Trust gehört dazu. Ebenso die zeitliche Veränderung von Vertrauen und der Übergang von vertrauenswürdigen Systemen zu verantwortbaren Entscheidungen. Mit Decision Security verfolgen wir bereits einen dieser Übergänge als dedizierte Research-Arbeit.

Weitere Fragen werden folgen. Das ist gewollt. Denn AI-Systeme entwickeln sich. Menschen verändern ihre Nutzung. Neue Abhängigkeiten entstehen. Und Erkenntnisse, die heute belastbar sind, müssen es morgen nicht automatisch noch sein. Reife im Umgang mit AI bedeutet deshalb für uns nicht, irgendwann jede Frage endgültig beantwortet zu haben.

Sie bedeutet zu erkennen, welche Frage als Nächstes gestellt werden muss und bereit zu sein, die Antwort von gestern erneut zu hinterfragen.

Über den Autor

Simon Zumstein arbeitet seit Beginn der 1990er Jahre im IT-Bereich, wobei er als Engineer, Projektleiter, Security Consultant und CIO tätig war. Ganzheitliches Risikomanagement mit Einbezug der betriebswirtschaftlichen Aspekte und der Darstellbarkeit gegenüber den Entscheidungsträgern sind sein Fachgebiet.

Links

• https://cisac.fsi.stanford.edu/publication/mind-gap-challenges-assurance-artificial-intelligence
• https://news.mit.edu/2024/when-to-trust-ai-model-0711
• https://www.scip.ch/?labs.20180823
• https://www.scip.ch/?labs.20201112
• https://www.scip.ch/?labs.20260813
• https://www.uehiro.ox.ac.uk/publication/2412891/ora-hyrax