A new AI idea emerges. Another system is currently being developed. A third has long been facing the realities of operational use. They are at entirely different points, yet they lead to the same fundamental questions: What do we need to know, what can we substantiate, and how far can we trust? Our project and research work has led us to eight questions. Not eight phases, but a Journey that begins wherever your relevant question lies.

Eight Questions for Trustworthy AI

Your AI is in production. It has been tested. Security has reviewed it. Governance is defined. Users are working with it.

Can you explain why you trust it?

Do you also know what the system is actually being used for today? Whether its original assumptions still hold? What Evidence supports those assumptions? Where the boundaries of trust lie? And who is accountable for a decision made with its support?

One seemingly simple question quickly leads to others. That is no coincidence.

In our research on Trustworthy AI and our practical work with AI systems in customer projects, we have repeatedly encountered the same pattern: The most difficult questions do not arise within a single discipline. They arise between them.

Our exploration of Trust and the right questions has accompanied us for years. As early as 2018, we examined Trust in AI from different perspectives, including Person, Process, Environment, and Time, in On Trust in AI – A Systemic Approach. Two years later, Marisa Tschopp and Marc Ruef explored in the scip Labs Trust and AI – Three Wrong Questions why seemingly obvious questions such as Does the user trust our AI? or How can we increase trust? may miss the underlying issue. The idea remains relevant to our work today: Before we try to create or increase Trust, we should understand which question we are actually trying to answer.

An architecture may be sound, Security Controls may work, Governance may be defined, and a model may have been successfully tested. Yet one crucial question can remain unanswered: Does the organisation understand sufficiently why it may trust this system in this context?

We have therefore examined in depth how technical, organisational, and human perspectives can be brought together. Our AAM Customer Journey emerged from research, methodological development, and practical experience. Not as yet another AI Lifecycle. But as a Journey structured around questions.

Perhaps the Questions Matter More Than the Answers

AI is now surrounded by frameworks, standards, and methodologies. Lifecycles structure development and operation. Security Frameworks address threats and Controls. Risk Frameworks structure risks. Governance models define responsibilities. Regulation introduces additional requirements.

We need these perspectives. But they answer different questions. What happens if, instead, we start with the AI system itself and ask: What do we need to know about this system in order to work with it on a justified basis?

Our research and project work has led us to eight fundamental questions:

• What do we have, what do we want to achieve, and what really matters?
• How should we design it?
• Does it actually work as intended, including under adverse conditions?
• Who is accountable, and how do we remain in control?
• Do we have sufficient Evidence to trust it?
• Can we responsibly base decisions on it?
• How do we create organisational value with Trustworthy AI?
• How do we know that it remains trustworthy?

Before reading on, a brief self-test may be worthwhile:

How many of these questions can you convincingly answer today for an important AI application in your organisation?

Not with “we have a policy for that”, not with “the system was tested”, and not with “the vendor complies with Standard X”. But with traceable Evidence. Perhaps you can answer all eight. Or perhaps you will discover a question that is more difficult to answer than it first appears.

That is exactly what these questions are for.

Eight Questions, Not Eight Phases

We call these eight questions:

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

Together, they form the AAM Customer Journey.

The term Journey can create a misunderstanding. The eight Steps are not project phases, not a prescribed sequence of Assessments, and not eight Services that must be performed one after another.

Eight questions, not eight phases.

A phase typically describes what should be done next. Our Journey, by contrast, describes what an organisation must be able to understand, know, substantiate, and take responsibility for.

An AI Red Team, for example, is not automatically a phase of the Journey. An organisation may instead be facing the question of whether certain assumptions about its system are actually robust. That creates a need for VALIDATE. A Red Team may be an appropriate method for generating Evidence. The activity follows the question. Not the other way around.

UNDERSTAND – Do We Really Know What We Have?

What do we have, what do we want to achieve, and what really matters?

Imagine an AI application originally introduced to summarise documents. Two years later, a team uses its outputs to prioritise customer cases. The model may still be the same. Its significance is not.

UNDERSTAND therefore asks more than what was built. It asks what actually exists today, how it is being used, and which people, data, dependencies, and impacts are involved.

An inventory tells us what is there. Understanding tells us what it means.

DESIGN – Does the Design Still Match Reality?

How should we design it?

AI systems evolve. New data sources, models, APIs, agents, or external services change architectures and dependencies. For an existing solution, the original design question therefore becomes another one: Is what we have today still appropriate for what the system has become? An architecture may work technically and still no longer fit its actual use.

DESIGN therefore means deliberate design and a willingness to reconsider that design when the purpose, system, or environment changes.

Good design must remain deliberate design even as the system evolves.

VALIDATE – Which of Our Assumptions Actually Hold?

Does it actually work as intended, including under adverse conditions?

An AI system has been extensively tested. Six months later, the model is updated, a new data source is integrated, and an agent is given access to additional tools. What exactly does the original test still prove today? Every design contains assumptions about data, Controls, users, system boundaries, or model behaviour. But an assumption is not yet Evidence.

VALIDATE confronts these assumptions with reality, including under unexpected or adversarial conditions.

The objective is therefore not: We tested the system. It is: We have Evidence that our assumptions hold. And if an assumption does not hold, we also know more than we did before.

That is not a failure of Assurance. It is Evidence.

GOVERN – Who Is Really in Control?

Who is accountable, and how do we remain in control?

A human makes the final decision. On the process diagram, Human Oversight is therefore satisfied. But what if that person reviews hundreds of AI recommendations every day, accepts almost all of them, and has neither the time nor the information required to challenge them meaningfully? Do we have Human Oversight, or merely a human confirmation step? Governance does not become effective simply because responsibility has been documented. It becomes effective when responsibility can actually be exercised.

GOVERN therefore asks not only who is responsible on paper, but who can make changes, grant approval, intervene, accept risks, and ultimately assume accountability.

Governance must not merely exist. It must work.

TRUST – Do We Trust, or Do We Hope?

Do we have sufficient Evidence to trust it?

The model produces good results. The architecture has been reviewed. Security Controls are implemented. Governance is defined. Yet nobody can say precisely under which conditions its outputs should not be used. Is that trust, or hope? For us, Trust is neither a certificate nor a permanent property of an AI system. A system may be sufficiently trustworthy for a particular purpose, under specific conditions, and within known boundaries, while not being trustworthy for another use.

The question “Is this AI trustworthy?” is too broad. A more interesting question is: For what purpose, under which conditions, on the basis of what Evidence, and within which boundaries is our trust justified? Trustworthy AI therefore does not mean eliminating uncertainty completely. It means knowing enough to justify trust and recognise its boundaries.

DECIDE – What Follows From Our Trust?

Can we responsibly base decisions on it?

Justified trust in an AI system is important. But it is not the same as a justifiable decision made with its support. This transition is where Decision Security begins for us. In our publication Decision Security – From Secure Information to Trustworthy Decisions, we examine the entire path from information through interpretation and recommendation to decision and impact.

For the Customer Journey, one question remains: If we can justify why we trust the system, can we also justify what we do on the basis of that trust?

TRANSFORM – Can Trust Create the Ability to Act?

How do we create organisational value with Trustworthy AI?

Trustworthy AI is not an end in itself. Organisations invest in AI because they want to unlock knowledge, support people, improve processes, or create new capabilities. Justified trust should therefore do more than reveal boundaries. It should enable conscious decisions about where AI can be used meaningfully, where human judgement remains necessary, and where its use is inappropriate. Assurance and innovation are therefore not opposing forces.

Trust must enable responsible action.

IMPROVE – What Has Reality Taught Us?

How do we know that it remains trustworthy?

An AI system can remain technically unchanged and still change in practice. People use it differently, data shifts, new threats emerge, or the significance of its recommendations increases. The basis of our trust changes with it. Reality produces new evidence. Real-world use, Incidents, Near Misses, and actual decisions generate Evidence that could not have existed at the time of the original Assessment. It may confirm or contradict our assumptions.

IMPROVE therefore leads back to UNDERSTAND: Not because a Customer Journey needs an aesthetically pleasing circle, but because new Evidence can change our understanding.

You Do Not Have to Start at the Beginning

Perhaps you already operate AI systems and are thinking at this point: This Journey comes too late for us. The opposite is true.

The Journey has a direction, but no mandatory entry point.

The questions apply just as much to an initial idea as they do to a system in the middle of development or a solution that has been in production for years.

Existing systems are particularly interesting. New data sources are connected, models are replaced, APIs and agents are added, permissions change, and people discover new ways of using them. A function originally intended to provide support can gradually become a relevant part of a decision-making process. The system still has the same name. But is it still the same system? Over time, intended use and actual use, planned architecture and evolved architecture, or assumed controls and effective controls can drift apart.

At the same time, existing systems possess something that a new initiative cannot yet have: Real-world use and real-world Evidence. Technical maturity therefore does not determine where the Journey must begin. The relevant question determines the entry point.

From Understanding AI to Justifying Decisions

This is the essence of the AAM Customer Journey for us: From understanding AI to being able to justify the decisions made with it. We express this as: Understand AI. Justify trust. Take responsibility for decisions.

An organisation should be able to explain more than which model it uses, which Controls it has implemented, or which tests have been performed. It should be able to justify why this system is being used for this purpose, which assumptions apply, what Evidence supports them, which limitations are known, what Uncertainty remains, and how far the resulting trust may extend. That is different from saying: Our AI passed the Assessment. The stronger statement is: We know why we trust it, and we know the boundaries of that trust.

A Simplified Representation of Justified Trust

The eight questions examine different aspects of an AI system. Taken together, they create a foundation on which trust can be justified.

We can express this relationship as a simplified representation:

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

Where:

• T represents Justified Trust: the trust in an AI system that can be justified for a specific purpose.
• C represents Context: purpose, operating environment, affected people, processes, data, and actual use.
• E represents Evidence: observations, tests, reviews, and other robust findings that can confirm or challenge assumptions.
• L represents Known Limitations: known boundaries of the system, its models, data, architecture, and intended use.
• U represents Uncertainty: the remaining uncertainty about what we do not know or cannot yet assess with sufficient confidence.
• G represents Governance and Effective Controls: accountability, decision rights, and technical, organisational, and human control mechanisms that are actually effective.

The function is deliberately not a Trust Score and not a mathematical calculation of trust. It is a simplified representation of the factors that influence our assessment of Justified Trust.

The relationship to the Journey is also deliberately not entirely one-to-one. UNDERSTAND primarily establishes Context C. DESIGN makes assumptions, dependencies, and Known Limitations L visible. VALIDATE generates and challenges Evidence E. GOVERN establishes accountability and Effective Controls G. Together, these insights provide a foundation for TRUST.

One variable behaves differently, however: Uncertainty U does not belong to any single Journey Step.

Uncertainty runs through the entire Journey. We may be uncertain about the Context, may not sufficiently understand design assumptions, may discover new uncertainty through Validation, or may have to make decisions while uncertainty remains. This leads to a perhaps initially surprising conclusion: More Evidence does not necessarily mean less Uncertainty. Sometimes new Evidence reveals Uncertainty we did not know existed.

Evidence can reduce Uncertainty. But it can equally reveal that a boundary we previously considered clear is less certain than assumed. This is an important distinction between L and U: Known Limitations describe boundaries we know. Uncertainty describes how confident we can be about our knowledge and those boundaries in the first place.

This is also why T has a time index. At a given point in time t0, we can simplify the relationship as:

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

At a later point in time t1, the assessment may be based on a changed foundation:

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

Not necessarily because the system has become worse. But because we know more, less, or something different about it.

We do not consider this simplified representation to be a final formalisation of Trust. It is a condensation of our work so far and, at the same time, a starting point for further research questions. How does new Evidence change the quality of Trust? When does existing Evidence lose its relevance? How do we describe remaining Uncertainty? Which changes require reassessment? And how far may Justified Trust extend before decisions and actions are based upon it?

Our considerations do not exist in isolation. A 2026 paper published in Nature Reviews Psychology by researchers from the University of Kent and the Uehiro Oxford Institute at the University of Oxford explicitly distinguishes between Trustworthiness, Trust, and Trusting Behaviour and describes Trust in AI as multidimensional, dynamic, and context-dependent. This distinction is also relevant to our perspective: The properties of a system, a person’s trust in that system, and the behaviour resulting from that trust are interconnected, but they are not the same thing.

Evidence and Uncertainty also deserve a differentiated view. A research paper on Uncertainty Quantification presented by MIT News illustrates, for example, the importance of reliable and well-calibrated uncertainty estimates when assessing model outputs. At the same time, the paper Mind the Gap: The Challenges of Assurance for Artificial Intelligence, published through the Stanford Center for International Security and Cooperation, describes AI Assurance as a collection of approaches and techniques for assessing quality, Reliability, and Trustworthiness, while also pointing to the limitations of a still-maturing Assurance ecosystem. Assurance therefore does not automatically create Trust. But it can generate Evidence, challenge existing assumptions, and reveal what we still do not know well enough.

These questions are already taking us further. One of our current lines of thought concerns the relationship between Justified Trust and what we provisionally refer to as Assurance-backed Trust: trust whose relevant foundations and assumptions are not only understandable, but have been systematically challenged through appropriate Assurance activities and robust Evidence. We are particularly interested in what can actually be verified. Perhaps it is less the Trust itself than the assumptions on which it rests. Verification generates new Evidence; that Evidence changes what we know and can, at the same time, reveal new Uncertainty. How far this line of thought can be developed into a robust methodological concept is one of the questions we continue to investigate.

The function does not conclude our research. It opens the next questions.

Conclusion

From our perspective, AI Assurance does not simply require more Controls, Frameworks, or completed Assessments. It requires organisations that ask the right questions, generate robust Evidence, and can use it to justify why and how far they trust an AI system.

That is precisely why we developed the AAM Customer Journey. Its eight questions connect technical, organisational, and human perspectives. They apply to an initial idea just as much as to an AI system that has long been in production. The Lifecycle does not determine the entry point. The question that needs to be answered today does.

Understand AI. Justify trust. Take responsibility for decisions.

At the same time, our research and project work to date shows that this path generates new questions. The relationship between Evidence, Uncertainty, and Justified Trust is one of them. So is the way trust changes over time and the transition from trustworthy systems to responsible decisions. With Decision Security, we are already pursuing one of these transitions as a dedicated line of research.

More questions will follow. That is intentional. AI systems evolve. People change how they use them. New dependencies emerge. And insights that are robust today may not automatically remain so tomorrow. For us, maturity in AI therefore does not mean having answered every question once and for all.

It means knowing which question needs to be asked next and being prepared to challenge yesterday’s answer.

About the Author

Simon Zumstein has been working in IT since the 1990s as an engineer, project lead, security consultant and CIO. Integral risk management while taking managerial-economic factors and the presentability to decision makers are his area of expertise.

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