AI Glossary / AI and machine learning / Beginner

Configuration

Definition

Configuration is the set of choices and settings that control how an AI system runs, from model options and thresholds to file paths, limits and credentials, set without changing the system's code.

What it means

Every AI tool has two layers: the code that does the work and the settings that tell it how. Configuration is the second layer: the dials, switches and values that shape behavior.

Some settings are modeling choices, such as batch size, learning rate or which model version to use. Others are operational: which database to read, how many retries, when to alert, whose key to bill.

Configuration lives in files, environment variables, admin screens or deployment pipelines. Where it lives decides who can change it and how mistakes get made.

Most real-world AI incidents are configuration incidents: the right model pointed at the wrong data, a threshold left at its demo value, a test key used in production.

For a business, the lesson is that buying a good model is not enough. Its configuration, who owns it, who may change it, and how changes are recorded, is where reliability is won or lost.

In modern AI services, prompts and model parameters are configuration too: the same service with a different prompt is behaviorally a different product.

How it works

Settings are gathered in one place, ideally a versioned configuration file or managed settings store, rather than scattered through code.

Environments get separate configurations: development, testing and production each have their own, so experiments cannot touch live customers.

Changes go through review like code changes, because a one-line configuration edit can alter behavior as much as a rewrite.

Secrets such as API keys are kept in a secrets manager, never in shared documents or code, and rotated on a schedule.

Running systems log their active configuration, so after an incident you can see exactly which settings were in force.

Good teams treat configuration as code: versioned, reviewed, tested, and rolled back with the same tooling as software changes.

Three practical examples

  • A threshold value in a config file deciding when the churn model flags a customer.
  • Environment-specific settings pointing the same model at the test database or the live one.
  • A retry and timeout policy for calls to an external AI service, tuned per environment.

Think of it this way

Think of the same car driven by different people: seat position, mirror angles and favorite radio stations are configuration. The engine is identical; the experience is not.

The limit: configuration is powerful exactly where it is dangerous. A seat adjustment is trivial; pointing the fuel line at the wrong tank is not, and both are just settings.

Worked example

the demo threshold that went to production

Suppose a team trials a document classifier with a confidence threshold of 0.5, set quickly for the demo.

The trial succeeds and the system goes live, the threshold untouched. Months later, a review finds half of all flagged documents should never have been flagged, wasting hundreds of review hours. The figures are illustrative.

The team moves the threshold into a reviewed configuration file, sets it deliberately at 0.8, and schedules a quarterly review.

The lesson: configuration inherits the carelessness of the moment it was set, unless someone owns it afterwards.

Illustrative case study

A fictional retailer runs the same recommendation model across three markets. One market's results collapse after a deploy, and engineers spend days hunting a model bug.

The cause is configuration: that market's settings still pointed at an old product feed. The fix is a pre-deploy check that validates every environment's configuration against a checklist.

The invented lesson: when behavior changes suddenly, check configuration before code. It is the most common culprit and the cheapest to inspect.

The retailer's post-incident rule survives: any behavior change triggers a configuration check first, and the checklist lives next to the deploy button. Incidents from settings drop to near zero in the following year.

Common misconceptions and mistakes

  • Configuration is a technical detail for engineers. It encodes business policy, thresholds and targets, so its ownership is a business question.
  • Defaults are safe choices. Defaults are set for demos and average cases, not for your costs and risks.
  • Small setting changes do not need review. A single digit in a threshold can change thousands of decisions a day.

Business use

Name an owner for every AI system's configuration, keep settings under version control, and require review for changes to anything that affects customers or money.

Ask vendors which of their defaults are demo values that you are expected to set for your business.

People also ask

Where should configuration live?

In versioned files or a managed settings store, separated per environment, with secrets in a secrets manager.

Is a prompt part of configuration?

In AI services, yes: prompts, model choices and parameters are all configuration that shapes behavior.

How often should configuration be reviewed?

On a schedule, and after every incident, deploy or change in the surrounding process.

Who should approve configuration changes?

Whoever owns the outcome the setting affects: thresholds by the process owner, credentials by security, models by the technical lead.

Check your understanding

Why do most real-world AI incidents trace back to configuration rather than the model?

Answer: Because the model is usually unchanged while the settings around it, data sources, thresholds, keys and environments, are easy to change, easy to forget and rarely reviewed.

Related terms

  • Environment
  • Threshold (for decision trees)
  • Deployment
  • configuration file
  • secrets management
  • threshold
  • default

Learn next

AI for Business Owners covers the operating discipline that keeps AI tools reliable after the demo ends: https://aiforbusinessandlife.com/academy/ai-for-business-owners. [C2]

More in AI and machine learning

  • Computer audition - Computer audition, also called machine listening, is the use of computational methods to interpret sound.
  • Concept drift - Concept drift is the gradual or sudden change in the relationship between a model's inputs and its target, so that patterns the model learned stop matching...
  • Conceptual clustering - Conceptual clustering groups examples while also developing descriptions of the resulting groups.
  • Confusion matrix - A confusion matrix is a table that lays a classifier's predictions against the true classes, showing not just how often it is right but exactly which...
  • Connectionist expert system - A connectionist expert system uses a neural-style network to represent and apply knowledge for a specialized task.
  • Connectionist temporal classification - Connectionist temporal classification, or CTC, is a training method for sequence models that learn from unaligned data, where the input and output sequences...

Sources

[S2] Google, Machine Learning Glossary; [S8] Jurafsky and Martin, Speech and Language Processing (3rd ed. draft). Full URLs are in the source ledger. Verified 11 October 2026.

Previous: Confidence values Next: Configuration space

  • Home
  • Daily AI Updates
  • Blog
  • AIFBL Academy
  • AI Glossary
  • Products and Tools
  • Store
  • Free CFO AI Prompt Pack
  • About Shihan Sheriff
  • Privacy Policy
  • Terms of Use
  • Refund Policy
  • Cookie Policy
  • Earnings Disclaimer