How to map where an AI tool's prompts and logs actually go

When a firm evaluates an AI tool, the contract names one provider. The data rarely stays with that one provider. A prompt may pass through a hosting provider, a model provider, a monitoring service and a support team, each in a different place, and each with its own logs.

This piece shows how to write that chain down, before anyone decides whether it is acceptable.

Not legal advice. The German rules on attorney service providers (BRAO §43e) contain specific requirements where a service is used abroad. Whether a given chain meets them is for counsel to decide. This method only produces the facts counsel needs. For the overall decision chain, start with how German attorney service-provider rules apply to AI tools in a law firm.

Why a map comes before the review

Counsel cannot assess what nobody has written down. Questions like "where is this processed?" or "who else can see it?" are often answered with a sales sentence. A map turns that sentence into a list of named roles, places and data types that can be checked, questioned and kept on file.

It also shows where the firm itself still has a choice: a setting, a region, a feature that can be switched off.

Step 1: List what leaves the firm

Start from the firm's side, not the provider's. Write down every kind of data the tool receives:

• prompts and the text pasted into them
• uploaded files and attachments
• the tool's answers
• conversation history stored for later
• usage and error logs
• feedback, ratings and support tickets

If the tool connects to your firm software, add the documents and fields it can read. The interface piece covers that in detail: how to connect AI to your law firm software through an interface.

Step 2: Name every party in the chain

For each data type, ask who receives it. Typical roles:

• the provider you contract with
• the hosting or infrastructure provider
• the model provider, if different from the provider you contract with
• services for monitoring, logging, analytics or error reporting
• support staff, including teams in other locations
• backup and disaster-recovery storage

Record the role even when the provider does not name the company. "Unnamed model provider" is a finding in its own right.

Step 3: Record where each party processes and stores

For each party, note the location of processing and of storage separately. They are often not the same. Also note where support or administrators may access the data from, since remote access can mean the data is used abroad even if it is stored in the firm's own country.

Step 4: Record how long each copy lives

Write down, per party and data type: how long it is kept, whether it is used to train or improve models, and how deletion works, including backups. "Deleted on request" and "deleted after a fixed period" are different answers. Note which one you were given.

Step 5: Mark what the firm controls

Mark every item the firm can change itself: data region, history on or off, training opt-out, log retention, which users have access. Everything not marked is outside the firm's control and should be visible as such.

Step 6: Note the source of every answer

Next to each entry, write where it came from: the contract, a published list of subprocessors, a technical document, an email from sales. Mark anything that rests only on a verbal statement. Counsel will weigh these sources differently, and so should the firm.

Step 7: Keep the map current

Chains change. Providers add subprocessors, move regions and launch features. Date the map, note who owns it and when it is next checked, and record how the provider announces changes. A map that was right last year is not evidence for today.

A fictional map, one row

Fictional example. All roles and details are invented and describe no real provider.

Every "not stated" in this row is a question for the provider before counsel can review it.

What to hand to counsel

• the completed map, dated
• the documents behind each entry
• a list of open questions and items without a source
• the settings the firm intends to use

What the firm should not hand over is a conclusion. Whether the chain is acceptable is the review, not the map.

The same discipline applies inside the prompt itself. Whatever the chain looks like, less client detail in the prompt means less to map: how to remove client and matter details from AI prompts.

Short checklist

1. List every data type the tool receives.
2. Name every party per data type, by role if not by name.
3. Record processing, storage and access locations separately.
4. Record retention, training use and deletion per party.
5. Mark what the firm controls.
6. Note the source of every entry.
7. Date the map and set the next check.

FAQ

Does a complete map mean the tool may be used? No. The map describes facts. Whether a use meets professional secrecy and the rules on service providers is decided by counsel. Not legal advice.

What if the provider will not name its subprocessors? Record that as a finding. An unanswered question belongs on the map as clearly as an answered one.

Is storage in our own country enough? Storage is one entry. Processing, support access, backups and model providers can sit elsewhere. Map each one separately.

How we build this at AETOP

We build agents on Spectacle on the same principle: a model gets only the objects a task needs, numbers are calculated in code, the model handles language, every request is logged, and a human releases before anything changes. Knowing where each request goes is part of building it, not an afterthought. The aim is time back for the people who still do this coordination by hand, without taking the decision away from them. Approval-gated actions are on our roadmap and not yet bookable; we do not describe them as live before they are. If you want to talk through your own setup: see Spectacle.

Not legal advice. This piece describes operational practice and does not replace a legal review.