Governance structures for AI: the centre of excellence, policies and procedures

Why this matters

Every technical control in this course assumes somebody decided it was needed. A prompt firewall exists because someone decided customer-facing models must be fronted by one; an evaluation gate exists because someone set the threshold and owns it. Governance is the structure that makes those decisions, writes them down and checks they are followed. Without it, AI security depends on which team happened to build the system and how careful they felt that week.

AI makes the gap visible faster than most technologies. Generative tools reach every department at once, through a browser tab, with no procurement step. A marketing team builds a chatbot on a public model, finance pastes forecasts into a summariser, and engineering wires an agent to the ticketing system, all in the same quarter, each with a different idea of what is allowed. The security professional is usually the first to notice, and is then asked what the rules are.

Lessons 30 to 33 cover the principles, risks, regulations and corporate policy content that governance has to address. This lesson is about the structures that carry them: who owns AI decisions, how rules are written, how a new use gets approved, and how all of that joins the governance the organisation already has.

The exam angle: scenarios describe an organisation where something went wrong because nobody owned a decision, a rule existed but nobody knew how to follow it, or the approved route was so slow that people went around it. The answer names the missing structure.

The lesson

An AI centre of excellence: what it owns and what it must not become

An AI centre of excellence (CoE) is a standing, cross-functional group that holds expertise and sets direction for AI across the organisation. It usually has an executive sponsor, a written charter and members drawn from data science and engineering, security, privacy, legal, risk and the business units that use AI.

What a CoE typically owns:

• Standards and reference architectures: the approved way to build a RAG application, where the gateway and guardrails sit, how models are hosted.
• The catalogue of approved platforms, models and tools, maintained so that teams can find a sanctioned option before reaching for an unsanctioned one.
• Reusable components: a shared gateway, a prompt-template library, an evaluation harness, so each team does not rebuild controls badly.
• The inventory of AI use cases, recording what exists, who owns it, what data it touches and its risk tier.
• Intake and triage of new proposals, routing each to the right depth of review.
• Skills and awareness: guidance, training and a community of practice.

Many organisations run it hub-and-spoke: a small central team sets standards and provides shared services, while practitioners embedded in business units build and run their own systems within those standards.

What it must not become:

• A bottleneck. If every use waits months for a central team, people use public tools instead and the CoE governs only the projects that asked. Slow governance creates shadow AI, which lesson 31 covers as a risk.
• The owner of every risk. Accountability for an AI system stays with the business owner who benefits from it. The CoE advises, sets standards and reviews; it does not accept risk on another team's behalf.
• Judge of its own projects. A CoE that promotes adoption, builds flagship systems and also signs off their risk has a conflict of interest. Risk acceptance and assurance should sit with functions independent of the builders, a separation lesson 29 develops role by role.
• Advisory with no teeth. Standards nobody checks are suggestions. The CoE's requirements need to be enforced somewhere: in the pipeline gates of lesson 27, in procurement, or in architecture review.

AI policies and procedures, and the difference between them

The governance document hierarchy is familiar from security, and it applies unchanged to AI. What matters is putting each rule at the right level.

A policy states what is required and why, at a level that rarely changes. It is approved by senior management, it is mandatory, and it is short enough to be read. "Confidential and personal data may be entered only into AI tools on the approved list" is a policy statement.

A standard makes a policy measurable: which tools are on the list, what evaluation thresholds a customer-facing model must meet, what logging every AI application must produce.

A procedure is the step-by-step method for doing something in a way that complies: how to request a new AI tool, how to run the pre-release evaluation, how to report a suspected AI incident, how to retire a model. Procedures change as tools and teams change, and are owned by the team that performs them.

A guideline is recommended practice, not mandatory, such as prompting advice for staff using an approved assistant.

Typical AI policies include an acceptable-use policy for staff using AI tools, a policy on developing and procuring AI systems, rules on what data may be used for training and prompting, model risk management, and AI incident handling. Some organisations fold these into existing policies; others write one AI policy with sections. Either works if the content is there and people can find it.

The scenario distinction is reliable. If staff did something harmful because nobody had said whether it was allowed, the missing item is a policy. If staff knew it was required but did it inconsistently, or did not know how, the missing item is a procedure. If the policy said "appropriate controls" and two teams interpreted that differently, the missing item is a standard.

An approval path for new AI use that people will actually follow

Every AI policy implies an approval path: before a new use goes live, somebody checks it. The path's design decides whether it governs anything, because a path people avoid approves nothing.

The elements of a path that works:

• One front door. A single, easy-to-find intake form, not a choice of committees. It asks the few questions that decide risk: what data, which model, who uses the output, whether it acts or decides about people, whether it faces customers.
• Risk tiering at intake. Using an approved assistant with internal, non-sensitive data is low risk and should be approved quickly, perhaps automatically. A customer-facing chatbot is higher. A system that makes or informs decisions about people's employment, credit or access to services goes to full review, and may fall within regulated categories discussed in lesson 32.
• Pre-approved patterns. A team that builds on the CoE's reference architecture, gateway and evaluation harness inherits their approvals and needs to justify only what is new. This is the strongest incentive to use the safe path, because it is also the fast one.
• Published turnaround times for each tier, so teams can plan instead of guessing.
• Conditions and a review date on every approval. Approval is for this model, this data and this purpose, and lapses on a date.
• Re-approval on material change. A new model version, a new data source, a new tool for an agent or a new user population is a new risk, and goes back through intake at its tier.
• A register entry for every approval, which becomes the inventory the CoE maintains.

The test of an approval path is the shadow AI it finds later. If discovery (network logs, expense claims, browser extension inventories) turns up many unapproved uses, the path is too slow or too hard to find, and fixing the path does more than punishing the users.

Fitting AI governance into existing security and risk governance

The common mistake is building AI governance as a parallel system with its own risk register, its own supplier reviews and its own incident process. Parallel systems drift apart, double the work and leave gaps where each assumes the other is responsible. The better design extends what exists.

• Enterprise risk management. AI risks go on the existing risk register, scored on the same scale and reported through the same committee, so the board sees AI risk next to every other risk.
• Third-party risk management. AI vendors are suppliers. The existing assessment gains AI questions (training on customer data, model provenance, data location) rather than a separate process. Lesson 33 covers the content.
• Data governance and privacy. Classification labels decide what may enter a prompt. Privacy impact assessments already exist for new processing of personal data; the AI policy can require one for every AI use that processes personal data, which is stricter than the GDPR, where a formal data protection impact assessment is required only for processing likely to be high risk.
• Change management. Model, prompt and guardrail changes flow through it, as lessons 26 and 27 described.
• Security architecture review gains an AI threat-modelling step, using the methods from lesson 8.
• Incident response gains AI incident categories and playbooks rather than a second team.
• Internal audit includes AI systems in its plan.

The three lines model gives a useful map. The first line, business owners and the teams who build and run AI, owns and manages the risk. The second line, risk, compliance, privacy and security functions, sets standards and oversees. The third line, internal audit, gives independent assurance to the board. An AI CoE usually straddles the first and second lines, which is exactly why it must not also be the third.

Frameworks support this integration. The Govern function of the NIST AI Risk Management Framework is about establishing exactly these structures and cuts across its Map, Measure and Manage functions. ISO/IEC 42001 specifies an AI management system that can be certified, and it follows the same high-level management-system structure as other ISO management system standards such as ISO/IEC 27001, so an organisation can run the two together. Lesson 32 treats both in more depth.

Reading a governance scenario and naming the missing structure

Governance questions describe symptoms. Map each symptom to the structure whose absence produces it:

• Teams use different, incompatible approaches to the same problem, and nobody can say which is correct: no standards or reference architecture, the role of a CoE.
• Nobody can list the AI systems in use: no inventory or register.
• Staff paste confidential data into a public tool and say nobody told them: no policy, or a policy nobody was made aware of.
• The policy exists but every team applies it differently: no standard, or no procedure.
• Most AI use is discovered rather than declared: an approval path that is too slow or invisible.
• A model was retrained on new data and nobody reviewed it: no re-approval trigger on material change.
• The team that built a high-risk system also signed off its risk: no separation between building and assurance.
• AI risks are tracked in a spreadsheet the risk committee never sees: governance running in parallel instead of integrated.

A useful habit is to resist the technical answer. When a governance scenario offers a new tool alongside a missing policy or owner, the tool is usually the distractor: a tool deployed into an organisation with no owner and no rule becomes one more unmanaged system.