In current discussions around the opportunities of leveraging AI assistants for data analysis, we often encounter the same argument: in humanitarian or international development organizations, an AI assistant, powered by a large language model (LLM), can help teams make sense of their data much faster. That saved time can go directly toward delivering aid instead.
However, this approach cannot work if the initial data is unorganized, siloed, and lacks context. An AI assistant that is let loose on the organization's internal documents and spreadsheets to deal with multiple duplicate files, undefined relationships between datasets, and lack of context will produce unreliable and misleading outputs. Even worse, it might create data protection risks and compliance issues.
A common example is donor reporting and evaluations that go through several revisions, or mid-term reports many of which are archived in OneDrive or SharePoint. The AI assistant would have trouble recognizing which definitive version to use. Without a trusted, structured system of record, you're likely to get different numbers each time you ask it for insights.
In this article, we discuss the most pressing challenges LLMs face when it comes to working with quantitative data and how the relational database model and a relational database such as ActivityInfo can help organizations tackle those.
Referential integrity: Maintain clear relationships between data
LLMs cannot easily identify relationships among different entities when they lack context. So if for example you have several spreadsheets in OneDrive or SharePoint mentioning the same entity (e.g. a beneficiary or a location) in slightly different ways, the model won't be able to detect the connection unless very explicitly guided to do so. Imagine having hundreds of entities mentioned in tens of spreadsheets in various folders across your organization; it can quickly become an impossible task to guide it through those.
However, a relational model allows you to build this structure and provide that context so that the LLM can work based on a solid foundation that guides it through the connections of your data.
Permissions and role-based access: Protect confidential and sensitive data
There are several considerations when it comes to data protection and AI assistants.
First of all, your organization should treat the LLM provider like any other technology provider, asking the same questions and holding them to the same, if not stricter, requirements. A data processing agreement (DPA) with the LLM provider should be in place to govern how they will access and use your organization's data.
It is important to ensure that sensitive data is only accessed by the provider's team only for agreed purposes. Consumer AI tools' terms of service may permit broad use of shared data, for example for model training or product improvement, so it is necessary to check the specific provider's policy carefully, as this can be incompatible with keeping beneficiary data confidential. In addition to ethical considerations, there are also legal and compliance requirements to consider. For example, if the LLM provider requires data to be transferred outside the organization's country, do you have the permission to allow that?
Another important consideration involves controlling access to data within your own organization. AI assistants provide a new natural language interface to your data that exists next to existing web-based user interfaces. There might be sensitive and confidential data such as case notes, PIIs, or other data that should be limited to only specific staff members.
For example, a MEAL officer analyzing pre- and post-training assessments from a rights holders' training might use an AI assistant to measure changes in participants' understanding, assuming a DPA is in place with the provider. However, someone in the communications team who only needs aggregate completion numbers for a donor report should not be able to access individual participants' names, responses, or locations through their own AI tool.
To facilitate control over this, your organization needs to have a governance structure in place to classify data and define access permissions that clearly indicate which data must remain private and protected, and which can be analyzed and shared for fundraising, public awareness or other data analysis purposes and by whom. Respectively, the AI assistant must enforce the users' permissions following that structure.
In a relational database such as ActivityInfo, you have the tools to refine permissions and define access according to specific roles. This way you ensure that the AI assistant can access only what's needed for the analysis.
Authoritative single source of truth: Detect the correct version and verify results
As discussed, when you have multiple versions of the same file in your folders, it becomes difficult for an AI assistant to know which is the correct version so as to use it as the starting point and its single source of truth.
With a well-structured relational database, there is a single value for each indicator for a given time period. In platforms such as ActivityInfo, it is possible to enforce validation rules for data entry to ensure that you start with a clean, quality basis. You can for example, prevent a duplicate beneficiary record or flag a value that doesn't make sense. This way the AI assistant has one authoritative, quality source to begin with.
Without that, you risk getting wrong numbers for donor reports, or having two teams within the same organization making decisions off different figures. Structured data makes it far easier to trace back and validate that the AI assistant's output is correct before sharing it with stakeholders.
LLMs and the challenge of data analysis
While LLMs are good at summarizing data and narratives, they are challenged when advanced data analysis comes into play.
Even if you provide detailed instructions and run the datasets through code generated by the model, it is still possible that it will run into logical errors, skip null values, and write code that is based on wrong assumptions. There is also the risk that it will provide adjusted, optimized approaches that quietly change what is being measured, simply to manage to provide an output.
Because there are no constraints on how data is combined, the issues increase if linked datasets are involved; the LLM might assume relationships that don't exist due to naming conventions, double-count values, or run into other logic issues. What makes this worse is that non-technical users cannot review the code the LLM runs, so it becomes really difficult to track if and what might have gone wrong, fix it and defend the end result.
On the contrary, in platforms, such as ActivityInfo, that are designed specifically to facilitate working with data, there are guardrails that reduce the risk of error.
Using an AI assistant to write SQL to analyze data in relational databases can provide some guardrails for the process thanks to the defined constraints in the database. Even better, using it to write a data analysis tool description, such as a Notebook in ActivityInfo, and to create that tool in the system itself, lowers the risk of error further.
In this case, it is possible even for non-technical users to validate or fix issues in data analysis. Because the user can view the report definition and understand the choices made, where the data comes from, and what is used as dimensions and measures, it becomes much easier to monitor and verify the results of the AI assistant's process.
In addition, when asked to back up the results of the data analysis, it is much easier to go back and view the trail from the report definition, the numbers used in the report, and the users who provided the source data so as to defend the choices made and the provided results.
ActivityInfo as the data foundation for your AI assistant
ActivityInfo is a web-based information management platform specifically designed for the social sector. It is used by the UN, INGOs, NGOs, governments and local nonprofits for monitoring and evaluation, humanitarian coordination, case management, conservation and many more.
Based on the relational database model, the system allows you to collect and import data to the system in various ways. It stores data and the relationships between the datasets, such as for example activities, locations, and beneficiaries. It enforces strict validation rules at the point of entry, ensuring that what you eventually offer to an AI assistant is clean, consistent, and standardized across multiple countries or hundreds of partners. It allows you to bring data into the system in multiple ways. It offers data analysis and visualization tools as well as an API to facilitate integrations with external software. Last but not least, it offers role-based access and advanced user management and data security capabilities to enhance data protection.
Building on this foundation, ActivityInfo now offers an MCP server, which makes it possible to connect AI assistants directly to ActivityInfo databases.
Helping the AI assistant make the most of your data
In short, you cannot have a high-performing LLM system without a solid, structured foundation.
When you work with an AI assistant it is as if your organization has hired the best data analyst in the world to support their data analysis activities; that person would need to know where and how they can find the data, if the data is cleaned, which datasets can be accessed and which should be used, the context of the situation they are analyzing, the relationships between the datasets, and more. Similarly, without well-structured, validated, and governed data, AI assistants cannot produce trustworthy results.
We believe that the organizations that will benefit most from LLMs are not those adopting it fastest, but those that are investing in a structured, high-quality foundation to which an AI assistant can be linked to help them advance their progress and reach their full potential.
If you wish to explore the ActivityInfo platform, you can try various database templates and learn more about the MCP server.