Rollout plan for your AI project
Teams that own your systems can slow a project down when they hear about it late. This plan asks each of them early, with what they will want to see.
Timeline
- Week 1Ask the security team
- Weeks 1 to 2Ask the network team
- Weeks 2 to 3Ask the enterprise apps team
- Weeks 5 to 8Run the pilot
- Weeks 9 to 10Decide: scale, fix, or stop
Security team
What they’ll worry about
- Where does our data go, and who at the vendor can see it?
- What internal information could end up in prompts, and who can see the results?
- How are access and logs handled, and what happens when something goes wrong?
What to bring
- A one-page data-flow summary: what goes in, where it’s processed, and what comes out.
- The vendor’s security documentation, and your completed vendor questionnaire.
- The roles that will have access, and how access is granted and removed.
What to say
- “Our data [stays in our region and isn’t used to train the vendor’s models]. I’ll confirm that in writing.”
- “We’ll start with [five pilot users] and read-only access, and only expand after you’ve reviewed it.”
- “Logs are kept for [30 days], and [a named owner] reviews them [weekly] during the pilot.”
Network team
What they’ll worry about
- Which domains and ports does it need, and can we limit access to named users or devices?
- How much traffic should we expect, and what happens if the service goes down?
What to bring
- The list of domains, address ranges, and ports the vendor documents.
- The number of users and a rough traffic estimate.
- Which users or devices need access.
What to say
- “Access is for [named users] only, and the change is limited to [these domains].”
- “If there’s a problem we can roll back by [removing the allowlist entry].”
- “We expect about [number] requests at peak, and we’ll [monitor it] through the pilot.”
Enterprise apps team
What they’ll worry about
- Does it need access to our systems at all, or does it stand alone?
- How does it fit our release and change windows?
- Who owns it after the pilot?
What to bring
- A note on whether it connects to any system, and which.
- The permissions or API scopes it needs, and nothing more.
- A named owner for support after launch.
What to say
- “[A named team] owns support from day one.”
- “It’s read-only during the pilot, so it can’t change anything in your systems.”
- “We’ll schedule around your [change windows] and won’t ask for exceptions.”
The people side
- Name a sponsor who can decide when these teams disagree.
- Pick [5 to 10] pilot users who want to try it and will give honest feedback.
- Train them on what it can and can’t do, and which data stays out.
- Agree the success measures before the pilot starts, so the decision at the end isn’t an argument.
- Tell the wider team what is happening and why before the pilot begins.