AI Governance for Startups Without a Compliance Department

Direct answer: For a startup, AI governance is four things: an inventory of where you use AI, a decision on what data may reach it, a named owner, and a record of what you told customers. That is genuinely enough to answer most buyer questions and to satisfy the AI section of a security questionnaire. Formal ISO 42001 certification is a later decision.

Start with the inventory

Every AI feature in your product, every AI tool your team uses, and every AI capability inside SaaS you already buy. That third category is the one that surprises people, because vendors keep switching features on.

For each, record what data reaches it, whether it is a subprocessor, and who owns the decision. Most companies cannot answer these on the day they are asked, which is the actual failure.

Decide the data rule and write it down

One clear statement: what may and may not go into an AI system, with customer personal information handled explicitly. Then make it real by approving specific tools rather than issuing a prohibition everyone routes around.

What buyers are asking

Enterprise questionnaires now routinely ask whether AI is used to process their data, whether their data trains a model, whether a human reviews consequential outputs, and how you handle the risks specific to models. Those four are answerable in a paragraph each if you did the inventory, and unanswerable if you did not.

How much ISO 42001 to adopt

The standard is a management system for AI: context, policy, roles, risk assessment specific to AI, lifecycle controls, monitoring. You can adopt the shape without certifying, and that is what we usually recommend early. Certify when a customer or regulator requires it, not before.

If you sell into the EU, the AI Act has its own timeline and classification, which is a separate question from ISO 42001 and worth answering early because the obligation depends on what your system does rather than where you are.

The overlap you already have

If you are doing SOC 2 or ISO 27001, much of the underlying control set carries over: access control, vendor management, change control, incident response. AI governance mostly adds model-specific risk and transparency. Building it beside an existing programme is far cheaper than treating it as a separate project.

Our free AI governance assessment scores you against the shape of ISO 42001, the EU AI Act classifier tells you which obligations apply, and the AI Governance Program is the engagement when a buyer needs a real answer.

The inventory fields that make it useful later

Most AI inventories fail because they record the tool name and stop. The version that answers questionnaires without a research project holds nine fields per entry: the system or feature name, the provider, the deployment model (vendor API, self-hosted model, or a model embedded in a SaaS product you already buy), the categories of data that reach it, whether any of that data is customer personal information, whether the provider trains on inputs under your current contract tier, whether outputs are reviewed by a person before they affect anyone, the named owner, and the date of the last review.

The training field is the one to get exactly right, because it is contractual rather than technical. The same provider will train on inputs on a consumer tier and contractually will not on a business or enterprise tier, and teams routinely have both in the building. Record the tier and the contract, not the vendor's marketing page. When a buyer asks whether their data trains a model, the defensible answer cites the agreement you signed and the account tier you are actually on.

Finding the AI you did not know you had

Shadow AI is the practical starting problem, and it is findable in an afternoon with four sources. Pull the application list from your identity provider, which surfaces anything anyone signed into with company credentials. Pull the last two quarters of card and expense data and search for the obvious providers, because individual subscriptions get expensed. Ask your browser management or endpoint tooling for installed extensions, since a meaningful share of assistant tooling arrives that way. Then read the release notes of the SaaS products you already pay for, because features get enabled by default and the notice arrives in an email nobody opened.

That fourth source is the one that catches people out during a customer review. A support desk product that added an answer-drafting feature, switched on by default, is now processing your customers' support tickets through a model. You did not procure it, you did not assess it, and your customer's questionnaire will still ask you about it. Once you have found these, the useful control is not a ban. It is a small approved list, a route to request additions that takes under a week, and a default-off posture on new AI features in existing tools.

When an AI vendor becomes a subprocessor

This is where AI governance stops being an internal exercise and starts touching contracts you have already signed. If a model provider processes personal data on your behalf, they are a subprocessor and your data processing agreements almost certainly say something about that. Common clauses require a current published subprocessor list, advance notice before adding one, and a right for the customer to object. Adding a model provider to a production data path without updating that list is a contractual breach that a diligent customer will find, and they tend to find it during renewal.

Work through it in this order. Check whether the AI system touches customer data at all, because internal productivity tools handling only your own material usually do not create a subprocessor relationship. If it does, confirm you have a data processing agreement with the provider covering it. Add them to your published subprocessor list. Check your customer contracts for notice periods and honour them. If any customer contract contains an outright restriction on processing their data with AI systems, which is increasingly common in enterprise and public sector paper, that customer's data needs a technical route that excludes the feature, not a policy that says people should be careful.

Retention, prompt logs, and the thing nobody classifies

Prompts and outputs are data you now hold. If a user pastes a customer record into an assistant, your prompt log contains personal information, and it inherits every obligation attached to that record: retention limits, access control, deletion on request, inclusion in a breach assessment. Teams that carefully classify their primary database and never think about the prompt log are carrying an unclassified copy of the most sensitive data they hold.

Decide three things and write them down. How long prompts and outputs are retained, at your side and at the provider's, since several providers offer zero-retention or short-retention configurations that must be explicitly enabled. Who can read the logs, because debugging access to a prompt store is production data access and should be controlled as such. And how a deletion request propagates, which is the question that gets awkward when a customer exercises a right under PIPEDA or Quebec's Law 25 and the record exists in three places you had not mapped. None of this requires new tooling. It requires the same data lifecycle decisions you already made for your database, applied to a store that arrived quietly.

The security risks that are specific to models

Your existing controls cover most of the surface. The genuinely new failure modes are worth understanding properly rather than gesturing at. Prompt injection is the primary one: any untrusted content that reaches a model can carry instructions, so a model that reads customer-submitted tickets, scraped web pages or uploaded documents is reading attacker-controllable text. If that model also has tools, meaning it can call an API, query a database or send a message, then the injected instruction has reach. The control is not a cleverer prompt. It is treating model output as untrusted input, scoping tool permissions to the least the feature needs, and requiring confirmation for anything with a side effect.

The second is retrieval leaking across tenants. A shared vector index with tenant filtering applied at query time rather than at index time is one bug away from returning another customer's document, and it is a bug class that standard testing will miss unless someone specifically probes it. The third is over-permissioned service accounts, where the credential the AI feature uses can read far more than the feature needs, so any successful injection reaches the whole database. All three are architecture decisions, which means they are cheap in design and expensive after launch. If you are shipping agentic features with tool access, this is worth a proper look before the feature ships rather than after a customer asks.

What an AI incident looks like and how to handle it

You do not need a separate AI incident response plan. You need three or four scenarios added to the one you have, and a decision on who declares them. The realistic scenarios: a model output disclosed one customer's data to another, an employee pasted regulated data into an unapproved tool, a prompt injection caused an agent to take an action it should not have, and a model-driven decision produced an outcome that harmed a user and became a complaint.

Each needs the same things your existing plan already defines: who declares, who investigates, how you determine scope, what triggers customer notification, and what triggers regulator notification. The scoping step is where AI incidents differ most, because determining what a model was exposed to means reading logs that may not exist unless you decided earlier that they should. That is the practical argument for prompt logging with a defined retention window rather than none at all. Run one tabletop on the cross-tenant disclosure scenario and you will find your gaps in ninety minutes. If you want that facilitated alongside the rest of your programme, it fits inside a retainer rather than needing a separate project.

Human review, and what "consequential" actually means

Questionnaires ask whether a human reviews consequential outputs, and teams answer yes without defining the word. Consequential means the output materially affects a person's access to something they care about: employment, credit, housing, insurance, healthcare, education, or the continuation of a service they depend on. Drafting a marketing email is not consequential. Scoring an applicant, flagging an account for suspension, or triaging a clinical message is.

If you have any of the second kind, the review has to be real and it has to leave a record. A reviewer with no practical ability to disagree, no time budget, and no logged decision is not meaningful oversight and will not survive scrutiny from a regulator or a serious enterprise reviewer. Log who reviewed, when, and whether they accepted or overrode. That log is also your evidence that the control operates, which is what an auditor will ask for if AI governance ends up inside a certification scope.

The Canadian and cross-border position

There is no dedicated federal Canadian AI statute in force, so the operative obligations come from privacy law and from contracts. PIPEDA governs personal information in commercial activity, including where it flows through a model, and its accountability and transparency principles apply to processing you have delegated to a provider. Quebec's Law 25 goes further on automated decision-making, requiring that individuals be informed when a decision is based exclusively on automated processing and be able to request the reasons and the principal factors involved. If you sell in Quebec and any decision path is fully automated, that is a product requirement, not a policy paragraph.

Selling into the EU adds the AI Act, whose obligations attach to what the system does rather than where you are incorporated. Selling into US enterprises adds their internal AI policies, which are often stricter than any statute and arrive as contract terms. The practical approach is one control set, mapped to whichever obligations apply per market, exactly as you would handle privacy law generally. Running separate programmes per jurisdiction is how small teams end up maintaining three documents and complying with none.

What this actually costs in effort

Done as a focused piece of work, the four artefacts take a small team roughly two to four days of elapsed effort spread over a fortnight. The inventory is half a day if the identity provider export is clean and two days if it is not. The data rule is an afternoon of drafting and a longer argument about which tools get approved. The customer-facing disclosure is half a day, and it should be reviewed by whoever owns your contracts. Nominating an owner takes a meeting.

The ongoing cost is a quarterly review of the inventory, ideally sat alongside your vendor review and access review so it is one meeting rather than three, plus a check whenever you ship an AI feature or a vendor announces one. If you keep the inventory beside your vendor register and your risk register, which is how the free Workspace is laid out, the quarterly review is genuinely under an hour. Kept in three separate spreadsheets owned by three people, it becomes the kind of task that gets skipped twice and then done badly under deadline pressure.

When you should not build an AI governance programme

If you ship no AI features, use one approved assistant on a business tier that does not train on your inputs, and no customer data goes near it, then you do not have a governance programme to build. You have an inventory with three rows, a written rule, and a named owner. Anyone selling you more than that at this stage is selling you documents.

Do not pursue ISO 42001 certification because it appears in a competitor's press release. Certification carries an accredited audit, a surveillance cycle and ongoing management system overhead, and it is the right purchase when a specific customer or regulator requires it in writing. Adopting the shape of the standard costs a fraction and answers the same questions in a sales cycle.

Do not commission an AI-specific security assessment if your AI usage is entirely internal productivity tooling with no customer data and no tool access. Spend that budget on the basics that every questionnaire asks about first, because a company with excellent AI governance and no access reviews fails the review anyway. And if your buyer's question is really about a single feature rather than your whole posture, answer that question honestly and move on. Two paragraphs and an accurate subprocessor list close more reviews than a governance framework does, and if you are unsure which situation you are in, describe the question you were asked and we will tell you which one it is before you spend anything.

Worked answers you can adapt

Is AI used to process our data? Answer with the specific feature and the specific provider, not a general posture. "Customer content is processed by one AI system: our support summarisation feature, which sends ticket text to a named provider under our enterprise agreement. No other product feature sends customer data to a model. Internal staff tooling is restricted to an approved list and is prohibited from receiving customer data by policy and by the tools available."

Does our data train a model? Cite the contract. "No. Under section X of our agreement with the provider, inputs and outputs are excluded from model training, and we operate on the enterprise tier where that exclusion applies. Retention at the provider is configured to zero days." If any of that is not true, say what is true and what the retention period is, because a reviewer can check the provider's published terms in a minute.

Is there human review? Name the decision types and the record. "No product output makes a decision about an individual. Summarisation output is presented to a support agent who edits before sending, and edits are logged."

How do you manage AI-specific risks? Point to concrete controls rather than a framework name. Least-privilege service accounts for any model with tool access, tenant scoping enforced at index time for retrieval, model outputs treated as untrusted input, AI scenarios covered in incident response, and a quarterly inventory review with a named owner. That paragraph beats a page of principles, because every clause in it is something a reviewer could ask you to evidence.