In large companies, AI governance has a whole floor of people behind it. A data governance team classifies every table. A security team decides where data can travel. Privacy counsel sets retention windows. A risk team writes the policy, collects signatures and schedules the reviews, and internal audit comes back later to check that what happened matches what was written.
The small businesses I work with run on a different staffing model. A restoration contractor with twenty employees has one person holding every one of those roles, and that person also writes estimates, answers the phone after a water loss and signs payroll. When that owner starts using AI on business data, the same five questions apply as they do at a large company: what data the AI can see, where that data can go, who approves changes, how much the business will spend, and how anyone proves it all afterward.
A written policy answers those questions on paper, and the software reads none of it. Over a few months the document and the system drift apart. The gap stays invisible until someone asks where a customer's phone number went.
Managed governance is how we close that gap at Dr. Data. The policy lives as configuration inside the hub, the private platform we configure around each expert. The gateway enforces that configuration on every model call, and the same file generates the policy document the owner signs. The running system and the readable policy come from one source, so they match.
It starts with data classes. During the STZ session, the owner tells me which records are public, which run the business, which name a person and which carry legal or contractual duties. Those answers become four classes: public, internal, confidential and restricted. Every source, page, field and record carries its class from the moment it is ingested. A request that touches several records takes the highest class among them, and anything unclassified is treated as confidential until the owner confirms it in review.
Routing follows the class. Confidential records stay on the client's own model host. Restricted fields reach the code that needs them and reach a model only as a mask, so an account number becomes a token before any prompt is assembled. Internal records can go to a shared, stateless GPU pool, and to the client's own frontier provider as short excerpts with the owner's approval. Every call writes a row to the decision log with its class, lane, model, version, redaction count and outcome. When no allowed lane is available, the call is blocked and the log records the reason.
The policy document carries the SHA-256 hash of the configuration that produced it. The owner signs that document, and the signature is stored with the hash. If anyone edits the configuration afterward, the hash changes, the policy page shows the change, and the outside AI lanes pause until the owner reviews and signs again. Local work keeps running the whole time, so the business keeps moving while the review happens.
The owner also holds a kill switch. One control stops scheduled jobs and every model call across the deployment, keeps the records readable, and logs who turned it on and why. Turning it back on takes a stated reason, and that reason goes into the record as well.
The managed part matters as much as the configuration, because governance is a practice. Each month I review the decision log and the telemetry with the owner: calls per class and lane, blocked calls by reason, masked fields, spend against the ceiling, records still waiting for a class, and the accuracy of extracted fields against the golden set. Telemetry carries counts and states. Document text, field values, prompts and names stay inside the client's deployment.
When the business changes, the policy changes with it. Say an electrical contractor wants the provider lane to draft internal quotes. That change is written into the configuration, checked by the validator against a hard floor that keeps restricted data away from every model, regenerated as a new policy document and signed. A tighter rule takes effect right away. A looser one needs a stated reason and the owner's signature.
MSPs bring their own AI policy into the same structure. They write it once, I translate it into configuration, and the hub enforces it on every client deployment they host, with one view of policy state across all of them.
Last year I wrote that trust in a model depends on explanation. Governance works the same way. An owner can trust AI on business data when each answer traces back to its sources, each call traces back to a rule, and that rule traces back to a signed policy. Managed governance gives a twenty-person company that trail, and the monthly review keeps it current as the business grows.
Common questions
What should an AI governance policy for a small business include?
It answers five questions: what data AI can see, where that data can go, who approves changes, how much the business will spend, and how anyone proves it afterward. In managed governance, each answer becomes a configuration setting the system enforces on every model call.
How do you classify data for AI use?
Use four classes: public, internal, confidential, and restricted. Every source, page, field, and record carries its class from ingestion, a request takes the highest class among the records it touches, and unclassified data is treated as confidential until the owner confirms it.
What is an AI kill switch?
One control that stops scheduled jobs and every model call across a deployment, keeps the records readable, and logs who turned it on and why. Turning it back on takes a stated reason, which also goes into the record.
Related reading
- Why Every Managed Intelligence Platform Needs a Decision Science Layer
- Where Open-Weight Models Fit When the Expert's Rules Make the Decision
- How Milwaukee's Public and Private Sectors Are Putting AI to Work, and Why Shadow AI Is the Bigger Risk
- How to Choose a Private AI Partner
Want AI built for your actual job? Book a discovery call.