Integrating AI in a regulated medical environment means combining a strategy-first approach with focused, small-scope implementation rather than broad transformation. A bowtie analysis, a one-page risk diagram mapping threats to controls, helps compliance and technical stakeholders align and demonstrate regulatory compliance. Regulators respond better to specific, bounded use cases than to sweeping AI initiatives.
Key Takeaways
- Focusing AI integration on one specific, bounded problem makes regulatory compliance tractable, because regulators can analyze a narrow scope where a broad implementation gives them no choice but to refuse.
- A non-deterministic AI layer can produce deterministic outcomes when wrapped in the right controls, just as internet protocols deliver reliable communication over inherently unreliable packet transmission.
- Bowtie risk analysis condenses the entire compliance picture onto a single page, making threats and controls visible to technical staff, compliance stakeholders, and regulators simultaneously.
- Stakeholder needs must be quantified, not just named: specifying required precision, acceptable timeframes, and tolerable risk levels is what makes a strategy actionable rather than aspirational.
- Architecture decisions made early either enable or block the transition to agentic AI later, so long-term structural thinking at the outset prevents expensive migration work down the road.
Why AI in a regulated lab needs strategy before APIs
AI inside a regulated medical environment starts with strategy, not with integration work. The pull toward APIs, protocols, and quick experiments is strong, but it skips the question that decides everything downstream: what specific problem are you actually solving, and for whom?
A medical analysis lab sits in this exact tension. The industry is regulated, yet the organization wants to play with new technology. The interesting work is not the integration itself, which competent IT people can handle. The hard part is making that integration safe in legal and regulatory terms, especially when most of the relevant regulation is still being written rather than settled.
Alexis Savkin came at this from a strategist’s seat, not as an AI specialist. That distance turned out to matter. The brief was not “add AI,” but “play with new technology from a strategy-first perspective and stay safe.”
You can prove a problem is solvable before you know how
A non-deterministic system can carry a deterministic result. That is the first claim to establish, because it removes the objection that blocks every conversation in a regulated setting: AI changes, it drifts, so how can anything reliable be built on top of it?
Alexis frames this with a mathematician’s habit. Before solving a problem, you sometimes prove only that it can be solved. You do not yet know the method, but you have shown a solution exists. For a nervous stakeholder group, that proof is the icebreaker.
The internet is the working analogy. The packets exchanged across it are not deterministic. They arrive damaged, get lost, run into high latency. Internet protocols are built precisely to absorb that unreliability, and the result is a usable, dependable network. The same logic transfers to AI: build on something unstable, engineer for it, and produce a stable outcome.
A second analogy comes from peers in the same domain. If a company running cancer-diagnostic scans operates inside these constraints, the objection “we can’t do this” loses force. The honest counterpoint is budget, not possibility.
Okay, there I have like ten X more budget, but who cares? We have 10x more courage. — Alexis Savkin
Start from stakeholders, not from the ideal picture
Strategy-first means beginning with stakeholders and their needs, then narrowing hard. The mistake is to start with the technology or to start with the most ambitious version of what AI could do.
The method runs through a sequence. First, map the stakeholders and understand the landscape. A medical lab looks simple from outside: you give a sample, you get results by email a few days later. Inside, it is high-end hardware, IT processes, physical processes, many testers, and a lot of equipment that has to work together.
Next, sketch the ideal picture. Imagine AI using the full context of a patient’s medical history. That generates plenty of ideas, but the ideal picture is a starting field, not a plan.
Then cut it down. Some options are impossible. Some are still prohibited. A few are doable right now. From the ideal picture, two or three options come off the table simply because the regulation around them is not clear yet. What remains is a problem narrow enough to act on.
The payoff of narrowing is direct. When the scope is specific, you know what evidence you need to collect, you can test it against existing requirements, and you can scale to the next problem once the first one delivers value.
Bow tie analysis turns compliance into one page
Bow tie analysis was the single tool that made the work land. Out of a full strategic toolkit, strategy maps, change agenda frameworks, and more, this one captured attention because it solved the compliance problem visually.
The diagram puts the threats on one side and the controls that prevent those threats on the other, all on a single page. For a group that included compliance people, IT people, and non-technical stakeholders, that one page did most of the job. Roughly 80 percent of the effort was solving the compliance problem, and the bow tie made it legible to everyone at once.
The diagram also works as proof for a regulator. It shows, in one view, the controls actually being implemented. Classical tools could have solved the same problem, but the bow tie put it where every stakeholder could see it and agree.
Architecture is where the future of the system is decided
AI is a digital transformation, and like every transformation, it accumulates consequences. Rushing to implement APIs ignores what every long-lived product eventually faces: legacy buildup and architectural problems.
The architecture matters more than the first integration. Alexis built the lab’s architecture to stay compatible with agentic AI as that approach matures. The team does not run agentic AI today, but the structure allows it. That compatibility removed a future migration headache before it could form.
This is also the line between hiring a strategist and asking a chatbot. Ask ChatGPT the same question and you get a detailed answer, but not one that thinks long term. The value of a human advisor here is the long-term view, the architectural foresight that keeps today’s decision from becoming tomorrow’s rework.
How strict is the regulation, really?
For this quality-control case, the regulation is less rigid than the reputation of “regulated medical environment” suggests. Much of the fear comes from the size of the problem, not the strictness of the rules.
There are two parts to the quality-control work. One concerns a testing device generating an error and making sure that error never reaches the final result. That part is not regulated at all. It is your responsibility, and you have to get it right on your own. The other part has specific requirements, checkboxes to satisfy before use, rather than a certificate to obtain.
In some cases there is simply no regulation yet for the precise challenge at hand. Some organizations protect themselves with general ISO certification, which signals that they learn from their mistakes, but that is broad, not specific to the AI use case.
The regulation stays manageable as long as you avoid the obvious failures: training AI on patient data, sharing personal data. Don’t do those anyway. The constraint that does bite is scope. You trim the ideal picture down because parts of it sit in unclear regulatory territory, and you wait for that territory to settle.
The budget gap explains why some companies ship features that others cannot. A large player with deep pockets and a solid reputation can defend itself in court if challenged. Smaller organizations often lack that budget, and frequently the customer is not even ready to pay. In a medical lab it is not always clear who the customer is, who pays, or who owns the results: the patient, the insurer, the hospital. Unclear ownership is itself a reason to keep scope tight.
Treat regulators as allies, not obstacles
Regulators are trying to make life safer, and most of their recommendations are reasonable. Reading them as enemies misframes the relationship and makes the work harder than it needs to be.
A 2025 European Union report on the state of AI in healthcare reinforced the strategy-first case. Its conclusion: making AI possible in the medical domain requires combining strategy, funding, stakeholders, and regulation together. That is a direct rationale for starting from the top rather than from integration.
Collecting evidence becomes easy once you know what to collect, and you only know that when your scope is focused. The same focus that makes a problem solvable also tells you which controls to build and which proofs a regulator will want to see.
A first step for regulated teams adopting AI
The first move is regulatory scanning. If you operate in a regulated environment, set up a way, automated where possible, to track which regulations are coming up. Know the landscape before you build.
The second move is to refuse the temptation to solve everything. Present a regulator with “we want AI across the organization” and the answer is no, because the scope is too complex to assess. Bring a specific, bounded challenge and you can test it against the requirements that already exist.
Quantify stakeholder needs wherever you can. Not “we need analytics for our samples,” but the time window, the precision, the problem types, and the risk tolerance. Where can you accept risk, where can you not? Numbers turn a vague ambition into something a regulator and an engineer can both evaluate.
The throughline is simple. Focus on something solvable, show value to stakeholders fast, and the regulation problem shrinks along with the scope.
