How to Train an AI Model: The Retraction Clock Test

Most teams asking how to train an AI model should not train one. Pick the cheapest rung that meets the requirement, and pick that rung by a single number: how long it would take you to un-teach what you just taught.

That number has a name in this article. We call it time-to-retract, and the reason we lead with it is that every other decision input you will read about — accuracy lift, token cost, GPU hours, data volume — is recoverable. A bad accuracy result costs you a rerun. A model that learned something you are later obliged to remove costs you a rebuild, an evidence trail, and in the worst documented cases the model itself. Our position is that the training decision is an irreversibility decision wearing a machine-learning costume, and that reframing it changes which option most companies should pick.

The situation is ordinary enough that a developer described it on Hacker News in December 2025. Writing about the gap between a framework's release and its arrival in a foundation model's training data, HN user tithos argued for a shift "from 'teaching' (changing weights) to 'informing' (managing context)." That is the same fork every enterprise team hits, just with support tickets and contracts instead of a Rust web server.

The short answer: Choose the lowest rung on the training ladder whose time-to-retract you can live with, because retrieval and prompt assets can be un-said in minutes while fine-tuned weights can only be un-said by retraining.

Last updated: July 30, 2026.

The Retraction Clock: the same four options ranked by how long it takes to un-teach them.

One disclosure before the argument starts. We have not run a controlled fine-tuning benchmark for this article, so every accuracy figure and every price below is attributed to a published source rather than to our own lab, and the worked example is arithmetic over those published prices with its assumptions labelled.

What Training an AI Model Actually Means in 2026

Training an AI model means changing something so that the system produces different output for the same input. That is the only definition broad enough to cover what people mean when they ask the question, and it is deliberately broader than "gradient descent on weights." Four different operations sit under the phrase, they differ by roughly four orders of magnitude in cost, and the confusion between them is where most budget gets destroyed.

There are four operations. Writing durable context and prompt assets; standing up retrieval so the model reads your documents at question time; adapter fine-tuning, where a small set of extra parameters is trained while the base model stays frozen; and full fine-tuning or continued pretraining, where the base weights themselves move. Only the last two change weights. Only the last two are training in the narrow technical sense. All four are what a business person means when they say they want to train AI on custom data.

The field's own usage has drifted toward the broad definition, which is why a practitioner argument on the subject reads as sharply as it does. Discussing model memory in March 2025, HN commenter dimitri-vs described the trade-off in one line: "fine-tune which is a very lossy process that degrades generality." He is describing a real property. Moving weights toward your data moves them away from something else, and you do not get to choose what.

What training is not

Training is not how you get the model to stop making things up. It is not a substitute for access control, because a model that has learned your pricing table will recite it to anyone who can reach the endpoint. It is not a one-time capital project, because the base model underneath you is moving. And it is not what most production systems are doing. In Menlo Ventures' 2024 enterprise survey, retrieval-augmented generation reached 51% adoption, up from 31% the year before, while fine-tuning stayed "surprisingly rare, with only 9% of production models being fine-tuned."

That 9% figure travels widely, so it is worth flagging what happened to it. Menlo's 2025 edition, based on 495 US enterprise AI decision-makers surveyed between 7 and 25 November 2025, does not republish the percentage. It reports the pattern qualitatively instead: prompt design remains dominant, retrieval follows, and fine-tuning alongside tool calling, context engineering and reinforcement learning is "still niche and used primarily by frontier teams." The direction held. The precise number is a 2024 measurement and should be cited as one.

The Retraction Clock: Rank Options by How Fast You Can Undo Them

The Retraction Clock is a one-question test applied to each option: if you had to remove one specific document, customer, or contract from what the system knows, starting now, how long until you could prove it was gone? Answer that per rung and the ranking falls out on its own, because the rungs differ by minutes versus weeks and the difference is structural rather than a matter of effort.

We named it because the decision about how to train an AI model keeps getting made on the wrong axis. Teams compare accuracy lift and token price, both of which are recoverable in an afternoon, and skip the one property that is not symmetrical: adding knowledge to weights is cheap and removing it is not. The asymmetry is the whole decision.

Running the clock takes five questions, and a team that knows its own data can answer them in a single meeting.

1. Whose data is in the training set? Customers, employees, third parties under licence, or nobody's but yours. Each category carries a different revocation trigger.
2. What is the shortest revocation notice you are contractually or legally exposed to? A GDPR erasure request, a data processing agreement termination clause, a licence that expires, a customer who churns and asks for deletion.
3. If that notice arrived tomorrow, what would you have to rebuild? An index row, a prompt file, an adapter, or a base model.
4. How would you prove the removal? Naming the artifact is not proof. A deletion log tied to a specific version identifier is.
5. What breaks while you rebuild? If the answer is "the production system serves stale or wrong answers for two weeks," you have found the real cost of the higher rung.

Question four is the one that fails most often, and it fails quietly. Plenty of teams can delete the data. Far fewer can produce a record showing which model version was trained on which dataset snapshot, which is the artifact an auditor or a customer's legal team will actually ask for.

The Four Rungs Side by Side

Two of the four ways to train an AI model leave the weights untouched. For rungs 0 and 1, a retraction is a file operation. Rungs 2 and 3 move parameters, so a retraction is a training run plus a re-evaluation plus a redeployment. The table below is the at-a-glance version; the four sections that follow give each rung its own verdict block with what it is good for, what it costs, and where it fails.

Two things about this table are worth saying out loud. The cost column is the smallest column. And the time-to-retract column grows faster than the cost column as you climb, which is exactly the property that gets left out of build-versus-buy comparisons.

Rung 0: Context and Prompt Assets

Context engineering means putting the knowledge in the request rather than in the model: system prompts, style guides, worked examples, schema definitions, and a curated set of reference documents pasted in at call time. It changes no weights, which is why its time-to-retract is measured in minutes, and it is the rung that Menlo's 2025 survey still finds dominant in enterprise production.

Best for. Format and behaviour. Getting consistent output structure, a house tone, a fixed refusal policy, or correct use of an internal vocabulary. Also the right first move for any problem you have not yet characterised, because it is the only rung where a wrong answer costs you nothing but the rerun.

What it costs. Input tokens, every call, forever. This is the honest downside and it compounds at volume: a 4,000-token instruction block on a million calls a month is four billion input tokens a month, which is real money at any provider's list price. Prompt caching reduces it substantially but does not remove it.

Where it fails. It fails on scale of knowledge. You cannot paste a 40,000-document policy library into a context window and expect reliable recall of the one clause that matters, and the failure is not obvious from the outside because the model will answer confidently either way.

Verdict. Start here always, and treat the prompt assets as versioned artifacts rather than as strings in code. If you cannot say which prompt version produced a given output, you have already lost the audit trail at the cheapest possible rung, which does not bode well for the expensive ones.

Rung 1: Retrieval Over Your Own Data

Retrieval-augmented generation indexes your documents, finds the relevant passages at question time, and puts them in the prompt. The weights never move, so removing a document from what the system knows is a delete plus a reindex. This is the rung most teams asking how to train an AI model on their own content actually need, and it is where the published evidence on knowledge tasks points.

Best for. Anything where the answer lives in a document and the documents change. Support answers, policy questions, product specifications, contract lookups, internal wikis. Also anything where you need the answer to cite its source, because retrieval gives you the passage and fine-tuning does not.

What it costs. Embedding the corpus once, storing the vectors, re-embedding on change, and the retrieved passages as input tokens on every call. The engineering cost is concentrated in chunking, metadata, and evaluation rather than in the model layer.

Where it fails. It fails when the task is a behaviour rather than a fact. No amount of retrieved context reliably teaches a model to produce a rigid proprietary output format or to reason in a domain-specific chain it has never seen. It also fails when retrieval quality is poor, and retrieval quality is a genuine engineering discipline that teams routinely underestimate.

The permissions catch. A retrieval index inverts the order of the permission check. The pipeline reads the document long before anyone decides whether a given employee may see it, which is the problem we worked through in our earlier analysis of knowledge management governance. Rung 1 keeps the retraction clock short, but it does not give permissions for free. It relocates them.

One caveat on the clock. Deleting an index row stops future answers from using the passage. It does not recall answers already given, cached responses, chat transcripts, or the note somebody pasted into a ticket. A short retraction clock at the model layer is necessary and not sufficient, which is why retention policy on outputs belongs in the same review as the training decision.

Verdict. The default for knowledge. Its retraction clock is minutes, its evidence trail is naturally strong because you can log exactly which passages fed which answer, and the published accuracy evidence supports it as a first move rather than a fallback.

Rung 2: Adapter Fine-Tuning

Adapter methods are the cheap end of fine-tuning pre-trained models: a small number of additional parameters is trained while the base model stays frozen. The best-known is LoRA, whose original paper reports that it can "reduce the number of trainable parameters by 10,000 times" and cut GPU memory threefold relative to fine-tuning GPT-3 175B with Adam, with no added inference latency. That ratio is the reason this rung exists commercially. It made weight-changing cheap enough to be a Tuesday decision rather than a board decision.

Best for. Behaviour, format, and tone that context could not pin down. Classification and extraction tasks with a fixed label set. Latency and cost reduction, where a small tuned model replaces a large prompted one on a narrow task. Domain vocabulary where the base model keeps producing near-misses.

What it does to your accuracy. The most useful published measurement we could find comes from a Microsoft team's pipeline study on agriculture data, which reports "an accuracy increase of over 6 p.p. when fine-tuning the model," and states that the gain is cumulative with retrieval, which adds a further 5 percentage points. Read that carefully, because it is routinely quoted backwards. Fine-tuning and retrieval are additive in that study, not alternatives, and the retrieval half of the gain arrives at a far shorter retraction clock.

Where it fails. It fails as a knowledge store. Facts pushed into parameters go stale silently and cannot be cited. It also fails when the training set is small and unrepresentative, which is the normal condition of a first corporate dataset.

The clock. Days, not minutes. To remove one customer's records you rebuild the dataset, retrain the adapter, re-run your evaluation set, and redeploy. The one structural advantage over rung 3 is that the adapter is a separate artifact: detaching it returns you to the untouched base model immediately, which gives you a fast interim mitigation while the retrain runs. That property is worth more than it looks on a risk register.

Verdict. The right rung for behaviour, the wrong rung for facts. It is also the rung our earlier analysis of vertical AI agents argued is over-reached for: domain knowledge is the cheap half of a specialised agent, and the expensive half is what the thing is allowed to do. Reach for it after retrieval is working and after you have an evaluation set that can tell you whether the tune helped, not before.

Rung 3: Full Fine-Tuning and Continued Pretraining

Full fine-tuning moves the base weights. Continued pretraining goes further and keeps training the base model on a large unlabelled corpus of your own. Both produce a model that is genuinely yours in a way the other rungs do not, and both start a retraction clock measured in weeks.

Best for. A genuinely different distribution: a language, a notation, or a document type the base models handle badly. Sovereignty requirements where the weights must sit inside your boundary and no hosted tuning service is acceptable. Products where the model is the product and a durable capability gap is the business.

What it costs. Everything the lower rungs cost, plus a data engineering programme, plus an evaluation regime you build yourself, plus serving infrastructure. The published token prices in the next section are the smallest line item on the invoice.

Where it fails. It fails on timing, and this is the failure mode teams underestimate most. The base model moves. Stanford HAI's 2026 AI Index records that on the SWE-bench Verified coding benchmark, "performance rose from 60% to near 100%" in a single year, and that as of March 2026 the top-ranked model led the field by 2.7%. A capability you spent a quarter training into a snapshot has a live chance of arriving free in the next base release, at which point your tuned model is both behind and expensive.

Verdict. Justified rarely and deliberately. If you cannot name the specific capability that no base model will have in twelve months, you are buying a depreciating asset with a long retraction clock attached.

Before leaving the rungs, one honest note about vocabulary. Practitioners on this subject disagree in public, and this ten-minute IBM explainer walks the same fork from the model-engineering side rather than the governance side, which is a useful corrective if our framing feels too risk-shaped.

What It Actually Costs, With Published Prices

AI model training cost, for a mid-tier hosted model on a few million tokens of company data, lands in the tens to low hundreds of dollars in training charges at published list prices. That figure surprises people in both directions, which is why the interesting question is not the training charge but the standing charge and the retraction charge underneath it.

Here are current published tuning prices from Google Cloud's Vertex AI pricing page, fetched 30 July 2026. Google defines training tokens as the tokens in your training dataset multiplied by the number of epochs.

Two structural details on that page matter more than the numbers. Google notes that from Gemini 3 onward a "tuned model endpoint prediction price will be 1.5 times of the base model," while older Gemini models keep base pricing. So on the newest generation, the tuned model does not just cost money to make. It costs 50% more to run, permanently.

Microsoft's documentation makes the same point in a different shape. Its guide to deploying a fine-tuned model states that each deployed fine-tuned model "incurs an hourly hosting cost regardless of whether" it is ever called, and that deployments with no calls for 15 continuous days are deleted automatically. There is a Developer tier without the hourly fee, but Microsoft is explicit that it carries no availability SLA and is meant for evaluating model candidates rather than for production use.

A worked example, with the assumptions labelled

Take a 40-person insurance operations team deciding how to train an AI model to draft first-line responses to policy questions. Assumptions, which you should replace with your own: 4,000 historical tickets averaging 750 tokens of question-and-answer text, giving about 3M tokens of curated training data, run for 3 epochs.

The training charge is $45. Nobody's budget dies on $45. What the budget dies on is everything that is not on the price list: curating 4,000 tickets into training pairs, building an evaluation set that can detect regression, the review cycle when the tuned model starts producing a wrong-but-fluent answer on an edge case, the serving premium, and the retraining you will run each time a data question arrives. We priced the invisible half of enterprise AI budgets in more detail in our earlier analysis of implementation cost beyond the licence. The pattern holds here: the model line item is the part you can see, and it is not the part that hurts.

We have deliberately not put a dollar figure on that labour. Curation and evaluation effort varies by an order of magnitude between a clean ticketing export and six merged systems, and a made-up day rate multiplied by a made-up head count would look like evidence while being arithmetic over guesses. Price it against your own team's rates, using the line items named above as the checklist.

The one number in the table that people never budget is row four. A retraction is not a one-off. Any system trained on customer or employee data has a recurring probability of a removal event, and the correct way to price rung 2 or rung 3 is training cost multiplied by expected retrains per year, plus the evaluation labour each retrain drags with it.

Why the Clock Matters: Erasure, Disgorgement, and a Moving Base Model

Three separate forces make time-to-retract the load-bearing variable, and only one of them is regulatory. Together they explain why a decision that looks like an engineering trade-off behaves like a liability decision.

The legal force: erasure is a right, and it does not exempt weights

Article 17(1) of the GDPR gives a data subject the right to obtain "the erasure of personal data concerning him or her without undue delay," and obliges the controller to erase on any of six grounds, withdrawn consent and unlawful processing among them. Nothing in that text carves out model parameters. If personal data went into a training set, the honest answer to "is it erased" is a question about your model lineage, not about your database.

The enforcement precedent is older than the current AI wave and sharper than most teams realise. In January 2021 the US Federal Trade Commission settled with Everalbum, and the FTC's own announcement states that the proposed order requires the company to "delete models and algorithms it developed" from photos and videos its users had uploaded. That remedy, usually called algorithmic disgorgement, treats a trained model as contaminated by the provenance of its training data. It is the clearest possible statement that weights are downstream of consent.

European rules point the same way for the training stage specifically. Article 10 of the EU AI Act requires that training, validation and testing data sets for high-risk systems be "relevant, sufficiently representative," and as far as possible free of errors and complete for the intended purpose, alongside documented governance covering collection, annotation and bias examination. And Article 53, in force since 2 August 2025, obliges providers of general-purpose models to publish "a sufficiently detailed summary about the content used for training." The regulatory direction on training data is toward disclosure and provenance, not away from it. Our guide to EU AI Act compliance for deployers works through what that means for companies that buy rather than build.

The technical force: models remember, and unlearning is not deletion

The comfortable assumption is that training data dissolves into statistics and cannot be recovered. The research says otherwise. Carlini and colleagues, quantifying memorization across neural language models, found that "memorization significantly grows" with three things: model capacity, how many times an example is duplicated in the data, and how much context the prompt supplies. Duplication is the finding with the sharpest business edge. Corporate training corpora are full of near-duplicates: the same clause across 300 contracts, the same customer identifier across a year of tickets.

Machine unlearning is the research field trying to fix exactly this. A 2025 survey of unlearning techniques for large language models describes the goal as removing an example's influence "without requiring full retraining" while preserving the model's general utility, and is candid that the field is early enough to lack a consolidated view of its own evaluation methods. Read that as a schedule risk rather than a technology verdict. Approximate unlearning may well mature. Today, the reliably provable route to removing a training example's influence is still retraining without it, and a plan that assumes otherwise is a plan with an unpriced dependency.

The commercial force: the ground moves under a tuned model

The 2026 AI Index figures cited earlier are the third force. When benchmark performance on a hard coding task moves from 60% to near 100% in a year and the top ten models sit within a few percentage points of each other, the capability you paid to train in has a real chance of arriving in the next base release for free. That is not an argument against ever fine-tuning. It is an argument for treating a tuned model as a depreciating asset with a review date, and for keeping the artifact detachable so you can re-base it cheaply.

Choose This Rung If: The Decision Table

The four ways to train an AI model are not a maturity ladder. They are a set of tools with different reversibility, and the correct answer for most teams is a combination rather than a climb. Here is the explicit selection rule.

The last row deserves emphasis, because the build-versus-buy framing common to this topic tends to hide it. In the Microsoft agriculture study, fine-tuning and retrieval stacked. The hybrid was better than either alone. If your requirement genuinely has both a facts half and a behaviour half, the honest recommendation is not to pick a side but to put the facts in retrieval, where the retraction clock is short, and only the behaviour in weights.

When Training the Weights Still Wins

An honest guide has to say when its own recommendation is wrong. Retrieval-first is our default, and there are four situations where it is the weaker choice.

Latency and unit cost at high volume. A tuned small model that answers in 200 milliseconds without a retrieval hop can beat a large prompted model on both latency and cost by a wide margin. If you are serving millions of narrow, repetitive requests, the arithmetic can flip decisively toward rung 2.

A distribution the base models genuinely do not cover. Low-resource languages, specialised notation, unusual document layouts, and domains where the public web has little representative text. Retrieval cannot supply a competence the model does not have; it can only supply facts.

Sovereignty that forbids the alternative. If policy says weights and data stay inside your boundary and no hosted tuning endpoint is acceptable, then self-hosted training is not a preference, it is the requirement. We have written separately on how that self-hosted versus SaaS deployment decision usually plays out.

The model is the product. If you are selling the capability rather than using it internally, a durable, defensible model is the asset. The retraction clock still applies. You simply have a business reason to pay it.

There is also a case where our framing genuinely does not help. If you have no personal data, no third-party licensed content, and no customer records anywhere near the training set, then the retraction clock is short by construction at every rung, and you should go back to comparing accuracy and cost like everyone else. The clock is a tie-breaker that only bites when someone else has a claim on your data.

Data Preparation Is a Permissions Job, Not a Cleaning Job

The standard advice about training data is about quality: deduplicate, label consistently, balance the classes, hold out a test set. All true, all necessary, and all of it skips the step that determines your retraction clock. Before a single row enters a training set, you need to know who has a claim on it.

Practically, that means every training example carries four fields alongside its content, and they are the fields nobody writes down until the first removal request arrives.

Notice that none of these fields is about data quality. They are access-control metadata attached to training data, and the reason they belong there is that a training set is a permission-collapsing structure. Documents that fifty different people could each see under fifty different entitlements become one artifact that anyone with model access can query. Article 10 of the EU AI Act pushes in this direction for high-risk systems by requiring documented data collection processes and origin, but the operational reason to do it has nothing to do with regulation. It is that without artifact lineage, question four of the Retraction Clock has no answer at any price.

The labelling question people ask most is how much data they need. The honest answer is that the number depends on the rung and the task, and that quality dominates volume everywhere. For behavioural adapter tuning, published vendor guidance and practitioner reports cluster in the dozens-to-low-hundreds range of examples for a narrow format change, rising into the thousands for domain adaptation. We are deliberately not putting a precise threshold in a table, because the number that circulates most in blog posts is not traceable to a source that measured it.

Run the Retraction Clock in One Sitting

This is the procedure, start to finish, for a team that has ninety minutes, one candidate use case, and a decision to make about how to train an AI model against it. It produces a decision and a written justification, which is the artifact you will need again when someone asks why you chose what you chose.

1. State the requirement as an observable failure. Not "improve accuracy." Something like: "the assistant uses the wrong claim-status vocabulary in about one in five drafts." A requirement you cannot observe is a requirement you cannot test a rung against.
2. Classify the requirement as facts or behaviour. Facts change and need citation. Behaviour is stable and needs consistency. If you have both, split them now and run the rest of this twice.
3. Inventory the data you would use, by subject. Four buckets: yours, employees', customers', third parties' under licence. Count rows in each. This is the input to the whole clock, and it is also the step where most sessions stall, because very few teams can classify an export by subject without going back to the source system. If you cannot do it in the meeting, that answer is itself informative: an inventory you cannot produce in ninety minutes is one you will not produce in the two days a deletion request gives you either.
4. Answer the five clock questions per candidate rung. Write the answers down. The one that most often has no answer is how you would prove removal.
5. Price the retraction, not just the training. Training cost times expected retrains per year, plus the evaluation labour each retrain triggers, plus what breaks while you rebuild.
6. Pick the lowest rung whose clock you can live with, and set a review date. If you chose rung 2 or 3, the review date is when you check whether the base model has closed the gap for free.
7. Write down what would make you climb. One sentence: "we move to adapter tuning if format errors stay above 5% after two prompt iterations." Without this, rung 0 becomes permanent by inertia rather than by decision.

A team that runs this honestly usually finds one of two results. Either the requirement is a facts problem and rung 1 answers it, or the requirement is a behaviour problem with no customer data in it, in which case rung 2's clock is short enough not to matter and you should just do it.

Common Mistakes That Wreck a Training Decision

Deciding to train an AI model in order to fix hallucination. Fine-tuning teaches the shape of an answer, not the truth of one, and a model tuned on your documents will produce confidently wrong answers in your house style. Grounding with retrieval and citations is the mechanism that addresses factuality. This is the single most common reason a fine-tuning project fails to deliver what was promised in the business case.

Skipping the evaluation set. If you cannot measure the current failure rate, you cannot detect whether tuning helped, and you certainly cannot detect the regression it introduced somewhere else. Build the evaluation set before the training set. It is the cheaper artifact and it survives every rung change.

Treating a tuned model as done. It has a maintenance schedule: drift as your business changes, staleness as the world changes, and obsolescence as base models improve. A tuned model with no owner and no review date is technical debt that also happens to hold personal data.

One dataset, no provenance. Merging exports from six systems into one training file and losing track of what came from where is how a two-hour deletion becomes a two-week forensic exercise. The provenance fields cost minutes at ingestion and hours after the fact.

Confusing "our model" with "our weights." Using a provider's tuning API generally produces a customisation you can call, not a weights file you can carry to another vendor. If portability matters, confirm it in the contract before the training run, not after.

Letting training happen without anyone owning it. A tuned model deployed by one engineer, on one team's credentials, with no registered owner, is the same governance failure as any other ungoverned AI surface. It is the pattern we described in our earlier analysis of shadow AI, just with a bigger artifact attached.

Where This Analysis Is Still Uncertain

Several parts of this argument could move. Naming them is more useful than writing around them.

Approximate unlearning could shorten the clock at rungs 2 and 3. The research field is active, and if verifiable unlearning becomes practical and auditable, the asymmetry this article is built on gets substantially smaller. We do not think it is there yet, and the survey literature is candid about the gap, but this is the assumption most likely to age.

The accuracy evidence is thinner than the topic deserves. The most-cited controlled comparison of fine-tuning and retrieval, the Microsoft agriculture pipeline, is one study on one domain with a specific model set. Treating "6 percentage points, plus 5 more" as a general law would be wrong. It is directional evidence that the two techniques stack, no more.

Published list prices are not what large buyers pay. The Vertex figures above are list, fetched on one day. Committed-use discounts, negotiated enterprise agreements and regional variation all move them. Prices also change frequently enough that any figure here should be re-checked before it enters a budget.

We could not verify one source a reader would expect. OpenAI's own pricing pages returned HTTP 403 to every automated fetch we attempted, so no OpenAI fine-tuning price appears in the cost table. Rather than quote a secondary source repeating them, we left them out. Check platform.openai.com directly if that provider is on your shortlist.

Our Tier-1 practitioner voices all came from Hacker News. Reddit was unreachable for this run, which skews the practitioner sample technical. The business-side view of this decision is under-represented in our evidence, and readers on that side should weight the engineering caveats accordingly.

We did not run our own fine-tuning benchmark. Every accuracy and price number here is attributed to a published source. The framework is ours; the measurements are not.

Where LeapForce Fits

LeapForce does not train models for you, and nothing on our platform will curate your dataset or run your evaluation. What the training decision produces, though, is a governance object: a model or adapter that holds company data, that someone must own, that must be revocable, and whose use has to be recorded. That layer is what we build. Our AI Gateway puts one governed endpoint in front of every model including your tuned ones, so the record of who called what exists without anyone remembering to create it; the rollout guide we publish is deliberately staged as "Observe first. Enforce second. Optimize third," which is the same discipline this article applies to training, applied to traffic. Ownership of a tuned model as a named, scoped, expiring non-human identity is the access and identity side of the same problem, and per-request evidence lives in observability and audit. Per our published build-status convention, some capabilities in that stack are live today and others are in development, and the product pages label which is which.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.