Who Controls Your AI Model's Behavior in Production? (It Might Not Be You)

When you deploy an AI model into production, someone controls how it behaves. That someone is not necessarily you.

The model's behavior — what it says, what it refuses, how it frames ambiguous situations, what it emphasizes — is determined by a stack of decisions. Some of those decisions were made during training. Some during fine-tuning with human feedback. Some through safety filtering systems. And some through system prompt constraints you wrote yourself.

Here is the breakdown of that stack, and which parts you actually control.

The Behavior Stack

Training data is the base layer. The model's world-model — what it knows, what it treats as normal, what associations it has learned — comes from the data it trained on. Training data choices were made by the vendor. You had no input. The data reflects the vendor's priorities, legal constraints, geographic context, and available datasets.

RLHF/RLAIF (Reinforcement Learning from Human Feedback / AI Feedback) is the fine-tuning layer. After pretraining, the model is tuned using human rater preferences to produce outputs that feel helpful, harmless, and honest. Those raters were recruited, instructed, and evaluated by the vendor. Their preferences — their aesthetic sensibilities, their political sensitivities, their thresholds for what counts as harmful — are now encoded in the model's behavior. You had no input into rater selection, instruction, or calibration.

Safety filters apply post-generation in many commercial systems. These are rule-based or classifier-based systems that review model outputs before returning them to the caller. Filters are calibrated for a population of use cases, not your specific use case. They can refuse outputs that are entirely appropriate in your domain.

System prompt and inference parameters are what you control. Temperature, top-p, max tokens, the system prompt — these shape behavior at the margins. You can steer the model. You cannot override the training.

So: when your model produces an output, the behavior was determined by (1) training data, (2) RLHF calibration, (3) safety filters, and (4) your system prompt and parameters — in that order of precedence. You control only the last element.

The Silent Influencers

The RLHF raters who shaped this model were not your domain experts. They were generalist workers evaluating responses across many domains. Their preferences may systematically diverge from what's appropriate in your context.

Some examples of how this plays out:

Format preferences: RLHF raters tend to prefer structured, bulleted responses. A model trained with this preference will produce bulleted lists even when prose is more appropriate for the task. Your domain experts may have strong opinions about this — but the preference is baked in.

Length calibration: Raters trained on consumer use cases tend to prefer concise responses. A model calibrated for consumer brevity may systematically under-elaborate for technical or professional domains where completeness matters more than conciseness.

Hedging behavior: Commercial models are heavily calibrated to hedge uncertain claims. "I'm not a doctor, but..." and "You should consult a professional before..." are RLHF artifacts. In a clinical workflow where users are licensed professionals, these hedges are noise — but they're difficult to train out from the system prompt level alone.

Political and social sensitivities: Raters bring their own values. These values influence how the model handles topics adjacent to contested social questions. The influence may be subtle — a systematic pattern in how topics are framed — but it's real.

None of these are failures. They're reasonable defaults for general-purpose use. They're just not calibrated for your use case, and you didn't choose them.

The Safety Filter Problem for Enterprise

Safety filters are calibrated for the modal use case. For a general-purpose consumer AI assistant, the modal user is not a licensed medical professional, not a security researcher, not a defense analyst. The safety filter assumes a general population.

That's appropriate for consumer products. It creates friction for enterprise professional applications.

A medical AI assistant that refuses to discuss drug dosages or interaction effects because the safety filter treats drug discussion as potentially harmful is not useful to an emergency physician. The filter is calibrated for consumers; the deployment is clinical. The mismatch is structural — you cannot write a system prompt that fully overrides safety filter behavior, because the filter operates after the model generates its response.

This problem appears in every regulated domain. Legal AI that refuses to engage with violent crime case facts. Financial AI that adds disclaimers to internal analysis used by licensed analysts. Security AI that won't discuss known vulnerabilities. The safety filter is right for the consumer context and wrong for the professional one.

When you own the model — when you fine-tune on your domain data and control the inference pipeline — you control the safety calibration too. You can set appropriate thresholds for your user population, which is a population of licensed professionals, not a general consumer audience.

When Vendors Change Behavior

API model updates happen. Sometimes announced, sometimes not. When they happen, behavior changes propagate to your production system immediately, without any deployment action on your part.

This has happened repeatedly across the industry. GPT-4 updates changed summarization style, response length distribution, and refusal patterns — sometimes in ways that broke production prompts that had worked reliably for months. Claude updates changed how edge cases were handled in ways that affected enterprise deployments. The updates were generally improvements from the vendor's perspective and the population average perspective. They were disruptive to specific production use cases.

If you have a compliance requirement to demonstrate that your AI system behaved consistently and predictably over a period — and in healthcare, finance, and legal, you often do — this creates a documentation problem. What model version was running? When did it change? What did that change affect?

With API-based AI, answering these questions accurately is difficult. With a model you own, these are answerable: the version is explicit, changes are explicit, and the documentation is yours.

The OpenAI/DoD Question

In early 2026, OpenAI contracted with the US Department of Defense to provide AI services for military applications. This is a factual business decision.

The question it raises for enterprise AI teams is not about the ethics of that decision. It's about what the decision signals for model development priorities going forward.

Defense contractors have different optimization targets than consumer AI companies. They prioritize reliability under adversarial conditions, specific performance characteristics on specific task types, and — crucially — different safety calibrations. A model optimized for defense applications should have different thresholds than one optimized for consumer use.

Will OpenAI's training process start reflecting these priorities? Will their RLHF calibration shift? Will safety filters be adjusted for defense use cases in ways that propagate to civilian API users? You don't know. There's no mechanism by which you could know. The model is a black box and the training process is proprietary.

This is not a conspiracy claim. It's a governance observation: when your AI vendor changes their strategic orientation, you have no visibility into whether and how that change affects the model behavior your production system depends on.

What Model Ownership Changes

Fine-tuning an open-source foundation model on your domain data changes the control equation at every layer of the behavior stack.

Training data is now your data. You curated it, labeled it, and can document its lineage completely. The model's domain knowledge reflects choices you made.

RLHF calibration can be done with your domain experts as raters, evaluating outputs against your standards, not general population preferences. The behavioral preferences encoded in the model reflect your operational requirements.

Safety calibration is under your control. You set appropriate thresholds for your user population based on your knowledge of who those users are and what they're doing.

Deployment and updates are explicit. The model version is a file you control. It does not change unless you retrain. Changes are decisions your team makes, with pre/post behavioral comparison before promotion.

This doesn't mean you need to run a full MLOps stack. Ertas Fine-Tuning SaaS handles the training infrastructure — you provide the dataset, configure the run, and download the resulting GGUF checkpoint. The model is yours to run on your own hardware, version as you choose, and update on your schedule.

See early bird pricing →

The governance framework for AI in your organization should be able to answer: who made the decisions that determine how this model behaves? If the answer is primarily "the vendor," your governance framework has a gap at the layer that matters most.

Related: Why 'We Use the API' Means You Have No Control and AI Model Governance in Production.