AI’s last mile problem: 6 lessons for GTM Ops

AI can research an account, summarize a sales call, recommend a segment, and write an email before you finish reheating your coffee.

Then you ask it to update Salesforce.

Suddenly, everyone from IT, InfoSec, legal, finance, and the person who still remembers what happened during the Great CRM Sync Incident of 2022 would like to join the meeting.

That gap between what AI can demonstrate and what an enterprise will trust it to do in production is AI’s last mile problem.

1. Getting AI to work with your business systems is still a major blocker

Every panelist had encountered the same underlying problem: AI can do a lot of the work, but getting that work safely into the systems where the business operates is much harder.

The exact obstacle depended on the organization.

At Celigo, Jules described an ownership and handoff problem. Marketing Ops owns HubSpot and the quality of the data going into it, but another technology team owns parts of the list-upload process. Any AI workflow has to account for all the people, systems, and approvals involved.

At Lyra Health, Harjot faces a privacy and compliance problem. Because Lyra operates in healthcare, AI access has to be designed around HIPAA requirements and the possibility that patient information could appear alongside business data.

For a smaller organization like marketingops.coms, the challenge is more likely to be adoption, training, and economics. A small team may have the authority to connect AI to more systems, but they still has to decide whether those connections are useful, sustainable, and worth the AI token bill that comes with it.

Across Openprise customers and prospects, Ryan sees the enterprise version of the problem regularly:

The models may be ready, but the systems aren’t.

Sometimes InfoSec blocks the connection. Sometimes the data is not prepared well enough for the AI to use. Sometimes the technology can read from a system but cannot safely write anything back.

Different symptoms, same gap.

2. AI automation still needs process design

One of the most useful examples came from Celigo’s list-upload process.

Before introducing AI, uploading a marketing list could take three to five days and involve three or four departments. The team built a Claude routine that monitors Asana requests, checks incoming data, identifies duplicates, removes personal email addresses, validates country fields, and prepares the next ticket in the process.

That helped reduce turnaround time for list upload to roughly 24 hours.

Celigo’s global technology team then began automating the upload itself using an internal integration platform. The goal was to move the process from days, to hours, to nearly instantaneous.

That sounds like a clean AI success story. But the important part is everything Celigo had to do around the AI to make it work.

The team still needed to define:

What every spreadsheet column meant
Which fields were required
What data needed to be removed
How the file should be formatted
Where one system handed the process to another
When a human should review the result
How the workflow would be tested in a sandbox

AI did not eliminate process design. It made good process design even more important.

Jules compared the current AI hype to the early days of marketing automation. Executives heard “automation” and assumed the platform would simply open itself, understand the funnel, and start generating revenue.

AI is now receiving the same treatment.

Connect the tool. Add a prompt. Let it cook.

Except the robot does not know that the “Country” column must contain an ISO code, that personal emails should be excluded, or that the global technology team needs five specific fields in a particular order. Someone has to define those rules.

Usually, that someone is Ops.

3. Compliance is a design requirement, not an inconvenience

During the live webinar, 60% of respondents said access to their GTM data was restricted because of compliance or privacy concerns.

That did not surprise the panel.

At Lyra Health, every proposed connection between an LLM and business data has to be reviewed by privacy and security teams. The organization cannot simply connect Gemini or Claude directly to Salesforce, Marketo, analytics systems, or patient-related data and see what happens.

Those restrictions are reasonable. They also limit use cases such as account research, segmentation, and analysis that depend on combining internal and external signals.

Harjot’s team has found creative ways to deliver value while respecting the boundary.

For account research, Lyra uses predefined prompts and a controlled group of priority accounts in Common Room. Salespeople can view the resulting research through a Chrome extension displayed alongside Salesforce.

The insights are available where the rep works, but the AI does not need unrestricted access to Salesforce or sensitive internal data.

That is an important distinction.

Crossing the last mile does not mean sneaking AI around InfoSec. It means designing an architecture that gives teams useful capabilities while respecting what AI can see, what it can change, and where sensitive information is allowed to go.

Harjot also noted that organizations are becoming more restrictive about exports. When employees cannot connect Claude directly to Salesforce, they may download reports and upload them manually for analysis. That can create another path for governed data to leave the system.

Closing one door does not solve the problem if everyone immediately starts climbing through a window.

GTM Ops, IT, privacy, and security need a shared approach that allows controlled experimentation without giving an agent the keys to the entire building.

4. An integration does not guarantee the AI can do the job

The panel also discussed the difference between technically connecting AI to a system and giving it a genuinely useful capability.

Mike shared an example involving Claude and HubSpot. Claude could retrieve contact properties and identify records that matched a segmentation request. It could even produce a static list.

What it could not do efficiently was create the dynamic HubSpot list with the required AND/OR logic and keep it updated natively.

Technically, Claude could have used browser automation to click through the HubSpot interface. But that would consume more time and tokens to replicate something HubSpot already does well.

This is where tool-specific and domain expertise still matter.

A new employee working entirely through an AI assistant might assume the correct solution is to rerun the segmentation every night. An experienced Marketing Ops practitioner knows that the better answer is a native dynamic list that updates automatically.

AI can make a task possible without making it sensible.

The same distinction applies across the GTM stack. Native integrations, private apps, MCP servers, browser automation, and custom APIs may all provide different levels of access.

But access alone does not answer the important questions around when, where, and how to use AI:

What should the AI be responsible for?
What should remain deterministic?
What should happen inside the system of record?
What should happen outside it?
How much will each option cost to operate?

The goal is not to make AI touch everything. The goal is to use AI where it adds value and use conventional automation where consistency, speed, and cost matter more.

5. Documentation of AI workflows is a must

When asked what helped Celigo move AI workflows across teams, Jules had a delightfully unglamorous answer:

Honestly, documentation.

An AI routine may run in the background, but the people affected by it still need to know what it does, why it exists, what systems it touches, and what happens when something goes wrong.

Documentation also makes approval easier. IT and security teams are more likely to support a workflow when Ops can clearly explain:

The business use case
The data the AI can access
The actions it is permitted to take
The systems involved
The handoff points
The validation and review process
The owner when something breaks

But documentation also has to be written for the person using the process.

Celigo’s first version of its list-upload instructions was extremely detailed. The team receiving the ticket responded that they did not need to read “the entire War and Peace.” They needed five pertinent points.

That feedback led the team to simplify the output.

Ryan highlighted the broader lesson: builders tend to document systems for other builders. But many AI workflows are being built to give business users self-service capabilities. Those users do not need a guided tour of every API call. They need to understand what information to provide, what result to expect, and what to do next.

In other words, the workflow is a product.

The prompt is an interface. The documentation is onboarding. The business user is the customer.

Treating it that way will produce much better results than releasing a clever automation into the wild and waiting for the support tickets to arrive.

6. The AI bill belongs in the design conversation

AI usage costs were not an abstract concern for the panelists.

Celigo’s Marketing Ops team became the company’s second-highest consumer of AI credits behind engineering. When the IT team introduced organization-wide usage limits, the team reached them quickly because it had multiple routines and scheduled processes running in the background.

That led to a more deliberate operating model.

The ops team now reviews usage regularly, compares the costs of different models, estimates consumption before launching new workflows, and evaluates how often each routine really needs to run.

Does the workflow need to run three times a day? Once each morning? Only when a ticket arrives? Could part of it move into Celigo’s internal automation platform instead of repeatedly calling a third-party model?

These are operational design questions, not merely finance questions.

Lyra takes a similar approach to account research. Because vendor costs are tied to the number of researched accounts, the team cannot simply enrich every company in its total addressable market. Marketing Ops works with GTM leadership to identify the accounts that actually matter and determine which tiers deserve the investment.

As Mike put it during the discussion:

Aim small, miss small.

More AI activity is not automatically more AI value. Running an expensive process across 20,000 poorly prioritized accounts is not a strategy. It is a very fast way to produce an interesting invoice.

Data preparation also matters. Ryan pointed out that AI often burns tokens trying to understand enterprise data before it can answer the actual question.

Ask an agent, “How many customers have we had in the last 12 months?” and it may need to inspect custom objects, conflicting status fields, duplicate accounts, partner relationships, historical product names, and whatever creative decisions accumulated during years of CRM administration.

Or Ops can prepare a clean, governed customer dataset once and give the AI something it can actually understand.

The second option is faster, more reliable, and much less expensive. It is also a central principle of effective data and AI orchestration: prepare and structure the data before handing the problem to a probabilistic model.

Closing AI’s last mile requires a trusted execution layer

By the end of the webinar, the pattern was clear.

AI adoption stalls when teams try to connect a probabilistic technology directly to systems that require consistent, governed, and auditable execution.

IT is not being difficult when it objects. An AI agent can misunderstand an instruction, ignore a rule, expose information to the wrong person, or confidently make a bad update. Giving it unrestricted write access to a CRM is not transformation. It is an incident report waiting to happen.

Ryan explained how Openprise can sit between AI agents and the GTM stack as a trusted control layer.

Instead of giving an agent direct access to Salesforce, Marketo, HubSpot, or another system of record, Openprise can:

Prepare clean, governed datasets for the agent
Restrict the data and fields it can access
Validate requested actions against business rules
Execute approved actions deterministically
Maintain the controls and auditability InfoSec needs
Reduce the data preparation and interpretation work consuming AI tokens

Think of Openprise as an AI firewall.

The agent can recommend or request an action. Openprise governs and performs the execution through a controlled workflow. The AI does the work that benefits from language, reasoning, and flexible analysis. Openprise handles the work that has to happen correctly every time.

That combination gives Ops teams a much more credible answer when IT asks, “What exactly are you connecting to our CRM?”

Ops is becoming the architect of AI adoption

The panel ran out of time before completing its planned discussion about the “new” skills Ops teams need. But Mike argued that the core skill is not entirely new.

Ops has always translated business requirements into technology capabilities.

What is changing is the scale of that responsibility.

The successful Ops practitioner will not just administer individual platforms or build point-to-point workflows. They will design reusable capabilities that can be consumed by employees, applications, and AI agents.

That requires stronger product thinking, system architecture, documentation, data governance, and financial awareness.

It also puts Ops in a valuable position.

Sales understands the desired outcome. IT understands enterprise infrastructure and risk. Finance sees the consumption bill. AI vendors understand their models.

Ops is the function that understands how the whole process is supposed to work.

That makes Ops more than the team receiving requests after an AI pilot has already been purchased. It makes Ops the team capable of turning that pilot into something the business can safely use.

AI can make it through the first 90% of the journey on a great demo.

The last mile belongs to Ops.

See how Openprise helps GTM teams connect AI to governed data and deterministic execution. Explore AI orchestration or request a demo.

‍