ENNL
Book a call

Services / ML and LLM operations

Models and LLM applications that keep working in production.

We take machine learning models and LLM applications from notebook to production on Databricks and keep them there: versioned, tested, monitored and governed. A core team leads, and dedicated engineers join where the work needs them.

Book a callAll services

01 / Problems

Problems we solve

These are the situations that bring teams to ML and LLM operations.

  • Models stuck in notebooksA model works for one data scientist and never becomes a service, because nothing turns the notebook into something a team can release, serve and own.
  • Manual, slow releasesEvery deployment is a handover with hand-built steps, so a change takes weeks and nobody can say which version is running.
  • Drift and quality loss go unseenData changes and models degrade quietly. Without monitoring on inputs and predictions, the first alert is a complaint from the business.
  • LLM apps without evaluation, cost control or audit trailPrompts and models change, and no test set says whether an answer got better or worse. Spend has no cap, and nobody can show which model answered what.

02 / Lifecycle

One path from data to production

Every model and LLM application follows the same six steps, so each release is repeatable and reviewable.

  1. Data and featuresPipelines and a feature store
  2. Training and trackingExperiments tracked in MLflow
  3. Evaluation gateA test set must pass
  4. Registry and approvalModels governed in Unity Catalog
  5. Deployment and servingBatch and real time
  6. Monitoring and feedbackDrift, quality, retraining

03 / What we build

MLOps and LLMOps

Classical models and LLM applications need the same discipline and different controls. We build both on one platform.

MLOps

  • Experiment tracking and a model registry in MLflow, governed in Unity Catalog
  • Training and deployment pipelines as code, released through CI/CD
  • Feature pipelines that give training and inference the same definitions
  • Batch and real-time serving on Databricks Model Serving
  • Drift and performance monitoring with alerts
  • Retraining triggers driven by monitoring results

LLMOps

  • Prompt and model versioning
  • Evaluation sets built from your own cases, with judges checked against people
  • A regression gate in the pipeline that stops a release when quality drops
  • Tracing of every step an application takes
  • Guardrails and policies on requests and responses
  • Cost and token budgets per use case through Unity AI Gateway
  • Inference tables as the audit trail
  • Self-hosted open-weight models with vLLM, or API models, as your rules decide

Cost and token optimisation for LLM applications

04 / Approach

How we engineer it

Five steps, each ending in something you can review. Everything is code in your repositories and is deployed only by pipelines.

  1. Assess the path to production

    We trace how a model reaches users today: who trains it, who approves it, how it is released and who notices when it degrades. The result is a ranked list of gaps.

  2. Build the platform as code

    Terraform and Asset Bundles define workspaces, registry, serving and monitoring. Pipelines deploy them through dev, test, acceptance and production, and nobody deploys by hand.

  3. Run the first model or LLM app through the full path

    One real use case goes from data to production with the evaluation gate, approval, serving and monitoring, so the path is proven on your own work.

  4. Monitoring and runbooks

    Dashboards and alerts for drift, quality, latency and spend, and a runbook for what to do when one fires.

  5. Hand over and train your team

    Your team learns to release, monitor and retrain on the same path. Code, runbooks and decisions stay with you.

The path is a bundle, and every release walks it.

  • The evaluation gate runs before a model version is registered
  • Approval sits between the registry and production
  • The same bundle deploys to every environment
databricks.ymlIllustration
# One bundle ships pipeline, model, endpoint
bundle:
  name: ml-service
targets:
  dev:
    mode: development
  test:
  acceptance:
  production:
resources:
  jobs:
    train_evaluate:   # train, then the gate
  model_serving_endpoints:
    scoring:          # approved versions only

05 / Proof

Machine learning that runs in production

Outcomes are quoted from our case studies. Your result depends on your data, your teams and your starting point.

At RIVM, the Dutch National Institute for Public Health, we built LLM operations frameworks and multi-agent proofs of concept with MLflow, LangChain and Azure AI Foundry. Read the RIVM case

We completed the Databricks Delivery Expert training track for Agent Evaluation, and we build every evaluation set on your own tasks.

  • Databricks
  • MLflow
  • Unity Catalog
  • Terraform
  • Azure DevOps
  • GitHub
  • Python

Governance for AI

One gateway for every model, agent and tool

Every call from teams, agents and coding tools passes through Unity AI Gateway, so access, spend and logs follow the rules of the rest of your data.

  1. Teams, agents, coding toolsWhoever calls a model
  2. Unity AI GatewayPermissions, budgets, limits, policies, logging
  3. Models, MCP servers, toolsDatabricks-hosted and external
  • AccessUnity Catalog privileges decide who may use what.
  • Budgets and limitsSpend and request rates have a cap per use case.
  • PoliciesRules apply to requests and responses.
  • LoggingEvery call lands in Delta tables for audit.
  • RoutingTraffic splits across models, with failover.

How we set it up

  • The gateway and its policies are defined as code and deployed by pipeline, never clicked together.
  • One service per use case, each with its own budget and an owner who answers for it.
  • Inference tables with a retention period and access groups, so logs are useful and not a liability.
  • System-table dashboards for tokens, cost and latency per team.
  • Coding agents such as Claude Code are routed through the gateway, with repository rules and review gates on top.
  • Fallbacks are tested before go-live, by switching a destination off on purpose.
  • Smart Routing stays out of production while it is in Beta.

Generally available. Smart Routing is in Beta. Last verified: 10 November 2026. Unity AI Gateway documentation

06 / Deliverables

What you get and how to start

Each starts with a conversation about your scope.

Typical duration: 4 to 8 weeks

MLOps and LLMOps foundation

We build the path to production for your models and LLM applications on Databricks: registry, pipelines, evaluation gate, serving and monitoring, with your first use case running through it.

What you get

  • Assessment of your current path to production
  • Registry, pipelines and serving as code in your repositories
  • First model or LLM application taken through the evaluation gate to production
  • Monitoring, alerts and a runbook
  • Handover and training for your team
Ask for a quote

Typical duration: 3 days

Databricks health check

We check cost, security with the Security Analysis Tool, governance with Unity Catalog and delivery with Asset Bundles and CI/CD, and give you a prioritised fix list.

What you get

  • Cost and usage review
  • Security and governance findings
  • Delivery and CI/CD review
  • Prioritised fix list with effort
Ask for a quote

All engagement models

Free check

Take the check

A score from 0 to 100 and a next step, in about three minutes.

All six checks

07 / FAQ

Questions about ML and LLM operations

Do you work with our existing models?

Yes. We start from what you run today: models, notebooks, scripts and the tools around them. We assess the path they take to production and build the missing pieces around them. Models that already work move onto a registry, a pipeline and monitoring, and they stay yours.

Which tools do you use?

Databricks on Azure: MLflow for tracking and the registry, Unity Catalog for governance, Model Serving for endpoints and Unity AI Gateway for LLM access and budgets. Terraform and Asset Bundles define the platform, and Azure DevOps or GitHub Actions deploy it. If another tool fits a part of your path better, we say so.

Can you run LLMs on our own infrastructure?

Yes. We serve open-weight models with vLLM on your own servers, on Nebius in European regions or on Azure in an EU region, and we put the same evaluation, tracing and budgets around them as around an API model. The sovereign and self-hosted AI page has the details.

How do you measure LLM quality?

With an evaluation set built from your own cases. Judge models score the answers, and we check the judges against ratings from your people before we trust them. The set runs as a regression gate on every change, and tracing shows every step behind a poor answer.

What do we own at the end?

Everything. Pipelines, platform definitions, evaluation sets, dashboards and runbooks are code and documents in your repositories and your Databricks workspace. Your team is trained on the path, so you can release, monitor and retrain without us.

Next step

Which model should be in production first?

Tell us what you run today and where releases get stuck. We will say what the path to production needs and what a first engagement involves.

Book a callSend a messageor email info@nexops.nl directly

Currently accepting projects for Q4 2026