Speaker A
[music] Okay. Hello, everybody. My name is Chris Lovejoy, and I'm a member of technical staff at Anterior, and I work as a forward deployed engineer. So, I embed within enterprise organizations and help them get value from using AI agents.
Explores why current enterprise tech stacks struggle with AI agents, focusing on compliance, audit trails, data handling, and production challenges.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Enterprise tech stacks are not inherently designed for AI agents, requiring new primitives and architectural trade-offs.
- Auditability and compliance are critical and demand more than typical developer logs, needing immutable, unified transaction logs.
- Data privacy and strict access controls must be enforced rigorously in AI deployments, especially in regulated industries like healthcare.
- Human-in-the-loop escalation is necessary to ensure safe and compliant AI decision-making.
- Existing enterprise patterns can be adapted and combined with AI innovations to enable production-ready AI agent deployments.
What the video covers
- Chris Lovejoy and Saul Howard discuss challenges of deploying AI agents in enterprise tech stacks, especially in healthcare.
- Healthcare's strict regulatory and compliance requirements make AI deployment complex but offer lessons for other regulated industries.
- A typical enterprise proof of concept (POC) involves multiple layers including application, control, data planes, and model providers.
- Initial POCs often succeed technically but face significant hurdles when moving to production due to compliance and integration needs.
- Key production challenges include audit trails, data sensitivity, decision approval mechanisms, and integration with existing systems like Epic and Salesforce.
- Audit trails in enterprises require immutable, comprehensive logs that meet strict security standards like SOC 2, HITRUST, and HIPAA.
- Using a transaction log as a single source of truth simplifies auditability and compliance by making the system’s state fully traceable.
- Strict data access controls and role-based access control (RBAC) are essential to protect sensitive healthcare data when accessed by AI agents.
- Escalation mechanisms must allow human intervention and approval in AI-driven decisions to meet clinical and regulatory requirements.
- Combining existing enterprise patterns with new AI-specific approaches can help overcome current tech stack limitations.
Chapters
- 00:00Introduction and speaker backgrounds
- 01:21Lessons from healthcare for regulated industries
- 02:24Building an enterprise AI proof of concept
- 03:08Initial POC success and stakeholder reactions
- 04:05Challenges in productionizing AI: audit trails and compliance
- 04:55Security frameworks and audit trail requirements
- 06:29Architectural patterns for auditability
- 08:07Data privacy, access controls, and RBAC
- 11:04Human escalation and decision approval
- 14:47Evaluation and combining enterprise patterns with AI
Full Transcript — Download SRT & Markdown
Speaker A
And I previously worked at Anterior with Saul. Hi, everybody. I'm Saul. I'm VP of Engineering at Anterior. We're a New York-based company selling AI, uh, agentic AI to US health insurance companies.
Speaker A
Um, Chris and I have spent a lot of time building in enterprise and in health care enterprises, particularly. And health care is a very challenging place to develop and deploy AI.
Speaker A
Uh, health [clears throat] care is so challenging because of the requirements around process and, uh, compliance, the regulatory requirements that, that, that are so important.
Speaker A
Also because of the, uh, direct real impact that your work has on people's lives, which is, of course, also what makes it so rewarding.
Speaker A
Um, I think a lot of the learnings you can take from working in enterprise for health care, you can take to enterprise in other regulated industries. Like finance, defense, government work, anywhere where process is so important and has to be followed.
Speaker A
In this talk, we're going to talk about, um, some of the learnings that we've had, and specifically, we're going to talk about why enterprise tech stacks aren't ready for AI agents and some of the primitives that we've built in the past
Speaker A
in order to unlock them. And to make this concrete, let's start by considering a scenario that might be familiar to many of you, which is the, the enterprise proof of proof of concept, the enterprise POC.
Speaker A
And let's say we have identified a customer that we want to serve, and we've identified a priority use case with them. So, obviously, we're on the healthcare track here. Let's consider a, um, a large health system and a use case
Speaker A
that is some sort of administrative healthcare workflow. So, you work with them, you scope out a POC, you define the metrics that you are going to care about, you're going to benchmark yourselves on.
Speaker A
Um, you allocate two engineers, you spend 4 weeks building it, and, um, the actual build-out might look a little bit something like this.
Speaker A
An enterprise stack is very complicated. It's much, much more than we're showing here, but generally, you can have an application layer, a control plane layer, the data plane.
Speaker A
For your POC, you're going to need some access to the model provider as well.
Speaker A
And your POC is going to need access to data across all of these different planes. It may be some in the data lake, some directly from the application layer, for example. And so, you're going to deploy it something like this. It's
Speaker A
going to connect to all these different places. There's going to be some offline data pulling. There's going to be some maybe some online.
Speaker A
Generally, you'll get access to the data and push towards the results. And so, things go well. You, you get great results. The, the AI performs, you know, as you expected. You, you hit the performance metrics. Um, you know, it's
Speaker A
fast. It's relatively cheap. And you hold a meeting, you present this to the relevant stakeholders, and everyone seems pretty happy. Um, so, you know, your chief of finance, um, in the, in the company is very excited and wants to
Speaker A
understand what's going to be the impact on the budget for next year. Uh, your chief medical officer is excited to tell his, his colleagues, you know, how accurate his AI is. Um, and the head of sales asks, "Okay, when can we put
Speaker A
powered by AI? When can we put that on the websites?" Um, but the problem is that everyone here is assuming that the, the hard part is done, that the AI was, was the challenging part. But actually, as we know, often getting things into
Speaker A
production is really where the challenge lies. Um, and to get a bit more specific on what that challenge looks like, um, you hold a meeting the next day, you bring in the relevant stakeholders to discuss productionizing this proof of
Speaker A
concept application. And somebody raises their hand and says, "Um, can I see the, the audit trail for this? Like for us, for compliance, it's critical that we can see every step, every action that the agent takes, every piece of data that it accesses. Can, can
Speaker A
you give that to me?" And you realize actually, you know, with the way things have been implemented in the initial POC, without these, um, kind of true integrations, that actually that's going to be quite challenging.
Speaker A
And then somebody else, um, pops up with some other questions. So, somebody asks, "Okay, well actually, how is data, sensitive data being handled here? Um, how's that being passed to the agents?
Speaker A
You know, we have a very strict boundary around where our data can go and where it can't go. Um, is it, is this respecting that? How does that look?" And then your chief medical officer says, again, "Who's approving the
Speaker A
decisions here? Because we know in certain scenarios, we have to escalate to a clinician who will then, uh, you know, approve or, or, or not agree with what the agent is saying. Um, so, how does that happen? Like what's the
Speaker A
mechanism for that?" And over the course of the meetings, you know, you can imagine you get more and more questions. So, can untrusted data manipulate the model? How do we know that the agent continues to perform well? How do we deal with integrations?
Speaker A
How do we connect to Epic, to Salesforce, to the other kind of applications that we care about?
Speaker A
And for the purposes of this talk, we're going to focus on these four, the highlighted ones. For the other two, feel free to come and chat to me and talk about these later. We're very happy to talk, but, um, just in the interest of
Speaker A
time, we'll stay focused. And let's start with, uh, this one about the audit trail.
Speaker A
So, this is a question you're guaranteed to get from the security team. They're going to want to see an audit trail.
Speaker A
And for programmers, an audit trail sounds very like a typical developer log you might have in DataDog. Surely it's, it's, it's a similar kind of thing. But for security frameworks that, that exist in the real enterprise world, like SOC
Speaker A
2, HITRUST, HIPAA, an audit trail is, is a bit more than that. It, it has to contain a complete record of absolutely every action that the agent took. It has to contain all of the places where the agent
Speaker A
accessed data, all of the authorization by which the agent did something. It's, it's this complete record in, in a much more fundamental way.
Speaker A
And, uh, one way of thinking about it is in a legal sense. It say our agent's decisions came up in a court of law.
Speaker A
Could we show a justifiable chain of evidence for why the particular actions were taken by a decision? And that's something that could easily happen within the health care context, for example.
Speaker A
When I think about architecting systems like this, I think often about what do I want to make easy?
Speaker A
What are, but when I'm choosing my constraints, I'm saying, "Okay, these are the things I want my system to be easy," and let that drive the trade-offs that, that I'm going to make. And a particular pattern that, uh, uh
Speaker A
is used in lots of different industries, for example, in finance, is a transaction log.
Speaker A
An immutable record of events that store all of the transactions that happen throughout the system.
Speaker A
And this is append-only timestamp log. It's complete. So, this is your source of truth for all of the data of the system.
Speaker A
And it's unified. So, there's only one source of truth across all of the different agents that you might have running in parallel, for example.
Speaker A
And architecting this way, the making this trade-off, uh, means that auditability becomes trivial. It falls out of your data storage paradigm that you've chosen. It sort of is impossible not to be able to roll back time and, and see exactly the state
Speaker A
of the system at a, a particular point in time and be able to, uh, provide that as an audit trail for what happened, uh, uh, each point in time.
Speaker A
And of course, these are trade-offs. So, what's the trade-off you're making here? I think we could say that for this kind of event logging or some
Speaker A
Reads become more difficult because you have to read through all of the events in order to reconstruct a view of what happened.
Speaker A
And there are patterns like caching and snapshots so you can bring to to to make that that simpler, but there always is more effort there.
Speaker A
Although, I have seen in in the healthcare context that actually, you're going to want different interpretations of the raw data that your agents recorded after the fact. So, for example, it might be that more events happened and that changes
Speaker A
the interpretation of the healthcare journey, and you want a different view of the the source of truth at that particular time.
Speaker A
And this pattern makes that easy because all of your views of the data are ephemeral computed projections of the event log.
Speaker A
Um okay. Next, the compliance officer comes and is asking, "How is the sensitive data passed around the system? What's the life cycle of data within our system?" And within a healthcare context, as we all know, data means a lot. It's PHI, protected or
Speaker A
personal health information. It's has legal restrictions around it. Not just HIPAA, but other legal restrictions about the use of people's data. You cannot have your agent, just as you cannot have humans, accessing and reading and utilizing healthcare data
Speaker A
that they don't absolutely have a necessity to use at that that point in time for that particular journey.
Speaker A
And so, again, architecturally, when I think about how am I storing data within a particular system, I would like to think, "What is the shape of the data, what kind of characteristics does the data have?
Speaker A
For health care data, that might be that it's very complicated. It doesn't follow strict hierarchical um relationships.
Speaker A
It's uh sometimes unstructured and it's sometimes structured. It could be very large. For example, health care data but one piece of health care data can easily be over a megabyte in size or or much more than that.
Speaker A
Uh it has strict access controls. As we've been saying, the R back comes into play like uh both for humans and and then for agents downstream of that.
Speaker A
Uh it may even be we I've seen customers where they're not willing to have their health care data leave their own environment, leave their on prem VPC for example. So, we have tangential access to their to their data.
Speaker A
And so, an architectural paradigm I might go to is object storage. Schema driven object storage, I think is a good fit for this. It's m- matches well with the choice of using event logging because you can separate the two. So,
Speaker A
the events we talked about as the record of what the agent is doing at any particular time only contain references to the schema driven blobs that are the storage of the actual health care data itself.
Speaker A
And uh it's important therefore that the health care data is stored immutably again so that you can always go back in time and reconstruct what data the agent had access to at that particular point in time.
Speaker A
This separation of events for what happened and object storage for the data that was used at that particular point in time has actually some some very useful benefits. For example, with a system like this, it's possible for developers
Speaker A
to go back and debug and have observability over what happened, what particular steps the agent took, why it did that, and and retrace the agent's steps without having access to the personal health information itself.
Speaker A
Although because of the schema driven, they can see the shape of that data, they they can't and to be honest, often won't be able to be given access to that health care data.
Speaker A
So, you can separate out observability and orchestration and instrumentation from the health care data itself.
Speaker A
And this then has another benefit, which is zero trust. It it the object storage becomes a place where you can apply zero trust principles.
Speaker A
Your agents can bear tokens and use those tokens to access the data at the point of use and not allow data to flow around the system as it likes.
Speaker A
This then leads into a mitigation for prompt injection for the lethal trifecta. The way I think about the lethal trifecta is can I solve for the constraint if I have an agent at point A with access to this
Speaker A
data? Is it possible within my architecture for the agent to be also accessing data over here?
Speaker A
And zero trust principles, tokens are bad by the agents and object storage segregated from the event stream that has your orchestration logic gives you a place to be able to solve for that constraint. It won't be possible for the
Speaker A
agent to access data within the same process that that you've given it the the previous data.
Speaker A
Okay, so then it comes to how do you handle escalation? And in many scenarios, you will want to be able to escalate the decision that an agent makes or an action that an agent makes to a human.
Speaker A
But one of the challenges here is that this is quite dynamic. So, you don't know in advance when exactly perhaps the agent's going to escalate. It could be that you're asking the AI to escalate when it's not sure.
Speaker A
Um it could be that you define some sort of rules in your system, maybe in a medical context, the treatments going above a certain threshold means that it needs to be escalated uh for an approval.
Speaker A
But [snorts] this makes it very challenging because of this this inability to predict. And a second challenge is also that humans and LLMs ultimately process context differently. You know, LLMs will have no problem if you give them massive
Speaker A
massive amounts of text, but humans that's not the case. So, what we've seen is that one pattern that can work very well here is if in your platform you enforce you kind of a wider definition of agent which
Speaker A
encompasses both LLMs and humans, then you can make it such that any action that can be taken by an LLM could also be taken by a human.
Speaker A
And this is helpful because at any point in the kind of chain of actions that your agent is taking, it can escalate to a human, the human could perform that action, and then any step downstream doesn't care about whether it was a
Speaker A
human or an LLM that did those actions upstream. Um and on the second point around the context, what this also makes much easier is that you can define methods that take the context, which has some kind of shared definition of
Speaker A
context, which is irrespective of whether it's a human or an LLM that's going to be accessing it.
Speaker A
And you can take those methods to then map into something that's agent friendly, like a prompt, or into something that's more human friendly, for example, a UI.
Speaker A
And then on this fourth and final question that we're going to talk about, um evals.
Speaker A
Obviously, you know, we hear a lot about evals. We know that evals can be very helpful, that often they drive decision-making about the types of model you want to use, the type of approach you might want to use
Speaker A
within your product. But we also know that evals can be pretty hard, and there's various factors here. We [snorts] know that LLMs are not deterministic, so it can be quite tricky to pin down the precise change that led
Speaker A
to some sort of change in outputs. Um we also know that the data that you might put in an offline data set might not necessarily represent production data, and it could be that um maybe you sampled from data, but
Speaker A
actually that sample isn't truly representative. And then you also have drift of data over time, so maybe your offline data set is now out of date.
Speaker A
And what we found is that these three primitives that we've described described so far in the talk actually give you effective privacy preserving evals almost as a byproduct without needing to kind of bolt something onto the side of your
Speaker A
architecture. So to make that more concrete, so the immutable ledger, what this means is that you can replay your actions. So you can go back to any particular time, you know, in this kind of sequence of events, you can see the complete state
Speaker A
of the system at that point in time. And if you wanted to, you could then make very specific tweaks. So you could tweak a prompt, you could tweak a model, you could tweak the code, and you can see
Speaker A
the exact direct impact of that because you have all of that context. Secondly, you have this human agent equivalency, which means that for any task, you could get both the agent, the LLM agent, and the human to perform it,
Speaker A
and your difference is your eval, that gives you the eval scores. And then finally, what the object storage enables you to do is to actually run these evals on production data including inside your customer's environment without actually ever
Speaker A
exposing that data. You can get your eval results without the sensitive data ever needing to come to where your agent is performing the work.
Speaker A
Right, so we've gone through four architectural principles that we found useful for building in healthcare and more generally in regulated environments for enterprise. The immutable ledger of actions, the orchestration adjacent object storage, the human agent equivalency, and the way that with these
Speaker A
three principles evals can emerge as a first-class property of the system rather than as something you attach onto the side.
Speaker A
I think one of the matters here is that I like to think about architecture as taking your constraints very seriously and thinking about what you want to be simple within the system and then choosing the trade-offs for that.
Speaker A
And of course, alongside that, some things will become hard, but it's the things that are simple that are most important to you.
Speaker A
And that there are patterns that already exist across enterprises that solve for a lot of these things. And sure, with AI, we need to combine them in new, sometimes radical ways and bring in other way other pieces, but there are patterns that have worked
Speaker A
very well within finance, within defense, within big tech that that can be applied to this kind of system architecture.
Speaker A
And I'd say the takeaway is that where I've seen it go wrong is taking that initial POC, that um that point solution that showed so much promise and that that showed the high accuracy, for example, and then trying to build up from it,
Speaker A
strapping on the enterprise requirements as you come across them. Okay, we need eval, we need uh security, we need auditability, and bolting these on as additions to the the the foundations of the POC.
Speaker A
You end up with something very brittle, something very hard to uh uh externalize and to generalize across different use cases.
Speaker A
But where I've seen it go well is if you take the constraints of a production-ready, scaled enterprise uh system seriously from the beginning and treat those as the architectural principles that you're going to build everything upon and then build back up
Speaker A
towards that POC accuracy using your new primitives. Thank you for your attention. Thank you.
Speaker A
[applause] [music]
Topics:AI agentsenterprise tech stackhealthcare AIcomplianceaudit trailHIPAASOC 2RBACAI production challengesAI integration
