Generative AI is changing how organizations work, but deploying models is only the beginning. As enterprises move from experimentation to execution, they need AI that makes decisions consistently and in line with how the business actually operates.
In a new episode of The AI Forecast, "Decision Logic: The Missing Layer in Enterprise AI," Darlene Newman, Innovation Lead at Duczer East, joins host Paul Muller to explain why enterprise AI needs more than data and prompts to deliver reliable outcomes. Drawing on her experience leading AI and digital transformation initiatives, Newman explains why organizations must capture the decision-making knowledge employees apply every day and make it accessible to AI.
Read on to discover why decision logic may become a foundational building block of enterprise AI.
What is decision logic?
Paul: Let's talk about decision logic. When I first saw the topic, I had one of those moments where you're tempted to nod along and pretend you understand it. Even after a quick look, I realized I had no idea what decision logic meant as a discipline. So help me out. What is it, and why should I care?
Darlene: An LLM generates awesome output, but it's pattern-matching on the text it has been trained on from the Internet. It's not true intelligence, but it will change how we work day to day. For it to know and make sense, you must help it understand.
I've spent a lot of time in contract management, and I think it's a phenomenal use case for LLMs. If I ask whether a contract has an auto-renewal clause, phrases like may renew, shall renew, automatic renewal, or tacit renewal could all mean the same thing. When someone says, "This is an auto-renewal contract," the question becomes, "How do you know?"
That's what I mean by decision logic. It's the why behind what you do, the tribal knowledge people apply instinctively every day. You have to teach that knowledge to the LLM. Otherwise, it will make its own decision, and it may not be the right one.
The “Librarian” Behind Enterprise AI
Paul: What I'm hearing is that decision logic gives us a way to capture some of that tribal knowledge and build it into the system for defined use cases, reducing the need for constant human intervention. So what kind of talent or skills do organizations need to build that capability?
Darlene: I equate it to a librarian, someone who's organizing information. I always say there are two key skills you need to build an agent: understanding the business process and understanding the data. Blend those together, and you have someone who can do the knowledge design. They're not pure engineers, but the person designing the knowledge layer needs to understand how data is structured and how the business actually works. You still need technical people to implement the agent, but designing the knowledge is really a blend of business expertise and data understanding.
I think what often happens is that if someone designing this comes from a purely technical background, they'll structure their vocabulary around what's already in the system. People will say, "We've got Collibra. We have data definitions for all our fields, and we've mapped the lineage." My response is, "That's not a controlled vocabulary."
Having field definitions is great, but the real question is, what does the concept actually mean? A definition alone doesn't tell you how it should be interpreted or how an AI should identify it. You have to take it a step further. You don't want your concepts and your understanding to simply mirror what's in a relational data model. That's the risk of taking too technical an approach when you're defining the semantic layer.
Build Decision Logic into AI from Day One
Paul: Let's end with a bit of a call to action. For people like me who might hear the term decision logic and simply nod along, what should we actually be doing about it? Is it something boards and executives should be thinking about, and at what point in an AI project should decision logic become part of the conversation?
Darlene: You start thinking about decision logic at the beginning of the project, when you're designing the agent. With agents, you can no longer get away with minimal requirements. Every task has potential edge cases, so you need to decide whether the agent handles them or hands them off to a human.
I always tell people to start with the process flow. Don't try to design the entire process around the agent. Instead, identify the critical activities in that process. Map out the work you're doing today and say, "Here are all the things we do in this flow. Which ones make the most sense that you can do? " And at that point, what are the tests? What's the input? What's the output, and how do you make that decision for that output? And you start documenting how you do that.
The challenge is that semantic layers aren't yet something boards readily understand or fund. Boards readily understand data lakes and APIs, but semantic layers haven't yet reached that level of understanding.
With some clients, we had to prove the value. We started with a single agent, and the output was poor. We built a simple controlled vocabulary for the agent to reference, and the results improved. As we added more rules and definitions, we were essentially building a basic semantic layer. Today, we're formalizing it through knowledge design and open standards, but at the time, we had to build it behind the scenes because organizations weren't asking for it. It's a difficult concept because people don't naturally think this way. I've found it's easier to show what a knowledge graph looks like than explain it.
Catch the full conversation with Darlene Newman on The AI Forecast on Spotify, Apple Podcasts, and YouTube.
