Germany POC: Architecture, Security and Delivery Model

01

Target architecture & data flows

The platform separates two planes: a control plane where configuration is defined and stored, and a runtime plane where conversations are processed.

For the Germany POC, hosting region, encryption boundaries and data residency are agreed with you up front, and the deployment operates only within those approved regions.

The platform controls agent configuration. It does not run the agent.

Once configuration is complete, a runtime instance is started that pulls its settings from the platform database, compiles its own copy of the system prompt, and from then on runs independently, with capacity added automatically as load increases.

AI agent platform architecture: control plane and runtime plane

Two flows, always running in parallel

Two flows running in parallel: runtime request flow and control-plane configuration flow

Where each class of data lives

Data type	Stored in	Owned by	Germany POC position
Agent configuration	Curizen Platform Database	Curizen platform	Region fixed to the agreed EU deployment region
Knowledge data	Customer database	Carglass	On infrastructure Carglass controls
Conversations	Customer-configured storage	Carglass	Storage target and retention set by Carglass
Logs	Defined environment	Customer policy	Separate from conversation content

Data residency is a deployment choice. The infrastructure region is not fixed by the platform's architecture. Confirming the AWS region for the Germany POC is item 1 of the readiness gate in §07.

02

Product layer vs. custom build

This section sets out how much of the agent Carglass can change independently after the POC.

The scope is the console surface: sixteen configuration areas, all self-service and all versioned. What sits outside it is a short and specific list.

Everything in the first column below is a configuration screen. Changing it produces a new immutable version, is testable in the Playground, and is publishable and reversible by an authorised Carglass user, with no Curizen involvement and no release cycle on our side.

Carglass configures without Curizen development

Self-service console

Identity & scope: company, department, business role, objective, target audience, working hours, responsibilities, hard limitations
Prompt Studio: personality (warmth, formality, autonomy, response depth), tone, greeting, response length, technical level, response format
Behaviour rules: always do / never do / ask permission before / escalate to human when
Capabilities: enable only what's required: booking, CRM access, payments, human handoff, SMS, email
Policies: payment confirmation, small talk, call recording, sensitive-data masking
Knowledge: add documents, websites, text or database sources; chunking, retrieval strategy (semantic / hybrid / keyword), top-K, similarity threshold, reranking, source priority
Response control: hallucination protection, confidence threshold, fallback behaviour (clarify / cite / hand off)
Channels: website widget styling, phone, WhatsApp, email
Versions: compare, publish, roll back
Users, roles, permissions: view / edit / publish, per product area

Configured jointly at setup

One-time, with Curizen

AWS region, encryption boundary and data-residency decision
Connection of Carglass systems (CRM, calendar, ticketing, help desk, telephony) with OAuth / API key / credential setup
Tool definitions against Carglass APIs: input schema, output schema, authentication, validation, error handling, approval workflow (AI-assisted import and a basic builder exist; Carglass can create and edit tools thereafter)
Storage provider and database connection (PostgreSQL, MySQL, SQL Server, MongoDB, Supabase; PostgreSQL optionally as vector store)
Model and voice provider selection, retention policy per data type, escalation contacts and SLA

Requires Curizen engineering

Outside the console surface

New channel types or providers not on the supported list
Platform-level features not exposed as configuration
Bespoke integration patterns that cannot be expressed as a tool schema through the API gateway
Changes to the runtime, isolation model or platform database itself

Change without engineering, end to end

Carglass user edits config→ New immutable version→ Playground test + trace→ Publish→ Live on every channel→ Roll back if needed

Fig. 4. A configuration change in Prompt Studio or Knowledge takes effect on every channel simultaneously, with no separate work per channel

03

Security, GDPR, residency and data handling

Encryption, access, masking, retention, deletion and the full subprocessor register, including exactly what each third party receives and what it never sees.

No single control is relied on alone. Data is protected at every layer it passes through, so that one control failing does not mean data is exposed.

Defence in depth: six layers

1

Network & transport

Every connection between every party (customer channel, gateway, agent runtime, model provider, knowledge database) is encrypted in transit via TLS. Nothing moves between systems in plain text.

2

Identity & access

Every person and every system component authenticates before it can act. Role-based permissions determine exactly what a given user can view, edit or publish. Nobody has broader access than their role requires.

3

Data at rest

Configuration, system-prompt copies, recorded conversations and knowledge content are encrypted at rest in every database, both the platform database and Carglass's own knowledge database.

4

Application & AI behaviour

Guardrails, prompt-injection protection and hallucination detection constrain what the agent itself can be made to do or say, independent of the infrastructure around it.

5

Audit & accountability

Every sensitive action (a configuration change, a permission change, a key rotation, a rollback) is logged with who did it, when, and what changed.

6

Governance

Agent governance settings, release approval and compliance monitoring are reviewed as one programme, not as five disconnected controls.

Call, transcript and log handling

Masking at the point of capture

User-identifying information is masked in stored conversation records before the record is written, not redacted after the fact.
A recording can be kept for quality and audit purposes without exposing who the customer was.

Minimising what leaves the platform

Only the data a specific step actually needs is passed to that step. The language model, the voice provider and any external tool each receive the minimum required, not the full customer record.
Nothing is sent to an external provider beyond what the configured task requires.

Separation by design

Agent configuration and customer knowledge sit in physically separate databases, so compromise of one does not automatically expose the other.
Application, error and access logs are kept separate from conversation content, so operational troubleshooting never requires exposing customer conversations.

Recording is opt-in

Call recording is a per-agent policy setting, not a default.
Recordings are only retained where recording is explicitly enabled.

Data lifecycle

Capture

Encrypted in transit from the channel

Processing

Masked before storage; minimal data sent to providers

Storage

Encrypted at rest; knowledge in Carglass's own database

Retention

Held per configured policy, not indefinitely

Deletion

Enforced on request or on schedule, across every store

Retention & deletion matrix

Every category of stored data has a defined retention period and a defined method of deletion, not a single blanket policy.

Data	Retention	Deletion method
Transcript	Per configured policy, matching Carglass's regulatory requirements	Manual on request, or automatic on retention expiry
Recording	Per configured policy; only retained where recording is explicitly enabled	Manual on request, or automatic on retention expiry
Logs	Operational retention window, separate from conversation content	Automatic on retention expiry
Knowledge	Until the source is removed or superseded by Carglass	Manual removal, propagated to every index and cache

Retention periods are configurable, not hard-coded. Right-to-delete requests are honoured by removing the corresponding data from every store it exists in, including recorded conversations.

GDPR roles

Party	GDPR role
Carglass / Belron	Data Controller: determines the purpose and means of processing its own customers' data
Curizen	Processor: processes data on Carglass's behalf, per Carglass's instructions and configuration
Amazon Bedrock · ElevenLabs · Amazon Polly	Subprocessors: engaged by Curizen for specific processing functions, under enterprise data-processing terms

Subprocessor register: who touches what

Provider	Function	Data access	Region	DPA status
AWS	Hosting, compute, storage, networking	Infrastructure-level access only; application data encrypted at rest	Agreed deployment region	AWS DPA
Amazon Bedrock	Language model	Only the minimised request context for that turn; no persistent access to platform or customer databases	Agreed deployment region	Covered under AWS DPA
ElevenLabs	Conversational voice	Audio / text for the current turn only	Agreed deployment region	Confirmed per subprocessor agreement
Amazon Polly	Text-to-speech	Text to synthesise for the current turn only	Agreed deployment region	Covered under AWS DPA

Access control: who or what can reach what

Who or what	What they can reach	Control
A console user	Exactly what their role permits: view, edit or publish, per product area	Role-based permission matrix
An external integration	Only the specific API calls it is configured to make	Scoped credentials, per-tool authentication (OAuth, API key)
The AI model provider	Only the conversation context and knowledge passed to it for that request	Data minimisation at the request boundary

04

LLM & AI governance

Model providers, guardrails, prompt-injection protection, hallucination controls, and an unambiguous position on training.

Model stays inside the deployment

The language model runs within the customer's own AWS environment, not on a shared external endpoint that pools data across customers.

Enterprise data terms

Every provider is used under enterprise-grade data-processing agreements that exclude training on customer content. This is a contractual guarantee, not only an architectural one.

No feedback loop

Conversation data flows one way, into storage and monitoring, and never back into a training pipeline for the underlying model.

Providers used at runtime

Amazon BedrockLanguage model, used for every deployment by default

ElevenLabsConversational voice, for real-time speech in voice agents

Amazon PollyText-to-speech, used alongside ElevenLabs per configuration

Provider and model selection is a configured, versioned setting, reviewed as part of release approval. It is not an implicit runtime default that can drift.

Four named safeguards

Prompt-injection protection

System instructions and live user input are kept structurally separate, so a customer's message cannot rewrite the agent's underlying rules or permissions.

Guardrails

The agent operates only within its configured scope, tools and behaviour rules. It cannot act outside what it was explicitly given.
Active on every deployment, not an optional add-on.

Hallucination controls

Responses are grounded in retrieved knowledge against a confidence threshold.
Below threshold, the agent asks for clarification, cites sources, or hands off to a human rather than answering speculatively.

Human oversight

Behaviour rules define exactly when a conversation escalates to a person. Sensitive, ambiguous or out-of-scope situations are not left to the model alone.
Risk classification and human-approval requirements are set per agent.

Data minimisation at the model boundary

Carglass customer database→ Only the required context for this turn→ LLM provider

Fig. 5. The full customer record never leaves Carglass's own database

05

Monitoring, testing, release & rollback

Every configuration change creates a new immutable version, never an edit to the version already serving customers. Rollback is always to a real, previously-running configuration.

Release management & version lifecycle

Release management and version lifecycle: edit, save, test, publish, rollback

Automatic rollback

Triggered by operational metrics such as error rate, latency and failed tool calls, without waiting for a person to notice.

Manual rollback

An authorised administrator can roll back to any prior version directly from the console.
Every prior version stays available, with version compare and change summary.

Testing before anything reaches a customer

Playground

Text chat and voice simulation against the exact version under review.
Trace view: retrieved knowledge, tool calls, confidence, latency.

Health gating

An instance must pass a health check before it accepts any traffic.
Security validation of credentials, network policy and encryption config runs before deployment.

Version comparison

Each version stores identity, prompt, policies, knowledge, retrieval and capabilities.
Compare versions and review a change summary before publishing.

Monitoring & reporting

Conversation qualityResponse time · resolution rate · tool success · knowledge accuracy · CSAT

InfrastructureRunning instances · req/min · CPU & memory · error rate · p95 latency

CommercialCost per conversation, per channel, per activity · forecasting

Conversation-level reporting

Full transcript, tool calls, knowledge citations and customer satisfaction, per conversation.
Knowledge quality monitoring: retrieval accuracy, knowledge gaps, source quality.

Infrastructure reporting

Live table, one row per instance: availability zone, status, CPU/memory, req/min, error rate, uptime.
Searchable event and log table: scaling actions, health-check results, recovered errors.
Always references the currently active published version, so it is clear which configuration the running instances serve.

Incident handling & escalation

Detected by metric or report→ Console self-service→ Platform support→ Engineering→ Rollback / fix→ Post-incident review

Fig. 7. Named contacts at each step; SLA response times agreed per deployment and scaled to incident severity

Planned maintenance is scheduled and communicated in advance, and does not bypass the version-controlled release process.

06

Integration, handover, IP & support

How the agent reaches Carglass backend systems, how a conversation is escalated to a person, how intellectual property and data ownership are divided, and how support is provided.

API & backend integration

Tool calls and enterprise-system integrations reach the outside world through the same layered path, never a direct connection from the model to an external system.

Carglass external systemCRM · booking · ticketing · other backend

↑↓

API GatewaySingle controlled entry / exit point for backend calls

↑↓

Authentication layerOAuth / API key / secrets, scoped per tool

↑↓

Tool execution layerRuns the specific tool call, per its configured schema

↑↓

Agent runtime

Fig. 8. Every hop encrypted in transit and authenticated independently; a credential scoped to one tool cannot be reused to reach a different system through the same gateway

Tool definition & control

Input schema, output schema, authentication, validation, error handling, approval workflow.
Lifecycle: draft → testing → published → disabled → archived.
Execution logs record input, output, duration and status for every call.

Integration surface

CRM, calendar, ticketing, help desk, messaging, telephony.
Authentication by OAuth, API key or credentials.
Creation by AI-assisted import, basic builder or advanced builder.

Human handover

Customer→ Agent→ Low confidence / policy trigger→ Human agent→ Context transfer→ Conversation continues

Fig. 9. Escalation is a defined path back to a person, not a dead end

The escalation policy is configured per agent. Full conversation context transfers with the handover, so the customer never has to repeat themselves.

IP & data ownership

Curizen owns

The platform, the agent runtime and the underlying framework, which is the software itself.

Carglass owns

Its own data, knowledge base, conversations and business configuration, meaning everything the platform is configured to hold on Carglass's behalf.
Anything generated from Carglass's own use of the platform.

Documentation & support model

Documentation

Developer Center: APIs, SDKs, webhooks and documentation.
Per-agent configuration is self-documenting through the compiled prompt view and version history.

Support

A named Curizen contact point for the deployment.
Escalation: console self-service → platform support → engineering.
SLA response times agreed per deployment, scaled to incident severity.
Planned maintenance scheduled and communicated in advance.

07

Germany POC readiness gates

Before any use of real customer data or any customer-facing exposure, every item below is confirmed and jointly signed off. A partial gate does not permit customer-facing exposure.

AWS region confirmed
Deployment region agreed with Carglass and locked before provisioning.
Encryption verified end to end
In transit and at rest, across every hop in Fig. 1.
PII masking confirmed active
Verified before any conversation record is stored.
Role-based permissions configured
For all named Carglass users, per product area.
Subprocessor list & DPA status accepted
Reviewed by Carglass data protection.
Retention & deletion policy configured
Per data type: transcript, recording, logs, knowledge.
Agent governance settings reviewed
Risk classification and human-approval rules for the agreed use case.
Accuracy & guardrail test pass completed
Against the agreed use case, evidenced in the Playground.
Incident & support escalation path confirmed
With named contacts on both sides and agreed SLA.