Skip to content

Command Palette

Search for a command to run...

For enterprises

Roll AI out in stages, with owners and exit criteria

Enterprise AI fails less from model quality than from unclear ownership: nobody decides which tools are approved, what data they may see, or who can switch them off. Move through the stages and do not advance until the exit criteria are true.

Rolling AI out across an organisation
1 / 4Assess

Step 1 of 4

Assess

Find out what AI is already in use, what data it touches and who owns it. Build an inventory by asking teams, then look for tools nobody listed, and set the rule for which data may reach which tool.

Governing is not the end: what you learn changes what you assess next.

  1. Stage 1

    Assess

    Know what AI is already in use, what data it touches and where you stand, before adding more.

    Actions

    • Build an inventory by asking each team, then look for tools nobody listed
    • Classify data and decide which classes may reach which tools and models
    • Define a small set of risk tiers and the controls each requires
    • Place the organisation honestly on a maturity scale, and score candidate use cases

    Move on when

    • Every known AI system has an owner and a tier in the inventory
    • A data-class-to-tool rule is published in plain language
    • Named people hold security and evaluation decisions

    Owners: Head of engineering, Security lead, Data owner, Legal and risk contact

  2. Stage 2

    Pilot

    Prove the controls on one well-scoped, internal use case with a clear owner and a measurable outcome.

    Actions

    • Stand up the AI gateway as the only path to a model call
    • Give the pilot its own agent identity and an approved model
    • Build a reviewed evaluation set and measure a human-only baseline
    • Add tracing and cost dashboards before anything sophisticated

    Move on when

    • The pilot passes its evaluation set and beats or matches the baseline
    • No direct provider calls bypass the gateway
    • Logs show the pilot's actions under its own identity

    Owners: Product owner, Platform engineering lead, Security reviewer

  3. Stage 3

    Scale

    Add a small number of use cases deliberately, with the gates that make scale safe rather than reckless.

    Actions

    • Prioritise use cases that reuse the pilot's sources, tools and patterns
    • Add an evaluation regression gate and a red-team set to CI
    • Apply least-privilege tools, a declarative policy and approvals for irreversible actions
    • Finalise the model catalogue and a short new-use-case review checklist

    Move on when

    • Each use case has its own identity, evaluation set and tier
    • The CI gate blocks a deliberately degraded change
    • The kill switch has been tested on a non-production agent

    Owners: Engineering managers, Platform engineering lead, Security lead

  4. Stage 4

    Govern

    Make the controlled way the default way, with a record, a rhythm of review and a rehearsed response.

    Actions

    • Open the gateway, identity and evaluation tooling to other teams as a documented platform
    • Make the audit trail queryable by security and compliance without engineering help
    • Run a tabletop incident exercise and fix the gaps it finds
    • Schedule recurring maturity and inventory reviews, and feed lessons back into the SDLC

    Move on when

    • New use cases go through the review checklist by default, not by exception
    • An incident rehearsal has been run and its gaps have owners
    • The next review is in the calendar, not left to chance

    Owners: Chief technology officer or equivalent, Security and compliance leads, Platform owner

Go deeper

Get the controls for your environment

Choose the environment and risk tier for a platform-owner view of the controls.

Open the enterprise checklist →