The Role We Needed Before an AI Development Factory

The first idea was an AI development factory for people who were not developers. It would let them build work tools safely within set technical limits. We planned one process for creation steps, risk levels, and automatic checks. The aim was to support wider use while keeping control.

This defined the problem as who should build tools and how they should build them.

Field interviews challenged this starting point. Related teams were already using natural language tools to build what they needed. Their problems started after creation.

They could not easily find where data was stored. There was no place to check safety and accuracy. Problems with shared data and outside systems also required support beyond one tool maker.

What was the problem?

Another central creation tool would probably give field teams only one more choice. Existing tools would remain spread across different places. Data in personal accounts and storage would not return to central control.

Creation features alone could not remove delays in checks and system connections.

We changed the main problem. It was not a lack of creation ability. It was a lack of clear responsibility after creation.

Who would judge risks? Who would turn repeated features into shared features? Who would collect feedback from tools already in use? Releasing one platform would not solve these questions.

How I compared the choices

The main test was simple. We separated tasks that field teams could handle from tasks needing wider authority.

Tool creation was already happening in field teams. However, individual makers could not easily manage data location and access rights. Shared connections also needed support across the organization.

The cost of reversing a choice was also different. Teams could change how they created tools when needed. However, recovery became costly after sensitive data spread across many places.

The same was true when unchecked tools became widely used. Checks based on risk were more important than increasing use. We also needed to confirm real work results.

What I chose and did

We changed from designing a structure at a distance to joining field services directly.

The role was to collect needs and give advice and solutions to real services. It could also include development work when needed. The aim was not to stop or replace creation.

We wanted to connect these tools in a form the organization could manage.

The level of support would depend on risk. We would check data location, access rights, exposed keys, and connections to outside services. This included connections to large language models, which process and create text.

High-risk features, such as payments or account settlement, would need separate approval. A person would check sensitive results before teams used them in their work.

The interviews showed three main needs. These were checks, a shared base, and bringing separate tools together.

What happened and what remains

The confirmed change was a new problem definition and a new direction for the role.

The idea that we needed a factory did not match the facts from field teams. We documented a new direction based on direct work in checks and shared solutions.

However, there is still no evidence that this has become a working system or produced results.

Dedicated ownership and the investment level are not yet agreed. The meaning of success also remains open.

Release counts and usage numbers cannot fully show check quality or changes in work. We also need clear operating ownership and priorities. Otherwise, field support may become extra work carried by one person.

What I will do next time

Before planning a platform, I will first check what field teams already solved in other ways.

A central team should not focus only on features that field teams cannot build. It should own shared problems and risks that one team cannot manage alone.

Data ownership, check responsibility, and handover for ongoing operation should come before creation speed.

To change an idea, I need to look at real tools with field teams. I will not treat release as the end of the role.

Support should match the level of risk. Repeated problems should move into a shared base. The work should also include responsibility for operation after each decision.