What to Include in an Internal AI Service Catalog Entry

Write these six fields for every service. Anything less and consuming teams cannot make a decision.

ITIL-aligned guidance for service catalogs already recommends documenting service levels, costs, availability, request procedures and a service owner (ManageEngine). The AI-specific work is in making each field concrete enough to act on.

The owner field is where most AI catalog entries fail, because ownership is usually split between the team that built the model and the team that runs it. The RAND review of AI project failures, based on interviews with 65 experienced data scientists and engineers, found that misunderstanding what problem needs solving is the most common root cause, followed by missing data, technology-first thinking, inadequate infrastructure and tasks too hard for AI (RAND). Unclear ownership is the mechanism by which several of those failure modes go unaddressed.

Split the field into three roles:

• Accountable owner. One person, not a team alias. They approve changes to the service, own the review date, and answer for the service level.
• Operational contact. The on-call rotation or shared queue that receives incidents. Include the channel, the hours it is staffed, and the response target.
• Business sponsor. The person who funds the service and can decide to withdraw it.

Add a review date. A prompt or retrieval change can move output quality without any deployment event, so the passport needs a scheduled re-read. Quarterly is workable for services under active development, twice a year for stable ones.

This is the section engineers actually use, and it is where prose fails. Describe the contract the way you would describe an API.

For inputs, state what is accepted and what is rejected:

{
  "service": "contract-clause-extraction",
  "accepts": {
    "content_types": ["application/pdf", "text/plain"],
    "max_payload_mb": 20,
    "max_pages": 60,
    "languages": ["en", "es", "de"]
  },
  "rejects": [
    "scanned PDFs with no text layer",
    "documents containing embedded images larger than 5 MB"
  ],
  "required_preprocessing": "OCR with confidence above 0.90 before submission"
}

For outputs, state the shape, the units, and the failure semantics. If the service returns a confidence score, say what the score means and what threshold callers should trust. If it can return an empty result, say so and explain when that is correct rather than a fault. The cost-per-task framing is useful here: a single task can fan out into embedding generation, a vector lookup and a model inference, each billed differently, so the output description should note which downstream calls a request triggers (Keito).

Add a worked example of one request and one response, with the response redacted. A concrete pair resolves more ambiguity than a paragraph.

Traditional SLAs cover availability and response times. AI services need three more dimensions.

Availability. The percentage of requests the service accepts at all. This is separate from whether the answers are good.

Latency. Publish p50 and p95, not an average. Averages hide the tail that callers actually feel.

Quality. Define one measurable quality signal and how it is sampled. For an extraction service, that might be field-level accuracy on a fixed evaluation set, recomputed on every prompt or model change. For a classification service, it might be agreement with a human-labeled sample of 200 records per month.

Teams often measure the wrong things here. Metrics like number of automations, uptime, and percentage of budget used sound promising but do not reflect business impact (kyp.ai). A catalog entry that publishes uptime and nothing else tells a consuming team nothing about whether the service is worth wiring into a workflow.

Be explicit about what the service does not guarantee. If it is not approved for regulated decisions, for customer-facing text, or for data above a certain classification tier, say so in the entry. This is the field that prevents the worst incidents.

A cost basis is three things: the unit you count, the rate you apply, and the model by which cost lands on someone's budget.

The unit. Tokens, tasks, documents, or GPU-seconds. Because AI pricing is token-based, the same call can cost cents or dollars depending on prompt length, output length and model tier, so allocating by call count understates reality (Amnic). Pick the unit that matches how the consuming team thinks about its work, then show the conversion.

The rate. Publish it as an internal transfer rate and date it. Rates derived from a provider bill move, and consumers need to know when the number was last recalculated.

The model. Chargeback bills the consuming unit for what it uses and moves cost onto that unit's P&L. Showback reports the same numbers without moving money. The FinOps Foundation distinction is that chargeback sends expenses to a product or department P&L while showback keeps them on a central budget (Mavvrik). Common practice is to run showback for four to six weeks, confirm that attribution coverage holds, then switch (Amnic).

A worked example makes the cost basis legible. Suppose a document extraction service averages 12,000 input tokens and 900 output tokens per document, and runs 4,000 documents a month for one team. If you publish a blended unit rate per document, the consuming team can forecast without understanding token pricing at all. That is the point of the field: it should let a product manager build a budget without calling the platform team.

Cost allocation across an enterprise is rarely clean. A survey of 1,192 FinOps practitioners found 98 percent now manage AI spend, up from 31 percent two years earlier (Amnic). The catalog entry is where that management becomes attributable rather than aggregate.

Remember the human cost line. Human-in-the-loop review, correction and spot checks are real costs of running an AI service and belong in the unit economics, not outside them (Keito).

An escalation path without triggers is a phone tree. Write it as tiers with conditions.

Add a fourth, slower path for requests rather than incidents: new fields, higher quotas, new languages. Route those to the owner with a stated turnaround rather than letting them arrive as tickets.

Publish what a caller should include when they escalate: a request identifier, a redacted input, the output received, and the expected output. This shortens the first response meaningfully and gives you a feedback loop that feeds the evaluation set.

Treat the entry as a versioned document. A minimal front matter block gives you most of the governance value:

service: contract-clause-extraction
owner: [email protected]
backup_owner: [email protected]
version: 4
last_reviewed: 2026-02-14
next_review: 2026-05-14
status: live
data_classification_max: internal

Bump the version whenever inputs, outputs, service levels or cost basis change, and note the change in a one-line changelog at the bottom of the entry. Consumers who wired an integration need to know when the contract moves.

Retire deliberately. When a service is replaced, keep the entry in the portfolio marked retired, with a pointer to the successor and a date after which the old endpoint stops accepting traffic. Enterprises abandoned 42 percent of at least one AI initiative in a single year, up from 17 percent the year before, per S&P Global figures reported by Beam AI. Retirements are normal, and a catalog that handles them gracefully keeps trust.

One more habit: attach the original business problem statement to the entry, in the requester's words. RAND's interview study lists miscommunication about the problem to be solved as the leading cause of AI project failure (RAND). A catalog that preserves the problem statement next to the service description makes that failure mode visible to everyone downstream.

If your team is standing up several of these services at once and wants a single key across text, image, audio and embedding models rather than a separate vendor contract per service, Quanta Inference is built for that shape of work.