A policy in the shared drive is not governance. Governance is what actually happens the next time someone asks 'can we use this,' and whether the answer is the same person's call every time.
AI governance at small-team scale isn’t a document, it’s a habit built around four decisions: who approves a new AI use, what gets written down about that decision, how often the whole setup gets revisited, and when the question needs to leave the building and go to a lawyer. This piece gives you a delegation table sized to a solo founder, a twenty-person ops lead, and a department head with no legal support, a logging template already filled in, a review cadence with real triggers, and the specific legal thresholds (personal data at scale, regulated sectors, employment decisions, customer-facing scale) worth knowing before you hit one.
An operations lead at a twenty-person logistics company got a one-line Slack message from the founder on a Tuesday afternoon: “can we use this for customer emails,” with a link to a new AI writing tool. She checked the shared drive for the company’s AI policy. It existed, two pages, written eight months earlier during the week everyone agreed AI mattered. It said employees should use AI responsibly and protect customer data. It didn’t say who got to approve a new tool, what she was supposed to write down if she said yes, or when anyone would check back in. She said yes anyway, because someone had to answer, and moved on with her day.
That’s not really a story about a bad policy. The policy was fine, as policies go. It’s a story about what happens to any document once the meeting that produced it ends: it stops moving. The real governance in that story isn’t the two pages in the drive, it’s what the ops lead actually did at 2:14pm on a Tuesday, and whether the next ten people who get a similar message make a similar call or ten different ones, depending on who they happen to ask.
Most of what gets written about “AI governance” describes a document: a policy, a charter, a set of principles a committee signs off on once. If you need that document, our guide to writing an AI acceptable use policy covers how to build one well, and it’s worth having. But the document is the easy part. What happens after it’s written is the part that either survives past month one or quietly stops, and it’s the part almost nothing gets written about for a team that doesn’t have a compliance department to run it.
| Moment | The document version | The habit version |
|---|---|---|
| A new AI tool shows up | Nobody’s sure who to ask, so people just start using it | One named person gets asked, every time, before it goes live |
| What gets written down | Nothing, or everything, depending on who remembers | The same few facts, in the same place, every time |
| Six months later | The policy sits in the drive, unread since the day it was written | Someone has actually looked at what changed and updated it |
The difference isn’t how good the document is. It’s whether anything happens after it’s written.
The rest of this piece is about the habit, not the document: the four decisions that make it up, sized for a team that has an operations lead and maybe a lawyer on retainer for contracts, not a governance committee that meets monthly.
Strip away the frameworks, the maturity models and the slide decks, and AI governance at small-team scale comes down to four recurring decisions. Almost every real question you’ll actually face is a version of one of these, and if you can answer all four in a sentence each, you don’t need anything more elaborate than this.
The rest of this guide is one section per decision.
Notice what’s not on that list. There’s no governance board, no quarterly all-hands presentation, no maturity score out of five. Those things exist for organisations large enough that no single person could plausibly know every AI use across every team, which is a real problem at that scale and not one a ten-person company actually has. The failure mode at small-team scale isn’t too little process, it’s borrowing enterprise process that nobody has the headcount to run, giving up on it within a quarter, and concluding that governance itself doesn’t work.
Each of these four decisions needs an owner, which sounds obvious until you watch how often it doesn’t happen. A tool gets approved in a Slack thread with three people reacting with a thumbs up, which means it was approved by everyone and by no one. Six months later, when someone asks why the tool was ever allowed to touch customer data, the thread has scrolled into the archive and nobody remembers agreeing to anything specific.
Every one of these four decisions gets one name attached to it, not a committee nobody can pin down.
That doesn’t mean one person makes every decision alone forever, and the next section is about exactly how that authority should be shared out as a team grows past the size where the founder can plausibly answer everything themselves.
The instinct at a five-person company is to let everyone decide for themselves, because asking permission feels like exactly the kind of bureaucracy AI was supposed to help you avoid. The instinct at a twenty-person company is the opposite: route everything through the founder, since nobody else has been formally handed the authority. Both break in about the same amount of time. The first produces five different answers to the same question. The second turns the founder into the bottleneck for every new AI tool anyone wants to try, stacked on top of everything else they already own.
What actually holds up is matching who approves to what’s at stake, not to where someone sits on an org chart. A tool that drafts internal meeting notes and a tool that screens job applicants are not the same decision, and treating them identically is how a five-minute yes and a decision that needs real scrutiny end up taking exactly as long as each other.
| Team shape | Low-risk internal tools | Anything customer-facing, or touching people’s data |
|---|---|---|
| Solo founder, under 5 people | You approve it, but write down the yes | Same, plus give yourself 24 hours before saying yes |
| Ops lead at a ~20-person company | Ops lead approves directly, logs it | Ops lead and founder sign off together, before launch, not after |
| Department head, larger org, no dedicated AI or legal function | Department head approves within their own team | Escalates outside the department to whoever owns company-wide risk, even if that’s just the CEO |
A worked example. Swap in your own team’s actual shape and names, keep the two-column logic: low-stakes stays close to the work, anything customer-facing or people-data-related goes up a level.
The advice really does change by role, and it’s worth being specific about that rather than talking about “the team” as one undifferentiated group. A solo founder is, by necessity, the only approver there is, and the actual job is building the habit of pausing before saying yes to anything customer-facing, since there’s no one else to catch a bad call. An operations lead at a twenty-person company usually becomes the default approver for internal tools and the router for anything reaching customers, employee data, or money, sending those upward rather than deciding alone. A department head inside a larger organisation that still has no dedicated legal or AI governance function typically owns approvals for their own team’s day-to-day tools, but doesn’t have the authority, or the visibility across other departments, to sign off on anything touching regulated data or company-wide risk, and pretending otherwise is where this usually goes wrong.
Three questions are worth asking before anyone assumes a decision is theirs to make solo, whatever their title:
A yes to any of those moves the decision up a level, regardless of how the org chart is drawn. That’s a cheaper rule to apply consistently than trying to maintain a full risk taxonomy nobody has time to keep updated.
Ask five small teams what they log about their AI use and you’ll get five different answers, and most of them are either “nothing” or “everything.” Neither works. Logging nothing means the day someone asks why a tool was ever allowed near customer data, there’s no record of who approved it or what they were told about it at the time. Logging everything means a spreadsheet nobody opens, because scrolling through forty rows to find the one that matters defeats the entire purpose of writing it down in the first place.
The right amount of detail is whatever you’d actually want in front of you if the same question came up again in six months, and not much more. In practice that’s four fields, filled in at the moment a tool is approved, not reconstructed later from memory.
| Field | Filled-in example |
|---|---|
| Tool and what it’s for | Otter.ai, transcribing internal sales calls |
| Who approved it, and when | Approved by the ops lead, 12 March 2026 |
| What data it touches | Call audio and transcripts only. No customer data beyond names already shared on the call |
| What would trigger a re-review | Any plan to use it on customer-facing calls, or any change to the vendor’s data-retention terms |
Four rows, filled in once, at the moment of approval. Not a risk score, not a justification essay, not a template left blank for someone to fill in “later.”
Notice what isn’t on that list: a lengthy justification, a risk score, or a rating out of ten. Those feel thorough and mostly measure how good someone is at writing justifications, not whether the tool is actually safe. The four rows above are what you’d genuinely want in front of you if someone asked, eight months from now, “wait, why do we have a transcription tool listening in on sales calls.”
Some small teams try to have AI itself help maintain this log, drafting the plain-English description of what a new tool does, or summarising a vendor’s data-retention terms so nobody has to read twenty pages of legal language before a five-minute approval decision. That’s a genuinely useful shortcut, as long as the split between what the tool drafts and what a person still owns stays explicit rather than assumed.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Drafts a plain-English summary of what a new tool does and what data it touches, pulled from the vendor’s terms of service | Deciding whether that summary is accurate enough to approve on, and whether the vendor’s own claims hold up | The approver reads the vendor’s actual data-retention clause once, not just the AI summary, before the first approval |
| Drafts the first version of the log entry from the approver’s own Slack message or email | Confirming the entry is accurate before it’s saved as the record | One log entry spot-checked against reality every quarter, by whoever owns the review |
A worked example, not a universal rule. The right-hand column changes with the task; what doesn’t change is that something on it stays a person’s job.
If you can’t find why an AI decision was made in ten seconds, you didn’t log it, you buried it.
A log that takes longer than ten seconds to search isn’t doing its job, whatever format it’s in. That’s a better test than counting rows or measuring how detailed each entry looks.
Ask when to review an AI policy and the honest answer sounds unsatisfying at first: it depends on how fast the team is actually changing, not how much time has passed on a calendar. A team that hasn’t added a new AI tool in four months and hasn’t hired anyone doesn’t need a quarterly ceremony to feel busy. A team that’s added three new tools since the last look, or just hired its first dedicated marketing or HR person, needs to look again regardless of what the calendar says.
Even so, a fixed floor matters more than a perfectly tuned trigger system, because the real failure mode isn’t reviewing too often. It’s not reviewing at all, which is exactly what happened to the two-page policy that opened this piece.
| Cadence | What happens | Who does it |
|---|---|---|
| Quarterly, light | Check the log against what’s actually in use. Anything approved that shouldn’t have been, or anything in use that was never logged at all | Whoever owns approvals |
| Twice a year, full | Reread the policy itself line by line. Does it still match how the team actually works now, not eight months ago | The approver, plus whoever they report to |
| Immediately, regardless of the calendar | A new tool touches customer or employee data for the first time; the team crosses a size or regulatory threshold; a customer or employee actually raises a concern about an AI-generated decision or output | Whoever is closest to the trigger, escalated up the same day |
A floor of two real reviews a year, plus a short list of events that don’t wait for the calendar.
None of that tells you whether the habit is actually working, though, and that’s a different question from whether a review technically happened on schedule. Three things are worth checking, in this order. Use: is anyone actually asking before a new tool goes live, or has that quietly stopped happening without anyone deciding it should? Persistence: is the log still being filled in during month four the same way it was in month one, without someone having to be reminded? Impact: has the process ever actually caught something, stopped a bad rollout, caught a data-handling mistake before a customer saw it, or changed which tool got the green light? A policy nobody has broken yet might mean the process genuinely works. It might also mean nobody’s tested it yet.
A policy nobody has reopened in six months isn’t lean. It’s abandoned.
Lean and abandoned look identical from the outside, which is exactly what makes this easy to miss until someone asks a question the policy was supposed to answer and gets silence instead.
Say a department head at a 300-person company, with no in-house legal team and no dedicated AI governance function, is under pressure to speed up hiring for a role that’s drawing 400 applications. They start using an AI tool to screen incoming resumes, filtering out anything that doesn’t match a rough set of keywords before a person even looks at the pile. It’s not a reckless decision. It saves the recruiting team real hours every week, and every application that survives the filter still gets read by a human. Nobody in the room realises that using software to substantially narrow an applicant pool before human review is exactly the kind of automated employment decision New York City’s Local Law 144 was written to catch, and if any of those roles are based in the city, the tool now needs an independent bias audit and candidate notice before it can keep running.[2]
That’s the shape of a genuine legal threshold: not a vague sense that “AI in HR feels risky,” but a specific, named requirement that already applies to what you’re doing, whether or not anyone told you at the time. This is the point where the delegation table and the logging habit stop being enough on their own, and the honest move is to get a lawyer to look at the specific use case, not to write your own interpretation of the rule and hope it holds up.
A handful of situations are worth naming plainly, because they come up often enough that recognising them early is worth more than a long checklist:
| Situation | Genuine threshold? | What that usually means |
|---|---|---|
| Using AI to draft internal marketing copy or meeting notes | No | Your normal approval and logging process covers it |
| Using AI to screen, score, or rank job applicants | Yes | Bias audit and notice requirements may already apply, depending on where the role is based |
| Using AI on data that includes health, financial, or government ID information | Yes | Sector-specific rules likely apply on top of general privacy obligations |
| Using AI to draft customer support replies, with a human reviewing before sending | Usually no, if the review is real | Still worth logging. Not on its own a reason to call a lawyer |
| Using AI to auto-send customer-facing messages at volume with no human review | Often yes, once something goes wrong at scale | Worth a lawyer’s view on liability and disclosure before scaling further |
A starting sort, not a substitute for advice on your specific facts. When a row says yes, that’s the point to stop guessing.
The federal picture on this has been unstable rather than absent, which makes “check what’s currently required” more useful than memorising a rule that might not hold. In early 2025, the EEOC removed the technical guidance it had published on assessing AI tools for discriminatory impact under Title VII. The guidance disappeared, but the underlying law didn’t: Title VII, the ADA and the ADEA still prohibit discriminatory outcomes, whether the discrimination came from a manager’s judgment or a vendor’s algorithm, and several states have been moving into the gap the federal government left, with Colorado and Illinois both passing their own AI employment rules that take effect in 2026.[3]
Team size doesn’t buy an exemption either, and it’s tempting to assume otherwise. The EU AI Act is explicit that it doesn’t carve out an exception based on company size: a five-person company deploying an AI system that reaches EU users falls under the same categories of obligation as a 5,000-person one, even though the Act does build in real relief for smaller companies once you’re in scope, like simplified documentation and lower fine caps.[4] For what’s actually required and by when, our EU AI Act guide covers the detail; the point that matters here is narrower: don’t assume you’re exempt just because you’re small.
The law doesn’t ask how many people are on your team before deciding whether it applies to what you built.
None of this is legal advice, and nothing in this article should be read as a substitute for a lawyer looking at your specific situation. What it can do is help you tell the difference between “we should probably think about this” and “this needs a lawyer this week,” so a small team spends its limited legal budget on the handful of moments that genuinely call for it, instead of either ignoring every warning sign or paying a lawyer to review every new tool that comes through the door.
If none of this exists at your company yet, don’t try to stand up all four decisions this week. Pick the one your team already gets wrong the most, which is usually who approves, since silence defaults to everyone deciding for themselves. Write the answer down in one sentence today. Add the logging habit next month. Put a first review date on the calendar before you close this tab. That’s the whole starting move, and it costs less than the meeting it took to write the policy nobody’s reopened since.
AI governance is the set of habits that decide who can turn on a new AI tool, what gets written down about that decision, and how often the whole setup gets checked. A small company needs a version of it, just not the enterprise version: skip the governance board and the maturity scorecard, and keep the four decisions (who approves, what’s logged, how often it’s reviewed, when to call a lawyer), sized to a team that might be five people or two hundred.
Match the approver to what’s at stake rather than to a title. Low-risk internal tools can be approved by whoever owns that part of the work, an ops lead or a department head, and logged. Anything touching customer data, employee data, or a real employment decision should move up a level, to the founder or whoever owns company-wide risk, before it goes live rather than after.
Four fields are usually enough: what the tool is and what it’s for, who approved it and when, what data it actually touches, and what would trigger a re-review. If it takes longer than ten seconds to find why a specific AI decision was made, the log isn’t detailed, it’s just been buried under detail that doesn’t matter.
Set a floor of two real reviews a year, where someone actually rereads the policy line by line against how the team currently works, plus a lighter quarterly check of the log itself. On top of that floor, a few events should trigger an immediate look regardless of the calendar: a new tool touching customer or employee data for the first time, a jump in team size, or an actual complaint about an AI-generated decision.
When the situation crosses a genuine legal threshold rather than a judgment call: AI used to screen or score job candidates, AI touching health, financial or government ID data at scale, anything in a regulated sector, or anything customer-facing at a volume where a mistake would reach many people before a human caught it. Team size doesn’t exempt you from any of these, and the EU AI Act in particular is explicit that its obligations apply regardless of company size.
The four-decisions framework, the delegation model and the logging template are Future Factors’ own synthesis, built for this piece from teaching AI adoption and governance across corporate workshops, and presented as practical judgment tools rather than as research findings. All four regulatory and statistical claims cited were checked directly against primary sources on 4 September 2026: the small-business AI adoption figure against the U.S. Chamber of Commerce’s own 2025 report page (not a secondary blog, one of which had misquoted the adoption rate and attributed an unrelated 77% figure to a nonexistent ‘no policy’ finding), the NYC Local Law 144 details against the Department of Consumer and Worker Protection’s own FAQ PDF, the EEOC guidance-removal claim against a law firm alert describing the change directly, and the EU AI Act’s size-neutral scope against an independent, citation-linked explainer of the Act’s actual articles. This is not legal advice; where a genuine legal threshold is described, the recommendation is to consult a lawyer about your specific facts, not to apply this article’s general categories as a ruling on your situation.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.