Security, privacy and responsible AI, stated precisely

Access to the NLAI admin area follows one permission matrix, with separate roles for administration, content editing, sales, training and event staff. The matrix is enforced on the server for every admin page, action and API, so the interface never decides on its own who may see or change what. Content changes made in the admin are recorded with who made them, what changed and when.

Passwords are stored only as bcrypt hashes, never in readable form. After five failed sign-in attempts for an account from the same address within 15 minutes, sign-in for that combination is paused. Event tickets and shared feedback links use random codes of at least 128 bits, and only a SHA-256 hash of each code is stored, so the links cannot be recovered from our database. Admin sessions expire after eight hours.

The platform sends a strict content security policy that limits the sources of scripts, styles and network connections to its own origin, and forbids other sites from showing it in a frame. Further headers stop content-type sniffing, limit referrer information and isolate the browsing context. Camera access is allowed only on the event check-in scanner. Public form endpoints, including contact, careers, newsletter, event registration, feedback and programme enrolment, are rate-limited per client address.

Our site analytics are first-party: events go to our own server, not to an advertising network. No IP address, user agent, email address or free text is stored with an analytics event, and every event property is checked against an allowlist on the server. A random, anonymous identifier is kept on your device only if you accept analytics cookies, and a Global Privacy Control signal is treated as a refusal.

Our approach to your data:

• Only what is needed. We agree at the start which data an engagement needs, and work with the smallest set that answers the question.
• Your environment first. Where possible, data stays in systems you control and we work inside them rather than copying it to ours.
• Least-privilege access. Access is granted per person and per purpose, and removed when the work ends.
• Retention agreed up front. How long working copies are kept, and how they are deleted, is agreed before work starts.
• Your obligations, mapped. We map data flows against the rules that apply to you, such as Saudi Arabia's Personal Data Protection Law (PDPL) or the EU General Data Protection Regulation (GDPR), and design controls together with your compliance team. We do not certify compliance on your behalf.

We treat where a system runs as an architecture decision, made with you against your requirements for data location, security, latency and cost:

• Public cloud — managed services in a cloud region you choose, including regions inside the Kingdom where your provider offers them.
• Private cloud — your own virtualised environment, using the same deployment pipeline.
• On-premises — installed in your own data centre when data must not leave your premises.
• Edge — models running on devices close to where data is produced, such as cameras and machines, when latency or connectivity demands it.

The chosen option and the reasons for it are recorded in the architecture documentation we hand over.

Our approach starts from the decision an AI system supports, not from the model:

• Purpose first. Each system has a documented purpose, the decisions it may support and the decisions it must not make.
• Transparent by design. People can tell when they are working with AI output, and the system can show what its output is based on.
• Fairness checked. We test for uneven performance across the groups and cases that matter for the use case, before and after release.
• Accountable people. Each system in production has a named owner on your side who is accountable for how it is used.

For each AI system we deliver, our approach produces governance records your team keeps using after handover:

• An entry in a use-case register with purpose, owner, data sources and risk level.
• A risk assessment covering data, model, security and operational risks, with the agreed mitigations.
• A model card describing training data, evaluation results, known limitations and intended use.
• Decision rights and change control: who approves a new model version, a new data source or a change of use.

We design the level of human involvement into the workflow instead of adding it afterwards:

• A human in the loop where AI output feeds a decision with material impact on people, money or safety: a person reviews and approves before it takes effect.
• Confidence thresholds send uncertain cases to people instead of forcing an automated answer.
• Override and escalation are available in the interface, and overrides are logged so the model can be reviewed.
• A stop switch: the owner of every automated flow can pause it without a code change.

Before release, our approach validates each model against acceptance criteria agreed with you:

• Held-out evaluation on data the model has not seen, representative of real operating conditions.
• Error analysis of the cases the model gets wrong, reviewed with your domain experts.
• Robustness checks against noisy, missing or unusual inputs.
• Monitoring after release of accuracy, data drift, latency and cost, with thresholds that trigger a review.

A model that does not meet its criteria does not pass the release gate.

Our approach is that a delivered system must keep running without us:

• Runbooks for operation, monitoring, incident handling and recovery.
• Rollback plans for every release, rehearsed before go-live.
• Your accounts, your code. Infrastructure, repositories and credentials are set up under your ownership.
• A documented handover, so that another qualified team could take over operation.