What a 30 to 200 person company has to inventory, document and restrict before customer data goes into a model, and when a no-training vendor API means you need far less.

Most AI data governance advice is written for banks with a chief data officer. A 60-person SaaS company does not need a governance committee, a catalogue platform or a 40-page policy. It needs answers to five questions that an enterprise customer, an auditor or a privacy regulator will eventually ask: what data went in, where did it come from, were people told, who can get it back out, and how long do you keep it.
The cost of not answering is real. IBM's 2026 Cost of a Data Breach report found that roughly one in five organizations reported a breach of an AI model or application, up from 13% a year earlier, and 92% of those lacked proper AI access controls. Only 40% of organizations said they use access controls on AI models and data. This guide sets out the minimum we recommend before customer data goes anywhere near a model.
It depends on what you do with the data, not on which model you use. Here is how we scope it, and where we disagree with vendors who sell one platform to every tier.
Your AI use | Minimum governance | Do you need a catalogue or AI governance platform? |
|---|---|---|
Calling a vendor API that does not train on inputs | Data classification rule, acceptable-use policy, vendor contract review | No. A spreadsheet and a contract checklist are enough |
RAG over internal or customer documents | Inventory, permission-aware retrieval, logging of what was retrieved | No. Fix permissions in the source systems first |
Fine-tuning a hosted model on customer data | Inventory, lineage, purpose check, datasheet, retention rule, deletion plan | Rarely. Under about 20 datasets, a versioned repo does the job |
Training your own model | Everything above plus model cards, bias testing, reproducible pipelines | Possibly, once several teams share data |
Any model that makes or shapes decisions about people (credit, hiring, pricing, access) | Everything above plus impact assessment and human review | Your obligations come from law, not tooling; see the purpose section |
The opinion embedded in that table: buying software before you have an inventory produces a well-indexed list of unknowns.
A common gap we see in AI readiness assessments is simple. Nobody can say which datasets fed which model version. Engineering knows the pipeline, product knows the feature, legal knows the privacy notice, and nothing joins the three.
Fix that with one table, owned by one named person (usually the head of engineering or data), with a row per dataset and these columns: dataset name, system of origin, whether it holds personal information, the purpose stated to customers when it was collected, which models or indexes use it, who can read it, and its retention rule. For most companies under 200 people this is 10 to 40 rows. If it takes longer than a working session, that is itself a finding.
Include support tickets, call transcripts, analytics events and the shared drive your RAG index crawls. Also the prompts and outputs your own staff send to AI tools, which is where shadow AI exposure usually starts.
ISO/IEC 42001:2023, the AI management system standard published in December 2023, groups its data controls under Annex A.7 "Data for AI systems". In plain terms, A.7.2 to A.7.6 ask you to define and document data management for AI development, how data is acquired, quality requirements, provenance, and how data is prepared. The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) covers the same ground in its MAP and MEASURE functions, and its Generative AI Profile, NIST AI 600-1 (July 2024), lists data privacy among 12 generative AI risks and recommends tracking data and content provenance.
You do not need to adopt either framework to borrow the evidence they expect.
Based on Gebru et al.'s "Datasheets for Datasets", keep two pages per dataset: why it was created, what it contains, how it was collected and consented, what was removed or de-identified, known gaps (missing customer segments, languages, date ranges), and who approved its use. Store it in the same repository as the pipeline so it versions with the code.
Model cards (Mitchell et al., 2019) record intended use, out-of-scope use, the datasets and versions used, evaluation results broken down by relevant groups, and known limitations. It answers the questionnaire item "how was this model trained?". Teams pursuing ISO 42001 certification will reuse both documents as audit evidence; our free ISO 42001 gap assessment shows which Annex A controls you already meet.
The fastest way to get into trouble is to reuse data collected for one purpose to train a model for another. Regulators on both sides of the border have said so directly.
PIPEDA's fair information principles require you to identify purposes at or before collection (Principle 4.2), obtain meaningful consent (4.3), and limit use and retention to those purposes (4.5). In December 2023, the federal, provincial and territorial privacy commissioners jointly issued principles for responsible, trustworthy and privacy-protective generative AI, which apply those same ideas (legal authority and consent, appropriate purposes, necessity and proportionality, openness, accountability, accuracy, safeguards) to developers and users of generative AI.
Quebec's Law 25 goes further. Since September 22, 2023, private-sector organizations must inform a person when a decision about them is based exclusively on automated processing, and must conduct a privacy impact assessment for any project to acquire or develop an information system involving personal information. Penal fines reach C$25 million or 4% of worldwide turnover for the preceding fiscal year, whichever is greater.
There is no federal privacy statute, so the pressure comes from the FTC and the states. The FTC has ordered companies to delete models built on data they should not have collected or used, including Everalbum (2021), and in December 2023 it banned Rite Aid from using facial recognition for surveillance for five years and required it to delete the images and any models derived from them. California's CPPA finalized regulations in 2025 that add risk assessments and automated decisionmaking technology (ADMT) obligations, with ADMT requirements phasing in from January 1, 2027. If you serve healthcare customers, PHI cannot go to a model vendor without a business associate agreement under HIPAA.
GDPR Article 35 requires a data protection impact assessment for high-risk processing, and Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects.
The test for each inventory row: would a customer reading your privacy notice expect this data to train or ground a model? If the honest answer is no, you need a new notice, consent, de-identification or a different dataset.
Retention rules for raw data are familiar. The hard part with AI is that deleting a record from the database does not remove its influence from a fine-tuned model. Machine unlearning is still a research problem, not a feature you can switch on.
That changes the order of work. Decide retention and deletion before training, not after a customer asks. Three rules hold up in practice:
Keep fine-tuning datasets as versioned, immutable snapshots, so you can show exactly what a model saw and retrain without a deleted customer's records.
Prefer RAG for customer-specific knowledge, because deleting a document from the index removes it from answers the same day.
Write down the retrain trigger: for example, retrain within one release cycle when a deletion request touches a training snapshot.
When the data was the problem, the FTC's remedy was deleting the model.
A retriever with a service account that can read the whole shared drive will happily surface HR files to a sales rep. OWASP's Top 10 for LLM Applications 2025 lists sensitive information disclosure, and vector and embedding weaknesses, as separate risks for exactly this reason. The fix is to enforce the requesting user's permissions at retrieval time, not to ask the model to keep secrets. Clean up overshared folders before you index them, and log which chunks were retrieved for each answer so you can investigate later. Our post on MLOps pipeline security covers the build-side controls, and data poisoning attacks covers what happens when someone writes to the data you trust.
If the model only drafts marketing copy, a spot check is proportionate. If it ranks job applicants, scores leads that decide who gets a sales call, or sets prices, test error and outcome rates by relevant group before release and on every retrain. In US employment, the EEOC's four-fifths guideline (a selection rate below 80% of the highest group's rate signals possible adverse impact) is a common first screen. It is a screen, not a safe harbour.
Many teams over-build here. If you send prompts to a commercial API that does not train on them, most of the work above does not apply. OpenAI, for example, states that API data has not been used to train its models since March 1, 2023 unless the customer opts in, and keeps abuse-monitoring logs for up to 30 days, with zero data retention available to eligible customers.
In that case your governance is short:
A data classification rule that says which classes of data may be sent to which approved vendors.
A contract review that confirms the no-training term, retention period, sub-processors, data residency and breach notice.
Logging of prompts and outputs on your side, with the same retention as the source data.
An acceptable-use policy so staff do not paste customer data into consumer AI tools.
What this will not fix: decisions about people. If the output decides who gets approved, flagged or priced, the purpose, transparency and automated-decision rules above still apply, whoever hosts the model.
In our experience this sequence fits SaaS teams of 30 to 200 people with one or two AI features, and it mirrors how we structure AI governance and data security and privacy work.
Days 1 to 10, engineering lead: build the AI data inventory and classify each row by the tiers in the first table. Output: one spreadsheet, one named owner.
Days 5 to 15, privacy lead or counsel: check each personal-information row against the stated purpose and the PIPEDA, Law 25 and state rules that apply. Output: a list of datasets cleared, blocked or needing new notice or consent.
Days 10 to 25, engineering: fix retrieval permissions and remove overshared sources before (re)indexing. Output: a permission test showing a low-privilege user cannot retrieve restricted documents.
Days 15 to 30, data or ML owner: write a datasheet per training set and a model card per released model. Output: documents committed next to the pipeline.
Days 20 to 40, product and engineering: set retention, deletion and retrain rules, and run a bias test where the model affects people. Output: written rules and a first test report.
Days 30 to 45, security: review AI vendor contracts and update the acceptable-use policy. Output: vendor register with no-training and retention terms confirmed.
Days 45 to 60, executive sponsor: review findings, accept or fund the remaining gaps, and set a quarterly review. Output: a signed risk register entry.
The free AI Governance Playbook gives you templates for the policy and risk register. If you would rather have someone run the 60 days with you, our vCISO service starts from US$2,000 a month, or book a 30-minute call and we will tell you which tier of the first table you are actually in.
Our diverse industry experience and expertise in AI, Cybersecurity & Information Risk Management, Data Governance, Privacy and Data Protection Regulatory Compliance is endorsed by leading educational and industry certifications for the quality, value and cost-effective products and services we deliver to our clients.