Building Trustworthy AI: A Practical Solution Guide for Enterprise AI Teams

Introduction

In my previous post, I described the time I spent helping build IBM Cloud for Financial Services — a platform-level response to the unique compliance demands of the financial services industry. In fall 2023, I shifted focus and joined the newly formed AI Center of Excellence (CoE) in the IBM Infrastructure business unit — a large organization responsible for IBM Cloud, IBM Power, IBM Z, IBM Storage, and more. The CoE’s mission is to accelerate the development of safe AI solutions across the business unit as part of an internal transformation intended to improve productivity and employee satisfaction. That means helping teams navigate the sharp turn from traditional software development to generative AI application development, and doing it responsibly.

The result of that work is an internal AI Solution Guide and Questionnaire that I led from inception through development. It spans AI concepts, architecture patterns, security and compliance guidance, a layered controls framework, an AI application pipeline, reference architectures, and a self-assessment questionnaire. The guide has been referenced at the highest levels of the organization and adopted as the recommended way to govern AI development. It’s also being used to help inform broader corporate guidelines in this area.

This post is a reflection on what the guide addresses and why the problems it tackles are harder than they first appear.

The Problem: AI Is Not Just Software With a New Coat of Paint

Enterprise teams are quick to recognize that generative AI unlocks new possibilities. They are slower to recognize that it also introduces an entirely new class of risk — layered on top of the existing risks that already make traditional software hard to secure and govern.

AI applications carry all the familiar risks: inadequate access controls, unencrypted data at rest and in transit, vulnerable dependencies, insufficient monitoring. Generative AI and large language model (LLM) applications add a set of new and amplified threats on top of that — threats that most security frameworks haven’t fully caught up with:

• Prompt injection — a user or attacker crafts an input that hijacks the model’s behavior, overriding the developer’s intended instructions
• Hallucination — the model confidently outputs false information, potentially feeding incorrect conclusions into downstream business decisions
• Data poisoning — malicious or low-quality data corrupts model behavior, whether at training time or through the contextual data fed into a retrieval pipeline at inference time
• Sensitive information disclosure — the model inadvertently reveals training data, confidential context, or personal information in its outputs
• Supply chain attacks — vulnerabilities introduced through third-party models, libraries, datasets, or toolchains

These aren’t hypothetical concerns. OWASP maintains a Top 10 for LLM Applications that makes the threat landscape concrete, and IBM’s AI Risk Atlas classifies AI risks as traditional (carried over from prior forms of AI), amplified (intensified by the generative capabilities of foundation models), and new (emerging risks intrinsic to generative AI itself). Any useful guide needs to address all three categories without overwhelming the engineering teams it’s supposed to help.

There’s a second challenge that’s less technical but just as real: governance debt. Enterprise teams building AI proofs-of-concept often defer security and privacy assessments because the system “isn’t in production yet.” That logic has never been sound, and it’s even less defensible for AI applications — where the data handling patterns, model choices, and access control designs made during prototyping often survive intact into production.

The Guide: Pillars, Layers, and a Pipeline

The AI Solution Guide is organized around three interlocking structures: a set of well-architected framework pillars, a layered security and controls model, and an AI application pipeline.

Well-Architected Framework Pillars

Good AI applications need to be well-architected applications first. The guide adapts the IBM Well-Architected Framework to include the realities of AI workloads. It is organized around six pillars:

Pillar	What it covers
Security and compliance	Protecting users, functionality, and data from unauthorized access and malicious intent
Operational excellence	Deploying automation to monitor and maintain solutions reliably and securely
Performance efficiency	Staying performant under shifting demand
Reliability	Providing correct results through disruptions
Cost optimization	Operating cost and resource efficiently
Hybrid and portable	Running workloads across multiple environments without platform lock-in

The intent is not to replace general engineering best practices — it’s to ensure they get applied, and to layer on top of them the guidance that’s unique to AI. A large percentage of the risks and controls that matter for AI applications are the same ones that matter for any enterprise application. The guide tries to be honest about that distinction so teams don’t lose the familiar foundation while they’re learning the new terrain.

Trustworthy AI Pillars

Running alongside the well-architected framework is a set of trustworthy AI principles that any AI or algorithmic system should uphold:

• Explainability — good design does not sacrifice transparency to create a seamless experience; imperceptible AI is not trustworthy AI
• Fairness — properly calibrated AI can counter human biases and promote inclusiveness
• Robustness — AI systems must be actively defended from adversarial attacks, minimizing security risks and enabling confidence in system outcomes
• Transparency — trust is built through disclosure: sharing what data is collected, how it’s used and stored, and who has access
• Privacy — AI systems must safeguard users’ data rights and provide explicit assurances about how personal data is used and protected

These principles aren’t soft add-ons. They map directly onto the well-architected pillars. Robustness and privacy align naturally with security and compliance. Explainability, fairness, and transparency belong to operational excellence. Building trustworthy AI and building well-architected AI are, in the end, the same project.

A Layered Controls Model

The security and compliance section of the AI Solution Guide draws on the Generative AI Controls Framework — a comprehensive approach to identifying Gen AI-specific risks and associated controls at each layer of the AI technology stack, co-developed by IBM with members of the IBM Financial Services Cloud Council. It organizes controls around five layers:

Layer	What it addresses
App controls	Securing the application stack; upholding ethical standards
Model controls	Securing training, validation, access control, and API integrations
Data controls	Securing data collection, storage, quality, and classification
Infrastructure security controls	Hardened network, access controls, encryption, and intrusion detection
AI governance, risk, and compliance	Managing, auditing, and demonstrating responsibility for the AI program

Source: IBM Generative AI Controls Framework

The key insight is that infrastructure security controls aren’t new — every enterprise team already needs them — but they must be deliberately applied to AI environments. The new territory is the governance layer and the model and app controls that address threats unique to generative AI systems.

An AI Application Pipeline

Finally, the guide is structured around an AI application pipeline modeled on the broader concept of MLSecOps — a security-first approach to the full machine learning lifecycle. The pipeline has five top-level phases:

1. Design — scope and plan the application, including data governance and team responsibilities
2. Develop / Build — collect data, select and tune models, engineer prompts, develop the application
3. Test — test the system end-to-end, including adversarial and red-team testing
4. Deploy — deploy the model to an appropriate landing zone with the right security controls in place
5. Manage — monitor the running system for drift, anomalies, and ongoing security posture

Each phase has its own principles, practices, and guidance. Security is not a final checkpoint — it is infused into every stage. This is the “shift-left” philosophy that has proven its value in traditional DevSecOps, now extended to cover the data, model, and ML dimensions unique to AI applications.

The RAG Pattern as the Starting Point

For most enterprise teams right now, the practical entry point for generative AI is the retrieval-augmented generation (RAG) pattern. RAG uses a pre-trained large language model as its foundation — no custom model training required. Instead, relevant documents are retrieved from a private or public data source at runtime and included as context in the prompt sent to the model.

This dramatically lowers the barrier to entry for building AI applications that can reason over an organization’s own data. But it also means the security of the data pipeline is just as important as the security of the model itself. If an attacker can poison a document store — or cause confidential context to leak through model outputs — the model becomes a liability rather than an asset.

The guide’s reference architecture describes how to wire together the key components of a RAG application: the orchestrator microservices that implement the business logic, the vector database that stores document embeddings, the model inference endpoint, and the intranet or cloud data sources that provide the knowledge the application depends on. It surfaces the trust boundaries, landing zones, and access control decisions that teams need to reason about before they write a single line of code.

The Questionnaire: A Mirror, Not a Checklist

One of the more practical artifacts that came out of this work is a self-assessment questionnaire — a structured set of questions organized around the layers of the controls model: governance, application, model, data, and infrastructure.

The questionnaire was not designed as a compliance hurdle to clear. It was designed as a mirror: a way for teams to surface, before production deployment, the places where they had made implicit decisions without necessarily evaluating the implications. Questions like:

• Have you registered your application and completed the required privacy and ethics assessments?
• Have you cleared your datasets and AI models through the appropriate approval process?
• Are you monitoring model outputs for sensitive information or inappropriate content?
• What is your plan if the model’s behavior degrades or is attacked?

These questions are uncomfortable in the same way a good architecture review is uncomfortable: not because they’re adversarial, but because they force the team to be explicit about choices they may have left implicit.

The questionnaire has been piloted across multiple project teams. Its most valuable use wasn’t as a final sign-off — it was as a starting point for structured conversations between development teams, security architects, and governance stakeholders early enough in the development cycle to actually change what got built.

My Role in Building This

I led the development of this guide from early conception through its current published state, synthesizing guidance across industry standards alongside IBM-specific materials on MLSecOps and generative AI controls. It required sustained collaboration with security architects, data scientists, compliance leads, and product teams to make the guidance grounded and usable — not just technically correct. Beyond the documentation itself, I led AI security reviews for multiple project teams and collaborated with security and privacy leaders to influence evolving corporate policy. I also developed a companion learning plan — including a short quiz — to give developers a baseline familiarity with the material before they started building on a shared AI platform.

Conclusion

Building AI applications well — securely, compliantly, and in a way that earns trust — requires more than good intentions and a capable model. It requires a coherent guide that engineering teams can actually use: one that covers the full application lifecycle, addresses both the familiar and the novel risks, and makes governance questions unavoidable rather than easy to defer.

The problems this guide addresses are not unique to one organization. Whether your team is shipping its first RAG-based chatbot or scaling a broader generative AI program across the enterprise, the same questions arise: What data are you using, and how was it cleared? What happens if the model is attacked? Who is accountable if something goes wrong?

Start with those questions early. Build security and governance into the design, not the review. The incremental cost is small. The alternative — retrofitting trust into a deployed system — tends to be very expensive.