I agree to build an AI automation on a company’s data only when the company can show who is allowed to use that data, what the automation may decide or send, and who can stop it when it behaves badly. I walk away when ownership, access, or responsibility remains a vague promise for “after the pilot.”
At 6:40 on a Thursday evening, an illustrative founder named Kojo was sitting in a small Accra office with a cooling cup of coffee beside his laptop. His team had a sales follow-up tool ready to connect to a client’s inboxes and CRM. The client wanted it live before Monday, with replies drafted from past conversations and customer records.
Then someone asked a basic question: if a former sales rep’s conversations were in the archive, could the system use them?
Nobody in the room could answer. The commercial lead said the data belonged to the company. The client’s operations manager said the CRM vendor hosted it. The person responsible for the account had left months earlier. If the tool started drawing from records nobody had permission to reuse, the Monday launch could become a dispute neither side could undo with a quick patch.
The demo was ready. The right to use the data was not.
Start with the decision the automation will make
“AI automation” can mean almost anything, which is why I begin with the action at the end of the chain.
Will it classify incoming requests for a human? Draft a reply that someone approves? Send a payment reminder? Change a customer record? Recommend which account a salesperson calls next?
Those are different levels of risk. A tool that groups support tickets can be useful with limited access and clear review. A tool that sends a message under an employee’s name needs stronger rules. A tool that changes prices, billing status, eligibility, or customer records needs a named person who owns the decision and a way to inspect what happened.
I want the company to describe the bad outcome in ordinary language. “It should work safely” tells me very little. “It must never send a customer a final cancellation notice without a person checking it” gives the build a boundary.
That boundary also changes the technical work. We can limit actions, keep logs, make review visible, and decide what happens when the system is uncertain. Without it, the project becomes a moving target disguised as a prototype.
Data access needs an owner, not a shared assumption
Before connecting anything, I look for the person who can answer four plain questions: where the data came from, who may access it, how long access lasts, and what happens when the engagement ends.
A company can own its customer relationship while still having contractual duties around its data. It may have data from a partner, a former contractor, a third-party platform, or a business unit that never agreed to share it for model development. “It is already in our drive” is not an answer to any of those questions.
This is where projects often become uncomfortable. The request may be reasonable, the team may be capable, and the deadline may be real. Yet nobody wants to put a clear instruction in writing because that instruction exposes an unresolved internal decision.
I have learned to pause there.
The same issue appeared in a different form in [the partner dataset behind the demo](\/blog\/the-partner-dataset-behind-the-demo-and-what-it-could-cost-the-launch-cd3c9254\/). A dataset can make a demo look convincing long before anyone has settled whether it can support the work that follows.
For Kojo, the useful next move was smaller than the original plan. The team separated records the client could clearly authorize from the larger historical archive. The first version would draft responses from an approved knowledge base and current account notes, with a human approving every message. It was less impressive in a slide deck. It was a system somebody could defend.
Ownership after delivery changes the build
I also need to know what the company believes it is buying.
Are they paying for a one-off implementation? A tool their internal team will run? A hosted service? A workflow that needs continuing monitoring as policies, prompts, staff, and source systems change?
Those choices affect who owns the code, the configurations, the prompts, the evaluation set, the credentials, and the records created by the automation. They affect who receives an alert when an integration breaks on a Saturday. They affect whether the company can continue operating if the relationship ends.
A vague answer creates pressure later. The client expects a handover. The builder expects ongoing access to fix problems. Both believe the other party owns the unglamorous work of keeping the automation accurate.
I prefer to name the handover before the first build starts. What will be documented? Who can change the instructions? Who approves new data sources? What access is removed at the end? Which outputs must remain reviewable?
These questions can feel slow at the beginning. They prevent much slower arguments when the automation has already entered a customer-facing process.
The point where I decline the work
I walk away when a company wants the benefit of automated decisions while leaving accountability floating between departments, vendors, and contractors.
The red flags are familiar: credentials passed around in chat, a request to “use everything we have,” no person empowered to approve data use, or a plan to decide ownership after the automation proves valuable. I do not treat those as paperwork gaps. They are product risks.
There is a related ownership problem inside the workflow itself. As explored in [Miriam’s question about workflow ownership](\/blog\/ai-product-defensibility-what-miriam-s-question-taught-founders-about-workflow-ownership-aff45eae\/), the valuable part is often the decision process around the model, not the model alone.
Kojo’s team did not launch the larger version on Monday. They launched a narrower review queue later, with an approved data source, named approvers, and a record of what the tool suggested. The coffee cup was gone by then. The uncomfortable question remained visible in the project documents, where it belonged.
Comments
No comments yet.