Turning AI into a service

In my previous post, I wrote about the challenge of finding value in enterprise software once the implementation is finished. The approach I used with customers was to stop treating the platform of choice as a tool and start treating it as a service.

In practice, that meant putting three things in place: an intake process for new use cases, a catalog for repeatable requests, and a small set of artifacts to make ownership, priorities and value visible.

I ended that post with a note that the same model might be worth revisiting for AI. While reading OpenAI's article on five AI value models, I felt like it was a useful structure to map my model against.¹

OpenAI's view in short

OpenAI describes five value models that are emerging most clearly in the Enterprise setting. I do not read them as a strict ladder and my interpretation is that they can cross-pollinate. OpenAI even points out in their article that an organization may work across several at the same time.

OpenAI groups the practical adoption path into three broader phases: build trust, capture value, then scale with potential to reconsider the operating model.

Where my service approach fits

The five value models describe where an organization may create value with AI. My service approach is more concerned with how a team receives demand, decides what to work on and turns a capability into something the organization can generate value from.

I therefore see it as a practical structure that enables the OpenAI value models rather than an alternative to it. The governance model runs as one connected process, and all of it stays in play whichever value model a piece of demand serves. The table below shows where that process adds the most to each value model.

Put against OpenAI's three adoption phases, the same logic holds: the whole process runs throughout, with the emphasis shifting. The model I propose could also be implemented on a per team basis to keep value-case processing and delivery as lean as possible.

What is the right AI implementation technique?

My original model separated demand into two lanes. The service lane handled predefined, low-complexity requests. The use-case lane handled work that was unique, less certain and potentially more valuable.

For AI, I would keep that split but change the intake a bit. The core assessment becomes: what is the right implementation technique? In practice there are four escalating options:

• A project with prompting: curated context and well-structured prompts for one role's repeated task. The fastest option, owned by the person doing the work.
• A skill: that same expertise packaged with instructions, examples and resources so anyone can invoke it the same way. A good skill can become a shared asset.
• A workflow: a defined sequence of steps with AI at fixed points. Software orchestrates the path instead of a model making a decision.
• An agent: the model runs the workflow or decides which workflow to run. It plans, uses tools and handles exceptions with guardrails set up.

The assessment then routes demand through the two lanes of my original model:

• Service lane: prompting projects, skills and existing AI capabilities. Repeatable requests with a known outcome, configured and delivered in days.
• Use-case lane: workflow and agent candidates — work with ambiguity, judgment or several systems involved, taken through a value and risk gate, a pilot and evaluation before a roadmap decision.

A proven use case graduates into the service catalog with whatever implementation technique was utilised: a skill others can invoke, a managed workflow, or a managed agent service with an owner, a defined scope, expected service levels and a known route for exceptions.

Mapping the service artifacts to an AI service

Most of my original service artifacts have a natural place in the structure of this AI service design but I think a few potential modifications or adjustments should be made:

Three key additions are critical from some form of governance:

First, evaluations and observability. The team needs a definition of good and a way to test against it.

Second, permissions at tool and action level. Reading a policy document is not the same risk as changing a customer record or approving a payment. The governance board has to take accountability here and make the teams lives easier.

Third, human intervention as part of the service design. By implementing these processes we can dictate early on what the guardrails should look like for human intervention.

Final thoughts

I have been working with a combination of these models for my current role for a while now and I think it works pretty well. I don't think it would hold up perfectly in an enterprise setting but I think with a few modifications it could work.

The idea I like the most within this post is the prospect of implementing this on a per team level. Imagine you placed an Applied AI Engineer into a business with these models as guardrails. Could have the potential for high impact, no? Curious to hear your thoughts. Feel free to send me direct messages or an email.