Questions to Answer Before Giving AI Access to a Business System

Questions behind the search

What the reader is trying to decide

• Why does the AI need live access instead of a sanitized export?
• Who owns the access decision and ongoing review?
• What can the integration actually read, write, send, delete, or delegate?
• Which records and fields are allowed, and which are excluded?
• Where does information travel, and how long does each copy remain?
• Is no-training the same as no-retention?
• Can outside content become an instruction through prompt injection?
• Which actions need human approval, and where is it enforced?
• How do you stop work and revoke access, including queued and in-flight jobs?
• What records let a person reconstruct an action?
• Which boundary and failure tests must pass before production access?
• Who handles failure, and can the business continue manually?
• What operating cost and exposure are you accepting?
• What belongs in an access decision record?
• When should a business pause or decline the connection?

Before giving AI access to a business system, answer twelve questions about purpose, ownership, permissions, data, outside instructions, approvals, revocation, logs, testing, fallback, and cost. Put the answers in a dated access decision record. Approve only the connection you can explain, restrict, test, and stop. If an important answer is missing, use a narrower pilot or keep the system disconnected.

A successful demonstration does not establish safe access. A tool that correctly summarizes one customer record might still be able to export the entire customer list. A draft-only workflow might use an account that can send messages. Your decision needs to describe what the integration can actually do, including the actions you do not intend to use.

This checklist helps an owner authorize one proposed connection. It is not a vendor ranking, a credential configuration guide, or a complete governance program. The questions about giving AI access to a business system apply whether the model runs locally or through a cloud service. The surrounding software, permissions, and data path still need review.

1. What business task justifies the connection?

Write one sentence naming the work, the information needed, and the expected output. “Prepare a daily summary of approved support tickets for the service manager” is reviewable. “Help across the business” leaves almost every access question unresolved.

Ask whether live access is necessary. A sanitized export, an approved document folder, or a person pasting a limited excerpt may be sufficient for an early test. Live business system integration adds ongoing access and operational dependencies. It should solve a problem those simpler options cannot reasonably handle.

Record how you will judge the result: factual accuracy, missed items, review effort, or time to a usable draft. Include the work that remains human. If the proposed output cannot be checked by its intended reviewer, pause before connecting production records. More access will not fix an undefined task.

2. Who owns the access decision and ongoing review?

Name the business owner, the system administrator who applies permissions, and the person who reviews exceptions. In a small company, one person may hold several roles. Write those roles down anyway, including who covers an absence and who can suspend the workflow.

When giving AI access to a business system, do not let the installer become the default business approver merely because they know how to connect it. The data owner needs to understand the proposed exposure and use. Administrators need an approved scope they can implement rather than an informal request to make the tool work.

Set an access review date and early-review triggers: new tools, changed provider terms, a different model, expanded records, a new recipient, or an incident. NIST's Manage guidance calls for mechanisms and responsibilities to supersede, disengage, or deactivate systems with outcomes inconsistent with intended use.^[4] Your record should identify who performs those actions.

3. What can the integration actually read and do?

Request an effective permission inventory, not just the connector's friendly description. Separate reading, searching, exporting, creating drafts, changing fields, sending externally, deleting, modifying access, and invoking other tools. Include the underlying account or service identity and any shared folders or inherited rights it can reach.

Compare requested AI agent permissions with the task in question one. OWASP identifies excessive functionality, excessive permissions, and excessive autonomy as causes of excessive agency. Its examples include an email integration with send capabilities when the application needs only reading.^[1] That makes unused capability relevant to the access decision.

Ask the administrator to demonstrate restrictions with the real service identity. A configuration screenshot is useful but insufficient: attempt an excluded read and an excluded write in a controlled test. If the connector only offers a broad scope, record that limitation. Consider a different integration, a restricted intermediary, or an export instead of accepting broad AI system access by default.

4. Which records and fields are allowed, and which are excluded?

Define the record set precisely: one queue, one folder, an approved project, or named fields within specified records. “Customer information” does not distinguish a service request from payment details, identity documents, private notes, or an attachment containing somebody else's information.

Check whether the restriction is enforced by the source system or connector, or merely described in a prompt. If the identity can retrieve excluded records, the prompt has not removed that access. Inspect attachments, linked records, search results, and exports as well as the primary screen.

Before giving AI access to a business system, inventory the personal information the proposed workflow needs and identify who receives it. Document why each sensitive field is necessary; leave unnecessary fields out of the pilot.

Read-only access still permits information to be read and potentially copied into another system. It reduces the ability to change source records, but it is not a blanket privacy guarantee. If the workflow involves health, financial, employment, or other restricted information, obtain qualified review of applicable obligations before exposing it.

5. Where does the information go, and how long does it remain?

Draw the actual data path: business system, connector, automation host, model provider, output destination, and any monitoring service. For each location, identify the fields received, purpose, access holders, storage region if relevant, data retention period, and deletion process. Include conversation history, temporary files, indexes, backups, debugging traces, and downstream exports.

Do not treat “not used for training” as “not stored.” OpenAI's API documentation, for example, separately describes training use, abuse monitoring logs, and application state. It says API data is not used to train models unless the customer opts in, while default abuse monitoring logs may contain customer content and are retained for up to 30 days, subject to documented exceptions.^[5]

The same documentation describes approval-based retention controls and endpoint or feature limitations.^[5] This is a product-specific example, not a rule for every AI service. Verify the exact account, endpoint, feature, and current contractual terms your workflow uses. A provider's business plan and a consumer account may require different reviews.

Save the relevant settings and terms with the decision. Identify who deletes each copy and what cannot be deleted immediately. Disconnecting a connector stops neither every historical copy nor every backup. If you cannot account for a material destination, withhold that data until you can.

6. Can outside content become an instruction?

A support ticket, email, document, or web page may contain text telling the AI to ignore its task, disclose records, or call a tool. OWASP distinguishes direct prompt injection through user input from indirect injection through external sources such as websites and files.^[2] A workflow that reads incoming content needs to address both the requested task and the untrusted material it encounters.

Before giving AI access to a business system, ask which channels are allowed to issue instructions. External document content should remain evidence to analyze, not permission to change the workflow. The receiving software should constrain tool calls, validate destinations and arguments, and keep authorization separate from the model's interpretation.

OWASP says it is unclear whether foolproof prevention methods exist and recommends defenses including limiting privileges and segregating external content.^[2] Reject a promise that one system prompt eliminates the problem. Require a test using a hostile message in a safe environment: does the workflow refuse the requested disclosure or forbidden action? Preserve the result, including any exposure that remains.

7. Which actions need approval, and where is it enforced?

List permitted automatic actions separately from proposed actions that need human approval. Link each approval to an authorized role, the information that person sees, an expiry rule, and what happens after rejection or no response. Our guide to which AI actions require human approval helps classify consequences; this access decision must show the gate works in the proposed connection.

A model instruction to “ask first” is not equivalent to an execution control. OWASP recommends implementing authorization in downstream systems rather than relying on the model to decide whether an action is allowed.^[1] Ask the implementer to show that an unapproved attempt fails even if the model requests it.

The approval should cover the exact target, recipient, fields, and proposed change. If those details change, invalidate the earlier approval. Keep rejected, expired, and altered requests from reaching execution. Test a missing approver and an unavailable approval service; consequential work should wait or stop, not silently continue.

8. How do you stop work and revoke access?

Identify the control that stops new jobs, the administrator who revokes the integration's authorization, and how you confirm that subsequent calls fail. Include scheduled jobs, queued tasks, sessions, refresh credentials where applicable, connected tools, and any other identity that can continue the same work.

Revoking AI access is not always the same as cancelling work already in progress. Ask what happens to a request that has reached the business system before revocation. If a write cannot be interrupted, define the follow-up inspection and recovery action. Do not describe a stop button as undo.

A practical rehearsal before giving AI access to a business system is to queue a harmless test job, stop the worker, revoke its access, and attempt another permitted call. Record what stopped, what remained queued, what completed, and what the source system denied. Revocation also needs a separate cleanup plan for copies already stored elsewhere.

9. What records let a person reconstruct an action?

Request a sample trace covering the initiating user or scheduled job, service identity, source record, proposed action, approval decision, execution attempt, result, and time. Use a shared correlation identifier where possible so the reviewer can follow one job across the connector and business system.

Audit logs should distinguish a proposal from an attempt and a confirmed result. “Request succeeded” in the automation host does not establish that the intended source record changed correctly. Check the target state and preserve the relevant response or reference. For a sensitive change, identify who verifies it.

Do not solve traceability by recording every credential, private message, or full customer file. Define redaction, log access, and data retention separately. Ask whether someone outside the running workflow can retrieve the evidence during an incident. A log that only the stopped worker can access is a weak recovery tool.

10. Which tests must pass before production access?

Use representative sanitized or explicitly approved records. Test the expected task, then test the boundaries. A successful summary is one test; a refused out-of-scope request is another. Keep expected behavior, actual behavior, evidence, owner, and unresolved findings together.

• Try an excluded record or field. Confirm that the integration cannot retrieve it.
• Attempt a forbidden write, send, export, or tool call. Confirm that downstream controls deny it.
• Place hostile instructions in an incoming message. Check that they do not expand the task or disclose data.
• Reject, expire, and alter an approval request. Confirm that none executes under the old approval.
• Repeat a job after a timeout. Check for duplicate changes or messages and an explicit reconciliation path.
• Make the source, model, or approver unavailable. Confirm bounded retries, an alert, and a usable handoff.
• Revoke authorization and inspect queued and in-flight work. Confirm the documented stop behavior.

These are recommended access tests, not a certification standard. Before giving AI access to a business system, define what failure blocks the pilot. Record a known limitation as a decision, with narrower scope if appropriate, rather than turning a failed test into a footnote.

11. Who handles failure, and can the business continue manually?

Write the manual fallback for this task: who takes the work, where they find the last reliable record, and how they know what has already happened. Staff should not have to guess whether a message was sent or a record changed before a timeout.

For a partial failure, require reconciliation before replaying a consequential action. A retry can be useful for a failed read; repeating a payment, customer commitment, or external message can have a different consequence. The access decision should name the person who resolves uncertain outcomes.

NIST's Manage guidance addresses monitoring third-party risks and postdeployment plans including incident response and recovery.^[4] For this connection, ask who receives an alert, what triggers a pause, and how the operator restores the ordinary process. If the business cannot function during an outage, prove the fallback before making the connection essential.

12. What operating cost and exposure are you accepting?

Include connector and model usage, hosting, log storage, human review, administration, maintenance, and incident response. Estimate normal activity and a failure scenario involving retries or unusually large inputs. Use current prices and actual test usage rather than a generic savings claim.

Set a spending threshold, an owner for alerts, and a response when the limit is reached. Check whether a budget feature actually prevents spending or only notifies someone. Bound job counts and retries in the workflow; a notification after repeated calls does not stop those calls.

The cost of giving AI access to a business system also includes review capacity. A pilot that produces more approvals than the responsible person can examine will either stall or encourage careless acceptance. Choose a scope that fits the available staff. If a simpler export meets the need at lower operational burden, use it.

Create an access decision record before connecting

Copy this table into your project notes. Add evidence links, responsible names, dates, and unresolved questions. Its purpose is to make the decision inspectable without requiring another meeting to reconstruct what everyone meant.

For example, a hypothetical pilot might read only approved support tickets, omit attachments and private account notes, and prepare an internal summary. It would not send replies or change tickets. The record would attach the effective permissions, the tested exclusions, the data path, and the stop rehearsal. This is an illustration of a narrow decision, not a customer story or proof that every support platform can enforce those restrictions.

Do not approve broad access conditionally on controls someone hopes to add later. Authorize the scope supported today. Any expansion should receive a new access decision record and tests for the changed boundary.

When should you pause or decline?

Pause when you cannot identify an accountable owner, verify a material data destination, enforce exclusions, block unapproved actions, reconstruct results, or stop further access. Decline when the necessary exposure cannot be justified by the task, the residual risk is unacceptable, or a required contractual or legal condition cannot be met.

Read-only access can be a sensible starting point, but not when it exposes unrelated confidential records. Local hosting can change the data path, but it does not establish safe permissions by itself. The comparison of private local AI and cloud AI can help evaluate that choice without treating either location as a substitute for controls.

This checklist cannot establish regulatory compliance or guarantee protection from misuse. If the connection affects sensitive rights, regulated information, or material commitments, include the appropriate security, legal, and business specialists. A completed table does not override a failed control.

A safe next step

Choose one proposed connection and complete its record before giving AI access to a business system. Request missing evidence from the system administrator or implementer. Then decide whether to allow the bounded task, reduce it to an export or draft-only pilot, or leave it disconnected.

For a broader review of an existing automation, use what an AI automation audit should examine. If you want to discuss a proposed workflow with Ordisyn, bring the access decision record and unresolved questions. That starts the discussion with the work, limits, and evidence; it does not assume a particular connector is supported or that access should be granted.

Sources

1. OWASP LLM06:2025 Excessive Agency
2. OWASP LLM01:2025 Prompt Injection
4. NIST AI RMF Playbook: Manage
5. OpenAI: Data controls in the API platform

A practical next step

Start with the work, the authority, and the failure path.

Ordisyn begins with the operating problem and defines the smallest responsible implementation before access expands.

Start the conversationExplore solutions