Guide
Before an AI Tool Accesses Your Business Data
Questions to settle before an AI tool reads customer records, internal messages, or other business data.
An AI project can start with one narrow job and still touch sensitive business records. A tool that reviews a purchase order may see customer names, pricing, addresses, and notes someone added months earlier.
Before connecting a production account, write down which records the tool can read and who checks what comes back. Document any permission to send, edit, or delete data separately.
Write down the exact job
Write one sentence that someone who already does the job would recognize. For example: read incoming purchase orders, copy five named fields, and send uncertain entries to a review queue.
That sentence gives the person configuring the account a boundary to enforce. A tool doing this job has no reason to receive complete customer histories or unrestricted access to a shared drive.
Identify the information involved
List the records the tool could encounter, including attachments, free-text notes, archived files, and information pulled indirectly from connected systems. Mark financial, health, employment, credential, and confidential business information for separate review. Removing visible names may leave identifying filenames, metadata, account numbers, document history, or linked identifiers.
Give the test account less access
Start with synthetic records when they can exercise the workflow realistically. If real records are required, remove information the test does not need and handle the remaining data according to its sensitivity. Sample testing can expose obvious failures. It does not establish that the tool is ready for production.
If the test must touch a real system, use a read-only service account when the job allows it. Grant that account access only to the folders, records, and actions required for the test.
Keep a short access record beside the project. Fill in each line before the connection opens:
- Approved purpose and account owner
- Records the connection can read
- Actions the connection can take
- Person who reviews the output
- Start, review, and expiration dates
- Person who can revoke access
Follow one record through the connection
Follow one purchase order from the source system to the AI tool and back. Note every place that keeps a copy, including logs, backups, and support systems.
Review current documentation for the exact product, account, and settings in use. If the records are regulated or covered by a contract, ask the person responsible for security, privacy, legal review, or compliance to check the connection. Check these points directly with the provider:
- The data-processing agreement that applies to the account
- Use of prompts or outputs for model training or product improvement
- Default retention and the deletion process
- Subprocessors that may receive the data
- Processing and storage regions when location matters
- Access available to support personnel
- Breach notification terms and administrator controls
Set retention and deletion rules
Do not give every copy the same retention period. Temporary uploads may be short-lived while audit logs remain longer.
Choose how deletion will be requested and verified. Also ask what happens to copies held in backups and whether the business can export its records before the relationship ends.
Decide which actions require approval
If an output can release a payment, contact a customer, change access, or update a person's record, require approval before the next action runs. Show the reviewer the source record beside the proposed result.
Decide whether any lower-impact outputs will be sampled after release, which error pauses the workflow, and who can override the tool. For work that needs an audit trail, keep the source beside the proposed result, the reviewer's decision, and any correction.
Test failures before expanding access
Use incomplete records, unusual formats, duplicate entries, and conflicting information during testing. Check whether the tool flags uncertainty, invents missing values, or sends a questionable result into the next system.
A document, email, or web page can contain instructions aimed at the AI. Include a test record that tells the tool to ignore its assigned job, reveal another record, or trigger an unrelated action. A tool with write access needs controls that prevent an untrusted document from authorizing a change.
Choose the fallback before launch. Some workflows should hold the record for a person. Others may retry once and then send an alert. Recheck the account whenever the workflow gains a new data source or permission, and remove access the original test no longer uses.