AI Platform and Security · Module 2 · Data, Models and DevSecMLOps

Integrating AI into the Enterprise Landscape

The lesson closes Part II at the place where AI output reaches a case file, an order or a citizen. Participants learn the gateway functions as integration seam, when to integrate synchronously and when by event, three principles for legacy systems of record, delegated authority with explicit identity propagation, contracts for probabilistic services, caching and idempotency, and the interoperability duties of public bodies under the Interoperable Europe Act.

Lesson 12 of 25Chapter 1275 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Platform and Security / Module 2 / Chapter 12

Learning objectives

After the lesson the participant can:

Key concepts

Integration seam
The AI gateway as the single seam through which every AI call passes, performing the functions no team should implement twice: authentication and delegated authority, policy enforcement, routing, quotas and budgets, guardrails, logging and tracing, caching and idempotency.
Proposal, not write
AI never writes directly to a system of record. It writes a proposal to an intermediate store or publishes an event, and a deterministic component or a person commits the change, which makes a confident wrong answer recoverable.
Delegated authority
The gateway exchanges the person's token for a short-lived token bound to the AI service's identity, with the person preserved as an act claim. The system of record, not the model, makes the authorisation decision.
Contract for a probabilistic service
An API contract that expresses how confident the service is, where the answer came from, what happens when it cannot answer and which model produced it. Refusal and fallback are first-class outcomes consumers must handle.
Idempotency
A retried request produces no second effect. The gateway stores an idempotency key per request, returns the stored outcome on retry and never re-executes a completed tool call.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Sort

Call or event?

Sort each integration need under the style of integration the chapter recommends for it.

Interactive exercise 2 · Match

Fields of a contract for a probabilistic service

Match each part of the summary service's response schema with what the chapter says it is for.

Teaching plan

10 minThe teacher names the two broken assumptions: the same request may give a different answer, and the most dangerous failure is a fluent, wrong response that passes every schema check.
20 minRead Hansa Mutual's gateway route as a list of the gateway functions, then compare synchronous and event-driven integration using the claim triage events.
15 minDecode the delegated token of Nordvik Region's staff assistant claim by claim, then cover the response contract, caching and idempotency.
25 minExercise: participants design the integration of one AI service with a system of record and write its response contract; pairs test whether the consumer degrades safely without the AI service.
5 minClose with connectors in Modes 2 and 3 as integration decisions and the interoperability duties of public bodies.

Discussion

  1. Collapsing the service identity and the acting person into one is called the most common identity mistake. What does your system of record see today when an AI service calls it?
  2. Semantic caching is disabled on Hansa Mutual's claims route. For which content in your organisation would a similar enough answer be acceptable, and for which never?
  3. What would each consumer of your AI services do if the service were removed entirely, and has anyone tested it?

Written exercise

Exercise · 25 minutes

Design an integration with a system of record

Choose an AI service in your organisation whose output should reach a system of record, or use a triage suggestion in Hansa Mutual's claims system. Decide whether the integration is synchronous, event-driven or both, and give the reason. Describe the path from proposal to commit and who or what commits. List the claims of the delegated token: service identity, acting person, scope, purpose and lifetime. Then write the response contract as a field list: status values including refused and fallback, a calibrated confidence, provenance, model and prompt versions, and disclosure. Finally state the cache key and whether semantic caching is allowed, with the reason.

Deliverable: A one-page integration design with the commit path, the token claims, the response contract fields and the caching decision.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. Which of the following is one of the three principles for integrating AI with legacy systems of record?

    Show the answer

    C. AI never writes directly to a system of record; a deterministic component or a person commits its proposal
    The other two principles are an adapter with its own contract and treating the legacy data as a data product with a contract.

  2. In the delegated token of Nordvik Region's staff assistant, what do the sub claim and the act claim identify?

    Show the answer

    A. The service identity of the assistant and the officer on whose behalf it acts
    Both identities reach the adapter, which checks them separately before returning a document, and the audit log records both.

  3. When is a model change behind an unchanged API contract a major version, according to the chapter?

    Show the answer

    B. When the evaluation suite does not pass, as decided by the consumer's contract tests
    A model change is a minor version if the evaluation suite passes and a major version if it does not; the consumer's contract tests, not the provider's assurances, decide.