Enterprise AI Governance: Policy, Registry, Controls

Enterprise AI governance runs on the same three artefacts every organisation needs, a usage policy, a tool register and attestation records, just operated at a scale where a single shared document and an honour system stop being enough. Add headcount, regulatory exposure and a longer list of AI tools, and governance needs defined roles, dated evidence and controls that survive an auditor's questions, not just a founder's word. None of this is exotic; it is what a risk-management framework calls governance, made concrete. Most of the failure modes at this scale are boring rather than dramatic: a spreadsheet nobody updates, an owner who left and was never replaced, a policy that quietly drifted out of date. The goal is to add structure without turning it into theatre everyone quietly routes around.

What changes as you scale

At 20 people, one owner and a one-page policy is credible governance; everyone knows who wrote it and can ask them a question directly. At 500, that breaks down quietly rather than dramatically. You need defined roles (who approves a new tool, who owns the policy, who handles an incident), a versioned policy with a change history instead of a single document someone edited in place, a tool register that distinguishes approved, restricted and prohibited tools by data type, and attestation tracking that reaches every employee including this month's new joiners. A useful gut-check: could you hand your tool register to a new compliance hire on their first day and have them understand, without asking you anything, which tools are approved for which data? At enterprise scale, that's the actual bar. The substance doesn't change; what changes is that everything now has to be provable to a customer or a regulator, not just asserted in a meeting.

The AI tool register becomes the workhorse

At enterprise scale, the register does most of the actual work. It should record every AI tool in active use, who owns it internally, what data flows into it, its risk rating, the approved use cases, and the date it was last reviewed. That same register doubles as vendor-management evidence for a SOC 2 audit and as the AI system inventory that both the EU AI Act and ISO 42001 expect an organisation to maintain. Some organisations run this as a spreadsheet with an owner and a review-date column; others use dedicated software. The format matters far less than whether it's actually kept current, which is the part that usually slips first. The honest gap is shadow AI: a register is only as good as your ability to find the tools staff adopted without asking, so it has to be paired with a process that makes requesting a new tool genuinely easier than working around one.

Controls and evidence auditors actually check

Enterprise reviewers rarely ask whether a control exists in principle; they ask whether it operated, on a specific date, for a specific tool. That means single sign-on on AI tools so access is centrally revocable the day someone leaves, signed DPAs and BAAs on file for any tool touching regulated data, an approval workflow with a timestamped record of who signed off on what, and an audit log that doesn't rely on anyone's memory. None of this needs to be expensive: a shared drive with dated approval emails is weak evidence, a system that timestamps sign-off automatically is strong evidence, and the difference in effort between the two is smaller than most teams assume. The AICPA's Trust Services Criteria, the basis for SOC 2, treat this kind of evidence, not intent, as the actual test.

Is this different from 'responsible AI'?

Not really; they're the same idea from two directions. Responsible AI is usually the values-and-principles framing, fairness, transparency, human oversight. Enterprise AI governance is the operational machinery that makes those values checkable: the policy, the register, the sign-off trail. A responsible-AI statement without a tool register and attestation records is a set of good intentions nobody can verify. Governance is what turns the intention into something an auditor, or a worried customer, can actually be shown.

Does a chief AI officer need to own this?

Not necessarily. Plenty of enterprises run credible AI governance with the responsibility sitting inside an existing security, legal or compliance role rather than a dedicated title. What matters more than the job title is that one person is named, accountable, and has enough authority to say no to a tool that fails the vetting process, even when the request comes from a senior stakeholder. A chief AI officer becomes worth creating once the volume of tool requests and the regulatory surface area genuinely need a full-time owner, which for most mid-sized organisations is later than people assume.

What if governance exists on paper but not in practice?

This is the most common failure mode at enterprise scale, and it's more dangerous than having no governance at all, because it creates a false sense of coverage. A policy nobody has read since it was published, a register missing the last six tools procurement approved, an owner who left the company eight months ago and was never replaced, these all look fine in a folder and fall apart the moment someone asks a pointed question. The fix is a review cadence, quarterly for the register, annual for the policy, mandatory re-attestation, and a named, current owner accountable for keeping it live.

The register that stopped being true

A 400-person logistics company built a tidy AI governance programme in a single quarter: policy signed off by legal, a spreadsheet listing 30 approved tools, and an attestation drive that hit 94% completion. Eleven months later, a customer security review asked for the current tool list, and the team discovered the spreadsheet hadn't been touched since it was created; procurement had since approved nine more tools through a different channel, and nobody had removed two vendors that had since been dropped. The programme wasn't fake, it had simply stopped being maintained the moment the initial push ended. They fixed it by assigning register updates to whoever approves a new SaaS purchase, folding it into a process that already existed rather than creating a new one people had to remember.

Mapping governance to a recognised framework

Once the basics run reliably, mapping them to a named framework turns internal discipline into something external parties recognise. The NIST AI RMF organises this into four functions, GOVERN, MAP, MEASURE, MANAGE, and a tool register maps neatly onto MAP, while attestation and control evidence map onto MEASURE and MANAGE. ISO 42001, published in December 2023 as the first AI management system standard, asks for broadly the same artefacts under its own clause structure. Neither framework requires new software or a new department; both are checklists for governance that was already meant to exist. This mapping exercise is usually a half-day of work once the artefacts already exist, not a fresh project, because the framework is describing what good governance already looks like.

Governance that runs beats a framework still being designed

The failure mode to avoid is spending a quarter perfecting a governance framework on paper while the actual policy, register and attestation records sit untouched. ModelCharter gives you a versioned policy, a tool register with approval states, and attestation tracking in one place, with control mapping to NIST AI RMF and ISO 42001 on the Business tier for teams that need to show governance to an auditor rather than just describe it. A programme with a slightly rougher framework mapping but a register that's actually current will outperform a beautifully mapped framework sitting on top of stale data, every time an auditor actually looks. If you haven't reviewed your AI usage policy or your code of conduct for AI this quarter, that's the honest place to start.