The problem
Engineering shipped an LLM feature, support pasted customer data into a chatbot, and a prospect just sent an AI questionnaire asking which models you use, on what data, with what human oversight. You do not have those answers written down anywhere.
The method.
Inventory every AI system, including the ones nobody registered
Models and services in the product, third-party AI APIs called from your code, AI features embedded in the SaaS you already buy, and staff use of public assistants. For each: purpose, model and provider, training or fine-tuning data, input data classes, output use, and whether a human reviews the output before it affects a person.
Classify by risk and by your role
Under the EU AI Act your obligations depend on the risk class of the system and on whether you are the provider or the deployer. Most mid-market SaaS features are limited-risk and attract transparency duties; anything touching employment, credit, education or biometrics is high-risk and attracts a materially heavier regime. Establishing which one you are in is the first decision, and it is often the last one needed.
Set the control set the class requires
Data governance for training and evaluation sets, technical documentation, logging of inputs and outputs with retention aligned to your privacy commitments, human oversight design, accuracy and robustness testing, and disclosure to users where they interact with an AI system. Under ISO 42001, these become an AI management system with the same clause structure as ISO 27001.
Address the security surface honestly
Prompt injection and untrusted content in the context window, over-broad tool and function-calling permissions, data leakage through prompts and logs, and third-party model provider terms, specifically whether your inputs are used for training. These are tested, not assumed, and the model provider's data-use terms are read rather than trusted.
Write the acceptable-use rules people will follow
An AI use policy that names the approved tools, the data classes forbidden from being pasted into them, and the review path for new AI features. Paired with a change-approval gate so the next AI feature enters the inventory when it ships, not when a customer asks about it.
What is AI governance?
AI governance is the set of processes that record which AI systems an organisation builds or uses, classify them by risk, define the data they may process, establish human oversight, and document the whole thing well enough to answer a regulator or a customer. Under ISO 42001 it takes the form of a management system; under the EU AI Act it takes the form of obligations tied to the risk class of each system.
Does the EU AI Act apply to a company that only uses AI features, not builds them?
Yes, in the role of deployer. Deployers have lighter obligations than providers (principally transparency to affected people, human oversight, and using the system according to its instructions), but they are obligations, and they attach to companies that merely buy AI-enabled tools. Where you fine-tune or place a system on the market under your own name, you may become a provider, which is a materially heavier regime.
What should be in an AI system inventory?
For each system: its purpose, the model and provider, whether it was trained or fine-tuned and on what data, the classes of data it receives as input, how its output is used, whether a human reviews the output before it affects a person, and the risk classification with your role as provider or deployer. This inventory is what customer AI questionnaires and regulators both ask for.