What Is Spring AI? The Enterprise Java Framework for Calling Any AI Model

July 11, 2026 · Spring AI for Enterprise Java (part 1)

▶ Watch on YouTube & subscribe to The Stack Underflow

Every AI tutorial starts the same way: pip install openai, paste a key, call an HTTP endpoint. That’s fine for a weekend project. It is not how a bank, an insurer, or a platform team ships anything, because nobody on your security or audit team signs off on a raw HTTP call sprinkled through fifty services.

So when a Java team is told to “add AI” to a product, the first honest question isn’t “which model?” It’s “how does this pass the same review every other dependency in this codebase already passes?” That’s the question Spring AI answers.

Spring AI 2.0.0, released 2026-06-12, is a Spring project that brings model calls into the patterns enterprise Java teams already trust: dependency injection, auto-configuration, typed objects, swappable beans. It is not a new SDK to learn from zero. It’s your existing way of building Spring Boot services, pointed at a model.

The one-sentence version: Spring AI is not an LLM wrapper — it’s the seam between your enterprise Java code and any model provider, built entirely from Spring patterns (DI, auto-config, typed POJOs) your team already audits.

The problem Spring AI actually solves

Without an abstraction layer, “calling AI from Java” means writing a bespoke HTTP client per provider. OpenAI wants one JSON request shape. Anthropic wants another. Amazon Bedrock wants a third. Each gets its own client, its own auth handling, its own retry logic, its own error handling — scattered across whichever services happen to need a model call.

It works. You can demo it. But it fails enterprise review for a specific, structural reason: a platform or security team can review one pattern used fifty times. They cannot meaningfully review fifty bespoke HTTP integrations, each slightly different, each with its own way of handling a key, a timeout, a failure. There’s no dependency injection to trace, no typed response to validate, no central place to configure. “It works on my machine” is where that review conversation starts, and it’s also where it stalls.

Spring AI collapses that tangle into a single seam:

┌─────────────────────────────┐
│   ▸ YOUR CODE  (unchanged)   │   <- your @Service classes, controllers
├─────────────────────────────┤
│   SPRING AI (the seam)       │   <- ChatClient · auto-config · DI
├─────────────────────────────┤
│   ◆ MODEL PROVIDER           │   <- OpenAI, Anthropic, Bedrock, Vertex, Ollama...
└─────────────────────────────┘

Your code talks to the seam. The seam talks to whichever provider is configured. Swap the provider and the seam — and everything above it — doesn’t change.

What the seam is actually made of

The middle band isn’t hand-waving; it’s three concrete Spring mechanisms, all of which a Spring Boot developer already uses daily:

This is the core reframe: Spring AI doesn’t ask a Java team to learn an “AI framework.” It asks them to point patterns they already have at a new kind of dependency.

Setup note: Spring AI 2.0.0 is built on Spring Boot 4.0 / Spring Framework 7.0 and requires Java 21 to build (Java 17 is only the Spring Boot 4 runtime floor). If your build is still pinned below Java 21, that’s the first thing to fix before any of this compiles.

The whole first program, line by line

Here is a complete, working Spring AI call — the entire “seam” made concrete in code you’d actually commit:

@Autowired
private OpenAiChatModel model;

ChatClient chatClient = ChatClient.create(model);

String answer = chatClient.prompt()
    .user("Why is the sky blue?")
    .call()
    .content();

Read it against what each line actually is, in plain Spring terms:

• @Autowired private OpenAiChatModel model; — dependency injection. OpenAiChatModel is an auto-configured bean, wired by Spring Boot the same way a DataSource gets wired for a JDBC starter. You never construct it yourself.
• ChatClient.create(model) — a static factory on ChatClient that wraps the injected model once, in your service’s constructor or a @Bean method.
• .prompt().user("...").call().content() — a fluent chain: open a prompt, attach the user’s message, send it, read the response back as a String. Same shape as RestClient or WebClient.

There’s nothing AI-specific about the shape of this code. It’s a Spring Boot program where the payload happens to be a model response instead of a database row — which is exactly the point.

Why the provider is a detail, not a rewrite

Because your code only ever talks to ChatClient, the thing behind it is swappable. Spring AI 2.0.0 ships a SpringAIModels class with string constants identifying supported providers, including:

SpringAIModels.OPENAI
SpringAIModels.ANTHROPIC
SpringAIModels.BEDROCK_CONVERSE
SpringAIModels.VERTEX_AI
SpringAIModels.OLLAMA

SpringAIModels lists more providers than these five (Azure OpenAI, Bedrock Cohere, Bedrock Titan, DeepSeek, Mistral, Google Gen AI, and others) — this is a representative, enterprise-relevant subset, not the full list. The point isn’t memorizing constants; it’s that OpenAI today, Anthropic tomorrow, Bedrock or Vertex for a cloud-residency requirement, or Ollama for a model that can’t leave your network, are all the same ChatClient call above the seam. The provider swap happens in configuration, not in a rewrite of your service layer.

Why this actually clears enterprise review

This is the part that makes Spring AI more than developer convenience:

• Testable — because OpenAiChatModel is an injected bean, you can mock it like any other collaborator in a unit test.
• Swappable — because your code depends on ChatClient, not a provider SDK, changing providers is a configuration change.
• Observable — because it’s a normal Spring-managed call, it participates in whatever observability tooling (Micrometer, tracing) your team already runs.

AI lands inside the patterns your security and audit teams already trust, instead of getting bolted on beside them. That’s the difference between something you can demo and something you can actually ship.

How to apply this right now

1. Confirm your build is on Java 21 and Spring Boot 4.0. This is a hard prerequisite for Spring AI 2.0.0 — check it before anything else.
2. Identify one low-risk, internal-facing use case — a summarization endpoint, an internal support tool — rather than starting with a customer-facing feature.
3. Let a chat model bean get auto-configured rather than hand-constructing a provider client; if you find yourself new-ing up an HTTP client for a model call, you’ve stepped outside the pattern.
4. Wrap the model once with ChatClient.create(model) in a service class, not inline in a controller — treat it like you would a RestClient bean.
5. Ask your platform/security reviewers what they’d need to see to review this the way they review any other injected dependency — chances are the answer is “nothing new,” and that’s the sales pitch, not a coincidence.
6. Watch this space for provider portability (Episode 4 in this series) before committing hard to a single vendor in application code.

Common misconceptions

“Spring AI is just a thin wrapper around the OpenAI SDK.” It’s a provider-agnostic abstraction with ChatClient as the single entry point above five-plus providers (SpringAIModels.OPENAI, ANTHROPIC, BEDROCK_CONVERSE, VERTEX_AI, OLLAMA, and more). Code written against ChatClient doesn’t reference OpenAI’s SDK at all.

“You need to learn a new framework to use it.” You need to already know Spring Boot. Everything in the first working example — @Autowired, an auto-configured bean, a fluent chain — is a pattern a Spring developer uses weekly. The unfamiliar part is the payload, not the mechanics.

“This is only useful for chatbots.” The ChatClient fluent chain is the entry point for any model call — summarization, extraction, classification, structured output — not just conversational UIs. This episode shows the minimal call; later episodes in this series build real production patterns on top of it.

“Enterprise AI adoption is mostly a modeling problem.” For most enterprise Java teams, the harder problem is integration and review, not model quality. Spring AI’s actual value is making a model call auditable the same way any other dependency is auditable — DI, auto-config, typed responses — which is an engineering-process win as much as a technical one.

Frequently asked questions

Is Spring AI a Spring Framework module or a separate project? Spring AI is its own Spring project (like Spring Security or Spring Data), versioned independently and built on top of Spring Boot 4.0 / Spring Framework 7.0. The version pinned throughout this series is 2.0.0 GA, released 2026-06-12.

Do I need to know machine learning to use Spring AI? No. The learning objective of this series is explicitly built around Spring Boot fluency, not AI background. ChatClient.create(model).prompt().user(...).call().content() requires understanding dependency injection and a fluent API, not how the underlying model works.

What Java and Spring Boot versions does Spring AI 2.0.0 require? Spring AI 2.0.0 requires Spring Boot 4.0 / Spring Framework 7.0, and needs Java 21 to build — Java 17 is only the Spring Boot 4 runtime floor, not the build requirement. Confirm this before adding the dependency to an existing project.

Which model providers does Spring AI support? SpringAIModels lists constants for OpenAI, Anthropic, Amazon Bedrock (via BEDROCK_CONVERSE), Google Vertex AI, Ollama (self-hosted), Azure OpenAI, and several others (Bedrock Cohere, Bedrock Titan, DeepSeek, Mistral, Google Gen AI, and more). This episode covers a representative enterprise-relevant subset; provider-swap mechanics get a full episode later in the series.

Is ChatClient.create(model) the only way to build a ChatClient? It’s the static factory shown in this episode’s minimal example. ChatClient also exposes a builder path used for more advanced configuration (default advisors, default tools) — that’s covered once this series introduces those concepts, not in this first episode.

Why does the code use OpenAiChatModel specifically instead of a generic type? This episode autowires the provider-specific bean (OpenAiChatModel) that Spring Boot auto-configures when the OpenAI starter is on the classpath, to keep the very first example concrete. The starter coordinate and configuration properties that make that auto-configuration happen are covered in the next episode.

Where this fits in the series

This is Episode 1 of Spring AI for Enterprise Java. It establishes the core mental model — Spring AI as the seam between your code and a model provider — that every later episode builds on.

Next up: Why Spring Boot Teams Already Know 80% of This, which walks through exactly which Spring skills you already have transfer directly to Spring AI.

Runnable code for this episode lives in the spring-ai-enterprise-examples repository, 01-what-is-spring-ai module.

If you want the video version of this walkthrough as soon as it’s live, subscribe to @TheStackUnderflow on YouTube — full architecture diagrams and code walkthroughs for the rest of this series post there first.