How AI does the work on a data engagement, and the data it never touches

AI does real work on a data engagement for the same reason a good consultant does. It reads the right things. None of those things is your production data.

There is a fantasy version of AI in data consulting where you point a model at a client's data lake and answers fall out. That is not how the useful work happens, and honestly it is not how I would want it to happen. The real version is more grounded and a lot more disciplined.

On an engagement, AI earns its keep by working from a handful of ordinary project materials, the same ones a careful human consultant would lean on. My private knowledge base is one of them, and it gets attention because it is the unusual one, but it is not the only one and it is not even the starting point. Here is the full set, what each piece is for, and the line that runs through all of them.

The materials the work runs on

Five sources do most of the work. Each answers a different question.

A local copy of the repository. This is the ground truth. The notebooks, the scripts, the pipeline code. It tells me what the system actually does, not what someone remembers it doing. The relevant table schemas can be inferred straight from this code, which is as close to the data as the work needs to get.
Client meeting transcripts, especially discovery and design sessions. This is the spoken record. Discovery sessions capture what the client has, what hurts, and what they actually want. Design sessions capture the decisions we reached together and the tradeoffs behind them. Both hold the concerns raised and the calls made out loud in a room. Months later, a transcript settles arguments that memory cannot.
The statement of work and the pre-sales notes. This is the mandate. The SOW says what we agreed to deliver and where the edges are. The pre-sales and solution architecture notes from the team that scoped the deal carry the original intent, the reasoning behind the shape of the project, handed from the people who sold it to the people who deliver it.
The document deliverables. These are the formal outputs produced during the project. Design documents, architecture decisions, runbooks. They are both a product for the client and a record I can hold the rest of the work against.
The knowledge base. This is memory. It sits across the other four and keeps the distilled facts and decisions so they survive from one session to the next.

The first four are primary sources. They are where the facts live. The fifth is what I remember about them.

How the knowledge base actually works

The repository, the transcripts, the SOW, and the deliverables are large. You cannot hold all of them in your head across a project that runs for months, and re-reading them from scratch every session is slow and easy to get wrong. The knowledge base is what fixes that, and the way I use it is the part most people picture wrong.

I do not write these notes by hand, and I do not sit and read them back. I tell the AI what to capture. Sometimes that is specific, like "save that decision and the reason we made it." Sometimes it is general, like "review the scope section of the statement of work and capture any durable facts worth keeping." The AI distills each one into a small note, one idea per note, and files it with its source attached, so a later read knows whether a client said it in a meeting or I worked it out on my own.

Getting information back out runs the same way in reverse. I do not write queries against a database. I ask the AI a question in plain language, and it is set up to search the knowledge base on its own any time it needs context or history, before it answers or starts building. The store is the AI's long-term memory. I drive it by talking to the AI, not by touching the database.

That arrangement earns its place by doing three things.

A fresh session starts informed. Every AI session begins with a blank slate. One search against the knowledge base at the start hands it the decisions, constraints, and history it would otherwise have to be taught all over again.
Solved problems stay solved. When something comes up that we already worked through, the AI finds the earlier answer instead of redoing the work, or worse, quietly contradicting it.
Design and debugging inherit the reasoning. When the AI is building a feature or chasing a bug, the why behind the earlier decisions is right there, so its logic builds on what we already settled instead of guessing.

It does not replace the primary sources. It points back into them. The transcript is still the transcript. The knowledge base is the working memory that makes the other four usable at speed.

What it actually remembers

It would be easy to assume the most valuable notes are the technical ones, the table shapes and the field names. They are not. Those already live in the code. The notes that earn their keep are the ones no single document holds, the things that exist only because a conversation happened or a decision got made. A few kinds matter most.

Decisions, and the reasoning behind them. Not just what we chose but why we chose it over the alternative. Months later the reasoning is what lets me apply the same call to a new question instead of reopening a settled one.
Constraints that came out of discovery and design. The ones that contradict the obvious reading of the problem. A client's existing model that the new work has to merge into rather than replace. A piece of their vocabulary that means something different from the textbook. These are the highest-value notes in the whole system, because getting one of them wrong means building the wrong thing.
Scope boundaries from the statement of work. What we agreed to deliver, what is explicitly out, and where the edges are. This is what keeps the work, and the AI helping with it, inside the lines.
The language to use in deliverables, and the language to avoid. Where a casual word would set the wrong expectation, the note records the precise phrasing the client and I settled on. A small thing with a big effect on trust.
Open questions, and how sure I am of each answer. Every note carries its source, so a half-confirmed answer from a hallway conversation never gets treated like a locked decision. Knowing what I do not yet know is part of the memory.

Notice that none of these is the client's data. Every one of them is a fact about the work.

What the work needs, and what it never does

Now look at that whole set and notice what is missing from it.

None of these materials is the client's production data. The repository is code, not rows. The transcripts are conversation. The SOW is commercial and scope. The deliverables are design. Schemas can be inferred from the code, and that is the closest the work ever gets to the data.

The actual data, transactional or analytical, OLTP or OLAP, is not in any of these. It does not live on my work laptop. The amount of production data sitting outside a repo on that laptop should always be none, and that is the target I hold to without exception.

PII and HIPAA

This is what keeps the approach safe for regulated work, including healthcare under HIPAA.

The distinction that matters is between the shape of the data and the contents of the data. The code and the design documents can tell me that a field exists and how it moves through a pipeline. The records that actually flow through that pipeline are a different thing entirely. Under HIPAA those real patient records are PHI, and they stay inside the client's own environment. They never land on my laptop and they never enter the knowledge base.

Credentials get the same treatment. Connection strings, keys, and passwords are not knowledge. They are secrets, and they live in a separate secrets manager, never in the knowledge base.

What happens when the project ends

Most of these materials are handled by the normal close of an engagement. Access to the repository goes away. The deliverables are handed over. The transcripts and the statement of work are retained according to whatever the agreement says.

The knowledge base is the one piece that is mine and that persists, so the discipline there has to be explicit. When the engagement closes, client-identifiable information gets cleansed from it. What is allowed to remain is the de-identified lesson. The pattern that worked, stripped of anything that points back to a specific client. I keep the knowledge. I do not keep the client's fingerprints.

That cleanup is part of closing out the work, the same as handing over documentation or shutting down access.

The short version

AI does real work on a data engagement for a plain reason. It reads the same things a careful consultant reads. The code, the conversations, the agreement, the deliverables, and a memory that ties them together. None of that is your data. The architecture travels with me. The data stays home.

If you run data or AI work in a regulated industry and that balance is the thing keeping you up at night, it is worth getting right. It is most of what I think about. admin@westarkdata.com.