Map an internal AI application by following one request from the employee's action to every system that receives, stores, transforms or acts on its content. The map should include retrieval, model inference, gateway routing, logging, tools, exports and human review. A deployment diagram that stops at the model endpoint cannot show where a sensitive document, generated answer or tool argument travels.
The NIST AI Risk Management Framework organizes risk management around govern, map, measure and manage. Its MAP function includes risks and benefits across components such as third-party software and data. The NIST Privacy Framework is a companion resource for managing privacy risk. Neither framework creates a data-residency or compliance guarantee; the map supplies facts for your own controls and obligations.
Start from one user action
Pick a real but safe workflow, such as “summarize this approved project document.” Record the actor, input type, authorization decision, destination and output at each hop. Include the negative paths: a blocked request, an uninspectable attachment, a provider timeout and a tool-call refusal.
| Hop | Questions to answer | Evidence to collect |
|---|---|---|
| Employee client | What content is selected and who may submit it? | Application authorization and classification |
| Retrieval | Which index, connectors and source permissions apply? | Source identifiers and access decision |
| Inference boundary | Which policy, region and provider connection are selected? | Policy version and request record |
| Provider | Where is content processed under the selected service terms? | Current provider documentation and account configuration |
| Tools | What action can the model propose, and who validates it? | Tool schema, authorization result and audit event |
| Operations | Which logs, traces and exports receive metadata or content? | Retention, access and redaction settings |
Do not substitute a generic diagram for an observed configuration. A retrieval service, browser extension or debugging export can add a data recipient that the original product architecture did not include.
Represent data classes and decisions separately
One arrow on the map can carry different content types with different requirements. A document title, full document text, user identifier, retrieved chunk, model output and tool argument should not all have the same label. Record whether each is content, metadata or a derived value, and which rule governs it.
For example, a hypothetical internal research assistant receives an employee question, retrieves an authorized paragraph, sends selected text through an inference gateway, then proposes a ticket update for a separate system. The retrieval service needs source permissions; the gateway needs a destination policy; the ticket tool needs an operation-level authorization. An allow decision at one step does not prove an allow decision at the next.
Include the controls that can fail
For each component, describe what is inspected, what is not inspected and what happens when a control cannot decide. Alectura inspects the text layer of PDFs, but image, audio and video input passes through as uninspected unless a policy rejects it as attachment_uninspectable. This is a coverage boundary, not proof that a permitted attachment has no sensitive content.
Use this failure table during design review:
| Condition | Question for the team | Safe decision to define |
|---|---|---|
| Retrieval source is unauthorized | Can the application stop before model input? | Refuse and record the reason |
| Attachment cannot be inspected | Does the policy reject or permit it with known limits? | Use the selected fail-closed or explicit exception path |
| Provider connection is unavailable | Is a fallback permitted for this data class and region? | Refuse rather than crossing a policy boundary |
| Tool call is malformed or over-broad | Does an application authorization check run after the model? | Reject without executing the action |
| Debugging needs content | Can the problem be diagnosed with metadata or a controlled sample? | Limit access and retention |
The table does not prescribe one answer for every organization. It makes the unanswered question visible before a production incident makes it urgent.
Turn the map into a reviewable artifact
Store the map with its application version, owner, data classifications, evidence links and last review date. Update it when a model, provider feature, retrieval connector, tool or logging system changes. Tie tests to the map: one test for an approved request path, one for a prohibited destination, and one for a known coverage gap.
Keep it readable by people who own different parts of the system. A security reviewer may need destinations and logs; an application owner may need authorization and tool behavior; a privacy reviewer may need data classes and retention. They should be able to trace the same request without reconstructing the system from source code.
Use the map before expanding access
Complete the map before adding a broader user group, new attachment type, new provider or tool with write access. This avoids an easy failure mode: the application works in a pilot, then the rollout adds a connector or record type that invalidates its earlier control assumptions.
For a practical policy and routing review of one internal application, start with the Alectura platform documentation.