KENX AI in GxP East 2026

2026-09-16-1150-ai-validation-pharmacovigilance-it-compliance-lecture

46 min read

Pharmacovigilance and IT compliance AI validation lecture

Recorded 2026-09-16 at 1150 via Plaud. 34:14.

Summary

Twenty-four months of building and validating AI-assisted applications for pharmacovigilance and IT compliance, told as lessons learned. The validation paradigm shifted from deterministic CSV (known input, predefined output) to AI-assisted decision support (known evidence, acceptable behavior range), operationalized as a six-step GxP process: controlled evidence, fixed questions and prompts, AI analysis, evidence plus rationale, human review, approved output with audit trail. The team wrote dedicated SOPs for the AI SDLC, testing, and validation; built golden sets and baselines with three consecutive regression runs and delta views; hardened guardrail language so the system answers “unable to verify” when evidence is missing; and catalogued failure modes including severity inflation, duplicate findings, plausible but unevidenced assumptions, and citation overreach.

Agent personas carry CVs (training scope, versions, validation history, data residency) and get retrained when SOPs change; deployments isolate tenants, prohibit public web access, and retest decision-relevant behavior when vendor models change. Advice for smaller organizations: start with a bounded quick win, build golden test sets, and formalize a responsible-AI policy early to keep management support.

Plaud AI notes

<App-generated notes from the Plaud cloud, verbatim.>

Date Time: 2026-09-16 11:50:15 Location: CAMBRIGE, MA Instructor: Binesh Prabhakar; Ken; Speaker 1

Plaud summary

Across 24 months of building and validating AI-assisted applications for GxP-regulated environments—centered on pharmacovigilance (PV) and IT compliance—speakers detailed a cultural shift toward responsible AI, rigorous data security, and a reframed validation approach suited to probabilistic systems. Real-world outcomes included substantial time savings (e.g., compressing multi-day PV report drafting into minutes), improved cross-document mapping, and client-specific drafting aligned to varied templates and tones. Success depended on collaborative, human-in-the-loop workflows; strict AWS-based guardrails; client- and modality-specific training; and iterative validation cycles emphasizing evidence, traceability, and reviewer-led decisions. The validation paradigm moved from deterministic CSV (known input → predefined output) to AI-assisted decision support (known evidence → acceptable behavior range), reinforced by a six-step GxP process and custom SOPs for AI. Common failure modes (severity inflation, duplicate findings, plausible assumptions, citation overreach, contextual misreads) were mitigated through fixed prompts, controlled evidence, delta comparisons across runs, and guardrail language (“unable to verify” when evidence is missing). Multi-tenant SaaS deployment considerations and agent personas (e.g., “Michelle” for IT compliance, “Sam” for PV) underscored the need for agent-level CVs, version control, and client-managed qualification. Smaller organizations were advised to start with bounded, quick-win use cases, build golden test sets, and formalize responsible AI policies to secure momentum and management support.

Knowledge Points

1. Cultural and Ethical Foundations for AI in GxP

  • Responsible AI mindset: Educate AI teams on FDA principles and GxP priorities (traceability, guardrails, patient-centricity); embed fairness, transparency, explainability, privacy/data governance, reliability, monitoring, safety, and security.
  • Compliance culture: Shift from pure efficiency to defensible processes; normalize GxP terminology and rationale for controls within engineering teams; human experts retain final decision authority.

2. Data Security and Environmental Guardrails

  • Containment and isolation: Keep all data within dedicated AWS instances; enforce tenant isolation with per-client databases; least-privilege IAM, continuous monitoring, auditability, backups, and controlled change management.
  • Controlled agent behavior: Prohibit public web access; require agents to rely on authorized sources; iteratively harden guardrails and operationalize secure behavior.

3. Reframing Validation and GxP Testing for AI

  • From deterministic CSV to AI-assisted validation: Validate acceptable behavior ranges grounded in evidence and decision relevance, not exact wording.
  • Six-step GxP process: Controlled Evidence → Fixed Questions & Prompts → AI Analysis → Evidence + Rationale → Human Review → Approved Output + Audit Trail.
  • OQ model and acceptance criteria: Test for materially consistent facts, evidence basis, status, and conclusions; display citations, rationale, and confidence; document deviations; defer protocol approval until repeated controlled runs build confidence.
  • Dedicated SOPs: Create separate SOPs for AI SDLC, testing, and validation to reduce deviations and clarify AI-specific procedures.

4. Pharmacovigilance Use Cases, Client Variability, and Training

  • PV drafting and analytics: Support DSURs, annual summaries, SAE/DSCR reports, RTQs; extract data to Excel; generate visualizations and trend insights.
  • Client-specific templates and tonality: Customize outputs per client; preserve stylistic fidelity and citation handling.
  • Modality and terminology differences: Train separate agents for small molecule oncology vs. CGT/biologics; avoid cross-use without retraining; normalize terminology (e.g., AEs like nausea variants).
  • Discovery and documentation: Engage PV scientists to catalog internal vocabularies and report structures; cannot reuse validation artifacts across clients; invest upfront to align on expectations.

5. Testing Strategy, Baselines, Golden Sets, and Regression

  • Collaborative test development: Co-create scripts with SMEs and QA; handle synonyms and domain nuances; target precise queries (dose/country comparisons across indications).
  • Baselines and golden sets: Establish evidence selection baselines and golden sets to calibrate acceptable outputs; iterate 3–6 months to refine guardrails and protocols.
  • Regression and negative testing: Run multiple consecutive runs; detect unchanged vs. changed evidence; show delta views; prompt no-change warnings; validate platform core plus client-specific behaviors.

6. Failure Modes and Remediation

  • Common issues: Severity inflation, false deficiencies from missing evidence, plausible but unevidenced assumptions, citation overreach/misapplication (Part 11/Annex 11/GAMP), duplicate findings, false precision, lifecycle/context misinterpretations.
  • Guardrails and language: Replace definitive deficiency claims with “unable to verify” when evidence is missing; constrain severity classification to evidenced impact; ensure findings are editable with rationale and basis.
  • Deduplication and normalization: Cluster repeated findings; unify technical terms to prevent splitting identical concepts; constrain regulatory references to relevant contexts; incorporate lifecycle-aware checks (e.g., first PR not a deviation).

7. Outcomes, Agent Persona Model, and Architecture

  • Efficiency with accountability: Rapid evidence triage and drafting; cross-document reviews surface gaps/themes; traceable citations enable quick verification; human-in-the-loop decisions preserved.
  • Run-to-run transparency: Explain differences between runs; list changed/added documents; highlight material deltas to support auditability.
  • AI agent personas and validation: Define agent CVs with training scope, versions, validation history, and residency; retrain and revalidate on SOP updates; manage version control of prompts/templates/configs.
  • Multi-tenant SaaS deployment: Isolate tenants at infra/data layers; central control plane; larger clients prefer dedicated instances; client-managed qualification for agent releases; monitor vendor model/version changes and retest decision-relevant behavior.

Questions

  • [Insert Question/Confusion]

Assignments

  • Define and document AI GxP validation SOPs accommodating AI variability, with acceptable behavior ranges and evidence standards; create separate SOPs for AI SDLC and testing.
  • Implement strict AWS-based data isolation per client with least-privilege IAM, monitoring, auditability, backups, and controlled changes; verify agents cannot access external web sources.
  • Establish a responsible AI policy (fairness, transparency, explainability, privacy/data governance, reliability, monitoring, safety, security) and train AI engineers.
  • Conduct client discovery with SMEs to catalog templates, tone, internal vocabulary, and modality-specific terminology; build client-specific corpora and fixed prompts/questions.
  • Train separate agents per modality (small molecule vs. CGT/biologics); avoid cross-deployment without retraining and validation.
  • Create golden sets for priority use cases (DSURs, annual summaries, RTQs; geographic/dose comparisons); baseline performance and limits through iterative runs.
  • Co-develop test scripts with SMEs and QA; include synonym mapping; require explicit verification of traceability (citations/evidence links).
  • Pilot AI-driven evidence triage and cross-document analytics for change controls, CAPAs, access logs, and audit trails; measure time savings and reviewer satisfaction; confirm defensibility.
  • Set up regression and negative testing protocols: run at least three consecutive runs on unchanged and changed evidence; document deltas and prompt no-change warnings.
  • Implement guardrail language updates (“unable to verify”); calibrate severity logic; deduplicate findings; normalize terminology; constrain regulatory citation relevance; incorporate lifecycle-aware checks.
  • Use version control for prompts, questionnaires, report templates, and key AI configurations; document deviations and release readiness criteria.
  • For companies adopting AI, develop a simple roadmap and identify a bounded quick win achievable within three months to build momentum and secure management buy-in.
  • Evaluate third-party AI vendors for multi-tenant architecture, data handling/security, model version control, change notification, subcontractor dependencies; maintain regression scenarios post-change.

Highlights (button-flagged moments)

Presenter Outlines Scope of AI GxP Lessons Learned

The speaker, Binesh Prabhakar, begins his presentation by stating his intention to discuss lessons learned from building AI applications, directly echoing the title slide’s theme: ‘What’s working, What’s not, and What we should do differently’. • Visual Context: The slide introduces a presentation on ‘AI GXP Practice’ by Binesh Prabhakar and Vijay Chigarapati, posing the central questions of what works, what doesn’t, and what should be done differently. • Discussion Insight: Speaker 1 (Binesh Prabhakar) confirms the presentation’s purpose is to share lessons learned over the last two years in building AI-based applications for pharmacovigilance and IT compliance. • Key Takeaway: The presentation’s core objective is to distill two years of practical experience with AI in a regulated GxP environment into actionable recommendations for the audience.

Core Pillars for Validating AI in GxP-Regulated Systems

The presentation slide visually outlines the three core pillars for AI in regulated environments—GxP Validation, Data Security, and Responsible AI—which the speaker identifies as the essential ‘cornerstone’ for developing a compliant application, based on two years of practical lessons learned. • Visual Context: The slide titled ‘AI Ethos for GxP Systems’ categorizes key principles into three pillars: GxP VALIDATED (e.g., risk-based approach), DATA SECURITY (e.g., client data isolation), and RESPONSIBLE AI (e.g., fairness, transparency). • Discussion Insight: The speaker emphasizes that implementing these three pillars required a significant cultural shift, educating AI engineers on GxP regulations and patient safety to move their focus from pure tech development to compliant software engineering. • Key Takeaway: The speaker concludes that these three pillars—data integrity, ethical AI use, and GxP validation—are interdependent and absolutely critical; without all three, creating a successful AI GxP validation application would be ‘really difficult’.

Mindset Shift in AI Platform Validation: From Exact Outputs to Defensible Decisions

The presentation slide visually contrasts traditional software validation with AI-assisted software validation, a concept the speaker verbally reinforces by recounting how his team had to abandon expecting predefined outcomes and instead focus on whether the AI reached a defensible conclusion based on the correct evidence. • Visual Context: The slide outlines a practical shift in validating AI, moving from expecting a ‘predefined output’ (traditional software) to ensuring an ‘acceptable behavior range’ based on known evidence (AI-assisted software). • Discussion Insight: Speaker Binesh Prabhakar explains that his team’s initial approach to validation based on traditional ‘expected outcomes’ failed, forcing a six-month re-evaluation period to align with the realities of AI behavior. • Key Takeaway: The core principle for validating GXP AI applications is to control the decision-making process by verifying the evidence used and the defensibility of the conclusion, rather than trying to predefine the exact output verbiage, leaving the final decision to the human reviewer.

Speaker Validates AI’s Effectiveness in GxP Compliance Functions

While the presentation slide lists six key areas where AI is transforming functions, the speaker provides detailed, real-world examples confirming AI’s success in document analysis, traceability, cross-referencing, and tailored report drafting. • Visual Context: The slide outlines what is working with AI, highlighting functions like Evidence Triage, Cross-Document review, and maintaining a Human Review Loop, with the key principle of using AI to compress work, not to outsource GxP decisions. • Discussion Insight: The speaker confirms the slide’s points, explaining that trained AI agents excel at pulling information from source documents, providing traceability to specific audit trail entries, and significantly reducing the time for data analysis. • Key Takeaway: A central theme is that AI’s value lies in augmenting human reviewers by handling repetitive tasks like document mining and first-pass drafting, which speeds up processes while keeping final accountability with the human expert.

this talk is quite practical, it has examples that the speaker went through.

• Key Insight: A major challenge is aligning AI engineers with a GXP/regulatory mindset, which can take up to six months of training on patient safety, traceability, and validation principles. • Risk Identified: AI agents are not ‘plug-and-play’; an agent trained for one drug modality (e.g., small molecule oncology) cannot be reused for another (e.g., cell therapy) without extensive retraining. • Key Insight: Traditional software validation methods are insufficient for AI; a new, iterative approach involving Subject Matter Experts, QA, and engineers from the start is necessary. • Action Item: For smaller companies, secure a small, quick AI win within a three-month window to gain management buy-in before tackling larger problems.

Speaker Details AI Failure Modes in GXP Validation

The speaker elaborates on the presentation slide, providing specific examples for each listed AI failure mode, including exaggerating criticalities, making plausible but false assumptions, and generating duplicate findings. • Visual Context: The slide lists six failure modes encountered when validating an AI GXP compliance platform, including ‘Missing Evidence’, ‘Plausible Assumptions’, ‘Severity Inflation’, and ‘Duplicate Findings’. • Discussion Insight: Speaker 1 confirmed that the AI exhibited these failure modes, such as exaggerating the criticality of a missing document (‘Severity Inflation’) and incorrectly flagging that a periodic review was missed for a new system (‘Plausible Assumptions’). • Key Takeaway: The primary lesson from these failures is the need for rigorous, iterative validation and continuous feedback to fine-tune the AI, control its assumptions, and prevent issues like hallucination and report inflation.

Speaker Elaborates on AI Guardrails for GxP Compliance Validation

The speaker directly references and expands upon the on-screen slide, explaining that a key lesson was to ‘validate the guardrails’ by training the AI to handle missing evidence and justify its findings to constrain risk. • Visual Context: The slide outlines a strategy to validate AI by focusing on GxP process guardrails, such as having the AI state ‘unable to verify’ for missing evidence rather than manufacturing a deficiency. • Discussion Insight: The speaker confirms that implementing these guardrails was a critical and iterative process, requiring months of training to prevent the AI from making its own conclusions or exaggerating findings. • Key Takeaway: The core validation goal is not to prove AI is always correct, but to prove that deterministic controls and human-in-the-loop review successfully constrain the risks of probabilistic AI in a regulated environment.

Shifting from Exact-Output to Criteria-Based Testing for AI Validation

The speaker explains the critical shift in testing mindset required for AI, moving away from the traditional model of expecting exact outputs to an AI-specific model where responses are evaluated against predefined, decision-relevant acceptance criteria, as illustrated on the slide. • Visual Context: The slide contrasts traditional testing, which seeks an exact ‘Output B’, with AI testing, where a reviewer evaluates an ‘Evidence-grounded response’ against acceptance criteria. • Discussion Insight: The speaker recounts that his compliance team initially had a traditional software mindset expecting precise answers, a method that ‘completely went out of the window’ when validating the AI platform. • Key Takeaway: Successful AI validation requires abandoning rigid, exact-output testing in favor of a flexible approach that verifies if the AI’s conclusions are materially consistent, evidence-based, and decision-relevant, not just whether the wording is identical.

Strategies for AI Platform Validation: Quick Wins and Third-Party Considerations

The speaker elaborates on the on-screen slide, which outlines ‘Quick Wins’ and ‘Third-Party Realities’ for AI implementation, by sharing lessons learned from a two-year project validating an AI platform for pharmacovigilance (PV) and IT compliance. • Visual Context: The slide presents two sets of strategies for AI implementation: ‘Quick Wins,’ such as starting with a bounded use case and building a small golden test set, and ‘Third-Party Realities,’ like managing model changes and understanding data handling. • Discussion Insight: The speaker emphasizes the importance of starting with a small, manageable win to secure management buy-in, directly reflecting the ‘start with a bounded use case’ point on the slide, and advises creating a simple AI roadmap. • Key Takeaway: A successful AI GXP validation requires a fundamental mindset shift away from traditional software testing, extensive upfront collaboration between AI engineers, QA, and SMEs, and a clear understanding that AI outputs should be treated as drafts requiring human-in-the-loop verification.

Introduction of ‘Michelle’, the AI Agent for IT Compliance Reviews

The speaker presents a slide introducing ‘Michelle’, an AI agent designed for IT compliance, and elaborates on its capabilities and the extensive, multi-month development process required to overcome challenges like exaggerated findings and ensure its effectiveness. • Visual Context: The slide introduces ‘Michelle’, an AI agent for Periodic & Audit Trail (PR & ATR) reviews, listing key features like multi-source ingestion, transparent reasoning, and a human review loop. • Discussion Insight: The speaker explains that ‘Michelle’ is named after his former boss and is purpose-built for IT compliance, while another agent, ‘Sam’, handles pharmacovigilance (PV) tasks. • Key Takeaway: While the slide highlights the AI’s speed and accuracy, the speaker reveals that achieving this required a six-month iterative process of training and validation with subject matter experts to correct issues like exaggerated findings and ensure the ‘human in the loop’ could effectively verify its output.

now we have personas that speaker is thinking about

• Context: The speaker outlined a vision for a future QA organization where specialized AI agents are integrated with human oversight to improve efficiency. The personas are named to honor influential figures in the speaker’s career. • Key Insight: AI agents will be treated as specialized team members with defined roles, such as ‘Michelle’ for IT GXP and ‘Sam’ for pharmacovigilance surveillance. • Key Insight: Each AI agent will have a ‘resume’ or CV that documents its training data (e.g., Part 11, Annex 11), validation history, and version control, ensuring traceability. • Key Insight: The proposed system maintains a ‘human in the loop’ for oversight while leveraging AI for specific, repeatable tasks like SOP updates. • Action Item: When an SOP is updated, the relevant AI agent will be retrained on the new version and its ‘resume’ will be updated with a new version number.

Presenter Details Multi-Tenant SaaS Architecture for Validated AI Platforms

The speaker uses a slide illustrating a multi-tenant SaaS architecture to explain how they handle varying client needs for data isolation and custom deployments, a key lesson learned from validating AI in the GXP space. • Visual Context: The slide diagrams a multi-tenant SaaS architecture, highlighting different layers such as Users, Control Plane, Tenant Layer, and AWS Foundation, and showing options for both custom dedicated tenants and shared infrastructure with isolated data. • Discussion Insight: The speaker explains that this architecture is necessary because AI agents trained for one client (e.g., with a small molecule drug) cannot be directly used for another (e.g., with a CGT product) due to different terminologies and requirements. • Key Takeaway: The speaker advises that when evaluating vendors, it is crucial to ask about their tenancy models (single vs. multi-tenant) and confirms larger clients often require AI agents to be deployed within their own dedicated instance, as depicted by the ‘custom dedicated’ model on the slide.

AI GXP should have its own set of standard operating procedures (SOPs) rather than being integrated into one system.

• Speaker 1, Binesh Prabhakar, advises that creating distinct SOPs for AI GXP applications will lead to less resistance, fewer deviations, and a clearer path to successful implementation. • After 24 months of experience, Prabhakar’s team realized that a planned, traditional GXP validation SOP framework for AI was unworkable, leading to deviations at almost every step due to unpredictable outcomes. • The team spent about six months iterating on their approach, working closely with clients to understand specific requirements before they could build a reliable validation protocol, highlighting the need for a specialized process.

second person who says we should have a separate SOP for AI applicstions in GxP

• Context: This analysis is based on 24 months of experience building and validating AI-driven GxP applications. It addresses the challenges of fitting novel AI development lifecycles into traditional, rigid validation SOPs. • Key Insight: Attempting to manage AI GxP validation within a single, all-encompassing SOP leads to significant difficulty and frequent deviations. • Action Item: Develop a new, dedicated SOP for AI GxP applications that defines its own unique SDLC and testing processes. • Key Insight: Utilizing separate SOPs for AI GxP reduces implementation resistance and creates a clearer, more predictable validation pathway.

Transcript

[00:01] Speaker 1: My name is Binesh Prabhakar. I’ve been in the GXP IT space for the last 20 years. You know, doing a lot of validation work, writing protocols and all sorts of things of that nature. For the last two years, we’ve been involved in really building a couple of AI-based applications supporting pharmacovigilance and IT compliance and. The purpose why the focus of my presentation would be to talk about what we have done over the last two years, lessons learned, what worked, what didn’t work, and what we would recommend from our learnings that you can take back to your place and put it into practice. So that’s that’s really the purpose of this. Before we go anywhere, I think one of the key points that we felt. Talking to clients and really putting an AI GXPI application. What we really figured out was the AI guys are basically tech bros, right? So they are tech people with no sense of GXPI and regulations, right? They they go ask to build something, they go build something, and it was really important for us internally, even within the the AI development team and within the company at, to bring a culture of compliance. But also the the guiding principles around AI, right? Why FDA certainly came up with their guiding principles. They came up with ten different points. It was really important for us to educate the AI engineers and saying why we are doing what we are doing. You know, end of the day, it’s about the patients. It’s not you know, yes, efficiency is good and all of those things. But bottom line is, we need traceability. We need certain guardrails and things of the nature. So. What really did so, which goes back to really building responsible AI-based applications. So that’s something we made sure that we insisted in. And as over the last two years, what we’ve noticed is even our AI engineers are now talking GXP. They’re saying validation. They, you know, they understood some of the guiding principles and things of the nature. So really changing their mindset from. Building a software into basically saying, “Hey, building a software that end of the day serves the patients.” So that mindset had to be changed because a lot of some of the folks that we had were pretty much not traditional software aspects. So they they use AI tools and things of the nature. So they had a very different mindset. So changing the mindset was one of the biggest things that we had. Certainly, you know, the other piece was guardrails around data, data security, you know, general data integrity practices. But also making sure that data stays within our AWS instance or within the client’s AWS instance. So that was another big piece that we really had to insist on, and also making sure that the agents themselves don’t go outside to the World Wide Web, go through answers, and come back. So essentially, having those security guardrails around whatever they’re standing and so that was another big piece learning for us. And again, a lot of this took time and iteration and learning, and so on. The third piece is basically the GXP validation itself. So we’ve all done traditional CSV validation. For us, what what we realized was we put together AI GXP validation SOP, and then going into day one, day two, we knew, oh, we are going to deviate almost every single step because the expected outcomes. You know the compliance team put the SOP together. The development did their work, and when we go test it out, and we have several dry runs and so on. And what we quickly realized was, you’re going to deviate here from your SOP every step of the way in terms of expected outcomes and things like that. So that was a big, big lesson learned for lesson learned for us, and and a lot of training went into that. So I would say between these three pieces, probably we spent about six months. Going back and forth, back and forth, and back and forth. So, so those were some of the big key lessons. And I think where I’m taking this is basically as you guys are building internally or you’re looking at your vendors. I would certainly say these three pillars are the cornerstone in terms of data integrity, ethical use of AI, and then the GXP validation. Those three pillars are extremely important. Without which, it it would be really difficult to have a AI GXP validation application. All right. What what changed when we validated an AI platform? Right, several things, of course, and it took time, it took resources, and failed attempts and frustration and so on. So, outside of those things, I think the compliance team went went and had a traditional software mindset. Basically, expected outcomes, meaning click this, click that, and then these are the different answers that you would expect in the protocol. That. Completely went out of the window. So, so one of the things we start asking was the we used an agent AI to solve two functions: one on the IT compliance and one on the farm coverage. So, I’ll talk about those things. On the PV side, what we figured the the application itself was used to is used to create summer reports for the PV scientist, you know, DSURs and annual summer reports and things of that nature, but also insights. And graphs for RTQs, and you know, any agency requested things like that. They wanted to be able to extract data from their existing safety database, really put that into an Excel, and then kind of create charts and reports and things of that nature. So those that’s the that was one of the problems we were trying to solve. And what we realized was the expected outcomes. So, for example, writing a summary report. We we came to know we immediately came to know that the tonality of writing a report for A client, one client, client A, and their template was very different from client B and their template. Just, just, just that itself was very different. Then we also realized for the AI agents, the client that we worked with had a small molecule oncology product, and another one had actually a CGT product. So completely different agent thinking, and the terminologies itself were very different. So what we had to do was basically for the small molecule line, we used the existing literature and had to train the agent within that particular instance. So the agent would understand not just the standard PBT terms like SAEs and AEs and so on, but also it had to go into the uncalibrated terms and kind of learn that as well. So that that probably took about three months, and What we realized also was we couldn’t take the same agent and use it for a biologic, so that that really didn’t work as well. So those were some things. So then, then the question is like, how would you have one set of expectations for one client and another set of expectations for another client, but kind of have similar functions? So the protocols had to be different to begin with, and the so we could not really leverage. The documentation that we had here and the expectations with one client, and use it for another client. That just didn’t happen, just because of the functions, because of the modality, and the functions, and so on. So those were some big lessons learned for us, and therefore, what what we did was we put a lot of time upfront in really talking to, for example, the PV scientists because they were the ones who were using the system extensively, and we had to spend a lot of time really understanding. Not just the pain points, but really terminologies. The internal, you know. For example, one of the clients had something called a surveillance report, but the same terminology, the same functions with another client was a different terminology. So they didn’t use it. They didn’t call it that, but it was a similar report, but not not really same. So again, going back for us, it was basically hey, we need to really understand the literature that they have, the terminologies that they have, and any internal vocabulary, so to speak. And then have the agents trained on that, and only then was it able to satisfy a lot of the functions there. So that was a huge lesson learned. Again, the principles were basically the same, but once you got into the details, it was like apples and oranges. There’s no way we could say this is working here, therefore we could take it and implement it here. So that was a big lesson learned. But I think like the question you started asking, so does that mean we kind of take any attempt at automated testing? Yes. Yes. Yeah. Actually, so great question, right? So the way what we did was we actually, you know, thanks to all the the clients themselves and the TV scientists because they gave us a lot of time, because obviously our folks were technical folks, and they had to really train our technical folks in saying, hey, this is what I want to see. So for example, they had a one client on the Trump Odyssey side, they had like. Twelve to fifteen different side effects that they wanted to see, and they had multiple terms for the same thing. They had, you know, I’m not the P.D. scientist, but like for example, nausea, and they had a different word for the same thing. So when the chief medical officer came, they would use a different term, like the M.D.s use a different term. So those were things where actually the development team, and the client, and our Q.A. all had to be like really hands low. Working in really framing on how the test scripts and the execution and so on had to be done, and I but I understand right. But in other functions, it could be very different. I think compliance could be very different, like a periodic review is a periodic review. But this, I I wanted to make sure, like you know, we touched upon other things that probably we didn’t sit through today, like on the PDS. So that was one. So the questions we were asking was basically, is it going and pulling the right report? Is it going? So, for example, we we one of the questions asked of us was, “Hey, we’ve got trials all over the world. I want to know what’s happening in Singapore for these three different dosages.” So they had multiple, you know, they had different dosages and different indications for the same product. So they would basically say, “At 25 mg, what were the findings in Singapore versus the same findings in Poland, for example?” And at 50 mg, what were what were the findings in Singapore versus Poland? So, and then they would want that to come into a report where they can actually visually see and say, “Oh, this is what’s happening; these are the trends, and so on.” So, those were very specific use cases, and we had to train the agents to really go pull that information. And once we had an idea, so essentially, what we were doing was basically fine-tuning the evidence itself, so that once we, you know, you can call it the golden set. Once we had that, then we had confidence that we could take this and find the next different set of data, for example. So, kind of baselining on what you want the outcomes to be, and also baselining what your agents can do and cannot do. That that probably took us about six months, just going back and forth and hydration and so on. So, by time we came down to validation downstream, we had put a lot of work up front, and therefore the the way the protocols came out. Seemed more than what you would traditionally want to see. I know you asked a question, like you know. Please feel free to ask me any questions as we go. I don’t have too many slides, but I certainly do want to talk about, you know, some of the questions that you may have and so on. So another big thing is right. What is really working, at least in the 24 months? What have we learned? Well, certainly we used agent AI, and what we learned is. The as long as you give the right supporting documents and source documents, and if you train your AI agents, they do a pretty good job of pulling information. So that that’s something. So for example, you know, take change controls. If you upload 15 different change controls, it’ll summarize all that and and give you a nice report. We thought that was pretty good. The second was it was really good in providing traceability. So if I found out something where. Hey, what happened to this particular instance where multiple login attempts happened? Why it happened? It would really point to that particular piece of the audit trail, and it would basically say at such and such time, such and such user logged in five different times within the span of three minutes or four minutes or something like that. So, so it was really doing that, but also kind of showing. Traceability as well. So as and obviously this is basically surfacing everything to the human, and they could go click on it, and then within a couple of clicks they could see what is going on in the document and so on. It’s almost like a verification of the source document. So it really did a good job of that. The other piece certainly was just the expedited manner in which it would analyze documents and data. It I it really was very impressive for us actually. So for example, we had. Just on the PB side, they had multiple Excel files that were uploaded, and then if you run a report, it basically would summarize something within like five to ten minutes. Which, which you know, the scientist clearly said, hey, for us it would probably take three days to do this, and so on. You know, we have a day job, but we still had to do it, and so on. So in that sense, we really did a good job of saving time. And you know, cross documentation review that was another one. It was really good. So any policy changes impacts SOPs, impacts work instructions. It clearly would say, “Oh, this SOP changed.” You know, you’re reporting an SOP change. Therefore, your policy has to change, and so on. So that’s kind of mapping, and really did a good job of that as well. So those were some of the things, and and really drafting. So for example, again, I had mentioned this. Like one client had their reports, like they had one specific template. Another client had a different template. And a different way of writing, and and this would the tool would really pick that up, and when you see the output, client A’s report would look like how client A would write it, and client B’s report would look like how they would write it. So really, the tonality and things like that did a excellent job. So those were some of the things that we thought really is a value add to clients. Any questions here? What’s up, man? The cross talk. Yeah. Yeah. Was Was there relationships already built between those documents, or was it doing textual searches? Contextual. So we uploaded all the policies and SOPs and work instructions, and then it found out. So the I would almost say the the way we saw the agent pretty much was, let’s just say somebody who’s trained for six months. And if they went and did a job, you know, like they went and gave you a draft report, pretty much he did something like that. Where it was not intelligent enough was like the first draft, and what you have probably had like a thirty percent delta. You know, like if you went back and said the final report within the first draft, that’s probably thirty percent. Again, what he was really good at is citation and things like that. He really cited, but. And then we also had to do a lot of learning. So, for example, as I mentioned before, it would take the same technical word for nausea, for example, and that, and it would think it’s two different indications or two different side effects, right? So, those are some training that we had to do with the literature that was available within the clients. Those were some things. Another thing we noticed also was it would take part eleven, it would take Annex eleven, and sometimes it’ll basically. Exaggerate the findings, so something which probably is an observation, it probably categorized as critical, and so on. So, so that we thought was something that had to be treated. Yes. Yes. So, yes, we did validate it, and how we validated is like by failing so much that then finally we had multiple rounds of failing. So it took again. I said right, like it took us about six months to get there. But I guarantee you, if we started in the beginning, we would have failed. So what we realized is, so essentially, we went with a plan A. We said, oh, we’re going to do this and this and that and all that stuff. And 30 days in, we realized, guys, whatever framework we had for our testing approach is not going to work. So so therefore, we had to spend another four months really working very closely with the clients, understand what exactly their requirements are. And really, now, now if you run that same protocol for that particular SAE report or DSCR report, it would be a pretty decent protocol. It would give you the expected report and things like that. But again, if you run once, and then if you add additional documents, supporting documents, and you run it again, there will be a difference in that report between the first report and the second report. And it’ll also ask you, okay. So, for example, one of the test cases that we did was to say, so we did not change the source documents, and we ran the report twice. So when when it and also we ran the report twice, and they configured that the second time, we would basically say, there’s really no change in the documentation. Everything seems same. Are you sure you want to run it? So those were some guardrails that we started adding. So so for example. If you changed, it will say, “Oh, these documents have changed.” Therefore, and it’ll give you a report, and and it’ll tell you what documents, what additional documents were added. So you can see what happened. Your first run, this is your second run, and your third run, and you will also see what the delta was. Yes. So for the negative testing, yes, for regression testing, we had to do that. So, for for because for the client to have confidence in the first run, we had to do runs two and three to show that when you change documentation, this this would identify that for you. Or if you didn’t change documentation, it would basically say, hey, none of the documents were changed. Are you sure if you still want to run? So that those were prompts that were, so it took it took multiple efforts. So pretty much it’s like custom validation because it’s custom requirements and. So, so what? So one of the things we had to do was we basically validated the platform. We called the platform is like certain set of standard functions, and have that within our instance, and then there were additional testing for client specific functions. Even though the functions were the same, since the modalities were different and so on, you know, there was a lot of delta between this and that. What’s not working? Obviously, we took you know again six to seven months of lessons learned and resources, time and all that. Pretty much exaggerating criticalities. That was one. We noticed that our documentation was missing. We would make a big deal of it, right? So that was one. Then we had the the false position. So. We also noticed that it would basically say, oh, this is something is so critical because this particular change control or this change control was not there, for example. Things of that, like for example, we had that countries and they had studies. So if a country was missing, it would be like, oh, this particular country is missing, therefore this critical. But actually, what really happened was they excluded that particular country. So so it took the baseline from first and thought, oh, all these 15 countries were there, but. Typically, for the second study, they didn’t have a group; they only had a smaller group of, you know, smaller study. So those were some of the things that would highlight. And then finally, we had to go back and say, okay, it’s highlighting something, but it’s not really true. And then we had to go and figure out why it’s not true, and why the agent was doing what it was doing, and how do we control that and fine tune that and tweak that again, and so on. So those were things that were constantly happening. And assumptions as well, you know. So that was another thing. So, for example, on on the periodic review, this was a good one. We uploaded some documents for IT change control system. It the first question, like one of the few, one of the very first questions said, “Oh, periodic review was never done before. Therefore, it’s a big critical deviation.” But the system didn’t understand that the system itself was within that its life cycle, and it was the first. PR, he didn’t realize that. So that was something. Things like that happened, and obviously, you had to go back and work with the clients and analyze. There was also duplicate findings. So that was another very interesting case. So you would have an adverse event. It will write a statement or two, and then in the second or the third page, it will write the same thing in a different way. So you almost had a duplicate finding. So that’s something that again we had to go back and figure out why it happened, and we had to go back to the PB scientist and say, “Hey, is this the same thing?” And then they’ll be like, “Oh, it’s the same across the board. Here’s the number for that. It’s the same thing, but it you know it kind of reinforces again. So again, it’s a lot of back and forth, and and kind of fine tuning. And again, the idea is if you were really in validation, you’d be writing so many different deviations, right? So. So, so typically, so that’s why what we said is, all right, we’ll we will document everything with the understanding that these things are going to change, and so you wouldn’t approve your final protocol till we have confidence that. So it’s like multiple engineering runs or trials. Basically, that’s what. What you know, what should we, what we should do differently? You know, validate the guardrails. I think. I think you know. Here, I would say is this right? So, instead of saying there’s a deficiency, it has to say unable to verify. Right. So, big thing was is we didn’t want the agent to make its own conclusions and say is something’s a problem or not a problem. That that was the big thing that we we had to go multiple iterations and train and so on. And the other is if it says it’s a finding and it gives you a solution, we had to go back and say. All right. Show us the citation. Show us the confidence level that you have for this particular finding, and why it’s showing what it’s showing. So basically, avoiding you know, limiting your hallucination. Essentially, that’s and drift. Those are some of the things. And outputs again, right? Same AEs in different formats and different sentences and things like that. So that was a big issue. So we had to go back and figure that out. So, in fact, you know, dig down a little deeper here. It’s truly for a successful AI foundation. It’s really important to really work for the the AI engineers, QA, compliance, and the system owners, or the system owners, or the SMEs. It’s really important to really work together to really build a good testing approach. Anything in isolation, it’s. You know, before if you implemented SAP, you could have a CSP analyst write a protocol, and you can go and the SME or you know somebody who’s not quite change to execute that protocol. You’d be you know deeply disappointed if you did that with an AI-based application. What you want to do is multiple runs and really fine-tuning it so that there are no surprises. So that’s that was huge lesson. You know, I think mentioned was much better, better testing mindset. So you know, if you have a lens or a lab instrument, and you run it, you run the experiment, and then you know there’s going to be eight different tables that are going to be filled and clear, definitive answers. That’s probably not going to be the case, actually, right? So it’s going to give you a range. It’s almost like a human doing the work, and the way they write it, the you know the templates they use. The data sources, all of those things will vary, actually, right? But I think what you want, what, and I think that’s why human in the loop is so important, because you really want an SME looking at things and say, did it really come with the right data? Did it really do what it’s supposed to do? Can do I have backup source data to back all of these answers up? And and then also, is it within my environment? Is it within our instance? And all of those. Those are the big things that I think you know. From a testing approach, the mindset has to change. Quick implementation wins. No, I think, yeah, I think with third party, maybe I’ll talk about third party, right? I think it’s really important for both the vendor and the client to kind of understand that, hey, yes, you have a tool, yes, it does certain functions, but making sure that how When you go and implement it, you know, bring it in house. So if it’s a SaaS solution, just making sure like what the expectations are, and and really being closely involved in that whole life cycle, the testing process, software development process, the life cycle process. If typically, traditionally, what happens, QA basically is brought in at the last minute, the last time, you know, the business goes by the system, IT is not brought in. QA is not brought, and they bring the system in. Then IT is like, hey, send me a, give me a project manager, and then once they have a project plan, then they finally call QA and say, hey, can you please do a, GxP assessment from? So that that used to, I mean, it might still happen in a lot of places. Pulling QA or even you know other stakeholders at the last minute, you’re bound to fail. That’s because because the expected outcomes are going to be different, right? So you know you can’t go and say, oh, QA is throwing a wrench because Bottom line is you brought them in so late into the game, and your SMEs came in so late, and you go to implement it, you’re basically going to be, you know, failing while you’re testing actually, right? And the project’s not going to be a success. Nobody’s going to be happy. So, so really, in my in our experience, it’s it’s the vendors, it’s the software, the AI engineers, compliance, IT, QA, and SMEs all working hand in glove is the only way. You know, I shouldn’t say only way, but. That’s the best way to really succeed. Well, so what do I, in my mind, how do I think future QA organizations are going to function? I think there will be an archer that be head of QA, and there’ll be quality systems, GMP, GCP, QA, and so on, so on. But I also feel like there’ll be dotted lines where. You have certain agents doing certain functions. So, for example, you might say, “Oh, we have our agent Michelle. Michelle does ITGXP. We have Sam. Sam does farm surveillance. So that’s how. So it’ll be a combination of AI-based agents plus human. And and I think that that’s how I I personally see it happening. And. The AI agent themselves might have a resume, which basically says, “Hey, they’ve been trained on Part 11, Annex 11. They’ve been trained on EMA guidelines, and so on and so on. They themselves will have like a almost like a bio, you know, like a CV, and also version controls, when they were validated, how they were validated, where they reside within the system, and so on. That’s that’s I think is probably going to happen, and and there will be a lot of efficiencies gained that way.” Still, with human in the loop, I do have a couple of slides. I can, you know, so so you know, I want to introduce Michelle. So what Michelle does is she does IT compliance. She’ll do periodic review, audit trail review, and she’ll be, you know, in your quality system. And she’ll be trained. So if you change your SOP, she’ll be trained on the SOP. So she’ll have a new version number. And she be validated, you know, and there’ll be release notes and things like that. That’s I, again, it’s just how I’m thinking about it. It may happen, may not happen, but we’ll see what happens. And by the way, Michelle, my boss, old boss, is Michelle, so I just wanted to honor her. So that’s that’s why Michelle. And then we also have a PV Sam. That’s after one of our clients who really helped us, and we we are going to call that agent Sam. So Sam does PV stuff. Michelle does IT compliance. And you know we’re kind of getting into some of the multi-tenant SaaS and stuff. These are standard questions that comes up. Hey, is it single tenant, multi-tenant? What are the controls for the tenant, and so on? I’m certainly not an IT infrastructure guy, but I know that when you guys are looking at vendors, these are some of the questions you should be asking, right? And and I know with bigger some of the bigger organizations that we are talking to are pretty much. What they want is they want the agents curated, configured, and deployed within their instance. They build a separate instance for that particular agent. The agent resides there, and anytime that we release a new version of the agent, they have their own qualification process and things like that. And then the agent gets deployed. So, so that’s that’s something to think through. Do you have any other questions? All right. So I think I will go back. Happy, happy. Take any questions, and feel like I rushed through everything. But, but yeah, I take you know happy to answer any questions. Right, lessons learned over the last 24 months. So I know there was a question on should we have a separate SBLC. I the way I think is, remember we used to bring in IT system goes through an assessment, SOX, GXP, and then GXP. And I think there would be something which says GXP AI AI GXP, and then the AI GXP needs to have its own set of SOP. It’s almost if you try to put everything in one, it’s it’s going to be extremely difficult. You’re going to deviate from that, right? So you’re you’re much better off really having stand you know separate SOPs for AI GXP applications, just how to go about the SBLC process, how to go about the testing process, and that. I think that would much less resistance, less deviation, and and a clear approach on implementing a successful system. That’s one. The other thing I wanted to share also was we we talked to a lot of clients, a lot of small to mid-sized companies, and everybody comes and they’re like, oh, we want AI to do this. We are using Cloud. We are using Copilot. We’re doing we’re going to do this and that. What we you know so what we told our What the common theme is this? Everybody wants to really boil the ocean, but then we ask the follow-up questions like, “Hey, do you guys have a AI roadmap in place, right?” So, typically they’d be like, “Oh, the IT is doing it, or something like that, or maybe they have a roadmap.” Then we said, “All right, what’s the first small win that you guys want to show to your senior management, right?” So, so then you can get the next level of budget and so on. So, then then again, you know, it’s a lot of coaching. What we realized is a lot of the small companies. Some have roadmaps, some don’t. The ones that succeed have a typical roadmap. But not only that, they have a roadmap. They usually want to go after a small use case that they can implement and get a small win within a three months window. And when they get that win, then they can go back to the senior management and bring in the next project and so on. So, and these are like for small to midsize companies. Of course, the bigger ones are spending billions of dollars, and they know what they’re doing. For the smaller ones, our advice would be like: if you don’t have a roadmap, please put a simple AI roadmap. Get a small win before you go and tackle the bigger problems. So that was another lesson learned. Any questions? All right. Well, happy to answer any offline. Again, thank you very much for your time. 好啊，幾多位？

Graph View

Backlinks