Governance, Risk & AI Safety

The solution processes customer personal data in order to identify callers, access account information, and resolve interactions. All personal data processing is conducted in accordance with UK GDPR and, for European deployments, the EU GDPR. Data is processed only for the purposes defined in the service agreement and is not used for any other purpose, including AI model training on customer data without explicit consent.

For UK customers, data is stored and processed within the UK and EU. For European customers requiring full data sovereignty, the solution can be deployed entirely within the EU, hosted on AWS EU infrastructure. This is a critical requirement for an increasing number of public sector and regulated organisations and is built into our standard European deployment architecture.

Customer interaction data — transcripts, call recordings, and chat logs — is used solely to improve the performance of the AI for that specific customer’s deployment (customer-specific fine tuning), not to train a shared or generic model. Data from one customer’s deployment is never used to train or improve the model for another customer. This is a key differentiator from many generic AI platforms.

Access to interaction data is strictly controlled by role-based access controls (RBAC). Within the customer organisation, access is limited to authorised personnel defined during the security and guardrails workshop. StableLogic accesses interaction data only for performance monitoring, quality assurance, and improvement purposes, under the terms of the data processing agreement.

Yes. StableLogic provides a full Data Processing Agreement as standard, covering the roles of data controller and data processor, the categories of data processed, retention periods, sub-processor details, and the rights of data subjects. This is provided at contract stage and can be reviewed by your legal and information governance teams prior to signature.

Default retention periods are defined in the service agreement and are configurable to meet your organisation’s data retention policy. Interaction transcripts, recordings, and summaries can be automatically deleted after a defined period. Audit logs are retained for a minimum period to support compliance and complaints handling requirements.

Safeguarding is built into the solution by design, not as an afterthought. The AI uses real-time sentiment analysis to identify customers who may be distressed, confused, or vulnerable. When these signals are detected, the AI adjusts its behaviour — slowing the interaction, offering clearer options, and proactively offering human escalation. The specific triggers and escalation pathways are defined with each customer during the Security and Guardrails workshop.

The AI is configured with sector-specific safeguarding triggers — for example, references to domestic abuse, mental health crisis, or self-harm — that result in immediate escalation to a human agent and, where appropriate, signposting to relevant support services. These triggers are defined in collaboration with the customer’s safeguarding team before go-live.

All escalation pathways for vulnerable customers are defined, documented, and tested before go-live. The AI’s behaviour in sensitive scenarios is tested as part of the testing phase and reviewed in the first weeks of operation. Human agents who receive escalated vulnerable customer interactions are trained in the context they will receive from the AI handoff.

The option to speak with a human agent is always available and is never suppressed. The AI is designed to offer human escalation proactively in any interaction where it detects complexity, distress, or customer preference. There is no point in any AI-handled interaction where the customer is unable to reach a human if they need to.

The solution operates within a governance framework that is defined and agreed with each customer before go-live. This includes a documented set of policies, guardrails, escalation procedures, and performance metrics. The framework is reviewed at regular intervals and updated as the solution evolves, the customer’s requirements change, or the regulatory environment shifts.

Guardrails are defined during a dedicated Security and Guardrails workshop, which takes place before implementation begins. This workshop identifies the actions the AI is permitted to take, the scenarios in which it must escalate, the language and tone it is permitted to use, and the boundaries of its knowledge and authority. These guardrails are implemented as hard constraints in the system configuration — not as suggestions to the AI.

The AI can take actions of this type only where they are explicitly within the guardrails agreed during the Security and Guardrails workshop, and only within the authorisation boundaries defined by the customer. For high-value or high-risk actions, additional confirmation steps can be built into the workflow — for example, requiring the customer to confirm by SMS before a refund is processed.

For Social Housing, the solution is configured to support compliance with the Housing Ombudsman’s complaint handling requirements, the Regulator of Social Housing’s Transparency, Influence and Accountability standard, and consumer regulation requirements. For Healthcare, the solution is designed to support CQC-aligned service delivery and relevant NHS frameworks. For Public Sector, the solution is designed to meet Government Digital Service (GDS) accessibility standards, including WCAG 2.1 AA. For all regulated sectors, a sector-specific compliance review is included in the discovery phase.

The UK government operates a principles-based approach to AI regulation, built around five cross-sectoral principles: safety, security, fairness, accountability, and transparency. StableLogic’s governance framework is explicitly designed to address all five principles. We monitor developments in UK AI regulation, including the AI Safety Institute’s guidance, and update our governance framework accordingly.