Enterprise Integration Patterns for AI

Executive Summary

AI systems do not exist in isolation: every AI feature that adds value to an enterprise reads from and writes to existing systems — EHRs, data warehouses, message queues, identity providers, and business applications. The integration architecture between the AI layer and these systems is frequently the highest-risk, longest-lead component of an enterprise AI project, and the pattern chosen (synchronous, asynchronous, or batch) has direct consequences for system reliability, latency, and the complexity of failure handling. This chapter establishes the foundational integration patterns that all subsequent chapters in this section build upon.

Learning Objectives

  • Classify AI integration requirements as synchronous, asynchronous, or batch and justify the selection
  • Identify the failure modes specific to each integration pattern
  • Design an integration architecture that isolates AI system failures from upstream source systems
  • Apply the integration patterns to the Hospital Management System (HMS) scenario

Business Problem

A Reference Healthcare Organization deploying clinical decision support AI faces an integration challenge that is orthogonal to the AI capability itself: how does the AI system receive patient context from the EHR in time for a clinician's decision? How does it return recommendations without blocking the EHR workflow? How does it recover when the AI inference service is unavailable during a critical clinical encounter?

Answering these questions requires choosing and implementing the right integration pattern before any AI model is selected, because the pattern determines end-to-end latency, failure isolation, and operational complexity.

Core Architecture

Enterprise Considerations

Failure isolation: The AI layer must never take down the source system. Always implement circuit breakers on synchronous AI calls, and design async consumers so that queue depth growth does not cause backpressure on the source system.

Idempotency in async patterns: Messages may be delivered more than once in at-least-once delivery queues. AI workers must be idempotent: processing the same job_id twice should produce the same result and not duplicate the output (e.g., writing two discharge summaries to the EHR).

Dead letter queues: Async pipelines must route failed jobs to a dead letter queue (DLQ) after exhausting retries. Without a DLQ, failed jobs are silently dropped. The DLQ must be monitored and produce alerts when messages accumulate.

Common Mistakes

1. Using synchronous calls for long-running AI operations. A 30-second AI response on a synchronous call holds an HTTP connection and a thread for the entire duration. Under load, this exhausts connection pools and cascades failures to the calling system.

2. Not implementing fallback for synchronous AI calls. If the AI service is unavailable and the calling system has no fallback, the calling system fails too. For clinical systems, the fallback must be defined before the feature is deployed.

3. No idempotency in async workers. A Kafka consumer that processes the same message twice writes two AI-generated documents to the EHR. Every async AI worker must check whether a job_id has already been processed before executing.

Key Takeaways

  • The integration pattern (synchronous, asynchronous, batch) must be selected before the AI model, because it determines end-to-end architecture
  • Synchronous AI integration requires explicit timeout and fallback behavior; the AI system must never take down the calling system
  • Asynchronous AI integration requires idempotent workers and dead letter queues
  • Batch AI integration requires checkpointing for resumability on large datasets
  • PHI handling requirements apply to all three patterns: encryption in transit, audit logging, least-privilege access

Further Reading