Define the AI system

Start with intended purpose

Controls cannot be selected responsibly until the system is defined. Begin with the outcome the system is intended to support, the people who use or are affected by it, and the decisions it may influence.

A useful intended-purpose statement includes:

• The business or public-service outcome.
• The approved users and affected parties.
• The inputs, data classes, and authoritative sources.
• The output and how it is used.
• The degree of automation and human responsibility.
• Explicitly prohibited or unsupported uses.
• The deployment and operating context.

Identify actors and responsibilities

List human and machine actors. Typical actors include a business owner, system owner, data owner, model approver, platform operator, application team, security team, assurance reviewer, end user, external provider, and incident responder.

For each actor, record:

Actor:
Decisions owned:
Permitted actions:
Privileged access:
Evidence produced or reviewed:
Escalation responsibility:

This prevents “the platform” or “the AI team” from becoming an undefined owner for material risk.

Inventory the system components

Include every component that can materially affect behavior or control:

• User interfaces and consuming applications.
• APIs, gateways, identity, policy, and tool brokers.
• Prompt templates, system instructions, models, adapters, and routers.
• Ingestion, parsing, embedding, retrieval, indexes, and source documents.
• Container images, packages, registries, build systems, and deployment automation.
• Compute, storage, networking, secrets, observability, backups, and evidence stores.
• External services, administrators, support paths, and update sources.

Do not limit the system inventory to the model.

Define lifecycle states

At minimum, describe how the system moves through proposal, design, build, evaluation, approval, deployment, operation, change, incident response, and retirement.

Controls and evidence differ by state. A model-evaluation report supports approval; a runtime access log supports operation; a deletion record supports retirement.

Write the one-page system definition

The output should be short enough to review but precise enough to anchor the architecture:

System name and version:
Owner:
Intended purpose:
Approved users:
Affected parties:
Inputs and data classes:
Outputs and decision impact:
Automation and human oversight:
Deployment environment:
External dependencies:
Prohibited uses:
Lifecycle state:

The system definition is a living control artifact. Update it when purpose, data, automation, model, deployment boundary, or ownership changes materially.

Next, use Trust boundaries and data flows to make the system’s control transitions visible.