Courses / AI Integration For Companies / Week 10

Week 10 of 12 · Intermediate

Operating Model

You learn how a company organises itself to run AI over years: who decides, who builds, who is accountable, which policies apply and how vendors are managed. You draft a lightweight operating model for your own organisation.

3 hours18 slides6 min read

Open slides Read study notes

Why A Pilot Needs An Operating Model Three Ways To Organise The AI Council The Center Of Excellence Roles And Accountability Policies People Can Follow Managing Vendors

You Will Be Able To

Compare central, federated and hub and spoke operating models
Define the purpose, members and decision rights of an AI council
Describe what a center of excellence does and what it should not do
Assign roles for AI use cases with a clear accountable owner
Write the key policies and a vendor management checklist

Why A Pilot Needs An Operating Model

In week 9 you built a cost and benefit case. A good case leads to more than one use case, and soon the company faces the same questions again and again. Who may approve a new tool? Who pays for it? Who answers when an output causes harm? Without clear answers, every team invents its own rules, spend spreads, and risk grows quietly.

An operating model is the set of structures, roles, rules and routines that let an organisation run something repeatedly. For AI it answers four questions: who decides, who builds and runs, who is accountable, and how do we know it works. The aim is the lightest structure that gives enough control. Too little structure creates risk. Too much structure makes teams work around the rules.

Three Ways To Organise

In a central model, one team owns AI for the whole company. Standards are consistent and expertise is concentrated, but the team becomes a bottleneck and sits far from the real work. In a federated model, each business unit builds its own capability. Teams move fast and know their domain, but practices diverge, costs duplicate and risk is harder to see.

Hub and spoke combines the two. A small central hub sets standards, provides shared platforms, and offers expert help. Spokes in business units own use cases and results. Most mid and large companies end up here. Start closer to central while skills are scarce and rules are new, then move decisions to the spokes as capability grows.

Central: consistent and safe, risk of bottleneck
Federated: fast and close to work, risk of divergence
Hub and spoke: shared standards, local ownership
Choose by company size, skills and risk, then revisit yearly

Three Operating Models Compared

Model	Strength	Weakness	Fits when
Central	Consistent standards	Bottleneck, far from work	Few skills, early stage
Federated	Speed, domain knowledge	Divergence, duplicate cost	Strong units, mature skills
Hub and spoke	Shared rules, local owners	Needs clear boundaries	Most mid and large firms

Many companies start central and move toward hub and spoke.

Control Versus Speed By Model

central control (illustrative, 1 low to 5 high)

Illustrative scale to show the trade off, not a measurement.

The AI Council

An AI council is a decision forum that sets direction and approves higher risk use. Keep it small, with seven to ten members who hold real authority: a senior sponsor from the executive team, and leaders from IT, security, legal and compliance, data protection, HR, finance and two or three business units. Include a voice from the employees who use the tools.

The council meets on a fixed rhythm, monthly at first. It owns four things: the list of approved use cases and their risk tiers, the policies, the shared budget and priorities, and the review of incidents and results. It should not review every small request. Define tiers: low risk uses follow a standard checklist and proceed without a meeting, medium risk uses need review by the hub, and high risk uses, such as decisions affecting people or customers' rights, come to the council. Record every decision and its reason.

Approval Path By Risk Tier

Team proposes use case
Hub assigns risk tier
Low risk: checklist
Medium risk: hub review
High risk: AI council

Only the highest tier reaches the council, which keeps it fast.

The Center Of Excellence

A center of excellence, or CoE, is the hub's working team. It holds the technical and practical knowledge. It runs the shared platform, maintains approved tools and templates, offers training from week 8, supports teams through discovery and pilots, runs evaluation and monitoring, and publishes patterns that worked.

The CoE enables and does not own the business outcome. When a CoE builds everything itself, business units stop learning and the team becomes a queue. Measure it by the number of teams it has helped to run on their own, by the reuse of its templates, and by time from idea to pilot. A small CoE with a clear service menu works better than a large one with a vague mission.

Provides: platform, templates, evaluation tools, training
Supports: discovery, pilots, security reviews with the right teams
Publishes: patterns, lessons and a use case catalogue
Leaves with business units: ownership of outcomes

Roles And Accountability

Every AI use case needs named people. A business owner is accountable for the outcome and for the decision to use the system. A product owner runs the day to day and the backlog. A technical owner keeps the system running and secure. A data owner approves the use of data. A risk and compliance contact checks legal duties such as KVKK, GDPR and, where relevant, the EU AI Act. Reviewers check outputs in line with the human oversight design from week 7.

Write the roles in a simple responsibility table, often called a RACI: who is Responsible, Accountable, Consulted and Informed for each decision. One person is accountable for each decision. A model or a vendor can never hold that role. When something goes wrong, the question is always the same: who owned this use case?

Policies People Can Follow

Policies fail when they are long, vague or hidden. Write short ones in plain language and attach examples. A starting set covers acceptable use, including what data may never be entered into a tool; approved tools and how to request a new one; human review and disclosure rules, for example when a customer must be told that they talk to AI; handling of personal data under KVKK and GDPR from week 5; intellectual property and the use of generated content; and incident reporting.

Pair each policy with a route. If a policy says only no, people find shadow tools. If it says no, here is the approved way, they follow it. Review policies every six months because tools and laws change, and keep a change log. Check the exact legal wording with your counsel, since duties differ by sector and country.

Managing Vendors

Most companies buy AI from vendors, so vendor management is a core part of the model, as you saw in week 4. Assess a vendor before signing and again at each renewal. Ask where data is stored and processed, whether your data trains their models, which sub processors they use, what security certifications they hold, how they notify you of incidents, how they announce model changes, and what happens to your data when the contract ends.

Put the answers into the contract: a data processing agreement, service levels, audit rights where appropriate, notice periods for changes, and exit terms that let you export your data and prompts. Keep a register of all AI vendors with the owner, the data they touch, the risk tier and the renewal date. Review the register at each council meeting. Week 11 returns to model change and lock in.

Review the operating model itself once a year. Ask the council whether decisions are fast enough, whether teams know where to go for help, whether policies are followed, and whether any use case has no clear owner. Collect answers from the people who use the process, not only from the people who designed it. A short survey and two or three interviews usually reveal where the structure creates friction. Change the smallest part that fixes the problem and announce the change plainly.

Data: location, training use, retention, deletion on exit
Security: certifications, incident notice, sub processors
Service: uptime, support, change notice periods
Commercial: price changes, exit and export terms

Key Terms

Operating model: The structures, roles, rules and routines that let an organisation run AI repeatedly.
AI council: A small senior forum that sets direction, policies and approval rules for AI use.
Center of excellence: A central team that provides platforms, standards, training and expert help to business units.
Hub and spoke: A model with a central team for standards and shared tools and business units that own use cases.
Risk tier: A level of review assigned to a use case according to the harm it could cause.
RACI: A table that shows who is Responsible, Accountable, Consulted and Informed for each decision.
Use case register: A list of all AI uses in the company with owners, data, risk tier and status.
Data processing agreement: A contract that sets how a vendor may process personal data for you.
Sub processor: A further company that a vendor uses to process your data.

Exercise: Draft Your Operating Model On Two Pages

Choose central, federated or hub and spoke for your company and write one reason.
List council members by title and write the three decisions only the council makes.
Define three risk tiers with one example use case in each.
Fill a RACI table for one use case from your week 7 process.
Write the first five lines of an acceptable use policy in plain language.
Create a vendor checklist with eight questions and test it on one real vendor.