AI curriculum

Course outline for Owning the AI Stack

Possessing model weights or business context does not mean an organization can operate or migrate its AI system. Compare sourcing options for one task while separating harness, provider, model, and portable work artifacts. Exercise an outage or exit scenario and make lifecycle responsibility, export rights, and unresolved dependencies explicit.

Technology: AI Strategy and Adoption
Duration: 6 hours
Modules: 3 · 2 hours each
Level: Level 2

About Owning the AI Stack

Owning the AI Stack Course Objectives

Compare SaaS, API, and self-hosted responsibility for a defined task.
Distinguish open weights from verified licensing and data-use rights.
Separate portable task/context artifacts from provider-specific dependencies.
Estimate lifecycle cost including maintenance, review, and migration.
Walk a provider-outage or migration scenario without assuming equivalent quality or automatic privacy.

Pre-requisites

AI capability and limitation awareness equivalent to Artificial Intelligence Foundations.
Familiarity with technology purchasing or product decisions.
Ability to compare supplied contracts, architecture profiles, and cost tables; no coding is required.

Before this course

Complete the required courses or bring equivalent experience. Recommended courses add useful depth; they are not enrolment gates.

Required preparation

Artificial Intelligence Foundations

Recommended preparation

Understands AI sourcing categories and has purchasing/product context; technical operating courses are optional depth for the decision matrix.

Find your place in the learning map

Lab Setup

Computer with a spreadsheet and document editor.
Use supplied architecture, licensing/contract excerpts, cost scenarios, and task-output fixtures for guided analysis.
No cloud account, coding, model download, or paid service is required; current license and contract verification is a decision prerequisite, not assumed by the fixtures.

Detailed Course Outline

Module 1: Sourcing options and model fit

SaaS vs API vs self-hosting: Compare application, provider, and infrastructure responsibilities for the same task; distinguish convenient access from operational ownership and continuity capability.
Open vs closed models: Separate weight availability from licensing, permitted use, and data rights; compare supplied terms without assuming open weights mean unrestricted use.
Local models: Assess hardware fit, task quality, maintenance, logging, and network paths; distinguish local inference from verified privacy and security.
Small language models: Compare supplied task outputs and resource profiles against fixed quality constraints; reject inadequate results even when size or operating cost is attractive.

Practical outcome: Compare supplied options for a fixed task, separating harness/provider/model choices, capability limits, hardware needs, and licensing questions rather than equating open weights with permissive use.

Module 2: Ownership, portability, and exit

Infrastructure ownership: Assign responsibility for operation, maintenance, recovery, and continuity; distinguish possession of infrastructure from the capacity to run it reliably.
Data ownership: Examine supplied storage, export, and data-use terms; distinguish possession of context artifacts from verified rights to retain or migrate them.
Vendor dependence: Inventory portable task contracts, context, and evaluation fixtures alongside nonportable integrations; exercise an outage or exit scenario and mark unresolved blockers.

Practical outcome: Inventory portable task contracts, context, evaluation fixtures, and nonportable integrations; assign operational owners and exercise a supplied outage/migration scenario with unresolved export rights marked.

Module 3: Lifecycle decision

Cost: Estimate setup, operation, maintenance, review, and migration costs; apply mandatory quality and data-use constraints before comparing weighted sourcing options.
Security: Map data paths, access responsibilities, and unresolved protections across sourcing profiles; avoid inferring security from local execution or available weights.
Strategic control: Compare exit rights, portable artifacts, operating capacity, and continuity responsibilities; choose sourcing that preserves required options rather than symbolic ownership.

Practical outcome: Produce a weighted sourcing matrix with maintenance, review, migration, data paths, and continuity responsibilities; distinguish local inference from verified privacy and security.

Practical exercise

Submit a sourcing matrix, responsibility/portability inventory, and tested tabletop exit plan for a fictional organization.
Compare three sourcing profiles and apply the same task contract to two supplied provider-output fixtures.
Reject the fixture that fails the task's quality or data-use constraints, even if its token price is lower.
Preserve every declared portable artifact during the migration walkthrough and assign an owner or unresolved blocker to every nonportable dependency, missing export right, and maintenance obligation.

What you will produce

Choose an AI sourcing model with an explicit, exercised responsibility and exit plan.

How the work is checked

All three sourcing profiles are compared using the same task constraints and lifecycle cost categories; mandatory quality and data-use constraints are checked before weighted ranking.
The incompatible output fixture is rejected rather than accepted on price alone.
Every dependency has a portability classification and an owner or explicit exit blocker.
The plan distinguishes artifact possession, legal rights, operating capacity, and verified security.

Six-hour noncoding sourcing and exit tabletop; live migration, infrastructure operations, and contract review require separate specialists.

When another approach is better

Self-hosting is unsuitable when maintenance capacity or measured task quality is insufficient.
A cheap API is not a good choice when export, data-use, or continuity constraints cannot be met.
Do not infer privacy, licensing rights, or equivalent quality from local execution or open weights.

How we train

Ask about exercises, instructor feedback and the prior knowledge you need. Tool-specific courses marked provisional may become modules in a broader course.

Discuss your learning goals