Google Cloud Storage Can Add AI Metadata to Images and PDFs

Imagine that your company stores thousands of product images, invoices, scanned documents, and PDF reports in Google Cloud Storage. The files are safely stored, but finding the right file can become a problem. A filename such as document_2026_1045.pdf tells you very little about what the document contains.

Developers usually solve this problem by building a separate processing pipeline. The pipeline reads each file, sends it to an AI or machine learning service, collects the results, and saves the extracted information in a database. This approach works, but it adds more code, infrastructure, monitoring, and maintenance.

Google Cloud Storage is introducing Object Enrichments, a feature that can automatically generate structured metadata for supported images and PDF documents. Instead of building the entire analysis pipeline yourself, you can configure Cloud Storage to run Google's pretrained machine learning models and attach the results to the stored objects.

The feature became available in Preview on October 13, 2026. It gives developers another way to make unstructured data easier to search, organize, and use in AI applications.

What Is Object Enrichment in Google Cloud Storage?

Object enrichment means analyzing a stored file and adding useful information about its contents.

Traditional Cloud Storage metadata describes properties such as the filename, content type, file size, creation time, and storage class. These details are important, but they do not explain what is inside an image or a document.

For example, an image might be named warehouse_001.jpg. Its normal metadata tells an application that it is a JPEG file. AI-generated metadata could identify objects visible in the image, such as boxes, vehicles, or people.

Similarly, a PDF might contain an invoice, a tax document, or a financial statement. The filename alone might not tell your application which type of document it is. An enrichment model can classify the document and return structured information about its category.

The important difference is that developers do not have to create and maintain a separate machine learning pipeline just to generate these basic annotations.

Cloud Storage processes eligible objects asynchronously, meaning the upload does not have to wait for the analysis to finish. Once processing completes, the generated information becomes available alongside the object.

Which AI Models Does Google Cloud Storage Support?

Object enrichment offers several pretrained models. You choose the models that match your application instead of running every model against every file.

Model	What it does	Example use case
`object-detector`	Detects objects and their positions in images	Finding products or equipment in photographs
`label-detector`	Assigns labels based on image content	Organizing images by subject or activity
`face-detector`	Detects faces and returns facial landmarks and related measurements	Image analysis and image organization
`content-safety`	Checks images for potentially explicit or violent content	Supporting content moderation workflows
`pdf-classification`	Classifies PDF documents into business or industry categories	Identifying invoices, tax documents, and financial records

Each model produces structured output. Depending on the model, this can include labels, object locations, category information, confidence values, or other model-specific results.

For example, an image-labeling model could help an application group photographs by their visual content. A PDF classification model could help a finance team separate invoices from other documents before sending them to the appropriate processing system.

These results are useful starting points, but they should not automatically be treated as verified business facts. A model can make mistakes, and sensitive decisions may still require validation or human review.

How Object Enrichment Works

The feature uses a configuration to define which buckets Cloud Storage should monitor and which models should run.

The process can be understood in four steps.

Step 1: Choose the buckets

You identify the Cloud Storage buckets that contain the images or PDFs you want to analyze. The configuration uses specific bucket names, so you should decide carefully which data belongs in the workflow.

For example, a company might enable enrichment for a bucket containing product photographs without enabling it for a separate bucket containing confidential employee documents.

Step 2: Select the models

Choose one or more supported models based on your requirements. A product-image workflow might use image labeling and object detection, while a document-management workflow might use PDF classification.

Selecting only the models you need can help avoid unnecessary processing and cost.

Step 3: Let Cloud Storage process eligible objects

Cloud Storage scans eligible objects asynchronously and runs the selected models. The results are stored as object contexts, under the custom context metadata associated with the object.

Each enrichment payload uses a Google-managed context key with a google:annotation: prefix. The generated information is therefore associated with the stored object instead of requiring developers to maintain a separate mapping for every result.

Step 4: Use the generated metadata

After enrichment, applications can inspect the metadata for individual objects through supported Cloud Storage interfaces and APIs.

For larger collections, Storage Insights can export object metadata and enrichment information into BigQuery. Developers can then use SQL to filter, search, and analyze the results across many objects.

This separation is useful: Cloud Storage handles the enrichment process, while applications and analytics systems decide what to do with the results.

How to Configure Object Enrichment

You can configure object enrichment through the Google Cloud console, the Google Cloud CLI, or the JSON API.

Before starting, make sure your project has the necessary permissions and that the service agent can access the target buckets. You also need to choose a supported processing location.

The following command illustrates how to create a configuration using the Google Cloud CLI:

gcloud alpha storage feature-configs create image-enrichment \
    --description="Classify product images and PDF documents" \
    --auto-annotate-models=label-detector,object-detector,pdf-classification \
    --auto-annotate-processing-location=asia \
    --include-bucket-id-regexes=company-content-bucket

Here is what the command does:

image-enrichment is the identifier for the configuration.
--description provides a short explanation of its purpose.
--auto-annotate-models selects the image-labeling, object-detection, and PDF-classification models.
--auto-annotate-processing-location specifies the processing location. The supported values are us, eu, and asia.
--include-bucket-id-regexes identifies the bucket to include. Despite the flag's name, the configuration requires exact bucket names; wildcard patterns are not supported.

The gcloud alpha command is part of the alpha CLI surface, so check your installed Google Cloud CLI version and the current feature requirements before using it in an automated deployment.

You must also grant the object-enrichment service agent the required permissions. Creating a configuration alone does not guarantee that processing will succeed if the service cannot read the objects or attach the generated metadata.

For a production environment, use the narrowest permissions that satisfy the workload. Granting access only to the required buckets is generally preferable when project-wide access is unnecessary.

Important Limitations to Understand

Object enrichment can reduce the amount of custom code you need to maintain, but it has several restrictions worth checking before you enable it.

Supported file types and size

Cloud Storage uses an object's Content-Type metadata to decide whether it is eligible for processing. Supported image types include BMP, GIF, ICO, JPEG, PNG, TIFF, and WEBP. PDFs must use the application/pdf content type.

Objects must be 20 MiB or smaller.

This means a file with a misleading or missing content type might not be processed, even when its actual contents are a supported image or PDF. Validate content types during upload rather than relying entirely on file extensions.

Processing is asynchronous

Do not assume that enrichment metadata will be available immediately after an upload. Cloud Storage processes objects in the background, and configuration changes can take up to 24 hours to take effect.

Applications should be designed to handle objects whose enrichment is still pending. For example, a document-management interface could display the uploaded file immediately and add classification information when it becomes available.

Some bucket configurations are unsupported

Object enrichment is incompatible with Rapid buckets and buckets that have hierarchical namespace enabled. It is also incompatible with bucket relocation while the relevant configuration remains active.

Check these restrictions before designing a workflow around an existing bucket.

Processing location matters

Choose a processing location that meets your organization's data residency and compliance requirements. Cloud Storage supports the us, eu, and asia processing locations.

Configuring multiple processing locations for the same bucket and model can cause the same objects to be processed more than once, resulting in additional charges. Keep the configuration aligned with your actual requirements.

Using Enrichment Results in BigQuery

The generated metadata becomes particularly useful when a bucket contains thousands or millions of objects.

Suppose an online retailer stores product photographs from multiple suppliers. The team wants to find images that contain a particular type of object without opening every image manually.

After configuring Storage Insights to export the relevant metadata into BigQuery, developers can query the exported enrichment information using SQL.

For example, a simplified query against a table containing already-extracted image labels might look like this:

SELECT
  object_name,
  label
FROM
  `my_project.product_catalog.image_labels`
WHERE
  LOWER(label) LIKE '%vehicle%'
ORDER BY
  object_name;

This query assumes that your own downstream process or query layer has made the generated labels available as rows in the illustrated image_labels table. The table is an example, not an automatically created table with that exact name or schema.

In an actual implementation, use the documented Storage Insights export schema and the object_contexts_catalog_view view to access the exported object-context data. The precise SQL depends on the model, the exported fields, and how you want to extract the labels.

This distinction matters because generated metadata is model-specific. A face-detection result has a different structure from a PDF-classification result, so a single query cannot safely assume that all enrichment payloads contain the same fields.

BigQuery is useful when you need to search across a large collection. For a single file, inspecting its object context directly may be simpler.

Advantages and Disadvantages

Advantages

Less custom infrastructure: You do not need to build a complete image or PDF analysis pipeline just to generate supported metadata.
Better discoverability: Generated labels and document categories can make large file collections easier to organize and search.
Flexible model selection: You can choose models based on the kind of content your application stores.
Useful analytics integration: Storage Insights and BigQuery provide a path to analyzing enrichment results across large collections.
Support for existing objects: The feature is designed to process eligible stored objects, not just files uploaded after configuration.

Disadvantages

Preview availability: The feature is in Preview, so its behavior and support commitments may change.
Background processing delays: Enrichment is not guaranteed to finish before an application needs the metadata.
Additional costs: Model inference, metadata storage, data access, and networking can incur charges.
File restrictions: Unsupported content types, oversized objects, and incompatible bucket configurations can prevent processing.
Model errors: Automatically generated labels and classifications need validation when accuracy is important.

Best Practices for Developers

If you plan to use object enrichment in a real application, a few practical decisions will make the workflow more reliable.

Start with one bucket and a small set of models. Test the output against real files before expanding to larger collections. This helps you understand the quality of the results and estimate the processing cost.

Validate content types at upload time. Make sure images and PDFs have correct Content-Type metadata. A valid file with incorrect metadata can be skipped.

Design for delayed results. Keep upload completion separate from enrichment completion. If your application needs the generated labels immediately, introduce an explicit pending state rather than assuming the metadata will already exist.

Monitor processing status. Use the available Cloud Monitoring metrics to track pending objects, model executions, and processing progress. Missing enrichment data should be investigated instead of silently treated as a negative result.

Review permissions and data residency. Give the service agent the access it needs, choose the appropriate processing location, and confirm that your data-handling requirements are satisfied.

Validate high-impact decisions. AI-generated classifications can support document routing and moderation, but they should not replace human review where an incorrect result could have serious consequences.

Measure the total cost. Include model inference, data access, metadata storage, and any BigQuery analysis in your estimate. If Autoclass is enabled, reads performed for enrichment can also trigger storage-class transitions.

Common Problems and How to Troubleshoot Them

Problem	What to check
No enrichment metadata appears	Confirm the configuration is active, the service agent has the required permissions, and processing has had enough time to run.
Some images are skipped	Check the file size and `Content-Type` metadata. The object must meet the supported format and size requirements.
PDFs are not classified	Confirm that the object is a supported PDF, is no larger than 20 MiB, and has `application/pdf` as its content type.
Results are delayed after configuration changes	Allow time for the configuration to propagate. Updates can take up to 24 hours to take effect.
Processing costs are higher than expected	Review the selected models, processing locations, data access charges, and whether the same bucket and model are configured in multiple locations.
BigQuery queries cannot find the results	Verify that Storage Insights datasets are configured and that you are querying the exported object-context schema rather than assuming a custom table exists.

What This Means for Developers

Google Cloud Storage Object Enrichments gives developers a more direct way to turn stored images and PDF documents into data that applications can work with.

Previously, a team that wanted to classify files might have needed a separate service to read objects, call machine learning models, process responses, and maintain a database of results. With object enrichment, Cloud Storage can handle the supported analysis and attach the generated metadata to the objects themselves.

That does not remove every engineering task. Developers still need to configure permissions, choose models, handle asynchronous processing, validate the results, monitor costs, and build the application logic that uses the metadata.

For teams working with large image collections, document repositories, content moderation, or AI-powered search, this feature is worth evaluating. Start with a small set of real files, measure the quality and cost of the results, and expand only when the workflow meets your application's requirements.

Object enrichment is currently in Preview, so teams should also review the feature's current limitations before making it a critical part of a production system.