The Legal Review Timeline Your AI Feature Roadmap Never Costed

You sketched a six-quarter AI roadmap. The model swap, the new data source, the multilingual launch, and the prompt that now offers advice each got a single row on the Gantt chart, sized by engineering effort. Then the first launch slipped four weeks, and the post-mortem said the same thing three times in three different sections: "waiting on legal." The roadmap had assumed engineering capacity was the binding constraint. The actual binding constraint was a queue of legal reviews, each running its own three-to-six-week SLA, none of them aware of each other, and all of them landing on the same two product counsels.

The mistake was not in any of the individual reviews. Each one was warranted. The mistake was treating four parallel features as four parallel timelines while their legal dependencies serialized through the same upstream resource. By the second slip the org learns the shape of the problem. By the fourth it learns to plan against it. The teams that ship AI features on a predictable cadence have stopped treating legal throughput as an external surprise and started treating it as a planning input on the same footing as headcount and infra capacity.

Why the AI roadmap multiplies the review surface

A conventional feature touches one or two review-worthy properties: a UX change here, a data field there. An AI feature touches more, and each touch can re-open the review. A model swap changes the data processor of record and may shift the legal basis under data-protection law. A new training corpus invites questions about provenance, license, and whether the upstream license survives derivative use. A multilingual launch crosses jurisdictional lines and pulls in the EU AI Act's transparency obligations, the UK's emerging guidance, and a half-dozen state laws in the US. A prompt change that turns a "summarize" feature into an "advise" feature can re-classify the system entirely under the AI Act risk tiers, with documentation requirements to match.

The 2025 regulatory wave made this concrete. The EU AI Act entered into force in August 2024 and began phasing obligations through 2025 and 2026: prohibited-system bans in February 2025, general-purpose-model rules in August 2025, broad applicability in August 2026, high-risk obligations in August 2027. Each phase added a checklist that legal has to apply against the in-flight roadmap, and each phase widened the definition of what counts as a reviewable change. A model upgrade that would have been a one-line release note in 2023 is now, plausibly, a regulatory event with its own documentation package.

The roadmap that costed each feature in engineering weeks did not cost any of this. The legal queue is the queue the roadmap forgot.

The queue you cannot see is the queue that ships your dates

The first symptom of an under-modeled legal queue is the same in every org: the dates are met until they are not, and then they slip together. Three features in three different teams discover at roughly the same week that their reviews are still pending. The teams blame each other's reviews for "blocking ours." The legal team blames a load it was never staffed for. The roadmap owner blames the calendar.

The shared property is that nobody ran the queue as a queue. The reviews entered through a wiki form, a Slack DM, and a quarterly intake meeting. They had no posted SLA, no inflight count, no triage rubric. The product counsel was reading three of them at once, and the engineering team had no visible "you are #4 in line, expected start in three weeks" signal. This is the part of legal that looks most like an unmonitored microservice: a single endpoint serving a saturated thread pool, with the caller's only visibility being whether the response eventually came back.

The diagnosis is dull and the fix is duller. Treat the review intake as you would treat any production-facing service. Post the SLA. Post the current depth. Publish a category list so an engineer can see in advance whether their change falls inside the standing envelope or triggers a fresh review. Track the rate of intake, the rate of clear, and the time-in-queue percentiles. None of this is novel. It is novel only in that the organization has never thought to apply it to a legal function.

The standing envelope is the highest-leverage move

A standing envelope is a pre-approved scope inside which a class of changes can ship without a fresh legal review. The classic example is the marketing template that has already been cleared, against which a new asset is "obviously inside the lines." For AI features, the envelope is harder to draft but vastly more valuable, because the marginal review cost is what dominates the schedule.

The envelope is a contract between legal and engineering that says: for changes of this shape — same data sources, same risk class, same external surface, model swap inside this whitelist, prompt change inside this category — the team may ship under a posted self-attestation, and legal will sample audit instead of pre-reviewing. The trade is explicit. Legal gives up gate review on the in-envelope set in exchange for a sharper, faster review on the out-of-envelope set. Engineering gives up the freedom to silently expand scope in exchange for a predictable shipping path on changes that stay inside the box.

The shape of the envelope matters more than its size. A small envelope that covers 60% of the planned changes is more useful than a large envelope that requires a 90-minute reading exercise before anyone can tell whether their change qualifies. The envelope should be readable in a single page. It should have a worked example. It should have an unambiguous out-of-envelope trigger list — adding a new data source, changing the legal basis, expanding to a new jurisdiction, shifting the output from informational to advisory — and an unambiguous in-envelope confirmation step that produces a logged self-attestation. The attestation is the artifact that makes the envelope auditable.

Teams that ship this envelope discover that 70-80% of their review volume falls inside it. The remaining 20-30% is the genuinely novel work, which is exactly the work that warrants a careful pre-review. The legal team is now reviewing the right things, instead of pre-reviewing every change because there is no way to triage.

The embedded counsel is a cycle-time intervention, not a cost line

Embedding a product counsel inside a feature team is the move every leadership team understands intellectually and resists operationally because it looks like a headcount increase that does not produce a deployable artifact. The resistance is wrong on the math. An embedded counsel does not produce code; it produces compressed cycle time on every feature the team ships. A four-week review that becomes a two-day conversation because the counsel was in the design review is the entire ROI calculation.

The structural reason this works is that the most expensive legal feedback is the late feedback. A counsel who learns about the feature at the gate review can only say "stop and redo." A counsel who was in the spec review can say "yes, if you do it this way." The "yes, if" is the artifact that turns a hard no into a workable design. It is also the artifact that fails to exist when the counsel sees the feature for the first time as a finished PR.

The leadership move is to staff legal to the cadence of the AI roadmap rather than to the volume of historic legal work. The historic volume is a lagging measure of a function that was sized for a slower world. The forward volume is a function of how many AI changes per quarter the roadmap actually intends to ship, multiplied by the fraction outside the standing envelope, multiplied by the average review depth. That number is the staffing target. If the function is undersized against it, the roadmap will slip and the cause will read "waiting on legal" in every post-mortem, which is the symptom but not the diagnosis.

Treat the legal pipeline as a planning input, not a launch surprise

The roadmap that survives the next eight quarters is the one that prices legal review at the same fidelity as engineering effort. This means three concrete changes to how the roadmap document looks.

• Every AI feature row carries a legal-cost estimate alongside the engineering-week estimate. The estimate is in queue-weeks, not in lawyer-hours, because queue-weeks is what the calendar feels. A model swap inside the envelope might cost zero queue-weeks. A new data source might cost six. The estimate is a guess; the discipline of guessing is what forces the conversation.
• Features that share an out-of-envelope legal dependency are flagged as a shared-resource conflict in the same way two features that need the same SRE on-call are flagged. The Gantt chart that ignores this is lying about the schedule.
• The standing envelope is reviewed quarterly with the same seriousness as the architecture roadmap. The envelope drifts as regulation drifts. The team that wrote the envelope in Q1 and forgot it by Q3 will discover at Q4 that half of what they have been shipping under self-attestation is no longer inside the lines.

There is also the second-order leadership move, which is to treat the legal partner as a co-owner of the roadmap rather than a downstream consumer of it. The co-owner attends the roadmap review. The co-owner pushes back on a feature whose shape will require an out-of-envelope review the team forgot to budget. The co-owner is graded, in part, on shipped features, not just on reviews completed. The grading change is what aligns the function with the roadmap; without it, the function is incentivized to review thoroughly and slowly, which is the locally optimal strategy that produces the globally observed slip.

The forward read

The 2026 regulatory horizon does not get cheaper. The EU AI Act's August 2026 broad-applicability date arrives mid-year for most companies. The high-risk obligations land in August 2027. State-level US laws continue to land at the rate of roughly one new significant regime per quarter. Each new regime is a new column in the review checklist and a new dimension along which the standing envelope has to be re-validated.

The teams that built the queue, drafted the envelope, embedded the counsel, and priced legal into the roadmap will absorb each new regime as an envelope amendment and a re-staffing decision. The teams that didn't will absorb each new regime as a roadmap re-plan and a quarter of slipped launches.

The leadership lesson is the one that every infra team learned about databases a decade ago: a function whose throughput sets your shipping calendar is not a vendor or an external service; it is part of your production stack, and it needs the instrumentation, the SLOs, the capacity planning, and the ownership that any production-stack component gets. Legal review for AI features is that function now. The roadmap that doesn't cost it is shipping against a plan that was wrong before the first sprint started.