Case study

Building AI CORA: an AI compliance analyst for the nonprofit sector

How a manual review process measured in hours became a 15-minute workflow, and what I learned shipping an AI system that a compliance team trusts with real decisions.

By Chinmay Bandekar · Hasso Plattner Foundation · 2025–2026

The problem nobody chose

Every foundation that gives out grants has the same quiet obligation behind the scenes: making sure every grantee actually complies with the rules. At the Hasso Plattner Foundation, that job sits with the Controlling team, and the rules are not simple. Grantees operate under both German and US charitable law, two dense regulatory frameworks that do not always agree with each other.

The process was entirely manual. For every grantee, someone had to work through stacks of legal and financial documents, cross-check them against regulatory requirements, and write up an assessment. A single review could mean 10 or 11 PDFs, some of them enormous. It took 5 to 6 hours per grantee, and the real cost was not even the time. It was the risk: with that volume of documents and that much regulatory surface area, small but important details can slip past even careful human eyes.

We looked for existing tools and found nothing built for this in the nonprofit sector. Compliance AI existed for banks and insurers, not for foundations navigating charitable law. So we decided to build it ourselves.

Finding the right tools by rejecting the wrong ones

The first phase was exploration, and most of it was learning what would not work. I evaluated low-code routes first, including Power Automate and Power Apps with their built-in OCR capabilities. They were quick to prototype with, but they hit a ceiling fast: not enough control over how documents were parsed, how context was assembled, or how the reasoning layer behaved. For a compliance tool, that control is not optional.

The stack we landed on gave us that control: Python and Django for the application, LangChain for orchestrating the document pipeline and LLM calls, OpenAI and Anthropic models for the reasoning layer, and Azure for deployment. Every piece earned its place by surviving an iteration where something simpler failed.

One month to a working prototype

The first version of AI CORA took a month of building, tearing down, and rebuilding. There were many iterations and more than a few changed decisions before the architecture settled. The prototype did one thing end to end: take real legal documents, run them through an AI analysis layer, and present the results on a live web UI. Seeing a genuine grantee document go in one side and a structured, readable analysis come out the other proved the concept was real and worth scaling.

The system grew into two modules that mirror how the team actually works: a Monitoring module that gives a document overview and an AI-generated analysis of an existing grantee, and a Vetting module that supports due diligence on new grantee applications to verify their eligibility for funding.

The three hardest problems

1. GDPR and data protection. This was the toughest constraint of the entire project, and rightly so. A compliance tool that itself violates compliance is worse than useless. We aligned the system with GDPR requirements from the design stage and built in PII detection, so personal data is identified and handled according to the rules rather than flowing blindly through the pipeline. Working in Europe, I now treat data protection as an architecture input, not a checkbox at the end.

2. Token economics at document scale. A single review can involve 10 or more PDFs, and some of them are massive. Naively pushing everything into an LLM context is both expensive and counterproductive. A large part of the engineering effort went into reducing token cost while holding output quality high enough for audit purposes: smarter document chunking, retrieval instead of brute force, and being deliberate about what actually needs to reach the model.

3. Hallucination in a domain where wrong answers have consequences. In casual applications, a hallucinated sentence is an annoyance. In compliance, it is a liability. Grounding the analysis in retrieved document content, constraining the model's role, and keeping a human reviewer in the loop for every final decision were all part of making the output trustworthy enough for audit-facing work. AI CORA drafts the analysis; the team makes the call.

Where it stands

AI CORA runs in production today and is used daily by the 8-person Controlling team. What used to be a 5 to 6 hour review is now roughly 15 minutes of reading a prepared analysis and making the judgment call that only a human should make. The time saved goes where it belongs: into the judgment, not the paperwork.

What's next, and what I'd do differently

The foundation is laid for more than one team's workflow. The natural next steps are a systematic evaluation harness that continuously scores output quality against human reviews, deeper multi-model routing so each task runs on the most cost-effective model that can handle it, and extending the same document-intelligence core to neighboring processes like audit preparation.

If I rebuilt it today, I would design the evaluation layer first, not last. I would also introduce retrieval earlier instead of discovering token limits the hard way, and invest in observability from day one, because the fastest way to earn a team's trust in an AI system is being able to show them exactly what it did and why.

The takeaway

AI CORA taught me that the hard part of AI engineering is rarely the model. It is everything around the model: data protection, cost discipline, grounding, deployment, and the slow, honest work of earning the trust of the people who have to rely on the output. That is the work I want to keep doing.