Solution · Private AI

Private AI for WordPress

A privacy-conscious AI architecture for WordPress editing, media metadata, frontend AI, DocSearch and chatbot experiences.

Short answer: Private AI for WordPress means adding AI capabilities to the WordPress editing and visitor experience without making a shared SaaS runtime the default center of the architecture. AI-Kit starts with local browser AI where supported, and can connect to a customer-configured AWS backend for stronger workflows such as chatbot, DocSearch and knowledge-base search.

Explore AI-Kit

Read AI-Kit docs

Why this matters

The common SaaS AI wrapper model is convenient, but it often pushes editorial content, prompts, API keys and cost controls into a vendor-controlled runtime. That may be acceptable for simple drafting, but it is not always acceptable for agencies, regulated clients, internal documentation or customer-specific governance rules.

WordPress AI also needs to fit the actual places where work happens: Gutenberg, the Media Library, image blocks, frontend content interactions and documentation search. Copying text between ChatGPT and WordPress is not a workflow architecture.

AI-Kit uses a layered model: local-first where supported, optional backend fallback when local AI is unavailable or insufficient, and customer-configured AWS backend patterns for Bedrock, RAG, DocSearch, chatbot and advanced AI workflows.

Architecture and data flow

WordPress / Gutenberg / Media Library
        ↓
AI-Kit editor and frontend surfaces
        ↓
Local browser AI where supported
        or
Configured API endpoint
        ↓
Customer-configured AWS backend
        ↓
Bedrock / knowledge base / retrieval / business logic

Capability map

Local-first editor AI

Use browser/on-device AI where supported for Gutenberg writing workflows, including generation, rewrite, proofread, translate and summarization patterns without making a shared SaaS API the default path.

Diagnostics and runtime detection

AI-Kit checks which browser AI capabilities are available, explains missing requirements, and can surface status events such as local run, model download, backend request or done.

Gutenberg Sidebar tools

Generate post SEO metadata, excerpts and draft text by topic, instruction, tone, length and language, then review and apply inside the editor instead of copying content between tools.

Inline and Media Library tools

Proofread, rewrite or translate editable text; generate alt text, title, caption and description for image-like blocks and Media Library items, including bulk preview/accept/save workflows.

Frontend AI Feature block and shortcode

Expose summarize, write, rewrite, translate and proofread actions to visitors using a Gutenberg block, shortcode or custom JavaScript UI where visitor-facing AI is useful.

Backend modes

Run local-only, backend fallback or backend-only execution depending on browser support, governance, reliability and model requirements; the backend can be deployed into a customer-owned AWS account.

Knowledge Base source admin

Enable WordPress posts and pages as KB sources, generate base documents, override sections where needed, preserve source links and prepare content for search and answer workflows.

RAG, DocSearch and chatbot publishing

Convert content to clean Markdown, attach category/subcategory/tag metadata, split documents into better chunks, publish them to the AI-Kit backend and let backend ingest update the knowledge base.

Knowledge-base and RAG publishing pipeline

For DocSearch, chatbot and RAG-style answers, the important work is not only connecting a model. The content must be prepared, categorized and published in a form the backend can retrieve reliably. AI-Kit can treat WordPress posts and pages as knowledge-base sources, generate markdown-oriented documents, allow manual overrides, and publish the prepared documents to the backend where ingestion can start automatically.

WordPress posts / pages / docs
        ↓
AI-Kit KB source selection
        ↓
Markdown conversion + section override
        ↓
Category / subcategory / tags / source URL
        ↓
Chunk preparation for KB / RAG quality
        ↓
Publish to AI-Kit backend
        ↓
Backend ingest → knowledge base → DocSearch / chatbot

Guided AI-Kit backend deployment

The AI-Kit backend should not feel like a raw CloudFormation exercise. A small deployment wizard can collect the few important choices, generate a prefilled CloudFormation Create stack review URL, and let the customer deploy the backend in their own AWS account. After deployment, the API base URL from stack outputs is copied into WordPress under AI-Kit API settings.

AI-Kit deployment wizard
        ↓
Important decisions only: auth mode, frontend features, protections
        ↓
Prefilled CloudFormation Create stack review URL
        ↓
Customer clicks Create stack in AWS
        ↓
CloudFormation outputs ApiBaseUrl
        ↓
WordPress → SmartCloud → AI-Kit Settings → API Settings

Decision table

Mode / dimension	Best for	Data path / approach	Trade-off
Local-only	Editor and media tasks where browser AI is available	Browser / on-device	Browser support varies and some features may be unavailable
Backend fallback	Reliable UX when local AI is unavailable	Browser → configured API → backend	Requires backend configuration and operational ownership
Backend-only	Predictable AI behavior and stronger models	Browser/editor → customer backend	More setup, more control
RAG / DocSearch	Grounded answers from site docs or KB	KB source → backend retrieval → cited answer	Requires content preparation and indexing

How this differs from the usual approach

Manual ChatGPT copy-paste

Good for occasional drafting, but weak for repeatable editorial metadata, governance and in-editor workflows.

Generic SaaS AI plugin

Convenient when vendor runtime is acceptable, but may centralize prompts, content routing and cost model outside the client architecture.

Self-hosted/local model approach

Maximum control in theory, but can require significant model hosting, device and UX work.

AI-Kit local-first + optional AWS backend

Designed for WordPress-native workflows with local browser AI where supported and customer-configured backend patterns when stronger capabilities are needed.

When this is a good fit

Editorial teams that want AI inside Gutenberg instead of a separate copy/paste workflow.
Teams that care about privacy, data routing and client-specific governance.
Agencies standardizing WordPress + AWS patterns across clients.
Sites that need image alt text and SEO metadata generation.
Documentation-heavy sites that need DocSearch, RAG or a WordPress AI chatbot.
Static WordPress projects that still need AI interactions via browser-side components and configured APIs.

When not to use this

A team that only needs occasional manual drafting and is happy to use ChatGPT directly.
A project where a simple SaaS AI plugin is acceptable and privacy/ownership is not a concern.
A site where no supported browser AI is available and no backend will be configured.
A project that does not need WordPress-native AI workflows at all.

Implementation path

Use a phased implementation path so the page can honestly explain both the low-friction editor experience and the stronger backend-powered workflows.

Install AI-Kit and enable the editor, inline language and Media Library workflows that match the editorial process.
Define brand voice, content rules, metadata conventions and supported output languages before generating larger volumes of content.
Use AI-Kit Diagnostics to verify local browser AI availability, Chrome version requirements and fallback behavior.
Choose local-only, backend fallback or backend-only mode for each workflow: editor tools, frontend AI, chatbot and DocSearch do not need the same runtime policy.
For backend features, use the deployment wizard to generate the prefilled CloudFormation Create stack URL and deploy the AI-Kit backend in the target AWS account.
Copy the backend API output, such as ApiBaseUrl, back into WordPress AI-Kit API Settings and test a backend-backed feature.
For KB/RAG, enable WordPress posts or pages as KB sources, generate markdown documents, override weak sections, assign categories/tags and publish to the backend.
Add frontend AI blocks, chatbot and DocSearch only where they improve visitor workflow; avoid decorative AI widgets that do not help the page.

AI-Kit

product page for editor AI, Media Library metadata, frontend AI features, DocSearch and chatbot

WordPress RAG Chatbot on AWS

companion solution for grounded knowledge-base answers

AI-Kit vs SaaS AI WordPress plugins

decision support for AI architecture choices

WordPress + AWS Reference Architecture

technical reference for the broader platform

Docs

implementation and API reference

AI Agents

machine-readable and agent-facing WP Suite resource entry point

WordPress for Agencies on AWS

agency and client-owned infrastructure angle

FAQ

What does private AI mean in WordPress?

Private AI for WordPress means designing AI workflows around controlled data routing and ownership. In AI-Kit, that can mean local browser AI where supported, plus optional customer-configured AWS backend patterns for stronger features such as DocSearch, chatbot and knowledge-base answers.

Does AI-Kit send content to a vendor by default?

The local-first mode is designed to use browser/on-device AI when available, so supported workflows can stay in the browser. Backend features require configured endpoints and should be reviewed against your architecture.

Does everything run locally?

No. Private AI does not mean every model always runs locally. Some workflows can use local browser AI; stronger or visitor-facing workflows may use a configured backend.

What happens if browser/on-device AI is unavailable?

AI-Kit can be configured for local-only, backend-fallback or backend-only behavior depending on the feature and the project requirements.

Can AI-Kit use my own AWS account?

The intended Pro backend pattern can be customer-configured or customer-owned, commonly using AWS services such as Bedrock and backend APIs.

Can it work on static WordPress sites?

Yes, where browser-side features and configured endpoints remain reachable after static export. WordPress/PHP does not need to proxy every request.

Can visitors use AI features on the frontend?

Yes. Pro frontend surfaces include AI Feature blocks/shortcodes and chatbot or DocSearch experiences when backend requirements are met.

Can it generate image alt text and SEO metadata?

Yes. AI-Kit supports alt text, title, caption and description workflows in Gutenberg image-like blocks and the Media Library.

Can it power a documentation chatbot?

Yes, through backend-powered chatbot and DocSearch patterns that can use prepared knowledge-base sources.

Is this the same as a ChatGPT plugin?

No. AI-Kit is a WordPress-native feature layer with local-first and optional backend modes, not just a wrapper around a single shared AI chat service.

Is this suitable for agencies?

Yes, especially when agencies need repeatable AI workflows but different clients require different data-handling and infrastructure ownership policies.

When should I not use AI-Kit?

Do not use it if manual drafting is enough, if privacy/ownership does not matter, or if neither local browser AI nor a backend will be available for the required workflows.

Add private AI workflows to WordPress

Add privacy-conscious AI to WordPress with AI-Kit: local-first browser AI, optional AWS backend, Gutenberg tools, Media Library metadata and frontend AI features.