From Concept to Compliance: A Case Study in Building an AI Tool You Can Trust
By now, most life sciences leaders know AI is coming to their function. What’s harder to see is what “doing it right” actually looks like — the decisions, documentation, and discipline that separate an AI tool a regulator can defend from one that quietly creates risk.
In Episode 3 of Let’s Talk AI, NPG’s Christine Bonifield and Taylor Bean walk through a real case study: how a team took an idea, defined what they actually needed, wrote the requirements, tested against them, and designed the human oversight that made the tool trustworthy in a regulated environment. Along the way they’ll tackle the question every AI leader eventually faces — how do you validate a tool that feels like a black box, and how do you know when the outputs are accurate and repeatable?
Christine and Taylor will also share where the same discipline applies to the AI initiatives now landing on leadership’s desks — from labeling to complaints handling. This isn’t a framework talk, and it isn’t a product pitch. You will leave with a sharper sense of what to ask, what to require, and what to focus on, before your organization commits to an AI path.
What You’ll Learn
By the end of this session, you’ll understand:
- Why the requirements are the most important part of an AI initiative. How clearly defining the need — before anyone starts building — shapes what AI can and can’t do to meet your need(s), and why this is the step that most often gets skipped in regulated organizations.
- Why validation for AI is different, and why leaders need to understand that difference. How the discipline of validation still applies, why some AI tools resist validation, and what reproducibility, boundaries, and testable outputs mean in practice.
- Why human oversight — not just human-in-the-loop — is the design decision that makes AI defensible. Why AI is a tool serving your team, not the other way around, and how to think about which humans, where in the workflow, and with what authority make an AI implementation trustworthy.
Who Should Attend
Life sciences leaders who have been asked to “do something with AI” and need to know what responsible implementation requires — before signing an SOW, kicking off a pilot, or approving a vendor. Especially valuable for:
- VPs and Directors of Regulatory Affairs, Quality, and Compliance
- Global Labeling and Labeling Operations leaders
- Digital Transformation, AI Program, and Innovation leaders
- Validation, CSV, and QMS owners
Speakers
Christine Bonifield, Partner, NPG
Christine has spent six-plus years building and operating AI in regulated environments at NPG, including the human-oversight AI solution NPG uses in label verification. She has been the featured voice across the Let’s Talk AI series and works with client leaders on AI governance, validation, and integration into existing systems.
Taylor Bean, Engagement Manager, NPG
Taylor is an Engagement Manager on NPG’s Digital Transformation and Labeling team and one of the internal SMEs behind NPG’s AI development work. He works directly with life sciences clients on labeling operations, AI-supported verification workflows, and digital transformation projects involving software deployments and data migration.
Overview
What should you require before an AI tool becomes part of a regulated workflow? In this on-demand episode of Let’s Talk AI, Christine Bonifield, Partner at NPG, and Taylor Bean, Engagement Manager at NPG, use NPG’s FALCON Labeling AI experience to show how a workflow problem became a defined set of user needs, design inputs, and requirements. Taylor walks through examples of label-data extraction and content comparison, connecting the demonstrated features to the needs they were built to address. The discussion also shows why usable outputs matter: reviewers need visibility into unfamiliar items, identified differences, and content the tool reports as unchanged. You’ll see how acceptance criteria support test development and why human judgment remains essential when deciding whether a label change was intended. This case study introduces verification and validation considerations without presenting a complete validation protocol or promising suitability for every AI implementation.
Key Takeaways
- Start with observed workflow pain and compare process changes, training, existing tools, and software development before selecting AI.
- Gather user needs from the people doing the work and the stakeholders contributing inputs or consuming outputs.
- Connect design inputs to observable tool features, then develop requirements and acceptance criteria that support testing.
- Make output review part of the design, including unfamiliar items, reported differences, and reported matches.
- Keep intended-versus-unintended change decisions with human reviewers rather than treating the tool’s report as approval.
- Revisit user needs and requirements as the tool and the surrounding workflow evolve.
Related-content
• Start with Episode 1: Balancing AI Innovation & Compliance in Life Sciences for the series’ responsible-AI framing and FALCON origin story.
• Read the leadership context in Episode 2: A Leader’s Playbook for AI Strategy, Compliance, and ROI for requirements, governance, and implementation decisions.
• Explore NPG’s Digital Transformation services for related service context.
Transcript
This transcript has been lightly edited for readability and preserves the substance of the live discussion. It is provided for general informational purposes and is not legal or regulatory advice. The case study does not establish that another AI tool or implementation is validated, compliant, or suitable for its intended use.
Speaker introductions: Christine Bonifield, Partner, Network Partners Group (NPG); Taylor Bean, Engagement Manager, NPG. Timestamps follow the original recording. Explicitly labeled paraphrases are not verbatim quotations.
00:32 — NPG and the case-study speakers
Christine Bonifield: I am Christine Bonifield, a Partner here at Network Partners Group, or NPG.
If you’re not familiar with NPG, allow me a couple of minutes to summarize. NPG is a professional services group focused on Compliance, Tech Ops, and Digital Transformation. We do this through our industry expertise and experience in quality, regulatory, packaging, labeling, project management, and supply chain. NPG can bring both SME consulting and expert execution.
I am pleased to have Taylor Bean joining me today. Taylor is an Engagement Manager at NPG. He uses his industry expertise to support current clients and assist future clients as a business thought partner. Taylor was also a key member of the FALCON development team and continues to oversee our FALCON tool.
04:40 — What FALCON does and why NPG developed it
Christine Bonifield: We received feedback asking us to better explain what FALCON is. If today is your first episode, FALCON Labeling AI is a label-analysis tool we developed at Network Partners Group six years ago. Before AI became the craze it is today, we embarked on this journey of incorporating AI into a regulated industry.
We’ve been sharing our challenges, watchouts, and lessons learned because they are still pertinent today. Our goal is to share our journey as a guide or model as you embark on your own AI journey.
FALCON does two things very well. It parses data from a PDF of a label and populates a spreadsheet. In other words, it takes the label elements and makes that data usable for activities such as tabular review or a where-used search.
The second thing is a non-pixel-to-pixel label comparison. FALCON compares the elements on the legacy or original label with the elements on the new label and produces a report identifying what has been added, deleted, modified, or stayed the same. I’ll pass the virtual mic to Taylor to dive more deeply into this.
06:40 — Start with workflow pain, not an AI solution
Taylor Bean: Thanks, Chris. I’m happy to be here, and thank you all for your time. We’re going to give a FALCON demonstration alongside a look at some early planning documents: how we determined our needs, what we wanted the software to do, and how we structured our user requirements.
Before the demonstration, I want to provide context that may help you plan your own initiatives if you’re evaluating AI to enhance processes, mitigate gaps, or reduce pain points.
Our internal discussions about what eventually became FALCON began with the work we were doing with clients to migrate labels and data from one system to another. There is a lot of manual work: typing information into cells, copying and pasting between loading spreadsheets or databases, formatting content, and manually verifying that content in a table, system, physical label, or PDF.
Based on the work we had done, we knew these processes could be improved. We began recording examples of pain points that we and our clients experienced. From that information, we started discussing possible solutions.
It’s important to be clear: we didn’t leap directly to an AI solution or software development. We knew the pain points and some of the user needs, and we looked at a broad range of potential solutions. AI or software development were possibilities, but we also considered process improvements, training for team members, and existing off-the-shelf tools. Was something already on the market that could do the work we wanted?
After those conversations, we reviewed the data and our ratings of possible solutions. We concluded that the strategy with the most potential for us was developing a new tool. That eventually became FALCON. We then took the data and discussion outcomes and began building our user needs and requirements.
09:26 — Translate user needs into design inputs
Taylor Bean: This is a sample of our requirements-gathering process. On the left is a column of user needs. These came from conversations with stakeholders: people doing the work, people using its downstream outputs, and people contributing upstream inputs.
We wanted to collaborate across those groups to determine the needs of each user set. From there, we developed design inputs: what we wanted to give the development team to say, “We want the tool to be able to do this.”
As Chris mentioned, our targets included parsing information from available labels and using it in a database or spreadsheet for different outputs. Another part was bringing in versions of labels for comparison and producing accompanying reports.
We’ll look at how those user needs and design inputs became features, then connect them back to the User Requirements Specification, or URS, and the verification and validation testing.
We created the list of user needs, including parsing data, comparing inputs, and reporting differences, and tied those to design inputs. These lists were the starting point for the URS and the development of the tool. Now I’ll show how some of those inputs became features.
11:37 — Data extraction and reviewable label information
Taylor Bean: You should now be able to see the user interface for our FALCON label-analysis tool. The first feature is data parsing.
PDFs sometimes contain embedded text that is easy to extract. Other times, what looks like text on a label is an image, which makes it hard to manipulate, transform, or move from one place to another. FALCON can pull that information from the PDFs and turn it into a document we can use.
Here are a few sample labels. You’ll notice other requirements: we needed to identify different elements on a label. FALCON is trained for text in multiple character sets, including Roman alphabets, Asian character sets, and right-to-left languages such as Arabic. It is also trained to recognize barcodes, including machine-readable and human-readable information, and a set of symbols.
For the initial tool, we designed it to recognize symbols from the ISO 15223 standard, along with other life sciences labeling symbols such as the CE mark. The idea is to see the content of each field, including the text and symbols.
FALCON can process labels in the background. We can load a set, let it do the work, and then put the resulting data sets into a spreadsheet for other activities.
The parsing requirement leads to a spreadsheet like this. Each label is differentiated by its reference or catalog number, and each row contains the data set for that label.
If the information isn’t already in a database, this gives you a place to do where-used searches. It also lets you look down a column for something different. For example, one of the lot numbers here is a digit longer than the others.
The other fields reflect our requirements to capture the ISO 15223 symbols, other life sciences symbols, barcode information, and labeling content. When we return to the user requirements documentation, you’ll see how we can draw a line from those requirements into testing.
15:04 — Verification, validation, and human oversight
Taylor Bean: We want to do both verification and validation. On the validation side, we’re asking, “Did we build the right thing?” Did what we built meet our initial requirements? Did we make the product that matches?
On the verification side, we’re asking, “Are we building the product right?”
Taylor Bean, attributed paraphrase: He explains that the team also needs to check whether the outputs produced from its inputs are the expected outputs.
Taylor Bean: Along with that, any process, whether AI-related or not, is only as good as the people involved. Human oversight, the human-in-the-loop, is important both in development and in the continued operation and success of a tool like FALCON.
We’ve looked at the data-parsing side. The second half is comparison. Parsing fits the front half of our user needs: ingesting information and helping build the database in the system that will create labels.
Comparison works on the back end. We’ve generated new labels, and now we want to compare them to make sure that content that shouldn’t change has remained unchanged, that only intended changes were made, and that the tool surfaces those results.
16:29 — Label comparison and minimum viable scope
Taylor Bean: I’ve loaded a couple of label pairs for the demonstration. Some of the initial requirements said the tool should ingest PDFs. As we mapped what the tool would do, it became clear that we needed to distinguish current and revised labels and be able to build projects in different ways.
There are cycles involved in development. Even for the Minimum Viable Product, or MVP, your requirements and development should lead to a tool that meets your basic needs and can perform the function you designed it for. From there, you can create enhancements or add features.
For comparison, we assign a set of labels as current and another set as revised, then determine how the tool will match them. In this case, we pair labels by reference number.
One user need reflected a difference we see in the industry: comparison software can use pixel-to-pixel comparison. From a labeling perspective, that can cause issues when you move content to make things fit, add requirements, change label stock, or make other design decisions.
FALCON looks first and foremost at the content. Here, symbols are on the right side of one label and in a different orientation on the left side of the other. FALCON uses its training to match that content: both labels have a “do not reuse” symbol and an “instructions for use” symbol, even if those symbols are in different places.
That also applies to more complex labels. You might have multiple sublabels or seven of the same barcode across peel-off labels. FALCON counts those elements and provides information about the elements and how many there are.
19:03 — Review unfamiliar items, differences, and matches
Taylor Bean: Once the labels are processed and paired, we want to look at the output. We wanted a way to review and check the outputs so this isn’t a black box and we get useful information.
FALCON doesn’t know every image or every symbol in the world. We can do additional training, but it has a defined set of items it is trained to recognize. This is where the human-in-the-loop reviews the output.
In this example, I added a Network Partners logo that FALCON didn’t recognize. The first thing it does is surface those items for the human reviewer to look at, because the tool hasn’t been trained on them yet.
Then we get information about the content FALCON is trained to look at. Here, content is boxed in gray or red. Gray indicates that content was found on both labels and matched as the same. Red indicates content that differs between the labels.
We get the current and revised labels and summary reports with granular detail. First is a summary of the fields and their counts. Differences are prioritized first.
The human reviewer determines whether a difference is an intended or unintended change. FALCON’s goal is to surface differences. These may be intended changes under the change plan, or unintended changes caused by an error in the data or label development.
Another requirement was that we didn’t want to see only the differences. We also wanted a checklist of all the fields FALCON reviewed. We can see the same-barcode analysis results, the same-symbol results, and the same-text-field results, with current and revised values together.
These pieces give you an idea of the first MVP: software that met our user needs based on the design inputs, connected to our user requirements and our verification and validation testing.
22:16 — URS acceptance criteria and ongoing development
Taylor Bean: Here are example items from our URS documentation. These are more developed than the initial brainstorming. They evolved during planning and development. As we added features or updated the tool, the requirements were added to and modified to match what we needed the tool to do and what changed in development.
The process of identifying user needs, developing design inputs, and building the tool is familiar across the industry. At the end, we have our MVP and user requirements. We continue that process today as we use FALCON, identifying new user needs, process improvements, and system enhancements.
The idea is to give requirements structure: state the user need clearly, define the system requirement, and include acceptance criteria. I’ve also included some priorities for these examples.
Those acceptance criteria and requirements help you build test cases: to validate that you have the right system and verify that you built it right, with the outputs you expected for the work you want to do.
The last thing I want to say is that people are the secret sauce of these projects. AI is a powerful tool. Software development is a powerful tool. Process change is a powerful tool. But they work best when stakeholders are involved and there is human oversight. Chris, back to you.
Christine Bonifield: Taylor, I appreciate it. Great job on the demonstration and on tying it back to our URS.
25:18 — Q&A: current client use cases and design review
Christine Bonifield: The question is: you shared that you developed FALCON six years ago. Are people still using it in the industry? The answer is yes.
You heard some of the use cases Taylor shared. Clients moving from one labeling system to another may have data that is flat and lives on the label rather than in an active data set. They use FALCON to parse it out.
As Taylor said, this supports where-used reports, data cleanup, and tabular review. In the spreadsheet example, one value had an extra digit, and you could see it during the review.
The other piece is label verification: taking a legacy label and comparing it with a new label.
Another use case has emerged over the years: using FALCON in the design phase. The designer makes the requested label changes and sends us the legacy and new labels. We run them through FALCON and send the report back.
That lets the designer see whether the correct changes were made and whether there were inadvertent changes. They can correct the label before it enters approval.
They can send it back multiple times until they get what we call a clean report, where only the intended changes occurred. They then use that report as part of the change-control documentation in their approval process. That can allow approval to move more quickly than finding a typo during approval and having to start again.
27:30 — Q&A: content-focused comparison and next steps
Christine Bonifield: Taylor, explain a little more: what is the difference between FALCON and other vision systems on the market?
Taylor Bean: As I mentioned, one of the biggest differences is pixel-to-pixel comparison. Other tools may look at spatial relationships rather than the content of the label itself. We wanted FALCON to be content-focused.
Content matters because incorrect label content can create regulatory issues. When data moves from one area of a label to another because of requirements, limitations, or changes in the label-development system, we wanted to show what changed in the content.
Taylor Bean, attributed paraphrase: He explains that the comparison was designed to distinguish content changes from changes in position or orientation, including cases where the content remains the same.
Christine Bonifield: Thank you, Taylor. If you would like a FALCON demonstration specific to your labels, we’re happy to do that. If you want to talk about your own AI journey in more detail, reach out to Taylor and me.
We appreciate the feedback you provide. Please connect with us and share additional feedback or topics you’d like us to explore. We’re happy to continue the conversation. Have a great day.
