---
title: "How to Use AI Agents in Safety-Critical Industries"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/zxst7kq5ns"
content: auto-caption transcript, proper-noun corrected
---

# How to Use AI Agents in Safety-Critical Industries

*Ketryx webinar — transcript of the recorded session.*

[▶ Watch the recording](https://fast.wistia.net/embed/iframe/zxst7kq5ns)

---

Hi, everybody. My name is Erez Kaminski. I'm the founder and CEO of Ketryx, and with me today is Gabriel Pascali. Hey, everyone. Gabriel is our head of solutions engineering, helps build a lot of, complex systems for enterprises small and large all over the world.

And today, we're gonna talk about how AI agents are transforming compliance for the life science, medical device, and other regulated industries. As a reminder, we're gonna record the session. We're gonna send out slides. There's q and a. There's people answering that q and a, so you're welcome to submit questions.

And then at the end, if you leave during the session or at the end of the whole thing, there's gonna be a feedback feedback survey. Please answer it. We really appreciate the feedback. It helps us, understand what next webinar to do and how to do it best to to bring you the content you're looking for. So let's start with a quick poll.

Where do you see the greatest opportunity to use AI, and how do you think of using that across the regulated product life cycle? And we we also welcome other if other is the right category for you. Yeah. I think, you know, the the big theme here is that there are a lot of use cases and that you need to be able to achieve many use cases in order to get that kind of our overall ROI. So finding a scalable way to to deploy agents is is quite critical in these environments.

It's not just about solving one problem and spending the whole team's effort to build automation and integration to do requirements drafting, for example. It's about how can you apply it across the entire life cycle, easily and and scalably. Yeah. And I think it's one of the challenges we're gonna talk about is AI is kind of really made to do small tasks, which is appropriate to a lot of different industries. But for us, because of the structured nature of processes inside GMP or regulated processes, or other GXP processes, there's this challenge of how do you know you've run through the process correctly, which is what Ketryx really does and how we're gonna kind of discuss that.

So I think the poll is about to be over, and if we could share that. Wonderful. So we see kind of generating compliance documentation is obviously one of the biggest things, detecting gaps and validation, summarizing audit trails, all the typical stuff, and performing change impact analysis, which is something we're gonna talk about today. So pretty excited about that. Apparently, not as excited as you are about classifying and responding to complaints, Gabriel.

Shit. Totally off target. And so, again, my name is Erez, founder and CEO. I used to work at, Wolfram Research helping implement large scale AI systems, at a variety of large companies. I then went to Amgen to lead AI for the medical device division, went to MIT and then started this company at MIT trying to help people around the world develop, validate, deploy highly regulated AI solutions, then software, and now also hardware systems, everywhere from medical device cloud based medical device to physical diagnostics to robots, to factory automation.

Gabriel. Hey, everyone. Gabriel Pasquale. I started my career at the Meta Corporation in a cybersecurity role focused on cyber physical systems and embedded system security. Spent a lot of time interacting with folks that support the medical device industry with respect to cybersecurity playbooks, the attack framework, CBSS, and the CVE database folks.

I went on, back to MIT for a degree in electrical engineering, computer science as well as an MBA. And then after, I spent some time at Amgen applying AI on the quality and reliability space. That's where I went ran into a lot of the challenges of building validated systems and validated AI. Was fortunate to meet Erez and have been working at Ketryx for the past few years helping folks evaluate and implement the platform, as well as manage aspects of the product management process. So looking forward to today's conversation and and demonstration.

And we won't talk too much about what Ketryx is. We've had a lot of webinars on that. You can find a link on our website to see a demo of that. But Ketryx is basically, an AI driven compliance platform. It combines, both agentic workflow and generative workflow with more standard automation to allow you to interoperate across many different product development and life cycle management systems, automatically generate all evidence of compliance, ensure enforcement of quality and QMS processes, and ship products faster.

And when I say faster, I mean, companies have used us to go from a yearly release cycle to a weekly release cycle. Some companies release with us every day, fully validated, fully documented software. So that's kinda what we do, and we connect it all with a layer of automation, AI, and this kind of cohesive abstraction that sits on top of your, product development systems. Today, we're gonna talk, first of all, about the challenge of leveraging AI and safety critical industries and why it's so important, how generative and deterministic AI and deterministic AI has a lot of names, symbolic computing, expert systems, rule based automation. But this idea of using both the generative component and the deterministic component in product development.

And then we'll talk about a lot of use cases, and Gabriel is gonna take us through quite a bit of demonstration of how this actually looks. Wonderful. And so when we look at the AI landscape and leveraging AI across product development, there are a lot of, features and and capabilities that you might consider. All the way from creating, requirements and drafting test cases, helping you manage traceability, or even doing simple q and a against product data, documentation, etcetera. I think one of the the main themes of today's conversation will be around how do you link a set of capabilities and features to achieve a specific use case.

How do you link item creation along with conflict and impact analysis in order to execute a full change management workflow. But, ultimately, all of these independent features and capabilities are necessary in order to support the overall, total product life cycle, which brings us to a little bit of a description from Aras on the TPLC. Yeah. So I always think it's important to understand the context of where you work and how we are using AI. So I wanna start with describing what a TPLC is and how, regulators and ourselves think about running through the total product life cycle.

So this is the end to end product design to manufacturing commissioning, deployment, post market surveillance kind of workflow, and we're gonna talk a little bit about how you can use AI in it. So the first part is the idea of designing a product, you know, kind of section, five and six to three or four. How do you launch a product? To start by, deciding you want a product a product to go out or you start with agreeing on the project, having a brief, unintended use, writing requirements, at least high level ones. And then you start to iterate, right, in an agile workflow, ideally, writing requirements, specification code together, verifying and validating that system, taking it on a design, validation or clinical trial, and then kind of packaging it together.

And Ketryx helps you monitor that process. You then need to go into the supply chain component where you are using stuff, whether that's a virtual supply chain like open source software and other supercuts, or you're using physical goods. Right? But you need to accept something, do, kind of a super view or an OTS review or a supplier review, understand where that's coming from, generate an SBOM or a BOM, configure a cloud appropriately, and get ready to start kind of building the final artifact and deploying it. You then need to, quote, unquote, manufacture as part of the software manufacturing or physical manufacturing process and soft kind of the build process, connect it to CICD pipelines, do an internal audit or an external audit to make sure the product's ready for launch.

It's fully traceable, and then you launch the product. What happens though is when you launch the product, you don't actually launch a product. You launch variants of the product. Maybe you're deploying cross regionally, so you have an EU variant that deals with GDPR. You have a US variant, or all this problem of variant management and global configuration management.

You then, have all these variants in the market and you get complaints for them, Both, kind of product feedback ideas and complaints about adverse events or things of that nature, which you need to address, do complaints trending, make sure you're fixing the product. So you take those complaints, you make them into anomalies or kappas or bugs or things of that nature, and then you create change requests or engineering change orders to figure out what in your life cycle, what in the design, what across the supply chain is not working, or what features you need and how to improve that. All those have a lot of challenging questions that AI can help solve. So we can see that between these points, and this is just a sample, we have different people working and different agents that could work taking input and turning it into output. For example, in the left top quadrant, going from complaints into kappas or change requests.

Now what's amazing is that in a modern system, there could be so many requirements. It's very hard for a person to understand what, impacts what and how the traceability works and what complaint might impact a particular configuration item or requirement. But actually, AI is really, really good at that, reading all the requirements you have and analyzing and helping you think about the root cause, helping you think about the impact, and then you can use Ketryx and the deterministic AI to check, the up and down feasibility issues and how the impact analysis go throughout the life cycle. Another example of that is to take, an item that comes in on the supply chain and audit it and make sure you have the appropriate compliance information in your s bomb, the vulnerability management information. There's all kinds of tasks within your processes and activities that you need to do, and AI can help you do that.

And that's the idea of Ketryx agents. It's a way to perform tasks while being monitored by a central system to ensure your activities and processes are executed correctly across the total product life cycle. And at the center of all of this is the need to generate evidence. As we work within a regulated company, we wanna generate evidence that we have done these activities, And that's where Ketryx helps you generate all this evidence from all the different connected systems you're working in in order to accelerate development. So the ultimate next question is is how how do we achieve that?

And I would say from from the enterprises that we work with, our partners, we see the current state is a big focus on on leveraging existing, enterprise AI assistance and tools. So we've seen significant adoption across all of our partners with tools like OpenAI's enterprise plan, Anthropics Cloud, or those that are using g Suite and already leveraging Gemini. For many of the leaders in the space, they've taken steps to incorporate existing data within the organization to fine tune those models and provide context against the global quality management system, maybe global product data, or in some cases, even post market data. The limitations, with respect to this phase are you're able to generate content and recommendations that are tailored to the global context of your organization, but you're oftentimes missing specific product context and you're missing context around the overall change management process, which is how do we get from a to b when attempting to achieve a specific, agentic use case. So on the right here, we have a set of use cases that teams are attempting to achieve.

Things like leveraging, you know, an agile validated development workflow, using AI, generating test cases, or or even doing automated complaint handling. And the two phases, I would say, or two key components of the gap between these two sides are, one, getting that assistant or that that generative tool into the context of your work. So does it understand the schema of a requirement that you're generating? Does it understand the relevant procedure SOP that describes how to write a requirement? And does it have access to the other relevant requirements from a past product or relevant requirements from the current product in order to better produce output for your current use case?

So with that, finding a way to get information and the correct context to the model is key in delivering value out of what is generated. The second and and maybe more more challenging part of this problem is how do you build awareness or give awareness to the AI assistant or the agent into the life cycle? This is not only connecting that assistant or agent to a set of life cycle systems so they can affect change. For example, pushing a requirement to go get actioned on, but also all of the challenges around ensuring that the quality management system is followed, that you aren't modifying data in a potentially dangerous way, and ensuring that the interactions that the assistant or the agent has with those life cycle systems are appropriately validated and controlled. So that's where, you know, we have thought deeply about this problem in how do you create effectively a system that allows agents and assistants to operate safely across a set of life cycle systems, in order to achieve ultimately, end to end use cases, not isolated siloed features.

Yeah. And I think, Gabriel, now is, like, a perfect time to talk about why, question we got before the webinar, which is how do you do this within a quality management system? And I was waiting for this slide to explain, well, the way you do it, is by ensuring there's human in the loop because there's this part of love and compliance aspect where we need to understand who modified the data and who allowed the data to be modified and who took ownership. So the way we view these assistants, these AI agents are kind of like Grammarly. It suggests things to edit.

It suggests, deeper insight. But at the end of the day, it is a human's choice and a natural person's choice to make decisions about regulated systems and safety critical products. Right? Both from a moral kind of perspective, from a safety perspective, from a compliance perspective. But basically humans need to make these decisions to make sure that things are safe, traceable, and reliable.

And that's these ideas of what is a safety critical agent. So a safety critical generative agent is an aid is an entity that has a prompt. It's kind of like a large language model. Right? You ask it a question.

It performs analysis. Like, for example, take a complaint or write a document based on all these different requirements, and then it analyzes it. And then based on that analysis, it makes recommendations of what to do. A human reviews those recommendations and then syncs them and propagates them across the systems of work so people other people can take those recommendations that have been reviewed and edited and, approved by a person and leverage them across their work across the different parts of the life cycle. So this gives kind of more central control and more shared understanding across all the different data sources.

And now we wanna talk a little bit about the difference between that type of agent that we just talked about, which is a generative agent that does a task. Right? You ask it for a prompt, it respond. It does a specific task to task oriented agents. It executes individual tasks in the life cycle, like changing one configuration item or changing one step.

One task we really love is the ability to translate between a set of stories into requirements or from requirements to stories. It depends kind of where you start your development. So, basically, like, an agent like this can take a bunch of stories and turn them into a technical requirement or take a bunch of requirements and took them turn them into a series of stories that people can implement. So moving between kind of an informal system of work to a formal system, of controlled approval and traceability. Then what happens is the problem is now okay.

So you have this agent executing a task, but how can you have someone execute a process correctly and ensure your quality system is executed correctly? And that's kind of what the Ketryx framework for agents does. Because in Ketryx, you can bring your own agents if you want. You can bring your own back end. You can use ours, but we also allow you to leverage our entire framework and the way we do symbolic AI and symbolic computing to ensure your quality system is executed correctly.

And this is part of an approach called neurosymbolic computing that we'll hear a lot more about over the coming years. And Ketryx is the first application I know that leverages neurosymbolic computing within a b to b environment to help enterprises execute, their quality system and life cycle. And so what happens? Let's look at a at a change impact analysis workflow. We know that some folks asked about that, so I think it's it's also great that we have it here where you have a change request or an engineering change over, something you wanna modify in a system.

You can then have an agent, get a prompt for that. For example, create a change request to add, change the machine learning engine of the application or to add a certain UI or to change the colors or something of that nature. And then the agent can write that change request or that engineering change over odor and suggest which requirements might be impacted by this change. It then can, kind of deploy the change request in the connected system after it's gone through human approval. The next step is you're now connected to requirements, and the requirements might need to be changed.

So the agent can suggest changes to the requirement and basically edit it, send it to a human for approval. And then as a result of the traceability and the symbolic or process oriented agent, you can continue to execute a change impact analysis process by going down your traceability in a deterministic way, checking the design inputs, or design outputs meet, conform to design inputs at every step. And every time you change a requirement, it'll open the underlying, child requirement or spec and basically ensure that that specification is also being reviewed. So on and so forth until you terminate the process or the traceability thread, which is what people do today a lot in change impact analysis. So, basically, you go step by step, and what happens is that, Gabriel, if you can click one more time, you kind of go one after the other through these agents, get human approval to do the different tasks, and the process agent ensures you're running the activity or process correctly.

And that's gonna be a big part of our demo today is how you connect these two things. And before we jump in and and talk about the specific use cases, it's important to note that with the recent launch around this feature within the Caprix platform, we've provided six different out of the box agents that we've been using here internally. In addition to these six agents, we also enable you to create custom agents, And we'll I'll show you what that process looks like when we get into the platform. But as a part of this webinar, we've actually adapted a few of these agents in order to go through that kind of change management process that's supported by a set of agents, altogether here. So the two main use cases that that we'll go over in the demo environment will be one around complaint processing.

So starting with a set of complaints, grouping those complaints, tying them to a set of anomalies, and then creating a change request or tying to an existing change request that would resolve that anomaly and therefore the the associated, complaints. The second one will be exactly what Erez was describing of detecting, first, specific change that we wanna make in the system, suggesting what changes to make to a set of requirements, and then cascading the the change in a structured, way that follows your quality management system, down to the leaves, which in this case would be ultimate year verification and validation testing, all while leveraging an agent to help generate recommendations. I see a good question actually here, from from one of the attendees on which of is the most used agent among the presented ones of the previous slide. And I think this is a good good chance to to mention that. I would say and and, Erez, I'll I'll I'll hear hear yours as well.

But I would say the requirements conflict agent and redundancy agent is one of the, most used one. And the reason is is that Ketryx is built to connect into existing requirements management tools and existing tools where you're managing the software development life cycle. This means that even though you have an existing system that you're using heavily heavily today, on day one when Ketryx connects to these systems, we can already deliver value with these two specific agents and, help identify those conflicts and and redundancies even without even talking about the other parts of the platform. Yeah. I think that one and the anomaly review one, it changes kind of every week who's using what, but, I'd say those are the ones that people are really excited about.

I personally love the change request agent because I write a lot of change requests of things I wanna see better in the product. And over time as you get complaints, I'd say that complaint agent is the most classic machine learning application in GxP that I'm aware of because it's been implemented in so many companies, over time. Wonderful. Thank you for that question. So what we'll do is we have a few slides to describe the use cases, and I'll jump back and forth a little bit from slides in the demonstration.

But we will start with a very quick introduction to what Ketryx is. We have lots of webinars, like Erez said, on a deep dive of our platform, how it aligns with different standards like sixty two three zero four. But just to ground for those folks that haven't seen Caprix before on how, Caprix works, this will help provide a little context as we get into some of the the AI features. Yeah. And I'm seeing a question here that just kind of sets us up is question is, do you provide APIs for interacting with ALM systems?

So I'd say absolutely we provide those APIs. And also, in many cases, we have pre validated connectors to those systems, that allow you to integrate with them, both for ALM systems, PLM systems, and commonly used software development tools that people use outside of those tools. So it's a great question. It's exactly what Gabriel is about to show. So thank you for that question, Deline.

Wonderful. Yeah. So when we go into the Ketryx platform for the first time, you'll be met with the projects dashboard. And what we'll see is a set of Ketryx projects that have been connected to external systems. In this case, I'm just gonna show you a project that's connected to Jira and your a code repository.

But this particular project could connect to Jama for requirements management, Polarion for kind of that complete ALM, including requirements management, or even QA systems like TestRail. When you go into a project in Ketryx, you'll be met with this all items screen. This shows us all of the different objects that exist across the different systems where our teams are working. So in this case, we have teams that are in Jira managing requirements. In this case, some of those requirements are risk controls.

In addition to some of the software design and a lot of testing information. We also have teams working in a source code repository. Looks like they're documenting part of the software design directly in the source code along with tagging automated test cases that live in the source code, and enabling Ketryx to both manage the approval life cycle of them and the ability to build traceability, which we'll look at shortly. To give you a sense of what it looks like to operate in one of these systems, I can open up one of these items over in in Jira. What you'll see in Jira is a few different things.

The first is a view into the traceability of the particular, in this case, requirement that we're managing, as well as the ability to conduct peer reviews and approvals directly within the system. This is key in order to allow your teams to continue using their preferred dev tools while still getting all of the functionality around traceability, AI agents, and ultimately generating all the evidence you need of compliance for your particular process. Going back and giving a little bit of insight into that audit trail, for each item that's managed within a connected system, Ketryx is tracking a complete and detailed audit trail of changes made to that item. This allows you to, greater auditability and allows Ketryx to help you with many key activities around ultimately change management. Another important part of maintaining a validated system is traceability.

So one of the other core tenets of Ketryx is to allow you to get real time visibility into the aspects of traceability that exist within a system, such as within your requirements management tool, but also across systems. So we might have a set of requirements that come from a requirements management tool that trace down into a source code or a ticketing system for design and testing, and even out to where we're maintaining, bugs, for example. And this particular view and real time, ability to navigate the trace matrix gives us an understanding for a particular component of our system, the upstream and downstream relationships. Again, coming back to change impact and understanding how how, an impact might affect other parts of the system. And this deep knowledge, Gabriel, I think it's important to mention the structured knowledge allows us to then use, symbolic AI or these process agents to deterministically round down the traceability graph and correctly execute different, processes and activities.

Yes. Which will become, very apparent as we as we go into the AI use case where the the kind of generative or the task agent interacts with that process agent. Before we move to talk about the AI the first AI agent use case, we'll round out this discussion of the intro to Ketryx with our release dashboard, which gives us a full kind of high level view of what process steps need to be executed in order to get to a validated release, as well as a set of documentation that's automatically generated from those different systems. So with a click of a button here, we can pull all of those records no matter what system they're being maintained across into a set of templates that have been configured for your organization. So just to show you an example of what one of these might look like, we can open up this system requirement specification for our sample project, and we will see, you know, a word template that pulls in information, in this case, from Jira as well as from our our GitHub code repository.

So with that whirlwind intro to Ketryx, we'll go back to the slides and and introduce the first use case that leverages an agent to execute a process. We'll start with AI driven complaint management, and this process starts with receiving, any number of of complaints against our product. And the first step that we need to do is go through a categorization of these complaints, whether it's an adverse event, severe adverse event, product complaint, or or other. Once we've done that classification, we can go ahead and group these complaints and understand how they relate to potential new anomalies in our system or existing anomalies that have already been reported. So the first agent that we'll leverage is an agent that looks at our existing anomalies as well as complaints that we have received and builds traceability from complaints to anomalies, the related anomaly.

And so now that we're in this Lung Insights platform example, we'll be back on the all item screen, and we can just filter down to get a sense of what types of items are in here for a particular release that we're working against. And you can see we have around, you know, ten different complaints, but we could have hundreds here. In addition to that, we have two existing anomalies. So in this case, you can imagine these anomalies are being managed in a ticketing system like Jira or Azure DevOps, and then our complaints are complaint coming from our complaint intake system. If we go into our agents module here and, yeah, I'll just reorder these.

We look at our first agent, which is tracing complaints to anomalies. If I open up, a run, so this run, happened last night. It went ahead and categorized the existing anomalies in my project and enabled me to build, traceability from the anomaly and the set of complaints that, relate to it. So with this finding, I can click review. It will suggest to me that this particular anomaly should trace to these sets of complaints.

And for each trace, it will also provide a description of why it believes that there should be a trace between that anomaly and that complaint. This is one of the core components, which is ensuring that any recommendation that the AI gives you is explainable. And as you can see here, that it all requires human review. So until I hit save changes here, we won't modify any data in the system, and this is part of a validated workflow within the Ketryx platform. So I can go ahead and save changes and that will push changes into the system where or sync changes into the system where I'm maintaining, that traceability.

The other one we will also do is is there's a second anomaly. We'll go ahead and review this anomaly and, see that there's one particular trace that it's made to a complaint. But in this case, let's see if, the AI, we have these AI suggest buttons that are that are inputted across different parts of the platform. We'll see if this particular AI suggest button has some other ideas for us. So it looks like maybe since the agent ran, there were some additional complaints we wanna trace.

It's also recommending that we trace this anomaly to the relevant parts of our product that that might be need to be changed due to this anomaly. Go ahead and save that change, and we'll go ahead and build that traceability. So now that we've done that, we've leveraged an agent to build traceability from groups of complaints to anomalies. We can move down to this next step, which is based upon this anomaly that's been reported against our product, can we trace it automatically to an existing risk that we have documented, or maybe we need to create an additional risk? Going back into our agents, we have an additional agent set up for that, which helps us automatically as anomalies are reported within our system, trace those anomalies to risks.

Opening up the most recent result for this particular, anomaly, we can see that it's recommending a few different things. The first, I guess, second thing here is a missing traceability link from our anomaly to a risk of incorrect and incomplete data in exporter reports. So if we go ahead and review this change, we'll see that it's gonna modify our anomaly and suggest a trace to a risk. And in this case, it looks like it's also tracing to a particular requirement. We'll go ahead and accept the trace to the risk in this case only.

We'll save that change and it will go ahead and create a trace from that anomaly to the associated risk. The final step in this workflow is how can we go about making a particular change? So with this, we will have a final agent that has working in the background to analyze both the risks as well as the anomalies and suggest changes to our system. We could coordinate the change through the anomaly item itself, but in this case, we we have a change order which allows us to to centralize changes for a particular release. Going back again to the the agents dashboard here, we have an additional agent which shows creating a change request based on an anomaly.

If I open up the result that ran last night, we'll see that for this particular, anomaly, it's recommending the creation of a change request. So up in so far, we up up until now, we have only been modifying items, creating traceability, but the agents can also suggest new items. In this case, it's suggesting that we create a new change request titled fix data filtering logic and export module. So the particular agent has read this particular anomaly. It's read related items to why this anomaly met exists and it's suggesting a change.

So when I click review, it will go ahead and draft that change request for me to go ahead and read over and give the thumbs up that we should push this into the system where we're managing our change requests or change orders. You'll also see that in this case, it's automatically traced to the particular anomaly and risk that the change request is related to. Now, of course, we wanna trace this to maybe a requirement that's impacted or a specification and ultimately downstream to a test case, but this saves us a lot of time as we build out our change request. I'll go ahead and create this item, which will push a new change request with that traceability. And, Gabriel, can I ask you to approve one of these items so we can show some of the traceability log?

Yeah. Absolutely. So if we go into a particular let's see here. So let's actually go into that change request which we just created, and we'll filter down for change request. And we'll go into fix data filtering logic.

And, Erez, you were saying you wanna go through just an approval here? Yeah. Just to show how one is the audit log of the changes based on the agent and then later to see it in the overall audit log of the whole system because I saw Robert ask a really good question here. Please provide an overview how Kettrick system can enable and facilitate to verify compliance to FDA standards for transparency based on this, particularly if the system, is periodically modified by the user or manufacturer, by added agents and and moving things around. So that's what we're trying to show here is, basically, all these activities get logged, resolved, closed.

And it's okay, Gabriel, if you didn't set it up for approval. We don't have to show the whole whole kind of thing because what we could do is just go into the history and see all the modifications that happened. So both for the kind of one previous step that was supported by I, but really generated and approved by Gabriel, same as Grammarly, and then kind of all the analog of the actions. And for the earlier question that someone else is, do we connect to, requirements management system, Polarion, JAMA, things of that nature? We connect to them, and then we allow you to retrieve this type of audit log from them as well, and create this cohesive, place where all the tracking of all the movement happens.

So that's kind of idea. And, Robert, please let us know if you answered that. Yeah. Wonderful. And we'll see more of that, I think, as we move to the to the next use case, which, you know, just to summarize here, we went through the process of grouping a set of complaints, tying that to an anomaly that was previously identified against the system, tracing that anomaly to risks that the anomaly introduces, and then ultimately tracing both that anomaly and the risk to a change order to address, to address the issue.

As we move into the next use case, which we're gonna talk through automating the design and development process, that sort of, auditability and tracking of changes will will continue to become apparent. In this case, we are gonna start with a change order or a change request. We have a product manager. Maybe Erez introduces a change order into the system, and the agent is gonna recommend, changes to new either creating new requirements or modifying existing requirements. Now the real challenge here is not necessarily recommending the change, but understanding the implications of making that change and ensuring that those implications cascade and that folks are notified about parts of the system that need to be reviewed.

So after we go through that agent that modifies an existing requirement, we'll see that that requirement relates through traceability to specifications and ultimately downstream to test cases. And so this process agent collaborates with the task agent in order to assure that we follow the traceability thread and cascade changes and and execute proper reviews on each item, before we go to the next step in our release process. So if we go into our agents, I'm gonna go down to this last agent number seven, which is modifying requirement based on a change request. So in this case, we have this agent that's run that has run-in the background and recommended based upon a change request the an update to a requirement. We'll see here that there's a requirement around seamless PAC integration with vendor agnostic support, and one of the recommendations is to add measurable performance acceptance criteria for the PACS integration.

So this is an update to an existing requirement, that ultimately is gonna require changes to specifications and and test cases to ensure that the requirement is still validated. Before I make this change, I'm just gonna open up the traceability screen and show you where this requirement sits in relation to other specs and test cases to give you a sense of what that looks like. If we open up the traceability screen and if we go to seamless packs, we'll just filter down to that particular requirement, we'll see this particular traceability thread. So the agent is gonna modify this design input and then the process agent is gonna instruct the users of the systems to reverify the downstream items that, flow out of this design input. So now that we've given a little bit of an overview of what that looks like, we can go back to the agent result, and then we'll go ahead and review this recommendation to add acceptance criteria.

And once we accept this change, we scroll down, we wanna make sure we review the change. So every change that's gonna occur on a particular item, will have this kind of red line, green line to understand updates that you're making to the particular, requirement or other design item. When we save this change, I'll go ahead and bring this requirement change through an approval process, and that will kick off our process agent, which will reopen those downstream items that now require re verification because we've modified an upstream requirement. So going into this particular requirement, which we just modified, I can look at the history and I can compare that history to the previous, time, which shows me those same changes, the changes that I just made with the agent. And then I can go ahead and edit this item.

I'll assign this item to myself as the owner, so I can go ahead and approve it. We'll save these changes here, And let's see here. We will bring this into two two one point one, And then I will go back to the all items screen to give this an approval. You can see here that it's now this particular item is in a resolved state because we've made a change to it. I can go ahead and transition.

In this case, I might need a permission in order to bring this to a result to an approved state. And I'm not sure The while I get rolling, just wait for a second to get that permission. I see here a question. Thank you so much for the attendee. Will there be particular recommended procedures for using your recommended AI agent within our respective QMS?

How will this agent be validated to meet functional requirements, and what mechanism will be in place to monitor the AI agent's performance versus quality objectives? So, I'd say that basically if you're in a large company that has a preexisting QMS, Ketryx as a system can be configured to that quality management system and the agents could be used as part of those tasks. Again, all these agents still come back to people for approval and for any modification. So as a result, basically, it's a question if you wanna include them in your procedures or not. Some of our agents, we have some validation we've done for them, and over time, that's gonna grow both in robustness and in the number of pre validated agents that come ready for use.

And those can, come with a monitoring package and to meet certain quality objectives. So that depends on your organization, but we can provide you with that information, as well as more and more tools to do that using a common technique for AI and other process qualification, which is statistical process control and monitoring of them. Wonderful. And so going in now that we can approve, may need to make sure that was part of the the appropriate approval group for this particular item, one of the other kind of core features here, the ability to manage a centralized set of approval groups, and then apply those approval groups across the set of systems that Ketryx is connected to. In this case, I'll go ahead and apply my part eleven compliant signature on this change to our requirement.

And as a result of this change, we will go ahead and see that those downstream items that we were referring to in the traceability matrix have now been reopened for review. So in this case, we have that software item, which was connected to the requirement along with the test case. Another view to see this within is on the release dashboard. So if we go back to a particular release that we're working on relevant to this particular set of items, we have this section called change impact analysis. And this will bring up any items that need to be re reviewed in the case that you yourself have gone through and changed an upstream item.

So this is, again, just describing how we can leverage that agent to make changes, but rely on the system, Ketryx, to ensure that the necessary process steps that occur after relevant to change management, occur in the correct order, following your process. Now in order to to close this out, we can go back through and we'll complete a release here altogether. I'll go ahead and approve this particular software item as reviewed along with the test case, and then we'll go to the release screen and and complete our release. And the idea here is that ultimately, you can collaborate with a set of agents in order to drive change and rely on Ketryx in order to enforce the downstream effects of making those changes. In this case, I'm gonna ignore this particular change request that we created earlier.

We'll just exclude that item and allow us to go towards the release. Alright. So now that we've closed all of our items, we can go back to the release dashboard for this one point one release. And a final step that we'll make is just to to remove one last control here, to allow us to do the final release. In this case, apologies on my side here.

So we would do our final test executions, which we I guess, Erez, on your side, do you think we have time to go through the test execution process? Or I don't think folks are wrapping up. One or two more questions I wanted to address, and then I wanted to close on time. You know, I think that one important thing to show is kind of how the, overall traceability is still intact, and that's a big part of this. Right?

It's how do you drive the generative AI agents through the traceability up and down, and how do you kind of execute systems like this? So we see our traceability is still intact. We still need to approve things. And, basically, we ensured through this execution that we were doing all the right things in the right moments. I know that there is a question that came before the webinar that I wanna just maybe assess and maybe we could try it live, Gabriel, is Yeah.

Ask the assistant if it can add which just launches kind of an independent agent. Can you add risks up to ten risks to this project? So we had a great question before the webinar. Thank you, for the question. Is how do you deal with documentation generation, which we basically showed.

Right? We generate a bunch of documents. We're about to show you at the end of this how we generate that, and how do you use that to review requirements and do software failure mode effect analysis, which is kind of this FMEA risk management. So now we launch the system, and this agent kind of reads all the existing requirements and creates risks that are appropriate for the system. So now we we created a bunch of risks.

It can keep going. Right? You can ask it to do deeper thinking about all these risks and failure modes. Let's create these items for a moment. And then I wanna show how documents are generated at the end, which is basically we go into the release dashboard, and we can see the specific change requests we generated.

So that kind of answers both of those questions. We just generated some risks. Of course, we're kind of on a demo mode that makes it much lighter and much less deep thinking. So we generated some risks. And now in the documents, we can regenerate the documents and show some of them.

Maybe we'll show, a quick risk management file, and maybe we'll show a quick kind of, problem report if one exists. And while we Absolutely. Yeah. While we do that, I'm gonna look at these questions here. I see your questions that, in many cases, user or not regulatory experts struggle to understand the process they're expected to follow.

While most AI agents use case focus on operational task, do you also see value in exploring AI agent acting as process interpreters, helping users understand what they're doing and why as a meaningful use case. I absolutely do see that as a meaningful use case. Once you upload your QMS documents into Ketryx, you can ask questions about your QMS documents and procedures and how to follow the next step. And then kind of how do you follow it, how you take the next action in the sequence, and how do you ensure people are following your procedures. On the other hand, the Ketryx process agent, which is kind of our this really deep validated automation that can could be configured to run your quality management system, it allows you to, execute correctly to solve that exact problem.

But thanks for that question. And this is kind of where we wanted to finish. Here are all the things we created, generated as documents, reviewed as items by people independently at scale, hundreds of people working simultaneously to review them. And here's the result of all that, all the evidence. Right?

So we kind of went through this life cycle. We generated this evidence. We generated risks. We connected them. We're able to execute them in the right time, and we see that we just created a lot of these things, right, just a moments ago here on the right hand side, that unresolved anomaly.

And so, Gabriel, can I ask you to go back to the webinar and just come back to that circle, and then we could just finish from there? Yeah. Absolutely. Let me go back to that slide here. One moment.

I know we have four more minutes, and we'll be done on time. I I see the questions coming in, so I appreciate them, and looking forward to getting some more. And I just wanted to finish here and say that's what we did today. Right? We took something through this entire life cycle.

We updated things. We did a modification. We had complaints. We modified requirements. We generated anomalies, traceability, review design input output, and perform change impact analysis.

At the center of it all, we created evidence as a result of all that work. And we've seen teams use this technology to accelerate their release, again, from a year to a week, reduce documentation time by over ninety percent. Some cases, eighty percent. Some people over ninety percent release daily, weekly, monthly, quarterly, but mostly control their own life cycle with stability and automation and reduce the amount of, error prone, monotonous work people are doing, increase employee satisfaction. And I'd say the most importantly is make safer products because you have this always on agent that allows you to have, zero lag safety and traceability.

So thank you, Gabriel, and everybody else for joining us, and I think we just need to talk about the next webinar and be done there. Yeah. Absolutely. So very excited to introduce this next webinar. And in in many ways, it's an extension of what we're talking about today, but with more of a concrete application on one of the most, common life cycle management, requirements management tools out there, which is Polarion.

I'm very excited to introduce this integration and go into depth on how we can not only access information more easily within Polarion through the use of the assistant as well as agents, but also how those activities connect into a software development tool, a ticketing tool like Jira. Really looking forward to this, and please go ahead. We'll we'll drop the registration link, in the chat. K. Thank you, everybody.

We're happy to take some more questions, and we'll leave you here. Appreciate your time today.