AI governance for mid-size companies without a compliance team

An AI governance framework for a mid-size company is five decisions written on two pages: what staff and systems may use AI for and what they may not; how data is classified and which classes may reach which models; which actions an AI system may take on its own and which need a person; what is logged for every automated decision; and who owns each system and the policy itself. That is enough to satisfy most customers, auditors and boards, and it is achievable without a compliance department. This article sets out each decision, gives the checklist we use with clients in AI product strategy engagements, and explains how the policy is enforced in the systems rather than filed in a drawer.

Why an AI governance framework matters before the first system

Governance is often postponed until a regulator or a large customer asks for it, at which point it is written in a hurry and bolted onto systems that were not designed for it. Doing it first is cheaper for three reasons. The data classification tells engineers which models a use case may use before they build it. The action approval rules shape the design of every agent, because a policy gate is easier to build in than to retrofit. And the logging requirement determines the audit trail, which is expensive to add to a system in production. A two-page policy written before the first build saves weeks on every subsequent one.

The five parts of a responsible AI policy

Use policy: the page staff actually read

The use policy answers the questions employees have: may I paste customer data into a public assistant, may I use AI to draft a contract, must I tell a customer that a reply was generated. The answers should be short and specific. Public assistants may be used for non-sensitive work; customer and financial data goes only into the company's approved tools; AI-drafted external communications are reviewed by a person; customers are told when they are talking to a system. For products the company builds, the policy states which uses are in scope and which are prohibited, such as decisions about individuals without review. Keep it to one page and revisit it when the tools change.

Data classification: the decision that shapes architecture

Three or four classes are enough: public, internal, confidential and, in regulated sectors, restricted. Each class maps to permitted destinations: public and internal data may use approved public model APIs; confidential data uses private or contractually covered models; restricted data never leaves the boundary. Engineers then build the routing layer to those rules, so the policy is enforced in code rather than in training slides. Data protection law adds obligations on purpose and retention; the DPDP Act and AI article covers what Indian companies must do, and the zero data egress design is what the restricted class usually requires.

Approval for autonomous actions

This is the part that matters most for agents. List the actions any AI system might take: send a message, update a record, issue a refund, change a booking, approve an application. For each, decide whether the system may act alone, must queue for a person, or is prohibited, and set limits where useful, such as a refund ceiling. The rule is enforced by a policy gate that checks every action before it executes and logs the result. Autonomy is expanded per action as shadow-mode evidence accumulates, never by default. The mechanics are in policy-gated actions. Our own stance, shadow mode before autonomy and policy-gated actions in every agent, is the engineering form of this decision.

Logging and the named owner

Logging is a sentence in the policy and a component in the system: every automated decision records input, context, model and prompt version, output, checks, action and any human review, in a store that cannot be edited, for a retention period set by the governing regulation. The AI audit trail article lists the fields. Ownership is the sentence most often missing: each system has a named owner who runs its weekly review and answers for its behaviour, and the policy has an owner, usually a COO, CTO or head of operations, who reviews it quarterly and whenever a system is added. Without the names, the rest is decoration.

AI risk management for an SMB: keeping it proportionate

Frameworks such as the NIST AI Risk Management Framework and ISO's AI management system standard are written for organisations of any size, and they are useful as a checklist of what a mature programme covers. A mid-size company should borrow their structure and skip their ceremony. A single risk register with one line per system, listing what could go wrong, how it would be detected and what the response is, does the job of a risk committee. A quarterly review of that register with the system owners is the governance meeting. When a customer's procurement team sends a questionnaire, the two pages and the register answer most of it.

What to do when a large customer asks for more

Enterprise customers increasingly ask suppliers for an AI policy, evidence of data handling and sometimes a certification. The two-page policy, the classification, the audit trail and the risk register usually satisfy the first two. If a certification is required, the policy is the starting point for it, and the systems already have the controls the auditor will test.

A worked example

A direct-to-consumer brand with a small operations team wanted a WhatsApp agent that could answer order questions, recommend products and process simple returns. It had no compliance function and no AI policy. In a one-day session we wrote the two pages: staff could use public assistants for marketing drafts but not for customer data; customer data was confidential and went only to models under contract inside the agent; the agent could answer questions and recommend products alone, could initiate a return below a value threshold, and had to queue anything else for a person; every conversation and action was logged with a viewer for the operations lead; and the operations lead was named owner with a weekly review. The agent was built to those rules, and when a marketplace partner later asked for the brand's AI policy, it existed. The build is described in our personalisation and WhatsApp agent case study.

Team and timeline

Writing the framework takes a one-day workshop with the policy owner, an operations lead, someone from IT or security and whoever owns customer data, followed by a day of drafting. We run it as part of a Sprint Zero, ten working days at $3,250 or ₹2,00,000, credited to the next build, alongside the readiness check and the use-case ranking, or as a standalone two-day engagement. The controls the policy requires, routing by classification, policy gates, logging and the review dashboard, are built into every customer service agent and agent system we deliver, and the weekly review is supported under a Care Plan. Prices for programmes and plans are on the pricing page, and the policy and the controls are yours.

Before you start: a checklist

• A policy owner with authority, named before the workshop
• An inventory of AI tools staff already use, including unofficial ones
• A list of the data classes the business handles and where each lives
• Every action an AI system might take, listed with a proposed rule
• Retention requirements for logs from the governing regulations
• A named owner per existing or planned AI system
• A one-line risk entry per system: what could go wrong, how it is detected, what the response is
• A date for the first quarterly review

AI governance checklist: the two pages

• Use policy: permitted and prohibited uses for staff tools and built systems; disclosure rule for customers
• Data classification: three or four classes, each mapped to permitted model destinations
• Action approval: per action, autonomous, reviewed or prohibited, with limits
• Logging: fields per decision, retention, access roles, viewer
• Ownership: owner per system, owner of the policy, weekly and quarterly reviews
• Risk register: one line per system, reviewed quarterly
• Change control: prompts, models and policies changed only with an evaluation run and a recorded approver
• Incident response: who is told, what is switched off, and how customers are informed

Related reading

Sovereign AI in India: what it means for enterprises, why AI pilots never reach production, and how to choose an AI development company.

Five decisions, two pages and a named owner are enough governance for most mid-size companies, provided the decisions are built into the systems rather than filed beside them.