The Model Is Not the Product: Integrating AI Without the Magic
The first version usually fits on one screen.
Receive a message. Send it to a model. Return the text.
It works in the demo. Then a customer pastes someone else’s name, address, and order history into the box. The model finds a private support note. A week later you give it a refund tool, and it tries to use that too.
Same endpoint. Very different system.
The call to the model was never the hard part. The hard part is deciding what may cross into it, what may come back out, which keys it gets, and who is responsible when the result touches a real person.
Picture the model on the other side of a service hatch. Your application controls the hatch. It checks what goes through, fetches only the records the customer may see, inspects what comes back, and keeps the keys to everything that can change the real world. The model can ask. It doesn’t get to open the door itself.
That boundary is the product.
The API call is the smallest part
In the first article, I opened the engine and showed the token loop underneath the assistant. The second put context, tools, and retrieval on the desk. The last one turned that into a work loop: Brief, Inspect, Ground, Act, Verify, Sign off.
Putting the model inside an application makes that loop run for every user, whether anyone is watching or not.
The application now supplies the brief. It chooses the evidence, exposes tools, checks the result, and decides which actions need sign-off. It also does the ordinary product work model demos skip: authentication, tenant isolation, rate limits, deletion, incident response, and a way back to a human.
A better model can improve the answer in the middle. It can’t decide that Alice may read Bob’s support ticket. It can’t create a lawful reason to send customer data to a third party. It can’t turn a model-generated refund request into an authorised refund.
Those decisions belong on your side of the hatch.
This distinction matters under EU law too. The AI Act regulates models, systems, operators, and particular intended uses, not an API call viewed in isolation. The GDPR applies to every operation in the path that processes personal data. Buying access to a well-documented model helps, but it doesn’t inherit the rest of the application for you.
The model sits across a boundary
A useful integration has gates on both sides.
The input gate knows the signed-in user, the tenant, the declared purpose, the fields that are allowed, and the records that person may retrieve. It strips what the job doesn’t need before anything leaves your system.
The output gate treats the answer as untrusted input. It checks the expected shape, citations, tool arguments, policy limits, and whether a person must approve the next step. A fluent sentence doesn’t get a security bypass because it came from an expensive model.
Tools sit on a side branch. The model may request draft_refund, for example. The application still checks who is signed in, whether that order belongs to the tenant, whether the amount is inside policy, and whether the user approved the exact action. Only then does ordinary code call the payment system.
The final layer runs across the path: versions, evaluations, audit events, monitoring, and a stop switch. If a model update changes behaviour, you need to know which version answered, which sources it saw, and which policy was active. “The AI did it” isn’t a useful incident report.
Change the switches below. The model in the middle stays the same. The work around it doesn’t.
Change what the application is allowed to do
Start with a customer support assistant. Each switch changes the boundary around the same model, not the model itself.
3 characteristics selected. 12 controls are visible.
Supplies the general-purpose model and its downstream documentation.
Defines the feature, purpose, context, tools, interface, and safeguards.
Uses the finished AI system under its authority. Exact roles still need checking.
Legal duty · 5
Map the supplier chain
Record who supplies the GPAI model, who provides the downstream system, and who operates it.
Train the people operating it
Staff need enough AI literacy for the system, its risks, and the people affected by its use.
Disclose the AI interaction
Tell people they are interacting with AI at the first interaction unless that fact is already obvious.
Define the GDPR data path
Set a purpose and legal basis, minimise fields, disclose recipients, limit retention, and support data rights.
Check processor and transfer terms
Verify the DPA, sub-processors, storage region, training use, deletion terms, and any third-country transfer mechanism.
Assessment required · 2
Write down the intended purpose
Name the job, users, affected people, data, outputs, and forbidden uses before choosing a model.
Screen for a DPIA
Personal data does not make every feature high-risk, but likely high risk to people requires a DPIA before processing starts.
Engineering control · 5
Version, test, and monitor the system
Keep model, prompt, policy, and evaluation versions together so a changed result can be traced.
Treat model output as untrusted
Validate structure, citations, permissions, and allowed actions before anything reaches a user or tool.
Retrieve through the user’s permissions
Filter by tenant and user before retrieval. The model must never decide which private records the user may see.
Carry deletion into indexes and caches
Access, correction, and deletion workflows must reach copied chunks, embeddings, traces, and caches too.
Keep useful receipts, not a shadow database
Log versions, source IDs, approvals, and outcomes while avoiding unnecessary raw personal data in audit events.
Illustrative engineering orientation, not a legal classification. EU rules checked 15 July 2026. The demo is hand-authored and makes no network calls.
The support assistant starts with personal data and private retrieval, but no action tools. Turn tools on and the application needs a permission and approval path. Turn significant decisions on and the demo stops showing a comfortable end state. That is deliberate. A toggle can’t classify a real use under the AI Act or the GDPR, and neither can a generic checklist.
Scope note, checked 21 July 2026: this is an engineering guide for a SaaS or web application whose processing falls within the GDPR’s territorial scope and whose use falls within the AI Act’s scope, integrating a third-party general-purpose AI model. It’s not legal advice. Training models, medical devices, critical infrastructure, law enforcement, biometric systems, education admissions, employment screening, credit, and insurance need their own legal and sector review.
Start with the job, not the model
The first design document should describe the job without mentioning a model name.
“Answer support questions from records this customer may access, draft a response, and hand uncertain or policy-sensitive cases to an agent” is a usable intended purpose. “Add AI to support” isn’t. The first version gives you people, data, limits, and an outcome you can test. The second gives you a logo for the navigation bar.
Write down at least these five things:
- Who will use the feature, and who may be affected by it?
- Which sources may it read?
- What may it produce or recommend?
- Which actions may it request?
- Which uses are outside the product, even if the model can technically do them?
That last line is easy to miss. A narrow support summariser will often sit outside the AI Act’s high-risk categories, though its GDPR risk still depends on the data, scale, and effects. Letting the same endpoint rank job applicants is a new intended purpose, not a small configuration change.
The AI Act follows that use. Article 5 bans specific practices, including defined harmful manipulation and social scoring, untargeted scraping to build facial-recognition databases, and emotion recognition in workplaces or schools except for medical or safety reasons. Don’t build a mitigation plan for a prohibited use. Stop.
Article 6 and Annex III cover high-risk systems. The list includes certain uses in biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice, and democratic processes. An Annex III system can fall outside high-risk classification only if it poses no significant risk of harm, including by not materially influencing decision-making, and meets at least one of Article 6(3)’s four conditions. Profiling natural persons keeps it high-risk. That is a legal assessment to document, not a label to infer from the model’s confidence score.
For the support assistant here, the ordinary starting position is different: define a narrow service job, prevent it drifting into eligibility or employment decisions, and review again whenever the purpose, tools, affected people, or sales claims change.
The hatch needs a sign telling everyone what it’s for.
Whose system is it?
Model vendors and application teams don’t provide the same thing.
Under the AI Act’s Article 3 definitions, a provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority, outside personal non-professional use.
That creates a supply chain:
| Layer | Typical actor | What it controls |
|---|---|---|
| General-purpose model | Model vendor | Model capabilities, limitations, and model documentation |
| Downstream AI system | Application provider | Intended purpose, context, interface, tools, checks, and user experience |
| Operation | Deploying organisation | Actual use, staff, monitoring, and human oversight |
The exact role can change with the arrangement. An organisation can also hold more than one role. The useful point isn’t to memorise a title; it’s to stop treating the model vendor as the owner of choices the application team made.
If you develop the support system around the model and place it on the market or put it into service under your name, you’re normally the provider of that downstream system. The vendor’s safety paperwork doesn’t describe your refund rules, tenant filters, interface, or users.
The upstream documentation still matters. Since 2 August 2025, providers placing general-purpose AI models on the Union market have generally had duties that include supplying downstream providers with information needed to understand capabilities and limitations. Models already on the market before that date have until 2 August 2027, and qualifying free and open-source models have limited documentation exemptions. The Commission’s GPAI guidance describes that hand-off. Ask for the documentation that applies. Keep it with your own system record. Check it again when the model changes.
Then document your half: intended purpose, known limitations, evaluation set, permitted data, tool contracts, human controls, and the conditions that should disable the feature.
The vendor built what is behind the hatch. You built the hatch.
The dates that actually matter
The AI Act did not switch on in one go. As of 21 July 2026, the original Act remained the published law while a signed amendment awaited publication in the Official Journal. The Commission’s application timeline uses these dates:
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibited practices and AI-literacy duties |
| 2 August 2025 | Governance rules and obligations for GPAI model providers |
| 2 August 2026 | Most remaining provisions, including the general transparency rules |
| 2 December 2027 | Under the signed amendment, rules for systems classified under Article 6(2) and Annex III |
| 2 August 2028 | Under the signed amendment, rules for systems classified under Article 6(1) and Annex I product legislation |
The later high-risk dates come from the Digital Omnibus on AI. Parliament approved the agreed text on 16 June 2026, the Council adopted it on 29 June, and it was signed on 8 July. As of 21 July it still awaited Official Journal publication, after which it will enter into force on the third day.
None of that postpones the GDPR. As of 21 July, Article 4 still required providers and deployers, to their best extent, to take measures to ensure sufficient AI literacy among relevant staff and others operating AI systems on their behalf. The signed amendment will soften that wording to supporting the development of AI literacy without guaranteeing a particular individual level.
Training here should match the job. A support agent needs to know what the feature can see, how to spot an unsupported answer, when to take over, how to report a bad result, and which data never belongs in the box. A developer needs the threat model and evaluation process. The person approving a refund needs authority to say no.
A thirty-minute slide deck called “AI awareness” isn’t the same thing.
What may cross the boundary?
The GDPR question starts before the request leaves your server.
Customer messages, account records, support history, names, email addresses, device identifiers, and sometimes the generated answer itself can be personal data. The fact that the vendor promises not to train on API traffic doesn’t make the processing disappear. The data still moved, was analysed, and may have been logged.
The European Commission’s summary of the GDPR principles gives the useful baseline: lawfulness, fairness, transparency, specified purposes, data minimisation, accuracy, storage limits, appropriate security, and accountability. Apply those principles to the path, not just the database where the data started.
For each field that could cross the hatch, answer four questions:
- Why does this job need it?
- What legal basis covers that purpose?
- Who receives or stores it, and where?
- How will applicable access, rectification, objection, restriction, and erasure requests be handled across the controller, processors, and relevant recipients?
Consent isn’t a universal AI switch. Identify an Article 6 basis for each purpose and make sure its conditions are met. Contractual necessity is narrow. A legal obligation must come from applicable law. Legitimate interests requires necessity and a case-specific balance of reasonable expectations, impacts, and safeguards. If the path processes special-category data, it also needs an Article 9(2) condition. The EDPB’s opinion on AI models makes that case-by-case approach explicit.
Minimisation is where architecture earns its keep. If the user asks about one order, retrieve that order after checking tenant and user access. Don’t put the whole CRM export on the desk. Strip email signatures when they add nothing. Replace an address with a stable internal reference if the model only needs to know that delivery failed; that reduces exposure but will usually remain pseudonymised personal data. Keep provider logs and application traces no longer than their documented purpose requires.
RAG doesn’t bypass authorisation. Every chunk must inherit the source’s current access rules, tenant, and classification, and retrieval must enforce them before results reach the model. If access rules are left inside the prompt, a prompt injection gets to negotiate with them. An authorised document can still contain hostile instructions, so retrieved text remains untrusted. That is the same desk from the context article, now with a guard at the drawer.
When an erasure request is valid, locate the personal data in chunks, embeddings, caches, traces, and support exports, subject to Article 17’s exceptions and the applicable backup and recipient procedures. An embedding isn’t automatically anonymous just because the source record has gone.
Finally, determine the real controller and processor roles from what each party decides and does. If the vendor is a processor, put the Article 28 terms in place and review its sub-processors, instructions, security, assistance, deletion or return, audit support, and breach notification. Also review retention, training use, access locations, and onward disclosures. For transfers outside the EEA, identify an adequacy decision or another valid mechanism such as Standard Contractual Clauses, then assess whether the destination and safeguards provide effective protection. The Commission’s international-transfer guidance explains the available routes.
“EU region” is one answer in that review. It’s not the whole review.
Which keys does the model get?
Text generation has no side effect until another component interprets or acts on it. Tools make that path explicit.
A support model that can read one ticket can leak one ticket. A support agent with a broad CRM token, email access, and a generic run_request function can change records or contact people. The blast radius comes from the keys around the model, not from how many parameters it has.
The OWASP Top 10 for LLM Applications 2025 covers prompt injection, sensitive-information disclosure, improper output handling, excessive agency, and vector and embedding weaknesses. A system prompt saying “never reveal secrets” is useful guidance. It’s not an authorisation check.
Give the model narrow requests it can make:
find_order(order_id)instead of unrestricted database search;draft_refund(order_id, amount, reason)instead of a general payment API;prepare_reply(ticket_id, body)instead of direct access to the mail account.
Then enforce the real rules in ordinary code. Authorise the authenticated person for this operation on this exact object on every call. Validate every argument against a schema and policy. Use service credentials with only the required scope. Put amount and frequency limits outside the model.
For consequential work, split preparation from execution. The model drafts the refund. The interface shows the order, amount, reason, and destination to an authorised person. That person approves the exact action. Bind that short-lived, single-use approval to the person, tool, target, and normalised parameters. The server authorises it again and executes it once, with an idempotency key.
This isn’t a lack of trust in one particular model. It’s how you operate any component that consumes untrusted input and can ask for privileged work.
The model can slide a request through the hatch and ask the broker to use delegated authority.
It never receives the key itself.
What comes back is untrusted
The response can be wrong without looking broken.
That was the whole problem in the working-with-LLMs article: plausible isn’t verified. Inside a product, the answer also has to pass mechanical checks before anyone considers whether the prose sounds good.
If the UI expects JSON, validate it against a closed schema. Reject fields you did not ask for. If the answer contains citations, confirm mechanically that each source ID and version came from the authorised retrieval set. Whether the passage supports the claim still needs a domain-specific check or a competent person for consequential answers. Render ordinary output as escaped text. If you intentionally support HTML or Markdown, use a maintained allowlist sanitizer and validate links. If it requests a tool, treat every argument as hostile until server policy accepts it.
Then choose a check that can see the failure.
A grounded support answer can quote the right policy and still apply it to the wrong customer. A schema check can confirm that amount is a number while missing that the amount exceeds the order total. A human can click approve without noticing anything if the interface hides the source and consequence.
Human oversight has to be real. The reviewer needs enough context, time, competence, and authority to change the result. A rubber stamp at the end of an opaque flow isn’t a safety control.
This becomes an Article 22 issue when personal data is used for a decision based solely on automated processing and that decision produces legal or similarly significant effects. A nominal human step doesn’t avoid that boundary if the person doesn’t genuinely assess and influence the result. The GDPR generally restricts those solely automated decisions, subject to defined exceptions and safeguards. Employment, credit, access to essential services, and other listed uses may separately trigger the AI Act high-risk track.
Don’t try to solve that with one more confirmation dialog. Stop, classify the use, involve legal and data-protection owners, and design the decision process itself.
What must the user know?
Put the AI notice at the hatch, not six clicks deep in a privacy policy. Make the separate GDPR information easy to reach there too.
From 2 August 2026, Article 50 of the AI Act requires providers of systems intended to interact directly with people to design them so the person is informed by the first interaction that they are interacting with AI, unless that is obvious to a reasonably well-informed, observant, and circumspect person in context. For a support assistant, a plain label at the first interaction is cheap and honest.
That notice is separate from the privacy notice. “AI assistant” tells the person what they are talking to. The GDPR information must identify the controller and explain the purposes and legal bases, relevant legitimate interests, recipients or recipient categories, retention period or criteria, applicable rights and complaint route, plus the other items required by Article 13 or 14. If a third-country transfer is intended, explain the adequacy decision or safeguards.
Article 50 also contains different rules for generated content. Providers of systems that generate or manipulate synthetic audio, image, video, or text must make outputs machine-readable and detectable as artificial where technically feasible given the content, implementation costs, and state of the art. Exceptions cover specified standard editing, changes that don’t substantially alter the input or its meaning, and certain law-enforcement uses. Deployers publishing generated text to inform the public on matters of public interest must disclose its artificial origin unless the text has undergone human review or editorial control and a person or organisation holds editorial responsibility.
Those aren’t one universal “AI-generated” badge. A chatbot interaction, a machine-readable content mark, a deepfake disclosure, and a public-interest publication each have their own condition. Use the one that matches the product instead of covering every screen in the same sticker.
As a product and risk control, give the user a way out. A support assistant needs a human hand-off when it can’t answer, the customer disputes a consequential result, or the request falls outside the declared purpose. Article 50 doesn’t require this for every chatbot, but transparency without recourse is just a warning label on a locked door.
Keep the receipts
When something goes wrong, you need more than the final paragraph.
A useful audit event may record system, model, and policy versions; source IDs; user and tenant references; tool and permission decisions; approval; validation; and outcome where those fields are necessary for accountability, security, or applicable AI Act logging duties. It doesn’t need every raw prompt, retrieved document, and answer forever.
Logs are another data store. Give them a purpose, access policy, retention period, deletion path, and security controls. Redact or tokenise personal fields where the investigation doesn’t need the original value, but remember that re-linkable tokens remain personal data. Separate product analytics from incident evidence instead of keeping everything because storage is cheap.
Before launch, screen the processing for a Data Protection Impact Assessment. A DPIA isn’t required merely because the word AI appears in the architecture. It is required where processing is likely to create a high risk to people’s rights and freedoms. Article 35 specifically names systematic and extensive automated evaluation behind legal or similarly significant decisions, large-scale processing of Article 9 or Article 10 data, and large-scale systematic monitoring of publicly accessible areas. National authority lists can add more cases.
Treat the assessment as a design input. It should change which data crosses the hatch, who can open it, how long receipts stay, and where the system must stop. If high residual risk remains after planned mitigation, consult the competent supervisory authority before processing under Article 36.
After launch, watch the real system. Track grounded-answer quality, unsupported claims, hand-offs, rejected tool calls, approval overrides, access-control failures, complaints, latency, and cost. Run the same evaluation set when the model, prompt, retriever, policy, or tool contract changes. Keep a kill switch that actually removes tools and traffic rather than only hiding the button.
The receipts aren’t paperwork added after the product ships. They are how you tell what crossed the hatch and whether the guard did its job.
The practical integration
The application-side shape is boring in the good way. This is illustrative TypeScript, not a library or a complete compliance recipe:
type AiRequest = {
message: string;
approvedActionId?: string;
};
async function handleAiRequest(request: AiRequest, session: Session) {
const identity = await authenticateSession(session);
const safeInput = minimiseForPurpose(request.message, 'customer-support');
const context = await loadAuthorisedContext({
identity,
query: safeInput,
sources: ['support-policy', 'customer-orders'],
});
const toolContracts = await allowedToolsFor(identity);
const modelResult = await modelGateway.generate({
input: safeInput,
context,
tools: toolContracts,
});
const checked = validateModelResult(modelResult, {
allowedSourceIds: context.map((item) => item.id),
allowedTools: toolContracts.map((tool) => tool.name),
});
const pendingAction = checked.toolRequest
? await requireExplicitApproval(
identity,
checked.toolRequest,
request.approvedActionId,
)
: undefined;
await writeAuditEvent({
tenantId: identity.tenantId,
modelVersion: modelGateway.version,
sourceIds: context.map((item) => item.id),
requestedTool: checked.toolRequest?.name,
actionStatus: pendingAction?.status,
validation: checked.validationSummary,
});
return {
text: checked.text,
sources: checked.sources,
pendingAction,
aiGenerated: true,
};
}The names will differ in a real codebase. The order should not.
Identity comes from a trusted session before retrieval. Minimisation comes before the vendor call. Tool permission comes from the application, not from the model. Validation comes before display or action. Approval identifies one concrete side effect. The audit event keeps enough evidence to investigate without copying the whole conversation by default.
Put the model behind one gateway so model choice, region, retention settings, timeouts, and version reporting have a single owner. Keep retrieval and authorisation separate so changing the embedding model can’t change who may see a record. Keep the tool executor separate so a model swap can’t widen its permissions.
Then test the system, not only the prompt. Try a user asking for another tenant’s order. Put hostile instructions in a retrieved ticket. Return malformed tool arguments. Make the model cite a source it did not receive. Remove the vendor network. Revoke approval between proposal and execution. Ask for deletion and confirm the data leaves logs, caches, and indexes.
That is where an integration becomes dependable.
The model is still only one component
The practical model is small enough to keep in your head:
- Purpose tells the hatch what job it serves.
- The input gate minimises data and enforces access before retrieval.
- The model gateway contains the vendor and version boundary.
- The output gate checks claims, structure, and requested actions.
- The tool broker owns permissions and approval.
- Receipts and monitoring show what happened and when to stop.
- People own the purpose, the exceptions, and the final responsibility.
The EU rules fit that picture because they ask many of the same operational questions. What is the system for? Who provides and uses it? Which people and data does it affect? What must they be told? Which risks need assessment? Can a person intervene? Can you show what happened?
There is no single “AI compliant” switch, and a vendor badge can’t answer those questions for your product. What you can build is a system whose purpose is narrow, whose boundaries are visible, whose decisions can be checked, and whose evidence is available to the people responsible for it.
The model stays on the other side of the service hatch.
Your application decides what passes through.
The interactive demo is hand-authored and runs entirely in your browser. It makes no model or network calls and doesn’t classify a real system. Its controls show the engineering and review questions accurately; the result is orientation, not legal advice.