AI (SI?) Adoption in Regulated Environments

Public health labs have been through shifts like this already. When labs moved to genomic sequencing and bioinformatics, nobody bought a sequencer and called it done. Labs built computing infrastructure, standardized methods, trained people, checked performance and leaned on networks of shared expertise. The sequencer mattered, but everything around it is what made it useful.

The responsibilities haven't changed. You still evaluate the need, prepare staff, validate the workflow and keep local ownership. What's different with AI is reach. It touches communications, admin work, quality systems, code, data management and scientific interpretation. There's no single workflow, no single risk profile and no one approval process that covers all of it. The lessons are familiar. There are just a lot more decisions to make.

Every technology I've seen adopted has been a bridge from a starting point to an end point. What makes AI different is how many gaps it can bridge. When code is cheap and the friction to build is mostly gone, you're no longer stuck with the one crossing you could afford. You suddenly have a dozen possible ones.

That sounds like pure upside, and a lot of it is. But it moves the hard part. The scarce thing isn't engineering time anymore. It's judgment. That means picking the problem that actually matters, scoping it well, and knowing what "done" and "good enough" look like before anything gets built. Brandon Galang sums this up well: "When code is cheap, there's a premium on scope."

"Human in the loop" sounds reassuring, but it can hide a pretty weak control. Which human? Looking at what evidence? With the authority to fix or stop the process? Accountability doesn't disappear because the answer showed up in confident, well-written prose.

In a large organization, human in the loop has to be built into the process, not bolted on at the end. Before anything is built, experts define the problem, the constraints and what success looks like. During the build, teams integrate systems and inspect intermediate results. At release, owners check the evidence, approve the use and keep maintaining it.

That's why the best enterprise AI adoption I've seen puts real engineering and people behind it, and why two roles keep showing up. A forward-deployed engineer works inside the team that will use the tool. They sit with the lab staff, learn the actual workflow, connect the systems, test against messy real data and stay through rollout. That matters because AI pilots tend to look great on clean data and stall at scale, a pattern Sandeep Pawar of Manifold sees in pharma, where forward-deployed engineers now work alongside teams to make adoption stick (shameless plug for our episode together on Down To A Science, where we speak on this exact challenge).

Alexander Titus' concept of the AI Product Partner works on the other side of the gap. They help leaders decide which problems are worth solving, set success criteria, sequence the work and keep each tool owned and maintained after launch. One keeps the build honest to how work really happens. The other makes sure the organization builds the right bridges and keeps owning them.

Neither replaces the domain expert. They give that expert's judgment a way into working systems.

Two public health examples make this concrete, one at the scale of a federal agency and one built by a single expert.

CDC's agency-wide GenAI chatbot expands staff capacity

CDC rolled out an agency-wide generative AI chatbot and reports more than 41,000 staff hours saved a year, mostly on content creation and coding, and over $3.7 million in labor costs saved to date. Those are CDC's own internal, unpublished estimates, so treat them as directional. What I like about the example is the shape of it. It's routine information work, staff still review every output, and there's a clear way to measure the gain. If you try this yourself, track the time spent reviewing and correcting alongside the time saved.

GenomicEpi, one expert's build that became shared capacity

The other is GenomicEpi.com, built by genomic epidemiologist Krisandra Allen, MPH, MB(ASCP). She knew exactly what the field was missing. Outbreak data was scattered across systems, formats and update schedules, and federal dashboards were hard to interpret. AI handled the coding and integration. Krisandra directed the build and caught and corrected AI's mistakes along the way.

What one person built is now shared capacity. GenomicEpi pulls 20 automated sources into five outbreak dashboards, from measles and Ebola to New World screwworm, alongside a library of more than 180 free trainings. The Ebola dashboard alone gets about 1,800 visitors a month, and the site has been linked or cited by NETEC, FMI, ASU's Health Observatory and SciLine.

Her expertise wasn't automated away. It got multiplied. That's the leverage AI offers anyone in a regulated field who knows their problem cold.

The good news for regulated organizations is that you're not starting from zero. Data use and privacy rules, information security, procurement, change control and quality management are already the starting point for evaluating AI. HIPAA, PHI policies and data sharing agreements still govern what AI can touch. Existing vendor relationships help too. Indiana, for example, built its Copilot rollout on the Microsoft 365 licensing it already had.

Match the controls to the consequences. A draft staff announcement isn't the same as software that touches patient results. Both deserve care, but they don't need the same evidence. For low-stakes work, expert review and approved sources might be plenty. For routine workflows, you'll want representative testing, error handling, version control and a named owner. Anything that affects reportable results goes through the validation obligations that already apply. Every regulated industry has its own version of this ladder.

It also helps to use AI to build the tool, not to be the tool. A model can give different answers to the same input. A script it helps you write gives the same answer every time, so you can validate it once and then monitor it. That repeatability makes verification easier. It doesn't prove the script is right.

AI doesn't replace your quality system. It hands your quality system a new set of questions.

Luke put it best on our podcast: "If I'm using AI and I publish something that has incorrectly calculated stuff because of AI, it's still me. I'm still accountable."

Pilots tend to get judged on whether the demo looks impressive. Production systems have to survive staff turnover, messy inputs, weird edge cases, model updates, budget cuts and ordinary Tuesday mornings. Dependable tools need a named owner, the specialists to implement them, ongoing maintenance with documented versions and a plan to roll back, and staff with the time and authority to report errors and pause work that isn't reliable.

So the scorecard has to go past "did the AI produce an answer?" Did the workflow actually get better? Did quality hold? How much expert review did it take? Can we keep this running?

Public health has one big advantage here, a long habit of sharing technical support. APHL has helped labs through earlier technology shifts with committees, guidance, peer learning, training and fellowships. Regional bioinformatics networks proved that not every jurisdiction has to invent every capability on its own. A similar hub-and-spoke model could put AI, quality, privacy and security expertise within reach of every lab while they keep local control.

The goal isn't to turn every lab into an AI lab. It's to give the experts already there more leverage for the work they do. The same goes for any regulated organization.

Start with a real bottleneck, not a favorite technology. Ask your team what's repetitive, slow, error-prone or hard to scale. Pick a contained use case whose output a reviewer can check on their own. Decide who owns it, what data it can use and what tests it has to pass. Give people room to learn on approved, low-risk tasks. Then build a deliberate path from "useful prototype" to "supported service."

AI adoption isn't a race to run the most pilots. It's about choosing the right bridges and owning them once they're built. Public health's history of scientific rigor, shared infrastructure and hands-on workforce development has a lot to teach the rest of us working in regulated spaces.

Thank you to APHL and Scott Becker for inviting Luke and I into this conversation. It would have been easy to keep AI off a board agenda, or to treat it as hype that will pass. APHL instead chose to take it on directly and talk about it openly, including the parts nobody has figured out yet. That takes courage, and it's the same kind of leadership public health labs have shown every time a new technology has come through the door.

Other regulated industries can learn a lot from how APHL is approaching this. They started at the top, putting AI in front of the board instead of leaving it to scattered individual experiments. They brought in practitioners who are actually building with it and asked for an honest picture, not a sales pitch. And they're treating it the way they've treated every major shift before, as something to work through together, with shared expertise and existing structures, rather than leaving each lab to figure it out alone.

Hospitals, pharma companies, and government agencies facing the same pressures can follow that lead.