The data-access negotiation in enterprise AI

Ask an engineer what slows an enterprise AI project down and you will hear the model, the framework, or the integration. Ask someone who has done forward deployed work and the answer is different. The first three weeks go on waiting. For a service account, for a data-sharing approval, for a security review nobody scheduled because nobody knew it was needed.

I now treat that waiting as the first engineering problem of every engagement. It is a negotiation, it has a shape, and you can run it well or badly.

Why it is getting harder

Agents change the question security teams ask. A retrieval chatbot reads. An agent acts. It updates records, sends messages, triggers workflows.

The protocols that make this easy are arriving fast. In late October, Claude Code's CLI added MCP Tasks, in public beta, which let a tool run a long job, and Elicitations, which let a tool stop mid-task to ask a person for confirmation (Upstash). SAP made inbound Agent2Agent calls generally available through an Agent Gateway with discovery, allow-lists and audit, and it says plainly: "Discovery does not itself grant permission to invoke an agent." (SAP Architecture Center).

That sentence is the whole negotiation in small. Technology makes reaching things easy. Permission is still a human decision, and someone has to ask for it well.

The four people you are actually negotiating with

"Get data access" hides four separate conversations. Each person has a different worry.

1. The data owner, often a business function and not IT, worries about misuse and about being blamed. They need to know exactly which fields, for what purpose, for how long.
2. The security reviewer worries about blast radius. What can the system reach, and what happens if it is compromised or simply wrong.
3. The platform or infrastructure team worries about operational load. One more service account, one more network path, one more thing to patch on a Saturday.
4. Legal, privacy or compliance worries about where the data goes, especially to a model hosted outside the jurisdiction.

Most delays come from asking all four for "access" in a single email. Each of them needs a different document.

Close

Getting data access is four negotiations. The data owner worries about misuse and blame and needs exact fields, purpose and expiry. Security worries about blast radius and needs a named owner and limited writes. Platform worries about operational load and needs one identity per system. Compliance worries about where data goes and needs model hosting and retention. One request, one section per person, and list the fields you do not need.

The access request I write

Before I ask for anything, I write one short document per use case. It goes to all four people, but each section is written for one of them.

• Purpose and workflow. One paragraph on the business task, who does it today and what changes.
• Data inventory. The specific tables, fields or document sets, marked read or write, with the reason for each. Fields we do not need are listed explicitly. Removing columns is the fastest way to speed up an approval.
• Action boundaries. Every action the system can take, marked as unattended, needs human confirmation, or not allowed. Writes to a system of record always start as "needs confirmation".
• Identity. One service identity per system and environment, never a shared technical user, with minimum role.
• Model hosting. Which model, hosted where, under which terms, and whether any data is retained. Where residency matters, which parts run on an in-region or locally hosted model.
• Logging and audit. What is logged, who can read it, how long it is kept. Logs a business owner can read are worth more in a review than logs only an engineer can parse.
• Expiry and review. Access expires on a date and gets reviewed at handover.

It is two to four pages. It saves weeks.

Patterns that speed up approval

Start with a read-only slice. Prove the workflow on read access with a human doing the final action. Ask for write access once the evaluation shows that step is reliable.

Use masked or synthetic data for the build, real data for the evaluation. Many security teams approve masked development data quickly, and approve real data separately for a scored, logged evaluation run.

Put approvals in the tool, not in the prompt. "Always ask before changing a record" in a system prompt is a request to a model. A tool that will not proceed without a recorded confirmation is a control a reviewer can actually test. Elicitations are one way to do it where the client supports them. A simple approval queue is another.

Pre-book the security review. Find out in week one what the review process is and how long the queue is. Book it then, against a draft design, even if you will revise it later.

Bring the evaluation to the review. Reviewers relax when they can see how often the system is wrong and what happens when it is.

What the stall usually is

A pattern I see again and again: the stated blocker is not the real one. A widely shared LinkedIn summary of lessons from Palantir's FDE practice tells of a data quality engineer who blocked a migration for about a year. Her real need was a way to inspect rows by eye. Once someone built her a viewer, she approved the migration within days (Glenn Santos, LinkedIn).

In my own engagements the hidden need is usually one of three things. The data owner wants to see outputs before they go anywhere. The security team needs a named person accountable for the service account. Or compliance needs one sentence about where the model runs. Ask what would make each person comfortable saying yes, and write that down.

Plan for it, price for it

Access time is not slack in the plan. It is the plan for the first gate. In my engagements, readiness does not pass until the data owner's approval is in writing, the security review is booked or done, and the action boundaries are agreed. If those can not be reached in about two weeks, the right recommendation may be to pause. I cover how that ties to commercial terms in pricing an FDE engagement.

Learn it as a skill

This is why I teach access negotiation as a proper skill in the AIXL Academy Forward-Deployed AI Engineering cohort, alongside the code. It is the part of the job most engineers have never been asked to do, and the part that decides whether their code ever runs. Dates and fees are on the AIXL Academy page. The method behind this is set out in forward-deployed engineering.

Common questions

Why do enterprise AI projects wait so long for data access?

Because "access" is really four approvals, from the data owner, security, platform and compliance, each with different concerns. A single vague request satisfies none of them.

What should an AI data access request include?

Purpose, a field-level data inventory, action boundaries, one service identity per system, model hosting and retention, logging and audit, and an expiry date.

How do you get an AI agent through a security review faster?

Start read-only, use masked data for the build, put human approvals in tools instead of prompts, book the review in week one, and bring the evaluation results.

Should AI agents get write access to systems of record?

Not at first. Start with a human confirming each write, and allow unattended writes only for steps the evaluation shows are reliable.