AI Asylum Aid

AI Asylum Aid simplifies complex legal systems, using AI-powered guidance and resource navigation to make seeking asylum accessible and to help reclaim a path to safety.

Comment

Inspiration

We go to a boarding school with kids from a lot of different countries, and over the past few years that's meant hearing a lot of stories we never expected to hear. A friend's family that couldn't go back home. Someone mentioning that an uncle had been detained and nobody knew what they were supposed to do about it. We obviously hadn't lived any of that ourselves. But after hearing versions of it enough times, one thing was pretty clear: the law usually wasn't the hardest part. The hardest part was that nobody could tell these families, in a language they actually understood, what to do next. When the hackathon kickoff landed on Direction A, "Crisis-to-Action Translator," it lined up with all of that. But we didn't want to build something that only would've helped the two or three families we happened to know. UNHCR's most recent numbers put forced displacement at around 117.8 million people worldwide at the end of 2025, with about 9 million of them asylum seekers waiting on a decision. That's the gap we wanted to build for.

What it does

AI Asylum Aid is a multilingual chatbot that gives people an actual next step instead of a wall of legal text. It's available as a web app, an iOS app, and an Android app, all running on the same backend.

  1. You start by entering where you're from and where you currently are. Everything else (gender, civil status, more detail about your situation) is optional.
  2. You describe your situation in your own words, in your own language, and the AI responds in that same language. Guidance is supported in around 100 languages, and right-to-left layout kicks in automatically for Arabic, Dari, Pashto, Persian, Urdu, Sorani Kurdish, Sindhi, Uyghur, Hebrew, and Syriac.
  3. You get a plain-language explanation, a numbered checklist, and next steps. No legal jargon without an immediate plain-language definition, and every claim is grounded in a curated list of sources for your destination country (USCIS, EOIR/DOJ, UNHCR, GOV.UK, EUAA, IRCC, and others), cited directly.
  4. You get a map of legal-aid clinics, NGOs, and community services near you.
  5. You always get pointed to a real attorney by the end. The app explains and orients. It doesn't decide your case for you. ## How we built it We started with notes. During the kickoff we split up taking notes; one of us on the rubric, one on the example prompts, one on what the judges said they'd actually be looking for. Afterward we got on a call with those notes open and just talked about which direction we wanted to spend the whole weekend on. Crisis-to-Action Translator kept circling back to the conversations we'd had at school, so we looked at the current state of the world; displacement numbers, how different asylum systems are country to country, etc; and decided to build specifically for people seeking refuge, since that's the gap we understood best. From there we opened a GitHub repo and spent a while just talking to Claude before writing any product code. Not "build us an asylum app," but actually working through what the intake form should ask for, which fields should be optional, what a response should look like so it's useful to someone who's scared and exhausted instead of another wall of text, and where the line has to sit between explaining the law and giving legal advice. Once that felt right, we built it with Claude through; the backend, the prompt design, and eventually two native app ports. The architecture ended up being three layers: text Browser / iOS / Android client | HTTP — localhost only Node.js + Express proxy (server/server.js) - holds the API key server-side, never sent to any client - validates & sanitizes input, rate-limits per IP | HTTPS (Anthropic SDK, streaming) Anthropic Claude API - fixed system prompt, adaptive thinking, streamed token-by-token | GET /api/resources — curated, static, authoritative links

The web frontend is vanilla HTML/CSS/JS with no build step. It talks to the backend over POST /api/chat, which streams the reply back as newline-delimited JSON so it looks like it's typing in real time instead of showing up all at once. We built native SwiftUI and Kotlin/Compose apps on top of that same backend — same routes, same guardrails, same system prompt — so the safety behavior doesn't change depending on which app you're using. iOS reads the stream with URLSession.bytes(_:).lines, Android does the equivalent in Kotlin. Neither one stores anything on the device. For the map we used Leaflet and OpenStreetMap on web, MapKit on iOS, and osmdroid on Android, with location data from the Overpass API and Open-Meteo geocoding. Results get ranked by actual distance using the haversine formula: $$ d = 2r \cdot \arcsin\left(\sqrt{\sin^2\left(\frac{\phi_2-\phi_1}{2}\right) + \cos\phi_1 \cos\phi_2 \sin^2\left(\frac{\lambda_2-\lambda_1}{2}\right)}\right) $$ where $\phi$ and $\lambda$ are latitude and longitude in radians and $r$ is Earth's radius. Nothing fancy, but it's the difference between a list of pins and actually showing the clinic that's closest to you.

Challenges we ran into

The biggest one was the one we expected going in, which was the gravity of the situation we were working with. A static FAQ can't really be "wrong" about much because it never claims to know much. An AI confidently giving someone the wrong filing deadline or the wrong eligibility ground could hurt them. We spent more time arguing about this than about any single feature. Instead of trying to make the model itself "more correct," we leaned on a strict human-in-the-loop setup: the system prompt makes the AI explain and orient, not decide, every claim has to come from our curated source list and gets cited, and any case-specific question gets redirected straight to a real attorney. That system prompt is fixed server-side so it can't get talked around through clever phrasing in the chat. Second was figuring out what data we just shouldn't have. Asylum seekers are often fleeing someone with power over them, so "what if our database gets compromised or subpoenaed" wasn't a hypothetical we could brush off. We ended up designing around not having the data at all; the backend is stateless, conversation history only lives in memory for the session, nothing's logged server-side, and even the optional fields (ethnicity, religion, political opinion, civil status) are capped in length and never saved. We gave up some features we originally wanted, like saved case history, because it wasn't worth the risk for this group of people. Third was keeping three apps consistent with each other. Once the web app worked, porting the same guardrails and the same map ranking to native Swift and native Kotlin without something quietly drifting in translation took more discipline than we expected. We ended up treating the backend as the single source of truth and keeping both native apps deliberately thin, so there's really only one place any of this logic could break.

Accomplishments that we're proud of

We're proud that our project can meet someone at a bad moment, scared, in an unfamiliar country, maybe not speaking the local language, and hand them back something they can actually act on, in seconds, in their own words. We're also proud we shipped a full cross-platform product over the hackathon week: a web app and two fully native mobile apps sharing one backend, without cutting the safety design to get there. We also held the privacy line even when it meant the app remembers less than a typical one would.

What we learned

We learned that translating an app is really two separate problems: translating the interface, which we hand-did for English, Spanish, Arabic (RTL), French, and Ukrainian, and translating the actual content, which the model handles dynamically across around 100 languages. Those two systems need to fall back into each other cleanly instead of breaking when they don't line up. We learned how much a map changes how an app feels. Going from a list of links to an actual pin a few blocks away is a bigger jump than we expected, and it also meant dealing with location permissions, OpenStreetMap attribution requirements, and what to show if someone declines location access. We learned a lot about how much power AI actually has here. The same model that can take someone's panicked three-paragraph message and turn it into an ordered checklist in their own language in under ten seconds could just as easily generate a confident, wrong answer about something that can't be undone. We also learned a decent amount about the actual legal landscape asylum seekers deal with; the five grounds protection can be claimed under (race, religion, nationality, political opinion, and membership in a particular social group), how different the process looks depending on where someone's trying to go, how real filing deadlines are, and how often the real obstacle isn't the law itself. It's just not knowing it exists.

What's next for AI Asylum Aid

We have a working web app, iOS app, and Android app. From here:

Verified handoff to real attorneys. Right now we link out to legal-aid directories. Next, we want a consent-based handoff to an actual vetted attorney or accredited rep in someone's destination country, not just a URL.

Offline and low-bandwidth support, including SMS. A lot of the people who need this most are in camps or in transit without reliable data. A lightweight SMS fallback would reach a lot more people than a smartphone app alone ever could.

Voice mode. Not everyone we're trying to reach reads comfortably in any language. Speech-to-text and text-to-speech across our supported languages would open this up to people for whom typing itself is a barrier.

A resource directory that stays verified over time, ideally in partnership with UNHCR or established NGOs, plus attorneys periodically reviewing anonymized transcripts to check quality.

Taking the same idea past asylum specifically. Translating an overwhelming, high-stakes process into a sourced, personalized checklist with a human at the end of it isn't unique to asylum cases. We'd want to try the same approach on other crisis-to-action gaps this hackathon's brief points at, like disaster recovery or domestic violence safety planning

Built With

Share this project:

Updates