A release process for applications employees build with AI

Useful prototypes without a support process

Management at a company within a corporate group asked me to organize how they handled applications employees were building with ChatGPT and Claude. These tools already helped with everyday tasks. The company wanted to preserve that initiative while establishing how to release and support them.

The applications were still rough prototypes, with security not properly addressed. There was no shared process for storing code, maintaining applications, deploying them more widely or giving colleagues access. It was unclear who would investigate a failure or continue working on a tool if its author left.

That uncertainty may be tolerable for a personal experiment. Once business processes depend on an application, reliance on a single author becomes a company risk.

My task was to design the workflow, define responsibilities and agree with the participants on the process from prototype to release and ongoing support.

Security risks that a working prototype can conceal

An employee building an application with AI is often not a developer. Their main concern is whether the tool solves their problem. They may miss technical risks such as access keys in source code, dependencies on personal accounts or unsafe settings. These can put personal data and company secrets at risk.

A working prototype is therefore not enough for release. Authors can handle some preparation with clear instructions, but a specialist needs to assess technical readiness and fix problems. Mandatory request fields help structure the handoff; they do not replace technical review.

More examples are covered in the article on applications employees build with AI.

A technical owner between the author and infrastructure teams

I separated the responsibilities of the application author, technical owner and infrastructure specialists. The employee completes the basic preparation covered by the instructions. The technical owner reviews the code, makes necessary improvements and takes responsibility for release readiness. DevOps deploys the prepared application through CI/CD to test and production environments.

The company had no specialist who could take technical responsibility for these applications. A prototype's author may not have software development or maintenance skills, while DevOps engineers and administrators should not be responsible for someone else's application code. I persuaded the business owner to hire a technical owner to take on employee projects, review them and prepare releases.

That responsibility continues after launch. When an application fails, the technical owner investigates first, then brings a specific issue to DevOps or administrators if needed. A specialist handles technical communication rather than an employee who may struggle to identify the cause.

Corporate code storage and a structured release request

I started with code storage: a dedicated section of corporate GitLab was set aside for employee applications. This keeps source code available to the company whether or not the author stays.

I then documented project preparation requirements and wrote deployment instructions for corporate GitLab. In particular, keys must be stored in variables rather than source code, and applications must not depend on their authors' personal accounts.

The instructions distinguish basic preparation that employees can handle from deeper technical work. Authors complete their part before handing over a project. The technical owner then reviews and improves the application against stricter release requirements.

At my request, an administrator created a dedicated release request form in the corporate service desk. It includes mandatory confirmations and cannot be submitted until all required items are complete. Employee-facing items cover preparation and risks the author can reasonably control by following the instructions.

Those confirmations remain in the request history, recording the information supplied at handoff. They document preparation; the specialist remains responsible for the actual review and technical readiness.

Why specialist review remains manual

I chose not to build a separate automated review system for these prototypes. There were few applications, they varied substantially, and they integrated with different systems. A dedicated review system would itself need maintenance. A part-time developer was a more proportionate choice for reviewing the applications before release and bringing them into working condition.

The route from employee prototype to deployment

Once the participants had agreed on the process, it went into use for employee projects:

1. An employee uses AI to build a tool for a work task.
2. The company prioritizes the project based on expected profit.
3. The author completes the required basic preparation before handing the project to the technical owner. Most of this work uses the same AI tools the employee used to build the prototype.
4. The technical owner takes projects in priority order, performs an in-depth review, improves the application and prepares it for release.
5. The prepared project goes to DevOps through a service desk request. DevOps deploys it through CI/CD to test and production environments on company infrastructure.

The queue is based on expected profit, not profit already earned. Tools from which the company expects a greater return are reviewed first.

Released applications now have source code in the corporate repository, a preparation history in the service desk request and a specialist responsible for their technical upkeep. After launch, the technical owner continues maintaining the application and coordinating with DevOps and administrators. An author's departure no longer leaves the application without an owner or company-accessible code.

Employees can still create their own tools with AI. New projects now follow an agreed path from personal prototype to a reviewed application prepared for operational use.