What Access Does an AI Implementation Partner Actually Need?

An AI implementation partner needs access to the evidence and operations required for a defined delivery task. Ask them to separate discovery access, setup privileges, and the permissions the finished application needs. Approve the resources and actions for each phase, name who can withdraw access, and test that the company can operate the result after the partner leaves.

Ask for the operation before the account

Begin with the result the partner must deliver. An assessment of job-completion delays needs different information from a production assistant that creates follow-up work. Describe the workflow and its first accepted output, then ask the partner to map each requested permission to that work.

A request for CRM access needs more detail. Which customer population, fields, and operations does the team need? Will a person inspect a sample, will a connector read records regularly, or will the finished application update them? Who receives the resulting information?

Ask the partner to identify the least privileged role or interface that supports each operation. If they request broader access, have them explain the missing capability, the proposed duration, and the alternative. The explanation should give the system owner a decision they can check.

Microsoft's least-privilege guidance distinguishes unused permissions from reducible permissions that have a less privileged alternative. That is a practical review question for an access request: does the delivery use this permission, and can the required operation work with less?

Keep account creation separate from approval of the project. The business sponsor can authorise the engagement while a source owner still needs to approve access to their system. Record the relevant approver and a decision date so the project plan includes that dependency.

The legacy-system access guide explains the connector design in detail. This article focuses on commissioning the partner's access and establishing what your own team must approve, monitor, and eventually remove.

Separate discovery, setup, and operating access

Build a phase-based access plan. Discovery may start with interviews, source definitions, and a representative export. Engineering needs a test environment and integration documentation. Production release needs a controlled deployment path. Support needs a defined view of failures and an approved way to intervene.

Name human identities separately from application identities. A consultant's account supports their reviewed work. A connector's identity supports the running service. Ending the consultant's engagement shouldn't stop an application that your company has accepted, and keeping the application running shouldn't require keeping the consultant's privileges.

Microsoft Graph's permissions documentation distinguishes delegated access on behalf of a signed-in user from app-only access using an application's own identity. Those models can have different effective reach. Have the implementation team identify which model each connection uses and how it limits access to the approved resources.

Separate a privileged setup step from ongoing operation. An authorised administrator may need to approve an application or configure an integration. That doesn't establish that the partner needs a standing administrator account. Agree who performs the setup, how they review it, and when any temporary elevation ends.

Keep the company's accepted code, configuration, and operating accounts under the agreed company ownership arrangements. Confirm who controls recovery and billing administration. A working demonstration in the partner's personal account doesn't establish a maintainable production handover.

Give each person an attributable account with the required authentication controls. Store application credentials through the approved secret-management process. Keep passwords and tokens out of prompts, source documents, and ordinary project tickets.

Specify permitted reads and writes

Define reads by resource and population, not just by a read-only label. Name the relevant business units, record types, fields, and date range. A read-only account that can export every employee record has a different scope from an account that reads the approved job-status view.

Follow data beyond the source lookup. Document what reaches the partner's development environment, model service, search index, and diagnostic records. Permission to read a source doesn't by itself approve every onward destination or every person who can inspect a copied record.

For a write, name the business operation and its allowed inputs. Creating a proposed follow-up task differs from changing a customer master record or marking a job complete. Keep each action's approval and validation requirements with its access request.

Restrict production writes to a supported transaction path that the system owner approves. Include how the application handles a changed record, duplicate request, and uncertain submission outcome. A connector permission is only part of that operating design.

Keep human commercial or operating authority explicit. Permission to create a draft doesn't authorise the partner or model to issue a customer commitment. The process owner determines which decisions need review and who can make them.

Test the actual effective scope. Role names can conceal broader inherited permissions or application grants. Ask the technical owner to demonstrate the permitted operation and a representative denied operation using the identity the delivered service will actually use.

Set workload bounds alongside data bounds. An authorised read can still consume source capacity. Agree the frequency, result size, and recovery behaviour with the operator, including how the connector behaves during a source outage.

Agree vendor approval and the data destination

Have the source-system owner confirm the supported interface for the installed product and edition. Check the relevant licence and supplier conditions with the responsible people. A current cloud API page doesn't establish what an older local installation permits or supports.

Identify the platform administrator who can approve the requested connection. The partner can prepare the permission manifest and configuration instructions. Your authorised administrator can review and perform the grant where the delivery model allows it, without handing over their own login.

Agree the development and processing destinations before transferring data. Record the hosting arrangements, model or other service providers, partner personnel, and any subcontractor access involved. Ask which copies the work creates and which people can administer those copies.

ASD's September 2026 procurement and outsourcing guidance describes attributable accounts and least privilege, with customer-approved tools, source addresses, and time windows for service-provider access. It also calls for independent logging. Use the framework as a reference when your system owners agree the controls appropriate to the engagement.

Put approved access and data-handling responsibilities into the engagement arrangements. Include the route for an additional tool, subcontractor, or destination to receive approval. A later troubleshooting request shouldn't silently expand the original source or audience.

If access exceeds what the source owner can safely support, change the design or the delivery sequence. The project may begin with a prepared sample while a supported connector receives approval. Record what that first phase can establish and which production questions it leaves open.

Use an export when it meets the task

A prepared export can support discovery, data profiling, or a workflow that accepts a reporting cutoff. Define its selection rules and required fields. Have an owner confirm that the sample includes the exceptions the project needs to understand.

Remove unnecessary information before the partner receives the file. Where test cases don't need real identities, use approved synthetic or transformed records. Preserve the relationships and formats required for the test, and have the responsible owner review whether the transformation meets the handling requirements.

Record the extraction time, source definition, and known omissions. A file that excludes cancelled jobs or older amendments can distort the workflow assessment. The partner needs to distinguish a real absence from a filter in the export.

Set the delivery location, authorised recipients, retention, and withdrawal process. An exported file is a new copy with its own access boundary. It needs the same care when someone downloads it to a development machine or attaches it to a support request.

Explain the limit of the method. An export can test record matching or draft preparation against a snapshot. It doesn't establish current permission enforcement, live availability, or safe production writes. Keep those acceptance requirements for the relevant later phase.

If the business needs a recurring export, assign its maintenance. Name who notices a failed delivery or changed column, how the application shows stale information, and when staff must return to the source system. Include that operating work in the comparison with a live connection.

Require audit records and access tests

Agree the evidence before granting access. The company should be able to trace who accessed which resource, for what approved operation, and with what outcome. Link privileged interventions to the relevant change or support request.

Have the company retain an appropriate independent view of provider activity. Define who reviews unexpected access and who receives an incident report. A log stored only in a location the partner can alter doesn't give the customer an independent record.

Keep credentials and unnecessary record contents out of general diagnostics. Restrict sensitive audit material to its intended reviewers. Enough evidence to reconstruct an operation doesn't require copying complete customer files into every error message.

Use authorised test cases for successful and denied access. Check a record outside the approved population, an attempted write from the read component, and a request from an expired or removed identity. Include bulk reads and downloadable attachments where the interface supports them.

Test failure handling without expanding authority. If the ordinary read fails, the application should follow the agreed fallback. It mustn't switch to a broader administrator credential or expose a general-purpose tool to keep the task moving.

Check the receiving workflow too. A permitted write can still create work in the wrong queue or under the wrong owner. Reconcile the result with the source and destination, and record how staff recover when the outcome is uncertain.

Make these tests part of release acceptance and later permission changes. The evidence should describe the tested configuration and identities. A demonstration using an administrator's session doesn't establish the delivered application's boundary.

Plan withdrawal and handover before granting access

Give every temporary grant an owner, purpose, and review or end condition. Identify who can remove it during normal offboarding and who can stop access urgently. The company needs a route that works even when the partner is unavailable.

Keep an inventory of human accounts, application identities, consent grants, credentials, remote-access arrangements, and relevant repository permissions. Review it at phase changes. Removing a consultant's login doesn't demonstrate that every separate connector or integration has lost access.

Test the withdrawal procedure in the agreed environment. Have the owner remove or disable the relevant grant, then verify the resulting behaviour through the approved path. Establish how existing sessions and issued credentials behave in that system rather than assuming a universal immediate cutoff.

Distinguish access that ends from operating access the company accepts. Transfer responsibility for a production connector to its named owner and test recovery using company-controlled arrangements. Remove temporary human elevation and development access when their purpose ends.

Account for copied information. Agree the return or deletion of development exports and diagnostic copies, and record any retained material and its access restrictions under the approved retention arrangements. Removing source access doesn't retrieve files already exported.

Practise the handover. The receiving operator should inspect a failed connection, use the recovery instructions, and know which owner can approve a changed permission. The workflow ownership guide explains how that operating responsibility fits the wider team.

Write a brief your system owners can approve

Consider an illustrative field-service company commissioning a case-preparation assistant. Staff need to connect a customer enquiry with the relevant job and its completion status. The first release prepares an internal case; it doesn't amend the job or send a customer message.

The discovery brief gives the partner an approved sample of customer and job records, source definitions, and selected exception cases. The source owners approve the export and its destination. Engineering begins in a test environment with the same permitted fields and representative relationships.

For production, the company authorises a connector to read the relevant records for the permitted staff population. An authorised administrator performs the reviewed setup. The application has a company-owned operating identity, while the partner's human access has its own purpose and end condition.

A later request to create follow-up tasks needs a new decision. The process owner names the task type and receiving queue; the technical owner verifies the supported write path. The release review includes duplicate handling and an attempt to perform an operation outside that grant.

Turn that example into a concise access pack for your engagement. State the delivery output, systems and resources, identities, permitted operations, data destinations, and phase dates. Attach source-owner approvals, acceptance evidence, and the withdrawal and handover plan.

For an SME, the same person may hold several approval roles, but they still need the evidence to make each decision. A larger company needs a named route through its platform and security owners. A PE portfolio should obtain local approval in each company rather than treating a fund-level engagement as permission to access every operating system.

The data integration service guide describes how we scope source connections and their operating handover. Ask a prospective partner to explain their access request against the first delivery commitment. Expand it when a specific task justifies the new permission and the relevant owner can accept its controls.