Controls should match the system.

We design for the deployment boundary the workload actually needs. Availability of a given model depends on the engagement architecture and vendor constraints.

• Public cloud or managed cloud when the workload permits it.
• Dedicated / private cloud or customer VPC when isolation and residency require it.
• Hybrid patterns when data or systems must remain inside customer infrastructure.
• On-premise or self-hosted components where the operational and regulatory case justifies the added complexity.

Data controls are documented per system rather than implied by a generic website promise.

• Data residency, retention and deletion rules are defined per engagement before production.
• Encryption, key-management and network-isolation requirements are selected to match the deployment environment and customer policy.
• Model-provider data handling is reviewed contractually and technically for the providers actually used in the system.
• Sensitive data is minimised by design; systems should not collect or retain information merely because a model can consume it.

Agents need explicit identities and delegated authority, not just API credentials.

• Enterprise identity and SSO patterns can be integrated where the customer environment supports them.
• Agent permissions are scoped to the smallest useful set of resources and actions.
• Read, propose, approve and execute permissions are treated as separate capabilities.
• Privileged or consequential actions can require explicit human approval.

Human oversight is part of the execution design, not a disclaimer placed after the model output.

• Autonomy is chosen per workflow, not per model.
• Human checkpoints are placed at consequential, ambiguous or policy-sensitive steps.
• Systems include defined stop, escalation and recovery behaviour rather than assuming the model will always complete the task correctly.
• Rollback and override requirements are designed with the underlying system of record.

What gets logged depends on consequence, regulation and the systems being touched.

• The audit model is defined before deployment: what must be logged, who can inspect it and how long it is retained.
• Relevant traces can include model calls, tool use, approvals, policy decisions and writes to systems of record.
• Export and SIEM integration are designed to the customer's operational requirements when needed.
• Auditability is part of the architecture; retention periods and tamper-evidence mechanisms depend on the specific deployment.

We avoid unnecessary lock-in, but we do not pretend every provider is interchangeable in every workload.

• Model selection is based on task quality, latency, cost, privacy, safety and deployment constraints.
• Routing and fallback can be introduced where the business case warrants multi-model resilience or cost control.
• Provider changes and model deprecations are treated as lifecycle risks, not surprises.
• Open-weight or self-hosted models are considered when they materially improve control, residency or economics.

Production readiness is measured against the work the system is expected to perform.

• Acceptance criteria are defined against the workflow outcome, not a generic model benchmark.
• Pre-production evals cover representative cases, failure modes and policy boundaries.
• Production evaluation can sample real traces, with privacy and governance appropriate to the deployment.
• Metrics and review cadence are agreed per engagement; we do not claim a universal accuracy or hallucination rate.

Operational telemetry is designed around failure, cost and consequence.

• Metrics, logs and traces are selected around the workflow's operational risks.
• OpenTelemetry-compatible patterns can be used where they fit the customer's observability stack.
• Latency, availability, error and cost thresholds are defined for the system being operated.
• Alerting and dashboards integrate with customer tooling where required by the operating model.

Support commitments belong in the engagement contract and runbook, not in generic marketing copy.

• Incident ownership, severity levels and escalation paths are agreed before production handover.
• Support hours, response targets and any SLAs are contractual choices — not assumed website-wide guarantees.
• Material incidents should feed back into evals, controls, runbooks and architecture decisions.
• Customer communication and post-incident review are defined for the support model actually purchased.

We engineer systems with applicable governance obligations in mind and work alongside the customer's legal, risk, security and audit functions.

• GDPR / RGPD — privacy-by-design and data-governance requirements where applicable.
• EU AI Act — risk classification, transparency, technical documentation and human-oversight considerations where applicable.
• NIS2 — security and supply-chain considerations for organisations within scope.
• ISO/IEC 42001 and ISO/IEC 23894 — useful management and risk frameworks for AI programmes.
• NIST AI RMF — a practical reference for governance, mapping, measurement and management.

Lexdatum is an engineering consultancy. Referencing a regulation or standard means we can design around its requirements where relevant; it does not mean Lexdatum or a customer system is certified, audited or legally compliant by default.

There is no universal client subprocessor list because deployments are engagement-specific.

• This public website is currently hosted on Vercel.
• Model, cloud, email, observability and integration providers are introduced only as the selected architecture requires.
• Before a provider handles customer data, its role, data flow, region, retention and contractual position should be documented for that engagement.
• A current vendor / subprocessor register is provided when relevant to procurement or data-protection review.