WEEK 29 · ACCESS

Architect the YES on one blocked AI use case.

Blocking AI is a decision to go blind. Build the yes instead.

Submitted by Neil Watkins · MondayMove

Every "no" your team hands out on AI is a decision to go blind. The adoption happens anyway. You just lose the ability to see it.

Here is how the "no" actually plays out. You block the sanctioned tool. The work does not stop, so people route around you. They open a personal account on a personal device. They paste the same sensitive data into a worse channel, one with no logging, no retention control, and no seat at the table for security. The policy held. The risk went up.

This is shadow AI, and it is not a fringe behavior. It is the predictable result of a security function whose default answer is friction. When the safe path does not exist, people build an unsafe one, and they get good at hiding it.

So the question is not whether your people use AI. They do. The question is whether they use it somewhere you can see, shape, and govern.

Most teams think their job is to gate access, to stand at the door and decide who gets in. That framing always loses. Every gate you close pushes real usage toward the channel you control least. The stronger move flips it: your job is to build the path that makes the safe option the easy one. "No" scatters usage into the dark. "Yes, right here, with these guardrails" pulls it into the light you own.

That is not a policy exercise. It is architecture. Take one use case the org is blocking today, a team that wants ChatGPT, a developer who wants Copilot, an analyst who wants Claude, and design the version you could actually say yes to. What data does it touch? Which identity uses it? What access path, logging, and boundary make it safe? Write the one-page version, the one a skeptical CISO would sign.

So, here's the MondayMove

Find one AI use case your org is blocking right now, and architect the yes: map the data it touches, the identity that runs it, and the access path that makes it safe. Write the one-page version a CISO would sign.

Pick the loudest "no" in your backlog and turn it into a yes someone can run this week.

Friday Follow-Up

The Yes Was Never the Hard Part

Practitioners who ran the move found the block was easy. Writing the safe yes exposed what they never actually knew.

Submitted by Neil Watkins · MondayMove

July 17, 2026

MondayMove gives you one concrete action every Monday. FridayFollowUp closes the loop.

Each Friday, a short dispatch on what practitioners actually found when they ran the week's move: where they got stuck, what surprised them, and what to do next. Not sanitized case studies. Field notes. Practitioner to practitioner.

This week's move: find one AI use case your org is blocking, and architect the yes. Map the data, the identity, and the access path that make it safe, then write the one-page version.

The block was never the hard part. That was the first thing people reported back. Picking a blocked use case took five minutes, because everyone already had a list. Writing the yes is where it got uncomfortable. The one-pager kept stalling on the same line: what data does this actually touch? Several people found they could not answer it without going and asking, which told them more about their exposure than the exercise was supposed to.

The identity question tripped up the folks working on agent and service-account use cases. Proving a human is one thing. Proving which non-human ran the call, under whose authority, sent more than one person back to a whiteboard. A few realized the "yes" they wanted to write depended on a gateway that did not exist yet, so the honest one-pager became a small infrastructure ask, not a policy sign-off.

And a quieter pattern showed up. For some teams the "no" was load-bearing. It was doing emotional work, standing in for a control nobody had built. Turning it into a yes meant admitting the block was never really protecting anything, it was just deferring the decision. That stung a little, and it was the most useful thing the move surfaced.

What to do next: keep the one-pager, even the unfinished ones. The blank line you could not fill, the data you had to go ask about, the gateway you do not have yet, that is your real backlog. Next week, take the single most common gap across your one-pagers and close that, because it is almost certainly blocking more than one yes. Then publish the finished paved road somewhere people can find it, so the next request comes to you instead of going around you.

No correct answers here. This is practitioner-to-practitioner. The more honest the responses, the more useful this gets for everyone reading on Monday morning.

See you then.

Discussion