# Controlled AI Reference Architecture

Status: Sanitized reference pattern

Author: Robert Ganey

Purpose: Demonstrate the architecture decision method used to translate regulated AI requirements into an implementable system boundary. This is not an employer artifact, tenant design, controlled-data diagram, or production deployment record.

## 1. Decision statement

Enable an approved user population to perform bounded AI-assisted work while keeping data classification, identity, model access, logging, evaluation, and release decisions explicit and reviewable.

## 2. Assumptions

- The workload may include data that requires additional handling controls.
- Users, data sources, and model endpoints cannot be treated as one trust zone.
- A model response is untrusted output until the use-case-specific review condition is met.
- Platform availability is not equivalent to authorization for a use case.
- A successful prototype is not evidence of production readiness.

## 3. Logical boundary

1. Approved users authenticate through the enterprise identity plane.
2. Authorization combines user role, workload approval, and data classification.
3. Approved data enters a workload-specific resource boundary.
4. The orchestration layer calls only approved model deployments and tools.
5. Prompts, tool activity, policy decisions, and relevant outputs create an auditable event trail.
6. Evaluation and human review gates determine whether output can affect a business process.
7. Release, rollback, and incident ownership remain explicit human responsibilities.

## 4. Control domains

| Domain | Design question | Minimum decision |
| --- | --- | --- |
| Identity | Who can reach the workload and in what role? | Named groups, least privilege, separation of administration and use |
| Data | What can enter, persist, or leave the boundary? | Classification, approved stores, retention, egress rule |
| Model | Which model and endpoint can process the workload? | Approved deployment, version, region, evaluation record |
| Tools | What external action can the model request? | Allowlist, scoped credentials, confirmation rule, failure behavior |
| Observability | What must be reconstructable after an event? | Decision logs, tool calls, errors, model and configuration versions |
| Operations | Who approves release and handles failure? | Owners, acceptance gates, rollback path, incident route |

## 5. Architecture decisions

| ID | Decision | Reason |
| --- | --- | --- |
| ADR-01 | Separate platform eligibility from use-case authorization | A compliant platform can still be used in a non-compliant way |
| ADR-02 | Bind access to workload-specific groups | Broad tool access obscures accountability and data boundaries |
| ADR-03 | Use approved managed model endpoints | Version, region, policy, and capacity must remain identifiable |
| ADR-04 | Treat tool calls as privileged operations | Model reasoning does not replace authorization or confirmation |
| ADR-05 | Retain decision-relevant telemetry | Quality, security, and incident reviews need reconstructable evidence |
| ADR-06 | Evaluate the real workflow, not only the base model | System behavior depends on prompts, retrieval, tools, and users |
| ADR-07 | Make rollback a release prerequisite | Safe operation requires a known path out of a bad change |

## 6. Acceptance gates

### Gate A: Boundary approved

- Users, data classes, stores, endpoints, tools, and owners are named.
- Prohibited flows and unresolved authorization questions are visible.

### Gate B: Controls verified

- Access is tested in the intended user context.
- Logging, retention, key handling, and egress behavior match the design.

### Gate C: Workflow evaluated

- Representative tasks, failure modes, unsafe requests, and human-review conditions are tested.
- Results are versioned with the model, prompt, retrieval source, tool set, and configuration.

### Gate D: Operations ready

- Release owner, support route, rollback procedure, incident route, and change process are documented.
- Production readiness is not declared until all mandatory evidence is accepted.

## 7. Threat and failure register

| Failure | Required response |
| --- | --- |
| Unauthorized user or workload | Deny access and log the policy decision |
| Data classification is unknown | Stop processing and route for classification |
| Model or tool version drifts | Invalidate affected evaluation evidence |
| Retrieval source is stale | Show staleness and prevent unsupported high-impact action |
| Tool action exceeds scope | Deny, log, and require explicit reauthorization |
| Output fails a quality gate | Contain the output and preserve evidence for review |

## 8. What this artifact proves

It shows a concrete method for converting ambiguous requirements into architecture decisions, controls, verification evidence, and accountable release gates.

## 9. What this artifact does not prove

It does not disclose or reproduce a private employer design. It does not claim that this reference architecture is deployed, certified, or sufficient for any specific regulatory authorization.