AEM + RAG Services on Kubernetes.

Structured AEM content offers fields and provenance that can help build retrievable passages. This proposed PoC studies whether that structure supports useful, source-backed answers; it does not assume an LLM will preserve the source's meaning or access restrictions.

A technically healthy RAG service can retrieve stale content, omit the relevant passage or disclose information the caller cannot access. Those are application and governance failures that Pod health checks cannot detect.

An ingestion workload fetches approved content through GraphQL or APIs, transforms it into versioned passages and updates a retrieval index. Interactive services authenticate callers, retrieve permitted evidence, build a bounded prompt and call an external LLM endpoint before returning an answer with source references.

Attach source URL, content identifier, revision and access metadata to passages. Enforce authorization before content reaches the model, propagate deletions and permission changes, and treat retrieved text as untrusted data rather than executable instructions.

• Use stable identifiers and resumable ingestion so retries do not duplicate passages.
• Separate service identities and network access for ingestion, retrieval and model calls.
• Version chunking, embedding inputs, prompt templates and model configuration for reproducible evaluation.

Run a fixed question set against the candidate retrieval and prompt configuration, then inspect citations, abstentions and permission failures. Deploy compatible service and index revisions together, with a rollback plan that accounts for their shared data contract.

Batch ingestion and interactive requests have different latency and concurrency needs. Bound model-call budgets and retries, record retrieval timing and source revisions, and avoid storing sensitive prompts or answers in general-purpose logs.

A service boundary permits independent scaling and releases but introduces more failure points and operational cost. Before choosing Kubernetes, compare a simpler managed execution model; a small PoC may not justify a cluster operating model.

Continue with the complementary design in Headless AEM: GraphQL and Sling Model Exporter Delivery Boundaries.

The PoC's output should be an evaluation record and a decision about suitability, not a claim that deployment establishes trustworthy AI. Production adoption would require explicit security, content and operational acceptance.

• Ask the same question as differently authorized users and inspect retrieved passages as well as final answers.
• Delete or restrict an AEM fragment and verify it no longer reaches prompts after the defined propagation window.
• Test unsupported questions, conflicting sources and injected instructions inside retrieved content.
• Simulate LLM timeouts, ingestion interruption and incompatible index revisions; verify bounded failure and recovery.

Orchestration supports repeatability, but the decisive artifact is the evaluation evidence. A credible AI architecture makes permission handling, provenance and failure behavior as reviewable as its deployment manifests.

These sources document product behavior. The design and validation approach above are engineering proposals, not claims made by the vendors.

• Kubernetes: multi-tenancy and isolation
• Kubernetes: Secrets
• Kubernetes: Deployments