WPP × Wrike AI Pilot: risk controls overview
Warning The source deck is marked © Wrike, Inc. | Confidential. Treat this knowledge base the same way and do not publish it outside the teams involved in the Pilot.
What this is#
A working copy of the deck "WPP × Wrike — Pilot Risk Controls | Working Draft": Current controls, shared responsibilities and Pilot decisions. The deck assesses 18 numbered WPP risks against two ways of using AI with Wrike, and for each says what Wrike provides today, what WPP must confirm, and what the Pilot proposes.
The pages keep the deck's wording. Every table cell and screenshot is transcribed, with the slide number noted on each page so it can be checked against the PDF. Two pages are not from the deck: the discussion points added during conversion, and the empty discussion logs at the bottom of each page.
The two execution models#
| Wrike AI Agents | Assistant + Wrike MCP | |
|---|---|---|
| How it works | A builder sets up an agent inside Wrike and chooses where it acts. It runs like an automation within that setup. | A user works in an external assistant. The assistant calls Wrike tools through MCP to read or change work. |
| Where controls sit | Wrike provides creation permissions, a Space registry, location scope, action logs and individual-agent disablement. | Wrike checks access. WPP must confirm what its middleware/gateway and LLM assistant enforce for connections, tools, tokens and human approval. |
(Deck slide 2.) In short: for native agents the controls are mostly Wrike's. For MCP most of the controls to prove sit on WPP's side.
How to read the labels#
| Label | Meaning (deck legend) |
|---|---|
| Today | Wrike capability. What exists now. |
| Confirm | Setup or evidence that must be checked or shown. |
| Pilot | Proposed WPP process or control for the Pilot. (Slide 3 words it "proposed WPP process"; the later slides say "proposed control".) |
| Gap | A known shortfall, with no current control. |
| Note | Context or a limit to keep in mind. |
| Wrike / WPP / Joint | Used only on Pilot readiness: who is responsible for the item. |
Text in italics under a model is the deck's own cross-reference or "n/a" in place of a control.
Where to find things#
Working tools
- Open items tracker: every Gap, Confirm and Pilot item in one place, with owner and status columns to maintain.
- Risk register: the 18 risk numbers and every page that covers each one.
- Discussion points: questions raised while converting the deck. Not from the source.
Controls, by theme
| Page | Risks | Deck slides |
|---|---|---|
| Governance: ownership and visibility | #1, #7, #11 | 3–4 |
| Governance: review and action oversight | #6, #20, #21 | 5–7 |
| Identity and permissions | #3, #4, #15, #17 | 8 |
| MCP connections: approved apps and accounts | #3, #4, #16, #21 | 9 |
| Data scope | #2, #3, #6, #20 | 10–11 |
| Human review | #2, #6, #20 | 12–13 |
| Audit and traceability | #10, #12, #19 | 14–15 |
| Tools and data boundaries | #15, #16, #18, #21 | 16 |
| Disablement and incident response | #9, #14, #20 | 17 |
| Pilot readiness: responsibilities | Three risk groups | 18 |
| Official Wrike documentation references | n/a | 19–26 |
The deck's title slide is slide 1 and has no further content.
How to update this knowledge base#
- Edit the markdown file in
content/wrike-ai-pilot/. Use the Discussion log at the bottom of each page for decisions and outcomes. - When an item is agreed or evidenced, update its row in the open items tracker: set the owner and change the status.
- Keep the deck's original wording in the control sections. Record changes of position in the discussion log, with the date, so the original stays visible.
- Run
npm run buildto regenerate the site.
Suggested status values for the tracker: Open, In discussion, Evidence received, Agreed, Closed, Won't do.