I have shipped seven AI workflows inside a publicly-traded B2B company in the last year. Three more died before launch. The three that died were not killed by IT. They were killed by legal review, and in retrospect, all three were killed for the same reason.
This is what I learned to do differently.
The Pattern That Kills Pilots
When a corporate legal team reviews a new AI workflow, they are not reading your pitch deck. They are reading a checklist that was written before generative AI existed, and they are looking for things they recognize: data egress, vendor risk, audit trails, customer PII, IP ownership of generated outputs.
If they cannot map your workflow to that checklist in the first ten minutes, your pilot is in the queue behind every other unmapped request. That queue is measured in months.
The three pilots I lost all failed at the same step: I sent legal a description of what the AI did, instead of a document that mapped my workflow to the controls they already cared about.
The single document that gets a corporate AI pilot through legal review fastest is not a one-pager about the AI. It is a one-pager about the data the AI touches.
What Actually Got Through
After the third dead pilot, I rebuilt my submission template from the legal team’s perspective. Three sections, two pages, no marketing language. Here is the structure:
Section 1: Data inventory. Every data field the workflow ingests, where it comes from, and the existing classification it already has under our data policy. If a field is “customer PII” in our CRM, it is “customer PII” in the AI workflow. The classification does not change because a model is involved.
Section 2: Data flow. A literal diagram of where the data moves. Source system → preprocessing → model vendor → output destination → retention. For each arrow, I cite the existing vendor agreement that governs that hop. If no agreement covers a hop, that is flagged at the top of the document.
Section 3: Failure modes. What happens when the model is wrong. Who sees the wrong output, what business decision it could affect, and what the rollback looks like. This is the section that turns a “no” into a conversation.
The Reframe That Mattered Most
The thing that changed my hit rate was not the template. It was a single sentence I added to the cover note:
“This workflow does not introduce a new data classification, vendor relationship, or decision-making authority. It automates a task that an employee already performs under existing controls.”
If that sentence is true, legal can route the review to a fast-track process. If it is not true, the document tells them exactly which control needs new review. Either way, you have done their triage for them.
The pilots that died were the ones where I asked legal to evaluate “an AI tool.” The pilots that shipped were the ones where I asked legal to evaluate “a workflow that processes already-approved data through an already-approved vendor.”
Same workflow. Different framing. Different outcome.
What This Costs You
The honest version: writing this document takes about three hours per workflow. It is the least interesting part of the entire build, and the part that pays off the most.
The math is simple, three hours of writing on Friday afternoon, or three months in a review queue. I have learned to do the writing.
Field Notes
- The legal teams I have worked with do not have a problem with AI. They have a problem with novelty. Novelty is what makes their checklists useless.
- Two of the three workflows that died eventually shipped, six months later, after I rewrote the documentation. Same code, same data, same vendor.
- I keep a running document of every objection legal has ever raised, organized by control category. Every new submission addresses the relevant ones preemptively. The document is now eleven pages. It saves me weeks per pilot.