Designing governed AI solution architectures
5 Tasks
30 mins
Scenario
A large enterprise plans to modernize three business processes by using AI and automation. Previous experiments placed document interpretation, business decisions, external integrations, and content generation in a single component. The resulting designs were difficult to govern, explain, and maintain.
The architecture review board asks you to redesign the processes based on these scenarios:
Insurance claims intake
A claims team receives scanned claim forms and email correspondence. Claims adjusters manually enter claim information and search policy documentation for coverage guidance. The current process causes delays and inconsistent coverage decisions.
Employee expense review
An expense Case sends selected transactions to an external fraud-assessment service. The architecture must coordinate Workflow conditions, optional agentic planning, delegation to an external agent, access to external tools, and generation of an approver summary.
IT service desk voice channel
An IT service desk handles password resets and access requests through a telephone channel. The design must support flexible conversations while protecting account-changing actions through identity confirmation, governed processing, exception routing, and human assistance.
For each scenario, create an architecture decision record that assigns each responsibility to the appropriate feature, explains why competing alternatives are not appropriate, and preserves governance, auditability, and separation of concerns.
Challenge tasks
Task 1: Understand the process participants
Identify the people, objectives, process challenges, and risks in each scenario.
Task 2: Define architecture responsibilities
Convert each business problem into a responsibility map without selecting products or features.
Task 3: Explore architecture alternatives
Evaluate candidate features and identify the risks of assigning multiple unrelated responsibilities to one component.
Task 4: Create the solution architecture
Assign a feature, control, input, output, and fallback path to each responsibility.
Task 5: Test and defend the design
Evaluate the architecture against normal, uncertain, exception, and high-risk conditions.
The following table provides the credentials you need to log in to the Delivery Service application. However, this challenge mainly focuses on evaluating the design options and includes no specific implementation tasks.
| Role | User name | Password |
|---|---|---|
| Application Developer | admin@deliveryservice | rules |
Detailed Tasks
1 Understand the process participants
- Review the three business scenarios.
- For each scenario, identify the people who interact with or depend on the process.
- Record the primary objective of each person.
- Identify the current process challenge that prevents each person from achieving that objective.
- Record the consequences of an incorrect, uncertain, or unexplained decision.
- Complete an empathy map for each scenario by using the following questions:
- What information does the person provide?
- What outcome does the person need?
- Which decisions require consistency?
- Which inputs contain ambiguity?
- At which point does the person need an explanation?
- At which point must a person review or approve the result?
Expected result
Your empathy maps describe business and governance needs without naming a technical solution.
2 Define architecture responsibilities
- Divide each process into individual responsibilities.
- Classify each responsibility by using one of these categories:
|
Responsibility |
Description |
|---|---|
|
Interpretation |
Convert unstructured or ambiguous input into structured information. |
|
Retrieval |
Find relevant information from an approved source. |
|
Decisioning |
Apply defined business criteria to known data. |
|
Orchestration |
Coordinate the sequence and conditions of work. |
|
Delegation |
Assign an objective to another agent. |
|
Tool access |
Invoke a specific external operation. |
|
Generation |
Produce bounded natural-language content. |
|
Control |
Apply identity, approval, confidence, or authorization requirements. |
|
Human review |
Route work to a person when automation cannot proceed safely. |
- Define the input and expected output for each responsibility.
- Identify whether each responsibility is deterministic, probabilistic, generative, or human-owned.
- Mark the responsibilities that require an audit record.
- Write a design question for each scenario by using this format: How can the organization [business outcome] while [governance or user constraint]?
Sample design questions
- How can the claims team reduce manual intake work while retaining deterministic coverage decisions?
- How can the expense process use an external fraud service without combining orchestration, delegation, tool access, and summarization?
- How can the service desk support conversational password-reset requests while preventing unverified account changes?
Expected result
Your responsibility map separates business concerns before selecting an implementation feature.
3 Explore architecture alternatives
- For each responsibility, identify at least two candidate implementation approaches.
- Evaluate each candidate against these criteria:
- Nature of the input
- Required consistency
- Explainability
- Auditability
- Need for contextual reasoning
- Need for multistep planning
- Human-review requirement
- Failure and fallback behavior
- Identify any design that assigns unrelated responsibilities to a single AI, agent, workflow, or decision component.
- Label the design as a responsibility-overload anti-pattern.
- Explain one likely governance or operational consequence of the anti-pattern.
- Select the preferred approach for each responsibility.
Expected result
A responsibility-to-implementation mapping that identifies the preferred approach for each responsibility, including relevant anti-patterns and their governance or operational consequences.
4 Create the solution architecture
- Create one architecture diagram for each scenario.
- Represent each responsibility as a separate architecture component.
- Label every connection with the information, objective, or command that passes between the components.
- Add human-review paths for low-confidence, unsupported, uncertain, or high-risk outcomes.
- Add the control points that must be completed before a transactional or account-changing action.
- Complete an architecture decision record for each major decision using the information below.
| Field | Description |
|---|---|
| Decision | State the architecture decision. |
| Responsibility | Identify the responsibility addressed by the decision. |
| Context | Describe the business need and relevant constraints. |
| Selected approach | Identify the selected feature or pattern. |
| Reason | Explain why the governance model matches the responsibility. |
| Rejected alternative | Identify the main alternative. |
| Reason for rejection | Explain the mismatch or risk. |
| Control | Describe the confidence, authorization, approval, or human-review control. |
| Failure path | Describe what happens when the component cannot complete its responsibility. |
| Evidence | Identify the information recorded for audit or review. |
- Check that each component has one primary responsibility.
- Check that deterministic logic does not depend on generated text.
- Check that generative output does not make a fixed eligibility, authorization, or access decision.
- Check that the architecture provides a traceable reason for each major decision.
Expected result
Your diagrams and decision records show explicit ownership of interpretation, retrieval, decisioning, orchestration, delegation, tool access, generation, control, and human review.
5 Test and defend the design
- Test each architecture under the following conditions:
- A normal processing condition
- An uncertain or incomplete input
- A technical failure
- A high-risk or unauthorized request
- For each test, record the following information:
- The component that detects the condition
- The action that the component performs
- The information recorded for audit
- The person or component that receives the next assignment
- The condition for resuming automated processing
- Review the design by using these questions:
- Does each component have a clear primary responsibility?
- Does a deterministic component own fixed business criteria?
- Does a generative component process only bounded interpretation or content-generation work?
- Does an external agent receive an objective rather than unrestricted process control?
- Does a tool integration expose only the operation that the agent needs?
- Does the Workflow own sequencing and process state?
- Does a person review uncertain or high-risk results?
- Can an auditor reconstruct the final decision?
- Update the architecture when a test exposes a responsibility gap or missing control.
- Write a short design defense that explains the architecture principles applied across all three scenarios.
Expected result
Your final design separates responsibilities, handles exceptions, and supports a traceable architecture decision.
Available in the following mission:
Want to help us improve this content?