Before Louise joined RIVER, she spent years building health data infrastructure in Samoa. Disease surveillance systems. Vaccination tracking. Maternal health monitoring. The kind of foundational data work that saves lives but rarely makes headlines. When she started prototyping AI agents, the transition felt less like a career change and more like a natural extension. The instincts were the same.
The Data Foundation
Louise's work in Samoa was not glamorous. It was building systems that collected reliable health data from clinics across the islands, cleaning it, structuring it, and making it useful for decision-makers. In a context where internet connectivity was intermittent, paper records were the norm, and resources were constrained, every design decision mattered.
In Samoa, bad data means a vaccination campaign misses a village or a disease outbreak is detected three weeks late. The stakes taught me that data quality is not a technical problem - it is a human problem.
Louise Epa
AI Analyst & Research Consultant
The systems Louise built had to work for people who were not technical. Community health workers entering data on basic devices. Ministry officials pulling reports on slow connections. Regional coordinators comparing data across islands with different infrastructure. The technology had to disappear into the workflow.
This is the same challenge enterprise AI faces. The technology matters, but what matters more is whether the people using it can trust the outputs and integrate them into their actual work.
Why Data People Build Better AI
There is a pattern we keep seeing. The people who build the best AI systems are not the ones with the deepest ML knowledge. They are the ones who understand data deeply: where it comes from, how it gets messy, what it represents, and what it hides.
Louise came to AI with three instincts that most AI engineers have to learn the hard way:
Data scepticism. Years of working with health data in developing contexts taught her that data is always dirtier than you think. Missing values are not random. Collection biases are systematic. The first question is always "what is this data not telling me?" That instinct is invaluable in AI, where garbage in means garbage out at scale.
User empathy. When your users are community health workers in rural Samoa, you design differently. You design for the constraint, not the ideal. You assume the connection will drop. You assume the user is tired and distracted. You make the system forgiving. AI systems need the same design philosophy, especially in enterprise where users are busy, sceptical, and have limited patience for unreliable tools.
Outcome orientation. In public health, the point is never the data system. The point is the health outcome. The system is a means, not an end. Louise brings that same lens to AI: the point is never the model. The point is the decision it enables, the time it saves, the outcome it improves.
The Transition
When Louise started exploring AI agents, the conceptual parallels were striking. An AI agent is, at its core, a system that takes in information, processes it against a set of rules and context, and produces an output that helps someone make a decision.
That is exactly what a health surveillance system does. It takes in clinical data, processes it against disease thresholds and historical patterns, and produces alerts that help public health officials make decisions.
The technology stack is different. The principles are identical.
Louise's first AI prototype was better than most I have seen from experienced engineers. Not because the code was sophisticated, but because she understood what the user needed before she wrote a single line.
Dr Tania Wolfgramm
Chief Research Officer
The areas where data professionals have an edge in AI:
Data pipeline design. AI is only as good as the data it can access. Building reliable data pipelines, handling edge cases, managing data quality, and designing for scale are core data engineering skills that transfer directly.
Evaluation thinking. Data people are trained to question metrics. They know that a single number can hide important variation. They instinctively ask "what is this metric not capturing?" That is exactly the thinking AI evaluation needs.
Stakeholder translation. Data professionals spend their careers translating between technical and non-technical stakeholders. "Here is what the data says, here is what it means, here is what you should do about it." That translation skill is critical in AI, where outputs need to be contextualised for decision-makers.
The Bigger Pattern
Louise's story is not unique. Across the RIVER team, we see the same pattern. The people who deliver the best AI outcomes are the ones with deep domain experience: health, education, finance, construction. They bring understanding of the problem that no amount of model tuning can replace.
The AI industry has an overemphasis on model expertise and an underemphasis on domain expertise. The models are getting easier to use. The domains are not getting simpler. The competitive advantage is increasingly in understanding the problem, not the tool.
What This Means for AI Teams
If you are building an AI team, look beyond the obvious talent pool. Data engineers, data analysts, business intelligence specialists, and domain experts with data fluency are often better AI builders than ML engineers who have never worked in your industry.
The skills they need to learn (prompt engineering, model integration, evaluation frameworks) can be taught in months. The skills they already have (data instinct, user empathy, domain knowledge, stakeholder communication) take years to develop.
Louise went from health data systems in Samoa to prototyping enterprise AI agents. The career arc looks discontinuous from the outside. From the inside, it is one continuous thread: making data useful for people who need it.
That is what AI is, when you strip away the hype. Making data useful for people who need it. And the people who have been doing that work for years are the best positioned to do it with new tools.