The AI Delegation Register - How to Track What You've Handed Off (and Why It Matters)
An AI delegation register is a shared document that maps every PM task to its current automation status: fully autonomous, AI-assisted, or human-owned. It makes your team’s AI adoption visible, portable, and reviewable - instead of a patchwork of personal automations that lives only in one person’s head.
Six months of serious AI use. A small stack of automations - a scheduled agent pulling risk signals from project channels, a prompt sequence drafting the weekly status pack, a few saved workflows handling meeting extraction. It works. It saves hours every week.
Then comes leave. A new programme. A new team member who needs to understand how the project actually operates.
And the realisation: none of it is written down. The automations live in one person’s accounts, their Claude Projects, their Make.com workspace. The team has been benefiting from them without knowing they exist. The PM is the single point of failure for their own AI operating model.
Figuring out what to automate has been the easy part. Treating automation as something the team owns collectively - not a personal toolkit that disappears when the person who built it moves on - that is the next step.
The Register Is Not a Tech Audit
An AI delegation register gets confused with an IT inventory - a list of tools, licences, and integrations. That’s not it.
The register is a task-level map. It answers one question for each PM activity: who’s doing this right now?
Not “what tool is being used.” Not “is this prompt saved somewhere.” The register records the operating model for each task - the current state of the delegation decision - so that it’s visible, shareable, and reviewable by anyone on the team.
In its simplest form, it’s a table:
| Task | Delegation Level | Human Review Step | Config Owner |
|---|---|---|---|
| Weekly risk extraction | AI-Assisted | PM reviews for context and political sensitivity | PM (Make.com) |
| Meeting actions summary | Fully Autonomous | None - low-consequence failure mode | Project coordinator |
| Stakeholder status update | AI-Assisted | PM edits for tone and relationship context | PM (Claude Project) |
| Budget variance commentary | Human-Owned | N/A | Finance lead |
That’s it. It doesn’t need to be complex to be useful.
Three Levels, Not Two
The instinct is to think of AI delegation as binary: either a human does the task, or an AI does it. In practice, there are three meaningful states.
Fully autonomous. The agent runs on a schedule, produces an output, and it goes directly into the workflow without a human review step. This is appropriate for well-defined mechanical tasks where the failure mode is low-consequence and correctable - formatting, populating templates, extracting structured data from consistent inputs.
AI-assisted. The agent produces a draft or a starting point. A human reviews, edits, and approves before it has any consequence. This is the right mode for tasks where the output is generally useful but requires contextual judgement - risk summaries that need a PM’s read on the project context, stakeholder communications that need a tone check, analysis that needs a sanity review before it shapes a decision.
Human-owned. The human does the task, possibly with AI input in the background, but the work is primarily theirs. This applies to anything where the quality depends on relationship context, political awareness, or the kind of accumulated project knowledge that hasn’t been written down anywhere.
The register isn’t trying to push everything toward “fully autonomous.” It’s trying to make the current state of each decision explicit - so the team can agree on it, maintain it, and evolve it deliberately.
What the Register Does That Ad-Hoc Automation Can’t
The practical value shows up in four situations.
Team handover. When a PM hands off a project - or takes leave - the register is the AI operating model briefing. The incoming PM knows exactly what’s running, what it produces, who reviews it, and where the configuration lives. There’s no rediscovery period. Nothing gets accidentally turned off because nobody knew it existed.
Onboarding new team members. A new analyst or coordinator joining the project can look at the register and understand immediately which tasks are automated, which outputs are AI-generated, and which require their direct attention. That context used to take weeks to absorb from osmosis. The register compresses it.
Quarterly capability review. The models change. New agents become available. A task that required constant human review six months ago might now be delegable. The register gives you a structured reason to ask: has the automation level on each task kept up with what’s now possible? That conversation is hard to have if you don’t have a baseline to compare against.
The leadership conversation. Increasingly, programme boards and project sponsors are asking how AI is being used on delivery. Not because they’re suspicious - because they want assurance that it’s being managed. A register is the answer. It shows that AI adoption on the project is disciplined, accountable, and reversible. That matters more than you might think when something goes wrong and someone asks how the risk summary got approved.
Start With What’s Already Running
The practical starting point isn’t a blank spreadsheet. It’s a quick audit of what’s already running.
Go through your project workflows and ask: which tasks are currently being done partly or fully by an AI tool? Write them down. For each one, record what the AI produces, what a human reviews, and whether that split is intentional or just how it evolved.
Most doing this for the first time will discover three things. There are more automations running than they consciously realised. Some of them have no review step that anyone has formally agreed to. And there are tasks that could be automated - that have been on the mental list for months - but haven’t been because there was never a structured conversation about it.
That’s the starting inventory. From there, the register becomes a living document - updated when something changes, reviewed quarterly, shared with anyone new who joins the project.
It’s not a governance exercise. It’s making visible the operating model that already exists - and making sure it scales with the team, not just the person who built it.
What’s the most useful automation running on your current project - and does anyone else on the team know it exists?
Yes, AI helped me to write this :)