AI governance that covers the bill as well as the risk

One living list of every AI system in use: models, copilots, agents, AI features inside SaaS, personal accounts and API keys, with the spend behind each.

You cannot set rules, budgets or owners for AI nobody has listed. Most AI enters through a credit card, a SaaS update or a developer key, not procurement.

Regulators, auditors and customers now ask which AI you run. Finance asks why AI spend appears in five cost centers. Both questions start here.

Each new AI use states the business purpose, the users, the data it needs and the expected cost before it is approved.

Without a stated purpose there is nothing to judge access, data use or spend against, so every request looks reasonable.

Teams want AI quickly. A light intake with clear rules lets low-risk uses through in a day and slows only the ones that need it.

Every AI system has a business owner, a technical owner and a person who accepts the remaining risk and the budget.

Shared committees without named owners leave findings open and bills unexplained.

Boards and auditors expect a clear chain from the board to the person who can switch a system off. Three lines of defense need names, not teams.

A register of the models in use, their versions, where they run, their price, and the triggers to review or retire them.

Models change under you: new versions, price changes, deprecations. Each change can move quality, risk and cost.

Teams need to know which workloads break or get more expensive when a vendor retires or reprices a model.

Review of open-weight models before download, fine-tuning or hosting: license, origin, security, and full hosting cost.

Self-hosting moves duties to you: patching, safety testing, capacity and the license terms of the weights.

Self-hosting is often chosen to save money or keep data in house. It only pays at certain volumes and with an operations plan.

A consistent score for each AI use based on data sensitivity, decision impact, autonomy, users and regulatory exposure, mapped to a tier.

Not every AI use needs the same controls. Tiers put effort where harm, spend and legal exposure are highest.

Teams need to tell a meeting-notes assistant apart from an agent that changes customer records, and set controls to match.

A map of the AI rules that apply by country, state, sector and use case, with dates and the strictest common requirement.

Rules overlap and change: the EU AI Act timeline moved in 2026, US states keep adding laws, and sector regulators publish their own guidance.

A company selling in several markets needs one program that meets the strictest rule instead of separate projects per country.

A single AI risk register that keeps the specific requirement of each framework: EU AI Act, NIST AI RMF, ISO/IEC 42001, GDPR and sector rules.

Separate registers per framework duplicate work and hide gaps.

Audit, legal and security teams can work from one list and still answer each framework in its own terms.

The running cost of required controls, such as human review, safety screening, logging and evaluations, priced into each AI use.

Compliance work is real spend. Leaving it out makes AI look cheaper than it is and breaks the business case later.

Finance and product need the full cost per outcome, including review time, before they commit to scale.

Which data each AI system can read, retrieve or send, how sensitive it is, where it came from and who owns it.

Most AI exposure comes from the data it can reach, especially copilots and retrieval over shared drives with loose permissions.

Before rolling out a copilot or RAG assistant, teams need to fix oversharing so AI does not surface what people should never see.

Lawful basis, minimization, retention, cross-border transfer and explanation duties for personal data used by AI.

Privacy law applies to prompts, training data and outputs just as it does to databases.

Customers and regulators ask where personal data goes when an AI vendor processes it, and for how long.

Rights to the data used to train or tune models, copyright exposure, and who owns what AI produces.

Using data you have no right to, or shipping AI output you cannot own, creates legal and commercial risk.

Marketing, product and legal teams need clear rules before AI content goes to customers.

Where each model runs and where its provider is based, matched to your residency and sovereignty rules.

Some data cannot leave a region, and some buyers will not accept models from certain jurisdictions.

Public sector, health and finance buyers ask for this in every security review.

The identities AI uses (service principals, OAuth apps, API keys, agent identities), their permissions and how credentials are stored.

AI often inherits more access than it needs. A shared AI account makes it impossible to tell which agent did what.

Security teams need each agent on its own identity with only the access its purpose requires, and secrets that are not hardcoded.

Rules for agent actions: which tools, which data, how many steps, how much spend, which actions need a person, and a tested stop switch.

Agents act, not only answer. A loop or a wrong tool call can change records or run up a bill in minutes.

Before giving agents more autonomy, teams need hard limits that hold even when the model misbehaves.

Intake and review of MCP servers and other connectors that give agents tools and data, with scoped credentials.

Each connector is a new path to data and actions. Untrusted tool output can carry instructions an agent will follow.

Teams adding MCP servers need a review step, credentials scoped per connector, and a list of what each one exposes.

Approval of coding assistants: repository access, what code is sent, retention and training settings, and seat cost.

Developer tools see source code and secrets, and often arrive through individual sign-ups.

Engineering leaders want the productivity without leaking code or paying for seats nobody uses.

Every AI dollar traced to a vendor, product, team, workload and, where possible, an outcome such as a resolved ticket.

Invoices say how much was spent with a vendor. They do not say which team, agent or customer caused it.

Finance needs chargeback and leaders need cost per outcome to decide what to scale and what to stop.

Monthly budgets, daily hard limits, per-run caps, retry and context limits, and approval before spend above a threshold.

AI cost moves with usage. Without caps, one loop or one long-context workload can exceed a month of budget.

Enterprises want predictable AI bills and the ability to stop runaway spend without stopping the business.

Detection of unusual spend: loops, retries, context growth, new models and sudden usage spikes, with an alert and an owner.

Cost spikes are often the first sign of a broken agent, an abused key or a misconfigured workload.

Teams want to hear about it the same day, not from the invoice next month.

Cost per outcome, total cost of ownership and payback for each AI use, measured against the result it was approved for.

AI that costs more than the work it replaces should be changed or stopped, and that needs numbers.

Boards ask what AI returns. Product owners need proof to keep funding.

Paid AI seats (Copilot, ChatGPT Team, Claude Team, Gemini) matched to real usage, with reclaim and right-size actions.

Seat-based AI is easy to buy and hard to track. Unused seats are pure waste.

IT and finance want to pay only for seats people use and move licenses to those who need them.

Choosing the model and vendor per workload on price, quality tests, origin and dependency on a single provider.

The most capable model is rarely needed for every step. One provider for everything is a resilience risk.

Teams want lower cost per task without quality loss and a fallback if a vendor fails or reprices.

Monthly and quarterly AI spend forecasts by team and workload, and the chargeback or showback each team sees.

Without forecasts, AI spend surprises finance each quarter and budget fights replace planning.

CFOs want AI in the plan with ranges, not as a variance explained after the fact.

An agreed test set and pass mark for each AI use, run before release and after every model or prompt change.

Without a gate, quality drops show up as customer complaints.

Product and risk teams need evidence that the system met the bar when it shipped.

Controls for inaccurate AI output: answer checking, sourcing, labeling, and who signs off before AI content is used.

AI states errors with confidence. Wrong figures in a contract or a customer reply have real cost.

Teams need clear sign-off rules for AI content in contracts, reports and customer messages.

Tests for unfair outcomes in AI used for hiring, lending, pricing or access to services, and the level of explanation each decision needs.

Biased decisions create legal claims and damage trust. Some laws require explanations people can understand.

HR, lending and customer teams need test results and explanations they can show a regulator or court.

Defined points where a person reviews or approves AI, with the authority and time to overrule it, and records of what they did.

Reviewers who approve everything add cost without control. Oversight needs design, not just a step.

Regulators ask for proof that oversight changes outcomes. Finance asks what review costs.

Testing AI for prompt injection, data leakage, jailbreaks and misuse before release, with pass or fail criteria.

AI adds new attack paths that standard security testing does not cover.

Security teams need test results for high-risk AI before sign-off, and repeat tests after changes.

Review of AI vendors and AI features inside existing software: data use, training on your data, retention, security, liability and model changes.

Most enterprise AI is bought, not built. Vendor terms decide where your data goes.

Procurement needs a repeatable AI check that runs before signature and again at renewal.

Tracking changes to vendors terms, safety commitments and pricing, and reassessing when they weaken.

Vendors change terms and prices between renewals. Decisions made last year may no longer hold.

Teams want to hear about a material change and act before it affects customers or budgets.

The upstream parts each AI system depends on: foundation models, datasets, tools, hosting and compute, and the risk of each.

A failure or change upstream can stop your service or change its behavior.

Resilience planning needs a list of dependencies and a fallback for the critical ones.

Ongoing checks on quality, behavior, cost, access and data use after launch, with owners and review dates.

AI changes after approval: models update, data shifts, permissions grow and prices move.

A once-a-year review cannot keep up. Teams need alerts when something material changes.

A plan to detect, contain, investigate and report AI failures, with a kill switch and recovery steps.

AI incidents are different: wrong answers at scale, data leaks through prompts, agents acting on bad input.

Regulators may need notice within set times. Customers need a fast, honest response.

A tamper-evident record of inventories, assessments, approvals, policy changes, exceptions and remediation.

A policy without evidence of operation gives little assurance.

Auditors, regulators and litigants ask for proof. Collecting it later is slow and incomplete.

A structured audit of one AI system against its required controls, with findings that name the owner and the fix.

Program-level reviews miss system-level gaps.

High-risk systems need periodic audits with clear remediation work.

A workflow that assigns each finding to an owner, agrees the fix or an exception, and verifies closure.

Listing issues does not reduce risk. Fixing them does.

Leaders want to see risk going down, not a growing list of findings.

Plain rules on approved tools, what data may be typed in, what must never be, and training with completion records.

Most AI risk starts with a well-meaning employee pasting the wrong thing into the wrong tool.

The EU AI Act expects staff AI literacy, and customers ask for the policy in security reviews.

A regular report to the board with AI inventory, risk, spend, incidents and value, and thresholds for urgent notice.

Boards are accountable for AI risk and spend but rarely see either in one place.

Directors need enough context to ask good questions, and investors and regulators ask how the board oversees AI.

Scoring the governance program itself across all controls, from initial to optimized, with an evidence-backed rating and a plan.

Without a maturity view, programs grow paperwork instead of control.

Internal audit, buyers and investors ask how mature the program is and what evidence supports it.

Taking part in consultations and standards work, and keeping a record of positions and changes that affect you.

Rules are still being written. Early input and early warning reduce rework.

Regulated firms benefit from knowing what is coming and having a voice in it.

A starter set of controls for companies without a governance team: inventory, rules, spend caps, vendor settings and one owner.

Small teams use the same AI tools as large ones, with fewer people to watch them.

A proportionate program protects data and budget without slowing a small team down.

Extra controls for regulated sectors such as healthcare, financial services and employment, mapped to each sector rule.

Sector rules add duties on top of general AI law, such as clinical oversight or model risk management.

Regulated buyers expect sector-specific evidence, not general claims.