AI Governance for Teams Without a Compliance Department

AI governance sounds like something that happens in a bank, in a room with a policy binder and a person whose entire job title contains the word "risk." At a 20-person company there is no such room and no such person. There is a founder, a head of ops who also runs payroll, and eleven people who have already pasted something into a chatbot this week without asking anyone.

That is fine. AI governance at your size is not a program. It is five decisions, written down once, enforced mostly by defaults, and reviewed a few times a year. This article covers what to decide, how to fit it on one page, how to make the defaults do the enforcing, and how to tell when you have outgrown the lightweight approach.

What AI governance actually means at 20 people

Strip away the vocabulary and AI governance answers five questions:

1. Which AI tools are approved, and who can approve a new one.
2. What data is allowed into them, by class, not by vibes.
3. Which actions an AI may take without a human pressing a button.
4. What gets logged, and who can read the log.
5. When you review all of the above, and what triggers an off-cycle review.

That is the whole scope. Everything else in the discipline, model cards, red-teaming, bias audits, is either for people building models or for organizations under real regulatory pressure. You are neither.

The serious frameworks are worth knowing about even if you do not adopt them. The U.S. National Institute of Standards and Technology publishes the AI Risk Management Framework, and ISO/IEC 42001 is an international standard for AI management systems. Both assume more organizational machinery than you have. Treat them as a destination if you ever sell into enterprises or regulated industries, not as a starting point. Your starting point is a page in your team wiki.

The cost of skipping the exercise is rarely a headline. It is smaller and more annoying: a contract pasted into a consumer chatbot with training enabled, an automation that emailed forty customers before anyone reviewed the copy, a report quoting a revenue number nobody can trace back to a source. None of these are malice. They are the predictable result of nobody having made a decision.

Decision one: the approved tools list

Write the list. Keep it short. Publish it where people already look.

The instinct is to approve individual products, which means the list is stale in a month. Approve by category and data class instead, and name specific tools inside each category as examples rather than as an exhaustive whitelist:

Two things make this list survive contact with reality.

It has to be permissive enough to follow. A policy that approves one tool for one use case guarantees shadow AI. People use whatever is fastest to finish the task in front of them, and if the approved path is slower they route around it quietly, which is strictly worse than routing around it loudly. Approve generously in the low-risk categories and spend your strictness on the Restricted class.

It has to name an owner per category. Not a committee. One person who can say yes in a day. The failure mode at 20 people is not reckless approval, it is a request that sits unanswered for three weeks until someone gives up and uses the unapproved thing anyway.

The four questions to ask before approving a tool

When someone proposes a new tool, you need answers to four questions, and you should be able to find all four in public documentation without booking a sales call:

• Does it train on your data by default? Many vendors distinguish between consumer and business tiers here. The consumer tier of a familiar product is frequently not the same product from a data perspective.
• What is the retention window, and can you shorten or zero it?
• Are there admin controls? Can you see who is on the account, remove someone the day they leave, and enforce SSO?
• Where does the model key live? This one is underrated. If you supply your own provider key, your prompts run under your own account and your provider's terms, and you can revoke model access independently of revoking access to the application. That is a genuine governance lever, covered in more depth in Bring Your Own Key AI: What It Means for Cost and Control.

Skopx works this way: you connect your own Anthropic, OpenAI, Google, or other provider key, and Skopx never marks up the AI cost. From a governance standpoint the useful part is not the pricing, it is that the model relationship stays yours and stays revocable.

Decision two: data boundaries you can actually enforce

Three classes is the right number. Four is a taxonomy nobody remembers.

The important insight is in the right-hand column. The boundary you can enforce is at the connection, not at the keyboard. Telling people "do not paste contracts into chatbots" is a rule you cannot verify. Restricting which systems an AI tool can read from is a rule that enforces itself, because the tool cannot see what it is not connected to.

So configure it that way. When you connect a workspace tool to Slack, Google Drive, your CRM, or your database, connect the accounts and scopes you actually want in scope, not an admin account with visibility into everything. If your document store has a folder of signed contracts, keep that folder outside the connected scope and handle it deliberately.

Skopx connects to nearly 1,000 business tools, which means the connection decision is the governance decision. What you connect is what the AI can reason over. The integrations page lists what is available, but the discipline is the same regardless of vendor: connect narrowly, expand on request, and record why each connection exists.

On the vendor side, ask about encryption at rest and in transit, tenant isolation, and training. For Skopx specifically: AES-256 at rest, TLS 1.3 in transit, row-level isolation per organization, SOC 2 controls in place, and your data is never used to train a model. Ask every tool on your approved list the same questions and write the answers next to their name.

Decision three: approval rules are where AI governance gets real

Everything above is paperwork. This is the part that prevents actual incidents.

The question is not "can AI take actions" but "which actions, and what has to be true first." A four-level ladder covers almost every case at your size:

Write down which of your processes sit at which level. The rule of thumb that holds up: anything a customer will see, anything that moves money, and anything that is hard to undo stops at Level 1 or 2. Internal notifications, summaries, and read-only reporting can live at Level 3.

Skopx acts only with your approval, which puts it at Level 2 by default for anything it does on your behalf in chat. Its workflows, which you build by describing them in plain English rather than dragging boxes around a canvas, are the Level 3 mechanism: you approve the lane once, then the workflow runs on a manual trigger, a schedule with a 15 minute minimum interval, or a webhook.

In Skopx chat you would type:

Every weekday at 8am, check Stripe for payments that failed in the last 24 hours over $500, and post a summary to our #billing Slack channel with the customer name, amount, and failure reason.

What comes back is a built workflow: a scheduled trigger, a Stripe lookup step, a condition that filters on amount, a formatting step, and a Slack post. Each run is inspectable step by step, so when someone asks in September why the channel went quiet in August, you open the run history and see exactly which step failed and what it returned.

Notice the governance choice embedded in that sentence: it posts to an internal channel, it does not email the customer. That is deliberate, and it matches a real constraint worth knowing. Skopx workflows are acyclic, capped at 20 steps, and have no human-approval step. Steps are integration actions, AI steps that run on your own key, if/else conditions, and field transforms. There is no custom code step. So if a process needs a person to sign off mid-flight, the correct pattern is to have the workflow stop at a draft or a notification and let a human carry it forward. Do not simulate approval inside an automation that cannot pause. The workflows page covers the mechanics; the governance rule is that unpausable automation belongs only in lanes you have already approved.

Decision four: audit trails without an audit department

You need to be able to answer one question three months later: did an AI do this, and on whose instruction?

For a small team the trail comes from three places, and it helps to know which is which:

• The AI tool's own history. Chat transcripts, run logs, connection records. In Skopx, workflow runs are inspectable step by step, which is the layer that tells you what an automation actually did rather than what you assumed it did.
• The destination system. Slack shows who posted. Your CRM shows field history. Git shows the commit. These are often more durable than the AI tool's own logs, and they are the ones an outside party will trust.
• The output itself. This is the underrated one. Answers and documents that carry their sources are self-auditing: when a report says where each figure came from, verifying it is a click rather than an investigation. That property is the whole point of AI Document Generation: Reports, Proposals, and Specs That Cite Sources, and it applies equally to answers pulled from internal material, as covered in Company Knowledge Search: Finding the Answer, Not the Document.

Two habits cost nothing. First, label AI-assisted artifacts where provenance matters: commit messages, document footers, the ticket. Not for ceremony, but so that six months later nobody spends an afternoon reverse-engineering where a number came from. Second, keep a register of connections: which tool is connected to which system, under which account, approved by whom, on what date. A five-column table in your wiki is sufficient, and it is the first thing a serious customer's security questionnaire will ask about.

Decision five: a review cadence you will actually keep

Most small-team policies rot because the review is scheduled annually, which means it never happens. Shorten the loop and shrink the scope.

The weekly slot matters most and gets skipped most. It works best attached to something you already read. A daily brief that surfaces what changed and what is slipping across connected tools naturally covers automation output too, so reviewing anomalies becomes a byproduct of a routine you already have rather than a separate calendar item. That pattern is described in AI Morning Briefings: The Report Nobody Has to Write.

Add one item to your offboarding checklist today: revoke AI tool access and rotate any provider key the departing person had. This is the single most common gap in small-team AI governance, because AI tools are frequently adopted outside the normal provisioning path and therefore are not on the list that gets torn down.

The one-page AI governance policy

Here is the whole document. Fill in the brackets, publish it, link it from onboarding.

Approved tools. [Table by category, data class, and owner.] New tools require approval from the category owner. Approval takes one business day.

Data classes. Open, Internal, Restricted, defined as [your definitions]. Restricted data does not enter any AI tool without a written exception from [name], recorded in [location].

Actions. AI may read and draft freely. AI may execute actions only after a human approves them, except for the pre-approved automations listed in [location]. Anything customer-facing, financial, or irreversible requires a human to send.

Logging. Every AI tool connection is recorded in [the connection register]. Automation runs are inspectable. AI-assisted work products are labeled where provenance matters.

Review. Weekly anomaly check, monthly new-request review, quarterly full review. Offboarding revokes access and rotates keys.

Escalation. If something goes wrong, tell [name] the same day. Nobody is in trouble for reporting it.

That last line is not filler. The difference between a team that catches problems and one that discovers them in a customer email is almost entirely whether people expect to be punished for speaking up.

Where the lightweight approach stops working

Be honest about the ceiling, because pretending a one-page policy is a compliance program is its own risk.

This is governance, not security. It tells you what is allowed. It does not stop a compromised credential or a misconfigured share. Those are separate controls and you still need them.

Regulated data changes the calculus. If you handle data governed by a specific regime, or you are pursuing a certification because enterprise buyers demand it, you need a real framework, documented controls, and probably an auditor. A wiki page will not carry you through that procurement review.

Tooling has limits too, and vendors should say so. Skopx is an AI workspace: it answers questions across connected tools with citations, queries PostgreSQL, MySQL, and MongoDB in chat, generates documents, runs a morning brief, and automates bounded processes. It is not a governance and compliance system of record, not a BI or dashboard builder, and not a data warehouse. If you need a GRC platform, buy one. If you need dashboards, buy a BI tool. Skopx catches what falls between your tools, which is a different job.

And it is a paid product from day one. There is no free tier. Solo is $5 per month, Team is $16 per seat per month with no seat cap, and Enterprise and White Label are $5,000 per month. Current details are on the pricing page. Worth saying plainly in a governance article, because "we will evaluate it at no cost and decide later" is not a plan you can write policy around.

Frequently asked questions

Do we really need an AI governance policy at 20 people?

You need the five decisions. You do not need a program. The version that fits a 20-person company is one page and a quarterly hour. The reason to write it now rather than at 60 people is that habits form early, and retrofitting data boundaries onto tools eleven people already depend on is much harder than setting them on day one.

What is the absolute minimum viable AI governance policy?

Three lines: a short list of approved tools with an owner for each, a rule that Restricted data requires a written exception, and a rule that anything customer-facing or irreversible needs a human to press send. If you write nothing else, write those. Everything else in this article is refinement.

How do we stop people using unapproved AI tools?

Mostly by making the approved path faster. Shadow AI is a symptom of friction, not defiance. Approve generously in low-risk categories, answer new-tool requests within a day, and reserve enforcement energy for Restricted data, where you can enforce at the source system rather than by asking nicely. Then make it socially safe to say "I used X for this," because the tools you know about are the only ones you can govern.

Should we let AI take actions automatically at all?

Yes, in narrow lanes. A blanket prohibition pushes the work back onto people who will do it inconsistently, which is its own risk. The workable line: pre-approved, bounded, internal, reversible actions can run automatically, while customer-facing, financial, and irreversible ones stop at a draft. Check whether your tool can actually pause for approval mid-run. Skopx workflows cannot, so anything needing sign-off should end in a notification instead.

Does bringing our own API key change our governance posture?

It changes two things concretely. Your prompts run under your own account with your model provider, so their terms and retention settings apply, and you can revoke model access independently of revoking access to the application. It does not change what the application itself stores or who can see it, so you still ask the vendor about encryption, isolation, and training.

How often should we review this, honestly?

Weekly for anomalies, ten minutes, attached to something you already read. Monthly for new requests. Quarterly for the full list, including the connection register and offboarding. Plus an immediate review whenever a tool changes its data terms or a customer contract adds an AI clause. Annual-only review is how a policy quietly becomes fiction.