How do you bring legal into an AI project early without slowing it down?

Harrow Diagnostics sells an AI tool that flags urgent scans for radiologists to read first. Renata Sabbagh is the senior product manager who owns that triage feature, and she keeps a shared doc titled "things we almost shipped" that nobody outside her team has ever read.

How to answer this, stage by stage

Nobody is grading whether you can name a process. They're grading whether the process you name would survive contact with an actual sprint.

Let's learn

Harrow's scan-triage feature reads incoming radiology images and flags the ones a radiologist should read first, instead of working strictly in the order they arrived.

Before any formal process existed, a feature moved from PRD to shipped code in about six weeks, and legal reviewed it once, right before launch, as a final gate. That review took roughly eighteen days on its own, because it was the first time legal had seen the feature at all.

Now, the turn: the eighteen-day final review isn't really the cost. The real cost is that by the time legal sees the feature, the design is finished, the engineers have moved to the next sprint, and every legal fix means unwinding work everyone considered done.

Three steps ran fine. The fourth one, legal arriving after the feature already shipped, was the one costing real weeks.

At its worst: a feature almost went out with no consent language at all for how flagged scans get used in future model training, caught only because a departing engineer mentioned it in an exit interview, five days before launch.

What I would leave alone: Harrow's internal analytics dashboard, the one only the product team uses, needs no legal flag at all. Nobody outside the company ever sees it, and no patient data flows through it in a new way. Not every feature carries the same weight.

The lesson: "bring legal in early" isn't a mindset you adopt. It's a field you add to a form, sitting in the one place every PM already has to fill something in.

Now here is the same thing as a story

The short version above is what you'd say defending this process to Harrow's engineering leads. Read this one for how the near miss actually happened.

Renata Sabbagh has run Harrow's triage product for three years. She can spot which features will need real legal thought almost on instinct, mostly because she's the one who has to explain the delay when a review runs long.

For most of that time, the process worked the way it had always worked: write the PRD, build the feature, ship it, and let legal have their one look right before launch. Nobody complained, because nobody had reason to yet.

Not every feature needed the same attention. Triage scoring sat in the corner that actually mattered.

The near miss came from a new hire, not a catastrophe. Jonas Petrik, three weeks into his job as Harrow's second in-house counsel, sat in on a launch readiness review and asked a simple question: why hadn't legal seen this feature until today, when it clearly touched how flagged scans get reused for model training.

The gap Jonas found on day 58 was the same kind of gap the new process now finds by day 2.

Nobody had a good answer. The honest one was that the process had simply never asked the question sooner, because asking it sooner had never been anyone's job.

The fix wasn't a new meeting. It was one box added to a form every PM already filled out.

Renata built the intake flag over the following sprint, with Jonas writing the four things a lightweight triage actually checks.

Four specific things to check, not a vague instruction to "think about compliance."

The next feature through the door, a change to how flagged scans feed back into model retraining, hit the flag on day one. Jonas's triage found the exact same kind of consent gap the exit interview had surfaced months earlier, this time on day two, with three months of runway still ahead of it.

Two days of triage, folded into a total that still finished five days faster than the old process ever did.

The old process asked engineers to build first and hope legal agreed later. The new one asks a sharp, narrow question in week one, and only escalates to a full review when that question turns up something real.

I designed the original process around one review because that's what fit a team shipping one feature a year. I never went back and asked what should change once we were shipping four times as often, and it took a new hire's plain question, the kind nobody senior had thought to ask in a while, to see it.

SPARK, the intake flag in one screenNot a policy memo. SPARK is what forces the anchor to survive its own risk before you ship it.

The recap, one line per letter: situation is the single late gate before launch, payoff is flagging sensitivity the same day the one-pager is written, anchor is the checkbox routing to a 48-hour triage, risk is a rushed triage waving through a real problem, and keep out is holding off on a fully automated classifier.

And if you want to be sure it really works, try it somewhere elseSame five letters, an agricultural cooperative instead of a radiology company. This time the anchor isn't a checkbox at all.

Verdant Grain Cooperative uses an AI tool that recommends fertilizer blends to member farms based on soil sensor readings. Talia Osei manages that product, and her version of "bring legal in early" looks nothing like Harrow's.

The same branching test, run on a completely different kind of feature, sorts fertilizer recommendations and internal dashboards into very different lanes.

Situation: today, a new blend recommendation ships the moment the agronomy team signs off, with legal never in the loop unless a farmer complains about crop damage after the fact. Payoff: the habit Talia wants is the agronomy team routing any recommendation touching a new chemical combination through a standing legal contact before testing starts, not after. Anchor: a monthly quarter-hour call between the agronomy lead and legal, not a form field, since Verdant's small team moves faster through a standing conversation than a new tool. Risk: if the call becomes a formality, a genuinely new chemical combination slips through unreviewed, so the anchor includes a one-line written summary after every call, so skipping the substance would show up in writing. Keep out: a full legal sign-off on every blend variation, which would grind testing to a halt for changes that are really just ratio tweaks on an already-cleared combination.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "flag legal sensitivity at intake, triage in 48 hours, escalate only if it's real," and stop.
Cost: there's no headcount for a dedicated triage reviewer this quarter. Say so honestly, and start with a single standing contact who reviews flagged items as a fixed weekly slot, since even a slow but scheduled review beats an unscheduled one.
The model gets better, for real: if the triage system starts clearing everything without escalating anything, that's not a sign it's working, it's a sign the bar quietly dropped and needs a fresh look.

Where people run it wrong.
They treat "bring legal in early" as a value to state in a kickoff meeting instead of a field in the tool people actually use.
They build a full review that just happens to run earlier, which is still slow, only slow sooner.
They let the triage become a formality with no escalation criteria, so it clears everything and catches nothing.

How to use it live. When asked how to bring legal in early without slowing things down, don't answer with a meeting cadence. Answer with the one artifact everyone already touches, and where in that artifact the question gets asked.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0