AI Governance as Code: From PDF Policies to Pipelines
AI governance written into a PDF protects nobody. Ken Johnston, VP of AI and Data at Envorso, and Bob Rapp, Principal AI Architect at the General Motors AI Center, co-founded the AI GovOps Foundation to make the case that governance has to work like engineering: version controlled, automated, testable, and enforced inside the deployment pipeline rather than reviewed alongside it. They explain what governance as code changes in practice, which controls can be automated first, how to test systems that behave differently on every transaction, and why treating governance as paperwork guarantees it gets skipped under deadline pressure.
Key takeaways
• Policies belong in the software repository next to the models. If every change does not pass the same automated checks for lineage, fairness, and risk, you are not shipping policy as code
• Every gate has a yes or no answer, a contract, and a test. Fail the test and you do not pass the gate
• CI/CD gates are not enough for agentic systems. Governance watchdogs also have to run at runtime, at the edges between agents, and in front of prompt injection
• Governance done right is an accelerator. It gets you past the maybe gate, where a project sits finished but unsigned
• Testing non-deterministic AI means listening to every model on your network, mapping the regulations that apply, assessing compliance state, then sampling transactions for immutable logging. That is what Beacon does
• The rush to AI dropped software fundamentals. Automated deployments, automated rollbacks, observability, and blast radius control are the highest leverage fixes for a stalled pilot portfolio
About Ken Johnston
Ken Johnston is VP of AI and Data at Envorso and a founder of the AI GovOps Foundation, a nonprofit practitioner community advancing AI Governance as Code. He spent 25 years at Microsoft and then led a Ford subsidiary serving 20 million connected vehicles, with senior roles spanning AI, data, cloud platform, telematics, and digital transformation. His book The Lean AI Handbook is due from Pearson in summer 2026. He is known for helping enterprises embed governance controls into AI systems through engineering rigor, automation, and operational feedback loops rather than policy documents alone.
About Bob Rapp
Bob Rapp is Principal AI Architect at the General Motors AI Center and co-founder of the AI GovOps Foundation. He has built AI and machine learning systems across automotive, healthcare, telecom, and industrial settings, with prior leadership roles at IBM Watson, Microsoft, GE Healthcare, and Vodafone, including some of the first models shipped to diagnose certain cancers. At the foundation he focuses on turning AI governance into an engineering discipline through governance as code, operational controls, and open source tooling.
In this episode
| 00:00 | Welcome and guest introductions |
| 01:45 | Ken: GDPR, privacy, and the road to AI governance |
| 03:32 | Bob: when the models changed and the controls did not fire |
| 04:50 | What governance as code actually looks like |
| 05:54 | Where the policy code lives |
| 07:06 | Why gates also have to run at runtime |
| 08:21 | Will the CI/CD vendors build this? |
| 09:20 | Why the tooling is open source |
| 11:07 | Agent swarms, or viruses with credit cards |
| 11:52 | Ford: the puddle that flipped the car |
| 14:10 | GM: governance treated as a safety system |
| 15:14 | Over-the-air updates and automated targeting |
| 16:07 | Governance After Hours in San Francisco |
| 16:42 | The biggest misconception: governance as a brake |
| 17:34 | Unsafe at any speed |
| 18:00 | How much testing is enough |
| 18:24 | Red teaming and adversarial testing |
| 19:14 | The security analogy: shift left |
| 19:53 | Getting past the maybe gate |
| 20:33 | How many models do you test against |
| 21:05 | Inside Beacon |
| 22:19 | Umbrella, Lantern, and the audit layer |
| 23:14 | The Lean AI Handbook and the learning loop |
| 24:47 | Blast radius control and rollbacks |
| 25:27 | Data as the new oil, refined |
| 26:54 | Bob on where to start |
| 28:23 | Ken on his free e-book |
| 29:26 | Executive clarity and prototype theater |
| 30:33 | The one thing to remember |
| 31:26 | Wrap-up |
In their words
“If your policies don’t compile, you’re not governing AI, you’re just hoping.”
— Bob Rapp (05:12)
“The most dangerous control is the one that’s stuck in Word or a PDF.”
— Bob Rapp (14:38)
“Ten thousand agents, or as I like to call them, viruses with credit cards, unless you’ve got the right controls.”
— Bob Rapp (11:07)
“Governance is an accelerator. It gets you past the maybe gate and into production.”
— Ken Johnston (20:30)
“Everybody in a rush to get to AI seems to have dropped many of the fundamentals of good software engineering.”
— Ken Johnston (23:40)
“Governance that lives in a PDF doesn’t run in production.”
— Bob Rapp (30:41)
Resources
Websites and projects
AI GovOps Foundation: (also aigovopsfoundation.org). Nonprofit practitioner community behind the open source projects, with both guests’ writing and social links
Beacon: Open source governance agent, live now. Signs the evidence
Umbrella: Compiles evidence into executable controls
Lantern: Reads the evidence back, so auditors and policy people who are not technical can follow the audit trail
Ken Johnston’s free e-book on AI governance fundamentals: Case study driven, free to download, on the foundation site. Third version in four months, so link the page rather than a file
Ken Johnston on LinkedIn
Bob Rapp on LinkedIn
Books
The Lean AI Handbook, Ken Johnston: Pearson, summer 2026. Applying software engineering fundamentals to AI: agile development, incremental deployment, blast radius control, observability, and the learning loop
Unsafe at Any Speed, Ralph Nader (1965): Referenced by Bob Rapp for enterprises that fill out forms and hold retreats but have no governance they can execute
Also referenced
Governance After Hours, San Francisco: Co-hosted by AI Realized and the AI GovOps Foundation. This episode builds on that room
GDPR: The standard that started Ken Johnston on the path from privacy to data governance to AI governance
Zoox: Autonomous taxi case study Ken Johnston cites alongside the Ford telemetry example
Related AI Realized episodes and events
Your AI Agent Is Not the Risk. Its Authority Is.: Yogita Parulekar of Invi Grid on governing the authority you delegate to an agent.
Artifact-Scoped Agents: Stop Mimicking Job Titles: Chris Butler of GitHub on scoping agents to the artifacts they produce, and the read wide, write narrow trust boundary.
Governing Agents at Scale roundtable readout: The executive roundtable on governing agents at scale, co-hosted with the AiGovOps Foundation.
Frequently Asked Questions
-
Bob Rapp defines it by a single test: if your policies do not compile, you are not governing AI, you are just hoping. Governance as code means the policies compliance and legal spent months writing live in the software repository next to the models, and every change passes the same automated checks for lineage, fairness, and risk through the CI/CD pipeline. Rapp’s framing is that every gate has a yes or no answer, a contract, and a test. If it does not pass the test, it does not pass the gate.
-
Bob Rapp calls this the misconception that makes him twitch. Governance is an accelerator, not a brake: if a policy is stuck in a PDF you cannot ship software, but if the policy ships inside the software as code you can move faster because you are safe enough to ship. Ken Johnston adds that automated governance is what gets a project past the maybe gate, the point where a finished project waits on someone who is not ready to sign off. Rapp says he sees this working at companies including Merck, John Deere, and General Motors.
-
No. Ken Johnston is explicit that most governance activity today happens after the model has left the barn, which is why he and Rapp emphasize shifting governance back toward the development cycle. But gates also have to run at runtime, the way cloud teams already run watchdogs for live services. Those mechanisms need to sit in the observability layer, at the edges between agents, and in front of prompt injection.
-
Bob Rapp points out that the usual approach breaks down because a billion generative AI transactions are a billion different transactions, with no meaning unless you have context. His method is to listen to every model on your network, hold files for all the regulations you care about, assess where you sit from a compliance point of view, then take a sample of transactions for immutable logging that auditors can verify. Ken Johnston adds that the state of the art is still moving, and current techniques include using AI models to test other AI models and role-based adversarial red teaming.
-
Beacon is the AI GovOps Foundation’s open source governance agent, live now and aimed at people writing software. It listens for the models running on your network, tracks the regulations that apply, assesses your compliance state, and samples transactions for immutable logging. Beacon is one part of a three-piece toolkit: Beacon signs the evidence, Umbrella compiles it into executable controls, and Lantern reads the evidence back so auditors and policy people who are not technical can follow the audit trail.
-
Ken Johnston’s answer is to restore the software engineering fundamentals the rush to AI dropped. Many organizations, including large ones, lack fully automated deployments with automated rollbacks and proper instrumentation for observability. His Lean AI Handbook argues for agile, incremental change managed with blast radius control so work can be rolled back safely, and he is blunt that any AI project will need a rollback at some point.
-
Ken Johnston names executive clarity. He describes prototype theater, where no code, low code, and vibe coding tools produce flashy demos that get approved for production even though the demo is closer to a wireframe with 90 percent of the work still ahead. The AI projects that succeed are the ones aligned to executive objectives set by the board, and losing that alignment is how projects get cut.
-
Bob Rapp’s closing answer: governance that lives in a PDF does not run in production. To be trustworthy with AI at scale, your policies have to compile, your controls have to be testable, and your evidence has to be as automated as your deployments. If you cannot answer what happens when this fails, how it rolls back, and how it returns to the previous gate, you are not doing software engineering.
-
[00:00] Christina Ellwood: Welcome to AI Realized, the podcast for enterprise executives leading AI adoption. From tackling security, data, and operational challenges to navigating organizational transformation, AI deployment offers a unique opportunity to redesign our organizations from the inside out. I'm Christina Ellwood, your host for today's episode, and today I have two guests with us who have spent decades deploying AI at companies like Microsoft, Ford, IBM, GE Healthcare, and General Motors. And they are now channeling that experience into something new. Ken Johnston is the VP of AI and data at Envorso and the founder of AiGovOps Foundation. Bob Rapp is a principal AI architect at General Motors AI Center and is the co-founder of the same organization. Together, they're making the case that AI governance needs to work like engineering: automated, testable, and embedded in the deployment pipeline, not filed away in a PDF. AI Realized recently co-hosted Governance After Hours in San Francisco with the AiGovOps Foundation, bringing together executives and startups working on AI governance. And the energy in that room made it clear this is a conversation the industry is ready for Ken, you spent 25 years at Microsoft, then ran a Ford subsidiary serving 20 million connected vehicles, and now you're writing the Lean AI Handbook. Bob, you're, you've architected AI systems at IBM Watson, GE Healthcare, Vodafone, and now GM. What was the specific moment each of you realized that AI governance just simply couldn't stay in the policy document anymore, that it had to become code?
[01:45] Ken Johnston: I guess I'll go ahead and go first on this. For me, it started actually with GDPR. And so heading into that, I actually had been working a lot with Microsoft data, was one of the leading people at generating insights off of data. But GDPR was one of the first standards that came out and said that you needed to ask permission to use data, that those permissions were granted sometimes for a limited time and for specific use. Prior to that, there was just a general sense of do no evil. When GDPR came out, I spent a lot of time with our lawyers at Microsoft, learning and sharing with them how data could be used and abused, and what we needed to do to lock it up inside of Microsoft. At that exact same moment is when Microsoft was working on responsible AI standards as we moved into this AI era. So I moved directly from privacy into data governance, into into AI governance. And for me, when I saw how we had to automate for privacy and for data governance, when I left Microsoft and I went to Ford Motor Company and I saw the lack of automation we had there and how many things were locked up in documents and spreadsheets, I realized that I needed to do a major push to bring to bring that company and autonomic up to speed on modern practices. Just like we did with privacy, but now with AI, the threat was much higher and the speed was much faster, and so the need was even greater than before, and that's what kind of pushed me in this direction. What about you, Bob?
[03:25] Christina Ellwood: Yeah, that makes sense. And of course, it's only gotten more compli- complex from a regulatory point of view, yeah? And Bob, how about you?
[03:32] Bob Rapp: First let me thank you for inviting us to this podcast. I really enjoyed meeting you and such a wonderful bunch of founders. Boy, the center of the known universe in AI governance is clearly San Francisco. That was a wonderful event. I think for me it was cancer. So as a two-time cancer recoverer both at Watson, where I came to try to fix some of the problems we were having with how we were doing data science in the cancer space with Watson, and also at GE Healthcare, where I'm proud to say we shipped some of the very first models to diagnose certain kinds of cancers. What I noticed is I stopped trusting the decks the day that the cancer models changed, but our controls didn't fire. So we had a really good policy that was stuck in a piece of paper, and it didn't change how the diagnosis and other models were working. So data drift and other things are very dangerous, and we've got to watch that in real time.
[04:27] Christina Ellwood: Yeah. Even when you automate those systems, which of course many people still have not automated, even the most basic thing like website compliance the automation can be out of sync as well if it's not provided the most up-to-date information. And of course, in the world of agents where we have agents talking to agents generating data that no one has ever seen before, it's a much more complicated problem. Bob, you've said compliance frameworks that exist only in PDFs are liabilities waiting to surface. Walk us through what AI governance as code actually looks like and what gets automated, what gets tested, and what changes in the deployment pipeline.
[05:06] Bob Rapp: That's a great question. L-let me give you a couple of short ones, some tests you can do right now. If your policies don't compile, you're not governing AI, you're just hoping. Or another way to say that is that governance as code means that the wonderful policies that you spent a long time building from compliance and legal and all the good people that are doing that, if they don't live in your software repositories right next to the models, if every change doesn't go through the same automated checks for lineage and fairness and risk, AI, CI/CD pipeline all the way, then you're not shipping policy as code. You're hoping and you're praying that you have a plan. But you're not... The policy has no relationship to the product you're shipping. That's the test.
[05:54] Christina Ellwood: Okay, so then does the governance as code, the code that is governing the use of the LLM, sit in the data pipeline or sit in the in the inter- the space between the prompt and the model? Or where does it r- where does it really live?
[06:10] Bob Rapp: It... and Ken's probably as one of my heroes of tests, Ken can talk a little more deeply about this. What I would say is every single gate has a yes or no answer, it has a contract, and it has a test. Just like we've always done with CI/CD pipelines so continuous integration, continuous development. If you don't pass the test, you don't pass the gate. None shall pass, a Monty Python moment there. If you pass the gate, you pass the contract, you get to go to the next place. So it, the policy lives everywhere, instantiated as code, and we check it at every single gate, and it doesn't make it out the door. And it, whether it makes it out the door, whether it's sustained, or whether we have a fail and we recover, we-- those things are immutable. They're rules that always occur, and we never, ever make a flexible movement there. We lock those in, right?
[07:01] Christina Ellwood: Gotcha. Okay. K-
[07:02] Bob Rapp: yeah, Ken- Yeah ... why don't you, why don't you
[07:04] Christina Ellwood: elaborate from a test perspective?
[07:06] Ken Johnston: Yeah, I just wanna add in that the- You, the CI/CD pipeline is really where we focus a lot of our conversation, but as we know, especially with agentic AI, and we're all gonna get together and talk about that in a couple of weeks on the 17th you need to actually have your gates running in runtime as well. And so we do this already in the cloud, and one of the things that we talk about in governance is that a lot of what we're trying to do with governance as code is the same thing we do with services today. We have we have watchdogs in production today for live services. We need those kinds of mechanisms, but they need to be there for your governance policies, and they need to be there at the edges between your agents. They need to be there in place to protect against prompt injection. All of these different things have to be in place. You'll hear Bob and me talk mostly about the CI/CD pipeline because that's where we really focus because most governance activities these days are processes people do after the model has left the barn. And so we're really emphasizing shift left, bring governance back in closer to the development cycle. But you really need to have it also there through your observability layer and at your runtime.
[08:21] Christina Ellwood: So are you envisioning that these governance policies as code will live inside your CI/CD tools? Is that where you think they're gonna belong? So if you're using Rollbar, they're gonna be in Rollbar or something like that? Are you looking to the vendors to develop the mechanism by which we pour our policies into that pipeline?
[08:44] Ken Johnston: Well- Yeah, let me- Take a- Yeah, let me jump in on that, Bob- Okay. Sure ... because that's kinda what we're seeing with the ecosystem and why we started the AiGovOps Foundation, is that there is a lack of technology in the space today. We know this much, it needs to live in the CI/CD pipeline. It needs to live in those tools. You need to have those protections, but honestly, the technology has not yet been developed, and that's one of the things that we're trying to promote. We know that it needs to be automated. There are literally a gap of solutions to allow this to happen. And you were gonna say something, Bob?
[09:20] Bob Rapp: Yeah. So I was gonna say that the purpose of the open source projects that we'll talk about a little bit later is to build the executable code that we can give to the community and they can improve that says, "We're listening for certain patterns. We know about regulations. We're keeping track. We're looking at risk models. We've got dashboards to see where we're doing, and we can get to a compliant state." It's all very early but it does work, and there's a ton of folks in the space that have very similar solutions. And I'm very impressed. We've got a group of founders actually tomorrow that are presenting some of their solutions. So there's a lot of growth, there's a lot of hope, but it's not completely a solved problem, which makes it a really exciting time to, to get in here and fix it.
[10:04] Christina Ellwood: I think it was really wise to use an open source project because it does... It not only marshals the talents of the open source community, but it means that people can adopt this tool without having to look to their vendors as the sole source, right? They can ask their vendors for it. They can explain what they're looking for. They can represent how they're doing it today. But they have something they can use without having to have vendor delivery or approval for additional budget in order to make it happen. It-- Is your vision that this same approach, the same project that you've built for the general question of AI governance in the CI/CD pipeline would be used by agents as well?
[10:48] Bob Rapp: Sure. Sure. We think and Joe at Glacius is one of my heroes, and he's actually presenting tomorrow. What he would say is, what we're looking at is the baseline, the bottom set of standards, and a framework that people can use. So policy people and code people can get together on a common understanding of what the gates and what the rules are. But there's a lot of folks above that line that are delivering more. Agents are certainly the place to deliver. That's the-- Those are the cool kids. Microsoft Build has been announcing all week some amazing agents that are terrifying and wonderful. Agents also, by the way, exist as swarms. So imagine instead of just having one or two agents, you have ten thousand agents, or as I like to call them, viruses with credit cards, unless you've got the right controls, right?
[11:33] Christina Ellwood: Yeah, for sure. That's a great way to think about that, isn't it? So Ken, at Ford, you delivered over-the-air updates to twenty million vehicles. So you have my sympathies for what that must have been like. Having some background in IoT, I can appreciate that. Where a bad deployment could be life-critical. And Bob, you at GM were building AI for connected vehicles in safety-critical environments. So give me one example from automotive specifically where automated governance caught something or where the lack of it caused a real problem Real world case, guys
[12:12] Ken Johnston: Yeah. Gotta be careful that we don't actually share confidential details here. What I can share with you is this, and it's actually true both for Ford and a case study that I read on the autonomous taxi company Zoox. One of the things we were doing at Ford is we were pulling logs from our vehicles whenever the autonomous vehicle engine triggered- Even for a millisecond, a question mark, a this doesn't make sense. And maybe it solved it because clearly an accident didn't happen, but for even a millisecond, the AI wasn't sure what was going on. And I had this wonderful opportunity to be with the team that was analyzing this data, and for a millisecond, And because at Ford we had both LIDAR and we had cameras, but for one millisecond, one of the cameras thought that the world-- that the car was upside down. Jeez. And the reason was that it was a sunny day, and it was driving, and there was a puddle, and in the puddle there was a perfect reflection of the trees on either side of a two-lane road that were going down into the water. Now, because we had multiple systems, of course the system as a whole worked. But it was something that we captured, and because we were always working on how do you prevent these kinds of risks, so that ended up being something that we put into our quality control pipeline so that we can then monitor that in the future to make sure that the model never drifted out of that, that there were always retries. That, just 'cause the camera sees something, LIDAR and motion sensors are more authoritative in the system than a camera that might get tricked by a puddle. So that was a fascinating lesson.
[14:06] Christina Ellwood: Yeah, just that's a really good one. Yeah. Bob, do you have one to add?
[14:10] Bob Rapp: I would say, and I have lots of friends at Ford, lots of friends at GM. I think the auto industry tries really hard to be very safe. One thing I've noticed that I really admire about General Motors is that we treat governance as a safety system. So just like we think about other safety systems, LIDAR, radar, brakes all of those things, not as a slide deck, because the most dangerous control is the one that's stuck in Word or a PDF. The only controls that matter are the things that happen in real time. 'Cause if you think about increasingly self-driving is becoming the thing for all automotive manufacturers, so we could have up to a million transactions in a few seconds, and all of those transactions could have some level of artificial intelligence in them, right? We don't know. But we do at GM, but we-- in the future that could be a thing that would sneak out. So I'm really pleased by how thoughtful the safety engineers are in, in that process of policy as code, right? In the car.
[15:14] Christina Ellwood: And have you seen a case where automated governance- Avoided a problem or the lack of automated governance caused a problem?
[15:23] Bob Rapp: Yeah, I-- bo-both, and I'll talk about the good cases. By using automated governance, the way that we do over-the-air updates has really changed significant in the auto industry. I would say at GM and Ford and Toyota, and we have lots of friends in the industry. But one of the things that we're able to do, and it's really more about how you use artificial intelligence, both deterministic and non-deterministic, to target the right platform. 'Cause if you realize that there are six or seven hundred thousand different variations of just a pickup truck. So that's where automated governance says, "Do we have the right package to the right vehicle at the right time in the right order?" And I've seen that across the industry get better and better, so I'm very hopeful about the future.
[16:07] Christina Ellwood: Gotcha. Okay. That seems like a really practical use case, too, of making sure you've got the right make and model for the push of the update. So at our AI Governance After Hours event in San Francisco that you both came down from San-Seattle for, which I was thrilled to have you there as representatives of AiGovOps Foundation. I saw executives and startup founders in the same room wrestling with the same governance questions that you re- you wrestle with at the enterprise level. So these are-- this is about the technology. It's not about the size of the organization, the type of organization, or even the scale of the deployment. Everyone is facing those same challenges. And you've launched AiGovOps Foundation, what was it? Six months ago. And you're already presenting at AICon USA. You're hosting meetups. You're building with the practitioner community. So Bob, what's the single biggest misconception About AI governance that you're encountering from these various enterprise leaders, and what do you tell them?
[17:07] Bob Rapp: It's the thing that makes me twitch, is that people think that AI governance is a break. What it actually is an accelerator. As some of my friends, regulators in the UK and in Australia say is, if your policy is stuck in a PDF, you can't ship software. But if your policy is shipped in the software as governance, policy as code, that actually accelerates your ability to ship AI. And so I'm actually seeing that at companies like Merck and John Deere and certainly GM, that when we get that we can go faster because we're safe enough to ship. And it reminds me s- sometimes I feel like enterprises could be that Ralph Nader slogan, unsafe at any speed. Because they're, they fill out forms and they've all had a retreat, and they've planned their next retreat, but they don't have any governance that they can execute. They just have governance in documents.
[18:00] Christina Ellwood: It also strikes me though that the degree of testing is really significant because obviously models can hallucinate any time. You don't get to choose whether or not they're hallucinating while you're doing your tests. So how do you know when you have had sufficient testing to be safe to ship your code?
[18:21] Bob Rapp: I'll defer that to Ken, my test hero here.
[18:24] Ken Johnston: So the state of the art in... That's a very good question. The state of the art in this continues to evolve and change rapidly. One of the techniques people are using is using different AI models to test AI models and drive them. We used to do things in testing called boundary value analysis. There's a practice within red teaming now to actually create these kinds of role-based adversarial approaches to try to un- in essence, unnerve your AI to get it off of its game. And so those are some techniques that help harden the system. There is no pat answer right now. And so one of the analogies I often compare this to and why we're so focused on the concept AiGovOps is Bob and I go back to the early days of security, when security, everybody was paying it lip service. We used to do pen testing after we shipped a product. Seriously. It's oh, ship a product, let's see if the bad guys can get inside the fence. That was brilliant. But, with security, we've done the whole shift left thing, and we've developed a lot of new technologies, so we help prevent those kinds of mistakes getting into production. And that literally is a gap we have today with governance and governance automation. We are saying you need to go have governance as code, but we're also saying the tools don't fully exist and the frameworks don't exist correctly to fully automate it in a way that actually protects people. But we're also focused on this because, as Bob already said, governance done right is an accelerator. I'm gonna steal one of Bob's lines. One of the problems you get sometimes with governance is you get all the way done with your project and you get to the maybe gate. You get to the person that's there that says maybe we can ship it, but I'm not ready to sign off." "Maybe this is a good idea, but I don't know that we've checked all the boxes." And you get stuck at maybe. Governance, when it's automated, has your- ha- has your standards embodied in code, and you know that it's done, and you can continue to invest to make it the best state-of-the-art standards as possible as we continue to accelerate the development of the technology. Governance is an accelerator. It gets you past the maybe gate and into production.
[20:33] Christina Ellwood: I wanna do one follow-up question on this issue of testing, because obviously you're testing against a model, and most organizations are now using more than one model, and they may be using more than one version of a given model. How many models do you include when you're doing challenge testing? And what is the magic configuration for te- for the challenging? Do you s- you start with the one you're gonna deploy and then challenge it with one you're not deploying? W- what is it? What's the logic that is used in designing the testing with the challenge models?
[21:05] Bob Rapp: Let me take this one because it's one of my pet peeves, and I talk to an awful lot of people that say we already know how to do all of the CICD and testing and dev test and moving th-" the one difference here is that in non-deterministic or generative AI, if you have a billion transactions, each transaction is by design a little bit different. And so all of the systems that we've had before, whether it's security or virus or whatever it is, starts with we ship some code and now we're looking for anomalies. If I have a billion generative AI transactions, I have a billion generative AI transactions, but I have no notion of what they mean unless I have context. So your question about what do you test it sounds strange to say we test everything, but what I would say is you make sure you listen to all the models that are on your network. You then have files for all of the regulations that you care about, which should be all of them probably, and then you do a determination of how you're sitting from a compliance point of view, and then you decide what N number, N equals 19, N equal 1,000, to take as a sample for immutable logging so that auditors and other folks that are in policy can get a handle on this. And that is what-- That is, by the way, I've just told you what Beacon is, which is our open source project, which is live now. And we also have a Lantern project that goes around Beacon to explain to auditors and folks that are not as technical how to go through that audit process because we want to keep everybody safe. We want humans to ship great AI. We're huge fans of AI- ... when it's good, and we'd like them to not ship bad AI because we don't wanna dig that bunker in the backyard.
[22:47] Christina Ellwood: I think this question of how many models and which models and how many tests and whatever is a kind of maybe gate, right? Because maybe I'm okay with three models, but maybe I'm not sure if three is enough. So I think there's still maybe gates that people are gonna run into and I think your approach of providing the s- the foundation and then layering on top of the foundation is very sound. So Ken, your book, "The Lean AI Handbook," comes out this summer from Pearson. For the executives listening who have 15 AI pilots but only two in production, which I'm sure is more than one, what is the single highest leverage operational change they should make tomorrow morning?
[23:31] Ken Johnston: Thanks for asking that question. And so the Lean AI Handbook is less about, governance and more about just building AI correctly and the good engineering practices. And the number one thing I found in the research is this: everybody in a rush to get to AI seems to have dropped many of the fundamentals of good software engineering, and that's what the book focuses on. And they don't do AI deployments, and we've even seen this with major large companies like xAI, where they don't have fully automated deployments with fully automated rollbacks. They don't have proper instrumentation for observability. And what's unique about AI that's a little bit different than normal services development is what I call the learning loop. Your whole goal in AI is to actually start the learning process. You're not trying to build the perfect model the first time out. You're trying to get a model, an agent, a tool into production with the correct instrumentation for observability, because we know... One thing we, a lot of us know about AI is that data is fuel, and when you get your models into production, if you've got them instru-instrumented correctly, you're now generating more fuel to make your models better. So I really focus on, and why the book is called The Lean AI Handbook, it's really about going back to agile development, incremental small changes, and managing that with blast radius control so that you can roll things back safely. And one thing you do with AI is accidents are going to happen. Do not even imagine for a second that you're gonna do an AI project that is not gonna have to have a rollback at some point, and you're kidding yourself. And that's really the fundamental problem is everybody seems to have just said, "Oh, it's AI, it's magic. Let's stop the fundamentals." And so my book is actually really simple. Fundamentals of engineering apply to AI as well.
[25:27] Christina Ellwood: I would argue fundamentals of data are also really im-important to be reminded of because, as my friend Steve Jones at Capgemini likes to say, people call data the new oil, and it's true in the following sense: that like oil, it has to be refined. You don't take it out of the ground and put it straight in the car. And he said the thing about AI, generative AI in particular, is that you're moving the consumption of the data to the wellhead. And that, of course, is so true, especially when we are using our systems of record as our primary source of data because the systems of records weren't built to generate good data. They were built to do a function and exhaust... The data is the exhaust of that process. So it's not designed to be clean, it's not designed to be normalized, it's not designed to be any of the things that we need it to be to use it in AI. So that is different than the things you're working on in the governance area, but it's related obviously because a big part of what you're learning is from the data that may or may not be well-suited to the process of training. So let's move into our wrap-up section here. What one resource would each of you recommend for listeners who wanna learn more about what you're building? Go ahead, Bob
[26:56] Bob Rapp: I would go to aigovops-foundation.org or aigovops-foundation.com. We've just put those set up too, and look at the two open source projects. The first one's called Beacon. That's really for folks that are writing software. And then I would look at Lantern or Umbrella, we haven't quite decided on that name yet, which is really the structure around how you would deliver that. And big thanks, by the way, to Glacius, Joe, and the team for being our first folks helping us with oversight on that open source project.
[27:31] Christina Ellwood: Gotcha. Okay, that's great. And Bob is there anything about your work that you would want to f- highlight for folks, that they could either read about something you've written or perhaps a presentation you've given?
[27:43] Bob Rapp: So I tend to put everything up either on LinkedIn or YouTube. Recently, it's been LinkedIn, but if you go to our foundation site, you'll see both Ken and I's posts on LinkedIn and other social media. We try to keep that up to date, and I'm excited we'll be recording our first virtual meeting with, meetup with about 200 folks, some in Seattle and then some around the world. We have a speaker from Singapore, and I think one from London tomorrow, so that's really exciting. So-
[28:10] Christina Ellwood: Fantastic ... come look. I will be on, I will be on that call. Ken- Excellent ... what about you? What res-- what one resource would you recommend for listeners who wanna learn more about what you're building?
[28:23] Ken Johnston: Again, LinkedIn and our website. I did create an e-book on AI governance fundamentals. I go through a lot of case studies. A link to that can be found on our website that Bob already mentioned, and that's free to download. Again, we're focused on building a community, not a product, so we're giving a lot of our learnings away. And keep the link fresh because honestly, the book is in its third version since I started working on it four months ago. I keep adding new sections here and there because I keep learning. One of the things I love about the foundation is this: Bob and I have worked in this space for a while, but because we're taking a helping hand approach, the number of people that are approaching us and sharing their knowledge and information, honestly the amount that I am learning about good governance has skyrocketed because of the approach that we're taking. And so we're gathering that knowledge, we're putting it into open source tools, and I'm the one that likes li- long form documents, so I'm putting our learnings into documents.
[29:26] Christina Ellwood: That's fantastic. So Ken, in the AI revolution, what leadership skill do you find most valuable in your work today?
[29:35] Ken Johnston: That's easy. It's clarity. And it's actually executive clarity. One of the challenges we're seeing, and we call it prototype theater or demo theater too often now especially with no code, low code, vibe coding, people can create really flashy and cool looking demos, and everybody gets excited and says, "Hey, let's go put that into production." But as we've discovered, sometimes those flashy demos are nothing more than a wire frame, and you've still got 90 plus percent of the work to do, and you get distracted. You're now thinking you're taking a shortcut, but really you've just derailed your progress. The best AI projects are the ones that align to executive objectives delivered by the board. When you get off track from that, like any other software project, you're gonna end up cutting it and not executing because there's not alignment. So clarity and alignment, those are the things that I really focus on.
[30:32] Christina Ellwood: Great. That's really good advice. And Bob, if listeners remember just one thing from our talk conversation today, what would you like it to be, and why?
[30:41] Bob Rapp: I think the best thing to take away is if you're just gonna remember one thing, let it be this: governance that lives in a PDF doesn't run in production. So if you want to be trustworthy with your AI at scale, your policies have to compile, your controls have to be testable, and your evidence has to be as automated as your deployments. All the great principles Ken just talked about are true, but it's even harder because it's a non-deterministic world. So if you can't ask the question, what do we do when this fails? How do we roll it back? How do we fix it? How do we get it to the previous gate? You're not doing software engineering, you're doing hope, prayer, and probably a lot of theater.
[31:26] Christina Ellwood: Wonderful. So Ken Johnston, the VP of AI and Data at Envorso and founder of AiGovOps Foundation, and Bob Rapp, the Principal AI Architect at General Motors and co-founder of AiGovOps Foundation, thank you both for sharing your experience with us today. It's been a pleasure.
[31:45] Bob Rapp: Thank you very much. Thank you. A pleasure. Let's continue the conversation. Appreciate