You Cannot Govern the AI You Have Not Found Yet

Everyone asks which platform to buy

The decision arrives already shaped by whatever forced it: a board question, a customer's security review, an insurer's questionnaire at renewal. The instinct is to buy the control plane, because a control plane is a thing you can point at.

An AI governance platform, an AI posture management tool, a gateway in front of model traffic. Each sits over a population of AI systems that somebody has to define for it. A governance platform reports accurately against the register it is given, and it covers the accounts, tenants and network paths you connect to it. Building that register and making those connections is field work, and it happens inside your organization before any platform is chosen.

On the morning it goes live, the register on hand is the spreadsheet: the sanctioned assistant, the copilot licenses, the two internal projects that went through architecture review. The rest arrived by routes procurement never saw. A vendor turns on a summarization feature in a release of a SaaS application you already run, on by default, scoped to whatever data the application already held. A supplier puts a model inside a process you depend on.

The platform is doing its job. The number it produces in its first month is a measurement of the spreadsheet, and the spreadsheet is what you stand behind when counsel asks what AI is running here.

So the real decision is one of sequence, and the purchase falls out of it. Running discovery before tooling is a CWS recommendation. SAIL 2.0, the AI RMF, ISO/IEC 42001 and the Act each leave the sequence open, so the case for it rests below on what a register costs to fix afterward.

What discovery turns up

The data you already hold will find the traffic: model API endpoints called by hosts and workloads nobody can put a name to, OAuth grants to AI vendors against scopes nobody reviewed, team subscriptions recurring under every approval threshold.

The owner column is where the work sits. A finding with a name against it becomes an assignment, and telemetry produces the finding and leaves the name blank: an endpoint, a grant, a charge on a card. Source history can name whoever committed the code, which is a place to start, and the person accountable for it today may be somebody else. Ownership gets settled by asking, and the developer who built something useful on a Friday afternoon will say so when the ask is framed as registration.

So the deliverable is a register. Six kinds of row account for most of what goes into a first one.

• Sanctioned platform accounts with workspaces nobody administers, expensed by a team
• SaaS applications where a model feature arrived in a vendor release, inheriting the data scope the application already had
• Personal accounts on corporate devices and corporate domains, outside every license record
• Internal builds, from retrieval applications over document stores to a script calling a model API with the key committed to the repository
• Agents and connectors holding standing credentials into mail, ticketing, CRM or source control
• Suppliers who have placed a model inside a process your organization depends on

A list of tool names is not an inventory. An inventory has an owner, a data class and a credential on every row.

SAIL 2.0 as the spine, with AI RMF, ISO 42001 and the EU AI Act mapped onto it

A program needs a spine. Without one, every finding gets argued on its own merits, and this quarter's position cannot be reproduced for next quarter's auditor.

Discovery sits early in the sequence, ahead of the phases where tooling lands. That ordering is why CWS anchors AI governance work on SAIL 2.0, the Secure AI Lifecycle Framework it contributed to, which organizes the problem by lifecycle phase.

The other three map onto that spine. Security will ask for the AI RMF view, compliance for the ISO 42001 view, and whoever carries the regulatory exposure wants the role determination, all three readings off one body of evidence. Each of the four starts from a population somebody has already established.

• The NIST AI Risk Management Framework is voluntary, and what it gives you is vocabulary your board already recognizes. Its four core functions are GOVERN, MAP, MEASURE and MANAGE, and MAP is the context and categorization function. So when somebody asks why discovery comes first, you have a published ordering to point at.
• ISO/IEC 42001 is a certifiable management system standard for AI, which makes it an artifact you can hand somebody. Certification requires a stated scope, and a stated scope means naming the AI systems inside it. The boundary has to exist before anybody can certify against it.
• The EU AI Act is law. Obligations are tiered according to the risk a system presents, and they attach according to the role your organization occupies in relation to it, so you can be the deployer of one system and the provider of another. The specifics belong to your counsel. Counsel makes those determinations per system, which means each system has to be identified, classified and attributed to a role first.

The sequence: discovery, baseline, policy, then tooling

Four stages, each producing something you can put in front of somebody else, because each one has to earn the next. Policy is the stage that gets compressed when the tool arrives first, and the mechanism is plain: the product ships with defaults, and somebody configures them during deployment week.

• Discovery, run inside a fixed window, drawing on identity logs, egress and proxy data, SaaS admin consoles, expense records, source repositories, and interviews with the teams most likely to have built something. It produces the register. A survey still running after two quarters describes a state that has already moved.
• The baseline scores the register against the lifecycle phases and gives you a current-state position plus a gap list, each gap carrying an owner, a sequence and an effort estimate. This is the document that goes upstairs, and it funds everything after it.
• Policy covers acceptable use, the intake and approval path for a new AI system, the data classes that may and may not leave, and who signs. The intake path is what keeps the register from going stale inside a quarter.
• Tooling comes last, and by then the selection is short, because the requirements came out of the gap list and you already know which gaps need a product and which need a process change.

The configuration becomes the policy by accident. Nobody decided it, and nobody can defend it when an auditor asks who approved it.

The part that is hard from the inside

Technically this is ordinary work. The data pulls are routine and the interview questions are obvious once somebody writes them down. The difficulty is organizational.

• The work crosses boundaries. What surfaces spans identity, the SaaS estate, cloud accounts, source repositories and procurement records, most of it owned by teams that report elsewhere. Anyone who has asked a busy identity team for a complete OAuth grant export knows that conversation.
• Incentives decide your yield. Someone who declares the thing they built is volunteering for review, possible shutdown, and the word shadow attached to their work. Run discovery as an audit and you get back the sanctioned list you already had. Run it with a stated amnesty, where nothing surfaced inside the window becomes a disciplinary matter, and you get the rest. Announce that before the first interview, because it cannot be reversed halfway through.
• Calibration needs a stated method. A risk tier means something only against a written rubric, so settle the rubric before the first row is scored: what data the system reaches, what credentials it holds, what its output decides, and where the boundary between tiers falls. A team running this once in its own estate has one distribution to calibrate against, which is the argument for writing the method down and having somebody outside the team argue with it. An outside team is also freer to write down the answer that says configure what you already own and buy nothing this year.

What the first piece of work produces

Acceptance means the register and the baseline delivered and walked through, without anybody having to agree with the findings. Findings get argued with, and the argument is where the owner column gets filled in properly.

Write down what was left unexamined. Name the sources you had access to and the ones you were refused, because a refusal is itself a finding. Give the register a stated confidence position, because a register that claims completeness fails on the first audit question.

Settle this list before anybody starts, whether you run the work internally or commission it. The readout is too late.

• The register, a row per system carrying the owner, data classes touched, credentials held, hosting, bought or built, and a risk tier with the method stated
• A baseline against the lifecycle phases, each finding shown in its AI RMF, ISO 42001 and EU AI Act framing
• A preliminary role determination per system, deployer or provider, marked as a scoping input for your counsel to confirm, which is what it stays until they rule on it
• A gap list carrying owners, sequence and effort
• A draft policy set covering acceptable use, intake and approval, data handling, record keeping and sign-off authority
• A tooling requirements document, written before anybody books a demo

The inventory is going to exist either way. The only open question is whether anybody validated it before the tool started reporting on it.