
Loading summary
Yolandi
Foreign.
Podcast Host
Welcome everyone to the Emerge AI and Business podcast. Today's guest is Amar Aksa, SVP and Chief Architect at paysafe. Amar joins us to discuss bridging the consistency gap to move AI from risky demos to reliable production systems. He explains why embedding guardrails and evaluations early is the only way to protect AI' sponsorship and roi. Our conversation also covers shifting to a know your agent workflow, treating prompts as version code, and ensuring every agentic decision remains fully auditable and defensible. The views expressed by Amar on today's program do not reflect that of Paysafe or its leadership. Position your brand alongside the Fortune 500 leaders defining the enterprise AI roadmap for the opportunity to showcase your solution to the executives currently funding and scaling global initiatives. Partner with Emerge to reach the decision makers holding the strategic mandate. Secure your partnership membership at go.emerge.com partner that's G O.E M E-R- dot com P-A-R-T-N-E-R let's get into our conversation with Ammar Amar.
Yolandi
Welcome to the AI in Business podcast with Emerge.
Amar Aksa
Hey Yolandi, thanks for having me.
Yolandi
It's a big pleasure. So I know that our conversation today will speak directly to senior executives from multiple industries. And we know that one of their biggest concerns will always be trust. Now, for an executive, trust is not an emotion or a feeling for the rest of us. To them it's having that certainty that they are avoiding lawsuits, regulatory fines, PR disasters. And with AI, all of that fear comes right? So when we consider enterprise AI programs, where do we see the trust breakdown? Where do we find the moments where leaders realize that the systems behave differently in the real world the than what they did in the very controlled demo that we normally see.
Amar Aksa
So when I look at enterprise systems and large enterprise systems especially, I realized that it is rarely the trust breaks because the LLM is bad or the LLM has a lower quality or low bar in that sense. And even if it was that LLMs are becoming better on a minute by minute basis. Most of these trust parameters break because of the systems which are using the LLM or the rapids around it are immature. And that is what I sometimes call as the consistency gap. The LLMs are also distributed systems and they must be consistent across different business inputs and outcomes. Otherwise it is not a production system, it is just a demo system really. Trust collapses the moment predictability and determinism disappears. That is why it is very important that we embed guardrails and evaluations early in the process. It cannot be an afterthought. Most of the demo based systems today are a result of an outcome, a result of an excitement from the teams which are building it, experimenting with AI. And often, just like the older world, the authentication, the guardrails, the evaluations, the testing of it, the pipelines, the dataset management is kept to when we go production. But then if you do not have these things before production or use those things to even classify the results, then your predictability will break and your trust will break.
Yolandi
Absolutely. It sounds like a very basic concept of just predictability and knowing what's happening and knowing where it's going. So unpredictability is obviously a big risk. And I recently heard you say that blocked access creates blocked visibility. Is that also something that could have an effect on the consistency gap or not really?
Amar Aksa
Definitely. The systems need to be able to discover all the dimensions available for its workflow today. If you block access or if you hide visibility into systems, both of them will cause problems. If you block access, a lot of shadow AI may come up on developers or users desktop. Eventually they will find merit and they will find usefulness in those shadow AIs that they would want to make it production ready. At that point you are unequipped to quickly find the right solution or find all the consistency parameters to qualify that AI solution. If you block visibility, if you do not start observing these things at an early place, if you just go with the right solution outcomes and if you keep it a demo system until you make it production, then you are too far in the process. The Exec suite is really excited about the solution, but then they realize we don't have determinism, we don't have verification baked in, we don't have evaluations baked in. And then they feel that, well, the AI is not that fast enough. Right. So the sponsorship will be lost for AI as soon as the first production failure happens. It's very important for us to know that.
Yolandi
And that's a budget we don't want to lose. Right. Very important for the future of any enterprise. Okay, so enterprises always say that they test their AI and I'm sure they do. But what separates surface level testing from the production grade evaluation discipline that is actually required?
Amar Aksa
Yeah, so testing again goes back to the first principles of things like unit test, regression tests, integration tests. It is just that their definitions and the parameters have changed. In the world of AI, for example, production grade evaluation test is critical to AI infrastructure. You must have versioned prompts like prompt as code is becoming as important as ever. Prompt is intellectual property, it is code. It has to be organized and maintained as code. Replayable data sets are incredibly important in large enterprise systems because the dynamic data set will change across the lifecycle of the product. And you should be able to replay an old data set and be able to deterministically get the right outcome as you would have expected expected back then. And there should be very solid threshold configurations for guardrails. The AI must know when to stop and fail fast. See, fail fast as a paradigm hasn't gone away. If your AI system realizes that it cannot process a certain kind of input or it is incapable of taking decisions in a particular constraint, then it should just fail and let other fallback systems take over rather than creating a positive path anyway. And you will obtain that by putting the right guardrails, by controlling the right temperature, the controlling the right LLM configuration parameters to do that. So then it becomes a real enterprise grade systems with these parameters configured and deployed to production along with the code.
Yolandi
Absolutely. So what I'm hearing is that even though AI is so evolved, we still go back to the very basic principle of garbage in, garbage out. It doesn't matter what we do, it's always garbage in, garbage out.
Amar Aksa
That's correct. And also AIs and LLMs are still mathematical systems. They are still evaluating the context. They have to give you an outcome. So context must be codified.
Yolandi
So I know you're also a big fan of taking the KYC concept of know your customer into the idea of kya. Know your agent. How will that influence testing in the next for coming few months of AI development?
Amar Aksa
So KYA concept is an inherent next chapter of KYC or Know youw Human. See, agents have to represent the right human intent and they have to operate under the right policy framework. For example, I as a chief architect of the company cannot create an agent which can go look at HR systems and tell me the salary parameters or the salary patterns of my company. I shouldn't be allowed to do that. If as a human I don't have access to those systems, my agent should not have access to those systems. And that is where KYA comes in. Know your agent. KYA is really just trying to associate certain basic parameters to an agent, such as intent. What was it supposed to do? Its policy envelope in which constraints can it operate? What are its thresholds? Is it allowed to use X amount of resources to get the outcome? What if your agent has bad code and it goes berserk and starts consuming a certain resource in A loop and then causing you large bills. Those parameters have to be correctly baked into an agent and that form the KYA policy envelope of an agent that has to be stamped and trusted by the human who has delegated the agent behavior. Now in today's world there are very popular mechanisms like Passkeys and Fido, etc. Which can do it. But in test environment we can have equivalent variants of that which allow you to create that policy envelope for a test agent. And then you have to just do edge case testing, try to make agent do things which it was not supposed to do. Happy paths will mostly succeed because humans are wired to test happy paths. But it's incredibly important to to start testing edge case paths where you are not expecting the agent to do certain things. You are not expecting the agent to use so many resources or so many different systems to access to and make sure that those policy guardrails are well honored as part of tests. So KYA just becomes your scope based testing for agentic behavior in day to day systems.
Yolandi
This made me also think of something that I read recently is where it said that our agentic AI, well, all kinds of AI should actually be used as well. Not used, but implemented and handled the same way as you would handle a junior intern. Knowing that they can cause damage unknowingly and they can also create liability unknowingly. What you'll take on that and how do we, how do we work with that? How do we implement something that's supposed to make our lives easier, but then at the same time be very cautious in treating it like an intern, a junior intern for that matter.
Amar Aksa
Actually, I would go a step further and say junior intent who's not had enough sleep? Because without the right guardrails, the systems will start hallucinating and start producing different outputs. And that's what interns sometimes do because they do not have the context of the company. So they might produce different outcomes on a different day based on what was given as input to them. So that's a good analogy. I like the analogy you used of an intern and it strikes very accurately to this landscape because interns are a very good example. When they come into the company, they have the least context and they are there for a short duration. So they don't ever get the time to gather enough context and then operate autonomously. They will always require a guiding hand or a guide or a mentor to help them obtain knowledge to perform their current tasks. And then current tasks may become template at some point where they can become autonomous in that Envelope or policy envelope. But then the next new task, they will again need mentorship or guidance. So just like. And the reason behind that is because they will never get enough chance to be in the company for long enough to understand the company context. And the same thing is with agents, because agents, the same agent or the same system is going to do so many different tasks and has a certain amount of context memory that 10th time it is doing a new task, it will probably not have any context memory left to sort of relearn that. So you might have to unlearn some of the previous tasks and then relearn this new task, just like an intern.
Yolandi
And is that something that in the future might improve that having to unlearn all the tasks to make space for new tasks? What does the future look like?
Amar Aksa
There's the future is very much like how humans handle this thing. You just can't keep increasing the context because that will then make your outcomes very inaccurate. So being able to dynamically load the right context will be the key to getting these agents become more autonomous. In future they need to stay junior interns. But the systems around context management have to become better where based on a requirement they're able to load the right context. Loading the right context goes to the whole parameter of having organization based memories. If you are trying to execute a task for finance department today, you should be very quickly able to load a context which tells you my finance system uses XYZ tools. Here are the constraints, here are the patterns, here are the templates, here are the reports, etc. Please perform your task. So each organization documenting their context or documenting their landscape into a machine readable format and making it available for agents will become really important for future to be able to add more autonomy to these agents.
Yolandi
Perfect. That makes sense. So if we are now discussing this or just talking to an executive leader that has to sign off on new agents in his specific workspace and it's not necessarily a person involved in the technical aspect, but just someone that needs to sign off and make that executive decision. What are the three things that you would recommend that person think of or ask about this agent before deciding to officially sign off on it and implement it?
Amar Aksa
That's a great question. So one of my first questions would be around guardrails and policy envelope. I would ask my agent developers to show me how the agent behaves under stress. Is it able to? Happy parts are fine. I'll be happy to review the happy parts, but I want to see the sad parts, the messy parts, the negative parts. What if the logic goes wrong? What if the context is incomplete?
Yolandi
What.
Amar Aksa
What if the systems and the access to system access patterns are not accurate? What happens then? What is the outcome and how does it affect the customer? Then the second question is what happens in uncertainty? If you go back to technology and C back C days, or like old language programming days, you will realize that there was this concept of your system having an unpredictable behavior out of certain things. Like divide by zero was an unpredictable behavior. Crashing was the happiest thing. But anything could happen. No systems would define what should be the predictable behavior when divided by zero happens. It's the same concept. Whenever an uncertain input comes or whenever an uncertain constraint is applied, how does the system behave? Does it pause and restart with the right outcome? Or does it continue to work without any guardrails and then deliver the wrong outcome? Or does it fail fast? I think fail fast is important. Fail fast still is a great paradigm in the world of regulated systems and financial systems. Then the third question is, can we defend each action the agent took holistically to auditors? Every outcome, every decision, every step the agent took has to be audited and replayable. Why was a particular decision taken at any given point? The auditability and the observability and its own constraints is incredibly important because you cannot go out in the regulated world and say, I'm sorry the agent took that decision. The agent is still a delegated authority under a human intent. Remember, it's a junior intern operating under the guidance of a senior person. So it is their accountability and it has to be defensible, it has to be auditable.
Yolandi
And I think those are three fairly simple questions, but their answers will be invaluable in making business decisions AI related. That's it. Those are very, very great insights. Thank you so much, Amar. So what I get from our conversation today is that to build trust with our agents, we need to look at things like the consistency gaps and how we can address them and how we can narrow them as far as possible without overloading them with information that does not fall within their kya specs, basically. And answering fairly basic questions can give us a great indication of is this program ready for the real world or is it still stuck in demo mode?
Amar Aksa
That's great.
Yolandi
That's great. Thank you so much for your time today, Amar. I hope to speak to you again soon.
Amar Aksa
Cool. Thanks Yolandi.
Podcast Host
Thank you. Wrapping up today's episode, the three key takeaways for senior executives in regulated and financial industries from our conversation with Omar. First, to maintain AI sponsorship and ROI leaders must move beyond demo based systems by embedding predictability, determinism and automated guardrails early in the development process. Second, production grade AI requires treating prompt as versioned code and utilizing replayable data sets to ensure outcomes remain consistent and reliable across the product lifecycle. And finally, every agentic decision must be governed by a know your agent policy envelope. This envelope ensures that all AI actions are holistically auditable and defensible to regulators. Position your brand alongside the Fortune 500 leaders defining the enterprise AI roadmap for the opportunity to showcase your solution to the executives currently funding and scaling global initiatives. Partner with EMERGE to reach the decision makers holding the strategic mandate. Secure your partnership@go emerge.com partner that's g o.emerj.com p a r t N E R For further executive level analysis and to join our network of leaders delivering workflow impact with AI, visit emerge.com on behalf of the team at Emerge. We'll see you on the next episode.
Podcast: The AI in Business Podcast
Host: Daniel Faggella (with guest host Yolandi)
Guest: Amar Aksa, SVP and Chief Architect at PaySafe
Date: April 21, 2026
This episode explores the challenge of building trustworthy and auditable AI systems for enterprise workflows. Amar Aksa emphasizes the importance of embedding guardrails, evaluation mechanisms, and clear policies from the start, moving beyond flashy demos to robust production AI. The conversation centers on practical strategies for executives to ensure reliability, regulatory compliance, and sustained ROI from AI adoption.
Throughout the episode, Amar Aksa speaks with clarity and pragmatic insight, using accessible analogies (like the “junior intern”) to demystify complex technical safeguards for a business audience. The conversation persistently returns to practical risk management and the importance of foundational, auditable AI governance—guidance any non-technical executive can use to make better decisions.