How Uber governs AI models it doesn't want turning into a black box

Uber's own framing of this problem is a useful lesson on its own: as AI use grows, the instinct is to add more rules for every new system that shows up. Uber's team explicitly rejected that path. More rules per system means more friction for engineers and a governance process that gets slower exactly as the company needs it to get faster.

Instead, they aimed for durable systems and processes flexible enough to absorb new use cases - including the wave of generative AI work that showed up alongside their existing ML platform, Michelangelo - without needing a new governance policy written for every new kind of model.

The technical foundation of the whole program is deceptively simple: a centralized, searchable inventory of every AI system at Uber, called the Model Catalog. Each entry is built around a Model Card - a standardized document giving a shared view of what a model does, its performance and accuracy metrics, and its deployment details, readable by engineers, business owners, and governance staff alike without each group needing separate documentation.

The catalog is wired directly into the ML development workflow itself, with several fields auto-populated from system-generated signals rather than manually filled in by engineers. That detail matters: a governance system that depends on engineers remembering to document things by hand tends to decay over time as teams get busy. Automating the parts that can be automated is what keeps the catalog accurate instead of becoming stale paperwork.

A model catalog tells you a model exists. It doesn't tell you why the model made a specific decision - which is its own governance problem, especially for anything higher-impact, like a prediction that affects pricing or fraud flags. Uber's team built feature attribution directly into Michelangelo, their internal ML platform, so that explainability isn't a separate manual step teams have to remember to do.

They use three different techniques depending on what kind of explanation is needed. Permutation Feature Importance (PFI) gives a global view of a model by measuring how much its accuracy drops when one feature's values are randomly shuffled - the more performance degrades, the more the model actually relies on that feature. For explaining one specific prediction, they use SHAP-based methods (TreeSHAP for tree-based models specifically), which quantify how much each individual feature contributed to that one output - the difference between 'what does this model generally care about' and 'why did it make this particular call.' For deep learning models, where there's no clean tree structure to walk, they use integrated gradients, which trace a prediction back to its inputs by accumulating gradient signal along a path from a neutral baseline input to the actual input.

All of this attribution work runs automatically after training and links straight back into the Model Card, so the explanation isn't a separate artifact someone has to go dig up - it's attached to the same record everyone already looks at.

The part of this program most worth remembering is where the governance check actually happens. Uber's team describes a 'shift-left' approach: governance requirements get folded into the same internal document review process engineers already use to write PRDs and ERDs (product and engineering review documents) at the planning stage, rather than being bolted on right before a model ships.

That timing choice is deliberate. Catching a governance issue during planning costs a conversation; catching the same issue right before release costs a delayed launch and rework. On top of the planning-stage check, they added an in-product enforcement reminder - engineers are prompted to complete a Model Card before deployment - creating an auditable gate that ties governance directly into the actual delivery pipeline instead of living in a separate policy document nobody reads.

New governance rules are the easy part - the harder part is retrofitting them onto every model that already exists in production. Uber's team started this with manual onboarding and beta-testing alongside a few partner teams, then used that feedback to revise their Model Card requirements into a second version before rolling out a company-wide push to bring existing models up to standard.

To make that scale, they moved away from static, one-size-fits-all rules toward a more adaptive classification system, paired with human review for cases that need real judgment rather than a checkbox - distinguishing a model that meaningfully affects a decision from one with incidental, low-impact usage. Their own framing captures the idea well: adoption isn't a one-time rollout, it's an ongoing process of keeping people, platforms, and practices aligned as the company's AI footprint keeps growing.