How companies can make room for AI experimentation without losing control
AI can create useful capability inside far more workflows than a conventional use-case list suggests. Companies need a way to discover that potential without losing control of data, security, ownership and operational risk.
AI opportunities are wider than a use-case list
I think companies will miss a substantial part of the opportunity if they only look for a few centrally selected AI use cases.
Working with Claude Code and Codex has changed what I think is possible to build. Possibilities keep turning up in places I hadn't considered, from desktop applications and plugins to platform engineering and infrastructure. It has made me look differently at the work people do every day.
There may be a useful application around a task that is too specific to have attracted a software budget before. A team could build it for its own workflow, learn from it and change it as the work changes.
Give people room to experiment
People closest to a workflow can see possibilities that are difficult to specify in advance, so they need somewhere to try them. An experiment can reveal whether a tool removes repetitive work, helps someone make a decision or simply creates another thing to maintain.
That means making the boundaries usable. Which data can a team work with? Which systems can its tools access? What is it allowed to change, and who is responsible if something goes wrong? A small experiment with limited access can give people room to learn without giving it authority over customer records or business-critical processes.
Closing everything down prevents people from discovering what might help. Leaving responsibility and data access undefined creates problems that being experimental does not excuse.
The requirements should follow the risk
The requirements for a tool should follow what it can access, what its output is used for and what happens when it fails. A tool used by one person does not automatically need the availability and support arrangements of a core enterprise system. Being small does not automatically make it safe either.
I would make that distinction early. Let a team test a bounded idea quickly, then look at what happens when people use it. Keep the tools that prove useful. As others start depending on them, make support, testing, ownership and a way to recover from failure part of keeping them.
Some experiments will need stronger engineering before they can be used at all. Others can remain modest, short-lived tools. Treating both in the same way either adds unnecessary friction or overlooks a real risk.
The management question
For me, the management question is how to give people enough freedom to find useful applications while noticing when an experiment has become something the business relies on.