Hey Alessandro,

1. Technically feasible? Yes.

MLflow's tracking client is just HTTP. As long as your container can reach the Databricks-managed MLflow endpoint, you can send traces from anywhere. Set your workspace host and token as environment variables inside the container, point the tracking URI to Databricks, and you're connected.

2. Production gotchas:

The biggest one for a voice chatbot: don't let MLflow calls block your response path. Send traces asynchronously so observability never adds to user-facing latency.

Use a service principal over a PAT for auth. PATs expire, and manual rotation will catch you off guard in production. Also sort your network config early. If your ACI and Databricks workspace are in different VNets, private endpoints or IP allow-listing needs to be in place before anything else.

3. Alternative worth considering:

If latency is still a concern after going async, an OpenTelemetry sidecar collector in the same container gives you better control over batching and buffering before traces hit the network. You can export via OTLP to Databricks without the direct MLflow overhead.

The hybrid architecture you're describing is a common pattern now. MLflow as the centralized observability layer is a reasonable call. Just keep the tracing async and auth service-principal-based before you go live.

Good luck with the build.