When people hear "AI-powered document generation," they picture a lawyer typing a prompt and getting a finished brief back in seconds. Clean, simple, magical.
That's not how it works. Especially not in immigration law.
At LegistAI, we've spent significant time building document automation into the core of our platform — not as a bolt-on feature, but as a first-class workflow. This post breaks down how we approached the problem, the architectural decisions we made, and where the genuinely hard parts live. If you're building anything in the legal tech space, most of this will transfer.

Why immigration documents are a harder problem than they look
Before the engineering decisions make sense, it helps to understand what you're actually automating.
Immigration filings are not free-form documents. They're a mix of:

USCIS forms with strict field requirements, validation rules, and version-specific logic (USCIS regularly releases new editions of forms like the I-485, I-130, or I-129 — and old editions are rejected)
Supporting documents like cover letters, RFE responses, and legal briefs that are free-form but need to reference case-specific facts consistently
Evidence packages that compile client-supplied documents, attorney declarations, and exhibits into structured submission bundles

These three categories need fundamentally different generation strategies. Treating them the same way is where most legal document automation gets it wrong.

The architecture: three layers, not one
Layer 1 — Structured form filling (deterministic)
USCIS forms are essentially structured data schemas. The I-129 petition for nonimmigrant workers, for example, has over 50 fields across multiple parts, with conditional logic — if the beneficiary's job is in a specialty occupation, fill Part 2 differently than if it isn't.
For this layer, LLMs are the wrong tool. You don't want a language model making judgment calls about whether to check a box on a government form. You want deterministic logic driven by validated intake data.
Our approach here is a data-to-template pipeline:
Intake Data (structured JSON)
↓
Validation Layer (field rules, edition checks, conditional logic)
↓
Form Renderer (PDF generation with field mapping)
↓
Audit Log (every field value traced to source data)
The intake form on the attorney side is designed to collect exactly the data fields the USCIS forms need, mapped one-to-one. When a form edition changes, we update the field mapping — not the intake flow.
The key design principle: the output is deterministic and traceable. Every value on a generated form can be traced back to a specific input. Attorneys need to be able to review and sign off on filings. A black box that "generates" form answers is a liability, not a feature.

Layer 2 — Template-driven prose with AI augmentation
Cover letters, support letters, and petition narratives do benefit from AI generation — but not in the way most people think.
The naive approach is: give the LLM the case facts and ask it to write the cover letter. The output is usually grammatically fine and structurally wrong. It misses jurisdiction-specific language, omits required citations, and has a tone that doesn't match how immigration attorneys actually write.
Our approach is a template-first, LLM-augmented model:

Master templates — attorneys build and maintain template documents for each filing type (H-1B cover letter, I-485 transmittal, RFE response shell, etc.). These encode the required structure, standard language, and statutory references.
Variable extraction — the AI's job is not to write the document. It's to extract and normalize case-specific facts from intake data and attorney notes, then slot them into the template variables.
Narrative generation for open fields — sections like "describe the petitioner's specialized knowledge" or "explain the beneficiary's extraordinary ability" are where the LLM actually drafts prose. These sections get flagged for mandatory attorney review before any filing.
Consistency checker — a second LLM pass checks that names, dates, company details, and visa categories are consistent across all sections. This catches the subtle errors that happen when a document references "the petitioner" in one section and uses the company's full legal name differently in another.

Template (attorney-maintained)
+
Case Data (from intake)
+
LLM extraction pass (facts → variables)
↓
Populated draft
↓
LLM consistency check
↓
Flagged for attorney review (open narrative sections highlighted)
↓
Final document
The attorney reviews a near-complete document, not a blank page. Their job shifts from drafting to reviewing and refining — which is how it should work.

Layer 3 — Evidence bundle assembly
The third layer is less about generation and more about orchestration. An immigration filing typically requires assembling 10–40 supporting documents into a specific order, with a cover index, exhibit labels, and pagination that matches the index.
This is entirely deterministic — no AI required. But it's where a huge amount of paralegal time goes in a traditional firm. Our system:

Maintains a document checklist per filing type (configurable, since requirements vary by service center and visa category)
Tracks which documents have been received vs. outstanding
Assembles the final bundle with auto-generated exhibit tabs and a paginated index
Flags any document that's expired (passports, I-94s, employment letters older than 6 months)

The AI touchpoint here is in document classification — when a client uploads a file, a lightweight classifier identifies the document type and routes it to the right checklist slot. Getting this right saves attorneys the manual work of reviewing every upload.

Where hallucination is actually dangerous
A lot of legal tech discussion about LLMs focuses on hallucination in research contexts — the model citing a case that doesn't exist. That's a real problem. But in document generation, the failure mode is subtler.
The cases we've had to engineer carefully against:
Date arithmetic errors. An LLM asked to note that "the beneficiary's status expires 90 days from the filing date" will sometimes get the math wrong, especially across month boundaries or leap years. We handle all date calculations in code, never in the LLM.
Regulatory version confusion. Models trained on data from 2023 may reference policy memos or fee schedules that have since changed. Any regulatory reference in a generated document is validated against our internal policy database before the document is finalized.
Over-confident language. LLMs tend to generate declarative statements. Immigration filings often require carefully hedged language — "the petitioner submits that..." rather than "the petitioner has demonstrated..." The difference can matter in an RFE response. We use system prompts that enforce appropriate epistemic register, and attorneys flag anything that reads as too assertive.
Name and entity consistency. If the beneficiary's name appears in 14 places across a filing package, it needs to be identical every time — including middle name handling and hyphenation. We run a named entity consistency pass before any document is finalized.

The review workflow matters as much as the generation
This is probably the most underrated part of building legal document automation: the tools attorneys use to review AI-generated content are as important as the generation itself.
We've found that attorneys are much more comfortable with AI-drafted documents when:

Changed sections are highlighted — if the AI touched a section, the attorney sees it in a different color. Clean sections (pulled directly from templates or structured data) look different from AI-generated prose.
Each field is traceable — hovering over a filled field shows the source data it was pulled from.
Review is in-line, not export-and-edit — if attorneys have to export to Word to make changes, the feedback loop breaks. Changes need to flow back into the system so the intake data stays in sync.
Approval is explicit — a document cannot be marked ready for filing until an attorney has clicked through and approved each flagged section. No implicit approvals.

This isn't just UX polish. It's what allows attorneys to actually trust the output enough to use it.

What we'd build differently
A few things we'd approach differently with the benefit of hindsight:
Start with the review workflow, not the generation. We spent a lot of early engineering time on generation quality before we had a solid review interface. The bottleneck turned out to be attorney trust, not output quality.
Don't try to fine-tune for legal style early. We experimented with fine-tuned models for immigration document generation. The improvement in style wasn't worth the maintenance overhead. Better system prompting with carefully maintained template libraries achieved comparable results with much less friction.
Version your templates like code. Immigration form editions change. Policy language changes. Template drift is a real operational problem. We now treat templates as versioned artifacts with changelogs, reviewed whenever USCIS issues a form update.

The bottom line
Legal document automation for a domain like immigration law is not a single AI feature. It's a layered system where deterministic logic, structured data pipelines, LLM augmentation, and attorney review workflows all have to work together.
The places where AI adds genuine leverage — narrative drafting, fact extraction, document classification, consistency checking — are different from the places where you need hard guarantees — form field accuracy, date calculations, regulatory citations.
Getting that distinction right is what separates a tool attorneys actually use from one they try once and abandon.
If you're building in this space and want to dig into any of these layers in more detail, feel free to reach out. Happy to trade notes.

LegistAI is an AI-powered operating system for immigration law practices — combining case management, document automation, AI-assisted legal research, and USCIS tracking in one platform. Learn more at legistai.com.