This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why This Matters

If you own a learning product or a corporate training program, you are being pushed to add AI — a tutor, a synthetic presenter, automatic captions, generated quizzes — and every vendor and every engineer will tell you a different "obvious" answer about how to get it. This article gives you the decision framework and the real 2026 numbers so the choice is yours, not the loudest person's: the three ways to add any AI feature, the four drivers that actually decide between them, the cost-per-learner math with worked examples, and the learner-data privacy and lock-in questions that sink build-vs-buy decisions after the contract is signed. It is the decision capstone for where AI fits in a learning product and the AI-specific companion to build vs buy vs extend an LMS. It will not tell you which vendor to pick; it will tell you how to decide.

The Three Ways to Add Any AI Feature

Before any cost talk, fix the vocabulary, because "build vs buy" hides three distinct options, not two.

The first is buy a finished product: you license a vendor that already does the whole feature — for example a synthetic-presenter tool that turns a script into a talking-head video, like the avatar products covered in AI avatars for courses. You get a working feature in days, configure it, and pay a subscription. You write almost no AI code.

The second is call a managed model through an API: the model lives on someone else's servers — a large language model behind a chat tutor, or a speech-to-text service for captions — and your product sends it a request and gets a result back. The vendor that hosts the application programming interface, or API (the doorway one program uses to ask another for something), runs and updates the model; you build the feature around it. You write integration code, not model code.

The third is self-host an open model: you take an openly available model — Llama, Whisper, an open speech model — and run it on hardware you rent or own. Nothing leaves your infrastructure, you can fine-tune it, and there is no per-request vendor fee. In exchange you buy or rent the graphics processing units, or GPUs (the specialized chips that run AI models), and you own the engineering, the scaling, the monitoring, and the 2 a.m. page when it breaks.

The plain analogy: buying a product is eating at a restaurant; calling an API is meal-kit delivery — you assemble, they source; self-hosting is buying the farm. Each can be the right call. Most teams should start at the restaurant or the meal kit and only buy the farm when they are cooking the same dish thousands of times a day.

Three ways to add an AI feature, one row each, compared across four fields: what you run, how long it takes to ship, the shape of the cost, and where learner data goes. 1. Buy a finished product, least control: you run nothing, a vendor runs the feature; it ships in days; you pay per seat, per minute or per credit; learner data leaves your walls. 2. Call a managed API, where most products start: you run your app, they run the hosted model; it ships in weeks; you pay per token or per minute of use; learner data leaves, under a data processing agreement. 3. Self-host an open model, most control and most engineering: you run an open model on GPUs you rent; it ships in months; the cost is a large fixed amount and then little per request; nothing leaves. A band below reads that buying is the restaurant and calling an API is the meal kit, while self-hosting is buying the farm and is only worth it at thousands of dishes a day. Figure 1. The three ways to add any AI feature, from fastest-to-ship to most-control. Buying a product ships in days but offers least control; self-hosting offers most control but the most engineering. Calling a managed API sits in the middle, and is where most learning products should start.

The Four Drivers That Actually Decide

The choice is not "which model scores highest." It is a trade-off across four drivers, and naming them stops a benchmark or a sales deck from making the decision for you.

The first driver is usage volume — how many learners, how many minutes of video, how many tutor messages per month. Volume is the single biggest cost lever, because managed APIs charge per use while self-hosting charges a large fixed amount regardless of use. The second is the accuracy bar — how wrong the feature is allowed to be. Auto-captions on an internal lunch-and-learn can tolerate errors; captions on a compliance course that a regulator may audit cannot, and the higher bar usually favors a specialized vendor or a larger model. The third is data sensitivity — whether the learner data the feature touches can legally and safely leave your walls, which we treat in full below. The fourth is lock-in tolerance — how painful it would be to switch providers later, and how much you will pay now to keep that door open.

Hold all four at once. A high-volume, low-sensitivity, accuracy-tolerant feature (say, draft captions for thousands of internal videos) points toward self-hosting an open model. A low-volume, high-sensitivity, high-accuracy feature (an AI tutor handling named student records for a few hundred learners) points toward a vendor with a strong data-protection contract. The drivers, not the model leaderboard, pick the lane.

The Cost That Matters: Per Learner, Per Month

Translate every option into the same unit — cost per active learner per month — or you cannot compare them. Vendors quote per seat, per credit, per minute, and per million tokens precisely because those units do not line up; convert them all to per-learner and the picture clears.

Start with a managed language model behind an AI tutor. Pricing is per token — a token is roughly three-quarters of a word, the unit models read and write in. Suppose each tutor exchange averages 1,500 tokens in and 500 out, and an active learner has 40 exchanges a month:

Per learner per month:
  in:  1,500 tokens × 40 = 60,000 tokens
  out:   500 tokens × 40 = 20,000 tokens

At a mid-range 2026 API rate of ~$0.30 per million input
and ~$1.20 per million output tokens:
  in:  60,000  / 1,000,000 × $0.30 = $0.018
  out: 20,000  / 1,000,000 × $1.20 = $0.024
  total ≈ $0.042 per learner per month

Four cents per learner. At 5,000 active learners that is about $210 a month — far below the cost of one engineer-week spent standing up your own model. This is why, for most learning products in 2026, calling an API wins: the per-learner cost is tiny and the build cost of self-hosting is not. It helps that API prices fell roughly 80% between early 2025 and early 2026, so the same feature keeps getting cheaper without any work on your side.

Now captions. Speech-to-text is billed per minute: 2026 rates run from about $0.003 per minute for the cheapest managed model to about $0.006 for a mainstream one. A 30-minute lecture costs nine to eighteen cents to caption once. Avatars are the expensive end — synthetic-presenter video runs roughly $2 to $5 per finished minute on the major vendors, so a 10-minute lesson is $20 to $50 of generated video, which is fine for a polished core lesson and ruinous if you tried to render every learner's feed. The lesson is not a single price; it is that each feature has its own unit, and you must reduce them all to per-learner before deciding.

Build vs Buy vs Self-Host: The Comparison

Option Time to ship Cost shape Accuracy ceiling Data control Lock-in Standards / tracking
Buy a finished product Days Per seat / per minute / per credit Vendor-set, often high Lowest — data leaves your walls Highest — their format, their roadmap Emit xAPI/cmi5 from your side; vendor may not
Call a managed API Weeks Per token / per minute, scales with use High — pick the model Medium — depends on the contract Medium — swappable behind an abstraction You wrap results as xAPI statements
Self-host an open model Months Large fixed (GPU + engineering) + low marginal You own tuning; effort-bound Highest — nothing leaves Lowest — you own the weights Full control of the tracking pipeline

The tracking column matters because an AI feature that does not emit a record is invisible to your learning analytics. Whichever option you pick, the AI-generated quiz, the tutor session, or the watched avatar lesson should still produce an xAPI statement so it lands in your reporting — the wiring is in tracking video with xAPI. A bought product that cannot emit a statement leaves a hole in your data.

The Privacy Question: Where Does the Learner Data Go?

This is the question that sinks build-vs-buy decisions after signing, and it is sharper for learning products because learner data is personal data and sometimes protected student records.

When you call a vendor API or buy a product, learner data — names, answers, questions typed to a tutor, faces in a video — leaves your systems and enters theirs. Under the EU's data-protection law, the General Data Protection Regulation (GDPR), Article 28(3), any vendor that processes personal data on your behalf must be bound by a written data processing agreement, or DPA — the contract that says what they may and may not do with the data. No DPA means the processing is unlawful. The single most important clause is whether the vendor uses your data to train its models; the safe answer for a learning product is an explicit contractual "no," with retention limits and named sub-processors. Where US student records are involved, the Family Educational Rights and Privacy Act (FERPA) adds its own constraints on disclosure to third parties.

There is a second, newer trap specific to education. Under the EU Artificial Intelligence Act, an AI system that evaluates learning outcomes, assigns learners to programs, or monitors them during tests is classified as high-risk (Annex III) — and that classification follows the function, not the vendor, so buying the feature does not offload the obligation. A pure AI tutor that gives feedback without affecting grades is generally not high-risk; an AI that scores a final exam is. The high-risk obligations under Annex III now apply from 2 December 2027, which is time to prepare, not time to ignore. This is exactly where build-vs-buy meets compliance: self-hosting keeps the data inside your conformance boundary, while buying shifts data out and makes the DPA your main control — neither removes the high-risk duties if the feature evaluates learners.

Two lanes of the same shape showing where learner data ends up. Left, self-host an open model, inside your conformance boundary: learner data — names, answers, faces — flows down into your own infrastructure, where no third party is involved, there are no sub-processors to vet and you set the retention, and on into an open model on your GPUs, Llama, Whisper or open weights; the strip at the bottom reads that personal data stays in. Right, buy a product or call an API, across the boundary and under contract: the same learner data flows down into a GDPR Article 28(3) data processing agreement, which has to carry a no-training clause, named sub-processors and retention limits in writing, and on into the vendor’s model on the vendor’s servers; the strip at the bottom reads that personal data goes out. A band across both reads that either way, if the feature evaluates learners, EU AI Act Annex III makes it high-risk, the classification follows the function rather than the vendor so buying it does not offload the duty, Annex III obligations apply from 2 December 2027, and US student records add FERPA limits. Figure 2. Where the learner data goes. Self-hosting keeps personal data inside your conformance boundary; calling a vendor sends it across that boundary, where a GDPR data processing agreement is your main control. If the feature evaluates learners, EU AI Act high-risk duties apply either way.

A Common Mistake: Self-Hosting to "Save Money" Too Early

The failure we see most is a team that self-hosts an open model to avoid API fees, then discovers the fees were never the real cost. They rent GPUs that sit idle most of the day, hire or divert engineers to run inference, monitoring, and scaling, and end up paying far more per learner than the API would have cost — while shipping months later. Industry figures put even a minimal internal self-hosted deployment in the low-to-mid six figures a year once you count infrastructure, talent, and maintenance, so the "free" open model is only free of license fees.

The mirror-image mistake is buying a slick vendor demo without reading the data clauses, then learning at security review that learner data trains the vendor's model, the sub-processors are undisclosed, or there is no DPA — and the deal dies after engineering is already built around it. The third mistake is forgetting tracking: a bought feature that cannot emit an xAPI statement looks great in the demo and leaves your analytics blind.

The fixes are simple to state. For a new feature, start with a managed API to validate that learners use it and it helps; you are testing the product, not optimizing the plumbing. Put a thin abstraction layer between your code and the provider so you can switch later. Read the DPA before the demo dazzles you. And consider self-hosting only when steady volume, a hard data-residency requirement, or a need to fine-tune on your own content makes the fixed cost pay for itself.

The Math: When Self-Hosting Actually Pays Off

Self-hosting has a clean breakeven, and seeing it stops the argument. A managed API costs roughly (volume × price-per-unit) and almost nothing when idle. Self-hosting costs a large fixed amount — GPUs plus the engineering to run them — and very little per extra request. The crossover is where the API's growing bill passes the self-host's flat cost:

Self-host fixed cost (illustrative):
  one capable GPU rented ≈ $2,500/month
  + part-time ML/infra engineering ≈ $6,000/month
  ≈ $8,500/month, roughly flat

Managed API at the tutor rate above (~$0.042/learner/mo):
  break-even ≈ $8,500 / $0.042 ≈ ~200,000 active learners

For heavier per-learner AI use the break-even comes sooner;
for light use it may never arrive.

The exact number depends entirely on how heavily each learner uses the feature, but the shape is universal: below the crossover the API is cheaper and faster; above it, and only if the volume is steady, self-hosting wins on marginal cost. Note what the breakeven hides — the fixed cost includes scarce ML engineering time, the hardest line item to staff. For the full platform build-and-run picture, see the learning-platform cost model; for the broader non-AI version of this decision, see build vs buy vs hybrid for learning video.

A chart of cost in US dollars per month against active learners per month, from zero to 300,000 learners and zero to $15,000. A flat green line marks self-hosting at about $8,500 a month whatever the volume. A rising navy line marks the managed API at about $0.042 per active learner per month, starting at zero and reaching about $12,600 at 300,000 learners. The two cross at a marked point, with a dashed line down to the axis and a label reading break-even at about 200,000 active learners; the region left of it is labelled the API wins and the region right of it self-host wins. A panel below gives the arithmetic: self-hosting is one capable GPU rented at about $2,500 a month plus part-time ML and infra engineering at about $6,000, so about $8,500 a month, flat; the managed API at the tutor rate is 1,500 tokens in and 500 out over 40 exchanges at $0.30 and $1.20 per million tokens, so about $0.042 a learner and $210 a month at 5,000 learners; and $8,500 divided by $0.042 is about 200,000 active learners. Figure 3. Cost versus monthly volume. The managed API rises with use but starts near zero; self-hosting is a high flat cost that barely moves. Below the crossover the API is cheaper; only past it, and only at steady volume, does self-hosting win.

The Decision, in One Pass

Most teams can decide with four questions. Is this a new, unproven feature? Start with a managed API — validate before you optimize. Does the feature touch sensitive or regulated learner data that cannot leave your walls? Favor self-hosting, or a vendor with strict residency and a hard no-training DPA. Is the volume both high and steady, with the per-learner cost adding up past the crossover? Self-hosting starts to pay. Is the feature a complete, polished capability you do not want to engineer — synthetic avatars, a turnkey tutor? Buy the product and wire your tracking around it. The hybrid answer — buy or call now, self-host the one high-volume feature later — is not a compromise; it is the mature default.

A decision tree with four questions on one spine. Every Yes leaves to the right into an outcome card and every No drops to the next question. Is the feature new and unproven? Yes leads to start on an API and validate that learners use it and it helps before you optimise it. Does it touch data that cannot leave your walls? Yes leads to self-host it, or a vendor with strict residency and a hard no-training DPA. Is the volume high, steady and past the crossover? Yes leads to self-hosting pays, because past the crossover the fixed cost beats the per-use bill. Is it a polished capability you will not engineer? Yes leads to buy the product and wire your own tracking around it so it is not invisible. A No to all four leads down to hybrid, the mature default: buy or call now and self-host the one high-volume feature later, which is not a compromise but where most learning products land. A panel beside it reads that whatever you pick, the generated quiz, the tutor session and the avatar lesson each emit an xAPI statement. Figure 4. Build, buy, or self-host in one pass. New and unproven routes to a managed API; sensitive data or high steady volume routes to self-hosting; a complete polished capability routes to buying a product. Most products end up hybrid.

↓ Free download: Learning-AI Build-vs-Buy WorksheetA one-page gate to run per AI feature: name the data it touches, weigh the four drivers, convert every option to cost per learner per month, and check the DPA and the no-training clause before you commit.

Where Fora Soft Fits In

We start this conversation at build-vs-buy, not at the model, because that is where the money and the risk live. Fora Soft has shipped video conferencing, streaming, e-learning, and AI-driven video features since 2005, so when a client wants an AI tutor, synthetic avatars, automatic captions, or generated assessments, we map each feature to the right lane — buy, API, or self-host — against its volume, accuracy bar, learner-data sensitivity, and lock-in, and we put a thin abstraction layer in so today's choice is not a cage tomorrow. For most features we recommend a managed API first because it ships fast and the per-learner cost is small, and we reserve self-hosting for the high-volume or data-residency cases where the fixed cost genuinely pays back. Throughout, we wire every AI feature into your tracking and analytics so it is visible, and we read the data-processing terms before the demo, because the cheapest feature to ship is worthless if it cannot pass a security and privacy review.

AI for Video: A Complete Guide to Intelligence in Video Products: From Models and Inference to Computer Vision, Speech, Search, and Generative Video - book coverAI for Video: A Complete Guide to Intelligence in Video Products: From Real-Time Pipelines and Agents to Serving, Cost, Compliance, and Verticals - book coverVideo Streaming: A Complete Guide to Video Delivery: From ABR and CDNs to Players, WebRTC, DRM, and the Economics of Streaming - book cover

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume series that takes the whole video stack apart across 9,000+ pages — encoding, delivery, audio and AI — and someone who works through it can design and build a learning product like the one this article is about. Volume 7 is the closest to this decision: serving and inference infrastructure, the cost per stream-hour of actually running a model, and the regulatory surface — the EU AI Act, biometrics, what a system may collect and keep — that decides whether self-hosting is a line item or a liability. Volume 6 covers the capabilities themselves, the AI-feature lifecycle and the deployment topologies the three lanes above come from, and volume 3 the players, delivery and economics the feature has to sit inside. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

Which of your AI features actually belongs on your own GPUs?

Send us the feature list, the learner data each one touches, and the volume you expect in a year — and we will come back with the lane for each, the cost per learner per month for both options, and the DPA clauses to hold out for before anything is signed. 250+ video products shipped since 2005.

Book a 30-min call →WhatsApp →Email us →

See our case studies

References

  1. EU Artificial Intelligence Act — Annex III, "High-Risk AI Systems Referred to in Article 6(2)" — European Union, 2024 (Regulation (EU) 2024/1689). Classifies AI used in education to evaluate learning outcomes, assign learners, or monitor tests as high-risk; the classification follows the function, not the vendor. Tier 1. https://artificialintelligenceact.eu/annex/3/
  2. EU Artificial Intelligence Act — Article 6, "Classification Rules for High-Risk AI Systems" — European Union, 2024. The rule that an Annex III system is high-risk unless it does not materially influence the outcome of decision-making. Tier 1. https://artificialintelligenceact.eu/article/6/
  3. General Data Protection Regulation (GDPR), Article 28 — "Processor" — Regulation (EU) 2016/679. Requires a binding data processing agreement with any processor (vendor) handling personal data on the controller's behalf; the legal basis for the DPA and no-training clauses. Tier 1. https://gdpr-info.eu/art-28-gdpr/
  4. Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. § 1232g; 34 CFR Part 99 — U.S. Department of Education. Governs disclosure of US student education records to third parties, including AI vendors. Tier 1. https://www.ecfr.gov/current/title-34/subtitle-A/part-99
  5. Experience API (xAPI) Specification, version 1.0.3 — Advanced Distributed Learning (ADL) Initiative. The standard for emitting AI-feature activity (tutor sessions, generated quizzes, watched avatar lessons) as trackable statements to a Learning Record Store. Tier 1. https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md
  6. "LLM API Pricing Comparison 2026: Every Major Model, Ranked by Cost" — CloudZero, 2026. Source for the ~80% API price drop between early 2025 and early 2026 and mid-range per-million-token rates. Tier 4. https://www.cloudzero.com/blog/llm-api-pricing-comparison/
  7. "Self-Hosted LLM vs API: Breakeven Cost, GPU Math & When It's Worth It [2026]" — Braincuber, 2026. Source for the self-host fixed-cost shape, GPU throughput, and the volume-dependent breakeven against managed APIs. Tier 4. https://www.braincuber.com/blog/self-hosted-llms-vs-api-based-llms-cost-performance-analysis
  8. "Open Source LLM Cost: Hidden Expenses in 2026" — AI Superior, 2026. Source for minimal self-hosted deployments in the low-to-mid six figures per year and enterprise figures, the hidden cost of "free" open models. Tier 4. https://aisuperior.com/open-source-llm-cost/
  9. "Best Speech-to-Text APIs in 2026" and OpenAI Whisper API pricing 2026 — Deepgram / DIY AI, 2026. Source for $0.003–$0.006 per-minute managed speech-to-text rates used in the captions math. Tier 4. https://deepgram.com/learn/best-speech-to-text-apis-2026
  10. "HeyGen vs Synthesia (2026): Features, Pricing" — Colossyan / Synthesia, 2026. Source for the ~$2–$5 per finished minute synthetic-avatar video cost used in the avatar math. Tier 6. https://www.colossyan.com/posts/heygen-vs-synthesia/

Where sources disagreed, the standards and law win: vendor marketing claims that an AI feature is "compliant out of the box" were overridden by the EU AI Act's function-based high-risk classification (refs 1, 2) and GDPR's processor obligations (ref 3), which bind the buyer regardless of vendor claims; and the popular "self-hosting is cheaper" framing was tempered by the full-cost analyses (refs 7, 8) showing managed APIs win below a high, steady-volume crossover.