The Project

In a regulated industry, "ask the AI" is a liability unless you can answer two follow-up questions: where did that answer come from, and who was allowed to ask it. A confident-but-unsourced answer about a compliance requirement isn't a convenience — it's an audit finding waiting to happen, and possibly a regulatory one.

So when a paying customer in regulated lending needed a way for their team to get fast, trustworthy answers about the federal rules they operate under, the bar wasn't "a chatbot that sounds right." It was a system whose every answer is grounded in the actual regulatory text, scoped to the person asking, and built so that sensitive customer data never leaves an environment they control.

I designed, built, and deployed that system — solo — and it has been live in their hands for a paying engagement. Start to production: a few weeks, not the multi-quarter timeline this kind of work usually carries.

---

What Was Built

Answers grounded in the source, with citations — The core is a retrieval-augmented system over the corpus of federal regulations and supporting guidance the business is held to. Instead of letting the model answer from memory — where it can hallucinate a rule that doesn't exist or paraphrase one into the wrong meaning — every response is anchored to retrieved passages and shows its citations. An operator can click straight through from the answer to the exact regulatory text it rests on. In a compliance setting, "trust me" is worthless; "here's the paragraph" is the entire point.

Doctrine, not vibes — The assistant runs under an explicit operating doctrine rather than a loose prompt. That doctrine governs how it reasons about a question, when it must defer to the cited source, and where it must refuse to guess. The result behaves less like an improvising chatbot and more like a well-trained analyst who always shows their work and never freelances on a regulated topic.

Role-locked operators — Not everyone should see or do everything. The system enforces real role tiers, so what a given operator can ask, retrieve, and act on is bounded by their role — not by their willingness to type the right thing. Access is granted explicitly, never assumed.

A private, in-tenant model — This was non-negotiable for a regulated lender: the model runs inside an environment the customer controls, not behind a third party's public API. Sensitive material used in a query never leaves their boundary, which collapses an entire category of data-handling and vendor-exposure risk that would otherwise dominate the compliance review.

Production-grade, not a demo — It's deployed as a persistent, always-on service with authenticated access, ready for day-to-day operator use rather than a one-off demo that dies when the laptop closes.

---

Skills Demonstrated

  • Applied AI for regulated environments — designing a retrieval-augmented system whose value comes from traceability, not just fluency, with citations as a first-class requirement
  • Compliance-aware system design — translating "we're a regulated business" into concrete architecture: grounded answers, enforced roles, and a data boundary that survives an audit conversation
  • Data-privacy engineering — running the model in-tenant so sensitive data never crosses a vendor boundary, removing a whole class of risk by design
  • Access control — real role tiers and explicit grants, so capability follows authorization rather than the honor system
  • End-to-end delivery, solo — taking one engagement from problem statement to a live, paid, production deployment in weeks, owning every layer from retrieval to deployment

---

Why It Matters

Most "AI for compliance" pitches get the direction backwards. They start with a powerful model and try to bolt trust on afterward. In a regulated business that ordering doesn't survive contact with reality — the first question from anyone serious is where did the answer come from, and an ungrounded model has no good response.

This project started from the opposite end: traceability, scoped access, and data control as the foundation, with the model serving that foundation rather than the other way around. That's what made it deployable for a real, paying customer in a regulated field instead of a slick demo that legal would never sign off on.

The takeaway I keep coming back to: in regulated work, the differentiator isn't how smart the model sounds. It's whether every answer can be traced to its source, every operator is scoped to their role, and every byte of sensitive data stays where it belongs. Get that architecture right and a single person can ship — in a few weeks — something an enterprise would normally spend quarters circling.