Map — A system purpose and prohibited-use statement.
Define user, input, output, action and harm boundary.
Capability record · Reviewed 2026-09-03
AI systems engineering
Build AI-enabled applications as controlled product systems, not isolated model demonstrations.
01
Fit
When this capability belongs in the delivery path.
- 01
An AI feature must connect to an existing workflow, API, product or decision.
- 02
A prototype needs a route into controlled pilot use.
- 03
A team needs to define safe boundaries for prompts, tools, data and review.
02
Typical work
The work is shaped around a bounded operational outcome.
- 01
AI-assisted workflow design, prompt/instruction architecture and bounded tool use.
- 02
Retrieval, grounding, policy, permission and exception design.
- 03
Evaluation assets, human-review routes and operational release records.
03
Workflow
A delivery sequence with an output at every gate.
Engineer — A controlled workflow configuration.
Build the application boundary around model, data, tools and UI.
Evaluate — A versioned evidence record.
Test representative and difficult cases before release.
Operate — Monitoring, review and pause routes.
Observe exceptions and changes in use.
04
Technical decisions
Evidence and boundaries stay beside the decision.
What may the system do?
User workflow, tool contract and human authority. Boundary: Model output is not independent authorisation.
How is output grounded or reviewed?
Source context, evaluation cases and escalation route. Boundary: Fluent output is not proof of correctness.
What changes need re-evaluation?
Model, prompt, retrieval, tool and policy version record. Boundary: Provider change is not automatically minor.
05
Practitioner notes
What this capability means in the work itself.
Treat the model as a component
A useful AI product description identifies more than a model name. It explains what information enters the workflow, how instructions and retrieved context shape the output, which tools can be called, which user receives the result, and whether the result can cause a material action. This avoids the common error of evaluating a model in isolation and then assuming that the production application behaves the same way. A model can be capable while the surrounding product still has weak permissions, ambiguous user language, stale context or no safe path when the answer is uncertain.
Define a narrow action boundary
The first version of an AI-enabled workflow should be deliberate about what the system may propose, what it may prepare, and what it may do only after a person confirms it. A drafting assistant might summarise a case and prepare a response, while the accountable employee reviews facts and sends it. A tool-calling assistant might retrieve an approved record but not change it without a scoped operation and confirmation. These boundaries should reflect the actual impact of an error. The objective is not to remove people ceremonially; it is to make authority, review and intervention meaningful in the real workflow.
Build evaluation around decisions that matter
A demonstration set full of easy examples does not establish readiness. Evaluation cases should include representative inputs, incomplete or conflicting information, instruction conflicts, tool errors, requests outside intended use and cases where the right response is to ask for clarification or decline. Reviewers need a rubric that distinguishes factual support, task completion, safe handling and appropriate escalation. Results should be tied to the exact configuration being assessed. This lets a team see patterns in failure rather than reporting a single, overly broad accuracy number that cannot guide a release decision.
Keep change visible
AI systems change through more than code deployments. A model version, system instruction, retrieval source, tool schema, policy rule or user interface can alter behaviour. The operating record should make these changes traceable enough to answer a basic question after an issue: what configuration was active, who approved it and which evaluation evidence applied? This need not mean retaining every internal experiment forever. It means treating behaviour-changing changes as a product and risk decision, with a proportionate re-evaluation route rather than assuming that a provider update is invisible to the application.
Plan for uncertainty in the interface
The interface is part of the AI safety boundary. It should help a user understand what the system has done, distinguish source material from generated content where relevant, and provide a clear route to correct, escalate or abandon an unsuitable result. A confident visual treatment can unintentionally make weak output appear authoritative. Conversely, an unexplained warning can make a useful assistant impossible to use. Product and engineering teams should test whether people can recognise the limits of the result and still complete the work efficiently. That is a usability and governance question, not a styling detail.
Set a pilot boundary before people depend on it
A controlled pilot needs an explicit audience, task, period, support route and exit decision. It should not be framed as a hidden production rollout simply because the interface is polished. The team can state which inputs are permitted, what users should not use the system for, how feedback is captured, and when the configuration will be reviewed. A pilot may reveal that the use case needs more data preparation, a different interaction model or a narrower tool permission. That is useful evidence. The point is to learn under agreed conditions while preserving a credible route to pause or change course if the workflow does not meet its acceptance boundary.
06
Acceptance
Evidence expected before the next release decision.
- 01
The complete configured workflow is evaluated, not only a base model.
- 02
Tool permissions and error paths are exercised.
- 03
Owners can explain expected behaviour, limits and the intervention route.
07
Dependencies
Inputs and owners the capability cannot manufacture alone.
- 01
A defined use case and representative authorised inputs.
- 02
Product, security, privacy and operational ownership proportionate to the workload.
- 03
Current provider documentation for selected capabilities and terms.
08
Risks and limits
Where a careful answer stays conditional.
- 01
Evaluation cannot eliminate all uncertainty or future drift.
- 02
AI assurance is not an ISO certification or regulatory approval.
- 03
Higher-impact uses may need specialist sector and legal input.
Direct answers
Questions about ai systems engineering
01Can an AI system act automatically?
That depends on the workflow, permissions, impact and controls. The action boundary must be designed and reviewed explicitly.
02Does a model choice solve product risk?
No. Product, data, integration, human oversight and operating controls remain necessary.
Source discipline
Primary guidance and technical references
A practical next step
Use this capability inside a real delivery decision.
Share the workflow, existing systems, constraints, risk and evidence you need from the first useful release.
Discuss the work