When Your Manager Says to Feed the Data to AI

Your manager forwards a vendor demo with one line on top: “Can we feed our data to AI?” The thread already has three people saying yes. No one has said what “our data” is, who would ask it questions, or what they’d do with the answers.

That sentence is a goal with the spec missing. Underneath the pipeline request, you’re being asked to decide what the business wants a model to do. Start building before anyone makes that call and you’ve picked the fastest way to fail.

I’ve written before about what giving data to AI actually means at the system level: the model doesn’t swallow the warehouse, it gets tools to go look things up. This piece is about the step before that. How you take a vague instruction from someone with budget authority and turn it into something you can scope, cost, and ship.

The Literal Answer Is Always Yes

You can upload documents to a chat product this afternoon. You can point a retrieval index at a shared drive by Friday. Either one will produce a demo that answers a few questions well, and the demo will be mistaken for a project.

The trouble shows up a month later. Someone asks about a contract the index never saw. Someone else gets an answer drawn from last year’s pricing. A salesperson sees a document they were never cleared to read. The system did what it was built to do. Nobody decided what that should be.

So treat “feed the data to AI” the way you’d treat “make the site faster.” It’s a direction. Your job is to come back with the questions that make it buildable.

Five Questions That Turn It Into a Spec

Who is asking, and what do they do next? Name a person and a moment. “Support agents, mid-ticket, checking whether a customer’s plan covers a feature.” “Finance, at month end, explaining a variance.” The next action determines everything downstream. An answer that feeds a customer email needs a higher bar than one that feeds a brainstorm.

Which sources are actually authoritative? “Our data” is usually four systems, two spreadsheets that disagree with them, and a wiki nobody trusts. A model will happily blend all of it into one confident paragraph. Before anything gets connected, someone has to say which system wins when they conflict. That’s an ownership decision, and it will take longer than the integration.

Whose permissions apply? If the model can read it, it can repeat it. The safe default is that the model acts with the asking user’s access. A service account that sees everything will eventually show someone something they shouldn’t see, and that ends in an incident report.

How fresh does it need to be? A policy handbook can be indexed weekly. Inventory, account status, and open tickets go stale in minutes. Stale facts are worse than missing ones because they arrive looking current. Sort sources by how fast they change, and plan to look up the fast ones live instead of copying them into an index.

How will anyone know an answer was right? This one usually gets a blank stare, and it decides whether the thing survives. We automate what we can verify. If the answer cites its source, a person can check it in ten seconds. If it doesn’t, they either trust it blindly or stop using it. Decide up front what a correct answer looks like for twenty real questions, and test against those before launch.

What You Bring Back

Bring back a one-page proposal. One user group. One job. The two or three sources that are authoritative for that job. The access model. A list of real questions with known-good answers.

The page gives your manager something concrete to approve. It also moves the conversation from “should we do AI” to “is this job worth automating.” The second question has an answer. It also has a cost, and you can now estimate it, because you know how many people will ask, how often, and how much they need read to answer. Inference cost follows from the architecture, and you’ve just drawn the architecture.

It also gives you a way to say no to the parts that shouldn’t ship yet. Maybe the CRM data is too messy to be authoritative. Maybe the permissions model in the document store doesn’t map to people cleanly. Those are real findings. Surfacing them in week one is cheaper than discovering them in a postmortem.

Start Narrow on Purpose

The instinct is to connect everything so the model can answer anything. A narrow system that answers one team’s questions correctly builds trust. A broad one that answers everyone’s questions plausibly loses it the first time a plausible answer is wrong.

Pick the job where wrong answers are cheap and easy to catch, ship that, and watch what people actually ask. The questions they bring will tell you which source to connect next. Most of the time it won’t be the one leadership expected.

Your manager asked to feed the data to AI. What they want is some part of the business getting faster without getting worse. The one-pager is how you check whether this project does that.