AutoML, short for automated machine learning, is a set of tools that automate the slow, specialist steps of building a prediction model.

The simple definition

A machine learning model is a computer program that learns patterns from examples instead of following rules written by a human. Show it thousands of past loan applications together with the outcomes, and it can learn to estimate the risk of a new application. Show it thousands of labeled photos of parts on a factory line, and it can learn to spot a cracked one.

Normally, creating such a model takes a team of data scientists. They clean the data, invent useful input signals, choose a type of model, test many settings, compare the results and finally prepare the model for use. AutoML automates much of this work. Google describes it as a collection of functions inside its AI platform rather than a separate product, covering data preparation, feature engineering, training, tuning and deployment.

Why organizations need it

Skilled machine learning experts are scarce and expensive, and many business questions never reach them because the queue is long. Many useful questions are also fairly standard: Which customers will leave? How many units will we sell next month? Is this product photo defective? AutoML lets analysts, engineers and domain experts answer these questions without becoming experts in model design. It also gives expert teams a fast baseline, so they can spend their time on harder problems.

Before learning the tools, learn the map, because it has changed and older tutorials still show the old one.

From Vertex AI to Gemini Enterprise Agent Platform

For years, Google Cloud’s managed machine learning platform was called Vertex AI. In April 2026, Google announced the Gemini Enterprise Agent Platform as the replacement evolution of Vertex AI. Google’s documentation now lists renamed products. For example, the former Vertex AI AutoML for vision, video and tables appears as AutoML on Gemini Enterprise Agent Platform, forecasting with AutoML appears as Forecasting on the platform, and Vertex AI Training appears as Managed Training. Google’s older Vertex AI documentation pages state that they are no longer updated and point to the new documentation.

You will still see the old name in many articles, in older console screens, in code samples and in some web addresses. For a beginner, the safe rule is simple: if you read Vertex AI, think of the same platform under its earlier name, and always confirm details in the current documentation.

Products that were retired

Over the last few years Google has shut down several AutoML offerings. Knowing this will save you from following a tutorial that no longer works.

Based on Google’s current pricing and naming pages, the active AutoML capabilities are image models, tabular models and forecasting.

What about text and video?

For text tasks such as sorting support tickets, finding names in documents or judging sentiment, Google points users to Gemini. Instead of training a separate model from scratch, you write clear instructions and a few examples, or tune a Gemini model on your labeled data. For video, Google points to Gemini video tuning. This changes the way you work, but not the goal: you still want a model that gives reliable answers on your own data.

A few simple ideas are enough to understand everything else in this guide.

Data, features and labels

Data is the collection of examples your model learns from. In a table, each row is one example, such as one customer, and each column is one fact about it, such as age or number of purchases. These facts used as inputs are called features. The thing you want to predict is called the target or label. For a churn model, the features might be age, plan type and last login date, and the label is whether the customer left.

Training and prediction

Training is the stage where the model studies examples with known answers and adjusts itself to make fewer mistakes. Prediction, also called inference, is the stage where the trained model gives an answer for a new example whose answer is not yet known. Training happens occasionally and can take hours. Prediction happens constantly and must be fast.

Overfitting and why test data matters

A model can memorize its practice examples instead of learning the general pattern. This is called overfitting. A student who memorizes last year’s questions may fail this year’s exam. To catch this, the data is split into parts. A training part teaches the model. A validation part helps choose between options. A test part is held back until the end to give an honest score. AutoML handles this split for you, but you must understand it, because bad data splits produce misleading results.

Classification, regression and forecasting

Classification predicts a category. Regression predicts a number. Forecasting predicts how a number changes over future time. Choosing the right problem type at the start is one of the most important decisions in the project.

AutoML does not use magic. It automates choices that a skilled person would make, and it does so by trying many options and measuring each one.

Automatic data handling

Raw data is messy. Numbers have different scales, categories are written as words, and some values are missing. AutoML inspects each column, decides whether it holds numbers, categories or dates, and converts it into a form the model can use. It also handles missing values using sensible rules.

Feature engineering

Feature engineering means creating better inputs from raw ones. From a date, you might create day of week and month. From two columns, you might create a ratio. Experts spend a lot of time on this because good features often matter more than the model itself. AutoML tries many such transformations and keeps the ones that help.

Model selection and architecture search

There are many families of models, from simple trees to deep neural networks. For each problem, AutoML tries several of them, and it can even search for the best internal shape of a neural network. This is called architecture search. For tabular work, Google offers an End-to-End AutoML workflow built as a pipeline, which links these stages together.

Hyperparameter tuning

Every model has settings that are chosen before training, such as how fast it learns. These are called hyperparameters. Picking them by hand is slow. AutoML tests many combinations and measures each one, usually guided by earlier results so that it wastes less time on poor choices.

Ensembling

Often the best result comes from combining several models and averaging their opinions. This is called ensembling. A team of five reasonable doctors often beats one brilliant doctor, because their errors do not always line up.

flowchart LR
  A["Your labeled data"] --> B["Automatic data handling"]
  B --> C["Feature engineering"]
  C --> D["Try many model types"]
  D --> E["Tune settings"]
  E --> F["Compare using validation data"]
  F --> G["Combine best candidates"]
  G --> H["Final trained model"]
        

Whatever the data type, an AutoML project follows the same road from idea to working model.

flowchart TD
  A["Define problem"] --> B["Prepare data"]
  B --> C["Create dataset"]
  C --> D["Train with node hour budget"]
  D --> E["Evaluate metrics"]
  E -->|Good enough| F["Deploy or batch predict"]
  E -->|Not good enough| B
  F --> G["Monitor"]
  G -->|Drift or decay| B
        

Notice the arrows that go backward. Real projects rarely run in a straight line. Weak evaluation sends you back to the data, and monitoring sends you back whenever the real world drifts away from your training examples. The loop is normal, not a failure.

Teams that succeed with AutoML spend most of their effort on data, not on models.

Quality over quantity

More examples help, but only if they are accurate and representative. Ten thousand correct examples are worth more than a hundred thousand sloppy ones. Remove duplicates, fix obvious entry errors, and make sure the labels are right. For image work, have more than one person check a sample of labels, because tired labelers make mistakes.

Representative examples

Your training data must look like the real situations the model will see later. A defect detector trained only on photos taken in bright daylight will struggle on a dim night shift. A churn model trained only on last year’s customers may miss the behavior of newer customers. Include the variety that production will bring: different lighting, angles, seasons, regions and customer types.

Balanced classes

If ninety-nine percent of your examples are one answer, a lazy model can score ninety-nine percent accuracy by always guessing that answer, and it would still be useless. Make sure rare but important cases, such as fraud or defects, appear often enough to be learned, and judge the model by measures that care about them.

Avoid data leakage

Data leakage happens when information from the future or from the answer sneaks into the inputs. For example, including a column called refund issued in a model that predicts whether a customer will complain, when refunds only happen after complaints. The model looks brilliant in testing and fails in real use. Ask of every column: would I truly know this at the moment I need the prediction?

Splitting by time when time matters

For forecasting and many business problems, you should test on data that comes after the training period, not on randomly chosen rows. Otherwise the model peeks at the future, and the score looks better than it should.

Tabular data, meaning rows and columns, is the most common business data, and it is where AutoML is often most valuable.

Classification and regression

You choose a target column and a problem type. For classification, the model learns to output a category and usually a confidence for each category. For regression, it outputs a number. AutoML tries different approaches and tunes them within your training budget, which is billed in node hours. After training, the platform presents evaluation numbers and, where supported, information about which input columns mattered most.

Forecasting

Forecasting adds time. Your data must show one or more series of values over time, such as daily sales by store. You tell the system the time column, the target and how far ahead to predict, called the forecast horizon. Forecasting also lets you add helpful extra columns, such as holidays or promotions, because these often explain sudden changes.

Google’s pricing page treats forecasting prediction differently from other tabular inference. It is billed per thousand data points per month, where a data point is one time step in the forecast horizon, and the price per thousand falls as your monthly volume rises. Up to five prediction quantiles are free. A quantile is a way to ask for a range, for example the value that demand will probably stay below nine times out of ten, which is useful for planning stock.

Tabular Workflows

Besides the simple console flow, Google provides Tabular Workflows, which run as managed pipelines. The documentation lists End-to-End AutoML and a Forecasting workflow, each with training, online inference and batch inference guides. Pipelines give you more visibility into each stage and fit better into automated MLOps setups. Because they run on managed pipeline resources, check the tabular pricing page for any extra charges before using them.

AutoML for images lets teams build visual inspection and recognition systems without designing neural networks.

Image classification

You upload images grouped by label. The model learns which visual patterns belong to each label and then assigns labels to new pictures. It suits questions about the whole image, such as is this leaf healthy, or which product category is this photo.

Object detection

Detection goes further. For every object of interest, the model returns a box around it and a label. To train it, humans draw boxes on example images. It suits questions such as how many pallets are on this shelf, or where exactly is the damage on this panel. Labeling takes more effort than classification, because every box must be drawn carefully.

Edge models

Sometimes the model must run on a phone, a camera or a machine on the factory floor, where the connection is slow or the answer must arrive instantly. AutoML supports training image models intended for on-device use, which Google prices separately from the standard cloud-hosted models. Before choosing this path, confirm the currently supported export formats and target devices in the documentation.

Getting better image results

Take photos in real working conditions rather than clean studio setups. Include a good variety of angles and backgrounds. Provide enough examples for every label, including the rare ones. Keep the labeling rules consistent: if one person boxes the whole car and another boxes only the bumper, the model will be confused. Finally, review the mistakes the model makes, because they often point straight at a data problem.

AutoML bills training by compute time, so understanding the budget setting protects you from surprises.

What a node hour is

A node is a machine, or a share of a machine, that does the work. A node hour is one such machine working for one hour. If AutoML uses four machines for thirty minutes, that is two node hours. When you start training, you set a maximum budget in node hours. The system will not intentionally spend more than that on the search.

More budget, better model?

More budget gives the search more time to try ideas, so quality often improves, but with diminishing returns. Doubling the budget does not double the accuracy. Beyond a point, the model stops improving and you simply pay more. A practical approach is to begin with a modest budget, look at the result, and raise it only if the numbers are still climbing and the business value justifies it.

How billing behaves

According to Google’s pricing page, training is billed for the compute used, in thirty-second increments with no minimum duration. A training run that fails is not billed unless the failure was caused by you cancelling it, in which case the time already used is charged. Each deployed model is billed per hour even when no predictions are made, so you must undeploy a model you no longer need. Models that are not deployed, or that failed to deploy, are not charged for hosting.

A single score never tells the whole story. Learn a handful of measures and what each one hides.

Classification measures

Accuracy is the share of correct answers, and it is misleading when one outcome is rare. Precision asks: of the items the model flagged, how many were truly positive? Recall asks: of all the truly positive items, how many did the model find? A fraud model with high precision rarely accuses innocent people. A model with high recall catches most fraud. You usually cannot have both at the maximum, so you choose a balance that suits the cost of each kind of mistake.

The confusion matrix is a small table that counts four outcomes: true positives, false positives, true negatives and false negatives. It shows exactly where the model is wrong, and it should be the first thing you read, not the last.

Regression and forecasting measures

For numbers, the question is how far off the predictions are on average. Common measures average the size of the errors, in the same unit as the target or as a percentage. A small average error can hide a few huge ones, so also look at the worst cases.

Thresholds

Many classifiers output a confidence, and you decide the cut-off above which you act. Lowering it catches more positives but raises false alarms. Raising it does the opposite. This choice is a business decision, not a technical detail.

Look at the mistakes

Scores summarize, but mistakes teach. Sample the cases the model got wrong and look for patterns. Are they all in one region, one lighting condition or one customer type? Often a handful of data fixes improve the model more than any amount of extra training budget.

A trained model creates value only when someone or something uses its answers.

Online prediction

For live answers, you deploy the model to an endpoint, which is a web address that accepts a request and returns a prediction within moments. This suits checking a transaction as it happens or classifying an uploaded photo. You choose the machine size that serves it, and you pay for the time the model is deployed. Traffic can be spread over more than one node when load is high.

Batch prediction

For large collections, you run a batch job. You point it at a file or table, and it writes predictions to a destination when finished. This suits scoring the whole customer list every night or classifying a library of archived photos. Nothing needs to stay deployed, so it is usually cheaper for non-urgent work. Google’s pricing page notes, for example, that forecasting batch inference runs on a large group of high-memory machines, so check the cost for your data size.

Choosing between them

Ask how quickly the answer is needed. If a person or a process is waiting, use online prediction. If the answer can wait minutes or hours, use batch. Many systems use both: batch for the daily routine and online for urgent cases.

AutoML is one part of a larger picture that includes storage, pipelines, serving and monitoring.

The main pieces

Data usually starts in Cloud Storage as files or in BigQuery as tables. A dataset resource on the platform points to that data and records the labels or target column. A training job, run by AutoML, produces a model that is stored in a model registry, which is a catalog that tracks model versions. A model can then be deployed to an endpoint for online use or used in a batch job. Around all of this sit identity and access management for permissions, logging and monitoring for visibility, and pipelines for automation.

flowchart LR
  A["Cloud Storage files"] --> D["Dataset"]
  B["BigQuery tables"] --> D
  D --> E["AutoML training job"]
  E --> F["Model registry"]
  F --> G["Online endpoint"]
  F --> H["Batch prediction job"]
  G --> I["Apps and services"]
  H --> J["Output in storage or BigQuery"]
  K["Pipelines"] --> E
  L["Monitoring and logs"] --> G
        

AutoML is one road among several. Choosing the right road is a skill of its own.

AutoML costs come from four places: training, hosting, predictions and the data and pipeline services around them.

The published price shape

According to Google’s AutoML pricing page at the time of writing, image classification and object detection training are each listed at about three dollars and forty-seven cents per node hour. Training an on-device Edge model is listed at eighteen dollars per hour. Online prediction hosting is listed at about one dollar and thirty-eight cents per hour for image classification and about two dollars per hour for object detection, and batch prediction for images is listed at about two dollars and twenty-two cents per hour. Tabular classification, regression and forecasting training are each listed at about twenty-one dollars and twenty-five cents per node hour, and tabular inference is priced like inference for custom-trained models.

Ways to spend less

Training data often contains the most sensitive information a company owns, so protect it from the start.

Who may do what

Google Cloud uses Identity and Access Management, or IAM, to decide who can perform each action. Give people the smallest role that lets them do their job. A data labeler needs to add labels, not to deploy models. An analyst who reads predictions does not need permission to delete datasets. Separate environments for experiments and production, so that a mistake in a trial cannot touch live models.

Service accounts for automation

Pipelines and applications should use service accounts, which are identities made for software. Give each pipeline its own service account with only the permissions it needs, and avoid sharing one all-powerful account across projects.

Protecting the data

Keep storage buckets private and restrict who can read them. Remove personal data you do not need before training, since a model can sometimes reveal traces of what it learned from. Ask your security team about encryption with your own keys, region choice for data residency, and network controls, and confirm current options in Google’s documentation for the services you use. Record where training data came from and who approved its use.

Governing models

Treat models as controlled assets. Record who trained each one, on which data, with which scores, and who approved it for production. Require a review before a new version replaces an old one. This history is invaluable for audits and for explaining decisions to customers or regulators.

Models age. The world changes while the model stays frozen, so you need eyes on it.

Why models decay

A model learns the world as it was in the training data. Customers change habits, cameras are replaced, new products appear, and seasons turn. When the inputs the model sees in production drift away from what it learned, its answers get worse, often without any error message. This is called drift.

What to watch

Watch the operations: request counts, errors and response times. Watch the inputs: do the values look like the training data, or are new categories and ranges appearing? Watch the outputs: has the share of predicted positives suddenly changed? And, when the real outcome becomes known later, compare it with the prediction to measure true quality. Delays in learning the real outcome are common, so plan how you will collect it.

When to retrain

Retrain when monitoring shows meaningful decay, when you have a large amount of new labeled data, or when the business changes. Each new model should be evaluated against the one in production, ideally on the same fresh test data, and promoted only if it is clearly better.

A model that cannot be questioned should not be trusted with decisions that affect people.

Explainability

Explainability means showing which inputs pushed a prediction up or down. For a loan model, it might show that income and payment history mattered most. Google’s platform has offered Vertex Explainable AI for this purpose. However, Google’s deprecation page lists Vertex Explainable AI as deprecated on March 16, 2026, with a shutdown date of March 16, 2027, and recommends open source libraries such as SHAP and LIME. If you plan a long-lived system, design your explanation step so it can run with those open tools, and check the current status of any built-in explanation feature before you depend on it.

Fairness

Models learn from history, and history contains unfairness. If past decisions favored some groups, a model trained on them may repeat the pattern, even when the sensitive attribute is not an explicit input, because other columns can act as stand-ins. Test performance separately for different groups. Look not only at overall accuracy but also at who bears the cost of the mistakes.

Human oversight

For decisions that matter greatly to people, such as credit, hiring, health or safety, keep a qualified human involved, give people a way to challenge outcomes, and document the model’s limits in plain language. Be honest with users that automated predictions are being used.

These repeatable designs solve common AutoML needs in a clean and safe way.

flowchart LR
  A["Fresh labeled data"] --> B["Data quality checks"]
  B --> C["AutoML training"]
  C --> D["Challenger model"]
  D --> E{"Beats champion on fresh test data?"}
  E -->|Yes| F["Review and approve"]
  F --> G["Promote to production"]
  E -->|No| H["Keep champion, study failures"]
  H --> A
        

These mistakes appear again and again in real AutoML projects.

A short checklist of habits that make AutoML projects calmer, cheaper and more successful.

Start with the decision, not the model

Write down what decision the prediction will change, who will act on it and what a good outcome is worth. A model that is accurate but changes no decision has no value. A model that is only moderately accurate but changes an important decision may be very valuable.

Keep experiments honest

Never evaluate on data the model has seen. Keep a final test set aside and touch it only once, at the end. If you try many versions and keep picking the best on the same test set, you will slowly overfit to it, and the score will no longer be trustworthy.

Document as you go

Record the question, the data source, the date range, the cleaning steps, the budget, the scores and the decision about deployment. Six months later, when someone asks why the model behaves in a certain way, this record will be the most valuable asset in the project.

Here is how different industries typically use AutoML. These are common patterns, not descriptions of specific named customers.

Every technology choice buys something and costs something. Here is the honest balance.

The three-way tension

Most decisions balance speed of delivery, control over the model and cost. AutoML maximizes speed, custom training maximizes control, and Gemini-based approaches shine when language or video understanding is involved. No single choice wins on all three, so pick the one that matches your real constraint.

A prediction service that fails at the wrong moment loses trust quickly, so plan for trouble before it arrives.

Understand limits early

Cloud services protect themselves with quotas, which are limits on training jobs, prediction requests and resources you may use at once. Check the current limits for the features you plan to use, and compare them with expected peaks. Request increases well before a launch, not on launch day.

Build in fallbacks

Decide what your application does if the model endpoint is slow or unavailable. It might use the last known prediction, a simple rule, or a clear message. Test these paths on purpose in a safe environment. Add retries with growing waits for temporary errors, but always with a firm upper limit.

Quick checks for common problems

The real prize is not one clever model, but a reliable routine for producing and improving models.

Why a routine matters

The first model usually works because someone cared for it by hand. The tenth model will not, unless the steps are written down and automated. A lifecycle turns heroic effort into a dependable habit. It makes results repeatable, changes reviewable and failures recoverable.

The building blocks

Pipelines record every step as code, so the same steps can run again with new data. A model registry stores each trained model with its scores and history. Experiment tracking compares runs. Approval steps make sure a human signs off before anything reaches production. Monitoring closes the loop by feeding evidence back into the next training round. Google’s platform offers managed pieces for each of these, including pipeline tooling and tuning and experiment tracking services, and you can adopt them gradually.

sequenceDiagram
  participant D as Data team
  participant P as Pipeline
  participant R as Model registry
  participant A as Approver
  participant S as Serving
  participant M as Monitoring
  D->>P: Provide fresh labeled data
  P->>P: Validate data and train with AutoML
  P->>R: Register candidate with scores
  R->>A: Request review
  A-->>R: Approve or reject
  R->>S: Deploy approved version
  S->>M: Send predictions and metrics
  M-->>D: Report drift and quality
        

Here is a calm, low-risk way to bring AutoML into your organization.

Cloud AI products change quickly, so design your work to survive renames, retirements and new options.

If you used retired AutoML products

If your organization once trained models with AutoML Text or AutoML Video, those services have been shut down, and Google recommends Gemini prompting and tuning for text tasks and Gemini video tuning for video tasks. Plan the move this way. First, collect the labeled examples you used earlier, since these are valuable regardless of the tool. Second, build a test set from them and measure the new approach against your old results. Third, compare cost, speed and quality, including the effort of writing and maintaining instructions. Finally, switch traffic gradually and keep the old results for comparison during the transition.

If you rely on built-in explanations

Google’s deprecation page lists Vertex Explainable AI with a deprecation date in March 2026 and a shutdown date in March 2027, recommending SHAP and LIME. If you depend on it, begin testing the open tools now, record how the explanations compare and update your documentation for auditors.

Keep your assets portable

The most durable parts of an AI project are your data, labels, evaluation sets and written decisions, not the model file. Keep them in formats you control and in your own storage, with clear descriptions. When a tool changes, you can retrain elsewhere in days instead of starting from zero.

Watch the roadmap

Follow the platform release notes and the deprecation page, and review them on a schedule such as monthly. Subscribe the owner of each model to notices for the services it uses. Many painful surprises are simply announcements that nobody read.

Let us follow one imaginary project from the first meeting to a monitored model, using made-up numbers to keep the ideas concrete.

The situation

A streaming company has two hundred thousand subscribers. Every month, about four percent cancel. The retention team can afford to contact only five thousand customers each month with a discount offer. They want to pick the five thousand who are most likely to leave, so that each offer has the best chance to save a customer.

Defining the problem

This is a classification problem on tabular data. The target column is cancelled within thirty days, with the values yes and no. The team writes down the decision the model will change: who receives the offer. They also write the cost of mistakes. A wasted offer costs a few dollars. A lost customer costs much more over a year. That imbalance tells them recall matters, but the limit of five thousand contacts means precision at the top of the list matters even more.

Preparing the data

They build a table with one row per customer per month. Columns include plan type, months subscribed, hours watched in the last thirty days, number of support contacts, payment failures and the device mostly used. Then they ask the leakage question for every column. A column called cancellation survey completed is removed, because it only exists after a person has already decided to leave. They split by time: the first ten months of history for training, the next month for validation and the most recent month as the final test, so the model is judged on the future, not on a random mix.

Training and reading results

They run a short AutoML training with a small node hour budget. The accuracy comes out at ninety-six percent, which sounds wonderful, until they notice that always guessing no would score about ninety-six percent too. This is why they read the confusion matrix and the precision and recall numbers instead. They find that among the top five thousand customers ranked by risk, a good share are real leavers, far above the four percent base rate. That ranking quality is the number the business actually cares about.

Learning from mistakes

Looking at the missed leavers, the team sees many of them joined through a partner promotion. The data had few such customers, so the model learned little about them. They add more examples of that group and a column that marks the acquisition channel. A second short training run improves results for that group without a large budget increase.

Piloting and deploying

Because scoring happens once a month, they choose batch prediction, so no endpoint stays deployed. The output table feeds the retention team’s tool. For the first three months, the team keeps a small control group of risky customers who receive no offer, which lets them measure whether the program truly saves customers or whether the customers would have stayed anyway.

Monitoring and retraining

They log monthly scores and later compare them with who actually left. They set an alert if the share of customers flagged as high risk changes sharply, or if the observed quality falls. A new product launch changes viewing habits, the alert fires, and the team retrains a challenger model on the newest data, promoting it only after it beats the current model on a fresh test month.

AutoML reduces the need for specialist model builders, but it does not remove the need for people with the right skills.

The roles that matter

A successful AutoML project usually needs four kinds of contribution. A business owner defines the decision and measures its value. A domain expert knows what the data means and spots nonsense in it. A data engineer prepares and delivers clean data reliably. A platform or security specialist handles access, cost controls and monitoring. One person can wear several hats in a small team, but every hat must be worn by someone.

Skills worth building

The most valuable skills are not exotic. They are the ability to ask a precise question, to read a confusion matrix, to spot leakage, to write clear labeling rules, to translate model results into business language and to read cloud cost reports. A team that is strong in these basics will get more from AutoML than a team that knows advanced mathematics but skips the basics.

Communicating with leaders

Executives rarely need the details of the model. They need to know what decision it changes, how much value it creates, how sure the team is, what could go wrong and what it costs to run. Prepare a one-page summary in plain words, with one chart that shows the benefit against a simple baseline. Honest descriptions of limits build more trust than inflated promises.

Short answers to the questions beginners ask most often.

Not exactly. Google describes it as a collection of automation functions within its managed AI platform, which is now called the Gemini Enterprise Agent Platform and was formerly known as Vertex AI.

Google announced the Gemini Enterprise Agent Platform in April 2026 as the replacement evolution of Vertex AI. Many services were renamed, and older documentation says it is no longer updated. The practical advice is to use the new name when searching and confirm details in current documentation.

Based on Google’s current pricing and naming pages, AutoML covers image models, tabular models and forecasting. Text and video AutoML have been retired.

Google recommends Gemini prompting and tuning for text classification, entity extraction and sentiment, and Gemini video tuning for supervised learning on video data.

Not for a basic run. You can prepare data, start training and review results through the console. Coding becomes useful when you automate pipelines and connect predictions to applications.

It is one machine working for one hour. Training budgets are set in node hours, and billing is in thirty-second increments according to Google’s pricing page.

At the time of writing, image training is listed at roughly three dollars and forty-seven cents per node hour and tabular training at roughly twenty-one dollars and twenty-five cents per node hour, plus hosting and prediction costs. Always confirm on the official pricing page.

According to Google’s pricing notes, a failed training run is not billed unless the failure came from you cancelling it, in which case the time used is charged.

A deployed model is billed per hour even with no predictions. Undeploy models you no longer need.

On standard problems it often produces a strong baseline quickly. For unusual problems, very large scale or deep customization, experts using custom training can do better. Many teams use both.

It depends on the problem and the data type, and the platform documents minimum requirements for each. In general, quality, variety and correct labels matter more than raw volume.

Yes, but note that Vertex Explainable AI has been deprecated, with Google recommending open libraries such as SHAP and LIME. Check the current status before building on a built-in explanation feature.

Retrain when monitoring shows quality decay or input drift, when you have a meaningful amount of new labeled data, or when the business changes. Test the new model against the current one before replacing it.

You can, with great care. Test for fairness across groups, keep humans involved in important decisions, explain outcomes and allow challenges.

AutoML in Google Cloud lets teams turn labeled data into working prediction models without designing every part by hand. Today it centers on image classification, object detection, tabular classification and regression, and forecasting, all inside a platform that Google has renamed the Gemini Enterprise Agent Platform. Text and video AutoML have been retired in favor of Gemini prompting and tuning, and the built-in explanation service is on a path to retirement, so staying current with the documentation is part of the job.

The tool automates the search, but it cannot fix poor data, unclear goals or missing oversight. Teams that succeed define the decision first, prepare honest and representative data, judge results with the right measures, control cost by managing budgets and endpoints, secure what they build, monitor for drift and keep humans involved where the stakes are high.