Anusha Dandapani:
AI industry picks its own tests, right? It’s like you telling me that you grade your own papers. Retrofitting ethics into a system that’s already there is like putting seat belts on after the car is already going ninety miles per hour. No algorithm should be the final word on whether a family qualifies for humanitarian assistance. When someone asks, “where did this information come from?” or “where did this number come from?” you have to resist the temptation to build a grand, unified data architecture on day one. That’s the foundational thing nobody wants to talk about.
Saket Saurabh:
Hi everyone. Thanks for listening to another episode of Data Innovators and Builders. Today I’m speaking with Anusha Dandapani, Chief Data and AI at the United Nations International Computing Centre, UNICC. Anusha, thanks for chatting with me today.
Anusha Dandapani:
It’s my pleasure. Thank you, Saket, for having me.
Saket Saurabh:
Anusha, let’s start with a little bit about your background and your role at UNICC.
Anusha Dandapani:
Sure. I initially started this practice at UNICC in 2020, and my mandate was to lead the data practice. In 2025, UNICC launched the UNICC AI Hub, a centralized resource for AI-related initiatives across the UN system. In my role, I focus on coordination of responsible AI within UN-wide initiatives, such as AI governance and the responsible development and deployment of AI, and I’m very much focused on delivering shared solutions that align with UN mandates. Previously, I worked in financial services. Prior to joining UNICC, I served as the data science lead at Barclays, focused on the regulatory environment and delivering end-to-end data science solutions.
I’m also an adjunct professor teaching data visualization and visual analytics at Fordham, and that’s one of my passions.
Saket Saurabh:
It’s an incredible background, Anusha, and it’s a pleasure talking to you. You talked about your role at UNICC and how it connects across different parts of the organization. When you’re building AI systems that operate in such critical areas, what keeps you up at night?
Anusha Dandapani:
Honestly, it’s not the technology that keeps me up. I think it’s the asymmetry of consequences. What I mean is, if commercial AI makes a wrong recommendation and someone loses money, that’s a very different kind of scenario to respond to and handle. But in a humanitarian context, if someone loses access to aid, or isn’t given the right information at the right time, especially in a context like ours, the demands are completely different, and our relationship with the uncertainty of this kind of information is also very different. So I don’t lose sleep over whether these AI models perform correctly. I lose sleep over whether every failure we might have has a human consequence.
A failure is sometimes rarely purely technical. There’s also an organizational, political, and cultural consequence. That’s what keeps me up.
Saket Saurabh:
It’s a high-stakes role, and clearly, because of the impact, AI safety is top of mind for you. Compared to the industry, where everyone’s experimenting and moving quickly, and AI is moving at such a fast pace, you’re keeping safety top of mind. Tell us a little bit about your approach to that.
Anusha Dandapani:
In the context we operate in, there aren’t many safety evaluation frameworks or methodologies to systematically address safety. For example, how do you make sure safety holds across multilingual contexts? AI models are built for English, but we’re deploying everywhere. If a model only reliably works in English, how do you deploy it in Spanish, Arabic, or French? We see performance degrade, not because those models aren’t performing well, but because the training data for those languages was thin, fragmented, or even absent.
For multilateral organizations like ours, operating across the globe and beyond, this is critical: safety, hallucination resistance, and making sure we’ve evaluated the model per language, not just English. Those are some of the research questions we’re dealing with.
Saket Saurabh:
I see. So organizationally speaking, what does the team structure look like for approaching this? Is it more humans in the loop, your own team testing and evaluating models? How do you approach it?
Anusha Dandapani:
Right now, what we’re trying to achieve is a small team focused on identifying scenarios relevant to us, and scenarios we can validate, either with a RAG system or with benchmarks. We have an audit method that brings in engineers from our team, as well as data scientists and research collaborators from academia. That’s more or less the structure of how we’re currently contextualizing AI safety, and testing these AI models with UN data in mind.
Saket Saurabh:
I see. And in your case, you’re dealing with a lot more data fragmentation than you’d see in industry, since this is data across different organizations. How are you thinking about data interoperability in a way others could learn from?
Anusha Dandapani:
Dozens of organizations have this complexity. One thing that’s worked very well for us is that we don’t try to boil the ocean first. We resist the temptation to build a grand, unified data architecture on day one, because that’s usually how projects die, in committees. Instead, what makes more sense is to find the minimum viable interoperability layer, a small shared vocabulary or a small shared use case where at least two organizations can exchange something meaningfully. That way, we’re not abandoning what we build. We start there, prove the value, and the complexity doesn’t disappear just because we’re dealing with two organizations, it just becomes manageable.
We’re essentially working with real stakeholders rather than abstracting away the data sets or data silos these organizations have. Dealing with it interoperability-first made more sense for us.
Saket Saurabh:
I think that’s a very pragmatic approach. You come from a large bank, for example, and sometimes large organizations have huge resources and think, “we can take on the entire problem.” But it’s better to say, “we have a set of resources we can work with, so let’s point at one problem rather than take on too much.” So now you’re using foundation models, for example, and solving some of these use cases. Would you be able to share a couple of examples we can relate to from an outside perspective, where you’ve seen success?
Anusha Dandapani:
One of the use cases we’ve tackled that we can share is a shared AI platform we built for our HR community colleagues, in collaboration with some of our UN partners. Our role was to be the technical implementation organization. What we learned implementing that use case, especially for HR, was using AI to identify information from policy documents. It’s called Unify HR. That was a shared infrastructure solution where participating member organizations not only shared the data but were able to tackle the problem from a total-cost-of-ownership standpoint, what we call a frugal approach, doing more with less.
Because it was a cooperative solution built as a shared solution across multiple organizations, their contribution wasn’t just data, the cost of the solution was also divided among the participating organizations. That helped us focus on solving the problem itself, rather than worrying about the cost of owning a solution per organization. Second, it helped us avoid duplicating the same solution in different shapes and forms across organizations. Imagine ten organizations each ending up building the same AI solution for the same workflow, that would have created a lot of duplication across enterprise platforms. The third aspect we tackled in this successful use case is the concept of scale.
Because across the ten organizations, they were able to share test scenarios, and it wasn’t just benchmarking on model performance, it also covered prompt engineering, jailbreaking, and red teaming. It was a very helpful AI use case that we implemented two years ago, and it’s been in production for eighteen months since.
Saket Saurabh:
One of the things you’ve talked about is thinking about responsible AI from day one, which may not necessarily happen in commercial settings. How do you approach that? How do you lay down the framework for responsible AI, and why is trying to do that later, or bolting it on, not the right approach?
Anusha Dandapani:
Retrofitting ethics into a system that’s already there is like putting seat belts on after the car is already going ninety miles per hour. The architectural decisions need to be made at the design level, in the first few weeks of an initiative or project. What we care about most, when it comes to responsible AI, is what data you use, what proxy variables you allow, and how comfortable you are with that, and then what the model is actually optimizing those decisions for, especially when it comes to the ethics of the system.
Whether you acknowledge it or not, if you bring in a responsible AI review six months later, you’re not re-auditing the system for choices it’s already made. You can’t remove decisions the system has already taken. So it’s not that organizations doing this backwards are being irresponsible, it’s that they don’t realize the technical decisions they’ve already made are values decisions they needed to bake in when designing the architecture of these systems.
Saket Saurabh:
I think the question of responsible AI has become somewhat mainstream, and there are some model providers, for example, we’ve seen Claude talk a lot about it. As the impact of AI increases, that becomes more critical. How do you see the industry evolving toward some of the goals you’ve been focused on? To what extent is it catching up?
Anusha Dandapani:
Responsibility goes hand in hand with the systems we build, across the board, across multiple enterprises. We’re a shared services organization, so when we engage with multiple enterprises, what matters most to us is building trust, trust in AI systems, especially when working across multiple jurisdictions and environments, and making sure the AI systems we deploy are reliable. Even in lower-stakes decision environments, we don’t take it easy. We make sure that the level of acceptability we agree to, beyond performance, is about trust. We do risk monitoring, we do risk assessment, and we make sure we’re not deploying black-box models in decision-making contexts. So what we’re willing to accept varies enormously.
But we invest heavily in making sure trust and validation of these AI systems is a priority.
Saket Saurabh:
You’re working with different stakeholders with different objectives. How do you manage that, and what lessons can we take from it?
Anusha Dandapani:
That’s a very valid question, because when we’re engaging in a multi-stakeholder context like ours, where stakeholders aren’t the same, our role as the technical advisory or implementing organization is to make sure our stakeholders are aware of the non-negotiables. It’s like holding their hand through the journey, not just giving them a well-tested solution, but making sure they have enough confidence when operating these AI systems. Sometimes, when we hand off these technical solutions, we make sure to provide them with an independent audit and the assurance that the system was built properly, not by someone outside the system, or outside the UN context.
That’s a helpful process we focus on heavily as a shared services organization. But we also care about making sure speed matters, while clearly building things that can be off-ramped when we need to. The agile way of working, giving stakeholders bite-sized options, is something we focus on, and it helps us build trust in our multi-stakeholder engagements.
Saket Saurabh:
What does rollout look like, from initial idea to prototype to scaling into production? And it seems like, along the way, you’re also educating and building trust with stakeholders. How do you plan that rollout, and how do you execute it?
Anusha Dandapani:
In rolling out solutions in a context like ours, one very important factor is that it’s easy to pilot, everybody wants to pilot with AI. What matters more is the last mile, going from pilot to production. Most organizations miss the workflows needed to scale from a pilot. When it comes to piloting these AI use cases or putting things into production, we make sure that, with the institutional knowledge we have, we technically validate these systems as production-ready. Second, we also care about whether, when we deploy these systems, they’re designed correctly for the user community.
One of the key factors we’ve learned by deploying is that change management is critical. Technology can work very well in different contexts, but if the organizational immune system rejects it because it hasn’t been integrated or accepted, that’s where change management becomes very important in how we deploy things into production. That’s one of the things we’ve learned in an enterprise context like ours.
Saket Saurabh:
What might be a key bottleneck in that last mile to production? Is there a way to say, “okay, we’ve hit this level, it’s ready for production,” or some kind of litmus test?
Anusha Dandapani:
Yes, we do what we call security assessments, especially at the cybersecurity layer. Unless we get clearance from our security team, and the risks they highlight are addressed, we don’t move forward. Second, there’s the regulatory landscape where we’re deploying into a user population where sensitive data is involved. We want to make sure we’re maintaining all the controls we need to keep in mind. Those are a couple of things we do around the ongoing upkeep of an AI solution. The second thing we definitely do is monitor them, because creating and deploying is one thing, but if you can’t maintain and sustain a system in production, the value or return on investment isn’t there in the long run.
If, eighteen months from now, the system we built stops working, that’s not a good outcome for the organization’s return on investment.
Saket Saurabh:
Especially with generative AI, I think the quality of models, and how they behave, has been evolving quite rapidly, as have approaches, from RAG to more agentic solutions. So there’s constant evaluation and enhancement. Let’s talk a little bit about the foundation side, Anusha. From a data foundation perspective, what creates a solid foundation to build AI on? You said early on that the goal wasn’t to take it all in, but to focus on a use case and stay on that. What foundational pieces did you have to put together, or did you already have in place?
Anusha Dandapani:
I’m going to mention something that might sound unsexy. What we see as a foundational thing that nobody wants to talk about is data lineage, because nobody wants to fund it, and everybody assumes someone else has already done it. The moment you’re in a high-stakes meeting and someone asks, “where did this information come from?” or “where did this number come from?” and you can’t answer with confidence, your entire AI system loses credibility. In our context, this is even more acute, because we often pull data from different instances, applications, or partner organization feeds. If you don’t know the provenance of your input, you can’t defend the integrity of your outputs, especially in production environments, and you need to always be able to defend them.
So, data lineage, that’s the foundational thing.
Saket Saurabh:
Data lineage is actually one of the harder problems to solve, especially in your case, dealing with both sensitive data and data from different organizations, which makes it that much harder to build a system where you have clean confidence that you’re using data that should be used, with the right governance applied. Is there an approach that’s worked, or tools you’d recommend for solving this problem?
Anusha Dandapani:
Most organizations usually have what they call a governance framework, which needs to be considered as a design input from the start. But the real practical impact comes down to whether organizations rely on tools to tackle the problem, versus actually focusing on the mapping within the organization, a governance framework or governance model with things baked in that the AI system can readily adopt architecturally. That’s what I’d recommend considering, because a first-class architecture that aligns with the organization’s governance framework makes the decision much easier, not just for your technical teams, but also for building a rollback plan or an escalation plan when needed. It’s not a tool-based problem, it’s a solution.
It’s more about how you design architecturally for the context.
Saket Saurabh:
One thing I was curious about, as we’ve been evolving approaches within AI, from more RAG-related approaches for answering questions, to more agentic approaches where we want agents to take actions, how do you view that, especially when it comes to agents taking action as part of the workflow, which is a big theme in enterprise right now, how specific workflows can be automated, partially or fully? What would your guidance be, especially in a high-stakes environment?
Anusha Dandapani:
When it comes to AI agents, I think the biggest misconception is that AI is a project, not a capability. Building the possibility of automating workflows using AI agents is quite different, but what we see is that leaders within these organizations often don’t approve a budget for the deliverable, for how the AI system gets built or deployed, because their mental model doesn’t account for this dynamic environment of using different AI agents or tools. The world is changing, and going back to what I mentioned before, it’s not a tool-based decision.
The landscape is evolving so fast, with gen AI and agents and new ways of doing things, that the organizations that succeed in the long term are the ones that treat an AI system like critical infrastructure, with ongoing investment and monitoring. That’s where I see organizations moving over the next eighteen months, if their leaders look at it through the lens of long-term success for AI systems in their organization. Hope that answers your question, Saket.
Saket Saurabh:
Yeah, certainly. I want to get into the aspect of AI replacing human decision-making, and where you draw the line on what AI should or shouldn’t do.
Anusha Dandapani:
My line is drawn around irreversibility and accountability. AI should handle decisions that are high volume, time-sensitive, and reversible, because sometimes we’re using AI for pattern detection or anomaly flagging. But we need to make sure humans retain authority over decisions that are irreversible and carry a lot of accountability. No algorithm should be the final word on whether a family qualifies for humanitarian assistance, or a person gets flagged as a security risk, or whether a community’s resources get allocated or not, because AI can’t process those decisions correctly. Some of these decisions come down to a concept I care about: answerability.
You have to go beyond explainability, because you can’t hold algorithms accountable, you can only hold people accountable. AI should amplify human judgment, and it should never launder human responsibility.
Saket Saurabh:
That becomes part of training the team too, right? The people using the AI tools, because I personally feel it becomes easy sometimes to look at a big output from AI and say, “that looks more or less fine,” and go ahead with it. A lot of it comes back to our own responsibility as users.
Anusha Dandapani:
Yeah.
Saket Saurabh:
I like the framework, high-stakes decisions that are irreversible and require human judgment, versus repetitive things that have low impact or are at least reversible. That’s a good way to think about it. In general, one of the things you mentioned is that the kind of decisions being made can impact individuals in a real way, even if you’re making them at large scale, it could impact individuals in terms of their life. For example, an aid decision for a family, and you might be looking at millions of people, but each individual decision still matters to that person. In many of these processes, the context of the whole situation matters a lot.
We’ve been talking a lot about context in the world of AI, and context could very well be the person, their finances, their situation, a lot of other factors that go in. How are you approaching the context part of your analysis? Because you have a diverse set of resources, I’d imagine, for context.
Anusha Dandapani:
Sometimes the term “context” means something very different for different organizations. If I go back to the AI use case I mentioned earlier, we focus on spending twice as long defining the problem, because it only takes half the time to select a model to solve it. The elegance of an approach is easy to achieve right now with the technology and technical tools available to us. But genuinely focusing on defining the problem, and making sure you’re solving the right problem, is what makes more sense in the context of the organization. Sometimes AI can become the most expensive mistake we make when it comes to choosing a solution.
Building the right solution for the wrong problem is far more expensive.
Saket Saurabh:
Very true. I like your point that it starts with defining the problem and spending more time on that. I think that itself forces the framing of the context and the decision-making process. You’re solving some really incredible problems, and your approach sounds very pragmatic to me. What would you say is something contrarian you believe about implementing AI, that others in the industry might disagree with?
Anusha Dandapani:
That’s a very leading question. I believe we, as an industry, are over-investing in model sophistication and performance, and under-investing in decision architecture. What I mean is, the AI field rewards novelty and benchmark performance, but in my experience, the difference between a transformer model and a gradient boosted model rarely determines whether an AI initiative succeeds or fails. What actually determines whether an organization keeps using an AI system is whether there’s a clearly defined decision that the AI is supporting for the user community, who has the authority to override it, and what happens when the system goes wrong.
I’d rather have a less sophisticated, small, embedded model with a rigorous decision architecture than a state-of-the-art model just dropped into the space. Most of my peers would call that conservative, but I call it pragmatic, because this pragmatic approach is what actually scales.
Saket Saurabh:
I think that’s very well said, and I’d agree that in many cases we go with the flow of the bigger, better model, and forget about reliable approaches that already exist. I’d love for you to double-click a bit on the decision architecture you talk about, what that means, and how we can all benefit from that approach.
Anusha Dandapani:
I might frame it slightly differently. We’re no longer in the “move fast and break things” era. In my opinion, that was never appropriate advice, it worked in a consumer tech context because even broken features didn’t impact people’s lives in a serious way. In our environment, the right mental model is to move decisively but reversibly. Speed doesn’t mean recklessness, it means doing fewer things with much higher confidence. Building a system that can move fast on a narrow, well-defined problem, with strong human oversight, that’s what I mean by decision architecture. “Human in the loop” has become a fancy phrase for everyone to say.
I’d frame it as human oversight, because when you move slowly and the scope is ambiguous, the failure modes become more irreversible. So the distinction, when you’re making decisions between speed and irreversibility, that’s where most organizations get into trouble with risk. The decision-making process comes back to doing fewer things with much higher confidence, and building that in as a layer in your architecture helps enterprise organizations meet their stakeholders’ expectations.
Saket Saurabh:
So it seems like the shift is also, instead of just optimizing model output, designing good failure paths too. When things don’t work, how do you handle that?
Anusha Dandapani:
Yeah. Sometimes I’d rather have a less sophisticated model with a very solid design that’s sustainable, available, and running reliably in production across the board, and focus more on scaling that, than have an AI solution that’s ambiguous or unclear in how it behaves. When we’re feeding in our data, whatever data we bring into the AI solution affects a lot of things that aren’t fully in our control. So, as I said before, the right algorithm for the wrong problem is the most expensive failure point we care about.
Saket Saurabh:
Do you think, from an approach perspective, since we talk about how these models are “better than PhDs” and can ace any test, that we might be over-indexing on how capable the models are, to the point where we as implementers are missing the foundations of data science or data analytics we’d normally apply to a problem, and just outsourcing it to the model? Is there a risk that this approach is undermining how much human analysis actually gets applied?
Anusha Dandapani:
If the AI industry picks its own tests, it’s like you telling me that you grade your own papers. How do you design an evaluation framework that actually measures what matters to us? Sometimes AI developers selectively adopt certain benchmarks as the de facto measure of success, but in a context like ours, treating benchmarks as marketing isn’t very helpful. Most of our operational workflows need a benchmark and audit methodology that genuinely covers our scenarios and addresses our gaps, because our gaps are very different from the private-sector benchmarks that get explicitly published for marketing purposes.
We care about accountability mechanisms in these benchmarks more than we care about the marketing.
Saket Saurabh:
I can see a very deep understanding of your organization’s goals, objectives, constraints, and data coming into play in how you’re approaching implementation. Do you think that’s what differentiates organizations that end up successfully scaling AI from those stuck in endless experiments and pilots, that clarity of understanding and awareness? Is that the big difference?
Anusha Dandapani:
I think the big difference for successful organizations is recognizing that interoperability is fundamentally the most important thing, and it’s not just a technical problem, it’s an organization-wide problem. If an organization fails to share its own internal data because of a lack of proper APIs or formats, it fails to build trust around how its data will be used internally, and that data could even potentially be weaponized against them. Having technical interoperability and a trust-based architecture actually resolves many of the issues large enterprise organizations usually face. Sometimes we build this beautiful, all-encompassing, unified data architecture that nobody actually puts their data into.
Saket Saurabh:
I’ve seen that happen, multi-year projects with a lot of upfront investment and a big-bang launch, but then the outcomes just aren’t there years later. And often, by the time you get there, the technology has moved on, and people have moved their focus elsewhere. They often end up looking like half-started, unfinished initiatives.
Anusha Dandapani:
Yes.
Saket Saurabh:
One thing you mentioned earlier was that, when it comes to lineage, there’s often not a willingness to invest. Everybody’s talking about AI, but the willingness to invest in the fundamentals, data quality, data lineage, data cleanliness, structuring and organizing things, is less, even though we need that for the outcome. What’s your advice to other data leaders as they’re figuring out their budgets?
Anusha Dandapani:
When you’re determining budgets, I’d suggest not pushing back on the innovation, push back on the timeline instead. Instead of saying “our data quality isn’t good enough,” say, “based on the data we have right now, this model will give a wrong answer some percentage of the time. What does that wrong answer look like for us in operational terms?” When you translate data quality into decision quality and risk, it stops being a technical objection. People start understanding it, and at least at the leadership level, leaders can make an informed choice to accept that risk. What they can’t do is make a responsible choice when the risk is hidden inside a technical euphemism. Framing data quality as a data maturity challenge actually helps data leaders negotiate.
Saket Saurabh:
I think it goes back to the foundations of leadership, communicating both up and down, and keeping that pragmatic approach, which goes back to where we started: take a narrow focus area, build, and show outcomes from that. You can’t just constantly say “I’m building the infrastructure and the results will come later.” It’s keeping both together. This has been fabulous, Anusha, and you have really great insights into how data leaders can operate, at a much more complicated scale, given the nature of the organization you work with and the variety of stakeholders you deal with. But these are great lessons for everybody. Really appreciate you going into the details. To wrap up, I’d love for you to share what you find as good resources for people to learn and keep up with, and anything you’d want to share with the audience.
Anusha Dandapani:
Sure. Thank you for having me, Saket. These are the conversations that actually move the field forward. For anyone who wants to continue the dialogue, the best way to find me is on LinkedIn. I try to write regularly about the intersection of AI governance, humanitarian data, and responsible deployment, and what that actually looks like at scale. If you’re working on similar problems, I genuinely want to hear from you. This work is too important, and too complex, to figure out alone.
Saket Saurabh:
I love the mission and the impact AI can have with the work you’re doing, so I’d love to keep track and see the impact it creates. Thank you so much for taking the time today, really appreciate it.
Anusha Dandapani:
Thank you, Saket. Thank you.
