[Enter short decision title]

[Enter decision ID]

[Enter date]

[ ] Proposed
[ ] Under review
[ ] Approved
[ ] Approved with conditions
[ ] Rejected
[ ] Superseded
[ ] Deprecated
[ ] Deferred

Name:
Function:
Email:

[Enter AI use case name]

[Enter inventory record reference or link]

[Reference intake, risk assessment, control assessment, assurance plan, vendor assessment, incident record, or other related documents]

[Describe the context that led to this architecture decision]

[Describe the business need or problem this decision addresses]

[Describe the technical environment, systems, platforms, data sources, vendors, tools, workflows, or integrations involved]

[ ] Copilot
[ ] Internal LLM application
[ ] RAG system
[ ] AI-enabled SaaS
[ ] Embedded vendor AI
[ ] Agent
[ ] AI-enabled workflow automation
[ ] Customer-facing AI
[ ] Employee-facing AI
[ ] Developer AI tool
[ ] Security operations AI
[ ] Decision-supporting AI
[ ] Action-capable AI
[ ] Other

[ ] Tier 1: Low-risk productivity or public-data use
[ ] Tier 2: Internal productivity with enterprise data
[ ] Tier 3: Decision-supporting AI
[ ] Tier 4: Action-capable AI
[ ] Tier 5: High-impact autonomous or regulated AI
[ ] Unknown / pending assessment

[State the decision clearly. Example: The AI use case will use user-delegated identity for retrieval and a separate agent identity for tool execution.]

[Summarize the decision in one or two paragraphs]

[ ] AI pattern
[ ] Model or AI service
[ ] Vendor or platform
[ ] Identity model
[ ] Data boundary
[ ] Retrieval architecture
[ ] Prompt/input control
[ ] Output/decision control
[ ] Tool/action control
[ ] Human accountability
[ ] Monitoring/logging/evidence
[ ] Assurance/testing
[ ] Incident containment/recovery
[ ] Operating model
[ ] Other

Option name:
Description:
Benefits:
Risks:
Control implications:
Reason accepted or rejected:

Option name:
Description:
Benefits:
Risks:
Control implications:
Reason accepted or rejected:

Option name:
Description:
Benefits:
Risks:
Control implications:
Reason accepted or rejected:

[Add additional options if required]

[ ] AI must be inventoried before it is trusted.
[ ] AI must not receive authority without identity.
[ ] AI must not access data without boundaries.
[ ] AI inputs must be treated as control surfaces.
[ ] AI outputs must not become decisions without control.
[ ] AI must not execute actions without control.
[ ] Human accountability must remain assigned.
[ ] AI must be tested before and after deployment.
[ ] AI must be observable and reconstructable.
[ ] AI failure must be containable.

[Describe how the decision aligns with or deviates from relevant principles]

[Describe inventory, classification, lifecycle, and risk-tier implications]

[Describe identity model, delegated authority, service accounts, agent identities, access review, and revocation implications]

[Describe data sources, data classification, retrieval boundaries, retention, training/reuse, and output sensitivity implications]

[Describe allowed inputs, prohibited inputs, prompt injection risk, system prompt protection, context isolation, and input logging implications]

[Describe output classification, validation, review, approval, generated records, downstream use, and correction implications]

[Describe tools, APIs, workflows, action classification, approval gates, blast-radius limits, kill switches, and rollback implications]

[Describe business owner, technical owner, decision owner, approver, escalation, override, and exception ownership implications]

[Describe required testing, validation, prompt injection testing, data leakage testing, tool/action testing, regression testing, and assurance evidence]

[Describe required logs, evidence, monitoring, retention, reconstruction, SIEM/SOC/GRC integration, and audit needs]

[Describe containment paths, revocation, kill switches, evidence preservation, rollback, vendor escalation, and recovery implications]

[ ] Direct user identity
[ ] Delegated user authority
[ ] Service identity
[ ] Application identity
[ ] Agent identity
[ ] Vendor-managed identity
[ ] Hybrid identity
[ ] Not applicable

[Explain why this identity model was selected]

[Describe systems, data, tools, APIs, workflows, and environments AI can access]

[Describe how access can be revoked, suspended, disabled, or rotated]

[Describe retrieval scope, filtering, access enforcement, classification restrictions, and tenant/user/session boundaries]

[Describe whether prompts, outputs, context, logs, embeddings, or interaction history may be retained or reused]

[Describe whether data is processed by a vendor, retained by a vendor, or used for training/product improvement]

[Describe allowed inputs]

[Describe prohibited inputs]

[Describe system prompt ownership, versioning, access control, testing, and rollback]

[Describe prompt injection mitigation, trusted/untrusted content separation, external content handling, and testing requirements]

[Describe context isolation across users, tenants, sessions, repositories, trust zones, and data classifications]

[Describe output types and impact]

[Describe validation, review, approval, or sampling requirements]

[Describe how AI recommendation is separated from final decision]

[Describe provenance, retention, correction, and record ownership]

[Describe controls before AI output is used by downstream systems or workflows]

[Describe allowed and prohibited actions]

[Describe approval gates for high-risk actions]

[Describe limits on records, users, amount, rate, systems, environments, or action scope]

[Describe kill switch, revocation, rollback, or compensation path]

[ ] Inventory record
[ ] Risk assessment
[ ] Identity/access approval
[ ] Data source approval
[ ] Prompt/input evidence
[ ] Retrieval logs
[ ] Output logs
[ ] Validation records
[ ] Decision evidence
[ ] Tool call logs
[ ] Action logs
[ ] Approval records
[ ] Exception records
[ ] Assurance test results
[ ] Incident evidence
[ ] Vendor evidence

[Describe logging approach, metadata/full content/redaction/reference-only, retention, and access control]

[Describe monitoring, alerts, anomaly detection, policy violations, SIEM/SOC integration, or manual review]

[Describe evidence retention period and storage location]

[ ] Design review
[ ] Pre-deployment testing
[ ] Prompt injection testing
[ ] Data leakage testing
[ ] Retrieval boundary testing
[ ] Output validation testing
[ ] Tool misuse testing
[ ] Approval gate testing
[ ] Logging completeness testing
[ ] Evidence reconstruction testing
[ ] Kill switch testing
[ ] Rollback testing
[ ] Vendor assurance review
[ ] Regression testing
[ ] Incident tabletop

[Describe what must pass before this architecture decision is considered ready]

[Describe changes that require retesting or architecture review]

[Describe benefits of the decision]

[Describe tradeoffs, limitations, risks, or operational burden]

[Describe risks that remain after the decision and required controls]

[Describe compensating controls if any control requirement cannot be fully met]

[ ] No
[ ] Yes
[ ] Unknown

[List conditions required for approval]

[ ] Approved
[ ] Approved with conditions
[ ] Rejected
[ ] Deferred
[ ] Requires additional review

[Document approval, conditions, rejection rationale, or next steps]

Name:
Function:
Date:

[ ] Model or provider changes
[ ] Vendor feature changes
[ ] System prompt changes
[ ] Retrieval logic changes
[ ] Data source changes
[ ] Tool/API access changes
[ ] Workflow changes
[ ] Risk tier changes
[ ] Incident occurs
[ ] Assurance finding is opened
[ ] Regulatory requirement changes
[ ] Business process changes
[ ] External exposure changes
[ ] Production scale increases
[ ] Exception expires

[Enter date]

Decision ID:
Decision title:
Use case:
AI pattern:
Risk tier:
Decision:
Key rationale:
Required controls:
Required evidence:
Required assurance:
Exceptions:
Approval status:
Next review date: