Data Governance for Machine Learning in Small Teams

Governance is a set of answers you can give quickly

The word governance makes small businesses picture committees, policies nobody reads and a consultant's invoice. For a team of five running two models, it should be none of those things.

Think of it instead as being able to answer a handful of questions quickly and truthfully. A customer asks why they were declined. A regulator asks what data trained your model. A new developer asks whether they can use the support tickets for a new classifier. The person who built the model left in March and nobody knows which spreadsheet it used. If those questions would cause a week of detective work, you have a governance gap, whatever your size.

The minimum record for each model

We suggest a single document, or a page in whatever wiki you use, with one entry per model. It should take under an hour to write and a few minutes to update.

1. Purpose. What the model predicts and what decision it informs.
2. Datasets used. Each source system and table, with the date range.
3. Owner. A named person responsible for the model and one for each key dataset.
4. Personal data. Which fields, the lawful basis, and whether a data protection impact assessment was done.
5. Training data version. Where the exact training dataset is stored.
6. Known limitations. Groups or situations where the model is less reliable.
7. Retention. How long training data and predictions are kept, and when they are deleted.
8. Review date. When someone will next check it still makes sense.

That is, in effect, a lightweight model card plus a dataset register. It is not glamorous, and it is the thing we most wish existed when we inherit someone else's model.

Ownership: the part that actually fails

Most governance failures in small teams are not missing policies. They are missing owners. The CRM data belongs to sales, the order data to finance, and the model that combines them belongs to whoever happened to build it.

Give each important dataset a named owner who is told before its structure changes and who decides who may use it. Give each model an owner who is accountable for its performance and for pulling it if something goes wrong. In a small business these may be the same two or three people. That is fine, as long as it is written down.

A dataset with no owner will change without warning, and the first to notice will be the model.

Lightweight versus formal: when to step up

Tooling such as data catalogues and model registries is useful at scale. For a small team, adopting it early mostly creates another system to keep in sync with reality.

Where regulation raises the bar

Data protection law already applies to any model using personal data. That means a lawful basis, transparency, minimisation, retention limits and, for automated decisions with significant effects on people, extra safeguards including the ability to get human review.

The EU AI Act adds specific data governance expectations for systems classed as high-risk, such as those used in recruitment, credit scoring, education and access to essential services. These cover the relevance and representativeness of training data, examination for possible bias, and documentation of data preparation. The obligations are phasing in over several years and the exact timetable has been subject to proposed adjustments, so check the current position for your use case rather than relying on a blog post. The practical point is that the lightweight record above becomes the foundation of what you would need anyway.

Our broader post on AI governance for mid-sized businesses covers policy and usage rules beyond data.

Habits that do most of the work

• Keep all pipeline and training code in version control, never only in notebooks on a laptop
• Never train on a live table; snapshot it first and keep the snapshot
• Keep modelling data separate from production systems, with named access
• Record a short note whenever a model is retrained or its data sources change
• Delete what you no longer need on a schedule, including old extracts on shared drives
• Put a recurring review in the calendar, twice a year is plenty for most

Old extracts are the risk people forget. The carefully governed warehouse is often fine; the CSV of customer data someone exported for a quick experiment two years ago is not.

How we set this up with clients

When SpiderHunts builds a model, the governance record is part of the handover, not an optional extra. We fill in the model card, set up versioned training data, restrict access to the modelling environment and walk the named owners through what they are responsible for. It usually adds a day or two to a project.

For data involving individuals, the design choices matter as much as the paperwork, which is why we pair this with the approaches in privacy-preserving machine learning. For organisations with higher regulatory exposure, our enterprise AI service includes fuller documentation and review processes.

Frequently asked questions