How to Build Trustworthy AI: A 4-Pillar Framework for Project Teams
This article is adapted from an episode of The Digital Project Manager podcast, featuring a conversation between host Galen Low and Cal Al-Dhubaib, Head of AI & Data Science at Further. Listen to it here.
Trust Ownership: Lack of individual responsibility often undermines trust in AI projects, complicating accountability.
Trust Engineering: A framework called trust engineering promotes a common language among diverse stakeholders in AI design.
Four Pillars: Trustworthy AI relies on four pillars: expectation management, decision design, governance, and trust infrastructure.
Project Questions: Teams should consider three key questions to ensure effective governance and risk management in AI solutions.
Measuring Trust: User behavior serves as a critical indicator of trust and effectiveness in AI systems.
Why Trust Needs an Owner
Most AI projects run into the same problem before they even get off the ground: nobody is explicitly responsible for whether the system can be trusted. Cal Al-Dhubaib, Head of AI & Data Science at Further, has seen this play out across industries, and he's blunt about the root cause. "The easy answer to that is by default, no one owns it, and that's the big problem," he says.
No one owns it [AI trust], and that’s the big problem.
The issue isn't a lack of concern — it's a lack of clarity about whose job it actually is. "An interesting thing about accountability is if it's everybody's responsibility, nobody owns it, and so you ultimately need an individual who is going to own this aspect," Al-Dhubaib explains. At Further, that principle isn't just theoretical. "We actually have one assigned to every one of these AI projects so that we can make sure that we're asking the right questions."
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
What Trust Engineering Actually Is
Al-Dhubaib's answer to the ownership gap is a framework he calls trust engineering — essentially a shared language for the many disciplines that touch an AI system. "It's a shared communication toolkit to help various different personas who collaborate around the design of AI solutions and adoption of AI solutions to talk more productively about preserving trust," he says.
The need for that shared toolkit comes from how fragmented the conversation usually is. Engineers, risk managers, governance leads, UX designers, and business stakeholders all look at the same system through different lenses. "There needed to be some shared way for all these people to talk about the same thing and have this similar understanding of the ways in which trust can be violated with AI," Al-Dhubaib says, "and the toolkits of how to defend against that."
There needed to be some shared way for all these people to talk about the same thing and have this similar understanding of the ways in which trust can be violated with AI.
The 4 Pillars of Trustworthy AI
Trust engineering breaks down into four practical pillars — expectation management, decision design, governance, and trust infrastructure. Each one addresses a different point where AI systems tend to lose people's confidence.
Pillar 1: Expectation Management
The first pillar is about scope. Generative AI systems are often too open-ended for their own good, and that openness can overwhelm the very users they're meant to help. "It's nice to have a limited range of what can I do with this tool," Al-Dhubaib notes.
He points to a real-world example from his work with Behr Paint, where the goal was to reduce decision fatigue in color selection. "You go to Home Depot and you see the big display of paint colors," he says, describing how customers — including himself — get stuck. "And, you get very overwhelmed if you have to pick." The fix wasn't more AI — it was a tighter, more deliberately scoped experience.
Pillar 2: Decision Design
The second pillar is about the guardrails placed around the choices an AI system is allowed to make. "How do you prompt the users with the right amount of information and the right amount of guardrails so that they know how to use the system well?" Al-Dhubaib asks.
In the Behr Paint project, this meant drawing a hard line around what kind of advice the AI could safely give. Color selection was fair game; anything touching paint mixing or application required a handoff to a human. "If at any point in the conversation it starts to veer into that direction, it quickly prompts the user with, here's our hotline for help with this particular inquiry," Al-Dhubaib says.
If at any point in the conversation it starts to veer into that direction, it quickly prompts the user with, here's our hotline for help with this particular inquiry.
The system was also built with reputational guardrails in mind — "it also doesn't get bullied into saying things that you don't want it to say and get screenshot and put all over the internet."
Pillar 3: Governance
The third pillar addresses a question that can't be answered by engineers alone: what does "fair" or "correct" even mean for this specific business? Al-Dhubaib describes a project involving a model for student admissions, where the client wanted quality assured across demographics. "There's 22 different ways of calculating fairness," he says. "And frankly, that's outta scope for the engineer. I can tell you what formula is and how to calculate them in various different ways. I'm gonna need to lean on you to say, what is your policy? How are you approaching this definition and what is correct for you?"
That governance work doesn't stop at internal decisions — it has to be communicated outward too. As Al-Dhubaib puts it, all of this gets documented and shared "in a user friendly system card."
Pillar 4: Trust Infrastructure
The final pillar covers the tooling and processes that keep an AI system honest once it's live. He illustrates the pillar with a contrast between two well-known quick-service restaurant chains. One pulled its AI voice-ordering system after it couldn't consistently place accurate orders.
The other took a different approach: "You have Domino's on the other hand where 80% of their call in orders are now being handled by an AI system," with human supervisors monitoring live calls and stepping in when needed, and "appropriate auditing measures in place to make sure that orders are continuing to match up with what the user said." The difference, in Al-Dhubaib's view, wasn't the underlying technology. "I don't think that this was a failure in terms of the technology so much as a failure to put the right guardrails around the technology."
I don’t think that this was a failure in terms of the technology so much as a failure to put the right guardrails around the technology.
Three Questions Every Project Team Should Ask
Beyond the four pillars, Al-Dhubaib offers project teams a simple diagnostic for any AI governance conversation — three questions, asked in sequence.
First: "What have you done upfront to test and assert that you've minimized the potential harm or potential risks inherent to this AI solution?" Second, once the system is live: "How are you going to know when it's making a mistake?" And third — the question he says gets overlooked most often — "What do you do then? How do you get it done? Have you actually stress tested that plan?"
How to Know If It's Working
Trust isn't just a design principle; it's measurable. Al-Dhubaib points to user behavior as one of the clearest signals a team has. "Is the user accomplishing your goal?" he asks, using the Behr example again — are people actually reaching the point of learning more about a paint spec, completing the interaction, and coming back to the tool.
Ultimately, he ties usefulness directly back to trust itself: "We're simply not useful — because that's also a part of trust."
The Bottom Line
Trust engineering isn't a checklist that gets bolted on at the end of a project — it's a series of design choices made throughout, about what the system will and won't do, and who is accountable for each decision. As Al-Dhubaib puts it, "You have to define what is correct and what assumptions you going to assert. These are all design choices that can happen as a part of trust engineering."
Want more insights like these? Sign up for a free DPM account to hear from more experts like these.
