Responsible AI Fairness and Bias Monitoring

Evaluate Fairness Metrics and Sliced Performance is the practice of measuring whether a model behaves consistently across protected groups instead of judging it by a single overall score. A model can show strong aggregate accuracy while performing poorly for a specific race, gender, class, or other sensitive slice. In Google Cloud, this work connects data validation, Vertex AI Model Evaluation (opens in a new tab) as a pipeline component, explainability, and continuous production monitoring with governance in Model Registry (opens in a new tab).

1.1Data Bias and Model Bias Indicators in the Agent Platform

Data bias and model bias indicators are evaluation signals that separate skew in the dataset from disparate behavior in the trained model. Gemini Enterprise Agent Platform exposes metrics called data bias and model bias that help evaluate fairness across categories such as race, gender, and class. Data bias reflects skew present in the dataset before training, while model bias reflects disparate behavior in predictions or scores after training. Statistical deviations across categories do not automatically prove harm, because differences might reflect sample size, valid base rates, or domain context, so deviations require domain review rather than automatic rejection.

1.2Sliced Evaluation Across Demographic Groups

Sliced evaluation is the comparison of overall model performance against performance computed on predefined data slices defined by demographic groups or sensitive attributes. Sliced evaluation starts by defining fairness measures that match the use case, such as demographic parity, equalized odds, or disparate impact, then evaluating the model for potential biases across different slices. This disaggregated view identifies disparate performance that affects specific subgroups even when aggregate metrics look acceptable.

Proactive bias work spans the machine learning operations (MLOps) lifecycle:

• Analyze training data for bias by detecting skew in feature distributions across different demographic groups or sensitive attributes.
• Evaluate overall model performance and performance across predefined slices of data to surface subgroup disparities.
• Document model limitations, intended use cases, and known potential biases as part of the model metadata in Model Registry.

The evaluation result for a slice depends on the slice definition, the chosen metric, and the dataset used, so the same model version must be compared on consistent slices and datasets over time.

1.3Vertex AI Model Evaluation in Pipelines

Vertex AI Model Evaluation is the Agent Platform capability for scoring model versions against defined metrics and datasets and tracking the results for lineage. The evaluation can run as a pipeline component with Agent Platform Pipelines, either by itself or with other components for data processing, training, evaluation, and deployment. The evaluation component consumes a model version and an evaluation dataset, computes overall and sliced metrics, and the workflow then compares model versions against those metrics. Evaluation results flow from the evaluation component to Agent Platform ML Metadata for lineage and tracking, which links the metrics back to training parameters, dataset version, and code version and feeds re-evaluation or retraining cycles.

1.4Explainability for Diagnosing Bias

Explainability is the set of techniques that show which inputs and logic drove a prediction so teams can check whether the drivers align with domain knowledge and ethical guidelines. Vertex Explainable AI provides feature-based explanations and is integrated with both BigQuery ML and Agent Platform; teams can perform explainability in BigQuery ML or register the model in Agent Platform and perform explainability in Agent Platform. For tabular models deployed on Agent Platform endpoints, feature attributions indicate the input features that contributed most to each prediction, which helps reveal when a sensitive or proxy feature carries unexpected weight.

Additional diagnostic practices connect explanations to decisions:

• Interactively explore model behavior and potential biases on a dataset by using the model-agnostic What-If Tool, which integrates with TensorBoard.
• Integrate explainability into monitoring dashboards and, where trust depends on understanding reasoning, surface explainability data directly through application interfaces.
• For complex generative models, explain the process the agent followed with trace logs, use prompt engineering to elicit reasoning steps, and in retrieval-augmented generation (RAG) applications provide citations for retrieved information.

Explanations do not by themselves prove bias, but they show where to investigate when a slice underperforms.

1.5Continuous Monitoring and Governance of Fairness

Continuous fairness monitoring is the production practice of detecting shifts in model behavior or outputs that might indicate emerging bias or unfairness after deployment. Model Monitoring on Agent Platform tracks prediction drift, data drift relative to training, unexpected shifts in prediction distributions, and spikes in low-confidence predictions, then feeds those insights back into re-evaluation or retraining. Cloud Logging provides an audit trail of key events and decisions, while Error Reporting groups errors to reveal patterns that point to underlying bias or areas needing refinement. Governance preserves the evidence needed to act on those signals, because data lineage from Knowledge Catalog tracks where data comes from, where it is passed, and what transformations are applied to it, which helps identify potential sources of bias or error. Model Registry stores each model version with its training parameters, evaluation metrics, dataset version, and documented limitations, so a fairness regression can be traced from a production prediction back to the data, pipeline, and model version that produced it.

Implement Explainable AI for Bias and Attribution Analysis is the capability to quantify how much each input feature contributed to a prediction and to aggregate those contributions to reveal systematic reliance on sensitive features. Vertex Explainable AI (opens in a new tab), now part of Gemini Enterprise Agent Platform (formerly Vertex AI Platform services), attaches an explanationSpec to a model and returns per-feature attribution values alongside each prediction. Local attributions explain a single instance, while global attributions summarize feature importance across many instances to reveal systematic reliance on sensitive or proxy features.

2.1Sampled Shapley Values for Structured Data

Sampled Shapley attribution is the Vertex Explainable AI method for structured data models that approximates exact Shapley values from cooperative game theory. Shapley values treat each model feature as a player in a game and assign credit to each player in proportion to the outcome of a particular inference. Exact Shapley computation considers different permutations of features, which is intractable for large feature sets, so the service uses a sampling approximation called Sampled Shapley. Increasing the number of sampled paths increases the precision of the approximation, but attributions can change dramatically as precision changes, so low path counts produce unstable explanations.

2.2Explanation Configuration With explanationSpec

The explanationSpec is the model configuration that controls how Vertex Explainable AI computes feature attributions for online and batch predictions. The explanationSpec.parameters block sets the method and its precision, for example sampledShapleyAttribution.pathCount: 6 controls how many permutation paths are sampled and topK: -1 controls how many highest-attribution features are returned. The explanationSpec.metadata block defines the model contract for explanations, with metadata.inputs mapping each input name such as prediction_values, static_value, and historical_values to its inputBaselines, metadata.outputs naming the predicted output such as value, and featureAttributionsSchemaUri describing the output schema. Data flows from the baseline input through the model to the inference output, and the service computes attribution as the change in inference value relative to the baseline value, so the baseline choice determines the question the explanation answers. A meaningful baseline must represent the reference point relevant to the bias question, such as neutral values for advertisement, holiday, date, product, store, and historical sales.

2.3Global and Local Attributions in BigQuery ML

BigQuery ML (BQML) (opens in a new tab) explainability separates local per-row explanations from global dataset-level explanations using extended SQL functions. Local functions return attributions for each row, while global functions aggregate attributions across the evaluation dataset to support bias review. ML.GLOBAL_EXPLAIN returns global explainability by taking the mean absolute attribution that each feature receives for all rows in the evaluation dataset, which surfaces features the model systematically relies on.

The table shows that tree-based models support both local and global views, AutoML Tables explanations are aggregated through ML.GLOBAL_EXPLAIN, and forecasting models explain through decomposition plus regressor attribution. ML.ADVANCED_WEIGHTS is an extended version of ML.WEIGHTS for weight inspection where supported. Choosing a global function is required when the question is whether a proxy feature consistently drives outcomes, while choosing a local function is required when the question is why a single prediction changed.

2.4Interpreting Attributions for Bias and Sensitivity Assessment

Attribution interpretation for bias review starts from the rule that attributions only express how much a feature affected the change in inference value relative to the baseline value. A large positive or negative attribution means that feature moved the prediction away from the baseline prediction, not that the feature is inherently important in isolation. When a sensitive attribute or its proxy, such as store, product, date, or correlated behavioral flags, repeatedly receives high absolute attribution in global results, the model depends on that encoding of historical bias. Counterfactual sensitivity is tested by changing the baseline or the feature value and observing whether the attribution and prediction shift, which reveals whether the model outcome is fragile to that feature.

Configure Continuous Bias Monitoring and Remediation Pipelines is the automated routine that compares production serving data to training data and to earlier serving windows to catch shifts that degrade accuracy and fairness. In BigQuery ML (opens in a new tab), the pipeline centers on descriptive statistics and validation functions that detect data skew and data drift, trigger investigation when thresholds are violated, and feed corrections back into retraining. Because serving data that deviates from training data can degrade performance even when the model itself has not changed, continuous comparison is what keeps deployed models accurate over time.

3.1Data Skew and Data Drift as Risk Signals

Data skew and data drift are two distribution shifts that signal performance and fairness risk in production machine learning (ML) systems. Data skew occurs when the distribution of feature values for training data is significantly different from serving data in production. Data drift occurs when feature data distribution in production changes significantly over time. A model performs best on serving data that is similar to the training data, so understanding variance between training and serving data is critical for ensuring that models remain accurate and equitable across cohorts.

3.2Monitoring Functions in BigQuery ML

Monitoring functions in BigQuery ML are SQL functions that compute descriptive statistics and validate differences between datasets without requiring separate monitoring infrastructure. Training statistics for the model are saved during model training, so the original training data is not required to use skew detection. Statistics for skew checks are only computed for feature columns in the serving data that match feature columns in the training data, which improves performance and lowers cost.

The monitoring functions divide by depth and purpose:

• ML.DESCRIBE_DATA computes descriptive statistics for a set of training or serving data to verify that both datasets are within expected parameters.
• ML.VALIDATE_DATA_SKEW computes statistics for serving data and compares them to the training statistics computed during model creation to identify anomalous differences.
• ML.VALIDATE_DATA_DRIFT computes and compares statistics for two sets of serving data to identify anomalous differences between time spans.
• ML.TFDV_DESCRIBE computes fine-grained descriptive statistics with the same behavior as the TensorFlow tfdv.generate_statistics_from_csv API for integration with existing validation solutions.
• ML.TFDV_VALIDATE compares training-to-serving statistics or serving-to-serving statistics with the same behavior as the TensorFlow validate_statistics API.

The basic functions support quick development and monitoring, while the TensorFlow Data Validation (TFDV) functions provide fine-grained statistics for teams that need to integrate with an existing monitoring solution.

3.3Skew Monitoring Workflow for Production Models

The skew monitoring workflow is the ordered routine for detecting when production inputs have diverged from training inputs. The workflow depends on the training statistics saved by BigQuery ML at model creation, which become the baseline that serving statistics flow into for comparison. This routine is appropriate when teams want to quickly develop and monitor a model for skew without needing fine-grained statistics.

The workflow runs first through validation, then through remediation:

1. Describe baselines: Run ML.DESCRIBE_DATA on training and serving data to confirm both datasets compare appropriately and sit within expected parameters.
2. Create and train: Create a BigQuery ML model and train it on the training data, which saves the training statistics for later comparison.
3. Validate for skew: Run ML.VALIDATE_DATA_SKEW to compare serving statistics against the saved training statistics and flag anomalous differences in matching feature columns.
4. Remediate and retrain: Investigate the root cause of skew, adjust the training data appropriately, and then retrain the model so the new training distribution reflects production reality.

Only after the root cause is addressed does retraining restore alignment between the model and its serving environment.

3.4Drift Monitoring and Continuous Remediation Loop

The drift monitoring loop is the continuous routine that watches for production data changing over time before the datasets diverge too much to retrain. Drift detection in BigQuery ML compares consecutive spans of serving data, for example between different days of serving data, and the comparison lets teams receive notification while correction is still practical. The loop starts with ML.DESCRIBE_DATA on training and serving data to confirm both datasets compare appropriately and remain within expected parameters. When ML.VALIDATE_DATA_DRIFT or ML.TFDV_VALIDATE flags an anomalous difference between serving windows, data flows from the alert into investigation of the shifted features, then into adjustment of training data and retraining. The control boundary sits between serving and training: serving statistics are observed continuously, while the saved training statistics remain the fixed reference until a new model version replaces them. This closed loop turns fairness degradation and accuracy loss from silent failures into measurable events with a defined remediation path of detect, investigate, adjust data, and retrain.

Key Facts

• Sliced evaluation compares overall model performance to disaggregated performance on slices defined by demographic groups or sensitive attributes to reveal disparities hidden by strong aggregate accuracy.
• Vertex Explainable AI computes feature attributions as the change in inference value relative to the chosen inputBaselines, so switching baselines can significantly change values and interpretation.
• ML.GLOBAL_EXPLAIN in BigQuery ML returns global explainability as the mean absolute attribution each feature receives across all rows in the evaluation dataset.
• Data skew compares training data statistics to serving data statistics, while data drift compares earlier serving data statistics to later serving data statistics.
• BigQuery ML saves training statistics at model creation so ML.VALIDATE_DATA_SKEW can detect skew without the original training data, and remediation requires investigating the root cause, adjusting training data, and retraining.