Alan Tan opened his talk in Bangkok with a question he did not answer: would you trust an AI to help diagnose you?
He did not need to answer it. His point was that the question is already moot. AI has moved out of research and into hospitals, clinics, pharmacies, laboratories, drug development and hospital administration. It is not a future concept. It is being implemented now, by people who have to make it safe while it runs.
What followed was the most useful hour we have spent on applied AI this year. Not because Alan's setting is ours, but because almost everything he said about putting AI in front of doctors turned out to be true of putting AI in front of a thirty-person business. This is what he said, and where it landed for us.
The lesson he started with
Alan's first slide was IBM Watson.
2011 Watson announced as an AI breakthrough
|
2013 in healthcare
|
2015 a dedicated division: Watson Health
|
2022 sold off to private equity
The technology had been hyped as a breakthrough, and in real clinical settings it sometimes recommended treatments that were unsafe or ineffective. The gap, in his telling, was never the ambition. It was data quality, clinical validation and safety: the unglamorous middle that nobody had built. The industry's response was to become more cautious, more collaborative and more transparent about how it deploys.
His conclusion was on the slide in bold: healthcare AI innovation must go hand in hand with rigorous testing, clinical oversight and ethical responsibility.
We have never worked in healthcare. But we have watched the small-business version of Watson Health play out: the chatbot that quoted a customer the wrong price, the automation that broke when an API changed, the pilot everyone was excited about that was quietly switched off. The failure has the same shape at every scale. Impressive technology, no testing layer, and nobody responsible when it is wrong.
What he built
Alan's case study was an assistant for healthcare professionals. The problem was mundane and expensive: doctors asking the field teams who support them the same repetitive questions, over and over. The solution was a retrieval-based assistant that answers from an approved body of content, in local languages, by text or voice.
What was instructive was the order he built it in. Governance first, before any real user touched it.
question (text or voice, local language)
|
v
approved content, split by disease area
and by local context (no cross-contamination)
|
v
assistant drafts an answer
|
v
guardrail layer: inside the compliant range?
| |
yes no
| |
v v
answer the doctor route to the responsible-AI
team for review
The data strategy was deliberately narrow: only the data that served the model's purpose, never general patient data.
This resonated for a specific reason. The idea behind our work is what we call "talk to your business": connect the databases, files and metrics a company already runs to an AI that can answer from them directly. Alan's partitioning rule is the same rule we apply across client workspaces, and we had been treating it as plumbing. Hearing it described as the thing that makes a clinical system safe reframed it as a feature we should explain, not hide.
The wall he hit
Alan was candid about what nearly stopped the project, and it was not the technology.
It was compliance. Their objection was that large language models are probabilistic, and no engineering makes them deterministic. You cannot promise a compliance officer the system will never be wrong, so the compliance officer will not sign. Add the EU AI Act and the FDA's requirements for software as a medical device, and the approval path becomes the project.
Leadership had a second wall. Satisfaction scores were not enough. They wanted hours saved or reach gained, a number in the language the budget is written in, before they would fund anything beyond the pilot.
| Who has to say yes | In a hospital | In a small business |
|---|---|---|
| Is it safe? | Compliance, against regulation | The owner |
| Is it worth it? | Leadership, in hours saved or reach gained | The same owner |
| What unblocks it | Governance, testing, a measured result | A number that answers "is it worth it" |
Here the resonance was uncomfortable. A membership organisation went quiet on one of our proposals for weeks. We read it as Alan's problem, an approval chain that could not decide who owned the yes. It was not. It was the price, delivered politely enough that we heard it as maybe. In a small business the compliance officer and the budget holder are the same person, and the objection is usually simpler: not "is it safe" but "is it worth it". Alan's leadership were asking the same thing. We had just not built the number that answers it.
How he tested it
Alan's team found that manual testing proved nothing. A few people trying a few dozen questions says nothing about a system that will field thousands. So they built a tester: an AI that ran hundreds of queries against the assistant from the perspective of different personas (doctors, nurses, pharmacists and, memorably, a housewife) to check that the tone was right for whoever was asking. Every response was graded into one of three bands of compliance.
personas: doctor, nurse, pharmacist, ...
|
v
hundreds of test queries
|
v
assistant answers each one
|
v
grade every answer into 3 compliance bands
|
v
a score you can compare --> fix --> re-run
^ |
+------------- after every change ----+
and on a schedule
Not "it seems fine". A number, re-runnable after every change.
This is the part we took home most directly. Our first paid data product, a market-intelligence file covering companies across Thailand in two languages, left the client not entirely happy. The model had been fine. The prompt analysing each prospect and the crawler feeding it were not. We found that out from the client's reaction, after delivery. Alan's team would have found it from a grid, before. We are building the same thing: a graded set of test cases that runs before anything ships, with the grid shown to the client.
What the doctors valued
When his team asked doctors why they liked the assistant, the top answer was not speed or accuracy. It was that they could ask basic questions without being judged for asking them.
Alan said this almost in passing. It stayed with us longer than anything else. These are specialists, and the feature they valued most was the absence of a colleague's raised eyebrow.
We think this applies far beyond medicine. The owner who does not want to ask the accountant the same question a fourth time. The new hire who will not admit they do not know a term. A surprising amount of friction in any organisation is people avoiding the social cost of asking. Systems that remove that cost get used, and it never appears in a requirements document.
Seven questions, and the model answers only the first
The slide Alan called "the hard part isn't the AI" was a ladder: seven layers, one question each, with the model at the top as the first thing checked and the least of the problems. The third column is how each rung reads outside a hospital.
| Rung | His question | The same question in a business |
|---|---|---|
| 1. Model | Does it work? | Does it answer correctly on our own data? |
| 2. Data | Is the data good enough? | Are the records it reads current and complete? |
| 3. Systems | Can it connect with other systems? | Can it reach the CRM, bookings, files and accounts we already run? |
| 4. Workflow | Does it fit the way care is delivered? | Does it fit how the work is actually done at the desk? |
| 5. People | Will clinicians and patients trust and use it? | Will the team trust it and use it? |
| 6. Governance | Who is responsible? | Who approves what, and who answers when it is wrong? |
| 7. Outcome | Does it ultimately improve care? | Did it save time or money, measured against a baseline? |
Rungs four and five are where our own history sits. Before Pulsar, part of our team worked inside a large corporate-travel operation. The systems the agents used were specified from the top; the agents themselves were not in the room. After launch, the agents rebuilt every workaround they had used before, inside the new system. Those workarounds had been normal for so long that nobody had ever prioritised removing them. The system fit the organisation chart and not the desk, and the people expected to trust it had been given no reason to.
Rung three is our entire line of business, sitting in the middle of a healthcare ladder as one of seven gates. That was a humbling place to find it.
The question he could not stop asking
Alan's most forward-looking point came in a small text box beside the ladder. Imagine a diagnostic model trained in 2025. By 2027 the patient demographics have shifted, clinical practice has changed, the equipment is different, the imaging protocols have moved, and disease patterns and data quality have drifted. The model has not changed. Everything around it has.
This is why, he explained, the FDA emphasises post-deployment monitoring: watching inputs and outputs after go-live, because changes in sites and populations degrade AI performance even when the code is frozen.
We have not been running long enough to live this yet. But the translation is obvious. A client's prices, products, staff and customer questions move every quarter. A test run once at launch is a photograph of a system that no longer exists. Alan's answer is that the test runs on a schedule, and we are building that habit before we need it.
Adoption is four things, not one
Alan's closing frame was that AI adoption equals business plus people plus technology plus trust.
BUSINESS strategy, use cases, value
PEOPLE skills, roles, culture
TECHNOLOGY data, architecture, integration
\ | /
v v v
TRUST AND GOVERNANCE
security, risk, ethics, compliance, assurance
|
v
SUSTAINABLE ADOPTION
His readiness framework had seven parts, and two of them are the ones we keep returning to. Process: workflow redesign, a human in the loop, an operating model. And adoption: change management, usage, measurement and continuous improvement.
The word we underlined was redesign. Connecting AI to the way a business already works is only the first move. The second, and the one that decides whether anything improves, is being willing to change how the work is done once the AI is in it. Automating the old workflow gets you a faster version of the old problems. We have watched that happen, and we would rather not sell it.
What we are taking from Alan
Not a checklist. A way of working, which we are adopting inside Pulsar and will ask the businesses we work with to adopt with us, because none of it works one-sided. We can build the connection and the tests. We cannot redesign a workflow from outside it.
| In Alan's order | When it happens |
|---|---|
| Governance: what it may do, who reviews what, where the audit trail lives | Before anyone touches it |
| A baseline: how often, how long, who does it today | Before the build |
| The people who live in the tool in the room, with their workarounds treated as the specification | From the first conversation |
| A graded set of test cases, shown to the client | Before delivery |
| A human on every decision that touches a customer or a price | Until the tests prove otherwise |
| Re-measure against the baseline | Sixty days after launch |
| Re-run the tests | On a schedule, for as long as it runs |
It is slower for a month and faster for every month after. Alan built it for hospitals. We think it fits a thirty-person business just as well.
Thank you to Alan Tan for a framework precise enough to be uncomfortable. That is the useful kind.
We shared a shorter version of this on LinkedIn: The hard part isn't the AI.
FAQ
Why did IBM Watson Health fail?
In Alan Tan's account, the technology was impressive but in real clinical settings it sometimes recommended unsafe or ineffective treatments. Data quality, clinical validation and safety testing had not been built around it. Watson Health was sold to private equity in 2022.
What are the seven questions for implementing AI?
Model, data, systems, workflow, people, governance and outcome. The model is the first question checked and usually the smallest problem. Most projects stall on the other six.
How do you test an AI assistant before launch?
Run hundreds of test queries from the point of view of different user personas, grade every answer against a fixed standard, fix what fails and re-run after every change and on a schedule. Manual spot checks by a few people do not show how a system behaves across thousands of questions.
Why does an AI system get worse after launch if nothing changed?
Because everything around it changes: customers, prices, products, staff and data. That is why regulators such as the FDA emphasise monitoring after deployment, and why tests should keep running after launch.