Software, AI and data

Your data stays in environments you approve. We prefer to run models in your own cloud account or through enterprise model services that do not train on your data. We agree what data the system may see, mask personal data where the task allows, and log access. Data used for evaluation is stored under the same rules as production data.

Read more: AI developmentLink to this question

Not if we can help it, and we design to prevent it. We use enterprise model services whose terms exclude training on your data, or open models hosted in your own environment. Prompts and documents are sent only to the services you approve, logs are kept under your retention rules, and personal data is masked where the task allows.

Read more: Generative AI and LLM integrationLink to this question

Yes, and we design for it from the start where decisions affect people, such as credit or claims. We prefer models whose reasoning can be explained, provide reasons for individual results, and document the data, features, validation and limits of each model version. That documentation supports your model-risk and regulatory reviews.

Read more: Machine learningLink to this question

We agree with you which groups and outcomes matter for the decision, then measure error rates and results across them on held-out data. Where differences appear, we investigate the data and features behind them and discuss the trade-offs with your team. Fairness checks are rerun with every retraining, not only at launch.

Read more: Machine learningLink to this question

Access is role-based and follows your identity provider. Personal and financial fields are masked or tokenised for users who do not need them, data is encrypted at rest and in transit, and access is logged. We keep data in the regions you specify and apply your retention rules to raw and modelled data alike.

Read more: Data engineering and analyticsLink to this question

Documents are stored encrypted in an environment you approve, processed by services whose terms exclude training on your data, and kept only as long as your retention rules allow. Access to the review screen is role-based, personal data is masked where it is not needed, and every view and change is logged.

Read more: Intelligent automation and document AILink to this question

We follow the OWASP guidance: input validation, output encoding, protection against cross-site request forgery, secure session handling and a strict content security policy. Permissions are checked on the server, never only in the browser. Dependencies are scanned for known vulnerabilities on every build, and we run security tests before each release. A specialist penetration test can be added before launch.

Read more: Web applicationsLink to this question

We keep keys and tokens in the platform’s hardware-backed secure storage, never in plain files. We use certificate pinning, biometric or device-bound sign-in, and server-side checks for every sensitive action. Where the risk calls for it, we add detection of rooted or jailbroken devices and tampered builds. We follow the OWASP Mobile Application Security guidance and can support an external penetration test before launch.

Read more: Mobile appsLink to this question

Identity comes first: single sign-on, least-privilege roles and no shared credentials. Networks are segmented, data is encrypted at rest and in transit, and secrets live in a managed vault. Guardrails block insecure configurations before they are deployed, pipelines scan code and images for known vulnerabilities, and audit logs are kept where nobody can alter them.

Read more: Cloud and DevOpsLink to this question

We map and profile the data first, so problems are found before migration rather than after it. Migrations are scripted and repeatable, run against copies first, and reconciled with counts and totals that show nothing was lost or altered. Personal and sensitive data is protected throughout, and access to it is limited to named people.

Read more: Legacy modernisationLink to this question