The AI Policy Says Ask First. The Logs Say Nobody Asks.
You published an acceptable use policy with an approval route in it. Discovery comes back with a register of running AI systems, and most of the rows have no request behind them. The policy is accurate about what you intended and wrong about the organization you are running.
The register is longer than the approval log
The policy carried what a policy needs: a statement of acceptable use, a list of data classes that must not leave the organization, and a route. Bring the AI system to this forum, get a decision, then use it. Legal reviewed it and the executive team signed it.
Then discovery runs across identity, egress, the SaaS estate, expense records and source repositories. The register that comes out is longer than the approval log, and the gap is too wide to read as a handful of exceptions.
Read the rows and the pattern holds. Someone had a delivery date. The sanctioned route had a form and a queue with no published length. Another way of doing the work sat in a browser tab and cost nothing to try. Nobody decided to breach a policy. They took the path that fit inside the week they had.
So you hold a document describing an organization where the approval route is the quickest way to get an AI system into use. The rows with no request behind them are ordinary. Four kinds account for most of them.
- A team subscription expensed under a threshold that required no approval, renewing quietly every month
- A model feature switched on in a release of an application you already ran, inheriting the data it already held
- An internal build that started as a Friday afternoon script and became something a weekly process depends on
- A connector holding standing credentials into mail or ticketing, configured by somebody who has since changed roles
The approval path is in a race with a browser tab
Lay the route out as elapsed time and the reason is ordinary. A request arrives and waits for a security review, which waits for a questionnaire to come back from a third party. Legal reads the terms. Architecture wants to see the integration. Procurement needs a purchase order. Each step takes an afternoon, and the waiting between them is where the weeks go.
Every reviewer in that chain is doing something defensible, and none of them is accountable for the total. The requester experiences one number, the days from asking to getting an answer, and that number competes against an alternative with no queue at all.
Enforcement arguments start here and stall. More monitoring, a block at the proxy, a firmer line in the handbook. Each of those raises the cost of going around while the clock on the sanctioned route stays where it is, so the team with a delivery date is left facing a slow path and a closed door.
- A form written for software procurement, asking questions a team using a hosted assistant cannot answer
- A review forum that meets on a cycle, so a request submitted the day after a meeting waits for the next one
- A queue with no published position and no decision date, so the requester cannot tell a project manager when the answer arrives
- An approval scoped so tightly that a small change in how the system is used sends the request back to the start
Time the whole route, from asking to getting an answer. That total is the number a requester is choosing against.
Two numbers about your own process
The register invites an argument about whether the count is bad, and that argument has nowhere to go. A normal count would need a benchmark drawn from estates like yours, and figures published elsewhere measure somebody else's organization at somebody else's size.
Two numbers move it somewhere useful. The first is coverage of your own route: of the AI systems running, how many have a decision record behind them. The second is decision time: for the requests that did go through, the days from submission to answer, reported with the spread, because an average hides the request that sat for a quarter.
Both numbers survive the meeting where somebody asks how you know, and both point at something you control. A route with low coverage and a long clock is a design problem in a process you own, and the people who went around it were responding to that design.
The owner column still has to be filled by asking. Logs give you traffic, grants and spend, and they leave that column blank. Source history names whoever committed the code, which gets you a person to start with, and the person accountable for the thing today may be somebody else. The developer who built the useful thing on a Friday fills the column in when the ask carries a stated amnesty.
- Identity and SSO logs, for grants issued to AI vendors and the scopes attached to them
- Egress and proxy data, for model API endpoints called by hosts and workloads nobody can put a name to
- SaaS admin consoles, for model features enabled inside applications you already licensed
- Expense and card records, for team subscriptions sitting below every approval threshold
- Source repositories, for client libraries, keys and prompts committed next to the code that calls them, with commit history naming who put them there
- Interviews with the teams most likely to have built something, which is where a name in a commit log becomes an owner who accepts the row
Put both numbers on the same page as the register. A count of running systems means little until the reader can see how long your route takes to answer.
What the frameworks are asking for here
A program needs a spine, or this quarter's position cannot be reproduced for next quarter's auditor. CWS uses SAIL 2.0, the Secure AI Lifecycle Framework it contributed to, for that. A phase closes on what it produced. A published policy is one output. Evidence that the route inside it is the route people actually take is a separate one.
The other three read off the same body of evidence. Security wants the AI RMF view, compliance wants the ISO 42001 view, and whoever carries the regulatory exposure wants the role determination.
An auditor reads the policy and then asks to see the decision records behind the systems that are running. The distance between those two is the finding, whichever framework the conversation is held in.
- The NIST AI Risk Management Framework is voluntary, and what it gives you is vocabulary your board already accepts. Its four functions are GOVERN, MAP, MEASURE and MANAGE. GOVERN covers the policies, accountability and processes the other three operate inside, and a route people go around lands there.
- ISO/IEC 42001 is a certifiable management system standard for AI. A management system audit tests the documented process against the operating one and asks to see the records. A published route with few records behind it is the shape of finding that surfaces.
- 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, so you can be the deployer of one system and the provider of another. The specifics belong to your counsel, who makes a role determination per system, which requires the system to have been identified and attributed to an owner first.
Shortening the sanctioned path
The work that closes the gap sits on the sanctioned side of the line. Putting it there is a CWS position, and it follows from the measurement: coverage is low because the route is slow. The standards above leave the choice open.
The change is mostly intake design. One review lane for every request puts a request that touches nothing behind a request that touches everything. The low-reach requests are the ones a team raises without thinking about it, which is why they crowd the lane.
The loop then has to close. The intake feeds the register, and discovery runs again on a cycle against the same two numbers. Coverage climbing while the clock falls is the evidence that the policy has begun to describe the organization you have.
- Split the intake by what the system can reach. A request touching no regulated data and holding no standing credential clears in a short lane. One wired into mail, ticketing or customer records gets the full review.
- Pre-clear patterns and publish them: a named configuration, a named data boundary, a named way for a service to call a model API. A request that fits a pattern then becomes a registration against a decision already taken.
- Put a decision clock on each lane, name the person who owns it, and publish where a request sits. A requester who can give a project manager a date will wait.
- Confirm the sanctioned option can do the work. A license tier or a configuration that falls short of what a team needs will keep sending people elsewhere however quickly the review runs.
- Announce the amnesty for registration before the first conversation and hold to it, because it cannot be withdrawn halfway through.
A policy becomes a control on the day the path it describes is the path people can take.