The AI tools sold for “complex compliance forms” almost never reach the form your compliance team actually has to fill.

Two layers, one phrase

Strip the hype out of the category and there are two distinct problems hiding under one phrase.

Layer one is the questionnaire. A prospect sends a SIG. A regulator asks for an attestation in a standardized template. A customer wants a CAIQ filled out before they will sign a master agreement. These artifacts are text-answer-shaped, and a model with access to the right knowledge base can draft excellent answers. Vanta AI, Drata, Sprinto, Inventive AI, Responsive, and Spellbook all live here, and they all do real work. If your bottleneck is “our security team is buried under questionnaires,” one of them probably solves that.

Layer two is the system of record. A claims rep opens Guidewire and types the contents of a first notice of loss into a 14-field form across three tabs. A bank associate opens Fiserv DNA and creates a new commercial account through a 17-screen onboarding flow. A patient access coordinator opens Epic and registers a new patient through a sequence of modals where field B will not save until field A passes a validation rule that depends on the patient class field three modals back. These forms are the ones the compliance audit eventually inspects, because they are where the regulated data lives. They cannot be filled by a tool that only knows how to talk to HTML.

Why layer-one tools cannot fill layer-two forms

The questionnaire AI tools share an architecture: a retrieval layer over a knowledge base, a model that drafts answers, and an HTML or API integration that writes those answers into a SaaS questionnaire portal. That third stage is the one that does not generalize. The screen where a hospital admits a patient, where a bank opens a commercial loan, or where an insurer assigns an adjuster is not a web form. There is nothing for the integration to talk to. Trying to extend a layer-one tool down here is like asking a website screen-scraper to drive a desktop accounting program: it can read the screen, but it cannot reliably do anything with it because the surface it knows is missing.

The fix is not better selectors. It is a different surface entirely: the Windows UI Automation accessibility tree, which is the same tree a screen reader consumes. Every Win32 control that a compliance officer ever audited (Epic, Cerner, Fiserv, Jack Henry, Guidewire, Oracle EBS, SAP GUI, AS/400 emulators) exposes nodes in that tree because that is how Windows assistive technologies have worked since 2005. A form-fill runtime that reads and writes through that tree inherits two decades of plumbing other categories of tool do not get to use.

What it actually takes to fill one field

The smallest unit of work in a system-of-record form-fill is a single field. Trace what happens when the runtime types one value into one control. The whole product is built around the fact that this loop has to be deterministic, observable, and auditable, even when the surrounding form is not.

The single most important step in that diagram is “Resolve locator,” because that is where the runtime decides which node on the live tree corresponds to the field the recording captured months earlier. Skipping that step (or doing it with image matching or absolute coordinates, the way old-style RPA does) is what makes form-fill brittle in regulated apps that ship a new build every quarter.

The anchor: type_into_element and a four-strategy match

The MCP tool that does the actual typing is type_into_element. It is emitted from apps/desktop/src-tauri/src/mcp_converter.rs (lines 2298 and 2460), takes a structured locator and a string, and either calls EditPattern.SetValue on the matching UIA node or, when the node does not implement EditPattern, falls back to dispatching Win32 keystrokes through the accessibility tree. The locator is resolved by a four-strategy cascade in apps/desktop/src-tauri/src/focus_state.rs, which tries, in order: the recorded automation id, the window handle plus bounds, the visible text content, and finally the parent window as a last fallback. The first three strategies absorb the kind of UI tweak that breaks selector-based RPA (a button shifts a row, a panel reorders, a form gains a tab). Only when all four miss does the runtime mark the step for re-recording.

That zero is the whole reason this approach works in regulated industries. A compliance officer cannot sign off on a workflow whose action sequence is decided by a frontier model on each run, because two identical inputs can produce two different action sequences. A deterministic runtime that reads its instructions from a TypeScript file checked into source control is the same audit shape as a SQL stored procedure. The reviewer reads the file, the reviewer signs off the file, the runtime executes the file. The model is gone by the time anyone in compliance opens the artifact.

The form-fill loop in numbers

Counts from the Mediar monorepo: four strategies in focus_state.rs, zero LLM call sites in crates/executor (run a ripgrep over the crate to verify), eight semantic fields per step in the recording format, and a roughly 50 to 200 millisecond accessibility-tree walk per typed field on a typical Windows session.

Counterargument: when you actually want a layer-one tool

The honest case for a questionnaire-AI product over a system-of- record form-fill product is real and worth naming. If your problem is “a prospect just sent a 380-question SIG and we have to turn it around in five business days,” you do not need Windows automation. You need a model with access to your security knowledge base, an HTML integration into the prospect's questionnaire portal, and a workflow that lets a security analyst review the drafted answers before submission. Vanta AI, Drata, Inventive, Sprinto, and Responsive all do this well. The category they sit in is mature, the answers they produce are accurate when the knowledge base is good, and the time savings are large.

The mistake is buying one of those tools and expecting it to also fill the regulated form in your system of record. It will not, because the surface it integrates against simply does not exist on a Win32 app. The two layers want different products. A reasonable stack is one tool from each layer.

Resolution: pick the tool that fits the form

So what is the honest answer to “what AI tool fills complex compliance forms?” It depends entirely on which form you mean. If the form is a questionnaire, a vendor security assessment, or a modern web RFP, pick a knowledge-base-backed answer-drafting product and let an analyst review the output. If the form lives inside Epic, Cerner, Fiserv, Jack Henry, Guidewire, Oracle EBS, SAP GUI, or any other Win32 app the regulator audits directly, pick a desktop automation runtime that talks to Windows UI Automation, and pick one whose runtime is deterministic so the workflow itself is the audit artifact.

A team that ignores the second layer ends up with very fast vendor questionnaire turnaround and a ten-person operations team still double-keying claims, registrations, or onboarding screens because their AI tool literally cannot reach those screens. A team that ignores the first layer ends up with a beautiful Epic automation and a backed-up queue of SIGs. Neither half on its own is a compliance-form strategy. The right answer is one tool from each layer, and the harder question, almost always, is the second one.

Frequently asked questions