Skip to main content

Internal AI Catalog: Governed Models and Configs for Every Use Case

Most enterprises do not have an AI strategy problem. They have a discoverability problem. Teams know AI can help, but they do not know which model, route, config, or policy baseline they are supposed to use for each workload. In that environment, every team builds its own informal catalog in chats, tickets, and tribal knowledge. The result is low adoption for safe workflows and high adoption for ungoverned ones.

An internal AI catalog fixes that. But a useful catalog is not just a table of model names. It should tell teams which governed option fits drafting, coding, support automation, sensitive analysis, or regulated work. Keeptrusts already has the building blocks for that catalog: model groups, templates, Unified Access policies, versioned configurations, routes, and evidence from Events. The key is to publish them as a product, not just as infrastructure.

Use this page when​

  • You want employees and engineers to choose from approved AI options instead of creating ad hoc tool stacks.
  • You need a practical way to map real use cases to governed models and configurations.
  • You are trying to raise adoption of the governed platform by making it easier to understand than the shadow alternatives.

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Platform engineers, enablement teams

The problem​

Without a catalog, platform teams often overestimate how self-explanatory their governance is. They may know that there is a strong template for prompt injection defense, a zero-retention path for sensitive prompts, a lower-cost lane for high-volume drafting, and a premium route for complex reasoning. But if users have to ask around to discover those paths, they will default to whatever external tool already has momentum.

This is not only a usability issue. It creates governance drift. One team might use a premium model for routine support work because they do not know a lower-cost route exists. Another might handle sensitive material through a general-purpose path because nobody published the zero-retention option clearly. A third might duplicate a policy baseline that already exists as a template. The organization loses the benefits of standardization because the approved options are hard to find or hard to interpret.

The catalog must solve two jobs at once. It must make discovery easy for requesters, and it must keep implementation manageable for the platform. That is why the catalog should be built from real Keeptrusts abstractions, not from a slide deck or internal wiki page that drifts out of date.

The solution​

Start with governed logical names instead of raw provider identifiers. Model groups are the backbone of the catalog because they let you publish business-friendly or workflow-friendly names while hiding the provider details behind them. Templates provide the starting baseline for common patterns. Unified Access narrows model access by team, service user, gateway, or tagged resource. Versioned Configurations turn each catalog entry into a managed asset instead of a loose file.

The catalog can then be organized around work, not technology. For example:

  • support-assistant for customer support drafting and summarization.
  • developer-review for code-focused internal workflows.
  • sensitive-review for workloads that require ZDR or tighter approval.
  • economy-drafting for high-volume internal content generation.

Each catalog entry should say who it is for, which model group it maps to, which template or config lineage it came from, what retention posture applies, what budget expectations exist, and who owns changes to it. Keeptrusts already captures most of that information in its configuration and runtime surfaces. The catalog simply makes it visible and reusable.

Implementation​

One pattern is to define named model groups and publish those names as the internal product surface. That makes the catalog stable even when backend targets change.

providers:
  routing:
    strategy: weighted_round_robin
  model_groups:
    - name: support-assistant
      description: "Customer support drafting and summarization"
      targets:
        - openai-gpt4o-mini
    - name: developer-review
      description: "Internal coding and engineering assistant"
      aliases:
        - gpt-4
      fallback_group: economy-drafting
      targets:
        - openai-gpt4o
        - azure-gpt4o
    - name: sensitive-review
      description: "Sensitive analysis path with tighter controls"
      targets:
        - anthropic-sonnet
    - name: economy-drafting
      description: "Lower-cost path for large-volume drafting"
      targets:
        - groq-llama

This is only the routing layer. The catalog becomes operational when you pair it with the Configurations workflow. Save the relevant YAML versions, assign clear change details, and roll them out through monitored deployments. Then use Templates for standard starter patterns and Unified Access for access boundaries. That way, the catalog is not merely descriptive. It is enforced.

The internal operating model matters here. If a catalog entry supports a regulated workload, document that it should inherit a stricter template or ZDR posture. If it is intended for broad internal drafting, pair it with a wallet or budget boundary that supports high adoption without unpredictable spend. If one team needs a variation, publish that as a new versioned configuration rather than as an undocumented exception.

Results and impact​

The first improvement is adoption quality. Teams move faster because they are choosing from approved, named paths instead of researching providers from scratch. Support, engineering, operations, and compliance teams can all point to the same catalog entries when they discuss rollouts. The platform team spends less time answering repetitive selection questions because the choices are already curated.

The second improvement is governance consistency. When teams use model groups and versioned configurations as the catalog contract, the runtime behavior becomes easier to reason about. Events can be reviewed against catalog entries. Policy changes have named owners. Costs can be understood in terms of actual use cases rather than a raw provider list. This makes the catalog useful not only for enablement, but also for auditing, budgeting, and incident response.

Over time, the catalog becomes one of the most important adoption levers in the platform. Teams use the governed path because it is easier to understand, easier to request, and easier to support than the unofficial alternatives.

Key takeaways​

  • An internal AI catalog should publish approved use-case paths, not just provider names.
  • Model groups, templates, Unified Access, and versioned Configurations make the catalog enforceable.
  • Catalog entries should describe audience, use case, retention posture, budget expectation, and ownership.
  • Better discoverability improves both adoption and governance consistency.

Next steps​