Skip to main content

AI Products

What is an AI product

An AI product is a reusable capability for solving a recurring task class with AI. It can be an internal solution, service, platform, or functional block that plugs into different departments and scenarios.

The key difference from a one-off pilot is reusability. A pilot closes one case for one team. A product closes a class of similar tasks for many teams and outlives a single project.

Without a product layer, the company builds a new solution for every request: duplicates appear, the same task class is solved in different ways, pilots are not reused, IT and security re-review similar solutions, and impact cannot be measured. The product layer turns scattered solutions into a managed set of capabilities.


AI product characteristics

Every AI product — platform or applied — is described by one set of characteristics. They create a shared language: products can be compared, maturity assessed, and evolution decisions made.

CharacteristicWhat it describesWhy it matters
TypePlatform or appliedDefines the user and how the product evolves
Task classWhich recurring task class it closesThe core test: is there a product at all
Target audienceWho it is for: teams, roles, departmentsWithout an audience a product is not reused
OwnerWho is accountable for value and evolutionA product without an owner degrades
ReusabilityHow many scenarios and departments it can serveDistinguishes a product from a one-off solution
MaturityIdea, pilot, production, evolution, retirementDefines what to do with the product next
Risk profileAccess to data and systems, cost of errorSets the depth of control and approvals
Delivery trackHow the need is closed and driven to impact: artifacts, approvals, processesSets the implementation route for the product type and the risk of the automated process
Support loopWho maintains it after launchWithout support a product dies after the pilot
MetricsUsage, quality, impact, costShow whether the product is justified

These same characteristics form the minimum product card in the portfolio catalog — a single record that shows what the product is, who it is for, and what state it is in. The full card structure is defined in the AI product card artifact.


Two AI product levels

Type is the first product characteristic. By type, AI products split into two levels.

1. Platform AI products

Platform products are base technology capabilities on top of which applied solutions are built.

They do not always solve a business task directly, but they let the company quickly create, test, and scale AI scenarios.

ProductWhat it gives the company
Corporate LLMShared access to models, prompts, policies, logging, and guardrails
RAG platformSearch and answer generation over corporate knowledge
ML platformTraining, deployment, and monitoring of ML models
Code agentFaster development, code analysis, testing, and documentation
Agent runtimeEnvironment for running, controlling, and monitoring AI agents

Platform products answer:

Which base AI capabilities does the company have?

2. Applied AI products

Applied AI products are services built on top of platform capabilities and oriented toward a specific task class. They can use several platform products at once.

For example, a "Regulatory document assistant" can use an LLM to generate documents from templates, a RAG platform to find relevant information, and agents under the hood to automate routine steps.

ProductBuilt onTask class
Knowledge base assistantLLM + RAGDocument Q&A
Document generatorLLM + templates + workflow automationStandard document preparation
Project manager assistantLLM + RAG + MCP Atlassian + agent orchestratorStatuses, minutes, risks, plans
Inquiry analyzerLLM + ML classification + integrationsInquiry analysis, routing, prioritization
Developer assistantCode agent + repositories + docsDevelopment, review, tests, documentation
Compliance agentLLM + RAG + control rulesText, document, operation checks

Applied products answer:

Which recurring business tasks can the company already solve with AI?


Where to Find the Full Product List

The full list of classes is not duplicated on this page. It lives in AI product taxonomy: that page captures 18 market classes and maps them to the operational catalog of no more than 10 delivery tracks.

This page answers a different question: what counts as an AI product in the operating model and how to decide whether a recurring task class deserves a separate product. The taxonomy classifies the market and business requests; the AI product model supports a management decision inside the portfolio.


How to identify which AI products you need

A product portfolio is not designed top-down by picking trending technologies. It is derived from demand — bottom-up. The most practical way is to take the company's last 30–50 AI requests and run them through a simple exercise.

Step 1. Remove department names. Describe the functional need, not "AI for HR" or "contract review for legal." Behind a department name there is almost always the same task class.

RequestFunctional need
HR chatbotsearch and answer over internal knowledge
Contract reviewextract, compare, and check documents
Developer assistantgenerate, explain, and review code
Risk modelpredict probability, classify events, detect anomalies

Step 2. Cluster by verb, not by department. Almost all AI requests reduce to a small set of verbs: find, summarize, extract, compare, classify, generate, predict, automate, recommend. A verb that recurs across functions is a signal that you need a reusable capability, not another department-specific solution.

Step 3. Map verbs to products. Behind each recurring verb stands an AI product candidate.

What people needAI product candidate
Find answersKnowledge search / RAG
Process documentsDocument intelligence
Capture meetingsMeeting intelligence
Predict or scoreML platform
Automate stepsWorkflow automation / agents
Build tools fasterCode agent
Govern all AI initiativesAI governance platform

Step 4. Apply the 3×5 rule. A capability deserves to become a separate AI product only if it:

  • appears in at least 3 different functions;
  • can support at least 5 real initiatives;
  • has repeatable data, security, and delivery requirements;
  • can be configured rather than rebuilt for every case;
  • has a clear owner and roadmap.

If a candidate fails the 3×5 rule, it is still a project for a specific case, not a product.

Candidates split into two levels right away: what closes a task class for users is an applied product; what several applied products need at once (LLM access, knowledge search, running agents) is a platform product.

For each product candidate, decide build / buy / partner — build it, buy a ready solution, or partner; the choice depends on task uniqueness, data and security requirements, speed, and cost. Review the portfolio at least quarterly: the market of models and tools changes faster than most technologies, and some "build" decisions are eventually cheaper to replace with "buy."


Anti-pattern and right approach

Anti-pattern. Legal, HR, procurement, risk, and IT — every department asks for its own separate RAG. The company ends up with five similar solutions, five support loops, five architecture reviews, and five security approaches.

Right approach. The company sees a common task class — "search and answers over documents" — and develops one platform product, then builds applied assistants on top of it:

The base technology is one; the applied products are adapted to different classes of users and tasks.


Key principle

The company must manage not a stream of scattered requests, but a portfolio of reusable AI products through which those requests are closed. Without it, AI adoption becomes a set of disconnected pilots; with it, the company gets less duplication, faster delivery, clearer architecture, managed security, and transparent accountability.


Connection to initiatives

An AI product answers "which reusable capabilities the company has." How a company travels from a business need to confirmed impact through these products is the topic of the AI initiative portfolio: one product serves many tasks, and one task can use several products.