How to Map an AI System Before Buying Tools

A model vendor can show a convincing answer in minutes. That demo doesn't tell you whether an employee may see the underlying record, whether the answer uses the latest policy, or who approves a change in a customer system. Draw the path of one real request before you choose the tools. The map will show what you need to buy, build, or fix in your existing systems.

Define the request and its finish line

Choose one task with a clear start and end. For example, a support agent receives a question about a delayed order. The agent needs the order status, the current delivery policy, and a draft reply. The task ends when the agent sends an accurate answer or escalates the case. It doesn't end when a model returns text.

Write down the trigger, the person responsible, the output, the system of record, and the cost of a wrong result. Then follow a normal case and an exception. A customer asking for an order update is a normal case; a customer seeking a refund under a disputed policy is an exception. Those two paths expose different data and approval needs.

Draw six boxes and the lines between them

Put these boxes on one page. Each line should name the data that crosses it, the permission used, and the failure response. A box can be an existing service; the drawing doesn't require six new products.

1. Identity and entry: Who starts the request, and how does the application know their role and organisation? Carry that identity into every data read and proposed action.
2. Source systems: Where do order status and policy actually live? Name the owner of each source and how quickly a change appears in the workflow.
3. Retrieval: How does the application find the relevant record or policy passage? Record the source ID and version alongside the text. Don't send an entire document store to the model.
4. Model call: What question and retrieved context reach the model? State the required output shape, time limit, and fallback when the call fails.
5. Action boundary: Can the system draft, send, update, or refund? Put approval and ordinary application checks between a model suggestion and any write to a business system.
6. Logs and evaluation: Record the request ID, source versions, model version, proposed result, reviewer decision, final action, latency, and cost. Limit access to those records and set a retention rule.

The AWS guidance on secure retrieval describes why the retrieval box needs access controls, provenance, and checks on incoming material. The Microsoft AI application architecture guide covers tracing retrieval and tool calls, latency budgets, and the coordination cost of extra steps. These concerns belong on the map before vendor selection.

Walk a support request through the map

In the support example, the agent signs in through the company's identity system and opens a case. The application reads only that customer's order record, then retrieves the current passage of the delivery policy. It sends the order facts and policy passage to the model with an instruction to draft an answer and cite the policy. If either source is missing, the application asks the agent to handle the case manually.

The model returns a draft; it doesn't send the email. The application checks the reply format and shows the draft, order status, and policy source to the agent. The agent edits or rejects it. Only the existing support application sends the final reply and records the case outcome. A refund request follows a separate route to the team member who has refund authority.

This walk-through makes the design testable. You can point to the exact step that fails when the policy is stale, a customer record is unavailable, or the model suggests a refund it cannot authorize. You can also see which capability already exists in the support application and which gap a new tool must fill.

Mark every permission and action boundary

A source document isn't an instruction to the application. Treat retrieved text and customer messages as untrusted input, even when the model needs to read them. The application decides which tools are available and validates their arguments. It should enforce the user's data permissions before retrieval and check them again before an action. A model's claim that a user has approval is never proof of approval.

For each line on the map, ask what happens if a user crosses into another customer's records, if a document contains hostile instructions, or if a tool call repeats after a timeout. For a write action, use a narrow operation, an approval step where the impact warrants it, and a request ID that lets the destination reject duplicates. Define a manual path when the system cannot establish the right source or authority.

NIST's AI Risk Management Framework Playbook asks teams to map how an AI system will be used and managed. The map here turns that question into named boundaries and owners. It also keeps the security review focused on a real workflow instead of an abstract model choice.

Test the map before selecting products

Take a small set of real, permission-safe cases through a manual version of the path. Include an ordinary answer, an outdated policy, a missing order, a customer from another account, and an action that needs approval. Have the task owner mark the correct source, acceptable reply, and required handoff for each case. Test retrieval and permission checks separately from the quality of the final draft.

Track where each case stops, how long each step takes, and how much human review it needs. A poor answer may come from a stale source rather than the model. A slow workflow may come from repeated searches or sequential tool calls. This evidence tells you which part of the map needs work; it also gives you concrete cases to run in a vendor trial.

Use the map to make a buying decision

Ask each vendor to show how its product fits a named box and how it connects to the lines beside it. Can it honor your user permissions at retrieval time? Can it return source IDs and versions? Can it stop at a draft, hand an action to your approval process, and export traces for your own checks? Ask to see these on your sample cases, including the failure cases.

If your source records are inconsistent or your approval rules are unwritten, a new model platform won't settle those decisions. Fix the source or the process owner first. If the path is clear, buy the capability that closes a measured gap and keep the rest of the workflow under your control. The system map then becomes the build brief, the trial script, and the record of who owns each failure.