Artificial intelligence promises improved efficiency, sharper decision-making, and higher productivity in the laboratory. For most leaders, however, the primary challenge is not recognizing AI's potential, but identifying where that potential fits within their organization and how to execute without costly missteps. That was the central theme of "Understanding AI Strategy and Readiness for Labs," a session at the 2026 AI in Lab Automation Digital Summit moderated by Lab Manager editorial director Scott Hanton, who was joined by Adam Steinert, chief technology officer at Yahara Software, and James Smagala, the company's bioinformatics practice manager. Together, they outlined a grounded framework for AI adoption—treating AI not as a magic bullet, but as a deliberate, evolving capital investment.
What foundational knowledge do lab managers actually need?
Many lab leaders assume deep technical fluency is a prerequisite for initiating an AI strategy. Steinert pushed back on this assumption, emphasizing that a shift in perspective matters far more than a crash course in machine learning.
"From a foundational knowledge standpoint, I think you just need to understand that it isn't a big, scary space," Steinert said. "It doesn't have to be. It's much more accessible than it has been." His prescription for the starting line is almost disarmingly simple: "I'd say that's maybe all you need to start with is just curiosity."
Smagala built on this by redirecting focus away from the technology itself and toward organizational operations. Because the field evolves so rapidly, complete technical mastery of AI is unrealistic. A clear-eyed understanding of internal lab workflows and strategic goals yields far greater value.
"Do we have the data that we need to support it? Which people are really going to be instrumental in making this project succeed?" Smagala asked. "Notice none of those is really about AI. And that's okay at the start of an AI project. It's probably better to have a clear vision of what you're trying to get to than exactly how you're going to get there."
Hanton framed the same objective from a lab manager's perspective: AI is "a real tool to solve real problems”. His advice was to target persistent operational bottlenecks rather than chasing AI implementation for its own sake.
How much does data readiness matter?
If curiosity is the entry ticket, data is the foundation everything else is built on. Yet, Steinert was careful not to let that dissuade anyone from the outset.
"It's not like you have to start with a mountain of data," he said. "You have to start somewhere, you have to start with a good organization, a roadmap, and a plan. And you can certainly make headway and do useful, valuable work without a ton of data up front and build that as you go."
The more critical question is whether available data aligns with the intended objective. While laboratories generate vast amounts of information, raw volume does not equal usability. Standards bodies have converged on a similar baseline: the NIH's FAIR principles hold that data must be findable, accessible, interoperable, and reusable before AI can act on it meaningfully.
Lab Quality Management Certificate
The Lab Quality Management certificate is more than training—it’s a professional advantage.
Gain critical skills and IACET-approved CEUs that make a measurable difference.
"If I was designing this as an experiment, have I collected the right data set that's going to help me answer the question that I'm trying to get to?" he said. "If the answer isn't going to be in the data that you've collected, you need to pause and think about the data harder."
Data format and integrity are equally critical. Steinert explained that structured data—clean, comma-separated values rather than a mix of handwritten forms and scattered digital files—is far easier to work with. Completeness and trustworthiness round out the picture. As he put it, "the more regular, the more formal you are, the more that you can trust the data that you've collected, the better off and the more accurate your journey into AI and machine learning.”
Common pitfalls in lab AI adoption
Some of the most valuable insight from the session came when Hanton asked about the mistakes labs make most often. Smagala and Steinert had no shortage of candidates. Many of them trace back to skipping the planning and prioritization work that should precede any procurement decision. The session highlighted the most common early missteps labs make:
- Leading with a top-down mandate: Deciding to "use AI" or buying a tool before identifying the problem it should solve.
- Ungoverned bottom-up sprawl: Allowing informal, individual AI workflows that were never designed to scale.
- Chasing a moonshot: Picking an oversized first project that carries long timelines, high costs, and a high chance of failure.
- Treating AI as a static software deployment: Treating AI as a one-time setup ignores the need for continuous validation, revalidation, and ongoing lifecycle maintenance.
- Expecting immediate perfection: Custom models require an iterative approach based on exploration and continuous refinement, rather than a single fixed launch.
Human expertise remains indispensable
An essential takeaway from the session was that AI cannot replace subject matter expertise. Hanton illustrated this with a scenario: a lab facing a new DNA sequencing problem, without genetics specialists on staff, deciding to simply let the AI analyze the data.
Interested in lab leadership?
Steinert addressed this risk directly: "We've not reached artificial general intelligence yet. Everything that we build, everything that we're using does rely on expertise from us, from people in the field that are directing it, driving it. And if you don't supply good inputs, as with any software project, the outputs will be bad."
Smagala added a caution regarding generative tools: "The AI will quite happily be confidently wrong and sound like it knows what it's talking about. It's trained to do that," he said. "And the number of times you catch it being wrong, assume it's doing that across all the other domains, too, and you just don't know it."
The safeguard is to deploy AI within areas where internal expertise is strongest. "You really want to be working in a domain that you do know well, and using this to help you automate things that you are struggling to automate with traditional software solutions, and not overextending yourself into a domain you don't understand,” explained Smagala.
The safeguards—the "guardrails you put around it"—are only as good as the human judgment behind them. Building those guardrails, Smagala noted, is exactly where outside expertise can pay off, provided the lab brings its own domain knowledge to the table. "It's the collaboration between those two things that'll get you to a more successful place."
Evaluating lab readiness
AI readiness is not a binary metric; it is a matrix. Steinert outlined four core dimensions for assessing readiness:
- Data availability: Assessing quantity, quality, and structural maturity relative to the target problem.
- Subject matter expertise: Ensuring internal experts are available to train, guide, and validate model performance.
- Internal processes: Ensuring workflows are defined and stable enough to support automation.
- Question quality: Defining properly posed problems align with current algorithmic capabilities.
The required threshold depends on project scope. Lightweight applications, such as using large language models or agentic frameworks for contained tasks, require minimal barriers to entry. Conversely, enterprise-wide initiatives demand systematic progression across all four dimensions.
Smagala added a dimension lab leaders sometimes overlook until it's too late: regulatory and compliance readiness. Before diving into the AI question, he urged leaders to ask whether their organization understands how a new system will fit within its regulatory framework. If the honest answer is no, "it may be something where you want to step back from the AI question and spend a little more time thinking hard about what are my organizational constraints and guardrails first." In FDA-regulated settings, that framework includes 21 CFR Part 11, which governs electronic records and signatures, and the agency's risk-based Computer Software Assurance guidance, finalized in 2025, which concentrates validation effort where patient and product risk is highest.
Hanton translated that into the language auditors speak: How am I going to validate this? How will I audit it? How do I document it and prove it to an auditor? These aren't AI-specific questions, he noted—they apply to any lab workflow. In that sense, an AI workflow "isn't different than any other workflow. It has to be explained to an auditor to get approval." For regulated environments, that means understanding what GxP, validation, and data integrity require of AI systems before deployment.
Build vs. buy: navigating architecture choices
One of the most practical exchanges tackled a decision nearly every lab will face: buy off the shelf, or build something bespoke?
Smagala offered a clear guideline. If a commercial AI module integrates directly into an existing system (such as a LIMS) and addresses the core need, leaders should adopt it without overcomplicating the decision. "If that's what you set out to buy, and it does the thing you need, buy the off-the-shelf product. Do not feel guilty about it. Get it up and running and working, and see if you can get some value back out of it."
However, challenges arise when workflows span multiple systems. "If the problem you are trying to solve does not live nicely in that one system, it is relatively unlikely that an off-the-shelf piece of software magically slots into where your problem is," Smagala said. That's when a custom approach enters the conversation, along with its own overhead of hosting, maintenance, revalidation, and the longer-term economics of validating a custom AI tool.
Importantly, Steinert noted, the economics of custom development are shifting fast. AI-assisted software development is driving the cost and time of custom builds down, turning what used to be an expensive, time-consuming proposition into "much more approachable and competitive types of solutions." As Hanton summarized, the space between the two poles "is getting faster, easier and cheaper," making it far more accessible than it was even a year ago.
Core roles for implementation success
Asked what expertise a lab needs in-house, Steinert pointed to several variables: strong subject matter expertise, a team that understands the AI and machine learning landscape well enough to steer toward the right solution, and solid data analytics. But the most fundamental need, he said, is also the one most often missing: "just good infrastructure, internal infrastructure support." Making sure the data is present, curated, and securely accessible is frequently where these initiatives actually need to begin—and where breaking down data silos pays the earliest dividends.
The core roles and capabilities a lab needs to support an AI initiative include:
- Subject matter experts: Scientists who know the domain well enough to guide, train, and validate model outputs.
- AI/ML technical leads: Specialists who select appropriate model architectures and implementation strategies.
- Data scientists & analysts: Professionals who organize, label, and govern data assets across the operational lifecycle.
- Infrastructure & IT Support: Teams that break down data silos, ensure secure access, and maintain underlying systems.
Smagala drew an important distinction that gets lost in the generative-AI headlines: much of the most successful AI work in laboratories is really machine learning at its core—the kind of modeling that powers categorization and anomaly detection. That work depends on clean, well-labeled data and, ideally, "a data scientist type around who understands your science."
The difference between a bench scientist who handles data daily and a dedicated data scientist, he explained, comes down to structure and discipline—organizing data correctly, applying the right controls, and treating it as part of the complete laboratory process. Unmanaged spreadsheets and informal data handoffs represent single points of failure until brought into formal data architecture.
A realistic timeline
Initial execution can move quickly. Steinert noted that a focused proof-of-concept (POC) can be delivered remarkably fast.
"We have an AI prototype offering where we will come in and discuss what could be done within a couple of weeks," he said. While a POC is not a production environment, it establishes what he called "directional success": validating technical viability and projecting potential ROI.
Moving from a validated prototype to full production typically requires roughly one quarter, Steinert estimated, depending on data integration complexity.
The bottom line for lab leaders
The strategic sequence embedded in the Yahara team's guidance is the real takeaway for lab leaders weighing an AI initiative:
- Focus on real operational challenges: Begin with curiosity and a clear problem statement, not a tool looking for an application.
- Audit data assets early: Confirm data completeness and structure before writing code or buying software.
- Scope modestly: Avoid moonshot projects and treat AI as an evolving capital investment that demands validation, maintenance, and governance.
- Retain human oversight: Deploy AI within existing areas of core expertise to ensure robust validation.
- Apply established capital project discipline: Evaluate, document, and validate AI deployments with the same rigor applied to major equipment acquisitions.
Ultimately, successful AI adoption is less of a pure technology challenge and more of a management discipline. The organizations that derive the greatest value from AI will not necessarily be those that move fastest, but those that align ambition with operational readiness, maintain rigorous data governance, and keep human expertise at the center of the process.
