AITE-SAT: AI Solution Architecture Expert — Body of Knowledge Artifact Template

How to use this template

This template is the governance artifact for a centralized LLM gateway (the pattern described in Lab 4). Organizations that route all internal applications’ model calls through a single gateway use this policy record as the source of truth for what is allowed, what is redacted, and what is limited. The policy is enforced at runtime by the gateway’s policy engine (Open Policy Agent, Cedar, an internal rule engine, or equivalent); the template is the human-readable record that the engine’s rules implement.

The template has four primary sections (allow-list matrix, redaction pipeline, rate-limiting and cost-attribution, change-management workflow). All sections are required. Empty sections are rejected by review.

Organizations without a centralized gateway still benefit from the template as a checklist for embedded policy in application code, but the template is intended for a gateway-centralized posture where the policy is enforced in one place and audited from one place.

LLM Gateway Policy — [Gateway Instance Name]

1. Identification and ownership

2. Allow-list matrix

The allow-list is a matrix of (calling application × data class × client or matter context × jurisdiction) → permitted providers and configurations. It is expressed as rules in the policy-engine language; this section captures the rule set in human-readable form.

2.1 Dimension definitions

2.2 Rules (human-readable)

Write each rule in the form: “For [application] on [data class] with [context] in [jurisdiction], the allowed configurations are […] and the default is […]. Override to […] is allowed under [condition].”

Required rules at minimum (organizations add more as their application inventory requires):

1. Default permit rule. For internal applications on internal-class data with no client-matter context, in approved jurisdictions, the default configuration is [named configuration], with override to [alternate]. Rule applies unless a more specific rule overrides.
2. Restricted-class rule. Any request carrying restricted-class data must pass the redaction pipeline. Unredacted restricted-class requests are denied. Requests on restricted data after redaction may proceed only via [listed provider channels].
3. No-third-party rule. Any request attached to a matter flagged “no-third-party” must route to the self-hosted path only. If the self-hosted path is unhealthy, the request is denied with a typed error, not silently routed to a managed API.
4. Jurisdiction residency rule. Requests originating in [jurisdiction] must route to providers whose residency posture for [data class] is compatible. A rule per jurisdiction-data-class pair.
5. Deny-by-default rule. Any request that does not match a permit rule is denied.

2.3 Deny response contract

3. Redaction pipeline

3.1 Detection taxonomy

At minimum eight classes. For each class: what it detects, what implementation family (NER model, regex, deny-list, hybrid), what the false-positive and false-negative targets are, and what the evaluation set used to measure them.

3.2 Replacement policy

3.3 Output-scan policy

4. Rate-limiting and cost-attribution

4.1 Rate limits

4.2 Cost attribution

4.3 Multi-tenancy

5. Change-management workflow

6. Review and amendments

Amendment log with date, author, sections affected, re-approvals obtained. Emergency amendments are logged at the time of commit and reviewed within 10 business days.

Notes on use

When to use this template. Any centralized LLM gateway. Organizations without a centralized gateway still benefit from the template as a structural checklist.

Common errors in first-time use. Deny-by-default rule missing; redaction FP/FN targets unquantified; cost-attribution reconciliation cadence absent; change-management rollback SLO not stated; no emergency-change protocol. Reviewers treat these as blocking.

What follows. The policy record is cited from Template 1 §8 (security architecture). It is re-reviewed quarterly at minimum and whenever a new calling application, a new provider, a new data class, or a new jurisdiction enters scope.

© FlowRidge.io — COMPEL AI Transformation Methodology. All rights reserved.