🧰 The One Who Connects the API Is Not the One Who Built the Model
Consuming Intelligence and Building It Are Different Capabilities
In Colombian technology forums and in regional LinkedIn it's frequent to find profiles presenting themselves as "artificial intelligence experts" with one or two years of experience using automation tools like n8n, Make, or connectors toward OpenAI. The experience is real and useful for what they do. But calling it by the same name that describes decades of work in machine learning, neural networks, and probabilistic systems is not a minor detail.
Having the tool is not having the craft.
Artificial intelligence is a field with more than seventy years of documented history. The term was coined in 1956 at the Dartmouth conference, and since then the field grew by layers that didn't replace each other. The first generation of solutions with real traction was expert systems in the seventies and eighties, programs encoding a specialist's knowledge into logical rules. MYCIN, developed at Stanford in 1972, assisted in diagnosing bacterial infections and showed a machine could perform structured reasoning before any chat interface existed. Then came machine learning, ML, a discipline where models learn patterns from data without anyone explicitly programming each rule. Within ML emerged deep learning, DL, based on neural networks with multiple layers that learn representations of unstructured data like images or text. Generative AI, which dominates headlines today, is a subcategory of DL that produces new objects resembling training data. A model classifying whether an email is fraud is ML. A model writing the email is generative AI. They're different tools for different problems, and confusing them is not an innocent error.
The student who knows how to find the answer at the end of the book answers well when the exercise is there. The one who understands why that answer is correct can solve the one that doesn't appear on any page. Companies hire the second type even if the first is more abundant.
Supervised, unsupervised, and reinforcement ML is still the most frequent type of AI in production within Colombian sectors that have worked with data for more than five years. Fraud detection in banks, churn models in telecommunications, demand prediction in retail, defect classification in manufacturing. Those models don't generate text; they predict, classify, or group. They require knowing how to read evaluation metrics like precision, recall, and AUC-ROC, managing class imbalance, validating against overfitting, and monitoring drift, which is the degradation a model suffers when real-world data starts differing from training data. A practitioner who only knows generative AI tools can't read a confusion matrix, can't evaluate whether a model with ninety-five percent accuracy is actually useless for detecting fraud in a class with one percent positives, and can't decide whether the existing system needs replacing or just recalibrating. Having the tool is not having the craft.
The following example shows two approaches for classifying support tickets at a services company. The first is representative of someone arriving at the problem with experience only in generative AI tools. The second reflects the judgment of someone with ML foundation.
# Without foundation: LLM to classify tickets
import openai
def clasificar(texto):
r = openai.chat.completions.create(
model="gpt-4",
messages=[{"role": "user",
"content": f"Classify into billing, technical, or commercial.\n{texto}"}]
)
return r.choices[0].message.content
# With foundation: model trained on historical data
from sklearn.pipeline import Pipeline
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
modelo = Pipeline([
("vec", TfidfVectorizer(max_features=5000)),
("clf", LogisticRegression(class_weight="balanced"))
])
modelo.fit(textos_historicos, etiquetas)
pred = modelo.predict([nuevo_ticket])
prob = modelo.predict_proba([nuevo_ticket])
The first version works in demos and low volumes, but in production with thousands of daily tickets it generates cost for each API call, unpredictable latency, and inconsistent outputs when the provider's model version changes. The second trains once on the company's real data, classifies in milliseconds, costs cents in infrastructure, and exposes the probability of each prediction to audit errors. The decision between both doesn't depend on which is more modern but on which solves the problem with least risk and cost. Knowing that requires understanding the full map of the field, not just the chapter that circulates most.
In the eighties something similar happened with expert systems. Hundreds of consultants built "AI" solutions encoding rules without understanding the probabilistic reasoning the field was grounded in. When limitations appeared and the first AI winter came, those consultants disappeared; researchers understanding the fundamentals built the next cycle. There's more than one summer in AI history, and having the tool is not having the craft.
Recommended Resources
- IBM Think - AI vs. Machine Learning vs. Deep Learning vs. Neural Networks (explainer)
- MIT News - Explained - Generative AI (article, November 2023)
- Stanford HAI - AI Index Report 2025 (annual report)
- fast.ai - Practical Deep Learning for Coders (free course)
[YouTube embed: Rethinking API Architecture for the AI Era]
MIT News documented in November 2023 that before the generative AI boom, when people talked about AI they usually meant ML models that learned to make predictions on data. The article, produced by researchers from MIT's CSAIL, notes that despite the noise generated by ChatGPT's launch, the underlying technology is not new and the computational advances that sustain it have been built for more than fifty years. The technical distinction matters because it defines what kind of training is needed to design, evaluate, and maintain each system.
Stanford HAI's AI Index, which since 2018 has tracked the global state of the field, documents each year that the inventory of AI types in production is much broader than large-scale language models. Classical ML systems, computer vision, pre-LLM natural language processing, and time series models continue operating in most organizations that adopted AI before 2022. Getting to the open book on the last page doesn't guarantee having read the previous chapters.
First identify what type of problem your company has, whether prediction, classification, grouping, or generation, then ask whether profiles presenting themselves as AI experts can explain when they wouldn't use generative AI, then review IBM's explainer and MIT's article referenced below to build basic evaluation criteria, finally use fast.ai's free course to contrast what you know with what the field has been teaching for decades.
In your company is there someone who can decide when a problem needs classical ML and when it needs generative AI, or is GenAI used for everything because it's what's most heard? 🧰