.png)
August 30, 2026
A moment keeps happening in our FlipWork™ Sprint cohorts.
A leader arrives confident that they understand AI. They have read the reports. They use the platform their company approved. They know the language. Then they watch AI research across sources, work from real context, create a finished deliverable, connect to other tools, or run a multi-step workflow.
And they stop me.
"Mine cannot do that."
Sometimes they are right. Their version cannot do that.
The model may be restricted. Web access may be off. Connected apps may be unavailable. The tool may be able to read but not act. Agent or scheduling features may not be enabled for their role. Two people can open the same product, see the same logo, and hold very different capabilities, because company permissions decide what each one can actually do.
There is a dicho everyone knows for this.
"No todo lo que brilla es oro." (Not everything that shines is gold.)
Except the problem here is subtler. It is gold. It is just not all of it, and no one told you how much they kept.
Usually, no one is trying to mislead anyone. IT and security teams are doing what they are accountable for doing: protecting company data, managing risk, and preventing a powerful tool from taking actions it should not take.
The problem begins when a limited rollout is presented simply as "AI."
A leader tests a permission-shaped version of the tool, gets chatbot-level results, and concludes that AI is underwhelming. Then that incomplete experience shapes budgets, strategy, talent decisions, and what the organization believes is possible.
You can read every study. You can sit through every vendor demo. You can forward every article to your team. None of that tells you what the technology does when you put real work in front of it.
The leaders who are getting this right are not better readers. They are practitioners. They have their own account, outside the company walls, where they test what the technology can actually do before they decide what their organization should be able to do with it.
You cannot lead what you have only observed from the surface.
The gap I see is no longer just between people who use AI and people who do not. It is between people who know what the technology can do and people who know only what their organization has currently allowed it to do.
1. An AI license is not a capability map. OpenAI's own enterprise documentation describes multiple control boundaries across workspace access, local tools, cloud execution, plugins, connected systems, and permissions. A request has to pass every boundary that applies to it. ChatGPT Work can complete multi-step tasks with files, applications, and tools, but only when those resources are available to the user and permitted by the workspace. In plain language, two people can open the same product and hold materially different capabilities. (OpenAI documentation) The access gap is measurable too. Deloitte found that 72% of respondents estimated fewer than 40% of their workforce had access to approved generative AI tools. (Deloitte)
2. Leaders are already working from an incomplete picture. In its Superagency in the Workplace research, McKinsey found that C-suite leaders estimated only 4% of employees were using generative AI for at least 30% of their daily work. Employees reported 13%, more than three times the leadership estimate. The same study found that only 1% of leaders considered their organizations mature enough to have AI fully integrated into workflows and producing substantial business outcomes. (McKinsey)
3. The real bottleneck is alignment between technology and the business. Gartner found that only 14% of surveyed IT application leaders strongly agreed that IT, business users, and leadership were aligned on the problems AI should solve. Organizations with that alignment were more than three times as likely to report significant value from their generative AI tools. (Gartner)
IT cannot know every workflow, judgment call, and opportunity inside every function. Business leaders cannot expect IT to infer what finance, marketing, legal, HR, operations, or sales will need next. The people closest to the work have to bring that context into the room. That only happens when those people have used the technology themselves.
Governance sets the boundary. Practitioners define the valuable work that should happen inside it.
Why we believe it: The logo is the same. The chat window is the same. The rollout email said we now have AI. So we assume we received the product we have seen demonstrated publicly.
Reframe: You may know what your current configuration can do. That is not the same as knowing what the technology can do.
AI capability is shaped by five things: the model, the context it can reach, the tools it can use, the actions it is allowed to take, and the workflows it can run. Remove most of those layers and a powerful work system becomes a chatbot.
This is where the myth does its real damage. A leader who mistakes a permission boundary for a technology boundary will underestimate what their people could be doing, underfund the work that would close the gap, and quietly write off a capability their competitors are already using. The conclusion feels like evidence. It is actually a configuration.
That does not mean every feature should be switched on for everyone. Some of those boundaries exist for good reason, and a leader who demands all of them removed has misread the room. It means leaders need to name which missing capability is blocking which valuable outcome, and bring that specific request to the people who own the risk.
You cannot name that gap from the inside of the restricted tool. You have to have seen the other side of it.
What to do: Stop asking IT for "more AI." Bring them one governed use case. Name the workflow, the data it needs, the specific permission required, the human approval point, and the result you will measure. That is a request a risk owner can actually evaluate.
ChatGPT Work is built for a different kind of interaction than Chat. Chat gives you an answer, explanation, brainstorm, or short draft. Work can take a clear goal, files, context, and approved tools and turn them into a finished brief, deck, analysis, recurring update, workflow, or other deliverable you can review. (OpenAI documentation)
That difference is what makes it useful for this week's experiment. The goal is not to ask a better question. The goal is to see whether AI can carry a real piece of work from source material to reviewable output.
Read this next part carefully, because it is the whole point of this issue.
I am asking you to run this test on your own, outside your company environment, in your own personal account. Not because your IT team is wrong. Because you cannot evaluate a ceiling you have never stood under. This is what becoming a practitioner actually looks like: you go find the edge of the technology on your own time, and then you come back to work knowing the difference between what the tool cannot do and what your company has not turned on.
⚠️ Security note before you start: Use only public, personal, synthetic, or company-approved material in this external test. No client names. No internal financials. No unreleased plans. No employee data. Never move confidential company information into a personal tool to get around a workplace restriction. The point is to learn the ceiling, not to route around your own governance.
Run this 30-minute test:
Prompt to steal:
I am testing the difference between getting an AI answer and delegating a complete piece of work. Using only the public, personal, or sanitized materials I provide, create [DELIVERABLE] for [AUDIENCE]. The result should help them [DECISION OR ACTION]. Before you begin, tell me which tools and sources you can access and ask any questions you need. Then complete the deliverable as a file I can review. At the end, list the capabilities you used, anything you could not access, the assumptions you made, and the human checks I should complete before using the work.
Also on my radar: Workspace agents that can repeat an approved process for a whole team. I am testing where they create real leverage and where the handoffs still break. I will go deeper once I have a practitioner view, not just a product announcement.
1. Map what you actually have. Open your company AI platform and inventory seven things: model access, web research, file access, connected apps, artifact creation, scheduled tasks, and agent or workflow capability. Mark each one Available, Restricted, or Unknown.
2. Activate this week's tool on your own. Run the 30-minute ChatGPT Work test above in your personal account, with non-confidential material only. Save the finished artifact and your capability list. You need evidence, not an impression.
3. Take one scoped request to IT. Use this structure: "For [TEAM], enable [CAPABILITY] for [SMALL PILOT GROUP] for [TIME PERIOD] so we can improve [WORKFLOW]. Limit it to [APPROVED DATA], require human approval before [HIGH-RISK ACTION], and measure [CYCLE TIME, QUALITY, OR BUSINESS RESULT]."
The conversation changes the moment you walk in having done the work yourself.
Do not grade the tool only on the prose it produces. Grade the whole workflow.
Did it find the inputs, organize the work, create the right artifact, show its assumptions, and leave you with something usable? Most people judge AI on one paragraph and stop there. That is testing a chatbot. Testing AI as a work system means watching what it does between your request and the finished file, because that middle is exactly where enterprise permissions either help you or quietly stop you.
Write down where it stopped. That note is your capability request.
AI fluency is not knowing the vocabulary. It is knowing the difference between what a tool cannot do and what your organization has not yet allowed it to do.
Until leaders can name that difference, they cannot lead AI adoption from evidence. They can only react to the version placed in front of them.
IT should not have to guess what every function needs. Leaders should not have to become technologists. They do have to become practitioners: close enough to the tools to recognize a valuable capability, define a real workflow, and help build the guardrails that make it safe to use.
That is the principle I keep coming back to. Adoption does not spread from a memo. It spreads when the leader has already done the thing.
Practice on your own. Find the ceiling. Then raise it with IT, one governed workflow at a time.
If this issue resonated and you want to become the informed practitioner instead of the leader reacting to whatever version landed on their desk, the next move is doing the work yourself. The FlipWork Sprint is where we work through exactly that with established professionals: the tools, practices, and operating rhythms for Agentic-Human Reinvention, so you can tell the difference between a technology limit and a permission limit, and lead the conversation that closes it. The next cohort kicks off September 3, and we are accepting late registrations through September 10.
"No todo lo que brilla es oro." (Not everything that shines is gold.)
What you were handed shines. Go find out how much of it is actually gold.
♻️ Share this with a leader who is judging AI by the version their company handed them.
¡Hasta la próxima, un abrazo fuerte! (Until next week, a big hug!)
