Custom AI Models
Distribution warehouse, the world the AI training hub and assistant runs in
Systems

What replacing four spreadsheets actually took

Building a company's AI infrastructure from zero means the hard part was never the model. It was registration, retention, and who's allowed to see what.

When a distribution company asked me to build a training hub and assistant, the request sounded like one project: "give us an AI tool for training." What actually existed underneath that request was 4 separate spreadsheets, a paper sign-up process, and no single place that knew who had attended what, who was certified, or what the company's own policies actually said when someone asked. The AI assistant was the last thing I built. It was also the smallest part of the work.

The model is not the bottleneck

Every company I've worked with that wanted "an AI tool" already had a reasonably good sense of what they wanted a model to say. What they didn't have was one trustworthy place for the model to say it from. 4 spreadsheets means 4 sources of truth, which in practice means 0 sources of truth, each one slightly out of date, maintained by a different person, contradicting at least one of the others by the time anyone needs an answer.

So before anything resembling retrieval or an assistant got built, the actual first job was data infrastructure: 1 registration system, 1 attendance record, 1 retention record, 1 place access rules live. Natural-language access to business data only works if the data underneath it is actually unified. Point a well-built RAG system at 4 contradicting spreadsheets and you've built a very articulate way to be wrong.

Replacing a paper process is a trust problem, not a technical one

The paper sign-up process wasn't slow because paper is slow. It was trusted because everyone could see it, and because nobody had to wonder whether a system was quietly deciding who counted as "trained" and who didn't. Replacing it meant the new system had to be more legible than the thing it replaced, not just faster. That shaped real decisions: what the assistant is allowed to say with certainty versus what it should hand off to a person, what gets logged, and where a human can always see the underlying record a given answer came from.

A system nobody trusts gets routed around, quietly, until it's just an expensive dashboard nobody opens.

Owning it end to end changes what you build

As the sole architect, with 1 person accountable for every layer instead of 5, I didn't have the option of treating this as "build the model, hand off the integration." Registration, training delivery, attendance, retention, and natural-language access to all of it are 1 system, not 5 handoffs between 5 teams, and the seams between those pieces are exactly where most AI projects I've seen elsewhere quietly fail. Owning the whole thing meant the data model, the access rules, and the assistant were designed together, from the start, instead of a model bolted onto whatever data happened to exist.

That's also why it's still running, and still mine. A system designed as 5 separate handoffs tends to need 5 separate people to keep it alive. One designed as a single system, by the person who understands every layer of it, doesn't.

What actually mattered, in order

All articles
SystemsData infrastructureRAG

Need someone to own this end to end?

I design and build the whole system: the data model, the access rules, the assistant on top. Not one piece handed off to the next person. If that's what you're hiring for, let's talk.

Yeriko VargasAI Systems Architect · Detroit, MI · remote-first