Their first AI project. And the questions nobody owned.

We were hired to lead our client's first AI deployment — not to build a component of it. They'd found a vendor whose product could draft and send customer emails, and they wanted a pilot. What they didn't have was anyone whose job it was to ask whether the foundation underneath it would hold.

We didn't open by telling anyone what to do. Our first calls were questions — what does this touch, who owns it, what does your day look like, and what happens if it goes wrong. Understanding each person's role and perspective before proposing anything isn't politeness. It's the reason nobody had to be persuaded later.

Only the client can see what is inside their own environment — what a field holds, who touches it, what breaks downstream if a record goes out wrong. That isn't a gap in the vendor's diligence; it's the correct boundary, and giving a vendor more access than the integration requires would create the exposure everyone is trying to avoid. What we find on nearly every first AI engagement is the assumption running the other way: someone should be watching the foundation, so the client assumes it's the vendor. Usually the agreement does address it — in the terms and conditions, in language most IT departments don't read closely or don't read as load-bearing. And where it says nothing at all, silence isn't coverage: a vendor who hasn't committed to something explicitly isn't doing it. That's a gap we can close, which we did here.

We started with the security question, not the technical one. Our first call with our client and our first call with the vendor opened with the same question: what hole does this open, and who's watching it? Our client hadn't considered SOC 2 in the context of the integration. So we put it to the vendor directly and got a clear answer — it sat outside their scope — then went back to the signed agreement and confirmed it there: nothing in it said they would handle it. Governance became a design input rather than a review at the end, which is what made every decision that followed obvious rather than contentious. Without that call the integration would have gone in as designed, and the exposure would have surfaced at the audit.

Then we stopped the pilot before it started. The next thing we assessed was the data, and it wasn't ready. Sixty percent of the fields the pilot depended on were sitting empty — they existed, but nobody had ever checked the required box, so people skipped them. Another third of what it needed had no field at all. Years of records, and most of them unusable. That's an uncomfortable conversation to have in week one, and it wasn't optional.

Then we made the fix structural rather than process- or people-driven — the easiest way to keep guardrails standing over the long term. Required fields became required. Formats got validated at entry. All of it gated before save, so a bad record can't be written in the first place. Defaults sit where the leadership team can change them without calling a developer. We didn't only fix it going forward: every field the pilot depended on was backfilled — the new ones given the value that was true for the records already written, and where a new field was built out of existing ones, we filled the gaps underneath it first so it computed correctly all the way back. Design ran as a second work stream at the same time, so the delay cost weeks rather than months.

One of those unclaimed pieces was the integration itself. Our client had signed for API integration before we were engaged — already in the agreement, committed to by someone who did not yet know what an API would mean for a CRM built entirely on custom tables. The vendor wasn't wrong to hold that line; API was what the contract said, and from where they sat, that was the deal. So when we raised EDI, the pushback wasn't a bluff — it was a vendor working from the only arrangement anyone had described to them.

Getting to a different answer took time: four meetings before their team engaged with the technical picture. Everything the integration touched was custom, every table and field, and Sage CRM's read-only SData access is the only API path into custom tables. The route the original agreement described meant bringing in a third vendor to build a minimal API first, quoted at ten times what the middleware finally cost, three months before any real work could start. And it would not have ended there: the vendor who would have built it told us plainly that every later schema change would need them to update the API. Every new field, another call back to them. A cost with no natural end.

We asked for their technical team directly, and with enough pushing and persuading we got the call. It took five minutes. They already had EDI capabilities in place — capabilities nobody on their side had connected to what we were asking for. Once their engineers were in the room, the vendor agreed to build to EDI at no additional cost. Getting there moved the start of the pilot by about two weeks — a delay, and a necessary one.

Agreeing to EDI settled the route. It did not settle the access. What the vendor asked for next was the CRM data in full — every table, not the fields the pilot needed. That request is close to universal, particularly in AI, and it is worth understanding rather than resisting. A vendor who holds more of your data can see more of your business, which can lead to recommendations beyond what the thing being built requires. Some of those recommendations may genuinely be worth buying. The problem is not the intent, and it is not usually the recommendation. It is that the data sits with them either way, at a volume the thing being built never required.

Clients rarely see it coming, and the reason is a fair one: they are focused on the solution and on getting the thing delivered. Data loss prevention, SOC 2, who holds what and for how long — none of that is front of mind when you are trying to get something live. That is where a third party earns its place, because our attention is on whether our client is protected and getting what they signed for, and nobody inside the project has room to hold both. So we held the access to what the build required, and then opened the other door: we put our client and the vendor in direct conversation about the schema and the rest of what the business captures, so the vendor could make recommendations against the real picture. We stayed in the room to make sure nothing went across that shouldn't. The opportunity stayed open; the exposure didn't.

Unlike what API, the middleware we wrote reads a fixed database view, not the tables underneath, so our client's schema can grow — new fields, new tables — without touching the interface. The middleware is what enforced that, and it was in production inside a week at a tenth of the quoted API build cost. It is ordinary C# on the Microsoft environment they already had, and it went to them with its source, the SDK library, the developer specification, and documentation for the error handling and the logs — written so somebody in the business, not a developer, can read a log and decide whether it needs anyone at all. They kept the training alongside it, so a change is theirs to make, or their CRM partner's, or ours. There is no subscription, because there is nothing to license. The vendor gets only the data they need, only when they need it, read-only and expiring, and our client keeps control of the repository both systems use.

Once the architecture question was settled, the vendor was straightforward to work with. Their project managers were good, they held their dates, and the build was easier for it.

We tested the seams, not just the ends — every handoff between systems, including what happens after a server restarts. Every leg carries error handling, alerting, and an audit log.

The AI is the vendor's product and the model is theirs. What we could control was what it was given and what it was taught. For thirty days after the integration went in, a named person in the business trained it on context and tone, with the vendor documenting every decision they made. Nothing went live until it was dialed in. After that it sends on its own, which is the point — put a reviewer back in the path and you put the cost back with it.

Then we piloted where it would be judged fairly. Three sites whose managers had asked to be involved — motivated, not volunteered. Thirty to sixty people, weekly check-ins for three weeks, then we let it run. At sixty days the business skipped a second pilot and went organization-wide.

Thirty people stopped writing those emails by hand, and that was the point. Eighty-five a day, on average — measured by the client across ninety days. No security exposure, no reliability issues, no data leaks, and a system that still runs. Their first experience with AI was a good one — which is the part that makes the next one easier.

Written by Dan Harrington.