
Pipeline Conversations · 2025-01-15 · 52 min
Key moments - from our scoring
Substance score
25 / 100
Five dimensions, 20 points each
Production LLM security extends far beyond theoretical risks - this conversation showcases practical strategies from industry leaders grappling with actual security challenges. Dropbox researchers discovered vulnerabilities in GPT-3.5 and GPT-4 using repeated token attacks that could leak training data, highlighting how even advanced models remain susceptible to simple exploits. Google addressed hallucination risks in security incident response by implementing careful prompt engineering and human review loops, demonstrating that LLM reliability depends heavily on instruction precision. Slack navigated FedRAMP moderate authorization through multi-layered security architecture combining access controls, ephemeral storage, and integrated compliance features. MercadoLibre tackled RAG security with cryptographic hashing, database encryption, and data lineage tracking across their vector database infrastructure. Block manages hundreds of AI endpoints on Databricks by decoupling vector search endpoints from model deployment, enabling secure updates without retraining. Doctalib processes sensitive healthcare data on-premise using specialized LLMs and the OMOP Common Data Model, partnering with John Snow Labs for domain expertise. GitHub Copilot balanced developer experience with content moderation filters and code reference tooling to address copyright and IP concerns. These case studies reveal that production LLM security requires thinking beyond the model itself - considering data pipelines, compliance frameworks, access controls, and human-in-the-loop validation.
Dropbox researchers fed the models specific sequences of repeated tokens over and over again, which sometimes bypassed the models' built-in safety controls and allowed them to extract portions of the training data.
Google used careful prompt engineering with precise instructions (like 'summarize the security incident in 100 words, focus on impacted systems') combined with mandatory human review steps to minimize inaccuracies.
Slack implemented a multi-layered security architecture combining strict data access controls, ephemeral storage for AI outputs, and integration with existing compliance features, with security baked in from the start rather than added later.
Decoupling separates the vector database from the LLM model, allowing Block to update context data (like product catalogs or terms of service) without retraining or redeploying the entire model, reducing downtime and deployment risk.
Doctalib processes all data on-premise with no external API calls, uses Kubernetes for deployment, employs the OMOP Common Data Model for consistency, and deploys multiple specialized LLMs rather than one monolithic model, partnering with John Snow Labs for domain expertise.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode covers a wide breadth of companies and use cases but sacrifices depth for breadth, with most observations being restatements of widely known best practices (encryption, access controls, human-in-the-loop). Occasional specific technical nuggets - like Block's decoupled vector search endpoint or MasterCard's simultaneous retriever/generator training based on Meta's RRAG paper - are mentioned but never explored with enough depth to yield actionable insight.
It highlights this pattern we're seeing over and over in lmops. Finding that sweet spot between the power of automation and, you know, the need for a human to keep an eye on things.
Like they say, measure twice, cut once.
The entire episode is a recitation of conventional LLM security best practices recycled across every company discussed - multi-layered security, prompt engineering, access controls, encryption, RAG. There is no contrarian argument, no first-principles reasoning, and no claim that challenges what a well-read B2B operator would already know. Every conclusion is a platitude dressed in a new company's name.
It's all about looking at security from every angle. You know, think about data access, where you're storing things, how it all fits in with your existing systems, and of course those compliance requirements.
Encryption's key there. You want to make sure even if someone gets access to the database, they can't actually read the data without the decryption key.
There are no guests whatsoever. Two unnamed hosts - clearly in a scripted, AI-generated podcast format modelled on tools like NotebookLM - summarize third-party written case studies from ZenML's database. No practitioner shares first-hand experience, no operator is interviewed, and neither host demonstrates domain expertise of their own beyond reading a summary.
you've sent over some seriously fascinating case studies from ZenML's LLM Ops, um, database. I mean, talk about a goldmine of real world insights.
Speaker B: Yeah, it's incredible, right? The sheer variety of companies jumping into the LLM game is mind blowing.
The episode earns partial credit for naming a large number of real companies (Dropbox, MasterCard, Block, NICE, Harvard Business School, Thomson Reuters, etc.) and citing a handful of concrete metrics - NICE's 86% query translation accuracy, Thomson Reuters' 1,000+ monthly active users with 5-minute average sessions, Harvard's 50%+ student adoption rate. However, most technical claims remain vague ('strict access controls,' 'multi-layered architecture') and the case studies lack dollar figures, timelines, or engineering specifics that would make them actionable.
They've hit an incredible 86% accuracy in query translation.
over a thousand monthly active users and an average interaction time of 5 minutes per user
The conversation is clearly scripted and formulaic - every host question is a naive setup designed to prompt the other speaker's next paragraph, and every answer is met with uncritical affirmation ('Wow, that's amazing,' 'That's impressive,' 'That's a great example'). There is no pushback, no follow-up probing a weak claim, and no productive disagreement across the entire 52-minute episode. It reads as AI-generated dialogue rather than a real interview.
So how did they tackle that? Did they just like feed it a mountain of data and cross their fingers?
Wow, that's amazing. It really shows that LLMs, when combined with careful engineering and a deep understanding of the data, can bridge the gap between natural language and structured data.
Computed from the transcript - who did the talking, and the words that came up most.
Learn how leading companies like Dropbox, NVIDIA, and Slack tackle LLM security in production. This comprehensive guide covers practical strategies for preventing prompt injection, securing RAG systems, and implementing multi-layered defenses, based on real-world case studies from the LLMOps database. Discover battle-tested approaches to input validation, data privacy, and monitoring for building secure AI applications. Please read the full blog post here and the associated LLMOps database entries here .
Transcribed and scored by The B2B Podcast Index.
Speaker A: Okay, strap in, everyone. Today we're taking a deep dive into LLM security. But hold on, we're not talking theory here. We're going full on practical, focusing on what's actually happening in production environments. And let me tell you, you've sent over some seriously fascinating case studies from ZenML's LLM Ops, um, database. I mean, talk about a goldmine of real world insights.
Speaker B: Yeah, it's incredible, right? The sheer variety of companies jumping into the LLM game is mind blowing. And the security challenges they're wrestling with are just as diverse.
Speaker A: Totally. I mean, we've got Dropbox uncovering vulnerabilities in OpenAI's models. Google using LLMs to basically turbocharge their security incident response. Slack trying to build secure AI features while somehow navigating that FedRAMP compliance maze. It's wild to see how LLMs are already out there in action across so many different industries.
Speaker B: And that's what makes this deep dive so gripping. You know, we're not just theorizing about potential risks here, we're seeing how companies are tackling these things head on. And in the real world, which is a whole different ballgame.
Speaker A: Let's jump right in with Dropbox then, shall we? Their security team found some vulnerabilities in GPT 3.5 and GPT 4. And get this, they did it using something called repeated tokens. I mean, it sounds almost too simple to be true, but the implications are huge.
Speaker B: Yeah, it is a bit of a surprise, isn't it? You'd think something so basic would have been caught way earlier. Essentially what Dropbox found was that if you feed these models specific sequences of the same token over and over again, and it can sometimes, well, trip them up a bit, bypass those built in safety controls, you know, and in some cases, they were even able to pull out bits of the actual training data.
Speaker A: Whoa, whoa, hold on a sec. For our listeners who might not be swimming in token land every day, uh, can you break down what a repeated token actually is and why it could turn into like a security nightmare?
Speaker B: Sure. Think of it this way. Each word or even a piece of punctuation in a sentence gets its own unique code. That's basically a token. Now imagine feeding a model a string of the same code repeatedly. Sometimes it throws a model off, makes it act a little unpredictably. And in Dropbox's case, that led to security gaps.
Speaker A: Okay, that makes sense. But leaking training data, that's, I don't know, that's next level scary, right? Imagine sensitive info from that training set just dot out there, accessible to anyone who knows how to exploit this.
Speaker B: It's a wake up call, that's for sure. It shows that even these super advanced LLMs are still susceptible to these seemingly simple exploits. It makes you wonder, how do we assess the security of models we don't even control? Especially when these things are constantly evolving.
Speaker A: You know, it's like trying to secure a moving target, constantly shifting. Speaking of moving targets, let's talk about Google. Their use of LLMs for security incident response is really interesting. But come on, even they must have hit some roadblocks when building this system, right?
Speaker B: Oh, absolutely. I mean, they were focused on automating these incident summaries and the executive communications, the kind of stuff that's super important but eats up tons of time. The catch is getting an LLM to spit out concise, accurate summaries. Especially in security. That's a tough one. Hallucinations are a constant worry.
Speaker A: So how did they tackle that? Did they just like feed it a mountain of data and cross their fingers?
Speaker B: Not quite. It was much more deliberate than that. Think of it as giving the model really precise instructions. You know, like summarize the security incident in a hundred words, focus on the impacted systems and how the attack might have happened. By crafting these prompts carefully and adding in a human review step, they were able to minimize the, uh, the made up stuff and get the accuracy up.
Speaker A: That's a really important takeaway for Anyone building with LLMs, isn't it? Prompt engineering isn't just a fancy buzzword. It's crucial for building reliable systems. It's like having a brilliant but easily distracted employee. Gotta be super specific.
Speaker B: Exactly. It highlights this pattern we're seeing over and over in lmops. Finding that sweet spot between the power of automation and, you know, the need for a human to keep an eye on things.
Speaker A: Okay, so we've got Dropbox showing us these unexpected vulnerabilities and Google demonstrating how powerful careful prompt engineering can be. Now let's switch gears completely and talk about Slack, a company that basically lives and breathes Fedramp compliance. How do they manage to build secure AI features while meeting those incredibly strict standards?
Speaker B: That's where it gets really interesting. Slack's case study is a masterclass in building secure AI in a super regulated world. They had to meet fegramp moderate authorization, which means a whole bunch of security controls. They did it by building this multi layered security architecture.
Speaker A: You know, multi layered. So it's not just about finding one magic solution.
Speaker B: Nope, not at all. They combined strict data access controls, making sure only the right people could see sensitive info with ephemeral storage. Meaning those AI outputs were only kept around for a short time, minimizing the data breach risk. They also made those AI features work seamlessly with their existing compliance features. So they were leveraging what they already had instead of starting from scratch.
Speaker A: So for our listeners who are probably thinking about deploying their own LLM powered systems, what's the key takeaway from Slack's approach?
Speaker B: It's all about looking at security from every angle. You know, think about data access, where you're storing things, how it all fits in with your existing systems, and of course those compliance requirements. You can't just tack on a few security features as an afterthought. It needs to be baked in from the beginning.
Speaker A: Yeah, for sure. And you know, speaking of building things right from the start, let's talk about arg, or retrieval Augmented generation. It, it's grounded in actual fact, which is awesome, but it also opens up a whole new can of worms, security wise.
Speaker B: Yeah, RA is like the hot topic these days, right? You hear about vector databases and all this cool new stuff, but I can definitely see how relying on external data sources could be a bit of a security nightmare.
Speaker A: Exactly. You've got this LLM pulling info from all over the place, right? Mhm, APIs, databases, even just websites. How do you even make sure that information is accurate in the first place and hasn't been messed with? And what about data privacy? Are you accidentally exposing sensitive data that wasn't meant to be shared? It's like a chain, right? If any link in that chain is weak, the whole thing breaks down. So for folks building RA based systems, where do they even start with securing that whole supply chain?
Speaker B: Well, the MercadoLibre case study actually dives into this. They really had to grapple with these issues and ended up with this multi pronged approach.
Speaker A: Okay, let's unpack that. What did they do?
Speaker B: First they focused on verifying those model sources. It's not enough to just grab a model from anywhere. Right. You need to make sure it's from a reliable place and that it hasn't been tampered with. They started using cryptographic hashing to check the integrity of those model files.
Speaker A: Smart. But that only solves part of the puzzle. Right? What about the data going into the vector database?
Speaker B: Right. So next they focused on data privacy within those databases. Encryption's key there. You want to make sure even if someone gets access to the database, they can't actually read the data without the decryption key.
Speaker A: Yeah, uh, encryption is always a good idea, but what about actually controlling who has access to that data in the first place?
Speaker B: Absolutely. They implemented strict access controls so only authorized people could read and write data to the database. They even took it a step further and implemented data lineage tracking so they could trace back where any piece of data came from.
Speaker A: That's impressive. It sounds like they're thinking about security. Every single stage. But I mean, all of this must add a ton of complexity to the system, right?
Speaker B: Oh, there's no doubt it's a lot to manage, but the MercadoLibre team seems to think that this go slow to go fast approach pays off in the long run. They argue that putting in the effort on security upfront can save you a lot of pain later.
Speaker A: Like they say, measure twice, cut once. All right, speaking of taking things slow, let's talk about Codeum. They're the folks building that LLM powered IDE called Windsurf, right?
Speaker B: Yep, that's them. And their approach is really interesting because they prioritized all those enterprise ready features and security right from the start. I mean, it meant their initial rollout was slower, but they argue that was super important for building trust with their target audience.
Speaker A: So instead of rushing to market with a minimum viable product and then scrambling to add security later, they took their time. I can see how that would appeal to big companies who are always a bit risk averse.
Speaker B: Exactly. Codeium was really focused on building a platform that could handle all sorts of different deployment models. Not every company wants to run their LLM system in the cloud. Right? Some need on premise deployments or virtual private clouds for compliance or security.
Speaker A: Right, that makes sense. But building a system that can handle all those different deployments must be really complex, right? Mhm. Managing security across all those environments can't be easy.
Speaker B: It's definitely not trivial. But Codeium seems to believe that flexibility is key for getting buy in from those big enterprise customers. They also really focused on making sure their platform could integrate smoothly with all those existing enterprise security systems. You don't want to force companies to rip out their entire security setup just to use your LLM system.
Speaker A: I get it. It's about meeting customers where they are, not making them bend over backwards for your tech. But I'm curious, did they actually share any specifics about how they actually did that integration? The case study seemed a little vague on the technical details.
Speaker B: Yeah, it is a little light on specifics. They mention stuff like single sign on and role based control, but they don't really dive deep into the nitty gritty.
Speaker A: That's a bummer. It would have been cool to see a more detailed breakdown of what they actually built.
Speaker B: I agree, but even without those specifics, their overall approach is still valuable. It highlights the importance of thinking beyond the model itself and considering the whole environment where that LLM system is going to live.
Speaker A: Okay, so we've talked about how crucial it is to secure that whole R edge supply chain and the benefits of taking that go slow to go fast approach. Now let's switch gears a bit and talk about Block, formerly known as Square.
Speaker B: What's really interesting about Block is how they've managed to implement this comprehensive LLMOP strategy across multiple parts of their business using a mix of retrieval, augmentation, fine tuning, and even pre training. They've really embraced LLMs, but they haven't let go of their commitment to security along the way.
Speaker A: They're involved in so many different things, from payments to to point of sale systems, to even like bitcoin trading. Managing all those different applications with LLMs must be a logistical nightmare, let alone keeping it all secure.
Speaker B: It's a pretty complex landscape for sure. They're managing hundreds of AI endpoints using databricks platform, which is a testament to their engineering skills. But what really stood out to me was their emphasis on decoupling their vector search endpoint.
Speaker A: Okay, I'm going to need you to break that down for me. Decoupling the vector search endpoint. What does that even mean? And why is it so important for security?
Speaker B: Imagine you're constantly updating the information your LLM is using. Think of things like product catalogs or financial data. Traditionally, you'd have to redeploy the entire model every time you made a change. That's a time suck and it introduces risk. But by decoupling that vector search endpoint, they can update the context data separately without touching the model itself.
Speaker A: So for listeners who are probably like, huh, huh right now, can you give us a real world example of how this decoupling thing might actually work?
Speaker B: Sure. Let's say Block has an LLM that's helping customers with questions about their accounts. If they need to update their terms of service, they don't have to retrain or redeploy that whole model. They just update the relevant documents in the vector database and boom. The LLM can access that updated info immediately, no downtime.
Speaker A: Okay, I see how that could be a huge win. It makes the system more flexible, but more secure and less likely to break.
Speaker B: Exactly. And it highlights another important principle in llmops. Treat every single implementation as a version model. This meticulous version control lets them track changes, evaluate performance and rollback if they need to.
Speaker A: It's like having a detailed history of every single change made to the system. Which is super important for security audits and incident response.
Speaker B: Exactly. Now let's dive into the specifics of their security measures. Block knows the risks of handling sensitive data with LLMs. They've decided to stick with self hosted models for processing that kind of information. It gives them tighter control over security.
Speaker A: Makes sense. Keeping that sensitive data within their own infrastructure definitely reduces the risk of external breaches. But even with self hosting, you still need strong security controls, right?
Speaker B: Absolutely. Block uses input filtering to stop those prompt injection attacks where bad actors try to manipulate the LLM by injecting sneaky prompts. They also validate the model's output to catch and filter any potentially toxic or harmful content before it gets to the user.
Speaker A: That's impressive. So they've got multiple layers of defense built in, but those layers only work if you can actually see what's going on inside the system.
Speaker B: Right. Uh, that's where their secondary model validation comes in. Think of it as another set of eyes scrutinizing the output, looking for any signs of hallucinations, biases, or just plain inaccuracies. It's like having an internal auditor for your LLM.
Speaker A: Okay, now it's starting to sound like a really solid system. But what about data privacy? Block handles tons of financial data and those privacy regulations are only getting stricter.
Speaker B: You're right. They followed the least data principle, so they keep data storage to a minimum wherever possible. They have strict access controls, so only authorized people can access sensitive information. And they've integrated their LLM systems with their existing compliance features to make sure they're meeting all the regulatory requirements.
Speaker A: So they're not trying to reinvent the wheel when it comes to compliance. They're leveraging what they already have, which is smart.
Speaker B: Speaking of smart, let's shift gears and talk about doctalib, a European healthcare platform. What they're doing is fascinating because they're working in a really regulated industry where data privacy is absolutely paramount.
Speaker A: Yeah, health care data is about as sensitive as it gets. One wrong move and you're facing huge fines and a PR nightmare. So how is Dr. Lib using LLMs? And how are they making sure patient data stays Safe?
Speaker B: They're using LLMs to unlock insights from all that unstructured medical data. You know, doctor's notes, lab Reports discharge summaries to help medical professionals make better decisions. But the key here is that they're doing all of this within their own infrastructure. No external API calls and all processing done on premise.
Speaker A: Wow, that's a bold move. No. Relying on third party cloud providers or APIs. It definitely minimizes the risk of data leaking out, but it must also add a ton of complexity and overhead.
Speaker B: It's a trade off, for sure. They're basically creating this secure bubble around their LLM system and the patient data it's processing.
Speaker A: But even within that bubble, you still need strong security controls. Right? What are they actually doing to protect that data?
Speaker B: They're using Kubernetes for deployment, which gives them flexibility in how they allocate resources and lets them scale individual components independently. They also went with a relational database as the foundation of their system, putting a premium on stability and reliability over the flexibility of a knowledge graph.
Speaker A: Interesting. So they're prioritizing stability and control over potential performance gains. M shows how seriously they're taking security and reliability.
Speaker B: And they're not stopping there. They've implemented the MOP Common Data model, which is a standardized way of representing healthcare data. This makes it easier to integrate data from different sources and ensures consistency across their entire system.
Speaker A: So they're not just building a secure system, they're building a system that can easily talk to other healthcare systems. That's super important in the complex world of healthcare.
Speaker B: They're also taking a pragmatic approach to LLM development. They're not trying to build one giant LLM to do everything. They're using multiple specialized LLMs, each focused on a specific task that makes a lot of sense.
Speaker A: Instead of a jack of all trades, they're building masters of specific domains. It's like assembling a team of specialists, each with their own unique skills.
Speaker B: Exactly. They have one LLM that's dedicated to extracting information from unstructured text, another one focused on semantic modeling, and yet another for query processing. This modular approach makes the system more flexible and avoids the potential complexity and performance issues that can come with trying to build one LLM to rule them all.
Speaker A: But even with this modular approach, you still need to figure out how to make all these different LLMs work together. Right.
Speaker B: They've built this really sophisticated workflow that carefully manages how these specialized LLMs hand off tasks to each other. This allows them to leverage the strengths of each LLM while minimizing their weaknesses.
Speaker A: It's like an assembly line for AI, with each LLM performing a specific task in the overall Process. This level of coordination must require a ton of engineering effort.
Speaker B: Oh, it definitely does. And they're not just relying on their own internal expertise. They're working with external partners like John Snow Labs, a company that specializes in building LLMs specifically for healthcare.
Speaker A: That's a smart move. It gives them access to cutting edge tech and expertise, which is essential in a rapidly evolving field like this. But even with all the right technology and expertise, you can't forget about the human element.
Speaker B: You're absolutely right. Doctalib is investing heavily in training and support for their end users, recognizing that even the most advanced AI systems are only as good as the people using them.
Speaker A: It's a holistic approach, considering not just the technical side, but also the human factors. They're not just building a system, they're building a solution. So with all this effort, they must be seeing some good results, right?
Speaker B: Oh, absolutely. Their system is already showing significant improvements over general purpose LLMs like GPT4, especially in things like summarizing clinical text, extracting clinical information and answering medical questions.
Speaker A: That's impressive. It shows the power of building LLMs that are specifically designed for a particular domain to solve complex real world problems.
Speaker B: It really does. Now let's switch gears a bit and take a look at GitHub, um, Copilot, that AI powered coding assistant that's been making waves in the developer world. It's a cool example of how LLMs can be used to augment human capabilities in a very practical way.
Speaker A: Yeah, Copilot seems to be everywhere these days. You see developers raving about it on Twitter. It's even sparking some interesting conversations about the future of software development. But building a tool like Copilot, which needs to fit seamlessly into developers workflows, must have come with some unique challenges, right?
Speaker B: For sure. GitHub took a really deliberate and iterative approach to building Copilot. They started with a very specific problem, code completion. Instead of trying to build an AI that could write entire programs from scratch, they focused on a task that developers do thousands of times a day. Day.
Speaker A: It's a classic engineering principle, right? Start small, solve a well defined problem and build from there.
Speaker B: Exactly. And they didn't just lock themselves in a room in code. They really invested in building a framework for rapid experimentation, using a B testing to quickly evaluate different approaches and get feedback from users. They even used dogfooding, meaning they use their own product internally to validate features and find any issues early on.
Speaker A: Dogfooding. I love that term. It's such a great way to get real world feedback and work out the kinks before you release something to the public.
Speaker B: It's a valuable strategy for sure. Now, they didn't just focus on the functionality. They also paid close attention to the user experience. They knew that developers wouldn't use a tool that disrupted their workflow or felt clunky and intrusive.
Speaker A: So they had to find that balance between being helpful and staying out of the way. Like a good assistant. Anticipating your needs without being overbearing.
Speaker B: Exactly. And let's not forget about security and privacy. When you're dealing with code, you're often dealing with sensitive information. Things like API keys, database credentials, proprietary algorithms.
Speaker A: Yeah, a security breach in a tool like Copilot could be a disaster. So what specific steps did GitHub take to make sure Copilot was secure?
Speaker B: They implemented a whole bunch of measures, including natural language filters for content moderation. Think of it as a way to prevent the LLM from generating offensive or inappropriate code. They also built systems to detect and filter public code matches, addressing concerns about copyright infringement and intellectual property theft.
Speaker A: That's interesting. So they're trying to prevent Copilot from accidentally spitting out copyrighted code.
Speaker B: Exactly. And they even included a code reference tool that shows you where Copilot's suggestions are coming from.
Speaker A: That's a great way to build trust with developers. They can see where the suggestions are coming from and make sure it's not plagiarizing code or violating any licenses.
Speaker B: Now, building a tool as popular as Copilot also meant dealing with some serious infrastructure challenges. They had to scale their systems to handle a rapidly, rapidly growing user base.
Speaker A: Yeah, scaling AI systems is no joke. You've got to handle tons of data, manage complex workflows, and make sure performance stays snappy even as the number of users explodes. So how did GitHub handle the scaling challenge?
Speaker B: They migrated from a direct API integration to a much more robust enterprise infrastructure. They implemented robust monitoring and reliability measures to ensure the system could handle the increased load. And they built scalable caching and processing systems to optimize performance.
Speaker A: So they were thinking about scalability right from the get go, designing the system in a way that it could grow and adapt as needed. It's a good reminder that LMOS isn't just about building the model itself. It's about building the entire ecosystem around it. From managing the data to the infrastructure to security.
Speaker B: Exactly. And GitHub didn't just focus on the technical side of things. They also put a lot of effort into engaging with the developer community. They actively sought Feedback addressed concerns and built features based on what the community was asking asking for.
Speaker A: That's a smart way to build a product people actually want to use. It's about treating developers as partners, not just customers. Now, speaking of partners, let's talk about MasterCard. Their use of LLMs to fight fraud is really impressive.
Speaker B: MasterCard's implementation is a great example of how LLMs can be used to solve high stakes problems in the financial world. Fraud detection is this constant battle, and LLMs are turning out to be a valuable weapon in that fight.
Speaker A: It's like having an army of AI detectives constantly scrutinizing transactions, looking for anything fishy. But building a system like that, which has to be both accurate and dependable, must have required some serious technical skills.
Speaker B: Absolutely. MasterCard had to overcome some significant technical hurdles. Managing massive amounts of data, ensuring the security and privacy of sensitive financial information, and integrating LLMs into their existing fraud detection systems. It was no small feat.
Speaker A: It's not just about building the LLM, it's about building that whole ecosystem around it. So what specific technologies and techniques did MasterCard use to build their system?
Speaker B: They opted for a RAG architecture combining the power of LLMs with the ability to access and pull relevant info from external sources. This lets them ground the LLMs, reasoning and actual data, making it more reliable and accurate.
Speaker A: It's like giving the LLM access to this massive library of fraud detection expertise, which allows it to make more informed decisions. But they didn't just settle for a basic RAG setup, right?
Speaker B: No, they actually went further and implemented a more sophisticated approach based on Meta AI's original RRAG paper. This involves training both the retriever and the generator components simultaneously using open source model parameters to fine tune the generator to produce factual information based on what it retrieves.
Speaker A: That's getting pretty technical. It sounds like they're pushing the boundaries of what's possible with rag. Yeah, but all of this technical wizardry must come at a cost, right? I mean, training and running these LLMs can be be computationally expensive.
Speaker B: You're absolutely right. They highlighted how traditional LLM pricing models are being challenged by the variable costs of actually running these LLMs. It's not just about the upfront cost of the model. It's about understanding those ongoing costs of keeping these systems running in production.
Speaker A: It's like the hidden costs of LLM ownership. The stuff they don't tell you about in the glossy brochures.
Speaker B: Exactly. They need sophisticated usage tracking across different models and versions, detailed cost monitoring for each query and each tenant, and they need to Integrate that cost monitoring into their overall observability stack.
Speaker A: It's like having a detailed expense report for your LLMs, breaking down costs by model, by task, even by user. So you can see where you could optimize precisely.
Speaker B: And you can achieve that optimization through careful model selection. Based on what each use case needs, efficient prompt and query design to minimize token usage, and techniques like quantization to reduce the size and computational demands of models.
Speaker A: It's a multifaceted approach that requires both technical know how and a sharp eye for cost management. Now let's shift our focus to another key player in the llmops ecosystem. Databricks.
Speaker B: Databricks is doing some fantastic work in this space, especially with the tools and infrastructure needed to support the entire LLM lifecycle. Heather from Databricks really emphasized the importance of data governance and lineage tracking all the way from where the data comes from to what the model outputs.
Speaker A: That's huge, especially when we're talking about security and compliance. Being able to trace the origins of data and model outputs is crucial. It's like having a detailed audit trail for your entire LLM pipeline.
Speaker B: Exactly. They're also building tools to help evaluate model outputs, make sure ethical standards are met, and support both custom and off the shelf model deployment.
Speaker A: So they're thinking about the big picture, not just the technical details, but also the ethical and practical implications of using LMOS in the real world.
Speaker B: They're also addressing some of the key security worries that pop up with LLMs, especially when handling private data and fine tuning. They're building features into their platform to protect sensitive data throughout the entire LLM lifecycle.
Speaker A: That's critical point. As LLMs are used to process increasingly sensitive data, security and privacy have to be at the forefront.
Speaker B: Absolutely. And speaking of companies that deal with sensitive data, let's talk about Mercado Libre, Latin America's biggest e commerce platform.
Speaker A: MercadoLibre is an e commerce giant. What are they doing with LLMs and how are they handling security concerns?
Speaker B: They're using LLMs to personalize the shopping experience for their millions of users, with a major focus on product recommendations. They've built a really sophisticated LLM ops system to manage it all.
Speaker A: Personalization at that scale is a technical challenge in itself, but doing it securely adds another layer of complexity. What stands out to you about their approach?
Speaker B: Well, for one, they're using intelligent routing to send user requests to the best model for the job, ensuring that each request is handled by the model that's best suited for it. They're also using rate Limiting to prevent abuse and manage costs.
Speaker A: Those are smart strategies. Rate limiting is crucial when you're dealing with external API calls. It can stop those costs from skyrocketing.
Speaker B: Exactly. They've also implemented mechanisms to reduce latency to ensure a smooth and responsive user experience.
Speaker A: Experience.
Speaker B: And they've built in capabilities to integrate with multiple LLM providers. This means they're not locked in with just one vendor and have backup systems ready to go if something goes wrong.
Speaker A: So they're thinking about redundancy and fault tolerance. It's a good reminder that in the world of LLMs, things can and do go wrong. You gotta be prepared for the unexpected.
Speaker B: Absolutely. But it's not just about building a robust and scalable system. They're also making LLMs more accessible to people who aren't super technical. They've created custom playground interfaces and SDK tooling that makes it easier for developers and even non technical staff to integrate LLMs into their applications.
Speaker A: That's a huge step towards making AI accessible to everyone. It empowers more people to use the power of LLMs, even if they don't have a PhD in machine learning.
Speaker B: It's a great example of how LLMOPS isn't just about the tech itself, but about making that tech usable for everyone.
Speaker A: Okay, so MercadoLibre is tackling some impressive technical challenges while also making LLMs more accessible. Now let's shift our attention to a company that's laser focused on LLM security. Prediction Guard. Their name kind of says it all, doesn't it?
Speaker B: It really does. Prediction Guard is addressing a crucial need in the LLM Oaks ecosystem. They're building security solutions that are specifically designed for LLM systems. They're not just taking traditional security measures and trying to force them into the LLM world. They're developing new approaches that consider the unique vulner vulnerabilities and risks that come with LLMs.
Speaker A: That's a crucial difference. LLMs bring a whole new set of challenges, and we need security solutions that are built from the ground up to handle those challenges. So what specific risks are they focusing on?
Speaker B: They're tackling a wide range of security issues, starting with AI supply chain security, which is all about verifying the integrity and trustworthiness of the models and data used in LLM systems. This is especially important for RA systems, where you're relying on all those external data sources that could be compromised or manipulated.
Speaker A: It's like having a chain of custody for AI. You need to be able to trace the origins of every component and ensure that it hasn't been messed with. So how are they actually ensuring this AI supply chain security?
Speaker B: They've implemented a system called a trusted Model Registry that verifies where models come from and their licensing. Uses hash checking for model files to prevent tampering, employs industry standard libraries with the right security settings, and carefully vets all dependencies on third party code.
Speaker A: It's like applying those same rigorous security standards we expect in traditional software development to the world of LLMs.
Speaker B: Exactly. But it's not just about the models and the data. It's also about the infrastructure that supports those systems. Prediction Guard gets that even the most secure LLM model is vulnerable if it's running on a compromised server.
Speaker A: Makes sense. You could build the Fort Knox of LLM models, but if it's sitting on a foundation of quicksand, it's not going to hold up.
Speaker B: They stress the importance of those traditional security measures. Things like endpoint monitoring, file integrity monitoring, regular penetration testing, and making sure they're SOC 2 compliant. They also emphasize designing infrastructure that's scalable and resilient.
Speaker A: So they're not just focused on the fancy AI stuff. They're also paying attention to the nuts and bolts of good IT security. It's a reminder that security is a multi layered challenge and you've got to address it at every level.
Speaker B: They're also super focused on data privacy and protection. They're developing advanced PII detection systems that can automatically find and redact personally identifiable information from text. Configurable filtering options to handle sensitive data the right way, and strong access control mechanisms to make sure only authorized users can access sensitive data.
Speaker A: That's essential. Um, data privacy is a huge concern, especially as LLMs are used to process more and more sensitive information.
Speaker B: They're even advocating for integrating LLM security into broader security monitoring systems like cimes, which let companies centralize their security data and analysis.
Speaker A: That's a good point. LLM security can't just exist in a vacuum. It needs to be part of the organization's overall security infrastructure and practices.
Speaker B: Now here's where Prediction Guard gets really interesting. They're already thinking about the future of LL apps, where autonomous agents are going to play a much bigger role.
Speaker A: Uh, autonomous agents? That sounds both exciting and kind of terrifying. Uh, I can only imagine the security implications of letting those AI agents loose.
Speaker B: It's definitely new territory and the potential risks are significant. But Prediction Guard is already working on solutions. They're focusing on managed permission systems that limit what agents can do. Dry run approaches to test agent actions without real world consequences. And human approval workflows for critical operations.
Speaker A: So they're building in safeguards and checks to prevent those AI agents from going rogue. It's a good reminder that as LLMs get more powerful and autonomous, security becomes even more crucial.
Speaker B: They're laying the groundwork for a secure and trustworthy AI future. Their emphasis on practical implementation and real world considerations is refreshing.
Speaker A: It's a pragmatic and thorough approach that recognizes that LLM security isn't just a tech issue, it's a business issue. Speaking of businesses embracing LLMs, let's talk about Thomson Reuters. They've built an internal platform called Open arena that lets their employees experiment with and explore the potential of LLMs.
Speaker B: Thomson Reuters approach is fantastic. They're fostering a culture of innovation and experimentation with LLMs within a large organization. They understood the transformative potential of LLMs for their business and wanted to create a safe and secure environment for their employees to explore those possibilities.
Speaker A: It's like an internal AI playground where employees can try out new ideas and push the limits of what's possible with LLMs. But creating that kind of environment within a big company must come with its own set of challenges, right?
Speaker B: Definitely. They, uh, had to strike a balance between encouraging fast development and deployment while maintaining strict security and compliance requirements. They also needed to create a platform that was easy to use, even for those without a ton of technical expertise.
Speaker A: It's like working a tightrope. You want to encourage exploration and creativity, but you also need to keep things safe and under control.
Speaker B: Exactly. And they did a great job of navigating those competing priorities. They went with a serverless architecture built on aws, which allowed them to scale the platform quickly and cost effectively. They chose Amazon SageMaker as their primary model deployment platform, which provides a secure and managed environment for deploying and running their LLMs.
Speaker A: It's like they're building a city for AI, complete with all the infrastructure and utilities it needs to thrive. Using SageMaker lets them focus on what makes their applications unique without getting bogged down in the nitty gritty of managing the underlying infrastructure.
Speaker B: Exactly. And they smartly decided to include multiple LLM types on the platform, both open source models and the ones they built themselves. This gives their employees a wider range of tools to play with and lets them choose the best model for the job.
Speaker A: It's a good reminder that there's no one size fits all solution in the world of LLMs. The best approach often involves using a mix of different models, each tailored to a specific task or use case.
Speaker B: And they didn't just dump a bunch of models on the platform and call it a day. They also made it user friendly with features like an API first approach for easy integration, a modular design so they could add new models quickly, and a clean and intuitive interface to help employees find the resources they need.
Speaker A: So they're not just building a technically complex platform. They're also building a platform that's easy to use and integrate with. That's crucial for getting people to actually use it.
Speaker B: Security was a top priority from the very beginning. They built a secure data handling pipeline, implemented access control mechanisms to protect sensitive information, and incorporated a system for tracking data lineage so they could trace back the origins of any data used by the platform.
Speaker A: That's impressive. They're not just building a secure system. They're building a system that's transparent and accountable. That's essential for building trust with employees and ensuring that the platform is used responsibly.
Speaker B: And their efforts are paying off. The open arena platform has been a big success, with over a thousand monthly active users and an average interaction time of 5 minutes per user.
Speaker A: That's fantastic. It shows there's a real hunger for LLM experimentation within Thomson Reuters. And they've created a platform that people genuinely find valuable and engaging.
Speaker B: The platform has also uncovered lots of new use cases for LLMs. Better collaboration between teams, and a faster overall AI innovation cycle. For the company. It's a clear demonstration of the value of creating a dedicated space for LLM experimentation and innovation.
Speaker A: It's a reminder that sometimes the best way to unlock the potential of new technology is to just give people the space and the resources to play around with it.
Speaker B: Absolutely. Now let's switch gears and take a look at Zalondo, Europe's leading online fashion platform. They're using LLMs to analyze security data and identify potential threats.
Speaker A: The fashion industry might not be the first thing that comes to mind when you think of cutting edge AI. But Zalando is showing that LMS can be just as valuable in fashion as they are in any other industry.
Speaker B: Zalando's LLM O strategy is incredibly sophisticated. They're not just focused on accuracy. They're also prioritizing security, scalability and explainability. They're using LLMs to sift through mountains of data, security logs, network traffic, user behavior, looking for patterns that could indicate a security threat.
Speaker A: It's like having an AI fashioned police, always on the lookout for anything suspicious. But building a system that can handle that much data and deliver reliable results must be a real challenge.
Speaker B: It is. Zalando had to Overcome some serious technical hurdles, like managing a complex data pipeline, making sure sensitive customer data was secure and private, and integrating LLMs into their existing security infrastructure.
Speaker A: So it's not just about building the LLM, it's about building the entire ecosystem around it. Yeah. How did they approach these challenges?
Speaker B: They took a really methodical approach, starting with a solid foundation built on their existing data infrastructure. They use databricks Lakehouse platform, which provides a unified space for data engineering, machine learning, and business analytics.
Speaker A: That's a smart move. Using a unified platform like databricks lets them streamline their data pipeline and ensures data is consistent and accessible across different teams and applications.
Speaker B: Exactly. And they didn't cut corners on security either. They implemented strict access controls, data encryption, and a rigorous data governance framework. They understand that security and privacy are absolutely essential, especially when you're dealing with sensitive customer data.
Speaker A: That's a responsible approach. It's great to see that they're taking data privacy seriously, especially in an industry where customer data is often a prime target for attacks.
Speaker B: Absolutely. They've also put a lot of effort into building a robust monitoring and observability infrastructure. They're tracking all sorts of metrics, including model performance, data drift, and overall system health.
Speaker A: It's like a regular health checkup for their LLM systems. Making sure everything's running smoothly and catching any potential issues before they become major problems.
Speaker B: Exactly. And their efforts have paid off. They've seen significant improvements in their overall security since implementing LLMs, including fewer false positives, quicker incident response times, and a much better understanding of their overall security landscape. It's a great example of how LLMs can be a valuable tool for improving security operations, even in industries that aren't typically associated with cutting edge AI.
Speaker A: And it's commendable that they're sharing the lessons they've learned and their best practices with the broader llmops community.
Speaker B: Sharing and collaboration are so important for moving the field forward. Speaking of moving forward, let's switch gears and talk about Harvard Business School. They're actually using LLMs to create AI teaching assistants.
Speaker A: Wow. AI teaching assistants. That's something else. Is a fascinating use of LLMs, but using them in education brings up some important ethical and teaching related considerations. You want to make sure these systems are used responsibly and effectively.
Speaker B: You're absolutely right. It's not just about throwing tech at the problem. It's about understanding how it might impact students and ensuring that these AI tools actually make learning better. So how is Harvard Business School approaching this?
Speaker A: Yeah, how are they making sure it's done right.
Speaker B: They're being very thoughtful about it, involving faculty in the design and evaluation process. They're carefully choosing the data used to train the models and putting mechanisms in place to reduce bias and promote fairness. They're not taking this lightly, which is good to see.
Speaker A: That's reassuring. It's good to know they're thinking about the ethical implications along with the technical challenges. But what about the practical challenges? Building an AI teaching assistant that's both helpful and engaging can't be easy.
Speaker B: It's definitely not a walk in the park. They had to make sure the AI teaching assistant was giving accurate and reliable information. It couldn't be just another fancy search engine. It needed to be engaging and interactive. And of course, they had to address those all important privacy concerns, especially since the system would be handling student data.
Speaker A: So they're juggling a lot here. Accuracy, engagement, privacy, and making sure it aligns with the course's learning goals. How do they tackle all of that?
Speaker B: They started by building a solid foundation using a really carefully curated collection of course materials, case studies, teaching notes, books, even old Slack Q and A data. They used all of this to train a rag system that could find relevant info and generate comprehensive answers to student questions.
Speaker A: So it's like giving the LLM access to a library full of expert knowledge. It can pull from that to answer student questions. Kind of like having a team of amazing teaching assistants on call 247.
Speaker B: Exactly. But they didn't stop there. They also added a human review step where faculty members checked the LLMs answers to ensure accuracy and give feedback.
Speaker A: That's a smart move. It combines the speed and efficiency of LLMs with the knowledge and experience of human educators.
Speaker B: And to make it even easier to use, they integrated the system with Slack, a platform students and faculty already use all the time. This way, students could ask questions and get answers in a familiar and convenient environment.
Speaker A: That's a great example of how putting LLMs into existing workflows can make them more user friendly. It's all about meeting people where they are.
Speaker B: Absolutely. And of course, they didn't neglect security. They're using Azure OpenAI service, which offers a secure and compliant environment for running LLMs. And they're using SSOC2 type 2 compliant Pinecone database for vector storage.
Speaker A: So they're not just building something functional and easy to use. They're making security and privacy top priorities. That's crucial when you're dealing with sensitive student data. So all this effort, they must be seeing some positive results, right?
Speaker B: Oh, they definitely are. The AI teaching assistant, which they call Chattel TV, has been a huge hit. Over 50% of students are using it, and the feedback has been overwhelmingly positive.
Speaker A: Wow, that's impressive. It sounds like students are really embracing this new way of learning.
Speaker B: They are. Students said Chattel TV helped them get ready for class, understand the material better, and participate in more meaningful discussions. And it's not just the students who are benefiting.
Speaker A: Really? How so?
Speaker B: Faculty are seeing positive results, too. They're saying Chattel TV is giving them better insight into what students understand, making it easier to spot those who might be struggling, and even lightening their administrative workload.
Speaker A: That's amazing. It's a win win for everyone. The AI Teaching Assistant is helping both students and faculty. It's a powerful example of how LLNs can improve the educational experience across the board.
Speaker B: Speaking of improving experiences, let's move on to Nice, a company specializing in contact center solutions. They're using LLMs in a really interesting way to allow users to query contact center metadata using natural language.
Speaker A: That's pretty neat. Contact centers generate mountains of data. Calls, chats, emails, surveys. Being able to analyze that data easily and efficiently can be incredibly valuable for business.
Speaker B: Exactly. But translating those natural language queries into SQL queries, the kind that a database can understand, especially when you're dealing with complex database schemas. That's a tough nut to crack.
Speaker A: Yeah, I can imagine that getting really messy. One tiny mistake in that SQL query and the whole thing could go haywire. So how did NICE approach this challenge?
Speaker B: They started by making sure they really understood their database schema, uh, inside and out. They built a translation table for column names so they could handle changes to the schema without retraining the LLM. And they made sure the LLM understood what the data actually meant, which is key for generating accurate and relevant queries.
Speaker A: So they're not just throwing a bunch of raw data at the LLM and hoping for the best. They're structuring that data carefully and giving the LLM the context it needs to do its job properly.
Speaker B: Exactly. And they didn't forget about security either. They implemented strict tenant isolation to prevent data from leaking between different customers, input validation to block malicious queries, and access control mechanisms to make sure only authorized users could get to sensitive data.
Speaker A: That's reassuring. Security is absolutely essential in a contact center environment, especially when you're dealing with sensitive customer data. So they got the data figured out. The schema is well defined. Security is tight. What else do they do to make this system work?
Speaker B: They created a sophisticated Context management system to handle those back and forth conversations that happen naturally when you're querying data. The system remembers previous SQL queries and uses that info to provide context for the next one.
Speaker A: That's a great way to make the system feel more natural and conversational. Like having a dialogue with a data analyst where each question builds on the last.
Speaker B: Right. And to make things even more efficient, they came up with a data refresh strategy that caches SQL queries so they can be run again. This lets them update the data daily without having to regenerate the SQL queries every time.
Speaker A: That's a smart optimization. Yeah, it's all about finding that sweet spot between accuracy and performance.
Speaker B: They also built in several mechanisms for preventing and handling errors. This includes validating queries against their business rules and providing clear feedback to help users create more precise queries.
Speaker A: It's like having a safety net for users, stopping them from making mistakes and giving them helpful pointers when they need it. This is sounding like a pretty impressive system. So how is it performing?
Speaker B: They've hit an incredible 86% accuracy in query translation.
Speaker A: Wow, that's amazing. It really shows that LLMs, when combined with careful engineering and a deep understanding of the data, can bridge the gap between natural language and structured data.
Speaker B: It's a good reminder that LLMs are more than just hype. They're powerful tools that can solve real problems and make data analysis more accessible.
Speaker A: Absolutely. Now let's turn our attention to Salesforce, the global leader in customer relationship management.
Speaker B: Salesforce is a true innovator in the CRM space, and their approach to LLMs is ambitious and practical. They're not just trying to add fancy AI features. They're figuring out how LLMs can solve real business problems and improve the user experience.
Speaker A: That's a refreshing approach. So what are they actually doing with LLMs?
Speaker B: Um, they're using them to automate tasks, generate insights, and personalize interactions, all, uh, while making sure customer data is protected and AI is used responsibly.
Speaker A: That's a big goal. It's like they're walking a tightrope between innovation and responsibility. What were some of the biggest challenges they faced and how do they address them?
Speaker B: One of their biggest hurdles was ensuring the security and privacy of customer data. Their platform handles mountains of sensitive information, and they had to make sure their LLM systems didn't create any new vulnerabilities.
Speaker A: Data breaches are a constant threat, and companies like Salesforce are prime targets. They can't afford to slip up when it comes to security.
Speaker B: Exactly. They implemented a security architecture with multiple layers, including things like prompt injection, prevention, input validation, output sanitization, access controls for models, version control, and comprehensive auditing. They're also monitoring and logging everything from system performance to security events to how users are interacting with the system.
Speaker A: So they're not just building a secure system, they're building a transparent and accountable system. They can see what's happening, identify potential problems early on, and respond quickly if something goes wrong.
Speaker B: Exactly. And they've also put a lot of thought into how they integrate LLMs into their existing infrastructure. They've built a sophisticated backend system using load balancers, authentication services, API gateways and database clusters to ensure their LLM systems can handle the massive number of users they have.
Speaker A: It sounds like they're building a city for AI with all the necessary infrastructure to support a growing population of intelligent systems.
Speaker B: And they're not afraid to embrace new technologies. They're using serverless technologies like AWS Lambda and AWS Fargate to create flexible and scalable systems. They're also using an event driven architecture which allows them to react to events as they happen. And they're adding real time processing capabilities to create a more dynamic and responsive user experience.
Speaker A: It's a really modern and advanced approach to building AI systems, taking advantage of all the newest cloud technologies.
Speaker B: Their data management strategy is impressive too. They're using a combination of Amazon S3 for object storage and Amazon RDS for structured records to manage the massive amount of data their LLM systems generate.
Speaker A: It's like creating a massive data warehouse for AI with different storage solutions optimized for different types of data.
Speaker B: Right at the heart of their AI integration architecture is Amazon Q Business, which they're using to build and deploy conversational AI applications. They've integrated Amazon Q Business into their platform using an embedded Web experience via iFrame, which allows for seamless integration without requiring major changes to their architecture.
Speaker A: That's a really smart way to do it. It's all about bringing the AI to the users instead of forcing users to adapt to new tools.
Speaker B: And they haven't forgotten about the principles of responsible AI. They've implemented keyword filtering for both questions and answers. They're strictly adhering to guidelines from public safety agencies, and they only allow responses from authorized data sources.
Speaker A: So they're not just letting the AI run wild, they're carefully guiding its behavior and making sure it stays within certain boundaries. It's a reminder that AI is powerful and it needs to be used responsibly.
Speaker B: Absolutely. And their implementation is already showing positive results. They've seen big improvements in efficiency, cutting down the time it takes to do certain administrative tasks, from minutes to seconds. They've also boosted their ability to search and analyze information, made it easier to access relevant data across different systems, and automated the process of summarizing case reports.
Speaker A: Those are some impressive results. It really highlights how LLMs can drive real business value when they're implemented effectively.
Speaker B: And the users are noticing the difference too. At a recent industry conference, people were calling the system a game changer. They loved how it made insights more accessible, allowing more people to access valuable information.
Speaker A: It's a good reminder that AI isn't just about automation, it's also about empowerment. Giving people access to information and insights that they couldn't get to before lets them make better decisions and be more effective.
Speaker B: They definitely hit some bumps along the way, but they overcame them through careful planning, thorough testing, and a focus on creating a user friendly experience.
Speaker A: It's a reminder that building a successful LLM system isn't a walk in the park. It takes a combination of technical skills, business smarts, and a deep understanding of the user experience.
Speaker B: All these case studies we've discussed paint a pretty fascinating picture. The security of LLM systems is taking center stage and it requires a multi layered approach. It's not just about protecting these systems from attacks, it's about ensuring that the LLMs themselves aren't causing harm.
Speaker A: It's a whole new way of thinking about security. As LLMs get more powerful and become more intertwined with our lives, strong LLMs practices, especially those focused on security, will become even more important.
Speaker B: You've hit the nail on the head, and it leaves us with a thought provoking as LLMs become increasingly integrated into critical systems, how do we ensure that our security practices, regulations and even our understanding of risk can keep up with these rapidly evolving capabilities?
Speaker A: That's a question that goes beyond the technology itself. It's a question that touches on ethics, governance, and the very foundation of our society.
Speaker B: And on that note, we'll wrap up today's deep dive into the world of LLM security and production. Thanks for joining us. Until next time, stay curious and stay secure.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.