AI Workflow for Systems Engineers & Architects

Short answer: give AI a narrow research-and-drafting role around a human-owned decision record. First establish the actual problem, requirements, data boundary, constraints, authorities, and sources. Then let AI create a transparent comparison and question list. A named owner—not the model—verifies facts, chooses an option, accepts residual risk, and authorizes every implementation or operational action.

Do not enter restricted material. Never put secrets, credentials, private diagrams, customer data, production logs, source code, or access-controlled material into an unapproved AI service. This manual produces a draft review packet, not a security assessment, architecture approval, configuration change, procurement decision, or production action.

The useful boundary

Safe for a bounded assistant

Turn approved non-sensitive notes into a requirements ledger; identify contradictions; draft questions; compare stated options; map claimed interfaces and trust boundaries; prepare an ADR; and flag missing evidence or reviewer routes.

Always human-owned

Source truth, data classification, architecture selection, risk acceptance, threat-model scope, security/privacy/legal/compliance judgment, spending, vendor terms, access, code/configuration, tests, deployment, rollback, incident actions, and messages.

The occupational source describes systems engineers/architects as solving complex application, administration, network, management, and integration concerns. NIST guidance supports visible alternatives, constraints, traceability, baselines, and evidence; it does not award approval authority.

Build the seven-part Architecture Decision Evidence Desk

Name one decision, not a vague modernization effort

Write the outcome, system boundary, excluded systems, decision deadline, accountable owner, affected people, and material consequences of being wrong.

Output: decision card

Separate facts from assumptions

For every requirement, interface fact, dependency, cost statement, and constraint, retain a source, version, date, verifier, and expiry. Mark unknowns instead of asking AI to fill them.

Output: source & assumption ledger

Set the AI boundary before the prompt

Use only approved, minimum-necessary, non-sensitive information. State forbidden inputs and actions. Keep the original sources beside the AI summary so a reviewer can challenge it.

Output: AI job card & receipt

Compare real alternatives against stated constraints

Ask AI to organize, not decide: option, requirement coverage, tradeoff, unknown, reversibility, dependency, and owner. Include defer/do-nothing when it is a real option.

Output: alternative matrix

Expose boundaries and questions

Map components, interfaces, data flows, trust boundaries, dependencies, failure paths, and open threats. Use the OWASP questions: what are we working on, what can go wrong, what will we do, and did we do enough?

Output: boundary & threat question set

Draft a decision record without pretending it is accepted

Capture context, evidence, options, non-decision, consequences, unresolved risks, required approvals, and review expiry. Its state is proposed or needs_review until named authority acts.

Output: ADR draft & review route

Stop at the handoff

Package the exact evidence, questions, limitations, and named reviewers. If a gap affects safety, security, privacy, money, obligations, rights, or production, return insufficient_evidence—not a recommendation.

Output: approval-ready packet

Give AI jobs, not invisible authority

Bounded role	Approved input	AI output	Human gate
Evidence clerk	Approved source extracts and constraints	Fact/assumption table and gap list	Source owner checks fidelity
Option mapper	Named alternatives and evaluation criteria	Comparison matrix and contradictions	Architecture owner selects or rejects options
Boundary scribe	Approved component/interface descriptions	Question set and draft boundary map	Security/privacy owners validate scope
ADR drafter	Reviewed evidence and unresolved questions	Proposed ADR with consequences	Named authority accepts, changes, or supersedes it
Handoff clerk	Reviewer list and retained evidence	Approval checklist and open-risk route	Authorized owners decide any next action

Failure modes that make an architecture packet unsafe

Invented environment facts

A fluent diagram or inventory can be wrong. Keep original source, version, verifier, and uncertainty visible; never turn an inference into an interface fact.

One option disguised as analysis

If alternatives, criteria, consequences, reversibility, or dissent are absent, the packet is advocacy, not decision evidence.

Threat list treated as a threat model

AI can prompt questions, but the responsible security process determines scope, likelihood, controls, evidence, and residual-risk acceptance.

Draft mistaken for authority

An ADR draft is not an accepted decision. A checklist is not a change ticket. No button in this page can configure, test, deploy, buy, or message anyone.

Run the worksheet: produce a review-only handoff

Use a fictional or approved non-sensitive scenario. This local form only composes text in your browser; it sends nothing and saves nothing.

Decision and outcomeVerified constraints and sourcesNamed alternatives and tradeoffs

Boundaries, data flows, and open questionsNamed reviewers and prohibited actions

Primary source desk

O*NET: Computer Systems Engineers/ArchitectsOccupation and task context; it grants no change or approval authority.NIST SP 800-160 Vol. 1 Rev. 1Trustworthy systems, architecture alternatives, stakeholder concerns, traceability, baselines, and evidence.NIST SP 800-160 Vol. 2 Rev. 1Cyber-resiliency views, architecture models, boundaries, and information flows.NIST AI RMF resourcesCurrent resource index; the AI RMF 1.0 revision is underway.NIST AI 600-1: Generative AI ProfileTailored risk-management considerations for generative AI.OWASP Threat Modeling Cheat SheetSystem modeling, threat identification, mitigation, review, and validation prompts.Architecture Decision Record repositoryMaintained open-source templates and lifecycle guidance; not a standard or approval workflow.

Next route: once a named authority has accepted the architectural route, use the Software Developer manual for implementation evidence, the Software QA manual for test/release evidence, or the Web Administrator manual for post-launch change and incident handoffs. Those are distinct stages, not permission to act automatically.