A typical introduction to generative AI covers what a large language model is, how to write a decent prompt, and perhaps a warning about hallucination. That is a reasonable starting point, and it is also where most internal trainings stop. The training I delivered internally was built to keep going past that point, into the mechanics that actually determine what a model can do, what it costs to run, and where it can be attacked.
Our audience was not machine learning engineers. It was SAP technical consultants and colleagues evaluating whether and how generative AI belongs in enterprise workflows. That audience does not need to train a model. It does need enough of the real mechanics to ask good questions: why does this response cost more than that one, why did the model just make something up, and what happens if an agent reads a document it was never supposed to trust.
The material moved in six stages, each one building on the last rather than sitting as an isolated glossary entry.
It started with foundations: what artificial intelligence, machine learning, and neural networks actually are, at a level precise enough to be useful rather than just reassuring.
From there it moved into the actual mechanics of a large language model: tokenization, embeddings, the transformer architecture, and the self-attention mechanism that lets a model weigh every word against every other word in its context window.
Next came how models are built and aligned: pretraining on raw text, supervised fine tuning to follow instructions, reinforcement learning from human feedback, and Constitutional AI as an alternative alignment approach that uses a model to critique itself against written principles rather than relying only on human labeling.
This is where the curriculum diverged from a typical introduction. Rather than stopping at prompting technique, it continued into production realities that determine cost and latency in practice: the key value cache that avoids recomputing every previous token during generation, quantization that compresses a model down to lower precision for a fraction of the memory cost, mixture of experts architectures that route each token to only a few specialized subnetworks instead of the whole model, and speculative decoding, where a small fast model drafts tokens for a larger model to verify in parallel.
It closed with applied architectures and security: retrieval augmented generation for grounding a model in real data, vision language models, agentic AI systems that plan and act rather than just answer, and a security section that specifically separated direct prompt injection, where an attacker types a malicious instruction straight into a chat, from indirect prompt injection, where the malicious instruction is hidden inside a document, email, or web page the AI reads on its own.
None of this was depth for its own sake. A consultant who understands quantization can reason sensibly about why a smaller model might be the right choice for a cost sensitive workload. A consultant who understands the difference between direct and indirect prompt injection is far better placed to ask the right question before connecting an AI agent to a live SAP data source, a question this website addresses directly in the multi agent architecture and private development stack pieces published elsewhere in the AI Projects section.
A curriculum builds vocabulary and mental models. It does not substitute for hands on practice, and I have been careful not to present it as if it did. The genuine hands on work, the actual pipelines and architectures built and debugged, live in the AI Projects section of this site, and the two are meant to be read together rather than in isolation.
Teaching generative AI honestly to a non specialist audience means resisting the temptation to stop at the demo. The mechanics that decide cost, capability, and risk are not advanced trivia. They are the difference between an audience that can use AI and an audience that can reason about it.