What is the right level of central control versus team autonomy for AI tooling?
Interviewer's question: "What is the right level of central control versus team autonomy for AI tooling?" Farrah Lindqvist runs the internal platform team at Northgate Home Health, a company with fourteen regional branches, each building its own AI note-drafting and scheduling workflows on top of tools her team maintains.
- Centralize model access, patient-data flow, and the pass bar before anything ships.Why: this is the layer where a mistake stays invisible until an audit finds it, and by then real patient data is already out.
- Leave prompt wording and day-to-day workflow choices to the branch doing the work.Why: the branch sees the real cases first, and forcing every wording choice through a central desk buys nothing but delay.
- Give every branch a fast, named path for a workflow-only change, not a queue with no owner.Why: a slow official path is exactly what pushes a good employee to build her own path around it.
- Read any unsanctioned tool use as a speed problem in the official path, not a discipline problem in the person.Why: the branch that went around the rules was usually the one that cared most about getting the job done.
- Track the platform team's own answer time as a health metric, not just model accuracy.Why: a rising wait time is the early warning that autonomy is about to happen with or without a rule against it.
- Push sign-off authority down only when the central queue itself becomes the slow, costly part.Why: that is the one piece of real evidence that should flip the balance, not a complaint from a single branch.
How to answer this, stage by stage
Nobody is grading whether you can define "governance." They're grading whether you can commit to one pick and then say exactly what it costs the side you didn't choose.
Let's learn
Before any of this, Farrah Lindqvist's forty field nurses wrote every visit note by hand on a clipboard, then typed it up between houses, about forty-five minutes a day per nurse, on top of the actual visits.
Northgate built a shared AI tool that listens to a visit and drafts the note, findings, care given, next steps, for the nurse to check and sign. Each of the fourteen branches customizes it a little: which fields show first, which phrases it drafts in, small workflow choices that make sense branch by branch.
Drafting time dropped to about twelve minutes a note. That part worked. The real trouble showed up somewhere nobody was measuring at all.
The turn: the extra mistakes were never the problem. The AI drafts were fine. The real cost showed up because one branch, tired of waiting on a small field change, found its own way to get the field it needed, and that way ran real patient details through a tool with no data agreement behind it at all.
At its worst: months of real patient identifiers sit inside a personal AI account with no contract behind it, invisible on any Northgate dashboard, until a routine annual security review notices an unusual outbound domain in a log sample and has to explain it to a compliance officer.
What I would leave alone: exactly which field order or phrasing a branch's tool uses day to day. That's real, harmless variation, and forcing every branch to use identical wording just adds friction for no safety gain at all.
The lesson: the real question was never "who owns the AI." It was "which mistake stays invisible until it's expensive," and that's the only line worth drawing hard.
Now here is the same thing as a story
The short version above is what you'd say to Northgate's leadership team. Read this one for how the actual gap got found.
Farrah Lindqvist can read a two-line visit note and tell exactly which nurse wrote it, a skill left over from years doing the job herself before she moved into building the tools.
The first year of the shared AI tool went well. Adoption was strong across all fourteen branches. Farrah's small platform team handled feature requests as they came in, and for a while, a few days each, that was fine.
Then the western branch asked for one thing: a wound-care checklist field their state's home-health regulator required, one their tool didn't draft yet. Two weeks passed with no answer. Then five. By week nine, still nothing, because the request sat in a shared queue with nine other tickets and no name attached to any of them.
One of the western branch's home-health aides, a woman who documented faster and more carefully than almost anyone on the team, wasn't going to let a missing checklist field slow down her visits. She started typing full patient visit summaries into a free consumer AI chatbot on her own phone, getting the wound-care language drafted in seconds, then copying it into the official system.
Nobody caught it for months. It surfaced during Northgate's routine annual security review, when an analyst noticed a personal AI vendor's domain showing up in outbound traffic logs from a branch device, and had to trace it all the way back to real patient names sitting in an account with no data agreement at all.
Farrah put the queue's own answer time on a wall dashboard next to the model accuracy numbers everyone already tracked. She kept the hard line where it belonged: model access, patient-data flow, and the pass bar before anything ships stay with her team, full stop. But she added one new lane: a workflow-only request, no new vendor, no new data path, gets a named on-call engineer and an answer within three business days.
Run the same nine weeks forward under the new design. The western branch's next request, a different checklist field for a new state requirement, gets a real answer in two days. The aide never opens a consumer chatbot on her own phone, because she never needed to.
Farrah had built the queue as one shared thing back when Northgate had three branches and every request really did get answered fast. Nobody redesigned it on purpose as the company grew to fourteen. It just kept being the queue, the same reasonable choice quietly stopped being reasonable.
PICK, in one screenNot a governance policy. PICK is what turns a control-versus-autonomy question into one line you can actually defend.
The recap, one line per letter: position is centralize the risk layer and free the workflow layer, impact is naming who feels a slow queue against who feels a hidden leak, cost asymmetry is choosing the hidden one to optimize against, and kill criteria is the platform team's own answer time crossing three weeks for two quarters.
And if you want to be sure it really works, try it somewhere elseSame four letters, a volunteer fire department network instead of a home-health company. Nothing else about the two jobs is alike.
Ashgrove Volunteer Fire Alliance shares an AI tool across nine independent volunteer departments that drafts incident reports from radio traffic and dispatch notes.
Mapped onto PICK: position centralizes the shared incident-classification taxonomy and any mutual-aid data sharing between departments, leaves each department's own radio codes and reporting habits to that department. Impact names who feels each error: over-centralize, and a department waits on a shared committee to approve a wording change nobody else even uses. Over-autonomize, and one department starts sharing raw incident data with a neighboring county over an unapproved channel, with no record of what left the building. Cost asymmetry: the wait is visible, the data-sharing gap is invisible until a state auditor asks who has access to what. Kill criteria: if the shared taxonomy committee's own answer time starts running past a full burn cycle, some of that authority moves down to regional leads instead.
Swap the trigger and it still runs.
Speed: an interviewer caps you at thirty seconds. Say "centralize the layer where a mistake hides until it's expensive, free everything else, and watch the queue's own answer time," and stop.
Cost: if there's no budget for a dedicated fast lane engineer, rotate the on-call duty across the existing platform team instead of dropping the SLA, since a slower promise kept beats a fast promise broken.
The model gets better, for real: if the shared AI tool gets more accurate, this design still matters, because a better model makes the temptation to skip the pass bar for a "surely fine" workaround even stronger, not weaker.
Where people run it wrong.
They centralize everything, including harmless workflow choices, and then act surprised when people route around the whole system.
They treat a workaround as a discipline problem and write a policy memo, instead of asking why the official path was too slow to use.
They never put the platform team's own answer time on a dashboard, so the early warning sign is invisible until the real incident happens.
How to use it live. When someone asks you where to draw the control line, ask yourself one question first: which mistake on this list stays invisible until it's expensive. Draw the line around that one, and free everything else.
Flashcards (tap any card to flip it)
Check yourself Score: 0 / 0
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
"What if the platform team just says no to every workaround, instead of building a fast lane?" Response: saying no without fixing the underlying wait doesn't remove the pressure, it just makes the next workaround harder to see coming, because the person who tried to ask first stops asking.
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
- A live AI agent you actually shipped
- A launch decision you can defend under pressure
- An interview-ready portfolio, not more flashcards
More on Internal AI tooling and enablement products
- #1 Why do companies underinvest in internal AI tooling, and what does it cost them?
- #2 Describe the first internal AI tool you would build at a 500-person company.
- #3 How do you measure adoption of an internal AI tool?
- #4 What is different about PMing for internal users who cannot churn?
- #5 Design an internal prompt library and explain who maintains it.
- #6 How would you build an internal eval platform that other teams actually use?